Antes de medir seu produto de IA, é preciso descobrir onde ele falha

Todo time que está construindo produto com IA generativa↳IA generativa81 conteúdosIA Generativa: 5 alternativas para começar a usar em 2025AI · jan 2025Gartner Revela o Futuro da IA GenerativaAI · jul 2024IA Generativa: Pesquisa global aponta Brasil como segundo país mais otimista com a tecnologiaAI · mar 2024Ver tudo em AI → chega, cedo ou tarde, na pergunta: como sabemos se isso está funcionando? A resposta padrão da indústria tem sido "evals": testes automatizados↳Testes automatizados4 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019TDD em Nodejs: conhecendo o JestDev (Back & Front) · mar 2019Arquitetura Hexagonal na prática com exemplos em PythonDev (Back & Front) · mai 2025Ver tudo em Dev (Back & Front) → que checam se as respostas do seu sistema de IA continuam boas depois de uma mudança de prompt, modelo ou código. Mike Krieger, ex-CPO da Anthropic e hoje à frente do Labs da empresa, chegou a dizer que "se tem uma coisa que dá pra ensinar pra gente de produto, é que escrever evals é provavelmente a coisa mais importante agora". Garry Tan, CEO da Y Combinator, foi na mesma linha: evals estão virando o verdadeiro fosso competitivo das startups de IA.

O problema, segundo Hamel Husain e Shreya Shankar em texto publicado na newsletter de Lenny Rachitsky, não é a ideia de medir. É a ordem em que os times fazem isso. Depois de trabalhar com mais de 50 empresas de IA, os dois notaram um padrão: quase todo mundo pula direto para escrever métricas e ignora a etapa anterior, que eles chamam de error discovery (descoberta de erros). O nome é novo, mas o conceito é uma evolução do que o próprio texto anterior de Husain e Shankar chamava de "error analysis". A mudança de nome não é cosmética: o objetivo declarado agora é identificar quais falhas valem a pena medir, não catalogar todas as falhas possíveis.

Por que isso é discovery de produto, não engenharia

A analogia que os autores usam é direta: assim como discovery de produto (aquela etapa de pesquisa que mostra quais problemas valem a pena resolver, antes de qualquer linha de roadmap) revela o que construir, error discovery revela o que medir. Sem essa etapa, o time constrói dashboards em torno de métricas genéricas que empurram o produto na direção errada.

O risco de pular essa fase é escrever métricas cedo demais, baseadas em suposições sobre o que importa. E aqui entra um fenômeno que os autores batizam de criteria drift: seus critérios do que é "uma boa resposta" mudam à medida que você revisa exemplos reais. Você só descobre certos padrões de falha depois de olhar os dados, não antes. Isso explica por que jogar um monte de traces (os registros completos de uma sessão de usuário com o produto de IA) na mão de um agente de codificação e pedir "encontre os problemas" não é suficiente: o agente é rápido para achar erros óbvios, mas não sabe, de antemão, qual é a sua definição de produto bom.

O caso que ilustra tudo: um "sucesso" que era falha de produto

O exemplo mais didático do texto vem do trabalho com a Nurture Boss, uma assistente de IA para leasing que ajuda gestores de imóveis a conversar com candidatos a inquilinos. Numa interação real, o candidato escreve: "Isso está fora do meu orçamento. Obrigado pela atenção." A assistente responde: "De nada! Se sua situação mudar ou tiver outras dúvidas, é só chamar. Tenha um ótimo dia!"

Para a maioria dos agentes de IA avaliando essa conversa, isso parece um sucesso: a resposta é educada, resolveu a interação, ninguém reclamou. Mas o objetivo do produto é fechar vendas, o que inclui apresentar alternativas quando o candidato bate de frente com uma restrição de orçamento. A assistente deveria ter sugerido unidades mais baratas ou outros imóveis da mesma administradora. Só depois de revisar esse trace manualmente é que Husain e Shankar chegaram ao critério "tratamento de objeção" (objection handling) como algo a ser medido. Se tivessem pedido para o agente checar objection handling desde o início, ele teria pego o erro sozinho. O problema é que ninguém sabia, a priori, que esse era um critério a se checar.

Num estudo mais amplo com 100 traces de produção da mesma assistente, os autores compararam ferramentas automatizadas de eval e agentes de codificação contra revisão humana. Os agentes erraram justamente nos casos que exigem julgamento de produto e contexto fora do trace, como formatação de Markdown quebrada em mensagens de texto e handoffs perdidos para humanos (além do próprio objection handling). Em compensação, os agentes foram bons em pegar falhas óbvias dentro do trace, como respostas que contradizem a saída de uma tool. E, curiosamente, também encontraram problemas que humanos passaram batido, ao custo de gerar ruído, marcando respostas boas como falhas.

O processo em três passos (com agente de codificação)

A solução proposta combina automação com revisão humana usando um princípio de active learning: escolher os exemplos mais informativos para revisar, dado tempo limitado. Na prática, o fluxo descrito no texto tem três etapas:

1. Reunir traces. Cada trace precisa conter input do usuário, prompt de sistema, chamadas de tool e o output final, o suficiente para alguém reconstruir o que aconteceu. Se o produto ainda não tem instrumentação, dá para pedir a um agente de codificação para logar isso em JSONL. Sem usuários reais ainda, dá para simular queries sintéticas definindo dimensões (tarefa, tipo de usuário, clareza do pedido) e gerando uma chamada de modelo por combinação, evitando que o agente produza variações homogêneas num único shot.

1. Revisar e anotar. Os autores publicaram um plugin de código aberto para isso: npx skills add https://github.com/ai-evals-course/evals-skills. Apontando o agente para a skill evals-start, ele lê uma amostra dos seus dados, aprende o schema e monta uma interface de revisão local customizada, diferente para um chat de leasing e para um assistente de escrita, por exemplo. A regra é anotar em texto livre pelo menos 10 traces antes de deixar o agente sugerir problemas, como salvaguarda contra viés de automação. Anotação boa é específica ("o assistente disse que a unidade estava disponível quando a tool mostrava que estava alugada"), não um veredito genérico ("resposta ruim"). A meta é chegar a cerca de 100 traces anotados antes de considerar a etapa madura.

1. Transformar padrões em prioridades de produto. Com a base anotada, o agente agrupa as anotações em modos de falha e conta a frequência de cada um, virando uma lista priorizada do que atacar primeiro no roadmap.

Quem já colheu resultado disso

O texto cita casos concretos de empresas que investiram nessa disciplina antes de escrever métricas. A Shopify usou evals para guiar o desenvolvimento de um construtor de workflows de IA que ficou 2,2 vezes mais rápido e 68% mais barato que o sistema de modelo de fronteira que substituiu. A Cursor desenvolveu o roteamento do seu Auto Balance com evals, resultado em satisfação de usuário bem maior e redução de custo de 41%. A Ramp aumentou a acurácia do seu produto de coleta automática de recibos de 35% para 83% depois de investir em evals. A Harvey reconstruiu seu revisor de contratos com IA usando o mesmo processo, quase dobrando a pontuação interna de qualidade do produto.

O que fica em aberto

O próprio texto reconhece o limite: dados sintéticos não substituem usuários reais, e a curva de aprendizado do processo humano-agente exige várias iterações até as sugestões do agente ficarem confiáveis. Também vale notar que esse é conteúdo pago da newsletter, então a etapa final (transformar clusters de falha em métricas propriamente ditas) fica só esboçada no trecho aberto. Ainda assim, o recorte que já dá para levar é claro: antes de escrever qualquer métrica de avaliação para um recurso de IA no seu produto, vale perguntar se alguém do time já sentou para ler, um por um, uma amostra diversa de traces reais e anotar, em linguagem simples, o que incomoda em cada resposta. Se a resposta for não, a métrica que sair dali provavelmente vai medir a coisa errada.

Fonte: Lenny's Newsletter