Estudo: overfitting e compute extra consomem 68% do ganho da evolução de harness

Quando uma equipe evolui automaticamente o harness em torno de um LLM congelado, as métricas sobem sem que nenhum peso seja atualizado. Um novo trabalho publicado no Hugging Face Daily Papers verifica quanto desse avanço é real. Os autores introduziram o protocolo Harness-Delta Attribution (HDA) e o aplicaram a 11 modelos executores e a três frameworks de evolução de harness. O resultado é incômodo: em 21 configurações com ganho estatisticamente significativo no conjunto de busca, em média 54% do avanço se explica por overfitting a artefatos do benchmark, e outros 14% vêm do orçamento computacional adicional na inferência.

O que o HDA decompõe

Harness é tudo o que cerca o modelo: prompts de sistema, descrições de skills, o conjunto de ferramentas e o código de orquestração. Os frameworks evolutivos reescrevem esses componentes de forma iterativa e selecionam as versões que se saem melhor no search set. Os pesos do modelo ficam fixos, e por isso a abordagem parece uma alternativa barata ao fine-tuning.

O problema é que o número final, "era 40, virou 52", mistura vários efeitos. O HDA divide o ganho em três partes:

• overfitting, ou seja, o ganho obtido com artefatos do conjunto de busca específico;
• efeito de test-time scaling, quando o harness evoluído simplesmente gasta mais tokens, tentativas ou etapas;
• resíduo, que os autores interpretam como o limite superior da melhoria generalizável.

O resíduo não prova que a melhoria se transfere. Ele é o máximo que poderia restar depois de subtrair os dois primeiros componentes.

Os números das 21 configurações

Os experimentos abrangem tarefas de matemática, programação, criatividade e agentes. Foram selecionados apenas os casos em que o ganho no conjunto de busca é estatisticamente significativo. Ao todo, foram 21.

• Média desses casos: o overfitting explica 54% do ganho, e o test-time scaling, 14%.
• Em 14 das 21 configurações, a parcela conjunta dos dois fatores supera 50%.
• Somando as médias, o resíduo responde por cerca de um terço do ganho inicial. Trata-se de uma média, não de uma garantia para uma configuração específica.
• O tamanho do resíduo e a transferência para tarefas reservadas dependem muito do tipo de tarefa, do modelo e do framework.

Outra conclusão diz respeito à validação. Sinais baseados em um conjunto de validação não impedem o overfitting. Uma equipe que interrompe a evolução no melhor score de validação ainda pode acabar com um harness ajustado ao próprio benchmark. Além disso, os ganhos no search set muitas vezes não se transferem para tarefas reservadas. Há poucos dados de que eles sobrevivam a uma mudança de distribuição na prática.

Como avaliar a evolução de harness na prática

Para equipes que constroem agentes, a conclusão é pé no chão. Um relatório dizendo "o harness trouxe +12 pontos", sem detalhamento, diz pouco por si só. É preciso verificar no mínimo três coisas. Primeira: como o resultado se comporta em tarefas realmente reservadas, que não participaram nem da busca nem da escolha do checkpoint. Segunda: quanto compute o novo harness passou a gastar por tarefa e o que a versão base mostraria com o mesmo orçamento. Terceira: quão estável é o resultado quando a distribuição das tarefas muda um pouco, por exemplo em formulações, domínios ou ferramentas.

Para quem pesquisa frameworks de evolução, o trabalho eleva a régua: comparar uma única métrica no search set já não parece suficiente. A atribuição do ganho passa a fazer parte da metodologia, como as ablações no machine learning tradicional.

Há limitações. O resíduo no HDA é um limite superior, não uma capacidade de generalização medida, e as conclusões se baseiam em 21 configurações. Ainda assim, a direção é clara. Enquanto a avaliação não separar a melhoria real do agente do ajuste ao benchmark e do compute adicional, as afirmações de que o harness pode ser melhorado automaticamente sem atualizar pesos merecem um desconto de cerca de dois terços do ganho.