Po co w ogóle Explainable AI? Prawdziwy problem, nie akademicka moda
Gdy model mówi „nie”, a nikt nie wie dlaczego
Wyobraź sobie zespół pracujący nad modelem kredytowym. Metryki w Jupyterze wyglądają świetnie: AUC wysoko, stabilność w porządku, walidacja krzyżowa elegancka. Model idzie na produkcję. Po miesiącu dział sprzedaży wraca z frustracją: „System odrzuca część dobrych klientów bez wyraźnego powodu. Nie umiemy im tego wytłumaczyć”. Klient pyta: „Dlaczego mój wniosek został odrzucony?”, a konsultant ma co najwyżej odpowiedź: „Taki wynik z systemu”.
Drugi przykład: model churn prediction. Dane są bogate, użyty gradient boosting robi wrażenie na konferencjach. Jednak na liście „klientów wysokiego ryzyka” pojawiają się osoby, które według ludzi z obsługi są bardzo lojalne. Zespół produktowy pyta: „Co właściwie model uznaje za sygnał odejścia? Czy mamy podnieść limit kontaktów z call center, czy poprawić onboarding?”. Z samym numerkiem „prawdopodobieństwo churnu = 0,87” niewiele da się zrobić.
W obu sytuacjach brakuje jednego elementu: zrozumienia decyzji modelu ML. Nie chodzi o akademickie „ładne dowody”, tylko o bardzo praktyczne pytania: które czynniki faktycznie wpływają na wynik, w jaki sposób, i czy to ma sens dla biznesu, prawa i zdrowego rozsądku.
Różnica między „dobry wynik na metryce” a „kontrolujemy model”
Model może mieć świetne wyniki na walidacji, a jednocześnie opierać się na błędnych lub ryzykownych wzorcach. Klasyczny przykład: przyjęcia do szpitala. Model rozpoznawania sepsy działa znakomicie w danych historycznych, ale w praktyce nauczył się, że pacjenci trafiający na OIOM mają poważniejsze przypadki, więc „OIOM” stał się dla niego skrótem do wysokiego ryzyka. Problem w tym, że ta informacja jest wynikiem wcześniejszej decyzji lekarza, a nie cechą pacjenta przy przyjęciu.
Metryki jak accuracy, F1, AUC mówią, jak dobrze model przewiduje. Explainable AI odpowiada na inne pytanie: dlaczego model przewiduje tak, a nie inaczej. Dopiero połączenie tych dwóch perspektyw daje kontrolę. Jeśli nie wiesz, co model wykorzystuje do decyzji, nie masz narzędzi do:
wykrywania biasów i nieetycznych zależności,
uzasadniania decyzji przed klientem, audytorem czy regulatorem,
debuggowania dziwnych zachowań po wdrożeniu,
świadomego rozwijania modelu (np. dodawania nowych cech).
Główne powody, dla których Explainable AI staje się koniecznością
Można wskazać kilka głównych obszarów, w których wyjaśnialność modeli machine learning staje się realną potrzebą, a nie dodatkiem:
Zaufanie i akceptacja – biznes, użytkownicy i zarząd muszą mieć poczucie, że model nie działa losowo. Bez tego najpiękniejszy model wyląduje w szufladzie.
Regulacje i compliance – w sektorach takich jak bankowość, ubezpieczenia czy medycyna, decyzje AI podlegają prawu. Trzeba móc wyjaśnić, na jakiej podstawie ktoś dostał lub nie dostał kredytu albo dlaczego otrzymał konkretną diagnozę wspieraną przez model.
Debugging modeli – XAI to świetne narzędzie diagnostyczne. Pozwala sprawdzić, czy model nie korzysta z „dziwnych skrótów” (np. kodu pocztowego jako proxy dochodu), czy nie ignoruje krytycznych cech.
Etyka i bias – wyjaśnialność pomaga wychwytywać dyskryminację, np. gdy model traktuje gorzej pewne grupy klientów przez powiązane zmienne (proxy), nawet jeśli jawnych cech typu płeć czy rasa w danych nie ma.
Co znaczy „zrozumieć decyzję modelu” dla różnych ról
To samo wyjaśnienie decyzji modelu ML będzie inaczej wyglądać dla różnych odbiorców.
Data scientist chce wiedzieć:
które cechy napędzają predykcje globalnie,
czy model reaguje zgodnie z intuicją domenową (np. wyższy dochód → wyższa akceptacja kredytu),
jak zachowuje się w nietypowych regionach przestrzeni cech.
Product manager potrzebuje odpowiedzi na pytania:
jakie główne czynniki wpływają na wynik,
co można zmienić w produkcie lub procesie, by poprawić wskaźniki (np. zmniejszyć churn),
jak wytłumaczyć logikę modelu w prosty sposób stakeholderom i klientom.
Prawnik lub dział compliance patrzy na:
czy model nie wykorzystuje cech zabronionych lub ich proxy,
czy da się w sposób przejrzysty uzasadnić decyzje jednostkowe,
czy dokumentacja i audyt modeli ML spełniają wymogi regulatorów.
Użytkownik końcowy zwykle chce prostego, uczciwego wyjaśnienia: „Twoje szanse na kredyt zmniejszyły się głównie przez historię spóźnionych spłat i niski staż pracy. Gdy poprawi się X i Y, prawdopodobieństwo akceptacji wzrośnie”. Tyle, bez gradientów i drzew decyzyjnych.
Podstawy: interpretowalność vs wyjaśnialność – o czym właściwie mowa
Interpretowalność: gdy model jest z natury czytelny
Interpretowalność modeli ML oznacza, że sam model jest na tyle prosty, iż człowiek może zrozumieć jego działanie bez dodatkowych narzędzi. Klasyczne przykłady:
regresja liniowa / logistyczna,
proste drzewa decyzyjne o niewielkiej głębokości,
reguły decyzyjne typu „if-then-else”.
W regressji logistycznej każdy współczynnik mówi, jak dana cecha wpływa na log-odds wyniku. W drzewie decyzyjnym można prześledzić ścieżkę: „jeśli dochód > X i brak opóźnień w spłatach, to akceptacja”. Taki model jest white-box – wiadomo, co się dzieje w środku.
Wyjaśnialność: narzędzia do tłumaczenia złożonych modeli
Wyjaśnialność (explainability) odnosi się do sytuacji, w której model jest złożony i sam z siebie nie jest zrozumiały, ale korzystamy z dodatkowych metod, aby go „przetłumaczyć” na język człowieka. Przykłady takich modeli:
głębokie sieci neuronowe,
zespoły drzew (random forest, gradient boosting),
modele z setkami cech, z interakcjami i nieliniowościami.
To są typowe black-boxy. Explainable AI buduje wokół nich warstwę tłumaczącą: SHAP, LIME, partial dependence plots, modele zastępcze i inne. To trochę jak tłumacz symultaniczny między „językiem modelu” a „językiem człowieka”.
Modele white-box i black-box – kiedy który ma sens
Prosty schemat:
White-box – modele w pełni przejrzyste (regresja, proste drzewa, listy reguł), łatwe do ręcznej inspekcji, zwykle mniej dokładne w trudnych problemach.
Black-box – modele bardzo dokładne, ale nieprzejrzyste (głębokie sieci, boosting), wymagające Explainable AI do zrozumienia ich działania.
W praktyce często łączy się oba światy: korzysta się z black-boxa dla jakości predykcji, ale opakowuje go metodami XAI lub prostszymi modelami zastępczymi na potrzeby wyjaśnień dla biznesu.
Globalne i lokalne poziomy wyjaśniania modelu
Wyjaśnialność można rozpatrywać na dwóch poziomach:
Globalne wyjaśnianie modelu – próba odpowiedzi na pytanie „jak model działa ogólnie?”. Przykłady: globalne ważności cech, partial dependence plots, globalne reguły.
Wyjaśnienia na poziomie predykcji (lokalne) – odpowiedź na pytanie „dlaczego ten konkretny klient dostał wynik 0,87, a nie 0,35?”. Tutaj wchodzą: SHAP dla jednego punktu, LIME, lokalne modele zastępcze, breakdown.
Globalny poziom pomaga zrozumieć politykę modelu. Lokalny – pozwala uczciwie rozmawiać o konkretnych decyzjach i przypadkach brzegowych.
Różne grupy odbiorców, różne formy wyjaśnień
Wyjaśnienia trzeba dopasować nie tylko do modelu, ale też do odbiorcy:
Techniczni (data scientist, ML engineer) – poradzi sobie z SHAP summary plot, wykresami ICE, analizą interakcji, dokładnymi liczbami.
Biznes i produkt – potrzebuje prostych wizualizacji i narracji: ranking cech, kilka przykładów lokalnych wyjaśnień, historia wybranych klientów pokazująca logikę modelu.
Regulator / audytor – potrzebuje stabilnych, powtarzalnych metryk, jasnego opisu procesu, dowodów, że model nie dyskryminuje i ma kontrolowane ryzyko.
Klient końcowy – krótka, zrozumiała informacja: co zaważyło na decyzji i co może się zmienić w przyszłości.
Źródło: Pexels | Autor: Google DeepMind
Jak dobrać poziom złożoności modelu do potrzeb wyjaśnialności
Trade-off: dokładność vs interpretowalność
Zderzają się tu dwie ambicje:
jak najlepsze metryki predykcji,
takie wyjaśnialności modeli ML, które da się obronić przed biznesem i regulatorem.
Nie zawsze najbardziej złożony model jest najlepszym wyborem. Często prostszy model o minimalnie gorszej metryce, ale zdecydowanie wyższej przejrzystości, daje większą wartość biznesową. Łatwiej go utrzymać, wytłumaczyć i uczciwie audytować.
Decyzję o stopniu złożoności warto podejmować nie tylko na podstawie AUC, ale też:
krytyczności decyzji (np. medycyna, sądownictwo, kredyty),
ryzyka regulacyjnego,
oczekiwań biznesu co do wyjaśnialności,
dostępności narzędzi XAI i kompetencji w zespole.
Przykład: scoring kredytowy – regresja logistyczna vs gradient boosting
W scoringu kredytowym klasyczny wybór to regresja logistyczna. Jest:
dobrze znana regulatorom,
łatwa do interpretacji,
stosunkowo prosta do audytowania.
Jednak nowsze techniki, jak gradient boosting, potrafią wycisnąć dodatkowe punkty AUC, lepiej wykorzystać nieliniowości, interakcje, mikrowzorce zachowań. Pytanie brzmi: czy te kilka procent poprawy jakości predykcji jest war warte kosztu w postaci znacznie gorszej interpretowalności?
Częste podejście:
start z regresji logistycznej jako baseline’u,
porównanie z boostingiem,
jeśli różnica jakości jest duża – użycie boostingu plus silne narzędzia XAI (np. SHAP) oraz dokumentacja wyjaśniająca logikę,
jeśli różnica mała – pozostanie przy regresji z prostymi, zrozumiałymi zmiennymi.
Strategia modelu zastępczego (surrogate model)
Aby pogodzić black-box i wymagania przejrzystości, często stosuje się modele zastępcze. Działa to tak:
Trenujesz złożony model (np. XGBoost) jako model główny na danych rzeczywistych.
Generujesz dużą liczbę przykładów (prawdziwych lub syntetycznych) i przepuszczasz je przez black-box, zbierając predykcje.
Na tym zbiorze (cechy wejściowe + predykcje black-boxa) trenujesz prosty, interpretowalny model (np. drzewo decyzyjne) jako surrogate.
Ten model zastępczy służy do globalnego wyjaśniania: opisuje w przybliżeniu „politykę” działania black-boxa.
Kluczowy jest tu kompromis: surrogate nie będzie tak dokładny jak oryginał, ale pozwoli zrozumieć główne reguły, interakcje, podziały populacji. To narzędzie dla ludzi, którzy nie potrzebują szczegółów każdego przypadku, lecz ogólnego obrazu.
Kryteria wyboru złożoności i poziomu XAI
W praktyce przydaje się krótka checklista:
Ryzyko decyzji – im większy wpływ predykcji na życie ludzi lub finanse firmy, tym prostszy lub lepiej wyjaśniony model.
Regulacje – jeśli sektor podlega ścisłym regulacjom, przewaga prostych modeli lub bardzo mocnej warstwy XAI jest wyraźna.
Dojrzałość organizacji a apetyt na złożoność
Złożoność modelu powinna rosnąć mniej więcej w tym samym tempie, co dojrzałość analityczna organizacji. Inaczej wygląda wdrożenie XAI w firmie, gdzie pierwszy raz wchodzi się w ML, a inaczej tam, gdzie istnieje zespół data science, procesy MLOps i cykliczne audyty modeli.
Prosty podział pomaga poukładać oczekiwania:
Organizacja początkująca – 1–2 modele, brak formalnych procesów, mało danych historycznych. Tu zwykle bronią się white-boxy (regresja, proste drzewa) i ręcznie tworzone raporty wyjaśniające.
Organizacja „średniozaawansowana” – kilka modeli w produkcji, podstawowy monitoring, rosnące oczekiwania co do jakości. Pojawia się miejsce na boosting i pierwsze narzędzia XAI (SHAP, LIME), ale wciąż z mocnym naciskiem na prostotę komunikacji.
Organizacja zaawansowana – kilkanaście–kilkadziesiąt modeli, MLOps, zespoły ds. ryzyka, dedykowane osoby do audytów. Tu można myśleć o złożonych architekturach, ale też o systemowym podejściu do wyjaśnialności (standardy, biblioteki, panele XAI).
Model, którego nikt nie rozumie i którego nikt nie potrafi sensownie wytłumaczyć klientowi albo regulatorowi, prędzej czy później wyląduje w koszu – niezależnie od metryk. Lepiej zejść pół kroku niżej z „sztucznej inteligencji” i wejść poziom wyżej z zaufania.
Narzędziownik Explainable AI – przegląd metod z praktycznym kompasem
Trzy pytania, które porządkują wybór metody XAI
Zamiast zapamiętywać dziesiątki nazw, lepiej zadać sobie trzy proste pytania:
Co chcesz wyjaśnić? Cały model (globalnie) czy pojedynczą decyzję (lokalnie)?
Jakie masz dane? Klasyfikacja czy regresja, dane tabelaryczne, czasowe, obrazowe?
Kto jest odbiorcą wyjaśnień? Zespół data science, biznes, regulator, klient?
Odpowiedzi na te pytania szybko zawężają wybór. Innych narzędzi wymaga analiza ryzyka kredytowego w banku, a innych – wyjaśnianie rekomendacji produktów w e-commerce.
Metody globalne – „charakterystyka modelu jako całości”
Globalne metody wyjaśniania pomagają odpowiedzieć na pytania typu: „które cechy są ogólnie najważniejsze?”, „jak zmienia się predykcja, gdy rośnie dana zmienna?”. Dają obraz polityki modelu.
Najczęściej wykorzystywane narzędzia:
Globalna ważność cech (np. permutacyjna, SHAP globalny) – ranking cech odpowiedzialnych za zmienność predykcji w całej populacji.
Partial Dependence Plots (PDP) – średni wpływ zmiennej na predykcję, przy „uśrednieniu” po innych cechach.
ICE (Individual Conditional Expectation) – wykresy pokazujące, jak zmiana jednej cechy wpływa na predykcję dla poszczególnych obserwacji (a nie tylko średnio).
Modele zastępcze – proste drzewa/reguły przybliżające zachowanie złożonego modelu.
Dobrze dobrane narzędzie globalne pozwala szybko wychwycić: nadmierne poleganie na jednej cesze, nieintuicyjne zależności (np. „im większy dochód, tym niższa ocena ryzyka”) albo niespodziewane interakcje.
Metody lokalne – „dlaczego ten konkretny przypadek dostał taki wynik”
Metody lokalne schodzą na poziom pojedynczej decyzji. Odpowiadają na pytanie: „czemu akurat ta osoba/ta transakcja/ten wniosek został oceniony tak, a nie inaczej?”.
Do najpopularniejszych podejść należą:
SHAP w wariancie lokalnym – dla pojedynczej obserwacji rozkłada predykcję na wpływy cech.
LIME – buduje lokalny, prosty model wokół wybranego punktu.
Breakdown / additive feature attribution – pokazuje krok po kroku, jak kolejne cechy przesuwają predykcję.
W praktyce to właśnie metody lokalne najczęściej trafiają „na front” – do PDF-a dla klienta, do systemu obsługi wniosków, do panelu CRM. To one odpowiadają na naturalne ludzkie pytanie: „dlaczego ja?”.
Metody model-agnostic vs model-specific
Inny użyteczny podział: model-agnostic versus model-specific.
Model-agnostic – działają na dowolnym modelu, traktując go jak czarną skrzynkę (wejście–wyjście). Przykłady: permutacyjna ważność cech, PDP, ICE, LIME, większość wariantów SHAP. Atutem jest uniwersalność oraz możliwość porównywania wyjaśnień między różnymi modelami.
Model-specific – wykorzystują wewnętrzną strukturę konkretnego typu modelu (np. drzewa decyzyjne, sieci neuronowe). Są zwykle szybsze i dokładniejsze dla danej klasy modeli, ale mniej przenośne.
Jeśli w środowisku produkcyjnym rotują różne algorytmy, wygodnie jest zbudować „warstwę XAI” opartą głównie na metodach model-agnostic – nie trzeba wtedy przepisywać wszystkiego przy zmianie architektury.
Typowe pułapki przy wyborze narzędzi XAI
Dobór metod XAI ma kilka klasycznych pułapek, które powtarzają się w wielu projektach:
Fetysz jednej metody – „wszędzie SHAP”, „wszędzie LIME”. Jedno narzędzie rzadko odpowiada na wszystkie pytania. Lepiej połączyć dwie–trzy techniki niż próbować wcisnąć każdą sytuację w jeden schemat.
Mieszanie celów – to, co jest świetne dla zespołu data science (np. wykresy ICE), może być kompletnie nieczytelne dla zarządu czy klienta końcowego. Te same dane można pokazać różnym ludziom w zupełnie inny sposób.
Ignorowanie stabilności wyjaśnień – dwie bardzo podobne obserwacje dostają zupełnie inne wyjaśnienia? To sygnał, że coś jest nie tak: z modelem, z wyborem narzędzia lub z parametrami metody XAI.
Czasem najwięcej robi mały eksperyment: kilka narzędzi, kilkanaście tych samych przypadków, wspólne oglądanie wyników z biznesem i techniką. Szybko wychodzi, co naprawdę „niesie sens”, a co tylko ładnie wygląda.
Źródło: Pexels | Autor: Google DeepMind
Feature importance i permutacje: pierwszy poziom zrozumienia modelu
Dlaczego „ważność cech” to dobry start – i zły koniec
Ranking ważności cech to często pierwszy wykres, który ogląda zespół po trenowaniu modelu. I bardzo dobrze: jedna kolumna z nazwą cechy, druga z jej „wagą” – da się to pokazać prawie każdemu. Jest jednak pewien haczyk.
Feature importance odpowiada na pytanie „jak bardzo model polega na danej cesze”, ale:
nie mówi, czy wpływ jest „dobry” czy „zły” (np. rośnie czy maleje ryzyko),
zwykle nie pokazuje interakcji między cechami,
łatwo ją przekłamać przy silnie skorelowanych zmiennych.
Można ją traktować jak mapę drogą w niskiej rozdzielczości. Widać główne drogi i miasta, ale nie zobaczymy uliczek, korków i objazdów.
Permutation feature importance – jak to działa w praktyce
Jedna z najzdrowszych metod mierzenia ważności cech to permutation feature importance. Idea jest zaskakująco prosta:
Mierzysz jakość modelu na zbiorze walidacyjnym (np. AUC, accuracy, RMSE).
Bierzesz jedną cechę i losowo permutujesz jej wartości między obserwacjami – „psujesz” ją w danych.
Ponownie mierzysz jakość modelu.
Spadek jakości to miara ważności tej cechy dla modelu.
Jeśli „zniszczenie” danej cechy prawie wcale nie zmienia metryki – model w praktyce jej nie potrzebuje (lub ma mocnych zastępców). Jeśli jakość leci ostro w dół, oznacza to, że właśnie tę zmienną model naprawdę wykorzystuje.
Wybór metryki przy permutacjach – więcej niż detal
Permutation importance jest tak dobra, jak metryka, którą wybierzesz. Dla klasyfikacji binarnej najczęściej:
AUC – dobra, gdy ważne jest porządkowanie przypadków,
log-loss – gdy liczy się poprawne skalowanie prawdopodobieństw,
F1 / precision / recall – jeśli konkretny typ błędu ma największe znaczenie biznesowe.
W jednym z zespołów scoringowych pojawił się kiedyś spór: według permutation importance na AUC „dochód” był mniej ważny niż liczba zapytań kredytowych. Po analizie na log-loss okazało się, że dochód jest kluczowy dla poprawnego skalowania ryzyka, choć mniej wpływa na porządkowanie. Takie niuanse łatwo zgubić, gdy patrzy się tylko na jeden wskaźnik.
Ostrożnie z ważnością z drzew losowych i boostingu
Popularne biblioteki (np. random forest, gradient boosting) często oferują „ważność cech” jako gotowy produkt. Zwykle bazuje ona na:
Gini importance albo
gain / split importance – ile „korzyści” przynoszą podziały w drzewach.
Takie miary są wygodne, ale obarczone kilkoma problemami:
faworyzują cechy o większej liczbie możliwych wartości (np. zmienne ciągłe vs kategoryczne z niewielu klas),
czytane bez kontekstu mogą przeceniać znaczenie cech mocno skorelowanych z innymi,
najczęściej nie są bezpośrednio porównywalne między różnymi modelami.
Dlatego w projektach o wyższym ryzyku sensownie jest oprzeć się raczej na permutation importance, a wbudowane miary traktować jako wskazówkę, nie jako ostateczny dowód.
Jak prezentować feature importance biznesowi i regulatorom
Ten sam ranking cech może być podany na kilka sposobów w zależności od odbiorcy. Kilka praktycznych trików:
Ogranicz liczbę cech widocznych „na pierwszy rzut oka” – 8–10 wystarczy. Reszta może trafić do załącznika technicznego.
Grupuj podobne cechy – zamiast 12 różnych wskaźników zadłużenia, pokaż 2–3 logiczne grupy (np. „zachowanie płatnicze”, „aktywność kredytowa”), a szczegóły pozostaw zespołowi analitycznemu.
Dodaj krótką narrację przy najważniejszych cechach: jedno zdanie wyjaśniające, dlaczego model na nich polega („liczba spóźnionych spłat to sygnał problemów z płynnością, dlatego model silnie ją uwzględnia”).
Taki prosty zabieg często rozbraja napięcia na linii „czarna skrzynka” – „kontrola”. Ludzie widzą, że model opiera się na sensownych, intuicyjnych informacjach, a nie na przypadkowych korelacjach.
SHAP w praktyce: od teorii do sensownych wykresów
Intuicja stojąca za SHAP – „rachunek za rachunek”
SHAP (SHapley Additive exPlanations) odwołuje się do koncepcji wkładu gracza w wynik gry z teorii gier. Każda cecha jest takim „graczem”, a predykcja modelu – „wygraną”. Pytanie brzmi: jaki jest uczciwy wkład każdej cechy w konkretną predykcję?
W teorii gier liczy się wszystkie możliwe kolejności, w których gracze mogą dołączać do koalicji, i mierzy się, jak zmienia się wynik. W SHAP robi się podobnie, ale zamiast ludzi mamy cechy wejściowe, a zamiast wygranej – wynik modelu. W efekcie dostajemy zestaw liczb, które:
sumują się do różnicy między predykcją a wartością bazową (np. średnią predykcją),
są spójne globalnie i lokalnie – to, co ważne lokalnie, „składa się” na globalne znaczenie cechy.
W praktyce oznacza to: można wziąć pojedynczego klienta, policzyć dla niego SHAP values i powiedzieć: „zero to typowy klient, twoje +0,3 pochodzi głównie z cechy A i B, a -0,1 z cechy C”.
Warianty SHAP – nie tylko jeden algorytm
Pod zbiorczą nazwą „SHAP” kryje się kilka wariantów:
Główne typy algorytmów SHAP – co się za tym kryje technicznie
Pod wspólnym szyldem SHAP działa kilka dość różnych mechanizmów obliczania wartości Shapleya. Dobrze jest wiedzieć, który jest „pod maską”, bo wpływa to i na czas obliczeń, i na sensowność wyników:
TreeSHAP – wersja zoptymalizowana dla modeli drzewiastych (random forest, XGBoost, LightGBM, CatBoost). Wykorzystuje strukturę drzew, dzięki czemu liczy dokładne wartości Shapleya szybko, nawet dla tysięcy obserwacji.
KernelSHAP – uogólniona, model-agnostic metoda. Traktuje model jak czarną skrzynkę i aproksymuje wartości Shapleya przez sprytne próbkowanie podzbiorów cech. Działa prawie wszędzie, ale bywa wolna i czuła na dobór parametrów.
DeepSHAP – wariant dla sieci neuronowych (szczególnie w Keras/TensorFlow). Wykorzystuje gradienty i strukturę sieci, łącząc idee SHAP i tzw. DeepLIFT.
LinearSHAP – uproszczona wersja dla modeli liniowych i logistycznych, gdzie wartości Shapleya można wyprowadzić analitycznie z wag modelu i statystyk danych.
Jeśli kod ma w jednym miejscu modele drzewiaste, a w innym sieć neuronową, nie wystarczy „dodać SHAP”. Trzeba świadomie dobrać wariant i zrozumieć, że wyniki z TreeSHAP i KernelSHAP mogą różnić się nie tylko liczbami, ale i stabilnością.
Wybór wartości bazowej – co właściwie oznacza „zero” na wykresie SHAP
Każde wyjaśnienie SHAP rozkłada predykcję na:
wartość bazowa + suma wkładów cech (SHAP values) = predykcja modelu
Kluczowe pytanie: czym jest ta wartość bazowa? Najczęściej:
średnią predykcją na zbiorze referencyjnym (np. zbiór treningowy lub walidacyjny),
czasem medianą lub wartością oczekiwaną w podpopulacji (np. klienci danej linii biznesowej).
Od tego wyboru zależy interpretacja „zera”. Jeśli bazą jest średnia prawdopodobieństwo defaultu całego portfela, to SHAP +0,15 oznacza: „ten klient ma o 0,15 wyższe ryzyko niż przeciętny klient w portfelu”. Jeśli bazą jest węższa grupa, narracja będzie inna.
W praktyce dobrze działa prosty trik: policzyć SHAP na kilku potencjalnych zbiorach referencyjnych (np. wszyscy klienci vs tylko nowi vs tylko z danego kraju) i sprawdzić, jak zmieniają się interpretacje. Czasem jeden wybór podbija różnice, innym razem je wygładza.
Globalne wykresy SHAP – jak nie utopić się w kolorowych chmurkach
Pierwszy kontakt wielu osób z SHAP to słynny summary plot: poziome paski z kolorowymi kropkami. Wygląda efektownie, ale łatwo z niego wyciągnąć zbyt pochopne wnioski. Kilka elementów, na które opłaca się patrzeć:
Pozioma kolejność cech – najwyżej leżą zmienne o największej globalnej ważności (mierzonej np. średnią wartością bezwzględną SHAP). To dobry punkt startu do rozmowy: „na czym model najczęściej opiera decyzje?”.
Rozrzut kropek – szeroki „wachlarz” oznacza, że dana cecha dla części obserwacji ma bardzo duży wpływ, ale niekoniecznie dla wszystkich. To cenna informacja przy projektowaniu polityk biznesowych czy wyjątków.
Kolor – zwykle oznacza wartość danej cechy (niebieski – niskie, czerwony – wysokie). Kierunek nachylenia chmury mówi, czy wysokie wartości cechy podnoszą, czy obniżają predykcję.
Jeśli na summary plot widać, że wysokie „zadłużenie” (czerwone kropki) skupia się po prawej stronie (dodatnie SHAP), a niskie po lewej – można spokojnie powiedzieć: „dla modelu im wyższe zadłużenie, tym wyższe ryzyko”. To jest ten moment, gdy teoria spotyka się ze zdrowym rozsądkiem.
Wykresy zależności SHAP – prosty sposób na interakcje
Jedną z mocniejszych stron SHAP jest możliwość podglądania interakcji między cechami bez pisania skomplikowanych formuł. Służą do tego tzw. dependence plots.
Schemat jest prosty:
oś X – surowa wartość wybranej cechy (np. wiek),
oś Y – wartość SHAP dla tej cechy,
kolor – inna cecha, z którą chcemy zbadać interakcję (np. dochód).
Na jednym projekcie kredytowym taki wykres pokazał ciekawą rzecz: dla młodszych klientów rosnący dochód szybko obniżał ryzyko (SHAP spadał), ale dla bardzo starszych ten efekt się wypłaszczał. Sama tabela feature importance w ogóle tego niuansu nie zdradzała.
Dependence plots dobrze się sprawdzają na warsztatach z biznesem. Zamiast mówić abstrakcyjnie „model uwzględnia interakcje”, można pokazać krzywą i zapytać: „czy to zachowanie ma sens z perspektywy waszego doświadczenia?”.
SHAP dla pojedynczej decyzji – wykres waterfall krok po kroku
Gdy rozmowa schodzi na poziom „dlaczego ten konkretny klient dostał taką decyzję?”, przydaje się waterfall plot (lub podobny wykres sił). Działa to jak rozpisanie rachunku:
start od wartości bazowej (np. średnie ryzyko),
każda cecha dodaje lub odejmuje część wyniku,
na końcu lądujemy w punkcie „predykcja dla tej osoby”.
Na takim wykresie od razu widać, że np.:
„historia spłat” podnosi ryzyko o +0,18,
„wysoki dochód” obniża o -0,10,
„staż w pracy” minimalnie redukuje kolejne -0,02 itd.
Po kilku takich przykładach menedżerowie zwykle zaczynają mówić: „to trochę jak ocena analityka kredytowego, tylko w bardziej rozpisanej formie”. I o to chodzi – SHAP przestaje być tajemniczym algorytmem, a staje się narzędziem do porządkowania intuicji.
Stabilność wyjaśnień SHAP – jak sprawdzić, czy nie „drży ziemia pod nogami”
SHAP potrafi być zaskakująco stabilny, ale nie jest z natury odporny na:
szum w danych wejściowych,
niestabilny trening modelu (szczególnie przy małych próbach lub dużej losowości),
zbyt małe lub nieprzemyślane zbiory referencyjne przy KernelSHAP.
Zanim zacznie się wysyłać wykresy SHAP do regulatora, warto wykonać kilka prostych testów:
Powtórzenie treningu modelu z innymi seedami i porównanie rankingów globalnych SHAP – czy kolejność cech zmienia się radykalnie?
Porównanie lokalnych wyjaśnień dla prawie identycznych obserwacji – czy „top 3 cechy” jest podobne?
Sensitivity check – delikatne „zaszumienie” wejścia (np. drobna zmiana dochodu, zaokrąglenie liczby zapytań) i sprawdzenie, czy wyjaśnienia nie zmieniają się skokowo.
Jeśli lokalne wyjaśnienia „przeskakują” między kompletnie różnymi zestawami cech, a model jest używany w kontekście regulowanym, to raczej sygnał do przeprojektowania niż do polerowania dashboardu.
Typowe błędy przy użyciu SHAP w projektach produkcyjnych
W praktyce powtarza się kilka schematów, które potrafią unieważnić całą pracę z SHAP:
Mieszanie jednostek czasu i populacji – liczenie SHAP na historycznym zbiorze z innej epoki biznesowej i prezentowanie go jako „aktualnego” wyjaśnienia. Przy zmianie polityk, produktów czy scoringu bazowego trzeba odnawiać zbiory referencyjne.
Brak kontroli nad preprocesingiem – SHAP liczony po „gołych” cechach, mimo że model widzi ich złożone transformacje (np. target encoding, zlogarytmowane wartości). Wyjaśnienie przestaje odpowiadać temu, co naprawdę „widzi” algorytm.
Traktowanie SHAP jak orakulum przy złym modelu – jeśli model jest przeuczony, nieskalibrowany lub po prostu słabo dopasowany, SHAP tylko bardzo precyzyjnie opisuje jego błędy. Najpierw solidny model, dopiero potem szczegółowe XAI.
Dobrym nawykiem jest proste pytanie zadawane przy każdym wykresie SHAP: „czy gdyby model się mylił w danym fragmencie przestrzeni, ten wykres by nas o tym ostrzegł?”. Jeśli odpowiedź brzmi „nie bardzo”, warto uzupełnić SHAP innymi metodami.
Źródło: Pexels | Autor: Google DeepMind
LIME i metody lokalne: patrzymy na jedną decyzję naraz
Na czym polega LIME – lokalne przybliżenie czarnej skrzynki
LIME (Local Interpretable Model-agnostic Explanations) wychodzi z innej intuicji niż SHAP. Zamiast szukać „uczciwego” podziału wkładu między cechy globalnie, mówi: „tu, w okolicy tej konkretnej obserwacji, zachowanie modelu można przybliżyć prostym modelem”.
Algorytm działa w kilku krokach:
Wybiera jedną obserwację, którą chcemy wyjaśnić.
Perturbuje ją – generuje wiele podobnych wersji (np. zmieniając trochę wartości cech).
Przepuszcza te nowe punkty przez oryginalny model i zbiera predykcje.
Dopasowuje prosty, interpretowalny model (np. regresję liniową lub małe drzewo) do tych lokalnych danych, mocniej ważąc punkty bliższe obserwacji bazowej.
Współczynniki prostego modelu traktuje jako wyjaśnienie: które cechy są najistotniejsze w tej okolicy.
Można to porównać do patrzenia na bardzo skomplikowaną górę z bliska. Zamiast próbować opisać kształt całego łańcucha górskiego, rysujemy lokalny przekrój w okolicy schroniska, w którym stoimy.
Jakie modele lokalne stosować w LIME – prostota kontra wierność
Sednem LIME jest lokalny model zastępczy. Najczęściej używa się:
regresji liniowej – bardzo łatwo ją wytłumaczyć, ale słabo łapie każde nieliniowości, nawet lokalnie,
małych drzew decyzyjnych – minimalny kompromis między prostotą a możliwością złapania odrobiny złożoności.
Im prostszy model lokalny, tym łatwiej go zrozumieć, ale tym większe ryzyko, że nie oddaje dobrze lokalnego zachowania oryginalnego modelu. Z drugiej strony, zbyt rozbudowany model lokalny zamienia się po chwili w kolejną czarną skrzynkę.
Rozsądną praktyką jest:
zacząć od prostego wariantu (np. regresja liniowa),
policzyć miarę dopasowania lokalnego (np. R² lub błąd lokalny),
jeśli dopasowanie jest słabe, sięgnąć po nieco bogatszy model lokalny, ale tylko tam, gdzie to konieczne.
W narzędziach raportowych można pokazywać klientowi uproszczone, „przycięte” wyjaśnienie (kilka cech z najwyższym wpływem), a pełny model lokalny trzymać w dokumentacji technicznej.
Perturbacja danych w LIME – skąd biorą się „sąsiedzi”
Kluczowa decyzja przy LIME to sposób generowania lokalnych obserwacji. Od tego zależy, czy „okolica” faktycznie przypomina świat, w którym działa model. Najczęściej stosuje się:
losowe zmiany cech ciągłych (np. dodawanie małego szumu, próbkowanie z rozkładu zbliżonego do oryginalnego),
losowe przełączanie kategorii dla zmiennych kategorycznych,
skalowanie i ważenie odległości tak, aby punkty bliższe oryginalnej obserwacji miały większy wpływ.
Jeśli perturbacje są zbyt agresywne, LIME „patrzy” na regiony przestrzeni, w których model nigdy nie był dobrze nauczony, i lokalne wyjaśnienie robi się fantazyjne. Zbyt zachowawcze perturbacje z kolei oznaczają, że lokalny model dostaje mało zróżnicowane dane i niewiele może powiedzieć o wpływie cech.
Prosty test: wygenerować kilka zestawów perturbacji dla tej samej obserwacji, policzyć kilka wersji LIME i sprawdzić, na ile powtarzalne są kluczowe cechy w wyjaśnieniu. Jeśli lista „top 3” ciągle się zmienia, parametry perturbacji wymagają korekty.
Porównanie SHAP i LIME – kiedy które narzędzie ma większy sens
SHAP i LIME często pojawiają się w jednym zdaniu, ale służą nieco innym celom i mają inne mocne strony:
Co warto zapamiętać
Explainable AI nie jest dodatkiem „dla naukowców”, tylko warunkiem sensownego użycia modeli w biznesie – bez zrozumienia decyzji systemu konsultant w banku czy zespół od churnu dostają jedynie „magiczny numer”, z którym niewiele mogą zrobić.
Dobre metryki (AUC, F1, accuracy) nie gwarantują, że model działa rozsądnie – może opierać się na błędnych skrótach, jak w przykładzie sepsy, gdzie sygnałem „wysokiego ryzyka” stała się decyzja o przyjęciu na OIOM, a nie realne cechy pacjenta.
Wyjaśnialność jest kluczem do kontroli nad modelem: pozwala wykrywać bias i nieetyczne zależności, tłumaczyć decyzje klientom i regulatorom, debugować dziwne zachowania po wdrożeniu oraz rozwijać model w świadomy sposób.
Różne role potrzebują różnych wyjaśnień: data scientist szuka wglądu w cechy i zachowanie modelu w przestrzeni danych, product manager potrzebuje przełożenia logiki modelu na decyzje produktowe, a prawnik patrzy na zgodność z regulacjami i unikanie cech zabronionych.
Użytkownik końcowy oczekuje prostego, uczciwego komunikatu „co zaważyło na decyzji i co mogę poprawić”, zamiast technicznego żargonu – np. jasnego wskazania, że o odrzuceniu kredytu zdecydowały spóźnione spłaty i krótki staż pracy.
