Long Context oder Retrieval? Die Wahl für Finanzdokumente

Standardmäßig per Retrieval arbeiten und nur dann zu Long Context greifen, wenn das Dokument klein genug ist, um hineinzupassen, und die Frage sich über das gesamte Dokument erstreckt. Ein Geschäftsbericht mit 400k Token muss nicht im Fenster liegen, wenn die Antwort in zwei Absätzen steckt; Retrieval findet diese Absätze günstiger und mit einer saubereren Audit-Spur. Long Context zahlt sich aus, wenn das Reasoning wirklich global ist.

Der Pitch, den man immer wieder hört, lautet: Die Kontextfenster sind groß genug geworden, um die Debatte zu beenden. Den ganzen 10-K einfach reinwerfen, das Chunking überspringen, den Vector Store weglassen und das Modell die Sache regeln lassen. Das ist eine echte Fähigkeit und tatsächlich nützlich. Für die meiste Arbeit mit Finanzdokumenten ist es aber der falsche Standard, und die Gründe dafür sind langweilig und operativ, nicht eine Frage der Modellqualität.

Was Ihnen die beiden Ansätze tatsächlich bringen

Die beiden konkurrieren nicht auf derselben Ebene. Retrieval entscheidet, was das Modell liest. Long Context entscheidet, wie viel es auf einmal halten kann. Sie brauchen fast immer das Erste, selbst wenn Sie das Zweite haben, denn im Finanzumfeld haben Sie selten nur ein Dokument. Sie haben einen Geschäftsbericht, dazu den Bericht des Vorjahres, dazu den Kreditvertrag, dazu interne Exposure-Daten, dazu drei Quartale an Auszügen. Retrieval ist die Methode, mit der Sie auswählen, welche davon geladen werden. Die Fenstergröße spielt erst eine Rolle, nachdem diese Auswahl getroffen ist.

Wo Long Context wirklich gewinnt:

• Das Dokument ist ein einzelnes, in sich geschlossenes Objekt und die Frage bezieht sich auf das Ganze. „Widerspricht irgendetwas in diesem 80-seitigen Vertrag der Kündigungsklausel?” ist eine globale Frage. Retrieval zerlegt sie; man kann sich nicht zu „nichts anderes widerspricht dem” hinretrieven, denn Abwesenheit ist kein Chunk.
• Querverweise sind dicht und lokal; Chunking würde sie durchtrennen. Anleihebedingungen (Indentures) und Prospekte verweisen ständig zurück und nach vorn. Ein Chunk mit dem Wortlaut „wie in Abschnitt 4.2 definiert” ist ohne 4.2 nutzlos.
• Sie betreiben exploratives Lesen, keine produktive QA. Analyst-in-the-Loop-Arbeit verträgt die Kosten; eine Straight-Through-Processing-Pipeline, die tausendfach am Tag läuft, tut das nicht.

Wo Retrieval gewinnt, ist das Spiegelbild: viele Dokumente, wiederholte Anfragen gegen denselben Korpus und Antworten, die in wenigen identifizierbaren Textstellen liegen. Das beschreibt den Großteil dessen, was Finance-Operations-Teams automatisieren.

Die Kosten-Abwägung ist nicht knapp

Das ist der Teil, den viele unterschätzen. Nehmen Sie an, Sie führen einen Dokumenten-QA-Schritt innerhalb eines Abstimmungs-Workflows aus, ein paar Tausend Aufrufe am Tag gegen denselben Satz an Kreditakten. 250k Token Kontext in jeden Call zu stopfen ist kein Rundungsfehler. Sie zahlen dafür, dass das Modell ein Dokument erneut liest, das es vor neunzig Sekunden für die vorherige Anfrage gelesen hat, und Sie zahlen Prefill auf Token, die mit der Frage nichts zu tun hatten.

Retrieval kehrt das Verhältnis um. Ziehen Sie die vier oder fünf relevanten Passagen heraus, geben Sie 4k statt 250k Token aus, und die Rechnung pro Anfrage sinkt um fast zwei Größenordnungen. Prompt Caching verringert den Abstand beim Prefill eines stabilen Dokuments, schließt ihn aber nicht, und es ändert nichts daran, dass die meisten dieser Token für die konkrete Frage irrelevant sind. Wenn das Volumen hoch und der Korpus stabil ist, weist die Ökonomie in eine Richtung, und das nicht subtil.

Es gibt auch ein Latenz-Argument. Long Context ist langsam bis zum ersten Token, wenn das Fenster voll ist. Für ein interaktives Analyse-Tool ist das erträglich. Für eine Pipeline mit Quartalsende-Deadline und einer Warteschlange dahinter summieren sich Sekunden pro Call zu Stunden.

Long Context bedeutet nicht, dass das Modell alles liest

Die bequeme Annahme ist: Was hineinpasst, wird auch genutzt. Das stimmt nicht durchgängig. Der Recall verschlechtert sich mit der Position und mit der Anzahl konkurrierender Fakten im Fenster – und Finanzdokumente sind genau in dieser Hinsicht adversarial. Ein 10-K wiederholt ähnlich aussehende Zahlen über Segmente, Perioden und Restatements hinweg. Das Risiko ist nicht, dass das Modell eine Kennzahl nicht findet. Das Risiko ist, dass es selbstbewusst die Vorjahreszahl zurückgibt oder das Segmenttotal statt des konsolidierten Werts, weil beide im Fenster standen und es den falschen gegriffen hat. Das ist ein Point-in-Time-Korrektheitsfehler, und ein volles Kontextfenster macht ihn wahrscheinlicher, nicht unwahrscheinlicher, weil es jede ähnlich aussehende Zahl gleichzeitig vor das Modell stellt.

Retrieval mit anständigen Metadaten gibt Ihnen hier eine Verteidigung. Wenn jede Passage ihre Periode, Entität und Quelle trägt, muss das Modell über eine kleinere, beschriftete Menge reasonen, und Sie können nachvollziehen, welche Textstelle die Antwort erzeugt hat. Diese Herkunft (Lineage) zählt, wenn jemand fragt, warum eine Zahl in einem Bericht gelandet ist, und Sie mehr brauchen als „das Modell hat es gesagt”.

Nichts davon ist ein Grund, Long Context zu meiden. Es ist ein Grund, es an Ihrem eigenen Material zu testen, statt der Marketing-Zahl zu vertrauen. Bauen Sie einen Needle-Test aus echten Berichten: Platzieren Sie eine bekannte Kennzahl in unterschiedlichen Tiefen und messen Sie den Recall nach Position über Ihre tatsächlichen Dokumentlängen hinweg. Führen Sie das dann als erstklassiges Eval fort, denn dieses Verhalten driftet über Modellversionen hinweg, und Sie wollen eine Regression nicht ausgerechnet zum Quartalsende entdecken.

Wie wir tatsächlich entscheiden

Die Regel, die wir verwenden, ist nahezu mechanisch. Retrieven, es sei denn, Sie können einen konkreten Grund benennen, warum die Frage das gesamte Dokument auf einmal im Speicher braucht. Die meisten können das nicht, und für diese kostet Retrieval weniger und hinterlässt eine sauberere Spur. Für die, die es können, setzen Sie Long Context gezielt ein, dimensionieren das Eval auf die realen Dokumentlängen und behalten das False-Positive-Budget im Auge – denn globales Reasoning über ein großes Fenster ist genau der Ort, an dem selbstbewusst falsche Antworten lauern.

In der Praxis enden die meisten Finanz-Pipelines ohnehin hybrid. Retrieval grenzt einen Korpus von Hunderten Dokumenten auf das eine oder zwei relevanten ein, dann liest Long Context diese vollständig, wenn die Frage global ist. Diese Reihenfolge hält die Kosten begrenzt und bewahrt ein Protokoll darüber, was gelesen wurde – und das ist der Teil, der einen Prüfer noch lange interessiert, nachdem das Modell längst weitergezogen ist.