– Tato, dlaczego tak się uśmiechasz do komputera? – zapytała Jagódka, zakradając się z Otylką do sypialni, gdzie znajduje się moje biurko.
– Ponieważ znalazłem szklaną kulę, dzięki której mogę poznać przyszłość. Zatem nie będę musiał już czekać na poznanie odpowiedzi, których potrzebuję – uśmiechnąłem się.
– A zapytasz tej kuli, co będziemy z Oti robić, jak będziemy takie duże jak tata i mama?
– Wasze zawody prawdopodobnie nie zostały jeszcze wymyślone, Skarbie .
Zbudowaliśmy model, z którego jesteśmy naprawdę dumni! Metryki są dopieszczone i spełniają wymagania postawione przez biznes. Mamy pewność, iż dobraliśmy optymalną liczbę charakterystyk, wybraliśmy najlepszy rodzaj modelu i zoptymalizowaliśmy hiperparametry. Dodatkowo przygotowaliśmy dashboard (tutaj pokazane jak), który wyjaśnia, dlaczego model podjął taką, a nie inną decyzję.
Jedyną niepewną jest to, jak model działa w aktualnym miesiącu na najnowszych danych, ponieważ model przewiduje status klienta, który poznamy dopiero za kilka miesięcy… a szefowie chcą poznać odpowiedź na pytanie:
Szef:
„Jak działa Wasz model po wdrożeniu?”Z pomocą w uzyskaniu odpowiedzi na to pytanie przychodzi nam NannyML z opracowanym algorytmem szacowania wydajności opartym na zaufaniu. Dodatkowo NannyML pomoże nam odpowiedzieć na kilka jeszcze innych pytań, które możemy sobie zadać.
Uwaga! Przed dalszą lekturą warto poznać pojęcia związane z data drift z poprzedniego artykułu!
Czym jest NannyML?
NannyML to tak naprawdę firma stojąca za implementacją biblioteki open source napisaną w Python.
To, co moim zdaniem wyróżnia ten pakiet od innych rozwiązań to, iż patrzy on na problem z lotu ptaka. Twórcy NannyML wyszli z założenia, iż najważniejsza jest predykcja modelu.
Dopiero, o ile z predykcją są problemy, to warto zagłębić się w szczegóły i sprawdzić, chociażby, czy spadek mocy spowodowany jest dryftem danych. jeżeli tak, to można przeanalizować, które cechy na to wpłynęły.
Największe wrażenie wywarł na mnie ich autorski algorytm (zwany CBPE) do estymacji, jak będzie zachowywał się model, choćby jeżeli nie mamy w tym momencie zmiennej celu (groud truth).
Do tego sprawdzenia wystarczą same predykcje! Wobec tego można również przetestować modele napisane w innych językach niż Python (np. R).
Gdzie jest problem?
Załóżmy, iż firma poprosiła Cię o przewidzenie, który klient nie spłaci kredytu gotówkowego w ciągu najbliższych 12 miesięcy. Budujesz model i go wdrażasz. Po wdrożeniu na produkcję otrzymujesz prawdopodobieństwa zwracane przez model.
Dla przykładu mamy 4 klientów:
Po roku od dnia wzięcia kredytu dowiemy się, które z powyższych osób spłaciły kredyt, a które nie:
Wówczas na podstawie zaobserwowanych danych (ground truth) jesteśmy w stanie wyliczyć metryki takie jak accuracy, precision, ROC AUC czy inne.
I właśnie problemem tutaj jest CZAS, który musi minąć, aby dowiedzieć się, jak działa model. Oczywiście jest wiele sposobów na skrócenie go, jak chociażby estymacja na podstawie krótszej historii.
Jednak przyjrzyjmy się bliżej algorytmowi opracowanemu przez NannyML, który pozwala uzyskać wiarygodne oszacowanie wydajności modelu bez konieczności czekania.
Jak działa algorytm Confidence-Based Performance Estimation (CBPE)?
Jest to algorytm, który pozwala oszacować wydajność modelu w przypadku braku rzeczywistych danych (groud truth).
Idea stojąca za tym algorytmem jest prosta. Wykorzystujemy oszacowanie macierzy pomyłek (confusion matrix) na podstawie oczekiwanych poziomów błędów, które znamy przy założeniu, iż model jest dobrze skalibrowany. Mając macierz pomyłek, możemy oszacować dowolną metrykę wydajności, która jest na niej zbudowana (np. presicion, recall, AUC itp). Zaraz wszystko wyjaśnię w szczegółach.
Najpierw warto wiedzieć, iż mamy dwa „ALE”.
Założenia dla CBPE!
Aby algorytm dawał wiarygodne wyniki, muszą zostać spełnione dwa warunki wstępne:
a) Nie może być dryfu koncepcji.
Kiedy nastąpi dryf koncepcji, to granica decyzyjna wyuczona przez model nie ma już zastosowania do nowego wspaniałego świata.
Na szczęście sam dryf danych nie stanowi problemu. jeżeli chcesz dowiedzieć się więcej, czym jest dryf danych, jakie są jego rodzaje itp., to zapraszam do poprzedniego artykułu.
b) Prawdopodobieństwa generowane przez model muszą być odpowiednio skalibrowane.
Model odpowiednio skalibrowany to taki model, którego prawdopodobieństwa dają rzeczywiste częstotliwości występowania.
Kalibracja prawdopodobieństwa jest intuicyjną koncepcją – jeżeli masz grupę osób, których przewidywane prawdopodobieństwo wynosi np. 90%, to około 90% z nich powinno faktycznie okazać się pozytywne.
Uwaga! Większość klasyfikatorów binarnych tworzy wyniki, które są zwykle interpretowane i nazywane jako prawdopodobieństwa modelu… ale w rzeczywistości nie są prawdopodobieństwami. Wyższa liczba rzeczywiście oznacza wyższe prawdopodobieństwo pozytywnej klasy, ale nie zwraca dokładnej informacji, ile wyniesie.
Jednym z wyjątków od powyższej zasady jest regresja logistyczna. Z założenia modeluje prawdopodobieństwa i generuje skalibrowane wyniki. Dlatego jednym ze sposobów kalibracji źle skalibrowanego modelu jest przekazanie jego prognoz do klasyfikatora regresji logistycznej, który powinien je odpowiednio przesunąć! Proste a skuteczne .
Let’s go deeper
Aby lepiej zrozumieć działanie algorytmu, zagłębmy się w przykład z 4 klientami . Nasz model zadziałał 4-krotnie i zwrócił prawdopodobieństwa dla Mirka, Elwiry, Jagody i Otylki.
Jednak w rzeczywistości nie interesują nas prawdopodobieństwa, ale jesteśmy zainteresowani ustaleniem, które osoby będą pozytywne, a które negatywne.
Uwaga! W przypadku szacowania ryzyka klasa pozytywna oznacza, iż klient nie spłacił kredytu. No cóż.
Na początku musimy ustawić próg odcięcia (cut off lub treshold) – obserwacje powyżej tego progu zostaną sklasyfikowane jako pozytywne, a te poniżej progu zostaną sklasyfikowane jako negatywne.
Załóżmy treshold modelu na 50%. Zatem wszystkim osobom z prawdopodobieństwem powyżej 50% przypiszemy flagę 1 (nie spłaci kredytu) a poniżej przypiszemy flagę 0, czyli spłaci kredyt.
Przeanalizujmy prawdopodobieństwo Mirka równe 90%. Ponieważ nie da się ukryć, iż 90%>=50%, to przypisujemy Mirkowi klasę pozytywną (jeśli tak można mówić o tym, iż nie spłaci kredytu).
Ponieważ mamy model skalibrowany, to możemy oczekiwać, iż model będzie poprawny w 90% podobnych przypadków. Zatem zostaje nam 10% szans, iż prognoza będzie fałszywie pozytywna.
Dla Elwiry sprawa wygląda inaczej. Model mówi, iż ma 10% szans na klasę pozytywną, zatem zakładamy, iż jest z klasy negatywnej (10% < 50% – nasz cut off). Zatem Elwira ma 89% na zakwalifikowanie jako True Negative i 11% jako False Negative.
To samo powtarzamy dla Jagódki i Otylki.
Na końcu obliczamy sumę wartości dla wszystkich obserwacji i otrzymujemy w ten sposób macierz pomyłek na podstawie oczekiwanych błędów.
Teraz możemy obliczyć interesujące nas metryki. Na przykład oczekiwaną dokładność metryki accuracy liczymy dzieląc sumę TP i TN przez liczbę przypadków testowych:
I to wszystko .
A jak wyliczyć ROC AUC?
Krzywą ROC rysujemy, umieszczając na jednej osi metrykę True Positive Rate (TPR) a na drugiej False Posite Rate (FPR).
Dla powyższego przypadku wygląda to tak:
Pamiętajmy jednak, iż wybór progu jest arbitralny. Zatem, aby uzyskać ogólne pojęcie o wydajności modelu, krzywa ROC jest zdefiniowana jako zbiór wszystkich TPR/FPR dla wszystkich możliwych progów. Mając 4 różne wartości, istnieje 5 możliwych progów:
Zatem krzywa ROC wyglądałaby tak:
Pole pod wykresem to nasza metryka ROC AUC!
Jak działa sprawdzenie data drift?
Sprawdzenie, czy mamy problem z data drift, również odbywa się w duchu zasady od ogółu do szczegółu.
Na naszej próbce referencyjnej, gdzie mamy wszystkie charakterystyki, dla których zbudowaliśmy model, zmniejszamy ilość wymiarów korzystając z PCA (jeśli chcesz wiedzieć, jak dokładnie działa PCA, to zapraszam do artykułu). Następnie odwracamy proces i patrzymy, jaki otrzymujemy błąd rekonstrukcji (odtwarzania) danych.
Mając taki model PCA, możemy go przeliczyć na naszych najnowszych danych. jeżeli jest istotny dryf danych, wówczas błąd rekonstrukcji dla najnowszych danych powinien być większy niż na próbce referencyjnej. Prosta i genialna idea.
źródłoPrzykład NannyML w Python
Dość teorii. Przejdźmy teraz do praktyki. Na gwałtownie stworzyłem nowe środowisko w Python (kliknij tu, jeżeli nie wiesz jak) i zainstalowałem wszystkie najnowsze biblioteki, byście mogli także powtórzyć to doświadczenie.
Uwaga! Poniżej przygotowałem bardzo prosty preprocessing i model, aby skupić się na pokazaniu, jak wykorzystać NannyML. Nie linczujcie mnie za to, iż nie przygotowałem profesjonalnie oczyszczania danych, wyboru cech, modelu i hiperparametrów .
Wczytajmy potrzebne biblioteki:
Wiem, iż z czasem biblioteki będą miały nowsze wersje, dlatego poniżej dokładne wersje, jakie miałem na moment tworzenia tego przykładu:
Skoro teoretyczny przykład był dla ryzyka kredytowego, to pozostańmy w tym duchu. Wykorzystałem dane z konkursu Kaggle „Home Credit Default Risk„. Dla tego eksperymentu pobrałem jedynie tabelę z danymi aplikacyjnymi: application_train.csv. Dane możesz pobrać TUTAJ.
https://www.kaggle.com/competitions/home-credit-default-risk/data?select=application_train.csvWczytajmy dane:
Szybki preprocessing
Dla uproszczenia zbudujemy na gwałtownie random forest. Dlatego zróbmy prosty preprocessing danych i zamieńmy dane tekstowe na numeryczne.
Wiemy już, co i jak zmienić. Zmieńmy wartości tekstowe binarne na kolumnę z wartościami 0/1, dane tekstowe do 10 unikalnych kolumn zmieńmy na one-hot encoding, a kolumny z większą ilością wartości usuńmy.
Aby w pełni pokazać Wam, jak działa NannyML na podstawie klucza na klientach, przypiszę losowy okres z zakresu 2 lat:
Sprawdźmy, czy poziom klientów, którzy nie spłacają kredytów, jest mniej więcej ten sam:
Budowa przykładowego modelu
NannyML wymaga kolumny z podziałem na zbiór do nauki i do predykcji. Dlatego dla uproszczenia potraktujmy te dwa zbiory odpowiednio jako zbiór treningowy i zbiór testowy, na którym przetestujemy czy NannyML prawidłowo działa.
I przygotujmy zbiory:
Teraz wyłączmy jedynie ze zbioru treningowego zmienne, których nie chcemy używać:
i zbudujmy model:
Zapiszmy jeszcze wartości predykcji:
Kalibracja
We wcześniejszym kroku zbudowaliśmy las losowy. Sprawdźmy teraz, jak wyglądają wyniki predykcji z modelu do rzeczywistych wartości, kto nie spłacił kredytu.
Jak widać na powyższym rysunku, maksymalna wartość predykcji z modelu wychodzi około 0,18. Dla tej wartości widać, iż poziom defaultów wynosi 100%! Z wykresu możemy łatwo wywnioskować, iż od wartości z modelu powyżej 0,10 liczba defaultów w populacji jest wyższa.
Tak jak wcześniej opisałem, przygotowałem kalibrację, korzystając z regresji logistycznej. Jako zmienne do modelu podajemy tylko wartości z predykcji z modelu:
Po zbudowaniu modelu przypiszmy nowe prawdopodobieństwa do zbioru treningowego i testowego z przypisanym progiem odcięcia na poziomie 20%. Dlaczego 20%? Ponieważ przy aktualnym średnim oprocentowaniu, prowizji i % odzyskania w przypadku niespłacenia kredytu to nam się opłaca:
Sprawdźmy wcześniejszy wykres, czy wygląda lepiej:
Widać z wykresu, iż teraz kalibracja działa poprawnie. Wartości predykcji pokazują rzeczywiste wartości niespłaconych kredytów. Dla wyższych wartości są większe wahania, natomiast wynikają z mniejszych liczności.
Mając wyliczoną regresję, sami możemy prosto wyprowadzić funkcję kalibrującą na zmianę predykcji z modelu lasu losowego na rzeczywistą wartość predykcji. Można to zrobić tak:
Sprawdźmy teraz jeszcze, jaka jest różnica pomiędzy predykcją z modelu a predykcją z naszej kalibracji:
NannyML w akcji!
Czas skorzystać z algorytmu CBPE i zobaczyć, jak będą się kształtować metryki modelu w 2022 roku!
Jak widać na podstawie wyliczeń, w ciągu najbliższego roku sytuacja będzie stabilna według algorytmu. Warto zwrócić uwagę, iż niepewność jest na poziomie +/-2% AUC. Czasami to nie jest dużo. Jednak dla wielomilionowego banku z doświadczenia powiem, iż 1% AUC w perspektywie roku może odpowiadać za 1 mln dodatkowego przychodu.
Teraz bardzo prosto jest również sprawdzić inne metryki, na przykład accuracy (przy naszym progu odcięcia):
Nie wygląda to źle. Pamiętajmy, iż użyliśmy tylko danych aplikacyjnych (bez najważniejszych informacji, czyli jak klient historycznie obsługiwał produkty kredytowe), bez optymalizacji wyboru cech, modelu i hiperparametrów!
Porównanie różnic
Sprawdźmy, jak wygląda ostateczne porównanie estymacji algorytmu CBPE z NannyML i rzeczywistych danych.
Wow! Naprawdę zaskakująca skuteczność!
Data Drift
Sprawdźmy jeszcze, jak wygląda wynik algorytmu wyliczającego data drift na podstawie rekonstrukcji błędu z PCA:
Widać, iż nie wykrywamy tutaj dryfu danych.
… a co gdyby zepsuć dane (what if)?
W tym przypadku wszystko jest ok. A co gdybyśmy specjalnie troszkę zepsuli dane i zobaczyli, jak wówczas radzą sobie algorytmy z NannyML?
Sprawdźmy, która cecha z ponad 160 jest najmocniejsza w modelu:
Mamy faworyta! To zmienna „EXT_SOURCE_2”. Mówi ona o szacowanym ryzyku klienta na podstawie biura kredytowego. W Polsce odpowiednikiem takiego biura byłaby punktacja scoringowa z Biura Informacji Kredytowej (BIK).
Zbudujmy teraz próbkę, gdzie dla pierwszych 3 miesięcy z próbki testowej (2022) nic nie zmieniamy, a na pozostałym okresie zostawiamy tylko obserwacje z najwyższą wartością tej zmiennej:
Zobaczmy, jak zachowa się moc modelu na takiej próbce:
Widzimy, iż taka zmiana wpłynęła na moc modelu.
A czy byłoby to możliwe w prawdziwym środowisku bankowym? Oczywiście, iż tak. Wystarczyłoby wprowadzić regułę decyzyjną, która odrzucałaby takich klientów.
A jak w takim przypadku wyglądałby dryf danych?
Widać również przekroczenie zakładanych dopuszczalnych granic błędu.
Co dalej?
Ok, ale co moglibyśmy w takim przypadku zrobić? Tutaj wystarczyłoby sprawdzić zmiany rozkładów wszystkich zmiennych w czasie.
Poniżej zmiana rozkładu prawdopodobieństwa:
Analizując zmienną po zmiennej, zobaczylibyśmy, iż jedyna zmienna, na której zmienił się rozkład to „EXT_SOURCE_2”.
Polecam obserwować bibliotekę NannyML, ponieważ prace nad nią cały czas realizowane są i ciągle się rozwija.
Mam nadzieję, iż również Tobie przyda się w monitorowaniu modeli na produkcji tak jak mi!
Pozdrawiam z całego serducha,
Bibliografia:
- https://www.nannyml.com/
- https://towardsdatascience.com/data-drift-explainability-interpretable-shift-detection-with-nannyml-83421319d05f
- https://pub.towardsai.net/estimating-model-performance-without-ground-truth-453b850dad9a
- https://towardsdatascience.com/predict-your-models-performance-without-waiting-for-the-control-group-3f5c9363a7da
