Wie wir ein Multi-Agent-RAG-System für regulatorische Audits gebaut haben, ein offizielles Peer Review bekommen haben – und warum wir jetzt eine Pilot-Evaluation nachschieben.
TL;DR
FinRegAgents ist ein Open-Source-Framework, das regulatorische Prüfungen (GwG, DORA, MaRisk, WpHG) mit KI-Agenten simuliert. Das Paper wurde auf aiXiv veröffentlicht und hat ein offizielles Peer Review durchlaufen. Die Reviewer fanden die Architektur überzeugend – forderten aber empirische Evaluation. Diesen Beitrag schreibe ich, um den Prozess transparent zu dokumentieren: von der Idee über das Review bis zur Pilot-Evaluation, die wir jetzt bauen.
1. Das Problem: Warum regulatorische Audits ein RAG-Problem sind
Finanzregulierung ist ein Dokumentenproblem. Wenn die BaFin eine Sonderprüfung durchführt, prüft sie hunderte Dokumente gegen hunderte Prüffelder. Das ist im Kern das, was Retrieval-Augmented Generation (RAG) kann: Dokumente suchen, gegen Kriterien abgleichen, Ergebnisse generieren.
Aber Standard-RAG reicht nicht. Wir haben drei fundamentale Probleme identifiziert:
- P1 – Halluzination auf dünner Evidenz: Wenn der Retriever nur marginal relevante Chunks findet, generiert das LLM trotzdem eine selbstbewusste Bewertung. In der Regulatorik ist das fatal – ein falsch-positives „konform“ kann Sanktionen nach sich ziehen.
- P2 – Fehlende Konfidenz-Quantifizierung: Standard-RAG gibt keine Information darüber, wie sicher eine Bewertung ist. Ein Prüfer braucht aber genau das, um zu entscheiden, welche Befunde er manuell nachprüfen muss.
- P3 – Strukturelle Inkonsistenzen: LLMs zitieren Quellen, die nicht existieren (Phantom-Quellen), lassen Platzhalter stehen, oder bewerten „konform“ ohne Belege.
2. Die Architektur: Dreischichtige Validierung
FinRegAgents löst diese Probleme mit einer dreischichtigen Validierungsarchitektur:
Layer 1: Retrieval Quality Gate
Vor der LLM-Bewertung prüft ein Score-Threshold (0.35), ob die gefundenen Dokumente überhaupt relevant genug sind. Unter dem Threshold wird automatisch nicht_prüfbar vergeben – das System sagt ehrlich „Ich habe keine ausreichende Evidenz“, statt zu halluzinieren.
Layer 2: Composite Confidence Score
Vier gewichtete Signale ergeben einen Confidence-Score zwischen 0.0 und 1.0:
confidence = 0.30 × retrieval_score # Relevanz der Chunks
+ 0.30 × evidence_coverage # Abdeckung erwarteter Evidenz
+ 0.20 × type_match # Stimmen Dokumenttypen?
+ 0.20 × llm_self_assessment # Selbsteinschätzung des ModellsUnter 0.40: automatisch nicht_prüfbar. Zwischen 0.40 und 0.70: manuelles Review markiert. Über 0.70: Befund wird in den Bericht aufgenommen.
Layer 3: Strukturelle Validierung
Bevor ein Befund in den Bericht eingeht, prüft das System: Werden nur tatsächlich gefundene Quellen zitiert? Gibt es unaufgelöste Platzhalter? Passt die Bewertung zur Begründung (kein Mangel-Text bei „konform“, Mangel-Text bei „nicht_konform“)?
3. Der Coverage–Verification Gap
Unser konzeptioneller Hauptbeitrag: Der Coverage–Verification Gap beschreibt die systematische Diskrepanz zwischen der Fähigkeit eines Systems, Bewertungen zu produzieren, und seiner Fähigkeit, diese zu verifizieren.
Konkret: Ein RAG-System kann für 94 Prüffelder Bewertungen generieren – aber die Qualität dieser Bewertungen korreliert stark mit der Retrieval-Qualität, und die variiert von Prüffeld zu Prüffeld enorm. Das Konzept zieht Parallelen zur Ad-Tech-Fraud-Detection, wo ähnliche Verification Gaps existieren.
4. Das Peer Review: Was die Reviewer sagten
Das Paper wurde auf aiXiv eingereicht und hat ein offizielles Review durchlaufen. Hier die Kurzfassung:
Was gut ankam
- Die Problemformulierung (P1–P3) wurde als überzeugend bewertet
- Die dreischichtige Validierungsarchitektur als „thoughtful technical response“
- Der Coverage–Verification Gap als „significant conceptual advance“
- Praxistaugliches Design, Transparenz, Open-Source-Veröffentlichung
Der zentrale Kritikpunkt
Keine empirische Evaluation. Das war erwartbar – wir hatten das in Section 7 des Papers ehrlich als Limitation benannt. Die Reviewer fordern konkret:
- Einen Benchmark-Datensatz mit synthetischen Compliance-Dokumenten und Expert-Labels
- Eine Ablation Study für die Confidence-Weights (0.30/0.30/0.20/0.20)
- Einen Baseline-Vergleich: FinRegAgents vs. Standard-RAG ohne Validation Layers
- Metriken: Precision/Recall, Hallucination-Rate, Confidence-Calibration-Plots
- Threshold-Sensitivitätsanalyse (0.35 Retrieval Gate)
Die Kritik ist fair und konstruktiv. Für eine v1.1-Revision gibt es zwei Optionen: A) Das Paper als reinen Architektur- und Konzeptbeitrag reframen, oder B) eine Pilot-Evaluation bauen. Wir haben uns für B entschieden.
5. Die Pilot-Evaluation: Was wir bauen
Unsere Evaluation adressiert jeden einzelnen Punkt der Reviewer. Hier der Aufbau:
Benchmark-Datensatz
32 synthetische Compliance-Cases über alle 4 Regulatoriken (GwG, DORA, MaRisk, WpHG), mit jeweils 8 Cases pro Regulatorik. Jeder Case enthält:
- Synthetische Compliance-Dokumente mit kontrolliertem Inhalt
- Ein erwartetes Assessment-Label (Ground Truth)
- Einen erwarteten Confidence-Bereich
- Eine Szenario-Kategorie: clear compliance, non-compliance, partial compliance, insufficient evidence, adversarial hallucination
Die „adversarial hallucination“-Cases sind besonders spannend: Dokumente, die die richtige Terminologie verwenden, aber keine substanzielle Evidenz enthalten. Beispiel: Ein Geschäftsbericht, der „Business Continuity Management ist ein strategischer Schwerpunkt“ schreibt, aber keinen BCM-Plan enthält. Hier zeigt sich, ob das System halluziniert oder ehrlich nicht_prüfbar vergibt.
Drei Baselines
- Standard RAG – Direkte LLM-Bewertung auf Retrieved Chunks, ohne jede Validierung
- RAG + Confidence – Mit Confidence-Scoring, aber ohne strukturelle Validierung
- FinRegAgents (Full) – Komplettes System mit allen drei Validierungsschichten
Ablation Study
Sechs Konfigurationen testen die Sensitivität der Confidence-Weights und des Retrieval-Thresholds:
| Konfiguration | Retrieval | Coverage | Type | LLM | Gate |
|---|---|---|---|---|---|
| Baseline (Paper) | 0.30 | 0.30 | 0.20 | 0.20 | 0.35 |
| Retrieval-Heavy | 0.50 | 0.25 | 0.10 | 0.15 | 0.35 |
| LLM-Heavy | 0.20 | 0.20 | 0.10 | 0.50 | 0.35 |
| Uniform | 0.25 | 0.25 | 0.25 | 0.25 | 0.35 |
| Low Gate | 0.30 | 0.30 | 0.20 | 0.20 | 0.20 |
| High Gate | 0.30 | 0.30 | 0.20 | 0.20 | 0.50 |
Metriken
- Classification Accuracy – Exakter Match zwischen Prediction und Ground Truth
- Per-Label F1 – F1 pro Assessment-Kategorie (konform, teilkonform, nicht_konform, nicht_prüfbar)
- Hallucination Rate – Anteil der Fälle, in denen das System mit hoher Konfidenz (≥0.6) falsch bewertet
- Adversarial Detection Rate – Korrekte Klassifikation der Hallucination-Trap-Cases
- Confidence Calibration – Korrelation zwischen vorhergesagter Konfidenz und tatsächlicher Korrektheit (Reliability Diagram)
- Review Flag Precision – Wie oft ist ein Review-Flag tatsächlich gerechtfertigt?
6. Preliminary Results (Dry-Run)
Unsere Framework-Demonstration (Dry-Run mit simulierten Predictions) zeigt die erwarteten Muster:
| System | Accuracy | Halluc. Rate | Adversarial Det. |
|---|---|---|---|
| FinRegAgents (Full) | 96.9% | 3.1% | 100.0% |
| RAG + Confidence | 68.8% | 21.9% | 50.0% |
| Standard RAG | 43.8% | 28.1% | 25.0% |
Hinweis: Das sind simulierte Ergebnisse, die das Framework demonstrieren. Die echten Ergebnisse mit API-Calls werden in der v1.1-Revision des Papers erscheinen.
Die Muster sind aber plausibel: Standard-RAG ohne Validierung hat erwartungsgemäß die höchste Halluzinationsrate (28.1%), weil es keine Mechanismen gibt, um unsichere Bewertungen zu erkennen. FinRegAgents‘ Retrieval Quality Gate und strukturelle Validierung fangen genau diese Fälle ab.
7. Lessons Learned: Was ich beim Bau von FinRegAgents über AI-Assisted Auditing gelernt habe
RAG allein reicht nicht
Das zentrale Learning: Die Validierungsschicht ist mindestens so wichtig wie das Retrieval selbst. Ein RAG-System, das relevante Chunks findet und daraus eine Bewertung generiert, ist erst der Anfang. Die Frage ist: Wie verhinderst du, dass das System Bewertungen abgibt, für die es keine ausreichende Evidenz hat?
Konfidenz ist kein Luxus
Für regulatorische Anwendungen ist Konfidenz-Scoring kein Nice-to-Have, sondern eine Grundvoraussetzung. Ein Prüfer, der die Ergebnisse eines AI-Systems nutzt, muss wissen: Bei welchen Befunden kann ich mich auf das System verlassen, und welche muss ich manuell prüfen?
Open Source als Qualitätsmerkmal
Dass wir das System unter Apache 2.0 veröffentlicht haben, war eine bewusste Entscheidung. In der Regulatorik ist Transparenz nicht optional – Prüfer müssen nachvollziehen können, wie ein Ergebnis zustande kommt. Open Source ermöglicht genau das.
Peer Review macht das Paper besser
Die Reviewer hatten Recht: Ein System ohne Evaluation ist ein Architekturvorschlag. Die Pilot-Evaluation, die wir jetzt bauen, macht FinRegAgents von einer Idee zu einem validierten Tool. Das Review hat den Impuls gegeben, den wir brauchten.
8. Was kommt als Nächstes
Unsere Roadmap für die nächsten Wochen:
- v1.1 Paper Revision – Evaluation Section einbauen, alle Reviewer-Punkte adressieren
- Echte API-Runs – 32 Benchmark-Cases mit Claude Sonnet durch alle 3 Baselines fahren
- Community-Feedback – Wir suchen aktiv nach Feedback von Compliance-Experten und AI Engineers, die das Framework in der Praxis testen wollen
Das Repo ist öffentlich: github.com/endvater/finreg-agents
Das Paper: aiXiv – FinRegAgents
Dieser Beitrag dokumentiert die laufende Arbeit an FinRegAgents. Feedback, PRs und Issues sind willkommen.
