Retrieval Augmented Generation ist der Standardweg, um ein LLM auf einen Dokumentenbestand zu setzen, und für die meisten Bestände genügt ein semantischer Vektorindex. Finanzdokumente sind kein gewöhnlicher Bestand. Fragt man ein Modell, was ein Geschäftsbericht über ein bestimmtes Umsatzsegment aussagt, ist die Antwort nur dann brauchbar, wenn sie die richtige Zeile im richtigen Bericht trifft, für die richtige Einheit und zum richtigen Stichtag.
Hier steht mehr auf dem Spiel als bei einer Support-Wissensdatenbank. Ein unbelegter Absatz, den ein Chatbot einem Kunden serviert, ist ein Ärgernis. Derselbe Absatz vor einer Analystin, die eine Einschätzung schreibt, oder vor einem Prüfer, der sie freigibt, landet schnell in einer veröffentlichten Bewertung oder in einer Vorlage für ein Gremium. Bis jemand den Fehler bemerkt, hat er bereits seinen Weg gemacht. Die Retrieval-Schicht muss also mehr leisten, als etwas Relevantes zurückzugeben. Sie muss die exakte Zeile liefern und einem Menschen die Prüfung ermöglichen.
Wo reine semantische Suche scheitert
Ein Ticker, eine CUSIP, ein Abschnittsverweis wie „Item 1A”, ein über einen Vertrag durchgezogener Fachbegriff: Das sind Tokens, die exakt übereinstimmen müssen, und ein Embedding-Modell behandelt sie als ungefähr ähnlich zu einem Dutzend naher Nachbarn. Genau das ist der Sinn eines Embeddings, und genau hier ist es das falsche Verhalten. Sucht man nach AAPL, fördert ein reiner Vektorindex bereitwillig eine Passage zu einem anderen Emittenten zutage, die sich ähnlich liest. Quartalsangaben, Basispunktwerte und Fußnotenmarker werden auf dieselbe Weise verwischt.
Deshalb ist hybrides RAG, also Vektorsuche kombiniert mit Keyword- und BM25-Matching, 2026 die produktive Grundlinie für RAG über Finanzdokumente. Die Keyword-Seite verankert die exakten Identifikatoren; die Vektor-Seite bewältigt die umformulierte Frage, die kein Keyword erfassen würde. Man braucht beides, denn Finanzfragen sind in der Regel eine Mischung aus beidem: „Was hat das Management im Q3-Call zum Margendruck gesagt?” enthält im selben Satz eine unscharfe und eine harte Komponente.
Was Hybrid hinzufügt, und wie wir chunken
Das Retrieval-Design ist nur die halbe Miete. Wie man die Dokumente aufteilt, entscheidet darüber, ob die richtige Zeile überhaupt auffindbar ist. Unsere Standardeinstellungen über Geschäftsberichte, Earnings-Call-Transkripte und Analystenreports hinweg:
- Tabellen intakt lassen. Eine Tabelle mitten in einer Zeile zu trennen, reißt eine Zahl von ihrer Spaltenüberschrift los, und ein abgerufener Wert ohne seine Überschrift ist schlimmer als gar kein Wert.
- Fußnoten an ihren Anker binden. Eine Fußnote, die getrennt von der Zeile gelesen wird, die sie präzisiert, führt sowohl das Modell als auch die Leserin in die Irre.
- Entitäts- und Periodenmetadaten an jedem Chunk mitführen, damit eine Anfrage auf einen Emittenten und eine Berichtsperiode gefiltert werden kann, bevor das Ranking überhaupt läuft.
- Die Sprecherstruktur von Transkripten bewahren, damit eine Antwort eine Aussage dem CFO zuschreibt und nicht der Analystin, die die Frage gestellt hat.
Das hybride Ranking läuft dann über Chunks, die diese Struktur mit sich tragen. Die beiden Ergebnismengen werden fusioniert, und die besten Passagen gehen mit ihren angehängten Quellidentifikatoren an das Modell.
Die Analystin zur Quelle zurückklicken lassen
Eine quellenbasierte Antwort ist eine, bei der jede Aussage auf die Zeile verweist, aus der sie stammt. Wir führen die Dokument-ID, den Abschnitt beziehungsweise den Transkript-Zeitstempel und den Zeichenbereich durch das Retrieval hindurch bis in die Generierung, sodass das Modell den tatsächlich verwendeten Abschnitt zitiert statt eines dokumentweiten Verweises. Die Analystin, die die Antwort liest, kann direkt zur Berichtszeile oder zum Moment im Call springen und sie bestätigen.
Das ist mehr als bloße Bequemlichkeit. Nachvollziehbare Quellenangaben sind es, die dieselbe Pipeline Research und Review zugleich dienen lassen. Wenn jemand fragt, warum das System etwas behauptet hat, reicht man einen Link, statt eine Untersuchung anzustoßen. Es gibt einem zudem etwas an die Hand, gegen das man evaluieren kann: Ein Eval-Set aus Fragen mit bekannten Quellzeilen verrät, ob das Retrieval die richtige Passage findet, und zwar getrennt von der Frage, ob das Modell sie gut formuliert. Diese beiden Fehlerarten haben unterschiedliche Lösungen, und man will sie getrennt sehen.
Wenn Sie ein LLM über Geschäftsberichte und Calls setzen und die Antworten sich nicht auf eine Zeile zurückverfolgen lassen, ist die Retrieval-Schicht der richtige Ausgangspunkt. Setzen Sie auf Hybrid, damit die exakten Identifikatoren nicht länger verwischt werden, chunken Sie entlang der Struktur, die diese Dokumente tatsächlich haben, und halten Sie die Quellenangabe durchgängig angehängt, damit ein Prüfer die Arbeit nachvollziehen kann.