Letzte Woche stand ich vor dem geöffneten Kühlschrank und blickte auf die üblichen Verdächtigen: einen Kohlrabi, Mozzarella, zwei Möhren, drei Eier und eine Packung Udon-Nudeln. Meine kulinarische Kreativität hielt sich in Grenzen, also fragte ich eine den KI-Chatbot meines Vertrauens: „Was kann ich daraus leckeres kochen?“

Die Antwort kam prompt und klang durchaus plausibel. Ein Rezept mit präzisen Mengenangaben und einer Schritt-für-Schritt Anleitung, der ich folgen konnte. Das Ergebnis? Nun ja, technisch gesehen war es essbar. Geschmacklich allerdings eher lieb gemeinte 2 von 5 Sternen. Diese Bewertung könnte auch an meinen sehr limitierten Kochkünsten liegen, aber ich tendiere doch dazu, das jetzt mal auf die KI zu schieben.

Was war passiert? Die KI hatte strukturell korrekt geantwortet. Sie wusste, was ein Rezept ist, wie man es formuliert, welche Zutaten zusammenpassen könnten. Aber sie hatte keine Ahnung vom tatsächlichen Geschmack dieser spezifischen Kombination. Sie halluzinierte sich durch meine geschmacklichen Vorlieben.

Und genau hier wird es interessant für uns PLM-Experten.

Bild von Clker-Free-Vector-Images auf Pixabay

Vom Kühlschrank ins Business – wenn Halluzinationen teuer werden

In meiner Küche war der Schaden überschaubar. Im PLM-Kontext sind Halluzinationen dagegen richtig gefährlich. Ein LLM weiß sehr gut, was eine Mathe-Hausaufgabe ist – das Internet ist voll davon. Millionen von Beispielen haben das Modell trainiert.

Aber ein LLM kennt keine „Change Impact Analyse“ für ein spezifisches CAPA in eurem Unternehmen. Es weiß nicht, welche Komponenten von einer Änderung betroffen sind, welche Freigabeprozesse laufen müssen, welche regulatorischen Anforderungen greifen. Die dafür benötigten Daten liegen in euren digitalen Aktenschränken, in euren PDM-Systemen, ERP-Landschaften, QM-Tools, verteilt über Dutzende Daten Silos.

Das LLM kann euch eine strukturell korrekte Antwort liefern. Aber ob die zu 100% stimmt? Das ist eine andere Frage.

RAG – Die Suche im Heuhaufen

Die naheliegende Lösung heißt RAG: Retrieval-Augmented Generation. Stellt euch einen Bibliothekar vor, der blitzschnell das richtige Buch findet, die relevante Seite aufschlägt und vorliest. RAG durchsucht eure Dokumente, findet die passenden Textabschnitte und füttert damit das LLM. Die Antwort basiert dann auf echten Unternehmensdaten statt auf Internet-Wissen.

Das funktioniert gut für einfache Fragen. „Zeig mir das Lastenheft für Projekt X“ – kein Problem, solange der Projektname im Lastenheft erwähnt wird. Aber RAG stößt schnell an seine Grenzen, sobald es komplexer wird.

Das Problem: RAG findet Dokument A und Dokument B. Es versteht aber nicht die tiefen Abhängigkeiten dazwischen. Es kennt nicht den Digital Thread, der beide verbindet. Es weiß nicht, dass Dokument A in Revision 3 vorliegt, aber die darin beschriebene Komponente gerade in Version 2.1 freigegeben wurde, während die dazugehörige Fertigungsanweisung noch im Draft-Status hängt.

RAG liefert euch die Textbausteine. Aber der Kontext? Der muss immer noch selbst zusammengefügt werden.

Warum PLM Daten so herausfordernd sind

Wir haben es in der industriellen Produktentwicklung mit einer besonderen Art von Datenkomplexität zu tun. Relationale Datenbanken speichern Produktdaten hochstrukturiert ab. Das ist gut für Performance, aber schwierig zur Herstellung der Transparenz über Zusammenhänge. Das ist jetzt wahrlich keine neue Erkenntnis. Über die Notwendigkeit der Abschaffung von Datensilos und die Integration von Produktdaten habe ich auch schon in meiner Diplomarbeit im Jahr 2002 geschrieben.

Dazu kommt die Dynamik: Produktentwicklung bedeutet ständige Änderungen. Versionen, Revisionen, Freigabestatus – jedes Datenobjekt hat eine Geschichte und seinen eigenen Lifecycle. Und diese Geschichte ist relevant. In regulierten Branchen wie der Medizingeräteindustrie müssen wir jederzeit nachvollziehen können, warum eine Entscheidung getroffen wurde. Es gibt nicht nur einen Graphen unserer Produktdaten, sondern viele in der Historie des Engineeringprozesses.

Und dann noch das Sicherheitsrisiko: Die KI darf kein Leck für berechtigungspflichtige Daten werden. Need-to-know-Prinzipien müssen gelten. Sensible Projektdaten bleiben sensibel – auch wenn eine KI darauf zugreifen möchte.

Wie ich in meinem früheren Artikel zu maßgeschneiderten Knowledge Graphen beschrieben habe, brauchen wir Strukturen, die diese Komplexität nicht nur speichern, sondern auch semantisch verstehen. RAG allein reicht dafür nicht aus.

GraphRAG – der Enabler für echte Intelligenz

Hier kommt GraphRAG ins Spiel. Statt nur Texte zu durchsuchen, arbeitet GraphRAG auf einem Knowledge Graphen. Und ein Knowledge Graph ist mehr als eine Datenbank – er ist eine Landkarte der Produktdaten inklusive aller Abhängigkeiten.

Bleiben wir beim Bild des Bibliothekars. Bei RAG liest er einzelne Bücher. Bei GraphRAG hüpft er durch die Bibliothek – von Buch zu Buch, folgt Verweisen, versteht Zusammenhänge. Er weiß: Dieses Kapitel in Buch A bezieht sich auf jenes Kapitel in Buch B, und beide sind relevant für die Frage in Buch C.

Technisch bedeutet das: Die KI folgt den logischen Verknüpfungen von einem Datenobjekt zum nächsten. Sie traversiert den Digital Thread. Sie versteht strukturelle Beziehungen (Parent-Child), funktionale Abhängigkeiten (depends on), Flussbeziehungen (flow between) und sequenzielle Abfolgen (follows).

Die Vorteile:

• Höhere Performance: Graph-Datenbanken sind für diese Art von Abfragen optimiert. Traversierungen sind schnell, auch bei komplexen Abhängigkeiten.
• Mathematische Präzision: Graph-Modelle basieren auf Graphentheorie. Die Beziehungen sind nicht interpretiert, sondern definiert. Das reduziert Fehler massiv.
• Keine Halluzinationen: Der Kontext ist fest verdrahtet. Die KI kann nicht „raten“, weil die Daten strukturell eindeutig sind.
• Zeitliche Abfragefähigkeit: Ein gut gebauter Knowledge Graph unterstützt Versionierung. Die KI kann Fragen zu historischen Zuständen beantworten – essentiell in regulierten Branchen.

Stellt euch vor, ihr fragt: „Welche Bauteile sind von der geplanten Änderung an Komponente X betroffen?“ GraphRAG hüpft durch den Graphen, folgt den Stücklisten, checkt Abhängigkeiten, berücksichtigt Freigabestatus – und liefert euch eine vollständige Liste. Mit Kontext. Mit Historie. Ohne sich was auszudenken.

Hybride Lösungen – die Zukunft liegt in der Kombination

Die Realität wird vermutlich hybrider aussehen. Vektordatenbanken (die Basis für klassisches RAG) sind hervorragend für unstrukturierte Daten geeignet. Graphdatenbanken glänzen bei strukturierten, hochvernetzten Informationen. Die Kombination aus beiden – Vector + Graph – ist der Sweet Spot.

Viele Unternehmen lizenzieren gerade LLMs. Das ist der erste Schritt. Pilotprojekte laufen, Use Cases werden getestet. Aber das volle Vertrauen der User und die echte Power für die Industrie kommen erst durch die Integration von GraphRAG.

Es ist der entscheidende Enabler, da ohne den Digital Thread als semantische Basis KI im PLM-Kontext ein Glücksspiel bleibt. Mit GraphRAG wird daraus ein Werkzeug, dem man vertrauen kann.

Mein Udon-Rezept? Das hätte bei meinen Koch“künsten“ auch GraphRAG nicht gerettet. Aber bei Produktdaten macht es den Unterschied zwischen „klingt plausibel“ und „ist korrekt“. Und das ist in der Industrie der Gamechanger.