Wie Enterprise-RAG lernt, Zusammenhänge zu verstehen

Begriffe in Kürze

Knowledge Graph: Ein Graph aus Entitäten und Beziehungen, etwa Policy, Prozess, System, Owner und Dokumentquelle. Er macht explizit, wie Informationen zusammenhängen.

GraphRAG: Retrieval-Augmented Generation, bei der neben semantischer Suche auch ein Knowledge Graph zur Kontextfindung, Pfadverfolgung und Antwortbegründung genutzt wird.

Multi-Hop-Frage: Eine Frage, die nicht in einem einzelnen Absatz beantwortet werden kann, sondern mehrere Beziehungsschritte braucht, zum Beispiel von einer Richtlinie über einen Prozess zu einem verantwortlichen System.

Vector Search: Semantische Suche über Embeddings. Sie findet ähnliche Inhalte auch dann, wenn Nutzer andere Wörter verwenden als das Quelldokument.

RRF/Fusion: Reciprocal Rank Fusion kombiniert mehrere Ergebnislisten, etwa Vektor- und Graph-Treffer, über ihre Rangpositionen statt über schwer vergleichbare Rohscores.

Permission-Aware Retrieval: Retrieval, das Berechtigungen vor der Kontextübergabe an das Modell berücksichtigt. Nicht erst die Antwort wird gefiltert, sondern der abrufbare Kontext.

Ein Vertriebsleiter fragt die interne KI: "Darf ich einem strategischen Kunden im laufenden Quartal 18 Prozent Sonderrabatt geben, und wer muss das freigeben?"

Eine gute Antwort braucht mehr als einen passenden Absatz aus einer Rabatt-Policy. Sie muss den gültigen Policy-Stand finden, den Freigabeprozess erkennen, das betroffene System nennen, den Owner identifizieren, die Quelle belegen und prüfen, ob der Fragesteller diese Informationen überhaupt sehen darf. Der belastbare Pfad sieht ungefähr so aus:

Policy -> Prozess -> System -> Owner -> Quelle -> Berechtigung.

Genau an dieser Stelle trennt sich Enterprise-RAG von einer angenehmen Chat-Oberfläche. In Unternehmen reicht es nicht, dass eine Antwort plausibel klingt. Sie muss nachvollziehbar sein: Welche Beziehung wurde traversiert? Aus welcher Quelle stammt sie? Seit wann gilt sie? Wie sicher ist die Extraktion? Und durfte dieser Nutzer diesen Kontext sehen?

Vector Search ist dafür eine starke Eingangstechnologie. Sie findet Kandidaten, gleicht Sprachvarianten aus und skaliert gut über große Dokumentbestände. Aber verantwortbare Enterprise-Antworten brauchen zusätzlich prüfbare Beziehungspfade. Der Knowledge Graph ist nicht die Ablösung der Vektorsuche. Er ist die Struktur, die aus ähnlichen Chunks belastbare Zusammenhänge macht.

Warum ähnliche Chunks nicht genügen

Klassisches RAG beginnt mit einer Suchfrage, findet semantisch ähnliche Textstücke, gibt diese als Kontext an ein Sprachmodell und lässt daraus eine Antwort formulieren. Für viele Wissensfragen ist das erstaunlich wirksam. "Wo steht die Reisekostenregelung für Bahnfahrten?" oder "Welche SLA-Klassen gibt es im Supportvertrag?" sind typische Fälle, in denen Vector Search sehr gut funktioniert.

Enterprise-Fragen sind aber häufig keine reinen Fundstellenfragen. Sie sind Beziehungsfragen. Wer ist fachlich verantwortlich? Welche Policy überschreibt welche ältere Regelung? Welches System führt den Prozess aus? Welche Ausnahme gilt nur für eine Region? Welche Quelle ist neuer? Welche Antwort darf ein externer Dienstleister sehen?

Ein Chunk kann diese Zusammenhänge andeuten. Er muss sie aber nicht vollständig enthalten. Noch schwieriger: Zwei Chunks können jeweils korrekt sein und zusammen trotzdem eine falsche Antwort nahelegen, wenn Gültigkeit, Zuständigkeit oder Berechtigung nicht berücksichtigt werden.

Das Problem ist nicht, dass Vector Search schlecht wäre. Das Problem ist, dass Ähnlichkeit keine Beziehung ist. Ein Treffer kann semantisch nah sein und trotzdem den falschen Prozessstand, die falsche Organisationseinheit oder eine veraltete Quelle repräsentieren.

Der Beziehungspfad als Architekturprinzip

Für Enterprise-RAG sollte eine Antwort intern nicht nur aus Text bestehen, sondern aus einem erklärbaren Retrieval-Pfad. Der Pfad beschreibt, welche Entitäten und Beziehungen zur Antwort geführt haben:

flowchart LR
    Q["Nutzerfrage<br/>Sonderrabatt 18%"] --> P["Policy<br/>Discount Policy v4"]
    P --> R["Prozess<br/>Deal Desk Approval"]
    R --> S["System<br/>CRM / CPQ"]
    S --> O["Owner<br/>Revenue Operations"]
    O --> D["Quelle<br/>Policy-Dokument, Prozessseite, Ticket"]
    D --> A["Berechtigung<br/>Tenant, Projekt, Rolle, Dokumentrecht"]

Dieser Pfad ist nicht nur für die Antwortqualität nützlich. Er ist für Governance entscheidend. Ein Auditor fragt nicht: "Welcher Chunk hatte Score 0,83?" Er fragt: "Warum hat das System diese Antwort gegeben, auf welcher gültigen Quelle basiert sie, und durfte der Nutzer sie erhalten?"

Ein Knowledge Graph bildet genau diese Zwischenschritte ab. Policies, Prozesse, Systeme, Rollen, Personen, Dokumente, Projekte und Themen werden zu Knoten. Beziehungen wie IMPLEMENTS, OWNS, SUPERSEDES, REFERENCES, APPROVES oder EXTRACTED_FROM werden zu Kanten. Aus Retrieval wird damit kein freies Assoziieren, sondern eine nachvollziehbare Traversierung.

Was ein Knowledge Graph im RAG-Kontext ergänzt

Ein Knowledge Graph ergänzt vier Eigenschaften, die in reiner Vektorsuche nur indirekt vorhanden sind.

Erstens macht er Beziehungen explizit. Ein Graph kann abbilden, dass eine Policy einen Prozess steuert, ein Prozess in einem System ausgeführt wird und ein Owner für Ausnahmen zuständig ist. Das ist etwas anderes als drei ähnlich klingende Absätze nebeneinanderzulegen.

Zweitens trägt er Provenance. Eine Entität sollte nicht einfach "Revenue Operations" heißen. Sie sollte wissen, aus welchen Chunks, Dokumenten oder Systemen sie extrahiert wurde. Das macht Antworten zitierbar und überprüfbar.

Drittens kann er Validity modellieren. Viele Unternehmensinformationen sind nur in bestimmten Zeiträumen, Regionen, Rollen oder Produktlinien gültig. Gültigkeitsdaten, Versionen und Überschreibungsbeziehungen sind klassische Graph-Informationen.

Viertens kann er Confidence führen. Entity Extraction und Relation Extraction sind nicht perfekt. Ein professionelles System sollte daher unterscheiden, ob eine Beziehung aus einer strukturierten Quelle stammt, von einem LLM extrahiert wurde, mehrfach bestätigt ist oder nur schwach belegt wurde.

Damit wird der Graph nicht zu einem Wahrheitsorakel. Er ist eine prüfbare Struktur über Quellen, Beziehungen und Unsicherheit. Gerade diese Nüchternheit macht ihn enterprise-tauglich.

Hybrid Retrieval: Vektor zuerst, Graph daneben

Die robuste Architektur ist meist kein Entweder-oder. Sie ist ein dualer Retrieval-Pfad.

Vector Search findet Kandidaten, weil Nutzer selten so fragen, wie Dokumente geschrieben sind. Der Graph sucht oder erweitert entlang expliziter Beziehungen. Anschließend werden beide Ergebnislisten zusammengeführt, dedupliziert, berechtigt gefiltert und für die Antwortgenerierung vorbereitet.

flowchart TB
    Q["Nutzerfrage"] --> V["Vector Search<br/>semantische Kandidaten"]
    Q --> E["Entity Recognition<br/>Policy, System, Owner"]
    E --> G["Graph Traversal<br/>1-3 Hops entlang typisierter Beziehungen"]
    V --> F["Fusion / RRF<br/>Ranglisten kombinieren"]
    G --> F
    F --> P["Permission-Aware Filtering<br/>Tenant, Projekt, Dokument, Rolle"]
    P --> C["Kontextpaket<br/>Chunks + Beziehungspfade + Quellen"]
    C --> L["Antwortgenerierung"]
    L --> A["Antwort<br/>mit Quellen, Pfad und Grenzen"]

RRF, also Reciprocal Rank Fusion, ist dafür attraktiv, weil es Ergebnislisten über Rangpositionen kombiniert. Das ist praktischer als Rohscores direkt zu mischen: Ein Vektor-Score, ein Graph-Score und ein Reranker-Score sind nicht automatisch auf derselben Skala. In der Literatur und in vielen Retrieval-Systemen ist ein RRF-Konstantwert um k=60 ein verbreiteter Ausgangspunkt. In produktiven Enterprise-Setups sollte dieser Wert trotzdem als Konfiguration und nicht als Naturgesetz behandelt werden.

Der entscheidende Punkt: Vector Search bleibt die Candidate-Findung. Der Graph macht die Beziehungen prüfbar. Fusion sorgt dafür, dass beide Stärken in einer Antwort zusammenkommen.

Wie GraphRAG beim Indexieren entsteht

GraphRAG beginnt nicht erst bei der Nutzerfrage. Der wichtigste Teil passiert vorher, während der Ingestion.

Dokumente werden aus Quellen wie SharePoint, Confluence, Google Drive, Jira, Datenbanken oder Dateiablagen gelesen. Danach werden sie bereinigt, in Chunks zerlegt, mit Metadaten versehen und für semantische Suche eingebettet. Zusätzlich extrahiert die Pipeline Entitäten und Beziehungen. In anspruchsvolleren Implementierungen geschieht das in zwei Schritten: erst Entity Detection, dann Relation Extraction mit den gefundenen Entitäten als Kontext. Das reduziert die Versuchung, in einem einzigen Prompt gleichzeitig alles zu finden, zu typisieren und sauber zu verbinden.

Anschließend folgt Entity Resolution. "RevOps", "Revenue Operations" und "Revenue Ops Team" können dieselbe Organisationseinheit meinen. Ohne Deduplizierung entstehen künstliche Parallelwelten im Graphen. Erst wenn Entitäten kanonisiert sind, werden Beziehungen belastbar traversierbar.

Ein typischer GraphRAG-Index enthält deshalb nicht nur Dokumente und Chunks, sondern auch Entitäten, Relationen, Quellverweise, Versionen, Gültigkeitsinformationen, Confidence-Werte und Mandanten- oder Projektgrenzen. Als technische Backends kommen Property-Graph-Datenbanken wie Neo4j oder PostgreSQL-nahe Ansätze wie Apache AGE infrage. Für thematische Cluster oder globale Fragen kann Community Detection, etwa mit dem Leiden-Algorithmus, zusätzliche Struktur liefern.

Wichtig ist dabei die richtige Erwartung: Die Pipeline kann Zusammenhänge extrahieren, aber sie kann sie auch falsch extrahieren. Deshalb gehören Validierung, Re-Indexing, Quellenbindung und Audit-Informationen in die Architektur, nicht in einen späteren Qualitätssicherungsprozess.

Multi-Hop-Fragen brauchen Evidenzketten

Eine Multi-Hop-Frage verlangt mehrere logisch verbundene Schritte. Beispiel:

"Welche interne Richtlinie regelt die Nutzung von Kundendaten in KI-Piloten, welcher Prozess setzt diese Richtlinie um, und wer ist für Ausnahmen zuständig?"

Eine reine Vektorsuche kann mehrere relevante Textstellen finden: eine Datenschutzrichtlinie, eine Projektvorlage, eine Freigabeseite, vielleicht ein Ticket aus einem alten Pilotprojekt. Das hilft. Aber die Antwort ist erst dann belastbar, wenn das System zeigen kann, wie diese Fundstellen zusammenhängen:

flowchart LR
    A["AI Data Use Policy"] -->|REGELT| B["KI-Pilotprozess"]
    B -->|NUTZT| C["DPIA / DSFA Workflow"]
    C -->|LÄUFT_IN| D["GRC-System"]
    B -->|AUSNAHME_DURCH| E["Data Protection Owner"]
    A -->|EXTRACTED_FROM| F["Policy-Dokument v3.2"]
    B -->|EXTRACTED_FROM| G["Prozessseite"]
    E -->|EXTRACTED_FROM| H["Rollenmatrix"]

Die Antwort kann dann nicht nur sagen, was wahrscheinlich gilt. Sie kann angeben, welche Kette zur Antwort geführt hat, welche Quellen sie stützen und wo Unsicherheit bleibt. Falls die Rollenmatrix älter ist als die Prozessseite, kann das System diese Spannung sichtbar machen, statt sie still zu glätten.

Das ist der Unterschied zwischen einem plausiblen Chatbot und einem Enterprise-System, das man in kontrollierten Prozessen einsetzen kann.

Provenance, Validity und Confidence sind keine Anhängsel

Viele RAG-Demos zeigen Quellen am Ende der Antwort. Das ist ein guter Anfang, aber in Unternehmen reicht ein Quellenlink allein nicht aus. Die Quelle muss mit der konkreten Aussage verbunden sein.

Provenance beantwortet: Aus welchem Dokument, Chunk, Datensatz oder System stammt diese Entität oder Beziehung? Bei einer Graphkante wie Policy -> steuert -> Prozess sollte nachvollziehbar sein, ob sie aus einem Policy-Dokument, einer Prozesslandkarte, einem Ticket oder einer manuell gepflegten Architekturquelle stammt.

Validity beantwortet: Galt diese Information zum Zeitpunkt der Frage? Eine alte Richtlinie kann weiterhin im Index liegen und semantisch sehr passend sein. Wenn sie aber durch eine neuere Version überschrieben wurde, darf sie nicht als aktuelle Antwortgrundlage erscheinen.

Confidence beantwortet: Wie belastbar ist diese Beziehung? Eine Beziehung aus einem strukturierten Stammdatensystem ist anders zu bewerten als eine von einem LLM extrahierte Beziehung aus einem langen PDF. Confidence ist kein Ersatz für Wahrheit, aber ein Signal für Antwortstrategie: direkt antworten, Unsicherheit benennen, weitere Quelle verlangen oder eskalieren.

Diese drei Dimensionen verwandeln GraphRAG von einer Suchverbesserung in eine Governance-Schicht.

Permission-Aware Retrieval gehört in den Graphen

Permission-Aware Retrieval muss auch bei GraphRAG vor der Antwort greifen. Eine Entität darf nicht sichtbar werden, nur weil sie in einem allgemein zugänglichen Graphknoten zusammengeführt wurde, wenn ihre stützende Quelle für den Nutzer gesperrt ist. Deshalb ist die Verbindung zwischen Entität, Chunk, Dokument und Berechtigung zentral.

Eine robuste Implementierung verknüpft Entitäten mit den Chunks, aus denen sie extrahiert wurden. Chunks verweisen auf Dokumente, Dokumente auf Projekte, Tenants, Quellsysteme und Berechtigungsinformationen. Traversiert ein Nutzer den Graphen, darf eine Beziehung nur dann in den Retrieval-Kontext gelangen, wenn mindestens eine zulässige Quelle und der aktuelle Berechtigungskontext das hergeben.

Das ist besonders wichtig bei Multi-Hop-Fragen. Sonst kann ein System eine eigentlich gesperrte Information indirekt über einen Beziehungspfad rekonstruieren. Permission-Aware Retrieval ist daher nicht nur ein Sicherheitsthema für Chunks, sondern auch für Entitäten, Kanten, Pfade und aggregierte Graph-Summaries.

Was die +86% bei Multi-Hop bedeuten

In internen, produktseitigen und setup-abhängigen Auswertungen wurde für Multi-Hop-Fragen eine Verbesserung von etwa 0,42 auf 0,78 Recall@10 beobachtet. Das entspricht bis zu rund +86% gegenüber einem Vector-only-Setup in diesem konkreten Kontext.

Diese Zahl ist nützlich als Richtungssignal, aber sie sollte nicht als unabhängiger Benchmark gelesen werden. Sie hängt am Korpus, an den Fragetypen, an der Qualität der Entity Extraction, am Relation Schema, an Berechtigungsfiltern, an Reranking und an der konkreten Fusion. Für eine wissenschaftliche Aussage wären externe Benchmarks wie HotpotQA oder MuSiQue, klare Baselines, Signifikanztests und Ablationsstudien notwendig.

Für Architekturentscheidungen ist die vorsichtige Interpretation trotzdem relevant: Je stärker eine Frage auf mehreren Beziehungen beruht, desto eher stößt reine Ähnlichkeitssuche an Grenzen. Ein Graph kann dann zusätzliche Trefferwege liefern, die Vector Search allein nicht systematisch findet.

Wo GraphRAG scheitern kann

GraphRAG ist kein magischer Verständnismotor. Es macht Zusammenhänge nicht automatisch wahr. Es macht sie modellierbar und prüfbar.

Die erste Fehlerquelle ist Extraktion. Wenn Entitäten falsch erkannt oder Beziehungen falsch typisiert werden, traversiert das System falsche Strukturen. Dagegen helfen präzisere Schemas, Evaluationssets, Human Review für kritische Domänen und Confidence-basierte Antwortlogik.

Die zweite Fehlerquelle ist Aktualität. Unternehmenswissen ändert sich. Policies werden überschrieben, Teams umgebaut, Systeme migriert, Owner wechseln. Ein Graph braucht inkrementelle Updates, Versionierung und klare Regeln, wann alte Beziehungen ungültig werden.

Die dritte Fehlerquelle ist Berechtigung. Besonders gefährlich sind aggregierte Knoten, Community Summaries oder Entity-Merges, die Informationen aus Quellen mit unterschiedlichen Berechtigungen vermischen. Hier muss der Graph berechtigungsbewusst konstruiert und abgefragt werden.

Die vierte Fehlerquelle ist Übermodellierung. Nicht jede FAQ braucht GraphRAG. Für einfache semantische Fundstellen ist Vector Search oft schneller, günstiger und ausreichend. Der Graph lohnt sich dort, wo Beziehungen, Verantwortung, Gültigkeit, Audits oder Multi-Hop-Fragen zum Kern des Use Cases gehören.

Architekturfragen für Enterprise-Teams

Wer Enterprise-RAG bewertet, sollte deshalb nicht nur nach Modellqualität fragen. Die entscheidenden Fragen liegen in der Retrieval- und Datenarchitektur:

• Welche Entitätstypen und Beziehungstypen braucht der Use Case wirklich?
• Werden Entitäten mit ihren Quellchunks verbunden oder nur global gesammelt?
• Wie werden Versionen, Gültigkeitszeiträume und Überschreibungen modelliert?
• Welche Confidence-Signale gibt es für extrahierte Beziehungen?
• Wie werden Vektor-, Graph- und Reranker-Ergebnisse fusioniert?
• Greifen Berechtigungen auf Chunk-, Dokument-, Projekt-, Tenant- und Graphpfad-Ebene?
• Wie werden Community Summaries oder aggregierte Graphinformationen berechtigt?
• Welche Audit-Daten zeigen später, warum eine Antwort entstanden ist?
• Welche Fragetypen bleiben bewusst Vector-only, weil GraphRAG keinen Mehrwert bringt?

Diese Fragen wirken weniger spektakulär als ein neues Modell. In der Praxis entscheiden sie darüber, ob Enterprise-RAG belastbar betrieben werden kann.

Fazit: RAG muss Beziehungen verantworten können

Enterprise-RAG lernt Zusammenhänge nicht, indem es wie ein Mensch versteht. Es lernt sie, indem es Beziehungen explizit modelliert, Quellen bindet, Gültigkeit prüft, Unsicherheit sichtbar macht und Berechtigungen vor der Kontextbildung respektiert.

Vector Search bleibt dabei unverzichtbar. Sie ist die starke Candidate-Findung für heterogene Unternehmenssprache. Der Knowledge Graph ergänzt die Struktur, die in vielen Enterprise-Fragen fehlt: Policy -> Prozess -> System -> Owner -> Quelle -> Berechtigung.

Sobald Antworten Auswirkungen auf Freigaben, Compliance, Kundenkommunikation, HR, Finance oder technische Betriebsprozesse haben, reicht "ähnlich gefunden" nicht mehr aus. Die Antwort muss zeigen können, warum sie gilt.

Wer solche Beziehungspfade in eigenen KI-Anwendungen abbilden möchte, kann die TensorFive RAG API als technische Grundlage für hybrides, permission-aware Enterprise-RAG prüfen: mit Vector Search, Knowledge-Graph-Erweiterung, Fusion, Quellenbezug und Berechtigungslogik als Teil der Retrieval-Schicht.