Como avaliar um sistema RAG antes de ir para produção

Por que avaliar RAG antes de produção

Um protótipo RAG impressiona na demo: você faz uma pergunta, o sistema responde com base nos documentos, todos aplaudem. Em produção, os usuários fazem perguntas que você não previu, os documentos mudam, e o modelo alucina com confiança quando o retrieval falha.

Avaliar RAG não é opcional — é o que separa um chatbot interno de um sistema confiável. O erro mais comum é testar manualmente com cinco perguntas e declarar "funciona". Evals sistemáticos revelam onde o pipeline quebra: na recuperação, na geração, ou na combinação dos dois.

Este post cobre as métricas essenciais, como montar um dataset de teste e como rodar evals automatizados antes do deploy.

As três camadas de avaliação

RAG tem três componentes avaliáveis separadamente:

1. Retrieval — os chunks certos foram recuperados? (context precision, recall)
2. Generation — a resposta é fiel ao contexto? (faithfulness, groundedness)
3. End-to-end — a resposta é útil para o usuário? (answer relevancy, correctness)

Diagnosticar qual camada falha evita otimizar o prompt quando o problema é chunking, ou trocar de modelo quando o retrieval já está errado.

A demo acima mostra dois casos: um onde retrieval e geração estão alinhados (Case 1), e outro onde o contexto recuperado é irrelevante para a pergunta (Case 2) — faithfulness e context precision despencam mesmo com um LLM capaz.

Montando um dataset de teste

Antes de métricas automatizadas, você precisa de perguntas com respostas esperadas:

eval_dataset = [
    {
        "question": "O que é necessário para compartilhar dados no Open Finance?",
        "ground_truth": "Consentimento explícito do titular e participação em instituição autorizada.",
        "relevant_doc_ids": ["doc_open_finance_01", "doc_consentimento_03"],
    },
    {
        "question": "Quais APIs o Banco Central regulamenta?",
        "ground_truth": "APIs de Open Finance padronizadas para compartilhamento de dados.",
        "relevant_doc_ids": ["doc_bc_regulacao_02"],
    },
    # 15–30 perguntas cobrindo casos reais e edge cases
]

Regras para um bom dataset:

• Perguntas que usuários reais fariam — não só as óbvias
• Incluir perguntas fora do escopo — o sistema deve admitir que não sabe
• Incluir perguntas com sinônimos — testa robustez semântica do retrieval
• ground_truth conciso — referência para comparação, não texto marketing

Métricas essenciais

Context precision e recall

Medem se o retrieval trouxe os chunks certos:

• Precision — dos chunks recuperados, quantos são relevantes?
• Recall — dos chunks relevantes, quantos foram recuperados?

Baixa precision → chunks irrelevantes confundem o LLM. Baixo recall → contexto insuficiente para responder.

Faithfulness (groundedness)

A resposta é suportada pelo contexto recuperado? Se o LLM inventa informação não presente nos chunks, faithfulness é baixa — mesmo que a resposta "pareça correta".

Answer relevancy

A resposta responde à pergunta? Um texto fiel mas tangencial falha aqui.

Answer correctness

Compara a resposta gerada com ground_truth — pode ser exact match, BLEU, ou avaliação por outro LLM (LLM-as-judge).

Evals automatizados com RAGAS

RAGAS é um framework open source para métricas de RAG:

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)

eval_data = Dataset.from_dict({
    "question": [item["question"] for item in eval_dataset],
    "answer": generated_answers,
    "contexts": retrieved_contexts,
    "ground_truth": [item["ground_truth"] for item in eval_dataset],
})

results = evaluate(
    eval_data,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)

print(results)

RAGAS usa LLM-as-judge para algumas métricas — configure um modelo consistente (ex.: gpt-4o-mini) e fixe a versão para comparabilidade entre runs.

Evals com LangChain

LangChain oferece integração com evaluators:

from langchain.evaluation import load_evaluator
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")

faithfulness_evaluator = load_evaluator("labeled_criteria", criteria="correctness", llm=llm)

for item in eval_dataset:
    result = faithfulness_evaluator.evaluate_strings(
        prediction=generate_answer(item["question"]),
        input=item["question"],
        reference=item["ground_truth"],
    )
    print(item["question"], result["score"])

Para produção, integre evals no CI — falhe o deploy se faithfulness médio cair abaixo do threshold (como no post de GitHub Actions para ML).

Pipeline de avaliação recomendado

1. Dataset de 20+ perguntas com ground_truth
2. Rodar retrieval isolado → medir precision@k e recall
3. Rodar pipeline completo → medir faithfulness e answer relevancy
4. Comparar com baseline (modelo/chunker anterior)
5. Gate: faithfulness ≥ 0.85, context precision ≥ 0.80
6. Reavaliar após mudanças em chunking, embedding ou prompt

Versione o dataset de eval junto com o código — mudou o corpus de documentos, atualize as perguntas.

Além do básico: pontos de atenção

Armadilhas em evals de RAG:

• Evals no mesmo conjunto usado para tuning — overfitting de prompt; separe dev e holdout
• LLM-as-judge instável — mesma pergunta pode ter scores diferentes; rode múltiplas vezes ou use média
• Ignorar latência e custo — sistema com faithfulness 0.95 mas 30s de resposta pode ser inviável
• Não testar adversarial — perguntas maliciosas, injection no contexto, documentos contraditórios
• Métricas sem threshold — "faithfulness 0.72" não diz se passa; defina gates explícitos

Boas práticas:

• Logue retrieval + resposta em staging para revisão humana amostral
• Reavalie mensalmente com perguntas novas de usuários reais
• Monitore faithfulness em produção com amostra (ver post de monitoramento)

Conclusão

Avaliar RAG exige métricas nas três camadas: retrieval, generation e end-to-end. Monte um dataset de perguntas reais, use RAGAS ou LangChain evaluators, e defina gates antes do deploy.

Case 2 da demo ilustra o padrão mais comum de falha: retrieval errado → resposta confiante mas incorreta. Meça context precision antes de otimizar prompts. O próximo passo é decidir se RAG é mesmo a abordagem certa — ou se fine-tuning ou prompt engineering resolvem melhor.

Referencias

1. RAGAS — Documentação
2. RAGAS — Metrics overview
3. LangChain — Evaluation
4. LangChain — String evaluators
5. ARES — Automated RAG Evaluation
6. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
7. RAG na prática — post complementar neste blog (pipeline completo)