FinanceBench: Warum Vector-Store RAG bei echten Finanzdokumenten scheitert

FinanceBench erscheint in einem Moment, in dem jeder Anbieter von Unternehmens-KI behauptet, sein System könne „Fragen aus Ihren Finanzdokumenten beantworten“. Dieses Paper von Patronus AI stellt diese Behauptungen mit echten SEC-Einreichungen und sorgfältig kuratierten Open-Book-Fragen auf eine harte Probe. Die Ergebnisse sind eine unangenehme Lektüre für jeden, der Finanz-KI entwickelt.

Das Paper

Islam et al. stellen FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944) vor, eine Testsuite mit 10.231 Fragen zu börsennotierten Unternehmen, die aus echten SEC-Einreichungen stammen – 10-K Jahresberichte, 10-Q Quartalsberichte, 8-K aktuelle Berichte und Abschriften von Ergebnisberichten. Im Gegensatz zu früheren Finanz-QA-Datensätzen (FinQA, TAT-QA), die bereits extrahierte Tabellen und Passagen präsentieren, erfordert FinanceBench, dass ein System Beweise aus vollständigen Dokumenten abruft (Retrieval), bevor es antwortet. Das ist das realistische Szenario. Die Fragen sind so konzipiert, dass sie faktisch eindeutig sind und, in den Worten der Autoren, einen „Mindestleistungsstandard“ darstellen.

Das Team bewertete 16 Konfigurationen von GPT-4-Turbo, Llama2 und Claude2 über vier Retrieval-Strategien hinweg: Closed-Book (kein Retrieval), gemeinsamer Vektorspeicher (Shared Vector Store), Vektorspeicher pro Dokument und Long-Context-Prompts, die die gesamte relevante Seite einspeisen. Menschliche Kommentatoren überprüften manuell alle 2.400 Antworten aus 150 Open-Source-Fällen.

Kernideen

• Retrieval ist nicht der Engpass. GPT-4-Turbo erreicht mit der Oracle-Passage – der exakten Seite, die die Antwort enthält – immer noch nur 85 % Genauigkeit. Long-Context-Prompting (automatisches Einspeisen der richtigen Seite) erreicht 79 %. Perfektes Retrieval bringt lediglich sechs Prozentpunkte.
• Vector-Store RAG ist das eigentliche Problem. GPT-4-Turbo mit einem Vektorspeicher pro Dokument: 50 % korrekt, 39 % verweigert. Mit einem gemeinsamen Vektorspeicher über Unternehmen hinweg: 19 % korrekt, 68 % verweigert. Die Schlagzeile „81 % Fehlerrate“ stammt aus diesem Setup mit gemeinsamem Speicher – der Konfiguration, die die meisten Unternehmens-Demos tatsächlich verwenden.
• Modelle scheitern unterschiedlich. Llama2 halluziniert aggressiv (54–70 % falsch); GPT-4-Turbo verweigert die Antwort (39–68 % verweigert statt falsch). Beide Fehlermodi sind in der Produktion inakzeptabel, stellen jedoch keine gleichwertigen Risiken dar.
• 66 % der Fragen erfordern numerisches Schlussfolgern. Wachstumsraten, Margen, Vorjahresvergleiche. Hier irren sich Modelle am häufigsten – Rechenfehler, Verwechslung von Einheiten, Vorzeichenfehler.
• Langer Kontext rettet es fast. Claude2 Long-Context: 76 % korrekt. GPT-4-Turbo Long-Context: 79 %. Dies sind die besten praktischen Werte, die erreicht werden, indem das Retrieval übersprungen und die gesamte relevante Seite direkt eingespeist wird.
• Sogar das Oracle hat Lücken. Selbst mit perfekten Beweisen liegt die Obergrenze bei 85 %, nicht bei 100 %. Fünfzehn Prozent der Fehler sind reine Argumentationsfehler ohne Retrieval-Komponente.

Was Bestand hat – und was nicht

Das Design des Benchmarks ist solide. Auf echten Dokumenten anstatt auf vor-extrahierten Ausschnitten zu bestehen, ist die richtige methodische Wahl – es testet, worauf es im Einsatz tatsächlich ankommt. Die manuelle Auswertung von 2.400 Antworten ist aufwendig und glaubwürdig.

Weniger überzeugend finde ich es, Rankings aus n=150 abzuleiten. Der Unterschied zwischen Claude2 Long-Context (76 %) und GPT-4-Turbo Long-Context (79 %) ist bei dieser Stichprobengröße statistisch bedeutungslos, aber das Paper präsentiert ihn als Ranking. Der vollständige Benchmark mit 10.231 Fragen existiert, wird aber nicht öffentlich bewertet, was die unabhängige Reproduktion einschränkt.

Das Oracle-Ergebnis ist zudem der wichtigste und am wenigsten analysierte Befund. Wenn Modelle in 15 % der Fälle scheitern, obwohl sie die richtige Seite vorliegen haben, liegt das Problem beim logischen Denken und der Arithmetik, nicht beim Retrieval. Das Paper nennt Rechner-Tools und Chain-of-Thought als zukünftige Arbeit – diese Experimente hätten im Zentrum dieses Papers stehen sollen, nicht als Fußnote.

Der Benchmark räumt zudem ein, dass er auf eine „Mindestleistung“ abzielt: Einzeldokument-Fragen mit eindeutigen Antworten. Dokumentübergreifendes Schlussfolgern, mehrjährige Trends und Vergleiche zwischen Unternehmen sind ausgeschlossen. Paper, die den Long-Context-Wert von 79 % zitieren, werden diesen Vorbehalt selten erwähnen.

Warum das für Finanz-KI wichtig ist

Der Beancount-Write-Back-Anwendungsfall lässt sich fast direkt auf die Fehlermodi von FinanceBench übertragen. Ein Agent, der einen Transaktionseintrag abruft und prüft, ob der Betrag mit einem Kontoauszug übereinstimmt, führt dieselbe Retrieval-plus-Arithmetik-Aufgabe aus, die dieser Benchmark misst. Die Oracle-Obergrenze – 85 % selbst bei perfektem Kontext – ist die relevante Designbeschränkung: Selbst wenn der Agent den richtigen Bucheintrag findet, besteht eine reale Wahrscheinlichkeit, dass er den Vergleich falsch berechnet, das Vorzeichen verwechselt oder die Einheiten falsch liest.

Die Aufteilung der Fehler zwischen Llama2 und GPT-4 ist für die Agentenarchitektur von Bedeutung. Eine Verweigerung ist behebbar (Weiterleitung zur menschlichen Überprüfung); ein halluzinierter Abgleich, der in das Hauptbuch eingetragen wird, hingegen nicht. Dies spricht dafür, ein konservatives Verweigerungsverhalten einer selbstbewussten Halluzination vorzuziehen, selbst auf Kosten einer geringeren scheinbaren Erfolgsquote.

Der Vorteil langer Kontexte (79 % gegenüber 50 %) ist für Hauptbuch-Anwendungen praktisch frustrierend. Mehrjährige Beancount-Dateien sind zu groß, um sie vollständig einzuspeisen. Das Lösen des Retrievals über dichte numerische Dokumente – nicht nur das Text-Retrieval – bleibt ein offenes Problem.

Was man als Nächstes lesen sollte

• FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) – der Vorläufer-Benchmark, den FinanceBench explizit verbessert; nützlich, um zu verstehen, was das Fachgebiet bereits richtig gemacht hat, bevor das Retrieval aus echten Dokumenten erforderlich wurde.
• DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) – erweitert FinanceBench um schwierigere Multi-Hop-Fragen, die logische Schlüsse über verschiedene Abschnitte innerhalb einer einzelnen Einreichung hinweg erfordern.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) – lagert Arithmetik an einen Python-Interpreter aus und adressiert damit direkt die 66 % der FinanceBench-Fragen, die am numerischen Schlussfolgern scheitern.