Warum KI-Analyse-Agenten eine semantische Schicht statt rohen SQL benötigen
Text-to-SQL bei Rohtabellen erfindet Metriken und überspringt Zugriffsregeln. Eine semantische Schicht wie Cube, die über MCP bereitgestellt wird, verleiht KI-Agenten gesteuerte geschäftliche Bedeutung.
Quellen: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Es ist der schnellste Weg, eine beeindruckende Demo zu erstellen, wenn man einem KI-Analyse-Agenten erlaubt, SQL-Code zu schreiben. Gleichzeitig ist es auch der schnellste Weg zu Problemen, falls dieser SQL-Code auf rohen Lagerdatenblättern ohne Geschäftskontext ausgeführt wird. Der Fehler liegt nicht in der Syntax, sondern in der Bedeutung.
Nehmen wir das Wort „Umsatz“ und fragen wir, was damit gemeint ist:
- Gesamt- oder Nettoumsatz?
- Werden Rückerstattungen abgezogen?
- Welche Datumsspalte bestimmt das Quartal?
- Heißt „aktiver Kunde“ aktiv zum Zeitpunkt der Bestellung oder heute?
- Welche Regionenzuordnung gilt?
- Welches Währungsumrechnungsregelwerk wird angewendet?
- Ist diesem Benutzer überhaupt die Ansicht der Daten dieses Kunden gestattet?
Die reine Text-zu-SQL-Verarbeitung versagt genau an diesen Stellen. Das Modell kann gültigen SQL-Code erzeugen, die Datenbank kann ihn problemlos ausführen – doch die Ergebnisse können dennoch falsch sein. Aus diesem Grund benötigt ein Analyseagent eine semantische Schicht zwischen sich und den Geschäftsdaten. Cube ist ein gut konstruiertes Beispiel für eine solche Schicht, und er dient als Fallbeispiel im Folgenden.
Schemata tragen keine Bedeutung
Text-zu-SQL ist eine gute Idee. Sie ermöglicht Entwicklern, Analysten und Geschäftsbenutzern, schneller voranzukommen. Doch ein Lager-Schema enthält selten die Bedeutung, die man von ihm erwartet.
Eine Tabelle bietet Spalten wie amount, status, created_at, customer_type, region_id und currency, und niemand im Unternehmen formuliert Fragen auf diese Weise. Niemand fragt nach sum(amount) grouped by region_id where status = 'paid'. Stattdessen fragen sie, wie das Umsatzwachstum der Unternehmen in Südindien im letzten Quartal war.
Der eine Satz verbirgt eine Reihe von Entscheidungen. Was ist Umsatz, und was macht einen Kunden zu einem Unternehmen? Welches Datum markiert das Quartal, und wie wird Südindien dargestellt? Werden Rückerstattungen und stornierte Bestellungen entfernt? Welche Währungsregel gilt, und was darf der Anfragende sehen? Ein Modell kann zu jedem Punkt eine Schätzung abgeben. Doch Schätzen ist keine Governance. Wenn die Antwort des Agents von der Anzeige abweicht, verlieren die Menschen das Vertrauen darin. Wenn falsche Tabellen verwendet werden, sieht die Zahl glaubwürdig aus, ist aber falsch. Wenn Zugriffsregeln ignoriert werden, führt die Antwort zu einem Datenleak.
Die eigentliche Frage ist also nicht, ob das Modell SQL schreiben kann. Es geht darum, ob das Modell überhaupt Geschäftslogik erfinden sollte.
Was eine semantische Schicht leistet
Eine semantische Schicht befindet sich zwischen den Rohdaten und den Nutzern dieser Daten und wandelt technische Datenbankstrukturen in strukturierte Geschäftskonzepte um. Sie definiert Metriken, Maße, Dimensionen, Verknüpfungen, Segmente, Hierarchien, Zugriffsregeln, Caching-Regeln, vorab durchgeführte Aggregationen sowie die APIs, die zur Abfrage dieser Daten verwendet werden, anstelle dass Tabellen und Spalten direkt sichtbar gemacht werden.
Konkret werden orders.amount, customers.type, orders.created_at und refunds.amount zu Begriffen wie Umsatz, Unternehmenskunde, Bestelldatum und umgerechneter Umsatz. Agenten benötigen dieses Vokabular. Ohne semantische Schicht muss ein Agent sich ein Schema ansehen und selbst Schlüsse ziehen. Mit einer solchen Schicht arbeitet er nach genehmigten Definitionen. Der Agent ist zwar immer noch nicht perfekt, doch eine wichtige Ursache für Fehlinterpretationen in der Analytik verschwindet, da die Metrikdefinition nicht mehr aus den Rohdaten rekonstruiert werden muss.
Es handelt sich um eine Kategorie und nicht um ein einzelnes Produkt. Cube, die dbt Semantic Layer (basierend auf MetricFlow) sowie Lookers LookML adressieren jeweils das gleiche Problem in ihren eigenen Ökosystemen. Cube zieht hier die Aufmerksamkeit auf sich, weil seine Darstellung für Analyseagenten ungewöhnlich vollständig ist – allerdings spielt die Architektur eine wichtigere Rolle als die Marke.
Warum Cube ein gutes Beispiel ist
Cube ist nicht nur eine Dashboard-Schicht. Ein einziges, gut verwaltetes Modell versorgt gleichzeitig BI-Tools, eingebettete Analysen, APIs sowie KI-Agenten mit Daten, wobei dieses Modell aus Würfeln, Messgrößen, Dimensionen, Verknüpfungen, Segmenten, Hierarchien, vorab aggregierten Werten sowie Zugriffsrichtlinien besteht. Das sind nahezu genau die Bausteine, die ein Analyseagent benötigt.
Seine eigene Beschreibung des Designs fasst die Kernidee gut zusammen: Die Agenten fragen nicht direkt das Datenlager ab, sondern die semantische Schicht, wobei die Laufzeitumgebung als Schutzmechanismus zwischen Agent und Datenlager fungiert.
Vergleichen Sie, was jede Ebene dem Modell zur Verfügung stellt. Bei einer rohen Tabelle erkennt es nur Spaltennamen und nichts weiter. Bei einer semantischen Schicht erhält es außerdem die genehmigten Konzepte, die Berechnungen dahinter, deren Zusammenhänge, was der aktuelle Benutzer bearbeiten darf, sowie eine sichere Abfragemethode. Jedes Mal wieder Geschäftslogik neu entdecken zu müssen, ist verschwenderisch – daher sollte der Agent eine Schicht abfragen, die diese bereits enthält.
Verbindung plus Bedeutung: Wo MCP passt
MCP ist die gängige Methode, um KI-Assistenten mit externen Tools und Daten zu verbinden – doch Verbindung herzustellen bedeutet noch nicht, etwas zu verstehen. Selbst wenn einem Agent über MCP direkter Zugriff auf rohe Lagertabellen gewährt wird, muss er weiterhin die Bedeutung erraten, was das ursprüngliche Problem darstellt.
Ein stärkeres Muster leitet den Agenten über die semantische Schicht:
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP kümmert sich um den Zugriff und die semantische Schicht um die Bedeutung. Der Agent sollte nicht die Datenbank fragen, welche Tabellen zur Berechnung des Umsatzes kombiniert werden müssen. Stattdessen sollte er die semantische Schicht um die genehmigte Umsatzmetrik sowie die verwendbaren Dimensionen bitten.
Zwei Einschränkungen sorgen für Realismus, da sich dieses Gebiet schnell entwickelt und leicht übertrieben werden kann. Der offizielle Cube MCP-Server, der Teil von Cube Cloud ist und über HTTPS mit OAuth erreichbar ist, unterscheidet sich von den community-basierten MCP-Servern für Cube, wie zum Beispiel denen, die über Smithery verteilt werden. Ihr Vertrauensgrad, ihre Unterstützung und Wartung unterscheiden sich, und für produktive Anwendungen ist der offizielle, regulierte Weg erforderlich. Zudem ist die native MCP-Unterstützung erst kürzlich in diesem Bereich hinzugekommen und baut auf den seit Jahren angebotenen REST-, SQL- und GraphQL-APIs auf. Sie funktioniert zwar, handelt sich aber um eine Funktion aus dem Zeitraum 2025 bis 2026 – prüfen Sie daher, ob sie mit der von Ihnen tatsächlich genutzten Version kompatibel ist.
Eine sicherere Architektur von Anfang bis Ende
Im vollständigen Zusammenhang sieht der Ablauf so aus:
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
Der Agent hat keinen freien Zugriff auf Rohdaten. Er erhält eine regulierte Schnittstelle, sodass das Team kontrollieren kann, welche Metriken vorhanden sind, welche Dimensionen gültig sind, wie Verknüpfungen funktionieren, welche Filter erlaubt sind, wer welche Zeilen sehen kann, ob Antworten aus dem Cache oder aus voraggregierten Daten stammen und wie Abfragen über APIs bereitgestellt werden. Das ist besser, als einem Modell beizubringen, SQL zu schreiben, in der Hoffnung, dass die Geschäftslogik richtig funktioniert.
Beispiellösung: Umsatzwachstum
Man fragt nach dem Umsatzwachstum des Unternehmens im letzten Quartal. Ohne semantische Schicht muss der Agent selbst ermitteln, in welcher Tabelle der Umsatz gespeichert ist – ob es sich um Bruttoumsatz, Nettoumsatz, gebuchten oder anerkannten Umsatz handelt – ob Rückerstattungen ausgeschlossen werden, wie Unternehmenskonten identifiziert werden, welche Zeitspalte das letzte Quartal definiert, ob Währungen umgerechnet werden müssen und ob dieser Benutzer jeden Segment ansehen kann. Der SQL-Code mag ausgeführt werden, aber Ausführung bedeutet noch nicht, dass das Ergebnis korrekt ist.
Durch eine semantische Schicht existieren diese Antworten bereits. Der Umsatz ist eine genehmigte Kennzahl, der Unternehmenskunde ist ein genehmigtes Segment, das Bestelldatum ist eine genehmigte Zeitdimension – die Rückerstattungslogik wird einmal definiert und die Zugriffsrichtlinie gilt je nach Anfragenden. Der Agent erfindet keine Kennzahl, sondern beantragt eine genehmigte. Das unterscheidet die Erstellung von SQL-Anfragen in natürlicher Sprache von regulierten, gesteuerten analytischen Prozessen.
Was kann bei direktem Zugang zum Lager schiefgehen?
Direkter Zugang lässt dem Agenten zu viel Spielraum für Vermutungen, und die Fehler sind vorhersehbar:
- Kennzahlen-Erfindung: Der Umsatz wird anders berechnet als im Finanz-Dashboard.
- Falsche Verknüpfungen: Die Abfrage läuft, doch eine Verknüpfung dupliziert Zeilen oder löscht Einträge aus.
- Fehlende Filter: Stornierte Bestellungen, Testkonten, gelöschte Einträge oder interne Benutzer bleiben dabei.
Agenten, die geschäftliche Fragen beantworten, benötigen strengere Sicherheitsmaßnahmen als die von der SQL-Generierung bereitgestellt werden. Sie brauchen semantische Einschränkungen.
SQL beibehalten, ohne rohe Tabellen freizugeben
Flexibilität aufzugeben ist nicht der Preis für eine gute Governance. Eine ausgereifte semantische Schicht kann eine SQL-Schnittstelle offen halten, die auf verwaltete Objekte statt auf physische Tabellen verweist. In Cubes SQL-API erscheint jede Kugel oder Ansicht wie eine Tabelle, und ihre Messgrößen, Dimensionen sowie Segmente wie Spalten. Da sie das Postgres-Wire-Protokoll sowie -Dialekt verwendet, kann sich fast jeder client, der Postgres unterstützt, daran verbinden.
Tools und Agenten ermöglichen weiterhin Abfragen im SQL-Stil, doch das Modell bestimmt, was abgefragt werden kann. Der Agent durchforstet nicht rohe Tabellen, sondern arbeitet mit genehmigten Metriken und Dimensionen – ein praktischer Kompromiss, der viel näher an der Art und Weise liegt, wie Produktivitätsanalysen eigentlich ablaufen sollten.
Zugriffsregeln sind genauso wichtig wie Metriken
Bei konversationalen Agenten wird der Zugriffskontroll wird entscheidend, da ein Chatfenster offene Fragen zulässt. Jemand tippt „Zeigen Sie mir den Umsatz nach Kunden“, und das System muss wissen, welche Kunden diese Person einsehen darf, welche Region oder Tenant gilt sowie ob detaillierte Kundendaten erlaubt sind oder nur Aggregatwerte zurückgegeben werden sollen.
Cube wendet Zugriffsrichtlinien sowie Sicherheitsmaßnahmen auf Zeileebene innerhalb der semantischen Schicht an. Diese Platzierung ist beabsichtigt: Niemand sollte davon ausgehen, dass ein Agent jede Regel ohne Aufforderung abruft. Der Satz „Veröffentlichen Sie niemals nicht autorisierte Daten“ in einer Anweisung stellt einen Wunsch dar. Wenn die Schicht einen bestimmten Benutzer auf bestimmte Zeilen, Dimensionen und Messgrößen beschränkt, handelt es sich um Durchsetzung. Durchsetzung ist viel stärker und findet in der Datenschicht statt und nicht in der Anweisung.
Die Leistungsseite: Caching und Voraggregationen
Konversationelle Analytik ist iterativ. Eine Person fragt nach dem Umsatz nach Regionen, teilt ihn anschließend nach Produkten auf, vergleicht ihn mit dem Vorquartal und beschränkt ihn schließlich auf Unternehmenskunden. Wenn jeder Schritt zu einer neuen, komplexen Abfrage führt, steigen Latenz und Kosten schnell an.
Cubes Voraggregationen und Caching, die durch seinen CubeStore-Engine abgewickelt werden, beschleunigen häufige analytische Abfragen. Ein gemeldetes Ergebnis war eine etwa halbierte Lagerkosten nachdem die Aggregationen in Cubes Speicher übertragen wurden. Für wiederkehrende Fragen dient also die semantische Schicht neben der steuernden Funktion auch als Leistungsverbesserungsschicht.
Wo sich dieses Muster auszahlt
Agenten, die Fragen zu Umsätzen, Kundensegmenten, Produktnutzung, eingebetteten kundenorientierten Analysen, operativen Dashboards, KPIs oder Erklärungen zu Metriken beantworten, profitieren am meisten, genauso wie jedes Self-Service-BI-Szenario.
Die Vorteile sind am größten dort, wo bereits wiederkehrende Definitionen vorhanden sind. Definieren Sie einmal ARR, MRR, Umsatz, Churn-Rate, Retention-Rate, aktive Nutzer, Konversionsrate, Bruttomarge, Zeit bis zur Ticketlösung sowie die Adoptionsrate neuer Funktionen – danach verwenden alle Agenten diese Definitionen erneut, anstatt sie jedes Mal bei einer Änderung der Anfrage neu zu berechnen.
Wo Teams vorsichtig sein sollten
Das alles ist keine Magie – die Governance muss real sein und nicht nur ein Etikett. Ein unvollständiges Modell erschwert die Arbeit des Agents. Falsche Definitionen von Metriken führen zu korrekt verwalteten, aber falschen Zahlen. Übermäßig weit gefasste Zugriffsrichtlinien gefährden weiterhin die Datensicherheit. Ein mit verwirrenden, nahezu identischen Metriken überladenes Modell lässt den Agenten das Falsche auswählen. Und wenn die Aktualität nicht sichtbar ist, kann eine Antwort aktuell erscheinen, obwohl sie auf veralteten Daten beruht.
Die wichtige Frage ist daher nicht, ob eine semantische Schicht vorhanden ist, sondern ob diese Schicht gut genug ist, damit ein Agent sie sicher nutzen kann. Das Modell muss dokumentiert, versioniert, getestet, Zugriffskontrollen unterliegen und verständlich sein, mit den Dashboards übereinstimmen, denen die Menschen bereits vertrauen, mit Datenqualitätsprüfungen verbunden sein und Klarheit über Aktualität und Grenzen bieten. Eine schwache Schicht führt zu schwachen Antworten des Agents.
Von rohem SQL zu kontrollierter Analytik
Was die Ansätze voneinander unterscheidet, ist, was der Agent wahrnimmt und was fehleranfällig sein kann:
- Roher Text-zu-SQL-Ansatz: Der Agent sieht Lager-Tabellen und -Spalten, wobei das Hauptrisiko eine erfundene Geschäftslogik darstellt.
- SQL zusammen mit Schema-Dokumentation: Eine Verbesserung, doch Join-Operationen und Metriken werden weiterhin leicht falsch verwendet.
- Nur eine semantische Schicht: Der Agent arbeitet mit definierten Metriken, Dimensionen, Beziehungen und Richtlinien. Sicherer, wobei die Qualität durch das dahinterliegende Modell begrenzt wird.
- Semantische Schicht plus MCP: Regulierte Analysen, die als Agent-Tools bereitgestellt werden, sind derzeit am besten geeignet für kontrollierte KI-Analysen.
Text-zu-SQL bleibt nützlich, doch für Geschäftsanalysen sollte er auf einer regulierten semantischen Struktur statt auf Vermutungen bezüglich eines rohen Schemas basieren.
Checkliste, bevor ein Agent auf Geschäftsdaten zugreift
- Platzieren Sie zunächst die Kernmetriken in einer semantischen Schicht.
- Erklären Sie ausführlich, welche Dimensionen und Verbindungen zulässig sind.
- Setzen Sie Zugriffsrichtlinien sowie Regeln auf Zeileebene in der Schicht durch.
- Bieten Sie regulierte APIs anstelle der ursprünglichen Rohtabellen.
- Erreichen Sie die Schicht über MCP ausschließlich über genehmigte, offizielle Tools.
- Führen Sie ein Protokoll über jede Abfrage des Agents samt dem daraus resultierenden SQL-Code.
- Liefern Sie jede Antwort zusammen mit der Definition der dahinterliegenden Metrik.
- Geben Sie in jeder Antwort an, wie aktuell die Daten sind.
- Stellen Sie bekannte Geschäftsfragen erneut und vergleichen Sie die Ergebnisse mit zuverlässigen Dashboards.
- Blockieren Sie den direkten Zugriff auf sensible Lagertabellen.
- Entscheiden Sie, was passiert, wenn eine angeforderte Metrik keine Definition hat.
- Lehren Sie den Agenten, „nicht definiert“ zu antworten, anstatt improvisieren zu müssen.
- Versionieren Sie Metrikdefinitionen wie Code.
- Testen Sie Zugriffsregeln mit echten Benutzerrollen.
- Achten Sie auf Abfragen, die Fehler verursachen oder unklare Ergebnisse liefern.
Die wichtigste Regel: Wenn eine Metrik nicht definiert ist, sollte der Agent keine erfinden. Er sollte um Klarstellung bitten oder mitteilen, dass die Metrik nicht verfügbar ist.
Fragen an die Produktteams
Bevor Sie einem neuen Analyseagenten Ihr vollständiges Lager-Schema zur Verfügung stellen, halten Sie inne und klären Sie zunächst einige Dinge. Bestimmen Sie, welche geschäftlichen Fragen er beantworten soll, welche Metriken genehmigt sind, welche Dimensionen gültig sind und welche Verknüpfungen sicher sind. Klären Sie außerdem, wer was sehen darf, wie aktuell die Daten sein müssen, welche Antworten eine Definition oder einen Verweis benötigen und welche Abfragen abgelehnt werden müssen. Erst danach sollten Sie diese eingeschränkte Struktur dem Agenten zugänglich machen.
Der Cube ist eine Möglichkeit, die Oberfläche zu erstellen, während die dbt Semantic Layer-, LookML- und MetricFlow-Ansätze dasselbe Problem aus anderen Perspektiven angehen. Die wesentliche Erkenntnis hat nichts mit einem bestimmten Produkt zu tun. Agenten benötigen vor dem Umgang mit Geschäftsdaten geregelte Geschäftssemantik.
Der Kernpunkt
Die Betrachtung von KI-Analysen ausschließlich als Text-zu-SQL-Aufgabe verfehlt den Zweck, da die Steuerung der Bedeutung der schwierigere Teil ist. Ein Agent, der auf rohe Lagerungs tabellen zugreift, kann zwar vollkommen gültigen SQL-Code schreiben, aber dennoch falsche Geschäftsantworten liefern – durch erfundene Metriken, fehlerhafte Verknüpfungen, übersprungene Zugriffsregeln oder Zahlen, die im Widerspruch zum Dashboard stehen. Eine semantische Schicht wechselt die Schnittstelle: Genehmigte Metriken, Dimensionen, Verknüpfungen, Richtlinien und APIs ersetzen ein rohes Schema, das interpretiert werden muss. MCP stellt die Verbindung bereit, die semantische Schicht liefert die Bedeutung – und geregelte Analysen benötigen beides.
Weitere Literatur
- Ein AI-Agent zur Qualifizierung von Leads in Python mit FastAPI und Pydantic erstellen — Rohdaten zu qualifizierten Leads umwandeln: strukturierte Extraktion mit LLMs, Validierung mit Pydantic, bewertungsbasiertes Scoring, Speicherung in PostgreSQL, Warteschlangen sowie eine Überprüfungsschleife durch Menschen.
- Vergleich von Managed Agents: Anthropic, LangGraph und Google ADK — Wer steuert den Sandbox, die Zugangsdaten und die Protokolle? Ein Vergleich von Anthropic Managed Agents, LangGraph und Google ADK mit Preisen, Ausfallmöglichkeiten sowie einer schnellen Entscheidungshilfe.