Génération augmentée par récupération pour les tâches de TAL à forte intensité de connaissances

L'article « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks » de Lewis et al. (NeurIPS 2020) est probablement le document le plus déterminant dans la manière dont les systèmes d'IA de production sont architecturés aujourd'hui. Cinq ans après sa publication, il reste la référence par rapport à laquelle presque tous les systèmes de langage fondés sur des documents sont mesurés. Je le lis maintenant parce que tout ce qui se trouve dans mon backlog Bean Labs — du question-réponse sur grand livre à l'explication d'anomalies — finit par se heurter à la question de la récupération, et je veux comprendre clairement les décisions de conception originales avant de passer à ses successeurs.

L'article

Le problème central que le RAG aborde est que les modèles de langage pré-entraînés intègrent les connaissances dans leurs poids au moment de l'entraînement, ce qui rend ces connaissances statiques, opaques et impossibles à mettre à jour sans ré-entraînement. Lewis et al. proposent une architecture hybride : une mémoire paramétrique (BART-large comme générateur) couplée à une mémoire non paramétrique (un index FAISS dense sur 21 millions de passages Wikipédia), connectées par un récupérateur appris basé sur la récupération de passages denses (DPR, Karpukhin et al. 2020). Au moment de l'inférence, le modèle récupère les top-K passages pertinents, puis les marginalise pour produire le résultat final.

L'article introduit deux variantes. RAG-Sequence effectue une seule récupération et utilise le même ensemble de documents pour toute la séquence générée — plus cohérent mais moins adaptatif. RAG-Token permet au modèle de consulter un document récupéré différent à chaque étape de génération, lui permettant de synthétiser des informations provenant de multiples sources en milieu de phrase. Les deux variantes apprennent le récupérateur et le générateur conjointement lors du réglage fin (fine-tuning), bien que l'encodeur de documents soit gelé pour éviter le coût de la reconstruction de l'index FAISS pendant l'entraînement.

Idées clés

• RAG-Sequence atteint 44,5 de correspondance exacte (Exact Match) sur Natural Questions, 56,8 EM sur TriviaQA et 68,0 EM sur WebQuestions — l'état de l'art au moment de la publication.
• Sur le QA abstractif de MS-MARCO, RAG-Sequence obtient un score ROUGE-L de 40,8 contre 38,2 pour une base de référence BART seul — modeste mais constant.
• Génération de questions Jeopardy : des évaluateurs humains ont jugé les sorties RAG plus factuelles que BART dans 42,7 % des cas (BART plus factuel dans 7,1 %).
• Sur la vérification des faits FEVER, RAG atteint une précision à 3 voies de 72,5 % (4,3 points en dessous du SOTA spécialisé) sans aucune ingénierie spécifique à la tâche.
• Geler l'encodeur de documents pendant l'entraînement ne coûte que ~3 points EM sur NQ (44,0 → 41,2), ce qui rend l'approche informatiquement faisable au prix d'une connaissance d'index obsolète.
• La récupération dense surpasse BM25 sur toutes les tâches sauf FEVER, où les requêtes centrées sur les entités favorisent le chevauchement de termes — un signal concret que la récupération parcimonieuse n'est pas uniformément inférieure.

Ce qui tient la route — et ce qui ne la tient pas

L'intuition fondamentale — séparer le stockage des connaissances du moteur de raisonnement — a très bien vieilli. Cela vous donne des connaissances actualisables (il suffit de réindexer), l'attribution des sources (les passages récupérés sont inspectables) et se généralise à travers le QA en domaine ouvert, la génération et la vérification des faits sans architectures spécifiques aux tâches. Ces propriétés importent toujours plus en pratique que les chiffres spécifiques de correspondance exacte.

Les réviseurs de NeurIPS avaient raison de dire que la nouveauté technique est limitée. DPR et BART existaient déjà ; RAG est une intégration minutieuse, pas une avancée algorithmique fondamentale. La décision de geler l'encodeur de documents crée également un problème subtil que l'article survole quelque peu : l'index est construit une fois et devient un instantané. Tout fait qui change après la construction de l'index est invisible pour le modèle. Pour des corpus statiques comme les dépôts SEC, c'est acceptable. Pour les systèmes en direct — prix en temps réel, flux de transactions quotidiens — c'est une véritable contrainte architecturale, pas un détail mineur.

La découverte de l'effondrement de la récupération mérite plus d'attention qu'elle n'en reçoit. Sur les tâches de génération d'histoires, le modèle a appris à ignorer entièrement les documents récupérés et à générer à partir de la mémoire paramétrique. L'article note que cela se produit lorsque la tâche ne « nécessite pas de connaissances spécifiques » mais n'explique pas le mécanisme ni ne donne aux praticiens un moyen de le détecter. Un agent qui cesse silencieusement de récupérer tout en semblant fonctionner normalement est exactement le mode de défaillance qui m'inquiète dans les systèmes financiers en production.

L'empreinte mémoire est également non négligeable : l'index Wikipédia à lui seul nécessite ~100 Go de RAM CPU. L'article présente cela comme un avantage (la mémoire non paramétrique est « rapide à mettre à jour ») mais c'est un coût opérationnel réel qui a façonné l'évolution de la technique — vers des index compressés et une récupération approximative — dans les années qui ont suivi.

Pourquoi cela compte pour l'IA financière

L'architecture de récupération correspond naturellement à la structure des problèmes de Beancount. Un grand livre Beancount est un vaste corpus de documents en ajout seul où les entrées individuelles sont liées sémantiquement : une dépense déductible d'impôt fait référence à une catégorie, une catégorie fait référence à une règle, une règle fait référence à un exercice fiscal. Aucun modèle paramétrique entraîné sur des données publiques ne connaît le plan comptable spécifique d'un utilisateur. La séparation du raisonnement et de la connaissance opérée par RAG en fait la bonne réponse structurelle : réglez finement le générateur sur les formats de tâches comptables, mais basez les recherches factuelles sur l'index réel du grand livre de l'utilisateur.

L'inquiétude pratique est la même que celle identifiée par l'article mais sous-estimée : les index obsolètes. Si un agent Beancount effectue une récupération à partir d'un index construit hier, il peut manquer les transactions d'aujourd'hui. L'indexation incrémentielle et le re-indexage déclenché par les écritures sur le grand livre doivent faire partie de la conception du système dès le départ, et non être ajoutés après coup. L'autre préoccupation est la précision de la récupération sur des données structurées. RAG a été conçu pour la prose de Wikipédia. Un grand livre Beancount contient des plages de dates, des hiérarchies de comptes et des dénominations de devises que les récupérateurs optimisés pour la prose ne gèrent pas nativement. La question de savoir si les LLM peuvent raisonner sur des données tabulaires, que j'ai explorée précédemment, contraint directement ce que RAG peut récupérer utilement.

Lectures complémentaires

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — traite indépendamment chaque passage récupéré et les fusionne dans le décodeur, atteignant des scores NQ plus élevés que RAG tout en étant architecturalement plus simple ; mérite d'être compris avant d'adopter l'approche de lecture conjointe de RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — récupère à la demande pendant la génération en prédisant quand le modèle est sur le point d'halluciner ; l'extension la plus naturelle des idées de RAG vers des agents plus adaptatifs.
• « Fine-Tuning or Retrieval? » Ovadia et al. 2023 (arXiv:2312.05934) — comparaison systématique des méthodes d'injection de connaissances à travers les tâches ; la preuve empirique dont vous avez besoin avant de décider s'il faut régler finement un générateur spécifique aux registres comptables ou simplement améliorer la récupération.