Pliki danych dla AI i machine learning – jak je przygotować krok po kroku

Cel pracy z plikami danych dla AI i machine learning

Osoba przygotowująca pliki danych do AI i machine learning zazwyczaj chce dwóch rzeczy: lepszych modeli i mniej chaosu w projekcie. Kluczem nie jest „magiczny algorytm”, tylko porządek w danych – od surowych logów po finalny zbiór treningowy zapisany w sensownym formacie.

Drugi cel to ograniczenie błędów: wycieki informacji, źle opisane etykiety, niespójne wersje plików, bałagan w formatach. Porządny proces sprawia, że nowy członek zespołu jest w stanie odtworzyć dataset, a model zachowuje się stabilnie także po wdrożeniu.

Frazy pokrewne: przygotowanie danych do machine learning, formaty plików dla AI, etykietowanie danych krok po kroku, czyszczenie zbiorów danych, balansowanie klas w ML, dataset dla modeli językowych, dokumentacja zbiorów danych, narzędzia do anotacji danych, walidacja jakości danych, bezpieczeństwo danych treningowych

Po co w ogóle przygotowywać dane – wpływ na jakość modeli

Jakość danych vs. jakość modelu – prosta zależność

Model uczy się wyłącznie z tego, co mu podasz. Jeśli dane są przypadkowe, brudne albo sprzeczne, nawet najdroższy algorytm będzie produkował śmieci. To klasyczne garbage in, garbage out.

W praktyce zmiana modelu z „dobrego” na „świetny” daje kilka–kilkanaście procent wzrostu jakości. Natomiast przejście z chaotycznych danych na dobrze zaprojektowane, oczyszczone i opisane potrafi zmienić projekt z całkowitej porażki w stabilne wdrożenie.

Duża część pracy doświadczonych zespołów ML to nie tuning hiperparametrów, ale poprawa danych: lepsze etykiety, sensowniejszy dobór próbek, usunięcie błędów logicznych i wycieków czasowych.

Ten sam algorytm na „brudnych” i przygotowanych danych

Wyobraź sobie prosty klasyfikator maili spam/nie-spam. Ten sam model (np. gradient boosting) uczony na dwóch zbiorach:

• Wersja A – brudne dane: duplikaty, różne kodowania znaków, maile automatyczne czasem jako spam, czasem jako nie-spam, brak informacji o języku wiadomości.
• Wersja B – przygotowane dane: usunięte duplikaty, znormalizowany tekst, konsekwentne zasady etykietowania, dodatkowe cechy (np. liczba linków, domena nadawcy).

W wersji A model będzie „mylił się” w losowych miejscach: spam od jednego nadawcy będzie wpadał do skrzynki, a od innego nie. W wersji B te same techniki ML zaczynają rozumieć struktury w danych: wzorce domen, typowe słowa, konstrukcje zdań. Różnica w jakości potrafi być dramatyczna, mimo że algorytm się nie zmienił.

Dane do BI vs. dane do uczenia modeli

Zbiory danych do raportowania BI i do ML spełniają różne funkcje. W BI wystarczy, że dane są poprawne, możliwe do zagregowania i zgodne z definicjami biznesowymi. Modelowi potrzebne są dodatkowe własności.

Przy AI istotne jest:

• brak wycieków informacji (dane „z przyszłości” nie mogą pojawić się w cechach wejściowych),
• ciągłość w czasie – żeby model nie uczył się na nienaturalnym rozkładzie,
• etykiety spójne i odtwarzalne, z pełną historią tego, jak powstały,
• dokładne pola wejściowe, bez zbyt agresywnych agregacji, które zacierają sygnał.

Dużo projektów zaczyna się od tego, że ktoś „pożycza” tabelę z hurtowni danych. Potem wychodzi na jaw, że część kolumn zawiera informację technicznie dostępną dopiero po zdarzeniu, które model ma przewidywać. To niszczy sens walidacji.

Kiedy inwestycja w dane daje więcej niż „lepszy model”

W praktyce bardziej opłaca się:

• doprecyzować etykiety i instrukcję anotacji,
• dozbierać brakujący typ danych (np. próbek z rzadkiej klasy),
• posprzątać błędne rekordy i niespójne pola,
• przeprojektować cechy (feature engineering).

Zmiana modelu na bardziej złożony bywa kusząca, ale często tylko maskuje problemy danych. Dobrym sygnałem jest moment, gdy kilka różnych modeli ma podobny sufit jakości – wtedy warto prześwietlić dane, a nie dalej dokręcać algorytm.

Jakie dane są potrzebne do AI – typy i źródła

Główne typy danych w projektach AI

W większości projektów ML i AI przewijają się następujące typy danych:

• Dane tabelaryczne – klasyczne kolumny i wiersze (liczby, kategorie, daty). Modele: gradient boosting, drzewa, regresje.
• Tekst – wiadomości, opisy produktów, dokumenty, transkrypcje. Modele: klasyfikacja tekstu, wyszukiwarki, LLM.
• Obraz – zdjęcia, skany, klatki wideo. Modele: rozpoznawanie obrazów, detekcja obiektów, segmentacja.
• Audio – nagrania rozmów, sygnały, dźwięki maszyn. Modele: rozpoznawanie mowy, klasyfikacja sygnałów.
• Dane czasowe – szeregi czasowe, logi sensorów, dane transakcyjne w czasie. Modele: prognozowanie, detekcja anomalii.
• Logi i zdarzenia – kliknięcia, wejścia na stronę, akcje użytkowników. Modele: rekomendacje, scoring zachowań.

Od typu danych zależy sposób zapisu plików, metody czyszczenia, narzędzia do anotacji i finalny format datasetu.

Źródła danych: od systemu produkcyjnego po zakupy datasetów

Typowe źródła danych w projektach AI:

• Systemy produkcyjne – bazy transakcyjne, CRM, ERP, systemy billingowe.
• API – zewnętrzne usługi (np. dane pogodowe, kursy walut, dane o ruchu drogowym).
• Logi aplikacji – pliki logów serwera, zdarzeń w aplikacji, eventy z frontendu.
• Web scraping – dane pobierane automatycznie ze stron (trzeba liczyć się z ograniczeniami prawnymi i regulaminami).
• Zakupione zbiory danych – gotowe datasety od firm specjalizujących się w danych do ML.
• Dane wytworzone wewnętrznie – np. anotacje pracowników, dane syntetyczne do uzupełnienia rzadkich przypadków.

Dobry workflow zaczyna się od mapy: jakie źródła są dostępne, w jakich formatach, z jaką częstotliwością, kto za nie odpowiada.

Dane oznaczone, nieoznaczone i syntetyczne

Modele nadzorowane (supervised) potrzebują danych z etykietami. To oznacza, że do każdej próbki trzeba przypisać cel (np. spam/nie-spam, kategoria produktu, wynik zdarzenia).

Kategorie:

• Dane oznaczone (labelled) – mają przypisaną prawdę referencyjną (np. klasa, wartość liczbową). Tworzą je ludzie lub procesy automatyczne.
• Dane nieoznaczone (unlabelled) – brak etykiet; przydatne do unsupervised, pre-trainów, modeli generatywnych.
• Dane syntetyczne – generowane sztucznie, np. przez symulatory, modele generatywne, augmentację (obrót, szum, ścięcie obrazu).

Dane syntetyczne i augmentacja pomagają w rzadkich przypadkach, ale nie zastąpią prawdziwych próbek w modelach krytycznych (medycyna, bezpieczeństwo, finanse). Traktuj je jako wsparcie, nie główne źródło.

Kluczowe pytania przed startem zbioru danych

Przed pierwszym eksportem warto odpowiedzieć na kilka prostych pytań:

• Skala – ile rekordów jest potrzebnych realizacyjnie? Co jest realistyczne na dziś (np. 100 tys. wierszy vs. 10 mln)?
• Częstotliwość aktualizacji – czy zbiór jest jednorazowy, czy będzie aktualizowany co dzień/tydzień/miesiąc?
• Ograniczenia prawne – RODO, zgody użytkowników, dane wrażliwe (zdrowie, finanse, biometria).
• Ograniczenia organizacyjne – kto może eksportować dane, jak długo trwa zgoda działu prawnego, czy są wymogi audytu?
• Bezpieczeństwo – gdzie dane będą trzymane, jak są szyfrowane, kto ma dostęp? Czy dane opuszczają organizację?

Te odpowiedzi wpływają na wybór formatu plików, narzędzi i sam proces budowy zbioru treningowego.

Wybór formatu plików danych – od CSV po Parquet i JSONL

Najpopularniejsze formaty danych dla AI

W projektach ML przewijają się głównie te formaty:

• CSV/TSV – prosty tekst, kolumny rozdzielone separatorem (, lub tab). Nadaje się do tabelarycznych datasetów.
• JSON – struktury zagnieżdżone (klucze → wartości). Często używany przy danych tekstowych i API.
• JSONL (JSON Lines) – każdy wiersz to osobny obiekt JSON. Idealny dla dużych zbiorów tekstowych i logów.
• Parquet – kolumnowy format binarny, zoptymalizowany pod duże zbiory i odczyt kolumnami (Hadoop, Spark, duże hurtownie).
• Obrazy – zwykle PNG lub JPEG; metadane i etykiety w osobnym pliku (CSV, JSON, COCO, YOLO).
• Audio – surowe WAV, czasem FLAC; transkrypcje i etykiety w tekstowych plikach powiązanych.

Format powinien być prosty dla zespołu, ale także skalowalny. Inny wybór zrobisz w PoC na laptopie, a inny w systemie, który obsługuje miliardy rekordów.

Kiedy wybrać który format pliku

Małe pilotaże, PoC, praca na laptopie:

• dane tabelaryczne – CSV (lub TSV, jeśli w treści jest dużo przecinków),
• teksty – JSONL, gdzie każdy wiersz ma pola typu id, text, label,
• obrazy – pliki PNG/JPEG + plik CSV/JSON z etykietami i ścieżkami.

Duże zbiory, produkcyjne pipeline’y:

• Parquet jako główny format w hurtowni danych i feature store,
• eksporty do CSV/JSONL tylko jako finalne wejście do procesu trenowania,
• fragmentacja plików (partycje) według daty, użytkownika, kraju itp.

Modele językowe, LLM:

• JSONL z polami dopasowanymi do API/ramy (np. prompt, completion albo messages jako lista ról/treści),
• jasna konwencja: jeden wiersz = jedna interakcja, dokument lub przykład instrukcyjny.

Formaty pod komputerowe widzenie i audio

Dla obrazów i wideo ważniejsza od samego formatu pliku graficznego jest struktura katalogów i format plików z anotacjami.

Typowe warianty:

• Klasyfikacja obrazów: foldery /train/class_a, /train/class_b, każdy obraz w odpowiednim folderze.
• Detekcja obiektów: obrazy w jednym folderze, etykiety w formacie COCO (JSON) lub YOLO (tekst z koordynatami) powiązane nazwą pliku.
• Segmentacja: dodatkowe maski (obrazy binarne lub wielokanałowe) w osobnym folderze.

Dla audio:

• surowe nagrania jako WAV (bezstratny, prosty do obróbki),
• transkrypcje i metadane w plikach tekstowych/JSONL powiązanych po identyfikatorze pliku.

Konsekwencje złego wyboru formatu

Zły format pliku nie zatrzyma projektu, ale potrafi dużo skomplikować:

• pipeline’y stają się wolne i kruche (ciągłe parsowanie CSV z „dziwnymi” separatorami, problemy z kodowaniem),
• rośnie ryzyko błędów przy łączeniu danych (np. różne schematy JSON, brak spójnych typów),
• zespół traci czas na techniczne obejścia zamiast na projektowanie cech i eksperymenty,
• koszty storage’u i transferu rosną nieproporcjonalnie do wartości danych.

Typowy przykład: CSV z polami tekstowymi zawierającymi przecinki i znaki nowej linii. Niby drobiazg, a w praktyce psuje importy do różnych narzędzi, powoduje przesunięcia kolumn i trudne do wykrycia błędy etykiet. W takiej sytuacji prosty JSONL rozwiązałby większość kłopotów.

Inny klasyk to trzymanie ogromnych zbiorów w jednym „monolitycznym” pliku. Gdy każda iteracja modelu wymaga odczytu kilkudziesięciu gigabajtów na raz, czas eksperymentów dramatycznie rośnie. Rozsądne partycjonowanie (mniejsze pliki, logiczny podział) daje realny zysk już na poziomie zwykłego trenowania w PyTorchu czy TensorFlow.

Dobrze dobrany format danych porządkuje cały ekosystem wokół modelu: ułatwia wersjonowanie datasetów, dzielenie się nimi między zespołami i odtwarzanie eksperymentów. Staje się też rodzajem „umowy” – jeśli format jest stabilny i jasno opisany, łatwiej wymienić narzędzie czy bibliotekę bez przepisywania wszystkiego od zera.

Solidne przygotowanie danych, od wyboru formatu po sposób zapisu etykiet, często przynosi większy skok jakości niż zmiana modelu na nowszy o jedną generację. Dobrze zaprojektowane pliki danych dają spokojniejszą pracę dziś i prostsze skalowanie jutro, niezależnie od tego, czy chodzi o mały PoC, czy o system, na którym opierają się krytyczne procesy firmy.

Projektowanie schematu danych – kolumny, pola, etykiety

Dlaczego schemat trzeba zaprojektować z wyprzedzeniem

Schemat danych to odpowiedź na pytanie, jak wygląda pojedyncza próbka: jakie pola zawiera, w jakich typach, z jakimi nazwami. Chaotyczny schemat szybko mści się trudnym łączeniem tabel, błędnymi joinami i „niewyjaśnionymi” spadkami jakości modelu.

Dobrze zaprojektowany schemat jest nudny: spójne nazwy, jasne typy, zero niespodzianek typu data w stringu o trzech formatach.

Kolumny i pola – co musi się w nich znaleźć

Przy projektowaniu struktury warto odpowiedzieć na trzy pytania: jaka jest jednostka rekordu, co ma być celem (target), a co wejściem (features).

• Identyfikator – unikalne id rekordu (transakcji, użytkownika, sesji). Bez tego trudno śledzić próbki i błędy.
• Cecha wejściowa – to, czym „karmisz” model (np. kwota transakcji, ścieżka do pliku, tekst wiadomości).
• Etykieta / target – zmienna przewidywana (0/1, klasa, wartość liczbowa).
• Metadane – informacje kontekstowe: źródło, czas powstania, wersja procesu, język.

W praktyce lepiej mieć kilka dobrze opisanych pól niż dziesiątki podobnych kolumn różniących się drobiazgami.

Nazewnictwo i typy danych

Nazwy kolumn powinny być jednoznaczne, bez skrótów zrozumiałych tylko dla jednego zespołu. created_at mówi więcej niż c_at.

• Typy liczbowe – jawnie rozdzielaj wartości całkowite i zmiennoprzecinkowe.
• Daty i czas – trzymaj w jednym formacie (np. ISO 8601, UTC). W CSV lepiej użyć oddzielnych kolumn na datę i godzinę niż „magicznego” stringa.
• Tekst – standardowe kodowanie (UTF-8), bez mieszania formatów w jednym polu.
• Kategorie – spójne słowniki (np. status ∈ {active, inactive, blocked}), a nie free-text.

Typy warto przemyśleć pod kątem narzędzi: coś, co jest stringiem w CSV, w Parquet może być jasno zdefiniowane jako int32, bool czy timestamp.

Reprezentacja etykiet

Etykiety można trzymać w różnych formach. Klucz, by było to spójne od początku do końca pipeline’u.

• Klasy – najwygodniej symbolicznie (np. spam, ham) w datasetach, a dopiero w kodzie mapować na 0/1.
• Wartości ciągłe – jedna kolumna z liczbą, bez domieszek tekstu (brak jednostek w tym samym polu).
• Wielokrotne etykiety – lista kategorii (np. JSON array) albo kilka binarnych kolumn typu tag_is_promo, tag_is_news.

Przy wieloetykietowych problemach lepiej unikać jednego pola z rozdzielaną listą w stylu "promo,news,faq". JSONL lub osobna tabela etykiet jest bezpieczniejsza.

Schemat „logiczny” vs. „fizyczny”

Czasem opłaca się rozdzielić to, jak dane wyglądają w narzędziu analitycznym, od tego, jak wchodzą do modelu.

• Schemat logiczny – jak widzi dane analityk (kilka powiązanych tabel, relacje 1:N, daty, flagi).
• Schemat fizyczny – gotowy plik treningowy (np. jedna tabela z featurami po agregacjach, zakodowane kategorie).

Między jednym a drugim jest miejsce na warstwę feature engineeringu i mechanizmy kontroli jakości.

Zbieranie i łączenie danych – praktyczny workflow

Mapa źródeł i przepływów

W typowej organizacji dane do ML leżą w kilku miejscach: bazach OLTP, hurtowni, logach aplikacji, plikach w chmurze, systemach CRM/ERP.

Dobrze działa prosta mapa: skąd dane wychodzą, jakim kanałem, w jakim formacie, jak często i dokąd trafiają. To minimalizuje niespodzianki typu brak kolumny albo inne nazwy w „prawie tym samym” eksporcie.

Eksporty jednorazowe vs. stałe zasilanie

Tryb pracy mocno zmienia workflow.

• Eksport jednorazowy – proste skrypty SQL, ręczne czyszczenie, mniej nacisku na automatyzację.
• Stałe zasilanie – pipeline ETL/ELT, harmonogram (Airflow, dbt, cron), monitorowanie i alerty.

Jeśli PoC ma szansę wejść do produkcji, opłaca się od razu zadbać o możliwość odtworzenia zbioru: te same zapytania, te same filtry, ta sama logika łączenia.

Łączenie danych z wielu systemów

Większość problemów wychodzi przy merge’ach. Typowe pułapki:

• różne identyfikatory dla tego samego bytu (inne user_id w aplikacji mobilnej, inne w CRM),
• niejednoznaczne klucze (brak jednego „source of truth” dla klienta, zamówienia, urządzenia),
• joiny N:N, które multiplikują rekordy i zaburzają statystyki.

Bezpieczna praktyka: przed złączeniem policzyć unikalność kluczy w każdej tabeli i sprawdzić, czy join faktycznie jest 1:1 albo 1:N. Dobrze też dodać proste testy (np. liczba rekordów po joinie vs. przed).

Wersjonowanie i śledzenie pochodzenia danych

Nawet prosty log zmian chroni przed sytuacją, kiedy nie da się odtworzyć zbioru, na którym powstał „ten dobry model”.

• przechowywanie skryptów ekstrakcji w repozytorium,
• opisy datasetów: skąd, kiedy, jakie filtry, jaka wersja schematu,
• znacznik wersji w nazwach plików lub metadanych (np. dataset_v3_2024-05-01.parquet).

Prosty README w folderze z danymi potrafi oszczędzić godziny „archeologii danych”.

Czyszczenie danych – usuwanie szumu, błędów i braków

Typowe problemy jakości danych

Przed trenowaniem modelu warto przynajmniej przejść przez podstawowe sanity checki.

• Duplikaty – te same rekordy powielone w wyniku joinów lub importów.
• Braki danych – puste pola w kluczowych kolumnach.
• Outliery – wartości z kosmosu (np. wiek 400, kwota −1e9).
• Niespójne formaty – różne zapisy dat, liczb z przecinkiem/kropką, mieszane języki.

Narzędzia typu Pandas, DuckDB czy SQL wystarczą, by wychwycić większość problemów prostymi statystykami i grupowaniem.

Strategie radzenia sobie z brakami

Brakujące wartości są nieuniknione. Kluczowe, by obsłużyć je świadomie.

• Usuwanie rekordów – gdy braki są rzadkie i nie dotyczą kluczowych cech.
• Imputacja prostymi regułami – średnia, mediana, wartość domyślna typu „unknown”.
• Imputacja modelowa – osobny model do uzupełniania braków, ale to już kolejna warstwa złożoności.
• Specjalne wartości – osobna kategoria missing dla zmiennych kategorycznych.

Dobrą praktyką jest trzymanie flagi typu is_missing_feature_x, żeby model mógł sam nauczyć się, że brak informacji bywa informacją.

Outliery i błędy logiczne

Wyjątkowo duże lub małe wartości mogą być zarówno błędem, jak i cennym sygnałem (np. fraud, awaria). Zanim zostaną „ścięte”, trzeba zrozumieć, co oznaczają.

• sprawdzenie rozkładu (percentyle, wykresy log-scale),
• porównanie z regułami biznesowymi (minimalna i maksymalna sensowna wartość),
• wprowadzenie górnego/dolnego limitu (winsoryzacja) tam, gdzie problemem są pojedyncze wartości z importu.

Błędy logiczne (np. data zakończenia wcześniejsza niż startu) często lepiej oznaczyć i wykluczyć całe rekordy, niż „naprawiać na siłę”.

Standaryzacja tekstu i kategorii

Tekst i kategorie często wymagają prostych, ale konsekwentnych transformacji.

• normalizacja wielkości liter, usuwanie białych znaków na końcach,
• spójne słowniki (np. PL vs. Polska vs. POL → jedna forma),
• usunięcie oczywistych artefaktów eksportu (HTML, tagi, debugowe komentarze).

Przy LLM-ach nadmierna agresja (np. wyrzucanie znaków specjalnych, emotikonów) bywa szkodliwa, bo model traci kontekst. Bezpieczniej jest logować, co zostało usunięte i w razie potrzeby się wycofać.

Anotacja i etykietowanie danych – jak zorganizować proces

Projekt etykiet to projekt produktu

Zestaw etykiet decyduje, czego model może się nauczyć. Zbyt ogólne klasy dają mało przydatne wyniki, zbyt szczegółowe – nie da się ich rzetelnie rozróżnić.

Opłaca się zacząć od prostszego schematu etykiet i dopiero po pierwszych iteracjach wprowadzać rozróżnienia, które faktycznie coś wnoszą.

Instrukcje annotacyjne

Bez czytelnych instrukcji dwóch anotatorów opisze ten sam przypadek inaczej. Powstaje szum, który model tylko wzmacnia.

• jasna definicja każdej etykiety z przykładami „tak” i „nie”,
• lista reguł rozstrzygających sporne sytuacje,
• aktualizacja instrukcji, gdy wychodzą nowe typy przypadków.

Nawet proste 2–3 strony PDF z przykładami mocno podnosi spójność anotacji.

Jakość anotacji: spójność i kontrola

Kontrola jakości nie musi być skomplikowana, ale powinna być stała.

• Podwójna anotacja części próbek i liczenie zgodności (np. współczynnik Kappa).
• Próbki „kontrolne” z znaną prawdą, wplecione w normalną pracę.
• Przegląd trudnych przypadków na krótkich sesjach z annotatorami.

Jeśli spójność między annotatorami jest niska, model także nie będzie w stanie rozróżnić klas. Najpierw trzeba wyprostować definicje i proces.

Narzędzia i organizacja pracy

Narzędzie do anotacji nie musi być zaawansowane, ale powinno wspierać:

• wersjonowanie etykiet,
• eksport w uzgodnionym formacie (CSV/JSONL),
• przypisywanie zadań i prostą statystykę postępu.

Przy większych projektach warto rozdzielić role: anotatorzy, reviewerzy (druga para oczu) i osoba odpowiedzialna za definicje etykiet oraz ich zmiany.

Podział na zbiory treningowy, walidacyjny i testowy

Dlaczego podział danych nie może być przypadkowy

Jeśli dane zostaną podzielone źle, metryki modelu będą złudnie wysokie. Problem pojawi się dopiero po wdrożeniu.

Celem podziału jest uzyskanie uczciwej oceny modelu na danych, których „nie widział” w trakcie treningu ani strojenia hiperparametrów.

Typowe proporcje i warianty podziału

Najprostszy scenariusz to trzy zbiory: train, validation, test.

• Train – zwykle 60–80% próbek.
• Validation – 10–20%, używany do doboru hiperparametrów i wyboru wersji modelu.
• Test – 10–20%, „zamrożony” do końcowej oceny.

Przy małych zbiorach zamiast klasycznego podziału używa się walidacji krzyżowej (cross-validation), a osobny test zostawia tylko do finalnej oceny.

Stratyfikacja i podział czasowy

Podział „losowy” często nie wystarcza.

• Stratyfikacja – zachowanie podobnych proporcji klas w każdym zbiorze (np. fraud/nie-fraud), by uniknąć pustych lub skrajnie małych klas w walidacji.
• Podział czasowy – gdy dane mają porządek w czasie (prognozy, zachowania użytkowników), train pochodzi z wcześniejszego okresu, a walidacja/test z późniejszego.

Podział „przyszłość vs. przeszłość” lepiej odzwierciedla rzeczywiste działanie modelu po wdrożeniu.

Unikanie przecieku informacji (data leakage)

Źle zrobiony podział może sprawić, że model „podgląda” informacje z przyszłości lub z innych zbiorów. Wyniki wtedy wyglądają świetnie, ale są bezużyteczne produkcyjnie.

Klasyczne źródła przecieku to:

• kolumny, które bezpośrednio wynikają z etykiety (np. status „reklamacja rozpatrzona pozytywnie” przy przewidywaniu zwrotu),
• rekordy tego samego użytkownika lub zamówienia lądujące jednocześnie w train i w test,
• agregaty liczone na całym zbiorze przed podziałem (np. globalna średnia użyta potem jako cecha).

Bezpieczniej jest najpierw zrobić podział, a dopiero potem liczyć cechy (feature engineering) osobno na każdym zbiorze albo w czasie, tak jak w realnym systemie.

Balansowanie i reprezentatywność danych

Nierównowaga klas i jej skutki

W wielu zadaniach jedna klasa pojawia się dużo częściej niż druga. Modele uczą się wtedy „grać na łatwej piłce” i ignorują rzadkie przypadki.

Przy wykrywaniu fraudów, awarii czy churnu typowe są sytuacje, gdzie rzadkie przypadki to promile danych. Surowy model potrafi osiągać wysoką dokładność, jednocześnie przegapiając niemal wszystkie zdarzenia, na których najbardziej zależy biznesowi.

Techniki balansowania

Zanim zacznie się kombinować z algorytmami, można poprawić sam zbiór. W praktyce używa się kilku prostych zabiegów:

• undersampling klasy większościowej, by zmniejszyć dysproporcję,
• oversampling klasy mniejszościowej (np. duplikowanie rzadkich przykładów),
• syntetyczne dane (np. SMOTE) tam, gdzie proste duplikaty za szybko prowadzą do przeuczenia.

Dobrym kompromisem bywa lekkie „dopakowanie” klasy mniejszościowej i jednoczesne użycie wag klas w samym modelu, zamiast agresywnego przebalansowania wszystkiego 1:1.

Reprezentatywność względem produkcji

Zbiór treningowy powinien przypominać to, co system zobaczy po wdrożeniu. Chodzi nie tylko o klasy, ale też o kanały pozyskania danych, języki, urządzenia, regiony.

Jeśli produkt będzie działał w kilku krajach, a dane pochodzą z jednego, model zadziała dobrze lokalnie, ale po skalowaniu zacznie się psuć. Widać to zwłaszcza w modelach językowych, gdzie nagła domieszka innego języka potrafi wywrócić metryki.

Monitorowanie dryfu danych

Nawet dobrze zbalansowany zbiór starzeje się. Zmienia się zachowanie użytkowników, oferta, interfejs, procesy biznesowe.

Przydaje się prosty monitoring rozkładów cech i rozkładu klas w danych produkcyjnych. Jeśli zaczynają odbiegać od tego, co było w treningu, to sygnał, że trzeba zebrać nową partię danych i przejść skróconą ścieżkę: przygotowanie, czyszczenie, ewentualna anotacja, ponowny trening.

Dane dla AI i machine learning to nie jednorazowy projekt, tylko powtarzalny proces. Im prostszy, lepiej opisany i bardziej automatyczny zbudujesz pipeline danych, tym łatwiej będzie rozwijać modele, zamiast ciągle gasić pożary w plikach wejściowych.

Automatyzacja pipeline’u danych

Od ręcznego Excela do powtarzalnego procesu

Ręczne poprawki w Excelu są akceptowalne na etapie prototypu, ale natychmiast mszczą się przy pierwszym re-treningu modelu.

Proces przygotowania danych powinien dać się uruchomić ponownie od zera i dać identyczny wynik z tych samych źródeł.

Kluczowe etapy pipeline’u

Niezależnie od technologii, dobrze, jeśli pipeline da się rozpisać na kilka prostych kroków.

• pobranie danych ze źródeł (bazy, API, pliki surowe),
• wstępne przekształcenia techniczne (typy kolumn, parsowanie dat, kodowanie),
• łączenie i filtracja rekordów,
• czyszczenie i walidacje jakościowe,
• inżynieria cech (feature engineering),
• eksport gotowych plików treningowych w ustalonym formacie.

Dla każdego kroku dobrze mieć osobny skrypt lub zadanie w narzędziu orkiestracji, zamiast jednego „magicznego” notebooka.

Narzędzia do orkiestracji

Przy większej liczbie kroków łatwiej zarządzać pipeline’em przez dedykowane narzędzia.

• Airflow, Prefect, Dagster – klasyczne orkiestratory workflowów danych,
• narzędzia MLOps (Vertex AI Pipelines, KubeFlow, MLflow Pipelines) – integrują dane z treningiem modeli,
• proste skrypty cron + Git – przy małych projektach i jednym środowisku.

Niezależnie od wyboru, kluczowe jest logowanie każdego etapu i szybka diagnoza, gdzie pipeline się wyłożył.

Idempotencja i powtarzalność

Ten sam krok uruchomiony dwa razy na tych samych wejściach powinien dać taki sam wynik.

W praktyce sprowadza się to do jawnej kontroli nad:

• wersją kodu (commit w repozytorium),
• wariantem konfiguracji (parametry kroku, ścieżki, zakres dat),
• wersją wejściowych danych (snapshot, tag w hurtowni, hash plików).

Bez tego trudno zrozumieć, dlaczego nowy model nagle zaczął działać inaczej, mimo „braku zmian” po stronie zespołu.

Wersjonowanie danych i eksperymentów

Dlaczego sam Git nie wystarcza

Kod da się spokojnie trzymać w Git, ale pliki danych szybko przekraczają rozsądne rozmiary repozytorium.

Przy modelach, które są odświeżane cyklicznie, potrzeba sposobu na odtworzenie: jak wyglądały dane przy treningu konkretnej wersji modelu.

Strategie wersjonowania danych

Jest kilka prostych sposobów, które sprawdzają się lepiej niż losowe nazwy plików.

• Partycjonowanie po dacie w hurtowni (np. dt=2024-06-01) i zapisywanie, z jakiego zakresu dat pochodzi zbiór treningowy.
• Hash zawartości pliku/partycji zapisany razem z metadanymi modelu.
• Narzędzia typu DVC, LakeFS czy Delta Lake – pozwalają na „commitowanie” stanu danych podobnie jak w Git.

Przy małych projektach wystarczy tabela „modele” w bazie z informacją: ścieżka do danych, zakres dat, wersja pipeline’u.

Rejestrowanie eksperymentów

Podczas prac zwykle powstaje kilkanaście–kilkadziesiąt wariantów modelu. Bez rejestru po paru tygodniach nie da się powiedzieć, czym się różnią.

Przydatne jest systematyczne zapisywanie:

• wersji kodu i konfiguracji (hiperparametry, cechy włączone/wyłączone),
• identyfikatora zbiorów danych (np. data snapshotu, ścieżka),
• metryk na walidacji i na testach,
• krótkiego komentarza kontekstowego (np. „dodano cechy związane z kanałem sprzedaży”).

MLflow, Weights & Biases, Neptune albo prosta tabela w Postgresie – technologia jest drugorzędna, liczy się konsekwencja.

Bezpieczeństwo i prywatność w plikach danych

Minimalizacja danych wrażliwych

Modele zwykle nie potrzebują pełnych danych osobowych, by dobrze działać. Dane wrażliwe stają się tylko ryzykiem prawnym i organizacyjnym.

Na etapie projektowania schematu danych warto:

• odrzucić pola oczywiście zbędne (PESEL, adres zamieszkania, pełne numery dokumentów),
• zastąpić ID klientów wewnętrznymi identyfikatorami technicznymi,
• agregować szczegóły tam, gdzie wystarczą statystyki (np. przedział wiekowy zamiast pełnej daty urodzenia).

Im wcześniej zanonimizujesz dane, tym łatwiej będzie je później przenosić i udostępniać w zespole ML.

Anonimizacja i pseudonimizacja

Sam hashing identyfikatorów często nie wystarcza, bo łatwo je odtworzyć z innych źródeł.

Bezpieczniejsze techniki obejmują:

• pseudonimizację z losowymi kluczami (mapowanie ID klienta → losowy token trzymany w bezpiecznej usłudze),
• maskowanie części pól (np. pozostawienie tylko prefiksu numeru telefonu lub kodu pocztowego),
• perturbację wartości liczbowych w celach analitycznych (szum w granicach, które nie psują metryk modelu).

Przy danych tekstowych największym problemem są wklejone maile, numery telefonów, nazwiska – często trzeba je wycinać wzorcami (regexy) i zastępować placeholderami.

Dostępy i ścieżka audytu

Pliki treningowe nie powinny być kopiowane „na boki” po serwerach, laptopach i USB.

Dobrą zasadą jest trzymanie ich w jednym, kontrolowanym miejscu i nadawanie dostępu rolom, a nie pojedynczym osobom.

• czytelne strefy: dane surowe, dane oczyszczone, zbiory treningowe,
• logowanie kto i kiedy pobiera duże fragmenty danych,
• automatyczne wygasanie dostępów po czasie lub zmianie roli.

Przy audycie ważne jest, by pokazać nie tylko zasady, ale też faktyczne logi i procedury odtwarzania historii przetwarzania.

Specyfika danych dla modeli językowych

Segmentacja i tokenizacja tekstu

Modele językowe nie „widzą” dokumentu tak jak człowiek. Dostają sekwencję tokenów o ograniczonej długości.

Trzeba zdecydować, jak pociąć dokumenty:

• po akapitach lub sekcjach (nagłówki, paragrafy),
• po limitach tokenów (np. 512–1024),
• według naturalnych granic w danym biznesie (np. jedna sprawa, jedna rozmowa, jedna wymiana maili).

Za długie fragmenty będą przycinane przez model, za krótkie utracą kontekst. Często kończy się na prostym kompromisie: kontekst per zadanie użytkownika.

Szum i powtarzalność w danych tekstowych

Przy masowym zrzucie logów, maili czy czatów pojawia się dużo powtórzeń i bezużytecznych fragmentów.

Dobrze jest odsiać:

• komunikaty techniczne (stack trace, logi systemowe) jeśli nie są przedmiotem uczenia,
• automatyczne stopki, bannery RODO, podpisy,
• bardzo krótkie, nieinformacyjne wiadomości („ok”, „dzięki”).

W wielu projektach usunięcie stałych stopek i szablonów robi większą różnicę niż późniejsze „magiczne” tricki na modelu.

Formatowanie dokumentów złożonych

Przy dokumentach PDF, skanach, prezentacjach pojawia się problem struktury: tabele, nagłówki, przypisy.

Prosty zrzut tekstu z OCR psuje kontekst. Warto zachować choć szczątkową strukturę:

• naklejanie tagów sekcji (np. <title>, <section>, <table>),
• oznaczenie komórek tabeli jako oddzielnych pól lub przynajmniej wierszy,
• tagi pozycji z formularzy („pole: wartość”), by łatwiej nauczyć ekstrakcję informacji.

W JSONL da się to osiągnąć przez pola typu sections, tables, metadata, zamiast jednego nieopisowego text.

Instrukcje, kontekst i odpowiedzi przy treningu LLM

Przy treningu lub dostrajaniu LLM istotne jest, by pliki danych odzwierciedlały przyszłe użycie modelu.

Dla scenariuszy chatowych lub Q&A jeden rekord zwykle zawiera:

• instrukcję lub rolę systemu,
• historię dialogu (role: user, assistant),
• flagę, która część jest celem uczenia (np. ostatnia odpowiedź asystenta).

Przykładowy zapis w JSONL jest zwykle czytelniejszy niż zlepiony tekst, bo utrzymuje role i strukturę konwersacji w osobnych polach.

Specyfika danych dla modeli tablicowych

Stabilność cech w czasie

Przy modelach tablicowych częstym problemem jest drżenie definicji cech.

Kolumna „liczba zamówień” raz oznacza ostatnie 30 dni, innym razem cały okres historii. Taki chaos sprawia, że metryki są nieporównywalne między eksperymentami.

Każdą cechę warto zdefiniować jednoznacznie: okno czasowe, filtr (typ zamówień), moment obliczenia (tylko przeszłość względem etykiety).

Unikanie cech „po wyniku”

Cechy nie mogą wprost zawierać informacji obliczonych po zdarzeniu, które model ma przewidywać.

Typowe pułapki:

• liczba reklamacji liczona po dacie, dla której przewidujemy churn,
• informacje o windykacji użyte przy przewidywaniu niewypłacalności,
• sumy transakcji liczone na bazie pełnej historii, a nie tylko przeszłości.

Rozwiązaniem jest rygorystyczne stosowanie „okna”: każda cecha musi dać się policzyć z danych dostępnych najpóźniej w chwili, gdy decyzja ma być podjęta.

Normalizacja i kodowanie cech

W zależności od modelu potrzebne są różne transformacje.

• Dla drzew (XGBoost, Random Forest) skala liczbowa jest drugorzędna, ważna jest za to jakość podziałów i brak ekstremalnych outlierów.
• Dla modeli liniowych i sieci neuronowych przydaje się standaryzacja (średnia 0, wariancja 1) lub normalizacja do przedziału.
• Kategorie można zakodować jako one-hot, target encoding lub embeddingi, ale trzeba pilnować, by nie wprowadzić przecieków (target encoding liczony tylko na train, z walidacją krzyżową).

Parametry normalizacji (średnia, odchylenie) trzeba policzyć na train i zapisać, by później zastosować dokładnie te same wartości w produkcji.

Przenoszenie i udostępnianie plików danych

Środowiska: lokalne, testowe, produkcyjne

Modele zwykle powstają lokalnie lub w środowisku rozwojowym, a potem są wdrażane gdzie indziej.

Pliki danych nie powinny krążyć w formie ręcznie kopiowanych archiwów. Lepszy jest prosty, kontrolowany przepływ:

• surowe dane pozostają w infrastrukturze produkcyjnej,
• stamtąd są przetwarzane do wersji zanonimizowanej,
• anonimowe snapshoty są udostępniane do środowiska ML (np. osobny bucket w S3, GCS).

To redukuje ryzyko wyniesienia newralgicznych informacji i upraszcza audyt.

Formaty transferowe i kompresja

Przy większych wolumenach znaczenie ma też sam sposób przenoszenia.

• CSV dobrze sprawdza się przy małych plikach, ale przy dziesiątkach gigabajtów lepszy jest Parquet z kompresją.
• JSONL jest wygodny dla danych tekstowych i pół-strukturalnych, zwłaszcza przy strumieniowaniu.
• Kompresja (gzip, zstd) może istotnie zmniejszyć koszty transferu i miejsca, kosztem czasu odczytu.

Stały format i konwencja nazewnictwa (np. project/dt=YYYY-MM-DD/part-*.parquet) oszczędzają sporo czasu na szukaniu „tego właściwego pliku”.

Walidacja końcowa plików przed treningiem

Checklista przed uruchomieniem treningu

Przed puszczeniem drogiego treningu dobrze przejść krótką, techniczną checklistę.

• Spójność liczby próbek między cechami a etykietami.
• Brak oczywistych wycieków (cechy zależne od przyszłości, mieszanie użytkowników między train a test).
• Rozkład klas i podstawowych cech (czy nie ma dramatycznych różnic między train/val/test).
• Jakość etykiet (próbna manualna inspekcja kilkudziesięciu–kilkuset przykładów losowo).

Taki szybki przegląd zwykle wychwytuje błędy, które inaczej wyszłyby dopiero przy „dziwnych” wynikach modelu.

Jeśli dane są przetwarzane cyklicznie, checklista też powinna być zautomatyzowana. Prosty skrypt, który przy każdym nowym zbiorze generuje raport z rozkładami, udziałem klas, udziałem braków i podstawowymi statystykami, szybko staje się ważniejszy niż pojedyncza, ręczna analiza w notebooku.

Przy projektach z dłuższą historią dobrze zachować kilka takich raportów z różnych okresów. Pozwala to zauważyć dryf danych – nagłą zmianę typów spraw w call center, inne zachowanie użytkowników po zmianie cennika czy sezonowe piki, które powinny być widoczne także w późniejszych metrykach modelu.

Sensowną praktyką jest przejście przez kilka rekordów od początku, środka i końca zbioru. Szybko wychodzą na jaw problemy typu: przesunięte kolumny, dziwnie zakodowane wartości, brakujące pola w nowych miesiącach danych. Taka „mikroskala” dobrze uzupełnia hurtowe statystyki.

Jeżeli model będzie wdrażany produkcyjnie, przed treningiem dobrze jest też przetestować ścieżkę odczytu plików tak, jak zrobi to pipeline w produkcji: z tym samym kodem, tym samym formatem, na tej samej infrastrukturze. Unika się wtedy zaskoczenia, że lokalnie wszystko działało, a w docelowym środowisku brakuje pamięci lub biblioteka nie obsługuje konkretnej wersji formatu.

Dobrze przygotowane pliki danych nie gwarantują sukcesu modelu, ale dramatycznie zawężają pole potencjalnych problemów. Gdy struktura jest stabilna, etykiety spójne, a pipeline powtarzalny, praca nad samym modelem staje się przewidywalnym rzemiosłem, a nie serią niekontrolowanych eksperymentów.

Zarządzanie wersjami danych i powtarzalność eksperymentów

Model można łatwo odtworzyć tylko wtedy, gdy wiadomo, na jakich dokładnie danych był trenowany.

Przy pojedynczym pliku CSV to prosta sprawa, przy dziennych snapshotach, wielu źródłach i kolejnych iteracjach modeli – już nie.

Wersjonowanie zbiorów danych

Najprostsza forma to konwencja nazewnictwa i katalogów.

• Data i godzina w ścieżce lub nazwie pliku (churn/2024-05-01/train.parquet).
• Numer wersji schematu (schema_v2 w ścieżce albo w metadanych pliku).
• Jawne oznaczanie, czy plik jest surowy (raw), czy po przetwarzaniu (features).

Przy większych projektach przydają się narzędzia typu DVC, LakeFS albo systemy katalogów danych wbudowane w platformy ML.

Kluczowe jest, by z konkretnej etykiety modelu (np. tag w repozytorium kodu) dało się dojść do dokładnej wersji danych, bez zgadywania.

Hashowanie i metadane techniczne

Dla plików o stałym formacie można dodać proste zabezpieczenie: hasz zawartości.

• Wyliczenie np. md5 lub sha256 pliku i zapisanie go w logu eksperymentu.
• Przy kolejnym treningu porównanie hashy jako szybka kontrola, czy „ten sam” plik faktycznie się nie zmienił.

Warto też trzymać obok dane techniczne:

• liczbę rekordów,
• listę kolumn z typami,
• wersje bibliotek użytych do przygotowania cech.

To minimalizuje ryzyko cichego rozjechania się schematu między treningami.

Zapisywanie konfiguracji eksperymentów

Sama ścieżka do pliku nie wystarczy, gdy pipeline ma opcje i flagi.

• Konfigurację generowania cech (np. okno 30 vs. 90 dni) warto trzymać w jednym, wersjonowanym pliku YAML/JSON.
• Parametry podziału na train/val/test (seed, zakres dat) też powinny być jawne.
• Każdy eksperyment powinien zapisywać odwołanie do tej konfiguracji, a nie tylko „notatkę w głowie”.

Przy powrocie do projektu po kilku miesiącach to często różnica między godziną a tygodniem debugowania.

Bezpieczeństwo i prywatność danych w plikach do trenowania

Dane do AI zwykle zawierają informacje, które nie powinny krążyć po dyskach laptopów i publicznych bucketach.

Identyfikatory osobowe i pseudonimizacja

PESEL, numer telefonu, adres e-mail czy dokładny adres zamieszkania rzadko są potrzebne do samego modelu.

• Bezpieczniej jest zastąpić identyfikatory użytkownika stabilnym, losowym ID.
• Przy danych transakcyjnych często wystarczy agregacja po cechach, bez przechowywania surowych opisów.
• Przy logach tekstowych dobrze jest usuwać lub maskować fragmenty zawierające dane wrażliwe (np. regexy na numery kart).

Pseudonimizacja powinna być częścią pipeline’u, a nie ręczną operacją wykonywaną „tym razem”.

Dostęp do plików i ślady audytowe

Pliki z danymi treningowymi nie powinny być dostępne na zasadzie „kto ma link, ten czyta”.

• Dedykowane bucket’y lub udziały z jasno określonymi uprawnieniami.
• Logi dostępu (kto, kiedy, skąd pobrał plik).
• Oddzielenie środowisk: inne konta/projekty dla produkcji i dla eksperymentów.

Przy późniejszych audytach decyzji modelu możliwość pokazania, jakie dane były użyte i kto miał do nich dostęp, często bywa wymogiem formalnym.

Tekstowe dane wrażliwe

Przy mailach, czatach czy zgłoszeniach ticketowych problem danych wrażliwych jest trudniejszy niż w tabelach.

Sensowna praktyka to kilka warstw ochrony:

• reguły usuwające oczywiste dane (numery kart, hasła, tokeny API),
• modele NER wykrywające imiona, adresy, nazwy firm,
• proste heurystyki: „jeśli wiadomość zawiera słowo hasło, nie trafia do zbioru treningowego”.

Czasem lepiej zrezygnować z części danych niż ryzykować wyciek newralgicznych fragmentów w zachowaniu modelu.

Automatyzacja pipeline’u przygotowania danych

Ręczne notatniki sprawdzają się przy pierwszym prototypie. Przy regularnym trenowaniu modeli szybko stają się wąskim gardłem.

Od prototypu do pipeline’u

Po pierwszym udanym eksperymencie warto przepisać luźny kod na prosty pipeline.

• Wyodrębnienie etapów: ekstrakcja, czyszczenie, tworzenie cech, podział na zbiory.
• Każdy etap powinien czytać z określonego formatu i zapisywać wynik w innym, jasno opisanym miejscu.
• Parametry (daty, filtry) przekazywane jako konfiguracja, a nie w kodzie.

Narzędzie może być proste: Makefile, Airflow, Prefect, Dagster, albo nawet seria skryptów z sensownymi nazwami.

Monitorowanie jakości w pipeline’ie

Pełna automatyzacja bez kontroli jakości jest ryzykowna.

Przy każdym przebiegu pipeline’u przydają się:

• sprawdzenia schema (czy nie zniknęły/nie doszły kolumny bez aktualizacji kodu),
• limity na odsetek braków i ekstremalnych wartości,
• porównanie rozkładu wybranych cech z ostatnim „dobrym” snapshotem.

Jeśli coś odbiega powyżej ustalonego progu, pipeline powinien zakończyć się błędem, a nie generować „dziwne” dane do treningu.

Logowanie i artefakty pośrednie

Pipeline przygotowania danych rzadko jest idealny od pierwszego dnia.

Przy debugowaniu przydaje się zachowanie artefaktów pośrednich:

• małych próbek danych po każdym etapie (np. pierwsze 1000 rekordów),
• raportów w formacie HTML/Markdown z wykresami rozkładów,
• logów z czasem wykonania poszczególnych kroków.

Dzięki temu widać, od którego miejsca dane zaczynają „wyglądać inaczej”.

Specyficzne wyzwania przy danych z logów i zdarzeń

Logi aplikacyjne i zdarzenia systemowe to częste źródło danych dla modeli predykcyjnych i sekwencyjnych.

Uporządkowanie zdarzeń w czasie

W logach kolejność zdarzeń bywa zaburzona: różne serwery, różne strefy czasowe, opóźnienia w kolejkach.

• Daty i czasy trzeba sprowadzić do jednolitej strefy, najlepiej UTC.
• Należy wybrać jedno, spójne źródło prawdy o czasie zdarzenia (timestamp aplikacji vs. timestamp przyjęcia do systemu logowania).
• Przy sekwencjach kluczowe jest sortowanie zdarzeń per użytkownik/encja, a nie po globalnym czasie.

Błędy w kolejności zdarzeń szybko psują modele typu RNN/Transformer opierające się na historii zachowań.

Agregacje sesyjne i okna czasowe

Surowe logi są często zbyt szczegółowe, by trenować na nich wprost.

Praktyczne podejście to budowa cech na poziomie sesji lub okien czasowych:

• liczba akcji w sesji,
• czas trwania sesji,
• liczba błędów lub specyficznych eventów w ostatnich X minutach/godzinach.

Okno musi być zdefiniowane względem chwili podejmowania decyzji, by nie wprowadzać cech z przyszłości.

Filtrowanie szumu w logach

Logi bywają pełne zdarzeń technicznych, które nic nie wnoszą do problemu biznesowego.

• Trzeba zdecydować, które typy eventów są istotne, a które można całkowicie odrzucić.
• Dla zdarzeń rzadkich, ale krytycznych, często buduje się osobne cechy binarne („czy wystąpiło zdarzenie X w ostatnich 7 dniach”).
• Przy bardzo częstych eventach agregacja do prostych liczników lub histogramów zwykle daje lepszy stosunek sygnału do szumu.

Specyfika danych obrazowych i multimedialnych

Obrazy, audio i wideo mają inne problemy niż klasyczne dane tabelaryczne czy tekst.

Spójność rozdzielczości i proporcji

Modele konwolucyjne i wizualne transformery wymagają stałego rozmiaru wejścia.

• Obrazy trzeba przeskalować i ewentualnie przyciąć lub wypełnić tłem.
• Trzeba ustaloną metodą radzić sobie z różnymi proporcjami (crop vs. letterbox).
• Warto zapisać, czy w preprocessing’u zachowano proporcje, czy je zniekształcono.

Spójność pipeline’u przygotowania obrazów jest tak samo ważna jak przy tabelach – inne parametry na etapie treningu i predykcji potrafią całkowicie zniszczyć wyniki.

Formaty i kompresja obrazów

JPEG, PNG, WebP – każdy format ma inne właściwości.

• JPEG jest stratny, ale znacznie lżejszy, typowy dla zdjęć.
• PNG bywa lepszy przy grafikach z ostrymi krawędziami i tekstem.
• Dla treningu modele zwykle czytają obrazy z plików na dysku lub zbinowanych rekordów (TFRecord, LMDB).

Nie ma sensu trzymać plików w jakości przewyższającej rozdzielczość wejścia modelu – tylko rośnie koszt I/O.

Etykietowanie obrazów

Przy obrazach anotacja szybko staje się największym kosztem.

• Klasyfikacja obrazów: jedna lub kilka etykiet na obraz.
• Detekcja obiektów: bounding boxy, kategorie obiektów.
• Segmentacja: maski pikselowe.

W plikach danych trzeba zadbać o spójny schemat: format koordynatów (piksele, ułamki), system odniesienia (lewy górny róg, kolejność x/y), konwencję dla przypadków bez obiektów.

Kontrola dryfu danych i schematu w czasie

Dane produkcyjne się zmieniają. Modele trenowane na „zeszłorocznym świecie” z czasem tracą jakość.

Dryf rozkładów cech

Porównanie rozkładu cech między historycznym zbiorem treningowym a aktualnymi danymi wejściowymi bywa pierwszym sygnałem problemów.

• Dla cech liczbowych: średnia, mediana, percentyle; proste testy statystyczne.
• Dla kategorii: zmiany udziału poszczególnych wartości, pojawianie się nowych kategorii.
• Dla tekstu: zmiany długości, słownictwa, udziału języków.

Jeśli dryf przekracza ustalony próg, warto wymusić aktualizację lub ponowny trening modelu.

Dryf schematu danych

Zmiany w upstream’owych systemach często widać najpierw w schemacie plików.

• Nowe kolumny, znikające kolumny, zmiany typów.
• Zmiana znaczenia tego samego pola (np. nowy zakres kodów statusu).
• Zmiana słownika wartości kategorii (np. po rebrandingu).

Nawet proste narzędzia do porównywania schematów między kolejnymi snapshotami potrafią oszczędzić wiele godzin szukania przyczyny spadku metryk.

Praktyczne wzorce organizacji katalogów z danymi

Przy rosnącej liczbie plików bałagan w katalogach szybko mści się przy każdym nowym projekcie.

Hierarchia według projektu i fazy przetwarzania

Układ katalogów powinien odzwierciedlać przepływ danych.

• project/raw/ – surowe snapshoty, bez zmian merytorycznych.
• project/processed/ – po czyszczeniu, z ujednoliconym schematem.
• project/features/ – finalne pliki używane do treningu.

W każdym z tych poziomów można stosować podział po dacie i środowisku (train, val, test).

Konwencje nazw plików

Nazwa pliku powinna wystarczyć do orientacyjnego zrozumienia zawartości.

• Elementy: projekt, typ danych, zakres czasu, wersja schematu, środowisko.
• Przykład: fraud_features_train_2024-01-01_2024-03-31_v3.parquet.
• Unikanie spacji i przypadkowych skrótów, które zna tylko jedna osoba.

Spójna konwencja nazewnictwa ułatwia także definiowanie reguł retencji i backupów.

Przygotowanie danych do udostępnienia innym zespołom

Często ten sam zbiór danych ma służyć kilku zespołom lub projektom.

Dokumentacja schematu i założeń

Plik danych bez opisu szybko staje się źródłem błędnych interpretacji.

Dobrą praktyką jest dołączanie prostego „data card” lub „model card” w formacie Markdown obok pliku z danymi. Powinny tam się znaleźć: definicje pól, zakres dat, źródła, zastosowane filtry oraz znane ograniczenia. Jeden plik opisu na wersję zbioru eliminuje większość nieporozumień między zespołami.

Przydatne bywa też dopisanie kilku konkretnych przykładów użycia. Krótkie fragmenty SQL lub kodu w Pythonie pokazujące typowy join, filtr czy sposób wyliczenia etykiety pomagają szybciej wystartować nowemu zespołowi i zmniejszają liczbę pytań „jak tego używać?”.

Wersjonowanie i stabilność interfejsu danych

Jeśli wiele zespołów korzysta z tych samych plików, zmiany schematu trzeba traktować jak zmiany API. Zamiast nadpisywać istniejące pola, lepiej wprowadzać nową wersję zbioru lub nowe kolumny, oznaczając stare jako przestarzałe na poziomie dokumentacji.

Prosty system wersjonowania (np. v1, v2 w nazwie pliku lub katalogu) i okres przejściowy, w którym dostępne są dwie wersje, daje czas na migrację. Dobrze działają też niewielkie pliki „changelog” opisujące, co dokładnie zmieniło się między wersjami.

Dostęp, bezpieczeństwo i anonimizacja

Przy udostępnianiu danych innym zespołom trzeba jasno rozdzielić zestawy produkcyjne od sandboxowych. Często oznacza to przygotowanie osobnych, zanonimizowanych snapshotów z usuniętymi lub zhaszowanymi identyfikatorami oraz zredukowanym zestawem pól wrażliwych.

Warto zdefiniować poziomy dostępu: pełny dla zespołów operujących blisko produkcji, ograniczony dla analityków eksplorujących dane, minimalny dla zewnętrznych dostawców. Takie zasady powinny być opisane w jednym miejscu i odwoływać się do nich zarówno narzędzia dostępu, jak i sama dokumentacja zbioru.

Dobrze przygotowane pliki danych – od surowych snapshotów po finalne zbiory treningowe – stają się wtedy stabilnym fundamentem, na którym można budować kolejne modele, eksperymenty i projekty bez ciągłego „odkręcania” starych błędów w danych.

Reprodykowalność procesu przygotowania danych

Jednorazowy „notebook cud” szybko przestaje wystarczać, gdy zbiór danych trzeba odświeżać lub rozwijać.

Od notebooka do pipeline’u

Eksplorację robi się zwykle w notebooku, ale produkcyjny zbiór danych powinien powstawać z powtarzalnego pipeline’u.

• Każdy krok: ekstrakcja, czyszczenie, joiny, wyliczanie cech – osobny moduł lub etap joba.
• Parametry (daty, wersje słowników, progi filtrów) wyciągnięte do configu, a nie zaszyte w kodzie.
• Ten sam pipeline dla wszystkich środowisk (dev, test, prod), różnią się tylko parametry i ścieżki.

Dzięki temu nowa wersja zbioru to uruchomienie joba, a nie ręczne przepisywanie fragmentów notebooka.

Śledzenie wersji kodu i danych wejściowych

Powtarzalność oznacza możliwość odtworzenia dokładnie tego samego zbioru po czasie.

• Kod transformacji w systemie kontroli wersji (Git, Mercurial).
• Źródłowe snapshoty danych oznaczone datą i identyfikatorem (np. hash, numer zlecenia ETL).
• Log, który łączy wersję kodu, wejściowy snapshot i powstały plik z danymi treningowymi.

Bez takiego łańcucha ciężko później wyjaśnić, dlaczego model sprzed kilku miesięcy działał inaczej.

Testy dla pipeline’u danych

Dane też można testować automatycznie, nie tylko kod aplikacji.

• Testy schematu: czy wszystkie wymagane kolumny istnieją, mają oczekiwane typy i brak duplikatów.
• Testy jakości: proste asercje na rozkładach (brak ujemnych wartości tam, gdzie to niemożliwe, zakres dat, minimalna liczba wierszy).
• Testy regresji: porównanie kluczowych agregatów z poprzednią wersją zbioru (np. udział klasy pozytywnej, liczba unikalnych użytkowników).

Nawet kilkanaście prostych testów odcina większość „niespodzianek” typu puste etykiety czy nagłe zaniki całych segmentów użytkowników.

Automatyzacja walidacji i monitoringu danych

Im wcześniej wykryte problemy z danymi, tym mniej czasu marnuje się na debugowanie modeli.

Reguły jakości danych jako kod

Zamiast opisywać oczekiwania wobec danych w dokumentach, lepiej zapisać je jako reguły.

• Minimalne i maksymalne wartości dla kluczowych pól liczbowych.
• Listy dozwolonych wartości kategorii i ich typowy udział.
• Warunki między polami (np. created_at <= updated_at).

Takie reguły da się odpalać przy każdym budowaniu zbioru albo przy przyjmowaniu nowych danych do „raw”. W razie naruszenia pipeline może zatrzymać się lub oznaczyć partię jako podejrzaną.

Metryki jakości danych w czasie

Jednorazowa kontrola nie wystarczy, bo źródła ciągle się zmieniają.

• Monitorowanie udziału braków (NULL, pustych napisów) w wybranych kolumnach.
• Śledzenie liczby rekordów na dobę/tydzień, by wykryć przerwy w strumieniu.
• Alarmy na gwałtowne skoki w prostych agregatach (średnia wartości, udział klasy pozytywnej).

Prosta tablica z tymi metrykami w dashboardzie często wystarcza, by inżynierowie danych reagowali, zanim spadną metryki modeli.

Przygotowanie danych pod różne typy modeli

Ten sam problem biznesowy można rozwiązać różnymi algorytmami, ale wymagają one nieco innego przygotowania plików.

Modele klasyczne (drzewa, regresje)

Modele typu XGBoost, LightGBM czy regresje najczęściej korzystają z tabel z wyliczonymi cechami.

• Każdy wiersz to obserwacja (użytkownik, transakcja, sesja) z etykietą w jednej kolumnie.
• Cechy liczbyczne skalowane konsekwentnie, ale niekoniecznie standaryzowane (drzewa są odporne).
• Cechy kategoryczne przekodowane na liczby (label encoding, target/stats encoding) lub one-hot.

Pliki mogą być przechowywane w formatach kolumnowych (Parquet), a w pamięci ładowane partiami, jeśli dane są duże.

Modele sekwencyjne i czasowe

RNN, Transformers czasowe czy klasyczne modele ARIMA wymagają poprawnej struktury czasowej.

• Osobne pliki lub partycje per encja (użytkownik, urządzenie) albo przynajmniej sortowanie po kluczu i czasie.
• Zdefiniowane okna historii (np. ostatnie N zdarzeń lub dany zakres czasu) w jednym wierszu lub jako zagnieżdżona struktura.
• Jasna konwencja dla braków w sekwencji (padding, maski).

Niektóre biblioteki (np. PyTorch, TensorFlow) lepiej współpracują z formatami binarnymi (TFRecord, własne shardy), co warto wziąć pod uwagę przy projektowaniu plików.

Modele multimodalne

Łączenie tekstu, obrazu i danych tabelarycznych wymusza spójną warstwę identyfikatorów.

• Jeden plik „master” z kluczem i metadanymi (np. sample_id, etykieta, atrybuty numeryczne).
• Osobne magazyny dla obrazów, tekstów, audio, powiązane przez sample_id lub inny stabilny identyfikator.
• Pliki indeksów (np. JSONL lub Parquet) opisujące, gdzie leżą poszczególne modality (ścieżka do obrazu, długość sekwencji tekstowej).

Taki podział pozwala bezboleśnie podmieniać jedną modalność (np. lepsze tekstowe opisy) bez przebudowy całego zbioru.

Specyfika danych pod modele generatywne

Modele generatywne mają szczególnie wyostrzoną wrażliwość na jakość i „styl” danych wejściowych.

Dane dla modeli językowych

Przy trenowaniu lub dostrajaniu LLM najwięcej pracy idzie w jakość korpusu.

• Filtracja spamu, powtórek, stron z listami słów kluczowych, treści niskiej jakości.
• Usuwanie danych wrażliwych: identyfikatory osobowe, dane finansowe, loginy, hasła.
• Normalizacja znaków (Unicode), ujednolicenie końcówek linii, kodowania.

Często przydaje się kilkuetapowa selekcja: najpierw proste filtry heurystyczne, później klasyfikator jakości treści trenowany na ręcznie ocenionym podzbiorze.

Format instrukcji i odpowiedzi

Dla modeli instrukcyjnych kluczowe jest spójne formatowanie promptów i odpowiedzi w pliku.

• Jasne rozdzielenie roli użytkownika i asystenta (np. pola user, assistant w JSONL).
• Stały schemat metadanych: język, kategoria zadania, długość, flaga bezpiecznych/ryzykownych treści.
• Konsekwentne użycie tokenów specjalnych (np. <user>, <assistant>) albo zgodność z formatem bazowego modelu.

Mieszanie wielu niespójnych formatów w jednym pliku komplikuje trening i utrudnia diagnozowanie problemów.

Dedupikacja i balans treści

Modele generatywne szybko „uczą się na pamięć” powtarzających się fragmentów.

• Dedupikacja dokumentów na poziomie hashy lub podobieństwa tekstowego.
• Ograniczanie dominujących źródeł (np. jednej domeny) przez undersampling.
• Kontrola udziału różnych typów zadań (pytania faktograficzne, kod, dialogi, instrukcje proceduralne).

Bez tych kroków model bywa świetny w powtarzaniu najczęstszych wzorców, ale słaby w mniej reprezentowanych zastosowaniach.

Praktyka iteracyjnego poprawiania zbiorów danych

Zbiór danych rzadko jest „dobry od pierwszego strzału”. Najlepsze efekty daje iteracja powiązana z wynikami modelu.

Zbieranie feedbacku z treningów

Po każdym treningu warto przejrzeć typowe błędy modelu.

• Próbkowanie przypadków, gdzie model się myli z dużą pewnością (fałszywe pewniaki).
• Analiza segmentów z najgorszymi metrykami (np. konkretne kraje, typy urządzeń, małe firmy).
• Identyfikacja systematycznych braków danych (np. brak cech dla nowych produktów).

Takie „plamy ślepoty” wskazują, gdzie brakuje danych, anotacji lub sensownych cech.

Aktualizacja schematu i cech

Zamiast chaotycznie dodawać kolejne kolumny, lepiej planować zmiany schematu w małych, kontrolowanych krokach.

• Dodawanie nowych cech w osobnych kolumnach, bez usuwania starych, dopóki nie ma twardych dowodów, że są zbędne.
• Eksperymenty A/B na poziomie zbioru cech: porównanie modeli z różnymi podzbiorami kolumn.
• Oznaczanie w dokumentacji cech eksperymentalnych i stabilnych.

Pozwala to redukować „dług cechowy”, który inaczej prowadzi do setek kolumn o niejasnym pochodzeniu.

Systematyczne rozszerzanie danych

Gdy wiadomo, czego model „nie widzi”, można świadomie dobudowywać dane.

• Dokładanie nowych okresów czasu, ale z pilnowaniem spójności etykiet i sposobu liczenia cech.
• Dobór dodatkowych źródeł tylko dla konkretnych segmentów (np. dane branżowe dla B2B).
• Ponowne anotowanie trudnych przypadków przez bardziej doświadczonych annotatorów.

Kluczowe jest, aby każda taka zmiana była odnotowana przy wersji zbioru, razem z motywacją i oczekiwanym efektem.

Minimalny zestaw „higieny danych” na start

Nawet w małym projekcie kilka nawyków mocno podnosi szanse, że dane nie „wysadzą” modelu po tygodniu.

Stałe identyfikatory i zegar

Dwa elementy, które ułatwiają niemal każdą analizę i model.

• Stabilny identyfikator encji (użytkownik, produkt, urządzenie) w każdym pliku, najlepiej bez przeciążeń znaczeniowych.
• Jedno pole czasu zdarzenia w uzgodnionej strefie i formacie.

Od tego da się zawsze dojść do bardziej skomplikowanych konstrukcji, jak sesje czy okna czasowe.

Jasna etykieta i jej definicja

Etykieta powinna mieć precyzyjną, jednoznaczną definicję.

• Znany horyzont czasowy (np. konwersja w ciągu 7 dni od kliknięcia).
• Jedna kolumna z finalną etykietą w pliku cech, reszta jako pomocnicze pola do audytu.
• Opis, jak etykieta była liczona, najlepiej w formie krótkiego pseudokodu lub SQL.

Bez tego każdy kolejny model może „rozumieć” cel inaczej, nawet jeśli plik nazywa się tak samo.

Konsekwentne oznaczanie braków

Braki danych pojawiają się zawsze, różni się tylko sposób ich obsługi.

• Warto odróżniać brak techniczny (NULL) od braku znaczeniowego (np. „nie dotyczy”).
• Osobne flagi binarne sygnalizujące brak informacji w kluczowych polach.
• Spójna strategia imputacji, zapisana obok pipeline’u (np. mediany na poziomie kraju).

To ogranicza ryzyko, że kolejny zespół inaczej potraktuje te same braki i dostanie zupełnie inne wyniki na tym samym pliku.

Najczęściej zadawane pytania (FAQ)

Jak przygotować dane do machine learning krok po kroku?

Najprostszy schemat to: zebranie danych z głównych źródeł, ich wstępne oczyszczenie, zdefiniowanie etykiet, przygotowanie cech (feature engineering), podział na zbiory treningowe i walidacyjne oraz zapis w spójnym formacie plików.

W praktyce oznacza to m.in. usuwanie duplikatów, ujednolicanie kodowań, dopilnowanie, żeby w cechach nie było informacji „z przyszłości” oraz dokładny opis, skąd wzięła się każda kolumna i etykieta. Na końcu warto sprawdzić, czy inna osoba byłaby w stanie odtworzyć ten sam dataset z użyciem Twojej procedury.

Jaki format plików danych jest najlepszy do AI i uczenia maszynowego?

Do klasycznych danych tabelarycznych najczęściej używa się CSV lub TSV, bo są proste, czytelne i wspierane przez większość narzędzi. Przy większej skali lub pracy w ekosystemie big data lepiej sprawdza się Parquet lub podobne formaty kolumnowe.

Dla tekstu i danych zagnieżdżonych popularne są JSON oraz JSONL (każdy rekord w osobnej linii). JSONL dobrze działa przy dużych zbiorach dla modeli językowych, logów czy anotacji, bo można łatwo przetwarzać plik strumieniowo.

Czym różni się przygotowanie danych do AI od danych do BI?

Dane do BI mają służyć raportowaniu i analizie historycznej, więc kluczowe są poprawne agregacje, spójne definicje metryk i możliwość „zliczania” faktów. Modelowi ML potrzebne są bardziej szczegółowe i „surowe” informacje, często bez nadmiernych agregacji, które zacierają sygnał.

W ML trzeba też pilnować braku wycieków informacji (żadnych danych z przyszłości w cechach), ciągłości w czasie i dokładnego śledzenia tego, jak powstały etykiety. Zdarza się, że tabele z hurtowni świetnie działają w BI, a kompletnie psują walidację modelu.

Ile danych potrzeba do trenowania modelu machine learning?

Nie ma jednej liczby. Proste modele na dobrze opisanych danych potrafią działać już przy dziesiątkach tysięcy rekordów, ale dla złożonych problemów (np. obraz, język naturalny) często potrzebne są setki tysięcy lub miliony próbek.

Dobrym podejściem jest zaczęcie od realistycznej skali (np. to, co da się łatwo wyeksportować i oznaczyć), zbudowanie pierwszej wersji modelu i dopiero na tej podstawie planowanie, czy opłaca się inwestować w kolejne dane lub dokładniejsze etykietowanie.

Na czym polega etykietowanie danych krok po kroku?

Najpierw trzeba zdefiniować kategorie lub wartości docelowe (np. spam/nie-spam, typ dokumentu, wynik transakcji), a potem spisać jasne instrukcje dla anotatorów: co zaliczamy do której klasy, jakie są przykłady graniczne, kiedy rekord oznaczamy jako „niejednoznaczny”.

Następnie wybiera się narzędzie do anotacji (od prostych arkuszy po dedykowane platformy), przydziela próbki do oznaczenia i wprowadza kontrolę jakości: podwójne oznaczenia, przykładowe audyty, liczenie spójności między anotatorami. Cały proces powinien być wersjonowany, tak aby można było później odtworzyć, kto i kiedy oznaczył dane.

Jak sprawdzić jakość danych treningowych do AI?

Praktyczne metody to m.in.: analiza rozkładów cech, wykrywanie duplikatów i skrajnych wartości, sprawdzanie braków danych, testy na małych próbach (czy etykiety faktycznie mają sens) oraz porównanie jakości kilku różnych modeli na tym samym zbiorze. Gdy różne algorytmy osiągają podobny, niski sufit, winne są zwykle dane.

Dodatkowo warto osobno przejrzeć rzadkie przypadki i klasy mniejszościowe, bo tam często kryją się błędy oznaczeń i niespójności. Prosty przegląd kilku dziesiątek losowych rekordów z każdej klasy potrafi ujawnić więcej niż rozbudowane wykresy.

Czy warto używać danych syntetycznych w projektach AI?

Dane syntetyczne dobrze uzupełniają rzadkie przypadki, pomagają zbalansować klasy lub zasymulować sytuacje, do których trudno dotrzeć w realnym świecie (np. rzadkie awarie maszyn). Nadają się też do wstępnego treningu, gdy prawdziwych danych jest niewiele.

Nie powinny jednak zastępować realnych próbek w systemach krytycznych, takich jak medycyna czy finanse. W takich projektach syntetyka jest dodatkiem, który zwiększa różnorodność danych, ale ostateczną jakość i zachowanie modelu trzeba zawsze weryfikować na rzeczywistych danych z produkcji.