RAG für die Finanzwelt:
Von der Genesis
zur Produktion

Jede RAG-Demo sieht gut aus. Man wirft ein paar PDFs in einen Vector Store, verdrahtet OpenAI-Embeddings, holt die Top-5-Chunks und das LLM produziert eine kohärente Antwort. Fünf Minuten Arbeit. Überzeugender Output.

Dann versucht man dasselbe im regulierten Finanzbereich. Plötzlich muss das Schema, das in zwanzig Minuten entworfen wurde, eine Datenschutz-Folgenabschätzung überstehen.

Die Anforderungen sind konkret:

• Geschäftsberichte, die sich von Jahr zu Jahr semantisch fast identisch lesen.
• DSGVO-Löschpflichten, die durch die gesamte Wissensbasis kaskadieren.
• DORA-Audit-Anforderungen, bei denen jedes Retrieval-Ereignis einen Provenienznachweis braucht.
• MiFID-Eignungsregeln, bei denen eine falsche Portfolioempfehlung ein regulatorisches Ereignis ist, keine schlechte UX.
• Mandantentrennung, die fondsübergreifenden Anfrageangriffen standhalten muss.

Ich baue seit einigen Monaten unter genau diesen Anforderungen, als Teil von Nexqion, einer KI-Plattform für institutionelles Portfoliomanagement. Dieser Artikel zeichnet nach, wie fünf Jahre RAG-Forschung die Architektur geformt haben: vom ursprünglichen Paper aus 2020, das uns den Begriff gab, über die Survey-Papers, die das Feld kartiert haben, bis zu den finanzspezifischen Arbeiten, die offengelegt haben, welche Annahmen unter regulatorischem Druck brechen, und was wir als Antwort darauf gebaut haben.

Akt 1, Genesis

Wo RAG begann

Im Jahr 2020, bevor ChatGPT existierte, veröffentlichten Patrick Lewis und elf Co-Autoren bei Facebook AI Research, in Kooperation mit UCL und NYU, ein Paper mit dem Titel Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Sie versuchten nicht, einen Chatbot zu bauen. Sie versuchten ein anderes Problem zu lösen: Wie gibt man einem Sprachmodell Zugriff auf Fakten, die es aktualisieren, inspizieren und zitieren kann, ohne das Modell jedes Mal von Grund auf neu zu trainieren, wenn sich die Welt verändert?

Ihre Antwort trennte Wissen in zwei Speicher. Der parametrische Speicher sitzt in den Gewichten des Modells. Er ist dicht, opak, teuer zu aktualisieren und anfällig für Halluzinationen, weil das Modell nicht sagen kann, welches Trainingsbeispiel einen bestimmten Output erzeugt hat. Der nicht-parametrische Speicher lebt in einem externen Dokumentenindex. Er ist sparse, transparent, günstig zu aktualisieren, und jedes Retrieval lässt sich auf eine konkrete Quellpassage zurückführen.

Das Killer-Feature im ursprünglichen Paper war nicht die Genauigkeit. Es war ein kleines Experiment, vergraben im Ergebnisteil. Sie bauten einen Wikipedia-Index vom Dezember 2016 und einen weiteren vom Dezember 2018, und stellten dann demselben RAG-Modell Fragen zu Staatsoberhäuptern.

Mit dem 2016er Index: 70 % korrekt bei 2016er Fragen, 4 % bei 2018er Fragen. Mit dem 2018er Index kehrten sich die Zahlen um: 12 % bei 2016er, 68 % bei 2018er. Dasselbe Modell. Anderer Index. Das Weltwissen war hot-swapped worden.

Wenn ein Kunde sein DSGVO-Recht auf Löschung ausübt, löscht man Zeilen aus einer Datenbank, man trainiert kein Modell neu. Wenn sich die Fonds-Performance quartalsweise ändert, ingestiert man neue Run-Zusammenfassungen, man fine-tuned nicht. Wenn ein Regulator fragt, welches Dokument eine bestimmte Empfehlung gegroundet hat, zeigt man auf eine Zeile mit einem Hash. RAG ist nicht nur eine Technik. Es ist die Architektur, deren Eigenschaften, hot-swappable Wissen, nachvollziehbares Retrieval, löschbare Zeilen, den Kontakt mit der EU-Finanzcompliance am saubersten überleben. Andere Architekturen lassen sich compliance-konform machen, aber zu deutlich höheren Kosten.

Akt 2, Proliferation

Fünf Jahre und 100 Papers später

Die fünf Jahre zwischen dem Paper von Lewis et al. und diesem hier waren produktiv. BlackRock hat im vergangenen August eine Multi-Agent-RAG-Architektur für Equity Research ausgeliefert. Altbridge hat im April das Self-Driving-Portfolio-Framework veröffentlicht. Die UZH und die WMO haben ein agentisches RAG-System für Klima-Finance-Tracking produktiv gestellt. Die Forschung hat zu den Anforderungen aufgeschlossen, und das meiste davon weist in dieselbe Richtung.

Im Jahr 2024 veröffentlichten Yunfan Gao und Kollegen an der Tongji-Universität und Fudan einen Survey, der über 100 RAG-Studien sichtet. Ihr Technologiebaum zeigt die Verzweigungen des Feldes, Pre-Training-augmentierte Varianten, Fine-Tuning-augmentierte Varianten, Inferenz-Zeit-Varianten, alle proliferierend, nachdem ChatGPT retrieval-augmentierte Architekturen plötzlich industrierelevant gemacht hatte. Der Survey destilliert drei Paradigmen.

Naïve RAG ist die Demo: BM25- oder TF-IDF-Keyword-Retrieval, statische Datensätze, Retrieve-Read-Workflow. Einfach auszuliefern. Fällt um, sobald irgendetwas semantisches Verständnis erfordert.

Advanced RAG ergänzt Dense Retrieval (DPR), Neural Reranking und Multi-Hop-Retrieval. Hier landen die meisten Produktivsysteme, oder behaupten es zumindest.

Modular RAG zerlegt die Pipeline in komponierbare Bausteine: hybride Sparse-plus-Dense-Retriever, Query-Rewriter, Reranker, Tool-Integrationen, Evaluatoren. Jedes Modul lässt sich austauschen, ohne das gesamte System neu zu bauen.

Gao et al. haben ein Quadrantendiagramm gezeichnet, das in jedem Team, das mit LLMs arbeitet, an der Wand hängen sollte. Eine Achse ist benötigtes externes Wissen; die andere benötigte Modellanpassung. Prompt Engineering sitzt links unten: wenig Wissen, wenig Anpassung. Fine-Tuning sitzt rechts oben: viel Anpassung, Wissen in Gewichten internalisiert. RAG sitzt dazwischen: viel externes Wissen, wenig bis moderate Modellanpassung.

Die meisten Teams behandeln die Wahl zwischen RAG und Fine-Tuning als Entweder-oder. Der Survey macht klar, dass das nicht stimmt. Sie sind komplementär. To, Bui und Le (RAG-IT, arXiv:2412.08179, eingereicht Dezember 2024; letzte Revision Dezember 2025) haben das konkret bewiesen: Sie nutzten ein Teacher-LLM, um 800 Instruction-Q&A-Paare aus gechunkten NVIDIA- und AMD-Earnings-Reports zu generieren, und fine-tuneten dann Llama-2-7b per LoRA auf den generierten Daten. Das fine-getunte Modell erreichte 4,6/10 in der Korrektheit gegen einen unbekannten Broadcom-Earnings-Report, gegenüber 2,8 für das Llama-2-Baseline und 5,3 für GPT-3.5. RAG war nicht die Inferenz-Architektur. RAG war die Datenfabrik.

Für ein privates Finanzmodell, das innerhalb einer Mandantengrenze deployt wird, verändert das die Diskussion. Die Frage ist nicht „RAG oder Fine-Tuning?" Die Frage ist, wo im Quadranten der Use Case lebt, und Finance lebt am hoch-externes-Wissen-und-hoch-Compliance-Ende, wo beide Achsen zählen.

Wir trafen diese Weggabelung in Woche drei beim Bau von Nexqion. Fine-Tuning war auf der Inferenzkosten-Seite verlockend, ein privates Llama-Class-Modell ist pro Turn deutlich günstiger als ein GPT-4o-Aufruf, und ein selbst gehostetes Modell trägt weniger DPA-Nachverhandlungsrisiko als eine externe Embedding-API. Die DSGVO-Löschkosten haben das Vorhaben gekippt, bevor wir die Migration geschrieben hatten: jedes Gewicht, das auf Kundendaten trainiert wurde, ist eine Zeile, die man nicht löschen kann. RAG-als-Datenfabrik ist der spätere Weg; heute trägt der nicht-parametrische Speicher alles.

Akt 3, Wo General-RAG bricht

Fünf Annahmen, die im Finanzbereich versagen

Die meisten RAG-Tutorials bauen auf Annahmen auf, die für allgemeine Wissensbasen funktionieren und im regulierten Finanzbereich brechen. Zu jeder Annahme gibt es einen entsprechenden Forschungsbefund, der die Lücke offenlegt.

Act 4, What the research proves

Die Architekturbefunde, von Anfang bis Ende

Einen Schritt zurück, weg von den gebrochenen Annahmen: worauf konvergiert die jüngste Literatur tatsächlich?

Zur Retrieval-Architektur

Vier Designentscheidungen konvergieren über mehrere unabhängige Papers hinweg:

• Hybrid Sparse+Dense schlägt Dense-only auf langen Finanzdokumenten (Multi-HyDE-Ablation).
• Reciprocal Rank Fusion mit k=60 erscheint bei Cheng et al. (IEEE '26) und EW4All als Fusionsmechanismus für hybrides Sparse+Dense-Retrieval. FinSage konvergiert in dieselbe Sparse+Dense-Richtung, aber über Multi-Path-Retrieval plus Reranking statt explizit über RRF.
• Neural Reranking ist nicht mehr optional, die einzelne Erweiterung mit der höchsten Hebelwirkung in einer Finanz-RAG-Pipeline.
• Adaptive Cutoffs (kumulative Wahrscheinlichkeit ≥55 % oder Score-Cliff-Drop >0,15) verhindern Kontextverdünnung durch naives Top-k.

Die einzelne, am unmittelbarsten umsetzbare Zahl stammt aus der IEEE-März-2026-Ablation. Auf einer hybriden SQLite-FTS5- plus FAISS-Pipeline über 500 S&P-500-10-K-Reports, mit 1.500 Anfragen aufgeteilt auf 5 unabhängige Testgruppen am FinDER-Benchmark, hob das Hinzufügen von JinaReranker v2 (278M Parameter, multilingual) über den Top-30 fusionierten Kandidaten die Korrektheit von 33,5 % auf 49,0 %, ein Plus von 15,5 Prozentpunkten.

Kritische Fehler (Score=1) sanken von 35,3 % auf 22,5 %. Konsistent über alle fünf Testgruppen hinweg. Ohne RAG erreicht GPT-4-Turbo nur 9 % auf demselben Benchmark.

Zur Korpus-Konzeption

Zahlen schlagen Erzählungen. Allgemeine Finanztheorie ist verschwendetes Token-Budget. Quantitative firmenspezifische Kennzahlen sind der höchstwertige Inhalt pro Byte. Qualitative Zusammenfassungen helfen, aber weniger. Das ist der Korpus-Komposition-Befund aus Hornuf et al., und er widerspricht direkt dem, wie die meisten Teams Finanz-RAG-Korpora aufbauen: jedes auffindbare PDF einfach hineinwerfen.

Zu agentischer Architektur, aus der Praxis

BlackRock veröffentlichte AlphaAgents im August 2025 (Zhao, Lyu, Jones, Garber, Pasquali, Mehta). Drei GPT-4o-Agenten, jeder mit eigenem Toolkit:

• Fundamental, 10-K-RAG über die yfinance-API.
• Sentiment, Bloomberg-News mit reflexionsverstärkter Zusammenfassung.
• Valuation, OHLCV-Rechner mit mathematischer Volatilitäts- und Return-Berechnung.

Microsoft AutoGen GroupChat orchestriert eine Round-Robin-Debatte bis zum Konsens. Die Risikotoleranz ist über Role-Prompting eingebettet, risikoavers vs. risikoneutral.

Das risikoneutrale Profil schlug den Equal-Weight-Benchmark in einem 4-monatigen Back-Test über 15 Tech-Aktien. Das risikoaverse Profil schnitt schlechter ab: es schloss zu Recht hochvolatile Aktien aus, die in einem Tech-Bullenmarkt aber genau die Gewinner waren. Eine konkrete Warnung davor, prompt-basiertes Risk-Profiling als ausfallsicher zu behandeln.

Sie beobachteten zudem etwas Subtileres: Risikofreudige und risikoneutrale Prompts produzierten nahezu identische Outputs. Benachbarte Risikoprofile differenzieren sich allein durch Prompt Engineering nicht sinnvoll, ein Befund, der jedes Team, das MiFID-Eignung mit Prompts und Hoffnung baut, dämpfen sollte.

Ang, Azimbayev und Kim (April 2026) treiben dieselbe Architektur deutlich weiter. Ihre Self-Driving Portfolio deployt ~50 spezialisierte Agenten in einer sechsstufigen Pipeline:

1. Macro Agent, Regime-Klassifikation (Expansion / Late-Cycle / Recession / Recovery) mit Konfidenz-Scores.
2. Asset Class Agents, parallel, jeder läuft mehrere CMA-Methoden plus einen CMA-Judge.
3. Covariance Agent, historische Daten plus Makro-Forecasts speisen eine Anlageklassen-Kovarianzmatrix.
4. Portfolio Construction Agents, 20+ Methoden parallel: Equal-Weight, MVO, Risk Parity, HRP, Black-Litterman, Max Diversification, Min Variance, Max Entropy.
5. Strategy Review, Borda-Count-Voting, randomisiertes Peer Review, adversarialer Diversifier, CRO-Risikobewertung.
6. CIO Ensemble, kombiniert Vorschläge; produziert finales Portfolio plus Board-Memo mit abweichenden Meinungen.

Ein Meta-Agent schließt die Feedback-Schleife. Er vergleicht vergangene Forecasts mit realisierten Returns und schreibt Agenten-Code und Prompts neu, um zukünftige Performance zu verbessern.

Zur Governance

Das Self-Driving-Portfolio-Paper führt das Framing ein, das alles zusammenhält. Die Anlagepolitikerklärung (IPS) ist die Operational Design Domain für die Agentenflotte, in Anlehnung an die SAE-J3016-Stufen autonomen Fahrens. L3-Systeme empfehlen innerhalb der IPS-Parameter und benötigen menschliche Freigabe. L4-Systeme arbeiten autonom innerhalb beschränkter Domänen. Das IPS leistet für Portfolio-Agenten, was ein Compliance-Profil für Retrieval-Agenten leistet: es kodiert institutionelle Restriktionen als maschinenlesbare Regeln.

Das hat unsere Sichtweise auf den compliance_profile-Kind in Nexqions Korpus neu eingerahmt. Es sind keine Metadaten, die abgerufen werden, wenn der Nutzer nach Compliance fragt, es ist die Operational Design Domain, die die gesamte Pipeline beschränkt. Die Kinds-Whitelist ist ein Mechanismus, der das durchsetzt; das Audit-Log ein zweiter; der Mandanten-Scope ein dritter. Das IPS-als-ODD-Framing macht es deutlich einfacher, diese Architektur einem Regulator gegenüber zu vertreten.

Akt 5, Implementierung

Was wir bei Nexqion gebaut haben

So sieht dieser konvergierte Stack aus, wenn man ihn tatsächlich ausliefern muss.

Das Nexqion-Produkt ist der Alpha Quant Agent, ein Planungs- und Analysesystem, das über den vollständigen Investmentkontext eines Kunden räsoniert: Fondsstruktur, Performance-Historie, Methodikdokumentation, Compliance-Restriktionen, frühere Report-Bearbeitungen, Kommunikationsstil. Ziel ist es, die Art von Analyse zu generieren, für die normalerweise ein Senior Analyst einen halben Tag braucht, um Quellen zusammenzutragen.

Sein Aufbau erforderte, Stufe für Stufe, eine Antwort darauf, wie eine Glass-Box-RAG-Pipeline unter regulatorischem Druck konzipiert werden sollte. Das Muster, das sich in der jüngsten Literatur abzeichnet, ist ein sechsstufiger Fluss mit drei Compliance-Gates, universell im Skelett, variiert in der Ausprägung. Unterschiedliche Institutionen passen die Gates an ihr Regulierungsregime an; DORA, MiFID, DSGVO und SEC erzwingen jeweils unterschiedliche Designentscheidungen auf demselben Rückgrat.

Reference Architecture, Glass-Box RAG for Regulated Finance

Ein echtes Glass-Box-RAG. Vier strukturierte Quellkategorien, Workflow-Ausgaben, der Datenkatalog (mit expliziten Datenprofilen), die Referenzbibliothek und die Compliance-Konfiguration speisen die Indexing-Pipeline (links, gestrichelt). Anfragen fließen durch einen Intent-Klassifikator und ein Autorisierungs-Gate vor dem Retrieval (rechts, durchgezogen). Hybrides Sparse+Dense-Retrieval (BM25 ⊕ Vektoren via RRF) liefert Top-N-Kandidaten; ein Cross-Encoder-Reranker wählt die Top-K (der +15,5-Prozentpunkte-Korrektheitsgewinn aus der Literatur). Der kindbewusste Context Assembler übergibt dem LLM einen deterministischen, budgetierten Prompt. Jedes Retrieval-Ereignis wird vom Audit-Log erfasst. Compliance-Gates, in Code, nicht in Policy, sitzen am Autorisierungs-Schritt, am mandantengescopten SQL-Filter und an der Audit-Log-Erfassung.

Wie jede Stufe gestaltet sein sollte

Die folgenden Empfehlungen beschreiben, was jede Stufe tun soll und warum. Sie sind das konvergierte Muster der jüngsten Literatur, nicht spezifisch für eine bestimmte Institution.

Stufe	Design-Empfehlung
01	Intent-Klassifikation. Bilde die Nutzeranfrage auf eine endliche, im Code definierte Intent-Aufzählung ab, fünf bis zehn reichen für die meisten Institutionen. Vermeide freies LLM-Routing: ein Compliance Officer muss die Intent-Taxonomie in einer einzelnen Datei lesen und verstehen können, ohne KI-Vorwissen. Liefere Golden-Beispiele pro Intent, damit der Klassifikator testbar ist.
02	Autorisierungs-Gate. Ein fest verdrahtetes Mapping Intent → erlaubte Korpus-Kinds. Im Code definiert, in einer Datei prüfbar, niemals zur Laufzeit von einem LLM entschieden. Das macht aus „welche Korpus-Kinds waren für diesen Nutzer am Datum X zugänglich" eine einzeilige Antwort statt einer unbeantwortbaren Frage. Der Default für einen unbekannten Intent sollte das restriktivste Kind-Set sein, nicht das großzügigste.
03	Query-Embedding. Vektoren auf Einheitslänge normalisieren, damit das Skalarprodukt der Cosinus-Ähnlichkeit entspricht, ohne nachträgliche Renormalisierung. Den Embedding-Aufruf provider-abstrahieren, damit mandantenspezifische Residenz-Overrides (DACH strict, US default, etc.) eine Env-Var-Änderung sind, kein Refactor. Fail-soft bei Provider-Fehlern: zu „keine RAG-Hinweise" degradieren statt einen harten Fehler zurückzugeben.
04	Gescopetes Retrieval. Mandanten-Scope wird auf der Storage-Ebene erzwungen (SQL-WHERE-Klausel, Row-Level-Security oder Äquivalent), nie auf der Anwendungsebene. Anwendungs-Scoping versagt in dem Moment, in dem ein Entwickler eine Query schreibt, die den Filter vergisst. Der Kind-Filter aus Stufe 02 wird zusammen mit dem Scope angewandt. Hybrides Sparse+Dense-Retrieval und ein Neural-Reranker (gemäß IEEE 2026, +15,5 Prozentpunkte) sind die wirkungsstärksten Upgrades, sobald das Basis-Retrieval funktioniert.
05	Context Assembly. Hits nach Kind gruppieren, nicht nach Roh-Score. Einen Pro-Kind-Zeichen- oder Token-Cap anwenden, damit ein einzelner gesprächiger Hit nicht alles andere verdrängt. Kinds in einer Prioritätsreihenfolge rendern, die die Evidenzpräferenzen der Institution kodiert (Hornuf et al.: quantitativ schlägt qualitativ). Unter einem globalen Cap werden die niedrigprioritären Sektionen ganz verworfen statt mittendrin abgeschnitten, das bewahrt Prompt-Cache-Determinismus (gleiche Hits → gleicher String).
06	Geerdete Generierung + Audit. Jedes Retrieval-Ereignis loggen mit: Query-Hash (nicht Rohtext, DSGVO), Mandanten-Schlüsseln (aufgeteilt auf User, Org und Scope), Kinds-Filter, Top-k-Record-IDs, Modell, Latenz, Zeitstempel. Aufbewahrung für das Regulierungsfenster der Institution. Das Audit-Log selbst muss bei einer Mandanten-Löschung löschbar sein, das DSGVO-Recht auf Löschung kaskadiert hindurch, nicht nur durch die Quelldokumente.

Eine konkrete Ausprägung: Wie Nexqion es implementiert

Die Empfehlungen oben sind das Framework. Unten steht eine spezifische Ausprägung: wie der Alpha Quant Agent jede Designfrage heute beantwortet, was er ausliefert und was im nächsten Cycle abgeschlossen wird.

Drei der Designfragen oben sind heute beantwortet; zwei werden im nächsten Cycle abgeschlossen.

Stufe 04, Mandantenisolation auf SQL-Ebene. Der scope_key ist eine Spalte auf jeder Embedding-Zeile, jede Retrieval-Anfrage filtert auf der WHERE-Klausel, und die Postgres-Rolle, die von der API verwendet wird, darf nicht ohne Scope-Prädikat abfragen. Anwendungs-Scoping wurde als Design verworfen, es scheitert in dem Moment, in dem ein Entwickler eine Query schreibt, die den Filter vergisst.

Stufe 03, Fail-soft bei Embedding-Fehlern. Wenn der Embedding-Aufruf aus irgendeinem Grund fehlschlägt, läuft der Planning-Schritt ohne RAG-Hinweise weiter, statt einen harten Fehler zurückzugeben. Der Nutzer bekommt trotzdem eine Antwort, nur eine, die als reduziert kontextualisiert markiert ist. Das spiegelt die EW4All-Self-Healing-Haltung für den Teil-Fehlerfall.

Stufe 05, Kindgruppierte Context Assembly mit Prioritäts-Eviction. Hier lebt das interessanteste Stück laufenden Codes. Hits kommen aus dem Vektor-Retrieval ungruppiert zurück. Der Prompt-Block-Formatter gruppiert sie nach Kind, wendet pro Kind einen Zeichen-Cap an, rendert die Kinds in Prioritätsreihenfolge und erzwingt einen globalen 4-KB-Gesamtcap, indem die niedrigprioritären Sektionen ganz verworfen werden statt mittendrin abgeschnitten.

Eine einzige Datenstruktur regelt das Ganze:

# client_knowledge_base.py, was das 4-KB-Context-Budget regelt
_KIND_DISPLAY = (
    ("org_profile",         "Firm profile",      800),  # höchste Priorität
    ("compliance_profile",  "Compliance",        800),
    ("methodology",         "Methodology",       800),
    ("fund_profile",        "Funds",            1000),
    ("style_sample",        "House style",      1200),
    ("run",                 "Past runs",         700),
    ("report_edit_pattern", "Edit patterns",     500),
    ("dataset_summary",     "Dataset notes",     500),
    ("schedule",            "Schedules",         400),
    ("reference_report",    "Reference packs",   600),  # niedrigste
)
_PROMPT_BLOCK_TOTAL_CAP = 4096

Warum vollständiges Verwerfen niedrigprioritärer Sektionen statt teilweisem Abschneiden? Zwei Gründe. Erstens, Prompt-Cache-Determinismus, dieselbe Hit-Menge muss in jedem Turn denselben Context-String produzieren, damit OpenAIs Prompt-Cache weiter trifft; Teil-Trunkierung erzeugt fast-identische-aber-nicht-identische Strings in jedem Turn und zerstört den Cache. Zweitens, eine teilweise abgeschnittene Methodology-Sektion verwirrt den Planner mehr als das vollständige Weglassen einer geringer-signalisierten Schedule-Sektion.

Hornuf et al.'s Befund, dass quantitative firmenspezifische Daten qualitative Erzählungen schlagen, ist direkt in die Prioritätsreihenfolge kodiert: fund_profile und compliance_profile stehen oben; style_sample und reference_report unten. Der Korpus ist kein flacher Beutel von Chunks. Er ist ein budgetiertes, prioritätsgeordnetes, deterministisches Ledger.

Stufen 01–02, Intent-Klassifikation und Autorisierungs-Gate. Das ist der Cycle-8-Abschluss. Die Datenstruktur steht, ein deterministisches Intent → Kinds-Mapping in einer Datei, und die Storage-Schicht akzeptiert bereits einen kind-Filter. Was bleibt, ist der Orchestrator, der die richtige Liste in den Retrieval-Aufruf übergibt. Cycle 8.

# client_knowledge_base.py, der Cycle-8-Abschluss
KINDS_BY_INTENT: dict[ChatIntent, list[CorpusKind]] = {
    "performance":   ["run", "fund_profile", "dataset_summary"],
    "compliance":    ["compliance_profile", "org_profile", "methodology"],
    "methodology":   ["methodology", "fund_profile", "reference_report"],
    "narrative":     ["style_sample", "report_edit_pattern", "reference_report"],
    "attribution":   ["run", "methodology", "fund_profile"],
}

Die Roadmap, in Zahlen verankert

Vier Änderungen folgen direkt aus den Befunden oben:

• 1
  Wechsel IVFFlat → HNSW, sobald die Mandantengröße die Index-Schwelle übersteigt. Heute wird IVFFlat lazy angelegt, sobald ein Mandant ≥1.000 Vektoren hat, mit lists skaliert auf min(sqrt(count), 100); darunter führen wir Sequential-Scan innerhalb des Scopes durch, was ohnehin schneller ist. Das ist für die heutige Skalierung korrekt, aber suboptimal, sobald Mandanten 10.000+ Vektoren erreichen. HNSW ist bei jeder Größe unter 100.000 Zeilen genauer bei vergleichbarer Query-Latenz. pgvector unterstützt HNSW seit v0.5.0.
• 2
  Neural Reranking ergänzen, JinaReranker v2. Die IEEE-März-2026-Ablation macht den Fall eindeutig: +15,5 Prozentpunkte Korrektheit aus einem einzigen Cross-Encoder-Pass über die Top-30-Kandidaten. 278M Parameter, multilingual (108 Sprachen, relevant für DACH-Mandanten). Adaptive Cutoffs (kumulative Wahrscheinlichkeit ≥55 % oder Score-Cliff >0,15) verhindern Kontextverdünnung.
• 3
  Hybrid BM25 + Vektor mit RRF implementieren. Reine Cosinus-Ähnlichkeit verliert bei Exact-Match-Terminologie, Fondsnamen, ISIN-Codes, Regulierungsreferenzen, KPI-Labels. Die RRF-Formel 1/(60 + r_FTS) + 1/(60 + r_semantic) ist direkt gegen den vorhandenen pgvector- plus Postgres-FTS-Stack implementierbar.
• 4
  Den Evaluation-Harness aufbauen. Ohne eine Möglichkeit, Recall@5, MRR und Faithfulness gegen Held-Out-Nutzersessions zu messen, ist jede Änderung oben unsichtbar. Das ist die Voraussetzung für alles andere. Das Metrik-Framework aus FinSage (Faithful Evaluation, Mean Score, Pass Rate, Response Time) ist die Vorlage.

Wohin das geht

Das Framing des Self-Driving-Portfolio-Papers ist die Trajektorie. Die Anlagepolitikerklärung ist die Operational Design Domain für eine Agentenflotte. Das Compliance-Profil bei Nexqion ist dieselbe Konstruktion eine Schicht darunter, es beschränkt die Retrieval- und Analyse-Agenten so, wie ein IPS eine Portfolio-Konstruktions-Agentenflotte beschränkt.

Glass-Box-Modular-RAG mit Intent-Whitelists, Scope-keyed-Mandanten, Evidenz-Grounding, Audit-Trail-Retrieval-Logging und Fail-soft-Degradation ist keine Einschränkung dessen, was wir bauen können. Es ist genau das, was das System vertrauenswürdig genug macht, um es einem Fondsmanager vorzulegen. Die technische Infrastruktur und die Compliance-Haltung sind dasselbe.

Die Architektur ist governet. Die Roadmap ist konkret. Was diesem Beitrag bewusst fehlt: die Runtime-Zahlen. Wir veröffentlichen Mandantenzahl, Vektorzahl oder p95-Retrieval-Latenz erst, wenn der Evaluation-Harness in Ausgabe 05 diese Messungen ehrlich macht. Ein „Von der Genesis zur Produktion"-Artikel ohne Messungen wäre Marketing; den Titel verdienen wir uns lieber in der nächsten Ausgabe, statt ihn jetzt zu beanspruchen.