Das GUI stirbt – lang lebe das Protokoll

Veröffentlicht am , aktualisiert am von Christoph

 

Anfang Dezember 2025 hat Google still und leise eine Meldung veröffentlicht, die in der Breite wenig Aufmerksamkeit bekommen hat: Mit Google Workspace Studio können Nutzer jetzt eigene KI-Agenten bauen – per natürlicher Sprache, ohne eine einzige Zeile Code. Die Agenten verbinden sich mit Gmail, Drive, Salesforce, Jira und Dutzenden weiteren Diensten. Sie lesen, entscheiden, handeln. Der Mensch muss nur noch steuern und genehmigen.

Das ist keine isolierte Produktmeldung. Es ist ein Symptom eines strukturellen Wandels, der gerade quer durch die gesamte Softwarelandschaft rollt. Und der uns im PLM-Umfeld fundamental beschäftigen sollte.

„One more thing“ – revisited

Im Februar 2024 habe ich an dieser Stelle gefragt, was es bedeutet, wenn der zukünftige Client eines PLM-Systems nur noch ein Prompt ist, dem Fragen gestellt und Anweisungen erteilt werden. Damals war das eine provokante These. Heute ist es eine Beobachtung, die sich mit jedem Quartal klarer abzeichnet.

Was ich damals noch nicht vollständig durchdacht hatte: Die entscheidende Veränderung liegt nicht auf der Benutzerseite, sondern auf der Anbieterseite. Softwarehersteller müssen ihre Produkte nicht mehr primär für Menschen, sondern für Maschinen lesbar machen. Der neue „Endanwender“ vieler Enterprise-Systeme ist ein
KI-Agent.

Das USB-C-Moment der Unternehmenssoftware

Im November 2024 hat Anthropic das Model Context Protocol (MCP) als Open-Source-Standard veröffentlicht. Die Analogie, die sich dabei durchgesetzt hat, trifft es gut: MCP ist das USB-C für KI-Anwendungen. Wo früher für jede Kombination aus KI-Modell und Datenquelle eine individuelle Integration gebaut werden musste, entsteht jetzt ein universeller Stecker.

Die Adoptionsgeschwindigkeit ist bemerkenswert: OpenAI, Google, Microsoft und AWS haben MCP innerhalb weniger Monate übernommen. Im Dezember 2025 wurde das Protokoll an die Linux Foundation gespendet – ein klares Signal, dass es sich von einem Herstellerstandard zur kritischen Infrastruktur entwickelt hat. Seriöse Quellen sprechen inzwischen von über 10.000 MCP Servern, Tendenz stark steigend.

Das Muster ist immer gleich: Softwareanbieter schaffen programmatische Schnittstellen, über die KI-Agenten ihre Dienste konsumieren können. Die grafische Benutzeroberfläche wird dabei nicht abgeschafft – sie rückt nur in die zweite Reihe. Primäres Interface ist zunehmend das Protokoll.

Was bedeutet das für PLM?

Product Lifecycle Management hat in diesem Kontext eine besondere Ausgangssituation – und besondere Risiken. Die gute Nachricht zuerst: PLM-Systeme sind bereits hochgradig datengetrieben. Strukturierte Produktdaten, Stücklisten, Änderungsprozesse, Freigabehistorien – das ist genau das Material, auf dem KI-Agenten arbeiten können.

Ich habe in diesem Blog mehrfach argumentiert, dass ein Knowledge Graph die richtige Architektur ist, um den Digital Thread als semantische Basis für KI nutzbar zu machen. Diese Grundüberzeugung bleibt unverändert.

Aber die entscheidende Frage ändert sich gerade: Es geht nicht mehr nur darum, ob das PLM-System KI-ready ist. Es geht darum, ob das PLM-System agenten-ready ist.

Ein Blick auf die aktuellen Entwicklungen im Markt zeigt ein gemischtes Bild. Die etablierten PLM-Plattformen investieren massiv in KI-Assistenten und Copilot-Funktionen innerhalb ihrer eigenen Systemgrenzen. Das ist ein sinnvoller erster Schritt. Aber die Systemgrenze ist eben genau das: eine Grenze. Die KI versteht die Produktdaten der jeweiligen Plattform gut, aber sie „kennt“ nicht den Freigabestatus des zugehörigen REACH-Dokuments im QM-System nebenan. Sie navigiert die Stückliste, aber sie traversiert nicht den Digital Thread über Plattformgrenzen hinweg.

Das ist keine Schwäche einzelner Lösungen, sondern eine architektonische Grundfrage: Wie viel Kontext kann eine KI aus einer einzigen Datenquelle schöpfen – und ab wann braucht sie offene Protokolle, die heterogene Quellen ohne manuelle Integration verbinden?

Die eigentliche Gretchen-Frage für die PLM-Industrie

Gartner prognostiziert, dass bis Ende 2026 bis zu 40 Prozent aller Enterprise-Anwendungen aufgabenspezifische KI-Agenten integrieren werden. Das ist eine Zahl, bei der man genau hinschauen sollte. Nicht weil die Prognose zwingend eintrifft, sondern weil sie den Richtungspfeil beschreibt.

Die strategische Frage in der PLM-Industrie lautet eher: Für wen konzipiere ich meines Produkts Schnittstellen – für den Menschen, der durchklickt, oder für den Agenten, der traversiert? Und ja, das ist eine echte Entwurfsentscheidung: Datenmodell, Berechtigungskonzept, Versionierungslogik, Ontologien für Beziehungstypen – all das muss agent-consumable sein, nicht nur human-usable.

Auf der Anwenderseite stellt sich eine spiegelbildliche Frage: Welche PLM-Implementierungen sind so aufgebaut, dass KI-Agenten sinnvoll auf die Daten zugreifen können? Wer heute ein PLM-System einführt oder modernisiert, sollte diese Frage genauso ernst nehmen wie die Frage nach der Benutzerfreundlichkeit der GUI.

Das Protokoll ist das neue Interface

Die GUI stirbt nicht über Nacht. Das wäre eine übertriebene These. Aber ihr relativer Stellenwert verschiebt sich. Softwarehersteller, die ihre Produkte heute nur für menschliche Nutzer bauen, rüsten in einer Kategorie auf, die
morgen vielleicht nicht mehr der primäre Wettbewerbsparameter ist.

Für PLM gilt das in besonderem Maße: Unsere Daten sind komplex, versioniert, beziehungsreich und regulatorisch relevant. Das sind exakt die Eigenschaften, die einen gut gebauten Knowledge Graphen mit MCP-Schnittstelle von einem generischen Vektorspeicher unterscheiden. Wer diesen Baustein richtig setzt, hat das Fundament. Wer ihn ignoriert, hat eine schöne GUI gebaut – für eine Benutzergruppe, die immer seltener fragt.

Vom „one more thing“ im Februar 2024 zum agenten-ready PLM ist es nicht mehr weit. Die Blaupause liegt vor uns.

Jetzt geht es darum, wer sie schnell genug liest.

Long-Running Agents und GraphRAG – Revolution oder Evolution im PLM?

Veröffentlicht am , aktualisiert am von Christoph

 

Hand aufs Herz: Die meisten von uns haben gerade erst verstanden, dass RAG (Retrieval Augmented Generation) mehr ist als nur ein schickes Akronym. Wir haben gelernt, dass wir unsere LLMs „grounden“ müssen, damit sie nicht über unsere Produktdaten halluzinieren. Doch während wir noch überlegen, welche PDF-Dokumente wir in den Vektorspeicher werfen, zieht die Karawane schon weiter.

Der neue Hype heißt Long Running Agents (oder „Claude Cowork“). Die Frage, die jetzt im Raum steht: Brauchen wir den mühsamen Aufbau eines Knowledge Graphen, wenn die KI jetzt ein „Langzeitgedächtnis“ hat und wie ein digitaler Kollege agiert?

Schauen wir uns das Ganze mal unter der PLM-Lupe an. Denn im Engineering ist „fast richtig“ leider oft „falsch“.

Die drei Musketiere der Datenabfrage: Ein technischer Deep Dive

Um zu verstehen, wo die Reise hingeht, müssen wir die Werkzeuge präzise trennen. Denn ein Akkuschrauber ist kein Hammer, auch wenn man mit beiden Nägel einschlagen kann. Mein Akuschrauber weiß ein Lied davon zu singen.

Zuerst wäre da das klassische RAG, das wir als „Document Grounding“ kennen. Es funktioniert über die Suche nach Textähnlichkeiten (Vektoren) in Dokumenten. Für die Frage „Was steht in der Montageanweisung?“ ist das super. Aber in der PLM-Realität versagt dieser Ansatz oft, sobald wir fragen: „Welche Teile sind betroffen?“. Warum? Weil die Antwort nicht in einem einzelnen Dokument steht, sondern zwischen den Zeilen der Systemgrenzen vergraben ist.

Hier kommt GraphRAG ins Spiel, das auf einem Knowledge Graph basiert. Statt Textbausteine zu suchen, arbeitet dieser Ansatz auf einem Netz aus echten Objekten und deren Beziehungen, dem Digital Thread. Das ist die „mathematische Präzision“, die ich oft beschwöre. GraphRAG weiß, dass Teil A zu Baugruppe B gehört, die wiederum von Anforderung C validiert wird. Es findet Pfade und Abhängigkeiten, keine bloßen Wortfetzen.

Ganz neu auf der Bildfläche ist der Cowork-Agent (wie Claude Cowork). Das ist der digitale Praktikant. Er zeichnet sich durch ein User Memory aus und kann eigenständig Werkzeuge (Tools) ausführen. Während RAG eher passiv auf Abruf wartet, kann ein solcher Agent aktiv Suchen anstoßen, den Kontext über Wochen behalten und uns proaktiv unterstützen.

Impact Analyse: Warum Vektor-RAG hier baden geht

Stellen wir uns vor: Ein Entwicklungsingenieur plant eine Änderung an Komponente X. Es soll ein neues Material für ein Gehäuseteil verwendet werden. Die sich anschließende Frage lautet: Welche anderen Bauteile, Spezifikationen und Dokumente sind betroffen?

Wenn ihr ein klassisches RAG nach dem „Impact von Teil X“ fragt, findet es vielleicht das Lastenheft von Teil X. Aber es findet nicht die indirekten Abhängigkeiten. Vektor-Suchen verstehen keine Hierarchien oder „Where-used“-Beziehungen.

Der GraphRAG-Vorteil liegt in der Traversierung: Er folgt dem Digital Thread von der Mechanik zur Software bis hin zu den Requirements. Er liefert eine vollständige Liste der Betroffenen, weil die Beziehungen explizit modelliert und nicht nur statistisch erraten sind.

Ein Coworker-Agent wiederum setzt dem Ganzen die Krone auf: Er könnte hergehen, die Impacted Objects aus dem Graphen ziehen und dann eigenständig die betroffenen Fachabteilungen in Teams anschreiben, um eine erste Einschätzung einzuholen. Der Agent ist also der Prozessor, während der Graph die unumstößliche Source of Truth bleibt.

Weitere Use Cases aus dem Engineering

Wenn wir tiefer graben, ergeben sich Szenarien, die erst durch die Kombination von Agenten-Gedächtnis und Graph-Struktur wirklich fliegen:

  • Compliance-Check in der Prozessindustrie: Ein Agent könnte neue REACH-Verordnungen überwachen (Retrieval). Er nutzt dann den Knowledge Graphen, um sofort alle Rezepturen zu identifizieren, die den kritischen Inhaltsstoff enthalten, und erstellt automatisch einen Entwurf für einen Änderungsantrag.
  • Varianten-Bereinigung in der diskreten Fertigung: Ein Agent analysiert über Wochen hinweg die Verkaufszahlen im ERP und korreliert sie über den Knowledge Graphen mit der technischen Komplexität im PLM. Er schlägt aktiv vor, welche Varianten aufgrund hoher Herstellkosten bei geringer Marge eingestellt werden sollten.
  • Root-Cause-Analyse im Service: Tritt ein Fehler im Feld auf, liest der Agent die Serviceberichte (RAG) und verfolgt im Graphen präzise zurück, welche Charge von welcher Fertigungslinie in diesem Zeitraum betroffen war.

Fazit: Brauchen wir den Knowledge Graphen noch?

Einige behaupten, dass die riesigen Kontextfenster und das neue Gedächtnis der Agenten den Graphen ersetzen könnten. Schließlich erlaubt das Model Context Protocol (MCP) von Anthropic einem „Coworker-Agenten“ wie Claude, sich per „Plug-and-Play“ mit externen Quellen zu verbinden, z.B. von SQL-Datenbanken über Jira bis hin zum lokalen Dateisystem. Der Agent agiert hier wie ein digitaler Kollege mit einem unendlichen Satz an Adaptern.

Das klingt nach einer Revolution und für bestimmte Use Cases ist es das auch. Wenn ein Agent ad hoc eine Zusammenfassung über die letzten Änderungen an einem Bauteil schreiben soll, kann er per MCP die Tickets in Jira lesen, die E-Mails im Outlook-Server durchforsten und die CAD-Metadaten ziehen. Er baut sich in seinem Kontextfenster eine Art „Ad-hoc-Knowledge-Graph“ auf. Das ist ein gigantischer Fortschritt gegenüber reinen LLMs, die nur auf veralteten Trainingsdaten basieren.

Doch hier lauert die „Probabilistische Falle“, die wir im PLM nicht ignorieren dürfen.

Damit dieser ad hoc erzeugte Kontext korrekt ist, muss der Agent zwei Dinge wissen: Wo sind die Daten und wie hängen sie semantisch zusammen? Bei einem MCP-basierten Ansatz muss dieses „Beziehungswissen“ entweder mühsam im System-Prompt mitgegeben werden (was das Kontextfenster belastet und bei komplexen Produktstrukturen schnell instabil wird) oder der Agent muss die Zusammenhänge zwischen den Quellen interpretieren. Er muss raten, ob die „Revision“ aus dem PDM-System wirklich logisch deckungsgleich mit dem „Gültigkeit“ im ERP verbunden ist.

Hier liegt der entscheidende Unterschied:

  • Der Knowledge Graph ist deterministisch: Er hat die Ontologie (das Regelwerk des Beziehungswissens) fest „im Bauch“. Die Beziehungen (der Digital Thread) sind dort explizit modelliert und verifiziert. Wenn ich den Graphen frage, welche Baugruppe von einer Anforderungsänderung betroffen ist, ist die Antwort eine mathematische Gewissheit.
  • Der Agent ist probabilistisch: Er versucht, die Beziehungen auf Basis von Wahrscheinlichkeiten zu rekonstruieren. Er baut keine „Source of Truth“, sondern eine „Source of Plausibility“.

MCP ist der perfekte „Transportweg“, um die KI mit der echten Welt zu verbinden. Aber MCP ohne einen darunterliegenden Knowledge Graphen ist wie ein hochmoderner Glasfaseranschluss in ein Haus ohne Grundriss: Der Agent findet zwar alle Zimmer (Datenquellen), weiß aber nicht, welche Wand tragend ist und wo die Leitungen verlaufen.

Im PLM brauchen wir Determinisierung. Wir müssen beweisen können, warum eine Engineering-Entscheidung getroffen wurde. Ein Agent, der sein Wissen nur ad hoc aus MCP-Sourcen und seinem „Memory“ zusammenwürfelt, bleibt eine Blackbox. Der Digital Thread im Knowledge Graph bleibt daher das Pflichtprogramm. Er liefert die semantische Landkarte. Der Agent ist die Kür. Er ist derjenige, der auf dieser Landkarte die Arbeit erledigt.

Kurz gesagt: Der Knowledge Graph ist das Rezeptbuch, MCP ist die Zutatensuche, und der Agent ist der Koch. Ohne Rezeptbuch weiß der beste Koch nicht, ob er gerade ein Flugzeugteil oder eine Kaffeemaschine konstruiert.

GraphRAG – oder Kochen mit künstlicher Intelligenz und einem schlechten Koch

Veröffentlicht am von Christoph

 

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.

 

GraphAI – wenn Knowledge Graphen und GenAI zusammenfinden

Veröffentlicht am von Christoph

In meinem letzten Blogartikel habe ich das Konzept eines Knowledge Graphen etwas näher betrachtet. Heute möchte ich diese Gedanken aufgreifen und über die Effekte und Auswirkungen sprechen, wenn man diesen Knowledge Graphen und GenAI zusammenbringt.

Wir erleben gerade den Beginn einer neuen Ära, in der künstliche Intelligenz (KI) und maschinelles Lernen (ML) die Landschaft der Produktentwicklung neu gestaltet. Dabei spielt der Knowledge Graph eine zentrale Rolle. Diese mächtige Struktur ermöglicht es, Informationen aus und in der Produktentwicklung auf eine Weise zu verknüpfen und zu nutzen, die weit über traditionelle Datenbanken hinausgeht.
Eine der vielversprechendsten Ansätze, die diesen Produktentwicklungsprozess revolutioniert, ist die Integration von Knowledge Graphs mit Generative AI (GenAI). Diese Kombination ermöglicht es, komplexe Zusammenhänge zu verstehen und fundierte Entscheidungen zu treffen. Doch wie genau funktioniert das? Und welche konkreten Vorteile bringt es in der Praxis?

Technologische Grundlagen: Vektorisierung und die Verbindung von LLMs und Knowledge Graphs

Um zu verstehen, wie diese Technologie funktioniert, müssen wir uns zwei zentrale Konzepte ansehen: die Vektorisierung und die Verbindung von großen Sprachmodellen (LLMs) mit Knowledge Graphs.

Vektorisierung ist der Prozess, bei dem Informationen in numerische Vektoren umgewandelt werden. Diese Vektoren repräsentieren Daten so, dass maschinelle Lernmodelle sie effizient verarbeiten können. Texte, Bilder und andere Datenquellen werden in ein Format gebracht, das LLMs verstehen können. Dadurch wird es möglich, semantische Bedeutungen und kontextuelle Beziehungen zu erkennen.

Ein Knowledge Graph strukturiert Informationen in einem Netz aus Entitäten und deren Beziehungen. Stellen Sie sich das wie ein riesiges, intelligentes Diagramm vor, das Wissen nicht nur speichert, sondern auch die Verbindungen zwischen den Daten versteht. Wenn LLMs, die unstrukturierte Daten analysieren und generieren können, auf diese strukturierten Daten zugreifen, entsteht eine mächtige Symbiose. Diese Verbindung ermöglicht eine tiefere Einsicht und eine umfassendere Nutzung der vorhandenen Informationen.

Soweit die Theorie – aber was heisst das jetzt konkret in der Praxis? Schauen wir uns einmal konkrete Anwendungsfälle an.

Produktentwicklung (New Product Introduction NPI):

Ein Medizingerätehersteller plant die Entwicklung eines neuen tragbaren Überwachungsgeräts für Patienten mit Herzproblemen. Die Planung und das Aufsetzen eines solchen Produktentwicklungsprojekts ist sehr komplex und unterliegt strengen regulatorischen Anforderungen.

Der Knowledge Graph dieses Unternehmens enthält eine immense Fülle von Informationen: historische Projektdaten, wissenschaftliche Studien, Patente, regulatorische Vorgaben und Marktanalysen. Diese Daten können vektorisiert und mit einem LLM verknüpft werden. Das LLM kann diese die Daten analysieren und identifiziert daraus relevante Informationen, die für die Entwicklung des neuen Medizingeräts wichtig sind oder die wiederverwendet werden können.

Das LLM kann durch den Knowledge Graph auf alle relevanten gesetzlichen Bestimmungen und auf Daten aus vergangenen Entwicklungsprojekten zugreifen. So kann eine Liste der erforderlichen Dokumentationen und klinischen Studien zur Übermittlung an die Aufsichtsbehörden generiert werden. Zudem kann es es Best Practices vorschlagen, die aus erfolgreichen Einreichungen abgeleitet wurden. Dies erleichtert das Zusammenstellen der notwendigen Unterlagen und minimiert das Risiko von Verzögerungen aufgrund unvollständiger oder fehlerhafter regulatorischer Dokumente.

Der Knowledge Graph enthält Daten über Ressourcen, frühere Projektzeitpläne und Zulieferer. Das LLM kann diese Informationen analysieren und so einen optimalen Projektplan erstellen. Dabei werden mögliche Engpässe identifiziert und Alternativen und Lösungen unter Berücksichtigung der Projekthistorie und aktuellen regulatorische Anforderungen vorgeschlagen. Auch die Auswahl geeigneter Zulieferer und Partner für klinische Studien wird durch das System unterstützt, indem es auf vergangene Leistungsdaten und aktuelle Marktanalysen zugreift.

Während der Projektlaufzeit kann das LLM in Echtzeit auf neue Daten zugreifen und den Knowledge Graph aktualisieren. Es überwacht den Fortschritt des Projekts, erkennt frühzeitig mögliche Abweichungen und schlägt proaktive Maßnahmen vor, um diese zu korrigieren. Dadurch bleibt das Projekt flexibel und kann schnell auf unerwartete Herausforderungen reagieren.

Research und Design:

Im Bereich Research und Design kann die Integration von GenAI und Knowledge Graphs die Kreativität und Effizienz erheblich steigern. Nehmen wir an, ein Designer arbeitet an einem neuen, nachhaltigen Material für Verpackungen. Der Knowledge Graph verknüpft wissenschaftliche Artikel, Patente, Markttrends und Umweltdaten. Ein LLM kann diese Informationen analysieren und dem Designer nicht nur relevante Daten liefern, sondern auch innovative Vorschläge generieren, die auf den neuesten Erkenntnissen basieren. Dadurch können neue Materialien schneller entwickelt und auf den Markt gebracht werden, die den aktuellen Anforderungen und Trends entsprechen.

Fertigung:

In der Fertigung kann diese Technologie dazu beitragen, Produktionsprozesse zu optimieren und Ausfallzeiten zu minimieren. Stellen Sie sich eine Produktionslinie vor, die kontinuierlich Daten über Maschinenleistung, Materialqualität und Produktionsgeschwindigkeit sammelt. Diese Daten werden vektorisiert und in den Knowledge Graph integriert. Ein LLM kann diese Informationen in Echtzeit analysieren und Vorhersagen über potenzielle Probleme treffen, bevor sie auftreten. Es kann auch Optimierungsvorschläge machen, um die Effizienz zu steigern und Kosten zu senken. Zum Beispiel könnte das System erkennen, dass eine bestimmte Maschine bald gewartet werden muss und somit proaktiv Maßnahmen vorschlagen, um Unterbrechungen im Produktionsprozess zu vermeiden. Oder im Falle eines unerwarteten Ausfalls einer Anlage nach alternativen Lösungen suchen.

Das sollen nur einige Beispiele sein, die das Potenzial einer Verknüpfung dieser beiden Kernelemente aufzeigen sollen. Die Integration von Knowledge Graphs und Generative AI bietet Unternehmen eine leistungsstarke Möglichkeit, ihre Produktentwicklung zu revolutionieren. Durch die Vektorisierung von Daten und die Verbindung von LLMs mit strukturierten Informationen können tiefere Einblicke gewonnen und fundierte Entscheidungen getroffen werden. Ob in der Projektplanung, im Research und Design oder in der Fertigung – die Vorteile dieser Technologie sind vielfältig und helfen Unternehmen, innovativer und effizienter zu arbeiten.

Maßgeschneiderte digitale Fäden und Knowledge Graphen

Veröffentlicht am , aktualisiert am von Christoph

In Implementierungsprojekten von Unternehmenssoftware und insbesondere PLM-Systemen spricht man davon, dass diese Systeme an die jeweiligen Geschäftsprozesse angepasst und wie ein Maßanzug geschneidert werden müssen. Und maßgeschneiderte Anzüge zeichnen sich auch durch sehr guten Zwirn aus und dieses Nähgarn ist in Industrieunternehmen der Digital Thread.

Bild von WaveGenerics auf Pixabay

Der Begriff „Digital Thread“ bezieht sich auf die digitale Verknüpfung von Daten und Informationen, die über den gesamten Lebenszyklus eines Produkts oder Systems fließen. In der Produktentwicklung  spielt er eine entscheidende Rolle, indem er eine durchgängige, digitale Informationskette schafft, die von der Konzeption über die Entwicklung und Fertigung bis hin zum Betrieb und ggf. Recycling eines Produkts reicht. Es ist also ein recht langer Faden mit einer gewissen Reißfestigkeit.

In der heutigen digitalen Ära erweist sich ein Knowledge Graphen als das passende Werkzeug für das Verständnis komplexer Datenlandschaften und eine Realisierung eines vollständigen Digital Threads. Um zu verstehen, wie ein Knowledge Graph die konzeptionelle Umsetzung eines umfassenden Digital Threads darstellt, lohnt es sich, einen Blick auf die Grundlagen der Graphentheorie und insbesondere auf gerichtete Graphenmodelle zu werfen.

Die Graphentheorie befasst sich mit der Untersuchung von Graphen, die aus Knoten (oder Ecken) und Kanten (Verbindungen zwischen diesen Knoten) bestehen. Graphen dienen als abstrakte Modelle zur Darstellung von Beziehungen zwischen Objekten und sind in der Lage, komplexe interdisziplinäre Netzwerke zu beschreiben.

Gerichtete Graphen sind eine spezielle Art von Graphen, bei denen jede Kante eine Richtung aufweist. Dies bedeutet, dass die Beziehung zwischen zwei Knoten nicht symmetrisch ist; vielmehr zeigt die Kante von einem Knoten (dem Ursprung) zu einem anderen Knoten (dem Ziel). Diese gerichteten Verbindungen eignen sich hervorragend zur Darstellung von Datenflüssen, Abhängigkeiten und Hierarchien, was sie zu einem idealen Modell für die Strukturierung von Knowledge Graphen macht.

Ein Knowledge Graph nutzt diese gerichteten Graphenmodelle, um Wissen und Informationen innerhalb eines bestimmten Kontexts zu organisieren und darzustellen. Jeder Knoten im Graphen repräsentiert ein Datenobjekt (z.B. ein Produkt, eine Komponente oder einen Prozess), während jede gerichtete Kante eine Beziehung oder Abhängigkeit zwischen diesen Objekten symbolisiert. Durch die Einbettung von Metadaten und Eigenschaften in Knoten und Kanten werden komplexe Informationsnetzwerke erschaffen, die nicht nur die Einzelteile, sondern auch deren Interaktionen und Abhängigkeiten darstellen.

Im Rahmen eines Digital Threads ermöglicht der Einsatz eines Knowledge Graphen die konzeptionelle Verwirklichung einer vollständig vernetzten und interaktiven Datenlandschaft. Er verknüpft alle relevanten Informationen und Prozesse entlang des gesamten Lebenszyklus eines Produkts oder Systems. Von der ersten Idee über Design, Entwicklung, Fertigung bis hin zur Nutzung und Wartung werden alle Daten und Beziehungen in einem zentralen, durchsuchbaren und erweiterbaren Modell abgebildet. Diese umfassende Vernetzung fördert nicht nur eine effizientere Datenverwaltung und Entscheidungsfindung, sondern unterstützt auch die Agilität und Innovationsfähigkeit von Unternehmen.

Durch die Anwendung von Graphentheorie und gerichteten Graphenmodellen in Knowledge Graphen werden somit die theoretischen Grundlagen und technologischen Rahmenbedingungen für die Realisierung eines Digital Threads geschaffen. Soweit die akademische Theorie.

Das was bedeutet das jetzt in der praktischen Umsetzung und welche Herausforderungen lauern dort?

Heterogene Datenquellen

Eine verteilte Systemlandschaft und eine eher vielschichtige IT-Unternehmensarchitektur ist in den allermeisten Fällen die Realität in Unternehmen, auch wenn sich PLM- und ERP-Systeme als Integrationsschichten etabliert haben. Neben der rein technischen Herausforderung birgt das auch eine organisatorische Aufgabe. Zum organisatorischen Aspekt verweise ich gern auf den diesen Blogartikel und möchte weitere beachtenswerte Punkte benennen:

  • Datenintegration: Heterogene Datenquellen können in unterschiedlichen Formaten vorliegen, darunter strukturierte Daten (z.B. in relationalen Datenbanken), semi-strukturierte Daten (z.B. XML, JSON) und unstrukturierte Daten (z.B. Textdokumente, E-Mails). Die Integration dieser vielfältigen Daten in einen kohärenten Knowledge Graph erfordert effektive Methoden zur Datenextraktion, -transformation und -ladung (ETL-Prozesse).
  • Datenqualität und -konsistenz: Die Qualität und Konsistenz der Daten aus heterogenen Quellen kann stark variieren. Probleme wie unvollständige Daten, Duplikate, Inkonsistenzen und Fehler müssen identifiziert und bereinigt werden, um die Integrität und Nützlichkeit des Knowledge Graphen zu gewährleisten.
  • Semantische Heterogenität: Unterschiedliche Datenquellen verwenden oft verschiedene Terminologien und Konzepte, um ähnliche Dinge zu beschreiben. Die Überbrückung dieser semantischen Lücken erfordert die Entwicklung eines gemeinsamen Vokabulars oder Ontologien, die die Beziehungen und Bedeutungen der Daten innerhalb des Knowledge Graphen definieren.
  • Skalierbarkeit und Leistung: Mit der Integration heterogener Datenquellen kann der Umfang eines Knowledge Graphen schnell anwachsen. Die Sicherstellung der Skalierbarkeit und der Leistung bei der Abfrage und Aktualisierung des Graphen, insbesondere in Echtzeitanwendungen, ist eine technische Herausforderung.
  • Datensicherheit und Datenschutz: Heterogene Datenquellen können sensible oder persönliche Informationen enthalten, die geschützt werden müssen. Die Implementierung von Datenschutz- und Sicherheitsmaßnahmen, die den rechtlichen Anforderungen entsprechen, ist entscheidend, um die Vertraulichkeit und Integrität der Daten im Knowledge Graph zu gewährleisten. Das betrifft natürlich auch sensible, besonders schützenwerte Projektdaten, die einer Geheimhaltung oder einem Need-to-know Prinzip unterliegen.

 

Sehr hohe Dynamik im Lebenszyklus der Daten

Gerade Produktentwicklungsprozesse unterliegen einer großen Dynamik und sorgen damit für viele Änderungen an den Produktdaten. Vielfach werden (und müssen – gerade in regulierten Branchen wie der Medizingeräteindustrie) diese Änderungen durch neue Revisionen und Versionen der Datenobjekte abgebildet. Somit bleibt die Entstehungsgeschichte erhalten und kann jederzeit nachvollzogen werden.

Aus dieser Dynamik und den darin enthaltenen historischen Datenobjekten ergeben sich folgende Herausforderungen:

  • Zeitliche Abfragefähigkeit: Ein Knowledge Graph, der historische Datenobjekte effektiv verwalten soll, muss Abfragen unterstützen, die sich auf den Zustand des Graphen zu einem bestimmten historischen Zeitpunkt beziehen. Dies erfordert die Implementierung von Zeitstempeln oder Versionierungskonzepten, die es ermöglichen, die Evolution von Datenobjekten im Zeitverlauf nachzuvollziehen. Diese Nachvollziehbarkeit ist in regulierten Branchen (Luftfahrt, Medizingeräteindustrie, …) essentiell wichtig. Es gibt nicht nur einen Graphen, sondern viele in der Historie des Engineeringprozesses.
  • Versionierung und Historie: Die Handhabung der Versionierung von Datenobjekten ist eine zentrale Herausforderung. Es muss entschieden werden, wie Änderungen an Objekten im Graphen gespeichert werden – ob durch das Hinzufügen neuer Versionen von Objekten bei jeder Änderung, oder durch die Speicherung von Differenzen zwischen Versionen. Ebenso ist das Verhalten der Kante (Relation) bei Änderungen des Quell- oder Zielobjektes wichtig. „Wächst“ die Kante automatisch mit, zeigt also immer auf die letzte Version? Oder bleibt sie fest auf der Version kleben, auf der sie erzeugt wurde? Oft kann dieses Verhalten auch vom Status der Datenobjekte abhängen und sich bei der Freigabe eines Objektes von „Mitwachsen“ auf „Fest“ ändern.
  • Dynamische Datenaktualisierung: In vielen Anwendungsfällen müssen Daten in Echtzeit oder nahezu in Echtzeit aktualisiert werden, um den Knowledge Graph aktuell zu halten. Die Handhabung von Änderungen in den Datenquellen und die Sicherstellung, dass der Graph diese Änderungen zeitnah reflektiert, stellt eine große Herausforderung dar. Das gilt umso mehr, je heterogener die Systemlandschaft ist und die Datenobjekte über verschiedene System verteilt sind.
  • Effizienz der Datenspeicherung und die Performance von Abfragen: Mit der zunehmenden Anzahl historischer Datenobjekte und Versionen kann der Speicherbedarf eines Knowledge Graphen erheblich wachsen. Effiziente Speicherlösungen und -strategien sind notwendig, um die Skalierbarkeit des Systems zu gewährleisten. Optimierungen und spezialisierte Indexierungsmechanismen können erforderlich sein, um akzeptable Antwortzeiten zu gewährleisten.

Die Qualität oder Bedeutung der Relationen

Knowledge Graphen ermöglichen es, komplexe Zusammenhänge und Beziehungen zwischen Datenpunkten, also Entitäten, auf intuitive und effektive Weise darzustellen. Aber nicht alle Relationen in diesen Graphen sind gleich; sie tragen unterschiedliche Bedeutungen und Eigenschaften, die für verschiedene Anwendungsfälle entscheidend sind. Manchen Bindungen sind eher lose, aber deswegen nicht weniger wichtig, anderen wieder enger und fester.

Im Kontext des Systems Engineering können die Relationen in Knowledge Graphen grob in verschiedene Kategorien eingeteilt werden, basierend auf Beziehungstypen, die in der Systemmodellierung üblich sind. Dazu gehören:

  • Strukturelle Beziehungen (Parent-Child): Diese definieren die hierarchische Anordnung von Systemkomponenten. Ein „Parent“-Element beinhaltet ein oder mehrere „Child“-Elemente. Diese Beziehungen sind entscheidend für die Darstellung der Systemarchitektur und für das Verständnis, wie sich Teile zu einem Ganzen zusammenfügen. Stücklisten sind ein gutes Beispiel dafür.
  • Funktionale Beziehungen (depends on): Sie beschreiben, wie bestimmte Funktionen oder Prozesse voneinander abhängen. Zum Beispiel kann die Funktion „Energie bereitstellen“ von der Komponente „Batterie“ abhängen. Solche Abhängigkeiten sind kritisch, um zu verstehen, wie Änderungen an einem Teil des Systems Auswirkungen auf andere haben können.
  • Flussbeziehungen (flow between): Diese repräsentieren den Fluss von Material, Energie oder Informationen zwischen verschiedenen Komponenten oder Prozessen. Sie sind essenziell für die Optimierung von Prozessabläufen und die Effizienzsteigerung innerhalb des Systems.
  • Sequenzielle Beziehungen (follows): Dabei geht es um die Reihenfolge, in der Aufgaben oder Prozesse ausgeführt werden müssen. Dies ist besonders wichtig für die Planung und Koordination von Arbeitsabläufen.

Die Einbettung dieser Beziehungstypen in Knowledge Graphen, angelehnt an Industriestandards wie die Systems Modeling Language (SysML), bietet einen gute Grundlage für diese Abbildung. Es geht darum, die Kanten „intelligent“ zu machen und somit die Komplexität eine Knowledge Graphen überhaupt erst beherrschen zu können.

In meinem letzten Blogartikel haben ich über die „One more Thing“-Momente gesprochen und wie künstliche Intelligenz Software für Unternehmen verändern wird. Natürlich kann man hier den Knowledge Graphen nicht ausklammern. Ganz im Gegenteil, gerade der ermöglicht spannende Anwendungen und löst kritische Herausforderungen im Zusammenwirken mit künstlicher Intelligenz. Diese Aspekte möchte ich aber in einem separaten Artikel aufgreifen.