Geração Aumentada por Recuperação para Tarefas de PLN com Uso Intensivo de Conhecimento

O artigo de Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (NeurIPS 2020), é provavelmente o trabalho individual mais responsável pela forma como os sistemas de IA em produção são arquitetados hoje. Cinco anos após a publicação, ele continua sendo a linha de base contra a qual quase todos os sistemas de linguagem baseados em documentos são medidos. Estou lendo-o agora porque tudo no meu backlog do Bean Labs — desde QA de livros contábeis até explicação de anomalias — acaba esbarrando na questão da recuperação, e quero entender claramente as decisões de design originais antes de passar para seus sucessores.

O artigo

O problema central que o RAG aborda é que os modelos de linguagem pré-treinados incorporam o conhecimento nos pesos durante o tempo de treinamento, tornando esse conhecimento estático, opaco e impossível de atualizar sem um novo treinamento. Lewis et al. propõem uma arquitetura híbrida: uma memória paramétrica (BART-large como gerador) pareada com uma memória não paramétrica (um índice denso FAISS sobre 21 milhões de passagens da Wikipedia), conectadas por um recuperador treinado baseado em Recuperação Densa de Passagens (DPR, Karpukhin et al. 2020). No momento da inferência, o modelo recupera as top-K passagens relevantes e, em seguida, marginaliza sobre elas para produzir a saída final.

O artigo introduz duas variantes. O RAG-Sequence recupera uma vez e usa o mesmo conjunto de documentos para toda a sequência gerada — mais coerente, porém menos adaptável. O RAG-Token permite que o modelo consulte um documento recuperado diferente a cada etapa de geração, permitindo sintetizar informações de múltiplas fontes no meio da frase. Ambas as variantes aprendem o recuperador e o gerador de forma conjunta durante o ajuste fino (fine-tuning), embora o codificador de documentos seja congelado para evitar o custo de reconstruir o índice FAISS durante o treinamento.

Ideias-chave

• O RAG-Sequence atinge 44,5 de Exact Match em Natural Questions, 56,8 EM em TriviaQA e 68,0 EM em WebQuestions — o estado da arte na época da publicação.
• No QA abstrativo do MS-MARCO, o RAG-Sequence marca 40,8 de ROUGE-L contra 38,2 de uma linha de base apenas com BART — modesto, mas consistente.
• Geração de perguntas do Jeopardy: avaliadores humanos julgaram as saídas do RAG como mais fatuais do que as do BART em 42,7% dos casos (BART mais fatual em 7,1%).
• Na verificação de fatos FEVER, o RAG atinge 72,5% de precisão em 3 vias (4,3 pontos abaixo do estado da arte especializado) sem qualquer engenharia específica para a tarefa.
• Congelar o codificador de documentos durante o treinamento custa apenas cerca de 3 pontos de EM no NQ (44,0 → 41,2), tornando a abordagem computacionalmente viável ao custo de um conhecimento de índice obsoleto.
• A recuperação densa supera o BM25 em todas as tarefas, exceto no FEVER, onde consultas centradas em entidades favorecem a sobreposição de termos — um sinal concreto de que a recuperação esparsa não é uniformemente inferior.

O que se sustenta — e o que não

A percepção fundamental — separar o armazenamento de conhecimento do mecanismo de raciocínio — envelheceu muito bem. Isso proporciona conhecimento atualizável (basta reindexar), atribuição de fonte (as passagens recuperadas são inspecionáveis) e generaliza através de QA de domínio aberto, geração e verificação de fatos sem arquiteturas específicas para cada tarefa. Essas propriedades ainda importam mais na prática do que os números específicos de Exact Match.

Os revisores do NeurIPS estavam certos de que a novidade técnica é limitada. O DPR e o BART já existiam; o RAG é uma integração cuidadosa, não um avanço algorítmico fundamental. A decisão de congelar o codificador de documentos também cria um problema sutil que o artigo ignora um pouco: o índice é construído uma vez e se torna uma fotografia momentânea. Qualquer fato que mude após a construção do índice é invisível para o modelo. Para corpora estáticos como registros da SEC, isso é aceitável. Para sistemas dinâmicos — preços em tempo real, feeds de transações diárias — é uma restrição arquitetônica real, não um detalhe menor.

A descoberta do colapso de recuperação merece mais atenção do que recebe. Em tarefas de geração de histórias, o modelo aprendeu a ignorar completamente os documentos recuperados e a gerar a partir da memória paramétrica. O artigo observa que isso acontece quando a tarefa não "exige conhecimento específico", mas não explica o mecanismo nem oferece aos profissionais uma forma fundamentada de detectá-lo. Um agente que para de recuperar silenciosamente enquanto parece funcionar normalmente é exatamente o modo de falha que me preocupa em sistemas financeiros de produção.

A pegada de memória também não é trivial: o índice da Wikipedia sozinho requer cerca de 100 GB de RAM de CPU. O artigo apresenta isso como uma característica (a memória não paramétrica é "rápida de atualizar"), mas é um custo operacional real que moldou a evolução da técnica — em direção a índices comprimidos e recuperação aproximada — nos anos que se seguiram.

Por que isso importa para a IA financeira

A arquitetura de recuperação mapeia-se naturalmente para a estrutura de problemas do Beancount. Um livro contábil Beancount é um grande corpus de documentos de acréscimo apenas (append-only) onde as entradas individuais estão ligadas semanticamente: uma despesa dedutível de impostos faz referência a uma categoria, uma categoria faz referência a uma regra, uma regra faz referência a um ano fiscal. Nenhum modelo paramétrico treinado em dados públicos conhece o plano de contas específico de um usuário. A separação entre raciocínio e conhecimento do RAG torna-o a resposta estrutural correta: ajuste fino do gerador em formatos de tarefas contábeis, mas baseando as consultas fatuais no índice do livro contábil real do usuário.

A preocupação prática é a mesma que o artigo identifica, mas subestima: índices obsoletos. Se um agente Beancount recupera de um índice construído ontem, ele pode perder as transações de hoje. A indexação incremental e a reindexação acionada por gravações no livro contábil precisam fazer parte do design do sistema desde o início, não serem adaptadas posteriormente. A outra preocupação é a precisão da recuperação sobre dados estruturados. O RAG foi projetado para a prosa da Wikipedia. Um livro contábil Beancount possui intervalos de datas, hierarquias de contas e denominações de moedas que recuperadores otimizados para prosa não lidam nativamente. A questão "podem os LLMs raciocinar sobre dados tabulares" que explorei anteriormente restringe diretamente o que o RAG pode recuperar de forma útil.

O que ler a seguir

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — processa independentemente cada passagem recuperada e as funde no decodificador, alcançando pontuações de NQ mais altas que o RAG, sendo arquitetonicamente mais simples; vale a pena entender antes de adotar a abordagem de leitura conjunta do RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — recupera sob demanda durante a geração, prevendo quando o modelo está prestes a alucinar; a extensão mais natural das ideias do RAG em direção a agentes mais adaptáveis.
• "Fine-Tuning or Retrieval?" Ovadia et al. 2023 (arXiv:2312.05934) — comparação sistemática de métodos de injeção de conhecimento entre tarefas; a evidência empírica que você precisa antes de decidir se deve ajustar um gerador específico para livros contábeis ou apenas melhorar a recuperação.