Evals em vez de achismo: por que recursos de IA fracassam sem medição // nh labs

O recurso que funciona na reunião

Existe um momento que todo time reconhece assim que constrói seu primeiro recurso de IA. O protótipo roda, alguém digita uma pergunta, o modelo responde de forma fluente e esperta, e uma sensação morna se espalha pela sala: isto funciona. Três semanas depois entra no ar, e de repente o mesmo chatbot inventa números de pedido que nunca existiram, o sumarizador corta justamente o parágrafo que importava, e o classificador joga uma reclamação a cada duas na gaveta errada.

A pergunta incômoda na reunião de crise que vem a seguir é sempre a mesma: quanto piorou – e desde quando? E ninguém consegue responder. Não há número, não há comparação, não há um antes. Houve apenas uma boa sensação numa demo.

Isso é desenvolvimento orientado a demo, e é a forma mais comum de um projeto de IA fracassar. Não porque o modelo seja fraco demais, mas porque ninguém jamais mediu o que ele de fato faz. Uma demo mostra que um sistema pode funcionar no melhor cenário. Sobre o caso normal, sobre as longas pontas do uso real, sobre regressões, ela não diz absolutamente nada.

O que é, de fato, um eval

A resposta para esse problema é antiga e nada glamourosa: medir. No desenvolvimento de IA a ferramenta se chama eval – abreviação de evaluation, avaliação. E no fundo é surpreendentemente simples:

Um conjunto de entradas representativas. Exemplos reais que o recurso vai enfrentar em produção – os típicos, os complicados, os irritantes. Não os três casos bonitos da demo.
Uma forma de pontuar as saídas. Uma função que, para cada entrada, diz: bom ou ruim, certo ou errado, um número entre 0 e 1.

É isso. Um eval está para um recurso de IA assim como um teste está para código comum: uma afirmação repetível e automatizada sobre se o sistema faz o que deveria. Quem entrega software sem testes é, com razão, considerado imprudente. Quem entrega recursos de IA sem evals faz exatamente a mesma coisa – só que demora mais para alguém perceber, porque o modelo soa confiante mesmo quando está errado.

Como pontuar depende da tarefa:

Tarefas estruturadas podem ser verificadas de forma dura. Se o modelo tem que transformar uma nota fiscal em JSON, classificar um e-mail em uma de cinco categorias ou extrair um valor, existe uma resposta correta. Exact-match, asserções, validação de schema – como um teste unitário clássico.
Tarefas abertas exigem um julgamento mais suave. Para um resumo, uma resposta no chat de suporte, um texto gerado, não há uma única saída correta. Aqui você recorre ou a uma avaliação humana ou a um segundo modelo como juiz – LLM-as-judge – pontuando contra critérios claros.
Golden datasets são a espinha dorsal: um conjunto curado de entradas combinadas com a saída esperada ou ideal, contra o qual você verifica de novo e de novo.

Junte esses exemplos e rode-os automaticamente a cada mudança, e você terá uma suíte de regressão – a única autoridade que vai dizer com honestidade se a sua última "melhoria" foi mesmo uma melhoria.

Por que isso importa mais do que em código comum

Aqui você poderia objetar: testes a gente já conhece, isso não é nada novo. Verdade – e, ainda assim, a situação com IA é fundamentalmente mais perigosa, por dois motivos.

Primeiro: mudanças são não determinísticas. Código clássico faz a mesma coisa toda vez para a mesma entrada. Um modelo de linguagem não. A mesma requisição pode produzir uma boa resposta hoje e uma ruim amanhã. Uma única amostra – "acabei de testar, pareceu bom" – é, portanto, inútil. Você precisa de muitos exemplos e de uma distribuição, não de uma anedota.

Segundo, e esta é a parte realmente perigosa: mudanças são globais. Em código comum, uma mudança é local. Você altera uma função, e só o que chama essa função é afetado. Com IA, toda alavanca relevante é global. Você reescreve uma linha do prompt, troca o modelo por uma versão nova, mexe na temperatura – e isso afeta potencialmente toda saída ao mesmo tempo.

É exatamente aqui que mora a armadilha. Você ajusta o prompt para o modelo responder de forma mais educada, fica satisfeito com os três casos que conferiu – e não percebe que a mesma mudança derrubou silenciosamente em 30% a sua taxa de acerto na extração de dados. Sem um eval, você não vê. Você vê quando os seus clientes veem.

Esse risco fica concreto no momento em que você troca de modelo – o que acontece o tempo todo, porque os provedores descontinuam versões e modelos novos são mais baratos ou mais rápidos. Migrar de um modelo Claude ou GPT para o seguinte não é uma substituição plug-and-play. O modelo novo pode ser melhor na média e, mesmo assim, pior justamente na fatia que importa para o seu produto. Sem um eval, essa troca é um salto de olhos vendados. Com um eval é um número: 87% antes, 91% depois, erros de formato caíram de 4% para 1% – sinal verde.

O que medir, de fato

"Bom ou ruim" é um começo, mas é uma medida grosseira demais. Um eval útil decompõe a qualidade em dimensões que você pode acompanhar separadamente. Quais delas depende do recurso – mas este catálogo cobre a maioria dos casos:

Sucesso na tarefa. A pergunta central: o sistema resolveu a tarefa? Acertou a categoria, retornou o valor correto, deu a resposta utilizável.
Fidelidade / taxa de alucinação. Para tudo que se apoia em fontes – RAG, resumos, perguntas e respostas sobre documentos –, o número mais importante de todos: com que frequência o modelo afirma algo que não está na fonte? Uma invenção fluente e confiante é mais perigosa do que um honesto "não sei".
Aderência ao formato. Quando sistemas seguintes consomem a saída, o formato precisa estar certo. JSON válido, o schema correto, sem texto introdutório antes do código. Um único campo a mais pode quebrar um pipeline inteiro.
Latência e custo. Mesmo quando a qualidade se sustenta: um recurso que leva 30 segundos por resposta ou estoura o orçamento de tokens é inviável em produção. Os dois entram no eval, não na surpresa da fatura no fim do mês.
Taxa de recusa / cautela excessiva. O contraponto silencioso da alucinação: modelos que travam vezes demais com "não posso responder isso" quando poderiam e deveriam. Cautela em excesso é um defeito de produto tanto quanto invenção em excesso.
Buckets de modos de falha. O mais valioso num eval maduro não é a nota geral, é a separação das falhas por tipo. O modelo tropeça em entradas longas? Em um idioma específico? Em tabelas? Só os agrupamentos mostram em que trabalhar a seguir.

Uma única porcentagem é tranquilizadora e enganosa. É a decomposição que transforma um eval de uma nota em uma ferramenta de diagnóstico.

Onde o esforço não compensa

Agora a parte honesta – senão você tira as conclusões erradas e constrói infraestrutura de eval para coisas que não precisam dela.

Evals não são de graça. Um bom conjunto de dados quer ser curado, um juiz LLM quer ser calibrado, a suíte quer ser mantida quando os requisitos mudam. Esse esforço só se justifica quando o recurso vale a pena. Para um protótipo descartável, um script interno que uma pessoa roda duas vezes por mês, ou uma migração de dados única, "testa e olha no olho" é perfeitamente legítimo. Achismo é uma estratégia sensata quando o que está em jogo é pouco. Ninguém escreve testes unitários para um comando bash de uma linha, e ninguém deveria construir um golden dataset para um experimento de fim de semana.

Há um segundo perigo, mais sutil: o efeito Goodhart. "Quando uma medida vira meta, ela deixa de ser uma boa medida." Ajuste o prompt contra os mesmos 50 exemplos por tempo suficiente para empurrar o número até 99%, e talvez você só tenha aprendido a resolver aqueles 50 exemplos – e nada além deles. Um conjunto de eval ultrapassado, contra o qual você treinou por meses, vira sua própria ilusão de qualidade. Por isso o conjunto de dados precisa permanecer vivo: ampliado com regularidade, alimentado com casos de falha novos e reais, conferido de vez em quando contra um conjunto fresco e nunca visto.

A linha não passa entre "evals sempre" e "evals nunca" – ela passa pelo que está em jogo. Rigor proporcional, não cerimônia. Um recurso de IA crítico para o cliente, com receita ou confiança em jogo, merece uma suíte de eval séria. Um utilitário interno merece um olhar cético e pronto. A habilidade está em situar com honestidade em qual categoria você está trabalhando.

Como começar

O motivo mais comum para um time não ter evals não é resistência – é a crença de que isso é um projeto gigante. Não é. Começar é pequeno e concreto:

Comece com 20 a 50 exemplos reais. Não inventados, não idealizados. Pegue entradas reais ou realistas e escreva, para cada uma, como é uma boa resposta. Só esse ato – articular o que você espera – afia o seu entendimento do recurso mais do que qualquer demo.
Pontue-os. Para tarefas estruturadas, uma asserção dura. Para tarefas abertas, no começo até uma avaliação humana numa planilha, depois um juiz LLM com critérios claros. Não precisa ser perfeito, só consistente.
Conecte na CI. O passo decisivo: o eval roda automaticamente a cada mudança de prompt, cada troca de modelo, cada pull request. Igual aos testes unitários. Uma mudança que derruba a taxa de acerto fica visível antes de ir para produção – não depois.
Faça-o crescer a partir das falhas em produção. Toda falha real em produção é um presente: ela vira o próximo caso de eval. O conjunto cresce organicamente justamente na direção em que o sistema é fraco, e todo bug que você corrige uma vez fica corrigido para sempre.

Depois de algumas semanas você terá, quase como efeito colateral, uma suíte de regressão que protege as suas costas. E a sensação na próxima troca de modelo é completamente outra – não "tomara que nada quebre", mas "os números dizem que melhorou".

Conclusão

Trabalho sério com IA é engenharia, não roleta de prompt. A diferença entre um time que opera um recurso de IA de forma confiável em produção e um que cambaleia de reunião de crise em reunião de crise raramente é o modelo. É se alguém está medindo.

Uma demo produz uma sensação. Um eval produz um número – e só números podem ser comparados, acompanhados e melhorados. Sem eles, todo time voa às cegas: não consegue pegar regressões, não consegue trocar de modelo com segurança, não consegue melhorar prompts de forma sistemática e, no fim, nem sequer consegue dizer se o produto está melhor hoje do que estava na semana passada.

O desenvolvimento orientado a avaliação está para os recursos de IA assim como os testes estão para o software: não um luxo, mas a base de que você precisa antes de conseguir construir qualquer coisa séria. Não é preciso começar grande. Mas é preciso começar a medir. Todo o resto é esperança – e esperança não é estratégia para um produto em que as pessoas deveriam confiar.