Atlas: Gemeinsames Retriever-Reader-Pre-Training schlägt LLMs mit 540 Mrd. Parametern mit nur 11 Mrd. Parametern

Atlas ist der Nachfolger von Izacard und Graves eigenem Fusion-in-Decoder-Paper und erweitert FiD zu einem vollständig gemeinsam trainierten System, bei dem Retriever und Reader von Grund auf zusammen trainiert werden. Ich lese es jetzt, weil es die architektonische Linie vom ursprünglichen RAG-Paper über FiD bis hin zum gemeinsam trainierten Retrieval schließt – genau der Entscheidungsraum, den jedes Ledger-QA-System navigieren muss.

Das Paper

„Atlas: Few-shot Learning with Retrieval Augmented Language Models“ (Izacard et al., JMLR 2023) untersucht, ob Retrieval-Augmented-Modelle mit LLMs mit massiven Parametern bei wissensintensiven Few-Shot-Aufgaben mithalten können. Der Kernbeitrag ist ein sorgfältig vortrainiertes Retrieval-Augmented-System, das einen Contriever-basierten Dense Retriever zusammen mit einem T5-basierten Fusion-in-Decoder Reader trainiert. Die entscheidende Erkenntnis ist, dass das gemeinsame Pre-Training – nicht die Architektur – die Few-Shot-Wissensleistung vorantreibt. Das System ruft die Top-20-Dokumente ab, kodiert jedes unabhängig im Encoder und führt sie dann in der Cross-Attention des Decoders zusammen, das gleiche FiD-Design aus dem Paper der Autoren von 2021.

Kernideen

• Atlas-11B erreicht 42,4 % Genauigkeit bei Natural Questions mit nur 64 Trainingsbeispielen und übertrifft PaLM (540 Mrd. Parameter) um etwa 3 Punkte bei 50-mal weniger Parametern.
• Bei TriviaQA (64-Shot) erreicht Atlas-11B 74,5 % auf dem gefilterten Set und 84,7 % auf dem ungefilterten Hidden-Test, was zeigt, dass die Retrieval-Komponente die begrenzte Aufgaben-Supervision stark kompensiert.
• Vier Retriever-Trainingsziele werden bewertet: Attention Distillation (ADist), EMDR2 (Behandlung abgerufener Dokumente als latente Variablen), Perplexity Distillation (PDist) und LOOP (Leave-One-Out). Die Leistungsunterschiede zwischen ihnen sind gering; PDist wird aufgrund der Recheneffizienz übernommen.
• Gemeinsames Pre-Training auf unbeschriftetem Text ist der wichtigste Faktor: Alle Retrieval-Augmented-Pre-Training-Konfigurationen übertreffen die Baseline, die nur auf Retrieval-Augmented-Fine-Tuning basiert, deutlich.
• Der Dokumentenindex kann nach dem Training ohne erneutes Training des Modells aktualisiert werden, was architektonisch wichtig für dynamische Wissensdatenbanken ist. Zeitlich nicht abgestimmte Indizes verschlechtern die Leistung spürbar.
• Auf MMLU (5-Shot) erreicht Atlas-11B 47,9 % und übertrifft damit die gemeldeten 43,9 % von GPT-3 trotz etwa 16-mal weniger Parametern.

Was Bestand hat – und was nicht

Die Hauptbehauptung – dass Retrieval eine Few-Shot-Wissensleistung bei einem Bruchteil der Parameteranzahl ermöglicht – hält überzeugend stand. Der NQ-Wert von 42,4 % mit 64 Beispielen ist ein beeindruckendes Ergebnis, und der Vergleich mit PaLM ist fair, da PaLM zu dieser Zeit der State-of-the-Art-Maßstab für Skalierung war.

Doch ich habe drei Vorbehalte. Erstens ist die Retrieval-Genauigkeit auch nach dem gemeinsamen Training nicht optimal: Unabhängige Analysen zeigen, dass Contriever in etwa 85 % der Fälle mindestens eine Gold-Aussage verpasst und eine QA-Retrieval-Genauigkeit von etwa 47 % erreicht. Das gemeinsame Training verbessert das Retrieval gegenüber nicht gemeinsam trainierten Baselines, aber der Reader leistet enorme Arbeit, um das unvollkommene Retrieval zu kompensieren – die Schlagzeilen der Few-Shot-Zahlen spiegeln das System-Limit wider, nicht die Qualität der Retrieval-Komponente. Zweitens sind die Infrastrukturkosten real: Das Aktualisieren der Dokumentenindizes während des Pre-Trainings verursacht etwa 30 % zusätzlichen Rechenaufwand, und der vollständige Wikipedia+CommonCrawl-Index benötigt 587 GB in fp16. Das ist für ein Forschungsumfeld machbar, stellt aber eine echte betriebliche Einschränkung für den Produktionseinsatz dar. Drittens wird Datenlecks (Data Leakage) eingeräumt, aber nicht gelöst: 2,8 % der MMLU-Fragen erscheinen wortwörtlich im für das Pre-Training verwendeten CCNet-Korpus, was die MMLU-Ergebnisse um einen unbekannten Betrag aufbläht.

Es gibt auch eine subtilere architektonische Einschränkung, auf die das Paper nicht vollständig eingeht: FiD kodiert jede abgerufene Passage unabhängig vor der Fusion, was die Parallelisierung unterstützt, aber bedeutet, dass der Encoder keine Cross-Passage-Attention besitzt. Lange Multi-Hop-Argumentationsketten, die Informationen über Passagen hinweg verbinden müssen, müssen diese gesamte Arbeit im Decoder leisten – und bei 20 abgerufenen Passagen trägt die Decoder-Cross-Attention eine schwere Last.

Warum dies für Finanz-KI wichtig ist

Für die Beancount-Ledger-QA ist der relevanteste Beitrag von Atlas der empirische Nachweis, dass sich gemeinsames Retriever-Reader-Training in Few-Shot-Szenarien auszahlt – und seine ehrliche Bilanz, wann dies nicht der Fall ist. Ein Beancount-Agent, der mehrjährige Transaktionshistorien abfragt, steht genau vor dem Problem des dynamischen Index: Täglich kommen neue Einträge hinzu, und ein Index, der einen Monat alt ist, liefert falsche Antworten. Atlas zeigt, dass der Index ohne erneutes Training im laufenden Betrieb ausgetauscht werden kann, was architektonisch ermutigend ist.

Die Zahlen zur Retrieval-Genauigkeit sind jedoch ernüchternd. Wenn Contriever den relevanten Ledger-Eintrag in 53 % der Retrieval-Versuche selbst nach gemeinsamem Training auf allgemeinem Text verfehlt, benötigt ein Finanz-Domain-Agent, der auf Beancount-Ledgern arbeitet – mit ihren domänenspezifischen Rohstoffnamen, Kontenhierarchien und Bean-Direktiven –, entweder ein domänenadaptives Retriever-Training oder ein durch strukturierte Abfragemethoden (exakter Kontenabgleich, Datumsfilterung) erweitertes Retrieval. Retrieval im RAG-Stil allein, selbst wenn es gemeinsam trainiert wurde, wird für hochpräzise Ledger-Operationen nicht ausreichen.

Der Vergleich mit PaLM verdeutlicht auch den architektonischen Kompromiss: Retrieval ermöglicht es, Wissen in weniger Parametern zu komprimieren, was die Inferenzkosten senkt. Für ein Produkt wie Beancount.io, bei dem die Inferenzkosten bei Skalierung eine Rolle spielen, ist die Designphilosophie von Atlas attraktiv. Aber die Indexkosten von 587 GB verlagern die Last auf die Speicher- und Retrieval-Infrastruktur – eine andere Art von betrieblicher Einschränkung, die in den Benchmark-Zahlen nicht auftaucht.

Was man als Nächstes lesen sollte

• REALM: Retrieval-Augmented Language Model Pre-Training (Guu et al., arXiv:2002.08909, ICML 2020) – das frühere gemeinsame Retriever-Reader-Pre-Training-Framework, das Atlas erweitert; unerlässlich, um zu verstehen, was Atlas tatsächlich verbessert und was es unverändert lässt.
• RA-DIT: Retrieval-Augmented Dual Instruction Tuning (Lin et al., arXiv:2310.01352, ICLR 2024) – erreicht eine mit Atlas konkurrenzfähige Leistung durch Instruction Tuning anstatt durch gemeinsames Pre-Training von Grund auf; deutet darauf hin, dass die Lücke zwischen gemeinsamem und unabhängigem Training ohne die Infrastrukturkosten geschlossen werden kann.
• RETRO: Improving Language Models by Retrieving from Trillions of Tokens (Borgeaud et al., arXiv:2112.04426, ICML 2022) – DeepMinds Ansatz zum Retrieval während des Pre-Trainings in einem anderen Maßstab; vervollständigt das Bild der Retrieval-Augmented-Pre-Training-Ansätze vor der Wahl der Architektur für die Ledger-QA.