RAG Pipeline: como avaliar embeddings e evitar respostas erradas

O que é um RAG Pipeline

RAG significa Retrieval-Augmented Generation. E a técnica que faz um LLM como GPT ou Claude buscar informações em uma base de dados própria antes de responder. Em vez de depender só do que o modelo aprendeu no treinamento, você injeta contexto relevante na hora da resposta.

A ideia e simples: o usuário faz uma pergunta, o sistema busca os trechos mais relevantes nos seus documentos, junta tudo num prompt e manda para o LLM. O modelo responde com base nesse contexto. Isso resolve o problema de dados desatualizados e alucinações sobre informações específicas do seu negócio.

Empresas que tem bases de conhecimento internas, documentações técnicas ou grandes volumes de PDFs adoram RAG. E um dos casos de uso mais práticos de IA generativa hoje.

Como funciona a recuperação por embeddings

O coração de qualquer RAG e o modelo de embedding. Ele transforma texto em vetores numéricos - uma lista de números que representa o significado semântico do texto. Textos com significado parecido ficam próximos no espaço vetorial.

Quando o usuário pergunta algo, a pergunta também vira um vetor. O sistema calcula a similaridade entre esse vetor e todos os vetores armazenados e retorna os trechos mais próximos. Esses trechos viram o contexto do LLM.

O problema: se o modelo de embedding for fraco ou mal calibrado para o seu domínio, ele vai trazer trechos errados. O LLM vai receber contexto irrelevante e vai responder com base nisso. A resposta parece confiante, mas esta errada. Isso e o problema central do RAG mal avaliado.

Principais métricas para avaliar seu RAG

Existem quatro métricas fundamentais que você deve monitorar:

• Context Precision: dos trechos recuperados, quantos são realmente relevantes para a pergunta? Se você busca 10 trechos e só 3 são úteis, sua precisão e 30%.
• Context Recall: de todos os trechos que deveriam ter sido recuperados, quantos o sistema encontrou? Mede o quanto você esta perdendo informação relevante.
• Faithfulness: a resposta do LLM e fiel ao contexto fornecido? Ou o modelo ignorou o contexto e inventou algo do próprio treinamento?
• Answer Relevancy: a resposta final responde de fato a pergunta do usuário? Uma resposta pode ser fiel ao contexto mas irrelevante para a pergunta real.

O ideal e medir todas as quatro. Na prática, a maioria dos times mede só a velocidade e satisfação do usuário - e descobre os problemas só quando o cliente reclama.

Como começar: ferramentas para avaliação

O passo a passo básico para avaliar seu RAG:

Passo 1: Instale o RAGAS, a biblioteca mais usada para avaliação de RAG em Python:

pip install ragas
pip install langchain openai

Passo 2: Monte seu dataset de avaliação com perguntas, contextos recuperados, respostas geradas e respostas de referência.

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

data = {
    "question": ["Qual e o prazo de entrega?"],
    "contexts": [["O prazo padrão e de 5 dias úteis..."]],
    "answer": ["O prazo de entrega e de 5 dias úteis."],
    "ground_truth": ["5 dias úteis"]
}

dataset = Dataset.from_dict(data)
result = evaluate(dataset, metrics=[context_precision, faithfulness, answer_relevancy])
print(result)

Passo 3: Interprete os resultados. Scores entre 0.8 e 1.0 são considerados bons. Abaixo de 0.6, você tem um problema real a resolver.

Exemplo prático: diagnosticando um RAG com problemas

Imagine um chatbot de suporte técnico que responde perguntas sobre um manual de produto. O cliente pergunta como resetar as configurações de rede. O RAG recupera trechos sobre outro produto da mesma empresa, pois os documentos estão misturados. O LLM responde com confiança sobre o produto errado.

Rodando o RAGAS, você ve context_precision de 0.3 - 70% do contexto recuperado era irrelevante. O problema estava no chunking: os documentos de vários produtos estavam misturados sem metadados de identificação.

from langchain.schema import Document

doc = Document(
    page_content=chunk_texto,
    metadata={"produto": "ModeloX", "versão": "2.1"}
)

retriever = vectorstore.as_retriever(
    search_kwargs={"filter": {"produto": produto_do_usuario}}
)

Com o filtro de metadados, a context_precision subiu de 0.3 para 0.87. Sem mudar o modelo de embedding, sem mudar o LLM - só ajustando como os documentos são organizados e recuperados.

Comparação: modelos de embedding disponíveis

A escolha do modelo de embedding impacta diretamente a qualidade da recuperação. As principais opcoes em 2026:

• text-embedding-3-large (OpenAI): excelente qualidade geral, 3072 dimensões, custa por token. Bom ponto de partida para a maioria dos casos.
• text-embedding-3-small (OpenAI): 1536 dimensões, mais barato, qualidade ligeiramente menor. Bom para volumes grandes.
• nomic-embed-text (open source): rode localmente, sem custo por token, qualidade competitiva. Via Ollama em uma linha.
• multilingual-e5-large: melhor opcao se você tem documentos em português. Modelos treinados só em inglês perdem qualidade em PT-BR.

Para documentos em português, a diferença entre um modelo multilingual e um em inglês pode ser dramática. Sempre teste com dados do seu domínio antes de escolher.

Pontos positivos e limitações do RAG

RAG resolve problemas reais: dados atualizados sem retreinar o modelo, respostas com fontes verificáveis, custo muito menor que fine-tuning. Para a maioria dos casos corporativos, e a abordagem certa.

Mas tem limitações claras. Perguntas que exigem raciocínio sobre vários documentos ao mesmo tempo ainda são difíceis. Também falha quando o usuário faz perguntas vagas demais para o retriever encontrar algo útil.

Casos de uso reais

Suporte técnico interno: empresa com 500 PDFs de manuais. Sem avaliação, o chatbot estava respondendo sobre versões antigas de produtos. Com RAGAS, identificaram que o chunking estava quebrando tabelas ao meio - informação fragmentada, contexto inutilizado.

Chatbot jurídico: escritório de advocacia com jurisprudência própria. O problema era terminologia jurídica específica. Trocaram o modelo de embedding para o multilingual-e5 e a context_recall subiu de 0.55 para 0.82 em perguntas sobre legislação brasileira.

Documentação de produto SaaS: startup com documentação em constante mudança. Implementaram re-indexação automática toda vez que a doc e atualizada, com avaliação automática rodando em CI. Se o score cair abaixo de 0.75, o deploy e bloqueado.

Base de conhecimento de RH: respostas sobre políticas internas da empresa. Metadados de departamento e data de vigência fazem toda a diferença para filtrar documentos obsoletos.

Dicas e boas práticas

Vale a pena investir em avaliação de RAG?

Se você já tem um RAG em produção sem nenhuma métrica de qualidade, a resposta e sim - e urgente. A maioria dos problemas de RAG e silenciosa: o sistema responde, o usuário fica frustrado, mas não reporta. Você só descobre o problema quando alguém reclama de uma decisão errada tomada com base numa resposta incorreta do chatbot.

Para quem esta começando, a ordem e: primeiro faca funcionar, depois meca, depois otimize. Não tente otimizar o que você não consegue medir. O RAGAS com um golden dataset de 50 pares já e suficiente para começar a ter visibilidade real do que esta acontecendo.

O próximo passo: clone o repositório do RAGAS no GitHub, siga o quickstart e rode as métricas no seu pipeline existente. Uma tarde de trabalho pode revelar problemas que você não sabia que existiam.