14 jul 2025·8 min
Causaal denken van Judea Pearl: betere AI, debugging en beslissingen
Leer hoe Judea Pearl’s causale modellen teams helpen AI-gedrag te verklaren, fouten te debuggen en duidelijkere productbeslissingen te nemen voorbij correlaties.
Leer hoe Judea Pearl’s causale modellen teams helpen AI-gedrag te verklaren, fouten te debuggen en duidelijkere productbeslissingen te nemen voorbij correlaties.
Een team ziet iets “duidelijks” in hun dashboard: gebruikers die meer notificaties ontvangen komen vaker terug. Dus zetten ze het notificatievolume omhoog. Een week later daalt retentie en nemen klachten toe. Wat gebeurde er?
Het oorspronkelijke patroon was echt—maar misleidend. De meest betrokken gebruikers triggeren van nature meer notificaties (omdat ze het product meer gebruiken) en komen ook vaker terug. Notificaties veroorzaakten de retentie niet; betrokkenheid veroorzaakte beide. Het team handelde op basis van correlatie en maakte per ongeluk een slechtere ervaring.
Causaal denken is de gewoonte om te vragen: wat veroorzaakt wat, en hoe weten we dat? In plaats van te stoppen bij “deze twee dingen bewegen samen,” probeer je te scheiden:
Het gaat niet om wantrouwen van data, maar om specifieker formuleren van de vraag. “Correleren notificaties met retentie?” is anders dan “Zal het vaker sturen van notificaties de retentie verhogen?” De tweede vraag is causaal.
Dit artikel richt zich op drie praktische gebieden waar patroonherkenning vaak faalt:
Dit is geen wiskundige rondleiding door causale inferentie. Je hoeft geen do-calculus notatie te leren om hier waarde uit te halen. Het doel is een set mentale modellen en een workflow die je team kan gebruiken om:
Als je ooit een verandering hebt uitgerold die “er goed uitzag in de data” maar in de praktijk faalde, is causaal denken de ontbrekende schakel.
Judea Pearl is een computerwetenschapper en filosoof van de wetenschap wiens werk de manier waarop veel teams over data, AI en besluitvorming denken heeft veranderd. Voor zijn causale revolutie lag veel van “leren van data” in de informatica op statistische associaties: vind patronen, pas modellen toe, voorspel wat er gebeurt. Die aanpak is krachtig—maar faalt vaak zodra je een product- of engineeringvraag stelt die het woord omdat bevat.
Pearl’s kernverschuiving was om causaliteit als een eersteklas concept te behandelen, niet als een vage intuïtie bovenop correlaties. In plaats van alleen te vragen “als X hoog is, is Y dan ook hoog?”, vraagt causaal denken “als we X veranderen, zal Y dan veranderen?” Dat verschil klinkt klein, maar scheidt voorspelling van besluitvorming.
Associatie beantwoordt “wat neigt samen voor te komen.” Causatie probeert te beantwoorden “wat zou er gebeuren als we interveniëren.” Dit is belangrijk in computing omdat veel echte beslissingen interventies zijn: een feature uitrollen, rankings veranderen, een guardrail toevoegen, een trainingsset aanpassen, of een beleid bijstellen.
Pearl maakte causaliteit praktischer door het te framen als een modelleringskeuze plus expliciete aannames. Je “ontdekt” causaliteit niet zomaar uit data; je stelt een causaal verhaal voor (vaak gebaseerd op domeinkennis) en gebruikt dan data om het te testen, te schatten en te verfijnen.
Deze tools gaven teams een gedeelde taal om van patroonherkenning naar het beantwoorden van causale vragen te gaan met helderheid en discipline.
Correlatie betekent dat twee dingen samen bewegen: als het ene stijgt, neigt het andere ook te stijgen (of te dalen). Het is buitengewoon nuttig—vooral in datarijke teams—omdat het helpt bij voorspelling en detectie.
Als ijsverkoop stijgt wanneer de temperatuur stijgt, kan een gecorreleerd signaal (temperatuur) forecasting verbeteren. In product- en AI-werk voeden correlaties rankingmodellen (“toon meer van wat vergelijkbare gebruikers klikten”), anomaly detection (“deze metric volgt normaal gesproken die andere”) en snelle diagnostiek (“fouten stijgen als latency stijgt”).
Het probleem begint wanneer we correlatie behandelen als antwoord op een andere vraag: wat gebeurt er als we iets opzettelijk veranderen? Dat is causaliteit.
Een gecorreleerde relatie kan gedreven worden door een derde factor die beide variabelen beïnvloedt. X veranderen verandert Y niet per se—omdat X misschien niet de reden is dat Y oorspronkelijk veranderde.
Stel dat je wekelijkse marketinguitgaven plot tegen wekelijkse sales en een sterke positieve correlatie ziet. Het is verleidelijk om te concluderen “meer uitgaven veroorzaken meer verkopen.”
Maar stel dat beide stijgen tijdens feestdagen. Het seizoen (een confounder) drijft hogere vraag en activeert grotere budgetten. Als je in een niet-feestweek meer uitgeeft, stijgen de sales misschien niet veel—omdat de onderliggende vraag er niet is.
Je zit in causaal terrein wanneer je jezelf hoort vragen:
Als het werkwoord veranderen, lanceren, verwijderen of verminderen is, is correlatie een startpunt—geen beslissingsregel.
Een causaal diagram—vaak getekend als een DAG (Directed Acyclic Graph)—is een eenvoudige manier om de aannames van een team zichtbaar te maken. In plaats van vaag te discussiëren (“het is waarschijnlijk het model” of “misschien de UI”), zet je het verhaal op papier.
Het doel is geen perfecte waarheid; het is een gedeeld concept van “hoe we denken dat het systeem werkt” dat iedereen kan bekritiseren.
Stel dat je evalueert of een nieuwe onboarding-tutorial (T) de activatie (A) verhoogt.
Een gebruikelijke analytics-reflex is “controleer alle beschikbare variabelen.” In DAG-termen kan dat betekenen dat je per ongeluk corrigeert voor:
Met een DAG pas je aan voor variabelen met een reden—typisch om confounding paden te blokkeren—niet omdat ze beschikbaar zijn.
Begin met een whiteboard en drie stappen:
Zelfs een ruwe DAG brengt product, data en engineering op één lijn rond dezelfde causale vraag voordat je cijfers draait.
Een grote verschuiving in Judea Pearl’s causale denken is het scheiden van observeren en veranderen.
Als je observeert dat gebruikers die notificaties inschakelen beter behouden worden, heb je een patroon geleerd. Maar je weet nog niet of notificaties retentie veroorzaken, of dat betrokken gebruikers gewoon vaker opt-innen.
Een interventie is anders: je stelt actief een variabele in en kijkt wat er daarna gebeurt. In producttermen is dat niet “gebruikers kozen X,” maar “wij brachten X uit.”
Pearl labelt dit vaak als:
Het “do”-idee is een mentale notitie dat je de gebruikelijke redenen waarom een variabele die waarde heeft doorbreekt. Wanneer je intervenieert, zijn notificaties niet AAN omdat betrokken gebruikers kozen; ze zijn AAN omdat jij de instelling forceert of nudges. Dat is het punt: interventies helpen oorzaak-en-gevolg te isoleren.
De meeste productwerkzaamheden zijn interventievormig:
Deze acties hebben tot doel uitkomsten te veranderen, niet alleen te beschrijven. Causaal denken houdt de vraag eerlijk: “Als we dit doen, wat verandert er?”
Je kunt een interventie (of een goed experiment) niet interpreteren zonder aannames over wat wat beïnvloedt—je causale diagram, zelfs als het informeel is.
Bijvoorbeeld: als seizoensinvloeden zowel marketinguitgaven als aanmeldingen beïnvloeden, kan het veranderen van uitgaven zonder rekening te houden met seizoen nog steeds misleiden. Interventies zijn krachtig, maar beantwoorden alleen causale vragen wanneer het onderliggende causale verhaal min of meer klopt.
Een tegenfeitelijke vraag is een specifiek soort “wat als?”: voor dit exacte geval, wat zou er gebeurd zijn als we iets anders hadden gedaan (of als een invoer anders was geweest)? Het is niet “wat gebeurt er gemiddeld?”—het is “zou deze uitkomst voor deze persoon, dit ticket, deze transactie veranderd zijn?”
Tegenfeiten komen voor wanneer iemand een pad naar een andere uitkomst wil weten:
Deze vragen zijn gebruikersniveau en concreet genoeg om productwijzigingen, policies en verklaringen te sturen.
Stel een leningmodel wijst een aanvraag af. Een correlatie-gebaseerde verklaring kan zeggen: “Lage spaargelden correleren met afwijzing.” Een tegenfeitelijke vraag is:
Als de spaargelden van de aanvrager $3.000 hoger waren geweest (en verder alles gelijk), zou het model dan goedkeuren?
Als het antwoord “ja” is, leer je iets actiebaars: een plausibele wijziging die de beslissing omkeert. Als het antwoord “nee” is, voorkom je misleidend advies zoals “verhoog je spaargeld” wanneer de echte blokkade schuld-inkomensratio of instabiel werk is.
Tegenfeiten hangen af van een causaal model—een verhaal over hoe variabelen elkaar beïnvloeden—niet alleen van een dataset. Je moet beslissen wat realistisch kan veranderen, wat daardoor als consequentie verandert, en wat vast moet blijven. Zonder die causale structuur kunnen tegenfeiten onmogelijke scenario’s worden (“spaargeld verhogen zonder inkomen of uitgaven te veranderen”) en onbruikbare of oneerlijke aanbevelingen opleveren.
Wanneer een ML-model in productie faalt, is de root cause zelden “het algoritme ging achteruit.” Vaak is er iets in het systeem veranderd: wat je verzamelt, hoe labels ontstaan, of wat gebruikers doen. Causaal denken helpt je op te houden met raden en te beginnen met isoleren welke verandering de degradatie veroorzaakte.
Een paar terugkerende boosdoeners bij teams:
Deze situaties kunnen er in aggregate dashboards “oké” uitzien omdat correlatie hoog kan blijven, ook al is de reden dat het model correct is veranderd.
Een simpel causaal diagram (DAG) verandert debugging in een kaart. Het dwingt je te vragen: is deze feature een oorzaak van het label, een gevolg ervan, of een gevolg van hoe we het meten?
Bijvoorbeeld: als Labeling policy → Feature engineering → Model inputs, heb je mogelijk een pipeline gebouwd waarin het model het beleid voorspelt in plaats van het onderliggende fenomeen. Een DAG maakt dat pad zichtbaar zodat je het kunt blokkeren (feature verwijderen, instrumentatie aanpassen of het label herdefiniëren).
In plaats van alleen voorspellingen te inspecteren, probeer gecontroleerde interventies:
Veel “explainability”-tools beantwoorden een smalle vraag: waarom gaf het model deze score? Ze doen dat vaak door invloedrijke inputs te benadrukken (feature importance, saliency maps, SHAP-waarden). Dat kan nuttig zijn—maar het is niet hetzelfde als het verklaren van het systeem waarin het model zit.
Een voorspelling-uitleg is lokaal en beschrijvend: “Deze lening werd afgewezen vooral vanwege laag inkomen en hoge benutting.”
Een systeem-uitleg is causaal en operationeel: “Als we het geverifieerde inkomen verhogen (of benutting verlagen) op een manier die een echte interventie weerspiegelt, zou de beslissing dan veranderen—en zouden downstream uitkomsten verbeteren?”
De eerste helpt je modelgedrag te interpreteren. De tweede helpt je beslissen wat te doen.
Causaal denken koppelt verklaringen aan interventies. In plaats van te vragen welke variabelen correleren met de score, vraag je welke variabelen geldige hefbomen zijn en welke effecten ze produceren wanneer ze veranderen.
Een causaal model dwingt je expliciet te zijn over:
Dit is belangrijk omdat een “belangrijke feature” een proxy kan zijn—bruikbaar voor voorspelling, gevaarlijk voor actie.
Post-hoc verklaringen kunnen overtuigend lijken maar puur correlationeel blijven. Als “aantal supporttickets” sterk churn voorspelt, kan een feature-importance plot een team verleiden om “tickets verminderen” door support moeilijker bereikbaar te maken. Die interventie kan juist churn vergroten, omdat tickets een symptoom waren van onderliggende productproblemen—niet de oorzaak.
Correlatie-gebaseerde verklaringen zijn ook kwetsbaar bij distributionele veranderingen: zodra gebruikersgedrag verandert, betekenen dezelfde gemarkeerde features niet meer hetzelfde.
Causale verklaringen zijn vooral waardevol wanneer beslissingen consequenties en verantwoording hebben:
Als je moet handelen, niet alleen interpreteren, heeft een verklaring een causale ruggengraat nodig.
A/B-testen is causale inferentie in zijn eenvoudigste, meest praktische vorm. Wanneer je gebruikers willekeurig toewijst aan variant A of B, voer je een interventie uit: je observeert niet alleen wat mensen kozen, je zet wat ze zien. In Pearls termen maakt randomisatie “do(variant = B)” echt—dus verschillen in uitkomsten kunnen met recht aan de verandering toegeschreven worden, niet aan wie er toevallig voor koos.
Willekeurige toewijzing doorbreekt veel verborgen verbanden tussen gebruikerseigenschappen en blootstelling. Power users, nieuwe gebruikers, tijd van de dag, apparaat—deze factoren blijven bestaan, maar zijn (gemiddeld) gebalanceerd over groepen. Die balans verandert een metriekverschil in een causale claim.
Zelfs sterke teams kunnen niet altijd nette gerandomiseerde tests uitvoeren:
In die gevallen kun je nog steeds causaal denken—je moet dan expliciet zijn over aannames en onzekerheid.
Veelgebruikte opties zijn difference-in-differences (vergelijk veranderingen over tijd tussen groepen), regression discontinuity (gebruik een afkappuntregel zoals “alleen gebruikers boven score X”), instrumentele variabelen (een natuurlijke duwtje dat blootstelling verandert zonder direct de uitkomst te veranderen), en matching/weighting om groepen vergelijkbaarder te maken. Elke methode ruilt randomisatie in voor aannames; een causaal diagram helpt die aannames duidelijk te formuleren.
Voordat je een test (of observationele studie) start, schrijf op: de primaire metric, guardrails, doelgroep, duur en beslisregel. Pre-registratie elimineert geen bias, maar vermindert metric shopping en maakt causale claims geloofwaardiger—en makkelijker om als team te bediscussiëren.
De meeste productdebatten klinken als: “Metric X bewoog nadat we Y uitrolden—dus Y werkte.” Causaal denken scherpt dat aan tot een duidelijke vraag: “Heeft verandering Y ervoor gezorgd dat metric X bewoog, en hoeveel?” Die verschuiving maakt dashboards van bewijs tot startpunt.
Prijsaanpassing: in plaats van “ging de omzet omhoog na de prijsverhoging?”, vraag:
Onboarding wijziging: in plaats van “nieuwe gebruikers maken nu vaker onboarding af,” vraag:
Aanbevelingsranking wijziging: in plaats van “CTR verbeterde,” vraag:
Dashboards mengen vaak “wie de verandering kreeg” met “wie het toch goed had gedaan.” Een klassiek voorbeeld: je rolt een nieuwe onboardingflow uit, maar die wordt eerst aan gebruikers met de nieuwste appversie getoond. Als nieuwere versies sneller door betrokken gebruikers geadopteerd worden, toont je grafiek mogelijk een lift die deels (of volledig) versie-adoptie is, niet onboarding.
Andere veelvoorkomende confounders in productanalyse:
Een nuttige PRD-sectie heet letterlijk “Causale vragen,” en bevat:
Als je een snel bouw‑loop gebruikt (vooral met LLM-ondersteunde ontwikkeling), wordt deze sectie nog belangrijker: het voorkomt dat “we kunnen het snel uitrollen” verandert in “we rolden het uit zonder te weten wat het veroorzaakte.” Teams die in Koder.ai bouwen, verwerken deze causale vragen vaak al in de planningsfase en implementeren snel feature-flagged varianten, met snapshots/rollback om experimentatie veilig te houden wanneer resultaten (of neveneffecten) verrassen.
PMs definiëren de beslissing en succescriteria. Data-partners vertalen dat naar meetbare causale schattingen en sanity checks. Engineering zorgt dat de verandering bestuurbaar is (feature flags, schone exposure logging). Support deelt kwalitatieve signalen—prijswijzigingen “werken” vaak terwijl ze stilletjes annuleringen of tickets verhogen. Als iedereen het eens is over de causale vraag, wordt uitrollen leren—niet alleen uitrollen.
Causaal denken vereist geen PhD-implementatie. Behandel het als een teamgewoonte: schrijf je causale verhaal op, test het, en laat data (en experimenten waar mogelijk) het bevestigen of corrigeren.
Om vooruitgang te boeken, verzamel vier inputs vooraf:
In de praktijk telt snelheid: hoe sneller je een causale vraag in een gecontroleerde verandering kunt omzetten, hoe minder tijd je besteedt aan discussies over ambiguë patronen. Daarom gebruiken teams platforms zoals Koder.ai om van “hypothese + plan” naar een werkende, geïinstrumenteerde implementatie (web, backend of mobiel) te gaan in dagen in plaats van weken—met behoud van rigueur via gefaseerde rollouts, deployments en rollback.
Als je een opfrisser over experimenten wilt, zie /blog/ab-testing-basics. Voor veelvoorkomende valkuilen in productmetrics die “effecten” nadoen, zie /blog/metrics-that-mislead.
Causaal denken is een verschuiving van “wat neigt samen te bewegen?” naar “wat zou veranderen als we ingrepen?” Die verschuiving—gepopulairiseerd in computing en statistiek door Judea Pearl—helpt teams zelfverzekerde verhalen te vermijden die niet bestand zijn tegen echte interventies.
Correlatie is een aanwijzing, geen antwoord.
Causale diagrammen (DAGs) maken aannames zichtbaar en bespreekbaar.
Interventies (“do”) verschillen van observaties (“see”).
Tegenfeiten helpen individuele gevallen te verklaren: “wat als dit ene ding anders was geweest?”
Goed causaal werk documenteert onzekerheid en alternatieve verklaringen.
Causaliteit vraagt zorg: verborgen confounders, meetfouten en selectie-effecten kunnen conclusies omkeren. Het tegengif is transparantie—schrijf aannames op, toon welke data je gebruikte en noteer wat je claim zou falsifiëren.
Als je dieper wilt duiken, blader dan door gerelateerde artikelen op /blog en vergelijk causale benaderingen met andere analytics- en “explainability”-methoden om te zien waar elk helpt—en waar het kan misleiden.
Correlatie helpt je voorspellen of detecteren (bijv. “als X stijgt, stijgt Y vaak ook”). Causaliteit beantwoordt een beslissingsvraag: “Als we X opzettelijk veranderen, zal Y dan veranderen?”
Gebruik correlatie voor forecasting en monitoring; gebruik causaal denken wanneer je iets gaat uitrollen, een beleid vaststelt of budget toewijst.
Omdat de correlatie mogelijk wordt veroorzaakt door confounding. In het notificatievoorbeeld triggeren zeer betrokken gebruikers zowel meer notificaties als hogere terugkeer.
Als je notificaties voor iedereen verhoogt, verander je de ervaring (een interventie) zonder de onderliggende betrokkenheid te veranderen — dus retention verbetert misschien niet en kan verslechteren.
Een DAG (Directed Acyclic Graph) is een simpel diagram waarin:
Het is nuttig omdat het aannames expliciet maakt, zodat teams kunnen afspreken waarvoor te corrigeren, wat niet te corrigeren, en welk experiment echt de vraag beantwoordt.
Een veelgemaakte fout is “voor alles controleren”, wat per ongeluk kan corrigeren voor mediators of colliders en zo bias introduceren.
“See” is observeren wat natuurlijk gebeurde (gebruikers schreven zich in, een score was hoog). “Do” is actief een variabele instellen (een feature uitrollen, een default forceren).
Het idee: een interventie breekt de gebruikelijke redenen waarom een variabele een bepaalde waarde heeft, daarom kan het oorzaak-en-gevolg betrouwbaarder laten zien dan enkel observatie.
Een tegenfeitelijke vraag vraagt: voor dit specifieke geval, wat zou er gebeurd zijn als we iets anders hadden gedaan.
Het is nuttig voor:
Het vereist een causaal model zodat je geen onmogelijke veranderingen voorstelt.
Richt je op wat er upstream veranderde en wat het model mogelijk exploiteert:
Een causale mindset stimuleert gerichte interventies (ablations, perturbaties) in plaats van het najagen van toevallige metriekbewegingen.
Niet per se. Feature-importance legt uit wat de voorspelling beïnvloedde, niet wat je zou moeten veranderen.
Een “belangrijke” feature kan een proxy of symptoom zijn (bijv. support tickets voorspellen churn). Interveniëren op de proxy (“minder tickets door support minder toegankelijk te maken”) kan averechts werken. Causale verklaringen koppelen belang aan geldige hefbomen en verwachte effecten onder interventie.
Randomized A/B-tests zijn het beste wanneer mogelijk, maar soms heb je alternatieven nodig als:
In die gevallen, overweeg quasi-experimenten zoals difference-in-differences, regression discontinuity, instrumentele variabelen of matching/weighting — en wees expliciet over de aannames.
Voeg een korte sectie toe die duidelijkheid afdwingt voordat je analyseert:
Dit houdt het team gefocust op een causale vraag in plaats van op post-hoc dashboardverhalen.