Kurzurteil: Ein Knowledge Graph ist kein Wahrheitsautomat. Er kann Unternehmenswissen als identifizierbare, verknüpfte und belegbare Claims organisieren. Ob ein LLM dadurch besser antwortet, hängt zusätzlich von Quellenqualität, Gültigkeit, Berechtigungen, Retrieval, Prompt, Modell und Evaluation ab.
Die typische Ausgangslage ist nicht ein zu kurzer Prompt, sondern verteiltes Wissen: Produktdaten im PIM, Leistungsdefinitionen im CMS, Freigaben in Dokumenten, Vertragsgrenzen im Wiki und widersprüchliche Tabellen in Teams. Ein längerer Prompt löst diese Widersprüche nicht. Eine neue Graphdatenbank allein ebenfalls nicht.
Der sinnvolle Zwischenschritt ist ein Claim-Register: Was wird über welche Entität behauptet, durch welche Quelle ist es belegt, für welchen Zeitraum gilt es und wer darf es freigeben? Unsere Vorlage für ein Knowledge-Graph-Claim-Register macht diese Fragen sichtbar, bevor ein Team über RDF, Property Graphs oder GraphRAG entscheidet.
Was ein Knowledge Graph tatsächlich ist
Ein Graph beschreibt Dinge und ihre Beziehungen. Im RDF-Datenmodell ist ein Graph laut W3C RDF 1.1 Concepts eine Menge von Tripeln. Jedes Tripel besteht aus Subjekt, Prädikat und Objekt. Vereinfacht:
service:llmo-audit hasDeliverable artifact:evidence-ledger
artifact:evidence-ledger hasOwner role:measurement-lead
artifact:evidence-ledger validFor release:2026-q3
Diese Schreibweise macht Beziehungen explizit. Sie beweist sie aber nicht. Dazu braucht der Claim mindestens Herkunft, Gültigkeit und Reviewstatus. Ein belastbarer Datensatz trennt daher:
- Identität: stabile ID für Organisation, Produkt, Leistung oder Dokument,
- Claim: Subjekt, Beziehung und Objekt oder Wert,
- Provenienz: Quelle und genaue Fundstelle,
- Zeit: gültig ab, gültig bis und letzte Prüfung,
- Verantwortung: Datenowner und fachliche Freigabe,
- Zugriff: öffentlich, intern, vertraulich oder besonders geschützt,
- Status: vorgeschlagen, geprüft, freigegeben, widersprochen oder abgelaufen.
Ein Graph ohne diese Felder kann Beziehungen visualisieren. Für produktive KI-Antworten ist er noch keine kontrollierte Wissensquelle.
Tabelle, Datenbank, Ontologie oder Knowledge Graph?
Die Begriffe werden im Vertrieb häufig vermischt. Für die Systementscheidung hilft diese Abgrenzung:
| Artefakt | Stärke | Typische Grenze | Sinnvoll, wenn |
|---|---|---|---|
| Tabelle oder Claim-Register | schnell prüfbar, leicht exportierbar | komplexe Traversierung wird unhandlich | ein Pilot wenige Claimtypen testet |
| relationale Datenbank | starke Schemas, Transaktionen und etablierte Abfragen | viele wechselnde Beziehungen brauchen Join-Logik | Kerndaten bereits relational gepflegt werden |
| Property Graph | Beziehungen und Pfade sind direkt abfragbar | Modell und Portabilität sind produktabhängig | Pfadfragen und Beziehungstiefe zentral sind |
| RDF-Graph | globale Identifikatoren, Vokabulare und Datenaustausch | Governance und Modellierung bleiben anspruchsvoll | Interoperabilität und Linked Data wichtig sind |
| Ontologie | formale Begriffe, Klassen und Regeln | hoher Abstimmungs- und Pflegebedarf | maschinelle Schlussfolgerungen wirklich benötigt werden |
Nicht jede verknüpfte Tabelle ist ein vollwertiger Knowledge Graph. Umgekehrt muss ein sinnvoller Pilot nicht mit einer komplexen Ontologie starten. Die kleinste Architektur, die die relevanten Fragen reproduzierbar beantwortet, ist meist die bessere erste Entscheidung.
Die entscheidende Systemgrenze: Graph ist nicht Modellantwort
Ein produktiver Ablauf besteht aus mehreren voneinander prüfbaren Schichten:
- Quellen: freigegebene Systeme und Dokumente liefern Rohdaten.
- Claim-Register: Identitäten und Beziehungen werden normalisiert.
- Validierung: Schema, Quelle, Zeit, Rechte und Widersprüche werden geprüft.
- Retrieval: Die konkrete Frage bestimmt, welche Claims und Belege abgerufen werden.
- Modellantwort: Das Modell formuliert innerhalb eines definierten Ausgabe- und Ablehnungsrahmens.
Fehlt eine Schicht, kann die nächste den Fehler plausibel kaschieren. Ein korrekt gespeicherter Claim kann durch falsches Retrieval fehlen. Ein relevanter Claim kann veraltet sein. Ein sauberer Kontext kann trotzdem falsch zusammengefasst werden. Deshalb werden Graph-, Retrieval- und Antwortqualität getrennt gemessen.
Ein Claim ist mehr als Subjekt–Prädikat–Objekt
Nehmen wir eine Leistungsinformation:
SUBJEKT: service:example-audit
PRÄDIKAT: hasDeliverable
OBJEKT: artifact:release-check
QUELLE: /leistungen/example-audit, Abschnitt „Lieferobjekte“
GÜLTIGKEIT: ab Freigabedatum bis Widerruf
OWNER: Service Owner
REVIEWSTATUS: fachlich geprüft
Ohne Quelle und Gültigkeit wäre nicht feststellbar, ob das Lieferobjekt nur in einer alten Präsentation stand. Ohne Owner könnte niemand einen Widerspruch entscheiden. Ohne Zugriffsklasse könnte ein interner Claim versehentlich in externe Kommunikation gelangen.
Das herunterladbare Claim-Register lässt Beleg-, Freigabe- und Releasefelder bewusst leer. Es ist eine Arbeitsvorlage, keine Sammlung bereits bestätigter Fakten.
Curated Graph und automatisch extrahierter Graph sind nicht dasselbe
Ein kuratierter Graph enthält bewusst modellierte und geprüfte Claims. Ein extrahierter Graph entsteht, wenn Software Entitäten, Beziehungen oder Behauptungen aus Dokumenten ableitet. Die zweite Variante skaliert die Erfassung, produziert aber zunächst Hypothesen.
Die offizielle Microsoft-GraphRAG-Dokumentation beschreibt eine Indexierung, die aus unstrukturiertem Text Entitäten, Beziehungen und Claims extrahiert, Communities bildet, Berichte erzeugt und Text einbettet. Das ist eine Datenpipeline, kein Beleg dafür, dass jede extrahierte Kante korrekt ist. Die Dokumentation warnt außerdem, dass die Indexierung erhebliche LLM-Ressourcen verbrauchen kann und empfiehlt einen begrenzten Einstieg mit günstigen Modellen.
Für automatisch extrahierte Claims braucht ein Team deshalb:
- Link zur genauen Quellpassage,
- Extraktionsversion und Modellkonfiguration,
- Konfidenz nur als Sortierhilfe, nicht als Wahrheitsbeweis,
- fachliche Stichprobe oder vollständige Prüfung nach Risikoklasse,
- Duplikat- und Identitätsauflösung,
- Widerspruchsregister,
- Freigabe vor produktiver Nutzung.
Eine hohe Modellkonfidenz ersetzt keinen Quellennachweis.
Vektor-RAG, GraphRAG und hybride Suche vergleichen
GraphRAG ist nicht automatisch der nächste Reifegrad nach Vektor-RAG. Es löst andere Abfrageprobleme und bringt eigene Indexierungs- und Pflegekosten mit.
| Frageart | Vektor-RAG kann passen | Graphbasierter Abruf kann passen | Prüfkriterium |
|---|---|---|---|
| „Was sagt Dokument X zu Klausel Y?“ | relevanter Textabschnitt ist entscheidend | Graph bringt wenig Zusatznutzen | Quellenpassage wird korrekt gefunden |
| „Welche Produkte hängen von Komponente Z ab?“ | Ähnlichkeit kann Beziehungen übersehen | Pfade und Abhängigkeiten sind zentral | vollständige, erlaubte Beziehungskette |
| „Welche übergreifenden Themen prägen den Bestand?“ | viele Chunks müssen verdichtet werden | Community- oder Graphzusammenfassungen können helfen | Abdeckung gegen Referenzanalyse |
| „Welche aktuelle Preisregel gilt für Region A?“ | aktueller Datensatz kann direkt abgerufen werden | zeitlich versionierter Claim kann helfen | richtige Gültigkeit und Region |
| „Formuliere eine Antwort mit Beleg“ | Textquelle bleibt für Zitation wichtig | Graph kann Entität und Claim eingrenzen | Aussage wird durch sichtbare Quelle gestützt |
Microsoft GraphRAG kombiniert bei der lokalen Suche den extrahierten Graph mit Textabschnitten der Quelldokumente. Diese Architektur unterstreicht eine wichtige Grenze: Struktur ersetzt den Originalbeleg nicht zwingend. Für viele Workflows ist ein hybrider Abruf aus Claims und Quellpassagen besser prüfbar.
Der RAG-versus-SEO-und-GEO-Guide grenzt interne Wissenssysteme von öffentlicher Auffindbarkeit ab. Die technische Anbieterprüfung beschreibt unser RAG-Due-Diligence-Guide.
Öffentliches JSON-LD ist nicht Ihr interner Wissensspeicher
JSON-LD kann einen Graph serialisieren. Auf einer Website dient es jedoch einer anderen Oberfläche als ein internes Wissenssystem. Google beschreibt strukturierte Daten als standardisierte Hinweise über den Seiteninhalt. Nach den allgemeinen Google-Richtlinien für strukturierte Daten müssen sie den sichtbaren Inhalt wahrheitsgemäß repräsentieren; korrekte Auszeichnung garantiert keine besondere Suchdarstellung.
Damit gelten zwei getrennte Regeln:
Öffentliche Website
- nur öffentliche und sichtbare Aussagen auszeichnen,
- passende unterstützte Typen und Eigenschaften verwenden,
- stabile
@id-Werte für dieselbe Entität konsistent halten, - Markup und sichtbaren Inhalt gemeinsam aktualisieren,
- mit Rich Results Test und URL-Prüfung validieren.
Internes Wissenssystem
- Berechtigungen bis auf Quelle, Claim oder Nutzerrolle durchsetzen,
- vertrauliche Daten nicht in öffentliche Exporte übernehmen,
- Version, Gültigkeit und Löschregeln verwalten,
- Retrieval gegen Nutzerrechte prüfen,
- Ausgaben und Toolaktionen protokollieren.
Gemeinsame Identifikatoren können die Pflege erleichtern. Ein automatischer Voll-Export des internen Graphen in JSON-LD wäre jedoch ein Daten- und Sicherheitsfehler. Mehr zur sichtbaren Webauszeichnung steht im Guide Structured Data für Crawler und Sprachmodelle.
Die sieben häufigsten Fehlentscheidungen
1. Technologie vor Frage auswählen
„Wir brauchen Neo4j“ ist keine Anforderung. Beginnen Sie mit repräsentativen Fragen, erwarteten Belegen und heutigen Fehlern.
2. Jede Extraktion als Wahrheit speichern
Automatische Extraktion erzeugt Kandidaten. Erst Quelle, Review und Status machen daraus freigegebene Claims.
3. Identitäten nur über Namen verbinden
„Berlin“, „Berlin GmbH“ oder Produktkürzel können mehrdeutig sein. Stabile IDs und dokumentierte Zusammenführungsregeln sind zentral.
4. Zeit ignorieren
Preis, Rolle, Verfügbarkeit und Zuständigkeit ändern sich. Ohne Gültigkeitsfelder liefert der Graph alte und neue Aussagen nebeneinander.
5. Widersprüche löschen statt entscheiden
Abweichende Quellen sind ein Governance-Ereignis. Halten Sie beide Claims mit Herkunft fest und dokumentieren Sie die Entscheidung.
6. Öffentliche und interne Graphen vermischen
Web-Markup und internes Retrieval haben andere Nutzer, Rechte und Publikationsregeln.
7. Nur die Demo bewerten
Eine plausible Antwort sagt wenig über Abdeckung, Rechte, Aktualisierung und Fehlerverhalten aus. Die Abnahme braucht Testfälle und Rohbelege.
Pilot in sechs kontrollierten Schritten
1. Eine begrenzte Fragefamilie wählen
Geeignet sind wiederkehrende Fragen, bei denen Beziehungen wirklich wichtig sind: Produktkompatibilität, Leistungsgrenzen, Standortzuständigkeit oder Dokumentabhängigkeiten.
2. Baseline festhalten
Messen Sie dieselben Fragen ohne Graph: gefundene Quelle, fachliche Richtigkeit, unbelegte Aussage, Ablehnung, Latenz und variable Kosten.
3. Claimtypen modellieren
Definieren Sie nur die Entitäten und Beziehungen, die die Pilotfragen benötigen. Ein riesiges Universalschema erhöht die Abstimmung, bevor Nutzen belegt ist.
4. Belege und Rechte anbinden
Jeder relevante Claim braucht Quelle, Fundstelle, Gültigkeit und Zugriffsklasse. Das Entity-Authority-Angebot adressiert öffentliche Marken- und Organisationsbeziehungen; interne Wissenssysteme benötigen zusätzlich Daten- und Engineering-Verantwortung.
5. Retrieval und Antwort getrennt testen
Prüfen Sie zuerst, ob die richtigen Claims und Quellen zurückkommen. Bewerten Sie anschließend, ob die Modellantwort diese korrekt verwendet und bei fehlender Evidenz ablehnt.
6. Scale-or-Stop entscheiden
Erweitert wird nur, wenn die Graphvariante auf den definierten Aufgaben einen nachvollziehbaren Vorteil gegenüber der Baseline zeigt und Betrieb, Rechte sowie Aktualisierung tragbar sind.
Abnahme: Was muss messbar sein?
| Ebene | Messfrage | Negativtest |
|---|---|---|
| Identität | Wird die richtige Entität aufgelöst? | gleicher Name, andere Organisation |
| Claim | Ist Beziehung oder Wert korrekt modelliert? | vertauschtes Subjekt und Objekt |
| Herkunft | Führt der Claim zur stützenden Passage? | Quelle erwähnt den Claim nicht |
| Zeit | Wird nur die gültige Fassung genutzt? | abgelaufener Preis oder alte Rolle |
| Zugriff | Erhält der Nutzer nur erlaubte Claims? | vertrauliche Quelle mit öffentlicher Rolle |
| Retrieval | Werden erforderliche Claims vollständig gefunden? | mehrstufige Abhängigkeit |
| Antwort | Bleibt die Aussage innerhalb der Evidenz? | fehlender Beleg oder Widerspruch |
| Betrieb | Ist der Lauf reproduzierbar? | neues Modell oder geänderte Extraktion |
Das NIST AI Risk Management Framework betont dokumentierte Rollen, laufende Überprüfung, Systeminventare und kontextbezogene Tests. Für einen Graph-LLM-Workflow bedeutet das: Datenmodell, Index, Retrieval, Modell und Freigabe gehören in einen gemeinsamen, versionierten Betriebsprozess.
Rollen für den laufenden Betrieb
- Fachlicher Owner: entscheidet Bedeutung, Gültigkeit und Widersprüche.
- Source Owner: verantwortet das Ursprungssystem und dessen Aktualität.
- Graph Steward: pflegt Identitäten, Schema, Qualität und Releases.
- Security und Datenschutz: definieren Zugriff, Protokollierung und Löschung.
- AI-Workflow-Owner: verantwortet Retrieval, Prompt, Modell und Evaluation.
- Freigabeverantwortliche: entscheiden, welche Antworten oder Aktionen Menschen prüfen müssen.
Ein Graph ohne Pflegeprozess veraltet kontrolliert aussehend. Die betriebliche Qualität hängt weniger von einer spektakulären Visualisierung als von klaren Änderungs- und Eskalationswegen ab.
Fazit: Erst Claim-Qualität, dann Graphgröße
Knowledge Graphs können LLM-Workflows dort verbessern, wo Identitäten, Beziehungen, Herkunft und Zeit für die Antwort entscheidend sind. Sie sind kein pauschaler Ersatz für gute Quellen, Vektor-Retrieval oder fachliche Kontrolle. Und sie machen eine Modellantwort nicht automatisch wahr.
Der tragfähige Weg beginnt klein: Fragefamilie, Baseline, Claim-Register, Quellen, Rechte, Tests und ein begrenzter Pilot. Erst wenn diese Evidenz einen Vorteil zeigt, lohnt sich die Entscheidung über Graphdatenbank, Ontologie oder GraphRAG-Pipeline.
Im Knowledge-Workflow-Audit prüfen wir eine konkrete Fragefamilie, Quellen, Claims, Identitäten, Berechtigungen und Abnahmetests. Eine Conversion zählt erst mit bestätigtem appointment_booked; ein Graph-Screenshot oder eine Tooldemo ist noch kein belastbares Wissenssystem.
Häufig gestellte Fragen
Was ist ein Knowledge Graph im LLM-Kontext?
Ein Knowledge Graph repräsentiert identifizierte Dinge, Eigenschaften und Beziehungen als adressierbare Claims. In einem LLM-Workflow kann er Retrieval, Filterung und Herkunftsnachweise unterstützen. Er ist jedoch weder das Sprachmodell noch automatisch eine verlässliche Wahrheitsquelle.
Verhindert ein Knowledge Graph Halluzinationen?
Nein. Ein Graph kann relevanten und strukturierten Kontext liefern, aber falsche Extraktion, veraltete Claims, unpassendes Retrieval oder eine unbelegte Modellantwort bleiben möglich. Qualität muss gegen Testfälle, Quellen und Freigaberegeln geprüft werden.
Was ist der Unterschied zwischen JSON-LD auf einer Website und einem internen Knowledge Graph?
JSON-LD auf einer Webseite beschreibt öffentlich sichtbare Seiteninhalte für externe Systeme. Ein interner Graph kann geschützte Betriebsdaten, Berechtigungen, Versionen und Workflow-Claims enthalten. Beide können gemeinsame Identifikatoren nutzen, dürfen aber nicht als dieselbe Datenoberfläche behandelt werden.
Was unterscheidet GraphRAG von klassischem Vektor-RAG?
Vektor-RAG sucht typischerweise semantisch ähnliche Textabschnitte. GraphRAG ergänzt oder ersetzt Teile dieses Abrufs durch extrahierte Entitäten, Beziehungen, Claims oder Communities. Welche Methode besser passt, hängt von den Fragen, Daten, Kosten und Evaluationsergebnissen ab.
Kann ein Team mit einer Tabelle statt einer Graphdatenbank starten?
Ja. Für einen begrenzten Pilot reicht häufig ein Claim-Register mit stabilen IDs, Subjekt, Prädikat, Objekt, Quelle, Gültigkeit, Owner und Reviewstatus. Eine Graphdatenbank wird erst nötig, wenn Abfragen, Datenmenge, Beziehungstiefe oder Integrationen sie rechtfertigen.
Welche Daten gehören nicht ungeprüft in einen Knowledge Graph?
Ungeklärte personenbezogene Daten, vertrauliche Inhalte ohne Rechtekonzept, automatisch extrahierte Behauptungen ohne Herkunft sowie abgelaufene oder widersprüchliche Claims sollten nicht als freigegebene Wahrheit behandelt werden. Zugriff und Zweck müssen vor der technischen Integration geklärt sein.
Wie misst man den Nutzen eines Knowledge Graphs für LLMs?
Verglichen werden definierte Aufgaben auf einem versionierten Testset: Retrieval-Treffer, Quellenabdeckung, korrekte Ablehnung, unbelegte Aussagen, Berechtigungsverstöße, fachliche Qualität, Latenz und variable Kosten. Entscheidend ist die Verbesserung gegenüber einer geeigneten Baseline, nicht die Größe des Graphen.
Kostenlose Ersteinschätzung
Ist Ihr Unternehmenswissen verknüpft oder nur verteilt?
Wir prüfen einen konkreten KI-Workflow, seine Quellen, Entitäten, Claims, Rechte und Testfälle – bevor eine Graph-Technologie ausgewählt wird.
Knowledge-Workflow prüfenErgebnis zuerst. Kontaktdaten erst, wenn Sie fortfahren möchten.