Przygotowanie danych:
surowe dane zamieniamy w gotowe do modelowania podstawy
Przygotowanie danych to faza 3 procesu data science: surowe dane są czyszczone, zagęszczane do cech i ujmowane w odtwarzalne potoki. Wynikiem jest czysty, odtwarzalny zbiór danych jako podstawa do modelowania.
Sztuka przygotowania danych
Przygotowanie danych zajmuje największą część pracy projektowej. Automatyzujemy je przy użyciu solidnych procesów.
Przygotowanie danych to praca między eksportem surowych danych a pierwszym modelem. Składa się z trzech kroków, z których każdy dostaje na tej stronie własną sekcję. Pierwszy to czyszczenie danych, czyli postępowanie z brakującymi wartościami, duplikatami, wartościami odstającymi i niejednolitymi formatami. Drugi to inżynieria cech, czyli budowanie cech, z których model może się uczyć. Trzeci to budowa potoku danych, który czyni obie rzeczy powtarzalnymi. Po angielsku ta sama praca nazywa się data preparation albo data wrangling. Następuje po pozyskiwaniu danych w fazie 2 i dostarcza zbiór danych do analizy eksploracyjnej w fazie 4.
Jak duży jest udział w czasie projektu, zależy od stanu źródeł. Często podawane w branży 60 do 80 procent uważamy za wiarygodne, gdy tylko w grę wchodzi więcej niż jedno źródło; zmierzonego udziału obejmującego wszystkie nasze projekty nie mamy. Staje się on planowalny, gdy z góry wiadomo, jakie wady tkwią w danych.
Punktem wyjścia prawie nigdy nie jest gotowy zbiór danych, lecz to, co i tak powstaje w Państwa firmie: tabele ERP, eksporty ze sklepu internetowego, protokoły maszyn, książki zmian. Z tymi danymi pracujemy najchętniej w Państwa infrastrukturze, dzięki czemu dane nie muszą opuszczać firmy. Jest też przypadek, w którym przygotowanie zatrzymuje projekt: gdy zmienna docelowa, którą model ma przewidywać, w ogóle nie występuje w danych albo gdy istnieje tylko dla okresu, który nie obejmuje pytania. Wtedy mówimy to po inwentaryzacji, a nie dopiero po miesiącach.
Czyszczenie danych
Systematyczne postępowanie z brakującymi wartościami, duplikatami i niespójnościami.
Tworzenie cech
Wyprowadzanie znaczących cech na podstawie wiedzy dziedzinowej.
Automatyzacja
Odtwarzalne potoki z obsługą błędów i kontrolami jakości.
Czyszczenie danych: brakujące wartości, duplikaty, wartości odstające
Czyszczenie danych (po angielsku data cleaning) to rozpoznawanie i usuwanie wad w surowych danych: brakujących wartości, duplikatów, wartości odstających i niejednolitych formatów. Jest pierwszą i zwykle najdłuższą częścią przygotowania danych i odpowiada na cztery pytania: Czego brakuje? Co jest podwójne? Co jest nieprawdopodobne? Co jest poprawne, ale zapisane inaczej niż reszta? Która odpowiedź jest w danym przypadku właściwa, rozstrzyga nie sama statystyka, lecz cel późniejszego modelu. Dlatego przy każdym z czterech punktów podajemy regułę decyzyjną, a nie tylko lista metod.
Brakujące wartości: usunąć, imputować albo zakodować jako cechę
Brakująca wartość rzadko jest przypadkiem, a często sama jest ustaleniem: w zbiorze danych platformy dostawczej 38,78 procent zamówień było nieocenionych, najważniejsze stwierdzenie o jakości danych platformy. Zanim więc cokolwiek zastąpimy, warto zapytać, dlaczego wartości brakuje.
Otwarte są trzy drogi. Usunięcie: usunąć wiersze albo całe kolumny, dopuszczalne przy niewielu dotkniętych wierszach bez związku ze zmienną docelową. Imputacja, czyli zastąpienie: medianą, średnią, ostatnią znaną wartością albo modelem pomocniczym. W segmentacji klientów zastąpiliśmy brakujące dane o dochodzie medianą i usunęliśmy jedną skrajną wartość; z 2 240 rekordów klientów zostało 2 232. Zakodowanie jako cechy: sam brak staje się informacją, na przykład jako kolumna „dochód nieznany”. To właściwa droga, gdy brak jest systematyczny, bo wtedy mówi modelowi coś o kliencie.
Przypadkiem szczególnym są zastępniki jak „?”, „-1” albo „9999”, które uchodzą za prawidłowe wartości. W zbiorze UCI Adult kolumna „Workclass” wydaje się wypełniona w 100 procentach; dopiero gdy znak zapytania zostanie zadeklarowany jako brak, pokazuje się 5,6 procent luk.
Reguła decyzyjna (nasza reguła kciuka, nie norma): jeśli udział braków w kolumnie leży poniżej około pięciu procent i nie widać wzorca, usuwamy albo po prostu imputujemy. Powyżej, albo gdy tylko brak wiąże się ze zmienną docelową, kodujemy go jako cechę i dokumentujemy każdą imputację. Przy bardzo wysokim udziale braków kolumna przydaje się zwykle już tylko jako cecha tak/nie, a w danych Titanica kabiny brakuje u 77,1 procent pasażerów, wieku u 19,9 procent.
Duplikaty i klucze
Duplikaty rzadko powstają z literówek, a najczęściej z techniki: eksport uruchomił się dwa razy, dwa systemy prowadzą tego samego klienta, join zwielokrotnił wiersze. W zbiorze UCI Adult z 32 561 wierszami zmierzyliśmy 24 podwójne wiersze, czyli 0,074 procent: mało, ale nie zero, i bez sprawdzenia niewidoczne.
Sprawdzenie przebiega na dwóch poziomach: identyczne pełne wiersze to duplikaty techniczne i są usuwane. Wiersze zgodne tylko w zadeklarowanych kolumnach kluczowych, na przykład numer zamówienia plus data, to duplikaty merytoryczne, a pytanie brzmi, który jest właściwy. Drugi poziom zakłada, że klucz w ogóle jest znany. W danych procesowych podwójne numery zamówień należą do wad, które rozstrzygają, czy powstanie solidny model, czy ładna, fałszywa analiza.
Reguła decyzyjna: duplikaty techniczne są usuwane, a ich udział protokołowany. Duplikaty merytoryczne nigdy nie są usuwane po cichu, lecz rozstrzygane według reguły ustalonej z działem biznesowym: wygrywa najnowszy stan albo stan z systemu wiodącego. Reguła trafia jako kod do potoku.
Wartości odstające: błąd pomiaru czy rzadkie zdarzenie
Statystycznie wartość odstająca to wartość daleko poza resztą rozkładu; klasyczna reguła Tukeya wyznacza granicę przy 1,5-krotności rozstępu ćwiartkowego. W naszym audycie jakości danych na trzech publicznych zbiorach wiarygodność wartości była wymiarem najczęściej świecącym na czerwono, bo ciężkie ogony są w realnych danych regułą. Następny krok jest mimo to zawsze ludzki. Czy wartość to błąd czujnika, pomylona jednostka czy prawdziwe rzadkie zdarzenie? W zbiorze UCI Adult kolumna fnlwgt pokazuje ciężki ogon i jako waga próby jest merytorycznie w pełni uprawniona.
Reguła decyzyjna: wartość odstająca jest usuwana tylko wtedy, gdy można nazwać błąd: jednostka, czujnik albo literówka. Inaczej zostaje w zbiorze, dostaje oznaczenie jako osobna cecha, a modelowanie wybiera metody mniej wrażliwe na wartości skrajne, na przykład medianę zamiast średniej albo modele drzewiaste zamiast liniowych.
Formaty i jednostki: data, separator dziesiętny, strefy czasowe
Najmniej spektakularna część czyszczenia danych powoduje najpóźniejsze błędy. Data zapisana jako tekst na początku ledwo rzuca się w oczy i staje się dramatem, gdy tylko model szeregów czasowych zacznie po niej sortować; w naszym audycie 25 lat dziennych kursów Apple taka tekstowa data była pierwszym ustaleniem. Równie cicho działają separatory dziesiętne: „1.250” to zależnie od pochodzenia tysiąc dwieście pięćdziesiąt albo jeden i dwadzieścia pięć setnych. Wykres w jednym z naszych własnych artykułów przez pewien czas pokazywał angielskie kropki dziesiętne, podczas gdy tekst obok używał przecinka.
Jednostki i strefy czasowe należą do tego samego sprawdzenia: zmieniające się jednostki w danych maszynowych, znaczniki czasu w czasie lokalnym obok znaczników w czasie uniwersalnym, zmiany czasu letniego, przez które jedna godzina pojawia się podwójnie albo wcale. Każde z tych odchyleń jest samo w sobie nieszkodliwe; w sumie dają fałszywy model.
Reguła decyzyjna: każda kolumna dostaje zadeklarowany typ, jednostkę oraz, przy znacznikach czasu, strefę czasową. Wszystko to zapisujemy jako kod w potoku, a nie w głowie osoby opracowującej. Luki czasowe są liczone, ale nie wypełniane automatycznie: w kursach Apple znalazło się 168 luk, czyli 2,7 procent interwałów, i wszystkie były weekendami oraz dniami wolnymi giełdy.
| Problem | Wykrywanie | Działanie | Ryzyko przy złym wyborze |
|---|---|---|---|
| Brakujące wartości | Udział braków w każdej kolumnie; zastępniki jak „?”, -1, 9999 zadeklarować jako braki | Usunąć, imputować albo zakodować jako cechę, zależnie od udziału i wzorca | Systematyczny brak ginie jako informacja |
| Duplikaty | Identyczne wiersze; identyczne klucze (ID plus data) | Duplikaty techniczne usunąć, merytoryczne rozstrzygnąć według reguły z działem biznesowym | Agregaty są zawyżone; wygrywa zły stan |
| Wartości odstające | 1,5-krotność rozstępu ćwiartkowego, 5 sigma, merytoryczne granice wiarygodności | Usuwać tylko udowodnione błędy pomiaru, resztę oznaczyć, wybrać odporne metody | Rzadkie zdarzenie zostaje wyczyszczone |
| Formaty i jednostki | Sprawdzenie typu w każdej kolumnie; data jako tekst, separatory dziesiętne, strefy czasowe | Zadeklarować typ, jednostkę i strefę czasową; luki czasowe liczyć, nie wypełniać | Ciche błędy, które ujawniają się dopiero przy podziale szeregów czasowych |
Kto przed projektem chce wiedzieć, ile czyszczenia go czeka, dostaje wraz z Data Quality Check wynik z ryzykiem w skali świateł. Samego czyszczenia wyraźnie w nim nie ma, bo jest ono przedmiotem tej fazy.
Data Quality Check w stałej cenie: inwentaryzacja przed fazą 3Inżynieria cech: z wiedzy domenowej powstają cechy
Cecha (feature) to kolumna, z której uczy się model. Inżynieria cech to praca polegająca na budowaniu z surowych kolumn cech niosących znaczenie merytoryczne. Z naszego doświadczenia ta praca częściej rozstrzyga o jakości modelu niż wybór algorytmu i jest tą częścią przygotowania danych, która bez wiedzy fachowej Państwa firmy nie działa.
Czym jest cecha: dwa przykłady
W naszym obliczeniu modelowym dla konserwacji predykcyjnej sterownik maszyny dostarcza co dziesięć minut wibracje, temperaturę, pobór prądu i kody błędów. Żadna z tych surowych wartości nie jest sama w sobie dobrą cechą. Dobre cechy to krocząca 24-godzinna średnia wibracji, trend poboru prądu i liczba kodów błędów w ostatnich 72 godzinach: streszczają to, na co doświadczony utrzymaniowiec i tak miałby oko.
Predictive maintenance: konserwacja według stanu zamiast według kalendarzaW handlu odzieżą najsilniejszą cechą dla następnego zwrotu jest dotychczasowy wskaźnik zwrotów klienta, ale tylko wtedy, gdy jest liczony wyłącznie z zamówień o wcześniejszej dacie. Zbudowany poprawnie, w naszej analizie 2,33 mln pozycji zamówień podniósł jakość predykcji (ROC-AUC) z 0,696 do 0,737. Jak z komentarzy w wolnym tekście powstają policzalne powody zwrotów, pokazuje drugi przypadek użycia.
Analiza przyczyn zwrotów: z wolnego tekstu powstają przyczynyTypowe transformacje
- Agregacja w oknach czasowych: sumy, średnie i trendy z 24 godzin, 7 dni lub 12 miesięcy. Decydująca jest krawędź okna: okno kończy się w momencie predykcji, nigdy później.
- Kodowanie kategorii: tekst jak „sposób płatności” czy „ID maszyny” staje się liczbami, klasycznie jako kodowanie one-hot z kolumną tak/nie dla każdej kategorii. Kodowanie względem celu przy wielu wartościach tylko ostrożnie, bo łatwo przemyca informację ze zmiennej docelowej.
- Skalowanie i normalizacja: dla metod mierzących odległości kolumny sprowadza się do porównywalnych rzędów wielkości; we wspomnianej segmentacji klientów porównanie pięciu metod klastrowania poprzedziły standaryzacja i analiza składowych głównych. Metody drzewiaste tego kroku nie potrzebują.
- Selekcja (feature selection): cechy, które niczego nie wyjaśniają albo tylko powtarzają inne, są usuwane; to utrzymuje model wyjaśnialnym, a potok szczupłym.
Data leakage: największa pułapka
Data leakage, po polsku wyciek danych, oznacza: cecha zawiera informację, która w momencie predykcji nie może jeszcze być dostępna. Model wygląda w teście znakomicie i zawodzi w eksploatacji. Jak duży może być efekt, pokazuje nasza analiza około 50 000 sesji sklepu internetowego: z cechami koszyka z końca sesji model osiągnął AUC 0,961, a bez nich 0,860. Dobre dziesięć punktów AUC nie było przenikliwością, lecz przeformułowaniem wyniku. Co to ustalenie oznacza dla walidacji modeli, wyjaśnia faza 5, a sama analiza jest w artykule badawczym.
Wynikają z tego trzy reguły. Po pierwsze podział między treningiem a testem przebiega wzdłuż czasu albo jednostki (sesja, klient, maszyna), nigdy wierszami; inaczej ta sama sesja trafia na obie strony. Po drugie każdą cechę sprawdza się pod kątem tego, kiedy jest znana w eksploatacji: historia konserwacji do wczoraj jest dozwolona, raport z naprawy z jutra nie. Po trzecie zaskakująco wysoki wskaźnik jest powodem do podejrzeń, a nie sukcesem. Jeśli demo leży wyraźnie powyżej tego, co daje czysty podział czasowy, różnica jest z dużym prawdopodobieństwem premią za leakage.
Dlaczego niemal idealne modele konwersji zwykle tylko opowiadają koszykPotoki danych: odtwarzalne, przetestowane, wersjonowane
Potok danych to ścieżka przetwarzania, która przy każdym przebiegu zamienia surowe dane w cechy w tej samej kolejności i według tych samych reguł. Pojęcie ETL (extract, transform, load: odczytać, przekształcić, zapisać) opisuje tę samą ścieżkę z perspektywy przechowywania danych. Które narzędzie ją wykonuje, jest drugorzędne; decydujące są odtwarzalność, testy i wersjonowanie, trzy właściwości z motta grafiki poniżej.
Dlaczego skrypty w notatnikach nie wystarczą: notatnik to właściwe narzędzie, by opracować czyszczenie, i niewłaściwe, by je eksploatować; po trzech tygodniach nikt już nie wie, który eksport był podstawą.
Wersjonowane są trzy rzeczy. Po pierwsze kod transformacji. Po drugie zamrożony stan danych (snapshot) surowych danych, względem którego każdy wynik da się przeliczyć. Po trzecie logika transformacji jako dokumentacja, czyli która reguła obowiązuje z jakiego powodu. „Dokumentacja wszystkich transformacji” wśród rezultatów tej fazy nie jest więc dodatkiem, lecz produktem ubocznym potoku.
Testy schematu i zakresów wartości: każdy przebieg sprawdza z góry, czy wejście nadal odpowiada oczekiwanemu schematowi (kolumny, typy, jednostki) i czy zakresy wartości są wiarygodne: żadnych ujemnych ilości, żadnych znaczników czasu z przyszłości, udziały braków poniżej uzgodnionego progu. Takie testy kontraktowe względem znanego schematu to inna warstwa niż diagnoza w fazie 2; pełny zestaw testów kosztuje zależnie od modelu danych od jednego do czterech tygodni i za to wyłapuje każdy przyszły eksport, który po cichu zmieni format. Gdy test się uruchomi, przebieg zostaje przerwany, zamiast dostarczyć cicho fałszywy wynik.
Przejście do fazy 6: ten sam potok, który wytworzył dane treningowe, wytwarza później w eksploatacji dane wejściowe dla modelu. Kto w fazie 3 zbuduje dwie osobne drogi, jedną dla eksperymentu i jedną dla produkcji, dostaje w fazie 6 rozbieżności, których nikt nie umie wyjaśnić.
Ten sam potok w eksploatacji: faza 6Przygotowanie danych w średnich firmach: trzy typowe sytuacje wyjściowe
Trzy sytuacje wyjściowe spotykamy w średnich firmach raz po raz. Żadna z nich nie jest przeszkodą; każda wymaga innego pierwszego kroku.
Listy w Excelu w kilku działach
Sprzedaż prowadzi klientów w jednej tabeli, księgowość w drugiej, produkcja w trzeciej. Ta sama firma występuje w nich trzy razy, trzy razy inaczej zapisana. Przygotowanie zaczyna się tu od zbudowania klucza: która kolumna jednoznacznie identyfikuje klienta? Dopiero potem opłaca się czyszczenie, inaczej trzy prawdy staną się czyste, ale nie jedna.
Eksport ERP z polami wolnego tekstu
Eksport jest czysto ustrukturyzowany, ale decydująca informacja znajduje się w polu uwag: powód anulowania, warunek specjalny, specjalne życzenie klienta. Wolny tekst jest tłumaczony przez przetwarzanie języka na kategorie, które dają się policzyć. Kategorie ustala dział biznesowy, nie model; model tylko sortuje.
Dane maszynowe bez wspólnej osi czasu
Sterownik maszyny, system realizacji produkcji (MES) i ERP protokołują to samo zlecenie, ale z własnymi zegarami i własnym taktem. Przed każdym modelowaniem źródła trzeba powiązać przez znaczniki czasu oraz ID zleceń i maszyn. Luki w szeregach czasowych, zmieniające się jednostki i podwójne numery zleceń to przy tym typowe ustalenia.
Schematyczny przebieg z wartościami przykładowymi: po lewej surowy zbiór danych (38 procent pustych pól, 25 procent niejasnych wpisów, 18 procent duplikatów, 12 procent mieszanych formatów), po prawej zbiór cech (42 cechy, 98 procent jakości, 95 procent pokrycia, 100 procent zaliczonych testów). Wartości przykładowe, nie pomiar projektowy.
Nasze podejście
Czyszczenie & harmonizacja
Systematyczne rozwiązywanie problemów z jakością danych z różnych źródeł.
Inżynieria cech
Tworzenie cech, które najlepiej wspierają uczenie modelu.
Budowa potoku
Zautomatyzowane, wersjonowane przepływy przetwarzania danych.
Zapewnienie jakości
Zintegrowane mechanizmy kontroli dla trwale zapewnionej jakości danych.
Typowe rezultaty
Najczęstsze pytania o przygotowanie danych
Czym różni się przygotowanie danych od czyszczenia danych?
Czyszczenie danych jest częścią przygotowania danych. Usuwa wady w surowych danych: brakujące wartości, duplikaty, wartości odstające, niejednolite formaty. Przygotowanie danych obejmuje dodatkowo inżynierię cech, czyli budowanie merytorycznie sensownych cech, oraz budowę potoku, który czyni oba kroki powtarzalnymi i sprawdzalnymi.
Jak postępować z brakującymi wartościami?
Najpierw wyjaśnić, dlaczego wartości brakuje. Jeśli brakuje jej losowo i rzadko, wiersz jest usuwany albo wartość zastępowana medianą lub ostatnim znanym stanem. Jeśli brakuje jej systematycznie, brak jest kodowany jako osobna cecha. Zastępniki jak „?” albo 9999 trzeba wcześniej zadeklarować jako braki, inaczej kolumna błędnie uchodzi za kompletną.
Ile czasu zajmuje przygotowanie danych w projekcie data science?
Największą część pracy projektowej, gdy tylko w grę wchodzi więcej niż jedno źródło. Często podawane 60 do 80 procent pokrywa się z naszym doświadczeniem; pomiaru obejmującego wszystkie projekty nie mamy. Udział staje się planowalny, gdy inwentaryzacja, jak Data Quality Check, pokaże wcześniej, jakich wad się spodziewać.
Czym jest inżynieria cech i dlaczego jest ważniejsza niż algorytm?
Inżynieria cech buduje z surowych kolumn cechy o znaczeniu merytorycznym, na przykład kroczącą 24-godzinną średnią wibracji zamiast pojedynczej wartości. Algorytm znajduje tylko wzorce, które tkwią w cechach, a lepsza cecha z reguły podnosi każdy model, lepszy algorytm tylko ten jeden. Dlatego w tej pracy tkwi wiedza fachowa Państwa firmy.
Czym jest data leakage i jak go uniknąć?
Data leakage występuje, gdy cecha zawiera informację, która w momencie predykcji nie może jeszcze być dostępna, na przykład stan koszyka na końcu sesji dla prognozy konwersji. Uniknąć go można przez czasowy podział między treningiem a testem, sprawdzenie każdej cechy pod kątem momentu, w którym staje się znana, i nieufność wobec wskaźników, które wyglądają zbyt dobrze.
Czy nasze dane muszą być idealne, zanim zbuduje się model?
Nie. Modele radzą sobie z lukami i szumem, jeśli oba są znane i udokumentowane. Trzy rzeczy muszą się zgadzać: zmienna docelowa musi występować w danych, okres musi obejmować pytanie, a jednoznaczny klucz musi łączyć źródła. Jeśli brakuje jednej z nich, przygotowanie zatrzymuje projekt, lepiej wcześnie niż późno.
Czy przygotowanie danych można zautomatyzować?
Wykonanie tak, decyzje nie. Sprawdzenia typów, wyszukiwanie duplikatów, statystyka braków i testy schematu działają w potoku automatycznie przy każdym nowym stanie danych. Czy wartość odstająca jest błędem pomiaru, czy prawdziwym zdarzeniem, i jaka reguła obowiązuje przy duplikatach merytorycznych, decyduje człowiek z wiedzą fachową, i to tylko raz.
Porozmawiajmy o Państwa projekcie
Każdy projekt jest wyjątkowy. Prosimy opowiedzieć o Państwa wyzwaniu.
Zarezerwuj bezpłatną rozmowę wstępną