GraphRAG: wenn 'wer hält was' deterministische mehrstufige Traversierung verlangt

Jeder Portfoliomanager hat schon einen Nachmittag vor einem Bloomberg-DRSK- oder CRPR-Screen verbracht und sich durch eine eingerückte Emittentenhierarchie gearbeitet: oben der Ultimate Parent, in der Mitte zwischengeschaltete Holdcos, unten die operativen Tochtergesellschaften, die tatsächlich die Anleihen begeben. Dieser Baum ist seit dreißig Jahren die Form, in der Counterparty-Look-Through funktioniert. Er ist nüchtern, monospaced und strukturell ehrlich: Parent, Child, Kante, Kantentyp.

GraphRAG ist derselbe Baum, nur abfragbar gemacht durch ein Sprachmodell, ohne die Struktur aufzugeben. Konventionelles RAG verflacht einen Korpus zu einem Vektorspeicher und lässt Ähnlichkeit die Arbeit machen; die Emittentenhierarchie verschwindet in einer Suppe von Absätzen. GraphRAG macht das Gegenteil. Es bewahrt die Hierarchie als erstklassiges Objekt - typisierte Knoten (Issuer, Parent, Subsidiary, Fund, Covenant, LEI) und typisierte Kanten (owns, guarantees, holds, defaults_under) - und verlangt vom Sprachmodell, am richtigen Knoten in den Graphen einzutreten und von dort einen deterministischen Pfad zu gehen. Das Modell läuft dabei innerhalb des Haus-Perimeters; DORA Art. 28-30 gilt für den Inferenz-Stack, nicht für eine externe API.

Die Literaturbrücke ist exakt: eine eingerückte Bloomberg-Hierarchie ist ein Graph, ausgelegt als Tabelle. GraphRAG hebt die Tabelle nur von der Seite ab, sodass 'liste jeden meiner Fonds auf, der gegenüber einer Tochter exponiert ist, deren Parent eine Covenant-Verletzung aufweist' zu einer Traversierung wird und nicht mehr zu einem Absatz-Match.

Microsoft Research hat GraphRAG 2024 formalisiert (Edge et al., arXiv:2404.16130). Die Pipeline hat fünf mechanische Stufen, und keine davon ist Dekoration. Erstens wird der Korpus - Prospekte, KIIDs, Factsheets, IC-Memos, Counterparty-Vereinbarungen - in Chunks zerlegt. Zweitens extrahiert ein Sprachmodell typisierte Entitäten und typisierte Relationen aus jedem Chunk und liefert eine Knoten- und Kantenliste. Drittens werden diese Knoten zu einem einzigen Graphen zusammengeführt und dedupliziert. Viertens partitioniert der Leiden-Algorithmus zur Community-Detection (Traag, Waltman, van Eck, 2019) den Graphen in hierarchische Communities - Cluster dicht verbundener Knoten, dann Cluster von Clustern. Fünftens wird jede Community rekursiv zusammengefasst, niedrige Ebenen unten, breitere Zusammenfassungen oben.

Zur Abfragezeit teilt sich das System in zwei Modi. Lokale Abfragen ('welche meiner Fonds halten Anleihen der Töchter von Emittent X?') verankern sich an einem Knoten, durchlaufen eine kleine typisierte Nachbarschaft und geben die passenden Triples zurück. Globale Abfragen ('was sind die drei größten Konzentrationsrisiken im Buch?') berühren nie Rohtext - sie mappen auf einer gewählten Hierarchieebene über die Community-Zusammenfassungen und reduzieren. Vektorsuche ist weiterhin vorhanden, ihre Aufgabe reduziert sich aber darauf, den richtigen Eintrittsknoten in den Graphen zu finden; ab dort ist die Traversierung deterministisch. Was im LLM-Kontext landet, ist ein kleiner, benannter, auditierbarer Subgraph - keine unscharfe Absatzwolke.

Das Ganze läuft innerhalb des Haus-Perimeters. Der Graph-Store, der Embedding-Index, die Community-Zusammenfassungen und das Sprachmodell, das die Extraktion und die finale Synthese leistet, liegen alle auf Infrastruktur, die das Haus kontrolliert - DORA Art. 28-30 ICT-Drittparteienregister findet Anwendung, und kein Prompt und kein Chunk überschreitet die Grenze zu einem öffentlichen Modellanbieter. Die Daten bleiben im Haus.

Nehmen Sie die AIFMD-Anhang-IV-Look-Through-Pflicht. Die Aufsicht will wissen, gegenüber was Ihr Fonds tatsächlich exponiert ist, drei Sprünge unterhalb der Headline-ISIN: der Emittent hinter der Anleihe, der Parent hinter dem Emittenten, der Sektor und das Land hinter dem Parent. Ein flacher Vektorspeicher kann diese Traversierung nicht garantieren - er liefert Absätze, die Dinge erwähnen, nicht Kanten, die sie verbinden. Ein typisierter Graph kann es: drei Sprünge sind drei Kantenfolgen, und der resultierende Subgraph ist die Antwort.

Dieselbe Form gilt für die MiFID-II-Geeignetheit (passt dieses Produkt zum Exposure-Profil des Kunden, gegeben alles Übrige, was er hält?), für ESMA-Look-Through bei Dachfonds und für interne Konzentrationsrisiko-Überwachung über Counterparties hinweg. In jedem Fall ist die Frage strukturell, nicht textuell. GraphRAG ist das Retrieval-Muster, das die Struktur respektiert.

Der operative Anker ist, dass der für jede Abfrage zurückgegebene Subgraph selbst ein Audit-Artefakt ist: eine Menge typisierter Knoten und Kanten mit Provenienz zurück zum Quelldokument. Das Sprachmodell zitiert den Pfad, den es gegangen ist, nicht nur die Dokumente, die es berührt hat. Lokale Inferenz innerhalb des Perimeters hält Prompts, Completions und den Graphen selbst aus jedem externen System heraus.

AIFMD Anhang IV verlangt von Fondsmanagern eine Berichterstattung über Look-Through-Exposures; die ESMA-Leitlinien zu Dachfonds erweitern dieselbe Logik; MiFID II Art. 25 stellt dieselbe Anforderung aus der Geeignetheitsperspektive. Alle drei Regime verlangen, dass die Ketten von Eigentümerschaft und Exposure auf Anforderung rekonstruierbar sind. Der Kontrakt typisierter Kanten von GraphRAG liefert diese Rekonstruktion als deterministischen Walk über ein gespeichertes Objekt - nicht als Absatzsuche.

Der DORA-Rahmen nach Art. 28-30 ist die zweite Hälfte des Aufsichtsarguments. Weil der Graph-Store, die Leiden-Partitionierung und das Sprachmodell, das darüber operiert, alle auf Infrastruktur innerhalb des Haus-Perimeters sitzen, ist das Drittparteienrisiko-Register für diese Fähigkeit kurz. Kein Prompt, kein Chunk, keine Community-Zusammenfassung verlässt die Grenze. Die Audit-Spur ist eine der Ausgaben des Systems, kein nachträglich aufgeschraubtes Feature.

Stellen Sie das nicht als bunten Netzwerk-Ball mit undifferenzierten Knoten und unbeschrifteten Kanten dar. Das ist das Fraud-Detection-Demo-Idiom von Quantexa und Palantir, und PMs werden es innerhalb von drei Sekunden mental unter Marketing-Geschwätz ablegen. Der Graph hat eine Struktur - typisierte Knoten, typisierte Kanten, hierarchische Communities - und die Visualisierung muss diese Struktur zeigen. Ein Haarknäuel löscht den gesamten Beitrag aus.

Eröffnen Sie nicht mit einem Cypher-Screenshot. Cypher ist eine Abfragesprache auf Speicherebene; sie schreckt nichttechnische Käufer in Sekunden ab und signalisiert 'das ist ein IT-Problem' - der falsche Rahmen. Den Käufer interessiert die Look-Through-Pflicht, nicht die Syntax, die sie unterstützt. Beginnen Sie mit der Hierarchie, die er wiedererkennt, und decken Sie den Graphen darunter erst danach auf.

Reduzieren Sie GraphRAG nicht zu einem flachen Links-rechts-Sankey mit dem Label 'GraphRAG'. Mehrere Anbieterdecks machen das; es verbirgt den Graphen vollständig. Der Graph IST die Methode. Und stellen Sie schließlich Community-Detection nicht als Clustering von Embeddings dar - Leiden operiert auf Graphstruktur, nicht auf Vektorraum, und beides zu vermengen verkennt, was der Algorithmus tatsächlich tut und warum er auditierbare Partitionen liefert statt weicher k-Means-Klekse.