Knoten
Knoten repräsentieren Dinge, über die das System sprechen soll: Personen, Produkte, Verträge, Services, Dokumente oder Ereignisse.
Service, Team, Vertrag, Incident
Deep Dive · Knowledge Graphs
Ein Knowledge Graph macht Wissen als Netz aus Dingen und Beziehungen abfragbar. Er hilft, Zusammenhänge über Dokumente, Tabellen und Systeme hinweg zu navigieren und Informationen als verbundene Struktur zu behandeln.
Kuratierter erster Schnitt · Stand Mai 2026
Ein Knowledge Graph speichert Wissen so, dass Beziehungen selbst Teil des Datenmodells sind. Dokumente, Datensätze und ihre Verbindungen werden gemeinsam auffindbar: Wer ist verantwortlich? Was hängt wovon ab? Welche Regel betrifft welchen Prozess?
Praktisch ist ein Knowledge Graph also eine Struktur zum Fragen, Navigieren und Erklären. Eine kann dabei helfen, die Bedeutung der Begriffe sauber zu halten. Der Knowledge Graph ist die konkrete, abfragbare Wissensstruktur, mit der Anwendungen, Analysten oder Agenten arbeiten.
Diese Seite beschreibt Knowledge Graphs vor allem als Domänen-Graphen: fachliche Objekte und ihre Beziehungen. Der Unterschied zu Dokument-Graphen wird auf der GraphRAG-Detailseite erklärt.
Woraus ein Knowledge Graph praktisch besteht
Knoten repräsentieren Dinge, über die das System sprechen soll: Personen, Produkte, Verträge, Services, Dokumente oder Ereignisse.
Service, Team, Vertrag, Incident
Kanten beschreiben konkrete Beziehungen zwischen Knoten. Dadurch wird Wissen auffindbar und navigierbar.
Team betreibt Service, Incident betrifft System
Eigenschaften speichern konkrete Werte an Knoten oder Kanten: Status, Datum, Quelle, Rolle oder Gewichtung.
gültigSeit, Risiko, Quelle, Priorität
Pfade verbinden mehrere Beziehungen zu einer erklärbaren Antwortspur. Das ist der praktische Unterschied zu einer flachen Trefferliste.
Kunde → Vertrag → Klausel → Risiko
Der Wert liegt nicht darin, dass Daten als Graph „moderner“ aussehen. Der Wert entsteht, wenn Beziehungen häufig gefragt, erklärt oder wiederverwendet werden müssen.
01
Ein Knowledge Graph zeigt, welche Dinge zusammengehören, auch wenn sie in verschiedenen Systemen, Dokumenten oder Tabellen liegen.
02
Graphabfragen suchen nach Mustern: Welche Services hängen an System X? Welche Verträge enthalten Klauseln mit Risiko Y?
03
Für RAG und Agenten kann der Graph relevante Entitäten, Nachbarschaften und Pfade liefern, bevor ein LLM formuliert.
Ein Knowledge Graph wird greifbar, wenn man ihn als abfragbares Netz betrachtet: Welche Dinge gibt es, welche Beziehungen verbinden sie, und welche Frage wird dadurch einfacher?
Knoten
Kanten
Welche Teams müssen informiert werden, wenn System X ausfällt?
Knoten
Kanten
Welche Kunden sind von einer geänderten Klausel betroffen?
Knoten
Kanten
Wer kennt sich mit Technologie Y aus und hat passende Projekterfahrung?
Viele Knowledge Graphs starten mit Tabellen und entwickeln daraus explizite Graphmodelle. Im Graph werden wiederkehrende Dinge und Beziehungen als eigene Struktur sichtbar.
(Team: Core) -[:BETREIBT]-> (Service: Atlas)
(Service: Atlas) -[:NUTZT]-> (System: Nova)
(Service: Atlas) -[:NUTZT]-> (System: Reporting API)
(Service: Atlas) { criticality: 'hoch' }
Gute Graphmodelle entstehen selten durch maximale Vollständigkeit. Sie entstehen durch wiederholte Fragen: Was muss navigierbar sein, welche Beziehungen tragen Bedeutung, und was bleibt einfache Eigenschaft?
Wenn man später danach fragen, filtern oder navigieren will, ist ein Begriff meistens ein guter Knotenkandidat.
Beziehungen sollten fachlich lesbar sein: betreibt, nutzt, enthält, betrifft oder ersetzt sind stärker als unspezifische Links.
Ein Wert bleibt Eigenschaft, solange man nicht über ihn navigieren muss. Sobald er eigene Beziehungen trägt, wird er eher ein Knoten.
Zu viele ähnliche Kanten machen Abfragen schwer. Lieber wenige belastbare Beziehungstypen als viele plausible Nuancen.
Graphabfragen sind Muster. Man fragt nach Datensätzen und Beziehungen zwischen Dingen. Die Syntax hier ist illustrativ und zeigt den Denkstil.
MATCH (s:Service {criticality: 'hoch'})-[:NUTZT]->(sys:System)
RETURN s.name, sys.nameMATCH (team:Team)-[:BETREIBT]->(service:Service)-[:NUTZT]->(system:System {name: 'Nova'})
RETURN team.name, service.nameMATCH (a:Service)-[:NUTZT]->(system:System)<-[:NUTZT]-(b:Service)
WHERE a <> b
RETURN a.name, system.name, b.nameEin Knowledge Graph altert. Deshalb braucht er neben Beziehungen auch Herkunft, Zeitpunkt, Gültigkeit und nachvollziehbare Korrekturen.
Ein Knowledge Graph ist ein Datenprodukt. Sobald Teams oder Agenten darauf Entscheidungen stützen, braucht er Produktverantwortung: Qualität, Aktualität, Herkunft und Pflege müssen sichtbar sein.
Wer entscheidet über Begriffe, Kanten, Korrekturen und fachliche Prioritäten?
Wie schnell müssen neue Quellen, geänderte Verantwortungen oder gelöschte Systeme sichtbar werden?
Kann jede Aussage auf Quelle, Zeitpunkt, Import oder manuelle Korrektur zurückgeführt werden?
Welche Stichproben, Testfragen oder Graphmetriken zeigen, dass der Graph verlässlich bleibt?
Beide Themen gehören zusammen und übernehmen unterschiedliche Aufgaben. Der Knowledge Graph ist das arbeitende Netz aus konkreten Dingen und Beziehungen; die kann die fachliche Bedeutungsschicht liefern, die dieses Netz konsistent hält. Der Aufbau dieses Netzes ist das Thema von .
Struktur und Zugriff
Der Knowledge Graph ist das nutzbare Wissensnetz: Knoten, Kanten, Eigenschaften, Abfragen, Pfade und Datenpflege.
Bedeutung und Regeln
Die Ontologie klärt, welche Begriffe und Beziehungstypen fachlich gelten und welche Aussagen erlaubt oder widersprüchlich sind.
Implementierung
Das Graphschema beschreibt, wie der Graph in einer konkreten Datenbank oder Anwendung technisch modelliert ist.
Praxisentscheidung
Für einfache Dokumentensuche ist ein Knowledge Graph oft zu viel. Er wird wertvoll, wenn Fragen regelmäßig über Entitäten, Abhängigkeiten, Verantwortlichkeiten, Regeln oder Pfade laufen. Dann kann der Graph Kontext liefern, den eine reine Trefferliste nicht zuverlässig ausdrückt.
Nächste Schritte