Jakość danych przed pierwszym projektem AI: 7 pytań przed budżetem

Większość projektów AI nie przegrywa na modelu, tylko na danych. Siedem pytań, które da się zadać i sprawdzić w tydzień, zanim ruszy budżet.

Na kickoffie projektu AI rozmowa zwykle dotyczy modelu: który wybrać, ile będzie kosztował, kiedy będzie demo. Pytanie o dane pada na końcu, często w formie "no, mamy to w systemach". Po trzech miesiącach okazuje się, że "mamy" oznacza pięć eksportów do Excela, dwie różne definicje klienta i tabelę, której nikt nie odświeżał od zeszłej jesieni.

Ten tekst to lista pytań, które warto zadać przed podpisaniem umowy z kimkolwiek, także z nami. Każde da się sprawdzić w ciągu tygodnia, bez dużego zespołu i bez nowych narzędzi.

Dlaczego to ma znaczenie

Liczby bywają przesadzone, więc trzymajmy się tych z wiarygodnych źródeł. Gartner przewiduje, że do końca 2026 roku organizacje porzucą 60% projektów AI, które nie mają wsparcia w danych gotowych pod AI. W tej samej publikacji pisze, że 63% organizacji nie ma właściwych praktyk zarządzania danymi pod AI albo nie jest tego pewnych (ankieta wśród 1203 liderów danych z lipca 2024).

RAND, w raporcie z sierpnia 2024 opartym na rozmowach z 65 doświadczonymi inżynierami i analitykami danych, wymienia pięć głównych przyczyn porażek projektów AI. Nieodpowiednie dane to jedna z nich, obok źle zrozumianego problemu, pogoni za technologią zamiast za problemem, słabej infrastruktury i zadań zbyt trudnych dla AI. Raport przywołuje też często cytowane szacunki, że ponad 80% projektów AI kończy się niepowodzeniem, ale zaznacza, że to "szacunki", nie wynik jego własnych pomiarów.

Model da się kupić, dane trzeba mieć. Dlatego pytania poniżej dotyczą danych, nie algorytmów.

Siedem pytań diagnostycznych

1. Czy wiemy, które dane są potrzebne do tego jednego przypadku użycia?

Nie "jakie dane mamy", tylko "jakich dane wymaga ta konkretna decyzja". Prognoza popytu potrzebuje sprzedaży, cen, promocji, stanów magazynowych i kalendarza. Nie potrzebuje całej hurtowni.

Jak sprawdzić w tydzień: weź jeden przypadek użycia i narysuj na kartce, jakie pola muszą wejść do modelu, z jakiego systemu pochodzą i kto je wprowadza. Zrób to z osobą, która na co dzień podejmuje tę decyzję, nie z samym działem IT.

Zła odpowiedź: lista zaczyna się od słów "wszystko, co mamy". To zwykle znaczy, że problem biznesowy nie jest jeszcze zdefiniowany, a to według RAND najczęstsze źródło kłopotów.

2. Kto jest właścicielem tych danych?

Nie systemu, tylko danych. Osoba z imienia i nazwiska, która odpowie na pytanie "czy to pole jest poprawne" i może zdecydować o zmianie jego definicji. Data owner nie musi być techniczny. W handlu to często szef sprzedaży, w logistyce kierownik operacji.

Jak sprawdzić: dla każdego z kluczowych pól z pytania pierwszego wpisz właściciela. Zadzwoń do trzech z nich i zapytaj, kiedy ostatnio ktoś pytał ich o jakość tego pola.

Zła odpowiedź: "to jest w ERP, więc IT". IT zarządza bazą, ale nie wie, czy status zamówienia "zrealizowane" oznacza wysyłkę, płatność czy podpis klienta.

3. Czy te same pojęcia znaczą to samo we wszystkich systemach?

To problem spójności i najczęstszy w firmach, które urosły przez przejęcia lub kilka generacji systemów. "Aktywny klient" w CRM to ktoś, kto rozmawiał z handlowcem w ostatnim kwartale. W fakturowaniu to ktoś, kto kupił w ostatnich 12 miesiącach. Model nauczy się któregoś z tych znaczeń, a raport zarządu pokaże drugie.

Jak sprawdzić: wybierz pięć pojęć, które pojawiają się w raportach zarządczych (klient, zamówienie, przychód, aktywny użytkownik, marża). Poproś o definicję z każdego systemu i z działu finansów. Porównaj na jednym slajdzie.

Zła odpowiedź: trzy różne definicje i nikt nie wie, która jest obowiązująca. Zanim ruszy model, ktoś musi podjąć decyzję i ją zapisać.

4. Jak świeże są dane i kto zauważy, gdy przestaną się odświeżać?

Aktualność to wymiar, który psuje się po cichu. Pipeline przestaje działać w piątek, a pierwszy sygnał przychodzi we wtorek, gdy model rekomenduje coś na podstawie danych sprzed tygodnia.

Jak sprawdzić: dla każdej tabeli z pytania pierwszego zapytaj o datę ostatniej aktualizacji i oczekiwaną częstotliwość. Różnica między nimi to opóźnienie. Potem zadaj drugie pytanie: czy istnieje alert, który to wychwyci, czy dowiadujemy się od użytkowników.

Zła odpowiedź: "powinno się odświeżać codziennie" bez możliwości sprawdzenia, czy się odświeża.

5. Ile jest braków, duplikatów i wartości niemożliwych?

Tu wchodzą trzy z klasycznych wymiarów jakości: kompletność (ile pól jest pustych), unikalność (ile rekordów to ten sam byt wpisany dwa razy) i poprawność (ile wartości łamie zdrowy rozsądek, jak data zamówienia z 1970 roku albo ujemna waga paczki).

Jak sprawdzić: nie potrzeba specjalnego narzędzia. Kilkanaście zapytań SQL na wybranych tabelach da obraz w jedno popołudnie. Dla kluczowych kolumn policz odsetek pustych, liczbę zduplikowanych identyfikatorów i liczbę wartości poza oczekiwanym zakresem. Jeśli macie już dbt, te same sprawdzenia to gotowe testy: unique, not_null, accepted_values i relationships (zgodność kluczy między tabelami). Każdy z nich to zapytanie zwracające błędne wiersze, a test przechodzi, gdy nie zwróci żadnego.

Zła odpowiedź: kluczowa kolumna ma 30% braków albo identyfikator klienta powtarza się w kilku tysiącach rekordów. Nie znaczy to, że projekt jest skazany, ale że czyszczenie trzeba wpisać w harmonogram i budżet.

6. Czy wiemy, skąd dane przychodzą i co się z nimi dzieje po drodze?

To pochodzenie danych (lineage). Pole, które model dostaje na wejściu, mogło przejść przez trzy transformacje, jeden arkusz ręcznie poprawiany przez asystentkę i skrypt napisany przez kogoś, kto odszedł z firmy dwa lata temu.

Jak sprawdzić: wybierz jedno kluczowe pole i prześledź je wstecz od raportu do źródła. Policz kroki i osoby, które mogły je zmienić. Jeśli lineage jest udokumentowany w narzędziu, zajmie to godzinę. Jeśli nie, zajmie dzień i da więcej wiedzy niż jakakolwiek ankieta.

Zła odpowiedź: w łańcuchu jest krok, którego nikt nie potrafi wyjaśnić. Taki krok jest pierwszym podejrzanym, gdy model zacznie dawać dziwne wyniki.

7. Czy wolno nam tych danych użyć w tym celu?

Pytanie, które w polskich firmach pada najpóźniej, a kosztuje najwięcej. Jeśli w danych są dane osobowe (klienci, pracownicy, pacjenci), obowiązuje RODO, w tym zasada minimalizacji z art. 5 ust. 1 lit. c: dane mają być adekwatne, stosowne i ograniczone do tego, co niezbędne do celu.

W praktyce oznacza to, że nie wrzucamy do treningu całej bazy klientów, bo "może się przyda". Europejska Rada Ochrony Danych w opinii 28/2024 z grudnia 2024 stwierdziła, że model AI wytrenowany na danych osobowych nie zawsze jest anonimowy, a ocena odbywa się indywidualnie. Podstawa prawna w postaci uzasadnionego interesu wymaga trzyetapowego testu: interes, niezbędność, równoważenie z prawami osób. Opinia wskazuje też środki łagodzące, takie jak pseudonimizacja czy dane syntetyczne.

Jak sprawdzić: dla pól z pytania pierwszego zaznacz te, które są danymi osobowymi. Zapytaj inspektora ochrony danych (albo prawnika), czy cel treningu mieści się w celu, dla którego dane zebrano, i czy wszystkie zaznaczone pola są naprawdę potrzebne. To rozmowa na godzinę, jeśli przyjdziecie z listą.

Zła odpowiedź: "dane są w systemie, więc możemy". Albo "nie wiemy, czy w tych polach tekstowych nie ma danych osobowych". W polach z notatkami handlowców zwykle są.

Co zrobić, jeśli odpowiedzi są złe

Złe odpowiedzi to nie powód, żeby rezygnować z AI. To informacja, gdzie najpierw włożyć pieniądze. Kilka zasad.

Zacznij od jednego przypadku użycia, nie od całej firmy. Doprowadź dane potrzebne do niego do przyzwoitego stanu, zamiast gonić za idealną jakością wszędzie. Pierwsze wyniki pokażą, które braki naprawdę bolą.

Wyznacz właścicieli dla kluczowych pól i zapisz definicje na jednej stronie. To najtańsza interwencja i zwykle daje najwięcej. Bez niej każde kolejne czyszczenie wróci do poprzedniego stanu w ciągu kwartału.

Dodaj automatyczne testy tam, gdzie dane wpływają na model. Ten sam zestaw reguł (unikalność, braki, zakresy, świeżość) można zapisać w dbt, Great Expectations albo Soda, zależnie od tego, co już macie. Narzędzie jest mniej ważne niż to, że test faktycznie blokuje złą paczkę danych, zanim dotrze do modelu.

Przy danych, które przychodzą od innych zespołów, ustalcie prosty kontrakt: jakie pola, w jakim formacie, z jaką świeżością i kogo informować o zmianie. Data contract nie musi być osobnym produktem. Czasem to jeden plik YAML w repozytorium, pod którym podpisują się obie strony.

Na koniec policz koszt. Jeśli wcześniej nikt się danymi nie zajmował, czyszczenie i testy zjedzą w pierwszym projekcie sporą część czasu. Lepiej zobaczyć to w planie niż w drugiej fakturze.

Jak wygląda szybki audyt danych w praktyce

Tydzień wystarczy na wstępną ocenę, jeśli ktoś ją poprowadzi i jeśli ludzie z biznesu mają czas na rozmowy.

Dzień pierwszy: warsztat z osobą decyzyjną, wybór jednego przypadku użycia i lista potrzebnych pól (pytanie 1). Dzień drugi: wywiady z właścicielami i inwentarz definicji (pytania 2 i 3). Dzień trzeci i czwarty: zapytania profilujące na kluczowych tabelach, sprawdzenie świeżości i prześledzenie jednego pola do źródła (pytania 4, 5 i 6). Dzień piąty: rozmowa z inspektorem ochrony danych i podsumowanie.

Wynik to jedna tabela: dla każdego pola ocena (ok, do poprawy, blokuje), właściciel, szacowany koszt naprawy. Do tego decyzja: ruszamy, ruszamy po naprawie X, albo wybieramy inny przypadek użycia. W projektach, które prowadzimy, taka tabela zmienia kolejność prac, a czasem oszczędza zamawianie modelu, który i tak nie miałby na czym się uczyć.

Jeśli chcecie przejść przez te pytania na własnych danych, napiszcie do nas. Chętnie zrobimy to razem, nawet zanim zdecydujecie o jakimkolwiek projekcie.