Text-to-SQL: Datenbanken in natürlicher Sprache abfragen

Die Umsatzzahlen für Region Süd, aufgeschlüsselt nach Quartal und Produktlinie, nur für Kunden mit mehr als drei Bestellungen. Wer diese Frage heute beantworten will, schreibt entweder selbst SQL oder wartet, bis jemand aus dem BI-Team Zeit hat. Beides kostet. Text-to-SQL verändert diese Rechnung: Ein KI-Modell übersetzt die Frage in natürlicher Sprache direkt in eine Datenbankabfrage, führt sie aus und liefert das Ergebnis. Und das Entscheidende für Unternehmen mit sensiblen Daten: Dieses Modell läuft im eigenen Rechenzentrum, nicht bei einem Cloud-Anbieter.

Warum natürliche Sprache an der Datenbank zählt

In den meisten Unternehmen sitzt das Wissen in relationalen Datenbanken. ERP, CRM, Warenwirtschaft, Ticketsystem – strukturierte Daten, sauber in Tabellen. Nur kommt kaum jemand direkt daran. Die Fachabteilung formuliert eine Frage, reicht sie an die IT oder das Reporting weiter, und ein paar Tage später liegt ein Export im Postfach. Jede neue Frage startet die Warteschleife erneut.

Text-to-SQL kürzt diesen Weg ab. Die Vertriebsleiterin tippt ihre Frage so, wie sie sie einem Kollegen stellen würde. Das Modell kennt das Datenbankschema, wählt die richtigen Tabellen, verknüpft sie über die passenden Schlüssel und baut eine gültige SQL-Abfrage. Der Mensch bleibt im Spiel: Er sieht die erzeugte Abfrage, prüft sie bei Bedarf und führt sie aus. Niemand muss JOIN-Syntax lernen.

Der Gewinn liegt nicht nur im Tempo. Er liegt im Zugang. Fragen, die vorher nie gestellt wurden, weil der Aufwand zu groß schien, landen plötzlich im Alltag. Ein Lagerleiter prüft morgens selbst, welche Artikel unter den Meldebestand gerutscht sind. Das schafft eine Kultur, in der Entscheidungen auf Zahlen fußen statt auf Bauchgefühl.

Wie die Übersetzung technisch funktioniert

Ein Sprachmodell kennt Ihre Tabellen nicht von Haus aus. Deshalb bekommt es den Kontext mitgeliefert: Tabellennamen, Spalten, Datentypen, Fremdschlüssel-Beziehungen. Bei kleinen Datenbanken passt das komplette Schema in den Prompt. Bei hunderten Tabellen wird vorab gefiltert – ein Retrieval-Schritt sucht die wenigen Tabellen heraus, die zur Frage passen, und nur die landen im Kontext.

Gute Systeme hören beim reinen Schema nicht auf. Sie reichern den Kontext an: kurze Beschreibungen pro Spalte, Beispielwerte, ein paar erprobte Frage-Abfrage-Paare aus der eigenen Domäne. Dass die Spalte status die Werte ‚A‘, ‚S‘ und ‚G‘ enthält und nicht ‚aktiv‘, ’storniert‘, ‚geliefert‘, muss das Modell irgendwoher wissen. Diese Hinweise entscheiden oft über Erfolg oder Fehlschlag.

Nach der Generierung kommt die Prüfung. Die erzeugte Abfrage läuft gegen den Parser der Datenbank, bevor ein Mensch sie zu sehen bekommt. Schlägt sie fehl, geht die Fehlermeldung zurück an das Modell, das korrigiert und erneut liefert. Zwei, drei solcher Schleifen fangen die meisten Syntaxfehler ab, ohne dass der Nutzer etwas davon merkt.

On-premise statt Cloud: der eigentliche Hebel

Text-to-SQL berührt den Kern Ihrer Daten. Die Abfrage selbst verrät schon viel über Struktur und Geschäft, das Ergebnis erst recht. Schickt ein Unternehmen diese Fragen an eine externe API, verlassen Metadaten und oft genug echte Zahlen das Haus. Für Finanzdaten, Personaldaten oder Patientendaten ist das selten eine Option.

Ein selbst gehostetes Modell dreht das um. Ein offenes Modell wie Qwen oder ein spezialisiertes Code-Modell läuft auf eigener GPU-Hardware, direkt neben der Datenbank. Keine Zeile Schema, keine einzige Zahl verlässt das Netzwerk. Für viele Branchen ist das keine Kür, sondern Pflicht – die DSGVO und branchenspezifische Vorgaben lassen wenig Spielraum.

Der Aufwand hält sich in Grenzen. Für Text-to-SQL braucht es kein Modell mit hunderten Milliarden Parametern. Modelle mittlerer Größe, auf Code und SQL trainiert, lösen die Aufgabe zuverlässig und laufen auf überschaubarer Hardware. Ein Inferenz-Server wie vLLM bündelt Anfragen effizient, sodass mehrere Fachabteilungen parallel arbeiten, ohne dass die Antwortzeiten einbrechen.

Wo die Fallstricke liegen

Ein generiertes SQL, das sauber durchläuft, ist nicht automatisch richtig. Die gefährlichste Fehlerklasse sieht korrekt aus, zählt aber das Falsche. Das Modell verwechselt zwei ähnlich benannte Spalten, vergisst einen Filter auf stornierte Aufträge oder summiert über die falsche Granularität. Das Ergebnis wirkt plausibel – und führt in die Irre.

Deshalb gehört die Validierung ins Zentrum, nicht an den Rand. Zeigen Sie die erzeugte Abfrage transparent an. Lassen Sie das System erklären, welche Tabellen es warum gewählt hat. Bei kritischen Kennzahlen hinterlegen Sie geprüfte Vorlagen, auf die das Modell zurückgreift, statt jede Abfrage neu zu erfinden. Vertrauen entsteht, wenn Nutzer nachvollziehen, wie eine Zahl zustande kam.

Und dann sind da die Rechte. Ein Text-to-SQL-System darf nur sehen, was der fragende Mensch sehen darf. Technisch heißt das: Das System arbeitet mit einem Datenbankkonto, das die Berechtigungen des Nutzers spiegelt, und bekommt ausschließlich lesenden Zugriff. Ein Modell, das versehentlich eine DELETE-Abfrage baut, richtet sonst Schaden an. Read-only ist nicht verhandelbar.

Schritt für Schritt einführen

Fangen Sie klein an. Suchen Sie eine Abteilung mit klarem Schmerz – oft das Reporting, das unter Ad-hoc-Anfragen ächzt – und einen überschaubaren Datenbereich. Ein Dutzend Tabellen, ein konkreter Fragenkatalog. An diesem Ausschnitt messen Sie, wie oft das Modell richtig liegt, bevor Sie die Reichweite ausweiten.

Investieren Sie früh in die Dokumentation des Schemas. Jede gute Spaltenbeschreibung, jedes hinterlegte Beispiel zahlt direkt auf die Trefferquote ein. Diese Arbeit wirkt unspektakulär, entscheidet aber mehr über das Ergebnis als die Wahl des Modells. Sammeln Sie dabei die Fragen, die Nutzer tatsächlich stellen – sie sind das Trainingsmaterial für die nächste Ausbaustufe.

Behandeln Sie das System als Assistenten, nicht als Orakel. Es schlägt eine Abfrage vor, der Mensch entscheidet. Mit wachsender Trefferquote und geprüften Vorlagen wächst das Vertrauen, und der Prüfaufwand sinkt von selbst. So wird aus einem Experiment ein Werkzeug, das die Fachabteilung jeden Tag nutzt – ohne die IT bei jeder Frage zu belasten.

Fazit

Text-to-SQL holt die Daten dorthin, wo die Fragen entstehen: in die Fachabteilung. Selbst gehostet bleibt dabei jede Zahl im Haus, und die Kontrolle über Rechte und Validierung bleibt bei Ihnen. Der Weg führt nicht über das größte Modell, sondern über sauber dokumentierte Daten, strikte Leserechte und eine Einführung in kleinen Schritten.

Sie möchten prüfen, wie sich natürliche Sprachabfragen und selbst gehostete KI in Ihre bestehende Datenlandschaft einfügen? Sprechen Sie mit dem Team von AI-Designers – wir begleiten Unternehmen von der ersten Machbarkeitsprüfung bis zum produktiven Betrieb eigener KI-Lösungen.

Bilder: AI-Designed