Mit Ihrer SQL-Datenbank sprechen: Text-to-SQL-Automatisierung in der Praxis

Warum Text-to-SQL für datengetriebene Organisationen relevant ist

In den letzten Jahren haben sich die Fähigkeiten großer Sprachmodelle (Large Language Models, LLMs) kontinuierlich weiterentwickelt, und ihre Anwendungsbereiche haben sich stetig erweitert. Diese Vielseitigkeit wurde durch das Fine-Tuning großer Foundation-Modelle auf spezifische Aufgaben (z. B. Instruktionsbefolgung) oder Domänen (z. B. juristische Texte) erreicht. Diese Modelle zeigen eine hervorragende Leistungsfähigkeit bei der Erzeugung strukturierter Ausgaben wie Code, JSON oder SQL. Der Fokus dieses Artikels liegt auf einem praxisnahen Business-Beispiel im Kontext von Text-to-SQL.

In modernen Organisationen werden große Mengen an geschäftlichen und proprietären Daten in relationalen Datenbanken gespeichert, deren effizienter Zugriff häufig geschultes Personal sowie ein gutes Verständnis von Datenstrukturen und Datenmanagementprinzipien erfordert. Viele Mitarbeitende, die mit diesen Daten arbeiten müssen, verfügen jedoch nicht über ausreichende SQL-Kenntnisse, was eine effiziente Datennutzung erschwert. Ein typisches Szenario aus der Praxis könnte wie folgt aussehen: Die Marketingabteilung eines Unternehmens benötigt die Verkaufszahlen von Produkt A aus dem vergangenen Jahr für alle Niederlassungen in Hamburg und Berlin.

Genau an diesem Punkt setzen Text-to-SQL-Systeme an, indem sie die Lücke zwischen in natürlicher Sprache formulierten Anfragen und der Extraktion von Informationen aus relationalen Datenbanken schließen. Die Qualität, die heutige LLMs erreichen, macht die Generierung von SQL zu einem verlässlichen Prozess (siehe beispielsweise Referenz [1] als aktuelle Übersicht). In den beschriebenen Geschäftskontexten sehen wir daher eine hohe Relevanz für Text-to-SQL-Systeme, die einerseits eine benutzerfreundliche Oberfläche mit natürlichen Spracheigenschaften kombinieren und gleichzeitig den Zugriff auf eine Vielzahl bestehender Datenbanken ermöglichen, darunter Data Warehouses oder Data Marts.

In diesem Blogbeitrag fassen wir unsere Erkenntnisse aus der Entwicklung und dem Testen eines standardisierten Text-to-SQL-Anwendungsfalls auf Basis einer Verkaufsdatenbank zusammen. Wir beschreiben die Bausteine, aus denen das Gesamtsystem besteht, gehen vertieft auf das entsprechende Prompt Engineering ein und skizzieren einen typischen Konversationsablauf. Dabei hat sich gezeigt, dass der Einsatz eines leistungsfähigen LLMs in der Nutzeranwendung zur SQL-Generierung eine Interaktion mit der Datenbank auf verschiedenen Ebenen ermöglicht:

Interaktionsebenen in LLM-basierten Text-to-SQL-Systemen

Direkte Interaktion mit Datenbankschema und Rohdaten

L0: Die unmittelbare Ebene.
Die Nutzeranfrage bezieht sich auf Fragen zum Datenbankschema oder zu rohen Tabelleninhalten. Beispiele sind:
„Zeige mir das aktuelle Datenbankschema“ oder „Gib alle Werte der Spalte ‚brand‘ zurück“.

Abfragen in natürlicher Sprache und SQL-Generierung

L1: Die Abfrageebene.
Dies ist die Konversationsebene, die für Anwendungsfälle besonders relevant ist, bei denen konkrete Informationsabfragen auf Basis des Schemas gestellt werden. Ein Beispiel:
„Zeige mir alle Produktnamen in der Kategorie ‚Kosmetik‘, die Kunden aus Hamburg im letzten Monat gekauft haben.“

Durch die Kombination von Informationen aus dem Datenbankschema mit den Abfragebegriffen ist das LLM in der Lage, die entsprechende SQL-Anweisung zu generieren, die anschließend von einem Orchestrator an die Abfrage-Engine weitergeleitet wird. In der resultierenden Abfragezeichenkette unseres Produkt-A-Beispiels werden unter anderem die Tabellen und Spalten ‚customer‘, ‚category‘, ‚product.name‘, ‚customer.address‘ und ‚sales.date‘ zusammen mit den erforderlichen Joins und Quantifizierungen adressiert.

Kontextbewusste und referenzielle Abfragen

L2: Die referenzielle Ebene.
Ein zentraler Vorteil des konversationellen Gedächtnisses liegt in der Möglichkeit, frühere Abfragen einfach zu referenzieren, sodass die gesamte Anfrage nicht erneut eingegeben werden muss, wenn nur geringfügige Anpassungen erforderlich sind. Kehren wir zu dem obigen Beispiel zurück: Die gleichen Informationen bezüglich Kategorie und Zeitraum werden benötigt, diesmal jedoch für die Niederlassung in Berlin. Die Eingabe „Wiederhole die letzte Abfrage für unsere Berliner Niederlassung“ genügt.

Abhängig von der Länge des Konversationsfensters und der Komplexität der Abfragen ist eine Interaktion mit der Datenbank auf SQL-Ebene in Dialogform möglich.

Kommunikation vom Typ L2 findet auch dann statt, wenn Nutzende Feedback geben, um generierten SQL-Code zu steuern oder zu korrigieren. Durch die Berücksichtigung verschiedener Datenbankdialekte kann sich das LLM gut an die Besonderheiten eines Datenbanksystems anpassen, dennoch können Fehler im Generierungsprozess auftreten. Sobald ein Problem durch strikte Syntax- und Formatprüfungen erkannt wird, kann ein Korrektur-Prompt bereitgestellt und durch eine Linter-Ausgabe ergänzt werden, etwa:
„In deiner letzten Abfrage liegt folgendes Problem vor: <Linter-Ausgabe>. Versuche, es zu korrigieren.“

Dieser Ansatz hat in den seltenen Fällen, in denen Syntax- oder Formatierungsprobleme auftraten, gut funktioniert. In einer produktiven Umgebung sollten Nutzende jedoch nicht mit der Wiedergabe von SQL-Korrekturen konfrontiert werden. Während der Entwicklungsphase half jedoch eine sorgfältige Analyse der Linter-Ausgaben dabei, den System-Prompt, die Schema-Linking-Strategie und die Postprocessing-Schritte zu verfeinern. Bei komplexeren Datenbankschemata oder hochkomplexen Abfragen wird diesen Aspekten eine noch größere Bedeutung zukommen.

Zusammenfassend lässt sich sagen, dass durch den Einsatz leistungsfähiger LLMs in SQL-getriebenen Geschäftsanwendungen Informationen über Text-to-SQL-Systeme leicht zugänglich werden und dadurch eine effiziente Erkenntnisgewinnung, eine höhere Datenautonomie sowie eine bessere Ressourcennutzung ermöglicht wird.

Rahmenbedingungen und Workflow unseres Demonstrationsfalls

Unser Ziel ist es zu zeigen, wie ein robuster und erweiterbarer Text-to-SQL-Workflow aufgebaut werden kann – beginnend bei einer Nutzeranfrage über die SQL-Generierung und -Validierung bis hin zur Bereitstellung der entsprechenden Datenbankergebnisse. In realen Kundenprojekten gelten dabei in der Regel folgende Rahmenbedingungen:

• Das LLM wird über eine API angesprochen; weder Self-Hosting noch Fine-Tuning werden in Betracht gezogen. Kundinnen und Kunden verfügen in der Regel nicht über die notwendige Hardware, um Modelle weiter zu verfeinern, und möchten schnell produktiv werden.
• Für eine beliebige Kundendatenbank stehen uns keine Goldstandards oder Ground Truths zur Verfügung. Dies bedeutet, dass zu Beginn keine allgemeinen Validierungen auf Basis von Kennzahlen wie Execution Accuracy (EXE), Exact Set Matching Accuracy (ESM) oder anderen Metriken durchgeführt werden (siehe Referenz [2] für eine detaillierte Analyse dieser Qualitätsmetriken). Validierungen können zu einem späteren Zeitpunkt erfolgen, wenn die Notwendigkeit besteht, Referenz-SQL-Abfragen und -Daten zu generieren. Wir ermöglichen spätere Tests, indem für jede Nutzeranfrage ein abstrakter Syntaxbaum (AST) aus der SQL-Abfrage sowie entsprechende Referenzdaten aus der Kundendatenbank erzeugt werden.

Die folgende Abbildung skizziert den Workflow.

End-to-End-Workflow von der natürlichen Sprachabfrage bis zur validierten SQL-Ausführung

Der Nutzer auf der linken Seite der Abbildung interagiert kontinuierlich mit dem System über ein Dialogfenster, in das Prompts eingegeben und Ergebnisse zurückgespielt werden. Das konversationelle Gedächtnis verfolgt sowohl die Nutzeranfragen als auch die generierten SQL-Abfragen, sodass eine Konversation auf L2-Ebene möglich ist. Bei jeder Abfrage erhält das LLM den System-Prompt zusammen mit dem bisherigen Gesprächsverlauf. Spezifische Informationen wie Datenbankschema, Datenbanktyp und SQL-Dialekt werden beim Systemstart in den System-Prompt eingefügt. In unserer Implementierung werden Validierungsmeldungen der Syntaxprüfer und Linter ebenfalls zu Kontroll- und Debugging-Zwecken zurückgespielt. Sobald die SQL-Abfrage alle Prüfungen bestanden hat, werden der AST und die abgerufenen Daten gespeichert, um eine zusätzliche Verifikation mit einem kundenseitigen Goldstandard zu ermöglichen.

Nach längeren Konversationen ist es empfehlenswert, das konversationelle Gedächtnis zu leeren, um mögliche Verzerrungen zu vermeiden, die sich in einer Kette von Abfragen aufgebaut haben könnten. Da die Kontextlängen begrenzt sind, verwenden wir ein Konversationsfenster mit einer Länge von 20. Für unsere Demonstration des Geschäftsanwendungsfalls kamen folgende Komponenten zum Einsatz:

• Chainlit als UI und Orchestrator
• GPT-4o-mini als generierendes LLM
• Dockerisierter MS SQL Server als SQL-Engine inklusive notwendiger Datenbanktreiber
• Microsoft-Contoso-Datensatz als Ausgangspunkt mit anonymisierten, realistischen Kundendaten
• SQLglot als strikter, SQL-dialektbewusster Syntaxprüfer und AST-Generator
• SQLFluff als leistungsfähiger, SQL-dialektbewusster Linter zur Erkennung von Formatierungsproblemen und weiteren versteckten Fehlern, selbst in syntaktisch korrekten SQL-Anweisungen

Prompt Engineering für zuverlässige SQL-Generierung

Wie bereits erwähnt, ist das Fine-Tuning eines Modells nicht zielführend, wenn es darum geht, schnell in den produktiven Einsatz zu gelangen. Aufgrund der Fähigkeiten heutiger LLMs lässt sich das Modell vielmehr durch durchdachtes Prompt Engineering steuern, das einigen grundlegenden Prinzipien folgt, die im Kontext der SQL-Generierung relevant sind. Wie in [1] beschrieben, lässt sich Prompt Engineering in drei Phasen unterteilen: Preprocessing, Inference und Postprocessing. Beim Aufbau unseres System-Prompts zur Erzielung hoher SQL-Qualität orientieren wir uns weitgehend an diesen Prinzipien, auch wenn einige der in [1] beschriebenen Aspekte auf unseren produktiven Anwendungsfall nicht zutreffen. Im Folgenden skizzieren wir unsere Konstruktionsprinzipien für den LLM-System-Prompt.

Preprocessing: Regeln, Schema-Linking und strukturierte Ausgaben

• In der Preprocessing-Phase werden im Prompt Hinweise auf die erwartete Abfragestruktur oder Beschreibungen ihrer abstrakten Repräsentation platziert. Darauf verzichten wir bewusst und listen stattdessen eine Reihe von Regeln auf, die vom Generator einzuhalten sind, um aus natürlicher Sprache qualitativ hochwertige SQL-Abfragen zu erzeugen. Darüber hinaus fordern wir die Ausgabe in strukturierter Form an, um Einblicke in den Erstellungsprozess selbst zu erhalten. Zu diesem Zweck stellen wir eine Beispiel-JSON-Datei bereit, die vom LLM bei jeder Antwortgenerierung verwendet werden soll. Die Vorlage der JSON-Struktur lautet wie folgt; die Platzhalter werden vom LLM ausgefüllt:

Beispiel für LLM-generierte Metadaten zur SQL-Erzeugung

• Der zweite Bestandteil des Preprocessings ist das Schema-Linking. Beim Systemstart fragen wir das Datenbankschema ab und fügen es nach Korrektur von Leerzeichen und einer gewissen Formatierung in die Prompt-Vorlage ein. Es ist empfehlenswert, dem LLM die einzelnen Komponenten des Schemas hinsichtlich ihrer Funktion (Tabelle oder Spalte) und ihres Datentyps zu erläutern. Wir haben festgestellt, dass eine weitergehende Ausarbeitung des Datenbankschemas nicht erforderlich war, um gute Ergebnisse zu erzielen, wobei unsere Untersuchung nicht als vollständig zu betrachten ist. Fortgeschrittene Aspekte aus der Literatur können ergänzt werden, sobald Defizite in den generierten SQL-Abfragen beobachtet werden. Wir vertreten die Auffassung, dass ein angemessenes Vertrauen in die Fähigkeiten des LLMs das Risiko reduziert, den System-Prompt mit zahlreichen fein granularen Regeln zu überladen, was andernfalls zu unerwünschten Nebenwirkungen führen könnte.

Inference: Steuerung der SQL-Generierung

• In der Inference-Phase werden Chain-of-Thought-(CoT-) und dekompositionale Workflows in der Literatur als bewährte Methoden genannt, um das LLM durch den Schritt der SQL-Generierung zu führen. Wie bereits erwähnt, haben wir eine Liste von Regeln definiert, die während des Konstruktionsprozesses zu beachten oder zu vermeiden sind. Ein gutes Regelwerk entsteht, indem der Generierungsprozess zunächst völlig unbeschränkt gestartet und die Ergebnisse für eine Vielzahl von Abfragen sorgfältig analysiert werden. Auf diese Weise lassen sich häufige Fehler und wiederkehrende Fallstricke identifizieren und vermeiden. Dieses Vorgehen ist nicht strikt identisch mit einem Chain-of-Thought-Prozess, weist jedoch Überschneidungen auf. Aufwendigere CoT- oder Dekompositionsverfahren könnten relevant werden, sobald die Abfragen in Kombination mit großen Datenbanken an Komplexität gewinnen.

Postprocessing: Fehlerbehandlung, Konsistenz und Kostenkontrolle

• In der Postprocessing-Phase stehen Selbstkorrektur und Konsistenz im Vordergrund. Durch die Analyse semantischer und formatbezogener Probleme, die von SQLFluff identifiziert wurden, konnten wir Leitplanken definieren, die in den System-Prompt integriert wurden. In einigen Systemen werden Selbstkorrekturschleifen im Hintergrund automatisch ausgeführt, bis die SQL-Korrektheit erreicht ist. Aufgrund der damit verbundenen Kosten durch mehrere LLM-Aufrufe haben wir diesen Ansatz nicht implementiert. Stattdessen geben wir in der aktuellen Implementierung auftretende Probleme direkt an die Nutzenden weiter und ermöglichen so L2-Korrektur-Prompts. Durch die wiederholte Offenlegung von Problemen konnten wir das Regelwerk kontinuierlich verbessern und den System-Prompt offline weiter verhärten. Während einer aktiven Konversation kann sich das LLM Probleme merken, sobald es einen Korrektur-Prompt erhalten hat, und Fehler im weiteren Verlauf des Informationsabrufs vermeiden. Ein weiterer vielversprechender Ansatz, den wir künftig verfolgen wollen, ist die in [3] beschriebene Self-Consistency-Methode. Dabei werden aus einer Anfrage in natürlicher Sprache mehrere SQL-Zeichenketten generiert, indem im LLM-Aufruf eine Temperatur T > 0 gesetzt wird. Die Menge der SQL-Zeichenketten wird anschließend vom LLM bewertet, und die am höchsten bewertete Abfrage wird an die Query-Engine weitergeleitet. Dieser Ansatz verursacht ebenfalls höhere Kosten aufgrund mehrerer LLM-Inferenzaufrufe. Für komplexere Szenarien hat sich Self-Consistency in der Praxis als sehr effektiv erwiesen, sollte jedoch stets mit einer sorgfältigen Kostenüberwachung einhergehen.

Veranschaulichung einer Nutzer-/Systeminteraktion anhand von Contoso-Daten

L0-Konversation zum Kennenlernen der Datenbank

Wie oben beschrieben, bezieht sich Ebene 0 auf Abfragen, die direkt die Datenbankstruktur oder rohe Tabelleninhalte betreffen und manchmal notwendig sind, um spezifische Details der Datenbank offenzulegen.

Direkte Schemaabfrage ohne fachliche Datenfilterung

Durch die Aufrechterhaltung des Konversationsverlaufs ist eine kurze Folgefrage möglich, die intern automatisch zur erweiterten Abfrage führt (die Ausgabereihenfolge der Tupel ist dabei beliebig).

Erweiterung einer bestehenden Schemaabfrage durch Konversationskontext

L1-/L2-Abfragen in einem realen Anwendungsszenario

Als Beispiel für eine reale Abfrage möchten wir Kunden ermitteln, die in einer bestimmten Filiale innerhalb eines bestimmten Zeitraums einen Kauf getätigt haben.

Übersetzung einer fachlichen Fragestellung in eine SQL-Abfrage

Nun wollen wir eine Folgeabfrage ausführen, um die Kunden für die Filiale in Hamburg zu finden, wobei angenommen wird, dass das LLM die fehlenden Informationen aus dem Konversationsgedächtnis ableiten kann.

Kontextbasierte Folgeabfrage mit semantischem SQL-Fehler

Interessanterweise wurde hierbei ein Fehler in der erzeugten Abfrage beobachtet (trotz syntaktischer Korrektheit), der darauf zurückzuführen ist, dass angenommen wurde, die Tabelle „Store“ verfüge über die Spalte „City“, was tatsächlich nicht der Fall ist. Hier konkurriert das interne Weltwissen des LLMs – mit hoher Wahrscheinlichkeit die Annahme, dass „Hamburg“ eine Stadt ist – mit den im Schema hinterlegten Informationen, dass keine Spalte „City“ in der Tabelle „Store“ existiert. Aus Sicht der Datenbank erscheint es etwas inkonsistent, Datenpunkte zu „Hamburg“ in der Spalte „Store.State“ zu speichern. Streng genommen ist „Hamburg“ jedoch ein Stadtstaat in Deutschland, was diese Modellierung rechtfertigen kann.

Nachdem das Problem lokalisiert wurde, können wir durch eine explizite Klarstellung, dass „Hamburg“ ein Filialstaat und keine Filialstadt ist, in einer L2-Konversation unmittelbar korrekte Ergebnisse erzeugen (beachten Sie das Auftreten deutsch klingender Kundennamen in den Datenbankergebnissen, was auf die Korrektheit der Daten hinweist).

Fehlerkorrektur einer kontextbasierten SQL-Abfrage durch Nutzerfeedback

Zusammenfassend sind die gezeigten Beispiele nicht sehr komplex, zeigen jedoch, dass eine Interaktion mit einer SQL-Datenbank in natürlicher Sprache innerhalb kurzer Zeit ohne gravierende Hindernisse realisiert werden kann. Intern haben wir zudem erfolgreiche Benchmarks mit komplexeren Abfragen durchgeführt, bei denen beispielsweise verschachtelte SELECTs aus anspruchsvolleren Anfragen in natürlicher Sprache generiert wurden.

Zentrale Erkenntnisse für produktionsreife Text-to-SQL-Systeme

• Die Prompt-Struktur beeinflusst die SQL-Qualität maßgeblich.
  Die Einhaltung etablierter Prompting-Regeln aus der Literatur hat einen erheblichen Einfluss auf die Korrektheit und Vollständigkeit der generierten SQL-Anweisungen. Um für das LLM möglichst verständlich zu sein, sollte das Datenbankschema in strukturierter Form bereitgestellt werden. Es ist hilfreich, aber nicht zwingend erforderlich, strukturierte Beispiele für Abfragen bereitzustellen; weitere Anforderungen können in natürlicher Sprache formuliert werden. Wird eine strukturierte JSON-Ausgabe benötigt, ist die Bereitstellung eines Beispiel-JSONs notwendig, um die erwarteten Schlüssel-Wert-Paare zu definieren.
• Syntax-Validierungswerkzeuge sind unverzichtbar.
  Bei unpräzisen Nutzeranfragen kann es vorkommen, dass syntaktisch inkorrekter oder qualitativ minderwertiger SQL-Code generiert wird. In solchen Fällen sind Syntax-, Semantik- und Formatprüfungen erforderlich. Wird eine Automatisierung durch Selbstkorrektur angestrebt, werden syntaktisch fehlerhafte SQL-Anweisungen vom LLM zusammen mit ihrer Fehlerbeschreibung wiederholt, bis die Validierung erfolgreich ist. Eine Alternative stellt die Self-Consistency-Methode dar, bei der mehrere SQL-Zeichenketten bewertet werden.
• Konversationeller Kontext vereinfacht die Interaktion und erhöht die Korrektheit.
  Der Kontext ermöglicht es Nutzenden, auf frühere Abfragen zu verweisen, komplexe SQL-Generierungen mit geringfügigen Änderungen zu wiederholen und unterstützt die Fehlererkennung und -korrektur sowohl während der Entwicklung als auch im laufenden Betrieb.
• Software-Engineering-Disziplin zahlt sich auch in GenAI-Projekten aus.
  Selbst in LLM-getriebenen Anwendungen unterstützt sauberes Engineering die Skalierbarkeit, Anpassungsfähigkeit und langfristige Wartbarkeit.

Ausblick und nächste Schritte

Mit Blick auf die Zukunft planen wir:

• die Einbindung von Open-Source-Modellen und die Evaluierung ihrer Text-to-SQL-Fähigkeiten in Kombination mit beliebigen Kundendatenbanken zur Kostensenkung
• den Einsatz eines Frameworks wie vLLM (https://docs.vllm.ai/en/v0.6.2/) für das Self-Hosting geeigneter Modelle ausreichender Qualität in Kundensystemen, was im Hinblick auf Datenschutz und Datensouveränität zunehmend an Bedeutung gewinnt
• die Erweiterung der Schema-Linking- und Postprocessing-Ansätze, um noch größere und strukturell unterschiedliche Datenspeicher zu unterstützen, etwa Star-Schemata, Snowflake-Schemata oder Data Vaults mit Hubs, Links und Satelliten
• die Unterstützung von Szenarien mit mehreren Datenbanken, was einen höheren Aufwand im Preprocessing und eine dynamische Schema-Generierung erfordert, um das LLM auf die tatsächliche Abfragestruktur fokussiert zu halten
• die Anpassung des Dienstes, sodass er nahtlos in ein MCP-(Model Context Protocol-)Setting integriert werden kann

Fazit

Unser Text-to-SQL-Beispielprojekt zeigt, dass Abfragen in natürlicher Sprache in Kombination mit soliden Engineering-Prinzipien praktikabel und zuverlässig umgesetzt werden können. Es schlägt die Brücke zwischen menschlicher Intention und strukturierten Daten und ermöglicht es Organisationen, den vollen Wert ihrer Datenbanken über konversationelle Schnittstellen zu erschließen.

Referenzen

[1] L. Shi et al., A Survey on Employing Large Language Models for Text-to-SQL Tasks, arXiv:2407.15186 (2025).
[2] B. Ascoli et al., ETM: Modern Insights into Perspective on Text-to-SQL Evaluation in the Age of Large Language Models, arXiv:2407.07313 (2025).
[3] X. Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, arXiv:2203.11171 (2022).