Generació augmentada per recuperació per a tasques de PNL amb un ús intensiu del coneixement

L'article de Lewis et al. «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» (NeurIPS 2020) és probablement el treball més responsable de com s'arquitecturen els sistemes d'IA en producció actualment. Cinc anys després de la seva publicació, continua sent la línia base amb la qual es mesuren gairebé tots els sistemes de llenguatge basats en documents. El llegeixo ara perquè tot el que tinc pendent al Bean Labs —des de les preguntes i respostes sobre el llibre major fins a l'explicació d'anomalies— acaba topant amb la qüestió de la recuperació, i vull entendre clarament les decisions de disseny originals abans de passar als seus successors.

L'article

El problema central que aborda RAG és que els models de llenguatge preentrenats integren el coneixement en els pesos en el moment de l'entrenament, fent que aquest coneixement sigui estàtic, opac i impossible d'actualitzar sense tornar a entrenar. Lewis et al. proposen una arquitectura híbrida: una memòria paramètrica (BART-large com a generador) emparellada amb una memòria no paramètrica (un índex FAISS dens sobre 21 milions de passatges de la Viquipèdia), connectades per un recuperador après basat en Dense Passage Retrieval (DPR, Karpukhin et al. 2020). En el moment de la inferència, el model recupera els K passatges més rellevants i després els marginalitza per produir la sortida final.

L'article introdueix dues variants. RAG-Sequence recupera una vegada i utilitza el mateix conjunt de documents per a tota la seqüència generada —més coherent però menys adaptatiu. RAG-Token permet al model atendre un document recuperat diferent a cada pas de la generació, cosa que li permet sintetitzar informació de múltiples fonts a meitat d'una frase. Ambdues variants aprenen el recuperador i el generador conjuntament durant l'ajust fi (fine-tuning), tot i que el codificador de documents es manté congelat per evitar el cost de reconstruir l'índex FAISS durant l'entrenament.

Idees clau

• RAG-Sequence assoleix un 44,5 de Match Exacte (EM) a Natural Questions, 56,8 d'EM a TriviaQA i 68,0 d'EM a WebQuestions —l'estat de l'art en el moment de la publicació.
• En QA abstractiu de MS-MARCO, RAG-Sequence puntua 40,8 en ROUGE-L enfront del 38,2 d'una línia base només amb BART —modest però constant.
• Generació de preguntes de Jeopardy: els avaluadors humans van jutjar que les sortides de RAG eren més factuals que les de BART en el 42,7% dels casos (BART va ser més factual en el 7,1%).
• En la verificació de fets FEVER, RAG arriba al 72,5% de precisió en 3 vies (4,3 punts per sota de l'estat de l'art especialitzat) sense cap enginyeria específica per a la tasca.
• Congelar el codificador de documents durant l'entrenament només costa uns ~3 punts d'EM a NQ (44,0 → 41,2), cosa que fa que l'enfocament sigui computacionalment viable a canvi de tenir un índex de coneixement obsolet.
• La recuperació densa supera BM25 en totes les tasques excepte a FEVER, on les consultes centrades en entitats afavoreixen la superposició de termes —un senyal concret que la recuperació dispersa no és uniformement inferior.

Què es manté vigent — i què no

La idea fonamental —separar el magatzem de coneixement del motor de raonament— ha envellit molt bé. Et proporciona coneixement actualitzable (només cal tornar a indexar), atribució de fonts (els passatges recuperats són inspeccionables) i es generalitza a través de QA de domini obert, generació i verificació de fets sense arquitectures específiques per a la tasca. Aquestes propietats encara importen més en la pràctica que les xifres específiques de Match Exacte.

Els revisors del NeurIPS tenien raó en dir que la novetat tècnica és limitada. El DPR i el BART ja existien; RAG és una integració acurada, no un avenç algorítmic fonamental. La decisió de congelar el codificador de documents també crea un problema subtil que l'article passa una mica per alt: l'índex es construeix una vegada i es converteix en una instantània. Qualsevol fet que canviï després de la creació de l'índex és invisible per al model. Per a corpus estàtics com les presentacions de la SEC, això és acceptable. Per a sistemes en viu —preus en temps real, fluxos de transaccions diàries— és una limitació arquitectònica real, no un detall menor.

La troballa del col·lapse de recuperació mereix més atenció de la que rep. En tasques de generació d'històries, el model va aprendre a ignorar completament els documents recuperats i a generar a partir de la memòria paramètrica. L'article assenyala que això passa quan la tasca no «requereix coneixements específics», però no explica el mecanisme ni dóna als professionals una manera basada en principis per detectar-ho. Un agent que deixa de recuperar silenciosament mentre sembla funcionar amb normalitat és exactament el mode de fallada que em preocupa en els sistemes financers en producció.

L'empremta de memòria tampoc és trivial: només l'índex de la Viquipèdia requereix ~100 GB de RAM de CPU. L'article ho presenta com una característica (la memòria no paramètrica és «ràpida d'actualitzar»), però és un cost operatiu real que va marcar l'evolució de la tècnica —cap a índexs comprimits i recuperació aproximada— en els anys següents.

Per què això és important per a la IA financera

L'arquitectura de recuperació s'adapta naturalment a l'estructura del problema de Beancount. Un llibre major de Beancount és un corpus de documents gran i de només addició on les entrades individuals estan vinculades semànticament: una despesa deduïble d'impostos fa referència a una categoria, una categoria a una regla, una regla a un any fiscal. Cap model paramètric entrenat amb dades públiques coneix el pla de comptes específic d'un usuari. La separació de RAG entre raonament i coneixement el converteix en la resposta estructural adequada: ajustar el generador en els formats de tasques comptables, però fonamentar les cerques factuals en l'índex real del llibre major de l'usuari.

La preocupació pràctica és la mateixa que l'article identifica però infravalora: els índexs obsolets. Si un agent de Beancount recupera informació d'un índex creat ahir, pot perdre les transaccions d'avui. La indexació incremental i la reindexació activada per escriptures al llibre major han de formar part del disseny del sistema des de l'inici, no ser un afegit posterior. L'altra preocupació és la precisió de la recuperació sobre dades estructurades. RAG va ser dissenyat per a la prosa de la Viquipèdia. Un llibre major de Beancount té intervals de dates, jerarquies de comptes i denominacions de moneda que els recuperadors optimitzats per a prosa no gestionen de forma nativa. La pregunta de si «els LLM poden raonar sobre dades tabulars» que vaig explorar anteriorment limita directament el que RAG pot recuperar de manera útil.

Què llegir a continuació

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — processa de manera independent cada passatge recuperat i els fusiona en el descodificador, assolint puntuacions de NQ més altes que RAG sent arquitectònicament més simple; val la pena entendre-ho abans d'adoptar l'enfocament de lectura conjunta de RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — recupera sota demanda durant la generació predient quan el model està a punt d'al·lucinar; l'extensió més natural de les idees de RAG cap a agents més adaptatius.
• «Fine-Tuning or Retrieval?», Ovadia et al. 2023 (arXiv:2312.05934) — comparació sistemàtica dels mètodes d'injecció de coneixement a través de diverses tasques; l'evidència empírica que necessites abans de decidir si ajustar un generador específic per al llibre major o simplement millorar la recuperació.