O que é RAG (e quando seu app de IA precisa de um)

TL;DR

Se você está colocando IA num produto e ela inventa resposta ou não conhece os seus dados, o problema quase nunca é o modelo. É que ninguém deu a informação certa pra ele ler na hora de responder. É isso que RAG resolve. RAG (retrieval-augmented generation, ou geração aumentada por recuperação) é uma arquitetura que busca, antes de cada resposta, os trechos mais relevantes da sua base de conhecimento e injeta no contexto do modelo, pra ele responder com informação sua em vez de adivinhar. O trade-off honesto: RAG mal feito não conserta nada. Recuperação ruim vira alucinação com cara de fonte confiável.

A frase que resume tudo: o modelo sabe muito do mundo e nada do seu negócio. RAG é como você conta o resto pra ele.

O que é RAG, afinal

RAG é dar ao modelo acesso ao seu conhecimento na hora da pergunta, sem retreinar nada. Em vez de torcer pra que o LLM “saiba” a sua política de reembolso ou o seu catálogo, você guarda esses documentos, recupera os trechos certos quando alguém pergunta, e cola no prompt. O modelo responde ancorado neles, não na memória vaga do treino.

Um LLM cru é um generalista brilhante e completamente amnésico do seu negócio. Ele leu meio mundo até a data de corte do treino, mas nunca viu o seu banco de dados, o seu contrato, o ticket que o cliente abriu ontem. Existem dois jeitos de ensinar o seu domínio a ele: retreinar o modelo (fine-tuning: caro, lento, e congela o conhecimento no dia em que você treinou) ou mostrar a informação na hora da pergunta. RAG é o segundo caminho, e na maioria dos casos é o certo.

O termo não é moda de ontem. Ele foi cunhado em 2020, num paper da Facebook AI Research (Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”). O que mudou de lá pra cá é que deixou de ser assunto de pesquisa e virou item de primeira necessidade: todo mundo que bota um chatbot ou um agente pra conversar com dado próprio esbarra no mesmo muro.

O modelo é o motor. RAG é o que abastece com o seu combustível.

Se você já leu por aqui sobre context engineering, o que decide se a sua IA escala, RAG é uma peça específica daquilo: a parte de trazer a informação certa da sua base pro modelo. Context engineering é montar a mesa inteira. RAG é como você põe o prato certo na mesa no momento certo.

Como o RAG funciona na prática

Um RAG tem duas fases. Antes, offline, você indexa: quebra os documentos em pedaços, transforma cada pedaço em vetor e guarda. Depois, a cada pergunta, você recupera os pedaços mais parecidos com o que foi perguntado, cola no prompt e deixa o modelo gerar a resposta em cima deles. Indexa uma vez, recupera sempre.

As peças que fazem isso acontecer:

Chunking. Você quebra cada documento em pedaços do tamanho certo. Pedaço grande demais entope o contexto com ruído. Pequeno demais perde o sentido e separa a resposta da pergunta. É a decisão mais chata e mais subestimada do pipeline.
Embeddings. Cada pedaço vira uma lista de números que captura o significado. Embedding é a representação numérica de um texto num espaço onde coisas com sentido parecido ficam perto umas das outras. Por isso “cancelar assinatura” e “encerrar plano” caem no mesmo canto mesmo sem repetir palavra.
Banco de dados vetorial. Guarda os vetores e, dada uma pergunta, devolve os mais próximos. Isso é busca semântica, por significado, não por palavra-chave batida. É o que faz o RAG achar a resposta certa mesmo quando o usuário pergunta com outras palavras.
Reranking. Os primeiros candidatos que o banco devolve nem sempre são os melhores. Um reordenador passa uma segunda régua de relevância e sobe pro topo o que realmente responde. Pular essa etapa é onde muito RAG começa a alucinar.
Aumento e geração. Você monta o prompt final juntando a pergunta com os trechos recuperados, e o modelo responde ancorado neles, idealmente citando de onde tirou. Sem essa âncora, ele volta a adivinhar.

RAG, fine-tuning ou só um prompt gigante?

Três formas de dar contexto ao modelo, três usos diferentes. RAG serve pra conhecimento que muda e precisa de fonte. Fine-tuning serve pra ensinar comportamento, formato e tom, não fato novo. Enfiar tudo num prompt gigante serve pra base pequena e estável. Eu vejo muita gente escolher errado e pagar caro por isso.

RAG quando o conhecimento muda, é grande demais pro prompt, ou você precisa citar a fonte. Catálogo, documentação, base de suporte, política interna. Atualizou o documento, o RAG já responde com a versão nova sem retreinar nada.
Fine-tuning quando você quer mudar como o modelo se comporta: o tom, o formato de saída, seguir um padrão específico. É a ferramenta errada pra ensinar fatos, porque o modelo esquece detalhe e alucina em cima do que foi treinado.
Prompt gigante (contexto longo) quando a base inteira cabe com folga e quase não muda. Parece o mais simples, e é, até a conta de tokens chegar e o modelo começar a perder informação no meio do contexto, respondendo pior justamente porque você deu mais.

Janela de contexto grande não é banco de dados. Reprocessar a base inteira a cada pergunta é o jeito mais caro de não ter RAG.

Na prática, produto sério mistura: RAG pra conhecimento, fine-tuning ocasional pra comportamento, e um prompt enxuto amarrando os dois. O erro é tratar um deles como bala de prata.

Onde o RAG quebra

RAG não é botão mágico. Ele amplifica a qualidade da sua base e da sua recuperação, pros dois lados. Base suja, chunk mal cortado ou embedding fraco produzem resposta errada com aparência de citação confiável, que é o pior tipo de erro que existe: o que engana quem lê.

“Botei RAG e a IA continua inventando.”

Quase sempre é a recuperação, não o modelo. Se o trecho certo não chega no prompt, o modelo preenche a lacuna, e ele preenche com toda a confiança do mundo. Os furos clássicos são poucos e repetidos: chunk que corta a frase no meio, base desatualizada, nenhum reranking, e a pergunta do usuário escrita de um jeito que não casa com como o documento foi redigido. Recuperação ruim não é detalhe. É o produto inteiro.

E tem o limite que nenhum pipeline resolve. RAG em cima de um problema mal definido só erra mais rápido. É a mesma régua de sempre: informação boa em cima de uma tarefa mal especificada é slop com curadoria. Antes de investir em recuperação, saiba exatamente o que o seu app precisa responder e pra quem. Isso é método, e método decide mais que ferramenta. Vale o mesmo princípio de quando a gente fala que todo codebase novo é o seu prompt pro MVP que escala: a base que você dá ao sistema decide o teto do que ele entrega.

Perguntas frequentes sobre RAG

RAG serve pro meu MVP ou é over-engineering?

Depende do que o MVP precisa provar. Se a IA é enfeite e a base cabe num prompt, não monte RAG: é peso morto. Se o produto vive de responder em cima do seu conhecimento (suporte, busca interna, assistente sobre os seus dados) e isso vai pra produção, sim, porque é a recuperação que decide se ele acerta. A régua é a de sempre: o que vai escalar merece engenharia, o que vai pro lixo não.

Dá pra fazer RAG no Postgres ou preciso de banco vetorial dedicado?

Dá, e pra começar quase sempre é a escolha certa. O Postgres com a extensão de vetores aguenta muito mais volume do que a maioria dos MVPs vai ter tão cedo, e mantém tudo num banco só. Banco vetorial dedicado faz sentido quando a escala e a latência apertam de verdade. Trocar depois é um problema bom de ter, e reversível. Não comece pelo mais complexo por medo de um gargalo que talvez nunca chegue.

RAG acaba com a alucinação?

Reduz muito, não zera. RAG ancora a resposta em trechos reais, então o modelo tem menos motivo pra inventar. Mas se a recuperação trouxer o trecho errado, ou nenhum, ele volta a preencher a lacuna sozinho. Por isso reranking, base limpa e a instrução pra dizer “não sei” quando não achar fonte importam tanto quanto o modelo. Alucinação com citação é mais perigosa que alucinação escancarada.

RAG ou fine-tuning: qual eu uso?

Na dúvida, comece por RAG. Ele é mais barato de montar, atualiza na hora e não exige retreinar nada quando o conhecimento muda. Fine-tuning entra quando o problema não é o que o modelo sabe, e sim como ele responde: um formato rígido, um tom específico, um comportamento que o prompt não segura. Os dois convivem. Fato vem do RAG, comportamento vem do fine-tuning.

Quanto custa manter um RAG em produção?

O custo real não é o servidor, é a manutenção da base e da qualidade da recuperação. Indexar é barato. Manter os documentos atualizados, medir se as respostas continuam certas quando a base cresce e ajustar chunking e reranking é o trabalho contínuo que ninguém coloca na conta no começo. RAG parado apodrece: a base envelhece e a resposta piora sem ninguém perceber. Orce a manutenção, não só a montagem.

A recuperação é o que você constrói, o modelo é o que você troca

Quem está esperando o próximo modelo resolver tudo está olhando pro lugar errado. O próximo modelo vem, é melhor, e nivela a capacidade bruta de novo pra todo mundo. O que ele não traz é o seu conhecimento recuperado na ordem certa, com a fonte certa, na hora certa. Isso não vem no peso do modelo. Isso você arquiteta.

RAG bem feito é engenharia sem glamour: chunking, recuperação, reranking, evals que pegam a regressão antes do cliente. É pouco sexy e é exatamente o que separa o app de IA que aguenta uso real do que impressiona na demo e desmorona na segunda semana. Montar essa recuperação com consistência em cada entrega, com gate de aceite e preço travado, é o que uma esteira de engenharia garante quando o produto sai do seu computador e vai pra mão do cliente.

Se a sua IA vai pra produção de qualquer jeito, decida como ela recupera antes de decidir qual modelo ela usa.