RAG für Finanzdaten richtig bauen wo die Abrufkette bricht.

Retrieval-Augmented Generation — die Kombination aus einem Sprachmodell und einer Abrufkomponente, die relevante Dokumente heraussucht — gilt als Standardrezept, um LLMs auf eigenen Dokumenten arbeiten zu lassen. In der Praxis scheitern Finanz-RAG-Systeme aber überraschend oft, und fast immer nicht am Modell, sondern am Retrieval: Das System findet die falschen Stellen, übersieht die entscheidende Zahl oder zieht eine veraltete Information. Das Modell formuliert dann eine flüssige, überzeugende Antwort auf falscher Grundlage — der gefährlichste aller Fehler, weil er nicht auffällt. Finanzdokumente sind für RAG besonders unfreundlich: Sie stecken voller Tabellen, Fußnoten, Stichtage und Querverweise, die ein naives Chunking zerreißt. Dieser Beitrag zeigt, wo die Abrufkette in der Praxis bricht — beim Zerteilen der Dokumente, beim Umgang mit Tabellen, bei der zeitlichen Zuordnung — und welche Strategien wirklich helfen. Es geht um die unsichtbare Hälfte eines RAG-Systems, die über Erfolg oder Scheitern entscheidet, lange bevor das Sprachmodell überhaupt zum Zug kommt.

Das Modell ist selten das Problem.

Wenn ein RAG-System falsche Antworten liefert, ist der erste Reflex, am Modell oder am Prompt zu schrauben. Meistens ist das die falsche Baustelle. Ein modernes Sprachmodell beantwortet eine Frage zuverlässig, wenn die richtige Textstelle in seinem Kontext liegt. Liegt sie nicht da, kann das beste Modell nur raten — und Sprachmodelle raten leider eloquent.

Die Diagnose ist deshalb fast immer dieselbe Frage: Hat das Retrieval die relevante Stelle überhaupt geliefert? Erstaunlich oft lautet die Antwort nein. Das System hat die passende Passage nicht gefunden, oder es hat sie in einem zerschnittenen, kontextlosen Fragment geliefert, aus dem die Information nicht mehr ablesbar war.

Die ehrliche Konsequenz für jedes Finanz-RAG-Projekt: Die meiste Ingenieurarbeit gehört in die Abrufkette, nicht in das Prompt-Tuning. Wer das umdreht, optimiert das falsche Ende und wundert sich über hartnäckige Fehler.

Chunking — wo die meisten Systeme schon scheitern.

RAG zerteilt Dokumente in Abschnitte (Chunks), die einzeln durchsuchbar gemacht werden. Die naive Methode — alle 500 oder 1000 Zeichen schneiden — funktioniert bei Fließtext passabel und bei Finanzdokumenten schlecht. Sie zerreißt Tabellen, trennt eine Zahl von ihrer Überschrift, schneidet einen Satz mitten in einer entscheidenden Aussage durch.

Besser ist strukturbewusstes Chunking, das die Logik des Dokuments respektiert: Abschnitte an Überschriften trennen, Tabellen als Einheit behalten, Fußnoten ihrem Bezugspunkt zuordnen. Das ist aufwendiger, weil es die Dokumentstruktur tatsächlich verstehen muss — aber es ist der wirksamste Hebel für die Abrufqualität.

Ein praktischer Zusatz ist kontextangereichertes Chunking: Jedem Chunk wird ein kurzer Hinweis vorangestellt, aus welchem Dokument, welchem Abschnitt und welchem Zeitraum er stammt. So bleibt ein Chunk auch dann verständlich, wenn er isoliert abgerufen wird — und genau das passiert ständig. Ein Chunk, der ohne seinen Kontext „1,2 Mrd.“ sagt, ist wertlos; einer, der „Umsatz Q3 2025, Segment Europa: 1,2 Mrd.“ sagt, ist brauchbar.

Tabellen sind der Härtefall.

Der überwiegende Teil der harten Zahlen in Finanzdokumenten steht in Tabellen — und Tabellen sind für RAG notorisch schwierig. Eine Tabelle in eine lineare Textfolge umzuwandeln, zerstört die Zuordnung von Zeilen, Spalten und Überschriften. Das Modell sieht dann eine Zahlenwüste ohne klare Bezüge und ordnet Werte falsch zu.

Mehrere Strategien helfen, mit unterschiedlichem Aufwand. Tabellen lassen sich in ein strukturerhaltendes Format wie Markdown überführen, das Zeilen und Spalten erkennbar hält. Bei komplexen Tabellen — verschachtelte Überschriften, zusammengefasste Zellen, Mehrjahresvergleiche — reicht das oft nicht; hier kann eine vorgeschaltete Aufbereitung jede Zelle mit ihrem vollständigen Kontext beschreiben („Wert in Zeile X, Spalte Jahr Y“).

Eine ehrliche Grenze: Es gibt Tabellen, an denen automatische Verfahren regelmäßig scheitern — etwa Bilanzen mit vielen Ebenen und Querverweisen. Für solche Fälle ist es seriöser, das System die Unsicherheit melden zu lassen und an den Menschen zu verweisen, als eine womöglich falsch zugeordnete Zahl auszugeben. Eine falsche Bilanzzahl, selbstbewusst präsentiert, ist im Finanzkontext gefährlicher als ein ehrliches „nicht eindeutig extrahierbar“.

Der Zeitbezug — das unterschätzte Leck.

Finanzinformationen haben fast immer einen Stichtag, und der Zeitbezug ist im RAG eine ständige Fehlerquelle. Eine Frage wie „Wie hoch ist die Verschuldung?“ ist ohne Zeitangabe unvollständig — gemeint ist immer ein bestimmter Berichtsstichtag. Ein RAG-System, das den falschen Zeitraum abruft, liefert eine veraltete Zahl, die formal korrekt aussieht und sachlich falsch ist.

Drei Mechanismen sind nötig. Erstens müssen Chunks mit Zeit-Metadaten versehen sein — aus welchem Berichtszeitraum stammt diese Information. Zweitens braucht der Abruf einen Zeitfilter, der nur Dokumente des relevanten Zeitraums berücksichtigt. Drittens muss bei der Antwort der Zeitbezug mitgeführt werden, damit der Nutzer weiß, von welchem Stichtag die Zahl stammt.

Besonders tückisch ist die Vermischung von Zeiträumen: Ein System, das Passagen aus mehreren Quartalen abruft und das Modell daraus eine Antwort bauen lässt, kann Zahlen unterschiedlicher Stichtage vermengen. Das Ergebnis klingt schlüssig, ist aber inkonsistent. Saubere temporale Filterung ist deshalb keine Kür, sondern Pflicht — und einer der häufigsten blinden Flecken in produktiven Finanz-RAG-Systemen.

Retrieval-Strategien jenseits der Vektorsuche.

Die verbreitetste Abrufmethode ist die semantische Vektorsuche: Frage und Chunks werden in Zahlenvektoren übersetzt, der Abruf findet die ähnlichsten. Das funktioniert gut für bedeutungsbasierte Fragen, hat aber eine bekannte Schwäche bei exakten Begriffen — Tickersymbole, präzise Kennzahlennamen, Paragraphennummern. Hier findet die Vektorsuche oft Ähnliches statt Exaktes.

Die robuste Antwort ist hybrider Abruf: die Kombination aus semantischer Suche und klassischer Stichwortsuche. Die Stichwortsuche fängt die exakten Begriffe, die Vektorsuche das bedeutungsbasierte Drumherum. In der Praxis liefert die Kombination spürbar bessere Trefferquoten als jede Methode allein.

Ein weiterer wirksamer Schritt ist das Reranking: Statt sich auf die ersten Treffer zu verlassen, ruft man eine größere Kandidatenmenge ab und sortiert sie mit einem präziseren, aber teureren Modell nach. Das kostet etwas Rechenzeit, hebt aber die Qualität der tatsächlich an das Modell übergebenen Passagen deutlich. Gerade bei Finanzfragen, wo die richtige unter vielen ähnlichen Stellen entscheidend ist, lohnt sich dieser Zwischenschritt fast immer.

Die Abrufkette messbar machen.

Ohne Messung optimiert man im Blindflug. Der entscheidende Schritt, um ein Finanz-RAG-System zu verbessern, ist, die Abrufstufe getrennt vom Generierungsschritt zu bewerten.

• Retrieval-Genauigkeit: War die korrekte Passage überhaupt unter den abgerufenen Chunks? Diese Frage isoliert das Retrieval-Problem vom Modell-Problem — und sie ist oft ernüchternd zu beantworten.
• Faktentreue der Antwort: Lässt sich jede Aussage der finalen Antwort auf eine tatsächlich abgerufene Stelle zurückführen? Aussagen ohne Beleg sind Halluzinationsverdacht.
• Vollständigkeit: Wurde alles Relevante gefunden, oder fehlt ein Teil der Antwort, weil eine zweite wichtige Stelle nicht abgerufen wurde?

Für eine belastbare Messung braucht es — wie bei jeder LLM-Anwendung — ein Set aus Beispiel-Fragen mit verifizierten korrekten Antworten und den zugehörigen Belegstellen. Erst damit lässt sich sagen, ob eine Änderung am Chunking oder am Abruf wirklich hilft oder nur das Gefühl verbessert.

Realistischer Einstieg und ehrliche Grenzen.

Ein Finanz-RAG-System ist kein Wochenendprojekt, aber auch kein Großvorhaben. Realistisch sind einige Wochen für einen ersten, sauber funktionierenden Anwendungsfall — etwa Fragen über einen klar abgegrenzten Bestand an Geschäftsberichten. Der Aufwand verteilt sich überwiegend auf die Abrufkette: strukturbewusstes Chunking, Tabellen-Handling, Zeit-Metadaten, hybrider Abruf, Reranking und das Mess-Set. Das Sprachmodell selbst ist austauschbar.

Zu den ehrlichen Grenzen: RAG eignet sich hervorragend für Fragen, deren Antwort als Textstelle in den Dokumenten steht. Es eignet sich schlecht für Aufgaben, die rechnerische Aggregation über viele Dokumente erfordern — „durchschnittliche Marge aller Portfolio-Unternehmen über drei Jahre“ ist keine Retrieval-Frage, sondern eine Datenbank-Abfrage. Wer RAG für solche Aufgaben zweckentfremdet, baut sich ein unzuverlässiges System. Die saubere Abgrenzung, welche Fragen RAG beantworten soll und welche besser über strukturierte Daten laufen, ist eine der wichtigsten Entscheidungen im ganzen Projekt — und eine, die am Anfang stehen sollte, nicht am Ende.

Sie wollen ein zuverlässiges RAG-System über Filings, Research oder interne Finanzdokumente aufbauen, das die richtige Stelle findet statt eloquent danebenzuliegen? Unverbindlich anfragen — wir nehmen die Abrufkette von Chunking über Tabellen-Handling bis zur temporalen Filterung in den Griff und machen die Qualität messbar.