Knowledge Graphs in RAG

Ein Knowledge Graph in RAG nutzt eine Domänenontologie und validierte Beziehungen als kontrollierte Wissensschicht, ohne Primärdokumente zu ersetzen. Er ist ein eigener Vertrag mit messbaren Eingaben, Ausgaben und Fehlerbedingungen. Zuerst werden Query-Typen, verfügbare Quellen, benötigte Evidenz und akzeptable Latenz definiert; erst danach werden Modell oder Bibliothek gewählt.

Da der Graph explizite Beziehungen zwischen Entitäten abbildet, sollte Retrieval nicht nur Text, sondern auch Relationstyp und Herkunftsnachweis liefern. Der Generator darf aus einem schwachen oder indirekten Edge keinen kategorischen Fakt machen. Das ist besonders bei Abhängigkeiten, Ownership, Kompatibilität und kausalen Aussagen wichtig.

Ein praktischer Ablauf: Ein Entity Linker ordnet die Query kanonischen Knoten zu, Traversal findet zulässige Pfade und Text-Retrieval ergänzt zitierbare Evidenz für die gefundenen Aussagen. Der Vertrag enthält eine stabile Request-ID, Konfigurationsversionen, Confidence oder einen Fallback-Grund und genügend Provenance zur Reproduktion. Text ohne Quellen-IDs ist kein vollständiger Retrieval-Output.

Ein robuster Knowledge-Graph-RAG-Vertrag umfasst canonical entity ID, relation type, source document, validFrom, validUntil und confidence. Der Textindex kann häufig neu gebaut werden, diese Identitäten müssen aber reproduzierbar bleiben. So lassen sich Entity Resolution, Relation Retrieval und das finale Evidence Bundle getrennt testen.

Ein Knowledge Graph lohnt sich, wenn ein stabiles Schema und Beziehungen echten Geschäftswert haben; für einen Korpus unabhängiger Referenzseiten ist eine komplexe Ontologie unnötig. Der stärkste einfache Baseline bleibt parallel bestehen, denn zusätzliche Komplexität ist nur durch gemessenen Nutzen gerechtfertigt. Der Router kann Query-Typ, Risiko, erwartete Evidenzmenge und Latency Budget berücksichtigen.

Hat eine Entität mehrere inkompatible Relation Paths, darf das System nicht still den bequemsten wählen. Es muss den Konflikt sichtbar machen, zeitliche oder Source-Priority-Filter anwenden und bei unzureichender Evidenz mit einer klaren Einschränkung antworten. So werden Graphfehler sichtbar, bevor sie zu überzeugenden Halluzinationen werden.

Das Hauptrisiko ist fehlerhafte Entity Resolution, die verschiedene Objekte zusammenführt; fehlende Temporal Qualifiers lassen historische Beziehungen aktuell erscheinen. Ein längerer System Prompt behebt das nicht. Nötig sind deterministische Constraints, negative Tests und die Trennung nicht vertrauenswürdiger Daten von steuernden Anweisungen. Automatische Fallbacks müssen im Trace sichtbar sein und dürfen Rechte oder Quellen nicht erweitern.

Release-Tests decken doppelte Entitäten, Alias-Kollisionen, Orphan Nodes, widersprüchliche Beziehungen und abgelaufene Fakten ab. Nach jedem Fehler bleibt ein minimales Graph Fixture als Regression Case erhalten. Ein Rollback muss Ontologieversion, Graph Snapshot und Retrieval Policy gemeinsam zurücksetzen, nicht nur den Application Code.

Wichtige Signale sind Precision beim Entity Linking, Accuracy der Relation Traversal, Evidence Coverage, Unanswered Rate für unbekannte Entitäten und Antwortqualität gegenüber einem Text-only-Baseline. Offline-Evaluation nutzt reale und adversariale Queries, eingefrorene Labels und Segmentierung nach Domäne, Sprache und Risiko. Ein Durchschnitt darf den Ausfall eines kritischen Segments nicht verdecken; dafür braucht es einen eigenen Guardrail Threshold.

Im Betrieb braucht es stabile IDs, Schema Registry, Constraints, eine Review Queue für neue Beziehungen, Effective Dates, Source Pointers und kontrollierte Ontologiemigrationen. Neue Konfigurationen starten im Shadow Mode oder kleinen Canary, werden gegen den Baseline verglichen und bei SLO-Verletzung automatisch zurückgerollt. So werden Qualität, Kosten und Zuverlässigkeit gemeinsam optimiert.

Ein Knowledge Graph ist für Multi-Hop-Beziehungen nützlich, aber jeder Node und Edge muss source, validFrom, validUntil und confidence tragen. Automatisch extrahierte Relations werden ohne Validierung nicht zu kanonischen Fakten. Die Query-Pipeline bestimmt zuerst Entitäten, dann zulässige Relation Paths und sammelt erst danach Evidenz für die Generierung. Zu breite Traversals erzeugen Rauschen, Latenz und Cross-Tenant-Leak-Risiken.

Die Evaluation prüft Entity Linking, Path Correctness, Temporal Validity und Answer Support. Bei widersprüchlichen Quellen hält der Graph beide Versionen samt Provenance, statt einen Fakt zu überschreiben. Graph-Updates müssen idempotent sein und Deletion Propagation unterstützen. Die finale Antwort zeigt die Source Chain, damit Nutzer die Verbindung der Aussagen prüfen können.

• Keine Edges ohne Provenance erzeugen.
• Traversal Depth begrenzen.
• Temporale Konflikte testen.