Ein Retrieval-System für Finanzdaten hat zwei Aufgaben, die in unterschiedliche Richtungen ziehen. Die eine besteht darin, eine exakte Zahl zu liefern: den Umsatz für Q3, die Schlussposition zu einem bestimmten Stichtag, eine Deckungsquote auf zwei Nachkommastellen. Die andere besteht darin, die Passage in einer 200-seitigen Offenlegung zu finden, die einen Einmaleffekt oder eine geänderte Umsatzrealisierung erklärt. Ein einzelner Speicher leistet keines von beidem gut. Fragen Sie einen Vektorindex nach einer präzisen Zahl, liefert er Ihnen etwas, das plausibel klingt, aber um eine Rundung oder eine Periode danebenliegt. Bitten Sie ein Warehouse, die Fußnote hinter einer Korrektur zutage zu fördern, hat es nirgendwo nachzuschlagen.
Deshalb bauen wir beides und legen von Anfang an fest, welche Fragen welchem Speicher gehören.
Warehouse für Zahlen, Vektorspeicher für Fließtext
Das Warehouse hält die strukturierte, numerische Wahrheit vor. Ausgewiesene Finanzkennzahlen, Zeitreihen, Positionen, alles, was man exakt abfragen würde. Lautet die Frage „wie hoch war die Zahl“, kommt die Antwort aus einer SQL-Abfrage gegen typisierte Spalten, nicht aus einem Sprachmodell, das eine Zahl aus Text rekonstruiert. Das hält die Arithmetik aus den Händen des Modells.
Der Vektorspeicher hält die Dokumentseite vor: die erzählenden Teile einer Offenlegung, Fußnoten, Lageberichte, den Text, der erklärt, warum sich eine Zahl verändert hat. Ist die Frage semantischer Natur, „was haben sie zu Lieferengpässen gesagt“, wird sie genau dort beantwortet.
Die spannende Arbeit liegt dazwischen. Die meisten realen Fragen sind gemischt. Eine Nutzerin fragt nach einer Zahl und nach der dahinterstehenden Begründung. Das richtige Muster besteht darin, den numerischen Teil an das Warehouse zu leiten, den erklärenden Teil an den Vektorspeicher und die beiden Antworten so zusammenzufügen, dass die Zahl maßgeblich und der Fließtext belegt ist. Dieses Routing richtig hinzubekommen, ist wichtiger als die Wahl des Modells.
Chunking, das eine Offenlegung lesbar hält
Naives Chunking zerstört Finanzdokumente. Zerteilen Sie einen Geschäftsbericht alle 500 Tokens, zerschneiden Sie Tabellen, trennen Fußnoten von den Posten, auf die sie sich beziehen, und entfernen die Information, welchen Geschäftszeitraum ein Absatz beschreibt. Das Retrieval liefert dann ein Fragment, das lokal flüssig und im Gesamtbild falsch ist.
Unser Daten-Chunking für Offenlegungen folgt der Struktur des Dokuments, nicht einer Tokenzahl:
- Jede Tabelle bleibt vollständig, mitsamt Kopfzeilen und Einheiten, damit eine abgerufene Tabelle für sich genommen lesbar bleibt.
- Fußnoten werden an den Posten oder die Aufstellung gebunden, die sie kommentieren, statt sie als freistehenden Text schweben zu lassen.
- Der Berichtszeitraum wird in jeden Chunk übernommen, damit sich eine Passage über „das Quartal“ auf ein konkretes Quartalsende auflöst und nicht mit einem anderen Jahr verwechselt werden kann.
Ein Chunk sollte eine in sich geschlossene Bedeutungseinheit sein. Wenn ein Mensch ihn nicht isoliert lesen und erkennen könnte, zu welchem Unternehmen, welcher Periode und welcher Aufstellung er gehört, kann es ein Retriever ebenso wenig.
Point-in-Time-Metadaten an jedem Chunk
Jeder Chunk trägt Metadaten, und zwei Felder sind nicht verhandelbar. Das erste sind Point-in-Time-Daten: As-of- und Knowledge-Datum, damit das System so antwortet, wie sich die Welt am angefragten Stichtag darstellte, und keine spätere Korrektur in eine frühere Antwort durchsickern lässt. Offenlegungen werden nachträglich geändert; eine ursprünglich ausgewiesene Zahl und eine später korrigierte Zahl sind verschiedene Fakten, und der Speicher muss beide vorhalten, jeweils mit dem Datum, an dem sie bekannt wurden.
Das zweite ist die Quelle: Dokument, Abschnitt, Seite und der Extraktionslauf, der den Chunk erzeugt hat. Das verschafft jeder Antwort einen Prüfpfad zurück zum Primärdokument. Im Finanzbereich ist eine Antwort, die man nicht zurückverfolgen kann, eine Antwort, die man nicht verwenden kann, und die Metadaten machen die Nachvollziehbarkeit günstig, statt zu einer forensischen Übung im Nachhinein.
Die beiden Speicher abgeglichen halten
Die Aufteilung löst das Retrieval-Problem und schafft ein Wartungsproblem. Warehouse und Vektorspeicher beschreiben nun überlappende Fakten, und sie können auseinanderdriften. Eine korrigierte Zahl landet im Warehouse, während der Vektorspeicher noch den ursprünglichen Offenlegungstext enthält. Die Entitätsauflösung behandelt zwei Ticker im einen Speicher als ein Unternehmen, im anderen nicht. Sich selbst überlassen, beginnt das System, sich zu widersprechen.
Deshalb ist der Abgleich eine Daueraufgabe, kein einmaliger Vorgang. Wir lassen Prüfungen laufen, welche die Zahlen, die eine Nutzerin aus den Dokumenten abrufen würde, mit denselben Zahlen im Warehouse vergleichen, Abweichungen markieren und beide auf dieselbe Point-in-Time-Sicht zurückbinden. Wird eine Offenlegung geändert, aktualisieren sich beide Speicher gemeinsam, oder die Inkonsistenz wird gemeldet.
Retrieval-fähige Finanzdaten bestehen größtenteils aus genau dem: dem richtigen Speicher für jede Art von Frage, Chunks, die das isolierte Lesen überstehen, Daten und Quellen an allem, und einem Abgleichprozess, der die beiden Hälften ehrlich hält. Das Modell obendrauf ist der Teil, den Sie austauschen können. Dies ist der Teil, den Sie zuerst richtig hinbekommen müssen.