RAG mit Tabellen und strukturierten Daten: Wie man Zahlen nicht verliert

Die Controlling-Abteilung fragt den Assistenten: „Wie hoch war der Nettoumsatz der Niederlassung in Danzig im Q3 2024?“ Das Modell gibt eine Zahl zurück. Problem: Niemand weiß, aus welchem Blatt sie stammt, ob es sich um die korrigierte Version oder einen Entwurf handelt und ob das Modell sie korrekt gelesen oder auf Basis ähnlicher Zeilen gerundet hat. Strukturierte Daten in RAG sind eine eigene Problemklasse, deutlich schwieriger als Retrieval über Textdokumente.

Ein Standard-Text-Splitter sieht eine Tabelle als kontinuierlichen Zeichenstrom und teilt sie nach der Token-Anzahl. Hat eine Tabelle 40 Zeilen, schneidet der Splitter sie etwa in der Mitte durch. Fragment A erhält die Spaltenüberschriften und Zeilen 1–20. Fragment B erhält Zeilen 21–40 ohne Überschriften.

Die Konsequenzen sind gravierend. Das Retrieval-Modell findet Fragment B und weiß nicht, dass die dritte Spalte „Nettoumsatz [PLN]“ und nicht „Marge [%]“ ist. Die Antwortgenerierung auf Basis eines solchen Fragments ist im Grunde Raten. Bei Fragen nach konkreten Werten liegt der prozentuale Fehler hier oft bei 100 %, weil das Modell die Zahl aus der falschen Spalte nimmt.

Dieses Problem betrifft Kalkulationstabellen (XLSX, CSV), Exporte aus ERP- und CRM-Systemen, Finanzberichte in tabellarischem Format sowie Ergebnisse von SQL-Abfragen, die als Dateien gespeichert sind. In jedem Fall hängt die semantische Konsistenz einer Zeile von der Überschrift ab, die ein Standard-Splitter abtrennt.

Es gibt keinen Ansatz, der für alle Fragen zu tabellarischen Daten funktioniert. Bei Cashcrown setzen wir zwei Modi ein und wählen zwischen ihnen in der Phase der Abfrageklassifizierung.

Text-to-SQL (oder text-to-query) eignet sich, wenn die Frage aggregierend oder punktuell ist: „Wie hoch war der Gesamtumsatz im Q3?“, „Zeige die 5 Kunden mit den höchsten Außenständen“, „Wie viele Bestellungen hatten einen Wert über 50.000 Zł?“. Der LLM übersetzt die natürliche Frage in eine SQL-Abfrage, die auf einer echten Datenbank oder einem in den Speicher geladenen Schema ausgeführt wird. Das Ergebnis ist deterministisch und hat eine eindeutige Provenienz: konkrete Tabelle, konkrete Spalten, konkrete WHERE-Bedingung.

Die Grenzen von text-to-SQL sind real: Das Modell muss das Schema kennen, Fragen zu Daten, die über mehrere Tabellen verteilt sind, erfordern komplexe JOINs, und eine falsch generierte Abfrage gibt eine falsche Zahl ohne Warnung zurück. Jede generierte Abfrage sollte vor dem ersten Einsatz auf Produktionsdaten von einem Menschen überprüft werden, und das System sollte jede ausgeführte Query mit Zeitstempel und Benutzer protokollieren.

Semantischer Retrieval auf denormalisierten Zeilen eignet sich für kontextuelle und musterbasierte Fragen: „Welcher Kunde hat ein Profil ähnlich wie Firma X?“, „Finde Produkte mit ähnlichen Verkaufszyklen“, „Welche Kostenkategorien sind im letzten Jahr überproportional gestiegen?“. Hier geht es nicht um eine einzelne Zahl, sondern um Beziehungen, Anomalien und Ähnlichkeiten, die sich nicht durch eine einfache SQL-Abfrage ausdrücken lassen.

Unabhängig vom gewählten Modus ist die Datenaufbereitungsphase kritisch. Für tabellarische Daten verwenden wir einen schema-aware Ansatz, der sich vom Standard-Chunking unterscheidet, wie es im Artikel über Chunking von Dokumenten für RAG ausführlich beschrieben wird.

Das Prinzip ist einfach: Jede Tabellenzeile, die in den Vektorindex gelangt, muss die Spaltenüberschriften mitführen. Nicht in einem separaten Fragment, sondern inline, im selben Chunk. Das Markdown-Format eignet sich gut, da es für das Modell lesbar ist und die Beziehung zwischen Spalte und Wert bewahrt:

Niederlassung: Danzig | Zeitraum: Q3 2024 | Nettoumsatz [PLN]: 1 247 890 | Bruttomarge [%]: 34,2 | Version: nach Korrektur 2024-10-15

Jeder solche Zeilen-Chunk erhält Metadaten: Name der Quelldatei, Tabellenblatt oder Tabellenname, Zeilennummer in der Originaldatei, Versionsdatum des Dokuments, Datentyp (finanziell, Verkauf, Personal). Die Metadaten ermöglichen das Filtern vor der Vektorsuche, wie wir es im Detail beim hybriden Suchen mit BM25 und Vektoren beschreiben.

Bei großen Tabellen (über 500 Zeilen) indexieren wir nicht alles. Wir indexieren Zeilen, die Potenzial für die Beantwortung von Geschäftsanfragen haben, also Zeilen mit von Null verschiedenen Werten, Ausnahmeflags, Aggregationen auf Abteilungsebene oder für einen Zeitraum. Granulare Zeilen gelangen in die SQL-Datenbank, die über text-to-SQL zugänglich ist.

Gemischte Fragen sind am schwierigsten. Der Assistent muss zunächst konkrete Zahlen per SQL abrufen und sie dann mit semantischem Kontext aus ähnlichen Perioden oder Produkten anreichern. Eine solche Architektur erfordert einen Orchestrator, der beide Ergebnisse zusammenführt, bevor sie in die Generierung einfließen. Ein Human-Gate für ein solch komplexes Ergebnis ist obligatorisch, wenn die Antwort eine Managemententscheidung speist.

Dies ist eine harte Anforderung an die Architektur, die wir bei Cashcrown auf Prompt-Ebene durchsetzen und im Golden-Set evaluieren.

Jede vom Assistenten zurückgegebene Zahl muss eine Attribution zu einer konkreten Quelle haben. Das Format der Provenienz hängt vom Modus ab:

Für text-to-SQL: „1 247 890 PLN (Quelle: bericht_ergebnisse_Q3_2024.xlsx, Tabellenblatt Niederlassungen, Zeile 47, Version nach Korrektur 2024-10-15, Abfrage: SELECT umsatz_netto FROM niederlassungen WHERE name='Danzig' AND zeitraum='Q3_2024')“.

Für semantischen Retrieval: „34,2 % (Quelle: Fragment Zeile 47 aus bericht_ergebnisse_Q3_2024.xlsx, Kosinus-Ähnlichkeit 0,97)“.

Das Modell sollte niemals eine Zahl runden oder interpolieren, die es nicht im Index gefunden hat. Wenn die Daten nicht verfügbar sind, lautet die Antwort: „Diese Zahl ist nicht in der Datenbank vorhanden. Überprüfen Sie Datei X oder bitten Sie einen Analysten um einen Export.“ Das ist besser als eine Zahl, die glaubwürdig aussieht, aber aus der ähnlichsten Zeile stammt.

Mehr darüber, wie man KI-Systeme aufbaut, die für Unternehmensdaten verantwortlich sind, im Artikel über Firmen-GPT auf Wissensbasis.

Finanz-, Personal- und Verkaufsdaten sollten selten für alle Benutzer des Assistenten zugänglich sein. In der RAG-Architektur über strukturierte Daten wird die Zugriffsfilterung über Chunk-Metadaten realisiert: Jede Zeile trägt ein Label access_level (z. B. „vorstand“, „controlling“, „vertrieb“) und tenant_id in Mehrfirmen-Systemen.

Die Vektorabfrage filtert nach diesen Metadaten, bevor sie zum semantischen Ranking übergeht. So sieht ein Controller keine Personaldaten, und ein Vertriebsmitarbeiter sieht keine Nettomargen. Details zur Implementierung der Zugriffsisolierung beschreibt der Artikel über Vektordatenbanken und Entscheidungskriterien.

Die zweite Sicherheitsdimension ist die Datenaktualität. Finanzblätter werden versioniert. Ein Vektorindex, der auf einem Entwurf vom 12. Oktober basiert, gibt andere Zahlen zurück als einer, der auf der korrigierten Version vom 15. Oktober aufgebaut ist. Das System muss die Version des Dokuments als Metadatum jedes Chunks speichern und dem Benutzer bei jeder Antwort anzeigen. Die Entscheidung, welche Version als verbindlich gilt, obliegt dem Menschen, nicht dem Assistenten.

Für regulatorische Berichte (z. B. Finanzberichte, Berichte an die KNF) empfehlen wir einen Nur-Lese-Ansatz mit Protokollierung jeder Abfrage und Antwort. Die Anforderungen des AI Act zur Dokumentation von Hochrisikosystemen können solche Assistenten umfassen, wenn sie Finanzentscheidungen beeinflussen. Mehr über Datenanalyse und BI im Artikel KI für Datenanalyse und BI.

Text-to-SQL sollte auf einer schreibgeschützten Kopie (Read Replica) oder Schemata mit SELECT-Berechtigungen nur für das Assistenten-Konto laufen. Jede generierte Abfrage sollte mit Zeitstempel und Sitzungs-ID protokolliert werden. Vor dem produktiven Einsatz empfehlen wir die Prüfung von mindestens 50 Beispielabfragen durch einen Analysten oder Entwickler, der das Schema kennt. Ein falsch generierter JOIN oder eine verwechselte WHERE-Bedingung kann eine Zahl zurückgeben, die glaubwürdig aussieht, aber auf einer falschen Teilmenge berechnet wurde.

Die Datenaufbereitungsphase sollte ein Mapping technischer Spaltennamen auf Geschäftsbeschreibungen umfassen. Die Spalte rev_net_adj_eur im Schema wird zu „Nettoumsatz nach Korrektur [EUR]“ in den Chunk-Metadaten und im text-to-SQL-Schema. Das ist analytische Arbeit, die ein Mensch mit Domänenkenntnis leisten muss; der LLM kann ein Mapping vorschlagen, aber die endgültige Entscheidung über den Geschäftsnamen liegt bei der Abteilung, die diese Daten nutzt.

Zusammengeführte Zellen sind eines der häufigsten Probleme beim Parsen von XLSX. Bibliotheken wie openpyxl geben den Wert nur für die linke obere Zelle des zusammengeführten Bereichs zurück, der Rest ist leer. In der Parsing-Phase muss der Wert der zusammengeführten Zelle auf alle Zeilen propagiert werden, die sie umfasst, bevor die Daten zum Chunking gelangen. Ohne diese Propagation sieht das Modell Zeilen ohne Gruppenüberschrift, was den Kontext zerstört und zu falschen Attributionen führt.

Ein Golden Set für tabellarische Daten sollte Fragen mit exakten, überprüfbaren Antworten enthalten: eine konkrete Zahl aus einer konkreten Zelle. Die Evaluationsmetrik ist nicht nur semantische Treffsicherheit, sondern numerische Genauigkeit: Stimmt der zurückgegebene Wert bis auf den letzten Groschen mit dem Wert in der Quelle überein (bei Finanzbeträgen sollte die Toleranz null sein). Für RAG über gemischte Daten lohnt es sich, separate Golden Sets für den SQL- und den semantischen Modus zu erstellen, da sie sich in der Erfolgsmetrik unterscheiden.

In begrenztem Maße. BM25 kommt gut mit exaktem Text-Matching zurecht, z. B. Niederlassungsnamen, Produktcodes, Vertragsnummern. Für reine Zahlen ist das BM25-Signal schwach, da dieselben Ziffern in vielen Zeilen vorkommen. Hybride Suche hilft bei gemischten Fragen, bei denen der Benutzer einen Namen angibt und nach einer Zahl fragt. Für rein aggregierende Fragen ist text-to-SQL zuverlässiger als jede Form des Vektor-Retrievals.