Avaliação de RAG: faithfulness e relevância
Sem medir, você não melhora. Como avaliar recuperação e geração de um RAG.
6 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
Você ajustou o chunking, trocou o modelo de embedding, reescreveu o prompt — mas como sabe se melhorou? Sem métricas, você está voando às cegas. Avaliação não é etapa final: é o instrumento que guia cada decisão do pipeline RAG.
Duas metades independentes para avaliar
Um pipeline RAG tem dois trabalhos distintos: recuperar os trechos certos e gerar uma resposta fiel a eles. Esses dois trabalhos falham de formas diferentes, então precisam de métricas diferentes.
Na recuperação, a pergunta é: os chunks relevantes apareceram na lista retornada? Você mede isso com hit rate (pelo menos um chunk relevante está no top-k?), precision@k (dos k chunks retornados, quantos são realmente úteis?) e recall@k (dos chunks relevantes que existem, quantos foram capturados?). Um retriever com precision baixa entope o contexto com ruído; um com recall baixo deixa informação crítica de fora.
Na geração, a pergunta se divide em duas: a resposta é fiel às fontes (faithfulness / groundedness) e ela responde à pergunta (answer relevance)? Faithfulness detecta alucinação — o modelo afirmou algo que não está em nenhum chunk recuperado. Answer relevance detecta respostas que são verdadeiras mas não resolvem o que foi perguntado.
Errar qual metade está quebrada é o erro mais caro em RAG. Se o retriever traz os chunks errados, melhorar o prompt não resolve. Se o retriever está bom mas o modelo alucina, trocar o embedding não ajuda. Medir as duas metades separadamente é o que permite agir no lugar certo.
Métricas de RAG: o que cada uma mede
| Métrica | Metade | O que detecta | Como calcular | |
|---|---|---|---|---|
| Hit Rate | Recuperação | Pelo menos 1 chunk relevante no top-k | % de queries com hit | — |
| Precision@k | Recuperação | Ruído no contexto enviado ao LLM | Chunks relevantes / k retornados | — |
| Recall@k | Recuperação | Informação relevante perdida | Chunks relevantes capturados / total existente | — |
| Faithfulness | Geração | Alucinação: afirmações sem suporte nos chunks | LLM-as-judge ou NLI por afirmação | — |
| Answer Relevance | Geração | Resposta não endereça a pergunta | Similaridade semântica resposta ↔ query | — |
| Latência (p50/p95) | Sistema | Degradação de experiência | Tempo de resposta end-to-end | — |
| Custo por query | Sistema | Impacto financeiro de mudanças | Tokens entrada + saída × preço do modelo | — |
Na prática, anotação humana é o padrão-ouro mas não escala para iteração rápida. O que funciona no dia a dia é usar um LLM (Claude 3 Sonnet ou Haiku no Bedrock, por exemplo) como juiz: você passa a query, os chunks recuperados e a resposta gerada, e pede ao modelo que avalie faithfulness e relevância em uma escala estruturada. Não é perfeito — o juiz também erra — mas é consistente o suficiente para detectar regressões entre versões. No site do curso há estudos de evals rodando no Bedrock com exemplos reais de prompts de julgamento. Use anotação humana para calibrar o juiz periodicamente, não para cada experimento.
Como montar um dataset de avaliação e detectar alucinação
Toda avaliação séria começa com um dataset de referência: pares (pergunta, resposta esperada) construídos a partir dos seus documentos reais. Você pode gerá-los sinteticamente — peça a um LLM que leia cada chunk e produza perguntas plausíveis — e depois filtre manualmente os casos mais representativos e os casos difíceis (ambíguos, multi-hop, sem resposta). Cinquenta a cem pares bem escolhidos valem mais do que mil gerados sem curadoria.
Para detectar alucinação, a técnica mais prática é decomposição por afirmação: quebre a resposta gerada em sentenças atômicas e, para cada uma, pergunte ao LLM-juiz se ela é sustentada por algum dos chunks recuperados. Uma afirmação sem suporte é uma alucinação. Isso é mais preciso do que avaliar a resposta inteira de uma vez, porque o modelo pode estar 90% correto e alucinar em um detalhe crítico.
Um detalhe operacional importante: meça custo e latência junto com qualidade. Aumentar k de 5 para 10 pode melhorar recall em alguns pontos percentuais, mas dobra os tokens de contexto e o custo de geração. Essa troca precisa aparecer no mesmo dashboard. Mudanças de chunking, modelo de embedding, estratégia de busca e prompt de sistema devem ser tratadas como experimentos com métricas registradas — não como ajustes informais.
Pipeline de avaliação RAG
Fluxo de como um experimento RAG é avaliado: dataset de referência alimenta tanto o pipeline RAG quanto o processo de julgamento, produzindo métricas de recuperação e geração separadamente.
- Dataset de referência · (query, resposta esperada)
- Documentos reais · (chunks indexados)
- Retriever · (busca híbrida + rerank)
- LLM gerador · (Bedrock)
- Resposta gerada · + chunks usados
- Métricas de recuperação · hit rate · precision · recall
- LLM-as-judge · (faithfulness · relevance)
- Anotação humana · (calibração periódica)
- Dashboard de métricas · qualidade · custo · latência
Métricas de RAG
Toque num conceito e depois na definição.
Avaliação contínua: cada mudança é um experimento
A avaliação não é algo que você faz uma vez antes de ir para produção. Cada mudança no pipeline — estratégia de chunking, modelo de embedding, valor de k, prompt de sistema, modelo gerador — deve disparar uma rodada de avaliação no dataset de referência. Sem isso, você acumula mudanças sem saber qual delas ajudou e qual introduziu regressão.
A estrutura mínima que recomendo: versione cada configuração do pipeline (pode ser simples, um hash dos parâmetros relevantes), rode o dataset de referência, registre as métricas em uma tabela comparativa. Quando uma métrica cai, você sabe exatamente qual mudança causou isso.
Em produção, adicione uma camada de avaliação online: amostre queries reais, rode o LLM-juiz de forma assíncrona e alerte quando faithfulness cair abaixo de um limiar. Isso captura problemas que o dataset sintético não previu — documentos novos que chegaram ao índice, mudanças na distribuição das perguntas dos usuários, drift de comportamento do modelo após atualizações.
Latência e custo entram aqui também. Um modelo gerador mais caro pode melhorar faithfulness em alguns pontos — mas se o custo por query triplicar, talvez um prompt melhor com o modelo atual seja a escolha certa. Só os números dizem. As aulas seguintes cobrem como o Bedrock Knowledge Bases gerencia parte desse pipeline, e como guardrails complementam a avaliação com controles em tempo real.
Como montar sua avaliação RAG do zero
- 1
Crie o dataset de referência
Gere pares (query, resposta esperada) sinteticamente com um LLM sobre seus documentos reais. Cuide manualmente de 50–100 casos, incluindo casos difíceis e sem resposta.
- 2
Meça a recuperação separadamente
Para cada query, compare os chunks retornados com os chunks relevantes conhecidos. Calcule hit rate, precision@k e recall@k antes de olhar para a geração.
- 3
Avalie geração com LLM-as-judge
Decomponha a resposta em afirmações atômicas. Para cada uma, peça ao juiz se está sustentada pelos chunks. Avalie também se a resposta endereça a pergunta original.
- 4
Registre custo e latência na mesma corrida
Tokens de entrada e saída, tempo de resposta p50/p95. Qualidade sem custo é uma métrica incompleta para decisões de arquitetura.
- 5
Versione e compare
Cada configuração do pipeline recebe um identificador. Nenhuma mudança vai para produção sem uma linha na tabela comparativa de métricas.
- 6
Adicione avaliação online em produção
Amostre queries reais, rode o juiz de forma assíncrona, alerte em regressões. Calibre o juiz com anotação humana periodicamente.
Dúvidas frequentes sobre avaliação de RAG
Posso usar RAGAS ou frameworks prontos?
Sim, RAGAS e frameworks similares implementam essas métricas e funcionam bem como ponto de partida. O importante é entender o que cada métrica mede para interpretar os resultados corretamente — frameworks não substituem esse entendimento.
Qual tamanho mínimo para o dataset de referência?
Não existe número mágico, mas 50 pares bem curados já permitem detectar regressões significativas. Abaixo disso, a variância estatística é alta demais para confiar nas comparações.
Faithfulness alta garante que a resposta está correta?
Não. Faithfulness mede se a resposta é sustentada pelos chunks recuperados — não se os chunks são verdadeiros. Se o documento fonte contém informação errada, faithfulness alta não ajuda. Por isso qualidade da base de conhecimento importa tanto quanto o pipeline.
Como medir custo por query no Bedrock?
O Bedrock retorna contagem de tokens de entrada e saída em cada resposta. Multiplique pelos preços publicados do modelo. Registre isso junto com as métricas de qualidade para ter a visão completa de cada experimento.
Fechamento do Módulo 2
Você chegou ao fim do Módulo 2 com o que realmente importa: não apenas como recuperar melhor (busca híbrida, reranking, filtros, roteamento), mas como saber se você está recuperando melhor. Avaliação é o que transforma experimentos em decisões. Um pipeline RAG sem métricas é um sistema que você opera no escuro — e em produção, escuro é caro. O Módulo 3 começa com o Amazon Bedrock Knowledge Bases: como o serviço gerenciado da AWS implementa boa parte do que vimos neste módulo, onde ele te poupa trabalho e onde você ainda precisa das suas próprias escolhas.
Checkpoint — Módulo 2
1. O que 'faithfulness' mede em RAG?