Latent Axiom — fundamentalny model latentnego stanu użytkownika dla wielodomenowych sekwencji zdarzeń behawioralnych
Notice description
Przedmiotem zamówienia jest usługa specjalisty – Systems Integration Engineer (MLOps) do realizacji prac badawczo-rozwojowych w ramach badań przemysłowych i prac rozwojowych planowanych w projekcie.
Prace realizowane w ramach zamówienia będą dotyczyły zaprojektowania, zbudowania i utrzymania infrastruktury obliczeniowej oraz integracji danych umożliwiających trening i ewaluację metody uczenia uniwersalnych, ukrytych reprezentacji sekwencji zdarzeń użytkowników — w tym laboratorium badawczego, kanonicznego modelu danych dla wielodomenowych, heterogenicznych strumieni zdarzeń oraz środowiska treningu rozproszonego wielkiej skali.
Zakres prac obejmuje działania badawczo-technologiczne związane z:
• budową i utrzymaniem laboratorium badawczego oraz powtarzalnego, w pełni zautomatyzowanego środowiska eksperymentów w oparciu o Kubernetes, framework rozproszonej orkiestracji (Ray) oraz rejestr eksperymentów (MLflow) traktowany jako pojedyncze źródło prawdy dla konfiguracji, metryk i artefaktów;
• Zastosowaniem praktyk inżynierskich klasy GitOps oraz pipeline'ów CI/CD zapewniających twardą reprodukowalność i identyfikowalność uruchomień treningowych po haszach kodu i danych;
• inwentaryzacją i klasyfikacją heterogenicznych źródeł zdarzeń, badaniem mechanizmu identyfikacji użytkownika między źródłami oraz współudziałem w rozstrzygnięciu kanonicznego schematu zdarzenia integrującego wielodomenowe strumienie danych;
• budową prototypowych adapterów sprowadzających dane surowe do schematu kanonicznego, projektowaniem warstwy dostępu wsadowego (batch) i online o niskiej latencji oraz formatu przechowywania typu lakehouse (Iceberg / S3);
• Zastosowaniem praktyk niezawodności platformy danych — monitoringu jakości i dryfu, testów kontraktowych, obsługi dead-letter i historycznego backfillu oraz oceny osiągalnej świeżości i kompletności per klasa strumienia;
• konfiguracją, optymalizacją przepustowości i debugowaniem treningu rozproszonego (multi-node, multi-GPU) z wykorzystaniem frameworków równoległości (FSDP, DeepSpeed), wraz ze strategią checkpointingu i automatycznego wznawiania po awarii;
• instrumentacją i monitorowaniem infrastruktury oraz zadań (Prometheus / Grafana) i dostarczeniem danych infrastrukturalnych i kosztowych zasilających studium wykonalności potencjalnego wdrożenia.
Szczegółowy opis przedmiotu zamówienia
Zamawiający w ramach zamówienia oczekuje wykonania przez Oferenta zadań dla stanowiska specjalista – Systems Integration Engineer (MLOps) w ramach projektu, dla którego wymagania i zakres zlecenia ustala się jak poniżej.
Dla zadania 1 (badania przemysłowe — Walidacja metody uczenia uniwersalnych reprezentacji ukrytych sekwencji zdarzeń — proof-of-concept w skali do ok. 100 mln parametrów)
• Zbudowanie laboratorium badawczego: organizacja repozytoriów kodu w dedykowanej podgrupie systemu kontroli wersji, ustanowienie przestrzeni nazw (namespaces) i limitów zasobów (quotas) w klastrze — osobno dla środowisk deweloperskich oraz dla klastra orkiestracji rozproszonej (Ray) — utworzenie magazynu obiektowego na zbiory danych, duże artefakty i półprodukty oraz kopie zapasowe rejestru eksperymentów z odpowiednią retencją logów treningowych, a także konfiguracja technicznych obiektów klastra (configmapy, poświadczenia).
• Zbudowanie środowisk deweloperskich z szybkim uruchamianiem i zmianą przydziału zasobów oraz repozytorium kodu treningowego z pipeline'em CI/CD rozdzielonym na rzadko przebudowywany obraz środowiskowy i szybki obraz z kodem; wprowadzenie standardów inżynierskich (formatowanie, lintowanie, pre-commit).
• Eksperymentalne zastosowanie modelu pełnego GitOps: trening uruchamiany wyłącznie poprzez pipeline CI/CD, konfiguracje wersjonowane bez zmian wprowadzanych w trakcie działania (runtime), twarda reprodukowalność i identyfikowalność uruchomień po haszach kodu i danych.
• Opracowanie infrastruktury obliczeniowej dla matrycy eksperymentów w oparciu o framework rozproszonej orkiestracji (orkiestracja zadań, równoległe przeszukiwanie hiperparametrów, równoległa ewaluacja) oraz o rejestr eksperymentów pełniący rolę pojedynczego źródła prawdy dla konfiguracji, metryk i artefaktów, z automatyczną kopią zapasową na magazyn obiektowy.
• Opracowanie skalowalnego formatu przechowywania danych w postaci tabel typu lakehouse (dane surowe ze schematem zależnym od typu zdarzenia) oraz wydajnej ścieżki ładowania danych do treningu.
• Wsparcie konfiguracji i debugowania treningu rozproszonego na wielu GPU oraz zapewnienie numerycznie starannej, powtarzalnej agregacji metryk między węzłami (wzorce all-gather).
Szczegółowe objaśnienie wykorzystania prac w zadaniu 1 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia powtarzalnego, w pełni zautomatyzowanego i reużywalnego środowiska badawczego (orkiestracja, rejestr eksperymentów, magazyn danych, GitOps), które umożliwia rzetelne prowadzenie matrycy eksperymentów na etapie walidacji metody (proof-of-concept) i pozostaje gotowe do ponownego wykorzystania na etapie treningu wielkoskalowego bez konieczności refaktoryzacji.
Okres realizacji zadania 1: 10 miesięcy.
Dla zadania 2 (badania przemysłowe — Krytyczne zbadanie kanonicznego modelu danych dla wielodomenowych, heterogenicznych strumieni zdarzeń)
• Badanie nad źródłąmi danych (m.in. sklepy internetowe, serwisy publicystyczne, poczta, aukcje reklamowe RTB) pod kątem typów zdarzeń, formatu, stabilności schematu oraz trybu udostępniania (topic, baza, dump, API), wraz z oceną trudności integracji per klasa źródła.
• Zbadanie i weryfikacja na danych mechanizmu identyfikacji użytkownika między źródłami (reguła wyboru kanonicznego identyfikatora, priorytety źródeł, fallback) oraz ustalenie, w których obszarach mechanizm ten wymaga uzupełnienia.
• Współudział w rozstrzygnięciu kanonicznego schematu zdarzenia (wspólne zmienne główne uzupełnione o payload zależny od typu zdarzenia) oraz jego walidacja na próbkach z każdej klasy źródła, jako wielokrotnie używalnego elementu składowego systemu.
• Budowa eksperymentalnych adapterów konwertujących dane surowe do schematu kanonicznego, z obsługą błędów (dead-letter, historyczny backfill) jako instrumentem pomiaru poprawności konwersji oraz z etapowaniem prac od klas źródeł krytycznych dla treningu.
• Zbadanie warstwy dostępu wsadowego (batch) na potrzeby treningu oraz dostępu online o niskiej latencji na potrzeby inferencji: przechowywanie w formacie lakehouse z doborem partycjonowania, charakterystyka osiągalnej latencji i przepustowości na interfejsie symulującym konsumenta oraz zbadanie punktu styku z istniejącym feature store.
• Wdrożenie praktyk niezawodności platformy danych: monitoring jakości i rozkładów kluczowych pól (detekcja dryfu), testy kontraktowe na styku adapter–storage, deduplikacja oraz ocena osiągalnej świeżości i kompletności per klasa strumienia.
Szczegółowe objaśnienie wykorzystania prac w zadaniu 2 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia zweryfikowanego w laboratorium dowodu słuszności kanonicznego modelu danych wraz z prototypami adapterów i udokumentowaną rozszerzalnością (dodanie nowego źródła sprowadza się do samego adaptera), zasilającego trening reprezentacji bez konieczności doraźnego ETL.
Okres realizacji zadania 2: 9 miesięcy.
Dla zadania 3 (eksperymentalne prace rozwojowe — Trening wielkoskalowy (rząd ~1 mld parametrów) i końcowa, wieloosiowa ewaluacja metody)
• Ocena pojemności dotychczasowej infrastruktury względem wymagań skali docelowej oraz konfiguracja treningu rozproszonego (multi-node, multi-GPU), w tym dobór i konfiguracja frameworka równoległości (FSDP, DeepSpeed) na podstawie wcześniejszych testów.
• Tuning komunikacji (NVLink, RDMA, akumulacja gradientów) oraz optymalizacja przepustowości danych na ścieżce od zintegrowanego strumienia do trenera (pomiar wąskich gardeł, prefetch, sharding zbioru), tak aby GPU nie oczekiwały na dane.
• Opracowanie i wdrożenie strategii checkpointingu oraz automatycznego wznawiania po awarii pod wielodniowy lub wielotygodniowy czas treningu, wraz z monitoringiem kosztów (utylizacja GPU/CPU, transfer do magazynu obiektowego, rozmiar checkpointów) oraz instrumentacją (metryki, logi, alerty).
• Reużycie istniejącej orkiestracji, rejestru eksperymentów i magazynu danych bez budowy nowych narzędzi oraz współudział we wkładzie infrastrukturalnym do studium wykonalności wdrożenia (wymagania przedwdrożeniowe, koszt utrzymania, ryzyka).
Szczegółowe objaśnienie wykorzystania prac w zadaniu 3 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia środowiska gotowego do ukończenia treningu wielkoskalowego (odpornego na awarie i o zoptymalizowanej przepustowości) oraz danych infrastrukturalnych i kosztowych zasilających studium wykonalności potencjalnego wdrożenia.
Okres realizacji zadania 3: 17 miesięcy.
Zamawiający dopuszcza realizację prac w oparciu o umowę B2B lub umowę cywilnoprawną, pod warunkiem posiadania przez Oferenta doświadczenia adekwatnego do zakresu zamówienia, w szczególności w realizacji prac B+R lub projektów technologicznych z obszaru inżynierii platform ML / MLOps i treningu rozproszonego oraz inżynierii danych dla wielkoskalowych, heterogenicznych strumieni zdarzeń (orkiestracja, formaty lakehouse, pipeline'y CI/CD / GitOps).
Miejsce realizacji
Kraj: Polska, Województwo: mazowieckie, Powiat: Warszawa, Gmina: Włochy, Miejscowość: Warszawa
Prace realizowane w ramach zamówienia będą dotyczyły zaprojektowania, zbudowania i utrzymania infrastruktury obliczeniowej oraz integracji danych umożliwiających trening i ewaluację metody uczenia uniwersalnych, ukrytych reprezentacji sekwencji zdarzeń użytkowników — w tym laboratorium badawczego, kanonicznego modelu danych dla wielodomenowych, heterogenicznych strumieni zdarzeń oraz środowiska treningu rozproszonego wielkiej skali.
Zakres prac obejmuje działania badawczo-technologiczne związane z:
• budową i utrzymaniem laboratorium badawczego oraz powtarzalnego, w pełni zautomatyzowanego środowiska eksperymentów w oparciu o Kubernetes, framework rozproszonej orkiestracji (Ray) oraz rejestr eksperymentów (MLflow) traktowany jako pojedyncze źródło prawdy dla konfiguracji, metryk i artefaktów;
• Zastosowaniem praktyk inżynierskich klasy GitOps oraz pipeline'ów CI/CD zapewniających twardą reprodukowalność i identyfikowalność uruchomień treningowych po haszach kodu i danych;
• inwentaryzacją i klasyfikacją heterogenicznych źródeł zdarzeń, badaniem mechanizmu identyfikacji użytkownika między źródłami oraz współudziałem w rozstrzygnięciu kanonicznego schematu zdarzenia integrującego wielodomenowe strumienie danych;
• budową prototypowych adapterów sprowadzających dane surowe do schematu kanonicznego, projektowaniem warstwy dostępu wsadowego (batch) i online o niskiej latencji oraz formatu przechowywania typu lakehouse (Iceberg / S3);
• Zastosowaniem praktyk niezawodności platformy danych — monitoringu jakości i dryfu, testów kontraktowych, obsługi dead-letter i historycznego backfillu oraz oceny osiągalnej świeżości i kompletności per klasa strumienia;
• konfiguracją, optymalizacją przepustowości i debugowaniem treningu rozproszonego (multi-node, multi-GPU) z wykorzystaniem frameworków równoległości (FSDP, DeepSpeed), wraz ze strategią checkpointingu i automatycznego wznawiania po awarii;
• instrumentacją i monitorowaniem infrastruktury oraz zadań (Prometheus / Grafana) i dostarczeniem danych infrastrukturalnych i kosztowych zasilających studium wykonalności potencjalnego wdrożenia.
Szczegółowy opis przedmiotu zamówienia
Zamawiający w ramach zamówienia oczekuje wykonania przez Oferenta zadań dla stanowiska specjalista – Systems Integration Engineer (MLOps) w ramach projektu, dla którego wymagania i zakres zlecenia ustala się jak poniżej.
Dla zadania 1 (badania przemysłowe — Walidacja metody uczenia uniwersalnych reprezentacji ukrytych sekwencji zdarzeń — proof-of-concept w skali do ok. 100 mln parametrów)
• Zbudowanie laboratorium badawczego: organizacja repozytoriów kodu w dedykowanej podgrupie systemu kontroli wersji, ustanowienie przestrzeni nazw (namespaces) i limitów zasobów (quotas) w klastrze — osobno dla środowisk deweloperskich oraz dla klastra orkiestracji rozproszonej (Ray) — utworzenie magazynu obiektowego na zbiory danych, duże artefakty i półprodukty oraz kopie zapasowe rejestru eksperymentów z odpowiednią retencją logów treningowych, a także konfiguracja technicznych obiektów klastra (configmapy, poświadczenia).
• Zbudowanie środowisk deweloperskich z szybkim uruchamianiem i zmianą przydziału zasobów oraz repozytorium kodu treningowego z pipeline'em CI/CD rozdzielonym na rzadko przebudowywany obraz środowiskowy i szybki obraz z kodem; wprowadzenie standardów inżynierskich (formatowanie, lintowanie, pre-commit).
• Eksperymentalne zastosowanie modelu pełnego GitOps: trening uruchamiany wyłącznie poprzez pipeline CI/CD, konfiguracje wersjonowane bez zmian wprowadzanych w trakcie działania (runtime), twarda reprodukowalność i identyfikowalność uruchomień po haszach kodu i danych.
• Opracowanie infrastruktury obliczeniowej dla matrycy eksperymentów w oparciu o framework rozproszonej orkiestracji (orkiestracja zadań, równoległe przeszukiwanie hiperparametrów, równoległa ewaluacja) oraz o rejestr eksperymentów pełniący rolę pojedynczego źródła prawdy dla konfiguracji, metryk i artefaktów, z automatyczną kopią zapasową na magazyn obiektowy.
• Opracowanie skalowalnego formatu przechowywania danych w postaci tabel typu lakehouse (dane surowe ze schematem zależnym od typu zdarzenia) oraz wydajnej ścieżki ładowania danych do treningu.
• Wsparcie konfiguracji i debugowania treningu rozproszonego na wielu GPU oraz zapewnienie numerycznie starannej, powtarzalnej agregacji metryk między węzłami (wzorce all-gather).
Szczegółowe objaśnienie wykorzystania prac w zadaniu 1 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia powtarzalnego, w pełni zautomatyzowanego i reużywalnego środowiska badawczego (orkiestracja, rejestr eksperymentów, magazyn danych, GitOps), które umożliwia rzetelne prowadzenie matrycy eksperymentów na etapie walidacji metody (proof-of-concept) i pozostaje gotowe do ponownego wykorzystania na etapie treningu wielkoskalowego bez konieczności refaktoryzacji.
Okres realizacji zadania 1: 10 miesięcy.
Dla zadania 2 (badania przemysłowe — Krytyczne zbadanie kanonicznego modelu danych dla wielodomenowych, heterogenicznych strumieni zdarzeń)
• Badanie nad źródłąmi danych (m.in. sklepy internetowe, serwisy publicystyczne, poczta, aukcje reklamowe RTB) pod kątem typów zdarzeń, formatu, stabilności schematu oraz trybu udostępniania (topic, baza, dump, API), wraz z oceną trudności integracji per klasa źródła.
• Zbadanie i weryfikacja na danych mechanizmu identyfikacji użytkownika między źródłami (reguła wyboru kanonicznego identyfikatora, priorytety źródeł, fallback) oraz ustalenie, w których obszarach mechanizm ten wymaga uzupełnienia.
• Współudział w rozstrzygnięciu kanonicznego schematu zdarzenia (wspólne zmienne główne uzupełnione o payload zależny od typu zdarzenia) oraz jego walidacja na próbkach z każdej klasy źródła, jako wielokrotnie używalnego elementu składowego systemu.
• Budowa eksperymentalnych adapterów konwertujących dane surowe do schematu kanonicznego, z obsługą błędów (dead-letter, historyczny backfill) jako instrumentem pomiaru poprawności konwersji oraz z etapowaniem prac od klas źródeł krytycznych dla treningu.
• Zbadanie warstwy dostępu wsadowego (batch) na potrzeby treningu oraz dostępu online o niskiej latencji na potrzeby inferencji: przechowywanie w formacie lakehouse z doborem partycjonowania, charakterystyka osiągalnej latencji i przepustowości na interfejsie symulującym konsumenta oraz zbadanie punktu styku z istniejącym feature store.
• Wdrożenie praktyk niezawodności platformy danych: monitoring jakości i rozkładów kluczowych pól (detekcja dryfu), testy kontraktowe na styku adapter–storage, deduplikacja oraz ocena osiągalnej świeżości i kompletności per klasa strumienia.
Szczegółowe objaśnienie wykorzystania prac w zadaniu 2 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia zweryfikowanego w laboratorium dowodu słuszności kanonicznego modelu danych wraz z prototypami adapterów i udokumentowaną rozszerzalnością (dodanie nowego źródła sprowadza się do samego adaptera), zasilającego trening reprezentacji bez konieczności doraźnego ETL.
Okres realizacji zadania 2: 9 miesięcy.
Dla zadania 3 (eksperymentalne prace rozwojowe — Trening wielkoskalowy (rząd ~1 mld parametrów) i końcowa, wieloosiowa ewaluacja metody)
• Ocena pojemności dotychczasowej infrastruktury względem wymagań skali docelowej oraz konfiguracja treningu rozproszonego (multi-node, multi-GPU), w tym dobór i konfiguracja frameworka równoległości (FSDP, DeepSpeed) na podstawie wcześniejszych testów.
• Tuning komunikacji (NVLink, RDMA, akumulacja gradientów) oraz optymalizacja przepustowości danych na ścieżce od zintegrowanego strumienia do trenera (pomiar wąskich gardeł, prefetch, sharding zbioru), tak aby GPU nie oczekiwały na dane.
• Opracowanie i wdrożenie strategii checkpointingu oraz automatycznego wznawiania po awarii pod wielodniowy lub wielotygodniowy czas treningu, wraz z monitoringiem kosztów (utylizacja GPU/CPU, transfer do magazynu obiektowego, rozmiar checkpointów) oraz instrumentacją (metryki, logi, alerty).
• Reużycie istniejącej orkiestracji, rejestru eksperymentów i magazynu danych bez budowy nowych narzędzi oraz współudział we wkładzie infrastrukturalnym do studium wykonalności wdrożenia (wymagania przedwdrożeniowe, koszt utrzymania, ryzyka).
Szczegółowe objaśnienie wykorzystania prac w zadaniu 3 projektu
Rezultaty prac zostaną wykorzystane do dostarczenia środowiska gotowego do ukończenia treningu wielkoskalowego (odpornego na awarie i o zoptymalizowanej przepustowości) oraz danych infrastrukturalnych i kosztowych zasilających studium wykonalności potencjalnego wdrożenia.
Okres realizacji zadania 3: 17 miesięcy.
Zamawiający dopuszcza realizację prac w oparciu o umowę B2B lub umowę cywilnoprawną, pod warunkiem posiadania przez Oferenta doświadczenia adekwatnego do zakresu zamówienia, w szczególności w realizacji prac B+R lub projektów technologicznych z obszaru inżynierii platform ML / MLOps i treningu rozproszonego oraz inżynierii danych dla wielkoskalowych, heterogenicznych strumieni zdarzeń (orkiestracja, formaty lakehouse, pipeline'y CI/CD / GitOps).
Miejsce realizacji
Kraj: Polska, Województwo: mazowieckie, Powiat: Warszawa, Gmina: Włochy, Miejscowość: Warszawa
Time limit for receipt of tenders
2026-06-16 21:59:59.0
Location
Kraj: Polska, Województwo: mazowieckie, Powiat: Warszawa, Gmina: Włochy, Miejscowość: Warszawa
Category assortment
Consultancy
Buyer details
Wirtualna Polska Media S.A.
Żwirki i Wigury 16
02-092 Warszawa
Województwo: mazowieckie
Kraj: Polska
NIP: 5272645593
Żwirki i Wigury 16
02-092 Warszawa
Województwo: mazowieckie
Kraj: Polska
NIP: 5272645593
