Generovanie rozšírené o vyhľadávanie pre úlohy NLP náročné na znalosti

Práca Lewisa a kol. „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“ (NeurIPS 2020) je pravdepodobne článkom, ktorý má najväčšiu zásluhu na tom, ako sú dnes architektované produkčné AI systémy. Päť rokov po publikovaní zostáva benchmarkom, voči ktorému sa meria takmer každý jazykový systém založený na dokumentoch. Čítam ju teraz, pretože všetko v mojom backlogu v Bean Labs — od QA účtovnej knihy po vysvetlenie anomálií — naráža na otázku vyhľadávania a chcem jasne porozumieť pôvodným dizajnovým rozhodnutiam predtým, než sa pohnem k jeho nástupcom.

O čom je tento článok

Základným problémom, ktorý RAG rieši, je to, že predtrénované jazykové modely vkladajú znalosti do váh v čase trénovania, čím sa tieto znalosti stávajú statickými, neprehľadnými a nemožnými aktualizovať bez pretrénovania. Lewis a kol. navrhujú hybridnú architektúru: parametrickú pamäť (BART-large ako generátor) spárovanú s neparametrickou pamäťou (hustý index FAISS nad 21 miliónmi pasáží z Wikipédie), prepojenú naučeným vyhľadávačom založeným na Dense Passage Retrieval (DPR, Karpukhin et al. 2020). V čase inferencie model vyhľadá prvých K relevantných pasáží a potom ich marginalizuje, aby vytvoril konečný výstup.

Článok predstavuje dva varianty. RAG-Sequence vyhľadáva raz a používa rovnakú sadu dokumentov pre celú vygenerovanú sekvenciu — je koherentnejší, ale menej adaptívny. RAG-Token umožňuje modelu pristupovať k inému vyhľadanému dokumentu pri každom kroku generovania, čo mu umožňuje syntetizovať informácie z viacerých zdrojov uprostred vety. Oba varianty sa učia vyhľadávač a generátor spoločne počas doladenia, hoci kódovač dokumentov je zmrazený, aby sa predišlo nákladom na prebudovanie indexu FAISS počas tréningu.

Kľúčové myšlienky

• RAG-Sequence dosahuje 44,5 presnej zhody (Exact Match) v Natural Questions, 56,8 EM v TriviaQA a 68,0 EM vo WebQuestions — v čase publikácie išlo o najmodernejšie výsledky (state-of-the-art).
• V abstraktívnom QA MS-MARCO dosahuje RAG-Sequence skóre 40,8 ROUGE-L oproti 38,2 pri baseline iba s BARTom — skromný, ale konzistentný výsledok.
• Generovanie otázok v Jeopardy: ľudskí hodnotitelia posúdili výstupy RAG ako faktickejšie než BART v 42,7 % prípadov (BART bol faktickejší v 7,1 %).
• Pri overovaní faktov FEVER dosahuje RAG 72,5 % 3-cestnú presnosť (o 4,3 bodu menej ako špecializovaná SOTA) bez akéhokoľvek inžinierstva špecifického pre danú úlohu.
• Zmrazenie kódovača dokumentov počas tréningu stojí iba ~3 body EM na NQ (44,0 → 41,2), čím sa prístup stáva výpočtovo realizovateľným za cenu zastaraných znalostí v indexe.
• Husté vyhľadávanie prekonáva BM25 vo všetkých úlohách okrem FEVER, kde dopyty zamerané na entity uprednostňujú prekrývanie termínov — konkrétny signál, že riedke vyhľadávanie nie je jednotne horšie.

Čo pretrvalo — a čo nie

Základný poznatok — oddelenie úložiska znalostí od inferenčného stroja — zostarnul veľmi dobre. Poskytuje vám aktualizovateľné znalosti (stačí preindexovať), uvedenie zdroja (vyhľadané pasáže sú kontrolovateľné) a zovšeobecňuje sa v rámci QA v otvorenej doméne, generovania a overovania faktov bez architektúr špecifických pre danú úlohu. Tieto vlastnosti majú v praxi stále väčší význam než konkrétne čísla presnej zhody.

Recenzenti NeurIPS mali pravdu v tom, že technická novosť je obmedzená. DPR a BART už existovali; RAG je starostlivá integrácia, nie zásadný algoritmický pokrok. Rozhodnutie o zmrazenom kódovači dokumentov tiež vytvára jemný problém, ktorý článok trochu zahmlieva: index sa vytvorí raz a stane sa snímkou (snapshot). Akýkoľvek fakt, ktorý sa zmení po vytvorení indexu, je pre model neviditeľný. Pri statických korpusoch, ako sú podania SEC, je to prijateľné. Pre živé systémy — ceny v reálnom čase, denné toky transakcií — je to skutočné architektonické obmedzenie, nie drobný detail.

Zistenie o kolapse vyhľadávania si zaslúži viac pozornosti, než sa mu dostáva. Pri úlohách generovania príbehov sa model naučil úplne ignorovať vyhľadané dokumenty a generovať z parametrickej pamäte. Článok uvádza, že k tomu dochádza, keď úloha „nevyžaduje špecifické znalosti“, ale nevysvetľuje mechanizmus ani nedáva praktikom principiálny spôsob, ako to zistiť. Agent, ktorý ticho prestane vyhľadávať, hoci sa zdá, že funguje normálne, je presne ten poruchový režim, ktorý ma znepokojuje v produkčných finančných systémoch.

Pamäťová náročnosť je tiež netriviálna: samotný index Wikipédie vyžaduje ~100 GB RAM procesora. Článok to prezentuje ako výhodu (neparametrická pamäť sa „rýchlo aktualizuje“), ale sú to skutočné prevádzkové náklady, ktoré formovali vývoj tejto techniky — smerom ku komprimovaným indexom a približnému vyhľadávaniu — v nasledujúcich rokoch.

Prečo je to dôležité pre finančnú AI

Architektúra vyhľadávania sa prirodzene mapuje na štruktúru problémov Beancount. Účtovná kniha Beancount je veľký korpus dokumentov typu append-only, kde sú jednotlivé záznamy sémanticky prepojené: daňovo uznateľný náklad odkazuje na kategóriu, kategória na pravidlo, pravidlo na fiškálny rok. Žiadny parametrický model trénovaný na verejných dátach nepozná konkrétnu účtovú osnovu používateľa. Oddelenie uvažovania od znalostí v RAG z neho robí správnu štrukturálnu odpoveď: dolaďte generátor na formáty účtovných úloh, ale faktické vyhľadávania oprite o skutočný index účtovnej knihy používateľa.

Praktická obava je rovnaká, akú článok identifikuje, ale podceňuje: zastarané indexy. Ak agent Beancount vyhľadáva z indexu vytvoreného včera, môže vynechať dnešné transakcie. Inkrementálna indexácia a spúšťaná reindexácia pri zápisoch do účtovnej knihy musia byť súčasťou návrhu systému od začiatku, nie dorábané dodatočne. Ďalšou obavou je presnosť vyhľadávania nad štruktúrovanými dátami. RAG bol navrhnutý pre prózu z Wikipédie. Účtovná kniha Beancount má dátumové rozsahy, hierarchie účtov a nominálne hodnoty mien, ktoré vyhľadávače optimalizované na prózu natívne nezvládajú. Otázka „dokážu LLM uvažovať nad tabuľkovými dátami“, ktorú som skúmal predtým, priamo obmedzuje to, čo môže RAG užitočne vyhľadať.

Čo si prečítať ďalej

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — nezávisle spracováva každú vyhľadanú pasáž a spája ich v dekodéri, čím dosahuje vyššie skóre NQ ako RAG a zároveň je architektúrou jednoduchší; oplatí sa mu porozumieť pred prijatím prístupu spoločného čítania v RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — vyhľadáva na požiadanie počas generovania predpovedaním toho, kedy sa model chystá halucinovať; najprirodzenejšie rozšírenie myšlienok RAG smerom k adaptívnejším agentom.
• „Fine-Tuning or Retrieval?“ Ovadia et al. 2023 (arXiv:2312.05934) — systematické porovnanie metód vkladania znalostí naprieč úlohami; empirický dôkaz, ktorý potrebujete pred rozhodnutím, či doladiť generátor špecifický pre účtovnú knihu alebo len zlepšiť vyhľadávanie.