Phase 1 · Step 2 von 9
Du lernst Knoten, Kanten und Pfade als einfache Sprache für Zusammenhänge kennen.
Was du mitnimmst
Graphen machen Beziehungen direkt modellierbar und abfragbar.

Du lernst Graphen als einfache Sprache für vernetztes Wissen kennen: Dinge werden zu Knoten, Verbindungen zu Kanten und längere Zusammenhänge zu Pfaden. Danach kannst du sehen, welche Fragen erst durch Beziehungen zwischen Dingen interessant werden.
Im Kontextbild aus Step 1 war der Graph einer der großen Bausteine. Jetzt schauen wir genauer hin: Was ist ein Graph eigentlich? Ein Graph ist eine Art, die Welt zu modellieren: Dinge werden zu Knoten, Beziehungen werden zu Kanten, und Fragen laufen oft über Pfade.
Graphdenken heißt: Dinge und ihre Verbindungen gemeinsam zu betrachten. Genau hier unterscheidet sich ein Graph von einer normalen Textsammlung.
Dieser Schritt ist wichtig, weil GraphRAG später nur dann verständlich wird, wenn du Beziehungen als eigene Information lesen kannst. Fehlt dieses Grundbild, wirkt ein Graph schnell wie eine Grafik statt wie ein abfragbares Modell.
Knoten stehen für Entitäten: Richtlinien, Systeme, Projekte, Teams, Pflichten oder Risiken. Eine gute Knotenwahl hängt vom Use Case ab. Im Compliance-Fall sind Richtlinie, System, Projekt und Team wahrscheinlich sinnvollere Knoten als jeder einzelne Satz im PDF.
Kanten beschreiben Beziehungen zwischen diesen Entitäten. Gute Kanten sind benannt und fachlich aussagekräftig: "gehört_zu", "verantwortet", "enthält", "erzeugt_Risiko". Schwache Kanten wie "erwähnt" können nützlich sein, aber sie erklären weniger.
Eigenschaften speichern Zusatzinformationen an Knoten oder Kanten: Datum, Quelle, Status, Version, Gewicht, Gültigkeit oder Vertrauen. Ohne Eigenschaften wird ein Graph schnell zu grob. Mit zu vielen Eigenschaften wird er schwer pflegbar.
Der eigentliche Wert entsteht durch Pfade. Eine Frage wie "Welche Technologie erzeugt welches Risiko in welchem Projekt?" wird als Traversierung durch mehrere Beziehungen beantwortet.
Nomen werden Knoten. Verben werden Kanten. Eine Frage wird zu einem Pfad.
Ein Ding im Graphen, zum Beispiel Projekt, Person oder Risiko.
Eine benannte Beziehung zwischen zwei Knoten.
Zusatzinformation an Knoten oder Kanten.
Eine Folge von Knoten und Kanten, über die eine Frage beantwortet wird.
Bleiben wir beim Compliance-Fall aus Step 1. Die Frage lautet: "Welches Team ist betroffen, wenn die Richtlinie für kritische Kundensysteme geändert wird?"
Ein einfacher Texttreffer findet vielleicht mehrere Seiten, auf denen "Richtlinie" oder "Kundensystem" steht. Ein Graph kann die Frage anders modellieren:
Richtlinie A -> betrifft -> kritische Kundensysteme -> umfasst -> CRM -> genutzt_von -> Projekt Alpha -> verantwortet_von -> Team Customer Core.
Jetzt wird aus "hier steht Kundensystem" ein Pfad: Die Richtlinie definiert eine Pflicht für eine Systemklasse, CRM gehört zu dieser Klasse, ein Projekt nutzt CRM, und ein Team verantwortet es. Genau solche Pfade machen Graphen für GraphRAG wertvoll.
Wenn zusätzlich Eigenschaften gespeichert sind, wird der Pfad belastbarer: Abschnitt 4.2 als Quelle der Prüfpflicht, Klassifikation aus dem Systemkatalog, Projektzuordnung aus der Projektliste und das Datum der letzten Prüfung. Der Graph wird dadurch zu einem abfragbaren Beziehungsmodell.
Viele verwechseln einen Graphen mit einer Visualisierung. Ein Netzwerkbild kann schön aussehen und trotzdem fachlich nutzlos sein. Entscheidend ist, ob die Knoten und Beziehungstypen echte Fragen beantworten.
Ein zweiter Denkfehler ist, jede Erwähnung sofort als Beziehung zu behandeln. "Dokument erwähnt CRM" ist schwächer als "Projekt Alpha nutzt CRM" oder "Customer Core verantwortet CRM".
Ein Graph wird relevant, wenn deine Frage mindestens zwei Beziehungsschritte braucht oder wenn die Beziehung selbst die Information ist. Typische Signale sind: "über welche Abhängigkeit", "welcher Pfad", "wer ist indirekt betroffen", "welche Ursache führt zu welchem Risiko".
Wenn du die Antwort als Kette von Entitäten und Beziehungen skizzieren kannst, denkst du bereits graphisch.
Baue einen Mini-Graphen für diese Frage: "Welches Team ist betroffen, wenn CRM jährlich geprüft werden muss?"
Notiere fünf Knoten, fünf Kanten und eine Pfadfrage. Markiere danach den Pfad, über den die Antwort entsteht.
Richtlinie A, kritisches Kundensystem, CRM, Projekt Alpha, Team Customer Core.
Richtlinie A betrifft kritische Kundensysteme. Kritisches Kundensystem umfasst CRM. Projekt Alpha nutzt CRM. Customer Core verantwortet CRM. Abschnitt 4.2 belegt die Prüfpflicht.
"Welches Team ist betroffen, wenn CRM jährlich geprüft werden muss?"
CRM -> Projekt Alpha und CRM -> Team Customer Core. Der Graph zeigt zusätzlich, warum das relevant ist: CRM ist als kritisches Kundensystem klassifiziert, und Richtlinie A definiert dafür die jährliche Prüfpflicht.
Ein Knoten steht für ein Ding oder eine Entität. Eine Kante steht für eine benannte Beziehung zwischen zwei Knoten, zum Beispiel "Projekt nutzt System" oder "Richtlinie definiert Pflicht".
"Erwähnt" sagt nur, dass etwas in einer Quelle vorkommt. "Verantwortet" beschreibt eine fachliche Zuständigkeit und trägt dadurch mehr Bedeutung für Entscheidungen, Pfade und Governance.
Eine Frage wird zur Pfadfrage, wenn die Antwort über mehrere verbundene Entitäten entsteht, etwa von Richtlinie zu Systemklasse zu System zu Projekt zu verantwortlichem Team.
Kernaussage
Graphen machen Beziehungen direkt modellierbar und abfragbar.