Model w notebooku ma AUC 0,87. Na produkcji wniosek kredytowy czeka 14 dni, bo cecha „liczba transakcji 30d” liczy się ręcznym eksportem z GUI do CSV. Albo p99 inferencji skacze powyżej 500 ms, bo ktoś zserializował pickle z laptopa i wcisnął go w kontener bez Feature Store.
To nie jest problem algorytmu. To jest problem potoku. Analityka predykcyjna w enterprise pada na hybrydzie: Jupyter i Dataiku z jednej strony, Spark CLI, Airflow i kubectl z drugiej. Zespół klika, wkleja, eksportuje. Model się starzeje w tempie, w jakim rośnie backlog „do wdrożenia”.
Poniżej rozróżnienie, którego brakuje w briefach „szukamy Data Scientista”: kiedy wynająć jedną osobę (body leasing Data Science, staff augmentation), a kiedy potok wymaga squada DE + DS + MLOps. Stawki godzinowe rozpisaliśmy osobno: ile kosztuje body leasing IT w 2026. Tu liczymy, czemu sam AUC nie schodzi na produkcję.
Jedno zdanie, którego nie ma na slajdzie sprzedażowym
Data Scientist bez potoku danych to badacz z limitem 8 godzin na Jirze. Potok bez Data Scientista to ETL, który nic nie przewiduje. Body leasing jednej roli ma sens, gdy druga już siedzi w Waszym zespole. W przeciwnym razie kupujecie timesheet, nie predykcję.
1. Anatomia: notebook to nie produkt
Typowy dzień zespołu analityki predykcyjnej w banku, telco albo retailu nie wygląda jak tutorial scikit-learn. Wygląda jak przełączanie modalności:
- GUI: inspekcja jakości w narzędziu BI, ręczny eksport z hurtowni, kliknięcie retreningu w Dataiku / SageMaker Studio, podgląd dryfu w dashboardzie.
- CLI / API: Spark-submit, dbt run, airflow dags trigger, kubectl rollout, MLflow log, batch na BigQuery.
Każde przełączenie to miejsce, w którym ginie reprodukowalność. Cecha liczona w notebooku nie jest cechą liczoną w serwisie. To training-serving skew: model uczy się na definicji, której produkcja nie powtórzy. Sculley i in. nazwali to w 2015 pipeline jungles i glue code — dług technologiczny ML, który rośnie szybciej niż sam model.
Trzy objawy, że macie jungle, nie platformę:
- CSV jako interfejs. Źródło prawdy to plik z wczorajszego eksportu. Nikt nie umie powiedzieć, z której tabeli i z jakim filtrem.
- Cecha liczona dwa razy. Pandas na laptopie, SQL w Airflow. Różnica 0,3 pp w fill-rate wychodzi po kwartale, gdy drift jest już w decyzji kredytowej.
- Deployment jako bilet do DevOps. Data Scientist kończy na „model.pkl”. Ktoś inny pakuje obraz, ktoś trzeci ustawia probe. Czas od pomysłu na cechę do inferencji: tygodnie, nie dni.
Dlatego brief „wynajem Data Scientista” bez kontekstu potoku jest najdroższym sposobem na kolejny notebook. Kompetencje, które faktycznie składają analitykę predykcyjną, siedzą na trzech landingach: Data Science i BI, Data Engineering, MLOps.
2. Co mówią badania, nie decki MLOps
Nie potrzebujecie kolejnej definicji „MLOps maturity”. Potrzebujecie granic, przy których model nie wychodzi z laboratorium.
- Dług ML jest w kleju, nie w vacie. Sculley et al., Hidden Technical Debt in Machine Learning Systems (NIPS 2015): w systemach ML kod uczenia to zwykle mały ułamek. Reszta to konfiguracja, zbieranie danych, weryfikacja, serving, monitoring. „Zmiana jednej cechy” pociąga lawinę, bo zależności są ukryte. Pipeline jungle powstaje, gdy nowe ścieżki dokładacie zamiast usuwać stare.
- Praca na komputerze jest hybrydowa. Shi, Wang, Fang, Liang et al., CUA-Universe (arXiv:2609.05374, wrzesień 2026): realna praca łączy inspekcję stanu wizualnego z precyzyjnym CLI na wspólnym stanie aplikacji. Agenty GUI-only produkują nieefektywne trajektorie; agenty CLI-only ślepną na layout. Trening na hybrydzie GUI+CLI dał modelowi 9B: CUA-Verse +39,3 pkt, −37% kroków, −60% tokenów; OSWorld SR +16,8 pkt, −57% kroków, −44% tokenów. To nie jest paper o scoringu kredytowym. To jest pomiar, ile kosztuje żonglowanie oknem i terminalem. Zespół Data Science, który klika w Studio i wkleja komendy do Confluence, płaci ten sam podatek.
- Dostarczanie liczy zespół, nie notebook. DORA 2024: elite vs low to rząd wielkości w częstotliwości deployu i lead time zmian. Te liczby opisują zespoły ze wspólnym Definition of Done. Pięć osobnych timesheetów (DS z vendora A, DE z B, „ktoś od Kubernetesa” z C) nie złoży lead time’u. Złoży trzy SLA zastępstwa i jeden status „in progress”. Anatomię tego błędu rozpisaliśmy w team leasing vs body leasing 2026.
Kluczowy wniosek architektoniczny
Standaryzacja potoku to nie „kupić SageMaker”. To zlikwidować przełączanie GUI↔CLI tam, gdzie da się je zastąpić API i IaC. Feature Store, jeden DAG, jeden obraz servingowy, test schematu na PR. Reszta to kosmetyka vendorów. Jeśli Wasz Data Scientist nie może odtworzyć cechy z commita, nie macie analityki predykcyjnej. Macie demo.
3. Studium z produkcji: scoring, który spóźniał się o sprint
Z praktyki inżynieryjnej: od 3 tygodni do 3 dni
Instytucja finansowa, portfel rzędu milionów klientów. Scoring wniosków i detekcja fraudu. Źródła: Oracle / PostgreSQL, data lake (S3 + Hive), logi w Elasticsearch. Zespół analityki predykcyjnej pracował tak:
- ekstrakcja: ręczne SQL, eksport CSV,
- cechy: Pandas na laptopie, sklejanie w Excelu „na wszelki wypadek”,
- trening: GUI platformy Dataiku, ręczny eksport artefaktu,
- wdrożenie: bilet do DevOps, Docker „jak wyjdzie”, API Gateway, Kubernetes bez testu schematu.
Problem: od pomysłu na cechę do inferencji 3–4 tygodnie. Modele były nieaktualne w dniu startu. p99 kluczowych predykcji > 500 ms. Koszt utrzymania rósł z każdym nowym pickle.
Zmiana: potoki Spark orkiestrowane Airflowem do Feature Store (Hopsworks). Każdy etap (dane, trening, walidacja, serving) w obrazie. GitOps na klaster. Monitoring dryfu cech i jakości danych (Prometheus / Grafana). DS przestaje eksportować CSV. DE przestaje zgadywać, którą wersję cechy wziąć do batcha.
Pomiar po wdrożeniu: czas do produkcji 3 dni zamiast 3 tygodni. Błędy potoku i deployu −85%. p99 inferencji < 80 ms. Koszt infrastruktury MLOps −40% — nie przez tańszą chmurę, przez brak ręcznych interwencji i porzuconych retreningów.
Ten wynik nie powstał z „lepszego XGBoosta”. Powstał z tego, że GUI zostało do inspekcji, a CLI/API do ścieżki, która musi się powtórzyć o 3:00 w nocy. To jest ta sama lekcja, którą CUA-Universe mierzy na agentach: hybryda działa, gdy obie modalności mają wspólny stan — nie gdy człowiek jest szyną między oknami.
4. Tabela decyzyjna: jaki potok, jaki skład
| Podejście | Złożoność | Latencja p95/p99 | Koszt infrastruktury | Narzut na zespół | Kiedy stosować |
|---|---|---|---|---|---|
| Notebook + ad-hoc ETL | Niska na starcie, rośnie wykładniczo | Sekundy–minuty, często ręcznie | Niski na starcie | Wysoki (klejenie, debugging) | PoC, jeden analityk, brak SLA |
| MLOps OSS (Airflow, MLflow, Kubeflow, Feast/Hopsworks) | Wysoka (platforma) | ms–s, powtarzalna | Średni | Średni–wysoki (DE + MLOps) | Enterprise z wymogiem kontroli i on-prem / hybrydy |
| Usługa zarządzana (SageMaker, Vertex, Azure ML) | Średnia (integracja z chmurą) | ms–s | Średni–wysoki (metryki usług) | Niższy operacyjnie | Gdy już jesteście w jednym chmurowym IAM i nie dźwigacie legacy GUI |
| Hybryda + skład T&M | Bardzo wysoka | Zależna od najsłabszego łącznika | Wysoki | Wysoki, dopóki nie zszyjecie GUI z API | Bank, pharma, dane, które nie wychodzą. Tu zwykle potrzebny jest squad, nie jedna rola. |
Python CRUD i Python od potoków danych to dwa zawody. Widełki backendu 145–200 / 200–280 PLN/h (specjalista / klient). Data pipelines są w górnej części tego pasma. AI/LLM na produkcji: 180–250 / 240–350 PLN/h. Marża 10–25%. Mapa, nie cennik — szczegóły w stawkach 2026.
5. Anty-wzorce, których nie ma w tutorialu Kubeflow
- Brief „Python Developer” na scoring. Dostaniecie Django. Nie dostaniecie Feature Store. Rynek pękł: klasyczny backend ma podaż, inżynier potoków i LLM nie. Ogłoszenie ze złą etykietą zbiera CV w 48 h i zero kompetencji od dryfu.
- Brak testów danych. CI sprawdza lint modelu, nie schemat wejścia. Cicha zmiana nulli w źródle przechodzi na produkcję. Predykcja jest „zielona”, decyzja biznesowa nie.
- Cecha bez właściciela. DS liczy w notebooku, DE w dbt, BI w Power Query. Trzy definicje churnu. Jeden dashboard, trzy wojny na stand-upie.
- Fałszywy zespół analityczny. DS z vendora A, DE z B, MLOps „jak będzie czas” z wewnętrznego DevOps. Trzy onboardingi, zero wspólnego DAG-a. To nie staff augmentation. To podatek integracyjny opisany przy leasingu zespołów IT.
6. Playbook: kogo wynająć i w jakiej kolejności
Nie zaczynajcie od modelu. Zacznijcie od pytania, która modalność blokuje SLA.
- Jedna luka w istniejącym potoku. Macie Airflow, Feature Store i kogoś, kto recenzuje PR. Brakuje seniora od modelu albo od Spark. To klasyczny body leasing Data Science albo Data Engineer: jedna osoba, Wasz stand-up, Wasze DoD. Pierwsze profile w dniach, nie w kwartale — sourcujemy na żądanie, nie sprzedajemy imiennej ławki na jutro rano.
- Notebook jest produktem. Nie ma DAG-a, nie ma testu schematu, nie ma servingu. Jedna osoba tego nie zszyje. Skład 3–5: DE (źródła, dbt/Spark), DS (model, walidacja), MLOps (obraz, monitoring dryfu). To bliżej team leasingu niż „dokupimy jeszcze jednego analityka”.
- Dane nie wychodzą z VPC. Kontraktor w Waszym IAM, Wasza chmura, NDA i powierzenie. Colab z zrzutem produkcyjnym jest wyciekiem, nie przyspieszeniem. Offline feature computation w batchu, online serving z tym samym kodem cechy.
- Ramp-up. Osoba do istniejącego zespołu: pierwsze CV 24–48 h, start po Waszych rozmowach i umowie. Squad od zera: tygodnie, nie sprint, bo zszywacie uprawnienia, dane i DoD. Kłamstwo „trzech seniorów Python od poniedziałku” to CV albo ławka, której nie mamy — i nie będziemy udawać.
Commoditech od 2012 robi T&M i rekrutację stałą z Warszawy. 80+ specjalistów w sieci, nie idle bench. Brief T&M albo success fee da się złożyć z IDE przez MCP dla agentów AI, nie tylko z formularza. Kwoty na konkretny stack liczy człowiek; widełki są w artykule o stawkach, nie w JSON-ie agenta.
FAQ
Czym różni się body leasing Data Science od etatu Data Scientista?
Etat to FTE w Waszym HR. Średni czas życia ogłoszenia IT na JobHunt we wrześniu 2026 to 50 dni — i to zanim wejdziecie w rozmowy. Body leasing Data Science to T&M: osoba w Waszym zespole, Waszym Gicie, Waszym SLA, z klauzulą zastępstwa roli. Nie kupujecie „modelu w abonamencie”. Kupujecie godzinę kompetencji. TCO vs etat (rekrutacja, bench, odprawy, sprzęt) jest w stawkach 2026.
Kiedy wynająć jedną osobę, a kiedy zespół Data Science?
Jedną osobę, gdy potok już istnieje i brakuje w nim luki: senior DS, Spark, MLOps. Zespół 3–5 osób, gdy notebook jest jedynym artefaktem. Sam Data Scientist dowiezie AUC. Nie dowiezie p99, testu schematu ani retreningu o 3:00. Jeśli nie macie komu recenzować PR-a od kontraktora, nie kupujcie body leasingu. Kupcie lead plus jedną rolę albo squad.
Ile kosztuje body leasing Data Science w Polsce w 2026?
Python od potoków danych nie jest CRUD: klient płaci w praktyce górę pasma 200–280 PLN/h na seniorze. Gdy model idzie na produkcję z LLM / RAG, bliżej 240–350 PLN/h. Marża dostawcy 10–25% — jeśli ktoś obiecuje 8% przy zastępstwie w 5 dni, doliczcie to w innej linii. To mapa rynku, nie oferta. Kwotę na brief liczy człowiek.
Czy kontraktor Data Science może pracować na danych pod NDA i RODO?
Tak: Wasze środowisko, Wasz IAM, Wasza chmura albo on-prem, umowa z NDA, powierzeniem i IP po stronie klienta. Notebook na prywatnym laptopie z produkcyjnym zrzutem to wyciek. Offline features liczone w batchu, online serving z tym samym kodem. Audyt dostępu jest Wasz. Kontraktor nie wynosi zbioru „żeby szybciej policzyć”.
Źródła
- Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NIPS 2015. papers.nips.cc
- Shi, H., Wang, W., Fang, W., Liang, Y. et al. (2026). CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents. arXiv:2609.05374. arxiv.org/abs/2609.05374
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- JobHunt.pl (1 września 2026). 21 211 aktywnych ról IT, średni czas życia oferty 50 dni — kontekst time-to-hire vs T&M.