W tym wpisie chciałbym się z Tobą podzielić przebiegiem i wnioskami z jednego z projektów, które miałem okazję realizować.
Spis treści
- Case study – czym jest i po co o tym piszę.
- Zarys projektu.
- Kilka definicji dotyczących systemu scoringowego.
- Potencjalne korzyści z wdrożenia systemu scoringowego.
- Proces budowy systemu scoringowego.
- Etapy realizacji projektu.
- Podsumowanie.
Case study – czym jest i po co o tym piszę?
Case study, a więc studium przypadku jest analizą pojedynczego zdarzenia lub projektu, pozwalającą wyciągnąć wnioski co do przyczyn i rezultatów jej przebiegu. Analiza ta z założenia powinna być w pewien sposób pouczająca i pozwalająca czerpać wnioski i wiedzę z czyichś (nie)powodzeń.
W Data Science pojedynczym przypadkiem może być np. projekt. Jest on tym, do czego przygotowujemy się przez lata nauki (bez względu na to, czy jest to projekt badawczy, czy komercyjny). Z jednej jest to momentem, gdy nasza wiedza jest weryfikowana, z drugiej zaś, jest bodźcem do nauki i dalszego rozwoju.
Lekcje płynące z projektów (w mojej ocenie) bywają znacznie cenniejsze niż te pochodzące z nawet najlepszych kursów i książek. Jest to wiedza na wagę złota, którą chciałbym się z Tobą podzielić. 🙂
Do wpisu zmotywowały mnie sugestie czytelników bloga. Na przestrzeni tych kilku lat blogowania regularnie pojawiały się prośby o przedstawienie szczegółów z realizowanych projektów bądź też o informacje „zza kulis” moich pracy. Skrupulatnie je spisywałem i oto jest: pierwsze case study na blogu.
Krótkie zastrzeżenie: Wobec pracodawców i kontrahentów jestem zobowiązany dochować tajemnicy dotyczącej szczegółów realizowanych projektów. Informacje, którymi dzielę się poniżej, są zatem dosyć ogólnikowe. Nie mogę wejść na wyższy poziom szczegółowości. Nie mniej jednak wierzę, że ten wpis okaże się dla Ciebie ciekawy i wartościowy. Miłego czytania! 😉
Zarys projektu
Zacznę od przedstawienia kilku kluczowych informacji o projekcie.
- Klient: firma z sektora finansowego, top 3 w swojej branży.
- Czas realizacji: lata 2017 – 2018.
- Zespół, w którym pracowałem: w sumie ok. 10 osób, w zależności od fazy realizacji. Na co dzień były to średnio 3 osoby.
- Cel projektu: budowa systemu scoringowego.
- Moja rola: główny konsultant Data Science / „koń pociągowy” projektu. 😉
Kilka definicji dotyczących systemu scoringowego
Zanim przejdę do szczegółów samego projektu, chciałbym przedstawić kilka definicji dla osób, które wcześniej nie miały doświadczenia z omawianym zagadnieniem.
System scoringowy to system oceny pozwalającej na klasyfikację obserwacji na podstawie wybranych cech. Pozwala sklasyfikować obserwacje na grupy. Zazwyczaj dzielimy obserwacje na dobre i złe.
Prócz samej klasyfikacji w systemie scoringowym szalenie ważnym elementem jest estymacja prawdopodobieństwa (zwłaszcza w sektorze finansowym). Pozwala ona w pewien sposób zarządzić ryzykiem i dopasować model do kryteriów wyznaczonych przez biznes.
Właściciel modelu może też wykorzystywać ocenę punktową klienta nie tylko do decyzji o przyznaniu lub nie kredytu, ale także do ustalenia jego ceny (ew. marży). Jest to tzw. wycena produktu oparta na ryzyku (ang. risk-based pricing).
W większości przypadków nie wystarczy, że wskażemy, czy klient jest dobry, czy zły. Model, który budujemy, powinien być również odpowiednio skalibrowany. Co to oznacza? W praktyce chcemy mieć względnie wysoką pewność, że spośród 100 klientów, dla których model ocenił prawdopodobieństwo np. na 70%, około 70 faktycznie nie wywiąże się ze zobowiązania (będą „jedynkami”).
Każdorazowo predykcja zostaje wyznaczona dla przyjętego horyzontu czasowego. Jest on ustalany z biznesem/klientem na podstawie ich oczekiwań. Horyzont czasowy jest to zakres czasu, jaki będziemy rozpatrywać. Przyjmując horyzont trzech miesięcy, nasz model odpowie na pytanie: czy w ciągu trzech miesięcy od wyznaczenia scoru, klient okaże się nierzetelny (wpadnie w default)?
Jeszcze kilka słów o defaulcie, który często pojawia się przy temacie scoringu. Jest on niczym innym, jak niewywiązaniem się obserwacji ze zobowiązania, które zostało podjęte. Przykład: klient zaciągnął pożyczkę gotówkową i w ciągu 3 najbliższych miesięcy przestał spłacać raty. 3 miesiące są tu umowne i zazwyczaj wartość ta jest ustalana z biznesem. Podobnie jest z „przestaniem spłacania”, które również jest obiektem wewnętrznych ustaleń.
Tego typu system wywodzi się z sektora finansowego, choć jego zastosowanie jest znacznie szersze. Jest on przecież niczym innym jak specyficznym systemem rozwiązującym problem klasyfikacji dwuklasowej. Równie dobrze tę samą metodologię budowy można zastosować przy problemie, np. retencji klientów.
Ideę scoringu dobrze przedstawia poniższa grafika.
Wybrana obserwacja – przykładowa JDG Jak Kowalski, jest opisany w bazie za pomocą szeregu zmiennych. Spośród n-zmiennych, 4 zostały użyte do wyznaczenia scoru, który wskazuje, że podmiot jest raczej kiepskim kandydatem na klienta. 😉
Potencjalne korzyści z wdrożenia
Głównym benefitem dla sponsora projekty są oczywiście pieniądze (jak to w biznesie). Zysk finansowy zazwyczaj ma pochodzić z:
- automatyzacji podejmowanych decyzji, co przekłada się na oszczędność czasu,
- ograniczania ryzyka (np. nie podejmujemy współpracy z klientami, którzy prawdopodobnie nie wywiążą się z umowy),
- odpowiedniego zarządzania posiadanym kapitałem (to temat dosyć złożony i nie będę go omawiać w tym wpisie).
Proces budowy systemu scoringowego
Proces budowy systemu scoringowego wygląda jak typowy projekt Data Science. Oczywiście wiele zależy od przyjętej metodyki wytwarzania modelu. My robiliśmy zgodnie z własną metodyką, która może przypominać CRISP-DM (ang. Cross Industry Standard Process for Data Mining).
Etapy realizacji projektu
Bazując na schemacie przedstawionym powyżej, omawiany projekt składał się z następujących etapów:
ETAP 1. Zrozumienie biznesu.
Celem tego etapu było zrozumienie potrzeb biznesu. Pierwsze 3-4 spotkania odbyły się jeszcze zanim wprowadziliśmy się do klienta „na stałe”.
Na tym etapie chcieliśmy się upewnić, że obie strony mają świadomość wyzwań i możliwości, jakie przed nimi stoją. Rozmawialiśmy o wymaganiach i ograniczeniach. Sam model, nawet najlepszy znaczy niewiele, jeśli istnieją realne bariery uniemożliwiające skonsumowanie jego rezultatów. Chcieliśmy mieć pewność, że na naszej drodze nie ma żadnych blokad.
Z ciekawostek mogę powiedzieć, że na tym etapie okazało się, że konieczna będzie budowa nie jednego, a dwóch modeli. Nasze rozwiązanie miało scorować również klientów bez żadnej historii w bazie danych, bazując jedynie na danych aplikacyjnych (wiek, płeć, wykształcenie, rodzaj prowadzonej działalności, etc.).
ETAP 2. Zrozumienie dostępnych danych.
Pierwsze spotkanie dotyczące danych odbyło się w mocno technicznym gronie. Na stałe do naszego zespołu dołączyć ekspert, który projektował bazę danych klienta i miał o niej pełną wiedzę. Na tym etapie chcieliśmy mieć pewność, sami rozumiemy dostępne źródła, ich podziału i logikę biznesową.
Następnie przeszliśmy do eksploracyjnej analizy danych. Wyznaczaliśmy podstawowe statystyki, weryfikowaliśmy braki i ocenialiśmy jakość poszczególnych zbiorów. Podjęliśmy pierwsze próby łączenia tabel i budowy zbioru ABT (ang. Analytical Base Table).
To, co mnie zaskoczyło, to duża asymetria zbioru – zmienna celu (na tym etapie wyznaczona jeszcze w sposób „roboczy”) była bardzo skośna. Musieliśmy coś z tym zrobić. Mieliśmy dostępne następujące możliwości:
- Próbować zbudować model na dostępnym zbiorze.
- Użyć metod samplowania i generowania „sztucznych” obserwacji (np. SMOTE).
- Wykonać samplowanie mające na celu zbalansowanie próby.
- Wpłynąć na rozkład zmiennej celu, poprzez zmianę definicji zmiennej celu (np. wraz ze skróceniem horyzontu czasowego, liczba obserwacji o y=1 maleje).
- Wzbogacenie naszego zbioru ABT o nowe źródła.
Finalnie po masie testów (które, jak szacuję, że zajęły nam ok. 40-50% projektu) zdecydowaliśmy się zastosować punkty 3, 4 i 5. Czemu tak długo? Otóż podczas iteracyjnego testowania wyżej wymienionych punktów, każdorazowo musieliśmy przechodzić przez proces budowy zmiennej celu (podział klientów na dobrych i złych), przygotowanie ABT, selekcję zmiennych, budowę modelu i ocenę modelu. Podczas gdy my modelowaliśmy, biznes starał się „wzbogacić” bazę o nowe źródła.
ETAP 3. Ustalenie finalnej definicji zmiennej celu.
Etap ten częściowo pokrywał się z poprzednim. Celem było znalezienie złotego środka, a więc takiej definicji zmiennej celu, która spełnia założenia biznesowe i sprawia, że zbiór ABT jest odpowiednio zbalansowany.
Etap ten sprowadzał się do odpowiedzi na dwa pytania: kto i kiedy?
Kto? – Kogo nazwiemy nierzetelnym, złym klientem?
Kiedy? – Jakie ramy czasowe przyjmie okres obserwacji. Jaki horyzont czasowy przyjmiemy? W odpowiedzi na to pytanie musieliśmy uwzględnić takie czynniki, jak:
- Zadbanie o odpowiednio wysoką zmienność danych (liczba transakcji, defaultów w danym okresie).
- Rozkład zmiennej celu w zbiorze ABT.
Z oczywistych przyczyn nie będę zdradzać wypracowanej definicji.
Przeczytaj również o… kategoryzacji zmiennych z użyciem drzewa decyzyjnego
ETAP 4. Pozyskanie nowych danych.
Po zadbaniu o formalności (kwestie prawne), przeszliśmy do integracji dwóch nowych źródeł ze źródłami już istniejącymi. Zbudowaliśmy skrypt, który w oparciu o dostępne API działał w dwóch trybach:
- Pobierał i zapisywał nowe dane do istniejących kartotek bazie.
- Pobierał i zapisywał dane nowych kartotek (na poczet uczenia).
W uproszczeniu nasz model danych wyglądał następująco:
- Dane z wewnętrznych źródeł klienta:
- Tabele opisujące klientów (teleadresowe).
- Tabele opisujące historię transakcji.
- Tabele opisujące wierzycieli.
- Dane pochodzące ze źródeł zewnętrznych.
ETAP 5. Przygotowanie danych.
Po raz kolejny wykonaliśmy filtrowanie danych o złej jakości i próbkowanie. Wykonaliśmy podział zbioru na 2 części:
- Ucząca.
- Walidacyjna.
Części testowej nie było. Wszystkie testy wykonywaliśmy na próbie uczącej z użyciem walidacji krzyżowej, uwzględniającej znacznik czasowy (w bibliotece sklearn ten rodzaj walidacji nazwany jest z ang. TimeSeriesSplit). Część walidacyjna posłużyła nam do finalnej walidacji jakości modelu.
Ciekawostka: w sektorze finansowym nazwy kolejnych prób różnią się od tych używanych w innych branżach (ucząca, walidacyjna, testowa) i w języku angielskim (train, validation, test). W bankach finalną weryfikację, przed wdrożeniem modelu, wykonuje dział walidacji modeli, stąd nazwa finalnej próby weryfikacyjnej brzmi: walidacyjna. 🙂
ETAP 6. Modelowanie.
Podczas projektu powstały 2 modele, które korzystały z następujących źródeł danych:
- Model 1 (behawioralny).
- Dane klientów.
- Dane dotyczące historii prowadzenia konta.
- Dane dotyczące historii spłat zobowiązań.
- Dane produktów, z jakich korzystał klient.
- Dane ze źródeł zewnętrznych.
- Model 2 (aplikacyjny).
- Dane ze źródeł zewnętrznych.
- Dane aplikacyjne.
Miary sukcesu, jakimi ocenialiśmy modele:
- Gini – podstawowa miara jakości modelu, dobrze znana i rozumiana przez biznes.
- Czułość (ang. recall) – procentowa wartość wszystkich dobrze rozpoznanych defaultów. Sprawdzaliśmy nią jak dobrze model „wycina” jedynki (złych klientów).
- Stabilność – badana podczas walidacji krzyżowej z pomocą współczynnika zmienności. Wyrażana w wartościach z przedziału 0-100. Liczona z pomocą wzoru: 100 – std(gini)/mean(gini).
Testowane algorytmy:
- Regresja logistyczna.
- Drzewo decyzyjne.
- Naiwny klasyfikator Bayesa
- Gradient Boosting.
Dobór zmiennych: wstępna filtracja oparta na współczynniku zmienności + analizie jednowymiarowej, a następnie selekcja zmiennych z użyciem autorskiej metody mojego znajomego (stepwise selection + variance inflation factor). Podejmowane były równie próby z użycie innych metod (recursive feature elimination, feature importance, etc.), ale bez większych sukcesów.
Finalnie w przypadku obu modeli wybór padł na regresję logistyczną i < 10 zmiennych. Najlepsze wyniki dał gradient boosting, lecz były one nieznacznie lepsze niż GLM, przy dużym spadku poziomu interpretowalności.
Dokładnych wyników, jakie osiągnął model, nie pamiętam (choć przecież i tak nie mógłbym ich przedstawić ;-)). Z dużą pewnością, w ujęciu statystyki Gini, mogę powiedzieć, że był to „rynkowy standard” dla tego typu rozwiązań. 😉
ETAP 7. Omówienie i przedstawienie wyników.
Ostatnie kilka tygodni pracy projektowej, to dogrywanie szczegółów, wymiana uwag dotyczących dokumentacji i przygotowywanie finalnej prezentacji dla interesariuszy. Moja praca na tym projekcie powoli dobiegała końca i powoli przechodziłem w inne miejsce.
Wyniki, jakie udało nam się uzyskać, zostały bardzo dobrze przyjęte. Po kilku miesiącach wytężonej pracy projekt został zamknięty i wspólnie ogłosiliśmy sukces. 🙂
Z ciekawostek dotyczących tego etapu mogę dodać, iż po zbudowaniu modelu zostaliśmy poproszeni o wykonanie dwóch rzeczy:
- Dobór optymalnego punktu odcięcia z uwzględnieniem uwarunkowań biznesowych.
- Przedstawienie scoru klienta w dwóch wersjach: surowej (prosto z modelu) i skalowanej (w której dobrany punkt odcięcia jest na poziomie 0.5).
Jak wybrać punkt odcięcia, bazując na uwarunkowaniach biznesowych?
Jeśli zastanawiasz się, po co komukolwiek skalowana wersja oceny scoringowej, to już tłumaczę. Osoby obsługujące system chciały, by cut-off był dokładnie w połowie skali. Z ich perspektywy wpływało to pozytywnie na interpretowalność zwracanych wyników.
Być może zastanawiasz się co z samym wdrożeniem. Otóż nie braliśmy w nim udziału. Wdrożenie powierzono jednostce wewnętrznej, podobnie jak monitorowanie wyników modelu.
Podsumowanie
Mam nadzieję, że ten wpis przypadł Ci do gustu i dowiedziałaś/-eś się z niego czegoś nowego. 🙂 Jeżeli masz jakieś pytania, to możesz podzielić się nimi w komentarzu pod wpisem.
W ciągu ok. 10 lat pracy zawodowej udało mi się wyrobić przydatny nawyk polegający na tym, że po zakończeniu projektu spisuję w swoim notesie wnioski, uwagi i nauki z niego płynące. W kolejnej części tego wpisu podzielę się z Tobą wybranymi lekcjami z tego projektu. 🙂
Źródła:
photo: pixabay.com
Dodaj komentarz