Retrieval-Augmented Generation voor Kennisintensieve NLP-taken

Het artikel "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" van Lewis et al. (NeurIPS 2020) is waarschijnlijk de publicatie die het meest verantwoordelijk is voor hoe productie-AI-systemen tegenwoordig worden ontworpen. Vijf jaar na publicatie blijft het de basislijn waarlangs bijna elk op documenten gebaseerd taalsysteem wordt gemeten. Ik lees het nu omdat alles in mijn Bean Labs-backlog — van grootboek-QA tot de verklaring van anomalieën — uiteindelijk stuit op de retrieval-vraag, en ik de oorspronkelijke ontwerpbeslissingen helder wil begrijpen voordat ik overga naar de opvolgers.

Het artikel

Het kernprobleem dat RAG aanpakt, is dat vooraf getrainde taalmodellen kennis vastleggen in gewichten op het moment van training, waardoor die kennis statisch, ondoorzichtig en onmogelijk bij te werken is zonder hertraining. Lewis et al. stellen een hybride architectuur voor: een parametrisch geheugen (BART-large als generator) gekoppeld aan een niet-parametrisch geheugen (een dichte FAISS-index over 21 miljoen Wikipedia-passages), verbonden door een getrainde retriever gebaseerd op Dense Passage Retrieval (DPR, Karpukhin et al. 2020). Tijdens de inferentie haalt het model de top-K relevante passages op en marginaliseert deze vervolgens om de uiteindelijke output te produceren.

Het artikel introduceert twee varianten. RAG-Sequence haalt één keer op en gebruikt dezelfde set documenten voor de volledige gegenereerde reeks — consistenter, maar minder adaptief. RAG-Token stelt het model in staat om bij elke generatiestap aandacht te besteden aan een ander opgehaald document, waardoor het halverwege de zin informatie uit meerdere bronnen kan synthetiseren. Beide varianten leren de retriever en generator gezamenlijk tijdens de fine-tuning, hoewel de document-encoder bevroren is om de kosten van het herbouwen van de FAISS-index tijdens de training te vermijden.

Belangrijke ideeën

• RAG-Sequence behaalt 44,5 Exact Match op Natural Questions, 56,8 EM op TriviaQA en 68,0 EM op WebQuestions — state-of-the-art ten tijde van publicatie.
• Op MS-MARCO abstractieve QA scoort RAG-Sequence 40,8 ROUGE-L tegenover 38,2 voor een BART-only basislijn — bescheiden maar consistent.
• Jeopardy-vraaggeneratie: menselijke beoordelaars vonden RAG-outputs in 42,7% van de gevallen feitelijker dan BART (BART was feitelijker in 7,1%).
• Op FEVER-feitverificatie bereikt RAG een 3-weg nauwkeurigheid van 72,5% (4,3 punten onder de gespecialiseerde SOTA) zonder enige taakspecifieke engineering.
• Het bevriezen van de document-encoder tijdens de training kost slechts ~3 EM-punten op NQ (44,0 → 41,2), waardoor de aanpak computationeel haalbaar wordt ten koste van verouderde indexkennis.
• Dense retrieval presteert beter dan BM25 op alle taken behalve FEVER, waar op entiteiten gerichte queries profiteren van term-overlap — een concreet signaal dat sparse retrieval niet uniform inferieur is.

Wat standhoudt — en wat niet

Het fundamentele inzicht — het scheiden van het kennissysteem van de redeneerengine — is zeer goed verouderd. Het biedt bijwerkbare kennis (eenvoudig herindexeren), bronvermelding (de opgehaalde passages zijn inspecteerbaar) en het is generaliseerbaar over open-domein QA, generatie en feitverificatie zonder taakspecifieke architecturen. Die eigenschappen zijn in de praktijk nog steeds belangrijker dan de specifieke Exact Match-cijfers.

De NeurIPS-beoordelaars hadden gelijk dat de technische nieuwigheid beperkt is. DPR en BART bestonden al; RAG is een zorgvuldige integratie, geen fundamentele algoritmische vooruitgang. De beslissing voor de bevroren document-encoder creëert ook een subtiel probleem waar het artikel enigszins aan voorbijgaat: de index wordt één keer gebouwd en wordt een momentopname. Elk feit dat verandert nadat de index is gebouwd, is onzichtbaar voor het model. Voor statische corpora zoals SEC-deponeringen is dit acceptabel. Voor live systemen — realtime prijzen, dagelijkse transactiefeeds — is het een wezenlijke architecturale beperking, geen klein detail.

De bevinding van 'retrieval collapse' verdient meer aandacht dan het krijgt. Bij verhaalgeneratietaken leerde het model de opgehaalde documenten volledig te negeren en te genereren vanuit het parametrische geheugen. Het artikel merkt op dat dit gebeurt wanneer de taak geen "specifieke kennis vereist", maar legt het mechanisme niet uit en geeft praktijkmensen geen principiële manier om dit te detecteren. Een agent die stilletjes stopt met ophalen terwijl hij normaal lijkt te functioneren, is precies de foutmodus die mij zorgen baart in financiële productiesystemen.

De geheugenvoetafdruk is ook niet gering: alleen de Wikipedia-index vereist al ~100 GB CPU-RAM. Het artikel presenteert dit als een functie (niet-parametrisch geheugen is "snel bij te werken"), maar het zijn reële operationele kosten die bepaalden hoe de techniek zich in de jaren daarna ontwikkelde — richting gecomprimeerde indexen en benaderende retrieval (approximate retrieval).

Waarom dit belangrijk is voor financiële AI

De retrieval-architectuur sluit natuurlijk aan bij de probleemstructuur van Beancount. Een Beancount-grootboek is een groot, append-only corpus van documenten waarin individuele boekingen semantisch gekoppeld zijn: een aftrekbare kostenpost verwijst naar een categorie, een categorie verwijst naar een regel, een regel verwijst naar een boekjaar. Geen enkel parametrisch model dat is getraind op publieke data kent het specifieke rekeningschema van een gebruiker. De scheiding van redeneren en kennis in RAG maakt het de juiste structurele oplossing: fine-tune de generator op formaten voor boekhoudtaken, maar baseer feitelijke zoekopdrachten op de werkelijke grootboekindex van de gebruiker.

De praktische zorg is dezelfde als die het artikel identificeert maar onderwaardeert: verouderde indexen. Als een Beancount-agent gegevens ophaalt uit een index die gisteren is gebouwd, mist hij mogelijk de transacties van vandaag. Incrementele indexering en getriggerde herindexering bij schrijfacties in het grootboek moeten vanaf het begin deel uitmaken van het systeemontwerp, niet achteraf worden toegevoegd. De andere zorg is de precisie van retrieval over gestructureerde data. RAG is ontworpen voor Wikipedia-proza. Een Beancount-grootboek bevat datumbereiken, rekeninghiërarchieën en valuta-aanduidingen waarvoor op proza geoptimaliseerde retrievers niet standaard geschikt zijn. De vraag "kunnen LLM's redeneren over tabelgegevens" die ik eerder onderzocht, beperkt direct wat RAG nuttig kan ophalen.

Wat nu te lezen

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — verwerkt elke opgehaalde passage onafhankelijk en voegt ze samen in de decoder, waarmee hogere NQ-scores worden behaald dan met RAG terwijl het architecturaal eenvoudiger is; de moeite waard om te begrijpen voordat men de joint-reading aanpak van RAG-Token overneemt.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — haalt on-demand op tijdens generatie door te voorspellen wanneer het model op het punt staat te hallucineren; de meest natuurlijke uitbreiding van RAG-ideeën naar meer adaptieve agenten.
• "Fine-Tuning or Retrieval?" Ovadia et al. 2023 (arXiv:2312.05934) — systematische vergelijking van kennisinjectiemethoden over verschillende taken; het empirische bewijs dat je nodig hebt voordat je beslist of je een grootboekspecifieke generator gaat fine-tunen of gewoon de retrieval gaat verbeteren.