O que é a Geração Aumentada por Recuperação (RAG)?

Como funciona o RAG

O RAG combina dois componentes: um retriever que localiza trechos relevantes e um gerador (o LLM) que lê esses trechos e produz uma resposta. Patrick Lewis e seus coautores apresentaram a arquitetura na NeurIPS 2020, combinando um modelo seq2seq pré-treinado (memória paramétrica) com um índice vetorial denso da Wikipédia acessado por meio de um retriever neural (memória não paramétrica). Seu artigo relatou que o RAG produz resultados “mais específicos, diversificados e factuais” do que uma linha de base exclusivamente paramétrica (Lewis et al., Geração Aumentada por Recuperação para Tarefas de PLN com Intenso Uso de Conhecimento (NeurIPS 2020), arXiv 2005.11401, 2020).

Durante a execução, o pipeline funciona em três etapas. Primeiro, a consulta do usuário é codificada em um vetor e comparada a um repositório de documentos pré-indexado para identificar as passagens mais relevantes. Em segundo lugar, essas passagens são anexadas à janela de contexto do modelo como entrada adicional. Em terceiro lugar, o LLM gera uma resposta que combina seu conhecimento paramétrico com as evidências recuperadas.

O repositório de documentos costuma ser um banco de dados vetorial: um sistema que armazena representações de alta dimensão de trechos de texto e permite uma pesquisa rápida por vizinho mais próximo aproximado. Os bancos de dados vetoriais que servem de base para aplicações RAG cresceram 377% em relação ao ano anterior, o crescimento mais rápido entre todas as categorias de tecnologia relacionadas a LLM monitoradas (Databricks, Situação dos Dados e IA (Adoção Corporativa e Tendências de Crescimento), 2024).

Por que o RAG se tornou a abordagem padrão para o aterramento

Os LLMs congelam seu conhecimento ao final do pré-treinamento. Qualquer fato que se altere após esse ponto de corte — seja um preço, uma regulamentação ou uma especificação de produto — requer uma nova rodada de treinamento ou uma camada de recuperação. O RAG lida com isso de maneira econômica. Em vez de treinar novamente, basta atualizar o repositório de documentos, e o modelo cita automaticamente as informações atuais na próxima vez que uma consulta relevante for feita.

A adoção pelas empresas reflete essa praticidade. A abordagem RAG tornou-se a principal estratégia para fundamentar os LLMs em dados proprietários ou atuais, com a adoção subindo para 51% das empresas em 2024, ante 31% no ano anterior (Menlo Ventures, 2024: A situação atual da IA generativa nas empresas, 2024).

Uma segunda vantagem é a auditabilidade. Como os documentos recuperados fazem parte da janela de contexto, um desenvolvedor pode verificar quais trechos o modelo utilizou e rastrear as afirmações até sua fonte. Isso é difícil ou impossível com um modelo puramente paramétrico.

Bases de conhecimento corporativas. A documentação interna, os documentos jurídicos e o conteúdo de suporte sofrem alterações frequentes. Um pipeline de RAG indexa esses documentos e permite que funcionários ou clientes os consultem em linguagem natural, sem precisar aguardar o próximo ajuste fino do modelo.

Dados da web em tempo real para agentes de IA. Os agentes de IA precisam de informações atualizadas, páginas de produtos, notícias e resultados de pesquisa — dados que nenhum corpus estático pode fornecer. Inserir conteúdo da web em tempo real na camada de recuperação proporciona ao agente um contexto preciso e atualizado. A Web Render API da Massive pode servir como a camada de fonte de dados da web atualizados neste contexto: o endpoint de pesquisa retorna resultados de pesquisa renderizados (incluindo visões gerais de IA por meio de awaiting=ai), e o endpoint “Browsing” retorna HTML ou Markdown sem formatação a partir de qualquer URL pública; ambos são formatos adequados para segmentação e incorporação em um pipeline de RAG.

Código e documentação da API. As APIs das bibliotecas mudam a cada lançamento. A aplicação de RAG a um corpus de documentos versionado permite que um assistente de programação cite a assinatura correta do método para a versão em uso, em vez de apresentar uma desatualizada.

Automação do atendimento ao cliente. Os bots de suporte baseados em um catálogo de produtos ativo, um documento de política de devoluções e um feed de problemas conhecidos respondem com precisão e citam a política pertinente, reduzindo o número de escalamentos.

O tamanho do bloco é importante. Blocos muito pequenos perdem o contexto; blocos muito grandes diluem o sinal relevante. A maioria dos profissionais começa com blocos de 256 a 512 tokens, com uma sobreposição de 10% a 20%, para evitar a divisão no meio de um pensamento.

Limpe primeiro seus documentos de origem. Texto padrão, texto de navegação e anúncios em uma página recuperada geram embeddings ruidosos e prejudicam a qualidade das respostas. Se você extrair conteúdo da web em tempo real, analise-o para convertê-lo em Markdown limpo ou texto simples antes de indexá-lo.

Avalie a recuperação e a geração separadamente. Uma resposta insatisfatória pode ser resultado de uma recuperação inadequada (o documento correto não foi retornado) ou de uma geração inadequada (o modelo ignorou um documento válido). Manter métricas separadas para cada etapa ajuda a identificar e corrigir o componente correto.

Atualize o índice em um intervalo que corresponda às taxas de alteração da fonte. Um catálogo de produtos que é atualizado diariamente precisa ser reindexado diariamente. Um corpus jurídico que é atualizado trimestralmente pode ser reindexado com menor frequência. Documentos desatualizados no repositório de recuperação são uma fonte comum de erros de RAG.

Fique atento aos limites da janela de contexto. Cada trecho recuperado consome tokens. Com muitas passagens, é possível que você exceda a janela de contexto do modelo ou dilua o sinal. Uma solução prática consiste em reclassificar os trechos recuperados por relevância e manter apenas os três a cinco primeiros.

O RAG aborda o modo de falha de produção mais comum em LLMs: respostas que são plausíveis, mas desatualizadas ou incorretas, pois o modelo não consegue acessar informações além do limite de seu treinamento. Ao separar a recuperação da geração, a arquitetura mantém o modelo generativo focado no raciocínio, enquanto o componente de recuperação se encarrega de conhecer os fatos atuais. A adoção corporativa ultrapassou a marca de 51% em 2024, e a infraestrutura de suporte — bancos de dados vetoriais, APIs de recuperação e camadas de acesso à web em tempo real — está agora suficientemente madura para que a maioria das equipes possa construir um pipeline RAG funcional sem conhecimento especializado em aprendizado de máquina. O principal desafio de engenharia não é mais decidir se deve-se usar o RAG, mas sim de quais fontes de dados se deve recuperar informações e como manter essas fontes atualizadas e limpas.