RAG em produção: 5 erros que custam caro (e como saber se é o seu caso)

Tese

RAG funciona bem em demo e degrada em produção por motivos recorrentes — mas "recorrente" não é o mesmo que "sempre a causa". Os cinco pontos abaixo são onde eu olharia primeiro, com o jeito de confirmar cada um antes de sair mudando código: uma melhora depois de ajustar chunking, por exemplo, é evidência de que o chunking importava nesse caso, não prova de que era a causa raiz.

1. Chunking sem contexto

Sintoma: respostas que citam fatos corretos fora de contexto, ou que "esquecem" informação que estava logo ao lado do trecho recuperado.

Causa provável: cortar documentos em pedaços fixos (ex.: 500 tokens) ignora limites semânticos — um chunk pode começar no meio de uma tabela e perder o cabeçalho que dava sentido a ela.

Como confirmar: inspecione manualmente uma amostra dos chunks recuperados para queries que falharam. Se o chunk em si já não faz sentido isolado, o problema é de chunking antes de ser de modelo.

Quando não é isso: se os chunks recuperados fazem sentido isolados e ainda assim a resposta erra, o problema provavelmente está no reranking ou no prompt, não no chunking — mudar a estratégia de corte não vai ajudar.

2. Sem reranking

Sintoma: o contexto certo existe no índice, mas não aparece entre os top-k enviados ao modelo.

Causa provável: buscar por similaridade de embedding e enviar os top-k direto pro modelo deixa passar resultados relevantes que não são os mais parecidos textualmente com a query.

Como confirmar: aumente o k da busca inicial (sem reranking) e veja se o trecho certo aparece mais abaixo na lista. Se aparece na posição 15 mas você só envia top-5, o problema é de ranking, não de cobertura do índice.

Contraponto: reranking com cross-encoder tipicamente troca uma fração de recall por precisão — ele reordena um conjunto menor de candidatos com mais fidelidade, mas não substitui uma busca inicial que já erra a cobertura. Se o trecho certo nem está entre os candidatos iniciais, reranking não resolve.

Exemplo de configuração: chunking + reranking

Para tornar os pontos 1 e 2 concretos, um exemplo de configuração real (LangChain) que endereça os dois ao mesmo tempo — chunking que respeita separadores naturais do texto, em vez de cortar a cada N caracteres fixos, e um passo de reranking com cross-encoder antes de mandar contexto ao modelo:

from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder

# 1. Chunking: tenta cortar em parágrafo/linha antes de cair em corte bruto por caractere.
# chunk_size e chunk_overlap dependem do seu conteúdo — os valores abaixo são ponto de partida,
# não uma recomendação universal.
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=120,
)
chunks = splitter.create_documents([documento_fonte])  # substitua pelo seu texto

# 2. Reranking: reordena os candidatos do retriever antes de gerar a resposta.
# "BAAI/bge-reranker-v2-m3" é um modelo entre várias opções de cross-encoder — troque conforme
# idioma e latência aceitável no seu caso.
reranker_model = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-v2-m3")
reranker = CrossEncoderReranker(model=reranker_model, top_n=5)

retriever_com_rerank = ContextualCompressionRetriever(
    base_compressor=reranker,
    base_retriever=retriever,  # seu retriever de vetor já existente (Chroma, Pinecone, etc.)
)

Este exemplo segue a documentação oficial do LangChain para o reranker, mas não foi executado neste ambiente — confira a versão do pacote e o nome exato do modelo de reranker antes de colar em produção.

3. Índice nunca reavaliado

Sintoma: respostas desatualizadas apresentadas com a mesma confiança de respostas corretas.

Causa provável: documentos-fonte mudam; o índice vetorial raramente é invalidado quando isso acontece.

Como confirmar: compare a data de última modificação dos documentos-fonte com a data da última reindexação. Se o gap for de semanas ou meses, esse é provavelmente um fator.

Quando não é isso: para bases de conhecimento que mudam raramente (documentação de referência estável, por exemplo), reindexação em tempo real é custo sem benefício proporcional — o problema nesse cenário costuma estar em outro lugar da lista.

4. Sem monitoramento de recall

Sintoma: ninguém percebe a degradação até um usuário reclamar.

Causa provável: sem medir se o contexto recuperado contém a resposta esperada, não há sinal antes do usuário virar o detector de regressão.

Como confirmar / o que medir: frameworks de avaliação de RAG como o RAGAS separam a avaliação em métricas de recuperação (context recall, context precision) e de geração (faithfulness, answer relevancy) — rodar isso contra um conjunto de perguntas de referência antes de cada mudança de índice ou de prompt dá o sinal que falta.

5. Prompt genérico demais

Sintoma: o modelo responde com confiança mesmo quando o contexto recuperado não contém a resposta — alucinação disfarçada de resposta segura.

Causa provável: o prompt de sistema não instrui o modelo a admitir quando o contexto não cobre a pergunta.

Como confirmar: teste deliberadamente com perguntas fora do escopo da base de conhecimento. Se o modelo nunca responde "não sei" ou equivalente, o prompt provavelmente não trata esse caso.

Avaliação e onde entra revisão humana

Métricas automatizadas (RAGAS ou equivalente) pegam regressão em escala, mas não substituem revisão humana de uma amostra — principalmente em domínios onde uma resposta errada tem custo real (jurídico, saúde, financeiro). Um pipeline de RAG em produção precisa das duas camadas: avaliação automatizada rodando a cada mudança, e amostragem humana periódica das respostas reais que os usuários receberam, não só do conjunto de teste.

Quando isso muda

Nada aqui é regra fixa. Um chatbot interno de baixo risco, com poucos usuários e fácil de corrigir manualmente, não justifica o mesmo investimento em avaliação que um produto voltado ao cliente final. A pergunta que decide o quanto investir em cada um desses cinco pontos é: qual o custo real de uma resposta errada, e com que velocidade alguém percebe quando isso acontece?