Phase 1 · Step 6 von 9
Du lernst, wie aus verbundenen Dingen ein fachlich nutzbares Wissensmodell wird.
Was du mitnimmst
Knowledge Graphs machen fachliche Beziehungen explizit, abfragbar und überprüfbarer.

Du lernst, wie aus Knoten und Kanten ein fachlich nutzbarer Knowledge Graph wird. Danach erkennst du, welche Rolle Entitäten, Beziehungstypen, Eigenschaften und Quellen spielen.
Ein Knowledge Graph macht fachliche Zusammenhänge explizit.
Für GraphRAG ist das zentral: Der Graph soll zeigen, welche Dinge zusammengehören, welche Beziehung sie haben und worauf diese Aussage basiert.
Dieser Schritt macht aus dem abstrakten Graphbegriff ein fachliches Modell. Später brauchst du genau dieses Modell, um Quellenbelege, Beziehungstypen und gültige Pfade sauber zu unterscheiden.
Ein Knowledge Graph beschreibt reale oder fachliche Entitäten und ihre Beziehungen. Entitäten sind zum Beispiel Richtlinie, System, Projekt, Team, Pflicht, Risiko oder Quelle. Beziehungen beschreiben die fachliche Aussage zwischen zwei Entitäten.
Entscheidend ist die Qualität der Beziehung. Der Beziehungstyp macht sichtbar, ob eine Quelle etwas erwähnt, eine fachliche Zuordnung belegt oder eine konkrete Pflicht beschreibt.
Ein guter Knowledge Graph hat außerdem ein Ordnungsprinzip. Er modelliert gezielt das, was für eine Frageklasse relevant ist. Im Compliance-Fall brauchst du andere Entitätstypen (Richtlinie, System, Projekt, Team) als für einen Lieferketten- oder Produktfall.
Dabei helfen zwei Sichten. Ein Dokumentgraph bleibt nah an Quellen: Dokument, Abschnitt, Tabelle, Erwähnung, Zitat. Ein Objektgraph modelliert fachliche Dinge: Richtlinie, System, Projekt, Team, Pflicht, Risiko. Für GraphRAG werden oft beide Sichten kombiniert: Der Objektgraph trägt die Bedeutung, der Dokumentgraph trägt den Beleg.
Für GraphRAG ist Quellenbezug besonders wichtig. Wenn der Graph eine Aussage enthält, muss klar sein, aus welcher Quelle sie stammt, wann sie gültig ist und wie zuverlässig sie ist.
Ein Graph zeigt Verbindungen. Ein Knowledge Graph erklärt, welche Verbindungen fachlich zählen.
Fachlich relevantes Objekt, zum Beispiel System, Projekt oder Richtlinie.
Benannte fachliche Verbindung zwischen Entitäten.
Strukturierungslogik, die dem Graphen Bedeutung und Konsistenz gibt.
Nachweis, woher eine Aussage im Graphen stammt.
Im Compliance-Fall verbindet der Knowledge Graph die relevanten Dinge:
Richtlinie A -> definiert_Pflicht_für -> kritische Kundensysteme. CRM -> ist_klassifiziert_als -> kritisches Kundensystem. Projekt Alpha -> nutzt -> CRM. Customer Core -> verantwortet -> CRM. Abschnitt 4.2 -> belegt -> Prüfpflicht.
Damit kann das System eine konkrete Frage beantworten: "Welche Projekte sind betroffen, wenn CRM jährlich geprüft werden muss?" Der Graph liefert den fachlichen Pfad von Richtlinie über Systemklasse und System zu Projekt und Team. Die Quellen liefern den Nachweis: Richtlinie A, Systemkatalog, Projektliste und Verantwortlichkeitsnotiz.
Wichtig ist: Jede Aussage sollte belegbar sein. "CRM ist kritisch" kommt aus dem Systemkatalog. "Projekt Alpha nutzt CRM" kommt aus der Projektliste. "Jährliche Prüfpflicht" kommt aus Abschnitt 4.2 der Richtlinie. "Customer Core koordiniert" kommt aus der Verantwortlichkeitsnotiz – mit niedrigerer Autorität als die formalen Quellen.
Der typische Denkfehler ist, Erwähnungen bereits als fachliche Beziehungen zu behandeln. Aus "CRM steht in der Projektliste" entsteht erst dann eine belastbare Aussage, wenn klar ist, dass Projekt Alpha CRM tatsächlich nutzt und welche Quelle das belegt.
Ein zweiter Denkfehler ist maximale Vollständigkeit. Ein Knowledge Graph wird wertvoller, wenn er wichtige Frageklassen stabil beantwortet: Betroffenheit, Prüfpflicht, Zuständigkeit oder Abhängigkeit.
Ein Knowledge Graph wird relevant, wenn fachliche Entitäten, Beziehungstypen, Regeln, Quellen und Gültigkeit Teil der Antwortqualität sind.
Wenn du erklären musst, warum eine Beziehung fachlich gilt und woher sie stammt, brauchst du Beziehungstypen, Quellen und Gültigkeit direkt im Modell.
Baue einen Mini-Knowledge-Graphen für diese Frage: "Welche Projekte sind betroffen, wenn CRM jährlich geprüft werden muss?"
Notiere fünf Entitäten, fünf Beziehungstypen und zwei Quellen, die den Pfad belegen.
Richtlinie A, kritisches Kundensystem, CRM, Projekt Alpha, Team Customer Core.
Richtlinie definiert Pflicht für Systemklasse. CRM ist klassifiziert als kritisches Kundensystem. Projekt nutzt System. Team verantwortet System. Abschnitt belegt Prüfpflicht.
Systemkatalog für die Klassifikation von CRM und Projektliste für die Nutzung durch Projekt Alpha. Für die Pflicht zusätzlich Abschnitt 4.2 der Richtlinie A.
Richtlinie A -> kritisches Kundensystem -> CRM -> Projekt Alpha. Die Verantwortlichkeitsnotiz ergänzt, dass Customer Core die Prüfung koordiniert.
Fachlich typisierte, quellenbezogene und für echte Fragen modellierte Beziehungen bilden die Grundlage.
Eine Beziehung wird bedeutungsvoll, wenn ihr Typ eine fachliche Aussage trägt, zum Beispiel "Projekt nutzt System" mit klarer Bedeutung und Quelle.
Weil Antworten nachvollziehbar bleiben müssen. Der Graph sollte Beziehung, Quelle und Gültigkeit zusammen sichtbar machen.
Kernaussage
Knowledge Graphs machen fachliche Beziehungen explizit, abfragbar und überprüfbarer.