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)
Avaliar um sistema de RAG exige olhar para todo o pipeline, não apenas para o modelo de linguagem. Em uma aplicação real, a resposta final depende de várias etapas interdependentes: indexação, recuperação, reordenação e geração.
Na prática, qualquer mudança em chunking, embeddings, ranking ou prompt pode alterar o contexto que chega ao LLM. Como resultado, a qualidade da resposta também muda. Por isso, a avaliação precisa separar duas dimensões principais: a qualidade da recuperação e a qualidade da resposta gerada.
Além disso, métricas de produto como latência e custo devem entrar no mesmo quadro de análise. Um sistema pode melhorar em precisão, mas se dobrar o custo ou aumentar demais o tempo de resposta, talvez não esteja pronto para produção.
Guias técnicos sobre avaliação e monitoramento de RAG recomendam justamente essa abordagem em camadas: medir os componentes separadamente e, depois, avaliar o app de ponta a ponta de forma reproduzível.
Métricas essenciais para avaliação RAG
Uma boa avaliação de RAG combina métricas de retrieval, métricas de geração e sinais operacionais. Dessa forma, o time consegue entender se o problema está na busca, no ranqueamento, no prompt, no modelo ou na arquitetura do sistema.
Recall@K: qualidade da recuperação
O Recall@K mede a fração dos itens relevantes que aparecem entre os K primeiros resultados recuperados. Essa métrica é especialmente útil quando o objetivo é “não perder” contexto essencial.
Por exemplo, se a resposta correta depende de um documento específico, esse documento precisa aparecer no top-K. Caso contrário, o LLM provavelmente não terá base suficiente para responder com precisão.
Em recuperação de informação, o conceito de recall mede a capacidade do sistema de encontrar itens relevantes. A variante @K, por sua vez, foca nos primeiros resultados apresentados ao modelo ou ao usuário. Essa lógica aparece em referências clássicas de avaliação em IR, como o material do TREC/NIST sobre medidas de avaliação.
MRR: posição do primeiro item relevante
O MRR, ou Mean Reciprocal Rank, avalia a posição do primeiro item relevante na lista de resultados. Quanto mais alto esse item aparece, melhor tende a ser a experiência do buscador, do reordenador e do próprio sistema de RAG.
Na prática, o MRR ajuda a responder uma pergunta simples: o sistema encontra a informação certa cedo o bastante?
Se o chunk relevante aparece apenas na décima posição, por exemplo, o modelo pode não usá-lo, dependendo do limite de contexto e da estratégia de seleção. Por outro lado, quando o item relevante está nas primeiras posições, a chance de gerar uma resposta correta aumenta.
Essa métrica é bastante usada em busca, recomendação e avaliação de ranqueamento, como mostram materiais acadêmicos sobre avaliação de sistemas de informação.
Answer faithfulness: fidelidade da resposta ao contexto
A métrica de answer faithfulness avalia se as afirmações da resposta são sustentadas pelo contexto recuperado. Em outras palavras, ela verifica se o modelo está respondendo com base nas fontes disponíveis ou se está adicionando informações sem suporte.
Esse ponto é crítico em RAG. Afinal, o objetivo do pipeline é reduzir alucinações e aumentar rastreabilidade. Se a resposta parece correta, mas não pode ser justificada pelos trechos recuperados, há um risco de confiabilidade.
A avaliação de faithfulness pode ser feita por regras, revisão humana, LLM-as-a-Judge ou bibliotecas que automatizam a checagem claim-by-claim. A documentação do Ragas sobre faithfulness descreve essa lógica de decompor a resposta em afirmações e verificar suporte no contexto. Também há materiais introdutórios sobre faithfulness em IA que ajudam a contextualizar o conceito.
Outras métricas úteis
Além de Recall@K, MRR e answer faithfulness, vale acompanhar métricas complementares. Entre elas estão precisão semântica, adequação da resposta, factualidade, toxicidade, segurança e sinais operacionais.
Nesse grupo, latência p95 e custo por 1.000 chamadas são especialmente importantes. Afinal, decisões de produção não dependem apenas de qualidade. Elas também precisam considerar experiência do usuário, escalabilidade e viabilidade econômica.
Por isso, ferramentas e guias de engenharia, como a documentação da Databricks sobre avaliação de performance em aplicações de IA generativa, recomendam analisar qualidade, custo e latência no mesmo relatório.
Golden set de Q&A: como construir
O golden set é a base de avaliação do sistema. Ele reúne perguntas, respostas canônicas e fontes de referência para comparar versões do pipeline de RAG de forma consistente.
Para construir esse conjunto, comece pelas perguntas reais dos usuários. Elas podem vir de tickets de suporte, buscas internas, FAQs, histórico de atendimento ou dúvidas frequentes de áreas de negócio. Em seguida, priorize os casos por volume, criticidade e valor.
As respostas canônicas devem ser curtas, objetivas e baseadas apenas em fatos presentes nas fontes. Além disso, cada resposta precisa apontar para o trecho de origem, permitindo auditoria posterior.
Também é importante segmentar as fontes. Marque cada exemplo com atributos como tópico, vertical, tipo de documento e período, por exemplo mês e ano. Dessa maneira, o time consegue estratificar os testes e evitar uma amostra enviesada para um único tipo de conteúdo.
Outro passo relevante é criar negativos plausíveis. Para cada pergunta, inclua chunks parecidos, mas não relevantes. Isso pressiona o rankeador e reduz atalhos frágeis, como recuperar um documento apenas porque contém o mesmo termo, mas trata de outra data, produto ou contexto.
Por fim, adote dupla rotulagem nos casos ambíguos. Quando houver dúvida, uma segunda pessoa deve revisar a marcação. Como resultado, o golden set ganha mais confiabilidade e mantém um histórico de quem marcou o quê, quando e por qual motivo.
Uma boa prática é manter o golden set em repositório versionado e congelar uma seed para reproduzir amostras. Esse tipo de controle é comum em pipelines modernos de avaliação de RAG, principalmente quando o time precisa comparar versões com segurança.
Protocolo de experimento (reprodutível)
Um protocolo de avaliação precisa permitir comparação justa entre versões. Portanto, antes de rodar experimentos, defina tamanho de amostra, critérios de estratificação, versões dos componentes e métricas de corte.
Para mudanças incrementais, uma amostra de 200 a 500 Q&A costuma gerar sinais úteis. Em lançamentos maiores, no entanto, vale ampliar a base para capturar mais variações por tema, fonte e tipo de pergunta.
A estratificação também faz diferença. Uma divisão simples pode distribuir os casos entre políticas, manuais, release notes e tutoriais. Assim, o resultado não fica concentrado em um único tipo de documento.
Outro cuidado é fixar a seed do sampler e registrar o hash do golden set. Além disso, documente a versão de embeddings, indexador, vector store, rankeador, LLM, prompts e pré ou pós-processadores.
Na hora de reportar os resultados, use cutoffs padrão, como Recall@1, Recall@3, Recall@5, MRR@5 e faithfulness. Para reduzir ruído, mantenha temperatura igual a zero e um valor fixo de max tokens durante a comparação.
Esse desenho permite medir recuperação e geração no mesmo run. Com isso, fica mais fácil entender se uma melhoria veio do retrieval, do re-ranking, do prompt ou do modelo usado na resposta final.
Como calcular (na prática, sem dor)
A avaliação de RAG pode parecer complexa, mas o cálculo básico das métricas é direto quando o golden set está bem estruturado.
1. Qualidade de recuperação
Para calcular Recall@K, verifique, em cada pergunta, se o chunk relevante aparece entre os K primeiros resultados. Depois, tire a média entre todas as perguntas avaliadas.
Já o MRR exige identificar a posição do primeiro chunk relevante. Em seguida, calcule 1 dividido por essa posição e tire a média entre os exemplos. Se o primeiro item relevante aparece na posição 1, o score é 1. Se aparece na posição 2, o score é 0,5, e assim por diante.
Essas métricas ajudam a entender se o sistema recupera o contexto certo e se esse contexto aparece cedo o suficiente para ser útil. Materiais de recuperação de informação, como aulas de Stanford sobre avaliação em IR, documentam a lógica por trás de indicadores como recall e MRR.
2. Qualidade da resposta
Para medir answer faithfulness, divida a resposta em afirmações individuais e verifique se cada uma possui suporte explícito no contexto recuperado. Essa abordagem claim-by-claim torna a avaliação mais auditável.
Na prática, é possível aplicar regras simples em alguns casos. Em cenários mais abertos, no entanto, ferramentas de avaliação e LLM-as-a-Judge podem ajudar a identificar se cada afirmação está sustentada pelas fontes. A documentação do Ragas sobre faithfulness apresenta essa abordagem com mais detalhes.
Também é recomendável avaliar respostas com e sem pós-processamento, como citações, trechos de suporte ou formatação final. Além disso, quando houver juiz automatizado, registre a justificativa da avaliação para permitir auditoria humana posterior.
Logging que evita regressão silenciosa
Um dos maiores riscos em sistemas de RAG é a regressão silenciosa. Ou seja, uma mudança aparentemente pequena melhora um ponto do pipeline, mas piora outro sem que o time perceba.
Para reduzir esse risco, registre a entrada e a versão de cada execução. Isso inclui query normalizada, seed, data, hora e ID do experimento.
No bloco de retrieval, salve IDs e posições dos chunks, score, origem da fonte e hash do índice. Já na geração, registre o prompt final após templating, parâmetros usados e resposta bruta.
As métricas também precisam ficar no log. Inclua Recall@K, MRR, faithfulness, latência p50/p95 por estágio e custo estimado por 1.000 chamadas.
Por fim, conecte cada execução ao commit de dados, código e relatório daquela versão. Dessa forma, quando uma métrica cair, o time consegue investigar a causa com rapidez.
A literatura prática de RAG e LLMOps, como a documentação da Databricks sobre infraestrutura de medição para IA generativa, recomenda criar essa estrutura desde o início. Afinal, medir qualidade, custo e latência depois que o sistema já está em produção costuma ser mais caro e mais arriscado.
Relatório comparável por versão (exemplo de sumário)
Um bom relatório de avaliação deve facilitar decisão, não apenas acumular números. Por isso, organize os resultados de forma comparável entre versões.
Comece pelo setup. Informe versão de embeddings, LLM, prompts, indexador, rankeador e intervalo de dados avaliado.
Depois, apresente o bloco de retrieval com Recall@1, Recall@3, Recall@5 e MRR@5, tanto no agregado quanto por tópico. Sempre que possível, destaque ganhos e perdas relevantes.
Na etapa de resposta, mostre o faithfulness médio, a distribuição dos scores e exemplos bons e ruins com trechos de suporte. Isso ajuda o time a enxergar não apenas o número final, mas também o tipo de erro que ainda precisa ser resolvido.
Inclua, ainda, uma visão operacional com latência p95 por estágio e custo por 1.000 chamadas. Em seguida, finalize com uma decisão explícita: promover ou não promover a versão. Caso a versão não seja promovida, registre os próximos experimentos recomendados.
Esse ciclo de avaliação, decisão e iteração é o que transforma a avaliação de RAG em uma prática contínua de engenharia, e não em uma análise pontual.
Checklist de avaliação
Antes de promover uma nova versão, valide se os principais elementos de avaliação estão cobertos:
- Golden set versionado, com estratos e negativos plausíveis;
- seed fixada, amostra de 200 a 500 Q&A e cutoffs padronizados;
- Recall@K e MRR calculados por tópico e no agregado;
- answer faithfulness avaliado claim-by-claim, com justificativa do juiz;
- latência p50/p95 e custo por 1.000 chamadas no mesmo relatório;
- logging com IDs de chunks, scores, prompts e versões;
- critérios de promoção definidos antes do teste, como ganho de 3 pontos percentuais em Recall@3 sem piorar p95 e custo.
Erros comuns (e como evitar)
Um erro comum é comparar versões com amostras diferentes. Para evitar esse problema, congele seed, estratos e critérios de seleção.
Também é arriscado otimizar apenas a resposta sem olhar para a recuperação. Se o contexto certo não chega ao LLM, ajustes de prompt tendem a ter impacto limitado. Por isso, resolva recall e MRR antes de investir em refinamentos mais sofisticados de geração.
Outro problema é medir faithfulness sem rastro de verificação. Nesse caso, a métrica pode até parecer objetiva, mas fica difícil auditar. O ideal é guardar claims, evidências e justificativas do juiz.
Ignorar custo e latência também compromete a decisão. Afinal, ganhos de qualidade que dobram o custo ou pioram muito o p95 podem não passar em produção.
Por último, evite misturar “hallucination” com “não encontrou contexto”. Quando a resposta falha porque o sistema não recuperou a fonte correta, o problema principal está no retrieval, não necessariamente no LLM.
Exemplo de “primeira entrega” (30–60 dias)
Uma primeira entrega de avaliação de RAG pode ser organizada em quatro etapas.
Nos dias 1 a 10, monte um golden set com cerca de 300 Q&A estratificados. Além disso, configure a indexação inicial e gere um baseline de retrieval.
Entre os dias 11 e 30, rode o experimento A, comparando embeddings A e rankeador simples contra o baseline. Em seguida, gere um relatório v0 com Recall@K e MRR.
Dos dias 31 a 45, adicione re-ranking e avaliação de faithfulness claim-by-claim. Nessa etapa, compare v1 com v0 considerando qualidade, custo e p95.
Por fim, entre os dias 46 e 60, padronize o logging, publique um painel de avaliação e defina critérios de promoção para as próximas iterações. Como resultado, o time passa a ter uma base confiável para evoluir o sistema sem depender de impressões subjetivas.
Conclusão
Avaliar RAG de forma séria significa separar retrieval de geração, padronizar métricas como Recall@K, MRR e answer faithfulness, além de incluir latência e custo no mesmo quadro de decisão.
Com golden set versionado, seed fixa e logging profundo, você reduz regressões silenciosas e cria uma base sólida para LLMOps contínuo. Mais do que medir respostas isoladas, essa abordagem permite comparar versões, priorizar melhorias e decidir com mais segurança quando uma mudança deve ir para produção.
Quer acelerar com prática guiada? O Bootcamp de ML & IA da Tekne conecta esses conceitos a um roteiro de learning-by-doing. Nele, você constrói o golden set, implementa experimentos reprodutíveis e publica um relatório comparável por versão, usando qualidade, p95 e custo como alavancas de decisão.
FAQ
Recall@K é suficiente?
Não. O Recall@K mostra se os itens relevantes aparecem no top-K, mas não avalia sozinho a experiência de ranqueamento nem a fidelidade da resposta. Por isso, use essa métrica junto com MRR e answer faithfulness.
Como medir faithfulness sem anotação humana pesada?
Uma alternativa é usar LLM-as-a-Judge com justificativa armazenada. Ainda assim, recomenda-se fazer auditoria humana periódica por amostragem, principalmente em casos críticos ou sensíveis.
Onde entram custo e latência?
Custo e latência devem aparecer no mesmo relatório das métricas de qualidade. Dessa forma, a decisão de promoção considera três eixos: qualidade, performance e viabilidade operacional.
