Avaliação de RAG: métricas para medir seu pipeline

Um pipeline de [RAG (Retrieval-Augmented Generation)](/artigo/rag-retrieval-augmented-generation-o-que-e-como-funciona) pode dar a impressão de que está funcionando bem: a busca retorna documentos, o modelo gera uma resposta coerente, e ninguém reclama. O problema é que "parecer certo" e "estar certo" são coisas diferentes — e a única forma de saber qual das duas está acontecendo é avaliar o pipeline com métricas específicas, não com a sensação de quem testou cinco perguntas manualmente. Avaliar RAG significa medir, separadamente, se o sistema busca os documentos certos (retrieval) e se o modelo usa esses documentos de forma correta e completa para responder (geração). Sem essa separação, é impossível saber se um erro veio de uma busca ruim ou de um modelo que ignorou um contexto perfeitamente relevante.

Por que um RAG "que funciona" ainda pode falhar

O objetivo do RAG é reduzir alucinação ao ancorar a resposta em documentos reais — mas isso não é garantido automaticamente. Como já mostramos ao explicar [o que é alucinação em IA](/artigo/alucinacao-em-ia-por-que-modelos-erram-como-reduzir), o modelo continua gerando texto de forma probabilística mesmo quando tem contexto na janela; nada o impede de ignorar o trecho relevante e inventar uma resposta plausível, ou de misturar a informação do contexto com conhecimento (possivelmente desatualizado ou errado) da própria etapa de treinamento. Um pipeline de RAG pode falhar de pelo menos três formas diferentes, e cada uma pede uma métrica diferente para ser detectada:

• Retrieval ruim: os documentos certos não estão entre os recuperados — o modelo nunca teve chance de acertar.
• Geração não fundamentada: o contexto certo foi recuperado, mas o modelo respondeu com base em outra coisa.
• Resposta incompleta: o contexto trazia parte da informação necessária, mas não toda, e a resposta final ficou pela metade.

Medir só "a resposta ficou boa?" no final do pipeline mistura os três problemas e não diz onde consertar.

Duas camadas, duas famílias de métricas

Antes de escolher uma métrica, separe o que está sendo avaliado: o retriever — a parte que decide quais [chunks](/artigo/chunking-rag-como-dividir-documentos-corretamente) de um [banco de dados vetorial](/artigo/banco-de-dados-vetorial-o-que-e-como-funciona) entram no prompt — ou o gerador, o LLM que lê esses chunks e escreve a resposta. Avaliações que tratam o pipeline como caixa-preta, olhando só a resposta final, não indicam se o problema está na busca por [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia) ou na forma como o modelo interpreta o contexto.

Métricas de retrieval: o sistema busca os documentos certos?

Essas métricas exigem um conjunto de perguntas com os documentos corretos já identificados manualmente — o chamado golden set. Segundo material de referência sobre avaliação de sistemas de busca publicado por fornecedores de bancos vetoriais como Pinecone e Weaviate, as métricas mais usadas são:

• Recall@k — de todos os documentos relevantes que existem, quantos apareceram entre os k primeiros resultados. Não considera a ordem, só a presença.
• Hit Rate@k — se pelo menos um documento relevante apareceu entre os k primeiros. Uma medida binária, mais grosseira que o recall.
• MRR (Mean Reciprocal Rank) — a posição do primeiro resultado relevante. Um acerto na 1ª posição vale mais que um na 4ª, mesmo com o mesmo recall@10.
• nDCG (Normalized Discounted Cumulative Gain) — parecido com o MRR, mas considera todos os resultados relevantes da lista, aplicando um desconto logarítmico para posições mais baixas.

def recall_at_k(retrieved_ids, relevant_ids, k):
    top_k = retrieved_ids[:k]
    hits = [doc_id for doc_id in top_k if doc_id in relevant_ids]
    return len(hits) / len(relevant_ids) if relevant_ids else 0.0

def reciprocal_rank(retrieved_ids, relevant_ids):
    for i, doc_id in enumerate(retrieved_ids, start=1):
        if doc_id in relevant_ids:
            return 1 / i
    return 0.0

# Pergunta com 2 documentos relevantes conhecidos (golden set)
retrieved = ["doc_9", "doc_2", "doc_5", "doc_1"]
relevant = {"doc_2", "doc_1"}

print(recall_at_k(retrieved, relevant, k=3))   # 0.5 -> só doc_2 apareceu no top 3
print(reciprocal_rank(retrieved, relevant))    # 0.5 -> primeiro acerto na posição 2

Rodar isso em produção exige manter um golden set — perguntas reais com os documentos corretos marcados à mão. É trabalho manual, mas é o único jeito de medir retrieval de forma objetiva; sem golden set, qualquer número é apenas a opinião do próprio LLM sobre si mesmo.

A RAG Triad: avaliando a geração por três ângulos

Para a parte de geração — o que o modelo faz com o contexto que recebeu — o conceito mais difundido é o da RAG Triad, popularizado pela TruLens/TruEra (hoje parte da Snowflake). A ideia é avaliar três perguntas separadas, cada uma com uma nota própria:

• Context relevance — o contexto recuperado é relevante para a pergunta feita? Na prática se sobrepõe às métricas de retrieval, mas avaliado pelo conteúdo, não pelo ID do documento.
• Groundedness (fundamentação) — cada afirmação da resposta pode ser rastreada até algo que estava no contexto? É a métrica que captura alucinação mesmo com contexto correto.
• Answer relevance — a resposta final realmente responde à pergunta original, ou é tecnicamente fundamentada mas evasiva?

Um pipeline pode ir bem em duas dimensões e falhar na terceira — por exemplo, contexto relevante e resposta fundamentada, mas que não responde de fato o que foi perguntado. Medir só uma das três notas esconde esse tipo de falha.

RAGAS: as mesmas ideias em um framework de código aberto

O framework de código aberto RAGAS formaliza uma proposta parecida com a RAG Triad, com nomes próprios e fórmulas mais explícitas:

• Faithfulness — a proporção de afirmações da resposta que podem ser verificadas diretamente no contexto recuperado. Um faithfulness de 0,7 significa que 3 em cada 10 afirmações não têm base no que foi recuperado — equivalente à groundedness da RAG Triad.
• Context Precision — dos trechos recuperados, quantos eram realmente relevantes para a pergunta. Precisão baixa indica contexto "poluído", que dilui informação útil com ruído.
• Context Recall — da informação necessária para responder corretamente, quanto apareceu nos trechos recuperados. Recall baixo indica que falta informação, mesmo que o que foi recuperado esteja correto.
• Answer Relevancy — a similaridade semântica entre a resposta gerada e a pergunta original.

LLM-as-judge: como essas métricas são calculadas na prática

Tanto a RAG Triad quanto a maior parte das métricas do RAGAS não vêm de uma fórmula matemática simples — elas usam outro LLM como "juiz", com um prompt específico pedindo para comparar resposta, contexto e pergunta e atribuir uma nota ou um veredito. Essa técnica, chamada LLM-as-judge, é o que torna essas métricas viáveis em escala (não dá para ter um humano lendo cada resposta), mas carrega limitações que valem registro:

• Custo e latência — cada avaliação gera pelo menos uma chamada extra a um LLM, às vezes várias, como uma por afirmação no caso do faithfulness.
• Viés do próprio juiz — um LLM-juiz tende a favorecer respostas mais longas, mais bem formatadas ou escritas em um estilo parecido com o seu próprio, independentemente da qualidade real.
• Não determinismo — rodar a mesma avaliação duas vezes pode dar notas ligeiramente diferentes, o que exige repetir a avaliação ou fixar a temperatura do juiz em zero para comparações confiáveis ao longo do tempo.

Isso não invalida a técnica — é hoje a forma prática mais usada de avaliar RAG em escala —, mas significa que os números devem ser lidos como uma estimativa direcional ("melhorou 12% depois da mudança no chunking"), não como uma verdade absoluta.

Por que o golden set humano continua necessário

LLM-as-judge automatiza a avaliação contínua, mas não substitui um conjunto de referência construído por humanos que conhecem o domínio. Um golden set — normalmente entre 20 e 100 pares de pergunta e resposta esperada, com os documentos-fonte identificados — serve para duas coisas que a automação sozinha não resolve: validar se o próprio juiz automático está calibrado, rodando-o contra respostas que você já sabe que são boas ou ruins, e capturar casos de borda específicos do seu domínio, que um LLM genérico não sabe reconhecer como errados.

Onde a avaliação de RAG mais falha na prática

• Avaliar só a resposta final, sem separar retrieval de geração — quando a nota cai, ninguém sabe se o problema foi na busca ou na escrita da resposta.
• Golden set pequeno demais ou só com perguntas fáceis, que não representa as perguntas reais dos usuários, incluindo as ambíguas e as que não têm resposta no conteúdo indexado.
• Não reavaliar depois de trocar o modelo de embeddings, a estratégia de chunking ou adicionar reranking — qualquer mudança nessas peças pode alterar o resultado, e sem reavaliação isso só aparece como reclamação de usuário.
• Confiar cegamente no LLM-juiz sem nunca conferir uma amostra manualmente — vieses de formato e de verbosidade passam despercebidos.
• Tratar avaliação como um evento único de lançamento, e não como um processo contínuo rodado a cada mudança relevante no pipeline.

Como montar uma primeira avaliação de RAG

• 1. Monte um golden set de 20 a 50 perguntas reais (ou plausíveis) do seu domínio, com a resposta esperada e os documentos-fonte identificados manualmente.
• 2. Rode só o retriever contra esse golden set e meça recall@k e MRR — isso avalia a busca isolada, antes de qualquer geração.
• 3. Rode o pipeline completo e meça faithfulness/groundedness e answer relevancy da resposta final, via LLM-as-judge.
• 4. Registre esses números como baseline antes de qualquer mudança em chunking, embeddings, reranking ou prompt do gerador.
• 5. Rode a mesma avaliação de novo a cada mudança relevante — o valor de um baseline é justamente poder comparar com ele depois.

Avaliação de RAG não é um checkbox de lançamento — é o instrumento que diz se uma mudança no chunking, na busca ou no prompt tornou o sistema melhor ou pior, algo que a leitura de umas poucas respostas nunca revela de forma confiável.