Wyobraź sobie taki scenariusz, który w 2026 roku jest już boleśnie normalny. Firma ma eleganckiego copilotowego asystenta dla handlowców. Model jest dobry. Prompt jest dopracowany. Demo na zarządzie wyszło świetnie. Asystent odpowiada na pytania o churn, sugeruje kolejne kroki sprzedażowe, podpowiada cross-sell, a nawet generuje szkice maili. Po wdrożeniu do prawdziwej pracy zaczyna się jednak ten mniej instagramowy etap życia systemu AI. Jeden handlowiec dostaje rekomendację opartą o kampanię, która skończyła się trzy tygodnie temu. Drugi widzi wynik score’u klienta policzony na niekompletnych danych z CRM. Trzeci pyta o historię zamówień i dostaje odpowiedź opartą o snapshot sprzed nocnego backfilla, bo pipeline się opóźnił. Model niby mówi po ludzku, ale dane pod nim żyją własnym, lekko tragicznym życiem.

W praktyce większość problemów produktów AI zaczyna się nie w modelu, tylko w jakości, świeżości i przewidywalności danych, które model dostaje.

I tu dochodzimy do rzeczy, której sporo zespołów uczy się dopiero po pierwszym poważnym incydencie: większość problemów produktów AI nie zaczyna się w modelu, tylko w danych i w tym, jak te dane przepływają przez system. Mówiąc wprost: możesz mieć świetne LLM-y, sensowny retrieval, porządny backend i nadal wypuścić produkt, któremu nikt nie ufa, bo zabrakło dyscypliny data engineeringowej. Model jest tylko ostatnim etapem łańcucha. Jeśli wcześniej wrzucasz do niego spóźnione, źle zmapowane, niespójne albo niewalidowane dane, to cała „inteligencja” staje się bardzo drogim sposobem na eleganckie halucynowanie rzeczywistych problemów integracyjnych.

Spis treści

Data Engineering długo miał wizerunek hydrauliki IT. Taki dział techniczny od rur, schedulerów, plików parquet i dziwnych skrótów w stylu CDC, SCD, DAG, OLAP, ETL, ELT. Mało sexy, dużo odpowiedzialności. Dopóki wszystko działa, nikt nie pyta. Kiedy przestaje, nagle wszyscy chcą zrozumieć, skąd model wziął tę jedną złą liczbę, czemu embeddingi nie uwzględniają najnowszych dokumentów, dlaczego dashboard pokazuje coś innego niż agent i czemu rekomendacje zachowują się tak, jakby system zatrzymał się w czasie.

Ale czemu to w ogóle powinno cię obchodzić, jeśli jesteś seniorem od backendu, platformy albo AI engineeringu? Bo współczesne produkty AI prawie nigdy nie działają na „gołym modelu”. Działają na danych transakcyjnych, eventach, dokumentach, logach, tabelach analitycznych, feature’ach, embeddingach, cache’ach i strumieniach aktualizacji. Jeśli nie rozumiesz, skąd te dane się biorą, jak są transformowane, kiedy są opóźnione, gdzie mogą się zepsuć i jak je odtworzyć, to budujesz system na fundamencie, którego nie kontrolujesz. To trochę jak pisanie skomplikowanego systemu rozproszonego z założeniem, że sieć „po prostu działa”. Tak, do pierwszego piątku wieczorem. Dokładnie dlatego rola AI Engineera osadzonego w realnym kontekście biznesowym nie kończy się na modelu i promptach.

W tym tekście przejdziemy przez Data Engineering i Big Data tak, jak naprawdę przydają się AI Engineerowi. Nie jako katalog narzędzi do odhaczenia w CV, tylko jako sposób myślenia o przepływie danych w produktach, które mają działać w produkcji, pod realnym ruchem i z realnymi konsekwencjami błędów. Zobaczysz, czym w praktyce różni się ETL od ELT, gdzie batch nadal wygrywa, kiedy potrzebujesz streamingu, po co ludziom ten cały lakehouse, czemu data quality nie jest luksusem, tylko mechanizmem obronnym, oraz jak buduje się feature pipeline’y i embedding pipeline’y, żeby model nie opierał się na przypadkowym bałaganie. Jeśli po lekturze będziesz patrzył na system AI jak na łańcuch danych z warstwami odpowiedzialności, a nie jak na prompt podpięty do API, to dokładnie o to chodzi, podobnie jak w tekstach o LLM Engineering jako rdzeniu pracy AI Engineera i o RAG mierzonym realnymi ewaluacjami.

Dlaczego ten temat jest ważny właśnie teraz

Jeszcze kilka lat temu dało się długo udawać, że data engineering jest czymś obok „prawdziwego AI”. Data scientist trenował model, backendowiec wystawiał API, ktoś inny dorabiał dashboard, a warstwa danych często była mieszanką SQL-a, skryptów cronowych i dobrych chęci. Przy proof of conceptach to przechodziło. POC żyje krótko, ma mało użytkowników i toleruje rzeczy, których produkcja nie wybacza. Problem w tym, że rynek przestał płacić za samo demo z LLM-em. Dziś firmy chcą systemów, które nie tylko odpowiadają efektownie, ale robią to na aktualnych danych, z kontrolą jakości, śledzalnością i kosztem, który nie eksploduje po pierwszym sukcesie sprzedażowym.

Zmienił się też charakter samych produktów. Kiedyś „AI w produkcie” często oznaczało pojedynczy model scoringowy albo klasyfikator w tle. Dziś masz agentów, RAG, personalizację w czasie zbliżonym do rzeczywistego, routing zadań, automatyczne ekstrakcje z dokumentów, semantyczne wyszukiwanie, generowanie podsumowań, rankingowanie i systemy, które łączą dane strukturalne z nieustrukturyzowanymi. To oznacza dużo więcej wejść, dużo więcej pochodnych reprezentacji i dużo więcej miejsc, w których dane mogą się rozjechać.

Do tego doszła bardzo praktyczna ewolucja infrastruktury. Cloudowe data warehouse’y, takie jak Snowflake, BigQuery czy Redshift, nauczyły zespoły myśleć o danych analitycznych inaczej niż przez klasyczny on-premowy ETL do jednej wielkiej hurtowni. Potem przyszły otwarte formaty tabelaryczne, Delta Lake, Apache Iceberg, Apache Hudi, czyli świat, w którym dane w object storage zaczęły zachowywać się bardziej jak zarządzalne tabele niż jak sterta plików. W tym samym czasie streaming przestał być niszą dla wielkich platform i stał się normalnym narzędziem tam, gdzie liczy się świeżość danych, detekcja anomalii, event-driven integration albo aktualizacja feature’ów i indeksów bez czekania na nocny batch.

AI dołożyło do tej układanki kolejny poziom komplikacji. Bo teraz nie zarządzasz już tylko tabelą zamówień czy eventów produktowych. Zarządzasz też pipeline’em chunkingu dokumentów, ekstrakcją metadanych, generowaniem embeddingów, wersjonowaniem promptów, obliczaniem feature’ów dla rankera, backfillami dla nowego modelu i monitoringiem driftu wejść. To już nie jest tylko problem analityki. To jest problem architektury produktu.

I tu pojawia się rzecz, którą senior developer zwykle docenia od razu: data engineering jest dziś dla AI tym, czym CI/CD i observability stały się dla backendu kilka lat temu. Na początku też były traktowane jako dodatki. Potem wszyscy zrozumieli, że bez pipeline’ów wdrożeniowych, testów, monitoringu i rollbacków można zrobić demo, ale trudno utrzymać system. Z danymi jest identycznie. Bez wersjonowania, walidacji, lineagu, retry, idempotency i sensownego modelu przetwarzania możesz uruchomić model. Nie możesz na nim spokojnie zbudować produktu, który ma przeżyć kontakt z rzeczywistością.

Jest jeszcze jeden powód, dla którego temat jest ważny właśnie teraz: AI bardzo skutecznie obnaża stare zaniedbania danych. Firma przez lata mogła żyć z tym, że CRM ma trochę duplikatów, eventy czasem nie dojadą, nazwy pól są niespójne, a dashboard liczy metrykę trochę inaczej niż pipeline marketingowy. Kiedy jednak na tym samym bałaganie próbujesz zbudować rekomendacje, agenta albo system wspierający decyzje, chaos przestaje być tłem. Staje się produktem. Nagle użytkownik widzi go bezpośrednio. I dlatego właśnie w erze AI temat danych wrócił z hukiem do centrum architektury.

Fundamenty: jak naprawdę myśleć o data engineeringu

Najprostsza definicja, która ma sens dla developera, brzmi tak: data engineering to projektowanie i utrzymywanie systemów, które dostarczają właściwe dane, we właściwym czasie, w przewidywalny sposób, do właściwych odbiorców. Brzmi banalnie. Nie jest. Bo za tym jednym zdaniem kryją się decyzje o modelowaniu danych, integracjach, formatach, harmonogramach, retry, walidacji, kosztach, opóźnieniach i granicach odpowiedzialności.

Jeśli chcesz zrozumieć data engineering bez korporacyjnej mgły, myśl o nim jak o połączeniu trzech światów. Pierwszy to logistyka: skąd dane przyjeżdżają, jak często, w jakim stanie i gdzie trafiają dalej. Drugi to kompilacja: bierzesz surowy input i przekształcasz go do czegoś, na czym da się sensownie pracować. Trzeci to operacje produkcyjne: musisz wiedzieć, co weszło, co wyszło, co się wywaliło, co można odtworzyć i czy wynik jest wiarygodny. To nie jest przypadek, że dobre pipeline’y danych mają dużo wspólnego z dobrymi buildami, deployami i workflowami asynchronicznymi.

ETL i ELT bez religii

Wokół ETL i ELT bywa zaskakująco dużo ideologii, a w praktyce to po prostu dwa różne punkty ciężkości.

ETL oznacza Extract -> Transform -> Load. Najpierw wyciągasz dane ze źródła, potem transformujesz je poza docelowym magazynem i dopiero wynik ładujesz tam, gdzie ma być konsumowany. Historycznie to był klasyczny model dla hurtowni danych: surowe dane wlatywały z systemów transakcyjnych, przechodziły przez warstwę przetwarzania, a do warehouse trafiał już materiał „po obróbce”.

ELT odwraca środek ciężkości: Extract -> Load -> Transform. Najpierw ładujesz dane możliwie blisko surowej postaci do miejsca, które dobrze skaluje przechowywanie i obliczenia, a transformacje wykonujesz później, często już w samym warehouse albo lakehouse. To jest model, który świetnie zgrał się z erą cloudowych platform danych i narzędzi typu dbt.

Który jest lepszy? To trochę jak pytanie, czy lepszy jest monolit czy mikroserwisy. Odpowiedź brzmi: zależy, ale bardzo konkretnie. Jeśli masz ciężkie transformacje, dużo logiki jakościowej, wymagania bezpieczeństwa albo nie chcesz ładować do centralnej warstwy brudnych danych bez filtracji, ETL nadal ma sens. Jeśli z kolei chcesz szybko ingestować źródła, zachować raw layer, a potem iterować nad transformacjami już na stabilnym storage i compute, ELT jest często wygodniejsze.

W systemach AI zwykle i tak kończysz hybrydą. Część rzeczy robisz jako klasyczne ELT, bo chcesz mieć surową historię zdarzeń i wersjonowalne transformacje w SQL. Część robisz jak ETL, bo np. przed wygenerowaniem embeddingów musisz najpierw odfiltrować śmieci, wyciąć wrażliwe dane albo znormalizować format dokumentów. Mówiąc wprost: ważniejsze od etykietki jest świadome miejsce, w którym dzieje się transformacja i kto za nią odpowiada.

Pipeline danych to nie skrypt, który akurat działa

Sporo osób zaczyna od myślenia: „przecież pipeline to po prostu skrypt Pythona odpalany cronem”. Jasne, czasem tak. I dokładnie tak samo można powiedzieć, że backend to po prostu while true czytający socket. Problem zaczyna się wtedy, gdy system rośnie.

Prawdziwy pipeline danych ma zwykle kilka cech, które odróżniają go od jednorazowego skryptu:

ma jasno zdefiniowane wejścia i wyjścia,
jest odtwarzalny,
jest obserwowalny,
ma retry i politykę błędów,
potrafi być uruchamiany według harmonogramu albo zdarzenia,
nie psuje danych przy ponownym uruchomieniu,
daje się rozszerzać bez przepisywania wszystkiego od zera.

To ostatnie jest ważne. W data engineeringu bardzo szybko okazuje się, że „działa” nie znaczy „nadaje się do utrzymania”. Jeśli nocny job wywali się po 70 minutach i nie wiesz, czy można go odpalić drugi raz bez duplikacji, to nie masz pipeline’u. Masz loterię opakowaną w schedulera.

Dlatego tak dużo mówi się o idempotency. Pipeline powinien być zaprojektowany tak, żeby powtórne uruchomienie nie tworzyło nowych szkód. To może oznaczać pracę na merge’ach zamiast ślepych appendach, używanie watermarków, deduplikację po kluczach biznesowych, atomiczne publikowanie tabel wynikowych albo trzymanie stanu przetworzenia w jawny sposób. Brzmi znajomo? Tak, bo to są te same inżynierskie odruchy, które stosujesz przy przetwarzaniu wiadomości czy integracjach eventowych.

Prosty szkic pipeline’u do budowy dziennego snapshotu cech klienta może wyglądać tak:

from datetime import date

def build_customer_features(run_date: date) -> None:
    raw_events = extract_events(start=run_date, end=run_date)
    cleaned = normalize_events(raw_events)
    validated = assert_schema_and_ranges(cleaned)
    features = aggregate_customer_features(validated)
    write_staging_table("stg_customer_features", features, run_date)
    quality_report = run_quality_checks("stg_customer_features", run_date)

    if quality_report.has_blocking_errors:
        raise RuntimeError("Feature build failed quality gates")

    publish_partition("customer_features", run_date)

Kod jest banalny i właśnie o to chodzi. Nie magia, tylko sekwencja odpowiedzialności: extract, normalizacja, walidacja, agregacja, zapis do stagingu, quality gate, publikacja. Jeśli pominiesz któryś z tych etapów, problem wróci później, tylko w gorszej formie i bliżej użytkownika końcowego.

Batch kontra streaming: nie wszystko musi być real-time

Jedna z bardziej uporczywych iluzji współczesnej inżynierii brzmi: skoro mamy streaming, to wszystko powinno być real-time. Nie powinno. Wiele systemów da się uprościć i ustabilizować, jeśli uczciwie przyznasz, że dane co godzinę albo co noc są wystarczająco świeże.

Batch processing nadal wygrywa tam, gdzie liczy się prostota, przewidywalność i niższy koszt operacyjny. Budowa dziennych agregatów, zasilanie warehouse, pełne backfille, rekalkulacja embeddingów po zmianie modelu, przygotowanie datasetów treningowych, materializacja features do raportów albo okresowe czyszczenie danych świetnie pasują do batcha. Batch ma tę piękną zaletę, że jest łatwiejszy do zrozumienia, debugowania i odtworzenia.

Streaming ma sens wtedy, gdy wartość biznesowa naprawdę zależy od świeżości. Detekcja fraudu, aktualizacja stanu sesji użytkownika, near-real-time personalizacja, zasilanie agenta eventami operacyjnymi, alerting, routing leadów, monitoring modelu albo szybkie odświeżanie indeksu dokumentów po publikacji zmian to klasyczne przypadki. Ale streaming nie jest „lepszym batchem”. To inny model z własnymi kosztami: out-of-order events, dokładnie-once, checkpointy, reprocessing, semantyka czasu zdarzenia kontra czasu przetworzenia, spóźnione wiadomości, dead-letter queue i cały ten zestaw rzeczy, które robią się zabawne dopiero na produkcji.

Jeśli biznes nie umie powiedzieć, po co mu świeżość danych liczona w sekundach, nie zakładaj streamingu tylko dlatego, że brzmi nowocześnie.

Orkiestracja: kto odpala co i skąd wiadomo, że już można

Pipeline’y rzadko żyją samotnie. Jedna tabela zależy od drugiej, embeddingi zależą od opublikowanych dokumentów, model scoringowy zależy od gotowych feature’ów, a raport zależy od zamknięcia dnia. To oznacza potrzebę orkiestracji.

Narzędzia typu Apache Airflow, Prefect czy Dagster rozwiązują dokładnie ten problem: deklarujesz zależności, harmonogramy, retry, parametry i sposób obserwacji przepływu pracy. W praktyce to jest warstwa, która odpowiada na pytania: co ma się uruchomić, kiedy, w jakiej kolejności, z jaką polityką błędów i jak to prześledzić po fakcie.

Przykładowy szkic DAG-a dla prostego pipeline’u dokumentowego może wyglądać tak:

with dag("document_ingestion"):
    raw = extract_from_sources()
    normalized = normalize_documents(raw)
    quality_ok = validate_documents(normalized)
    chunks = chunk_documents(normalized)
    embeddings = generate_embeddings(chunks)
    upsert_vector_index(embeddings)
    publish_metadata()

    raw >> normalized >> quality_ok >> chunks >> embeddings >> upsert_vector_index
    quality_ok >> publish_metadata

Taki DAG nie opisuje tylko kolejności. On ujawnia architekturę odpowiedzialności. Jeśli walidacja nie przejdzie, nie generujesz embeddingów. Jeśli embeddingi się wysypią, nie publikujesz indeksu. To jest fundamentalne dla AI: model ma działać na danych, które przeszły kontrolę jakości, a nie na danych „jakie akurat przyszły”.

Medallion, warstwy i po co ci raw data

W świecie lakehouse bardzo popularne stało się myślenie warstwami typu bronze, silver, gold. Nie trzeba kochać nazewnictwa, ale sama idea jest sensowna. Raw layer trzyma dane w możliwie wiernej postaci źródłowej. Cleaned or conformed layer porządkuje schematy, typy, deduplikację i podstawową semantykę. Curated layer daje już byty przygotowane pod konkretne przypadki użycia: raporty, modele, cechy, tabele aplikacyjne.

Po co to wszystko? Bo bez raw layer szybko tracisz możliwość odtworzenia prawdy historycznej. Jeśli jedyne, co masz, to „już przekształcona tabela wynikowa”, każda zmiana logiki oznacza zgadywanie, jak wyglądał input. Dla AI to szczególnie bolesne. Chcesz przetestować nowy embedding model? Potrzebujesz wrócić do surowych dokumentów. Chcesz zmienić definicję cechy churn? Musisz przeliczyć historyczne dane według nowej logiki. Chcesz sprawdzić, czy model zaczął się degradować przez zmianę upstreamu? Musisz mieć z czym porównać wejścia.

To trochę jak z git. Jeśli trzymasz tylko finalny build, nie zrozumiesz, skąd wziął się bug. Potrzebujesz historii zmian i punktów odniesienia. Raw data jest takim git history dla świata danych.

CDC, snapshoty i skąd wiesz, co się właściwie zmieniło

W bardzo wielu systemach nie chodzi o to, żeby co godzinę skopiować cały świat od nowa. Chodzi o to, żeby wiedzieć, co się zmieniło od ostatniego przebiegu. I tu wchodzi temat CDC, czyli Change Data Capture. Jeśli system źródłowy jest bazą transakcyjną, logiem zdarzeń albo API z sensownymi znacznikami czasu zmian, możesz budować pipeline’y inkrementalne zamiast ciągle robić full refresh.

To ma gigantyczne znaczenie dla AI. Weź prosty przykład: masz katalog produktów, z którego budujesz embeddingi do wyszukiwania semantycznego. Nie chcesz co noc generować embeddingów dla 8 milionów rekordów tylko dlatego, że 11 tysięcy z nich dostało nowy opis lub zmieniło cenę. Chcesz wykryć różnicę, wyciągnąć tylko zmienione rekordy, przepuścić je przez pipeline wzbogacania i podmienić reprezentację w indeksie. To samo dotyczy feature’ów, datasetów treningowych, tabel agregatowych i wielu przepływów analitycznych.

W praktyce są trzy częste strategie. Pierwsza to timestamp watermark, czyli przetwarzanie rekordów z updated_at > last_successful_run. Proste i skuteczne, dopóki upstream uczciwie aktualizuje pole czasu i dopóki umiesz obsłużyć poprawki historyczne. Druga to CDC z logu zmian bazy lub event streamu, co daje większą precyzję i zwykle lepszy model odtworzenia. Trzecia to snapshot diff, czyli porównanie dwóch stanów i wyliczenie różnic, przydatne tam, gdzie źródło nie oferuje dobrych zdarzeń zmian.

Każda z tych strategii ma pułapki. Timestamp watermark brzmi pięknie, dopóki ktoś nie zrobi ręcznej poprawki bez zmiany updated_at. CDC z logu transakcyjnego jest mocne, ale wprowadza operacyjną złożoność i wymaga sensownego mapowania zdarzeń domenowych. Snapshot diff bywa kosztowny i nie zawsze łatwo odróżnia prawdziwą zmianę biznesową od zmiany technicznej. Ale niezależnie od implementacji, sam sposób myślenia jest kluczowy: pipeline powinien umieć rozpoznać zmianę jako zdarzenie pierwszej klasy, a nie liczyć, że pełny reload rozwiąże wszystko.

To jest też ważne z punktu widzenia kosztu i świeżości. Inkrementalne przetwarzanie pozwala reagować szybciej i taniej. W AI to często robi różnicę między systemem, który może sensownie odświeżać wiedzę i cechy kilka razy dziennie, a systemem, który aktualizuje wszystko raz na dobę i modli się, żeby wystarczyło.

Data quality: testy dla świata, którego model nie wybacza

Najbardziej niebezpieczne błędy danych to nie te, które od razu wywalają pipeline. Najgorsze są te, które przechodzą dalej i produkują wiarygodnie wyglądające bzdury. Null w kolumnie, która „nigdy nie jest nullem”. Przesunięcie strefy czasowej o godzinę. Duplikaty eventów po retry. Zmiana nazwy wartości enum bez komunikatu. Embeddingi wygenerowane na pustym tekście po błędzie parsera PDF. Wszystko to potrafi przejść przez system bardzo daleko, zanim ktoś zauważy, że wynik jest subtelnie zły.

Dlatego data quality nie jest dodatkiem dla perfekcjonistów. To jest odpowiednik testów i monitoringu. Dobre quality checks pilnują kilku rzeczy naraz: zgodności schematu, kompletności, zakresów wartości, unikalności kluczy, relacji między tabelami, spójności czasowej i sensownych rozkładów danych. Narzędzia typu Great Expectations, Soda, dbt tests, Pandera czy Evidently nie rozwiązują wszystkiego, ale wymuszają zdrowy odruch: dane są kontraktem, a nie przypadkowym payloadem.

Przykład prostego quality gate w Pythonie:

import pandera as pa
from pandera import Column, Check

customer_schema = pa.DataFrameSchema(
    {
        "customer_id": Column(str, nullable=False, unique=True),
        "orders_30d": Column(int, Check.ge(0)),
        "revenue_90d": Column(float, Check.ge(0.0)),
        "country": Column(str, nullable=False),
    }
)

validated_df = customer_schema.validate(feature_df)

To nie jest akademicka ozdoba. To jest mechanizm, który zatrzymuje pipeline, zanim model zacznie udawać, że rozumie świat na podstawie popsutych wejść.

Data quality nie jest luksusem dla analityki. To jest warstwa obronna przed tym, żeby produkt AI nie podejmował decyzji na semantycznie uszkodzonych danych.

Głębsze niuanse: jak to działa pod spodem, kiedy skala i AI zaczynają boleć

Dobra, to teraz trudniejsza część. Bo na poziomie slajdów data engineering wygląda schludnie: źródła danych, pipeline, warehouse, dashboard, model, sukces. W praktyce robi się ciekawie tam, gdzie pojawiają się opóźnienia, zmiana schematu, ponowne przeliczenia, duże wolumeny i wiele reprezentacji tych samych danych. A w AI te reprezentacje mnożą się szybciej niż w klasycznej analityce, bo masz jeszcze features, embeddingi, snapshoty treningowe i kontekst retrievalowy.

Big Data to nie tylko rozmiar, ale też kształt problemu

Wiele osób słyszy „Big Data” i myśli: petabajty, klaster Spark, dziesiątki node’ów i budżet AWS-a topniejący szybciej niż cierpliwość FinOpsu. Czasem tak. Ale dla AI Engineera ważniejsze jest zrozumienie, że big data to często nie tylko kwestia rozmiaru. To także szybkość napływu, różnorodność formatów, liczba zależności, potrzeba przetwarzania historycznego i konsekwencje błędów przy dużej skali.

Możesz mieć system, który wcale nie ma petabajtów, ale jest big data problemem, bo produkuje miliony eventów dziennie, wymaga łączenia danych z pięciu domen, ma streaming, backfill, model scoringowy i indeks dokumentów aktualizowany na bieżąco. Możesz też mieć wielkie archiwum plików, które nie jest operacyjnie trudne, bo obrabiasz je raz w tygodniu. Sam wolumen nie mówi całej prawdy.

Lake, warehouse i lakehouse: o co tu naprawdę chodzi

Przez lata mieliśmy prostą narrację. Data warehouse to uporządkowane, zwykle SQL-owe centrum analityki. Data lake to tańsze, bardziej surowe składowisko danych, zwykle na object storage. Potem wszyscy odkryli, że warehouse bywa drogi do surowego składowania wszystkiego, a lake bywa chaotyczny jak folder final_final_v2_real. I tak pojawił się lakehouse.

Lakehouse to próba połączenia dwóch światów: taniego i skalowalnego storage’u z lepszą semantyką tabelaryczną, transakcjami, wersjonowaniem, schematami i wydajnym odczytem. W praktyce oznacza to często pliki Parquet na obiektowym storage’u plus warstwę formatu tabelarycznego, takiego jak Delta Lake, Apache Iceberg albo Apache Hudi, które dodają rzeczy, których zwykły katalog plików nie umie: ACID-ish table operations, snapshoty, schema evolution, time travel, compaction i zarządzanie metadanymi.

Dlaczego to jest ważne dla AI? Bo AI kocha dane pochodne i historię. Chcesz odtworzyć dataset treningowy z konkretnego dnia? Time travel pomaga. Chcesz przeliczyć embeddingi tylko dla rekordów, które zmieniły się od ostatniego snapshotu? Tabela z dobrym modelem zmian pomaga. Chcesz mieć jednocześnie tani storage surowych danych i sensowne SQL-owe transformacje nad nimi? Lakehouse często daje bardziej elastyczny kompromis niż klasyczne „wszystko w warehouse” albo „wszystko w jeziorze i jakoś to będzie”.

Ale uwaga: lakehouse nie jest magicznym zaklęciem, które naprawia kiepski model danych. Jeśli wrzucasz do niego bałagan bez kontraktów i bez planu publikacji warstw, dostaniesz po prostu lepiej ubranego bałagana.

Schema evolution i późno przychodzące dane

Jednym z najmniej romantycznych, ale najbardziej praktycznych problemów jest schema evolution. Źródła danych się zmieniają. Ktoś doda pole do eventu. Ktoś zmieni typ z int na string. Ktoś zacznie wysyłać null, bo „to pole już nie jest obowiązkowe”. Jeśli pipeline jest kruchy, całość wybuchnie. Jeśli pipeline jest zbyt pobłażliwy, przepuści zmianę i popsuje downstream po cichu.

Do tego dochodzą late-arriving events. W batchu jeszcze da się to ogarnąć oknami czasowymi i watermarkami. W streamingu dochodzi bardziej subtelna logika: zdarzenie z wczoraj może pojawić się dziś, ale nadal powinno wpłynąć na agregat liczony według czasu zdarzenia, a nie czasu przyjścia. Jeśli o tym zapomnisz, modele czasu rzeczywistego zaczną uczyć się i działać na zniekształconej rzeczywistości.

To jest ten moment, w którym data engineering przestaje być „przenoszeniem danych”, a staje się modelowaniem czasu, stanu i prawdy biznesowej.

Exactly-once to często marzenie, a nie stan natury

Tutoriale streamingowe lubią rzucać hasłem exactly-once tak, jakby dało się je kupić na licencji rocznej. W praktyce to bardziej zbiór warunków i kompromisów niż darmowy prezent od technologii. W realnych pipeline’ach częściej projektujesz system tak, żeby duplikaty dało się bezpiecznie zneutralizować, niż zakładasz metafizyczną doskonałość dostarczenia wiadomości dokładnie raz.

Dlatego kluczowe są klucze biznesowe, upsert, deduplikacja, checkpointing i publikowanie wyników w sposób odporny na powtórzenia. Jeśli twój feature pipeline przy retry podwaja liczbę zakupów klienta, model nie będzie miał pojęcia, że to błąd integracyjny. On po prostu zobaczy „aktywniejszego klienta”. I potem wszyscy będą godzinami debugować ranking, który w rzeczywistości został popsuty dużo wcześniej.

Feature pipeline’y: ML żyje na tych samych danych co produkt, ale nie zawsze w tej samej formie

W klasycznym software bywa tak, że baza aplikacyjna i analityka istnieją obok siebie, ale nie muszą być idealnie zsynchronizowane co do każdej kolumny. W ML i AI robi się trudniej, bo feature pipeline tworzy reprezentację świata, na której model się uczy albo podejmuje decyzje. Jeśli sposób liczenia feature’ów w treningu różni się od sposobu liczenia ich online, masz klasyczny problem training-serving skew.

To znaczy tyle: model nauczył się na jednych danych, a w produkcji dostaje trochę inne. W efekcie nie trzeba nawet błędu w modelu. Wystarczy niespójny pipeline.

Dlatego dobre feature pipeline’y pilnują kilku rzeczy:

jednej definicji cechy,
jawnego czasu obowiązywania,
możliwości backfillu,
wersjonowania,
zgodności między offline i online servingiem,
lineagu: skąd dana cecha się wzięła.

Jeśli ktoś mówi „to tylko kilka agregatów SQL”, a potem próbuje tym zasilać ranking lub model scoringowy na produkcji, zwykle niedocenia skali problemu.

Embedding pipeline’y: RAG też jest data engineeringiem

To jest moment, w którym AI Engineer często odkrywa, że robi data engineering, nawet jeśli nie używa tego słowa. Budowa indeksu RAG to przecież nic innego jak pipeline danych: pobierasz źródła, parsujesz, czyścisz, dzielisz na chunki, wzbogacasz metadane, generujesz embeddingi, zapisujesz indeks, testujesz jakość i aktualizujesz tylko to, co się zmieniło.

I tu zaczynają się prawdziwe problemy. Parser PDF-a zgubił tabelę. Chunking rozciął dokument w fatalnym miejscu. Embedding model został zmieniony, ale połowa indeksu nadal jest stara. Metadane tenantów nie zostały zsynchronizowane. Dokument został usunięty w source of truth, ale w indeksie wciąż żyje. System retrievalu odpowiada na podstawie treści, której już nie powinno być. Brzmi znajomo? To nie jest problem promptu. To jest problem pipeline’u.

Przykładowy szkic embedding pipeline’u z wersjonowaniem może wyglądać tak:

def refresh_embeddings(document_id: str, embedding_model_version: str) -> None:
    document = load_document_source(document_id)
    cleaned = sanitize_document(document)
    chunks = split_into_chunks(cleaned, strategy="semantic-v3")

    rows = []
    for chunk in chunks:
        rows.append(
            {
                "document_id": document_id,
                "chunk_id": chunk.id,
                "chunk_text": chunk.text,
                "embedding": embed(chunk.text, model=embedding_model_version),
                "embedding_model_version": embedding_model_version,
                "chunking_version": "semantic-v3",
                "source_updated_at": document.updated_at,
            }
        )

    replace_index_rows(document_id=document_id, rows=rows)

Kluczowe są tu nie same embeddingi, tylko to, że w indeksie masz wersję modelu, wersję chunkingu, powiązanie ze źródłem i możliwość pełnej wymiany reprezentacji dokumentu. Bez tego reindex staje się ruletką, a nie kontrolowanym procesem.

Jest jeszcze jedna warstwa, o której techniczne teksty mówią za rzadko: organizacja danych. Bo nawet najładniejszy pipeline nie uratuje cię, jeśli nikt nie wie, kto odpowiada za event order_paid, kto utrzymuje tabelę customer_profile, kto zatwierdza zmianę semantyki pola is_active i kto ma prawo powiedzieć „ten feed nie spełnia kontraktu, nie publikujemy go dalej”.

Tu pojawiają się data contracts. Idea jest prosta i bardzo software’owa: źródło i odbiorca uzgadniają nie tylko nazwę payloadu, ale też jego schemat, znaczenie, wymagania jakościowe, SLA świeżości i sposób komunikowania zmian. To trochę jak API contract, tylko dla danych. Bez tego zespoły downstream żyją w świecie domysłów. Dzisiaj pole istnieje, jutro znika, pojutrze zmienia znaczenie, a za tydzień wszyscy debugują model, który „nagle zgłupiał”.

W produktach AI jest to jeszcze ważniejsze, bo jedna zmiana upstreamu może uderzyć w kilka warstw naraz. Zmieniasz event produktu i nagle psują się dashboardy, feature pipeline, system personalizacji oraz monitoring driftu. Ktoś usuwa status dokumentu w CMS-ie i indeks RAG przestaje umieć rozróżnić szkic od opublikowanej treści. Ktoś zmienia jednostkę w polu przychodowym, a ranking klientów zaczyna traktować grosze jak złotówki. Tak, to są bardzo przyziemne awarie. I właśnie dlatego są groźne.

Dobre data contracts zwykle obejmują minimum takich rzeczy jak:

definicję pola i jego znaczenie biznesowe,
format i typ danych,
zasady nullowalności,
oczekiwaną częstotliwość dostarczania,
politykę wersjonowania zmian,
właściciela technicznego i właściciela biznesowego.

Brzmi nudno? Jasne. Dokładnie tak samo nudno brzmi dobrze utrzymane API, dopóki nie zobaczysz kosztu chaosu bez niego. AI bardzo szybko karze brak takich kontraktów, bo modele i pipeline’y pochodne są z natury wrażliwe na ciche przesunięcia semantyczne. Developer zwykle myśli o błędach typu exception albo timeout. Data engineering uczy jeszcze jednej klasy awarii: system działa, tylko znaczenie danych już nie jest tym, czym było wczoraj.

Małe pliki, partycje i koszty, o których nikt nie mówi na konferencji

Jeśli wejdziesz głębiej w lakehouse albo duże warehouse, szybko trafisz na problemy, które nie brzmią spektakularnie, ale realnie bolą. Small file problem potrafi zabić wydajność, bo system zamiast czytać sensowne segmenty danych, dusi się na tysiącach drobnych plików i metadanych. Złe partycjonowanie sprawia, że query skanują za dużo. Nadmiar materializacji robi z pipeline’u kosztowną fabrykę duplikatów. Źle zaplanowany backfill potrafi zabić zarówno budżet, jak i inne workloady.

To są rzeczy, które senior backendowiec szybko rozpozna jako odpowiednik problemów z N+1, złą strategią cache’a albo nadmiarem chatty calls między serwisami. Narzędzia są inne, ale zasada ta sama: wydajność i koszt wynikają z kształtu danych i dostępu do nich, nie tylko z tego, że „mamy mocny silnik”.

Praktyczne zastosowania: gdzie data engineering naprawdę spotyka AI

1. Feature pipeline dla modelu scoringowego albo rankera

Załóżmy, że budujesz system oceny jakości leadów albo ranking ticketów supportowych. Model ma przewidywać priorytet, prawdopodobieństwo konwersji albo ryzyko churnu. Brzmi modelowo, ale najwięcej pracy zwykle jest przed modelem.

Musisz zaciągnąć dane z CRM, billing, eventów produktowych, historii kontaktu i może jeszcze z narzędzi marketingowych. Potem zbudować cechy typu liczba aktywności z 7 i 30 dni, przychód z 90 dni, liczba otwartych ticketów, czas od ostatniego logowania, trend użycia produktu, a do tego pilnować, żeby wszystko było policzone względem właściwego punktu w czasie. Bo jeśli do treningu użyjesz danych „z przyszłości”, model będzie wyglądał genialnie i kompletnie się rozpadnie w produkcji.

Tu data engineering robi całą krytyczną robotę. Definiuje cechy, pilnuje czasu referencyjnego, robi backfill historii, waliduje rozkłady i publikuje te same definicje offline do treningu i online do inferencji. Bez tego model jest tylko dekoracją nad źle policzonymi liczbami.

2. RAG i indeks wiedzy, który nie kłamie po cichu

Drugi use case to system retrievalowy dla dokumentacji, procedur, umów, ofert, ticketów i innych treści tekstowych. Tutaj wiele osób zaczyna od myślenia: wrzucimy PDF-y, zrobimy embeddingi, podłączymy LLM i gotowe. Potem przychodzi rzeczywistość. Dokumenty mają wersje, widoczność per tenant, status publikacji, różne języki, załączniki, tabele, changelogi i czasem ładują się z pięciu systemów. Jeśli chcesz to później sensownie oceniać, nie uciekasz od pytań o jakość retrievalu, o czym szerzej pisałem przy RAG evals i metrykach RAGAS.

Dobry RAG wymaga pipeline’u, który umie:

pobrać i znormalizować źródła,
wykryć zmiany,
parsować różne formaty,
walidować minimalną jakość tekstu,
aktualizować embeddingi tylko tam, gdzie trzeba,
usuwać stare wpisy z indeksu,
publikować metadata filters zgodne z uprawnieniami.

Jeśli tego nie masz, produkt zaczyna po cichu gnić. Demo dalej działa, bo indeks ma „jakieś” dokumenty. Tylko niekoniecznie właściwe.

3. Streaming do personalizacji i detekcji anomalii

Trzeci use case to przypadki, gdzie realnie liczy się świeżość. Na przykład aplikacja e-commerce, która chce aktualizować rekomendacje w trakcie sesji. Albo system finansowy wykrywający podejrzane wzorce zachowania. Albo agent operacyjny reagujący na stan procesu niemal na żywo.

Tutaj wchodzą eventy, Kafka, Flink, Spark Structured Streaming albo lżejsze warianty stream processingu. Dane napływają w ciągu sekund, są łączone z kontekstem historycznym, trafiają do feature store, cache’a, tabel operacyjnych albo bezpośrednio do inferencji. To potężne, ale wrażliwe. Każde opóźnienie, niespójność klucza albo błąd deduplikacji szybko przekłada się na decyzję produktu.

Przykładowy pseudokod konsumenta streamu może wyglądać tak:

for event in kafka_consumer("product-events"):
    parsed = parse_event(event)
    if is_duplicate(parsed.event_id):
        continue

    session_state = load_session_state(parsed.user_id)
    updated_state = apply_event(session_state, parsed)
    save_session_state(parsed.user_id, updated_state)

    if should_refresh_recommendations(updated_state):
        features = build_online_features(updated_state)
        score = model.predict(features)
        publish_recommendation(parsed.user_id, score)

Kod wygląda prosto, ale pod spodem siedzą wszystkie trudne rzeczy: identyfikacja duplikatów, stan sesji, zgodność feature’ów z treningiem, latencja i odporność na błędy.

4. Pipeline dla embeddingów i wyszukiwania hybrydowego

Czwarty przypadek, dziś bardzo częsty, to system łączący klasyczne filtry, pełnotekst i wyszukiwanie semantyczne. Na przykład wyszukiwarka wiedzy wewnętrznej, gdzie użytkownik oczekuje, że znajdzie dokument po nazwie produktu, po numerze incydentu i po sensie pytania, nawet jeśli używa innych słów niż autor dokumentu. Jeśli pracujesz z wyszukiwaniem hybrydowym, praktyczne tło daje też przewodnik o integracji aplikacji z Elasticsearch.

Wtedy pipeline danych musi przygotować kilka reprezentacji tego samego źródła naraz: treść do pełnotekstu, metadane do filtrów, embedding do semantyki, a czasem jeszcze podsumowanie albo extracted entities do dodatkowego rerankingu. To już nie jest „wrzuć dane do bazy”. To jest świadome budowanie wielu warstw odczytu dla różnych mechanizmów wyszukiwania.

5. Observability modeli i danych wejściowych

Piąty use case jest mniej widowiskowy, ale absolutnie krytyczny: monitoring tego, co w ogóle trafia do modeli. Jeśli model klasyfikacyjny zaczyna widzieć inny rozkład cech niż podczas treningu, jeśli agent dostaje coraz dłuższe lub dziwnie sparsowane konteksty, jeśli parser dokumentów po cichej zmianie upstreamu produkuje puste teksty, to problem trzeba zauważyć zanim zauważy go klient.

To znowu jest data engineering. Musisz zebrać sygnały, policzyć statystyki, porównać je w czasie, zdefiniować progi alarmowe i umieć przejść od alertu do konkretnego źródła. Evidently, customowe joby jakościowe, telemetryczne tabele kontrolne, lineage i dashboardy operacyjne stają się częścią tego samego systemu. AI bez obserwacji danych jest trochę jak Kubernetes bez logów i metryk. Technicznie istnieje. Operacyjnie powodzenia.

Szósty przypadek jest mniej widoczny dla użytkownika końcowego, ale krytyczny dla zespołu budującego modele: przygotowanie datasetów treningowych i ewaluacyjnych. Jeśli dziś trenujesz model na zbiorze wygenerowanym „jakimś notebookiem”, a za dwa miesiące chcesz odtworzyć ten sam eksperyment, szybko okaże się, że bez data engineeringu nie masz nauki, tylko improwizację.

Potrzebujesz wiedzieć, z jakich źródeł pochodziły dane, według jakiej logiki zostały odfiltrowane, jak wyglądał snapshot czasowy, jakie rekordy odrzucono, które etykiety były jeszcze surowe, a które już poprawione, i jak powiązać to z wersją feature’ów albo promptów. Inaczej każda dyskusja o tym, czy model naprawdę się poprawił, zaczyna przypominać rozmowę o benchmarku z pamięci. A to jest słaby tryb pracy dla zespołu, który chce budować coś stabilnego.

W praktyce oznacza to, że pipeline do datasetów powinien być traktowany jak produkcyjny artefakt: z wersjami, z jakością, z możliwością odtworzenia i z kontrolowanym publikowaniem. Dla AI Engineera to bardzo cenna lekcja, bo pokazuje, że eksperymenty też potrzebują porządnej infrastruktury danych, a nie tylko sprytnego notebooka i odrobiny szczęścia.

Typowe błędy i pułapki

Najczęstszy błąd brzmi: „najpierw zbudujmy model, dane się potem ogarnie”. Mówiąc wprost: to jest jedna z głównych dróg do produktów AI, które imponują przez dwa sprinty, a potem żyją na ręcznym podtrzymywaniu przy życiu. Jeśli nie masz kontrolowanego dopływu danych, to nie masz stabilnego systemu. Masz tylko bardziej wyrafinowany frontend do chaosu.

Drugi błąd to wiara, że jakość danych rozwiąże się sama, jeśli tylko wybierzesz modne narzędzie. Nie rozwiąże. Airflow nie naprawi źle zdefiniowanych kontraktów. Kafka nie nada sensu eventom o niespójnym schemacie. Lakehouse nie sprawi magicznie, że zespoły zaczną rozumieć, która tabela jest źródłem prawdy. dbt nie obroni cię przed złą semantyką biznesową. Narzędzia pomagają, ale nie zastępują architektury.

Trzeci błąd to niedocenianie backfillu. Zmiana definicji cechy, zmiana chunkingu, nowy embedding model, korekta błędu parsera, dopisanie brakującego źródła, poprawa logiki sesji. To wszystko prędzej czy później wymaga przeliczenia historii. Jeśli twój system nie umie tego zrobić w kontrolowany sposób, każdy większy upgrade staje się projektem migracyjnym z poziomem stresu godnym cutoveru bazy danych w banku.

Czwarty błąd to mylenie dashboardowej poprawności z poprawnością produkcyjną. To, że agregat wygląda sensownie w BI, nie znaczy jeszcze, że nadaje się jako feature online. To, że embeddingi powstały, nie znaczy jeszcze, że są zgodne z aktualnym stanem dokumentów. To, że pipeline ma zielony status, nie znaczy, że wynik jest semantycznie poprawny. Dobre systemy danych pilnują zarówno powodzenia technicznego, jak i jakości merytorycznej.

Piąty błąd to budowanie streamingu tam, gdzie wystarczyłby batch. Tak, serio. Wiele zespołów wchodzi w Kafka i stream processing zbyt wcześnie, bo brzmi to jak krok w stronę dojrzałości. A potem miesiącami utrzymuje złożoność, która nie wnosi proporcjonalnej wartości biznesowej. Jeśli aktualizacja co 15 minut rozwiązuje problem, nie buduj platformy do reakcji w 800 milisekund tylko po to, żeby móc powiedzieć, że masz real-time AI.

Szósty błąd to brak własności danych. Kiedy nikt nie wie, kto odpowiada za definicję pola, tabeli, eventu albo jakości feedu, pipeline’y stają się politycznym polem minowym. W AI wychodzi to wyjątkowo szybko, bo model konsumuje sygnały z wielu domen jednocześnie. Bez właścicieli, kontraktów i lineagu każda awaria zamienia się w archeologię organizacyjną.

Ecosystem i narzędzia, które warto naprawdę znać

Jeśli chodzi o orkiestrację, klasykiem pozostaje Apache Airflow. Jest dojrzały, wszechobecny i ma ogromny ekosystem, choć jego DX bywa bardziej „enterprise archaeology” niż lekka przyjemność. Prefect i Dagster są zwykle przyjemniejsze w codziennej pracy, lepiej eksponują nowoczesny Pythonowy workflow i sensowniej podchodzą do obserwowalności. Który wybrać? Jeśli wchodzisz do istniejącej dużej organizacji, często zastaniesz Airflow. Jeśli budujesz nowy stack i zależy ci na szybszej iteracji, Prefect albo Dagster potrafią być bardziej ludzkie. I tak jak przy innych narzędziach AI, warto pilnować, żeby wybór technologii nie stał się celem samym w sobie, co szerzej opisałem w tekście o frameworkach i narzędziach AI bez hype’u.

W transformacjach analitycznych dbt stał się praktycznie standardem tam, gdzie głównym językiem transformacji jest SQL. I nie bez powodu. Testy, lineage, modularizacja modeli, dokumentacja i sensowny workflow pod review robią z transformacji danych coś bliższego software engineeringowi niż zestawowi plików .sql wrzuconych do współdzielonego folderu. Jeśli jesteś seniorem od backendu i chcesz wejść głębiej w data engineering, dbt jest jednym z tych narzędzi, które bardzo szybko porządkują myślenie.

Przy większym przetwarzaniu rozproszonym nadal ważny jest Apache Spark. To nie jest najbardziej seksi technologia na slajdzie, ale wciąż rozwiązuje ogrom klasy problemów: batch na dużych danych, ETL, streaming, joiny na dużych zbiorach, feature engineering, przygotowanie datasetów. Flink częściej wygrywa tam, gdzie streaming i event time są naprawdę centralne. Beam daje bardziej abstrakcyjny model, ale nie wszędzie zyskał taką trakcję operacyjną, jak sugerowały ambicje.

W messagingu i streamingu Kafka nadal jest bardzo mocną pozycją, zwłaszcza w organizacjach z większą skalą i potrzebą trwałych event logów. Prostsze systemy potrafią świetnie działać na RabbitMQ, cloudowych kolejkach albo pub/subach, ale jeśli mówimy o szerokim ekosystemie data engineeringowym, Kafka jest językiem wspólnym dla ogromnej części rynku.

W warstwie storage i analityki warto znać kilka rodzin narzędzi, a nie tylko jedno logo. Snowflake jest bardzo silny tam, gdzie liczy się łatwość operacyjna, odseparowany compute i dobra ergonomia SQL. BigQuery błyszczy w środowiskach GCP i w analityce serverless na wielkich danych. DuckDB jest fenomenalny lokalnie i do lekkich workflowów, eksploracji plików i mniejszych pipeline’ów. W lakehouse warto rozumieć rolę Delta Lake, Apache Iceberg i Parquet, nawet jeśli nie wdrażasz ich jutro. To już nie jest nisza. To jest język nowoczesnego storage’u danych.

Jeśli chodzi o jakość i obserwowalność, warto kojarzyć Great Expectations, Soda, Pandera, dbt tests i Evidently. Żadne z nich nie zrobi za ciebie semantyki biznesowej, ale każde pomaga zamienić intuicję „chyba dane są ok” w coś, co da się uruchomić, raportować i zablokować przed publikacją.

Wreszcie rzecz ważna dla AI: feature store’y i wektorowe pipeline’y. Nie każda firma potrzebuje od razu pełnego feature store’a, ale warto rozumieć, po co istnieją narzędzia takie jak Feast: chodzi o spójność definicji cech między treningiem a servingiem. Z kolei w świecie embeddingów i RAG bardzo ważniejsze od samej bazy wektorowej bywa to, jak zaprojektujesz ingestion, wersjonowanie i reindex. Produkcyjnie sprawdzone są zwykle nudniejsze rozwiązania z jasnym source of truth i kontrolowanym pipeline’em. Hype pojawia się tam, gdzie ktoś sprzedaje „magiczny retrieval” bez rozmowy o jakości źródeł.

Podsumowanie i co dalej

Jeśli chcesz zapamiętać z tego tekstu jedną rzecz, niech będzie nią to: AI nie unieważnia data engineeringu, tylko podnosi jego stawkę. Model może być świetny, prompt może być dopracowany, architektura mikroserwisowa może błyszczeć na diagramie, ale jeśli dane przychodzą za późno, w złej formie, bez walidacji, bez lineagu i bez możliwości odtworzenia, to cały system staje się nieprzewidywalny. A nieprzewidywalność w produktach AI jest szczególnie droga, bo użytkownik widzi ją od razu w decyzjach, rekomendacjach i odpowiedziach.

W praktyce dojrzały AI Engineer powinien umieć patrzeć na problem nie tylko przez pryzmat modelu, ale przez cały łańcuch danych. Skąd przychodzi zdarzenie? Gdzie jest source of truth? Która warstwa jest raw, która jest curated, a która służy tylko do serving-u? Czy pipeline jest idempotentny? Jak działa backfill? Co się dzieje po zmianie schematu? Kto pilnuje jakości? Jak reindexujesz embeddingi? Czy feature liczony online jest naprawdę tym samym feature’em, na którym model był trenowany? To są pytania, które odróżniają system „AI-ready” od systemu „ładnie wygląda na demo”.

Jeśli chcesz pójść dalej praktycznie, zrób jedno konkretne ćwiczenie. Weź prosty produkt AI albo nawet własny side project z RAG-iem i rozpisz jego przepływ danych od początku do końca. Nie tylko API i model. Wszystko: źródła, walidację, transformacje, staging, publikację, embeddingi, monitoring, retry i sposób odtworzenia po awarii. Potem dodaj dwa quality gate’y i jedną strategię backfillu. To ćwiczenie uczy więcej niż kolejne trzy tutoriale o „budowie agenta w 20 minut”, bo nagle widzisz, gdzie naprawdę mieszkają problemy.

Mówiąc brutalnie: większość produktów AI nie przegrywa dlatego, że wybrały zły model. Przegrywa dlatego, że zbyt długo traktowały dane jak tło. A dane tłem nie są. Dane są systemem nerwowym całej aplikacji. Data engineering to nie hydraulika schowana w piwnicy. To jedna z głównych dyscyplin, które decydują, czy AI działa jak produkt, czy jak demo udające produkt.

Pozostałe definicje

Technical debt

User Story

Timebox

Agile

Definition of Done

Sprint Review

Data Engineering i Big Data w pracy AI Engineera to nie hydraulika w tle, tylko warstwa, która decyduje o jakości pipeline'ów, feature'ów, embeddingów i świeżości danych w produkcie AI.

Data Engineering i Big Data w pracy AI Engineera: pipeline’y, streaming, lakehouse i dyscyplina danych bez ściemy