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. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
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.