Zapytaj salę inżynierów, jak poprawić system uczenia maszynowego, a większość sięgnie po model: lepszą architekturę, większą sieć, nowszą technikę. Zapytaj, skąd naprawdę biorą się zyski, a uczciwa odpowiedź jest niemal zawsze ta sama — dane. Wybór modelu jest widoczny i ekscytujący; jakość danych jest niewidoczna i żmudna. Wartość rozkłada się w dokładnie odwrotnej proporcji.
Niewygodna proporcja
W większości realnych projektów przytłaczająca większość wysiłku — i przytłaczająca większość ostatecznej wydajności — tkwi w danych, nie w modelu. Czyszczenie ich, rozumienie, poprawianie błędów etykietowania, uczciwe obsługiwanie brakujących wartości i upewnianie się, że dane treningowe faktycznie przypominają te, które model zobaczy w produkcji: ta niewdzięczna praca decyduje o wygranej lub przegranej projektu. Skromny model na doskonałych danych pobije wyrafinowany model na słabych danych niemal za każdym razem.
To nie jest kontrowersyjne twierdzenie wśród ludzi, którzy wdrożyli liczące się systemy. To bliskie konsensusu. A jednak sposób, w jaki zespoły przydzielają czas, rzadko to odzwierciedla, bo i zachęty, i zainteresowanie ciągną ku modelowi. Nazwanie tej luki to pierwszy krok do jej zamknięcia.
Dlaczego zespoły robią to na odwrót
Są zrozumiałe powody, dla których uwagę dostaje model. Praca nad modelem jest intelektualnie satysfakcjonująca i dobrze udokumentowana; zawsze jest nowa technika do wypróbowania. Praca z danymi jest powtarzalna i specyficzna dla Twojej organizacji, więc nikt nie napisał do niej samouczka. A lepszy model wydaje się postępem w sposób, w jaki poprawienie niespójności etykiet nie — nawet gdy poprawka etykiet przesuwa metrykę znacznie bardziej.
Efektem są zespoły spędzające tygodnie na dostrajaniu architektury, podczas gdy systematyczny błąd w ich etykietach po cichu ogranicza osiągalną dokładność daleko poniżej tego, gdzie dostrajanie mogłoby kiedykolwiek sięgnąć.
Co naprawdę znaczy jakość danych
To nie jedna rzecz. Oznacza etykiety poprawne i spójne. Oznacza dane treningowe pasujące do rzeczywistości produkcyjnej, a nie do czystszego, łatwiejszego rozkładu. Oznacza świadome rozumienie i obsługę brakujących wartości, zamiast pozwalania, by domyślna wartość je zamaskowała. Oznacza sprawdzanie wycieku — informacji w danych treningowych, która nie będzie dostępna w chwili predykcji i po cichu zawyża Twoje wyniki testowe. Każde z tych jest nudne. Każde z tych ma większe znaczenie niż model.
Wyciek: cichy sędzia wyniku
Wyciek danych zasługuje na szczególną wzmiankę, bo jest zarazem częsty i niewidoczny. Gdy informacja, która naprawdę nie byłaby dostępna w chwili predykcji, wkrada się do danych treningowych, model wygląda genialnie w testach i zawodzi w produkcji. Wyniki nigdy nie były prawdziwe. Wychwytywanie wycieku wymaga dyscypliny co do sposobu dzielenia danych i podejrzliwego oka wobec każdej cechy, która wydaje się zbyt przewidywalna. To jeden z najcenniejszych nawyków, jakie zespół danych może zbudować.
Praktyczna konsekwencja
Gdy dokładność rozczarowuje, instynkt każe zmienić model. Bardziej produktywnym pierwszym ruchem jest niemal zawsze przebadanie danych: spójrz na błędy, sprawdź etykiety, zweryfikuj, czy trening przypomina produkcję, i poluj na wyciek. Dziewięć razy na dziesięć problem — i rozwiązanie — jest tam. To nie powód, by ignorować modelowanie; to powód, by wydać wysiłek tam, gdzie są zyski, a zyski są w danych.
Patrz na dane, nie tylko na metryki
Zagregowane wyniki ukrywają tyle, ile ujawniają. Model o dziewięćdziesięcioprocentowej dokładności może katastrofalnie zawodzić na jednej kategorii, która ma największe znaczenie, a nagłówkowa liczba nigdy by Ci tego nie powiedziała. Nawyk, który konsekwentnie odróżnia silne zespoły od słabych, jest niewdzięczny: patrzą na rzeczywiste przykłady. Czytają przypadki, które model pomylił, jeden po drugim, a wzorce wyskakują, których żadna statystyka podsumowująca by nie ujawniła — klasa danych systematycznie źle etykietowana, podgrupa, której model nigdy się nie nauczył, dziwactwo formatowania, które go myli.
To wolne i nie wydaje się postępem, co jest dokładnie powodem, dla którego tak niewiele zespołów to robi. To także miejsce, z którego konsekwentnie płyną najcenniejsze wnioski. Popołudnie czytania błędów zwykle nauczy Cię więcej niż tydzień dostrajania.
Jakość danych kumuluje się
Istnieje efekt kumulacji, który czyni wczesną inwestycję w jakość danych szczególnie opłacalną. Czyste, dobrze zrozumiane, dobrze zarządzane dane pomagają nie tylko modelowi, który budujesz dziś — przyspieszają każdy kolejny model, dashboard i analizę. I odwrotnie: bałaganiarski fundament obciąża wszystko, co na nim zbudowane, na zawsze. Zespoły traktujące jakość danych jako jednorazowy koszt przeoczają, że naprawdę robią inwestycję, która zwraca się w każdym przyszłym projekcie. To najbliższe darmowemu obiadowi, co oferuje praca z danymi.
Budowanie nawyku
Zespoły, które to internalizują, wbudowują kontrole danych w swój przepływ pracy tak, jak zespoły programistów wbudowują testy: automatyczna walidacja napływających danych, alerty przy przesunięciu rozkładów i kultura patrzenia na przykłady, a nie tylko na zagregowane metryki. To mniej ekscytujące niż najnowsza architektura i jest to najbardziej niezawodny sposób budowania systemów, które naprawdę działają.