Chunking-Strategien für Finanzdokumente

Chunken Sie Finanzdokumente entlang ihrer Struktur, nicht nach Token-Anzahl. Trennen Sie an Abschnitts- und Klauselgrenzen, halten Sie jede Tabelle mit ihrer Kopfzeile und ihren Einheiten zusammen, und hängen Sie den umgebenden Kontext (Überschriftenpfad, Berichtsperiode, Entität, Währung) an jeden Chunk an. Das Splitten nach festem Fenster ist genau das, was Retrieval kaputtmacht: Es trennt einen Covenant von seiner Definition und eine Zahl von der Zeilenbeschriftung, die ihr überhaupt erst Bedeutung gibt.

Das Versagen lässt sich leicht reproduzieren. Nehmen Sie einen 10-K, ziehen Sie ein 512-Token-Gleitfenster über den extrahierten Text und suchen Sie nach dem Interest-Coverage-Covenant. Der Retriever liefert einen Chunk zurück, der die Schwellen-Ratio enthält, aber nicht die Definition des Begriffs, für den sie gilt, denn diese Definition stand zwei Seiten früher unter einer anderen Überschrift. Das Modell antwortet dann mit einer Zahl, die echt ist, und einer Bedeutung, die es sich ausgedacht hat. Das ist das ganze Problem mit naivem Chunking auf Finanzinhalten. Die Bruchstücke lassen sich sauber abrufen, und sie führen mit voller Überzeugung in die Irre.

Struktur ist das Signal, also parsen Sie sie, bevor Sie splitten

Finanzdokumente sind kein freier Text mit gelegentlicher Formatierung. Eine Bilanz ist ein Raster, in dem die Zeilenbeschriftung und die Spaltenperiode gemeinsam bestimmen, was eine Zelle bedeutet. Ein Kreditvertrag ist ein Baum aus definierten Begriffen, Abschnitten und Anlagen, die aufeinander verweisen. Ein Prospekt wiederholt dieselbe Kennzahl in drei Darstellungen. Wenn Ihre Pipeline von einem flachen Text-Dump ausgeht, haben Sie die Koordinaten, die Sie für gutes Chunking brauchen, bereits verloren.

Die erste Stufe ist also Layout-Parsing, nicht Chunking. Sie wollen eine Lesereihenfolge, die Spalten respektiert, eine Überschriftenhierarchie, die Geometrie der Tabellenzellen und die Grenzen von Fußnoten und Querverweisen. Daraus bauen Sie dann die Chunks. Die Reihenfolge ist entscheidend, denn der Parse bestimmt überhaupt erst, was eine gültige Grenze ist.

• Für Fließtext-Abschnitte (Geschäftsüberblick, Risikofaktoren, MD&A) splitten Sie entlang des Überschriftenbaums und halten jeden Blattabschnitt bis zu einer Größenobergrenze zusammen. Läuft ein Abschnitt lang, splitten Sie an Absatzgrenzen und tragen den Überschriftenpfad in jedes Kind hinein.
• Für Tabellen halten Sie die Tabelle ganz, wenn sie in einen Chunk passt. Wenn nicht, splitten Sie nach Zeilengruppen und wiederholen die Kopfzeile sowie jede Einheitenzeile in jedem Stück. Eine Finanztabelle ohne ihre Kopfzeile und ihre Skala (“in Tausend, außer je Aktie”) ist im Retrieval nahezu wertlos.
• Für Verträge ist die Klausel das Atom. Splitten Sie an der nummerierten Klausel oder Unterklausel, niemals mitten im Satz, und behalten Sie die Klauselnummer, damit nachgelagertes Reasoning sie zitieren kann.

Tragen Sie Kontext in den Chunk hinein, denn der Retriever sieht nur den Chunk

Zum Abfragezeitpunkt bewertet der Retriever einen isolierten Chunk. Er sieht nicht das Dokument darum herum. Alles, was ein Leser aus den umliegenden Seiten gebraucht hätte, um diesen Chunk zu verstehen, müssen Sie also vor dem Indexieren mit einfalten.

Konkret stellen wir jedem Chunk einen kompakten Kontext-Header voran: den Dokumenttyp und -titel, die Berichtsperiode, die berichtende Entität, die Währung und Skala sowie den vollständigen Überschriftenpfad bis hinunter zum Chunk. Eine Zahlenzeile aus einer Kapitalflussrechnung wird dadurch abrufbar als “Acme Corp, konsolidierte Kapitalflussrechnung, GJ2025, USD in Tausend, Finanzierungstätigkeit” statt als nackte Liste von Zahlen, die zu jedem beliebigen Unternehmen in jedem beliebigen Jahr gehören könnte. Das schützt unmittelbar die Point-in-Time-Korrektheit. Ohne die auf den Chunk gestempelte Periode wird ein Retriever bereitwillig eine Q1-Zahl in eine Antwort über das Gesamtjahr mischen, und keine nachgelagerte Prüfung fängt das ab, weil die Zahl selbst echt ist.

Zwei weitere Dinge gehören in die Chunk-Metadaten, aus dem eingebetteten Text herausgehalten, aber daneben gespeichert:

• Lineage: Quelldokument-ID, Seite und der Byte- oder Zellbereich, aus dem der Chunk stammt. Wenn eine Antwort falsch ist, müssen Sie bis zum exakten Ursprung zurückgehen können, und für alles, was einen Audit-Trail berührt, ist das nicht optional.
• Strukturelle Rolle: Ist dies eine Überschrift, eine Tabelle, eine Fußnote, eine Definition, ein Unterschriftenblock. Die Retrieval-Qualität steigt, wenn Sie nach Rolle filtern oder boosten können, und ein hybrider Retriever kann einen Definitions-Chunk anders gewichten als einen erzählenden.

Definitionen verdienen eine besondere Behandlung. In Verträgen sind definierte Begriffe die Gelenke des gesamten Dokuments. Wir extrahieren den Definitionsabschnitt separat und, wo eine Klausel sich auf einen Begriff stützt, fügen wir entweder eine kurze Erläuterung inline ein oder indexieren die Klausel und ihre Definitionen als verknüpftes Paar. Das ist die einzelne Änderung, die das Versagen “Covenant ohne seine Definition” am stärksten reduziert.

Splitten Sie dort, wo Bedeutung endet, und messen Sie dann, ob es funktioniert hat

Die vereinheitlichende Regel ist unspektakulär und sie hält: Schneiden Sie an einer Grenze, die ein menschlicher Redakteur erkennen würde, und niemals mitten in einer semantischen Einheit. Ein Satz, eine Tabelle, eine Klausel, eine Fußnote, ein definierter Begriff. Feste Größen sind ein Rückfallmechanismus für den Fall, dass Struktur wirklich ausgeht, nicht das primäre Verfahren. Overlap zwischen Chunks ist ein grober Flicken für Grenzfehler; wenn Sie den Overlap auf 30 Prozent hochschrauben, um Kohärenz wiederherzustellen, ist die eigentliche Lösung eine bessere Grenze, nicht mehr Redundanz.

Nichts davon lohnt sich auf gut Glück, also bauen Sie ein Eval-Set aus echten Anfragen gegen echte Dokumente. Unseres paart eine Frage mit der konkreten Textspanne, die sie beantwortet, und wir bewerten, ob die abgerufenen Chunks diese Spanne tatsächlich mit ihrem notwendigen Kontext enthalten. Ein Chunk, der die richtige Zahl ohne die Zeilenbeschriftung oder die Periode zurückliefert, zählt als Fehltreffer, denn er wird nachgelagert eine falsche Antwort erzeugen, auch wenn die Retrieval-Metrik gut aussieht. Verfolgen Sie das getrennt von der reinen Trefferquote.

Beobachten Sie zwei Dinge über die Zeit. Erstens die Abdeckung von Tabellen und Fußnoten, denn dort degradieren die meisten Extraktions-Pipelines stillschweigend, wenn zum Quartalsende ein neues Dokumenten-Template auftaucht. Zweitens die Drift der Chunk-Grenzen: Wenn ein Anbieter ein Filing-Layout ändert oder Sie den Layout-Parser austauschen, verschieben sich die Grenzen, und Retrieval, das früher funktionierte, beginnt Fragmente zurückzugeben. Lassen Sie das Eval-Set bei jedem Ingestion-Batch erneut laufen, und beides zeigt sich, bevor es einen Nutzer erreicht. Stichproben übersehen es. Behandeln Sie Chunking als lebendigen Teil des Data Layers, der dasselbe Monitoring verdient wie alles andere, das in eine Entscheidung einfließt, und nicht als Vorverarbeitungsschritt, den Sie einmal konfigurieren und dann vergessen.