Como você sabe que seu agente funciona?

Publicado em · 32 min de leitura

Foco manual seletivo

Foco manual seletivo

A habilidade mais disputada da área não é subir LLM em produção, é provar que ele funciona.

Toda conversa sobre agente em produção que eu acompanho, em time, em comunidade, em thread de LinkedIn, chega SEMPRE no mesmo lugar do mesmo jeito. Alguém descreve o sistema: RAG, tool calling, fallback, retry, um diagrama bonito. Aí alguém pergunta como sabem que aquilo funciona, e a resposta é uma variação de “a gente testou bastante e pareceu bom”, às vezes com um benchmark público que não tem nada a ver com o produto.

Esse artigo nasceu do incômodo com essa cena. O mercado gastou tempo anos ensinando todo mundo a subir sistema com LLM. Framework, template, curso de fim de semana. Subir é fácil. Medir continua sendo difícil, e é medir que decide as brigas que importam: trocar ou não de modelo, automatizar ou não o próximo passo, defender ou não o projeto quando o custo dele aparece na planilha de alguém.

Eu queria um texto que desse pra mandar pra alguém que acabou de subir o primeiro agente: por que benchmark público não resolve, em que estágio o time está, e o processo inteiro de montar o primeiro eval harness, com os números e as decisões de cada etapa. Não achei em português, então resolvi escrever.

Todo mundo aprendeu a subir, quase ninguém aprendeu a medir

Tem um número que abre bem essa discussão.

O curso AI Evals for Engineers & PMs, do Hamel Husain e da Shreya Shankar, custa US$ 4.200 e já passou por mais de 4.500 engenheiros e PMs, de times de OpenAI, Google, Meta, Amazon e Microsoft. Lenny Rachitsky, que provavelmente é a pessoa que mais entrevista construtor de produto no mundo hoje, descreve os dois como quem “ensina o curso mais popular do mundo sobre AI evals” e chama isso de a habilidade mais quente pra quem constrói produto de IA. A O’Reilly tem o livro deles, Evals for AI Engineers, marcado pra outubro de 2026.

Quatro mil e quinhentas pessoas pagando quatro mil dólares pra aprender a medir. Hype de feed não move orçamento de times desse tamanho.

Do outro lado, o cargo “AI Engineer” foi o que mais cresceu nos Estados Unidos na lista Jobs on the Rise do LinkedIn em 2025 e de novo em 2026, segundo a Axios e a Forbes. A fila de gente aprendendo a subir agente é gigantesca. A fila de gente aprendendo a medir agente é muito menor.

O argumento econômico, que é o que convence quem ta gastando dinheiro

A parte que interessa pro negócio cabe em duas frases.

O custo de errar cresce junto com o grau de automação. Enquanto tem humano revisando cada saída, o erro do modelo é um incômodo. Quando você tira o humano do meio, o erro do modelo vira o output da empresa.

E o mercado já está pagando essa conta em público.

Em fevereiro de 2024, o Civil Resolution Tribunal da British Columbia condenou a Air Canada porque o chatbot do site inventou uma política de tarifa de luto. A empresa argumentou que não podia ser responsabilizada pelo que o chatbot disse. O tribunal respondeu, no parágrafo 27, que a Air Canada estava sugerindo que “o chatbot é uma entidade legal separada, responsável pelos próprios atos”, e classificou isso como “uma alegação notável”. Foram CAD 812,02 no total. O valor é irrelevante. O precedente não.

A cidade de Nova York manteve no ar por mais de dois anos um chatbot que, conforme o The Markup documentou, dizia a empresários que dava pra recusar inquilino com voucher de habitação e ficar com parte da gorjeta dos funcionários. As duas coisas são ilegais lá. Só foi mandado desligar em fevereiro de 2026, depois de custar uns estimados meio milhão de dólares por ano.

E o caso mais fácil de medir: o pesquisador Damien Charlotin mantém uma base de decisões judiciais em que a corte reconheceu explicitamente que alguém usou conteúdo alucinado. Na consulta de 16 de agosto de 2026, são 1.922 casos, quarenta e um deles no Brasil.

Nenhum desses times era incompetente. Todos subiram alguma coisa que passou no olho de alguém.

A Gartner projeta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo, valor de negócio pouco claro ou controle de risco inadequado. É previsão, não uma medição, e vale ler como tal. Mas os três motivos que eles listam têm a mesma raiz, ninguém conseguiu mostrar, com número, que a coisa funciona bem o suficiente pra justificar o próximo passo.

Eval é o gate de confiança. Sem eval, você não tem argumento pra automatizar mais, e sem automatizar mais o projeto não paga o próprio custo.

Ninguém faz deploy sem teste em software tradicional. Em IA o teste existe também, só que o gabarito é probabilístico e você precisa construir o gabarito antes. É trabalho a mais, e é por isso que quase ninguém faz.

“Mas o Claude Code não usa evals”

Essa objeção merece resposta própria, porque ela dominou uma semana inteira de timeline em setembro de 2025.

O estopim foi real. Boris Cherny, do Claude Code, disse num podcast que decisões centrais do produto foram tomadas no “mostly vibes”, com dogfooding no lugar de benchmark. O swyx empacotou numa lista de produtos famosos “sem evals”, um CEO de startup de agentes escreveu que “evals are a scam”, outro foi menos educado, e por uma semana pareceu que a área de estudo tinha morrido antes de nascer.

Dois detalhes desmontam a objeção.

O primeiro é o contexto, no Claude Code, o desenvolvedor é o domain expert e usa o produto o dia inteiro. Dogfooding nessa configuração é error analysis contínua com o melhor anotador possível. Foi o que a Shreya Shankar respondeu no episódio do Lenny, quem diz que não faz eval quase sempre está fazendo, sem chamar assim.

O segundo é o epílogo. Em julho de 2026, o time do Claude Code declarou publicamente ter “milhares de evals”, e o próprio Cherny descreveu o ciclo: você usa o produto, vê onde ele apanha, e é daí que sai o eval set, que satura, é jogado fora e refeito. Isso é, quase palavra por palavra, o processo que eu descrevo daqui a duas seções.

O que sobrou de bom do debate foi a versão madura da crítica, que pode ser resuminda em “eval mal feita é teatro”. Juiz sem validação, golden set que não vem de produção, score corporativo usado como peça de marketing. O resto deste artigo é sobre como não fazer isso.

Os três estágios

Eu venho usando essa tipologia em conversa faz um tempo e ela se sustentou bem. Todo time que eu conheço está em um dos três. Inclusive o meu, em momentos diferentes.

Estágio 1, vibe check

Você abre o playground, roda cinco, dez e sei lá quantos exemplos que te vieram à cabeça, lê as saídas, acha que ficou bom, e sobe.

Descrito como medição, isso é n=5, amostrado por conveniência, avaliado pela mesma pessoa que tem interesse no resultado. Três vieses num movimento só.

Não tem nada de errado em começar aqui. Todo mundo começa aqui. O problema é ficar.

Os sintomas são fáceis de reconhecer, e são todos comportamentais, não técnicos:

O que impede de subir de estágio quase nunca é conhecimento técnico. É a crença de que eval é uma coisa que se faz depois, quando o produto amadurecer. A Anthropic colocou isso muito bem: “evals ficam mais difíceis de construir quanto mais você espera. No começo, requisitos de produto viram casos de teste naturalmente. Espera demais e você vai estar fazendo engenharia reversa dos critérios de sucesso a partir de um sistema vivo.”

Estágio 2, benchmark genérico

Aqui o time entendeu que precisa de número. Então foi buscar número onde tinha número pronto: MMLU, acurácia em dataset público, posição em leaderboard, score do model card.

Esse estágio parece maduro e é, na prática, mais perigoso que o estágio 1. Porque agora você tem um número, e número dá confiança. Só que o número é sobre outra coisa. Então, em três passos, vamos lá.

Primeiro, o benchmark pode estar dentro do treino. A Scale AI construiu o GSM1k, mil problemas novos espelhando a distribuição do GSM8K, e mediu a queda. Deu até 13 pontos percentuais, concentrada em famílias de modelo otimizadas pra matemática. O Math-Shepherd-Mistral-7B-RL fazia 74,5% no GSM8K e fez 61,1% no GSM1k. E não adianta confiar na descontaminação por n-grama, um trabalho de 2023 mostrou que paráfrase e tradução simples driblam os métodos padrão, e que de 8% a 18% do HumanEval aparece sobreposto em conjuntos de pré-treino públicos.

Segundo, o benchmark pode estar simplesmente errado. O paper “Are We Done with MMLU?” reanotou 5.700 questões do MMLU nos 57 subjects e encontrou 6,49% de questões com erro no dataset todo. No subset de Virologia, 57% das questões analisadas tinham problema, entre gabarito errado e questão ambígua. Corrigir isso mudou ranking de modelo, em Virologia, o Llama 3.1 405B era décimo sexto colocado considerando todas as instâncias, e virou primeiro considerando só as instâncias corretas.

Terceiro, o leaderboard tem gente jogando o jogo. O “The Leaderboard Illusion” documentou que aumentar a proporção de dados da arena no treino de 0% para 70% mais que dobra o win rate no ArenaHard, de 23,5% pra 49,9%. E que a Meta testou 27 variantes privadas na largada do Llama 4, podendo escolher qual score publicar. Antes disso, a própria LMSYS mostrou que boa parte da preferência humana na arena é explicada por comprimento e formatação markdown, controlando por estilo, um modelo caiu do 6º pro 18º lugar. A comunidade já tem até verbo pra essa prática, benchmaxxing, otimizar pro que o leaderboard mede em vez da capacidade que ele deveria medir.

Se você quiser um único número pra guardar dessa seção, use esse. A Epoch AI rodou o GPQA Diamond dezesseis vezes de forma independente num modelo cujo score reportado era 65%, e obteve média de 55%, com desvio de 3 pontos. Dez pontos de diferença, e sem causa identificável, porque quem publica score raramente reporta prompt e temperatura. Benchmark que não é reprodutível entre avaliadores não serve como critério de aceite de produto.

A crítica mais estrutural veio em 2025, quando um time do Oxford Internet Institute revisou 445 benchmarks de LLM publicados nas principais conferências. Apenas 16% usaram algum teste estatístico pra comparar modelos e menos de 10% usaram tarefas completas do mundo real. O título do paper é Measuring what Matters, e o argumento é exatamente esse.

Junte os três e sobra só uma conclusão, benchmark genérico prediz mal o desempenho na sua tarefa, e nenhum deles foi construído pra prever.

Sintoma clínico do estágio 2: o time discute qual modelo usar lendo model card, e não rodando os dois no próprio caso de uso.

Estágio 3, eval de produto

Aqui o gabarito é seu, e esse meio que é o problema?

O time olhou tráfego real, catalogou os modos de falha que acontecem de fato no produto, montou um conjunto de casos com veredito humano, construiu um juiz automático que foi calibrado contra esse veredito, e amarrou tudo num gate que roda a cada mudança.

O que muda no dia a dia é uma coisa só, e é enorme: o time volta a ter velocidade. Dá pra trocar prompt, trocar modelo, mudar chunking, mexer no retriever, porque existe um número que diz se piorou. O medo de mexer some.

O que impede de chegar aqui também não é ferramenta ou gap tecnico, e é isso que a próxima seção trata. É o trabalho manual chato que ninguém quer fazer, e que quase todo mundo pula.

O cookbook

Antes dos passos, as duas observações que explicam o formato deles. A receita só faz sentido se você aceitar as duas premissas.

Primeira: sistema com LLM falha em silêncio. Código tradicional quebra com stack trace. LLM não quebra. Ele responde, fluente, bem formatado, com exatamente a mesma confiança no acerto e no erro. Nenhuma exceção vai tocar alarme por você, e é por isso que a receita começa com leitura de dados e não com infraestrutura.

Segunda: qualidade não é propriedade do modelo. Ela nasce do encontro entre o modelo, o seu prompt, os seus dados e o seu tráfego. Muda quando qualquer um dos quatro muda. É por isso que ela não se terceiriza pra benchmark, e é por isso que todos os passos abaixo trabalham com o seu material.

Aceitou as duas, o resto é começar a execução. Sete passos. Não precisa de plataforma, não precisa de aprovação de compra, não precisa de time. Precisa de acesso aos traces e de disposição pra ler texto ruim por dois dias. Os seis primeiros passos cabem numa semana de uma pessoa. O sétimo roda pra sempre, e é ele que impede os outros seis de apodrecerem.

E não precisa tentar ser um herói, rode a receita padrão uma vez, do jeito que está, antes de adaptar pro seu caso. Adaptação prematura é como otimização prematura, só que mais difícil de reverter, porque você nunca vai saber como seria o resultado do processo que não rodou.

1. Colete traces reais

Junte de algo entre 50 a 100 traces de produção incialmente. Trace inteiro: input do usuário, o que o sistema recuperou, quais tools chamou, o que devolveu. Se você não tem tráfego ainda, gere dado sintético, e eu volto nisso no passo 4.

2. Leia tudo, um por um

Essa parte é ruim mesmo, desculpe. Leia todos, um por um, e escreva em linguagem livre o que está errado em cada um. Sem categoria pré-definida, sem rubrica, sem nota. Só um campo de texto do lado de cada trace, onde você escreve “respondeu certo mas ignorou que o usuário já tinha dito que era vegetariano” ou “chamou a tool duas vezes com o mesmo argumento”.

Toda vez que eu faço isso eu encontro alguma coisa que não estava procurando. Tool chamada duas vezes em loop, contexto truncado no meio de uma frase, router mandando pro agente errado, usuário repetindo a mesma pergunta com irritação crescente em três turnos. Nada disso aparece em dashboard, porque dashboard mostra o que você já sabia que devia olhar.

Isso tem nome, vem de pesquisa qualitativa e se chama open coding. O Hamel Husain e a Shreya Shankar adaptaram pra traces de LLM e é o coração do método deles. Três regras do FAQ deles:

  1. Anote só a primeira falha de cada trace no começo, porque erro lá em cima causa erro lá embaixo e você conta a mesma coisa diversas vezes.
  2. Quem anota tem que entender do domínio. Eles chamam essa pessoa de benevolent dictator, um psicólogo pro chatbot de saúde mental, um advogado pra análise de documento jurídico, o diretor de atendimento pra automação de suporte. Uma pessoa, não cinco. E sobre delegar, são bem diretos, “leia os traces brutos você mesmo no começo. É assim que você descobre novos tipos de falha. Nunca pule isso nem delegue.”
  3. Pare quando novos traces pararem de revelar categoria nova, o que também tem nome emprestado da pesquisa qualitativa, saturação teórica. A heurística deles, se uns 20 traces seguidos não trouxerem categoria nova, pode parar, mas revise pelo menos 100 na primeira rodada.

Se isso parece muito trabalho pra um resultado incerto, o número que eles dão é, “gastamos 60 a 80% do tempo de desenvolvimento em error analysis e avaliação”. Essa não é a etapa preparatória. É o trabalho.

3. Agrupe e conte

Agora pegue todas as anotações livres e agrupe em categorias. Isso é axial coding, e é a etapa que o Hamel fala que é a mais importante do processo todo.

Aqui um LLM ajuda de verdade, joga as suas cem anotações e pede pra propor um agrupamento. Você corrige, funde categorias que são a mesma coisa com nome diferente, separa as que viraram balaio. O critério é conseguir contar sem hesitar.

E aí conta a frequência por categoria.

Essa contagem é o produto do dia, e pode ser desconfortável, porque a distribuição quase nunca é a que o time imaginava. O exemplo público que o Hamel usa é de um produto onde três problemas respondiam por mais de 60% das falhas, e o pior deles era interpretação de data relativa, quando o usuário dizia “daqui a duas semanas”, o sistema errava 66% das vezes. Depois de atacado, a taxa de acerto foi de 33% para 95%. Ninguém tinha adivinhado que era esse o problema principal.

Priorize por dor vezes frequência. O topo da lista costuma ser óbvio quando a contagem está na sua frente.

4. Golden dataset v0

Agora você monta o conjunto de casos com veredito humano.

Tamanho, comece pequeno. A recomendação da Anthropic é bem específica e derruba a desculpa mais comum, “times adiam construir evals porque acham que precisam de centenas de tarefas. Na prática, 20 a 50 tarefas simples tiradas de falhas reais já é um ótimo começo.”

Regras que eu seguiria no começo:

  1. Caso real ganha de caso sintético. Você acabou de passar dois dias lendo produção. Os melhores casos já estão anotados.
  2. Inclua os difíceis e os ambíguos. Um golden set só com caso fácil te dá 98% de aprovação e zero informação. O Hamel tem uma frase boa sobre isso, “se você está passando em 100% das suas evals, provavelmente não está desafiando o sistema o suficiente. Uma taxa de 70% pode indicar uma avaliação mais significativa.”
  3. Se você não tem tráfego, gere sintético com estrutura. Pedir “me dê queries de teste” pro modelo produz lixo genérico e repetitivo. O que funciona é definir dimensões e escrever tuplas. Num app de receita, as dimensões seriam restrição alimentar como vegano, sem glúten, nenhuma, tipo de cozinha italiana, asiática, comfort food e complexidade simples, multi-etapa. Escreva 20 tuplas na mão primeiro, porque isso te obriga a entender o espaço do problema. Depois escale, e converta tupla em linguagem natural num prompt separado, senão todas as queries saem com a mesma cara.
  4. Espere que os critérios mudem enquanto você rotula. A Shreya Shankar deu nome a isso num paper de 2024, criteria drift. Você precisa de critério pra julgar saída, mas é julgando saída que você descobre o critério. Não trate a rubrica v0 como contrato, trate como rascunho.
  5. Se mais de uma pessoa rotula, meça a concordância antes de cobrar a máquina. E calibre a expectativa: num estudo de detecção de discurso de ódio de dezembro de 2025, anotadores humanos treinados ficaram com kappa de Cohen entre 0,47 e 0,48 em dois dos três datasets. Isso é “moderado”. Se os seus humanos concordam em 0,47, exigir 0,8 do seu juiz automático é incoerente.

Uma ressalva sobre o kappa, já que estamos aqui. Com classes desbalanceadas, que é exatamente o caso de eval, porque a maioria das saídas passa, ele pode dar baixo mesmo com concordância observada altíssima. Se a sua distribuição é muito assimétrica, vale olhar o AC1 do Gwet, e reporte o intervalo de confiança, não só o ponto.

5. Juiz binário, calibrado antes de usado

Agora automatizando. Duas decisões definem se isso vai funcionar.

Decisão 1: o juiz julga binário, um critério por vez.

Não peça nota de 1 a 10. A justificativa do Hamel é a melhor que eu conheço: “a diferença entre pontos adjacentes, tipo 3 e 4, é subjetiva e inconsistente entre anotadores, detectar diferença estatística exige amostra maior, e anotador tende a se refugiar no valor do meio pra não tomar decisão difícil”. Binário força a decisão em vez de esconder a incerteza no meio da escala.

Um critério por chamada. “A resposta está factualmente consistente com o contexto recuperado?” é uma eval. “A resposta respeitou a restrição alimentar declarada?” é outra. Não junte, porque quando o número cair você vai querer saber o que caiu.

Pra tirar a abstração, esse é o esqueleto de um juiz binário, no exemplo do app de receitas:

Você avalia um assistente de receitas.

Critério (um só): a resposta respeita as restrições alimentares
que o usuário declarou em qualquer ponto da conversa?

<conversa>
{{conversa}}
</conversa>

<resposta>
{{resposta}}
</resposta>

Passos:
1. Liste as restrições declaradas pelo usuário.
2. Liste cada ingrediente ou instrução da resposta que conflita
   com alguma delas. Substituições válidas não são conflito.
3. Qualquer conflito = FAIL. Nenhum = PASS. Na dúvida, FAIL.

Responda em JSON: {"analise": "...", "veredito": "PASS" | "FAIL"}

Três escolhas deliberadas aí. A análise vem antes do veredito, porque forçar o modelo a listar as evidências primeiro melhora a decisão e te dá material de debug quando ele errar. “Na dúvida, FAIL” resolve o empate por você, em vez de deixar o modelo resolver de um jeito diferente a cada chamada. E o critério cabe numa frase, que é o teste de que ele é um critério e não três. Quando o juiz errar em casos do seu golden set, esses casos viram exemplos few-shot dentro do próprio prompt.

Com uma ressalva, isso não é lei universal. Em tarefas com estrutura ordinal de verdade, como relevância de documento em recuperação de informação, tem trabalho de 2025 sugerindo que escalas maiores ajudam. A defesa forte do binário é sobre rotulagem humana e análise de erro, que é onde você está agora.

Decisão 2: meça o alinhamento do juiz com o humano ANTES de usar o juiz.

Separe uma parte dos seus casos rotulados como holdout, rode o juiz e olhe taxa de verdadeiro positivo e taxa de verdadeiro negativo separadamente. Não olhe só concordância bruta, porque com classe desbalanceada concordância bruta é enganosa.

Se o alinhamento for ruim, troque de modelo, reescreva o critério, ou aceite que aquele critério não é automatizável ainda.

E tem um detalhe que eu só vi sendo tratado direito recentemente, num paper de novembro de 2025 sobre como reportar avaliação com juiz LLM. Se você conhece a sensibilidade e a especificidade do seu juiz, o score bruto dele é um estimador enviesado, e dá pra corrigir com uma fórmula fechada. A medição e a correção, juntas, são dez linhas:

import numpy as np

humano = np.array([1, 1, 0, 1, 0, ...])  # 1 = pass, 0 = fail
juiz   = np.array([1, 1, 0, 0, 0, ...])

tpr = (juiz[humano == 1] == 1).mean()  # concorda nos que passam
tnr = (juiz[humano == 0] == 0).mean()  # concorda nos que falham

# taxa real de aprovação, corrigida (Lee et al., 2025)
p_bruto = juiz_em_producao.mean()
p_real = (p_bruto + tnr - 1) / (tpr + tnr - 1)

O que me pegou nesse paper foi a direção do viés, ela inverte. Sistema ruim parece melhor do que é, sistema bom parece pior do que é. Ou seja, quando o seu produto começa a ficar bom de verdade, o juiz não calibrado passa a te subestimar, e o time interpreta isso como retorno decrescente do trabalho. É diagnóstico errado causado pelo instrumento de medição e não das medidas.

6. Baseline e gate

Rode o sistema atual, sem mudar nada, contra o golden set inteiro. O número que sair é o seu ponto de partida. Ele provavelmente vai ser pior do que a intuição do time. Isso é o valor da coisa.

Depois amarre no CI, versão nova só sobe se não regredir no golden set. A separação que a Anthropic usa é útil aqui. Eval de capacidade responde “o agente consegue fazer isso?” e deve começar com taxa de aprovação baixa. Eval de regressão responde “o agente ainda faz o que já fazia?” e deve ficar perto de 100%. Quando uma eval de capacidade satura, ela se aposenta e vira eval de regressão.

Prefira checagem determinística a juiz LLM no CI sempre que der, porque CI roda o tempo todo e juiz custa. E como LLM não é determinístico, trate isso na configuração em vez de brigar, a GitHub Action do promptfoo tem repeat e repeat-min-pass, que roda cada teste três vezes e exige que passe em pelo menos duas. Falha consistente quebra o build, variância do juiz não.

Vale ainda uma conta de guardanapo da Anthropic sobre consistência, se o agente acerta 75% das vezes e você roda a mesma tarefa três vezes, a chance de passar nas três é 0,7⁵³, ou seja 42%. Média engana feio quando o usuário espera comportamento confiável toda vez.

7. Feche o loop

Cem traces frescos por ciclo de revisão, ciclo de duas a quatro semanas. Falha nova em produção vira caso novo no dataset. Sem isso o golden set envelhece e para de refletir o produto, e o seu gate passa a proteger uma versão do mundo que não existe mais.

Alguns pontos de cuidado

Chegar no estágio 3 não termina o problema. Só troca o problema por um mais interessante.

Armadilha 1, juiz superconfiante

O juiz LLM concorda demais e tem certeza demais.

O paper Overconfidence in LLM-as-a-Judge, de agosto de 2025, testou 14 juízes num benchmark de pares de respostas em que uma está sutilmente errada. O erro de calibração esperado do melhor modelo ficou em 11,78%. O do pior, em 74,22%. E vários modelos concentram as previsões na faixa de 90 a 100% de confiança, com acurácia bem abaixo da linha ideal.

Tem coisa pior, e é a mais útil de saber. Um trabalho da Kensho e do MIT, No Free Labels, mostrou que o juiz não sabe avaliar o que ele não sabe resolver. Nas questões que o próprio GPT-4o não consegue responder, o kappa dele com o rótulo humano desaba de 0,86 pra 0,16, ou seja, praticamente acaso. E juiz pequeno com referência bate juiz muito maior sem referência nenhuma, sendo que o que importa na referência é ela estar correta, não ter sido escrita por humano.

E tem a sicofância (essa eu tirei do dicionário), que é a mais desconfortável. Um estudo de setembro de 2025 mediu quanto o juiz muda de opinião quando o usuário discorda. Contra-argumento formal e fundamentado convenceu em 56% dos casos. Contra-argumento casual, assertivo e sem justificativa nenhuma convenceu em 84,5%.

Junte isso com os vieses clássicos documentados desde o MT-Bench, posição, verbosidade, preferência pelo próprio output. E repara num detalhe de leitura, porque o número mais citado da área nasce ali, aquela concordância de 85% entre GPT-4 e humanos exclui empates e votos inconsistentes. Incluindo tudo, cai pra 66%. Quem cita “85%” está citando o melhor caso.

Como resolve? Rótulo humano é a âncora, sempre. O juiz é uma aproximação barata de um rótulo caro, e aproximação precisa ser medida contra o que ela aproxima. Se o juiz mudou de prompt ou de modelo, ele é um instrumento novo e precisa ser recalibrado.

Armadilha 2, overfit no golden set

Você tem um número. O número vira meta. A meta vira otimização. E aí o time mexe no prompt até o número subir, sem que nada tenha melhorado pro usuário. O pior é que a falha é silenciosa de novo, o dashboard fica verde, a demo continua boa, e a única evidência de que algo quebrou é que a melhora não aparece em nenhuma métrica que o time não controla.

É Goodhart puro, e não é hipótese. É o que aconteceu com os benchmarks públicos da seção de estágios, e não tem nada de estrutural que impeça de acontecer com o seu benchmark privado.

Aliás, tem um achado que fecha essa porta de saída. Um estudo de 2026 sobre saturação de benchmarks analisou 60 benchmarks e encontrou 48,3% com saturação alta. E comparou públicos contra privados, manter o test set privado não protegeu contra saturação. O que protegeu foi curadoria por especialista.

Se resolve com, holdout que você não olha no dia a dia, refresh mensal com casos novos de produção, e desconfiar de melhora grande sem hipótese. Se o número subiu oito pontos e ninguém sabe explicar por quê, provavelmente o dataset vazou pro prompt.

Armadilha 3, métrica proxy

Essa é a mais silenciosa das três.

Eval mede o que é fácil de medir. Formato correto, ausência de alucinação, aderência ao contexto recuperado. Tudo isso é medível e nada disso é o objetivo do negócio na imensa maioria dos casos.

Dá pra ter um sistema com 95% no golden set que está destruindo valor, porque a coisa que ele faz bem não é a coisa que precisava ser feita. E o eval não vai te avisar, porque o eval está medindo exatamente o que você mandou ele medir.

Não vou desenvolver agora, mas talvez isso vire outro artigo.

Ferramenta é o menor dos seus problemas

Seção curta de propósito.

O mapa mudou bastante em 2026, então vale dar uma atualizada, a Langfuse foi adquirida pela ClickHouse em janeiro e o promptfoo pela OpenAI em março, os dois seguindo abertos. Fora esses, aparecem sempre Braintrust e LangSmith no comercial, Arize Phoenix em source-available, DeepEval e Inspect AI, do UK AI Security Institute com a Meridian Labs, no aberto. O openai/evals hoje aponta pra Evals API no dashboard da própria OpenAI.

Escolha uma e siga a vida. O Hamel, que consultou dezenas de times nisso, escreveu que não tem vendor favorito e que o critério que mais pesa na escolha é quem dá o melhor suporte, não quem tem mais feature.

A recomendação dele que eu acho mais subestimada é construir a sua própria interface de anotação. Leva algumas horas hoje, e ele afirma que times com ferramenta customizada iteram cerca de 10 vezes mais rápido. O que faz sentido, anotação é onde o tempo humano é gasto, e interface genérica não conhece o formato do seu trace.

O harness é 80% processo. A ferramenta é a parte que você troca sem dor.

Recomendações da minha cabeça

Bom, aqui vai resumos atômicos dos meus estudos e conclusões sobre o tema:

  1. Comece pela error analysis, não pela infraestrutura. Trinta minutos lendo 20 saídas depois de cada mudança relevante já muda o jogo.
  2. Uma pessoa decide o que é qualidade, e ela entende do domínio. Comitê de qualidade não converge.
  3. Binário por critério, um critério por chamada, e critério que você consegue explicar em uma frase.
  4. Meça o juiz antes de acreditar no juiz. Taxa de verdadeiro positivo e verdadeiro negativo em holdout rotulado.
  5. Vinte a cinquenta casos reais valem mais que quinhentos sintéticos. Aumente depois.
  6. Gate de regressão simples no CI vale mais que dashboard bonito que ninguém abre.
  7. Nunca reporte score de eval sem alguém ter lido transcript. A Anthropic tem uma regra explícita sobre isso, eles não aceitam score de eval pelo valor de face até alguém entrar no detalhe e ler algumas transcrições.
  8. Se a sua taxa de aprovação é 100%, o problema é a sua eval.

O mecanismo do erro

Eu acho que eu disse na abertura que dei a resposta ruim por tempo demais, caso tenha esquecido, eu também já dei respostas ruins sobre “O quanto funciona isso ai?”. Vale explicar o mecanismo, porque o meu erro tem estrutura, e aposto que é a mesma estrutura do seu.

Eu venho principalmente de experimentações. E experimentação tem uma propriedade que eu levei anos pra perceber que era um luxo, a randomização te dá o gabarito de graça. O grupo de controle é o contrafactual, a métrica de negócio existe antes do experimento começar, e a única pergunta é se a variante mexeu no número. Você nunca precisa definir o que é uma resposta boa. O desenho do experimento define por você.

Eval inverte o problema. Não tem controle, não tem contrafactual, não tem métrica pronta. O gabarito não existe em lugar nenhum esperando ser descoberto, você constrói, caso a caso, com alguém que entende do domínio. E construir gabarito é menos estatística e mais engenharia de instrumento de medida. O meu repertório inteiro me ensinou a analisar medidas, nunca a fabricar o medidor.

Então, quando eu subi meu primeiro sistema com LLM decidindo coisa, eu apliquei o instinto errado com toda a confiança de quem tem instinto treinado. Li as saídas, achei boas, e tratei isso como evidência. Mas “eu leio e acho bom” não é amostra, é prior. Sem rótulo, sem denominador, sem taxa de erro. O sistema rodou bem por umas semanas, apareceu um caso fora da distribuição que eu tinha imaginado, o modelo respondeu com a confiança de sempre, e eu soube por reclamação, não por métrica. O que me incomodou não foi o erro. Foi constatar que eu não tinha nenhum instrumento capaz de detectar aquilo, em nenhum momento, nem por sorte. Erro a gente corrige. Cegueira instrumentada a gente nem vê.

O que mudou depois não foi ferramenta e não foi modelo. Foi aceitar que a primeira entrega de qualquer sistema desses é o medidor, e que o medidor se constrói lendo dado ruim com um bloco de notas do lado.

E como soa a resposta certa pra pergunta do título? Ela não impressiona ninguém. É chata, e é mais ou menos assim:

“Eu olhei uns cem casos reais de produção e catalogei os modos de falha. Três categorias respondem pela maioria. Tenho quarenta casos com veredito humano, sendo que uns dez são casos de limite que eu escolhi de propósito. O juiz automático concorda com o meu rótulo com taxa de verdadeiro positivo e verdadeiro negativo que eu meço num holdout, e eu recalibro quando troco o modelo do juiz. O baseline atual está em tal número. Rodou no CI, se cair, não sobe. E eu sei quais falhas eu ainda não sei medir.”

Repare no último pedaço, porque é ele que separa. Saber o número é o esperado. Saber onde o número não alcança é o que denuncia quem já mediu de verdade.

E chegar nessa resposta não exige nada que este texto já não tenha te dado. Cem traces, um bloco de notas do lado, uma segunda-feira. É menos glamouroso que trocar de modelo, e vale dez vezes mais.

E fica a pergunta do título, agora apontada pro seu time, em que estágio vocês estão, sinceramente? Não o que está no roadmap. O que rodou semana passada.

Sistema de IA bom é o que você consegue provar que acerta, na semana em que alguém pergunta.

Referências

#avaliacao#agentes#ia-aplicada