Text-to-SQL
Text-to-SQL funktioniert – bis das Schema echt ist.
Ein Sprachmodell schreibt zu einer klaren Frage auf einem sauberen Schema erstaunlich gutes SQL. Auf einem zwanzig Jahre gewachsenen Datenmodell schreibt es weiterhin erstaunlich gutes SQL – nur beantwortet es dann manchmal eine andere Frage als die gestellte. Und das sieht man am Ergebnis nicht.
Der eigentliche Fehler
Nicht die Syntax ist das Problem, sondern die Bedeutung.
Fehlerhaftes SQL ist ungefährlich: Die Datenbank weist es ab, jemand sieht eine Meldung und stellt die Frage neu. Gefährlich ist SQL, das ausführbar ist, ein plausibles Ergebnis liefert und auf einer falschen fachlichen Annahme beruht.
Solche Annahmen entstehen zwangsläufig, wenn ein Modell nur das Schema sieht. Eine Spalte heißt „status“ und enthält Zahlen von 1 bis 7 – welche davon eine offene Rechnung bezeichnet, ergibt sich nicht aus dem Datenmodell, sondern aus einer Fallunterscheidung im Programmcode. Eine Tabelle heißt wie ein Geschäftsobjekt und enthält jede Änderung daran als eigene Zeile.
Enthält ein Datenbereich Änderungshistorie statt Gegenwart, zählt eine technisch korrekte Abfrage Statuswechsel statt Vorgänge.
Im Schema ist dieser Unterschied nicht erkennbar, und am Ergebnis sieht man ihn ebenfalls nicht: Beide Zahlen liegen in einer Größenordnung, die in einem Bericht niemandem auffällt, der sie nicht ohnehin kennt.
Genau das ist der Grund, warum die Zuverlässigkeit von Text-to-SQL nicht mit besseren Modellen steigt: Das Modell hat kein Erkenntnisproblem, sondern ein Informationsproblem. Die Information steht nicht im Schema.
Der strukturelle Unterschied
Generieren oder planen.
Beide Wege beginnen mit einer Frage in natürlicher Sprache. Sie unterscheiden sich darin, was zwischen Frage und Datenbank passiert.
Wo es konkret bricht
Fünf Stellen, an denen gewachsene Schemata Text-to-SQL überfordern.
Keine dieser Stellen ist exotisch. Sie kommen in praktisch jedem System vor, das länger als ein paar Jahre in Betrieb ist.
Statuswerte ohne Bedeutung im Schema
Codes, Kennzeichen und Flags, deren Auslegung im Programmcode steht. Ein Modell, das nur die Spalte sieht, wählt einen plausiblen Wert – und liegt bei jedem zweiten System daneben.
Historisierte Datenbereiche
Tabellen, die jede Änderung als Zeile führen. Ohne die Regel „nur der jeweils letzte Stand zählt“ werden Vorgänge mehrfach gezählt, ohne dass die Abfrage falsch aussieht.
Beziehungen ohne Fremdschlüssel
Zusammenhänge, die nur im Code aufgelöst werden. Ein Modell verbindet dann über ein Feld, das gleich heißt, aber etwas anderes bedeutet.
Mehrdeutige Zeitbezüge
„Dieses Jahr“ kann Erfassung, Rechnung, Buchung oder Leistung meinen. Alle vier Felder existieren, alle vier Abfragen laufen, und die Ergebnisse unterscheiden sich um Prozentpunkte – also genau so weit, dass es nicht auffällt.
Fachbegriffe, die nirgends stehen
„Neukunde“, „aktiver Vertrag“, „offene Forderung“ sind keine Spalten, sondern Regeln. Ein Modell muss sie erfinden, wenn sie nicht beschrieben sind – und es erfindet sie jedes Mal ein wenig anders.
Alle fünf Punkte sind keine Sonderfälle, sondern der Normalzustand gewachsener Produktivschemata – Fremdschlüssel fehlen darin regelmäßig vollständig.
Der naheliegende Einwand
Mehr Kontext im Prompt hilft – bis er nicht mehr hilft.
Der übliche nächste Schritt ist, dem Modell Schemainformationen, Beispielabfragen und Erläuterungen mitzugeben. Das verbessert die Ergebnisse messbar, und für einen abgegrenzten Anwendungsfall kann es genügen.
Es skaliert aber nicht mit der Fachlichkeit. Jede zusätzliche Regel verlängert den Kontext, und irgendwann konkurrieren die Regeln miteinander statt sich zu ergänzen. Vor allem aber bleibt die Wirkung auf die eine Unterhaltung beschränkt: Was ein Mitarbeiter im Chat erklärt hat, weiß der nächste Chat nicht.
Ein Prompt kann Kontext geben. Er kann nicht verhindern, dass eine Frage ohne Grundlage beantwortet wird.
Der entscheidende Punkt ist nicht die Menge der Information, sondern ihr Status. Solange die Regeln Hinweise sind, kann ein Modell sie übergehen – ohne Absicht, einfach weil eine andere Auslegung plausibler wirkte. Sobald sie eine geprüfte Struktur sind, kann es das nicht: Ein Abfrageplan, der einen unbekannten Begriff enthält, wird nicht ausgeführt.
Beispiel
Eine Frage, die generiertes SQL zuverlässig falsch beantwortet.
Zwei Zeiträume, ein Vergleich, ein zweiter Fachbereich und zwei Begriffe, die niemand als Spalte hinterlegt hat.
Schematische Darstellung an einem kaufmännischen Standardfall. Begriffe und Werte sind Beispiele.
| Kunde | Veränderung | Offen |
|---|---|---|
| Kunde A | −38 % | 18.400 € |
| Kunde B | −12 % | — |
- Bestellung zählt
- Erfasst und nicht storniert, bewertet nach Bestelldatum – nicht nach Lieferdatum.
- Rechnung gilt als offen
- Gestellt, nicht storniert, Zahlungseingang kleiner als Rechnungsbetrag, bewertet zum Stichtag.
- Vorjahresquartal
- Dasselbe Kalenderquartal des Vorjahres, nicht die letzten vier Quartale.
SELECT k.name, ...
FROM kunde k
JOIN bestellung b ON b.kunde_id = k.id
WHERE b.storniert = false
AND b.bestellt_am BETWEEN ... AND ...Einordnung
Wann Text-to-SQL genügt und wann nicht.
Die ehrliche Antwort ist nicht „nie“. Sie hängt an vier Eigenschaften Ihres Systems und Ihrer Fragen.
- Sauberes, dokumentiertes Schema
- Sprechende Namen, vollständige Fremdschlüssel, keine Historisierung in Fachtabellen: Hier liefert generiertes SQL oft gute Ergebnisse.
- Fragen ohne Fachbegriffe
- „Wie viele Zeilen hat Tabelle X im Januar?“ braucht keine semantische Schicht. „Wie viele Neukunden?“ braucht sie.
- Ergebnis wird ohnehin geprüft
- Wenn eine Fachperson jede Zahl gegenprüft, ist ein Fehlbefund unangenehm, aber folgenlos. Wenn die Zahl in eine Entscheidung geht, nicht.
- Leserechte reichen als Schutz
- Ein lesender Datenbankbenutzer verhindert Veränderungen, aber nicht, dass eine Rolle Daten sieht, die sie nicht sehen darf. Dafür braucht es Rechte auf fachlicher Ebene.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Ist ein Abfrageplan am Ende nicht auch nur generiertes SQL?
Die ausgeführte Abfrage ist SQL – erzeugt wird sie aber nicht vom Sprachmodell, sondern vom System aus einem geprüften Plan. Der Unterschied liegt darin, was geprüft werden kann: Ein Plan besteht aus Begriffen, Beziehungen und Regeln des semantischen Modells, und genau die sind gegen das Modell abgleichbar.
Freies SQL lässt sich nur auf Syntax und Leserechte prüfen. Ob es fachlich die gestellte Frage beantwortet, kann niemand prüfen, ohne die Fachlichkeit zu kennen – und dann bräuchte man die Abfrage nicht.
- Können wir Text-to-SQL nicht mit Beispielabfragen gut genug machen?
Für einen festen Kreis von Fragen ja. Sobald die Fragen offen sind, verschiebt sich das Problem nur: Sie pflegen dann Beispiele statt Definitionen, und ein Beispiel deckt genau seine Frage ab.
Eine beschriebene Regel deckt jede Frage ab, in der der Begriff vorkommt. Das ist derselbe Aufwand mit anderer Reichweite – und der Unterschied wächst mit der Zahl der Fragen.
- Was ist mit Schema-Linking oder RAG über die Schemabeschreibung?
Diese Verfahren lösen das Auffinden der richtigen Tabellen und Spalten und sind dafür wirksam. Sie lösen nicht, was in der Schemabeschreibung nicht steht.
Wenn nirgends beschrieben ist, dass ein Datenbereich Historie enthält oder dass „offen“ drei Bedingungen hat, kann kein Abrufverfahren diese Information finden. Sie muss vorher aufgeschrieben werden – und genau das ist die semantische Schicht.
- Wie viel mehr Aufwand ist das gegenüber einem SQL-generierenden Werkzeug?
Beim Einstieg mehr, danach weniger. Ein SQL-generierendes Werkzeug ist an einem Tag angebunden; die semantische Schicht entsteht KI-gestützt aus Sourcecode und Datenmodell und steht in Grundzügen innerhalb weniger Stunden, braucht danach aber fachliche Validierung.
Der Unterschied zeigt sich im Betrieb: Beim generierenden Werkzeug bleibt die Prüfung jeder Antwort dauerhaft Handarbeit. Bei der semantischen Schicht ist jede geprüfte Regel dauerhaft erledigt.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
Datenbank mit KI abfragen
Der Weg einer Frage bis zur belegten Zahl – und warum geprüft wird, bevor gelesen wird.
Semantische Schicht
Was in der Schicht beschrieben ist, wie sie entsteht und warum ein Prompt sie nicht ersetzt.
Sicherer KI-Datenbank
Warum das Sprachmodell keine Zugangsdaten erhält und die Grenze in der Architektur liegt.
Conversational BI
Auswertungen im Dialog statt im Report – und was mit dem vorhandenen BI-Werkzeug passiert.
Nennen Sie uns zwei Fragen, an denen Ihr Text-to-SQL-Versuch gescheitert ist. Daran lässt sich der Unterschied am schnellsten zeigen.