Text-to-SQL scheitert nicht am Modell, sondern an den Metriken

Die Erwartung an Text-to-SQL ist verständlich: eine Fachabteilung fragt in natürlicher Sprache, das Modell schreibt SQL, die Zahl kommt. In Demos funktioniert das beeindruckend gut. In gewachsenen Warehouses funktioniert es deutlich schlechter, und die übliche Erklärung – das Modell sei noch nicht gut genug – trifft nicht den Kern.

Das Experiment, das jeder selbst machen kann

Man nehme die Frage „Wie hoch war der Umsatz im letzten Quartal?“ und gebe sie drei erfahrenen Menschen im eigenen Haus – einem aus dem Controlling, einem aus dem Vertrieb, einem aus der Buchhaltung. In den meisten Unternehmen kommen drei verschiedene Zahlen zurück, und alle drei sind begründbar:

• Mit oder ohne Stornos, und ab wann gilt ein Storno als gebucht?
• Nach Rechnungsdatum oder nach Leistungsdatum?
• Konzernwährung zum Tages-, Monats- oder Stichtagskurs?
• Intercompany-Umsätze enthalten oder eliminiert?

Wenn drei Fachleute mit Kontext zu drei Antworten kommen, ist die Frage unterbestimmt. Ein Modell, das nur Tabellennamen und Spaltentypen sieht, hat weniger Kontext als diese drei – es kann die Frage prinzipiell nicht besser beantworten, nur schneller.

Ein besseres Modell macht aus einer unterbestimmten Frage keine bestimmte. Es rät nur überzeugender.

Warum das Rateergebnis so gefährlich ist

Ein falsch geschriebenes SQL wirft einen Fehler. Ein richtig geschriebenes SQL auf der falschen Tabelle liefert eine Zahl. Die Zahl sieht plausibel aus, hat die richtige Größenordnung und wandert in eine Präsentation. Der Fehler wird nicht bemerkt, weil nichts kaputtgeht.

Das unterscheidet Text-to-SQL von den meisten anderen Modellanwendungen. Bei einer Übersetzung sieht man, wenn sie schlecht ist. Bei einer Kennzahl sieht man es nicht.

Die Vorarbeit, die tatsächlich wirkt

Statt am Prompt zu arbeiten, arbeitet man an der Eindeutigkeit. Konkret heißt das, für jede Kennzahl, die in Berichten vorkommt, eine Definition zu hinterlegen – maschinenlesbar, versioniert, mit einem Verantwortlichen.

metrik: umsatz_netto
  beschreibung: >
    Nettoumsatz nach Stornoabzug, konzernintern eliminiert.
    Maßgeblich für die externe Berichterstattung.
  quelle: marts.fct_umsatz
  ausdruck: sum(betrag_eur)
  filter:
    - storniert = false
    - intercompany = false
  zeitachse: leistungsdatum       # nicht Rechnungsdatum
  waehrung: EUR, Monatsendkurs
  dimensionen: [region, produktlinie, vertriebskanal]
  freigegeben_von: Controlling
  gilt_ab: 2026-01-01

Mit einer solchen Definition ändert sich die Aufgabe des Modells grundlegend. Es muss nicht mehr entscheiden, welche Tabelle gemeint ist und wie Stornos zu behandeln sind. Es muss nur noch erkennen, dass „Umsatz“ die Metrik umsatz_netto meint, und die Dimensionen aus der Frage ziehen. Das ist eine Zuordnungsaufgabe, und die lösen Modelle zuverlässig.

Was das mit MCP zu tun hat

Über das Model Context Protocol lässt sich genau dieser Katalog anbieten: ein Werkzeug, das die verfügbaren Metriken samt Beschreibung liefert, und eines, das eine Metrik mit Dimensionen und Filtern abfragt. Das SQL entsteht dann im Warehouse aus der Definition, nicht im Modell aus dem Schema.

Der unbequeme Teil

Metrikdefinitionen zu schreiben ist keine technische Arbeit, sondern eine fachliche Einigung. Sie zwingt dazu, Fragen zu entscheiden, die jahrelang offen bleiben konnten, weil jeder Bereich seine eigene Auslegung pflegte. Genau deshalb wird diese Arbeit gern übersprungen und stattdessen ein besseres Modell gesucht.

Der Aufwand lohnt sich aber unabhängig von KI. Ein Semantic Layer beantwortet dieselbe Frage für Dashboards, Notebooks und Exporte. Die KI-Anwendung ist dann der Nutznießer einer Ordnung, die ohnehin fehlte – und nicht ihr Zweck.