- Gemini-basierte Text-to-SQL-Funktionen werden in der gesamten Google Cloud eingesetzt, um die Produktivität von Entwicklerinnen und Entwicklern sowie nichttechnischen Nutzerinnen und Nutzern zu steigern
- In realen Umgebungen ist die präzise Generierung von SQL aufgrund von fehlendem Geschäftskontext, Schwierigkeiten bei der Interpretation der Nutzerabsicht und Unterschieden zwischen SQL-Dialekten schwierig
- Um das zu lösen, setzt Google unter anderem auf intelligente Datensuche, kontextbasiertes Lernen und semantische Schichten
- Grenzen des Modells selbst werden mit Verfahren wie Mehrfachgenerierung und optimaler Auswahl (self-consistency), erneuten Prompts nach Validierung und Training für einzelne SQL-Dialekte überwunden
- Bewertung und Messung von Verbesserungen umfassen eigene Benchmarks und Verfahren mit LLMs als Bewertungsinstanz, um die Einsetzbarkeit in realen Umgebungen zu erhöhen
Techniques for improving text-to-SQL
Vom Text zu SQL: der Stand bei Google Cloud
- Unternehmen nutzen SQL für schnelle und präzise Dateneinblicke
- Gemini bietet eine Text-to-SQL-Funktion, die direkt aus natürlicher Sprache SQL erzeugt
- Diese Funktion ist nicht nur für Entwicklerinnen und Entwickler, sondern auch für nichttechnische Nutzerinnen und Nutzer hilfreich
- Derzeit ist die Funktion in BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI und weiteren Produkten verfügbar
Zentrale Herausforderungen der Text-to-SQL-Technologie
1. Schwierigkeit, Geschäftskontext bereitzustellen
- Um präzises SQL zu schreiben, muss dem LLM ausreichend Kontext bereitgestellt werden, etwa zur Datenbankstruktur, zur Bedeutung von Spalten und zu den tatsächlichen Dateninhalten
- Zum Kontext gehören sowohl explizite Informationen (Schema, Spalteninformationen usw.) als auch implizite Informationen (z. B. die geschäftliche Bedeutung bestimmter Daten)
- Ein Ansatz, das LLM fortlaufend zu trainieren (Fine-Tuning), um Datenbankstrukturen, Datensatzvarianten und Schemaänderungen zu berücksichtigen, ist in der Praxis teuer
- Geschäftswissen oder semantische Informationen sind oft nicht sauber strukturiert, und ihre Umwandlung in Trainingsdaten ist ebenfalls schwierig
- Beispiel: Wenn ein DBA die Bedeutung von
pcat_extension.cat_id2 = 'Footwear' nicht kennt, kann er auch kein SQL zur Abfrage von Schuhverkäufen schreiben — für ein LLM besteht bei fehlendem Kontext dasselbe Risiko, ungenaue Abfragen zu erzeugen
2. Probleme bei der Interpretation der Nutzerabsicht
- Anfragen in natürlicher Sprache sind im Vergleich zu SQL häufig weniger eindeutig
- Datenanalysten oder Engineers können unklare Fragen in der Praxis durch Rückfragen präzisieren, LLMs neigen jedoch dazu, sofort auf eine gegebene Frage zu antworten, wodurch das Risiko von Falschinformationen (Halluzinationen) entsteht
- Bei einer Frage wie „Welcher Schuh wurde am häufigsten verkauft?“ sind Kriterien wie die Bedeutung von „am häufigsten verkauft“ (Anzahl der Bestellungen, Umsatz usw.) oder die Zahl der gewünschten Ergebnisse mehrdeutig
- Nutzerinnen und Nutzer mit technischem Hintergrund können grobes SQL als Ausgangspunkt verwenden, für Nichtfachleute ist jedoch korrekt funktionierendes SQL wichtiger
- Damit dies effektiv funktioniert, sollte das LLM Funktionen für Rückfragen, Erklärungen des Schlussfolgerungswegs und Nutzerführung unterstützen, um die Absicht der Nutzenden klarer zu erfassen
3. Generative Grenzen von LLMs
- LLMs sind stark bei Dokumentenzusammenfassungen und Informationsextraktion, haben aber Schwächen bei exakter SQL-Syntax oder seltener genutzten SQL-Funktionen
- Die Syntax unterscheidet sich je nach SQL-Dialekt, und selbst kleine Unterschiede erfordern hohe Präzision
- Beispiel: In BigQuery verwendet man
EXTRACT(MONTH FROM timestamp_column), in MySQL dagegen MONTH(timestamp_column)
- Die zuverlässige Einhaltung komplexer Spezifikationen bei der SQL-Generierung ist für LLMs keine einfache Aufgabe
Verfahren von Google Cloud zur Verbesserung von Text-to-SQL
Problem: Schema und Geschäftskontext
- Semantische Suche und Ranking
- In-Context-Learning
- Datensampling und Verknüpfung
- Aufbau semantischer Schichten
- Analyse von Nutzungsmustern und Verlaufshistorie
Problem: Interpretation der Nutzerabsicht
- Klärung mithilfe von LLMs
- Identifikation von Entitäten, Prüfung relevanter Informationen und Anstoßen geeigneter Rückfragen
Problem: Grenzen von LLMs überwinden
- Self-consistency mit Erzeugung mehrerer Abfragen und anschließender Auswahl der besten
- Validierung und Re-Prompting
- Kontextlernen mit Beispielen für verschiedene SQL-Dialekte
- Modell-Fine-Tuning
Beispiele für die praktische Anwendung zentraler Techniken
SQL-aware-Modelle
- Gemini verwendet verschiedene Fine-Tuning-Versionen, um hochwertiges SQL zu erzeugen
- Um eine hohe Genauigkeit für einzelne SQL-Dialekte sicherzustellen, werden Mischungen aus Modellversionen und maßgeschneiderte Anpassungen eingesetzt
Präzisierung von Nutzerfragen (Disambiguation)
- Wenn eine Frage mehrdeutig ist, werden Klärungsfragen erzeugt
- Beispiel: „Die meistverkauften Schuhe?“ → „Meinen Sie nach Anzahl der Bestellungen oder nach Umsatz?“
Semantische Suche und Kontextaufbau
- Vektorsuche auf Basis mehrstufiger semantischer Zuordnung identifiziert relevante Tabellen und Spalten
- Der Prompt wird unter Einbeziehung von Nutzeranfrageverläufen, Beispielen für Geschäftsregeln usw. aufgebaut
- Dank Unterstützung für lange Kontextfenster ist auch der Umgang mit großen Schemata möglich
Validierung und Neugenerierung
- Explizite Fehler in LLM-generierten Abfragen werden etwa durch Parsing und Dry Run erkannt
- Wird ein Fehler erkannt, wird durch Re-Prompting eine Korrektur angestoßen
Self-consistency
- Statt nur einer Abfrage werden mehrere Abfragen auf unterschiedliche Weise generiert
- Wenn mehrere Modelle dieselbe Abfrage empfehlen, steigt die Genauigkeit
Bewertung und Leistungsmessung
- Bestehende Benchmarks (z. B. BIRD-bench) sind nützlich, haben aber Grenzen bei der Abbildung realer Schemata
- Google hat daher einen eigenen synthetischen Benchmark-Satz aufgebaut
Bewertungsstrategie
- Abdeckung von SQL-Dialekten und engine-spezifischen Funktionen: umfasst neben Abfragen auch DDL, DML und Verwaltungsaufgaben
- Metriken: Nutzerreaktionen, Offline-Metriken, LLM-as-a-judge
- Kontinuierliche Bewertung: ermöglicht die schnelle Überprüfung neuer Modelle und Prompt-Techniken auf Wirksamkeit
Fazit
1 Kommentare
Hacker-News-Kommentare
Es gibt Überlegungen zum eigentlichen Ziel von Text-to-SQL: Geht es darum, ein Hilfsmittel für Datenanalysten zu bauen, oder darum, Business-Insights ohne Analysten zu erhalten? Falls Letzteres das Ziel ist, bleibt das Problem bestehen, dass Nichtfachleute selbst mit noch so ausgefeilter Technik weder die Korrektheit noch die Vollständigkeit von SQL beurteilen können. Fragen wie „Warum lagen die E-Commerce-Transaktionen gestern nur bei 80 %?“, „Warum steigen die Kundengewinnungskosten?“ oder „Warum lief die New-York-Kampagne schlechter als die in San Francisco?“ liegen außerhalb des eigentlichen Text2SQL-Bereichs.
In der Praxis scheint es eher um das zweite Ziel zu gehen, aber die Ergebnisse bleiben hinter den Erwartungen zurück. In Unternehmen möchte man Berichte oft noch am Ende anpassen, bekommt die gewünschten Informationen aber wegen Analystenmangels nicht rechtzeitig. Man versucht das mit „unendlicher Geschwindigkeit“ zu lösen, dabei entsteht das eigentliche Problem daraus, dass über Metriken nicht gründlich genug nachgedacht wird. Die Daten sind komplex, Business-Wissen ist implizit extern gespeichert, und die Dateninfrastruktur ist unzureichend, weshalb Analysen lange dauern. Clevere Analytics-Leads nutzen den AI-Hype, um in grundlegende Infrastruktur zu investieren.
Ich denke, die obigen Fragen lassen sich grundsätzlich gar nicht mit SQL lösen. SQL beantwortet vor allem das „Was“, aber nicht das „Warum“. Das Ziel von Text2SQL ist es, Analysten Zeit zu sparen, damit sie das „Was“ schneller erledigen und sich dadurch auf das „Warum“ konzentrieren können.
Das stimmt, aber ich denke, natürlicher Text kann der universelle Input für LLM-Systeme werden. Text2SQL kann als Grundlage für Information Retrieval dienen, aus dem Antworten auf komplexere Fragen zusammengesetzt werden. Kurzfristig ist es eine Assistenzfunktion, langfristig geht es aber darum, die Basis für Automatisierung, Ergebnisvergleiche und die Integration in größere Workflows zu schaffen. Der Kern ist, die Grundlage zur Beantwortung solcher Fragen zu legen. Es gibt noch viel zu tun.
Jeden Algorithmus, den ein Mensch ausführen kann, kann man auch bauen und testen. Wenn man zehn Analysten hat, unterscheiden sie sich alle in ihrem Verständnis der Datenbank und des Geschäfts sowie in ihren Fähigkeiten. Automatisierung bietet einen Standard, der ein Mindestmaß an Können und Wissen garantiert. Auch neue Analysten liefern dann sofort bessere Ergebnisse. Es ist ein sinnvolles Ziel, das System gemeinsam mit Experten zu entwickeln und zu testen, sodass AI Trade-offs, Bugs und Abweichungen von erwarteten Ergebnissen interpretieren kann. Einsicht oder „Taste“ lassen sich schwer automatisieren, aber Domain-Experten können mit gut gestalteter Automatisierung und einem Gefühl für vernünftige Resultate sehr weit kommen. Es ist nicht perfekt, aber das ist mein Ziel.
Erfahrungsbericht mit dem OpenAI-4o-Modell: Geschäftsrichtlinien, Branchenterminologie sowie Beschreibungen von Tabellen und Fremdschlüsseln werden gemeinsam in den Prompt gegeben. Dann erzeugt das Modell auch komplexe Join-Abfragen und liefert die Ergebnisse zurück. Ziel war es, Resultate für Nutzer bereitzustellen, die kein SQL können, aber das SQL selbst wird zusätzlich als Referenz mit angezeigt.
AI muss kein perfektes SQL erzeugen. In meinem Fall kopiere ich die Ausgabe trotz Validierung per Code nicht direkt, weil wegen feiner semantischer Unterschiede Risiken bestehen. Stattdessen lasse ich mir von der AI einen Ansatz zeigen und schreibe das SQL dann selbst von Grund auf.
Erfahrungsbericht mit dem neuesten Gemini in Google AI Studio: Es ist wirklich erstaunlich beeindruckend und bahnbrechend. Die Coding-Ergebnisse von Claude und ChatGPT wirken, als kämen sie aus einem anderen Jahrhundert. Noch vor einem Monat fand ich Claude großartig, jetzt weiß ich nicht, wie ich ohne Google Gemini weiter coden sollte. Gemini AI Studio ist ein gewaltiger Sprung für das Programmieren.
Es überrascht mich, dass viele diesen Wandel noch nicht erkannt haben. Claude erledigt auch kleinere Aufgaben gut, aber sobald es komplex wird, ist Gemini deutlich überlegen. Besonders beeindruckend ist die Context-Handling-Fähigkeit. Ich nutze Gemini nicht nur als Coding-Agent, sondern auch für Beta-Reading eines 85.000 Wörter langen Manuskripts und bekomme fast in Echtzeit Feedback-Reports auf Expertenniveau.
Diese Woche habe ich das Gefühl, dass im kostenlosen Gemini Pro der Reasoning-Modus deaktiviert wurde. Wenn man verhindert, dass es kurz vor dem eigentlichen Coden stoppt oder zu stark verallgemeinert, ist es ziemlich nützlich. Allerdings neigt Gemini dazu, zu viel Code zu schreiben. Ich nutze es vor allem für architektonische Erkundung statt mich an die Implementierung zu klammern. Bei einem Beispiel zum Aufbau eines Abo-Services mit Stripe konnte ich anhand bestehender, auf meinen Tech-Stack und meinen Anwendungsfall abgestimmter Daten schon vor dem Schreiben einer einzigen Codezeile meine Architekturentscheidung ändern.
Die Antwort lautet: „Semantic Layer verwenden“. Das ist der effektivste Weg, den richtigen Kontext zu vermitteln, und zugleich der beste Punkt für menschliches Eingreifen. Wenn Menschen alle zentralen Kennzahlen klar definieren, kann ein LLM sie jederzeit nutzen. Definiert man zum Beispiel MAU, erzeugt das LLM seine Abfragen auf Basis dieser Definition. Wenn man Abfragen statt in SQL in JSON schreibt, liefert das LLM viel konsistentere Ergebnisse. Wir verwenden cube; das ist die beste Open-Source-Semantic-Layer. Es gibt auch proprietäre Optionen von Naver. Mein früheres Unternehmen hatte dazu einmal einen Blog geschrieben, aber der heutige Eigentümer hostet ihn nicht mehr.
Wenn man im realen Betrieb mit AI SQL erzeugt, ist das riskant. Jemand ohne SQL-Kenntnisse kann eine fehlerhafte Abfrage schreiben und damit den Server ernsthaft beeinträchtigen. Die Datenbank unseres Teams ist für die meisten Entwickler groß, aber nicht wirklich riesig. Selbst wenn ich die AI gelegentlich bitte, eine bereits optimierte Query weiter zu verbessern, hat sie noch nie eine bessere Antwort geliefert. Manchmal redet die AI Unsinn oder macht Vorschläge, die in Wirklichkeit nutzlos sind. Es fühlt sich an wie ein dummer Papagei, der Dinge wiederholt, die er früher einmal gehört hat.
Ich denke, eine AI-Funktion zur Umwandlung von Text in reguläre Ausdrücke wäre wirklich praktisch.
Von allen AI-Tools, die ich ausprobiert habe, war das in BigQuery integrierte Gemini mit Abstand das enttäuschendste. Die Spaltennamen waren eindeutig und die Beschreibungen gut gepflegt, aber es kam der Problemlösung überhaupt nicht nahe.
SQL ist die Sprache, in der ich bislang mit Abstand die meisten Abfragen geschrieben habe. Selbst wenn ich die AI bitte, Queries zu schreiben, brauche ich viel mehr Zeit zum Nacharbeiten des Ergebnisses, als wenn ich sie selbst schreibe. Nebenbei: Wenn es eine Funktion gäbe, die mich SQL deutlich schneller schreiben ließe, wäre das großartig. Unser firmeninternes DSL hat einen Operator, der anhand von Fremdschlüsseln automatisch Joins macht, und das ist unglaublich praktisch. Das Lästigste an SQL ist, Join-Klauseln für 10, 20 oder mehr Tabellen einzeln schreiben zu müssen. Alles andere ist im Vergleich dazu nicht besonders schwierig.
Meiner Erfahrung nach ist fast alles gelöst, wenn es klare Constraints und sauber definierte Fremdschlüssel gibt. Jede Tabelle muss klare Constraints haben, damit AI die gesamte Verknüpfungsstruktur korrekt erfassen kann. SQL hat eine sehr präzise Spezifikation, aber gerade deshalb kann AI ohne gut definierte Constraints und Fremdschlüssel keine präzisen Antworten liefern.
Mit allen Foundation Models ist das inzwischen ziemlich einfach geworden. Wenn die Tabellenschemata nur gut kommentiert sind, ist die Anfrage zur Query-Erzeugung simpel.
Wenn man mit der smolagents-Bibliothek ein wenig Scaffolding um das Modell baut, ist das ziemlich praktisch. Es gibt auch Beiträge, die erklären, dass Text2SQL in Demos zwar simpel aussieht, die Anwendung auf komplexe reale Fälle aber sehr schwierig ist.
Step 1: Das Schema enthält Tausende Tabellen und fast keine Kommentare. Step 2...
Genau so ist es. Inzwischen steckt da nicht mehr viel Magie drin. Das
CREATE TABLE-DDL ist praktisch schon eine exakte Beschreibung der Tabelle, sodass man fast nicht mehr braucht. Wenn man nur die gewünschte Query genau beschreibt, erzeugt fast jedes brauchbare LLM sie problemlos.Im Beitrag "Show HN: We open sourced our entire text-to-SQL product" (2024) wurden mit awesome-Text2SQL und Awesome-code-llm > Benchmarks > Text to SQL hervorragende Referenzen genannt.