FinDER: Reale Analystenanfragen decken eine Recall-Lücke von 74 % bei Finanz-RAG auf

FinDER (arXiv:2504.15800) ist ein Retrieval-Benchmark, der auf einer einfachen, aber unterschätzten Beobachtung basiert: Die Anfragen, die Finanzexperten tatsächlich eingeben, sehen ganz anders aus als die polierten Fragen in akademischen Benchmarks. Ich lese ihn, weil er an der Schnittstelle zweier Themen liegt, die ich verfolge – der Retrieval-Lücke in der Finanz-KI und dem Problem des praktischen Realismus, das DocFinQA und FinanceBench aufzudecken begannen.

Das Paper

Chanyeol Choi, Jihoon Kwon und Kollegen einer Finanz-KI-Firma präsentieren einen Datensatz aus 5.703 expertenannotierten Tripletts aus Anfrage, Evidenz und Antwort, die von einem realen Q&A-Service für Hedgefonds-Analysten stammen. Die Dokumente sind Form 10-K-Berichte von 490 S&P 500-Unternehmen, die von SEC EDGAR gesammelt wurden. Was FinDER von früheren Benchmarks unterscheidet, ist die Abfrageseite: 89,86 % der Anfragen enthalten drei oder mehr domänenspezifische Abkürzungen oder Akronyme. Statt „Wie hoch war der Gesamtumsatz von Unternehmen X für das Geschäftsjahr 2023?“ würde ein echter Analyst eher tippen: „GOOGL 10-K FY23 revs breakdown by segment“. Der Datensatz wurde auf dem ICLR 2025 Workshop on Advances in Financial AI veröffentlicht und erschien später auf der ICAIF 2025.

Kernideen

• Der Retrieval-Recall ist durchgehend schockierend niedrig: E5-Mistral (der beste dichte Retriever) erreicht insgesamt nur 25,95 % Kontext-Recall; BM25 schafft 11,68 %. Die Kategorie „Financials“ – die für die Buchhaltung relevanteste – ist am schwierigsten: 15,84 % bzw. 6,42 %.
• Abfrage-Ambiguität allein kostet 8,2 Präzisionspunkte: Beim Testen von E5-Mistral mit 500 Anfragen vergleichen die Autoren wohlgeformte Paraphrasen (33,9 Präzision) mit den realen, abgekürzten Anfragen (25,7 Präzision). Die Lücke ist vollständig auf den Umgang mit Abkürzungen/Akronymen zurückzuführen, nicht auf die Komplexität der Dokumente.
• Die Retrieval-Qualität ist der dominierende Flaschenhals für die Generierung: LLMs ohne Kontext erzielen nahezu null Punkte (9–10 % korrekt); mit den Top-10 abgerufenen Passagen erreichen sie 29–34 %; mit perfektem „Oracle“-Kontext springen sie auf 60–68 %. Diese 35-Punkte-Lücke zwischen realistischen und Oracle-Bedingungen ist größer als der Unterschied zwischen Open-Source- und Frontier-Modellen.
• Kompositionelle Arithmetik scheitert selbst bei gutem Retrieval: Aufgaben mit mehrstufigen Berechnungen (kompositionelle Abfragen) erreichen bei allen vier Modellen – Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill und Qwen-QWQ – nur ca. 20 % Korrektheit, selbst mit den Top-10 abgerufenen Passagen. GPT-o1 führt bei Multiplikationsaufgaben mit 42,90 %, fällt aber bei Division auf 27,78 % ab.
• LLM-Reranking bringt moderate, aber konsistente Verbesserungen: Wenn man Modelle die Top-10-Treffer von E5-Mistral vor der Beantwortung neu bewerten lässt, erreicht Claude-3.7-Sonnet einen F1-Wert von 63,05 und GPT-o1 62,90. Deepseek-R1-Distill liegt mit 60,01 dahinter, trotz starker Leistungen bei strukturiertem logischem Schließen in anderen Bereichen.
• Die Schwierigkeit der Kategorien ist ungleichmäßig: Risiko-Abfragen sind am einfachsten abzurufen (E5-Mistral: 33,07 Recall); Finanzen bleiben am schwierigsten (15,84). Dies korreliert mit der Abfragestruktur – Risiko-Offenlegungen nutzen natürliche Sprache, Finanztabellen nutzen dichte numerische Notation.

Was Bestand hat – und was nicht

Der Kernbeitrag ist solide: Dies ist eine reale Abfrageverteilung von arbeitenden Analysten, und das Abkürzungsproblem ist echt. Jeder Benchmark, der auf Wikipedia oder Crowdsourcing im FinQA-Stil basiert, übersieht dies. Die dreistufige Evaluierungsstruktur – kein Kontext, realistisches Retrieval, Oracle-Kontext – ist das richtige Design; sie trennt die Retrieval-Qualität sauber von der Qualität des logischen Schließens und zeigt die verbleibende Generierungslücke (immer noch ~32–34 % Fehlerquote selbst bei perfektem Kontext bei qualitativen Fragen).

Die größte Schwäche des Papers ist die Reproduzierbarkeit. Zum Zeitpunkt der Veröffentlichung war der Datensatz nicht öffentlich verfügbar – die Autoren geben an, dass sie planen, ihn „zu einem späteren Zeitpunkt öffentlich freizugeben“. Dies ist ein erhebliches Problem für ein Workshop-Paper, das sich als Evaluierungsstandard präsentiert. Benchmarks, die nicht veröffentlicht werden, sind keine Benchmarks, sondern Fallstudien. Da es inzwischen auf der ICAIF 2025 erschienen ist, könnte die Veröffentlichung gefolgt sein, aber die arXiv-Version bestätigt dies nicht.

Die Retrieval-Evaluierung nutzt zudem nur vier einstufige Modelle (BM25, GTE, mE5, E5-Mistral). Es gibt kein hybrides Retrieval, keine Query Expansion, kein HyDE, keinen Umschreibungsschritt, der speziell auf das Abkürzungsproblem abzielt. Da die Autoren die Abkürzungslücke präzise charakterisiert haben, ist es überraschend, dass sie die naheliegende Lösung nicht testen: die Erweiterung der Abfrage („GOOGL“ → „Alphabet Inc.“) vor dem Retrieval. Dieses Experiment fehlt.

Die Generierungsergebnisse verdienen eine genauere Betrachtung. Die ~9–10 % Leistung ohne Kontext sind keine nützliche Untergrenze – es ist praktisch null –, aber die 60–68 % Oracle-Obergrenze ist informativer als sie scheint. Selbst mit der korrekten Passage in der Hand scheitern die besten Modelle bei etwa einem Drittel der qualitativen Fragen und vier Fünfteln der kompositionellen Arithmetik. Diese Obergrenze ist wichtig: Sie bedeutet, dass Retrieval allein das Problem nicht lösen kann.

Warum das für Finanz-KI wichtig ist

Die Abfrageverteilung in FinDER lässt sich gut darauf übertragen, wie Beancount-Nutzer tatsächlich mit einem Ledger-Agenten interagieren. Ein Nutzer, der seine Konten seit Jahren führt, wird abgekürzte, kontextbezogene Anfragen tippen – „AMZN card Q3 reimb?“ statt „Was sind die Rückerstattungen der Amazon-Kreditkarte im 3. Quartal?“. Standard-Embedding-Modelle werden daran scheitern, die richtigen Einträge abzurufen, da sie auf sauberem, natürlichsprachlichem Text trainiert wurden. Der Präzisionsabfall von 8,2 Punkten von sauberen zu realen Anfragen ist für den Bereich privater Buchhaltung wahrscheinlich noch konservativ geschätzt, wo idiosynkratische Kurzschreibweisen („Hausverw Geb“ für „Hausverwaltungsgebühr“) noch weiter von den Trainingsdaten entfernt sind als SEC-Standardabkürzungen.

Die 25,95 % Recall-Obergrenze bei E5-Mistral ist ein Weckruf: Jede Beancount-RAG-Pipeline muss einen großen Anteil an fehlender Evidenz einkalkulieren. Eine Implikation ist, dass Re-Retrieval mit hohem Recall (mehrere Durchgänge, diversifizierte Abfrageformulierungen) wichtiger ist, als den F1-Wert eines einzelnen Durchgangs zu pushen. Eine weitere ist, dass die Abfragenormalisierung – das Mapping von Nutzer-Kürzeln auf kanonische Kontonamen vor dem Retrieval – ein expliziter Vorverarbeitungsschritt sein sollte und nicht dem Embedding-Modell überlassen werden darf.

Die 20 % Genauigkeit bei kompositioneller Arithmetik selbst mit Oracle-Kontext ist ein separates Signal: Für Beancount-Berechnungsaufgaben ist der Flaschenhals das logische Schließen, nicht das Retrieval. PAL-artiges Offloading (Generierung von Python-Arithmetik statt Freitext-Berechnung) bleibt die richtige Antwort für numerische Aufgaben, ungeachtet dessen, wie gut das Retrieval wird.

Was man als Nächstes lesen sollte

• Fin-RATE (arXiv:2602.07294) – der begleitende Benchmark für mehrperiodiges Tracking in SEC-Einreichungen; die Genauigkeit sinkt bei zeitlichen Aufgaben um 18,60 %, was das mehrjährige Beancount-Ledger-Problem direkt anspricht.
• IRCoT (arXiv:2212.10509, ACL 2023) – Verzahnung von Retrieval mit Chain-of-Thought-Reasoning; die mehrstufige Retrieval-Struktur adressiert direkt den niedrigen Einstufen-Recall, den FinDER aufzeigt.
• Query Expansion mit LLMs für domänenspezifisches Retrieval – noch deckt kein einzelnes Benchmark-Paper dies gut ab, aber die FinDER-Abkürzungslücke macht es zu einer Forschungspriorität erster Ordnung; die Suche nach „HyDE financial domain“ und „query expansion SEC filings 2025“ ist der richtige Ausgangspunkt.