Avaliação de RAG: Recall@K, MRR e answer faithfulness na prática (guia com checklist)
Por que medir RAG como sistema (e não só o LLM)
RAG é um pipeline com peças interdependentes: indexação → recuperação → reordenação → geração. Alterar chunking, embeddings ou ranking muda o que chega ao LLM e, portanto, a qualidade da resposta. A avaliação precisa separar (1) qualidade de recuperação e (2) qualidade da resposta, além de monitorar latência e custo como restrições de produto. Guias técnicos recentes organizam a avaliação em camadas e recomendam medir o componente e o app ponta a ponta, de forma reproduzível.
Métricas essenciais
Recall@K (recuperação) — fração dos itens relevantes presentes no top-K. Útil quando o objetivo é “não perder” contexto essencial. Em IR clássico, recall mede a capacidade do sistema de retornar os itens relevantes; a variante @K foca os primeiros resultados.
MRR (recuperação orientada à posição) — Mean Reciprocal Rank captura a posição do primeiro item relevante na lista: quanto mais alto, melhor a experiência do reordenador e do buscador. Muito usada em busca e recomendação.
Answer faithfulness (resposta) — verifica se todas as afirmações da resposta podem ser suportadas pelo contexto recuperado; pode ser calculada por regras, “judge LLM” ou bibliotecas que automatizam a verificação claim-by-claim.
Outras úteis — precisão semântica/adequação (factualidade), toxicidade/segurança, e sinais operacionais: latência p95 e custo/1.000 chamadas no mesmo relatório para decisões realistas.
Golden set de Q&A: como construir
- Coleta das perguntas — derive de tickets reais, buscas internas e FAQs priorizadas por volume/valor.
- Respostas canônicas — redija respostas curtas somente com fatos presentes nas fontes; cite o trecho origem para auditoria.
- Fontes segmentadas — marque cada exemplo com “tópico/vertical”, “tipo de documento”, “tempo (mês/ano)”. Isso permite estratificar o teste (amostra balanceada por tópico).
- Negative sampling — para cada pergunta, crie negativos plausíveis: chunks muito parecidos porém não relevantes, para pressionar o rankeador e evitar “atalhos” (ex.: mesmo termo, outra data).
- Rotulagem dupla — em dúvidas, peça uma segunda revisão e guarde o rastro (quem marcou o quê, quando).
Dica: mantenha o golden set em repositório versionado e congele uma seed para reproduzir amostras. Isso é padrão em pipelines de avaliação modernos.
Protocolo de experimento (reprodutível)
- Tamanho de amostra: 200–500 Q&A costumam dar sinais estáveis para mudanças incrementais; aumente nos “lançamentos” maiores.
- Estratificação: distribua por tópico/tipo de fonte (ex.: 25% políticas, 25% manuais, 25% release notes, 25% tutoriais).
- Seed fixa: fixe a seed do sampler e registre hash do golden set.
- Congelamento de versão: anote hash/versão de: embeddings, indexador (FAISS/VS), rankeador, LLM, prompts e pré/pós-processadores.
- Cutoffs padrão: reporte Recall@1/3/5, MRR@5 e faithfulness para temperatura=0 e max_tokens fixo (evita ruído).
As referências de avaliação de RAG sugerem camadas: medir recall/MRR no retrieval e faithfulness na geração, num mesmo run para comparação entre versões.
Como calcular (na prática, sem dor)
1) Qualidade de recuperação
- Recall@K: por pergunta, marque se o chunk rotulado está no top-K. A média dá o recall@K.
- MRR: identifique a posição do primeiro chunk relevante; some 1/posição por pergunta e faça a média.
Bases clássicas de IR e cursos de Stanford documentam MRR/recall e por que esses indicadores refletem a utilidade do ranqueamento para o usuário.
2) Qualidade da resposta
- Faithfulness (claim-by-claim): extraia as afirmações da resposta e verifique suporte explícito no contexto recuperado. Ferramentas e docs descrevem o processo e o uso de LLM-as-a-Judge quando não há regra simples.
Boas práticas: avalie com e sem pós-processamento (ex.: citações/trechos), e registre as rationale do juiz (quando aplicar) para auditoria.
Logging que evita regressão silenciosa
- Entrada e versão: query normalizada, seed, data/hora, ID do experimento.
- Retrieval: IDs/posições dos chunks, score, origem da fonte, hash do índice.
- Geração: prompt final (após templating), parâmetros, resposta bruta.
- Métricas: recall@K, MRR, faithfulness; latência p50/p95 por estágio; custo estimado/1.000 chamadas.
- Rastreabilidade: linke cada execução ao commit de dados/código e ao relatório daquela versão.
A literatura prática de RAG/LLMOps recomenda infra de medição com estrutura de métricas para qualidade, custo e latência desde o início (não depois).
Relatório comparável por versão (exemplo de sumário)
- Setup — versão de embeddings/LLM, prompts, indexador, rankeador; data range.
- Retrieval — Recall@1/3/5 e MRR@5 globais e por tópico; destaque top wins/losses.
- Resposta — Faithfulness médio e distribuição; exemplos bons/ruins com trechos de suporte.
- Operação — Latência p95 por estágio e custo/1.000.
- Decisão — “Promover / Não promover”; próximos experimentos.
Guias de engenharia mostram exatamente esse loop de avaliação → decisão → iteração, tanto no componente quanto no app fim-a-fim.
Checklist de avaliação
- Golden set versionado, com estratos e negatives plausíveis.
- Seed fixada, amostra 200–500 Q&A, cutoffs padronizados.
- Recall@K e MRR calculados por tópico e no agregado.
- Answer faithfulness claim-by-claim com rationale do juiz.
- Latência p50/p95 e custo/1.000 no mesmo relatório.
- Logging com IDs de chunks, scores, prompts e versões.
Critérios de promoção definidos antes do teste (ex.: +3 p.p. em Recall@3 sem piorar p95 e custo).
Erros comuns (e como evitar)
- Comparar versões com amostras diferentes — congele seed e estratos.
- Otimizar só resposta sem olhar a recuperação — suba recall/MRR antes de ajustar prompting.
- Faithfulness sem rastro de verificação — guarde claims, evidências e a justificativa do juiz.
- Ignorar custo/latência — ganhos de qualidade que dobram custo e p95 não passam em produção.
- Misturar “hallucination” com “não encontrou contexto” — resolva retrieval primeiro.
Exemplo de “primeira entrega” (30–60 dias)
Dias 1–10 — monte golden set com 300 Q&A estratificados; configure indexação inicial e baseline de retrieval.
Dias 11–30 — rode experimento A (embeddings A + rankeador simples) vs. baseline e gere relatório v0 com Recall@K/MRR.
Dias 31–45 — adicione re-ranking e faithfulness claim-by-claim; compare v1 vs. v0 (qualidade, custo e p95).
Dias 46–60 — padronize logging, publique painel de avaliação e defina critérios de promoção para as próximas iterações.
Conclusão
Avaliar RAG “a sério” é separar retrieval de geração, padronizar Recall@K/MRR e faithfulness, e colocar latência + custo no mesmo quadro para decidir promoção de versão. Com golden set versionado, seed fixa e logging profundo, você evita regressões silenciosas e cria base para LLMOps contínuo.
Quer acelerar com prática guiada? O Bootcamp de ML & IA da Tekne conecta estes conceitos a um roteiro de learning-by-doing: você constrói o golden set, implementa experimentos reprodutíveis e publica um relatório comparável por versão, com qualidade, p95 e custo como alavancas de decisão.
FAQ
Recall@K é suficiente? Não. Use com MRR (posição do primeiro relevante) e uma métrica de resposta (faithfulness) para cobrir o que foi recuperado, o quão cedo e se a resposta se apoia no contexto.
Como medir faithfulness sem anotação humana pesada? Empregue LLM-as-a-Judge com justificativa armazenada e amostragem para auditoria humana periódica.
Onde coloco custo e latência? No mesmo relatório das métricas de qualidade; decisão de promoção precisa olhar três eixos.
