Rozpoznawać wzorce. Decydować wcześniej.

Wiarygodną wartość docelową można ustalić dopiero na podstawie konkretnego przypadku użycia i reprezentatywnych danych. Uzgadniamy metody pomiaru i kryteria przerwania zamiast ogólnego wskaźnika sukcesu.

Obserwujemy dane wejściowe i dostępne informacje zwrotne dotyczące jakości. Aktualizacja odbywa się w sposób kontrolowany i jest sprawdzana względem obecnej wersji, zanim zostanie wdrożona produkcyjnie.

Prognozowanie zapotrzebowania, wykrywanie anomalii lub lepsze planowanie konserwacji: opracowujemy modele dla jasno zdefiniowanego procesu decyzyjnego. To, czy pomagają, mierzymy w odniesieniu do Państwa obecnego procesu i prostego rozwiązania porównawczego, zanim rozpocznie się pracochłonna integracja.

Ocena przypadków użycia według korzyści, dostępności danych i ryzyka Prototyp na rzeczywistych danych z porównaniem do obecnego procesu Budowa modelu z udokumentowanymi cechami, danymi treningowymi i wskaźnikami jakości Integracja przez interfejsy z ERP, MES, CRM lub systemami płatniczymi Wytłumaczalność wyników dla działu biznesowego, audytorów i osób, których dotyczą

Oceniony przypadek użycia z kryteriami przerwania Gotowy do produkcji model z interfejsem Karta modelu z jakością, ograniczeniami i wytłumaczalnością

Na początku ustalamy, jakie działanie wynika z rezultatu i które błędy są kosztowne. Przeoczona usterka ma inne konsekwencje niż zbędne powiadomienie o konserwacji. Na tej podstawie powstają wartości docelowe i akceptowalne wskaźniki błędów. Dane treningowe są sprawdzane pod kątem kompletności, dostępności w odpowiednim momencie i reprezentatywności. Informacje, które stają się znane dopiero po zdarzeniu będącym przedmiotem prognozy, nie mogą przypadkowo trafić do zbioru treningowego. Prosty model bazowy pokazuje, czy bardziej złożony model rzeczywiście przynosi dodatkową korzyść.

Dane zależne od czasu są sprawdzane we właściwej kolejności czasowej. Poszczególne lokalizacje, grupy produktów lub rzadkie przypadki analizujemy osobno, aby dobry wynik ogólny nie maskował słabych obszarów. Cechy i wersje modeli dokumentujemy tak, aby można je było później prześledzić. W docelowym procesie oprócz wyniku dostarczamy odpowiednie wskazówki dotyczące niepewności i ograniczeń. Jeżeli wynik wykracza poza sprawdzony zakres, można przewidzieć merytoryczną ścieżkę weryfikacji. Obliczenia można zintegrować w formie przetwarzania wsadowego lub przez interfejs, zależnie od wymaganego czasu reakcji.

Zatwierdzenie obejmuje zasilanie danymi, czas odpowiedzi, zachowanie przy brakujących danych wejściowych oraz ocenę merytoryczną. Dostarczamy udokumentowane porównanie z modelem bazowym oraz plan monitorowania i aktualizacji. Prototyp może też wykazać, że dostępne dane nie wystarczają do pożądanej prognozy. Wówczas wskazujemy luki w danych i alternatywne podejścia, zanim powstaną dalsze koszty rozwoju.

Niezależnie od tego, czy chodzi o prognozę popytu, wykrywanie anomalii czy klasyfikację: najpierw sprawdzamy, jaką decyzję ma poprawić model i jakie błędy są przy tym akceptowalne. Dopiero z tego wynikają przygotowanie danych, wybór modelu i sposób oceny.

Model jest porównywany z przejrzystym rozwiązaniem bazowym. Dane do oceny i dane testowe są oddzielone od danych treningowych. Niepewne wyniki i awarie mają zdefiniowaną ścieżkę obsługi.

Przykład: dział obsługi chce priorytetyzować napływające zgłoszenia. Trenujemy i testujemy model na historycznie ocenionych przypadkach, analizujemy koszty błędów i przekazujemy niepewne wyniki do ręcznego przeglądu. Korzyść mierzymy czasem obsługi i jakością merytoryczną, a nie tylko wskaźnikiem modelu.

Złożony model musi udowodnić swoją przewagę nad prostą regułą lub dotychczasowym sposobem pracy. Ustalamy taką podstawę i rozdzielamy dane treningowe, walidacyjne i testowe odpowiednio do zadania. W przypadku danych zależnych od czasu szczególnie zapobiegamy temu, aby informacje z przyszłości pośrednio trafiły do treningu. Poza średnią jakością analizujemy istotne podgrupy i rzadkie przypadki. Dobry wynik ogólny może maskować nieprzydatny proces, jeśli właśnie krytyczne wyjątki są oceniane błędnie. W ocenie merytorycznej uwzględniamy więc fałszywe alarmy, przeoczone przypadki i koszt ręcznej weryfikacji.

Prognozy potrzebują odbiorcy i działania. Definiujemy, kiedy model wydaje rekomendację, kiedy decyzję podejmuje człowiek i kiedy system powinien wstrzymać się od prognozy, ponieważ dane nie wystarczają do wiarygodnej oceny. Interfejsy, czasy odpowiedzi i wymagane wyjaśnienia dopasowujemy do tego procesu. Po wdrożeniu obserwujemy dane wejściowe i jakość wyników. Zmiany w ofercie produktowej lub sposobie pracy mogą wpływać na przydatność modelu. Uzgadniamy zdarzenia wyzwalające ponowną ocenę oraz ścieżkę powrotu do wcześniejszej wersji lub procesu ręcznego. Automatyczne douczanie modelu ma sens tylko wtedy, gdy zorganizowane są również weryfikacja i zatwierdzenie.

Lista priorytetów z korzyściami i nakładem pracy Dział biznesowy, IT, ochrona danych, Data Architect OTOKO® Ocenione przypadki użycia, mapa danych, klasyfikacja regulacyjna

Architektura danych, podejście modelowe, governance Dział biznesowy, architektura, bezpieczeństwo informacji Architektura docelowa, model eksploatacji, kryteria sukcesu, koncepcja ochrony danych