Quelle
Im Steering-Meeting am 12. Mai entscheidet Anna Keller, dass Service Atlas bis Q3 auf System Nova migriert. Ben Meier verantwortet die technische Umsetzung. Risiko: Die alte Reporting-Schnittstelle ist noch nicht freigegeben.
Deep Dive · Graph Construction
Graph Construction beschreibt, wie aus Dokumenten, Tabellen und Ereignissen ein nutzbarer Knowledge Graph entsteht. Entscheidend sind Extraktion, Validierung, Provenance, Entity Resolution und laufende Pflege.
Kuratierter erster Schnitt · Stand Mai 2026
Graph Construction ist die praktische Arbeit, die vor einem guten liegt. Aus Quellen werden konkrete Knoten, Kanten und Eigenschaften. Ein LLM kann dabei helfen, Entitäten und Beziehungen zu erkennen. Fachliche Gültigkeit entsteht durch Regeln, Quellenbezug und Review.
Der wichtigste Perspektivwechsel: Graph Construction ist kein einmaliger Import. Es ist eine Pipeline mit Qualitätsregeln. Quellen ändern sich, Entitäten werden umbenannt, Aussagen veralten und Fehler müssen korrigierbar bleiben.
Die Pipeline als praktische Arbeitsfolge
Zuerst wird geklärt, welche Quellen wirklich graphwürdig sind: Verträge, Tickets, Meetingnotizen, Policies, Tabellen oder Systemevents.
Dokumente werden in verarbeitbare Abschnitte zerlegt. Layout, Tabellen, Überschriften und Metadaten müssen erhalten bleiben.
Das System erkennt Kandidaten für Knoten: Personen, Organisationen, Systeme, Entscheidungen, Risiken, Dokumente oder Ereignisse.
Aus Textstellen werden Beziehungskandidaten: verantwortet, betrifft, enthält, entscheidet, hängt ab von oder verlangt Nachweis.
Gleiche Entitäten werden zusammengeführt. Aliasse, Schreibweisen und Rollen müssen geprüft werden, sonst fragmentiert der Graph.
Extraktionen werden gegen Quellen, Stichproben und Testfragen geprüft. Ohne Validierung bleibt der Graph nur plausibel.
Knoten, Kanten, Eigenschaften, Similarity Edges und Provenance werden in die Graphdatenbank geschrieben, idealerweise nachvollziehbar versioniert.
Neue Dokumente, gelöschte Quellen und geänderte Aussagen brauchen Update- und Korrekturregeln.
Die häufigsten Probleme sehen am Anfang klein aus und werden später teuer: falsche Identitäten, zu generische Beziehungen, fehlende Quellen oder veraltete Aussagen.
Michael Meierhoff, M. Meierhoff und ein E-Mail-Alias werden als drei Personen angelegt.
Ein Dokument erwähnt ein System, aber der Graph interpretiert daraus fälschlich eine technische Abhängigkeit.
Jede sprachliche Nuance wird ein eigener Knotentyp. Der Graph wird präzise wirkend, aber praktisch unbenutzbar.
Alles wird Dokument, Thema oder Person. Beziehungen verlieren ihre fachliche Bedeutung.
Eine alte Entscheidung bleibt im Graph aktiv, obwohl sie durch ein späteres Meeting ersetzt wurde.
Der Graph weiß etwas, kann aber nicht zeigen, aus welcher Quelle, welchem Abschnitt oder welchem Extraktionslauf es stammt.
Das Beispiel zeigt, wie aus einem kurzen Meeting-Text zuerst Kandidaten und dann prüfbare Graph-Aussagen entstehen.
Im Steering-Meeting am 12. Mai entscheidet Anna Keller, dass Service Atlas bis Q3 auf System Nova migriert. Ben Meier verantwortet die technische Umsetzung. Risiko: Die alte Reporting-Schnittstelle ist noch nicht freigegeben.
(Person: Anna Keller) -[:ENTSCHEIDET]-> (Entscheidung: Migration Service Atlas)
(Service: Atlas) -[:MIGRIERT_AUF]-> (System: Nova)
(Person: Ben Meier) -[:VERANTWORTET]-> (Aufgabe: technische Umsetzung)
(Risiko: Reporting-Schnittstelle nicht freigegeben) -[:BETRIFFT]-> (Service: Atlas)
Welche Risiken gefährden die Migration von Service Atlas und wer ist für die Umsetzung verantwortlich?
Ein Startschema muss nicht vollständig sein. Es muss nur genug Struktur geben, damit Extraktion, Review und Abfragen nicht beliebig werden.
Qualitätssicherung
Ein Graph ist erst wertvoll, wenn Nutzer den Aussagen trauen können. Deshalb gehören Provenance, Stichproben, Confidence, Review und Regressionstests direkt zur Construction-Pipeline.
Review ist ein Lernsignal für die Construction-Pipeline. Gute Stichproben zeigen, wo Schema, Prompts oder Entity Resolution nachgeschärft werden müssen.
Gezielt prüfen: neue Quellen, niedrige Confidence, wichtige Beziehungstypen und geschäftskritische Entitäten getrennt samplen.
Knoten sind oft leichter korrekt zu erkennen als Beziehungstyp und Richtung. Review sollte besonders Kanten bewerten.
Akzeptiert, korrigiert, verworfen und unklar sollten als Zustände persistiert werden, damit die Pipeline daraus lernen kann.
Wiederkehrende Fehler werden zu Prompt-, Schema-, Extraktions- oder Ontologie-Anpassungen und fließen in konkrete Korrekturen ein.
Gute Graph Construction braucht nicht sofort eine große formale . Aber sie braucht eine fachliche Leitplanke: Welche Entitätstypen sind erlaubt? Welche Beziehungen bedeuten wirklich etwas? Welche Aussagen müssen geprüft werden?
Ein kleines Schema gibt Extraktion und Review genug Richtung, ohne die Domäne zu überformalisieren.
Beziehungstypen sollten fachlich benannt und begrenzt sein. Sonst entstehen viele plausible, aber schwer nutzbare Kanten.
Das Modell darf wachsen, aber kontrolliert: neue Typen entstehen aus echten Fragen und wiederkehrenden Fehlern.
Praxisentscheidung
Der beste Einstieg ist ein enger Use Case mit wenigen Dokumenttypen und klaren Beispiel-Fragen. Der Graph muss nicht groß sein. Er muss prüfbar sein: mit Quellenbezug, Korrekturmöglichkeit und einer Messlatte für Antwortqualität.
Nächste Schritte