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.

One more thing…Intelligenz, die künstliche

Veröffentlicht am von Christoph

„One more thing“ ist eines der berühmtesten Zitate der Neuzeit und es war an diesem 9.Januar 2007 zu spüren, dass hier etwas Revolutionäres geschah. Das lag zu einem hohen Grad an der charismatischen Person von Steve Jobs, aber es bleibt unbestritten, dass dieser kleine Hochleistungscomputer, den wir alle mit uns herumtragen, diese unsere Welt so stark verändert hat wie vielleicht vorher die Erfindung der Dampfmaschine oder des Automobils.

Bild von Gerd Altmann auf Pixabay

Nicht nur im privaten Sektor, sondern auch und gerade im industriellen und beruflichen Kontext funktioniert (fast) nichts mehr ohne Smartphone. Das führt unter anderem dazu, dass ich sogar zwei von diesen Teilen mit mir herumschleppe. Danke, aber kein Mitleid, das ist ein selbstgewähltes Schicksal.

Doch zurück zu besonderen Daten mit diesem „one more thing“. Die grauen Wintermonate scheinen eine gute Kulisse für diese Momente abzugeben, auch wenn der 26.Februar 2024 in unseren Breiten eher frühlingshaft daherkommt. Die Telekom hat an diesem Tag das erste Smartphone auf dem Mobile World Congress vorgestellt, das komplett ohne Apps auskommt. Und die Süddeutsche Zeitung titelt: „Ein neues Zeitalter„.

Nun kann man die Augenbrauen hochziehen – ausgerechnet die Kupferkabel-Telekom aus Deutschland, dem Entwicklungsland für Breitband-Internetzugang und mehr mobilen Funklöchern als Löcher im Schweizer Käse? Die soll jetzt das nächste „one more thing“ haben?

Aber lassen wir diese Polemik mal kurz beiseite, was ist denn dieser „one more thing“ Moment hier? Wir sehen ein Smartphone, dass ein extrem cleanes User Interface hat und nicht für jeden Anwendungsfall eine App anbietet. Das ich natursprachliche Aufgaben geben oder Fragen stellen kann und die KI zeigt mir Lösungsmöglichkeiten oder gibt Antworten auf meine Fragen. Was das für die private Massenanwendung bedeutet, diese Analyse überlasse ich lieber Menschen, die das viel besser können als ich.

Was ich mich aber frage und diese Frage treibt mich wirklich um: Was bedeutet das jetzt für ein PLM-System? Oder machen wir es noch ein bisschen größer, für Unternehmenssoftware im industriellen Wertschöpfungsprozess?

Auch dort haben wir einen „Zoo“ aus verschiedensten Applikationen, angefangen von CRM über PDM-Systeme und deren Autorensysteme bis hin zu EMS und ERP. Und an die Logistik, QM und HR-Systeme möchte ich da noch gar nicht denken. Jede diese Anwendungen bringt dann noch eine ganze Reihe von Funktionen oder Apps mit und eigene Storages für die jeweiligen Daten. An deren Integration arbeiten wir seitdem in den 1990’er Jahren das Wort CIM das erste mal aufkam und stellen uns so der Herausforderung der zunehmenden Komplexität in den Unternehmensprozessen und -entscheidungen. Als eine beispielhafte Technologie soll der Einsatz von Cloud-Technologien und Microservices-Architekturen genannt werden. Microservices ermöglichen die Entwicklung und Wartung einzelner Funktionsbereiche einer Anwendung unabhängig voneinander, was die Komplexität reduziert und die Wartbarkeit verbessert. Cloud-Plattformen bieten zudem die notwendige Infrastruktur und Dienste, um Anwendungen effizient zu betreiben und zu skalieren.

Diese Ansätze finden sich aber eher im Maschinenraum der Unternehmenssoftware wieder. Was ist da aber für den Passagier an Deck, also den Endanwender drin? Wie können Unternehmensanwendungen diesem Endanwender zukünftig bei der Lösung seiner Herausforderungen helfen?

Bild von OpenClipart-Vectors auf PixabayUnd hier möchte ich auf den „one more thing“ Moment der Telekom zurückkommen. Ist der zukünftige Client eines (PLM-)Systems nur noch ein Prompt, dem Fragen gestellt und Anweisungen erteilt werden und die KI macht dann den Rest? Was ist dann überhaupt der Rest? Hier ist eine unvollständige Auflistung:

Automatisierte Datenintegration

Eine KI kann die Identifizierung und Zusammenführung relevanter Daten aus verschiedenen Quellen und Systemen automatisieren. Durch den Einsatz von Machine Learning-Algorithmen können Systeme Muster und Zusammenhänge zwischen Daten aus unterschiedlichen Silos erkennen und diese intelligent verknüpfen. Dies vereinfacht den Integrationsprozess erheblich und ermöglicht so einen konsolidierten Blick auf die Unternehmensdaten. Damit hilft die KI dem Anwender durch den Komplexität der verschiedenen Unternehmensanwendungen und -Systeme.

Intelligente Prozessautomatisierung

Die Automatisierung von Geschäftsprozessen, die Daten aus verschiedenen Systemen benötigen, ist ein weiteren Feld des Einsatzes vom KI. Robotic Process Automation (RPA) in Kombination mit KI ermöglicht es, repetitive Aufgaben, die früher manuelle Dateneingriffe aus verschiedenen Quellen erforderten, zu automatisieren. Dadurch werden Prozesseffizienz gesteigert und Fehler reduziert.

Predictive Analytics und Entscheidungsunterstützung

Durch die Integration und Analyse von Daten aus verschiedenen Silos können KI-Systeme tiefere Einblicke in Geschäftsprozesse bieten und zukünftige Trends vorhersagen. Predictive Analytics ermöglicht es Unternehmen, fundiertere Entscheidungen zu treffen, Risiken zu minimieren und Chancen proaktiv zu nutzen. Kritische Situationen können zeitiger erkannt und darauf aufmerksam gemacht werden.

Verbesserte Datenqualität und -bereinigung

Unzureichende Datenqualität ist eine häufige Herausforderung bei der Arbeit mit Daten aus verschiedenen Silos. KI-gestützte Tools können inkonsistente, unvollständige oder duplizierte Daten automatisch identifizieren und korrigieren. Durch die Bereinigung und Normalisierung der Daten wird deren Nutzbarkeit für Analysen und Entscheidungsprozesse erheblich verbessert.

Diese Aufzählung ist sicher nicht vollständig, aber zeigt wichtige Aspekte aus der PLM-Perspektive auf.

Versuchen wir uns einmal an einem Fazit. „One more thing“ kann zu einer radikalen Komplexitätsreduzierung für den (PLM-) Anwender führen. Ein Durchklicken durch Strukturen und Dashboards in unterschiedlichen Apps und Anwendungen ist nicht mehr nötig. Dagegen können einem Prompt natursprachliche Fragen gestellt und Anweisungen gegeben werden. Die KI versteht diese und kann Lösungen vorschlagen oder Antworten geben. Das ist eine revolutionäre Usability.

Des Weiteren verbessert die durch KI ermöglichte Systemintegration die Datenbasis, auf der die KI operiert und steigert damit direkt die Relevanz, Genauigkeit und Nützlichkeit der KI-generierten Antworten. Das sind dann die richtigen Vorschläge und Anworten, die die KI gibt.