🤖 AI

Stop Comparing LLM Agents Without Disclosing the Harness

Este artigo de posição argumenta que, para tarefas de longo horizonte, o mecanismo de execução do agente é frequentemente um determinante mais forte do desempenho do que o modelo de linguagem subjacente, instando a comunidade a adotar protocolos de avaliação conscientes do mecanismo para evitar a atribuição sistemática de ganhos de infraestrutura a melhorias do modelo.

Autores originais: Yunbei Zhang, Janet Wang, Yingqiang Ge, Weijie Xu, Jihun Hamm, Chandan K. Reddy

Publicado 2026-05-26

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Yunbei Zhang, Janet Wang, Yingqiang Ge, Weijie Xu, Jihun Hamm, Chandan K. Reddy

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Ideia Central: Não é Apenas o Motor, é o Carro

Imagine que você está tentando julgar qual motor de carro é o melhor. Você coloca um motor de Ferrari em um sedan enferrujado e quebrado, com pneus murchos e um volante que não funciona. Em seguida, coloca um motor ligeiramente menos potente em um carro de corrida novo, de alta tecnologia, com pneus perfeitos e um sistema de navegação GPS.

Se o segundo carro ganhar a corrida, será que ele venceu porque o motor era melhor? Não. Ele venceu porque o carro (o chassi, os pneus, a navegação) era melhor.

Este artigo argumenta que estamos atualmente cometendo exatamente esse erro com a IA.

Quando testamos "agentes" de IA (programas de IA que podem realizar tarefas como escrever código ou corrigir bugs de software), geralmente olhamos para uma única pontuação e dizemos: "Uau, o Modelo A é melhor que o Modelo B". Os autores afirmam que isso é enganoso. Eles argumentam que, para tarefas complexas e de longo prazo, a pontuação depende muito mais do "arnês" (a infraestrutura de software que envolve a IA) do que do próprio modelo de IA.

O "Arnês": O Corpo e o Sistema Nervoso da IA

O artigo chama a infraestrutura de "arnês". Pense no modelo de IA (o "cérebro") como um piloto. O arnês é o cockpit, o sistema de piloto automático, o medidor de combustível e o rádio de comunicação.

O Modelo (O Cérebro): É apenas a parte que pensa e gera texto. É "em malha aberta", o que significa que apenas dispara uma resposta e aguarda o próximo prompt. Ele não sabe se cometeu um erro até que alguém lhe diga.
O Arnês (O Controlador): Esta é a camada de software que:
- Decide quais informações mostrar à IA (Contexto).
- Verifica se a resposta da IA faz sentido (Verificação).
- Diz à IA para tentar novamente se ela falhar (Lógica de nova tentativa).
- Impede que a IA fique confusa com excesso de informações (Gerenciamento de memória).

O artigo afirma que, para tarefas longas e difíceis, o arnês é a "restrição vinculante". Isso significa que o arnês é o gargalo. Se o arnês for ruim, mesmo a IA mais inteligente falhará. Se o arnês for excelente, uma IA ligeiramente menos inteligente pode ter sucesso.

A "Tese da Restrição Vinculante"

Os autores propõem uma teoria chamada Tese da Restrição Vinculante. Em português claro, ela diz:

"Quando comparamos modelos de IA de ponta em tarefas difíceis e longas, a diferença em suas pontuações é causada mais pela forma como o arnês é construído do que pelo modelo utilizado."

Eles descobriram que alterar o arnês pode variar uma pontuação em 15 pontos percentuais, enquanto alterar o modelo geralmente move a pontuação apenas em 2 a 4 pontos.

A Analogia: Imagine dois corredores. Um é um velocista olímpico (Modelo A) e o outro é um amador muito em forma (Modelo B).

Se você colocar o velocista olímpico em botas de lama e der a ele uma mochila pesada (Arnês Ruim), ele pode perder para o amador correndo com sapatos perfeitos (Arnês Bom).
O artigo diz que as classificações atuais são como uma corrida onde todos usam sapatos diferentes, mas apenas reportamos quem venceu, ignorando os sapatos.

Por Que as Classificações Atuais são "Incompletas"

Atualmente, os benchmarks (como SWE-bench ou Terminal-Bench) agem como se estivessem testando apenas o "cérebro". Mas, na realidade, eles estão testando o Cérebro + O Arnês.

Como os pesquisadores raramente publicam exatamente como construíram seu arnês (a "receita" do cockpit), não podemos dizer se um modelo é realmente mais inteligente ou se a equipe apenas construiu um arnês melhor ao redor dele.

A Evidência do Artigo:

Exemplos do mundo real: Eles mostraram que o mesmo modelo de IA (Claude Opus) obteve uma pontuação de 45,9% com um arnês e 55,4% com outro. Isso é um salto enorme apenas mudando o envoltório de software, não o modelo.
Experimento Controlado: Eles pegaram três modelos de ponta diferentes e os executaram através de três arneses diferentes (Mínimo, Melhorado e Completo).
- Resultado: Alterar o arnês mudou as pontuações muito mais do que alterar o modelo.
- O Revesamento: Às vezes, um modelo "pior" com um arnês "melhor" derrotou um modelo "melhor" com um arnês "pior". As classificações inverteram!

A Solução: "Divulgação" e "Decomposição de Variância"

O artigo não diz que devemos parar de usar modelos. Diz que precisamos parar de fingir que o arnês não existe. Eles propõem uma nova maneira de avaliar a IA:

O "Cartão de Arnês": Assim como os rótulos de alimentos listam ingredientes, cada submissão de benchmark de IA deve listar seu "Cartão de Arnês". Este cartão detalha exatamente como o contexto é construído, como os erros são tratados e como a IA é verificada.
Decomposição de Variância: Em vez de apenas dar uma pontuação, os pesquisadores devem relatar:
- Quanto da diferença na pontuação é devido ao Modelo?
- Quanto é devido ao Arnês?
- Quanto é devido à Interação entre eles?

A Conclusão

Se você é um pesquisador, investidor ou usuário olhando para as classificações de IA, o artigo o alerta: Não confie nas classificações cegamente.

Até que vejamos o "Cartão de Arnês", uma classificação em um ranking é como julgar uma corrida sem saber quem estava dirigindo qual carro. O "vencedor" pode apenas ter tido um carro melhor, não um piloto melhor. Para entender verdadeiramente o progresso da IA, precisamos parar de comparar apenas os cérebros e começar a comparar o sistema inteiro — o cérebro e o corpo em que ele vive.

Resumo Técnico: Pare de Comparar Agentes LLM sem Divulgar o Orquestrador

1. Declaração do Problema

As práticas atuais de avaliação de agentes de Modelos de Linguagem de Grande Escala (LLM) em tarefas de longo horizonte confundem sistematicamente a capacidade do modelo com o desempenho do orquestrador de execução. O orquestrador de execução é a camada de infraestrutura responsável pela construção de contexto, mediação de interação com ferramentas, verificação de saída, orquestração (lógica de repetição/escalonamento) e critérios de parada.

As tabelas de classificação padrão (por exemplo, SWE-bench, Terminal-Bench, AgentBench) relatam uma única pontuação por par {modelo, benchmark}, atribuindo implicitamente o resultado exclusivamente ao modelo. Este artigo argumenta que, para tarefas de longo horizonte envolvendo modelos de fronteira comparáveis, o orquestrador é frequentemente a restrição vinculante no desempenho. Consequentemente, os protocolos de avaliação atuais atribuem erroneamente ganhos no nível do orquestrador a melhorias no modelo, tornando as comparações entre modelos pouco confiáveis e potencialmente enganosas. A confusão surge porque:

Evidência Observacional: Manter um modelo fixo enquanto se altera apenas a infraestrutura do orquestrador pode produzir deslocamentos de desempenho (por exemplo, 15 pontos percentuais) que superam em muito as melhorias de modelo relatadas (tipicamente 2–4 pontos).
Realidade Estrutural: Os agentes operam como sistemas dinâmicos de malha fechada, onde o orquestrador atua como controlador e o LLM como uma política estocástica. A confiabilidade de longo horizonte depende das propriedades do controlador (estabilidade, gerenciamento de deriva de contexto, atraso de controle) e não apenas da capacidade bruta da política.

2. Metodologia e Estrutura Teórica

A Tese da Restrição Vinculante

O artigo formaliza a Tese da Restrição Vinculante: No regime de tarefas de longo horizonte com modelos de fronteira comparáveis, a variância nas pontuações de benchmark induzida pelo orquestrador ($HV$) é frequentemente comparável ou maior do que a variância induzida pela escolha do modelo ($MV$).

A variância total de desempenho é decomposta como:
$\text{Var}(B(M, H)) = \underbrace{\text{Var}_M[E_H[B(M, H)]]}_{MV} + \underbrace{\text{Var}_H[E_M[B(M, H)]]}_{HV} + \underbrace{\text{Var}(\text{interação})}_{\text{Interação}}$
A tese afirma que $HV$ e o termo de interação dominam $MV$ nas avaliações atuais.

Formalização Teórica de Controle

Os autores reestruturam a execução do agente de um simples loop de inferência para um sistema dinâmico de malha fechada:

O LLM ( $\pi_\theta$ ): Uma política estocástica de malha aberta que recebe uma projeção de contexto $c(s_t)$ , mas não tem acesso direto ao estado completo $s_t$ .
O Orquestrador ( $C_H$ ): O controlador que atualiza o estado, filtra observações e gerencia o loop de feedback.
Quantidades de Confiabilidade: O orquestrador determina três quantidades estruturais críticas:
1. Estabilidade: Se o sistema faz progresso esperado não decrescente em direção ao objetivo (medida semelhante a Lyapunov).
2. Deriva de Contexto ( $\delta_t$ ): A taxa na qual informações relevantes para a tarefa são perdidas da janela de contexto.
3. Atraso de Controle ( $\tau$ ): O atraso entre a detecção de anomalia e a chegada de um sinal corretivo à política.

Abordagem Empírica

O artigo apoia a tese através de duas linhas de evidência:

Dados Observacionais: Análise de tabelas de classificação públicas (SWE-bench Pro, Terminal-Bench, HAL) mostrando que variações de "apenas andaime" (alterar o orquestrador mantendo o modelo fixo) resultam em oscilações de desempenho de dois dígitos e reversões de classificação.
Experimento Fatorial Controlado: Um experimento em grade 3x3 variando três modelos de fronteira (GPT-5.4, Kimi K2.6, GLM-5.1) contra três configurações distintas de orquestrador ( $H_1$ : Mínimo/Aberto, $H_2$ : Melhorado/Básico de malha fechada, $H_3$ : Completo/Avançado de malha fechada) em um subconjunto estratificado do SWE-bench Verified.

3. Principais Resultados

Evidência Observacional

SWE-bench Pro: Sob um andaime padronizado, os principais modelos abrangem 4,9 pontos. No entanto, fixando o modelo (Claude Opus 4.5) e alternando do andaime SEAL para o Claude Code, a pontuação aumenta em 9,5 pontos.
Reversões de Classificação: Adicionar um único subagente de busca (WarpGrep) à infraestrutura idêntica inverteu a classificação entre MiniMax 2.5 e Claude Opus 4.6.
Diferenças entre Andaimes: No SWE-bench Verified Mini, o mesmo modelo (por exemplo, Claude Sonnet 4.5) apresentou uma diferença de 34 pontos entre andaimes diferentes (SWE-Agent vs. HAL Generalist).

Resultados do Experimento Fatorial Controlado

Dominância da Variância: A variância induzida pelo orquestrador ($HV$) foi 7,80 vezes maior do que a variância induzida pelo modelo ($MV$).
- Média $HV$: 18,48 pp²
- Média $MV$: 2,37 pp²
Deslocamentos de Desempenho: Alterar o orquestrador moveu as pontuações em 8,5 a 13,0 pontos percentuais para modelos fixos, enquanto alterar o modelo dentro de um orquestrador fixo moveu as pontuações apenas em 2,5 a 5,0 pontos.
Instabilidade de Classificação: 6 de 9 comparações possíveis de par modelo/par orquestrador resultaram em reversões de classificação.
Análise de Mecanismo:
- Os ganhos de $H_1 \to H_2$ foram impulsionados pela redução do ruído de controle (melhor formatação, recuperação, tratamento de erros).
- Os ganhos de $H_2 \to H_3$ foram impulsionados pelo fechamento do loop de verificação e recuperação (autoverificação, detecção de anomalias, reversão).

4. Estrutura Proposta: Avaliação Consciente do Orquestrador

O artigo propõe um novo regime de avaliação exigindo três componentes:

Cartão de Orquestrador (Divulgação Estruturada): Cada submissão de benchmark deve incluir uma divulgação organizada pela taxonomia ETCSOVG:
- Execução (tempo de execução, sandbox, tempos limite)
- Tool (lista, esquema, contratos de erro)
- Contexto (limite de janela, compressão, recuperação, memória)
- Scheduling (loop, repetição, escalonamento, reversão)
- Observabilidade (registro de logs, rastreamentos)
- Verificação (análise sintática, autoverificação, detecção de anomalias)
- Governança (permissões, efeitos colaterais)
Protocolo de Decomposição de Variância: As avaliações devem empregar:
- Protocolo de Orquestrador Bloqueado: Um único orquestrador especificado aplicado a todos os modelos para classificação limpa.
- Protocolo Fatorial: Variar tanto modelos quanto orquestradores para relatar $HV$, $MV$, termos de interação e contagens de reversão de classificação.
Métricas em Nível de Trajetória: Para atribuir deslocamentos de desempenho a camadas específicas do orquestrador, o artigo propõe:
- Taxa de Recuperação (RR): Probabilidade de retornar a um estado que avança a tarefa após uma anomalia dentro de $k$ passos (mede Estabilidade).
- Retenção de Contexto: Fração de arquivos/restrições relevantes para a tarefa presentes no contexto (mede Deriva).
- Atraso de Controle ( $\tau$ ): Passos entre a detecção de anomalia e a chegada do sinal corretivo.

5. Significado e Alegações

O artigo afirma que as pontuações de benchmark para agentes de longo horizonte não são válidas para comparação entre modelos, a menos que o orquestrador de execução seja divulgado.

Precisão Científica: As tabelas de classificação atuais medem uma mistura de modelo e orquestrador, levando a uma atribuição sistemática errônea de ganhos. Isso distorce os incentivos de pesquisa, direcionando investimentos para a escalabilidade de modelos enquanto subinveste na engenharia de orquestradores, que é a maior fonte de variância.
Impacto Prático: Decisões de implantação baseadas nas classificações atuais são falhas porque não isolam a contribuição do modelo. A "restrição vinculante" é frequentemente a infraestrutura, e não os pesos do modelo.
Chamada à Ação: O campo deve mudar de tratar o orquestrador como uma variável oculta para tratá-lo como uma condição experimental primária. Até que as especificações do orquestrador sejam divulgadas e a decomposição de variância se torne rotineira, as comparações de tabelas de classificação devem ser tratadas como incompletas.

O artigo rejeita explicitamente a noção de que "modelos melhores resolverão isso", observando que, à medida que os modelos melhoram, os orquestradores tornam-se mais complexos (por exemplo, o Claude Code redesenhando componentes em vez de removê-los) para gerenciar a capacidade aumentada. A solução é a divulgação estrutural, não apenas padronização ou escalabilidade.