Bardzo lubię czytać klasyczne powieści detektywistyczne. Wspólnie z bohaterami, takimi jak Sherlock Holmes, Hercules Poirot czy Panna Marple, próbuję rozwiązywać zagadki, mając do dyspozycji tylko kilka poszlak.
Każdy, kto czytał tego typu książkę, wie, jak trudno i jak dużo czasu potrzeba, żeby określić, „kto zabił”, na podstawie wielu niejednoznacznych i pozornie sprzecznych ze sobą informacji. I podobnie jest z danymi.
Dochodzenie
Praca specjalisty od danych przypomina pracę detektywa. Przychodzi rano do pracy, a w jego skrzynce e-mailowej czeka już pytanie: „dlaczego dane na raporcie X są błędne?” albo „dlaczego model machine learning wyliczył błędne wartości?”. Oczywiście najczęściej błędy tego typu pojawiają się w krytycznych momentach, czyli w dniu, w którym akurat najbardziej potrzebujemy raportu albo poprawnych informacji z modelu.
W tym momencie specjalista od danych może założyć słynną czapkę Sherlocka i rozpocząć dochodzenie. Może błąd jest w samym raporcie albo w warstwie danych bezpośrednio przygotowującej do niego dane. A może jest głębiej, na poziomie analitycznej warstwy lub hurtowni danych? A może jeszcze dalej, na poziomie warstwy integracji czy samego systemu źródłowego? Czy te dane są błędne, a może algorytmy je transformujące? Poszukiwanie rozwiązania tej zagadki może trwać godzinami, a nawet dniami.
Znaczenie
Scenariusz, który przedstawiłem powyżej, jest i tak dość optymistyczny. Zakłada, że w procesie podejmowania decyzji specjalista ze strony biznesowej zauważył, że dane na raporcie lub wyliczenia modelu machine learning są błędne, co pozwoliło uniknąć dalszych szkód. Ale z praktyki wiemy, że równie często zdążają się sytuacje, w których na podstawie błędnych raportów lub sugestii algorytmu ktoś podejmuje błędne decyzje.
Sytuacja robi się szczególnie poważna, gdy weźmiemy pod uwagę raczkujący jeszcze na szczęście trend automatyzacji procesów na podstawie modeli AI. Nie możemy przecież liczyć, że modele te przy pomocy intuicji podobnej do intuicji specjalisty biznesowego zauważą błędy w danych i zaraportują je właściwym osobom. Zresztą sposób radzenia sobie z takimi przypadkami jest ważnym elementem tworzonych obecnie regulacji dotyczących AI.
Obserwowalność
Trendem w IT, który wychodzi naprzeciw tym problemom, jest obserwowalność danych (ang. data observability). Koncepcja ta zakłada monitorowanie procesów i stanu danych na wszystkich możliwych etapach ich integracji i transformacji w organizacji. Jest więc mieszanką ról i zasad wypracowanych w ramach projektów data governance, narzędzi mierzenia i czyszczenia danych wdrażanych w ramach projektów data quality oraz narzędzi do monitorowania infrastruktury, systemów i procesów przetwarzania danych wraz z odpowiednimi raportami i alertami pozwalającymi nie tylko wcześnie otrzymać informację o błędach w danych, ale i w łatwy sposób odnaleźć źródło ich powstawania.
Podejście takie nie jest niczym nowym w szerzej pojętym świecie IT. Obecnie mamy do wyboru ogromną liczbę narzędzi pozwalających na monitorowanie stanu infrastruktury czy systemów IT, które umożliwiają zespołom administracji i utrzymania natychmiastową reakcję na błędy, zanim jeszcze zostaną one zauważone przez użytkowników tychże systemów.
Dlatego dużo lepszym wyjściem będzie adaptacja tych dobrych praktyk w obszarze danych niż skazywanie naszych pracowników na niekończące się prowadzenie śledztwa w celu odnalezienia odpowiedzi na pytanie, „kto zabił”.
Łukasz Nienartowicz
Britenet
