RAG Sozinho Não Resolve Tudo
Três técnicas que multiplicam por 10 a performance das suas buscas de contexto para LLMs
Nos últimos anos, o RAG – Retrieval-Augmented Generation – se consolidou como uma das arquiteturas mais utilizadas para expandir a capacidade dos LLMs com dados externos, estruturados ou não. Ele permite que modelos de linguagem consultem bases de conhecimento dinâmicas e atualizadas, o famoso “contexto”, mesmo sem treinamento adicional.
Na prática, o RAG combina dois componentes principais:
Recuperação de contexto (Retrieval): busca de trechos relevantes com base na pergunta do usuário.
Geração aumentada (Generation): uso de um LLM para gerar respostas com base nesse contexto.
A pipeline básica para criar um sistema RAG é relativamente simples:
Pré-processamento dos documentos
São extraídos os textos de documentos (pdfs, markdown, csv, etc) que são divididos em chunks (pedaços de textos) menores (com ou sem sobreposição, chamado chunk overlap) para facilitar a indexação.Geração de embeddings
Cada chunk é convertido em um vetor numérico por um modelo de embedding (vários vendors provêem modelos de Embedding, como a OpenAI, Cohere, HuggingFace, etc).Armazenamento vetorial (Vector Store)
Os vetores são salvos em uma VectorStore (Chroma, FAISS, Weaviate, etc), que é um banco de dados que permite buscas por similaridade.Consulta
Quando o usuário faz uma pergunta, essa pergunta também é convertida em embedding.Recuperação (Retrieval)
O sistema (usando um modelo de Retrieval) busca os vetores mais relevantes à pergunta, extrai os textos e adiciona ao prompt (adição de contexto).Geração com LLM
Esses trechos são enviados como contexto para a LLM, que então gera uma resposta priorizando as informações do contexto.
Essa abordagem tem sido aplicada em diversos casos de uso reais:
Chatbots sobre documentação técnica
Assistentes jurídicos e compliance
Soluções fiscais e financeiras com base em normas
Sistemas de atendimento inteligente
Apoio clínico em guidelines médicos
Análise e explicação de relatórios empresariais
Em muitos cenários, o RAG transforma um LLM generalista em um assistente contextualizado especialista no assunto.
Entretanto, ele não resolve tudo sozinho.
Essa pipeline básica é limitada. Ela recupera o que parece relevante, mas não garante que o que vai para o LLM seja de fato o mais útil, deixando brechas para vários problemas.
O Problema da RAG “Crua”
Implementar uma pipeline RAG básica pode ser relativamente simples – poucos passos, algumas ferramentas prontas, e pronto: você tem um chatbot que responde perguntas a partir de documentos.
O problema?
A verdade é que muitas vezes, ele responde mal.
Mesmo com embeddings decentes e uma base de conhecimento bem estruturada, essa versão "crua" do RAG apresenta uma série de limitações que comprometem seriamente a qualidade da resposta.
Vamos decompor os principais gargalos dessa abordagem simples:
Recuperação rasa (retrieval por similaridade):
A busca vetorial retorna os chunks mais parecidos com a pergunta, não necessariamente os mais relevantes para respondê-la.
Trechos vagos ou redundantes podem ser priorizados.
Evidências realmente importantes podem ficar de fora.
Respostas factualmente incorretas podem parecer convincentes.
Chunking ruim = contexto quebrado:
A divisão dos documentos em chunks fixos (ex: 500 tokens com 50 de overlap) é fácil de implementar, mas raramente respeita a semântica do texto. Isso gera:
Frases cortadas no meio.
Perda de coesão e significado.
Trechos que isoladamente não fazem sentido.
Contexto demais = ruído no prompt:
Ao recuperar N chunks (normalmente 3 a 10) e jogar todos direto no prompt, você está:
Diluindo a relevância do contexto.
Aumentando o custo de tokens sem ganho real.
Sobrecarregando o LLM com informações pouco conectadas.
Tudo fica dependente do embedding:
Se o embedding não capturar nuances da pergunta (e isso acontece com frequência), a busca falha. Mesmo com vetores “semelhantes”, a semântica real da pergunta pode se perder.
Resultado?
Respostas genéricas, alucinações e um sistema que “parece” inteligente, mas erra nas perguntas que realmente importam, não consegue lidar com encadeamento de ideias, ambiguidades e deixa de fora o contexto realmente importante.
Como Saber se Seu RAG Precisa de Otimização: Os Sintomas
À primeira vista, sua pipeline RAG pode parecer estar funcionando bem. O modelo responde, os dados estão sendo buscados, e o chat flui.
Mas aos poucos, você começa a notar alguns sintomas estranhos. As respostas não batem com a realidade, o contexto parece ser ignorado, ou o sistema “trava” em perguntas simples, perguntas que parecem diretas trazem respostas incrivelmente complicadas.
Esses são sinais claros de que sua RAG precisa de otimização.
Siga esse checklist — se você identificar dois ou mais no seu sistema, já está na hora de revisar a arquitetura.
[ x ] Respostas vagas, genéricas ou óbvias.
Usuário: "Quais documentos são exigidos para abrir conta jurídica?"
RAG Responde: "Os documentos exigidos podem variar conforme o tipo de empresa."
[ x ] Alucinações dentro do assunto dos documentos.
Usuário: "Qual o comando para ativar o backup incremental no sistema X?"
RAG Responde: "Use--enable-incremental-backup
no terminal."
Esse comando não está certo, mas o comando certo existe nos documentos.
[ x ] Citações fora de contexto ou imprecisas.
Usuário: "A partir de qual valor é obrigatória a retenção de ISS?"
RAG Responde: "De acordo com o artigo 3.2, a retenção é obrigatória para todos os serviços."
Mas o artigo 3.2 se refere à isenção para MEIs.
[ x ] Partes importantes ignoradas
Usuário: "Qual a penalidade por quebra contratual antes de 6 meses?"
RAG Responde: "A penalidade por quebra contratual é de 10%."
Mas no contrato há uma cláusula que muda a penalidade se o prazo for inferior a 6 meses.
[ x ] Inconsistência em perguntas parecidas
Usuário A: "Quanto tempo leva a homologação de fornecedor?" → "Aproximadamente 5 dias úteis."
Usuário B: "Qual o prazo de aprovação de novo parceiro?" → "Até 15 dias úteis."
3 Técnicas que Transformam sua Pipeline RAG
Uma pipeline RAG básica cumpre o papel de colocar um LLM em contato com um banco de dados externo. Porém, como vimos anteriormente, esse modelo simples sofre com respostas genéricas, irrelevantes ou até alucinações perigosas.
Felizmente, existem técnicas já adotadas em sistemas de produção que resolvem grande parte desses problemas. Abaixo, detalho três otimizações fundamentais que transformam um RAG “cru” em um assistente confiável e com performance real.
1. Re-ranking: priorizando qualidade, não apenas similaridade
Na pipeline RAG padrão, os chunks retornados pelo vector store são os mais similares em embedding à pergunta. O problema é que “parecido” não é sinônimo de “útil”.
Com re-ranking, esses resultados são reordenados com base em sua relevância real para a pergunta, muitas vezes com um segundo modelo especializado (como o Cohere Rerank
, BGE-Reranker
, ou até o próprio LLM em modo de avaliação).
Vantagens:
Reduz drasticamente respostas vagas.
Melhora a precisão das informações recuperadas.
Permite retornar menos contexto, mas com mais densidade informacional.
Entende ambiguidade dentro dos documentos.
Pipeline:
Pergunta do usuário
↓
Geração do embedding da pergunta
↓
Busca vetorial (retrieval) — retorna N chunks mais similares
↓
Re-ranking dos resultados — reordena com base em relevância
↓
Seleciona os top K mais relevantes
↓
Envia para o LLM como contexto
↓
Geração da resposta
2. Re-retrieval: melhoramento da query antes de gerar resposta final
Na pipeline simples, a busca acontece uma vez, antes da entrada do LLM. Mas isso ignora o poder do modelo para ajudar na formulação de perguntas melhores.
Com re-retrieval, o sistema permite retrabalhar a consulta, expandir a pergunta original, ou até lançar novas buscas com base no raciocínio parcial do LLM.
Isso pode ser feito em dois formatos:
Iterativo: o LLM examina o que foi retornado, decide que não é suficiente e tenta uma nova busca.
Guiado por expansão de query: o sistema reformula a pergunta com termos mais precisos antes de buscar.
Vantagens:
Melhora a cobertura de dados relevantes.
Resolve perguntas ambíguas ou mal formuladas.
Permite criar pipelines adaptativas, que “insistem” até encontrar.
Pipeline:
Pergunta do usuário
↓
Geração do embedding da pergunta
↓
Primeira busca vetorial (retrieval 1)
↓
Análise pelo LLM — ele avalia se a evidência é suficiente
↓
Se necessário: reformula a query ou gera variantes
↓
Nova(s) busca(s) vetorial(ais) (retrieval 2, 3...)
↓
Combina e organiza os chunks relevantes
↓
Envia o contexto final para o LLM gerar a resposta
3. Compressão semântica: mais conteúdo, menos tokens
Mesmo com re-ranking e re-retrieval, há um limite físico: o tamanho do prompt. Grandes bases geram muitos chunks úteis, mas é inviável enviá-los todos para o LLM.
Com compressão semântica, o conteúdo é reduzido com inteligência, mantendo os elementos informativos e descartando redundâncias, introduções, e ruído.
Isso pode ser feito com modelos especializados ou com LLMs que transformam os trechos recuperados em sumários orientados por pergunta.
Vantagens:
Reduz custo de tokens.
Aumenta a densidade informacional do prompt.
Permite “encaixar mais conteúdo útil” sem extrapolar o limite do modelo.
Exemplo prático:
Recuperar 5 cláusulas longas de contrato pode consumir 3000 tokens. Com compressão, o mesmo conteúdo cabe em 700, focando apenas nos termos, condições e penalidades específicas.
Como fica a pipeline com compressão semântica?
Pergunta do usuário
↓
Geração do embedding da pergunta
↓
Busca vetorial — retorna N chunks relevantes
↓
Compressão semântica dos chunks recuperados — gera resumos compactos
↓
Concatenação dos resumos comprimidos em um contexto menor
↓
Envio do contexto comprimido para o LLM
↓
Geração da resposta
A compressão pode ser feita com técnicas como:
Modelos LLM que fazem summarization orientado à pergunta.
Algoritmos que extraem os pontos principais, descartando exemplos, explicações longas e redundâncias.
Ferramentas específicas para compressão de contexto, como
RefineDocumentsChain
eContextCompressor
do LangChain e LlamaIndex.
É Possível Combinar? Quando Usar Cada Uma?
As três técnicas — re-ranking, re-retrieval e compressão semântica — podem e devem ser combinadas para extrair o máximo desempenho de pipelines RAG.
Como combiná-las?
Re-ranking sempre acontece logo após a primeira busca vetorial, para garantir que você passe para o LLM os trechos mais relevantes, evitando ruído e informações irrelevantes.
Re-retrieval pode ser acionado quando o sistema detecta que a evidência inicial é insuficiente ou inconclusiva, permitindo iterar e refinar a busca para respostas mais precisas.
Compressão semântica é aplicada antes de enviar o contexto ao LLM, especialmente quando a soma dos trechos relevantes excede o limite de tokens permitido.
Quando usar cada uma?
Use re-ranking sempre, pois ele melhora a qualidade da evidência com pouco custo adicional.
Use re-retrieval em sistemas que lidam com perguntas complexas, ambíguas ou que exigem múltiplas etapas de raciocínio.
Use compressão semântica quando sua base de dados for grande, os trechos recuperados forem extensos e houver limite rígido de tokens no modelo.
A combinação das três técnicas cria uma pipeline iterativa, eficiente e robusta, capaz de entregar respostas precisas e contextualizadas, mesmo em bases volumosas e perguntas complexas.
Conclusão: O Essencial sobre RAG Otimizado
RAG é poderoso, mas não é mágico.
A pipeline básica (embedding → retrieval → geração) funciona, mas apresenta várias limitações em uso real.Os principais sintomas de um RAG mal otimizado incluem:
Respostas vagas, alucinações, inconsistência entre perguntas similares, falhas em perguntas compostas e sensibilidade exagerada à forma da pergunta.Re-ranking melhora a qualidade da evidência.
Reordena os trechos retornados para priorizar os mais relevantes, e não apenas os mais parecidos.Re-retrieval permite raciocínio iterativo.
O LLM participa da busca, reformulando queries ou solicitando novas buscas.Compressão semântica reduz ruído e custo.
Condensa os chunks recuperados para manter só o que importa dentro do limite de tokens.As técnicas são complementares.
Quando usadas em conjunto, elas formam uma pipeline muito mais confiável, eficiente e precisa — pronta para ambientes de produção.RAG sem otimização é só um MVP.
Para construir agentes úteis de verdade, é preciso investir em engenharia, refinamento e entrega do contexto.