Warum Supply-Chain-Agenten Knowledge Graphs brauchen

Executive Summary

• Produktstrukturen in der Supply Chain sind tief hierarchisch. Relationale Tabellen flachen diese Hierarchie ab, komprimieren oder denormalisieren sie. Dadurch wird es für Menschen wie für automatisierte Agenten schwierig, Beziehungen und Abhängigkeiten der Stücklisten (Bills of Materials, BOMs) zu interpretieren.
• Herkömmliche KI-Agenten haben damit zu kämpfen, weil sie die Beziehungen mit komplexen Operationen aus den Tabellen rekonstruieren müssen. Mit wachsender Komplexität wird das Reasoning brüchig und fehleranfällig.
• Ein Schema-RAG-Agent auf Basis eines Knowledge Graph macht alle Beziehungen für den Agenten explizit. Er navigiert BOMs, Komponenten und Initiativen präzise, ohne sie rekonstruieren zu müssen – das Ergebnis ist eine genauere Entscheidungsunterstützung.

Einleitung

In Supply-Chain- und Fertigungsumgebungen liegen Produktstrukturen selten an einem einzigen Ort. Sie verteilen sich über viele relationale Tabellen oder werden in einen einzigen, extrem breiten Datensatz gepresst. Diese Tabellen bilden typischerweise Stücklisten (Bills of Materials, BOMs) ab: Jede BOM beschreibt ein Produkt oder eine Baugruppe, und jeder Eintrag verweist auf eine weitere BOM oder eine Komponente. Zusammen bilden sie eine tief verschachtelte Hierarchie von Teilen.

Werden diese Strukturen als Tabellen ausgedrückt, wird die Hierarchie implizit. Sie wieder zusammenzusetzen erfordert, Identifier zu interpretieren, Datensätze zusammenzufügen und eine komplexe Abfrage zu formulieren, die die benötigten Informationen zurückgibt.

Besonders deutlich werden diese Grenzen, wenn Organisationen KI-Agenten einsetzen, um natürlichsprachliche Fragen durch Reasoning über Daten mit eingebetteter Hierarchie zu beantworten. Ohne explizite Struktur und expliziten Kontext haben selbst fortgeschrittene Agenten Mühe, Verschachtelung, Abhängigkeiten oder die Fortpflanzung von Änderungen durch Baugruppen hinweg zu verstehen. Statt eine klare Hierarchie zu navigieren, muss der Agent sie über komplexe SQL-Abfragen rekonstruieren.

BOM-Beispiel: Batterien für Elektrofahrzeuge

Nehmen wir ein Elektroauto. Es besteht aus Hunderten von Baugruppen: Türen, Lenksysteme, Sitze, Räder, Batterien und unzähligen Unterbaugruppen. Jede Baugruppe hat ihre eigene BOM. Jede BOM verweist auf Unterbaugruppen, die wiederum auf kleinere Teile verweisen – bis hinunter zu den Schrauben. Zusammengenommen bilden diese BOMs eine mehrstufige Hierarchie mit Tausenden von Knoten.

Auf diese Struktur wenden Organisationen laufende Initiativen an: technische Änderungen, Sicherheitsupdates und Modelljahr-Revisionen. Diese Initiativen bestimmen, ob ein BOM-Eintrag aktiv, neu eingeführt oder ausgelaufen ist. Um den aktuellen Zustand eines Produkts zu verstehen, muss ein System zwei Logiken kombinieren:

• die verschachtelte Hierarchie der BOMs
• die initiativengetriebenen Regeln, die diese Hierarchie im Zeitverlauf verändern

Eine vereinfachte Aufschlüsselung einer EV-Batterie verdeutlicht die Komplexität (siehe Diagramm):

• Battery Pack: die Baugruppe auf Fahrzeugebene
• Batteriemodule: Gruppen von Zellen
• Batteriezellen: elektrochemische Einheiten, die Energie speichern
• Zellinterne Komponenten: Elektrodenstapel, Gehäuse, Terminals, Ableiterfahnen
• Mechanische Verbindungselemente: Schrauben, die strukturelle oder elektrische Verbindungen sichern
• Systeme auf Pack-Ebene: Kühlung, Hochvolt-Schütze, Batteriemanagementsystem

Schon dieses vereinfachte Modell erzeugt eine große, hierarchische Struktur. Product-Lifecycle-Management-Systeme (PLM) wie Dassault 3DEXPERIENCE verwalten sie explizit als Produktstrukturbaum. In relationalen Tabellen gespeichert, wird diese Struktur jedoch schwer erkennbar. Und genau hier beginnen die Schwierigkeiten für KI-Agenten.

Warum herkömmliche KI-Agenten scheitern

Wird die mehrstufige Produktstruktur in Tabellen aufgelöst, werden selbst einfache Fragen für einen KI-Agenten unerwartet schwierig. Ein naheliegendes Beispiel:

„Welche Fahrzeugmodelle waren vom Sicherheitsupdate 2025 für Ableiterfahnen betroffen, und welches Teil hat es ersetzt?“

Eine Fachexpertin erkennt hier eine klare Kette von Abhängigkeiten. Ein herkömmlicher Agent nicht. Allein mit relationalen Daten muss der Agent:

• die relevante Sicherheitsinitiative identifizieren
• bestimmen, welche BOM-Einträge sie verändert
• die konkreten Ableiterfahnen lokalisieren
• identifizieren, was sie ersetzt haben
• die Hierarchie hinaufsteigen, um die betroffenen Fahrzeugmodelle zu finden

Die Herausforderung ist nicht die Frage, sondern die Repräsentation. Je mehr Komponenten, BOMs und Initiativen hinzukommen, desto stärker vervielfacht sich der nötige Inferenzaufwand. Das Retrieval wird fragil. Das Reasoning wird inkonsistent.

Explizite Hierarchie, klares Reasoning: Warum Schema-RAG funktioniert

Ein Schema-RAG-Agent verfolgt einen grundlegend anderen Ansatz. Statt die Struktur aus relationalen Mustern abzuleiten, arbeitet er auf einem Knowledge Graph, in dem Baugruppen, Teile und Verwendungsbeziehungen explizit repräsentiert sind.

Im Graphen gilt:

• Jeder BOM-Eintrag ist ein Knoten.
• Jede Eltern-Kind-Beziehung ist eine explizite Kante.
• Jede Initiative verweist direkt auf die Elemente, die sie einführt, verändert oder ausmustert.

Das verändert das Reasoning-Problem grundlegend. Die Hierarchie ist nicht länger verborgen. Die Initiativenlogik verteilt sich nicht länger über mehrere Tabellen. Die Struktur wird als vernetztes Modell sichtbar und navigierbar.

Betrachten wir einen RDF-basierten Knowledge-Graph-Ansatz. Ist die Struktur explizit ausgedrückt, kann der Agent die Ontologie nutzen, um die relevanten Entitäten zu identifizieren, und anschließend eine SPARQL-Query erzeugen, die Beziehungen direkt im Graph Store traversiert. SPARQL bietet eingebaute Path Expressions für mehrstufige Navigation, und RDF Schema sowie die OWL-Ontologie liefern klaren semantischen Kontext. Das reduziert die Abhängigkeit des Agenten davon, Metadaten zu erraten oder zu interpretieren.

SQL erfordert im Gegensatz dazu:

• mehrere Joins über verschiedene Tabellen hinweg
• rekursive CTEs, um Hierarchien hinaufzusteigen
• strikte Abhängigkeit von Metadaten und Kenntnis der Namenskonventionen

Schon kleine Fehler können eine SQL-Abfrage unbrauchbar machen, und Unterschiede zwischen Schemata erschweren die Generierung zusätzlich. SPARQL vermeidet diese Probleme, weil es der Art entspricht, wie der Agent ohnehin schlussfolgert: als Entitäten, die durch Beziehungen verbunden sind.

Um die eingangs gestellte Frage zu beantworten, läuft der Agent einfach durch den Graphen:

• Safety Update 2025 → modifies → Cell Tab
• Cell Tab → is part of → Cell → is part of → Module
• Module → is part of → Battery Pack
• Battery Pack → hasAssembly → Vehicle Models

Ein Knowledge Graph macht Hierarchie und Domänensemantik explizit, und ein Schema-RAG-Agent nutzt diese Semantik ganz selbstverständlich – ähnlich wie eine Fachexpertin, die ein klares technisches Diagramm liest, statt eine Tabellenkalkulation zu entziffern.

Fazit

Relationale Tabellen bleiben für die Speicherung unverzichtbar, doch sie verbergen die hierarchische und sich fortlaufend verändernde Natur von BOMs. In dem Maße, in dem Organisationen auf Datenagenten setzen, um Supply-Chain-Entscheidungen zu unterstützen, wird dieser Mangel an expliziter Struktur und explizitem Kontext zum ernsten Hindernis.

Ein Knowledge Graph räumt dieses Hindernis aus, indem er BOMs, Komponenten und Initiativen so abbildet, wie Produkte tatsächlich funktionieren. Ein Schema-RAG-Agent kann über Produkte so schlussfolgern wie Fachexpertinnen und Fachexperten: indem er expliziten Beziehungen folgt, statt sie zu rekonstruieren.

Für Organisationen, die Datenagenten aufbauen, ist die Einführung eines Knowledge Graph nicht nur eine technische Verbesserung. Sie ist die Grundlage für sicherere Entscheidungen, verlässlichere Automatisierung und skalierbares Reasoning über komplexe Produktökosysteme hinweg.

Wenn Ihre Agenten präzise Erkenntnisse auf echten Supply-Chain-Daten liefern sollen, geben Sie ihnen zuerst die Struktur und den Kontext, die sie brauchen – und ein Knowledge Graph ist der praktikabelste Weg dorthin.