Die Ampel ist grün: Warum KI im PLM einen Graphen braucht

Veröffentlicht am von Christoph

Manchmal liest man einen Artikel und nickt die ganze Zeit. So ging es mir mit dem Whitepaper „Intelligent PLM“ von Martin Eigner und Dirk Alexander Molitor, erschienen im Newsletter „Engineering X AI“. Die Kernaussage: Das wirtschaftliche Potenzial von KI im PLM steckt weniger in generativen CAD-Demos als im administrativen Rückgrat. Änderungsmanagement, Model-Based Engineering, Stücklisten, Konfigurationsmanagement, Qualität. Fünf Säulen, die jeder kennt, der schon mal ein Änderungsverfahren über drei Systeme hinweg verfolgt hat.

Das Whitepaper liefert eine klare Landkarte, wo KI im Engineering-Alltag den größten Nutzen stiftet. Ich möchte den Gedanken gern aufgreifen und eine Ebene tiefer gehen: Auf welchem Fundament stehen diese fünf Säulen?

Die Bausteine stecken bereits im Whitepaper. Abbildung 3 legt unter die Agenten eine Digital-Thread-Schicht aus Objekten und Beziehungen, Abbildung 7 nennt Knowledge/Context Graph und MCP, und Ansatz 1 setzt ausdrücklich auf Graphdatenbanken. Die Architektur ist also gesetzt. Offen bleibt aus meiner Sicht, wie die Agenten auf diesem Graphen suchen. Für ähnliche frühere Änderungen (Abschnitt 3.2) nennen die Autoren Vector Embeddings und semantisches RAG. Genau hier möchte ich ansetzen: Welcher Retrieval-Mechanismus passt zu diesem Graphen, und woher kommt die Verlässlichkeit, die Engineering-Prozesse brauchen? Seit meiner Diplomarbeit 2002 schreibe ich über die Integration von Produktdaten, und eine Haltung hat sich seitdem nur verfestigt: Im Engineering ist „fast richtig“ leider oft „falsch“.

Stücklisten sind keine Texte

Eine Stückliste ist ein gerichteter azyklischer Graph. Ob die Änderung an Baugruppe A die Variante für Kunde B betrifft, steht in keinem Dokument. Es ergibt sich aus der Struktur. Das Gleiche gilt für Konfigurationsbaselines (eingefrorene Graphzustände), für Änderungsanträge (ein Netz aus betroffenen Teilen, auslösenden Anforderungen, Baselines und Vorgängeränderungen) und für FMEAs (Kausalketten aus Fehlermodus, Ursache und Wirkung).

Frage ich ein Vektor-RAG nach ähnlichen Änderungen zu Teil X, bekomme ich Änderungsanträge, deren Text ähnlich klingt. Was ich eigentlich wissen will: Welche Änderungen betrafen Teile an einer vergleichbaren Stelle der Struktur, in einer vergleichbaren Konfiguration, und was ist danach passiert? Das steht nicht im Text. Das steht in den Kanten.

Die Ontologie: das Wissen über das Wissen

Ein Knowledge Graph bringt etwas mit, das ein Vektorspeicher nicht kennt: eine Ontologie. Sie legt fest, welche Objekttypen es gibt und was eine Beziehung bedeutet. „Ist verbaut in“ ist etwas anderes als „wird verifiziert durch“ oder „ersetzt Revision“. Für die Impact-Analyse ist das die Metaebene, die entscheidet, welchen Kanten ich folgen muss und welchen nicht. Eine Materialänderung wandert über Verwendungs- und Funktionsbeziehungen, nicht über den Verweis im Besprechungsprotokoll.

So eine Ontologie entsteht nicht durch eine Suche in Dokumenttexten. Sie verlangt Domänenwissen von Konstrukteuren, Fertigungsplanern und Qualitätsleuten, die wissen, wie ihr Produkt zusammenhängt. Standards wie SysML oder STEP AP242 und die Datenmodelle der PLM- und ERP-Systeme liefern ein gutes Gerüst. Die Feinheiten, etwa wann eine Kante bei einer neuen Revision mitwächst und wann sie festgenagelt bleibt, sind aber unternehmensspezifisch. Genau dieses Wissen macht den Graphen wertvoll.

Vollständigkeit statt Top 10

Vektorsuche liefert per Konstruktion die k ähnlichsten Treffer. Top 10, Top 50, irgendwo wird abgeschnitten. Für eine Impact-Analyse ist das ein grundsätzliches Problem, denn dort zählt nicht, was am ähnlichsten ist, sondern was betroffen ist. Und zwar alles.

Eine Traversierung über den Graphen findet jedes Objekt, das über die relevanten Beziehungen erreichbar ist, bis zur letzten Ebene. Bei versionierten Objekten auch die richtige Revision: Ist die Baugruppe in Revision C betroffen oder erst in D? Hängt die Stückliste noch an der alten oder schon an der neuen Version? Dieses Wissen steckt in Gültigkeiten und Kanten, nicht in Dokumenttexten.

Vollständig heißt dabei nicht wahllos. Über Normteile, Standardschrauben oder zentrale Dokumente ist in einem echten Produktgraphen transitiv fast alles erreichbar. Deshalb braucht es beides: die Ontologie, die festlegt, welchen Kantentypen die Analyse folgt, und eine Gewichtung, die zeigt, wo man zuerst hinschauen sollte. Und natürlich ist der Graph nur so vollständig wie das, was in ihm modelliert ist. Innerhalb dessen ist die Antwort aber vollständig, und das lässt sich nachweisen.

Mathematik aus dem Werkzeugkasten

Graphdatenbanken bringen ganze Bibliotheken mit Graphalgorithmen mit. Zwei davon passen für mich wunderbar zur Impact-Analyse.

Personalisierter PageRank für den Impact Report. Stellt euch vor, ein Konstrukteur will das Material eines Gehäuseteils ändern. Die direkt Betroffenen sind schnell gefunden: Verwendungsnachweis, Zeichnung, Prüfplan. Aber was ist mit dem Dichtungskonzept, das über eine Funktionsbeziehung am Gehäuse hängt? Oder mit der Anforderung zur Schutzart? Der Algorithmus startet am geänderten Teil und berechnet für jedes erreichbare Objekt einen Relevanzwert: Je enger und je vielfältiger ein Objekt mit dem Ausgangspunkt verbunden ist, desto höher. Die Gewichte der Kanten kommen dabei aus der Ontologie: „ist verbaut in“ zählt mehr als „ist dokumentiert in“. Der Impact Report zeigt dann keine flache Liste, sondern eine Rangfolge. Ganz oben die direkt verbauten Teile, dahinter die Dichtung, weiter unten die Serviceanleitung. Das Schöne daran: Auch dieser Wert ist berechnet, nicht geschätzt. Gewichte und Parameter sind Modellierungsentscheidungen, die man einmal fachlich validiert und dokumentiert. Danach gilt: Gleicher Graph, gleiche Parameter, gleicher Wert. Eine Wahrscheinlichkeit im statistischen Sinne ist es nicht, eher eine Gewichtung, die dem Menschen sagt, wo er zuerst hinschauen sollte.

Pfadsuche als Begründung. Im Engineering Review Board fragt die Qualitätsverantwortliche: „Warum steht die Serviceanleitung im Impact Report?“ Die Pfadsuche liefert die Antwort als Kette: Gehäuse → verbaut in Baugruppe B → beschrieben in Serviceanleitung S, Kapitel 4. Kein Sprachmodell, das sich eine plausible Begründung ausdenkt, sondern der konkrete Weg durch den Graphen.

Warum ich Determinismus-Ultra bin

Lesende dieses Blogs wissen, dass „deterministisch“ für mich ein Schlüsselwort ist. Deshalb lohnt sich ein genauer Blick darauf, wo der Determinismus eigentlich herkommt. Das Sprachmodell liefert ihn nicht. Es übersetzt die Frage in eine Abfrage und formuliert am Ende die Antwort, und beides bleibt Wahrscheinlichkeitsrechnung.

Warum wir diesen Übersetzer überhaupt brauchen, hat Friedemann Schulz von Thun schon lange vor ChatGPT erklärt. Wer jemals den Satz „Die Ampel ist grün“ vom Beifahrersitz gehört hat, weiß: Das ist nur zu einem Viertel eine Verkehrsinformation. Der Rest ist Appell, Beziehungsaussage und ein bisschen Ungeduld. Und wir wollen ernsthaft, dass eine Datenbank so etwas versteht? Goethe und Schiller als SPARQL? Menschliche Sprache ist voller Interpretationsspielräume. Das Sprachmodell übersetzt meine unscharfe Frage in eine präzise Abfrage, die der Graph beantworten kann, und löst dabei auf, welches Gehäuse, welche Revision und welches Produkt überhaupt gemeint sind. In der Forschung heißt das Entity Linking. Dabei entscheidet es sich für eine Lesart, und diese Entscheidung muss sichtbar sein.

Bild von Jürgen auf Pixabay

Noch besser ist es, dem Sprachmodell bei der Abfrage gar nicht erst freie Hand zu lassen. Statt selbst Graphabfragen zu formulieren, ruft es vordefinierte, fachlich geprüfte Werkzeuge auf, etwa eine Impact-Analyse mit den Parametern Teil und Revision. Das Sprachmodell wählt das Werkzeug und füllt die Parameter, die Logik dahinter ist festgelegt. Genau dafür sieht Abbildung 7 des Whitepapers Skills und Guardrails in der Agent Harness vor.

Damit ist die Arbeitsteilung klar. Der Graph ist deterministisch: Gleiche Abfrage auf gleichem Stand liefert das gleiche Ergebnis, jedes Mal. Die Wahrheit darüber, welche Teile betroffen sind, welche Baseline gilt und welche Anforderung dahinter steht, liegt im Graphen. Das Sprachmodell darf formulieren, zusammenfassen, einordnen. Es darf aber nicht entscheiden, was stimmt.

Neu ist diese Arbeitsteilung nicht. Die Forschung spricht von neuro-symbolischen Ansätzen, lesenswert ist etwa die Roadmap von Pan et al. zur Verbindung von Sprachmodellen und Knowledge Graphen. Im PLM liegt sie aber besonders nahe, weil die Struktur dort nicht erst mühsam aus Texten gewonnen werden muss. Sie ist längst in unseren Systemen gepflegt.

Bei Vektor-RAG ist dagegen schon das Retrieval unscharf. Es arbeitet mit Ähnlichkeit statt mit Bedeutung und hängt an der Formulierung: etwas andere Frage, anderes Einbettungsmodell, anderer Schwellenwert, und es kommen andere Treffer zurück. Dann liegen zwei unscharfe Schichten übereinander, und im Nachhinein lässt sich kaum sagen, woran es lag.

Mit dem Graphen als Fundament lässt sich dagegen jede Empfehlung auf einen protokollierten Werkzeugaufruf und einen konkreten Teilgraphen zurückführen. Wenn der Auditor fragt, warum das Engineering Review Board eine Änderung freigegeben hat, kann ich es zeigen. Source of Truth statt Source of Plausibility. Das Whitepaper fordert unter „Transparency and Auditability“ genau das, und der Graph ist aus meiner Sicht das Werkzeug, mit dem sich diese Forderung einlösen lässt.

Ohne Graph keine deterministische Grundlage. Dabei bleibe ich.

Wie die Teile zusammenspielen

Nehmen wir das ECM-Szenario aus Abbildung 3 des Whitepapers. Ein Change Orchestrator verteilt Aufgaben an Cost, Compliance und Manufacturing Agent. Damit das sauber funktioniert, braucht es aus meiner Sicht vier Schichten:

  1. Knowledge Graph als Rückgrat des Digital Thread. Anforderungen, Architekturen, CAD, Stücklisten, Fertigung, Qualität und Service als Objekte und Beziehungen, versioniert.
  2. Graph-Retrieval als deterministischer Zugang für die Sprachmodelle, und zwar auf dem gepflegten Produktgraphen, nicht auf einem Graphen, den ein Sprachmodell erst aus Texten extrahiert hat.
  3. MCP als Transportweg zwischen Agenten und Datenquellen. Seit Dezember 2025 bei der Linux Foundation und inzwischen quasi Industriestandard. Wie ich im Protokoll-Artikel geschrieben habe: Das Protokoll wird zum neuen Interface.
  4. A2A für die Abstimmung der Agenten untereinander, also Orchestrator zu Cost Agent. Von Google im April 2025 vorgestellt, seit Juni 2025 ebenfalls bei der Linux Foundation.

MCP ohne Graph bleibt der Glasfaseranschluss ins Haus ohne Grundriss. Und A2A ohne Graph heißt, dass sich mehrere Agenten gegenseitig ihre Plausibilitäten zuspielen. Das wird nicht besser, nur schneller.

Die fünf Säulen durch die Graph-Brille

Im Änderungsmanagement wird aus der Ähnlichkeitssuche eine Traversierung über Stückliste, Baselines und Anforderungen. Man findet alle Betroffenen, nach Relevanz sortiert und mit Begründungspfad.

Model-Based Engineering ist ohnehin graphbasiert. Ein SysML-Modell besteht aus Elementen und Beziehungen, und mit SysML v2 und seiner standardisierten API wird es direkt maschinell abfragbar.

Im Stücklistenmanagement zeigt sich der Unterschied bei der Wiederverwendung. Übernimmt man ein bewährtes Bauteil in ein neues Produkt, wird oft nur das CAD-Modell kopiert. Über den Graphen kommt der ganze Kontext mit: Testprotokolle, Materialzertifikate, Fertigungsstückliste, Freigabestatus. Und man sieht sofort, in welchen anderen Produkten das Teil bereits steckt, was bei der nächsten Änderung den Unterschied macht.

Im Konfigurationsmanagement ist die Frage nach dem gültigen Stand für Seriennummer X zum Datum Y eine Graphabfrage. Dazu habe ich schon vor zwei Jahren über mitwachsende und festgenagelte Kanten geschrieben.

Und im Qualitätsmanagement braucht Eigners „Digital Reasoning Thread“, also das dokumentierte Warum hinter Entscheidungen, genau diese Struktur. Eine DRBFM (Design Review Based on Failure Mode) als Kausalkette im Graphen ist abfragbar. Als PDF im Vektorspeicher ist sie bestenfalls auffindbar.

Das Beste aus beiden Welten

Vektorsuche und klassisches RAG haben natürlich ihre passenden Einsatzfelder: Freitexte, Normen, Serviceberichte, Reklamationen, Lessons Learned. Überall dort, wo das Wissen in Sprache steckt und nicht in Struktur, sind sie stark. In der Praxis liegt die Wahrheit deshalb oft im hybriden Ansatz. Der Graph liefert Struktur, Beziehungen und Vollständigkeit, die Vektorsuche erschließt die unstrukturierten Inhalte, die an den Knoten hängen. Ein Servicebericht wird per Ähnlichkeit gefunden, und der Graph sagt mir, welche Seriennummer, welche Konfiguration und welche Charge dahinterstehen.

Was es dafür braucht

Umsonst gibt es das nicht. Ontologie und Graph müssen aufgebaut und gepflegt werden, und sie müssen mit den führenden Systemen synchron bleiben. Und ein Graph, der alles mit allem verknüpft, muss Berechtigungen respektieren. Das Whitepaper betont zu Recht Need-to-know und exportkontrollierte Daten, und ich hatte schon Ende 2025 geschrieben, dass die KI kein Leck für berechtigungspflichtige Daten werden darf: Eine Traversierung darf nur zeigen, was der Fragende auch sehen darf. Das ist Arbeit, aber es ist die Art von Arbeit, die sich mit jedem weiteren Anwendungsfall erneut auszahlt.

Fazit

Martin Eigner und Dirk Alexander Molitor haben die richtigen fünf Säulen beschrieben. Mein Beitrag ist das Kellergeschoss: Ob der versprochene ROI kommt, entscheidet sich daran, ob die Agenten auf einem deterministischen Graphen arbeiten oder auf Textähnlichkeit. Denn der ROI im administrativen Rückgrat entsteht dort, wo Impact-Analysen vollständig sind, Freigaben im Review Board schneller durchgehen und Fehler gar nicht erst ins Feld gelangen. All das setzt Antworten voraus, auf die man sich verlassen kann. Das Sprachmodell ist der Koch, der Graph ist das Rezeptbuch, wie schon beim Kochen mit KI und einem schlechten Koch. Und im Engineering will ich wissen, was im Rezept steht.