Model AI jest dokładnie tak dobry jak dane, na których go trenowano. Garbage in, garbage out – ta stara zasada informatyki nigdy nie była bardziej aktualna niż w erze uczenia maszynowego.
Dlaczego jakość danych to fundament każdego projektu AI
Kiedy model AI zachowuje się nieprzewidywalnie, popełnia systematyczne błędy lub działa świetnie w testach, a fatalnie w produkcji – pierwszym miejscem, w którym należy szukać przyczyny, są dane treningowe. Nie architektura modelu, nie hiperparametry, nie wybór frameworka. Dane.
To jedna z najważniejszych lekcji, której uczą się zespoły pracujące nad projektami AI w świecie rzeczywistym. W środowisku akademickim pracuje się zazwyczaj na starannie przygotowanych, publicznie dostępnych zbiorach danych – MNIST, ImageNet, Common Crawl – które ktoś już wyczyścił i zwalidował. W projektach komercyjnych dane pochodzą z systemów produkcyjnych, baz klientów, logów aplikacji, ręcznych eksportów z Excela. I są pełne problemów, których żaden model nie jest w stanie sam naprawić.
Ocena jakości danych treningowych to nie jednorazowy krok przed rozpoczęciem treningu. To ciągły proces, który powinien towarzyszyć projektowi od pierwszego dnia do ostatniego.
Cztery wymiary jakości danych
Jakość danych to pojęcie wielowymiarowe i warto rozumieć je precyzyjnie, bo różne problemy wymagają różnych rozwiązań. Cztery kluczowe wymiary to kompletność, poprawność, spójność i reprezentatywność.
Kompletność mówi o tym, czy dane zawierają wszystkie potrzebne informacje. Brakujące wartości w kluczowych kolumnach, puste pola tekstowe, rekordy bez etykiet – to wszystko przykłady niekompletności. Każdy brakujący element to informacja, której model nie dostanie podczas treningu.
Poprawność dotyczy tego, czy dane odzwierciedlają rzeczywistość. Błędnie przypisane etykiety, literówki w danych tekstowych, pomyłki przy ręcznym wprowadzaniu danych – dane mogą być kompletne, ale niepoprawne. Model wytrenowany na błędnych etykietach nauczy się błędnych wzorców, a wykrycie tego problemu jest często trudniejsze niż wykrycie braków.
Spójność to zgodność danych z przyjętymi konwencjami i ze sobą nawzajem. Ta sama wartość zapisana na różne sposoby w różnych rekordach – „Warszawa”, „warszawa”, „WAW”, „Warsaw” – to problem spójności. Daty w różnych formatach, jednostki miary mieszane bez oznaczenia, kategorie o nakładających się znaczeniach.
Reprezentatywność to najbardziej podstępny wymiar. Dane mogą być kompletne, poprawne i spójne, a mimo to prowadzić do wadliwego modelu, jeśli nie odzwierciedlają rzeczywistego rozkładu zjawiska, które model ma przewidywać. Jeśli trenujesz model wykrywający oszustwa finansowe na danych z jednego kwartału, który był wyjątkowo spokojny, model może sobie nie poradzić z sezonem zwiększonej aktywności fraudowej.
Eksploracyjna analiza danych – gdzie wszystko się zaczyna
Zanim zaczniesz oceniać jakość danych, musisz je poznać. Eksploracyjna analiza danych (EDA) to proces systematycznego badania zbioru danych w celu zrozumienia jego struktury, rozkładów wartości i potencjalnych problemów.
Podstawowe statystyki opisowe – średnia, mediana, odchylenie standardowe, minimum i maksimum dla zmiennych numerycznych – często od razu zdradzają anomalie. Wartość minimalna wynosząca -999 w kolumnie reprezentującej wiek użytkownika to klasyczny przykład wartości sentinel używanej do oznaczania brakujących danych, która jeśli nie zostanie potraktowana odpowiednio, poważnie zaburzy trening.
Rozkłady wartości w kolumnach kategorycznych pokazują nierównowagę klas. Jeśli 95 procent przykładów należy do jednej klasy, a 5 procent do drugiej, masz do czynienia z niezbalansowanym zbiorem danych. Model wytrenowany bez uwzględnienia tej nierównowagi nauczy się po prostu zawsze przewidywać klasę większościową i osiągnie 95 procent dokładności – co brzmi świetnie, ale jest bezużyteczne, bo nigdy nie wykryje przypadków należących do mniejszości.
Wizualizacja danych to narzędzie, którego nie wolno lekceważyć. Histogram rozkładu, wykres pudełkowy pokazujący outliers, macierz korelacji między zmiennymi – te proste wizualizacje potrafią ujawnić wzorce i problemy, które całkowicie umykają przy patrzeniu na liczby.
Etykiety – gdzie kryją się najgroźniejsze błędy
W problemach uczenia nadzorowanego jakość etykiet jest często ważniejsza niż jakość cech. Możesz mieć tysiące dobrze zebranych próbek, ale jeśli etykiety są błędne lub niespójne, model nauczy się błędnych wzorców – i będzie to robił tym skuteczniej, im więcej danych mu podasz.
Błędy w etykietach rzadko są losowe. Częściej mają systematyczny charakter – określony annotator ma tendencję do przypisywania wątpliwych przypadków do jednej klasy, określona kategoria jest często mylona z inną ze względu na niejednoznaczną definicję, dane z określonego źródła były etykietowane według innych kryteriów niż reszta zbioru.
Ocena jakości etykiet wymaga kilku podejść jednocześnie. Inter-annotator agreement, czyli zgodność między różnymi osobami etykietującymi te same przykłady, to podstawowy wskaźnik – mierzy się go współczynnikiem kappa Cohena lub prostym procentem zgodności. Niski wynik oznacza, że definicje klas są niejednoznaczne i annotatorzy rozumieją je inaczej. Zanim poprawisz etykiety, musisz poprawić wytyczne.
Wartościową techniką jest też clean-room review – losowe losowanie próbki etykietowanych danych i ponowne etykietowanie jej od zera przez inną osobę lub przez eksperta domenowego, bez patrzenia na oryginalne etykiety. Porównanie wyników ujawnia systematyczne błędy w oryginalnym procesie etykietowania.
Wykrywanie i obsługa wartości odstających
Wartości odstające, czyli outliers, to obserwacje znacząco różniące się od reszty zbioru danych. Mogą być błędami pomiarowymi, błędami przy wprowadzaniu danych, wyjątkowymi ale prawdziwymi przypadkami, albo oznakami bardziej fundamentalnego problemu z procesem zbierania danych.
Kluczowe pytanie przy każdej wartości odstającej brzmi: czy to błąd, czy prawdziwa obserwacja? Odpowiedź ma fundamentalne znaczenie dla sposobu postępowania. Błędne wartości odstające należy usunąć lub poprawić. Prawdziwe wartości odstające należy albo zachować, albo świadomie wykluczyć z uzasadnieniem biznesowym – na przykład jeśli trenujesz model dla typowych klientów i celowo nie chcesz, żeby ekstremalnie duże transakcje wpływały na jego zachowanie.
Metody statystyczne wykrywania wartości odstających – z-score, IQR (rozstęp ćwiartkowy), isolation forest dla danych wielowymiarowych – pomagają zidentyfikować kandydatów do przeglądu, ale ostateczna decyzja zawsze powinna należeć do człowieka z wiedzą domenową, a nie do algorytmu.
Dryfowanie danych – problem, który rośnie po wdrożeniu
Ocena jakości danych treningowych nie kończy się w momencie uruchomienia modelu na produkcji. Jeden z najczęstszych problemów w produkcyjnych systemach AI to data drift – stopniowe zmiany w charakterystyce danych napływających do modelu w stosunku do danych, na których był trenowany.
Świat się zmienia. Zachowania użytkowników ewoluują. Wprowadzane są nowe produkty, zmieniają się regulacje, pojawiają się nowe wzorce. Model wytrenowany dwa lata temu na danych historycznych może dziś dawać coraz gorsze wyniki nie dlatego, że jest zepsuty, ale dlatego że świat wyglądał wtedy inaczej.
Monitorowanie dryftu polega na regularnym porównywaniu rozkładów cech w danych produkcyjnych z rozkładami w danych treningowych. Narzędzia jak Evidently AI, WhyLabs czy wbudowane funkcje platform MLOps automatyzują ten proces i generują alerty gdy drift przekroczy zdefiniowane progi. To sygnał do retreningu modelu na świeższych danych lub do głębszej analizy, czy zmiana ma charakter tymczasowy czy trwały.
Dokumentacja danych – niedoceniany element każdego projektu
Dane treningowe bez dokumentacji to tykająca bomba. Pół roku po zakończeniu projektu nikt nie pamięta skąd pochodziły dane, jakie transformacje zostały na nich wykonane, dlaczego pewne rekordy zostały usunięte i jakie były kryteria etykietowania. Każda zmiana w zespole oznacza utratę tej wiedzy.
Koncepcja data card – dokumentu opisującego zbiór danych w ustrukturyzowany sposób – zyskuje coraz szersze uznanie w środowisku AI. Dobra dokumentacja zbioru danych powinna zawierać źródło pochodzenia danych i sposób ich zebrania, zakres czasowy i geograficzny, zastosowane kryteria filtrowania i czyszczenia, opis procesu etykietowania wraz z wytycznymi dla annotatorów, znane ograniczenia i potencjalne źródła biasu oraz wszelkie zmiany wprowadzone w kolejnych wersjach zbioru.
Ta dokumentacja nie jest biurokratycznym narzutem – to inwestycja, która zwraca się przy każdym debugowaniu problemu z modelem, każdym audycie i każdym onboardingu nowego członka zespołu. Dobry model zbudowany na dobrze udokumentowanych danych jest znacznie łatwiejszy w utrzymaniu niż najlepszy model zbudowany na danych, o których nikt nic nie wie.
