O que é RAG (retrieval-augmented generation)?

RAG (retrieval-augmented generation) é buscar trechos relevantes de uma base sua e enviá-los junto com a pergunta ao modelo. A resposta sai do texto que você entregou, não do que o modelo memorizou no treino. São duas fases: uma indexação que roda antes e uma busca que roda a cada pergunta. Serve para responder sobre documento que o modelo nunca viu.

A sigla é literal: geração aumentada por recuperação. O que aumenta é o prompt. Você acrescenta a ele um punhado de passagens que a busca considerou relevantes, e quem monta esse prompt é o seu código. Essa montagem é toda a arquitetura de um RAG: dividir documento em chunks, virar cada chunk em embedding, guardar, buscar, montar.

Nada disso toca os pesos do modelo. O modelo do outro lado não sabe de onde veio o texto que chegou; para ele é só mais contexto.

As duas fases

A indexação roda antes de qualquer pergunta existir. Você lê os documentos, divide cada um em pedaços de algumas centenas de tokens, passa cada pedaço por um modelo de embedding e guarda o vetor resultante junto com o texto original e o metadado que interessa: arquivo de origem, data, permissão, seção. Isso roda uma vez e roda de novo quando um documento muda.

A consulta roda a cada pergunta. Você transforma a pergunta em vetor pelo mesmo modelo de embedding, procura os vetores mais próximos no índice, pega os cinco ou dez melhores, cola o texto deles em um prompt junto com a pergunta e manda para o modelo.

Um detalhe que derruba muita gente na primeira montagem: as duas fases precisam usar o mesmo modelo de embedding. Vetor gerado por um modelo não é comparável com vetor gerado por outro, mesmo que os dois tenham 1.536 dimensões. Trocar o modelo de embedding significa reindexar tudo, e é por isso que essa é a escolha mais cara de reverter no pipeline inteiro.

O índice é a junta entre as duas fases. É por isso que depurar RAG incomoda: um chunk mal cortado na segunda-feira vira uma resposta errada na sexta, e o sintoma aparece a três etapas de distância da causa.

O que a recuperação muda na resposta

Pergunte a um modelo qual é o SLA de resposta do seu plano Pro. Sem nada mais, a resposta vem no formato certo, com a confiança certa e um número que ele reconstruiu do que já viu sobre contratos de SaaS. “24 horas” é uma resposta plausível para essa pergunta em geral. Ela só não é a sua.

Com o parágrafo do contrato no prompt, o modelo lê “quatro horas úteis” e responde isso. Ele não ficou mais inteligente. Ele parou de ter que adivinhar.

O paper que cunhou o termo mediu esse efeito em 2020. Lewis e colegas combinaram um gerador seq2seq com um índice denso da Wikipédia e bateram o gerador puro em três tarefas de perguntas e respostas de domínio aberto; o texto gerado também saiu mais específico e mais factual que o do modelo sem índice¹. A palavra que eles usaram para a diferença foi memória: o modelo tem memória paramétrica, nos pesos, e o índice é uma memória não paramétrica, que você troca sem retreinar nada.

O paper de 2020 e o que virou “RAG” depois

Vale separar as duas coisas, porque o nome ficou e a receita mudou.

O trabalho original treinava o conjunto. O gerador era ajustado junto com o recuperador, e o recuperador vinha de outro paper do mesmo ano, o DPR, que tinha acabado de mostrar que recuperação densa treinada com pares de pergunta e passagem supera BM25 em 9 a 19 pontos absolutos de acurácia no top-20². Era esse resultado que tornava razoável apostar tudo em vetor.

O que se chama de RAG em 2026 quase nunca envolve treino. Você chama uma API de embedding, guarda os vetores em algum lugar, busca e concatena strings. É mais simples, funciona bem o suficiente e herdou o nome de uma arquitetura que fazia outra coisa. A confusão aparece quando alguém lê o paper esperando encontrar o sistema que construiu na semana passada.

O mapa do assunto

Cada caixa é uma decisão com consequência mensurável, e cada uma é um artigo deste cluster.

Indexar decide o tamanho do pedaço e o modelo de embedding. É a etapa mais cara de refazer, porque mudar qualquer uma das duas coisas obriga a reprocessar o corpus inteiro.

Buscar decide se você usa só vetor, só palavra-chave ou os dois. Ranquear decide quantos candidatos sobrevivem à busca e em que ordem eles chegam ao prompt.

Gerar decide o que o prompt final manda o modelo fazer quando o trecho não responde a pergunta. É engenharia de prompts comum, aplicada a um contexto que você mesmo montou.

Avaliar é o que separa as quatro anteriores quando o resultado sai ruim. É a etapa que a maioria dos times monta por último, depois de já ter mexido nas outras no escuro.

RAG, fine-tuning ou só prompt?

As três técnicas colocam informação no modelo em lugares diferentes, e a escolha costuma ser feita cedo demais.

O prompt guarda o que cabe em instrução: formato, tom, regra curta. Os pesos guardam comportamento, que é o que o fine-tuning muda: como responder, em que estilo, com que vocabulário. O índice guarda conhecimento que muda, e é o único dos três em que atualizar significa escrever um documento em vez de rodar um treino.

Na prática elas se combinam mais do que competem, e o critério que decide é a frequência de mudança daquilo que você está tentando ensinar. Qual usar em cada caso é a pergunta que todo time faz na primeira semana, quase sempre sem os números na mão.

Contexto longo não matou o RAG, mudou onde ele compensa

Essa é a discussão do momento e merece ser tratada sem torcida.

O argumento a favor do contexto longo tem evidência. Um estudo de 2024 comparou RAG e contexto longo em vários datasets públicos, com três modelos da época, e achou que, quando os recursos são suficientes, o contexto longo ganha em desempenho médio. A vantagem do RAG no mesmo estudo foi custo, não qualidade. Os autores propuseram rotear cada consulta para um dos dois caminhos, o que ficou perto do desempenho do contexto longo pagando bem menos³.

O argumento a favor do RAG também tem. Modelos não usam a janela de forma uniforme: um trabalho de 2023 mostrou que o desempenho é melhor quando a informação relevante está no começo ou no fim do contexto e cai de forma significativa quando ela está no meio, inclusive em modelos anunciados como de contexto longo⁴. Colar tudo não é neutro. É uma aposta de que o modelo vai achar a agulha, e a posição da agulha importa.

E existe a aritmética, que resolve boa parte dos casos antes da discussão começar. Dez mil páginas de documentação são algo como 6 milhões de tokens. Em julho de 2026, as janelas maiores em produção estão na casa do milhão. Um corpus que cabe na janela é um corpus pequeno, e a maioria dos corpora corporativos não é pequena.

O que mudou de verdade: para uma base pequena e estável, um manual de 40 páginas, uma política interna, colar o texto inteiro virou a resposta certa. É mais simples de construir, não tem índice para manter e não tem busca para errar. RAG deixou de ser a resposta padrão para “o modelo precisa conhecer este documento” e passou a ser a resposta para “o corpus é grande demais para colar, muda com frequência, ou eu preciso saber de qual passagem a resposta saiu”. A linha se move conforme o preço por token cai, e o prompt caching a empurra mais ainda para o lado do contexto longo em base estável. Não é uma fronteira fixa e ninguém deveria vendê-la como fixa.

Onde falha

A busca erra e ninguém percebe. Se o trecho certo não foi recuperado, o modelo responde com o que veio, e responde bem. A resposta tem a mesma cara de uma resposta correta. Este é o modo de falha número um do RAG e o motivo pelo qual é preciso avaliar a busca separada da geração.

Trecho quase certo é pior que trecho aleatório. Um estudo de 2024 encontrou o contrário do esperado: as passagens mais bem ranqueadas que não contêm a resposta prejudicam o modelo, enquanto acrescentar documentos aleatórios chegou a melhorar a acurácia em até 35% no que eles testaram⁵. É um resultado de um arranjo específico de perguntas e respostas, não uma lei geral, mas a implicação prática vale: subir o top-k “por segurança” pode piorar o sistema, porque o que entra a mais é justamente o quase-relevante.

O chunk corta no lugar errado. Uma tabela partida na metade, uma cláusula separada da sua exceção, um item de lista sem o cabeçalho que dizia do que era a lista. A busca funciona, o trecho chega, e o trecho não serve.

O índice envelhece. O documento foi atualizado, o índice não. A atualidade é o principal argumento do RAG e é a primeira coisa que quebra em produção, porque a reindexação é um job que ninguém monitora até o dia em que ele falha calado.

A permissão some no caminho. O índice achata a estrutura de acesso dos documentos. Se você não carrega a permissão no metadado e filtra por ela na busca, o RAG vira um canal de vazamento com interface de chat.

O modelo pode ignorar o trecho. Nada obriga o modelo a usar o que você entregou. Quando o texto recuperado contradiz o que ele aprendeu no treino, o resultado depende de qual dos dois sinais é mais forte, e não existe garantia de que seja o seu.

Quanto custa

Números de ordem de grandeza, para ter noção da forma da conta.

Indexar é um custo de uma vez. Aquelas 10 mil páginas, em chunks de 300 tokens, dão cerca de 20 mil chunks. Embedding é a chamada mais barata do catálogo, ordem de grandeza abaixo da geração, e você paga por ela quando os documentos mudam, não quando alguém pergunta.

Guardar é menos do que parece. Vinte mil vetores de 1.536 dimensões em float32 ocupam cerca de 120 MB. Isso cabe em Postgres com folga, e é a razão pela qual muita gente monta um banco vetorial dedicado antes de precisar.

Consultar é o custo que se repete. Cinco trechos de 400 tokens são 2 mil tokens de contexto por pergunta. Colar 200 mil tokens a cada pergunta custa cem vezes isso, em dinheiro e em latência. A razão entre os dois números é o que decide, não o preço absoluto, que muda toda vez que alguém publica um modelo novo.

Por onde começar

1. Tente sem RAG primeiro. Cole o documento no prompt. Se o corpus cabe na janela e não muda toda hora, você terminou aqui e economizou um sistema.
2. Divida por estrutura antes de dividir por tamanho. Seção, cláusula, função. Corte por número de caracteres só onde não houver estrutura.
3. Comece com busca vetorial pura e top-k de 5. Reranker e busca híbrida resolvem problemas que você ainda não tem.
4. Escreva 30 perguntas reais com a resposta e o trecho que deveria ter sido recuperado. É o instrumento inteiro. Sem ele, toda mudança no pipeline é palpite.
5. Meça a busca antes de medir a resposta. Se o trecho certo não está entre os recuperados, o problema não é o prompt.
6. Mande o modelo citar o trecho e dizer quando não achou. A abstenção precisa estar escrita no prompt; ela não acontece sozinha.

O passo 4 é o que separa quem melhora um RAG de quem troca de framework a cada duas semanas esperando que o próximo resolva.

Footnotes

1. Lewis et al. (2020) cunharam o termo e mediram o efeito: o modelo com índice bateu o gerador puro em três tarefas de perguntas e respostas de domínio aberto e produziu texto mais específico e mais factual. ↩

2. Karpukhin et al. (2020) mostraram que recuperação densa treinada com pares de pergunta e passagem supera BM25 em 9 a 19 pontos absolutos de acurácia de recuperação no top-20. ↩

3. Li et al. (2024) compararam RAG e contexto longo em datasets públicos: com recursos suficientes o contexto longo ganha em desempenho médio, e o RAG ganha em custo. Rotear a consulta entre os dois fica perto do desempenho do contexto longo por uma fração do preço. ↩

4. Liu et al. (2023) mediram a queda de desempenho quando a informação relevante fica no meio do contexto, inclusive em modelos anunciados como de contexto longo. ↩

5. Cuconasu et al. (2024) encontraram que passagens bem ranqueadas sem a resposta prejudicam o modelo, e que incluir documentos aleatórios chegou a melhorar a acurácia em até 35% nos experimentos deles. ↩