O Momento em que Eu Parei de Culpar o Modelo

Eu já perdi contas de quantas vezes ouvi (e falei) a mesma frase: “meu RAG funciona perfeitamente no teste, mas em produção começa a entregar respostas estranhas”. A reação natural é trocar de LLM, testar um modelo mais caro, ajustar o prompt de novo. Eu já fiz isso. Não resolveu.

O problema quase nunca está no modelo. Está na pipeline de recuperação — na parte chata, silenciosa, que ninguém quer debugar porque parece “já estar pronta”.

Depois de apanhar bastante com isso, cheguei num fluxo de 4 passos que resolve praticamente todo caso de RAG que entrega resposta genérica, incompleta ou simplesmente errada. Vou te mostrar exatamente onde cada etapa entra e por quê.

Passo 1: Limpeza e Clarificação da Pergunta (Query Rewriting)

Metade das respostas ruins de um RAG nem é culpa da recuperação — é culpa da pergunta que chegou até ela. Se o usuário manda algo vago ou sem contexto, a busca recupera trechos de baixa qualidade, porque está buscando a coisa errada.

Como eu corrijo isso:

  • Uso o histórico da conversa. Adiciono uma etapa intermediária onde um LLM leve reescreve a pergunta do usuário usando o contexto do chat. Se alguém pergunta “por que o pássaro comeu aquilo?”, essa etapa transforma em algo como “por que o pica-pau se alimenta de larvas de árvore, segundo o artigo X?” — agora sim, uma busca de verdade.
  • Configuro perguntas clarificatórias. Quando o sistema identifica que a query está vaga demais, ele pede uma confirmação rápida de contexto antes de sair buscando no banco vetorial. Custa um turno extra de conversa, mas evita entregar lixo com confiança.

Passo 2: Busca Híbrida (Vetores + BM25)

Essa foi a armadilha em que eu mais me enrolei no começo: confiar só na busca vetorial (semantic search).

Busca vetorial é ótima pra capturar conceito e significado semântico. O problema é que ela falha miseravelmente com termos exatos — código de erro tipo ERR_404_NET, número de série, SKU de produto, nome próprio raro. Vetores entendem “sentido”; não entendem “string exata”.

Como eu corrijo isso:

Implemento busca híbrida, combinando busca vetorial com um algoritmo de busca por palavra-chave tradicional, como o BM25. A busca por palavra-chave garante a captura do termo exato; a busca vetorial garante a compreensão do contexto ao redor dele. Uma cobre a fraqueza da outra.

Passo 3: Filtragem por Metadados (Metadata Filtering)

Enquanto a base de conhecimento é pequena, buscar em tudo funciona bem o suficiente. O problema aparece quando ela cresce pra milhares de documentos — nesse ponto, buscar no banco inteiro só aumenta o ruído e derruba a precisão da resposta.

Como eu corrijo isso:

No momento do chunking, enriqueço cada pedaço de documento com tags de metadados:

  • Data ou ano de publicação (ano: 2024)
  • Tipo de documento (categoria: politica_de_reembolso)
  • Nível de acesso ou departamento

Quando alguém pergunta “qual é a política de reembolso pra assinaturas em 2024?”, o sistema aplica um filtro de metadados antes da busca vetorial, restringindo o pool exclusivamente aos documentos de 2024. Isso elimina de vez o risco de recuperar uma política antiga e desatualizada — que, sinceramente, é um dos piores tipos de erro pra um sistema corporativo cometer.

Passo 4: Reordenamento de Resultados (Reranking)

A busca híbrida entrega uma lista ampla — e às vezes desorganizada — de trechos candidatos. É aqui que entra o Reranker.

Como eu corrijo isso:

O Reranker é um modelo especializado de pontuação que lê a pergunta do usuário contra cada trecho recuperado pela busca híbrida, reavalia a relevância real de cada um, e reordena a lista. O objetivo é simples: garantir que os trechos mais precisos fiquem no topo do contexto que vai ser enviado ao LLM — porque, no fim, o modelo tende a dar mais peso ao que está no começo do contexto.

A Pipeline Ideal: Ordem de Operações

Pra tudo isso funcionar junto, a ordem de execução importa. Essa é a sequência que eu sigo:

EtapaAção na pipelineFunção principal
1. Query CleaningReescrita e clarificação da perguntaTransformar a dúvida do usuário em uma busca precisa
2. Hybrid RetrievalBusca por vetores + BM25Capturar tanto o significado semântico quanto termos exatos
3. Metadata FilteringFiltragem por tags e categoriasReduzir o escopo da busca aos documentos relevantes
4. RerankingReordenamento por pontuação de relevânciaColocar os melhores trechos no topo do contexto do LLM

O Que Eu Realmente Penso

Toda vez que alguém me pergunta “qual modelo eu devo usar pro meu RAG”, eu sinto que a pergunta está um passo adiantada demais. Modelo importa, mas é a última peça da engrenagem — não a primeira.

O que eu aprendi, na prática e apanhando, é que melhorar um RAG não é sobre comprar inteligência maior. É sobre construir uma engenharia de recuperação em camadas, onde cada etapa corrige a falha estrutural da etapa anterior. Query ruim vira busca ruim. Busca ruim vira contexto ruim. Contexto ruim vira resposta ruim — não importa quão caro seja o modelo no final da cadeia.

Fico Com Essa Pergunta

Se o seu RAG está funcionando bem em teste e falhando em produção, eu apostaria que o problema está em uma dessas quatro etapas — bem antes do LLM entrar em cena.

Qual dessas quatro camadas está faltando na sua pipeline hoje? Me conta:

Query rewriting, busca híbrida, filtro de metadados, reranking. Nessa ordem, seu RAG deixa de entregar resposta genérica e passa a operar com precisão corporativa.

Leia Também