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 learningIn-database machine learning to podejście, w którym modele AI trenuje się i uruchamia bezpośrednio na danych w hurtowni — bez kopiowania ich do osobnego środowiska. Oszczędza czas, koszty i ogranicza ryzyko związane z bezpieczeństwem danych. w BigQuery ma znaczenie, jakie funkcje są dziś realnie dostępne i kiedy BQML wygrywa z pełnowymiarowym pipeline'em MLPipeline ML to łańcuch kroków od surowych danych do działającego modelu: eksport z hurtowni, czyszczenie, przygotowanie cech, trening, walidacja, wdrożenie i monitoring — najczęściej rozproszony między kilka systemów i języków programowania..

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 engineeringFeature engineering, czyli przygotowanie cech, to proces przekształcania surowych danych w zmienne, których model AI może użyć do uczenia się — np. wyliczenie wieku klienta z daty urodzenia albo zamiana tekstu na liczby., 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 (BQMLBQML to skrót od BigQuery ML — natywnego rozszerzenia BigQuery, które pozwala trenować i uruchamiać modele uczenia maszynowego bezpośrednio z poziomu SQL, bez wychodzenia do osobnej platformy ML.) 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 wektorowymWyszukiwanie wektorowe (vector search) to technika znajdowania podobnych dokumentów lub obiektów na podstawie ich znaczenia, a nie dokładnego dopasowania słów. Pozwala np. znaleźć produkty „podobne stylem” albo dokumenty „o tym samym temacie”., 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 MLOpsMLOps to praktyki i narzędzia do zarządzania cyklem życia modeli uczenia maszynowego w produkcji — odpowiednik DevOps, tylko dla AI. Obejmuje wersjonowanie modeli, monitorowanie jakości, automatyczne re-trenowanie i wdrażanie., 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)Drzewa wzmacniane (gradient boosted trees) to rodzina algorytmów uczenia maszynowego, w której wiele prostych drzew decyzyjnych uczy się po kolei, każde poprawiając błędy poprzednich. XGBoost to ich najpopularniejsza implementacja — uznawany za jedno z najlepszych narzędzi do klasyfikacji i regresji na danych tabelarycznych., głębokie sieci neuronowe (DNN), grupowanie metodą k-średnich, faktoryzacja macierzy (do systemów rekomendacji), ARIMA_PLUSARIMA_PLUS to rozszerzona wersja modelu ARIMA do prognozowania szeregów czasowych — z automatyczną detekcją sezonowości, świąt i nietypowych zdarzeń. 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 TimesFMTimesFM to pre-trenowany przez Google Research model bazowy (foundation model) do prognozowania szeregów czasowych w trybie zero-shot — działa bez treningu na Twoich danych, ponieważ nauczył się ogólnych wzorców na miliardach przykładów. od Google Research. Model wstępnie wytrenowany na miliardach punktów danych, działający w trybie zero-shotZero-shot oznacza, że model rozwiązuje zadanie bez wcześniejszego treningu na Twoich konkretnych danych — wykorzystuje to, czego nauczył się wcześniej z miliardów innych przykładów.. 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ętrzneZmienne egzogeniczne to dodatkowe czynniki spoza samego szeregu czasowego, które wpływają na wynik — np. wydatki na reklamę, pogoda, kalendarz świąt czy kursy walut wpływające na sprzedaż. (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: MAEMAE (Mean Absolute Error) — średni błąd bezwzględny prognozy, podany w jednostkach zmiennej docelowej. Mówi „o ile średnio mylimy się w złotówkach”., MAPEMAPE (Mean Absolute Percentage Error) — średni procentowy błąd prognozy. Mówi „o ile średnio mylimy się procentowo”, niezależnie od skali sprzedaży. i RMSERMSE (Root Mean Squared Error) — pierwiastek z średniego błędu kwadratowego. Mocno „karze” duże odchyłki, więc jest dobrym sygnałem, czy zdarzają się spektakularne pomyłki.. 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 AIVertex AI to platforma Google Cloud do trenowania, wdrażania i serwowania modeli uczenia maszynowego. Gemini, Claude i pozostałe modele LLM dostępne w BigQuery działają właśnie tam — BigQuery tylko wysyła do nich zapytania.. 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 widokMaterialized view to zmaterializowany widok — wynik zapytania zapisany jako tabela, która automatycznie się odświeża. W kontekście dashboardów: szybki dostęp do gotowych danych bez liczenia ich na żywo przy każdym otwarciu. 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 CTECTE (Common Table Expression) — to nazwany podzapytanie zaczynający się od `WITH ... AS (...)`. Pozwala dzielić skomplikowane zapytania SQL na czytelne kroki, jak rozdziały w dokumencie. — masz fundament, żeby zacząć robić rzeczy, które trzy lata temu były domeną wąskiej specjalizacji.