O que é RAG? Entenda a geração aumentada por recuperação

A geração aumentada por recuperação (RAG) é uma abordagem em que um sistema busca trechos relevantes em um índice externo de documentos e os envia a um modelo de linguagem antes que ele gere uma resposta. Em vez de depender apenas dos pesos fixados durante o treinamento, o modelo pode responder usando informações privadas, internas ou atualizadas recentemente.

Um modelo de linguagem convencional só conhece o conteúdo dos dados de treinamento até sua data de corte. Se uma pessoa perguntar sobre a política interna de reembolso da sua empresa, uma especificação de API recém-lançada ou um registro de conta atualizado há cinco minutos, o modelo base não tem como saber a resposta apenas de memória. O RAG preenche essa lacuna ao combinar uma etapa de busca com a de geração: primeiro recupera os fatos relevantes e depois gera uma resposta fundamentada no texto recuperado.

O que significa geração aumentada por recuperação?

Geração aumentada por recuperação significa combinar um sistema de recuperação de informações com um modelo de geração de texto para que a resposta seja orientada por documentos externos obtidos no momento da consulta. Em vez de esperar que uma rede neural memorize todos os fatos em seus parâmetros, o RAG trata um índice externo de textos como um livro aberto que o modelo pode consultar antes de responder.

De modo geral, todo fluxo de RAG segue duas fases principais:

1. Recuperar: quando uma pessoa envia um prompt, o sistema transforma a consulta em uma busca em um repositório externo, como um banco de dados vetorial, um índice de busca por palavras-chave ou uma combinação dos dois, e recupera os trechos de texto mais relevantes.
2. Gerar: o sistema insere os trechos recuperados no contexto do modelo junto com a pergunta original, e o modelo de linguagem gera uma resposta com base nesses trechos.

Como o texto de referência é obtido dinamicamente a cada solicitação, é possível atualizar o que o sistema sabe modificando o índice de documentos, sem treinar novamente o modelo subjacente. Por isso, o RAG é uma das abordagens comuns para criar assistentes de suporte, mecanismos de busca em documentação interna e ferramentas de perguntas e respostas especializadas. Ele também aparece em aplicações criativas nas quais equipes usam ferramentas de fluxo de trabalho como AI Studio Video para produção de mídia e APIs de texto para recuperar conhecimento.

Como o artigo sobre RAG de 2020 diferia da abordagem atual?

O termo «geração aumentada por recuperação» vem de um artigo de 2020 de Patrick Lewis e colegas (arXiv:2005.11401), que combinava um modelo sequência a sequência pré-treinado com um índice vetorial denso da Wikipedia. Hoje, desenvolvedores geralmente usam o termo para um pipeline mais simples de construção de prompts. Entender as duas abordagens ajuda a explicar por que o «RAG» é descrito de maneiras um pouco diferentes em artigos científicos e documentação técnica.

A arquitetura de Lewis e colegas de 2020

No artigo original de 2020 e na publicação de pesquisa da Meta AI que o acompanhou, os autores apresentaram os modelos de linguagem como sistemas com dois tipos de memória:

• Memória paramétrica: conhecimento armazenado nos pesos da rede neural, especificamente em um modelo BART sequência a sequência pré-treinado.
• Memória não paramétrica: conhecimento armazenado em um índice vetorial denso externo de artigos da Wikipedia, consultado por um recuperador neural chamado Dense Passage Retrieval (DPR).

Nessa configuração de pesquisa, o recuperador e o gerador foram treinados juntos de ponta a ponta. O artigo apresentou duas formulações de como os trechos recuperados influenciavam a geração:

• RAG-Sequence: o modelo usa os mesmos trechos recuperados para gerar toda a sequência de saída.
• RAG-Token: o modelo pode usar trechos recuperados diferentes para cada token gerado.

Nos testes de perguntas e respostas de domínio aberto apresentados nas tabelas do artigo (arXiv:2005.11401), o RAG-Sequence alcançou uma pontuação de 44.5 Exact Match no teste Natural Questions, superando tanto as referências seq2seq exclusivamente paramétricas quanto as arquiteturas de recuperação e extração avaliadas no estudo.

A abordagem atual de engenharia

No desenvolvimento moderno de aplicações, as equipes raramente treinam um recuperador e um gerador em conjunto. Em vez disso, «RAG» quase sempre se refere a um pipeline executado no momento da inferência, construído com modelos de embedding prontos e APIs de LLM de uso geral:

1. Dividir os documentos em trechos menores, chamados chunks.
2. Converter esses chunks em embeddings vetoriais e armazená-los em um índice.
3. No momento da consulta, recuperar os chunks mais correspondentes.
4. Opcionalmente, reordenar os resultados para melhorar a relevância.
5. Inserir diretamente no prompt os chunks de texto recuperados e pedir ao LLM uma resposta.

Tanto a arquitetura neural de ponta a ponta de 2020 quanto o pipeline atual que insere textos no prompt são chamados de RAG. Na engenharia de software cotidiana, a menos que alguém mencione especificamente o treinamento de um recuperador com um modelo seq2seq, o termo se refere ao pipeline moderno.

Como funciona, passo a passo, um pipeline RAG moderno?

Um sistema RAG em produção divide o trabalho em dois fluxos distintos: um pipeline de ingestão offline que prepara e indexa os documentos e um pipeline de consulta online executado sempre que uma pessoa faz uma pergunta. Guias de arquitetura, como as orientações da AWS sobre geração aumentada por recuperação e o guia de RAG do AWS Generative AI Innovation Center, dividem essas etapas em componentes que podem ser ajustados independentemente.

1. O pipeline de ingestão (indexação dos dados)

Antes que uma pessoa envie um prompt, o sistema precisa tornar os documentos de origem pesquisáveis:

• Carregamento e limpeza de documentos: extrair texto simples e metadados (títulos, URLs, carimbos de data e hora e permissões de acesso) de PDFs, wikis, bancos de dados ou arquivos Markdown, removendo formatação quebrada e elementos repetitivos de página.
• Divisão em chunks: dividir documentos longos em segmentos menores para recuperar apenas os trechos relevantes, em vez de manuais inteiros. Se os chunks forem pequenos demais, perdem o contexto ao redor e interrompem ideias; se forem grandes demais, trazem informações irrelevantes e aumentam o consumo de tokens. As equipes costumam incluir uma pequena sobreposição entre chunks adjacentes para que frases nos limites não percam o sentido.
• Embedding: passar cada chunk por um modelo de embedding para transformar seu texto em um vetor numérico denso que represente seu significado semântico.
• Indexação: armazenar esses vetores, junto com o texto original e os filtros de metadados, em um banco vetorial ou mecanismo de busca híbrido que combine similaridade vetorial e correspondência de palavras-chave, como BM25.

2. O pipeline de consulta (resposta a perguntas)

Quando uma pessoa faz uma pergunta durante a execução, o pipeline de consulta monta o prompt:

• Processamento da consulta e embedding: receber a entrada da pessoa, opcionalmente reescrevê-la ou expandi-la para maior clareza e convertê-la em um vetor com exatamente o mesmo modelo de embedding usado na ingestão.
• Recuperação: pesquisar no índice os chunks cujos vetores estejam mais próximos do vetor da consulta, frequentemente combinando busca semântica, correspondência de palavras-chave e filtros de metadados, por exemplo, para limitar os resultados aos documentos que a pessoa tem permissão para ler.
• Reordenação opcional: passar os chunks candidatos iniciais por um modelo de reordenação cross-encoder, que avalia quanto cada trecho responde diretamente à consulta e reduz a lista aos melhores resultados.
• Montagem do prompt e geração: inserir os trechos mais bem classificados em um modelo estruturado de prompt junto com a pergunta, enviar o conjunto ao LLM e retornar a resposta gerada, muitas vezes com citações que apontam para os metadados das fontes.

Como o RAG se compara a janelas de contexto longas e ao ajuste fino?

RAG, janelas de contexto longas e ajuste fino resolvem partes diferentes do problema de personalização de modelos. Sistemas em produção frequentemente combinam essas opções em vez de tratá-las como excludentes. A escolha adequada depende da necessidade de fatos atualizados, compreensão ampla em uma única sessão ou mudanças no comportamento do modelo.

Dimensão	Geração aumentada por recuperação (RAG)	Janela de contexto longa	Ajuste fino
Objetivo principal	Fornecer fatos relevantes de um acervo grande ou variável a cada consulta	Permitir que o modelo leia muito texto em uma única solicitação	Alterar estilo, tom, formatação ou comportamento em tarefas especializadas
Atualização do conhecimento	Atualizar ou trocar documentos no índice externo	Trocar os documentos originais inseridos no prompt	Reunir novos exemplos e executar outro treinamento
Impacto em tokens por solicitação	Baixo a moderado (apenas os chunks recuperados são enviados)	Alto (todos os documentos permanecem no prompt)	Baixo (o conhecimento ou comportamento fica incorporado aos pesos)
Atribuição de fontes	É simples citar chunks específicos recuperados	Possível, mas mais difícil de localizar em entradas enormes	Difícil; os pesos não registram citações explícitas de documentos
Controle de acesso	Aplicado a cada consulta por filtros de metadados do índice	Deve ser aplicado antes da montagem do prompt	Difícil de isolar; qualquer conteúdo dos pesos pode vazar para qualquer pessoa

RAG versus janelas de contexto longas

Como os modelos modernos oferecem grandes janelas de contexto, pode ser tentador dispensar a recuperação e colar toda a base de conhecimento em cada prompt. Para alguns documentos curtos, isso funciona bem, especialmente com cache de prompts e uma KV cache já preenchida, evitando reprocessar prefixos repetidos desde o início.

Porém, quando o acervo chega a milhares de arquivos, colocar tudo no prompt encontra dois obstáculos:

1. Custo e latência: enviar prompts enormes a cada turno aumenta os gastos com API e o tempo até o primeiro token. Por isso, a recuperação seletiva continua sendo uma das estratégias centrais para reduzir custos de APIs de IA.
2. Degradação da atenção: os modelos não prestam a mesma atenção a todas as partes de um prompt enorme. À medida que textos irrelevantes se acumulam na janela, a precisão frequentemente cai, em um fenômeno conhecido como degradação de contexto. O RAG mantém o prompt focado ao recuperar apenas os trechos importantes para a pergunta atual.

RAG versus ajuste fino

O ajuste fino atualiza os pesos de um modelo com exemplos selecionados. Ele é eficaz quando se deseja que o modelo siga um esquema de saída rigoroso, adote uma voz de marca específica ou aprenda a sintaxe de uma área especializada. É uma forma pouco adequada de ensinar fatos que mudam rapidamente.

O artigo de Lewis e colegas de 2020 (arXiv:2005.11401) demonstrou por que a memória não paramétrica é importante para fatos que mudam, por meio de um experimento de troca do índice em tempo de execução. Os autores testaram o modelo com uma cópia da Wikipedia de dezembro de 2016 e outra cópia da Wikipedia de dezembro de 2018, usando perguntas sobre líderes mundiais que haviam mudado entre essas datas:

• Quando o ano da pergunta coincidia com o do índice, o modelo respondeu corretamente a 70% das perguntas sobre líderes de 2016 usando o índice de 2016 e a 68% das perguntas sobre líderes de 2018 usando o índice de 2018.
• Quando o índice não correspondia às perguntas, a precisão caiu para 12% (índice de 2018 para líderes de 2016) e 4% (índice de 2016 para líderes de 2018).

A simples substituição do índice externo atualizou o conhecimento factual do sistema sobre o mundo sem treinar novamente um único peso do modelo.

Onde o RAG falha?

Adicionar recuperação a um modelo de linguagem reduz suposições sobre assuntos privados ou recentes, mas não elimina alucinações de IA nem garante respostas precisas. Como um sistema RAG tem vários componentes, falhas podem ocorrer tanto na busca quanto na geração:

• Falha na recuperação: se a pessoa formular uma pergunta com termos diferentes dos usados no documento de origem, ou se a divisão separar uma tabela de seu cabeçalho, o recuperador pode não encontrar o trecho que contém a resposta. Quando o chunk correto não chega ao prompt, o modelo trabalha às cegas.
• Documentos com ruído ou desatualizados: a qualidade de um índice depende dos arquivos que ele contém. Se a base de conhecimento tiver as versões de 2023 e 2026 de um guia de integração sem uma filtragem clara das versões obsoletas, o recuperador poderá entregar instruções antigas ao modelo.
• Recuperação excessiva: buscar 25 chunks «por precaução» costuma ter o efeito contrário. Encher o prompt de trechos pouco relacionados dilui a resposta, aumenta a latência e pode provocar degradação de contexto, em que o modelo se distrai com detalhes quase relevantes.
• Injeção indireta de prompt por texto recuperado: se o índice ingerir conteúdo externo não confiável, como e-mails recebidos, páginas públicas ou chamados enviados por usuários, um invasor poderá inserir instruções maliciosas em um documento. Quando o documento for recuperado e colocado no prompt, poderá desencadear um ataque de injeção de prompt que desvia o comportamento do modelo.
• Modelo ignorando ou interpretando mal o contexto: mesmo quando o trecho exato está no prompt, o gerador pode interpretar uma negação incorretamente, misturar dois chunks separados de modo impreciso ou dar prioridade ao conhecimento pré-treinado em vez do texto fornecido quando o trecho recuperado contradiz o conhecimento comum.

Lista de verificação para criar um sistema RAG confiável

Ao levar um protótipo RAG para produção, algumas práticas disciplinadas de engenharia evitam as falhas mais comuns:

• Mantenha o índice atualizado e sem duplicatas: crie pipelines automatizados que removam documentos excluídos, arquivem versões substituídas e associem carimbos de data e hora e URLs de origem claros a cada chunk indexado.
• Recupere menos, mas com mais qualidade: em vez de encher o prompt com dezenas de resultados pouco relevantes, combine busca híbrida (vetor + palavra-chave) com filtros de metadados e um reordenador para enviar ao gerador apenas um pequeno conjunto de trechos informativos.
• Separe claramente o texto recuperado não confiável das instruções de sistema: envolva os chunks recuperados em delimitadores estruturais explícitos, como tags XML ou blocos de documentos identificados, e instrua o prompt de sistema a tratar esses blocos apenas como dados de referência passivos, nunca como comandos executáveis.
• Oriente o modelo a não responder quando faltar contexto: instrua-o a informar claramente quando os trechos fornecidos não contiverem informações suficientes para responder. Uma instrução no prompt não garante que o modelo sempre a cumpra, mas oferece uma alternativa mais clara do que adivinhar em silêncio quando a busca não encontra resultados.

Perguntas frequentes

O RAG sempre precisa de um banco de dados vetorial?

Não. A geração aumentada por recuperação exige apenas uma forma de obter texto relevante antes de chamar o modelo. Embora bancos vetoriais sejam populares para busca por similaridade semântica, muitos sistemas RAG em produção usam mecanismos tradicionais de busca por palavras-chave, como BM25 no Elasticsearch ou a busca de texto completo do PostgreSQL, ou buscas híbridas que combinam palavras-chave e vetores.

O RAG pode impedir completamente que um LLM alucine?

Não. O RAG reduz alucinações causadas por dados de treinamento ausentes ou desatualizados porque fornece o texto de referência diretamente no prompt. Ainda assim, o modelo pode interpretar mal um trecho, combinar incorretamente fatos de dois chunks sem relação ou adivinhar uma resposta quando o recuperador traz documentos irrelevantes.

Devo usar RAG ou ajuste fino para os documentos internos da minha empresa?

Comece pelo RAG se o objetivo for fazer um modelo responder a perguntas sobre documentos internos que mudam com o tempo. O RAG permite adicionar, editar ou excluir arquivos no índice imediatamente e aplicar permissões de acesso por usuário no momento da consulta. O ajuste fino é mais adequado para ensinar formatação, tom ou fluxos de trabalho consistentes.

Fontes

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1