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.