Kommentar von Ben Szekely, Siemens Digital Industries Software Warum agentische KI einen Context Layer benötigt

Anbieter zum Thema

Siemens Digital Industries Software GmbH

Fivetran Germany GmbH

Data Lakes haben Unternehmen dabei geholfen, Informationen aus zahlreichen Systemen zu konsolidieren, doch das allein macht für KI-Agenten die Beziehungen zwischen den Daten noch nicht zugänglich. Da Agenten zunehmend domänenübergreifend Schlussfolgerungen ziehen müssen, können unzusammenhängende Daten zu langwierigen Suchvorgängen, einer ineffizienten Nutzung von Tokens und unzuverlässigen Ergebnissen führen. Knowledge-Graphen und Ontologien können eine Kontextebene bereitstellen, die vorhandene Unternehmensdaten miteinander verknüpft und diese Beziehungen explizit macht.

Seit Jahren unterstützen Data Lakes Unternehmen dabei, eine entscheidende Herausforderung zu bewältigen: die Konsolidierung von zuvor über Hunderte von Systemen verteilte Daten. Sie bildeten die Grundlage für Business-Intelligence-Dashboards und Data-Science-Initiativen und boten einen zentralen Ort für den Zugriff auf Informationen. Das Aufkommen agentischer KI verändert jedoch die Art der Anforderungen an Unternehmensdaten. Anders als bei herkömmlichen Analysen rufen KI-Agenten nicht einfach Berichte ab. Sie können planen, logisch denken und domänenübergreifend handeln – oft ohne, dass ihnen ein menschlicher Experte erklären muss, wie die verschiedenen Unternehmensbereiche miteinander in Beziehung stehen.

Daten zu konsolidieren und Daten miteinander zu verknüpfen, sind zwei grundlegend unterschiedliche Aufgaben. In vielen Unternehmen wurden Datensilos durch die Zusammenführung der Daten in einem Data Lake lediglich verlagert, statt beseitigt. Zwar liegen die Daten nun auf einer einzigen Plattform, doch die Beziehungen zwischen den Geschäftsentitäten bleiben häufig implizit oder sind nicht miteinander verknüpft. Hinzu kommt, dass einige der wertvollsten Unternehmenssysteme, wie Product-Lifecycle-Management-Plattformen (PLM) mit konfigurierten Stücklisten, häufig gar nicht in einen Data Lake übertragen werden können.

Hier kommen Knowledge-Graphen (Wissensgraphen) ins Spiel. Im Gegensatz zu einem Data Lake behandelt ein Knowledge-Graph Beziehungen als eigenständige Datenobjekte. Verbindungen zwischen Bauteilen, Lieferanten, Qualitätsereignissen und Kundenaufträgen sind implizit, in Fremdschlüsseln verborgen und werden von demjenigen rekonstruiert, der die Abfrage erstellt. In Kombination mit einer Ontologie – einem maschinenlesbaren Modell dessen, was Begriffe wie „Bauteil“, „Lieferant“ oder „Charge“ im Unternehmenskontext bedeuten – bildet der Knowledge-Graph eine Kontextebene, die bestehenden Unternehmensdaten Bedeutung verleiht, ohne selbst zu einem weiteren System of Record oder einem weiteren zu pflegenden Silo zu werden.

Wichtig ist, dass dies über die bloße Beschreibung von Daten hinausgeht. Ein Data Catalog kann zwar angeben, wo Informationen gespeichert sind, aber ein Context Layer ermöglicht es Agenten, Schlussfolgerungen aus den Daten zu ziehen. In anspruchsvollen Domains muss diese Kontextebene auf einer hochleistungsfähigen Graph-Verarbeitung über In-Memory- und virtualisierten Architekturen aufbauen.

Warum expliziter Kontext für Unternehmensagenten wichtig ist

Unternehmen interessieren sich zunehmend dafür, wie sich Knowledge-Graphen auf die Leistung von KI-Agenten auswirken. Zwar lassen sich Token-Einsparungen nach wie vor nur schwer quantifizieren – da sich die Agent-Architekturen monatlich ändern und gleichzeitig die Token-Preise sinken –, doch die zugrunde liegende Logik ist einfach: Wenn Agenten über voneinander getrennte Datenquellen hinweg arbeiten, müssen sie wiederholt Informationen suchen, Sackgassen korrigieren und ihre Vorgehensweise neu planen. Jede Iteration verbraucht zusätzliche Reasoning-Token. Eine Ontologie reduziert den Erkundungsaufwand, da der Agent bereits definierte Beziehungen lesen kann, anstatt sie während der Ausführung immer wieder neu zu entdecken.

Bei einem Knowledge-Graphen sollte es jedoch nicht nur um Kosteneinsparungen, sondern auch um Zuverlässigkeit gehen: Wenn Beziehungen explizit sind, müssen Agenten weniger Zeit mit Raten verbringen. In Unternehmensumgebungen kann eine plausibel erscheinende, aber falsche Verknüpfung, die eine auf den ersten Blick richtige Antwort liefert, weitaus problematischer sein als eine langsame Antwort.

Kommentar von David Maria Schmidt, Universität Bielefeld

Warum LLMs beim Kombinieren bekannter Fakten scheitern

Die Leistung auf der Datenebene ist ebenso wichtig. Agenten arbeiten iterativ: Sie stellen eine Abfrage, analysieren das Ergebnis und verfeinern die nächste Frage auf der Grundlage dessen, was sie gelernt haben. Wenn jede Abfrage Minuten dauert, kommt der Prozess zum Stillstand. Wenn Abfragen innerhalb von Sekunden beantwortet werden, kann der Agent eine Idee testen, sie verwerfen und innerhalb einer Sitzung eine andere ausprobieren. Das verändert nicht nur die Antwortzeiten – es verändert auch die Anzahl der Fragen, die ein Agent beantworten kann.

In der pharmazeutischen Fertigung ermöglichen Lieferketten-Graphen mit Milliarden von Knoten und Beziehungen bereits, dass Abfragen, deren Beantwortung früher Stunden oder sogar Tage und den Einsatz mehrerer Teams erforderte, nun in Sekundenschnelle oder innerhalb weniger Minuten beantwortet werden können. In der Automobilindustrie zeigen sich ähnliche Ergebnisse: Eine vollständig aufgeschlüsselte Fahrzeugstückliste kann Hunderte Millionen bis hin zu Milliarden von Beziehungen umfassen und geht damit weit über eine einfache Teileliste hinaus. Komplexe analytische Abfragen, die tief in diese Struktur reichen, lassen sich in Sekundenschnelle beantworten.

Unternehmensdaten mit realen Geschäftsfragen verknüpfen

Eine der häufigsten industriellen Anwendungen von Knowledge-Graphen ist die Analyse der Auswirkungen von technischen Änderungen. Betrachten wir die einfache Frage eines Ingenieurs: Wenn sich ein bestimmtes Bauteil ändert, welche Auswirkungen hat dies auf die Lieferkette, die Fertigung und die Qualitätsprozesse, und wann ist der kosteneffizienteste Zeitpunkt, um diese Änderung umzusetzen?

Die zur Beantwortung erforderlichen Informationen sind innerhalb des Unternehmens bereits vorhanden: Produktkonstruktionen befinden sich in PLM-Systemen, Beschaffungsinformationen und Lieferzeiten in ERP-Plattformen, Fertigungsprozesse in MES-Umgebungen, Fehlerhistorien in Qualitätssystemen und installierte Konfigurationen in Serviceaufzeichnungen. Was in der Regel fehlt, ist die Verbindung zwischen diesen Bereichen.

Unternehmen können diese Fragen daher zwar beantworten, jedoch oft erst nach mehreren Tagen, erheblichen manuellen Aufwands. Ähnliche Fragen tauchen immer wieder auf: Wenn dieses Bauteil nicht mehr verfügbar ist, was hat das zur Folge? Welche Geräte im Einsatz weisen diese Konfiguration auf?

Die häufigsten Fallstricke bei Knowledge-Graph-Initiativen

Trotz zunehmender Verbreitung stehen Unternehmen bei der Implementierung von Knowledge-Graphen vor wiederkehrenden Herausforderungen. Die erste besteht darin, zu versuchen, alles zu modellieren, bevor überhaupt ein geschäftlicher Nutzen erzielt wird. Dieser Ansatz führt oft zu komplexen Ontologien, die es nie in die Produktion schaffen. Erfolgreiche Projekte verbinden zwei oder drei Domänen rund um eine wichtige geschäftliche Fragestellung, stellen den Nutzern die Ergebnisse frühzeitig zur Verfügung und lassen sich bei der weiteren Modellierung von Feedback aus der Praxis leiten.

Die zweite basiert auf der Annahme, dass Orchestrierungsagenten die Verknüpfung übernehmen können. Die Interaktion zwischen Agenten ist bereits Realität und funktioniert bei vielen Aufgaben gut. Ein Orchestrierungs-LLM jedoch mit der Zusammenführung der Ergebnisse zu beauftragen, bedeutet letztlich, es wie eine Datenbank-Engine arbeiten zu lassen. Das kann funktionieren, wenn jeder Agent nur wenige Zeilen ausgibt, versagt jedoch, wenn eine Antwort die Verknüpfung von Zehntausenden von Datensätzen aus einem Zeitraum von zwei Jahren erfordert. Die Genauigkeit sinkt und die Antwortzeiten steigen, wobei sich beides umso stärker verschlechtert, je wertvoller die Frage ist.

Die dritte fußt auf dem Irrtum, alle Knowledge-Graphen als gleichwertig zu betrachten. In der Regel ist die in der Cloud-Datenplattform vorhandene Ontologie- oder Metadatenebene die naheliegende erste Wahl. Das ist eine legitime Funktion, die beschreibt, was sich in jeder Tabelle befindet und wie die Tabellen miteinander verknüpft sind. Für viele analytische Anwendungsfälle reicht dies aus. Anspruchsvollere Domains erfordern jedoch etwas ganz anderes. Sie benötigen einen Datenumfang über Systeme hinweg, die nie für die Zusammenarbeit konzipiert wurden; eine Ontologie, die reichhaltig genug ist, um die tatsächliche Semantik der Domain zu erfassen – einschließlich Konfiguration und Effektivität im Ingenieurwesen oder Gegenparteihierarchien im Finanzwesen – sowie die Fähigkeit, Hunderte Millionen oder Milliarden von Beziehungen unter realer Auslastung zu speichern und abzufragen.

Die gute Nachricht: Der Aufbau von Knowledge-Graphen ist längst nicht mehr so einschüchternd wie noch vor zwei Jahren. Unternehmen müssen den Graphen nicht mehr von Hand oder im Alleingang erstellen. Eine erste Ontologie kann direkt aus den Quellsystemen generiert werden, ohne dass jemand sie zuvor modellieren muss, und KI kann das Modell anschließend anreichern, es mit bestehenden Ontologien abgleichen und domainübergreifend verknüpfen. Ontologien und Graphen, deren Erstellung früher monatelange Modellierung durch Experten erforderte, lassen sich nun innerhalb weniger Wochen erstellen. Dadurch entsteht ein positiver Kreislauf: Je umfangreicher der Graph wird, desto effektiver kann KI ihn um die nächste Quelle und die nächste Domain erweitern.

Context Layer werden zur Unternehmensinfrastruktur

Mit Blick auf die Zukunft zeichnet sich ein Trend immer deutlicher ab: Kontextebenen werden zu einem Standardbestandteil der Unternehmensarchitektur. Praktisch jede große Datenplattform hat in den letzten Jahren eine Form von Context Layer eingeführt, die häufig auf Konzepten wie Knowledge-Graphen oder Ontologien basiert. Daher lautet die entscheidende Frage nicht mehr, ob Unternehmen Kontextebenen einführen werden, sondern vielmehr, welche Art von Knowledge-Graph der jeweilige Anwendungsfall erfordert.

Für viele Anwendungsfälle reicht die „leichtere“ Variante aus. Wenn sich eine Fragestellung weitgehend auf eine einzige Plattform beschränkt, kann ein bestehender Data Lake in Kombination mit einer handelsüblichen, metadatenorientierten Kontextebene ein sinnvoller Ausgangspunkt sein. Anspruchsvollere Bereiche erfordern eine breitere Datenabdeckung, eine reichhaltigere Ontologie und ausreichend Rechengeschwindigkeit, um einen Agenten zu unterstützen, der Dutzende von Abfragen innerhalb eines einzigen Workflows ausführt. Diese Anforderungen sind es, die ein Unternehmen dazu bewegen, von einem Metadaten-Graphen zu einem echten Knowledge-Graphen überzugehen.

Nachbericht Neo4j Graph Summit München

Neo4j zielt auf den KI-Markt

Es ist schwer vorherzusagen, wo agentenbasierte KI in zwei oder drei Jahren stehen wird. Vorhersehbarer ist hingegen, dass sich die Praxis der Knowledge-Graphen in diesem Umfeld weiterentwickeln wird. Die Investitionen in Ontologien und Graphen nehmen zu, und ein Context Layer wird zur Standard-Unternehmensinfrastruktur werden – genauso selbstverständlich, wie das Data Warehouse vor einer Generation.

Es ist unwahrscheinlich, dass sich Unternehmen auf eine einzige Ontologie oder Knowledge-Graph-Plattform einigen werden. Stattdessen werden sie mehrere davon für unterschiedliche Workloads, Domänen und Anwendungsfälle einsetzen, wodurch Interoperabilität unerlässlich wird. Das bedeutet jedoch nicht zwangsläufig, auf branchenübliche Ontologien zurückzugreifen, da dies zu den gleichen Kosten und Verzögerungen führen kann wie ein vollständiges Modellieren, bevor überhaupt etwas bereitgestellt werden kann. Stattdessen sollten Ontologien auf offenen Standards basieren; semantischen Standards wie W3C sind hierfür ein naheliegendes Beispiel. Knowledge-Graphen wiederum können Agenten über offene Protokolle wie MCP zugänglich gemacht werden.

Grundlagen aufzubauen ist einfacher denn je

Für Organisationen, die ihre nächsten Schritte abwägen, stehen zwei praktische Überlegungen im Vordergrund: Sie sollten vermeiden, den Fortschritt durch die Suche nach einer perfekten Plattform zu verzögern, und Lösungen priorisieren, die skalierbar sind und mit anderen Systemen zusammenarbeiten können.

Knowledge Layer aufbauen

Wissensschicht für kontrollierbare KI-Agenten

(ID:50951159)