Talk with your Data: warum Text-to-SQL ohne semantisches Modell falsche Zahlen liefert.

Die Demo läuft auf einer Datenbank mit sprechenden Spaltennamen, einem Kalenderjahr und einer Tabelle je Begriff. Ihre Datenbank hat drei Spalten, die Umsatz bedeuten könnten, ein Geschäftsjahr ab Oktober, Storno als negative Beträge, Regionscodes aus zwei Systemgenerationen und Rechte, die über eine Rollentabelle laufen. Das Sprachmodell sieht davon nichts; es sieht Spaltennamen und erzeugt die wahrscheinlichste Abfrage. Die läuft — und liefert eine Zahl, die plausibel ist, weil sie in der richtigen Größenordnung liegt.

Das ist der gefährlichste Fehlertyp im Reporting: nicht die Abfrage, die abbricht, sondern die, die durchläuft. Ein Syntaxfehler fällt auf; eine Zahl, die 6 Prozent zu hoch ist, wird in die Vorstandsvorlage übernommen. Im Webinar „Talk with your Data“ haben wir dieselbe Frage live gegen ein Marketing-Modell gestellt — mit und ohne semantisches Modell. Der Unterschied war nicht die Geschwindigkeit, sondern dass die zweite Antwort einen Beleg hatte, den man prüfen konnte.

Die Abfrage aus dem Schaubild ist keine Karikatur; sie ist das, was ein Sprachmodell gegen eine typische Verkaufstabelle erzeugt, wenn es nur die Spaltennamen kennt. Jeder der sechs Fehler hat eine eigene Ursache im fehlenden Modell — und jeder hätte eine Definition, eine Beziehung oder eine Regel verhindert.

Das semantische Modell liefert dem Agenten fünf Dinge, die in keiner Datenbank stehen: Definitionen (die fünf Felder je Kennzahl aus dem Semantic-Layer-Kapitel), Beziehungen mit Kardinalität und Filterrichtung, den Geschäftskalender, die Rollen und die Synonyme — „Erlös“, „Umsatz“ und „Revenue“ zeigen auf dasselbe Measure. Über MCP liest der Agent genau diese Metadaten: Measures auflisten, Beziehungen lesen, DAX lesend ausführen, Lineage auflösen. Zeilen und Werte sieht er nicht.

Mit diesem Kontext ändert sich, was der Agent erzeugt. Statt SQL gegen Spaltennamen erzeugt er eine Abfrage gegen die Definition — in Power BI als DAX gegen das Measure, in SQL gegen die View, die das Measure implementiert. Die Regelprüfung läuft vor der Ausführung: Zeitintelligenz nur über die Datumstabelle, Pflichtfilter gesetzt, Rolle des Fragenden angewendet. Und die Antwort trägt ihren Beipackzettel: Measure „Umsatz netto“ (Formel, Verantwortlich: Controlling), Tabelle Fakt Umsatz, Filter GJ 2026 Q3 Region Süd, Stand 31.10., Regelprüfung bestanden, zwei Ableitungsebenen bis zur Quellspalte. Fehlt eines dieser Felder, ist die Antwort ein Vorschlag, keine Zahl.

Ob die Frage als DAX gegen das Semantikmodell oder als SQL gegen das Warehouse beantwortet wird, ist keine Geschmacksfrage. DAX gegen das Modell hat die Definitionen, die Beziehungen, die Zeitintelligenz und die RLS eingebaut — die Antwort ist dieselbe wie im Bericht, dem der Fachbereich vertraut. SQL gegen das Warehouse ist richtig, wenn die Frage unterhalb des Modells liegt: Datenqualität, Ladeprotokolle, Vergleiche zwischen Staging und Produktion. Für Fachfragen gilt: so hoch wie möglich im Stack, so nah wie möglich am Measure.

Microsofts eigene Antwort auf dieselbe Einsicht sind Fabric Data Agents mit NL2DAX, NL2SQL und NL2KQL gegen bis zu fünf Quellen — mit Anweisungen und Beispielabfragen, die genau den Kontext nachliefern, der dem reinen Sprachmodell fehlt. Wo sie passen und wo nicht — derzeit nur Englisch, nur lesend —, steht im Vergleich der drei Agenten-Wege. Die Mechanik ist in allen Fällen dieselbe: Die Qualität der Antwort ist eine Funktion der Metadaten, nicht des Modells.

Self-Service BI hat die Arbeit in den Fachbereich verlagert; Talk with your Data verspricht, sie dort leichter zu machen. Das gelingt nur, wenn der Fachbereich nicht die Datenbank befragt, sondern das Modell, das sein Controlling freigegeben hat — mit denselben Definitionen, denselben Rechten, demselben Stand. Dann ist die Frage „Umsatz netto Q3 je Region?“ kein Risiko, sondern eine Abfrage mit Beleg, die der Fachbereich selbst prüfen kann: Measure, Filter, Stand stehen in der Antwort.

Drei Regeln haben sich in Projekten bewährt: Erstens bekommt der Fachbereich nur Fragen beantwortet, deren Kennzahlen im Katalog stehen — fehlt eine, ist die Antwort „nicht definiert“, nicht eine Schätzung. Zweitens läuft jede Abfrage mit der Rolle des Fragenden. Drittens wird jede Antwort protokolliert, damit die Frage „woher kam die Zahl?“ zwei Wochen später eine Antwort hat. Der Prompt-Leitfaden im Arbeitsmaterial übersetzt das in Formulierungen, die Fachbereiche ohne Schulung verwenden können.

Bevor ein Fachbereich Fragen stellt, stellt das BI-Team zehn: echte Fachfragen in der Sprache des Fachbereichs, je mit einem Referenzwert aus dem Bericht, dem heute vertraut wird, einer Toleranz, drei Durchläufen und vier Bewertungsklassen — exakt, in Toleranz, falsch, verweigert. Abnahmeregel: mindestens neun von zehn in Toleranz, null sicher-falsche Antworten, jede Antwort mit Measure, Filter und Stand. Streuen die drei Durchläufe, fehlt Kontext im Modell; weicht der Referenzwert selbst ab, ist es ein Datenfehler.

Der Fragenkatalog im Arbeitsmaterial enthält vierzig Fragen aus Vertrieb, Controlling, Marketing und Betrieb, sortiert nach dem Kontext, den sie brauchen — von „Umsatz je Region“ (Definition) über „Vorjahresvergleich“ (Zeitintelligenz) bis „Deckungsbeitrag je Kunde“ (Definition, Beziehung, RLS). Wer die zehn aus seinem Katalog gewählt hat, hat damit auch die Liste der Lücken, die vor dem Rollout zu schließen sind — und einen Test, der nach jeder Modelländerung erneut läuft.