O que é RAG (e onde ele termina e a memória começa)

RAG não é memória. Memória não é RAG. E confundir os dois quebra o seu agente — começando pela conta no fim do mês.

Esse erro é mais comum do que parece. O dev joga o histórico de conversa, o perfil do usuário e a base de documentos tudo no mesmo balaio, chama de "memória do agente", e acha que resolveu. Aí o agente esquece o que foi decidido na semana passada, repete pergunta que já foi respondida, e a fatura de tokens explode porque você está recuperando 8 mil tokens de documento a cada turno pra responder "oi".

Então vamos botar ordem nisso. Este é o primeiro de uma sequência sobre RAG aqui no blog, e ele responde a pergunta de base: o que é RAG, como ele funciona por dentro, e onde exatamente ele termina e a memória começa. Sem isso, qualquer coisa que você construir em cima vai ter rachadura na fundação.

TL;DR

• O que é: RAG (Retrieval-Augmented Generation) é dar ao modelo acesso a uma base externa de conhecimento na hora da pergunta, em vez de depender só do que ele decorou no treino.
• Stack típica: um modelo de embeddings, um vector database (pgvector, Pinecone, Qdrant), e o LLM que gera a resposta.
• Pra que serve: responder com base em fatos atuais e específicos do seu domínio — documentação, políticas, catálogo — sem retreinar nada.
• O que NÃO é: não é memória do usuário, não é fine-tuning, e não é mágica que conserta um modelo ruim.
• Paper original: Lewis et al., 2020 — Meta AI / FAIR.

O que é RAG, afinal

RAG é uma sigla feia para uma ideia simples: antes de o modelo responder, você busca informação relevante numa fonte externa e cola essa informação no prompt.

O termo nasceu num paper de 2020 do Patrick Lewis e equipe, na Meta AI, apresentado na NeurIPS. A sacada deles foi combinar duas formas de memória: a paramétrica — o que o modelo aprendeu nos pesos durante o treino — com uma não-paramétrica — uma base de documentos que ele consulta na hora. No paper, era a Wikipedia inteira indexada. Na sua empresa, é a base de conhecimento que ninguém documentou direito.

Por que isso importa? Porque o modelo sozinho tem dois problemas crônicos. Ele alucina quando não sabe — inventa com confiança. E ele tem data de corte: o que aconteceu depois do treino simplesmente não existe pra ele. O paper mostrou que modelos com RAG geram linguagem mais específica, diversa e factual do que o mesmo modelo sem acesso à fonte externa.

Traduzindo pro seu produto: em vez de fazer o modelo decorar o manual do seu produto (caro, lento, desatualiza), você deixa o manual numa base e o modelo consulta quando precisa. O conhecimento fica fora do modelo. Você atualiza um documento e a resposta muda no próximo segundo, sem retreinar nada.

Como o RAG funciona por dentro

RAG não é um botão. É um pipeline com duas fases, e entender a separação entre elas é o que te salva de muita dor depois.

A fase de ingestão roda offline, antes de qualquer pergunta. Você pega seus documentos, quebra em pedaços (os famosos chunks), transforma cada pedaço em um vetor com um modelo de embeddings e guarda esses vetores num vector database. É a sua biblioteca, indexada por significado.

A fase de recuperação roda em tempo real, a cada pergunta. A pergunta do usuário vira vetor com o mesmo modelo de embeddings, você busca os pedaços mais parecidos na base, pega os melhores e cola no prompt antes de chamar o LLM.

# Ingestão (offline, roda uma vez por documento)
chunks = split(documento, tamanho=800)          # 512-1024 tokens é o baseline de produção
for chunk in chunks:
    vetor = embed(chunk)
    vector_db.insert(vetor, chunk)

# Recuperação (runtime, roda a cada pergunta)
vetor_pergunta = embed(pergunta_do_usuario)
trechos = vector_db.search(vetor_pergunta, top_k=5)   # os 5 mais parecidos
prompt = f"Contexto:\n{trechos}\n\nPergunta: {pergunta_do_usuario}"
resposta = llm.generate(prompt)

Três parâmetros decidem se o seu RAG é bom ou lixo. O tamanho do chunk — quebrar no meio de uma frase destrói o significado e nenhum embedding salva isso. O top-k — quantos trechos você recupera (5 a 10 é o comum); poucos e falta contexto, muitos e você enche o prompt de ruído e paga por isso. E o reranking — uma segunda passada que reordena os trechos por relevância real antes de mandar pro modelo, jogando o lixo fora na última curva.

A busca aqui é por similaridade, não por verdade. O vector database te devolve o que é mais parecido com a pergunta, não o que é mais correto. Guarda essa frase. Ela é a chave da próxima seção. (E sim, RAG sério não é só vector search — tem busca híbrida, SQL e reranker na jogada, como mostramos em RAG não é só vector search.)

RAG vs memória: por que não são a mesma coisa

Aqui mora a confusão que quebra agente.

RAG e memória respondem perguntas diferentes. A documentação do Amazon Bedrock AgentCore resume isso melhor do que ninguém: a memória de longo prazo responde "quem é o usuário e o que aconteceu antes". O RAG responde "o que as fontes confiáveis dizem agora".

São eixos diferentes. Memória é sobre estado e continuidade — as preferências do usuário, as decisões que vocês tomaram, o que ele já te contou. RAG é sobre conhecimento factual e atual — o que está escrito na sua base de documentos neste momento.

E por que você não pode usar RAG como memória? Por três motivos estruturais, e nenhum deles é detalhe:

1. RAG é read-only. Ele recupera, mas não atualiza, não sobrescreve, não apaga. Memória precisa mudar a cada interação. Um índice vetorial não foi feito pra isso.
2. RAG recupera por similaridade, não por verdade. Se o usuário mudou de ideia ontem, a base ainda devolve as duas versões com a mesma confiança — a antiga e a nova são igualmente "parecidas" com a pergunta. RAG não sabe qual é a verdade atual.
3. RAG não tem noção de tempo. "O que a gente decidiu semana passada?" não tem resposta confiável num pipeline RAG puro, porque o índice não tem conceito de sequência ou de recência. Pra ele, tudo aconteceu ao mesmo tempo: nunca.

Então pensa assim: RAG é um componente de um sistema de memória, não um substituto pra ele. Você usa memória pra lembrar que o cliente é o João, que ele prefere resposta curta e que cancelou o plano premium. E usa RAG pra puxar a política de cancelamento atualizada da base. Os dois juntos: o agente é familiar e factualmente correto. Um sem o outro, ele é ou um estranho bem informado, ou um amigo que inventa fato.

RAG vs fine-tuning: também não é a mesma briga

Outra dupla que vive confundida. A diferença é onde o conhecimento mora.

No fine-tuning, você ajusta os pesos do modelo. O conhecimento — ou melhor, o comportamento — entra dentro do modelo. No RAG, o modelo não muda; você aumenta o prompt com dado externo na hora da pergunta. Conforme Red Hat e IBM colocam, RAG injeta conhecimento sem tocar no modelo; fine-tuning grava no próprio modelo.

Na prática, a regra de bolso é essa:

• Use RAG quando o que você precisa é conhecimento que muda — documentação, preços, políticas, catálogo. É mais barato, e você atualiza adicionando documento na base, sem retreinar.
• Use fine-tuning quando o que você precisa é comportamento consistente — um tom de voz específico, um formato de saída rígido, jargão de um domínio fechado. Isso é difícil de fazer só enfiando exemplo no prompt.

E não, não é "ou um ou outro". O setup mais maduro combina os dois: fine-tuning ensina o modelo a falar do jeito certo, RAG dá a ele os fatos certos na hora. Estilo vem dos pesos, verdade vem da recuperação. Já destrinchamos essa arquitetura híbrida com benchmark em RAG + fine-tuning juntos.

RAG na prática: onde ele brilha e onde te queima

RAG resolve muito. Mas tem armadilha, e quem ignora paga caro — às vezes literalmente.

Garbage in, garbage out continua valendo. RAG não conserta base ruim. Se sua documentação está desatualizada, contraditória ou incompleta, o RAG vai recuperar lixo com a maior confiança e o modelo vai responder lixo formatado bonito. A qualidade da resposta tem teto na qualidade da base.

O chunking mal feito mata silenciosamente. Quebra de chunk no meio de uma tabela, de um passo de tutorial ou de uma cláusula de contrato, e a recuperação devolve metade da informação. O usuário recebe uma resposta que parece completa e está pela metade. Esse é o bug que ninguém vê até o cliente reclamar.

Custo de token é real. Cada pergunta agora carrega os trechos recuperados no prompt. Top-k alto, chunk grande, e de repente cada turno custa 10x o que custaria sem RAG. Recuperar bem é recuperar pouco e certo, não muito e por garantia. É aqui que a confusão entre RAG e memória aparece na fatura: gente recuperando histórico de conversa via RAG, turno após turno, quando isso era pra estar numa janela de memória barata.

Similaridade não é relevância. Dois textos podem ser vetorialmente parecidos e responder coisas opostas. Sem reranking e sem um threshold de corte, você recupera o trecho parecido-mas-errado e o modelo acredita nele.

FAQ rápido

RAG resolve alucinação de vez? Reduz bastante, não zera. RAG dá fonte ao modelo, mas se a fonte recuperada estiver errada — ou se o modelo ignorar a fonte e responder de cabeça — a alucinação volta. Aterrar a resposta na fonte (e citar de onde veio) ajuda a auditar.

Preciso de um vector database caro pra começar? Não. Pra começar, pgvector no Postgres que você já tem em produção resolve a maioria dos casos. Vector DB dedicado é otimização pra escala, não pré-requisito.

RAG funciona com qualquer modelo? Funciona, mas o modelo precisa de janela de contexto suficiente pra caber os trechos recuperados e capacidade de seguir instrução pra usar o contexto em vez de inventar. Modelos atuais dão conta tranquilo.

Quando RAG é overkill? Quando a base é pequena e estável o bastante pra caber no prompt do sistema. Se são duas páginas que mudam uma vez por ano, cola no prompt e pula a infra inteira de RAG. Engenharia é escolher o suficiente, não o mais sofisticado.

Fechando: RAG é uma peça, não o sistema

Resumindo o que importa. RAG é recuperar conhecimento externo e atual na hora da pergunta — ótimo pra fato, péssimo pra estado. Memória é lembrar quem é o usuário e o que rolou — e isso é outro componente, com outras regras. Fine-tuning é moldar comportamento nos pesos — outra ferramenta ainda. Confundir os três é como usar chave de fenda pra martelar: até vai, até quebrar.

O próximo salto do dev não é "saber usar RAG". É saber arquitetar o sistema inteiro: o que vai pra memória, o que vai pra recuperação, o que vai pros pesos, e como essas peças conversam sem estourar latência nem custo. É exatamente esse tipo de decisão de arquitetura que a gente coloca na mesa, com código rodando, no Workshop Arquitetando Soluções de IA — como desenhar soluções de software com agentes de IA de verdade, não slide de hype.

Nos próximos posts dessa sequência a gente desce pro detalhe: chunking que não quebra significado, escolha de embeddings, reranking, e como medir se o seu RAG está realmente recuperando o que importa. Se quiser RAG na prática agora, com código de produção, o guia de RAG para devs backend com pgvector em Laravel já está no ar. Porque agora que você sabe onde o RAG termina, dá pra construir o que vem depois sem rachadura na fundação.