Avaliando apps de LLM - notas sobre o AI Engineering da Chip Huyen (capítulos 3 e 4)

Estou lendo o AI Engineering, livro da Chip Huyen publicado em 2025. E não consigo parar. Eu gosto de entender o lado técnico de tudo com que trabalho, e o livro passa um pouco por cada coisa. Vai levar um tempo até eu terminar, já que é longo. No momento estou nos capítulos 3 e 4, os de avaliação (evaluation), mas resolvi escrever esse artigo com o que tenho pensado e como estou usando o que aprendi nos meus projetos atuais, tanto em desenvolvimento quanto em produção.

O que me levou ao livro foi justamente essa parte da avaliação. Como ela mesma diz, avaliar aplicações de IA é um processo difícil. Para garantir que um app cumpre o papel dele, você precisa de métodos e métricas claras, e é aí que entra a avaliação. Se você não sabe o que precisa medir, é bem provável que termine com um produto que não consegue provar o próprio valor.

O grande problema de avaliar foundation models (LLMs, geradores de imagem, e por aí vai) é que eles entregam resultados abertos (open-ended): não existe um conjunto fechado de respostas possíveis. Isso torna muito mais difícil garantir que o resultado é o que queremos para uma tarefa específica. No capítulo 3, quando lista os desafios de avaliar esses modelos, ela lembra que quanto mais inteligente o modelo, mais difícil é avaliá-lo: quase todo mundo percebe a conta errada de uma criança da primeira série, mas nem todo mundo percebe o erro numa solução de doutorado. Saber se o céu é azul, por exemplo, é fácil. Se a LLM responde "o céu é vermelho", sabemos que, na maioria dos casos, está errado. Mas quando entram termos e fatos de domínio, de áreas científicas ou industriais, saber se a resposta está errada fica bem mais difícil. Um exemplo do meu trabalho: nosso assistente de SDR, que qualifica leads industriais pelo WhatsApp, ofereceu a uma fábrica de sucos produtos que a nossa base de conhecimento lista para biodiesel e laticínios. A mensagem era fluida, educada, e para quem não é da indústria parecia perfeita.

Isso nos leva a várias abordagens diferentes. O capítulo 3 tem uma seção inteira sobre AI as a judge, incluindo as limitações dela, como inconsistência e critérios ambíguos. Um ponto que me chamou atenção: o juiz não é só o modelo, é o modelo mais o prompt. Mudar um dos dois, muda o juiz. Eu venho combinando o método LLM as a judge com avaliação humana, até conseguir confiar o suficiente no juiz. Monto um dataset com casos que já vimos em produção, de conversas reais a interações anteriores com o nosso assistente, e depois crio experimentos com métricas que indicam se as respostas cumprem a tarefa. O SDR, por exemplo, precisa qualificar leads e obter informações relevantes deles, sem sair de uma persona e tom de voz natural. Também precisamos levar em conta o custo por mensagem, já que o volume desse app em produção é alto.

Com os resultados dos experimentos, dá para ir ajustando a arquitetura, os prompts, os nós, trocando modelos, até ver que estamos chegando mais perto do objetivo: as métricas que definimos e a intenção por trás de cada resposta. Trazer especialistas para o processo também ajuda muito, mas achei importante alinhar os critérios dos juízes de IA e dos juízes humanos. Assim, dá para comparar os dois e ajustar o juiz de IA para se aproximar do especialista. No capítulo 4, ela chama a criação de uma diretriz de avaliação clara de "the most important step of the evaluation pipeline" (o passo mais importante do pipeline de avaliação), e parte desse passo é validar a rubrica com humanos e refiná-la até que eles consigam segui-la sem ambiguidade. Nosso assistente primeiro planeja um objetivo para cada turno e só depois escreve a mensagem. Na minha primeira rodada de calibração, rotulei às cegas 40 desses objetivos e comparei com o veredito do juiz. Concordamos em só 65% deles (kappa de Cohen de 0,26). Ler as discordâncias foi a parte mais valiosa: algumas vinham de rubricas rígidas demais, e sete vinham de regras de negócio que não tinham sido escritas. Depois de corrigir as duas coisas, a concordância nos mesmos 40 itens subiu para 95% (kappa de 0,89). Esse é um número otimista, já que o ajuste foi feito nesses mesmos itens. O teste de verdade ainda vai ser uma rodada nova.

Essas regras importaram mais do que a escolha do modelo. Com elas, um modelo pequeno (Claude Haiku) foi de 71,3% para 93,8% de objetivos que cumprem a rubrica, empatando com o grande (Claude Opus, 92,5%) a 1/18 do custo por chamada. Nem sempre é fácil ter bastante dado de avaliação humana, custa caro, em dinheiro e tempo. Por isso um bom juiz, que faça esse papel, é tão importante: ele permite rodar esse tipo de comparação toda vez que algo muda.

A avaliação também mede as suas próprias proteções. Tínhamos uma etapa de revisão que conferia toda mensagem antes do envio. Quando medi, o revisor completo reescreveu 21,7% dos rascunhos, e 12 das 13 reprovações não tinham nenhuma falha grave segundo o juiz. Em alguns casos, a reescrita até deixou a mensagem menos natural. Valia a pena revisar tudo? Pelos números, não. Mandando ao revisor só os rascunhos de risco, escolhidos por um classificador barato, como o JEV, cerca de 20% dos turnos passaram pela revisão. O custo por turno caiu de US$ 0,042 para US$ 0,022, sem mais falhas graves do que revisando todas as mensagens.

A avaliação também mostra onde consertar. O erro da fábrica de sucos não pedia mais revisão: vinha da busca na base de conhecimento, que trazia trechos sobre a indústria errada. Filtrar a base pelo segmento do lead levou os turnos que usam RAG de 94,1% para 100% sem falha grave. É o primeiro passo do pipeline de avaliação que ela propõe no capítulo 4: avaliar cada componente do sistema separadamente, e não só a saída final, senão não tem como saber onde ele falha.

Todos esses números vêm de um laboratório, com leads simulados a partir de leads reais, de 40 a 81 casos e uma ou duas repetições por experimento. São amostras pequenas, e os próximos passos são confirmá-los com os rótulos do nosso time de vendas e, depois, em produção.

A principal lição até aqui: uma avaliação vale o quanto o seu juiz concorda com quem conhece o negócio, e é construindo essa concordância que aparecem as regras que faltavam no produto. Provavelmente vou escrever mais sobre o livro, ainda tem muito para aprender e testar nos meus projetos atuais. Também já estou escrevendo o case da IARA-SDR-2, a nova versão do assistente de SDR que temos em produção, e lá vão aparecer os números completos e os detalhes técnicos.

---

Este texto foi escrito originalmente em inglês. Esta é a versão em português (pt-br), com ajuda de IA na tradução e na revisão.