semantic-layer ontology text-to-sql data-engineering ai-agents

Agenten benötigen interpretierbaren Sinn: Semantische Schichten, Ontologien und gesteuerte Metriken.

Konversationelle BI versagt, wenn die Bedeutung unklar bleibt. Was Untersuchungen zu Text-zu-SQL zeigen und wie ein semantischer Layer, eine Ontologie sowie kanonische IDs zu zuverlässigen Antworten beitragen.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202615 Min. Lesezeit3393 Wörter

Quellen: Make Meaning Machine-Interpretable Before You Trust the Agent

Stellen Sie sich das Montag-Meeting vor. Ein Teammitglied klebt die Antwort des Agenten in Slack ein: der Umsatz pro Kunde aus dem vorherigen Quartal, ordentlich formatiert, kurz erklärt und mit voller Sicherheit präsentiert. Ein einziger Blick von der Finanzabteilung lässt die Besprechung stocken. Diese Zahl bezieht sich auf Buchungen, während der anerkannte Umsatz in einer anderen Tabelle mit anderer Struktur und eigener Ausschlussliste gespeichert ist. Mit dem SQL war alles in Ordnung. Niemand hatte sich darauf geeinigt, was die Frage eigentlich bedeutet.

Nach genügend solchen Szenarien zählt „das Modell erzeugt gültigen SQL“ nicht mehr als Erfolg. Große Sprachmodelle haben nahezu alle Lagerdokumente maschinenlesbar gemacht. Lesbar zu machen ist einfach. Interpretierbar zu machen ist das Schwierige: Was Kunden, Umsatz, Aktivität, Abwanderung und das vorherige Quartal in diesem speziellen Unternehmen für diese konkrete Entscheidung bedeuten.

Vor den Agenten hat eine Person dies durch Interpretation vor dem Schreiben jeder Abfrage erledigt. Übertragen Sie diese Aufgabe bei Laufzeit auf einen Agenten – er wird eine plausible Geschichte improvisieren, es sei denn, eine künstlich erzeugte wird bereitgestellt. Die dauerhafte Lösung besteht darin, Unternehmensbedeutungen wie ein Produkt zu verwalten: Geben Sie ihnen eine Identität, versionieren Sie sie, testen Sie sie, ordnen Sie sie physischen Daten zu und ermöglichen Sie es Menschen sowie Software, sie auf dieselbe Weise zu nutzen.

Für die meisten Teams ist der umsetzbare Schritt eine regulierte semantische oder Metriken-Schicht. Das langfristigere Ziel ist ein ontologiegestütztes Modell, das die nachgelagerten Prognosen – sei es LookML, SQL-Views, API-Verträge oder Agentenwerkzeuge – zusammenstellt, sodass kein Produkt eigene „private Wahrheiten“ erfinden muss.

Warum eine zuverlässige Antwort ein Risiko darstellt

Chat-basierte BI wird oft als Übersetzung von Natursprache in SQL beschrieben – ein Begriff, der den schwierigen Teil verbirgt. Der schwierige Teil besteht darin, eine Frage in einem Referenzrahmen zu lesen und ihre Bedeutung in einen anderen zu übertragen.

Betrachten Sie die Frage „Wie hoch waren die Einnahmen pro Kunde im letzten Quartal?“ Für ein Lager ist es einfach, eine präzise Abfrage durchzuführen. Die Herausforderung liegt darin, zu entscheiden, welche Abfrage die Frage widerspiegelt. Unter Einnahmen können Buchungen, Rechnungen oder erfasste Einnahmen verstanden werden. Der Kunde kann die Empfängerpartei, die Rechnungsempfängerpartei oder jeder andere Knoten in der Kontenhierarchie sein, der in den quartalsweisen Überprüfungen im Verkauf angezeigt wird. Das letzte Quartal kann auf Kalendermonaten, dem Geschäftsjahr oder dem dynamischen Zeitraum beruhen, den die Betriebsabläufe bevorzugen.

Auf einer Dashboard-Ansicht hat ein Analyst diese Entscheidungen bereits getroffen. Ein mit „Einnahmen“ beschriftetes Element wirkt autoritativ, weil die semantische Entscheidung bereits in dem Artefakt integriert ist. Im Chat wird diese Reihenfolge umgekehrt: Die Entscheidung erfolgt nun zur Laufzeit für beliebige Fragen innerhalb der Software, wodurch Semantik aus einer Wiki-Seite zu einer Laufzeit-Infrastruktur wird.

Die unangenehme Folge ist, dass je besser ein Modell in der Erstellung plausibler SQL-Abfragen wird, desto gefährlicher werden seine Fehlern. Syntaktische Korrektheit sagt nichts über semantische Gültigkeit aus. Eine gut formulierte Erklärung kann die falsche Frage so geschmeidig beantworten, dass niemand etwas bemerkt, bis eine Board-Notiz im Widerspruch zum Chat-Log steht. Teams, die nur prüfen, ob eine Abfrage ausgeführt wurde, trainieren sich damit, fließend formulierten Fehlern zu vertrauen.

Dimensionale Modelle tragen bereits Bedeutung in sich

All das macht einen Lagerbestand jedoch nicht zu einem leeren Blatt. Das Kimball’sche Dimensionenmodellierungskonzept hat jahrzehntelang versucht, auszugleichen, wie wenig allgemeingültige relationale Schemata aussagen können. Fakten, Dimensionen, Messgrößen, Granularität, Hierarchien sowie konforme Dimensionen bringen alle geschäftliche Bedeutung in Strukturen ein, die von Menschen abgefragt werden können.

Ein gut konstruiertes Sternschema fungiert bereits als informelle semantische Schicht. Heutige semantische Schichten fügen zusätzlich Metrikdefinitionen, Berechnungsregeln, Terminologie, zulässige Beziehungen sowie Geschäftsregeln hinzu, die aus den Spaltennamen nicht hervorgehen. Eine formale Ontologie geht noch weiter und trennt das konzeptionelle Modell bewusst von seiner relationellen Implementierung sowie von der Zuordnung zwischen den beiden.

Besser ist es, dies als Kontinuum und nicht als Umwandlungsprozess zu betrachten:

operatives relationales Schema
dimensionales Modell
semantische Schicht
formale Ontologie

Je weiter man in der Liste nach unten geht, desto mehr Bedeutung wird festgehalten und das Modell muss weniger raten. Jeder implizit gelassene Aspekt ist ein Risiko, dass die Schlussfolgerungen auf der Definition beruhen, die der CFO bestätigen würde.

Was die Forschung weiterhin zeigt

Jüngste Studien zur Umwandlung von Text in SQL kommen immer zum selben Ergebnis: Die explizite Angabe der geschäftlichen Bedeutung erhöht die Genauigkeit – und das gilt auch für Schemata, die bereits zur Analyse erstellt wurden.

In einem Test von Figueiredo und Kollegen wurde GPT-4 Turbo auf einem Sternschema eingesetzt. Allein das Schema ergab etwa 58 Prozent korrekte Abfragen, während die Hinzufügung kontextueller Semantik diese Rate auf rund 89 Prozent steigerte. Rumiantsau und Fokeev fügten ein kurzes semantisches Dokument zu einem auf Contoso basierenden analytischen Warehouse-Modell hinzu, wodurch die Genauigkeit von etwa 48 auf 52 Prozent anstieg. Diese Verbesserungen sind bedeutsam, da die Ausgangsschemata keine unübersichtlichen transaktionalen Strukturen waren.

Wenn das physische Schema weniger über das Geschäft verrät, wird der Effekt größer. Painter und seine Kollegen arbeiteten an einer operativen Datenbank mit mehr als 500 Tabellen und steigerten die Genauigkeit bei der Erstellung validierter SQL-Anfragen von etwa 8 % auf etwa 78 %, indem sie Terminologie, Regeln, Beziehungen und Zuordnungen bereitstellten. Nascimento und seine Kollegen beobachteten, wie die Ausführungsgenauigkeit in einer komplexen Industriedatenbank allein durch die Angabe geschäftsfokussierter konzeptioneller Namen von 41 % auf 65 % stieg, und auf 74 %, sobald auch nützliche Beziehungssemantiken explizit dargestellt wurden.

Formale Modelle weisen die gleiche Entwicklung auf. In einer Studie von Sequeda, Allemang und Jacob ergab das Direktstellen von Fragen an eine relationale Unternehmensdatenbank eine Genauigkeit von etwa 17 %, während der Einsatz eines durch eine Ontologie gestützten Wissensgraphen etwa 54 % erreichte. In einer Nachfolgestudie von Nascimento wurde zwar weiterhin SQL zur Ausführung verwendet, doch zunächst diente ein Wissensgraphen dazu, Geschäftskonzepte mit dem physischen Schema zu verknüpfen. Gemessen am Schema-Linking-F1 erzielte ein reines LLM etwa 0,85 Punkte. Der graphbasierte Ansatz erreichte 0,90 Punkte, der Ansatz mit Graph und LLM 0,93 Punkte, und der vollständige semantische-Linking-Prozess mit perfekter Erinnerungsrate 0,996 Punkte.

Die angemessene Interpretation ist architektonischer Natur und nicht werblicher Art: Die Zuordnung von Konzepten zu relationellen Strukturen muss explizit gemacht werden, die semantische Improvisation soll dem Modell entzogen werden, und die Ausführung soll beim relationellen Engine bleiben, wo sie bereits funktioniert.

Was das relationale Modell erreicht und nicht erreicht hat

Codds relationales Modell brachte Datenunabhängigkeit: Anwendungen sollten nicht davon abhängen, wie Daten physisch gespeichert sind. Dieser Erfolg ist bis heute von Bedeutung.

Unterhaltende BI-Anwendungen erfordern etwas Spezifischeres und Schwierigeres. Ein relationales analytisches Schema allein gibt nicht alle für die Beantwortung einer Frage notwendigen geschäftlichen Bedeutungen an. Namen, Schlüssel, Einschränkungen und Kommentare helfen dabei, und dimensionale Modelle helfen noch mehr. Dennoch bleiben Definitionen von Metriken, die Rollen der Begriffe, zeitliche Konventionen, Herkunft sowie Regeln zur Zuordnung von Konzepten zu physischen Objekten oft im Kopf der Menschen oder in Präsentationsfolien.

Deshalb haben sich um die Lagerhäuser Glossare, Metrikspeicher, semantische Schichten und Kataloge entwickelt. Sie machen schrittweise deutlich, was ein Analyst oder ein LLM sonst improvisieren würde. Eine moderne semantische Schicht ist eine praktische Lösung an dem Punkt, an dem BI genutzt wird. Sie bleibt enger gefasst als ein allgemeines konzeptionelles Modell des Unternehmens, und wenn Teams die beiden als identisch betrachten, sind sie später überrascht.

Ontologie hinzufügen, während das Lagerhaus beibehalten wird

In der Informatik beschreibt eine Ontologie das, was im interessierenden Bereich existiert – also Entitäten, Beziehungen und Einschränkungen – und ist so formuliert, dass Software sie nutzen kann. Sie teilt ihre Wurzeln mit dem relationellen Modell in der Prädikatenlogik: Aussagen über Dinge und die Beziehungen zwischen ihnen.

Datenbanken arbeiten bereits seit längerer Zeit an dieser Problematik. W3C Direct Mapping und R2RML definieren, wie relationale Daten zu RDF-Vokabularen werden. Ontology-Based Data Access geht noch einen Schritt weiter: Ein Benutzer stellt eine Abfrage an das konzeptionelle Modell, und das System übersetzt diese in SQL-Anfragen anhand der bereits vorhandenen Quellen. Ontop, ein ausgereiftes Open-Source-Virtuelles Wissensgraphen, tut genau das mithilfe von R2RML-Karten und leichten OWL 2 QL-Ontologien.

Die Wahl von OWL 2 QL hat eine unscheinbare, aber nützliche Begründung. Es gehört zur DL-Lite-Familie, deren Grenzen absichtlich so festgelegt sind, dass Abfragen, die durch die Ontologie vermittelt werden, auch bei großen relationellen Datenbanken handhabbar bleiben. Die Ausdrucksstärke wurde zugunsten der Umwandlung in SQL aufgegeben. Arbeiten an Ontologien für Lagerhäuser und multidimensionale Modelle existieren bereits länger und beschreiben Dimensionen, Maße sowie Hierarchien sowie leiten analytische Strukturen aus konzeptionellen Modellen ab.

Was bisher nur wenig sichtbare Verbreitung findet, ist eine Ontologiesprache, die gezielt auf moderne Business Intelligence zugeschnitten ist und Geschäftsentitäten, Beziehungen, Maße, Aggregationen, Zeit, Herkunft sowie Lagerhäuser in einem einzigen, regulierten Modell abbildet.

Die Übernahme dieses Ansatzes bedeutet nicht, dass das Lager in eine Graph-Datenbank verlegt werden muss. Die Bedeutung kann in der Ontologie beschrieben werden, während die Fakten in relationellen Tabellen bleiben und die Berechnungen in SQL stattfinden. Die Materialisierung eines Graphen ist optional, nützlich für Arbeitslasten, die davon profitieren, und stellt kein Entscheidungskriterium dar.

Gespeicherte Fakten und ihre Bedeutung

Zeilen und RDF-Triple stehen in engerer Beziehung zueinander, als es die工具-Konkurrenzen nahelegen. Eine Zeile gibt an, dass eine Tupel zu einer benannten Relation gehört, und ein Triple teilt eine Aussage in Subjekt, Prädikat und Objekt auf. Starke Normalisierung lenkt bereits die relationellen Designs in Richtung kleinerer Fakten. Die beiden sind formal nicht äquivalent, doch die Ähnlichkeit ist hilfreich.

Für Agenten ist der entscheidende Unterschied nicht zwischen Tabelle und Graph. Es geht vielmehr um erweiternde Daten im Gegensatz zu intentionalem Sinn: um die gespeicherten Fakten im Gegensatz zu den Regeln darüber, was diese Fakten bedeuten. Eine Ontologie kann angeben, dass eine Klasse eine andere untersummiert, dass zwei Prädikate invers zueinander sind, dass eine Beziehung transitiv ist oder dass eine bestimmte Kombination unmöglich ist. OWL bietet formale Semantik für solche Aussagen, SHACL überprüft die Struktur von Graphen, und es existieren weiterführende Logikrahmen für Fälle, in denen sie benötigt werden.

Nicht jede Ontologie lässt sich sauber in SQL umwandeln, da einige Sprachen ausdrucksstärker sind, als die effizienten Umwandlungsfragmente bewältigen können. Die OBDA-Forschung geht offen mit diesem Problem um und bietet Möglichkeiten, die Ausdrucksstärke einzuschränken, Approximationen vorzunehmen, Daten zu materialisieren oder in einem separaten Schritt zu reasoningen. Diese Einschränkung ist nützlich, da sie eine explizite Darstellung erzwingt, welche Semantiken auf dem Ausführungspfad gelten, welche im Voraus kompiliert werden und welche außerhalb des gewählten Profils liegen. Heute dokumentieren nur wenige Unternehmen diesen Verlust, wodurch er in Chatkanälen als Streitpunkte zum Vorschein kommt.

Der Kontext eines Anbieters ist nicht Ihre Ontologie

Die Anbieter handeln bereits. Google Cloud ist ein gutes Beispiel, denn mehrere seiner Veröffentlichungen für 2026 richten sich auf Unternehmensumgebungen, die von Maschinen genutzt werden können. Der Dataplex Universal Catalog wurde in Knowledge Catalog umgewandelt und verhält sich eher wie ein lebender Kontextgraph als wie ein statisches Register. Er bietet semantische Suche, erweiterte Beschreibungen, Beziehungsgraphen, überprüfte (goldene) SQL-Muster, Kontext-APIs sowie Zugriffswege für Agenten. Gleichzeitig ermöglicht Lookers Open SQL Interface JDBC-Clienten, LookML-Modelle so abzufragen, als wären es Schemata, wobei dabei die bereits dort definierten Dimensionen, Aggregationen, Berechnungen und Beziehungen wiederverwendet werden.

Solche Veröffentlichungen unterstreichen einen grundlegenden Punkt: Ein Agent benötigt mehr als nur Zugriff auf Zeilen – er braucht sorgfältig kuratierten Kontext, semantische Modelle, Beziehungen, überprüfte Beispiele sowie regulierte Schnittstellen.

Trotzdem fehlt es ihnen an einer einzigen, kohärenten Unternehmensontologie. Die LookML-Semantik, Katalogbegriffe, Graphdefinitionen von BigQuery sowie der von Agenten erstellte Kontext sind miteinander verbunden, doch es handelt sich um unterschiedliche Darstellungsformen. Sofern die Organisation keine kanonischen Identifikatoren sowie expliziten Zuordnungen zwischen ihnen besitzt, geht das Versprechen einer einmaligen Definition in eine Definition pro Produkt über.

Ganze Quartale wurden durch diese Falle verschwendet. Der Kontextgraph eines Anbieters kann äußerst wertvoll sein, ohne die formale Quelle semantischer Wahrheit darzustellen. Man kann ihn frei übernehmen, muss dabei jedoch bedenken, dass Übernahme nicht gleichbedeutend mit Eigentum ist.

Sechs Designprinzipien

Die oberste Regel ist, dass die Bedeutung gleichzeitig für Menschen und Maschinen lesbar sein muss und in allen Darstellungsformen konsistent bleiben muss.

Geben Sie Bedeutung eine Identität. Jedes Konzept, jede Beziehung, jede Messgröße, jede Richtlinie sowie jede Qualitätsangabe sollte einen stabilen Identifikator aufweisen. Ein Name ist lediglich ein Etikett, während ein Identifikator das Objekt selbst ausmacht. Der Begriff Kunde taucht in Dashboards, APIs, Lager-tabellen sowie Agentenanweisungen auf – all diese sollten auf ein einziges semantisches Objekt verweisen, oder gezielt auf getrennte Objekte, falls das Unternehmen tatsächlich unterschiedliche Konzepte verwendet. Support- und Finanzabteilungen können einen aktiven Kunden unterschiedlich definieren, sofern sie niemals einen Identifikator teilen, ohne dies ausdrücklich zu besprechen.

Machen Sie Definitionen ausführbar. Prosa dient Menschen und Modellen, doch alles, was die Berechnung beeinflusst, benötigt Struktur: Typen, Beziehungen, Kardinalitäten, Einheiten, Formeln, Granularität, gültige Zeiträume, Einschränkungen, Zuordnungsregeln sowie Richtlinien. Ein beschreibender Absatz in einem Katalog ist größtenteils eine menschliche Konvention.

Bei auf Google Cloud basierenden Architekturen sieht eine praktikable Aufteilung wie folgt aus: Der Knowledge Catalog enthält Identitäten, Definitionen, Einheiten, Eigentumsverhältnisse, Gültigkeitszeiträume, Richtlinien, Beziehungen sowie Zuordnungen. LookML beinhaltet die ausführbaren Formeln, Dimensionen, Verknüpfungen sowie die Erstellung von Abfragen. Conversational Analytics interpretiert natürliche Sprache im Kontext dieser Daten, wobei überprüfte Abfragen als Referenzpunkte für Regressionen dienen. Diese Struktur gilt nur dann, wenn die IDs absichtlich jede dieser Grenzen überschreiten.

Übersetzen Sie Semantik auf physische Daten explizit. Angenommen, die Ontologie besagt, dass ein Kunde ein Konto besitzt. Die Implementierung muss dann die Beziehung oder Ableitung benennen, die diese Aussage wahr macht, und die Zuordnung sollte zusammen mit beiden Endpunkten versioniert werden. Kein One-Click-Tool kann OWL in jedes Katalogprodukt übertragen. Jemand muss die Brücke erstellen und warten, sonst bedeutet das Wort „Semantik“ kaum mehr als Markenbildung.

Betrachten Sie Beziehungen als erstklassig. Eine Rolle erhält ihre Bedeutung durch ihre Verbindungen zu Prozessen, Organisationen, Aktivitäten, Fähigkeiten und Kosten – nicht durch eine Spalte mit dem Namen role_type. Kunden, Produkte, Verträge, Konten und Metriken funktionieren genauso. Unaufgeräumte Benennungen und Prosa helfen bereits beim Übergang von NL zu SQL, doch formale Beziehungssemantik ist es, die die praktische Verwendbarkeit in relationalen Systemen von ontologischer Klarheit unterscheidet. Ihre Erstellung erfordert echte Anstrengungen, und eine Ontologie, die diese Kosten ignoriert, scheitert bereits in der Pilotphase.

Bewahren Sie Metriken innerhalb desselben Modells auf. Dimensionale Maße enthalten bereits Identität, Formel, Aggregationsverhalten sowie semantische Schichten, wodurch sie besser umsetzbar werden. Die umfassendere Bedeutung – einschließlich Eigentumsrechten, Einheiten, Ausschlüssen, Herkunft, Richtlinien, Gültigkeitsdaten sowie Verbindungen zu Unternehmenskonzepten – neigt dazu, in andere Systeme abzudriften. Fragmentierung ist oft das eigentliche architektonische Problem: Ein dimensionales Maß, eine LookML-Maßangabe und ein Katalogbegriff beschreiben jeweils einen überschneidenden Aspekt derselben Geschäftsidee, jedoch unter drei verschiedenen Identitäten.

Einmal kompilieren, auf vielfältige Weise bereitstellen. Ein kanonisches Modell sollte seine Darstellungen erzeugen oder steuern – beispielsweise LookML, SQL-Views, API-Schemata, Katalogeinträge, Graphenstrukturen, Verträge für Tools für Agenten, Dokumentation sowie Validierungstests. Plattformen dürfen ihre eigene Syntax beibehalten, doch die Bedeutung darf nicht von ihnen erfunden werden.

LinkML zeigt, dass ein technologieunabhängiges Modell SQL DDL, BigQuery DDL, JSON Schema, OpenAPI, OWL, SHACL, Dokumentationen sowie Validatoren erzeugen kann. Was es jedoch nicht kann, ist im Namen anderer Entscheidungen bezüglich Fakten, Dimensionen, Messwerten, Granularität oder konformer Dimensionen zu treffen. Es gibt Forschungen zur Umwandlung von Ontologien in Sternschemata, doch es gibt keine etablierte Kette, die von einer kanonischen Ontologie über ein verwaltetes dimensionales Lager und ein ausführbares semantisches Modell bis hin zu einer auf der Ontologie basierenden Übersetzung von Natursprache in SQL reicht. Genau in diesem fehlenden Prozessschritt liegt die ingenieurtechnische Herausforderung, wobei die Erzeugung von DDL lediglich eine einfache Demonstration darstellt.

Zwei Ansätze und das Bedürfnis nach Konvergenz

Die meisten Unternehmen können das Lagerprogramm nicht pausieren und zunächst auf der Grundlage einer Ontologie neu aufbauen. Das ist in Ordnung. Die Aufgabe besteht darin, dafür zu sorgen, dass die Agenten die Bedeutung dessen, was verschickt werden kann, zuverlässig erfassen, und einen taktischen Weg zu entwerfen, damit sie weiterentwickelt werden können.

Im Rahmen von Plan A hat eine kanonische Unternehmensontologie die semantische Autorität, mit stabilen Identifikatoren und expliziter logischer Semantik. Physische Daten bewegen sich nicht, und die Ontologie wird auf relationale sowie andere Darstellungsformen abgebildet. Analytische Metriken werden zu kompilierten Prognosen. Die Agenten ziehen formale Konzepte, Beziehungen, Richtlinien sowie Herkunftsangaben heran, und Änderungen werden wie Code versioniert und veröffentlicht. Die Darstellungen innerhalb der Produkte werden aus der von dem Unternehmen gehaltenen Semantik generiert oder darauf abgebildet.

Plan B beginnt bereits dort, wo bereits Flächen genutzt werden: eine gesteuerte Metriken-Schicht in Kombination mit einem Katalog und einem Kontextmodell, zu denen absichtlich stabile, kanonische IDs hinzugefügt werden. Das Lager bleibt die Autorität, und die Zuordnung von semantischen Objekten zu Tabellen, Spalten, Verknüpfungen und Filtern wird festgehalten. Agenten wählen zertifizierte Felder und Metriken anstelle von Rohdaten-Tabellen und beziehen ihren Kontext aus Kontextdiensten, überprüften Abfragen sowie einem Abrufmechanismus, der Berechtigungen berücksichtigt. Metriken, Zuordnungen, „goldene“ Abfragen sowie semantische Regressionstests werden in den CI/CD-Pipeline integriert. IDs, die sich auf ein bestimmtes Produkt beziehen, werden niemals zu Unternehmensidentitäten, und Übersichtstabellen ermöglichen weiterhin Migrationsvorgänge.

Ein konkreter Plan B für Google Cloud kombiniert das Knowledge Catalog zur Bereitstellung von Kontext und zur Suche mit Looker – wobei ein reguliertes semantisches Modell die analytischen Prozesse auf zertifizierte semantische Objekte beschränkt, überprüfte Abfragen als Referenzpunkte für Regressionen nutzt und Unternehmensidentifikatoren außerhalb eines einzelnen Produkts speichert. Das Knowledge Catalog ist nur im engeren Sinne ontologisch geprägt, da es typisierten Kontext und Beziehungen für Agenten bietet, ohne ein vollständiges formales Ontologiesystem darzustellen. Man sollte es als Werkzeug und nicht als unumstößliche Regel betrachten.

Das Risiko besteht darin, eine taktische semantische Schicht zu verwenden, deren Identifikatoren und Logik niemals in ein formelleres Modell übertragen werden können. Ein Plan B, der sich nicht weiterentwickeln lässt, ist letztlich ein Sackgassenszenario, das lediglich mit Dashboards verziert wird.

Zuerst lösen, dann Tabellen anfassen

Ein solider Weg für konversationelle BI-Lösungen sollte nicht mit der Auswahl von Tabellen beginnen, sondern mit der semantischen Klärung der Anforderungen.

Nehmen Sie die Frage „Ist die Kundenabwanderung bei hochwertigen Einzelhandelskunden in diesem Quartal gestiegen?“ Her. Abwanderung, hochwertige Einzelhandelskunden und dieses Quartal müssen zuerst in gemanagte Objekte umgewandelt werden. In diesen Objekten sind die Definition der Metrik, die Klassifizierung, die Zeitkonvention, die zulässigen Dimensionen, die Quellzuordnungen sowie die Richtlinien enthalten. Erst danach sollte eine Ausführungsschicht die physische Abfrage erstellen.

Die Teammitarbeiter sollten in der Lage sein, die Abläufe in acht Schritten aufzuzählen:

Frage und Benutzerkontext
Semantische Umwandlung in gemanagte Konzepte und Metriken
Auswertung des Kontexts unter Berücksichtigung von Richtlinien und Berechtigungen
Zuordnung von semantischen Objekten zu physischen Daten
Erstellung der Abfrage oder des Toolsplans
Ausführung und Abgleich
Antwort, die durch Belege und Herkunft untermauert wird

Semantische Regression oder Bewertung sowie gelenkte Aktionen, wo dies anwendbar ist

Der Ansatz besteht keineswegs darin, das analytische Schema einfach in die Anfrage einzufügen und zu hoffen. Der große Sprachmodell kann zwar die Absicht klären und einen Plan erstellen, doch dies geschieht über gelenkte semantische Objekte und Tool-Verträge – nicht durch die Dekodierung des Wortschatzes des CFO aus einer Tabelle namens fct_rev_v3.

Überprüfte Abfragen sind als Tests und Beispiele wertvoll, doch sie stellen noch nicht die Semantik dar. Sie belegen lediglich, dass eine Frage zu einem bestimmten Zeitpunkt zu einer akzeptierten Implementierung führte. Die zugrundeliegende Bedeutung benötigt weiterhin ihre eigene Identität und Definition.

Was zählt nicht als semantische Architektur

Ein Katalog voller prosaischer Beschreibungen unterstützt die Entdeckung, ist aber kein ausführbares semantisches System.

Durch die Standardzuweisung von Tools zu rohen Lager-Schemata und die Bezeichnung dieses Self-Service-BI als solches wird das semantische Risiko lediglich auf ein probabilistisches Modell verlagert.

Das Duplizieren jeder Lager-Datenmenge in ein Wissensgraphen „für KI“, ohne klare Vorteile bei der Umsetzung, führt zu einer zweiten Unternehmenswahrheit, die aufgrund von Synchronisierungsverzögerungen hinterherhinkt.

Wenn Metriken so vollständig von der Ontologie getrennt werden, dass ein und dasselbe Geschäftskonzept in BI-Systemen und Wissensmodellen unterschiedliche Identitäten erhält, entstehen später Konflikte.

Die Verwechslung von Darstellung mit Semantik – beispielsweise durch die Annahme, ein Graph sei von Natur aus semantisch reicher als ein dimensionales Modell – ist gedankliches Cargo-Cult-Verhalten. Dimensionale Modelle, semantische Schichten, Wissensgraphen und Ontologien kodieren jeweils in unterschiedlichem Maße Bedeutung, und allein die Wahl eines Graphen fügt keine Bedeutung hinzu.

Wenn Metadaten oder durch KI erzeugte Beziehungen ohne Angabe der Herkunft oder Prüfungsstatus als Fakten behandelt werden, verwandelt sich plausibel erscheinende Fiktion in Richtlinien.

Das Ziel in einem Satz

Menschen möchten die Zahlen des letzten Monats genauso beiläufig anfordern können wie das Wetter. Das ist nicht länger Fantasie. Der Software wird die semantische Arbeit übertragen, die früher von Analysten und Ingenieuren unbemerkt erledigt wurde, und konsistente Antworten zu erzielen bedeutet, diese Arbeit explizit zu machen.

Weder ein auf ein Lagerhaus angebrachtes LLM noch ein Katalog in Kombination mit Vektorabfragen sind das Endziel. Es handelt sich um ein reguliertes semantisches System, in dem Konzepte, Beziehungen, Metriken, Einschränkungen, Richtlinien, Qualität und Herkunft für Menschen und Maschinen immer denselben Sinn haben und durch formale Zuordnungen an die zugrunde liegenden Daten gebunden sind.

Ein Großteil der zugrundeliegenden Daten wird weiterhin am besten in relationellen und SQL-basierten Analysemaschinen verarbeitet, und semantische oder ontologische Technologien sind noch nicht da, um sie zu ersetzen. Ihre Aufgabe besteht darin, das Modell auf ein Niveau zu vervollständigen, das ein relationales Schema allein niemals erreichen könnte – selbst dann nicht, wenn dimensionales Modellieren und sorgfältige Benennung bereits alles Mögliche erreicht haben.

Wenn es noch nicht realistisch ist, eine vollständige Analyseontologie zu entwickeln und zu warten, sollte eine gesteuerte semantische Schicht bereitgestellt werden, wobei der Überbegriff unverändert bleibt. Die Semantik sollte nach oben migrieren – aus Dashboards und Eingabefeldern heraus in ein erstklassiges Unternehmensmodell – wobei jede Produkt-Schicht als kompilierte Ansicht behandelt wird.

Ziel ist nicht eine einzige Datenbank, ein Werkzeug oder eine Syntax. Es geht um eine einheitliche Bedeutung, die von einer Person, einem Dashboard, einer Anwendung und einem KI-Agenten auf dieselbe Weise interpretiert wird. Wenn die vier unterschiedlicher Auffassung sind, liegt das Problem nicht beim LLM. Es handelt sich um ein aufgeschobenes Identitätsproblem.