Text-to-SQL

Text-to-SQL übersetzt eine Frage in Alltagssprache automatisch in eine SQL-Abfrage (Structured Query Language, die Standardsprache für Datenbank-Abfragen), die gegen eine bekannte Datenbank läuft. Moderne Umsetzungen kombinieren ein Sprachmodell (Large Language Model, ähnlich wie ChatGPT) mit einem Schema-Kontext, also einer kuratierten Beschreibung der verfügbaren Tabellen, Kennzahlen und Beispielabfragen. Sie sind die technische Grundlage sprachgesteuerter Analytics-Assistenten wie Databricks Genie, Snowflake Cortex Analyst oder Uber QueryGPT.

Was ist Text-to-SQL?

Text-to-SQL ist eine spezielle Aufgabe der maschinellen Sprachverarbeitung: Eingabe ist eine Frage in natürlicher Sprache plus eine Beschreibung der Datenbank (Tabellen, Spalten, Beziehungen), Ausgabe ist eine ausführbare SQL-Abfrage, die die Frage inhaltlich trifft und auf der konkreten Datenbank läuft, sei es ein Data Warehouse (klassisches Analyse-System wie Snowflake) oder ein Lakehouse (moderne Kombination aus Data Lake und Warehouse wie Databricks). Der Begriff stammt aus der akademischen NLP-Forschung (Natural Language Processing, computerlinguistische Sprachverarbeitung), ist aber seit 2023 vor allem als Baustein produktiver Analytics-Assistenten relevant.

Klassische Ansätze von etwa 2016 bis 2022 nutzten Sequence-to-Sequence-Modelle auf annotierten Benchmarks wie [Spider](https://arxiv.org/abs/1809.08887) und WikiSQL, häufig mit Grammar-based Decoding, das nur syntaktisch gültige SQL zulässt. Die Ergebnisse waren auf den Benchmark-Schemas stark, der Transfer auf reale Unternehmens-Schemas mit vielen Tabellen und Business-Vokabular blieb schwach. Mit den Foundation Models ab 2023 hat sich die Architektur verschoben: Ein Sprachmodell bekommt als Prompt-Kontext die relevanten Tabellen-DDLs, Spalten-Beschreibungen, Kennzahl-Definitionen und einige Beispiel-Abfragen und erzeugt SQL im gewünschten Dialekt (Spark SQL, Snowflake SQL, ANSI SQL, BigQuery Standard SQL). Retrieval-Augmented Generation wählt dabei aus einem Katalog nur die für die Frage relevanten Tabellen und Beispiele aus, weil ein Enterprise-Schema mit Tausenden Tabellen jeden Kontext sprengt.

Eine produktive Text-to-SQL-Pipeline besteht typischerweise aus fünf Bausteinen. Schema-Retrieval wählt aus einem Datenkatalog (Unity Catalog, Snowflake, Genie Space, dbt-Metadaten) die relevanten Tabellen und Views für die Anfrage. Die Semantic-Layer-Anbindung liefert die Definitionen für Kennzahlen und Business-Vokabular („Umsatz meint Netto ohne Retouren"), entweder als Instructions im Prompt oder als abfragebares Metriken-Modell (dbt Semantic Layer, Databricks Genie Ontology, Cube.dev, AtScale). Few-Shot-Beispiele oder Trusted Queries zeigen dem Modell typische Formulierungen und den erwarteten SQL-Dialekt. Die Ausführung und Validierung setzt die generierte Abfrage gegen das Warehouse ab; Syntaxfehler und unbekannte Spalten fließen als Feedback in eine Self-Correction-Runde zurück. Die Governance-Klammer wirkt transitiv über das Warehouse: Row-Level Security, Column Masking und Rollen-Berechtigungen filtern die Ergebnisse pro Nutzer; der Text-to-SQL-Layer erweitert die Rechte nicht.

Etablierte Produktumsetzungen folgen diesem Muster mit unterschiedlicher Kuration. [Databricks Genie](https://docs.databricks.com/aws/en/genie/) bündelt Tabellen, Instructions, Trusted Queries und Ontologie in einem Genie Space und führt gegen ein Serverless SQL Warehouse mit Unity-Catalog-Governance aus. [Snowflake Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) nutzt ein semantisches Modell in YAML als Kontext. [Uber QueryGPT](https://www.uber.com/en-DE/blog/query-gpt/) arbeitet auf über 200.000 internen Tabellen mit einer Domänen-Klassifikation als Retrieval-Grundlage. Open-Source-Frameworks wie Vanna.ai, Dataherald, LangChain SQLDatabaseChain und LlamaIndex NLSQLTableQueryEngine bieten das RAG-Muster als Bibliothek.

Kern-Herausforderungen sind SQL-spezifisch: Schema-Verständnis bei vielen Tabellen mit kryptischen Namen, uneinheitliche Business-Semantik ohne kanonische SQL-Übersetzung, Ambiguität in unterspezifizierten Fragen („Kunden im letzten Monat"), halluzinierte Spalten- und Tabellennamen, Dialekt-Unterschiede zwischen Spark SQL, Snowflake SQL, BigQuery und Postgres sowie mangelhafte Datenqualität im Modell darunter. Der aktuelle Benchmark [BIRD-SQL](https://arxiv.org/abs/2305.03111) von 2023 misst Execution Accuracy auf realistischen Schemas mit Business-Fragen; führende Systeme liegen bei rund 70 bis 75 Prozent und damit deutlich unter dem Spider-Niveau von über 90 Prozent auf einfacheren Schemas.

Abgrenzung zu Semantic Layer, NLQ, Query Rewriting und Data Agent

Text-to-SQL wird häufig mit angrenzenden Konzepten vermischt, die entweder eine andere Schicht oder eine andere Aufgabe bezeichnen.

Die wichtigste Trennlinie verläuft zwischen Text-to-SQL und Semantic Layer. Der Semantic Layer definiert die rechenbare Bedeutung von Kennzahlen und Dimensionen, etwa ARR als Summe aktiver Abonnement-Verträge, Umsatz als Netto ohne Retouren oder aktiver Kunde als Kunde mit Bestellung in den letzten 90 Tagen. Text-to-SQL ist der Zugriffs-Layer darüber, der eine Nutzerfrage auf diese Definitionen abbildet und ausführt. Ohne Semantic Layer sind Text-to-SQL-Ergebnisse zwischen Anfragen inkonsistent, weil das Modell die Berechnung bei jedem Aufruf neu erfindet.

Gegenüber Natural Language Query ist Text-to-SQL die SQL-Untermenge. NLQ umfasst zusätzlich Text-to-Cypher (Graph-Datenbanken), Text-to-SPARQL (RDF), Text-to-KQL (Kusto) und Metadata-Search über Katalog-Metadaten ohne strukturierte Ausführung. Die Datenbank-Sprache bestimmt Dialekt und Retrieval-Modell, das Grundmuster bleibt ähnlich.

Query Rewriting arbeitet an einer anderen Stelle der Pipeline. Es formt die Nutzerfrage in eine oder mehrere Retrieval-Anfragen um, bevor der Retrieval-Schritt läuft. In einer Text-to-SQL-Pipeline kann Query Rewriting das Schema-Retrieval verbessern (mehr relevante Tabellen und Beispiele im Kontext) und die Frage entzerren (Pronomen auflösen, Follow-ups kondensieren). Die SQL-Generierung selbst ist der Schritt danach.

Ein Data Agent umfasst Text-to-SQL, geht aber darüber hinaus. Er entscheidet, welches Tool eine Anfrage bedient (SQL-Abfrage, Dokumenten-Suche, Python-Berechnung, Web-Recherche), stellt Rückfragen bei unterspezifizierten Fragen und plant mehrstufige Analysen (erst Umsatz aggregieren, dann Ausreißer identifizieren, dann Detail-Kunden ziehen). Databricks Genie Agents und Snowflake Snowflake Intelligence bewegen sich in Richtung Data Agent, indem sie Text-to-SQL mit Retrieval, Planning und Follow-up-Klärungen kombinieren.

Beispiel: Vertriebs-Assistent mit kuratiertem Schema-Kontext

Ein Handelsunternehmen betreibt einen internen Analytics-Assistenten für regional verantwortliche Nutzer. Die Datenbasis liegt im Lakehouse als kuratierter Gold-Layer mit Views wie gold.sales_by_region_group, dim_products und dim_time. Das Data-Team hinterlegt in einem Genie Space Instructions in natürlicher Sprache („Umsatz meint Netto-Umsatz ohne Retouren", „Warengruppe kommt aus dim_products.category_l1", „Region meint Vertriebsregion, nicht Länderkennzeichen"), Kennzahl-Definitionen aus der Genie Ontology und drei Trusted Queries als Few-Shot-Beispiele für typische Aggregationen.

Ein Nutzer fragt: „Wie hat sich der Umsatz der Warengruppe Outdoor in DACH im Q2 gegenüber Q1 entwickelt?". Der Text-to-SQL-Layer holt per Retrieval die drei relevanten Views mit ihren Spalten-Beschreibungen, die passenden Instructions und die Trusted Queries in den Prompt. Das Sprachmodell erzeugt eine Spark-SQL-Abfrage mit Filter auf Kategorie und Region, Aggregation je Quartal und einer Delta-Berechnung zwischen Q1 und Q2. Die Abfrage läuft auf einem Serverless SQL Warehouse; Unity-Catalog-Berechtigungen filtern die Ergebnisse pro Nutzer über Row-Level Security. Auf eine Rückfrage („Und nur Neukunden, ohne Retouren?") baut die Pipeline auf dem Chat-Kontext auf und ergänzt die WHERE-Klausel um die Kohorten-Filter.

Ohne diese Kuration erzeugt derselbe Layer generische SQL: falsche Tabelle (etwa eine Roh-Fakten-Tabelle statt der Gold-View), halluzinierte Spalten (region_dach statt sales_region = 'DACH') oder eine andere Umsatz-Definition (brutto statt netto). Die Genauigkeit steht und fällt mit dem Semantic Layer, den Instructions und den Trusted Queries; das Sprachmodell allein liefert sie nicht.