Avaliação (evals) e alucinação: como saber se está bom

Quando você avalia um sistema de IA manualmente, lê uns dez outputs, acha razoável, segue em frente, você está fazendo amostragem de viés de confirmação. Você tende a notar o que funciona e a normalizar o que falha.

O problema se agrava com LLMs porque eles são fluentes por natureza. Uma resposta errada escrita com confiança e boa gramática parece mais certa do que uma resposta correta escrita de forma hesitante. Fluência não é factualidade.

Além disso, sistemas de IA têm superfície de falha não-determinística: o mesmo prompt pode gerar outputs diferentes dependendo de temperatura, versão do modelo, mudança no contexto. Uma avaliação manual pontual captura um momento, não um comportamento.

O que você precisa é de um conjunto de casos de teste com gabarito: entradas conhecidas, saídas esperadas, critérios de aceitação claros, e de um processo que rode esses casos toda vez que você muda algo: o prompt, o modelo, o chunking do RAG, a ordem das ferramentas. Sem isso, cada mudança é um salto no escuro. Com isso, cada mudança tem um placar.

Dataset de referência com gabarito é o tipo mais confiável. Você tem pares (pergunta, resposta esperada) criados por humanos, e compara o output do modelo contra esse gabarito usando métricas determinísticas (exact match, F1, ROUGE). É barato de rodar, reproduzível e ótimo para regressão. A limitação: construir o dataset custa tempo, e ele fica desatualizado se o domínio muda.

LLM-as-judge usa um modelo (geralmente mais capaz, como Claude Opus ou GPT-4o) para avaliar o output de outro modelo segundo critérios que você define em um prompt de avaliação: 'a resposta está factualmente correta? está fundamentada no contexto fornecido? é concisa?'. É escalável e funciona bem para dimensões subjetivas, tom, completude, ausência de alucinação, que métricas automáticas não capturam. O risco é viés do juiz: o modelo avaliador tem preferências próprias e pode ser enganado por outputs fluentes.

Métricas de tarefa são específicas ao que o sistema faz. Um sistema de extração de entidades tem precisão e recall. Um sistema de classificação tem acurácia e F1. Um sistema de geração de código tem taxa de compilação e taxa de testes passando. Defina essas métricas antes de construir, elas forçam clareza sobre o que 'funcionar' significa.

Avaliação humana é o padrão-ouro, mas não escala. Use para calibrar os outros métodos (você descobre que seu LLM-judge concorda com humanos em 87% dos casos), para casos-limite e para decisões de go/no-go em lançamentos críticos.

Correção e factualidade são o núcleo, a resposta está certa? Está fundamentada em fontes verificáveis? Não inventou dados? mas um sistema de produção exige mais dimensões.

Alucinação merece atenção especial. Existem dois tipos principais: alucinação factual (o modelo afirma algo falso sobre o mundo) e alucinação de fundamentação (o modelo cita ou parafraseia algo que não está no contexto que recebeu). Em sistemas RAG, o segundo tipo é mais traiçoeiro porque o modelo pode ignorar os documentos recuperados e gerar do seu próprio conhecimento, ou pior, misturar os dois. Um LLM-judge bem calibrado consegue detectar isso comparando o output com o contexto fornecido.

Custo em tokens é uma métrica de negócio disfarçada de métrica técnica. Se o seu prompt de sistema tem 4.000 tokens e você faz 1 milhão de chamadas por dia, isso importa. Meça tokens de entrada e saída por chamada, e projete o custo por caso de uso. Mudanças de prompt que parecem inocentes podem dobrar o custo.

Latência afeta UX diretamente. Meça p50 e p95, a mediana esconde os casos lentos que frustram usuários. Latência também é afetada por escolha de modelo, tamanho do contexto e se você está usando streaming.

Segurança como dimensão de eval significa: o sistema recusou corretamente inputs maliciosos? Vazou dados do system prompt? Executou tool calls que não deveria? Isso se conecta diretamente com a Lição 10, onde tratamos guardrails.

Um dataset de avaliação bem construído é um ativo de engenharia tão valioso quanto o código do sistema. Ele documenta o comportamento esperado, serve como especificação executável e protege contra regressões.

A cada mudança relevante, novo modelo, prompt revisado, chunking diferente no RAG, nova ferramenta adicionada ao agente, você roda os evals e compara com o baseline anterior. Se a pontuação de correção caiu 3 pontos e o custo subiu 20%, você tem evidência para decidir se vale a pena. Sem evals, você está tomando essa decisão no escuro.

O ciclo completo fecha quando você conecta evals com observabilidade em produção. Logs de produção revelam casos que você não antecipou no dataset, usuários fazem perguntas que você não imaginou, em idiomas que você não testou, com contextos que quebram suposições do seu prompt. Esses casos viram novos itens no dataset de eval. O sistema fica mais robusto a cada iteração.

Essa conexão entre evals offline e observabilidade online é o que diferencia um sistema de IA gerenciado de um sistema de IA que você torce para funcionar. No Módulo 5 vamos aprofundar a instrumentação de produção, traces, métricas e alertas, mas o fundamento é este: você precisa medir antes de chegar lá, e continuar medindo depois.