RAG virou a resposta automática pra tudo. "Como faço a IA saber sobre meus dados?" — "RAG!". "Como reduzo alucinação?" — "RAG!". E na maioria das vezes está certo — mas RAG também é uma das coisas mais mal-usadas do momento, jogada em problemas que não pedem por ela. Este post é o guia honesto: o que RAG realmente é, quando resolve, e quando você está construindo infraestrutura cara pra nada.
O que é RAG, sem o hype
Um modelo de linguagem sabe o que estava nos dados de treinamento e nada além disso. Ele não conhece os seus documentos internos, o seu catálogo, a política da sua empresa. E o contexto dele é limitado — você não pode simplesmente colar 10 mil páginas na conversa.
RAG (Retrieval-Augmented Generation) resolve isso buscando, na hora da pergunta, os pedaços de informação relevantes e injetando-os no contexto do modelo. O fluxo:
- Você quebra sua base de conhecimento em pedaços (chunks) e gera embeddings — representações numéricas do significado de cada pedaço.
- Guarda esses vetores num banco vetorial.
- Quando chega uma pergunta, você a transforma em vetor e busca os pedaços mais semanticamente próximos.
- Injeta esses pedaços no prompt e o modelo responde com base neles.
O resultado: o LLM responde sobre os seus dados, atualizados, citando a fonte — sem inventar. É "dar ao modelo a cola certa antes da prova".
Quando RAG resolve de verdade
RAG brilha quando você tem muito conhecimento externo, que muda, e que o modelo precisa consultar:
- Base de conhecimento / suporte: centenas de artigos, manuais, FAQs. O agente busca o trecho certo e responde com precisão.
- Documentos que mudam: políticas, catálogos, preços. Como RAG não treina nada, você atualiza o documento e a resposta muda na hora.
- Conhecimento privado: dados da sua empresa que nunca estiveram em nenhum treinamento.
- Necessidade de citar a fonte: RAG sabe de onde tirou a resposta, o que dá rastreabilidade.
Se o seu problema é "a IA precisa responder com base em muitos documentos meus que mudam", RAG é a ferramenta.
Quando NÃO usar RAG (a parte que ninguém fala)
Aqui está o contraponto que economiza meses de trabalho desnecessário:
Se a informação cabe no contexto, não precisa de RAG. Os modelos modernos têm janelas de contexto enormes. Se seu conhecimento é um documento de 20 páginas, coloque no prompt e pronto. RAG pra isso é matar mosca com canhão.
Se a resposta vem de um sistema, use function calling, não RAG. "Qual o status do meu pedido?" não é uma pergunta de busca semântica — é uma consulta a um banco. A ferramenta certa é function calling: o agente chama buscar_pedido(id) e pega o dado exato. RAG buscaria "documentos parecidos com a pergunta", o que é errado pra dado estruturado.
Se você não tem muitos documentos, RAG é over-engineering. Embeddings, banco vetorial, pipeline de ingestão, reindexação — é infraestrutura de verdade. Só vale quando o volume justifica.
A pergunta filtro: minha resposta depende de buscar significado em muitos textos, ou de consultar um dado específico? Se é buscar em textos, RAG. Se é consultar um dado, function calling.
Os detalhes que decidem se o seu RAG funciona
RAG mal-feito é pior que não ter RAG — ele traz o pedaço errado com confiança. O que separa um RAG que funciona:
- Chunking inteligente. Como você quebra os documentos importa mais do que parece. Chunks grandes demais diluem a relevância; pequenos demais perdem contexto. Respeite a estrutura do documento (seções, parágrafos).
- Qualidade do embedding. O modelo de embedding define o que "semelhante" significa. Um bom modelo de embedding é metade da batalha.
- Recuperar o suficiente, não o máximo. Injetar 50 chunks entope o contexto e confunde o modelo. Recupere os poucos mais relevantes.
- Reranking. Uma segunda passada que reordena os resultados por relevância real melhora muito a precisão.
- Avaliar. Se você não mede se o RAG está trazendo os trechos certos, você não sabe se ele funciona. Meça.
A visão de produto
RAG não é um objetivo — é um meio, como toda tecnologia de IA. O erro que eu mais vejo é times construindo um pipeline de RAG elaborado antes de perguntar se o problema pede por isso. Muitas vezes, o que resolve é function calling num sistema, ou simplesmente colocar o documento no contexto. RAG entra quando o conhecimento é grande, textual e mutável — e aí ela é poderosa.
Como sempre: a pergunta certa não é "que técnica de IA da moda vou usar?". É "qual é o problema, e qual a ferramenta mais simples que o resolve?". Às vezes é RAG. Muitas vezes não é. Saber a diferença é o que separa quem entrega de quem só segue hype.
Construo sistemas de IA que resolvem o problema certo com a ferramenta certa — RAG, agentes, integração — em produção. Se você está na dúvida se precisa de RAG, vamos conversar.