RAG

RAG (Retrieval-Augmented Generation) é o padrão de buscar informação relevante em uma base externa no momento da pergunta e injetar essa informação no prompt antes de gerar a resposta. Em uma frase: o modelo deixa de precisar saber e passa a precisar ler. Foi essa simplicidade que tornou RAG a arquitetura default de quase toda aplicação séria com LLM entre 2023 e 2025, e foi também essa simplicidade que, em 2026, virou objeto de revisão honesta. RAG não morreu, mas deixou de ser resposta para tudo. Vale entender por que ele existe, por que continua relevante, e quais primos próximos surgiram nesse meio tempo: GraphRAG, Agentic RAG, CAG, além das três formas distintas de “ensinar” um modelo (system prompt, fine-tuning e continual pretraining), que vivem ao lado de RAG e são frequentemente confundidas com ele.

Por que existe

Há três limitações estruturais de LLMs que motivaram RAG, e elas continuam reais mesmo com tudo que mudou desde então.

A primeira é que o conhecimento de um LLM é congelado no momento do treino. Um modelo cuja cutoff é fevereiro deste ano não sabe nada de março em diante, e atualizar isso significa retreinar: caro, lento, raro. A segunda é que, mesmo dentro do que viu, o modelo alucina: quando não sabe, frequentemente inventa com confiança. Não é maldade nem bug, é a natureza da geração probabilística sem uma fonte ancorada. A terceira, e talvez a mais prática, é que a base de conhecimento que importa para a maior parte das aplicações reais é privada. Documentação interna, contratos, tickets, código proprietário, base de clientes: o modelo nunca viu nada disso. Nem deveria, em muitos casos.

RAG ataca as três de uma vez pelo mesmo mecanismo. Em vez de o modelo saber, ele recebe os documentos relevantes anexados à pergunta e lê. Como os documentos vêm de uma fonte externa que você controla, você pode atualizá-los a qualquer momento (resolve o cutoff), o modelo cita o que está vendo em vez de inventar (reduz alucinação) e a base nunca precisou estar nos pesos (resolve privacidade).

Como funciona, em uma frase

Indexa-se o corpus em uma representação consultável: geralmente embeddings vetoriais, mas pode ser busca textual clássica, ou um grafo, ou um híbrido. Na hora da pergunta, busca-se os trechos mais relevantes, monta-se um prompt que diz algo como “responda usando este contexto: …” e gera-se a resposta. Toda a complexidade de produção mora nos detalhes (chunking, qualidade do retrieval, reranking, avaliação) mas o conceito é esse.

Quando ainda faz sentido em 2026

RAG continua sendo a escolha natural quando o conhecimento relevante é grande, mutável, e privado ou específico demais para estar no modelo. Documentação interna que muda toda semana, base de tickets de suporte com milhões de entradas, jurisprudência, papers científicos de uma área de pesquisa, base de produtos de um e-commerce: qualquer situação em que a resposta precisa ser ancorada em fontes verificáveis e atualizadas é território natural de RAG.

Um segundo caso forte é quando a citação importa. Se a resposta precisa apontar de onde veio cada afirmação (porque você está construindo um produto jurídico, médico, de compliance, ou porque seus usuários precisam confiar no que estão lendo) RAG dá uma estrutura natural para isso. Você sabe quais chunks foram usados, pode mostrá-los ao usuário, e a resposta deixa de ser uma caixa preta.

E há um terceiro caso, menos óbvio: multi-tenancy. Quando cada cliente tem sua própria base e nenhum cliente pode ver o conteúdo de outro, RAG é praticamente obrigatório. Stuffar contexto no prompt não escala quando você tem milhares de bases pequenas, e treinar um modelo por cliente é absurdo.

Quando deixa de fazer sentido

É aqui que a discussão fica mais interessante, porque várias premissas que justificavam RAG no início da década estão erodindo.

A primeira é o tamanho de contexto. Quando o limite era 4k ou 8k tokens, era impensável colocar uma base de conhecimento inteira no prompt. Em 2026, contextos na casa do milhão de tokens viraram commodity, e o custo por token caiu junto. Para bases pequenas ou médias (um manual de produto inteiro, todo o código de um repositório, a documentação completa de uma API) pode ser mais simples e mais correto jogar tudo no contexto e deixar o modelo encontrar o que precisa. Você economiza um pipeline inteiro de embeddings, índice vetorial, retrieval e reranking. Essa observação não é só teórica: virou uma arquitetura batizada de CAG (Cache-Augmented Generation), que vou descrever mais abaixo.

A segunda é o conhecimento estável e pequeno. Se a informação que você precisa injetar cabe em uma página e quase nunca muda (políticas internas, persona do assistente, formato de saída, regras de negócio fixas) isso não é RAG, é system prompt. RAG é overengineering para problemas que se resolvem com um parágrafo no início da conversa.

A terceira é quando a tarefa é raciocínio, não busca. RAG ajuda quando a dificuldade está em encontrar o fato certo, não em combinar fatos. Para problemas de raciocínio matemático, lógico, ou de planejamento, juntar mais trechos de documentação não ajuda, frequentemente atrapalha, porque enche o contexto de ruído que compete pela atenção do modelo. Nessas situações, o ganho vem de modelos com mais capacidade de raciocínio, não de mais retrieval.

A quarta é a chegada de agentes com ferramentas, que ressignificou o que retrieval é. Para informação pública e fresca, um agente que decide quando buscar, o que buscar e itera é frequentemente mais útil do que um RAG sobre um snapshot estático. RAG clássico, visto desse ângulo, é uma forma rígida do mesmo padrão: busca obrigatória antes da geração, sobre um índice fixo, sem possibilidade de reformular. Essa observação levou à popularização do Agentic RAG, também descrito abaixo.

E há finalmente o caso em que o que você quer não é injetar fatos novos, mas mudar como o modelo pensa: estilo, formato, vocabulário, decisões consistentes. Aí o jogo é outro: é fine-tuning, ou em casos extremos continual pretraining. Confundir essas três coisas é uma das fontes mais comuns de RAG mal implementado.

Variantes e parentes próximos

A palavra “RAG” hoje é um guarda-chuva. Vale separar.

Knowledge Graph RAG (GraphRAG)

RAG clássico usa embeddings vetoriais: ele encontra trechos semanticamente parecidos com a pergunta. Isso funciona muito bem para perguntas pontuais (“qual a política de reembolso?”) onde a resposta está em um único chunk, e a similaridade semântica basta para achá-lo.

O problema aparece em perguntas que exigem atravessar relações. “Quais clientes do segmento X compraram o produto Y depois que o vendedor Z entrou na equipe?” não é uma busca por similaridade: é uma travessia de grafo disfarçada de pergunta em linguagem natural. Vector RAG degrada rápido quando o número de entidades envolvidas cresce, porque embeddings tratam o texto como uma nuvem de significado, não como uma rede de objetos identificáveis.

GraphRAG (também chamado de Knowledge Graph RAG) ataca esse problema modelando o corpus como um grafo de entidades e relações. Em vez de, ou ao lado de, buscar chunks semanticamente parecidos, ele faz travessias no grafo: parte da entidade mencionada, segue as arestas relevantes, monta o contexto a partir dessa subrede. Em benchmarks de 2025 e 2026, GraphRAG ganha consistentemente em perguntas multi-hop e em “sensemaking global” (perguntas que exigem síntese de muitos documentos), enquanto vector RAG ainda ganha em perguntas single-hop e de detalhe.

A contrapartida é custo. Levantar um grafo decente exige modelagem de ontologia, pipelines de extração de entidades, e curadoria contínua: semanas a meses, contra dias para subir um pipeline vetorial. É por isso que, mesmo com benchmarks favoráveis, menos de 15% de empresas tinham GraphRAG em produção até 2025. Em 2026 a adoção cresceu, mas a regra prática continua: comece com vector RAG; mude para grafo quando o tipo de pergunta dos seus usuários começar a quebrar consistentemente nas multi-hop.

Agentic RAG

Se RAG clássico é “busca uma vez e gera”, Agentic RAG é “deixa o modelo decidir quando, o quê e como buscar”. Em vez de um pipeline linear, há um loop: o agente lê a pergunta, decide se precisa buscar, formula a query, lê os resultados, critica, reformula se necessário, e só responde quando está confiante (ou quando gastou o orçamento de iterações). Frameworks como LangGraph modelam isso explicitamente como um grafo cíclico de estados, com checkpoints e pontos de interrupção humana.

Em 2026 essa virou a arquitetura padrão para deployments de retrieval em escala enterprise, a ponto de parte da indústria começar a chamar o conjunto de “context architecture” em vez de RAG, sinalizando que retrieval deixou de ser uma feature isolada e virou infraestrutura. O ganho mensurável é grande: combinações de Agentic RAG com knowledge graphs estão derrubando taxas de alucinação em ordem de magnitude em alguns benchmarks de produção.

A contrapartida é complexidade. Você troca um pipeline determinístico (e auditável, e debugável) por um agente que pode entrar em loops, gastar tokens demais, ou tomar decisões opacas. Para muitos casos de uso, RAG clássico continua sendo a escolha certa exatamente por ser previsível.

CAG (Cache-Augmented Generation)

CAG é a aposta oposta de GraphRAG. Onde Agentic RAG adiciona inteligência ao retrieval, CAG diz: pode ser que retrieval nem seja necessário. Com modelos de contexto longo e preços de prompt caching agressivos, ficou viável carregar um corpus inteiro uma única vez em um prompt cacheado e responder cada query consultando esse cache, sem busca alguma. Latência cai a frações de segundo, custo por consulta também, e o pipeline some.

CAG ganha onde o corpus é pequeno, estável, amplamente consultado e compartilhado entre usuários, exatamente onde RAG sempre foi overengineering. RAG continua ganhando onde o corpus é grande, dinâmico, particionado por tenant, ou onde citação granular importa. Em 2026 a leitura madura não é “CAG mata RAG”, e sim “CAG é um par, não um substituto”. Times sérios frequentemente fazem um roteador híbrido: CAG no hot path (perguntas frequentes sobre conteúdo estável), RAG no cold path (perguntas específicas, dados frescos). Quem comprou o discurso “RAG morreu, contexto longo venceu” tipicamente teve que retroportar RAG dentro do quarter seguinte.

Como as três variantes são frequentemente comparadas entre si nas mesmas dimensões, vale uma referência rápida lado a lado:

Variante	O que muda em relação ao RAG clássico	Onde ganha	Custo extra
Vector RAG	(baseline)	Perguntas pontuais, single-hop, detalhe	baseline
GraphRAG	Modela entidades e relações	Multi-hop, sensemaking global	Semanas a meses de ontologia e curadoria
Agentic RAG	Agente decide quando, o quê e como buscar	Reduz alucinação, queries que precisam iterar	Latência variável, dificuldade de debug
CAG	Dispensa retrieval, cacheia o corpus inteiro	Corpus pequeno, estável, compartilhado	Requer contexto longo e prompt caching barato

RAG vs. as outras formas de ensinar um modelo

Talvez o mal-entendido mais caro em projetos de LLM seja tratar RAG, fine-tuning e continual pretraining como alternativas intercambiáveis. Elas resolvem problemas diferentes e operam em camadas diferentes do sistema.

System prompt é onde mora comportamento estático e contexto pequeno. Persona, formato de saída, regras de negócio, instruções gerais. Se cabe em uma página e quase nunca muda, é aqui. Custa nada implementar e é o primeiro lugar para tentar antes de qualquer coisa mais sofisticada.

RAG é onde moram fatos no momento da pergunta. Conhecimento que é grande demais para o prompt, ou que muda com frequência, ou que precisa ser citado. RAG não muda o modelo: muda o que ele tem à disposição para ler. É reversível, auditável, atualizável em tempo real.

Fine-tuning é onde mora comportamento aprendido. Estilo de escrita, vocabulário de domínio, formato consistente em casos repetitivos, decisões padronizadas. Fine-tuning não é para ensinar fatos: é para mudar como o modelo pensa. Tentar usar fine-tuning para injetar conhecimento factual é uma das armadilhas clássicas: o modelo “aprende” os fatos, mas os mistura, esquece, ou alucina variações. Para fatos, use RAG. Para forma, use fine-tuning.

Continual pretraining (também chamado de continued pretraining ou simplesmente retraining em conversas informais) é a versão profunda do fine-tuning. Em vez de ajustar o modelo em um conjunto pequeno de exemplos task-específicos, você continua o pré-treino dele em um corpus grande do seu domínio, milhões a bilhões de tokens não rotulados. Isso faz o modelo internalizar vocabulário, padrões e conhecimento de domínio de um jeito que fine-tuning não consegue. Mas custa caro: o investimento é geralmente da ordem de milhões de dólares e meses de engenharia, e raramente faz sentido fora de domínios muito específicos (biomedicina, código, jurídico em larga escala). Para a esmagadora maioria dos casos, RAG + fine-tuning resolve com uma fração do custo.

As quatro camadas vivem em planos diferentes, e confundi-las custa caro. Vale uma referência side-by-side:

Camada	O que de fato muda	Quando usar	Custo típico
System prompt	Comportamento estático e contexto pequeno	Cabe em uma página e quase nunca muda	~0
RAG	Fatos disponíveis no momento da pergunta	Conhecimento grande, dinâmico, multi-tenant, citação importa	Médio (infra de retrieval)
Fine-tuning	Como o modelo pensa (forma, estilo, decisões)	Forma é o problema, não fatos	Médio-alto (dataset + treino)
Continual pretraining	Conhecimento bakado nos pesos	Domínio próprio, vocabulário próprio, dezenas de milhões de tokens	Muito alto (milhões de US$, meses)

A regra prática de 2026 é a mesma de 2024, só mais clara: comece com prompt direto, suba para system prompt mais elaborado, adicione RAG quando o conhecimento ficar grande ou dinâmico, considere fine-tuning quando comportamento for o problema, e só pense em continual pretraining se você tem dezenas de milhões de tokens proprietários, um domínio com vocabulário próprio, e orçamento para pagar isso.

Diagnóstico: RAG faz sentido no meu caso?

A leitura completa dá o vocabulário, mas a decisão prática frequentemente cai em meia dúzia de eixos: tamanho e estabilidade do corpus, tipo de pergunta, necessidade de citação, e quanto da infraestrutura você está disposto a pagar. O pequeno diagnóstico abaixo cruza essas dimensões e sugere uma direção, não como prescrição, mas como um ponto de partida para validar contra o que você já sabe do seu problema.

Diagnóstico rápido

Cinco perguntas para sugerir qual técnica faz sentido para o seu caso.

O que sobra para RAG

Mesmo com tudo isso (Agentic RAG, GraphRAG, CAG, contextos longos, fine-tuning, agentes com ferramentas) RAG continua no centro de uma classe enorme de problemas: bases grandes, privadas, dinâmicas, multi-tenant, com necessidade de citação. O que mudou é a fronteira de quando vale montar a infraestrutura. Em vários projetos que começam querendo “fazer RAG”, a resposta certa é mais simples: prompt direto com contexto longo, system prompt bem escrito, CAG, ou fine-tuning. Em outros, é mais complexa: Agentic RAG, ou Agentic RAG com grafo por baixo.

A pergunta útil em 2026 não é “vou usar RAG?”, e sim “qual ponto do espectro retrieval × geração resolve esse problema com o menor número de partes móveis?”. RAG clássico é uma coordenada legítima desse espectro, não o ponto default.