Data Science w SQL: Jak wdrażać modele AI w Google BigQuery bez Pythona

To nie jest marketingowy slogan Google'a, ale realna zmiana w warstwie analitycznej — i jeden z najważniejszych ruchów na rok 2026. Pole bitwy o produktywność zespołów danych przeniosło się z notebooków do hurtowni. W tym artykule pokazuję, dlaczego in-database machine learning w BigQuery ma znaczenie, jakie funkcje są dziś realnie dostępne i kiedy BQML wygrywa z pełnowymiarowym pipeline'em ML.

SQL stał się językiem „od początku do końca" dla danych

Klasyczny proces pracy analityka wygląda znajomo w niemal każdej firmie: dane mieszkają w hurtowni, analityk pisze zapytania i ładuje wyniki do Pythona. Tam wykonuje feature engineering, trenuje model, eksportuje przewidywania z powrotem do hurtowni, a stamtąd do dashboardu. Trzeba pamiętać, że każdy z tych kroków generuje koszty — i nie tylko finansowe, ale także w obszarze bezpieczeństwa danych.

Python nie jest tu problemem. Problem polega na tym, że dla 80% typowych zadań biznesowych — klasyfikacji klientów, prognozowania sprzedaży, segmentacji, wykrywania nietypowych wzorców — cały ten aparat jest po prostu nadmiarowy. Firma płaci za sztab data scientistów wykonujących pracę, którą doświadczony analityk SQL mógłby zrobić sam, gdyby miał odpowiednie narzędzie.

W tę lukę wchodzi BigQuery ML.

Czym jest BigQuery ML (i czym jest BigQuery AI)

BigQuery ML (BQML) to zestaw rozszerzeń języka SQL, dzięki którym można trenować, oceniać i wdrażać modele uczenia maszynowego bez wychodzenia z konsoli BigQuery. Tworzenie modelu wygląda bardzo podobnie do tworzenia zwykłego widoku w bazie danych — używasz polecenia CREATE MODEL zamiast CREATE VIEW, wskazujesz typ algorytmu i karmisz model zapytaniem SELECT.

Pod marką BigQuery AI Google połączył BQML z generatywną AI, wyszukiwaniem wektorowym, agentami i nową rodziną funkcji AI.*. To istotna zmiana z punktu widzenia osób budujących i utrzymujących produkty. Do niedawna funkcje AI w BigQuery były rozsiane po różnych konstrukcjach (ML.PREDICT, ML.GENERATE_TEXT, zewnętrzne modele Vertex). Dziś wszystko układa się w spójny zestaw operatorów SQL — AI.GENERATE_TEXT, AI.FORECAST, AI.DETECT_ANOMALIES, AI.EVALUATE — które wywołasz dokładnie tak, jak SUM() czy ROW_NUMBER() OVER(...).

Granica między „programistą aplikacyjnym" a „inżynierem danych" zaciera się dalej. Jeśli umiesz napisać sensowne zapytanie SQL, masz dostęp do prawdziwych modeli AI. Bez pythonowego pipeline'u, bez własnego MLOps, bez przekładania danych między systemami.

Klasyczny pipeline ML kontra uczenie maszynowe w bazie danych

Różnicę najlepiej widać w zestawieniu. Tabela porównuje typowy proces budowania modelu predykcyjnego w obu podejściach — klasycznym, opartym o Pythona i osobne narzędzia, oraz nowym, w którym wszystko dzieje się wewnątrz hurtowni danych.

Wnioski są dwa. Po pierwsze — BQML nie zastępuje Vertex AI ani PyTorcha. Po drugie — dla ogromnej większości realnych problemów biznesowych nie musi tego robić. „Customowa architektura sieci konwolucyjnej" nie jest najczęstszym problemem działu marketingu.

Co konkretnie potrafi dziś BigQuery ML

Teraz prawę słów o klasie modeli i funkcji, które dostajesz „od ręki" w 2026 roku:

Modele predykcyjne (klasyczne) — regresja liniowa i logistyczna, drzewa wzmacniane (XGBoost), głębokie sieci neuronowe (DNN), grupowanie metodą k-średnich, faktoryzacja macierzy (do systemów rekomendacji), ARIMA_PLUS i ARIMA_PLUS_XREG do szeregów czasowych. Wszystko trenujesz przez CREATE MODEL, oceniasz przez ML.EVALUATE, a używasz przez ML.PREDICT.

TimesFM — model bazowy do prognozowania — najważniejsza zmiana jeszcze z 2025 roku. Zamiast budować własny model szeregów czasowych, używasz AI.FORECAST, która pod spodem wywołuje TimesFM od Google Research. Model wstępnie wytrenowany na miliardach punktów danych, działający w trybie zero-shot. Nie trenujesz nic i wskazujesz tylko tabelę z historią i pytasz, ile okresów do przodu chcesz prognozować.

Funkcje generatywne — AI.GENERATE_TEXT (i jej starsza wersja ML.GENERATE_TEXT) wywołują Gemini, Claude, Llamę lub Mistrala bezpośrednio z SQL. Analiza sentymentu, wyciąganie encji z tekstu, tłumaczenia, klasyfikacja tekstu, opisywanie obrazów — wszystko działa jako kolumna w wyniku SELECT.

Wykrywanie anomalii i ocena prognoz — AI.DETECT_ANOMALIES na szeregach czasowych (wykrywanie nietypowych wartości w sprzedaży, ruchu, logach) i AI.EVALUATE do oceny jakości prognoz.

Wspólny mianownik: piszesz SQL, dostajesz rezultat AI.

Case study: prognozowanie sprzedaży w 5 zapytaniach

Realny scenariusz wygląda dokładnie tak, jak typowe zlecenie od działu marketingu lub finansów: „mamy historię sprzedaży miesięcznej z ostatnich dwóch lat, daj nam prognozę na pół roku z przedziałami ufności".

W klasycznym podejściu oznaczałoby to eksport danych, uruchomienie skryptu w Pythonie, ręczne przygotowanie danych, trening, walidację i wizualizację. Czyli kilka godzin pracy, która wymaga specjalistycznych narzędzi.

W BigQuery ML to jest jedno zapytanie.

Krok 1: przygotowanie danych

Załóżmy, że masz tabelę myproject.sales.daily_orders z kolumnami order_date (data zamówienia) i revenue (kwota przychodu jako liczba zmiennoprzecinkowa). Agregujemy ją do poziomu dziennego:

CREATE OR REPLACE TABLE `myproject.sales.daily_revenue` AS
SELECT
  order_date AS ts,
  SUM(revenue) AS total_revenue
FROM `myproject.sales.daily_orders`
WHERE order_date BETWEEN '2024-01-01' AND '2026-04-30'
GROUP BY ts
ORDER BY ts;

Krok 2: prognoza z TimesFM (zero treningu i zero modelu)

AI.FORECAST używa wbudowanego TimesFM i nie tworzysz osobnego obiektu MODEL, ponieważ przekazujesz dane od razu do funkcji:

SELECT *
FROM AI.FORECAST(
  TABLE `myproject.sales.daily_revenue`,
  data_col => 'total_revenue',
  timestamp_col => 'ts',
  horizon => 180,                -- prognoza na 180 dni
  confidence_level => 0.95       -- 95% przedział ufności
);

Wynik to tabela z kolumnami forecast_timestamp, forecast_value, prediction_interval_lower_bound, prediction_interval_upper_bound. Pełna prognoza z przedziałami ufności na pół roku, bez trenowania, bez tuningu, bez „dobierania hiperparametrów na oko".

Krok 3: gdy potrzebujesz większej kontroli — ARIMA_PLUS

Czasem chcesz wytrenować model na własnych danych — masz nietypową sezonowość, chcesz uwzględnić zmienne zewnętrzne (np. wydatki na reklamę, kalendarz wydarzeń) albo porównać kilka wariantów prognozy. Wtedy wraca klasyczne BQML z ARIMA_PLUS:

CREATE OR REPLACE MODEL `myproject.sales.revenue_arima`
OPTIONS(
  model_type = 'ARIMA_PLUS',
  time_series_timestamp_col = 'ts',
  time_series_data_col = 'total_revenue',
  auto_arima = TRUE,
  data_frequency = 'AUTO_FREQUENCY',
  holiday_region = 'PL'         -- uwzględnia polskie święta
) AS
SELECT ts, total_revenue
FROM `myproject.sales.daily_revenue`;

I generujesz predykcje:

SELECT *
FROM ML.FORECAST(
  MODEL `myproject.sales.revenue_arima`,
  STRUCT(180 AS horizon, 0.95 AS confidence_level)
);

auto_arima = TRUE zostawia BQML wybór parametrów modelu (kluczowych liczb sterujących, jak model uczy się z danych). holiday_region = 'PL' to drobiazg a model uwzględni wtedy efekt polskich świąt narodowych przy prognozowaniu sprzedaży.

Krok 4: detekcja anomalii w danych historycznych

Klasyczny problem działu finansów: „czy w ciągu ostatnich miesięcy były dni nietypowe?". Zamiast pisać reguły typu „odchylenie > 2 sigma", uruchamiasz:

SELECT *
FROM AI.DETECT_ANOMALIES(
  TABLE `myproject.sales.daily_revenue`,
  data_col => 'total_revenue',
  timestamp_col => 'ts',
  anomaly_prob_threshold => 0.95
);

Funkcja zwróci tabelę, w której każdy dzień ma znacznik „czy to nietypowy wynik" i prawdopodobieństwo, z jakim model jest tego pewny. To samo, co zespół budowałby ręcznie w Pythonie przez weekend.

Krok 5: sprawdzenie jakości prognozy

Żeby zweryfikować, jak dobrze model przewiduje, odkładamy część rzeczywistych danych „na bok" (np. ostatnie 30 dni) i porównujemy je z tym, co model przewidział. Im mniejsza różnica — tym lepsza prognoza:

SELECT *
FROM AI.EVALUATE(
  TABLE `myproject.sales.daily_revenue_actual`,
  (SELECT * FROM AI.FORECAST(
    TABLE `myproject.sales.daily_revenue_train`,
    data_col => 'total_revenue',
    timestamp_col => 'ts',
    horizon => 30
  ))
);

Dostajesz trzy standardowe wskaźniki jakości w kolumnach tabeli: MAE, MAPE i RMSE. Tyle.

Cały flow — od surowych zamówień do prognozy z metrykami — to pięć zapytań i kilkanaście minut pracy. To jest dokładnie ta wartość biznesowa, którą sprzedaje się decydentowi: zamiast budować zespół ML do typowych prognoz, eksploatuj zespół analityczny, który już masz.

Gemini w SQL: gdy klasyczny ML to za mało

Klasyczny ML jest świetny do liczb. Co jednak, gdy masz 200 tysięcy komentarzy klientów i potrzebujesz analizy sentymentu? Bazę opisów produktów do skategoryzowania? Tickety supportu do automatycznego tagowania?

Wchodzi AI.GENERATE_TEXT z modelem Gemini.

Setup: zdalny model

Zaczynamy od jednorazowej konfiguracji w Google Cloud, dzięki której BigQuery uzyska bezpieczny dostęp do Vertex AI. Następnie definiujesz tak zwany „zdalny model" (remote model) i nie jest model trenowany u Ciebie, tylko nazwane odniesienie do Gemini, którego można używać w SQL:

CREATE OR REPLACE MODEL `myproject.ml.gemini_pro`
REMOTE WITH CONNECTION DEFAULT
OPTIONS(ENDPOINT = 'gemini-2.5-flash');

Od tego momentu myproject.ml.gemini_pro jest dla SQL-a obiektem, który wywołasz.

Use case 1: analiza sentymentu klientów

Tabela myproject.support.tickets z kolumną message, a dla każdego ticketu chcemy sentyment — pozytywny, negatywny lub neutralny:

SELECT
  ticket_id,
  message,
  ml_generate_text_llm_result AS sentiment
FROM AI.GENERATE_TEXT(
  MODEL `myproject.ml.gemini_pro`,
  (
    SELECT
      ticket_id,
      message,
      CONCAT(
        'Sklasyfikuj poniższy komentarz klienta jako jeden z: POSITIVE, NEGATIVE, NEUTRAL. ',
        'Zwróć wyłącznie jedno słowo, bez komentarza. Komentarz: ',
        message
      ) AS prompt
    FROM `myproject.support.tickets`
    WHERE created_at >= CURRENT_DATE() - 7
  ),
  STRUCT(
    0.0 AS temperature,        -- deterministyczne wyniki
    10 AS max_output_tokens,   -- ograniczenie długości odpowiedzi i kosztu
    TRUE AS flatten_json_output
  )
);

Wynik to dla każdego ticketu kolumna z odpowiedzią Gemini. Wystarczy zapisać to zapytanie jako zmaterializowany widok albo zaplanować jego nocne uruchomienie, a dashboard sentymentu działa codziennie bez osobnej infrastruktury ML.

Use case 2: ekstrakcja danych ustrukturyzowanych z tekstu

Trudniejszy scenariusz: opisy faktur w polu tekstowym, z których chcesz wyciągnąć kwotę, walutę i datę. Klasycznie — wyrażenia regularne (regex) i godziny pracy. Z Gemini w SQL:

SELECT
  invoice_id,
  raw_description,
  ml_generate_text_llm_result AS extracted_json
FROM AI.GENERATE_TEXT(
  MODEL `myproject.ml.gemini_pro`,
  (
    SELECT
      invoice_id,
      raw_description,
      CONCAT(
        'Wyodrębnij z poniższego tekstu kwotę, walutę i datę. ',
        'Zwróć wyłącznie JSON w formacie: ',
        '{"amount": <liczba>, "currency": "<3-literowy kod>", "date": "<YYYY-MM-DD>"}. ',
        'Jeśli czegoś nie znajdziesz, użyj null. Tekst: ',
        raw_description
      ) AS prompt
    FROM `myproject.finance.raw_invoices`
  ),
  STRUCT(
    0.0 AS temperature,
    200 AS max_output_tokens,
    TRUE AS flatten_json_output
  )
);

Następnie JSON_EXTRACT_SCALAR rozbija wynik na kolumny i masz tabelę gotową do analiz. Od nieustrukturyzowanego tekstu do tabelarycznych danych w jednym zapytaniu.

Use case 3: automatyczne tagowanie i kategoryzacja

SELECT
  article_id,
  title,
  ml_generate_text_llm_result AS tags
FROM AI.GENERATE_TEXT(
  MODEL `myproject.ml.gemini_pro`,
  (
    SELECT
      article_id,
      title,
      CONCAT(
        'Przyporządkuj artykuł do maksymalnie 3 tagów z listy: ',
        '[tech, business, finance, marketing, devops, ai, security]. ',
        'Zwróć tylko tagi oddzielone przecinkami. Tytuł: ',
        title
      ) AS prompt
    FROM `myproject.cms.articles`
    WHERE tags IS NULL
  ),
  STRUCT(0.0 AS temperature, 50 AS max_output_tokens, TRUE AS flatten_json_output)
);

Trzy minuty i mamy tysiące artykułów otagowanych automatycznie, a w klasycznym procesie ML byłby to projekt na tydzień. Oszczędność czasu jest oszałamiająca.

Kiedy NIE używać BigQuery ML

Zawsze i wszędzie, narzędzia musimy wybierać w sposób świadomy i przemyślany. BQML jest przydatne, ale nie jest magiczną różdżką, ponieważ są scenariusze, w których pełnowymiarowy stack ML jest wyraźnie bardziej odpowiedni:

• Własna architektura modelu, niestandardowe warstwy sieci neuronowej — do tego służą Vertex AI, PyTorch lub TensorFlow.

• BigQuery ML działa na danych wsadowych (batch). Modele aktualizowane z każdym nowym zdarzeniem to domena innych systemów.

• Rozproszony trening na wielu maszynach z GPU/TPU nie jest tym, w czym BQML się specjalizuje.

• Dedykowany endpoint w Vertex AI będzie miał niższe opóźnienia niż zapytanie SQL.

• BQML zapewnia automatyzację, ale w zamian tracisz granularną kontrolę nad procesem treningu.

Dla wszystkiego innego — czyli realnie 80% problemów biznesowych — BQML wygrywa kosztem i prostotą.

Koszty: zanim wrzucisz to na produkcję

Teraz trochę o niebezpieczeństwach finansowych. Cennik BigQuery ML ma swoje pułapki, ponieważ trening modeli klasycznych liczy się jak każde inne zapytanie — czyli głównie według ilości danych przeskanowanych przy uruchomieniu (a w przypadku bardziej iteracyjnych modeli także według czasu obliczeniowego). Funkcje AI.GENERATE_TEXT i pochodne generują dodatkowe koszty po stronie Vertex AI — płacisz za każde wywołanie modelu Gemini, a przy 200 tysiącach wierszy razy kilkaset tokenów rachunek może nieprzyjemnie zaskoczyć.

Po pierwsze — zawsze ustawiaj max_output_tokens na minimalną sensowną wartość. Klasyfikacja sentymentu nie potrzebuje 1000 tokenów odpowiedzi, podczas gdy klasyfikacja jedno-słowowa potrzebuje 10.

Po drugie — buduj proces inkrementalnie. Nie odpalaj AI.GENERATE_TEXT na całej tabeli historycznej, tylko partycjonuj po dacie i puszczaj tylko nowe rekordy przez nocny scheduled query.

Po trzecie — testuj na podzbiorze. LIMIT 100 w fazie developmentu może oszczędzić kilkuset dolarów na rachunku.

Co to oznacza dla zespołów i ról

Jeśli prowadzisz zespół analityczny albo planujesz rekrutację — ten trend zmienia kalkulację. Jeszcze niedawno każda firma chcąca robić ML potrzebowała dedykowanego data scientista. Dziś dobry analityk SQL z podstawową wiedzą o uczeniu maszynowym robi 70-80% tej pracy bezpośrednio w BigQuery.

Warto ciągle odkręcać mit pojawiający się przy narzędziach AI: data scientists nie znikają, ale ich rola się przesuwa — z „budowania modeli klasyfikacyjnych dla działu marketingu" w stronę „projektowania niestandardowych systemów AI i nadzoru nad jakością modeli w skali firmy". Oznacza to, że praca jest, ale głębsza i bardziej strategiczna.

Bariera wejścia w „prawdziwy ML" się obniżyła i jeśli umiesz pisać sensowne złączenia tabel, agregacje okienkowe (funkcje typu RANK() OVER (...)) i CTE — masz fundament, żeby zacząć robić rzeczy, które trzy lata temu były domeną wąskiej specjalizacji.