Warum KI-Agenten die Karte lesen müssen – nicht nur die Wegbeschreibung

Executive Summary

• Ein verbreiteter, aber fragiler Ansatz: Bei vielen Enterprise-AI-Lösungen erhält ein LLM-Agent ein textbasiertes „Destillat“ einer Ontologie, das ihm helfen soll, SQL-Abfragen auf Datensilos zu schreiben. Dieser Ansatz ist grundlegend fragil.
• Eine Ontologie in YAML ist nur Prosa: Eine Ontologie in einer nicht-formalen Sprache wie YAML kann ein LLM zwar heuristisch interpretieren. Ihr fehlt aber eine formale Semantik – sie ist weder deterministisch ausführbar noch überprüfbar. Das führt zu mehrdeutigen, nicht auditierbaren Ergebnissen.
• Enterprise-taugliche KI braucht eine formale Wissensrepräsentation: Nötig ist eine einheitliche, formale Wissensrepräsentation (etwa ein RDF/OWL-Graph), in der sich das semantische Modell (das Schema) und die Fakten mit einer einzigen Sprache navigieren lassen. Die Daten selbst können dabei in ihren Quellsystemen bleiben.
• „Executable Knowledge“ macht Reasoning überprüfbar: Dieses Modell ermöglicht es dem Agenten, „das Wissen abzuschreiten“. Er erkundet die relevanten Beziehungen und Randbedingungen, bevor er überhaupt Daten abfragt. Jeder Schritt seines Reasonings wird so überprüfbar.
• Raten skaliert nicht: Ein Agent, der textbasierte Schemas interpretiert und SQL-Joins errät, skaliert nicht über triviale Komplexität hinaus. Er liefert auch nicht die Fehleranalyse, die im Unternehmenseinsatz erforderlich ist.

Einleitung: Das Problem getrennter Ontologien und Daten

Der Wettlauf um intelligente, kontextbewusste Enterprise AI ist in vollem Gange. Dabei hat sich ein gängiges Muster herausgebildet: Ein Retrieval-Augmented-Generation-Agent (RAG-Agent) wird auf die Unternehmensdaten angesetzt und erhält einige Metadaten oder Schema-Informationen als Hilfestellung.

Eine verbreitete Variante dieser Architektur trennt die „Ontologie“ (das Modell des Unternehmens) von den „Instanzen“ (den Daten). Der Agent erhält ein „Destillat“ der Ontologie – einige Definitionen, Join-Schlüssel und Regeln – und baut damit SQL-Abfragen auf die Datenbanken.

Das klingt angenehm wenig invasiv. Es verspricht, die bestehende Dateninfrastruktur zu nutzen und eine Intelligenzschicht hinzuzufügen. Dieser Ansatz enthält jedoch einen kritischen und letztlich fatalen Fehler. Er erzeugt ein System, das intransparent, nicht deterministisch und nicht skalierbar ist. Er tauscht kurzfristige Bequemlichkeit gegen langfristige Fragilität.

Der entscheidende Unterschied: interpretierte Prosa versus ausführbares Wissen

Der Kern des Problems liegt darin, wie ein System Wissen darstellt und darauf zugreift. Es gibt zwei grundlegend verschiedene Modelle:

• Das Modell „Interpreted Schema“: Dieser gängige Ansatz ist grundlegend fragil. Die Ontologie liegt meist in textbasierten Formaten wie YAML-Dateien vor. Für den LLM-Agenten ist das nur Prosa. Der Agent interpretiert diese Beschreibungen, um die richtige SQL-Abfrage zu erraten. Das Schema ist von den Daten getrennt, und der Reasoning-Pfad des Agenten ist eine Blackbox.
• Das Modell „Executable Knowledge“: Hier ist die Ontologie in einer formalen, maschineninterpretierbaren Sprache wie OWL und RDF definiert. Sie ist keine Beschreibung des Wissens – sie ist das Wissen. Das Schema (Klassen, Eigenschaften, Randbedingungen) und die Fakten (die Dateninstanzen) werden im selben Graphmodell ausgedrückt. Die Fakten werden dabei aus den Systemen abgebildet, in denen sie liegen. Der Agent interpretiert keine Prosa, sondern führt eine formale Abfrage aus (etwa in SPARQL), um eine konsistente Landkarte des Unternehmenswissens zu navigieren.

Das erste Modell gibt dem Agenten eine Reihe mehrdeutiger, handgeschriebener Wegbeschreibungen. Das zweite gibt ihm eine präzise, maschinenlesbare Karte.

Definition: Was ist eine Ontologie?

Eine Ontologie ist im Kontext von Enterprise AI ein formaler, ausführbarer Vertrag über die Bedeutung von Unternehmensbegriffen – keine Dokumentation. Der Begriff wird jedoch oft falsch verwendet. Im Modell „Interpreted Schema“ wird die Ontologie wie eine Form der Dokumentation behandelt.

• Eine textbasierte „Ontologie“ (z. B. in YAML) ist lediglich eine Beschreibung. Ein Agent kann sie lesen, aber nicht formal gegen sie prüfen oder sie ausführen. Sie gleicht einer Wiki-Seite: Sie kann veralten, mehrdeutig sein und bietet keine Garantie für Korrektheit.
• Eine formale Ontologie (z. B. in OWL/RDF) ist ein präzises, mathematisches Modell. Sie ermöglicht es einem Agenten, Prüfungen durchzuführen und Beziehungen mit garantierter Konsistenz zu navigieren. Der Agent kann das Modell selbst abfragen, um die „Spielregeln“ zu verstehen, bevor er überhaupt nach einem bestimmten Datenpunkt sucht. Genau diese Prüfung ermöglicht es dem System zu sagen: „Diese Frage kann ich nicht beantworten“ – statt eine Zahl zurückzugeben, die plausibel aussieht, aber unbemerkt falsch ist.

Der Agent sollte niemals die Daten abschreiten müssen. Er muss aber das Modell abschreiten können – entlang expliziter Beziehungen statt erratener.

Beispiel: Die Grenzen der Interpretation

Angenommen, ein Agent erhält folgende Frage: „Finde alle Kunden, die im letzten Jahr ein bestimmtes Produkt gekauft haben, ein offenes Support-Ticket zu dieser Produktfamilie haben und in einer Region ansässig sind, die von einem bestimmten Logistikpartner bedient wird.“

Im Modell „Interpreted Schema“: Der Agent erhält eine Textdatei, die Kunden-, Produkt- und Tickettabellen beschreibt. Er liest Sätze wie „customer_id links customers to orders“. Dann versucht er, eine komplexe SQL-Abfrage mit mehreren JOINs zusammenzusetzen. Kennt er die genaue Definition von „Region“? Versteht er, dass „Produkt“ im Ticketsystem eine breitere Kategorie ist als die „Produkt-SKU“ im Auftragssystem? Das System kann es nicht sicher wissen. Schlägt die Abfrage fehl oder liefert sie eine falsche Zahl, lässt sich nicht nachvollziehen, warum der Agent diese Entscheidung getroffen hat. Eine Fehlermodusanalyse ist nicht möglich.

Im Modell „Executable Knowledge“: Der Agent navigiert zuerst durch den formalen Graphen. Er durchläuft den Pfad Customer -> has_purchased -> Product_SKU -> is_instance_of -> Product_Family <- is_about <- Support_Ticket. Dabei sieht er die expliziten, formal definierten Beziehungen und Randbedingungen. Die Abfrage, die er daraus erstellt (z. B. in SPARQL), ist ein direktes Abbild dieses gültigen Pfads. Der gesamte Prozess ist auditierbar. Jedes Konzept, jede Beziehung und jede Randbedingung, die der Agent verwendet hat, ist sichtbar. Ist eine Antwort falsch, lässt sich genau erkennen, wo der Fehler liegt.

Warum das wichtig ist: mehr als die Demo-Datenbank

Der Ansatz „Interpreted Schema“ mag in einem kontrollierten Experiment mit einem Dutzend Tabellen funktionieren. In einem realen Unternehmen mit Tausenden Tabellen und Hunderten mehrdeutiger, sich überschneidender Begriffe („Kunde“, „Service“, „Region“) erzeugt er enormes „Rauschen“. Der Agent sieht Dutzende plausibel klingender Tabellen und Spalten, und die Wahl der richtigen wird zur Lotterie.

Das Problem ist nicht nur die Größe des Kontextfensters, sondern die Dichte ähnlicher, aber semantisch unterschiedlicher Konzepte. Ein formaler Knowledge Graph (Wissensgraph) löst dieses Problem, indem er diese Konzepte durch seine Struktur eindeutig macht. Der Agent kann von einer kuratierten, vertrauenswürdigen Basis ausgehen und dann den Graphen erkunden, um die präzisen, relevanten Konzepte für eine Frage zu finden – auch für eine völlig neue. Das ist der Unterschied zwischen einem System, das nur vorhergesehene Fragen beantworten kann, und einem System, das tatsächlich über das Unternehmen schlussfolgern kann.

Abwägungen und Grenzen

Der Reiz des interpretierenden, SQL-generierenden Ansatzes liegt in seiner niedrigen Einstiegshürde. Er wirkt wie ein „Minimum Viable Product“, das die vermeintliche Komplexität einer formalen Ontologie umgeht. Das ist jedoch eine Scheinersparnis. Die Komplexität wird lediglich in das Laufzeitverhalten eines Blackbox-Agenten verschoben, wo sie sich weder steuern noch auditieren oder skalieren lässt. Erst die Stabilität des Semantic Layer (semantische Schicht) schafft Agilität auf der Datenebene.

Fazit: Wenn nur eines hängen bleibt …

Damit Enterprise AI vertrauenswürdig ist, darf sie nicht raten. Die Kernarchitektur muss auf formaler, maschineninterpretierbarer Bedeutung aufbauen. Ein Agent, der lediglich textbasierte Schemas interpretiert, um SQL zu schreiben, arbeitet mit Hoffnung statt mit Logik. Ein wirklich intelligenter Agent muss eine formale, ausführbare Karte des Unternehmenswissens navigieren können – Schema und Fakten gleichermaßen –, während die Daten bleiben, wo sie sind. Nicht die Wegbeschreibung übergeben, sondern die Karte.