Większość projektów wykorzystujących AI rozstrzyga się na danych, nie na modelu. Ocena danych powinna poprzedzać wybór narzędzia.
Co oceniamy
- kompletność — ile rekordów ma wypełnione pola istotne,
- spójność — czy te same rzeczy zapisane są tak samo,
- aktualność — kiedy dane były ostatnio poprawiane,
- dostępność — czy da się je pobrać bez ręcznej pracy,
- historię — jak daleko wstecz sięgają.
Ocena nie jest opinią. Każdy z tych punktów da się sprawdzić zapytaniem do bazy albo przeglądem eksportu: ile rekordów ma puste pole, ile wariantów zapisu ma ta sama nazwa dostawcy, jak stary jest najstarszy dokument.
Spójność bywa większym problemem niż braki
Brak danych widać. Niespójność udaje dane poprawne. Ta sama firma zapisana na cztery sposoby, jednostka miary raz jako „szt", raz jako „sztuki", kategoria wpisywana z palca zamiast wybierana z listy. Przy zliczaniu i dopasowywaniu każdy taki wariant tworzy osobny byt, a wynik wygląda wiarygodnie i jest błędny.
Dane rozproszone
Informacja podzielona między system, arkusze i skrzynki pocztowe wymaga scalenia, zanim cokolwiek na niej zbudujemy. Ten etap bywa większy niż samo wdrożenie. Trzeba wtedy rozstrzygnąć, które źródło jest rozstrzygające przy rozbieżności — bez tej decyzji scalanie nie ma reguły.
Dane opisowe
Opisy zgłoszeń, notatki, korespondencja. Przy zastosowaniach językowych to zwykle najcenniejszy zbiór — i najczęściej pomijany przy ocenie. Warto sprawdzić, czy da się je wydobyć w całości i czy zachowany jest kontekst: samo pytanie klienta bez udzielonej odpowiedzi ma ograniczoną wartość.
Ile danych wystarczy
Zależy od zastosowania. Klasyfikacja zgłoszeń potrzebuje setek przykładów, wyszukiwanie w dokumentach — samych dokumentów. Warto to rozstrzygnąć przed obietnicami. Ta sama ocena rozstrzyga, które czynności nadają się do automatyzacji: bez danych elektronicznych nawet dobry kandydat odpada.
Dane wrażliwe
Osobowe, handlowe, objęte umowami. Ich obecność decyduje o tym, gdzie wolno przetwarzać — i bywa argumentem za rozwiązaniem lokalnym. Warto ustalić to na etapie audytu, bo decyzja wpływa na koszt i na to, jakie narzędzia w ogóle wchodzą w grę.
Skąd je wziąć
Możliwość pobrania danych zależy od środowiska technicznego. Odczyt z bazy, interfejs programistyczny albo eksport plikami — sprawdza się to razem z oceną stanu systemów i możliwości integracji.
Uczciwa ocena
Wynik „dane nie wystarczają" jest lepszy niż projekt oparty na założeniu, że jakoś się uda. Bywa też początkiem sensownego projektu porządkowania. Jakość danych jest zresztą najczęstszym z ryzyk rozpoznawanych w audycie, więc lepiej nazwać ją wprost niż odkryć w połowie prac.
Jak przeprowadzić ocenę
Nie trzeba do tego dużego przedsięwzięcia. Wystarczy próbka: eksport kilkuset rekordów z każdego istotnego zbioru i przejrzenie ich pod kątem wymienionych wyżej punktów. Braki i niespójności widać wtedy od razu, a wynik da się wyrazić prostą liczbą — udziałem rekordów nadających się do użycia. Tę samą próbkę warto pokazać osobom, które te dane wprowadzają. Zwykle od razu wyjaśniają, skąd biorą się dziwne wartości, i wskazują pola wypełniane dla porządku, których nikt nie czyta.
