Datenbankabfragen in natürlicher Sprache: Text-to-SQL mit BigQuery

Inhalt
Mit Ihren Daten in BigQuery chatten können Sie, wenn Sie einen kleinen KI-Agenten zwischen Nutzer und Datenbank setzen. Der Agent liest das Tabellenschema, lässt ein Large Language Model (hier GPT-4o von OpenAI) die Frage in BigQuery-SQL übersetzen, führt die Abfrage aus und schickt einen etwaigen Fehler von BigQuery an das Modell zurück, damit es die Abfrage repariert. Auf dem Demo-Datensatz zur Kundenabwanderung eines Telekomanbieters, den wir unten verwenden, beantwortet diese einfache Schleife Fragen wie "How many churns are in the churn_table?" (1869), ohne dass jemand SQL schreibt.
Large Language Models schreiben sehr gutes SQL für die verschiedensten Datenbanken, auch für Google BigQuery. Das ist nützlich, denn BigQuery-Datensätze sind oft komplex und enthalten einige der wichtigsten Geschäftsdaten eines Unternehmens. Statt zuerst das richtige Datenmodell zu suchen und dann eine Abfrage zu schreiben, fragen Sie in normaler Sprache "Wie viele Nutzer haben sich letzten Monat registriert?" und haben in Sekunden eine Antwort.
In diesem Beitrag zeigen wir, wie Sie eine solche Chat-Oberfläche für Google BigQuery mit GPT-4o bauen. Wir richten die Entwicklungsumgebung ein, verbinden uns mit BigQuery, erzeugen die SQL-Abfragen über die OpenAI-API und führen sie auf Ihrer BigQuery-Datenbank aus.
Als Zugabe zeigen wir, wie Sie mit RAG (Retrieval Augmented Generation) (auf Englisch) die Qualität der erzeugten SQL-Abfragen verbessern. Wenn Sie BigQuery lieber an bestehende KI-Agenten und Chat-Clients anbinden möchten, lesen Sie unsere Anleitung zum MCP-Server für BigQuery.
Update (November 2026): OpenAI hat GPT-4o als veraltet markiert. Laut
OpenAIs Deprecations-Seite
werden die unten verwendeten gpt-4o-Snapshots am 14. Januar 2027
abgeschaltet. Der Agent funktioniert genauso mit jedem neueren Chat-Modell,
das Function Calling unterstützt. Sie müssen nur den Parameter model
ändern. Der Embedding-Code verwendet text-embedding-ada-002, das weiterhin
funktioniert; OpenAIs aktuelle
Embedding-Modelle
sind text-embedding-3-small und text-embedding-3-large. Wenn Sie
wechseln, prüfen Sie den Schwellenwert in query_chromadb erneut, denn die
Abstände ändern sich mit dem Modell. Der ChromaDB-Code verwendet
get_or_create_collection, das in allen ChromaDB-Versionen funktioniert
(der Rückgabetyp von list_collections() hat sich zwischen den Versionen
geändert).
Architektur einer Chat-Oberfläche für BigQuery
Eine Lösung, mit der Sie "mit BigQuery chatten", braucht drei Bausteine:
- Eine Möglichkeit, eine Frage in natürlicher Sprache einzugeben.
- Eine Schicht, die die Frage in SQL übersetzt.
- Eine Laufzeitumgebung, die die SQL-Abfrage auf der BigQuery-Datenbank ausführt.
Baustein 1 und 3 sind unkompliziert. Die eigentliche Logik und Komplexität steckt in Baustein 2, der Übersetzung von natürlicher Sprache in SQL.
Für gute SQL-Generierung braucht es diese Teilschritte:
- Die Struktur der Datenbank auslesen, also das Datenbankschema.
- Eine Beschreibung der einzelnen Spalten beschaffen, damit die KI den Kontext der Daten versteht.
- Mit Retrieval Augmented Generation die BigQuery-Tabellen und -Spalten finden, die für die Frage am relevantesten sind.
- Die SQL-Abfrage mit einem Large Language Model erzeugen.
- Fehler in der erzeugten Abfrage automatisch korrigieren, denn LLMs sind nicht perfekt und liefern ab und zu fehlerhafte Abfragen.
Zusammengesetzt hat eine robuste Chat-Oberfläche für BigQuery diese Architektur:
Grobarchitektur einer Chat-Oberfläche für BigQuery
Bei genauerem Hinsehen wird klar, dass wir BigQuery nicht einfach mit einem KI-Modell "verbinden". Wir brauchen einen KI-Agenten.
Kurz gesagt sind KI-Agenten KI-Modelle, die eine Eingabe entgegennehmen und dann selbstständig ihr Wissen, externe Werkzeuge (etwa einen Datenbankzugriff) und ihr Gedächtnis nutzen, um die Anfrage zu lösen.
Unser Agent ist klein. Seine Aufgabe ist es, die Frage in eine funktionierende SQL-Abfrage zu übersetzen, die sie beantwortet. Als Werkzeuge bekommt er Zugriff auf die BigQuery-Datenbank und eine Python-Laufzeit. Das nötige Wissen, nämlich SQL zu schreiben, bringt das KI-Modell selbst mit.
KI-Agent, der Nutzereingabe, Datenbankzugriff und eine Python-Laufzeit kombiniert
Hinweis: Da die KI hier nur wenige Aufgaben selbstständig lösen muss, bleibt unser Agent recht klein. KI-Agenten können sehr unterschiedliche Aufgaben übernehmen, hier reicht aber eine sehr begrenzte Umsetzung. Unser Agent muss nur SQL-Abfragen erzeugen, sie ausführen, bei einem Fehler entscheiden, ob er es noch einmal versucht, und das Ergebnis zurückgeben.
Schritt für Schritt: einen Text-to-SQL-Agenten für BigQuery bauen
Mit der Architektur im Kopf gehen wir die Umsetzung durch. Wir bauen die gesamte Agentenschleife von Grund auf, ohne eine der vorhandenen LLM-Bibliotheken. (Einen breiteren Überblick über diesen Ansatz gibt unser Beitrag, wie Sie KI-Agenten ohne Frameworks bauen (auf Englisch).)
Warum nicht LangChain oder LlamaIndex?
Sowohl LangChain als auch LlamaIndex bieten SQL-Agenten als Teil ihres Funktionsumfangs an.
Für den Einstieg in Text-to-SQL-Agenten eignen sich beide gut, ihre Abstraktionen machen aber schwer nachvollziehbar, was darunter passiert. Vor allem sind ihre Umsetzungen recht allgemein gehalten, damit sie viele SQL-Datenbanken abdecken. Nach vielen Stunden und Tagen mit SQL-Agenten haben wir festgestellt, dass jeder Anwendungsfall Anpassungen braucht, sowohl bei der SQL-Generierung als auch bei der Fehlerbehandlung. Diese Flexibilität bieten die High-Level-Schnittstellen von LangChain und LlamaIndex nicht.
Vorbereitung
Stellen Sie zuerst sicher, dass Sie ein aktives Google-Cloud-Projekt haben und für dieses Projekt die Abrechnung aktiviert ist.
Aktivieren Sie dann die folgenden Google-Cloud-APIs:
Richten Sie anschließend die Authentifizierung für BigQuery so ein:
-
Legen Sie für Ihr Projekt ein Dienstkonto an und geben Sie ihm die folgenden BigQuery-Rollen:
- BigQuery User
- BigQuery Data Viewer
- BigQuery Job User
-
Laden Sie den Dienstkontoschlüssel des neuen Dienstkontos herunter.
Zum Schluss importieren wir Demodaten in BigQuery. Sie können auch Ihre eigenen Daten verwenden.
-
Laden Sie den Demo-Datensatz herunter. Er enthält Daten aus einer bekannten Kaggle-Challenge zur Kundenabwanderung (Churn) bei einem Telekomanbieter.
-
Importieren Sie die Datei in BigQuery, in ein neues Dataset
aiagent_testund eine Tabellechurn_table.
Den KI-Agenten umsetzen
-
Legen Sie eine neue venv oder conda-Umgebung an und aktivieren Sie sie.
-
Installieren Sie die benötigten Python-Pakete:
-
Importieren Sie die Module, legen Sie BigQuery-Dataset und -Tabelle fest und setzen Sie den OpenAI-API-Schlüssel.
-
Erstellen Sie eine SQLAlchemy-Engine für die BigQuery-Datenbank.
-
Testen wir die Datenbankverbindung:
Das Ergebnis sollte so aussehen:
-
Wenn die Verbindung steht, lesen Sie das Datenbankschema aus.
Damit erhalten Sie eine Liste aller Tabellen und Spalten im angegebenen BigQuery-Dataset.
Damit ist die Vorbereitung abgeschlossen, und wir können den eigentlichen KI-Agenten umsetzen. Wir erzeugen die SQL-Abfragen über die OpenAI-API und führen sie auf der BigQuery-Datenbank aus.
Die Agentenschleife umsetzen
Im Kern ist ein KI-Agent nichts anderes als eine While-Schleife, die eine Aufgabe oder Frage entgegennimmt und ein KI-Modell aufruft, um sie zu lösen. Die Schleife (der Agent) läuft, bis eine Abbruchbedingung erfüllt ist.
Unser Agent ist einfach gehalten. In Pseudocode sieht er so aus:
while:
- Mit KI aus der Nutzereingabe und dem Datenbankschema eine SQL-Abfrage erzeugen
- Die erzeugte SQL-Abfrage auf der BigQuery-Datenbank ausführen
- Prüfen, ob es Fehler gab. Falls ja, die Abfrage per KI korrigieren
- Optional: Falls keine Fehler, per KI prüfen, ob das Ergebnis die Frage beantwortet. Falls nicht, wiederholen
- Aufhören, sobald die Frage beantwortet ist
Setzen wir das in Python um. Zuerst schreiben wir eine Funktion, die die Abfrage erzeugt. Dafür nutzen wir OpenAI Function Calling, weil es verlässliche JSON-Ausgaben liefert, die sich leicht weiterverarbeiten lassen.
Hinweis: In vielen Experimenten wirkten KI-Modelle mit Function Calling etwas weniger intelligent. Bei unserer SQL-Generierung war das bisher kein Problem, Sie sollten es aber im Hinterkopf behalten. Wenn Ihr Modell ständig schlechte Abfragen liefert, probieren Sie den "normalen" Chat-Endpunkt und werten Sie die Ausgabe selbst aus.
Diese Funktion übernimmt den ersten Versuch, eine Abfrage zu erzeugen. Die resultierende Abfrage führen wir auf BigQuery aus und prüfen auf Fehler. Gibt es welche, korrigiert die KI die Abfrage.
Dafür schreiben wir als Nächstes die Funktion zur Fehlerbehandlung. Sie ist nichts anderes als eine weitere Abfragegenerierung per LLM, nur dass wir dem Modell diesmal auch die Fehlermeldung mitschicken, damit es die Abfrage korrigieren kann.
Wir ändern nur den System-Prompt, sodass er den Fehler enthält und das Modell um eine Korrektur bittet. Ansonsten sind Anfrage und Funktion dieselben wie vorher.
Zum Schluss setzen wir alles in der Agentenschleife zusammen:
Jetzt starten wir den Agenten mit einer Frage:
Der Agent erzeugt die SQL-Abfrage, führt sie aus, behebt Fehler selbst und liefert das richtige Ergebnis.
Jetzt etwas Komplizierteres: der Anteil männlicher und weiblicher Kunden unter denen, die abgewandert sind.
Ausgabe:
Nicht schlecht für ein paar Dutzend Zeilen Python.
Den BigQuery-SQL-Agenten verbessern
Mit dem Agenten lässt sich schon gut herumspielen, er erzeugt aber auch eine ganze Menge unbrauchbarer Abfragen. Diese Fehler behebt er erstaunlich gut selbst, zwei Maßnahmen verringern aber die Zahl der Fehlversuche.
-
Beschreibungen zu den Datenbankspalten hinzufügen. Bisher geben wir dem KI-Modell nur den Tabellennamen und die Spaltennamen als Kontext. Das Modell muss dann "raten", welche Spalten für die Frage relevant sind. Das ist fehleranfällig, und Spaltenbeschreibungen verbessern es.
Dafür gibt es zwei Wege: a. Jede Spalte von Hand beschreiben. Das ist etwas mühsam, aber der genaueste und verlässlichste Weg, dem Modell Kontext zu geben. b. Ein
head(10)jeder Spalte an GPT-4o schicken und um eine Beschreibung bitten. Das Modell findet sehr wahrscheinlich eine brauchbare Beschreibung.Beide Methoden sind einfach, die Umsetzung überlassen wir deshalb Ihnen. Für diesen Beitrag habe ich unser Schema von GPT-4o so umschreiben lassen:
-
Mit RAG (auf Englisch) zuerst die möglicherweise relevanten Tabellen und Spalten finden. Das verkleinert den Suchraum für das KI-Modell.
Das funktioniert, weil sich die meisten Fragen nur auf einen Teil der vorhandenen Spalten beziehen. Wenn Sie relevante Spalten und Tabellen suchen, bevor die KI eine Abfrage schreibt, kann das die Qualität des erzeugten SQL deutlich verbessern.
Mit RAG die relevanten Spalten für Text-to-SQL finden
Um zu zeigen, wie ein RAG-gestütztes Text-to-SQL-System aussieht, erweitern wir den Agenten, den wir gerade gebaut haben.
Das RAG-Prinzip ist immer gleich: Sie nehmen eine Menge Texte (hier die Spaltenbeschreibungen), erstellen dafür einen Vektorindex und finden über diesen Index die Texte, die der Frage inhaltlich am nächsten sind.
Konkret erstellen wir einen Index über unsere Spaltenbeschreibungen und
speichern die übrigen Schlüssel (table_name, column_name und
column_type) als Metadaten.
Als Vektordatenbank verwenden wir in diesem Beispiel ChromaDB, jede andere funktioniert aber genauso. (Auch BigQuery selbst kann Embeddings speichern und eine Vektorsuche ausführen, siehe RAG, Embeddings und Vektorsuche mit BigQuery (auf Englisch).)
Hinweis: ChromaDB hat eine praktische Funktion:
Sie können collection.add() nur das "Dokument" (den Text, den Sie
indexieren wollen) ohne Embeddings übergeben, und ChromaDB erzeugt die
Embeddings selbst. In diesem Beispiel erzeugen wir sie von Hand, damit sich
der Code leichter auf andere Vektordatenbanken übertragen lässt. Wenn Sie
ohnehin ChromaDB verwenden, nutzen Sie die Funktion gern.
Mit den Embeddings schreiben wir eine Funktion, die die relevantesten Spalten heraussucht.
query_chromadb findet die 10 Spalten, die für die Frage am relevantesten
sind. Passen Sie diese Zahl nach Bedarf an.
ChromaDB hat keinen Parameter für einen Schwellenwert, deshalb filtern wir die Ergebnisse selbst und behalten nur Spalten, die einigermaßen relevant sind.
Hinweis: Wenn Ihre Vektordatenbank einen Schwellenwert unterstützt, können Sie das manuelle Filtern weglassen.
Jetzt verwenden wir die Funktion in unserem Agenten:
Die einzige Änderung ist der Aufruf von query_chromadb vor create_query.
Statt des ganzen Tabellenschemas bekommt das Modell nur die Spalten, die für
die Frage relevant sein könnten.
Probieren wir es noch einmal:
Auch mit RAG liefert der Agent das richtige Ergebnis.
Fazit
Wir haben einen einfachen KI-Agenten gebaut, der Fragen in natürlicher Sprache in SQL übersetzt, die Abfragen auf einer BigQuery-Datenbank ausführt und Fehler automatisch behandelt. Er nutzt GPT-4o von OpenAI für die SQL-Generierung, Google BigQuery für Speicherung und Abfragen und Retrieval Augmented Generation (RAG), um die relevanten Spalten auszuwählen.
Zwei Maßnahmen verbessern die Genauigkeit des erzeugten SQL:
- Beschreibungen zu den Datenbankspalten hinzufügen
- Vor der Abfragegenerierung mit RAG die relevanten Tabellen und Spalten finden
Ein weiterer Schritt ist eine semantische Schicht, die Geschäftsbegriffe auf Tabellen, Join-Pfade und SQL-Ausdrücke abbildet. Ein Werkzeug, das eine solche Schicht automatisch erzeugt, haben wir in Text-to-SQL mit semantischer Schicht: NVIDIA Auto Ontology im Praxistest ausprobiert.
Weil die Umsetzung selbst gebaut ist, können Sie Prompts und Fehlerbehandlung auf BigQuery und Ihren konkreten Anwendungsfall abstimmen. Das ist der Hauptgrund, warum wir weder LangChain noch LlamaIndex verwendet haben.
Wir glauben, dass solche Schnittstellen in natürlicher Sprache verändern können, wie Unternehmen mit ihren Daten arbeiten. Wer kein SQL kann, bekommt Antworten aus komplexen Datenbanken, ohne auf das Datenteam angewiesen zu sein, und Datenfachleute verbringen mehr Zeit mit Analyse und weniger mit dem Heraussuchen von Daten.
Unfehlbar ist das System allerdings nicht. Wichtige Ergebnisse sollten Sie immer prüfen, besonders bei komplexen Abfragen oder wenn Sie wichtige Geschäftsentscheidungen darauf stützen.
Wenn Sie ein solches System in Ihrem Unternehmen umsetzen wollen, unterstützen wir Sie gern. Melden Sie sich bei uns.
Weiterlesen
- KI direkt aus der PostgreSQL-Datenbank nutzen (auf Englisch)
- RAG-Qualität messen mit Ragas: RAG-Pipelines richtig evaluieren
- Eigenes LLM hosten, inklusive HTTPS
- MCP-Server mit FastMCP erstellen und eigene Datenbank-Tools bereitstellen
- Wissensgraphen für RAG mit dem Neo4j LLM Knowledge Graph Builder (auf Englisch)
- Was ist der Google Vertex AI Agent Builder? (auf Englisch)
Sie möchten zuverlässige KI-Agenten-Systeme bauen?
Wir haben auf Basis aktueller Forschung einen ausführlichen Leitfaden (auf Englisch) erstellt, wie Sie robuste KI-Agenten-Systeme bauen, die auch im produktiven Betrieb funktionieren. Der Leitfaden behandelt:
- die 14 systematischen Fehlerquellen in Multi-Agenten-Systemen
- belegte Best Practices für das Design von Agenten
- strukturierte Kommunikationsprotokolle und Prüfmechanismen



