Produtos
Soluções
Empresa
Empresas
EntrarCrie sua rede
AI · Interpretability · Forecasting

Interpretabilidade precisa da interação, não da feature

SHAP encontrou «trolley»; SPEX encontrou a sinergia de 4 palavras que a impulsiona. Uma feature não é um mecanismo. Theorem 3: uma propriedade só se garante com interação implementada e medindo.

Interpretabilidade precisa da interação, não da feature

SPEX e ProxySPEX da BAIR Berkeley identificam interações influentes em large language models em escala, onde a feature attribution vê apenas features individuais. A leitura do Honest Architect é um nível mais fundo: uma feature não é um mecanismo. A interação é. No trolley problem, SHAP culpou a palavra "trolley" e trocá-la por sinônimos não fez nada; SPEX encontrou a sinergia de 4 palavras (trolley×2 + pulling + lever), e trocar essas quatro baixou a taxa de falha a quase zero. O mecanismo era a interação, e a feature era uma pista falsa.

Conclusões-chave

  • SPEX (Spectral Explainer) e ProxySPEX identificam interações influentes em LLMs em escala, estendendo o descobrimento de interações de dezenas a milhares de componentes (BAIR Blog, "Identifying Interactions at Scale for LLMs", 2026).
  • Uma feature não é um mecanismo. No trolley problem, GPT-4o mini respondeu corretamente apenas 8% das vezes; SHAP culpou a palavra "trolley", mas SPEX encontrou a sinergia de 4 palavras (trolley×2 + pulling + lever), e substituir essas quatro baixou a falha a quase zero.
  • ProxySPEX iguala SPEX com ~10x menos ablations ao adicionar a propriedade de hierarchy a sparsity e low-degreeness.
  • Theorem 3: uma propriedade se garante exatamente quando seu mecanismo está implementado e medindo — faithfulness é a propriedade, sparse recovery é o mecanismo, e a interação é o que o mecanismo mede.

SHAP encontrou a feature; SPEX encontrou o mecanismo

Em 2026, o BAIR Blog publicou "Identifying Interactions at Scale for LLMs," descrevendo SPEX (ICML 2025) e ProxySPEX (NeurIPS 2025), algoritmos que identificam interações influentes em LLMs usando ablation e sparse recovery. A demonstração mais limpa é o trolley problem. Uma versão modificada onde "True" é a resposta claramente correta ainda obtém a resposta correta do GPT-4o mini apenas 8% das vezes. A feature attribution padrão (SHAP) identificou instâncias individuais da palavra "trolley" como os drivers primários da resposta incorreta. Substituir "trolley" por sinônimos como "tram" ou "streetcar" teve pouco impacto — a feature foi nomeada, mas a predição não mudou, porque a feature não era o mecanismo.

SPEX contou uma história mais rica. Identificou uma sinergia de alta ordem dominante entre as duas instâncias de "trolley" e as palavras "pulling" e "lever" — quatro palavras cuja presença conjunta impulsionava a falha, e cuja presença individual não. Quando essas quatro palavras foram substituídas por sinônimos, a taxa de falha do modelo caiu a quase zero. Essa é a distinção do Honest Architect em um exemplo: uma feature attribution diz qual feature correlaciona com o output; uma interaction attribution diz qual mecanismo o produz. SHAP mediu uma feature; SPEX mediu o mecanismo, e o mecanismo era a interação.

A implicação para a interpretabilidade é a mesma que o Theorem 3 traça para qualquer propriedade. Uma propriedade se garante exatamente quando seu mecanismo está implementado e medindo. "Sabemos o que impulsiona o modelo" é uma propriedade, e ela se cumpre exatamente quando a medição captura a interação, não a feature. Uma feature attribution que perde a interação é uma medição da coisa errada, e uma medição da coisa errada é pior que nenhuma medição, porque faz o modelo parecer explicado quando não está. O caso do trolley é a prova: SHAP disse "trolley", a equipe trocou "trolley", e nada mudou, porque o mecanismo eram quatro palavras agindo juntas.

Sparsity, low-degreeness, hierarchy: a estrutura que torna a recuperação tratável

A razão de SPEX funcionar em escala é uma observação estrutural, não um computador maior. Enquanto o número total de interações em um modelo cresce exponencialmente com o número de features, data points e componentes, o número de interações influentes é na verdade pequeno. SPEX formaliza isso com duas propriedades: sparsity (relativamente poucas interações realmente impulsionam o output) e low-degreeness (interações influentes tipicamente envolvem apenas um subconjunto pequeno de features). Estas tornam uma busca intratável em um problema tratável de sparse recovery, tomando ferramentas de signal processing e coding theory — ablations estrategicamente selecionadas que combinam muitas interações candidatas, depois decoding eficiente para desembrulhá-las.

ProxySPEX adiciona uma terceira propriedade: hierarchy. Onde uma interação de alta ordem é importante, seus subconjuntos de baixa ordem provavelmente também são. Essa estrutura adicional dá uma melhoria dramática: ProxySPEX iguala o desempenho de SPEX com cerca de 10x menos ablations. Num problema onde cada ablation é uma chamada de inferência cara ou um retraining, 10x menos ablations é a diferença entre um método que roda em tempo de pesquisa e um que roda em tempo de produção. SPEX estende o descobrimento de interações de dezenas a milhares de componentes, e ProxySPEX torna os milhares acessíveis.

A leitura do Honest Architect é que este é um mecanismo de medição desenhado em torno da forma da propriedade. Sparsity, low-degreeness e hierarchy são reclamos sobre como a propriedade de interação influente é estruturada, e o algoritmo é construído para medir exatamente essa estrutura. Um mecanismo que ignora a estrutura — ablation exaustiva, ou marginal attribution que promedia interações — mede a coisa errada a um custo que a equipe não consegue carregar. O texto nomeia isso: abordagens marginais (LIME, Banzhaf) podem operar a milhares de features mas exibem faithfulness significativamente menor, porque não capturam as interações complexas que impulsionam o output. Faithfulness é a propriedade; o mecanismo consciente da estrutura é o que a sustenta.

O Oracle mede a interação, não a Sister

[PERSONAL EXPERIENCE] O HAI Engine roda em produção desde 2016, e a medição de ensemble que mantemos tem a mesma forma que a recuperação de interações de SPEX. O Oracle normaliza probabilidades em exatamente um lugar, e a soma-para-um e a entropia do ensemble são verificadas a cada merge. A entropia é a medição de interação: nos diz quando as Sisters discordam o suficiente para importar, e um merge de baixa entropia é uma interação redundante (as Sisters estão dizendo a mesma coisa) enquanto um de alta entropia é sinérgico (as Sisters contribuem evidência distinta). Essa é a mesma distinção que o texto traça para data attribution — interações redundantes reforçam um conceito, interações sinérgicas definem um decision boundary — e é por que mantemos a entropia, não um score per-Sister.

Uma medição per-Sister é a feature attribution do ensemble. Diz qual Sister contribuiu qual massa de probabilidade; não diz qual interação entre Sisters produziu o forecast calibrado. O merge do Oracle é o mecanismo, e a entropia é sua medição, da mesma forma que o sparse recovery de SPEX é o mecanismo e faithfulness é sua medição. Tagueamos a calibração do Oracle como Production ✅ porque o mecanismo está implementado e a medição está a cada merge, não porque confiamos nas Sisters individualmente. As Sisters são modelos; o merge é a propriedade.

O resultado de data attribution do texto é a mesma lição na camada de training data. ProxySPEX num ResNet treinado no CIFAR-10 encontrou interações sinérgicas onde classes semanticamente distintas trabalham juntas para definir um decision boundary (um automobile compartilhando traços visuais com um sports car, um truck, um delivery vehicle) e interações redundantes onde duplicatas visuais reforçam um conceito (uma predição de horse influenciada por um cluster de imagens de dog com silhuetas similares). A análise fina permite preservar sinergias necessárias enquanto remove redundâncias com segurança. O equivalente em ensemble é: mantenha os merges de alta entropia que carregam evidência distinta; pode os de baixa entropia que carregam duplicatas. A entropia é a medição que diz qual é qual.

A topologia é onde as interações influentes vivem

[UNIQUE INSIGHT] O descobrimento de interações do texto opera em três camadas — feature, data e model component — e perde uma quarta que importa para qualquer sistema em produção: a topologia. The space is the router. Uma topologia de network, community e room decide quem vê o quê antes de qualquer coisa responder, e essa decisão de roteamento é uma interação — entre a requisição, o escopo do room e o agente que dispara. A interação influente nem sempre está dentro do modelo; está frequentemente entre o modelo e o room ao qual a topologia o roteou. Um método de interpretabilidade que para na camada de feature perde a interação de roteamento que decidiu quais features o modelo sequer viu.

Esta é a adição do Honest Architect à agenda do texto. O texto fecha nomeando a questão em aberto de unificar as três perspectivas — feature, data, component — num entendimento holístico de um sistema de machine learning. A vista unificada precisa de uma quarta camada: a topologia que roteia a requisição ao modelo em primeiro lugar. Um modelo que se comporta diferente em dois rooms não são dois modelos; é um modelo cuja interação influente inclui o room, e a topologia é o mecanismo que produz essa interação. Interpretabilidade que ignora a topologia explicará o modelo e perderá o sistema.

O limite de escopo civil-e-defensivo é uma interação ao nível de topologia no nosso caso. É uma política escrita que decide quais requisições roteiam a quais agentes, e a medição é o deal que declinamos, observável no pipeline. A soberania do cliente — sua network, seu brand, seu data — é outra: a regra de roteamento que mantém a topologia sua, com o export log como medição. Ambas são interações entre a requisição e a topologia, e ambas são propriedades que se cumprem exatamente quando seu mecanismo está implementado e medindo — o mesmo teste que SPEX aplica às features, aplicado uma camada acima.

Theorem 3: faithfulness é a propriedade, sparse recovery é o mecanismo

[ORIGINAL DATA] the 21 papers especifica o Theorem 3: uma propriedade se garante exatamente quando seu mecanismo está implementado e medindo. Leia como o teste para cada reclamo de interpretabilidade. "Podemos explicar o output do modelo" é uma propriedade, e se cumpre exatamente quando o mecanismo de medição captura as interações influentes — não as features, não as contribuições marginais, as interações. O score de faithfulness de SPEX é a medição; o sparse recovery sobre sparsity, low-degreeness e hierarchy é o mecanismo; a propriedade se cumpre quando o mecanismo está implementado e o score de faithfulness está num dashboard que alguém olha.

Por isso nossas etiquetas de honestidade não são adjetivos. Production ✅ significa que o mecanismo está implementado e sua medição é observada. A entropia do Oracle é Production ✅ porque é verificada a cada merge. O roteamento da topologia é Production ✅ porque a network, community e room roteiam antes de qualquer coisa responder. Um score de interpretabilidade não é uma etiqueta por si; é uma medição, e uma medição sem um mecanismo é um número, não uma propriedade. O texto é honesto sobre isso — avalia SPEX por faithfulness, que é se as attributions recuperadas predizem o output do modelo em test ablations não vistos, e esse é o teste correto, porque mede se o mecanismo realmente captura a propriedade.

O mesmo teorema é por que não prometeremos resultados de Wallet & Token, Super App, ou Community Credit — esses são Roadmap 🔵, o mecanismo ainda não está implementado e medindo, e um forecast que não podemos medir não é um forecast que podemos vender honestamente. Apenas escopo civil e defensivo, e sem promessas de resultados de token ou community-credit, porque o review Howey não rodou sobre um mecanismo que ainda não existe. Taguear um item Roadmap com o brilho de um resultado de interpretabilidade seria o mesmo erro que chamar uma feature attribution de mecanismo — uma medição da coisa errada, apresentada como uma propriedade.

Perguntas frequentes

O que SPEX encontrou que SHAP perdeu no trolley problem?

GPT-4o mini respondeu o trolley problem modificado corretamente apenas 8% das vezes. SHAP identificou instâncias individuais da palavra "trolley" como os drivers, mas trocar "trolley" por sinônimos não fez nada. SPEX encontrou uma sinergia de 4 palavras (trolley×2 + pulling + lever), e substituir essas quatro por sinônimos baixou a taxa de falha a quase zero. SHAP mediu a feature; SPEX mediu o mecanismo, e o mecanismo era a interação.

Por que SPEX escala quando a ablation exaustiva não?

Por três propriedades estruturais: sparsity (poucas interações realmente impulsionam o output), low-degreeness (interações influentes envolvem um subconjunto pequeno de features), e hierarchy (interações de alta ordem implicam que seus subconjuntos de baixa ordem importam). Estas tornam uma busca exponencial num problema tratável de sparse recovery. ProxySPEX adiciona hierarchy e iguala SPEX com ~10x menos ablations.

Como a entropia do Oracle é a mesma forma que a recuperação de interações de SPEX?

Ambas medem a interação, não o indivíduo. SPEX recupera interações influentes entre features; a entropia do Oracle mede a interação entre Sisters a cada merge. Um merge de baixa entropia é uma interação redundante (evidência duplicada); um de alta entropia é sinérgico (evidência distinta). O score per-Sister é a feature attribution do ensemble; a entropia é a medição do mecanismo.

Como o Theorem 3 se aplica à interpretabilidade?

Uma propriedade se garante exatamente quando seu mecanismo está implementado e medindo. "Podemos explicar o output" é uma propriedade que se cumpre exatamente quando a medição captura as interações influentes. Faithfulness de SPEX é a medição; sparse recovery é o mecanismo. Uma feature attribution que perde a interação é uma medição da coisa errada, e uma medição da coisa errada é pior que nenhuma medição.

Como isso mapeia para as etiquetas de honestidade da Everythink?

Production ✅ significa que o mecanismo está implementado e medindo — a entropia do Oracle a cada merge, o roteamento da topologia, a auto-desabilitação do World Monitor. Um score de interpretabilidade é uma medição, não uma etiqueta. Roadmap 🔵 significa que o mecanismo ainda não está implementado, e nenhum resultado de interpretabilidade o eleva. As etiquetas são a medição do mecanismo, não uma vibe sobre o modelo.

Fontes

Se sua network está pronta para uma medição que capture a interação, não a feature, crie sua network — a topologia roteia a requisição, as Sisters produzem os drafts, e o Oracle mede a sinergia a cada merge.

Construa seu mundo sobre um motor que prova o que afirma.

Crie sua própria rede no motor que está em produção desde 2016 — ou fale com a equipe por trás dos 21 artigos.