Siedem pytań decyduje, czy Twój projekt AI się nie powiedzie

W naszych rozmowach wdrożeniowych mid-cap pewien wniosek pojawia się z męczącą regularnością: pilotaże AI nie zawodzą na modelu. Zawodzą na jakości danych, której nikt wcześniej nie zaudytował. Dyskusja ląduje wtedy na dostawcy, na feature engineeringu albo na strojeniu hiperparametrów, rzadko tam, gdzie błąd faktycznie leży.

Chcieliśmy mieć narzędzie, które sprawdza zbiór danych w dziesięć minut względem siedmiu wymiarów, które naszym zdaniem decydują o sukcesie lub porażce przedsięwzięcia AI. Zbudowaliśmy je i publikujemy dzisiaj. Ten artykuł opisuje siedem wymiarów, podstawę metodyczną i wyniki z pierwszego testu na syntetycznym zbiorze danych ze znanymi defektami.

1 · Siedem wymiarów

Każdy wymiar mierzy inny aspekt jakości danych i produkuje ocenę sygnalizacji świetlnej (zielony, żółty, czerwony) plus wartość liczbową.

Trzy z nich (5, 6, 7) są opcjonalne i oceniane tylko wtedy, gdy wywołanie audytu poda potrzebne informacje (kolumnę czasu, specyfikację klucza obcego, definicję podziału).

2 · Narzędzie

Instalacja i uruchomienie w dwie minuty:

git clone https://github.com/myBytesResearch/data-quality-audit.git
cd data-quality-audit
pip install -e .

# Najpierw zrób kopię! Nigdy bezpośrednio na danych produkcyjnych.
cp /sciezka/do/produkcji.csv /tmp/audit_kopia.csv

dqa audit /tmp/audit_kopia.csv \
    --report moj_report.md \
    --json scorecard.json

Narzędzie wypisuje raport Markdown ze wszystkimi siedmioma wymiarami plus scorecard JSON do dalszej automatyzacji. CLI drukuje przed każdą operacją odczytu danych ostrzeżenie bezpieczeństwa i wymaga wyraźnego potwierdzenia, jeśli ścieżka nie jest widocznie oznaczona jako próbka lub kopia (--sample lub --copy).

Gwarancje techniczne narzędzia:

• Plik wejściowy otwierany jest wyłącznie w trybie odczytu.
• Brak wywołań sieciowych w czasie działania. Brak telemetrii. Brak ścieżek zewnętrznych.
• Brak automatycznej naprawy danych. Narzędzie diagnozuje, nie naprawia. Naprawa to świadoma decyzja w workflow inżynierii danych.

Pełny kod, siedem modułów wymiarów, testy i syntetyczny zbiór danych ze znanymi defektami znajdują się w repozytorium towarzyszącym data-quality-audit.

3 · Test na syntetycznym zbiorze danych

Zbudowaliśmy syntetyczny zbiór danych z pięcioma celowo wprowadzonymi defektami i puściliśmy na niego narzędzie. Defekty:

1. kolumna email z 40 % udziałem braków
2. kolumna phone z 20 % udziałem braków
3. mixed_col z mieszanymi typami Pythona (stringi i integery)
4. 50 zduplikowanych wierszy
5. trzy ekstremalne wartości odstające w amount (1·10⁹ i −1·10⁶)

Narzędzie w pełni wykryło i poprawnie oceniło pierwsze cztery. Przy piątym defekcie (mieszane typy) ujawniło się ciekawe ograniczenie: przy wczytywaniu z CSV wszystkie wartości są najpierw interpretowane jako stringi, więc mieszane typy giną na granularności wierszy. Narzędzie wykrywa ten przypadek czysto przy wejściach Parquet; przy CSV staje się on widoczny dopiero w dalszym kroku ładowania. To ograniczenie jest wyraźnie opisane w repozytorium towarzyszącym i w sekcji ograniczeń poniżej.

Fragment wygenerowanego raportu:

**Overall verdict:** 🟡 YELLOW
**Reason:** Yellow on: completeness, schema_consistency,
uniqueness, value_plausibility

## Dimension 1 · Completeness
🟡 YELLOW - Overall missing share: 6.6 %. Worst column: `email`
at 40.4 % missing.

## Dimension 4 · Value plausibility
🟡 YELLOW - `amount`: 407 odstających Tukeya, 1 |z| > 5σ
(zakres −1 mln … 1 mld).

Ocena sygnalizacji świetlnej per wymiar plus ważony werdykt ogólny to jeden output, który head of data może pokazać na stand-upie bez dołączania wyjaśnienia.

4 · Trzy realne audyty, trzy pouczające wnioski

Puściliśmy narzędzie na trzy publiczne zbiory danych, każdy w niezmienionej wersji oryginalnej, bez wstępnego czyszczenia. Wyniki znajdują się w audit-reports/ repozytorium towarzyszącego do samodzielnej weryfikacji.

4.1 UCI Adult Income (32 561 wierszy) - 🔴 czerwony

Klasyczny benchmark klasyfikacji, często używany w zajęciach.

Wniosek o fnlwgt jest metodycznie ciekawy: to waga próbkowania z projektu spisu, nie prawdziwa cecha obserwacyjna. Statystycznie wykazuje charakter heavy-tail; merytorycznie jest uzasadniona. Ten przypadek to podręcznikowy przykład, dlaczego diagnoza narzędzia musi być zawsze interpretowana wiedzą dziedzinową.

4.2 Titanic (891 wierszy) - 🔴 czerwony

Notoryczny wprowadzający zbiór danych do tutoriali ML.

Wniosek o Cabin (77,1 % braków) jest od lat obecny w każdym notatniku Kaggle o Titanicu. Narzędzie znajduje go w dziesięć sekund, bez tego, by ktokolwiek musiał wcześniej wiedzieć, że istnieje. To właśnie jest wartość operacyjna: nie pamiętanie, lecz systematyczne znajdowanie.

4.3 Dzienne ceny Apple, 25 lat (6 288 wierszy) - 🔴 czerwony

Yahoo Finance, AAPL 2000-01-01 do 2024-12-31.

Wniosek o Date jako string to najczęstsza przyczyna cicho zawodzących podziałów szeregów czasowych, jakie widzimy w codziennej pracy wdrożeniowej mid-cap.

168 luk czasowych to metodycznie nie defekty danych, to weekendy i święta giełdy w USA. Narzędzie wykrywa je poprawnie; interpretacja merytoryczna („to normalne dla dziennych kursów akcji”) należy do eksperta dziedzinowego. Wniosek jest mimo to operacyjnie wartościowy: architekt modelu szeregów czasowych pracujący z tym zbiorem musi wbudować mechanikę dni roboczych wprost, inaczej wróci ona jako bug.

4b · Trzy przekrojowe lekcje z audytów

Trzy zbiory danych są bardzo różne, a jednak ujawnia się wspólny wzorzec:

1. Wiarygodność wartości to najczęściej świecący na czerwono wymiar. Heavy tails są w realnych danych tak rozpowszechnione, że narzędzie prawie zawsze alarmuje tutaj. Kolejny konieczny krok jest zawsze ludzki: czy wartość odstająca to błąd sensora, pomyłka jednostek, czy prawdziwe rzadkie zdarzenie?
2. Dryf schematu na kolumnach dat jest na początku niepozorny we wszystkich trzech zbiorach i staje się dramatem w podziale szeregów czasowych. AAPL to przykład podręcznikowy.
3. Kompletność może być fałszywie zielona, jeśli loader CSV nie rozpozna wartości sentinel. Przykład UCI Adult jest pouczający: bez na_values='?' Workclass byłaby wypełniona w 100 %; w rzeczywistości brakuje 5,6 % wartości. Metodycznie uczciwa ocena jakości danych wymaga świadomej konfiguracji wartości sentinel przed oceną.

5 · Jak użyć go jako wyzwalacza rozmowy (discovery trigger)

Narzędzie jest celowo także punktem wejścia do rozmowy z nami. Konkretnie:

1. Zrób kopię zbioru danych, z którym pracujesz lub który przygotowujesz do projektu AI.
2. Uruchom na nim dqa audit.
3. Jeśli scorecard pokazuje trzy lub więcej wymiarów żółtych lub czerwonych, albo jeśli wyniki Cię zaskakują, odezwij się do nas. Czytamy Twój scorecard (chętnie zanonimizowany) w ciągu najbliższych 48 godzin i odpowiadamy oceną, która pomaga uporządkować Twoją strategię danych.

Trzy sposoby kontaktu z nami:

• Ustrukturyzowanie przez nasz kwestionariusz pre-meeting. Opisujesz swoją sytuację wyjściową w dziesięć minut, my przygotowujemy się celowo na rozmowę. To najskuteczniejsza droga, jeśli masz w przygotowaniu konkretne przedsięwzięcie AI lub jakości danych.
• Mailem na contact@mybytes.com. Prześlij nam scorecard i kilka zdań kontekstu, odpowiadamy w mniej niż 48 godzin.
• Bezpośrednio pod +49 40 60940415. Jeśli wolisz krótko porozmawiać, zanim wyślesz materiał.

Bez chwytu sprzedażowego, bez wieloczęściowej sekwencji. Jedna rozmowa, w której słyszymy, czy narzędzie dotyka Cię w punkcie, w którym możemy pomóc Ci dalej naszym zasobem doświadczenia wdrożeniowego.

6 · Steel-man: „jakość danych robimy już przez great_expectations”

Prawdopodobna kontrpozycja: „Mamy już stack jakości danych z great_expectations, pydantic albo dbt tests. Czy w ogóle tego potrzebujemy?” Trzy odpowiedzi:

• Inne warstwy. great_expectations i podobne frameworki są świetne do testów oczekiwanych względem znanego schematu. Wymagają sformułowania oczekiwania z góry. Nasze narzędzie startuje bez oczekiwania i pokazuje, co faktycznie kryje się w Twoim zbiorze. To pierwszy krok przed testami.
• Dziesięć minut zamiast dwóch tygodni. Pełne postawienie suite great_expectations kosztuje, zależnie od modelu danych, od jednego do czterech tygodni. Ocena dqa na świeżym zbiorze kosztuje dziesięć minut. Oba mają swoje miejsce; nie wykluczają się.
• Tradycja metod. Wymiary nie są wymyślone, lecz zaczerpnięte z utrwalonej literatury inżynierii danych (Tukey 1977, Kołmogorow 1933, Smirnow 1939) i z konwencji pandas. Narzędzie zbiera je w odtwarzalnej formie CLI.

7 · Czego to narzędzie nie robi

Sześć zastrzeżeń metodycznych, które należą do rzetelnego obrazu:

• Nie zastępuje kontraktu schematu. Jeśli potrzebujesz narzędzia inżynierii danych do testów kontraktowych względem znanego schematu, lepszym wyborem jest great_expectations lub pandera. dqa to diagnostyczny pierwszy etap przed tym.
• Nie naprawia. Narzędzie diagnozuje. Naprawa to świadoma decyzja, która musi nastąpić w Twoim workflow inżynierii danych.
• Ograniczenie CSV na spójności schematu. Na ścieżce odczytu CSV mieszane typy są maskowane przez czytnik CSV pandas. Jeśli potrzebujesz tego wymiaru ostro, wyeksportuj do Parquet na fazę audytu.
• Wymiary opcjonalne potrzebują wskazówek. Luki czasowe, integralność referencyjna i reprezentatywność są miarodajne tylko wtedy, gdy wywołanie poda kolumnę czasu, specyfikację klucza obcego lub podział.
• Brak wiedzy dziedzinowej. „Odstający” znaczy statystycznie wyjątkowy. Czy wartość jest faktycznie niewiarygodna w Twojej dziedzinie, wie tylko Twój ekspert dziedzinowy.
• Ograniczenie bezpieczeństwa. Narzędzie jest bezpieczne tylko wtedy, gdy trzymasz się disclaimera. Najpierw kopia. Audyt na kopii. Nigdy na produkcji.

Pełna lista ograniczeń z dalszymi punktami znajduje się w DISCLAIMER.md i w README repozytorium towarzyszącego.

8 · Lista lektur

1. Tukey 1977, Exploratory Data Analysis, klasyk, źródło testu odstających 1,5·IQR.
2. Kołmogorow 1933 / Smirnow 1939, test KS dla dwóch prób, podstawa detekcji dryfu w wymiarze 7.
3. dokumentacja pandas, Missing data, konwencje, którym narzędzie podąża.
4. dokumentacja Great Expectations, warstwa testów kontraktowych powyżej warstwy diagnozy.

Powiązane prace

• Protokół Truth-Check dla wyników badań nad AI, szablon przeglądu metodycznego, który stosujemy do każdego publikowanego twierdzenia.
• Granica pojedynczego GARCH na soft commodities, dyscyplina metodyczna w działaniu na stacku prognozowania.

Repozytorium towarzyszące

myBytesResearch/data-quality-audit, pełny kod, siedem modułów wymiarów, CLI, testy, syntetyczny przykładowy zbiór danych ze znanymi defektami. Prywatne w chwili publikacji; przełączenie na publiczne to osobna decyzja. Ważne: najpierw przeczytaj DISCLAIMER.md. Stosowanie na własne ryzyko, wyłącznie na kopiach zapasowych lub próbkach.