RAG (Retrieval-Augmented Generation): definição e funcionamento

O RAG é uma das peças técnicas que alimentam os agentes de IA autônomos de hoje, ao lado da chamada de ferramentas e da memória persistente. A sigla vem de um artigo de pesquisa publicado em maio de 2020 por uma equipe do Facebook AI Research (hoje Meta), com Patrick Lewis à frente. Na época, a constatação era simples: os grandes modelos de linguagem armazenam uma quantidade impressionante de conhecimento em seus parâmetros, mas não conseguem atualizá-lo facilmente, nem apontar com precisão para uma fonte. O RAG propõe uma solução: deixar o modelo buscar a informação em uma base externa no momento de responder, em vez de depender inteiramente de sua memória congelada no treinamento.

Definição detalhada

Retrieval-Augmented Generation, ou geração aumentada por recuperação, designa uma arquitetura que combina duas peças distintas: um mecanismo de busca (retrieval) que procura trechos relevantes em uma base documental externa, e um modelo de geração de texto que redige a resposta final a partir desses trechos. No artigo fundador de Lewis e seus coautores (NeurIPS 2020), o RAG associa uma memória paramétrica (o conhecimento interno do modelo pré-treinado) e uma memória não paramétrica (uma base de documentos consultada em tempo real), para melhorar o desempenho em tarefas que exigem conhecimento preciso.

O consenso em torno dessa definição é amplo: seja na literatura acadêmica, seja em explicações para o público em geral como a da NVIDIA, o RAG sempre volta a essa mesma mecânica em dois tempos, buscar e depois gerar. As divergências dizem respeito principalmente à implementação técnica (tipo de base vetorial, método de divisão dos documentos, número de trechos recuperados), não à definição do princípio em si.

O RAG responde a duas limitações conhecidas dos modelos de linguagem: as alucinações, quando o modelo inventa uma resposta plausível mas falsa, e a obsolescência, quando uma informação mudou desde a data de treinamento do modelo. Ao ancorar a geração em documentos reais e atualizados, o RAG reduz esses dois problemas sem exigir retreinar o modelo.

Como funciona

O fluxo típico de uma consulta RAG segue três etapas. Primeiro, a pergunta do usuário (ou a necessidade de um agente) é transformada em uma busca em uma base documental, geralmente por meio de uma busca de similaridade em representações vetoriais do texto, às vezes combinada a uma busca por palavras-chave clássica. Depois, os trechos mais relevantes retornados por essa busca são injetados no contexto enviado ao modelo de linguagem, além da pergunta inicial. Por fim, o modelo gera sua resposta apoiando-se nesses trechos, idealmente citando ou se alinhando ao conteúdo deles em vez de improvisar.

Essa mecânica se encaixa bem no uso por um agente de IA autônomo: a busca documental pode ser exposta como uma ferramenta que o agente chama sozinho, no momento em que julga precisar dela, em vez de ser acionada sistematicamente antes de cada resposta. É a diferença entre um RAG "estático", conectado antes de cada solicitação, e um RAG "agêntico", em que o modelo decide quando buscar, o que buscar, e se deve buscar de novo caso o primeiro resultado não seja suficiente.

Exemplo concreto com a Atako

A documentação pública da Atako não detalha a arquitetura interna de busca documental usada por seus agentes, portanto não é possível afirmar aqui que a Atako usa RAG no sentido estrito do artigo de Lewis et al. O que está documentado, por outro lado, é o mecanismo mais próximo: cada agente tem uma biblioteca de arquivos compartilhada pela empresa, organizada em pastas, com formatos pré-visualizáveis (Markdown, CSV, JSON, PDF, HTML, imagens, texto, código-fonte). Esses arquivos podem ser compartilhados com um agente para leitura, ou adicionados diretamente em uma pasta dedicada ao agente, por um humano ou pelo próprio agente.

Essa biblioteca de arquivos, combinada à memória persistente de um agente, que sobrevive a reinicializações e pausas, exerce o papel de base de conhecimento externa que o agente pode consultar antes de responder ou agir, o que corresponde em espírito ao princípio do RAG: buscar informação real em vez de depender só do que o modelo memorizou no treinamento. Um agente configurado para suporte ao cliente, por exemplo, pode consultar arquivos de documentação de produto compartilhados em sua pasta antes de responder a um ticket, em vez de adivinhar a resposta.

Erros comuns

Primeira confusão comum: achar que o RAG é um recurso que se ativa com um clique, como um botão em um software. Na realidade, é uma arquitetura, com escolhas técnicas concretas (como dividir os documentos, como indexá-los, quantos trechos retornar) que determinam diretamente a qualidade das respostas.

Segundo erro: pensar que o RAG elimina totalmente as alucinações. Ele as reduz ao ancorar a geração em documentos verificáveis, mas um modelo ainda pode interpretar mal um trecho, ou gerar uma resposta a partir de documentos irrelevantes retornados por uma busca imperfeita. O RAG desloca o risco, não o elimina.

Terceiro erro: confundir RAG com fine-tuning. O fine-tuning modifica o modelo de forma duradoura, retreinando-o com dados específicos; o RAG deixa o modelo intacto e acrescenta a ele uma base externa consultada a cada solicitação, o que é mais rápido de atualizar e geralmente menos custoso.

Por fim, subestimar a importância da qualidade da base documental é um erro clássico. Um sistema RAG conectado a documentos desatualizados, mal estruturados ou incompletos vai produzir respostas de má qualidade, independentemente da potência do modelo de geração usado por trás.