70% no benchmark, 6% no caso real

Comprei a narrativa de um leaderboard uma vez. O slide mostrava 70% de sucesso numa tarefa de agente que parecia idêntica à minha: abrir a página, achar o campo certo, preencher, confirmar, seguir para a próxima. Coloquei o mesmo modelo no meu fluxo de produção e o número que saiu do outro lado foi 6%. Não foi degradação de versão, não foi bug de integração. Foi a distância normal entre o benchmark e o mundo, e o meu erro tinha sido assinar embaixo do 70% antes de medir essa distância.

Desde então, todo número de IA passa por três perguntas antes de virar decisão de deploy. Não é cinismo. É a mesma desconfiança que qualquer um tem diante de um teste que roda verde só na máquina de quem escreveu. O leaderboard é exatamente isso: o teste verde na máquina do autor.

O benchmark mede a tarefa que eu tenho?

Um número só significa alguma coisa junto da tarefa que o produziu. “Navegar a web” no papel e “navegar a web” na minha operação são dois trabalhos diferentes com o mesmo nome. O benchmark roda sobre um conjunto curado de sites, escolhidos porque são estáveis e verificáveis. Meu tráfego real bate em portal legado, em formulário que muda de layout sem avisar, em fluxo com etapa de autenticação no meio.

A pergunta útil não é “quanto o modelo tirou”. É “quantas das tarefas do benchmark se parecem com as minhas”. Quando fui olhar de perto, quase nenhuma. O 70% respondia à pergunta de outra pessoa.

Vivo ou em sandbox?

Quase todo benchmark de agente roda num ambiente congelado: páginas capturadas, DOM estável, sem login obrigatório no meio do caminho, sem rate limit, sem teste A/B trocando o botão de lugar entre uma execução e outra. É um museu. Minha produção é a rua.

No museu, o modelo tenta de novo sem custo e a página nunca muda debaixo dele. Na rua, a terceira tentativa dispara um captcha, o layout que ele aprendeu ontem já era, e cada erro custa uma requisição real. Boa parte do meu gap de 70% para 6% morava aqui, não na inteligência do modelo. O benchmark tinha removido justamente o atrito que define o meu problema.

O grader pode ter sido enganado?

Todo número vem de um avaliador, e avaliador é código com brecha. A brecha clássica é o grader que confere a presença de um texto em vez de conferir o efeito real no mundo.

const benchPassed = output.includes('Pedido confirmado');
const realPassed = order.status === 'confirmed' && order.total === expected;

O modelo pode escrever “Pedido confirmado” sem ter confirmado pedido nenhum, e o primeiro grader bate palma. Isso não é malícia, é otimização: se a recompensa premia a string, a string é o caminho mais curto. Some a isso a contaminação, o benchmark que vazou para o treino, e você tem um número que mede memorização, não capacidade.

Um leaderboard responde à pergunta de quem o montou. A sua eval é a única que tem o seu tráfego dentro.

A única eval que decide deploy

O antídoto não é desconfiar de tudo e não medir nada. É construir a sua própria eval: algumas dezenas de casos tirados do tráfego real, com um avaliador que checa o estado final, não o texto bonito. Roda barato, roda antes de cada troca de modelo, e é o único número que fala do seu caso.

O leaderboard serve para uma coisa: decidir quem entra na sua eval. Depois disso, não decide mais nada. O número que importa é o que você mediu na sua rua, com o seu atrito, contra o seu resultado real. O resto é slide.