Guia prático de evals para funcionalidades com IA

Evals ajudam a sair do "parece melhor" quando uma funcionalidade com IA muda. Eles não garantem qualidade absoluta, mas tornam mais claro o que está sendo avaliado, quais casos importam e onde uma nova versão melhorou ou regrediu.

Contexto

Nos guias anteriores da série, a ideia foi montar uma base para pensar em aplicações com IA de forma mais prática.

Primeiro, o foco foi RAG: quando uma aplicação precisa buscar contexto externo antes de responder. Depois, o foco foi chunking, embeddings e retrieval: como preparar, dividir, indexar e recuperar esse contexto.

Em seguida, veio o tema de respostas estruturadas: quando a saída do modelo precisa virar dado validável para o sistema. Mas existe uma pergunta que aparece logo depois: como saber se a funcionalidade melhorou de verdade?

Essa pergunta pega muita gente no contrapé. A gente ajusta um prompt, troca o modelo, muda o tamanho dos chunks, altera o schema, adiciona um fallback ou refina uma instrução. A resposta fica mais bonita em um teste manual. A primeira impressão é boa.

Só que uma resposta boa em uma conversa isolada não prova que o fluxo melhorou. Talvez aquele caso específico tenha ficado melhor, mas outro caso importante tenha piorado.

O problema

A pergunta central deste guia é: como avaliar funcionalidades com IA sem depender apenas de impressão subjetiva?

Quando uma funcionalidade tradicional muda, normalmente existem alguns apoios conhecidos: testes automatizados, critérios de aceite, revisão de código, QA, logs, métricas e validação manual.

Com IA, parte disso continua valendo. Mas aparece uma dificuldade extra: a saída pode variar, a qualidade nem sempre é binária e nem todo comportamento esperado cabe em um `true` ou `false`.

• Uma resposta pode estar correta, mas incompleta.
• Pode estar bem formatada, mas pouco útil.
• Pode ser útil, mas estar fora do schema.
• Pode ser fiel ao contexto, mas longa demais.
• Pode parecer melhor para um caso e pior para outro.

Se a única validação for "testei aqui e gostei", o processo fica frágil. Não porque o teste manual seja inútil. Ele é importante. O problema é quando ele é o único critério.

Modelo mental

1casos de teste2  -> critérios de avaliação3  -> execução4  -> comparação5  -> decisão

Os casos de teste representam situações que a funcionalidade precisa lidar. Os critérios dizem o que será observado em cada resposta. A execução roda uma ou mais versões sobre os mesmos casos. A comparação mostra onde melhorou, onde piorou e onde ficou igual.

Um eval simples pode ser uma tabela com dez exemplos, uma rubrica curta e uma revisão humana honesta. O ganho já aparece quando os mesmos casos passam a ser usados para comparar versões diferentes.

Evals não são só benchmarks

Quando se fala em avaliar IA, é fácil pensar em benchmark público de modelo. Esse não é o foco aqui.

Benchmarks tentam comparar modelos em tarefas mais amplas, muitas vezes com datasets padronizados. Isso pode ser útil para acompanhar o mercado, mas não responde sozinho uma pergunta de produto ou engenharia: essa funcionalidade específica ficou melhor para o meu fluxo?

• O resumo preserva os pontos importantes?
• A classificação respeita as categorias definidas?
• A resposta usa apenas o contexto recuperado?
• O JSON segue o schema esperado?
• O fallback aparece quando deveria?
• A saída ajuda a próxima etapa do sistema?

Quando usar evals

Evals ajudam principalmente quando uma mudança pode afetar comportamento de forma difícil de perceber em um único teste.

• Ao mudar um prompt importante.
• Ao trocar ou comparar modelos.
• Ao ajustar chunking, embeddings ou retrieval.
• Ao alterar critérios de resposta estruturada.
• Ao adicionar uma etapa de fallback.
• Ao criar uma classificação automática.
• Ao gerar resumo, extração ou sugestão de ação.
• Ao investigar respostas inconsistentes.

O ponto não é transformar todo experimento em um processo pesado. O ponto é reconhecer quando o risco de regressão começa a justificar uma avaliação mais organizada.

Como começar pequeno

Um bom começo é montar um conjunto pequeno de casos representativos. Não precisa ser perfeito. Precisa ser útil.

Imagine uma funcionalidade fictícia que recebe mensagens de suporte e gera um resumo com prioridade, categoria e próximos passos sugeridos.

11. Usuário não consegue acessar a conta.22. Usuário relata cobrança duplicada.33. Usuário quer cancelar a assinatura.44. Usuário envia elogio sobre uma funcionalidade.55. Usuário mistura duas dúvidas na mesma mensagem.66. Usuário escreve de forma incompleta.77. Usuário informa dado sensível que não deve ser repetido.88. Usuário pede algo fora do escopo do produto.

Esses casos não cobrem o mundo inteiro, mas já ajudam a sair do teste com uma única mensagem confortável. Sempre que o prompt, o modelo ou o fluxo mudar, os mesmos casos podem ser usados de novo.

Critérios antes da resposta

Um erro comum é avaliar a resposta só depois que ela aparece. O problema é que, quando a resposta é convincente, a gente tende a adaptar o critério para gostar dela.

• Aderência ao contexto: a resposta usa apenas informações presentes ou recuperadas?
• Completude: os pontos importantes foram preservados?
• Formato: a saída respeita o schema ou estrutura esperada?
• Utilidade: a resposta ajuda a próxima etapa do fluxo?
• Segurança: a resposta evita expor dados sensíveis desnecessários?
• Consistência: casos parecidos recebem tratamento parecido?

Esses critérios podem ser exatos, aproximados ou avaliados por rubrica. Em muitos casos, uma escala simples como `passou`, `falhou` e `precisa revisar` já ajuda.

Exemplo prático

Vamos imaginar uma entrada fictícia para uma funcionalidade de triagem.

1Não consigo acessar minha conta desde ontem.2Tentei redefinir a senha, mas o e-mail não chega.3Preciso entrar hoje porque tenho uma reunião.

A funcionalidade precisa gerar uma saída estruturada para triagem, com categoria, prioridade, resumo, ações sugeridas e indicação de revisão humana.

1{2  "categoria": "login",3  "prioridade": "alta",4  "resumo": "Usuário não consegue acessar a conta e não recebe o e-mail de redefinição de senha.",5  "acoes_sugeridas": [6    "Verificar envio de e-mail de redefinição",7    "Conferir se há bloqueio ou falha recente no login",8    "Encaminhar para atendimento humano se o acesso for urgente"9  ],10  "precisa_revisao_humana": true11}

Agora imagine duas versões de prompt. A versão A classifica o caso como prioridade média, faz um resumo genérico e não pede revisão humana. A versão B identifica a urgência, preserva o detalhe do e-mail e encaminha para revisão.

Olhando só por impressão, a versão B parece melhor. Mas o eval deixa mais claro o porquê: ela acertou categoria, prioridade, resumo, próximos passos, revisão humana e formato.

O eval não diz que a versão B é perfeita. Ele mostra que, para esse caso e esses critérios, ela se comportou melhor. O mesmo teste precisa ser repetido em outros casos para revelar regressões.

Regressão é onde o eval mostra valor

Uma mudança em IA raramente melhora tudo de uma vez. Às vezes, um prompt novo resolve um problema e cria outro.

• Antes, o modelo esquecia campos obrigatórios; depois, respeita o schema, mas o resumo ficou genérico demais.
• Antes, respondia com mais detalhes; depois, ficou mais conciso, mas omitiu ressalvas importantes.
• Antes, o retrieval trazia contexto amplo; depois, ficou mais preciso, mas perdeu informações complementares.

Sem um conjunto de evals, essas regressões aparecem tarde. Com evals, a pergunta muda de "essa resposta ficou boa?" para "essa mudança melhorou o conjunto de casos que importa?".

Teste manual, checklist e eval repetível

Teste manual exploratório é quando você conversa com a funcionalidade, tenta exemplos livres e observa o comportamento. Checklist é quando você revisa pontos fixos: formato, tom, links, dados sensíveis, uso de contexto e fallback. Eval repetível é quando você usa os mesmos casos e critérios para comparar versões.

Os três têm valor. O erro é tratar um teste manual feliz como se fosse validação suficiente para uma funcionalidade inteira.

Onde a revisão humana entra

Nem todo critério precisa ser automático no começo. Para muitos projetos, a primeira versão de um eval pode ser manual, especialmente quando os critérios têm nuance.

• A resposta foi útil?
• O resumo preservou o sentido?
• O tom está adequado?
• A explicação ficou clara?
• A sugestão faz sentido para uma pessoa revisar?

Automatizar uma avaliação ruim só deixa o erro mais rápido. Antes de pensar em métricas sofisticadas, vale entender o que uma boa resposta significa naquele fluxo.

Como comparar versões

Um eval fica mais útil quando compara versões de forma controlada. O ideal é mudar uma coisa por vez quando possível: prompt A contra prompt B, modelo atual contra modelo novo, retrieval antigo contra retrieval ajustado, schema anterior contra schema novo.

1Data: 2026-07-132Mudança: prompt de triagem v23Objetivo: melhorar identificação de urgência4Casos avaliados: 125Resultado geral: melhorou urgência em 4 casos, manteve 6, piorou completude em 26Decisão: ajustar prompt antes de aprovar7Observação: versão nova tende a resumir demais mensagens longas

Esse tipo de anotação evita perder o raciocínio da decisão e ajuda quando a mudança precisa ser revisada depois.

Limites e ressalvas

Evals ajudam, mas não resolvem tudo. Eles não garantem que a IA nunca vai errar, não substituem revisão humana em fluxos sensíveis e não provam que uma funcionalidade é boa para todos os casos possíveis.

Também podem dar uma falsa sensação de segurança se os casos forem fracos. Um eval com exemplos fáceis demais pode aprovar uma mudança ruim. Um eval com critérios vagos pode virar só uma opinião com tabela.

A pergunta não é "como criar o eval perfeito?". A pergunta melhor é: qual conjunto mínimo de casos e critérios já tornaria essa decisão menos subjetiva?

Aprendizados

• Evals ajudam a comparar versões de funcionalidades com IA, não apenas modelos isolados.
• Uma resposta boa em um teste manual não prova que o fluxo inteiro melhorou.
• Casos representativos são mais importantes do que uma lista enorme de exemplos aleatórios.
• Critérios precisam vir antes da avaliação, não depois da resposta convincente.
• Regressão é uma das principais razões para manter evals.
• Revisão humana continua fazendo parte do processo.
• Um eval simples, manual e repetível já pode melhorar a qualidade da decisão técnica.

Conclusão

Trabalhar com IA em aplicações exige uma mudança de postura. Não basta perguntar se a resposta ficou bonita. É preciso perguntar se ela continua útil, fiel ao contexto, compatível com o formato esperado e adequada para o fluxo em que será usada.

Evals entram justamente nesse ponto. Eles não deixam a IA perfeita e não transformam julgamento técnico em matemática pura. Mas ajudam a sair do improviso.

Com poucos casos, critérios claros e comparação entre versões, já dá para perceber melhor onde uma mudança ajudou, onde trouxe regressão e onde ainda precisa de revisão.

No fim, medir melhor não é sobre ter certeza absoluta. É sobre decidir com menos chute.