Peaks & Pies Logo
Business Intelligence
18. März 2026- Aktualisiert am 18. März 20265 Min. Lesezeit

BigQuery & LLMs: Warum diese Kombination ein Gamechanger sein kann – und wo die Grenzen liegen

Die direkte Integration von Large Language Models (LLMs) in Google BigQuery via ML.GENERATE_TEXT ist technologisch faszinierend. Sie erlaubt es, KI-Power direkt dorthin zu bringen, wo die Daten liegen. Für viele Use Cases ist das ein enormer Effizienzsprung, da der Umweg über externe Skripte entfällt. Doch wer AI-Kompetenz ernst nimmt, weiß auch: Die bequemste Lösung ist nicht immer die beste.

SQL statt Python?

Die Architektur ist denkbar schlank. Ohne eine einzige Zeile Code oder die Bereitstellung von Cloud Functions können Daten direkt in SQL angereichert werden. Das spart Zeit bei der Infrastruktur-Einrichtung und macht KI für Data Analysts sofort nutzbar.

Beispielsweise für die Klassifizierung von Suchanfragen im Versicherungsbereich bietet sich dieser Ansatz an. Hier geht es darum, riesige Mengen an unstrukturierten Daten schnell in strategische Kategorien zu übersetzen. Dadurch können User besser verstanden und im Nachgang das passende Produkt angeboten werden. Ein detaillierter Prompt in BigQuery kann hier Erstaunliches leisten:

SQL

1SELECT
2  ml_generate_text_result,
3  search_query
4FROM
5  ML.GENERATE_TEXT(
6    MODEL `projekt-id.dataset_id.gemini_pro_model`,
7    (
8      SELECT
9        CONCAT(
10          'Klassifiziere die Suchanfrage einer Versicherung basierend auf Nutzer-Zustand und Intent. ',
11          'Berücksichtige Synonyme und Deklinationen (z.B. "kündigen" = "Kündigung").',
12          '\n\n1. VORSORGE: Ruhig, langfristig. (Beispiele: "sinnvoll", "für Kinder", "lohnt sich").',
13          '\n2. AKUT: Angespannt, hoher Zeitdruck. (Beispiele: "Implantat Kosten", "ohne Wartezeit").',
14          '\n3. VERGLEICH: Benchmark-getrieben. (Beispiele: "Testsieger", "Check24", "Stiftung Warentest").',
15          '\n\nReferenz-Beispiele: ',
16          '\n- "zahnzusatzversicherung sinnvoll" -> VORSORGE',
17          '\n- "implantat kosten zahnzusatz" -> AKUT',
18          '\n- "versicherung auch wenn es schon zu spät ist" -> AKUT',
19          '\n\nAntworte NUR mit dem Label: [VORSORGE, AKUT, VERGLEICH, WECHSEL, INFO]. ',
20          'Suchanfrage: ', search_query
21        ) AS prompt,
22        search_query
23      FROM
24        `projekt-id.dataset_id.sea_keywords_unique`
25    ),
26    STRUCT(0 AS temperature, 10 AS max_output_tokens)
27  );
28
sql
Warum Bequemlichkeit nicht alles ist: Die Grenzen von SQL-AI

So einfach zu nutzen dieses Feature ist, so wichtig ist die kritische Einordnung. BigQuery ML ist keine Allzweckwaffe. In der Praxis gibt es klare Szenarien, in denen eine maßgeschneiderte Lösung (z. B. via Cloud Function oder Vertex AI Pipelines) überlegen ist:

  • Komplexes Pre-Processing: Wenn Daten vor dem Prompting massiv bereinigt oder mit Drittdaten aus APIs angereichert werden müssen, stoßen SQL-Strings an ihre Grenzen.
  • Kostenkontrolle bei Millionen Zeilen: Bei extrem hohen Datenvolumina kann die Preisgestaltung pro Token in BigQuery teurer werden als optimierte Batch-Verarbeitungen in dedizierten Umgebungen.
  • Fehlerrate & Fallbacks: LLMs können halluzinieren oder Anweisungen ignorieren. In einer reinen SQL-Umgebung ist es schwerer, komplexe "Retry-Logiken" oder Validierungsschritte einzubauen, die greifen, wenn das Modell kein valides Label zurückgibt.
  • Stabilität & Reproduzierbarkeit: Während SQL-Operationen bei unveränderten Daten immer das gleiche Ergebnis liefern, sind LLM-generierte Features nicht zwangsläufig stabil. Eine erneute Ausführung von ML.GENERATE_TEXT auf denselben Daten kann zu abweichenden Klassifikationen führen. Diese mangelnde Reproduzierbarkeit kann für Anwendungsfälle, die eine hohe Konsistenz erfordern (z. B. im Reporting oder bei der Merkmalserstellung für andere ML-Modelle), problematisch sein. 
Strategien für robuste LLM-Integrationen in BigQuery

Trotz dieser Einschränkungen lässt sich die Zuverlässigkeit direkt in BigQuery signifikant steigern. Um der Varianz entgegenzuwirken und die Qualität zu sichern, haben sich folgende Best Practices bewährt:

  • Minimierung der Varianz: Für Klassifizierungsaufgaben sollte die temperature in den Modelleinstellungen zwingend auf 0 gesetzt werden, um die Wahrscheinlichkeit für konsistente Antworten zu maximieren.
  • Benchmarking mit Testsets: Die Etablierung eines Referenz-Datensatzes, der sowohl Standardfälle als auch komplexe Grenzfälle ("Tricky Cases") enthält, ist essenziell. Dieses Set dient als Benchmark, um bei Modell- oder Prompt-Änderungen sofort zu erkennen, ob sich die Gesamtqualität verbessert oder verschlechtert.
  • Prompt-Engineering als Software-Entwicklung: Ein Prompt sollte wie produktiver Code behandelt werden. Das bedeutet: Versionierung, systematisches Testen und formale Abnahmen.
  • Strukturierte Logik via Dataform: Bei komplexeren Pipelines empfiehlt es sich, Werkzeuge wie Dataform zu nutzen. Dies ermöglicht es, die Prompt-Logik modular zu verwalten, Abhängigkeiten sauber abzubilden und Datenqualitätstests direkt in den Workflow zu integrieren (mehr dazu in unserem Artikel zu [Dataform-Best Practices]).
  • Präzise Instruktions-Hierarchie: Wie im obigen SQL-Beispiel gezeigt, reduziert eine klare Strukturierung des Prompts – inklusive expliziter Definitionen und Referenzbeispielen – die Wahrscheinlichkeit für Fehlinterpretationen durch das Modell drastisch.
Expertise zeigt sich, wenn die KI versagt

Wahre AI-Kompetenz bedeutet, das System hinter dem Prompt zu verstehen. Ein Modell wie Gemini Pro liefert in BigQuery hervorragende Ergebnisse, solange der Kontext klar ist. Doch was passiert bei mehrdeutigen Suchanfragen wie "Zahnzusatzversicherung Ergo"? Ist das VORSORGE oder bereits eine gezielte Suche nach einem Anbieter (VERGLEICH)?

Hier trennt sich die Spreu vom Weizen:

  • Domain Knowledge: Wir definieren die logischen Leitplanken, damit das LLM nicht rät, sondern nach Geschäftslogik entscheidet.
  • Technical Excellence: Wir bewerten für jeden Use Case neu: Reicht die Convenience von BigQuery aus, oder brauchen wir für maximale Präzision und Kosteneffizienz eine spezialisierte Architektur in der Google Cloud Platform?
Fazit

ML.GENERATE_TEXT ist ein fantastisches Werkzeug für schnelle Iterationen und viele Standard-Tasks. Es macht verschiedene Datenanalysen agiler. Aber die Technologie ist nur so gut wie die Strategie dahinter. Der Anspruch sollte sein, nicht nur das LLM zu "füttern", sondern die stabilste und effizienteste Lösung für das jeweilige Datenproblem zu bauen – ob in SQL oder im Code.


Lust auf einen
Austausch?

Schreiben Sie uns
Crocodile illustration
Paperplane

Newsletter

Als Erstes informiert, wenn es Neuigkeiten in der digitalen Welt gibt!

Durch die Bereitstellung Ihrer E-Mail-Adresse erklären Sie sich damit einverstanden, Newsletter und Werbe-E-Mails von uns zu erhalten. Wir respektieren Ihre Privatsphäre und werden Ihre Informationen nicht an Dritte weitergeben. Sie können sich jederzeit abmelden.

You've reached the end
BER

Google Maps

Linienstrasse 222, 10119 Berlin

HAM

Google Maps

Raboisen 30, 20095 Hamburg

hello@peaksandpies.com

LinkedIn

Flower illustration