Peaks & Pies Logo
Business Intelligence
11. Mai 2026- Aktualisiert am 03. Juni 20263 Min. Lesezeit

Kosteneffiziente Nutzung von Gemini in BigQuery

Hand-gezeichnete Illustration: Suchanfragen werden durch einen Regex-Trichter gefiltert, der größte Teil landet im Eimer 'Rules', wenige Anfragen erreichen einen Gemini-Kristall, der die Labels VORSORGE, AKUT und VERGLEICH ausgibt

Die Berechnung der Kosten in Google BigQuery orientiert sich primär an der Menge der verarbeiteten Daten. Damit unterscheidet sich BigQuery grundlegend von klassischen Data-Warehouse-Lösungen, bei denen man für eine feste Instanz unabhängig vom Nutzungsvolumen zahlt. Ein zentraler Indikator für jeden Data Engineer ist die Kostenschätzung im BigQuery Editor, die vor der Ausführung einer Query die ungefähre Datenmenge angibt. Kennt man den Preis pro Terabyte, lassen sich die Kosten einer Abfrage leicht überschlagen.

Sobald eine Query jedoch nicht nur Daten abfragt, sondern über eine Model Connection Gemini nutzt (z. B. um KI-generierte Inhalte direkt in eine neue Spalte zu schreiben), verliert diese Schätzung an Aussagekraft.

Das Szenario: Keyword-Intents für Versicherungen

Das folgende vereinfachte Beispiel baut auf einem vorherigen Use Case auf: Eine Versicherung möchte SEA-Keywords automatisch einer bestimmten Nutzer-Intention zuordnen.

Der Prompt definiert verschiedene Kategorien (z. B. VORSORGE, AKUT, VERGLEICH), liefert Erklärungen und enthält Referenzbeispiele (Few-Shot Prompting), um die Genauigkeit von Gemini 3 Flash zu erhöhen. Um die Qualität zu validieren, wurden vorab 150 Keywords manuell klassifiziert.

Die initiale Abfrage (Naiver Ansatz)
1WITH unique_queries AS (
2  SELECT DISTINCT search_query
3  FROM `project-id.dataset-id.source_bingads_search_query_performance`
4  WHERE search_query IS NOT NULL
5),
6
7classified_data AS (
8  SELECT
9    search_query,
10    REGEXP_EXTRACT(UPPER(TRIM(ml_generate_text_llm_result)), r'VORSORGE|AKUT|VERGLEICH|WECHSEL|INFO') AS intent_klasse
11  FROM
12    ML.GENERATE_TEXT(
13      MODEL `project-id.dataset-id.gemini_model`,
14      (
15        SELECT
16          search_query,
17          CONCAT(
18            'Klassifiziere die Suchanfrage einer Versicherung basierend auf Nutzer-Zustand und Intent. ',
19            'Berücksichtige Synonyme und Deklinationen (z.B. "kündigen" = "Kündigung").',
20            '\n\n1. VORSORGE: Ruhig, langfristig. (Beispiele: "sinnvoll", "für Kinder", "lohnt sich").',
21            '\n2. AKUT: Angespannt, hoher Zeitdruck. (Beispiele: "Implantat Kosten", "ohne Wartezeit").',
22            '\n3. VERGLEICH: Benchmark-getrieben. (Beispiele: "Testsieger", "Check24", "Stiftung Warentest").',
23            '\n\nReferenz-Beispiele: ',
24            '\n- "zahnzusatzversicherung sinnvoll" -> VORSORGE',
25            '\n- "implantat kosten zahnzusatz" -> AKUT',
26            '\n- "versicherung auch wenn es schon zu spät ist" -> AKUT',
27            '\n\nAntworte NUR mit dem Label: [VORSORGE, AKUT, VERGLEICH, WECHSEL, INFO]. ',
28            'Suchanfrage: '
29          ) AS prompt
30        FROM unique_queries
31      ),
32      STRUCT(
33        0 AS temperature,
34        10 AS max_output_tokens,
35        TRUE AS flatten_json_output
36      )
37    )
38)
39
40SELECT
41  search_query,
42  COALESCE(intent_klasse, 'NICHT KLASSIFIZIERT') AS intent_klasse
43FROM classified_data
sql

Die versteckten Kostenfallen

Nach Ausführung der Query zeigen die Job-Informationen lediglich 30 MB an kostenrelevanten Daten ("Bytes billed"). In einer Standard-Umgebung wären das vernachlässigbare Cent-Beträge. Doch dieser Wert bezieht sich nur auf das Scannen der Quelltabelle. Die tatsächlichen Kosten verstecken sich in den Token-Metriken:

  • Prompt Token Count (ca. 14 Mio.): Das Large Language Model (LLM) verarbeitet den (langen) Prompt für jede der 20.000 Zeilen einzeln.
  • Candidates Token Output (ca. 43.000): Der generierte Output (die Labels) für alle Zeilen.

Bei einem Preis von etwa 0,25 $ pro 1 Mio. Token (für Gemini 3 Flash) kostet diese eine Query ca. 3,50 $. Was bei 20.000 Zeilen moderat klingt, skaliert bei Millionen von täglichen Datensätzen schnell auf dreistellige Monatsbeträge.

Zudem war das Ergebnis mit 70 % Genauigkeit nicht optimal. Den Prompt weiter zu verfeinern, birgt Risiken:

  • "Lost in the Middle": Zu viele Beispiele führen dazu, dass das Modell Informationen in der Mitte des Prompts ignoriert.
  • Kosten-Explosion: Jedes zusätzliche Wort im Prompt multipliziert sich mit der Anzahl der Zeilen.

Die Lösung: Der hybride Ansatz

Statt jedes Keyword unmittelbar an das Modell zu übergeben, wird eine Kombination aus deterministischer Logik (Regelwerk) und probabilistischer Klassifizierung (KI) genutzt (rule-based pre-filtering).

Das optimierte SQL-Modell

Vorgeschaltet wird ein CASE-WHEN-Statement, das eindeutige Muster per Regex abfängt. Nur die "schwierigen" Fälle werden an Gemini übergeben.

1CREATE OR REPLACE TABLE `project-id.dataset-id.bing_ads_intents` AS
2WITH unique_queries AS (
3  SELECT DISTINCT
4    search_query,
5    -- 1. Deterministische Schicht (Regeln sparen Token)
6    CASE
7      WHEN REGEXP_CONTAINS(LOWER(search_query), r'auslands|sofort|akut|notfall') THEN 'AKUT'
8      WHEN REGEXP_CONTAINS(LOWER(search_query), r'tarife|vergleich|test|beste') THEN 'VERGLEICH'
9      WHEN REGEXP_CONTAINS(LOWER(search_query), r'wechseln|kündigen') THEN 'WECHSEL'
10      WHEN REGEXP_CONTAINS(LOWER(search_query), r'^(brandname)( versicherung)?$') THEN 'INFO'
11      ELSE NULL
12    END AS pre_classified
13  FROM `project-id.dataset-id.source_table`
14  WHERE search_query IS NOT NULL
15),
16
17-- 2. Probabilistische Schicht (Nur für den Rest)
18llm_processing AS (
19  SELECT
20    search_query,
21    REGEXP_EXTRACT(UPPER(ml_generate_text_llm_result), r'VORSORGE|AKUT|VERGLEICH|WECHSEL|INFO') AS intent_klasse
22  FROM
23    ML.GENERATE_TEXT(
24      MODEL `project-id.dataset-id.gemini_model`,
25      (
26        SELECT
27          search_query,
28          FORMAT("Klassifiziere den Intent: '%s'. Labels: VORSORGE, AKUT, VERGLEICH, WECHSEL, INFO. Nur das Label antworten.", search_query) AS prompt
29        FROM unique_queries
30        WHERE pre_classified IS NULL -- Filtern!
31      ),
32      STRUCT(0 AS temperature, 10 AS max_output_tokens, TRUE AS flatten_json_output)
33    )
34),
35
36-- 3. Merge der Ergebnisse
37final_results AS (
38  SELECT search_query, intent_klasse FROM llm_processing
39  UNION ALL
40  SELECT search_query, pre_classified AS intent_klasse FROM unique_queries WHERE pre_classified IS NOT NULL
41)
42
43SELECT * FROM final_results
sql

Das Ergebnis der Optimierung

Durch die Vorab-Filterung konnten im Testprojekt bereits 30 % der Keywords regelbasiert zugeordnet werden. Da der verbleibende Prompt für die KI zudem deutlich kürzer gestaltet werden konnte, sank der gesamte Prompt-Token-Count um 65 %, während die Übereinstimmung mit den manuellen Test-Keywords auf über 90 % stieg.

Fazit

KI kann Aufgaben extrem schnell erledigen, aber sie ersetzt keine saubere Engineering-Architektur. Ein hybrider Ansatz, der etablierte SQL-Logik mit modernen LLMs kombiniert, ist oft nicht nur kosteneffizienter, sondern durch die Vermeidung des "Lost in the Middle"-Effekts auch präziser. Echte Mehrwerte entstehen dort, wo KI gezielt und "richtig dosiert" eingesetzt wird.

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