Dowiedz się, jak modele przyczynowe Judei Pearla pomagają zespołom wyjaśniać zachowanie AI, debugować błędy i podejmować jaśniejsze decyzje produktowe poza korelacjami.
Zespół zauważa coś „oczywistego” na dashboardzie: użytkownicy, którzy otrzymują więcej powiadomień, wracają częściej. Więc zwiększają liczbę powiadomień. Tydzień później retencja spada, a liczba skarg rośnie. Co się stało?
Początkowy wzorzec był prawdziwy — ale mylący. Najbardziej zaangażowani użytkownicy naturalnie wyzwalają więcej powiadomień (bo więcej korzystają z produktu) i też naturalnie wracają częściej. Powiadomienia nie powodowały retencji; to zaangażowanie wpływało na oba zjawiska. Zespół zadziałał na podstawie korelacji i przez przypadek stworzył gorsze doświadczenie.
Myślenie przyczynowe to nawyk zadawania pytania: co powoduje co i skąd o tym wiemy? Zamiast zatrzymywać się na „te dwie rzeczy występują razem”, starasz się oddzielić:
Chodzi nie o sceptycyzm wobec danych, lecz o precyzję pytania. „Czy powiadomienia korelują z retencją?” to co innego niż „Czy wysyłanie większej liczby powiadomień zwiększy retencję?” Drugie pytanie jest przyczynowe.
Ten tekst skupia się na trzech praktycznych obszarach, gdzie wykrywanie wzorców zawodzi najczęściej:
To nie jest matematycznie ciężka wycieczka po wnioskowaniu przyczynowym. Nie musisz uczyć się notacji do-calculus, by wynieść tu wartość. Celem są modele myślowe i workflow, które zespół może użyć, by:
Jeśli kiedykolwiek wypuściłeś zmianę, która „ładnie wyglądała w danych”, ale nie zadziałała w rzeczywistości, myślenie przyczynowe jest brakującym ogniwem.
Judea Pearl to informatyk i filozof nauki, którego prace zmieniły sposób, w jaki wiele zespołów myśli o danych, AI i podejmowaniu decyzji. Przed jego rewolucją przyczynową wiele z „uczenia się z danych” opierało się na skojarzeniach statystycznych: znajdź wzorce, dopasuj modele, przewiduj, co nastąpi dalej. To podejście jest potężne — ale często zawodzi, gdy zadajesz pytanie produktowe lub inżynieryjne zawierające słowo bo.
Podstawowa zmiana Pearla polegała na traktowaniu przyczynowości jako konceptu pierwszorzędnego, a nie jako mglista intuicji przykrywającej korelacje. Zamiast pytać tylko „gdy X jest wysokie, czy Y też jest wysokie?”, myślenie przyczynowe pyta: „jeśli zmienimy X, czy Y się zmieni?” Ta różnica wydaje się mała, ale oddziela przewidywanie od podejmowania decyzji.
Skojarzenie odpowiada na „co ma tendencję występować razem”. Przyczynowość stara się odpowiedzieć „co by się stało, gdybyśmy interweniowali”. To ma znaczenie w informatyce, bo wiele realnych decyzji to interwencje: wypuszczenie funkcji, zmiana rankingów, dodanie zabezpieczeń, modyfikacja zbioru treningowego czy polityki.
Pearl uczynił przyczynowość bardziej praktyczną, przedstawiając ją jako wybór modelu plus jawne założenia. Nie „odkrywasz” przyczynowości automatycznie z danych; proponujesz historię przyczynową (zwykle opartą na wiedzy dziedzinowej) i używasz danych do testowania, estymacji i dopracowania tej historii.
Te narzędzia dały zespołom wspólny język do przejścia od wykrywania wzorców do jasnego i zdyscyplinowanego odpowiadania na pytania przyczynowe.
Korelacja oznacza, że dwie rzeczy poruszają się razem: gdy jedna rośnie, druga ma tendencję rosnąć (lub spadać). Jest bardzo użyteczna — szczególnie w zespołach pracujących z danymi — bo pomaga w predykcji i wykrywaniu.
Jeśli sprzedaż lodów rośnie przy wyższej temperaturze, skorelowany sygnał (temperatura) może poprawić prognozy. W pracy produktowej i AI korelacje napędzają modele rankingowe („pokaż więcej tego, co kliknęli podobni użytkownicy”), wykrywanie anomalii i szybkie diagnostyki.
Kłopot zaczyna się, gdy traktujemy korelację jako odpowiedź na inne pytanie: co się stanie, jeśli coś zmienimy celowo? To jest przyczynowość.
Relacja skorelowana może być podyktowana trzecim czynnikiem wpływającym na obie zmienne. Zmiana X niekoniecznie zmieni Y — bo X mogło nie być powodem, dla którego Y się przesunęło.
Wyobraź sobie wykres tygodniowych wydatków marketingowych wobec tygodniowej sprzedaży i mocną pozytywną korelację. Pokusa, by stwierdzić „więcej wydatków powoduje więcej sprzedaży”, jest duża.
Ale załóżmy, że obie rosną w okresie świątecznym. Sezon (czynnik zakłócający) zwiększa popyt i jednocześnie uruchamia większe budżety. Jeśli zwiększysz wydatki w tygodniu bez sezonu, sprzedaż może się prawie nie zmienić — bo nie ma podstawowego popytu.
Jesteś w obszarze przyczynowości, gdy słyszysz siebie pytającego:
Gdy czasownik to zmienić, wprowadzić, usunąć lub zmniejszyć, korelacja jest wskazówką startową — nie regułą decyzyjną.
Diagram przyczynowy — często rysowany jako DAG (Directed Acyclic Graph) — to prosty sposób, by wizualizować założenia zespołu. Zamiast sprzeczać się w niejasnych terminach („to pewnie model” albo „może UI”), zapisujesz opowieść na papierze.
Celem nie jest doskonała prawda; to wspólny szkic „jak myślimy, że system działa”, który każdy może krytykować.
Załóżmy, że oceniasz, czy nowy tutorial onboardingowy (T) zwiększa aktywację (A).
Typowy reflex analityczny to „kontroluj wszystkie dostępne zmienne”. W terminach DAG oznacza to przypadkowe skorygowanie za:
Z DAG decydujesz, które zmienne kontrolować, aby zablokować ścieżki confounding, a nie dlatego, że są dostępne.
Zacznij od tablicy i trzech kroków:
Nawet szkicowy DAG zbliża produkt, dane i inżynierię do tego samego pytania przyczynowego zanim zaczniesz liczyć.
Wielka zmiana w myśleniu Pearla to rozdzielenie obserwowania czegoś od zmieniania tego. Jeśli obserwujesz, że użytkownicy, którzy włączają powiadomienia, lepiej się retencyjnie zachowują, poznałeś wzorzec. Nadal nie wiesz jednak, czy powiadomienia powodują retencję, czy raczej to zaangażowani użytkownicy częściej je włączają.
Interwencja to aktywne ustawienie zmiennej na wartość i obserwacja, co się dzieje dalej. W kategoriach produktu to nie „użytkownicy wybrali X”, lecz „wypuściliśmy X”.
Pearl często rozróżnia to tak:
Pomysł „do” to mentalna notatka, że przerywasz zwykłe powody, dla których zmienna przyjmuje wartość. Gdy interweniujesz, powiadomienia nie są WŁĄCZONE, bo użytkownicy zaangażowani je wybrali; są WŁĄCZONE, bo ty wymusiłeś ustawienie. To właśnie izoluje związek przyczynowy.
Większość praktycznej pracy produktowej ma kształt interwencji:
Te działania mają na celu zmienić wyniki, nie tylko je opisać. Myślenie przyczynowe pilnuje pytania: „Jeśli to zrobimy, co się zmieni?”
Nie możesz interpretować interwencji (ani zaprojektować dobrego eksperymentu) bez założeń o tym, co na co wpływa — czyli twojego diagramu przyczynowego, nawet jeśli jest nieformalny.
Na przykład, jeśli sezonowość wpływa i na wydatki marketingowe, i na zapisy, to „zrobienie” zmiany w wydatkach bez uwzględnienia sezonowości nadal może wprowadzić w błąd. Interwencje są potężne, ale odpowiedzą na pytania przyczynowe tylko wtedy, gdy historia przyczynowa jest choćby w przybliżeniu poprawna.
Kontrafaktyczne pytanie to specyficzny rodzaj „co jeśli?”: dla tej dokładnej sprawy, co by się stało, gdybyśmy podjęli inną akcję (lub gdyby jeden input był inny)? To nie jest „co się zdarzy średnio?” — to „czy wynik zmieniłby się dla tej osoby, tego zgłoszenia, tej transakcji?”
Kontrafaktycznie pojawiają się, gdy ktoś prosi o ścieżkę do innego wyniku:
Te pytania są na poziomie użytkownika i wystarczająco konkretne, by kierować zmianami produktu, politykami i wyjaśnieniami.
Wyobraź sobie model kredytowy, który odrzuca wniosek. Wyjaśnienie oparte na korelacji może brzmieć: „Niskie oszczędności korelują z odrzuceniami.” Kontrafaktyczne pytanie brzmi:
Gdyby oszczędności wnioskodawcy były o 3 000 USD wyższe (przy zachowaniu reszty bez zmian), czy model by go zatwierdził?
Jeśli odpowiedź brzmi „tak”, masz działającą wskazówkę: realistyczna zmiana, która odwraca decyzję. Jeśli „nie”, unikniesz mylącej porady typu „zwiększ oszczędności”, gdy prawdziwą przeszkodą jest stosunek zadłużenia do dochodu lub niestabilność zatrudnienia.
Kontrafaktyki zależą od modelu przyczynowego — opowieści o tym, jak zmienne na siebie wpływają — a nie tylko od zbioru danych. Musisz zdecydować, co może realistycznie się zmienić, co zmieni się jako konsekwencja i co musi pozostać stałe. Bez tej struktury kontrfakty mogą prowadzić do nierealnych scenariuszy („zwiększyć oszczędności bez zmiany dochodu lub wydatków”) i dawać bezużyteczne lub niesprawiedliwe rekomendacje.
Gdy model ML zawodzi w produkcji, rzadko przyczyną jest „algorytm się zepsuł”. Częściej coś w systemie się zmieniło: co zbierasz, jak powstają etykiety lub jak użytkownicy się zachowują. Myślenie przyczynowe pomaga przestać zgadywać i zacząć izolować, która zmiana spowodowała degradację.
Kilka powtarzających się przyczyn pojawia się we wszystkich zespołach:
Te problemy mogą wyglądać „w porządku” w dashboardach, bo korelacja może pozostać wysoka, nawet gdy powód, dla którego model miał rację, się zmienił.
Prosty diagram przyczynowy (DAG) zmienia debugowanie w mapę. Zmusza do pytania: czy ta cecha jest przyczyną etykiety, konsekwencją etykiety, czy konsekwencją sposobu mierzenia jej?
Na przykład, jeśli polityka etykietowania → inżynieria cech → wejścia modelu, mogłeś stworzyć pipeline, gdzie model przewiduje politykę, a nie zjawisko leżące u podstaw. DAG ujawnia tę ścieżkę, więc możesz ją zablokować (usunąć cechę, zmienić instrumentację lub przedefiniować etykietę).
Zamiast tylko analizować predykcje, przeprowadź kontrolowane interwencje:
Wiele narzędzi do wyjaśniania odpowiada na wąskie pytanie: dlaczego model dał ten wynik? Często robią to przez pokazanie wpływowych wejść (ważność cech, mapy saliency). To może być użyteczne — ale to nie to samo, co wyjaśnienie systemu, w którym model działa.
Wyjaśnienie predykcji jest lokalne i opisowe: „Ten wniosek kredytowy odrzucono głównie z powodu niskich dochodów i wysokiego wykorzystania linii kredytowej.”
Wyjaśnienie systemowe jest przyczynowe i operacyjne: „Jeśli zwiększymy zweryfikowany dochód (lub zmniejszymy wykorzystanie), w sposób odpowiadający realnej interwencji, czy decyzja się zmieni — i czy rezultaty downstream się poprawią?”
Pierwsze pomaga interpretować model. Drugie pomaga zdecydować, co zrobić.
Myślenie przyczynowe łączy wyjaśnienia z interwencjami. Zamiast pytać, które zmienne korelują z wynikiem, pytasz, które zmienne są prawidłowymi dźwigniami i jakie efekty dadzą po ich zmianie.
Model przyczynowy wymusza jawność co do:
To ma znaczenie, ponieważ „ważna cecha” może być proxy — przydatna do predykcji, niebezpieczna przy akcji.
Post-hoc wyjaśnienia mogą być przekonujące i jednocześnie pozostać czysto korelacyjne. Jeśli „liczba zgłoszeń do wsparcia” silnie przewiduje churn, wykres ważności cech może skłonić zespół do „zmniejszenia liczby zgłoszeń” przez utrudnienie kontaktu ze wsparciem. Taka interwencja może zwiększyć churn, bo zgłoszenia były objawem podstawowych problemów produktowych — a nie ich przyczyną.
Wyjaśnienia oparte na korelacjach są też kruche podczas zmian rozkładów: gdy zachowanie użytkowników się zmieni, te same cechy mogą już nic nie znaczyć.
Wyjaśnienia przyczynowe są szczególnie wartościowe, gdy decyzje mają konsekwencje i wymagają rozliczalności:
Gdy trzeba działać, nie tylko interpretować, wyjaśnienie potrzebuje przyczynowego kręgosłupa.
Testy A/B to w praktyce najprostsza forma inferencji przyczynowej. Gdy losowo przypisujesz użytkowników do wariantu A lub B, przeprowadzasz interwencję: nie obserwujesz tylko wyborów użytkowników, lecz ustawiasz, co widzą. W terminach Pearla randomizacja urzeczywistnia „do(variant = B)” — więc różnice w wynikach można wiarygodnie przypisać zmianie, a nie temu, kto ją zobaczył.
Losowe przypisanie przerywa wiele ukrytych związków między cechami użytkowników a ekspozycją. Power userzy, nowi użytkownicy, pora dnia, typ urządzenia — te czynniki nadal istnieją, ale (średnio) są zbalansowane między grupami. To równoważenie przekształca różnicę metryk w twierdzenie przyczynowe.
Nawet świetne zespoły nie zawsze mogą przeprowadzić czyste randomizowane testy:
W takich przypadkach nadal możesz myśleć przyczynowo — trzeba jednak jawnie formułować założenia i niepewność.
Popularne opcje to difference-in-differences (porównanie zmian w czasie między grupami), regression discontinuity (użycie reguły progowej, np. „tylko użytkownicy powyżej wyniku X”), instrumental variables (naturalny impuls, który zmienia ekspozycję bez bezpośredniego wpływu na wynik) oraz matching/weighting by uczynić grupy porównywalnymi. Każda metoda zamienia randomizację na założenia; diagram przyczynowy pomoże jasno je sformułować.
Przed uruchomieniem testu (lub badania obserwacyjnego) zapisz: główną metrykę, zabezpieczenia, populację docelową, czas trwania i regułę decyzyjną. Preregistracja nie wyeliminuje biasu, ale redukuje selekcję metryk i ułatwia zaufanie do roszczeń przyczynowych — oraz dyskusję w zespole.
Większość debat produktowych brzmi: „Metryka X ruszyła po wdrożeniu Y — więc Y zadziałało.” Myślenie przyczynowe zmienia to na jaśniejsze pytanie: „Czy zmiana Y spowodowała ruch metryki X i o ile?” Ta zmiana zamienia dashboardy z dowodu w punkt wyjścia.
Zmiana ceny: zamiast „Czy przychody wzrosły po podwyżce?”, zapytaj:
Modyfikacja onboardingu: zamiast „Nowi użytkownicy częściej kończą onboarding”, zapytaj:
Zmiana rankingu rekomendacji: zamiast „CTR się poprawił”, zapytaj:
Dashboardy często mieszają „kto dostał zmianę” z „kto i tak by sobie poradził”. Klasyczny przykład: wypuszczasz nowy flow onboardingu, ale najpierw widzą go użytkownicy z najnowszą wersją aplikacji. Jeśli nowsze wersje przyjmują bardziej zaangażowani użytkownicy, wykres może pokazywać wzrost będący w dużej mierze (lub całkowicie) efektem adopcji wersji, a nie onboardingu.
Inne częste confoundery w analityce produktowej:
Przydatna sekcja PRD może mieć tytuł „Pytania przyczynowe” i zawierać:
Jeśli pracujesz w szybkim cyklu build (zwłaszcza z pomocą LLM), ta sekcja jest jeszcze ważniejsza: chroni przed „zrobimy to szybko” kończąc na „wdrożyliśmy bez wiedzy, co spowodowaliśmy”. Zespoły używające Koder.ai często wbudowują te pytania przy planowaniu, potem szybko uruchamiają warianty z feature flagami i snapshotami/rollbackem, żeby eksperymentować bezpiecznie, gdy wyniki (lub skutki uboczne) zaskoczą.
PM definiuje decyzję i kryteria sukcesu. Zespół danych przekłada to na mierzalne estymaty przyczynowe i kontrole sanity. Inżynieria zapewnia, że zmiana jest kontrolowalna (feature flagi, czyste logowanie ekspozycji). Wsparcie dzieli jakościowe sygnały — zmiany cen często „działają”, jednocześnie cicho zwiększając rezygnacje lub obciążenie ticketów. Gdy wszyscy zgadzają się co do pytania przyczynowego, wdrożenie staje się nauką, a nie tylko wypuszczeniem.
Korelacja pomaga przewidywać lub wykrywać (np. „gdy X rośnie, Y często też rośnie”). Przyczynowość odpowiada na pytanie decyzyjne: „Jeśli celowo zmienimy X, czy Y się zmieni?”
Używaj korelacji do prognozowania i monitoringu; stosuj myślenie przyczynowe, gdy masz zamiar wdrożyć zmianę, ustalić politykę lub przydzielić budżet.
Bo korelacja może wynikać z czynników zakłócających. W przykładzie z powiadomieniami bardzo zaangażowani użytkownicy zarówno generują/otrzymują więcej powiadomień, jak i częściej wracają.
Jeśli zwiększysz liczbę powiadomień dla wszystkich, dokonujesz interwencji bez zmiany podstawowego poziomu zaangażowania — więc retencja może się nie poprawić, a doświadczenie użytkownika pogorszyć.
DAG (Directed Acyclic Graph) to prosty diagram, w którym:
Przydaje się, bo ujawnia założenia i pomaga zespołowi ustalić, co należy skontrolować, czego nie należy kontrolować i który eksperyment rzeczywiście odpowie na pytanie.
Częsty błąd to „kontroluj wszystko”, co może przypadkowo skorygować mediatory lub collidery i wprowadzić błąd.
„See” to obserwowanie, co naturalnie się wydarzyło (użytkownicy zapisali się, wynik był wysoki). „Do” to aktywne ustawienie zmiennej (wypuszczenie funkcji, wymuszenie domyślnej opcji).
Klucz: interwencja łamiе zwykłe powody, dla których zmienna przyjmuje wartość, dlatego lepiej ujawnia związek przyczynowo-skutkowy niż sama obserwacja.
Kontrafaktyczne pytanie brzmi: dla tej konkretnej sprawy, co by się stało, gdybyśmy zrobili coś innego.
Przydatne do:
Wymaga modelu przyczynowego, aby nie proponować nierealistycznych zmian.
Skoncentruj się na tym, co zmieniło się u źródła i co model mógł wykorzystać:
Myślenie przyczynowe skłania do testowania ukierunkowanych interwencji (ablacje, perturbacje) zamiast gonienia za przypadkową korelacją metryk.
Może i pomaga. Ważne jednak, że ważność cechy tłumaczy dlaczego model tak zadecydował, a nie co powinniśmy zmienić.
Cechy „ważne” mogą być proxy lub symptomem (np. liczba zgłoszeń do wsparcia przewiduje churn). Interwencja na proxy („utrudnić kontakt ze wsparciem, aby mniej zgłoszeń”) może pogorszyć sprawę. Wyjaśnienia przyczynowe łączą ważność z rzeczywistymi dźwigniami i oczekiwanymi efektami interwencji.
Testy A/B są najlepsze, gdy można je przeprowadzić, bo randomizacja tworzy rzeczywiste „do(variant = B)”. Jednak mogą być trudne, gdy:
W takich przypadkach rozważ quasi-eksperymenty (difference-in-differences, regression discontinuity, instrumental variables, matching), zawsze jawnie opisując założenia.
Dodaj krótką sekcję, która wymusza jasność przed analizą:
To pomaga zespołowi skupiać się na pytaniu przyczynowym, zamiast opowieści po fakcie z dashboardu.
