14 juli 2025·8 min
Judea Pearl och kausalt tänkande: bättre AI, felsökning och beslut
Lär dig hur Judea Pearls kausala modeller hjälper team att förklara AI-beteende, felsöka fel och fatta tydligare produktbeslut bortom korrelationer.
Lär dig hur Judea Pearls kausala modeller hjälper team att förklara AI-beteende, felsöka fel och fatta tydligare produktbeslut bortom korrelationer.
Ett team noterar något "uppenbart" i sin dashboard: användare som får fler notiser kommer tillbaka oftare. Så de ökar notismängden. En vecka senare sjunker retention och klagomålen om churn ökar. Vad hände?
Det ursprungliga mönstret var verkligt — men missvisande. De mest engagerade användarna triggar naturligt fler notiser (eftersom de använder produkten mer) och de återvänder också oftare. Notiser orsakade inte retention; engagemang orsakade båda. Teamet agerade på korrelation och skapade av misstag en sämre upplevelse.
Kausalt tänkande är vanan att fråga: vad orsakar vad, och hur vet vi det? Istället för att stanna vid “de här två sakerna rör sig tillsammans” försöker du skilja på:
Det handlar inte om att vara skeptisk till data — det handlar om att vara specifik med frågan. "Korresponderar notiser med retention?" är något annat än "Kommer fler notiser göra att retention ökar?" Den andra frågan är kausal.
Den här texten fokuserar på tre praktiska områden där mönstersökning ofta misslyckas:
Det här är ingen mattetung genomgång av kausal inferens. Du behöver inte lära dig do-calculus-notation för att få värde här. Målet är en uppsättning mental modeller och ett arbetsflöde ditt team kan använda för att:
Om du någonsin levererat en förändring som "såg bra ut i datan" men inte fungerade i verkligheten, är kausalt tänkande den saknade länken.
Judea Pearl är en datavetare och vetenskapsfilosof vars arbete omlokaliserade hur många team tänker om data, AI och beslutstagande. Före hans kausala revolution fokuserade mycket av "lärande från data" i datavetenskap på statistiska associationer: hitta mönster, anpassa modeller, förutsäga vad som händer härnäst. Den metoden är kraftfull — men den fallerar ofta när du ställer en produkt- eller ingenjörsfråga som innehåller ordet eftersom.
Pearls centrala skifte var att behandla kausalitet som ett förstklassigt begrepp, inte en vag intuition ovanpå korrelationer. Istället för att bara fråga "När X är hög, är Y också hög?", frågar kausalt tänkande: "Om vi ändrar X, kommer Y att förändras?" Den skillnaden låter liten, men den skiljer prediktion från beslutsfattande.
Association svarar på "vad tenderar att inträffa tillsammans". Kausation försöker svara på "vad skulle hända om vi ingriper". Det spelar roll i datavetenskap eftersom många verkliga beslut är interventioner: släppa en funktion, ändra ranking, lägga till en skyddsmekanism, ändra ett träningsset eller justera en policy.
Pearl gjorde kausalitet mer praktiskt genom att rama in det som ett modellval plus explicita antaganden. Du "upptäcker" inte kausalitet automatiskt från data i allmänhet; du föreslår en kausal historia (ofta baserad på domänkunskap) och använder sedan data för att testa, estimera och förfina den.
Dessa verktyg gav team ett gemensamt språk för att gå från mönstersökning till att svara kausala frågor med tydlighet och disciplin.
Korrelation betyder att två saker rör sig tillsammans: när den ena går upp tenderar den andra att gå upp (eller ner). Det är extremt användbart — särskilt i datarika team — eftersom det hjälper med förutsägelse och upptäckt.
Om glassförsäljningen ökar när temperaturen stiger kan en korrelerad signal (temperatur) förbättra prognoserna. Inom produkt- och AI-arbete driver korrelationer modeller för ranking ("visa mer av vad liknande användare klickade"), avvikelsedetektion ("den här metrisen brukar följa den andra") och snabba diagnoser ("fel ökar när latens ökar").
Problemet börjar när vi behandlar korrelation som ett svar på en annan fråga: vad händer om vi ändrar något med avsikt? Det är kausalitet.
En korrelerad relation kan drivas av en tredje faktor som påverkar båda variablerna. Att ändra X förändrar inte nödvändigtvis Y — eftersom X kanske inte var anledningen till att Y rörde sig från början.
Föreställ dig att du plottar veckovis marknadsföringskostnad mot veckovis försäljning och ser en stark positiv korrelation. Det är frestande att dra slutsatsen "mer reklam orsakar mer försäljning."
Men anta att båda stiger under helgdagar. Säsongen (en störfaktor) driver högre efterfrågan och triggar också större budgetar. Om du ökar spend i en icke-helgvecka kanske försäljningen inte stiger mycket — eftersom den underliggande efterfrågan inte finns där.
Du är i kausal-territorium när du hör dig själv fråga:
När verbet är ändra, lansera, ta bort eller minska är korrelation en ledtråd — inte beslutsregeln.
Ett kausalt diagram — ofta ritat som en DAG (Directed Acyclic Graph) — är ett enkelt sätt att synliggöra ett teams antaganden. Istället för att argumentera i vaga termer ("det är nog modellen" eller "kanske UI:t"), lägger du historien på papper.
Målet är inte perfekt sanning; det är ett gemensamt utkast till "hur vi tror systemet fungerar" som alla kan kritisera.
Anta att ni utvärderar om en ny onboardingtutorial (T) ökar aktivering (A).
En vanlig analysreflex är att "kontrollera för alla tillgängliga variabler." I DAG-termer kan det betyda att du av misstag justerar för:
Med en DAG justerar du för variabler av en anledning — typiskt för att blockera confounding-vägar — istället för bara för att de finns.
Börja med en whiteboard och tre steg:
Även en grov DAG får produkt, data och engineering att tala samma språk kring samma kausala fråga innan ni kör siffror.
Ett stort skifte i Judea Pearls kausala tänkande är att separera observera något från förändra det.
Om du observerar att användare som aktiverar notiser behåller bättre, har du lärt dig ett mönster. Men du vet fortfarande inte om notiser orsakar retention, eller om engagerade användare helt enkelt är mer benägna att slå på notiser.
En intervention är annorlunda: det betyder att du aktivt sätter en variabel till ett värde och ser vad som händer efteråt. I produkttermer är det inte "användarna valde X", det är "vi släppte X."
Pearl etiketterar ofta skillnaden som:
"Do"-idén är i grunden en mental markering att du bryter de vanliga skälen till att en variabel får ett värde. När du ingriper är notiser PÅ inte för att engagerade användare valde det; de är PÅ för att du tvingade inställningen eller förledde användaren. Det isolerar orsak och verkan.
Det mesta riktiga produktarbete är interventionsformat:
Dessa åtgärder syftar till att ändra utfall, inte bara beskriva dem. Kausalt tänkande håller frågan ärlig: "Om vi gör detta, vad kommer att förändras?"
Du kan inte tolka en intervention (eller ens designa ett bra experiment) utan antaganden om vad som påverkar vad — din kausala diagram, även om den är informell.
Till exempel, om säsong påverkar både marknadsförings- och signuprates, kan en spend-intervention utan hänsyn till säsong fortfarande vilseleda dig. Interventioner är kraftfulla, men de svarar bara på kausala frågor när den bakomliggande kausala historien är åtminstone ungefär rätt.
En kontrafaktisk fråga är en specifik "tänk om"-fråga: för det här exakta fallet, vad skulle ha hänt om vi gjort en annan åtgärd (eller om en insats varit annorlunda)? Det är inte "Vad händer i genomsnitt?" — det är "Skulle detta utfall ha ändrats för den här personen, denna biljett, denna transaktion?"
Kontrafaktiska frågor dyker upp när någon ber om en väg till ett annat utfall:
Dessa frågor är användar-nivå och konkreta nog att vägleda produktförändringar, policyer och förklaringar.
Föreställ dig en låne-modell som nekar en ansökan. En korrelationsbaserad förklaring kan säga: "Låga sparade medel korrelerar med avslag." En kontrafaktisk fråga är:
Om sökarens sparade medel var 3 000 USD högre (allt annat lika), skulle modellen godkänna?
Om svaret är "ja" har du lärt dig något handlingsbart: en möjlig förändring som vänder beslutet. Om svaret är "nej" undviker du att ge missvisande råd som "öka sparandet" när det verkliga hindret är skuld-till-inkomst eller osäker anställningshistoria.
Kontrafaktiska beror på en kausal modell — en historia om hur variabler påverkar varandra — inte bara en dataset. Du måste bestämma vad som realistiskt kan förändras, vad som skulle förändras som följd, och vad som måste hållas konstant. Utan den kausala strukturen kan kontrafaktiska bli omöjliga scenarier ("öka sparande utan att ändra inkomst eller utgifter") och ge ohelpfulla eller orättvisa rekommendationer.
När en ML-modell fallerar i produktion är rotorsaken sällan "algoritmen blev sämre." Oftare har något i systemet förändrats: vilken data ni samlar, hur etiketter skapas, eller vad användarna gör. Kausalt tänkande hjälper dig sluta gissa och börja isolera vilken förändring orsakade degraderingen.
Några återkommande syndare dyker upp i team:
Dessa kan se "bra" ut i aggregerade dashboards eftersom korrelation kan förbli hög även när anledningen till att modellen har rätt har förändrats.
Ett enkelt kausalt diagram (DAG) gör felsökning till en karta. Det tvingar dig att fråga: är denna feature en orsak till labeln, en konsekvens av den, eller en konsekvens av hur vi mäter den?
Till exempel, om Etiketteringspolicy → Feature-engineering → Modellinputs, kan du ha byggt en pipeline där modellen förutspår policyn snarare än det underliggande fenomenet. En DAG synliggör den vägen så att du kan blockera den (ta bort feature, ändra instrumentering, eller definiera om labeln).
Istället för att bara inspektera prediktioner, prova kontrollerade interventioner:
Många "förklarbarhets"-verktyg svarar en snäv fråga: Varför gav modellen den här poängen? De gör det ofta genom att framhäva inflytelserika input (feature-importance, saliency maps, SHAP-värden). Det kan vara användbart — men det är inte samma sak som att förklara systemet modellen sitter i.
En prediktionsförklaring är lokal och beskrivande: "Detta lån nekades främst för att inkomsten var låg och belåningsgraden hög."
En systemförklaring är kausal och operationell: "Om vi ökade verifierad inkomst (eller minskade belåningsgraden) på ett sätt som faktiskt är en rimlig intervention, skulle beslutet ändras — och skulle efterföljande utfall förbättras?"
Den första hjälper dig tolka modellens beteende. Den andra hjälper dig avgöra vad du ska göra.
Kausalt tänkande knyter förklaringar till interventioner. Istället för att fråga vilka variabler som korrelerar med poängen, frågar du vilka variabler som är giltiga spakar och vilka effekter de producerar när de ändras.
En kausal modell tvingar dig att vara explicit om:
Det spelar roll eftersom en "viktig feature" kan vara en proxy — användbar för prediktion, farlig för handling.
Post-hoc-förklaringar kan se övertygande ut samtidigt som de förblir rent korrelationella. Om "antal supporttickets" starkt predicerar churn kan ett feature-importance-diagram fresta teamet att "minska tickets" genom att göra support svårare att nå. Den interventionen kan öka churn, eftersom tickets var ett symptom på underliggande produktproblem — inte en orsak.
Korrelation-baserade förklaringar är också bräckliga vid distributionsskiften: när användarbeteendet ändras kanske samma framhävda features inte längre betyder samma sak.
Kausala förklaringar är särskilt värdefulla när beslut har konsekvenser och man måste kunna hållas ansvarig:
När du måste agera, inte bara tolka, behöver förklaringen en kausal ryggrad.
A/B-testning är kausal inferens i sin enklaste, mest praktiska form. När du slumpmässigt tilldelar användare variant A eller B utför du en intervention: du observerar inte bara vad folk valde, du sätter vad de ser. I Pearls termer gör randomisering "do(variant = B)" verklig — så skillnader i utfall kan rimligtvis tillskrivas förändringen, inte vem som råkade välja den.
Slumpmässig tilldelning bryter många dolda länkar mellan användaregenskaper och exponering. Power users, nya användare, tid på dygnet, enhetstyp — dessa faktorer finns kvar, men de är (i genomsnitt) balanserade över grupper. Den balansen är vad som förvandlar en metrikskillnad till ett kausalt påstående.
Även bra team kan inte alltid köra rena randomiserade tester:
I dessa fall kan du fortfarande tänka kausalt — du måste bara vara explicit om antaganden och osäkerhet.
Vanliga alternativ inkluderar difference-in-differences (jämför förändringar över tid mellan grupper), regression discontinuity (använd en cutoff-regel som "endast användare över poäng X"), instrumentvariabler (en naturlig knuff som ändrar exponering utan att direkt påverka utfall) och matching/weighting för att göra grupper mer jämförbara. Varje metod byter bort randomisering mot antaganden; en kausal diagram hjälper dig att formulera de antagandena tydligt.
Innan ni kör ett test (eller en observationell studie), skriv ner: primärmetrik, guardrails, målpopulation, duration och beslutsregel. Förregistrering tar inte bort bias, men minskar metrikshopping och gör kausala påståenden lättare att lita på — och lättare att diskutera i teamet.
De flesta produktdebatter låter: "Metrik X flyttade efter att vi släppte Y — så Y fungerade." Kausalt tänkande skärper det till en tydligare fråga: "Orsakade förändring Y att metrik X rörde sig, och med hur mycket?" Den förskjutningen förvandlar dashboards från bevis till startpunkter.
Prisändring: istället för "Gick intäkterna upp efter prisökningen?", fråga:
Onboarding-ändring: istället för "Nya användare slutför onboarding oftare nu", fråga:
Rekommendationsrankingsändring: istället för "CTR förbättrades", fråga:
Dashboards blandar ofta ihop "vem som fick förändringen" med "vem som ändå skulle gått bra." Ett klassiskt exempel: ni släpper en ny onboarding-flow, men den visas först för användare med senaste appversionen. Om nyare versioner adopteras av mer engagerade användare kan dashboarden visa en ökning som till stor del är versionsadoption, inte onboardingen.
Andra vanliga confounders i produktanalys:
En användbar PRD-sektion kan heta "Kausala frågor" och innehålla:
Om ni använder en snabb byggloop (särskilt med LLM-assisterad utveckling) blir den här sektionen ännu viktigare: den hindrar att "vi kan släppa snabbt" blir "vi släppte utan att veta vad det orsakade." Team som bygger i Koder.ai bakar ofta in dessa kausala frågor i planeringsläget och implementerar sedan feature-flagged varianter snabbt, med snapshots/rollback för att hålla experiment säkra när resultat (eller bieffekter) överraskar.
PM:er definierar beslutet och framgångskriterier. Data-partners översätter det till mätbara kausala skattningar och sanity checks. Engineering ser till att förändringen är kontrollerbar (feature flags, ren exponeringslogging). Support delar kvalitativa signaler — prisändringar kan "fungera" samtidigt som de tyst ökar avbokningar eller tickets. När alla är överens om den kausala frågan blir leverans lärande — inte bara leverans.
Kausalt tänkande kräver inte en PhD-utrullning. Behandla det som en teamvana: skriv ner din kausala historia, pressa den, låt data (och experiment när möjligt) bekräfta eller korrigera den.
För att komma framåt, samla fyra inputs i förväg:
I praktiken spelar hastighet roll: ju snabbare ni kan gå från en kausal fråga till en kontrollerad förändring, desto mindre tid spenderar ni på att bråka om tvetydiga mönster. Det är en anledning till att team använder plattformar som Koder.ai för att gå från "hypotes + plan" till en fungerande, instrumenterad implementation (webb, backend eller mobil) på dagar istället för veckor — samtidigt som de behåller stringens genom staged rollouts, deployment och rollback.
Om du vill ha en uppfräschning kring experiment, se /blog/ab-testing-basics. För vanliga fällor i produktmetrik som imiterar "effekter", se /blog/metrics-that-mislead.
Kausalt tänkande är ett skifte från "vad tenderar att röra sig tillsammans?" till "vad skulle ändras om vi agerade?" Den förskjutningen — populariserad i datavetenskap och statistik av Judea Pearl — hjälper team att undvika självsäkra historier som inte håller mot verkliga interventioner.
Korrelation är en ledtråd, inte ett svar.
Kausala diagram (DAGs) gör antaganden synliga och diskutabla.
Interventioner ("do") skiljer sig från observationer ("see").
Kontrafaktiska hjälper förklara enskilda fall: "vad om detta varit annorlunda?"
Bra kausalt arbete dokumenterar osäkerhet och alternativa förklaringar.
Kausalitet kräver omsorg: dolda störfaktorer, mätfel och urvalseffekter kan vända slutsatser. Motgiften är transparens — skriv ner antaganden, visa vilka data du använde och notera vad som skulle falsifiera ditt påstående.
Om du vill fördjupa dig, läs relaterade artiklar på /blog och jämför kausala metoder med andra analys- och "förklarbarhets"-metoder för att se var varje metod hjälper — och var den kan vilseleda.
Korrelation hjälper dig att förutsäga eller upptäcka (t.ex. ”när X stiger så stiger ofta Y också”). Kausation svarar en beslutfråga: ”Om vi ändrar X med avsikt, kommer Y att förändras?”
Använd korrelation för prognoser och övervakning; använd kausalt tänkande när ni ska släppa en förändring, sätta en policy eller lägga budget.
För att sambandet kan drivas av störfaktorer (confounding). I notis-exemplet både mycket engagerade användare triggar/aktiverar fler notiser och återvänder oftare.
Om ni ökar notisvolymen för alla så har ni förändrat upplevelsen (en intervention) utan att ändra den underliggande engagemangsnivån—därför förbättras inte retention och upplevelsen kan till och med försämras.
En DAG (Directed Acyclic Graph) är en enkel diagram där:
Den är användbar eftersom den gör antaganden explicita och hjälper team att enas om vad som ska justeras för, vad man inte ska justera för, och vilket experiment som faktiskt svarar på frågan.
Ett vanligt misstag är att “kontrollera för allt”, vilket kan få dig att oavsiktligt justera för mediators eller colliders och därmed biasera resultatet.
“See” är att observera vad som naturligt hände (användare valde att aktivera något, en poäng var hög). “Do” är att aktivt sätta en variabel (släppa en funktion, tvinga en standard).
Nyckeln: en intervention bryter de vanliga orsakerna till att en variabel har ett visst värde — därför kan den avslöja orsakssamband mer pålitligt än observation ensam.
En kontrafaktisk fråga är: för detta specifika fall, vad skulle hänt om vi gjort något annorlunda.
Den är användbar för:
Det kräver en kausal modell så att du inte föreslår omöjliga förändringar.
Fokusera på vad som ändrats upstream och vad modellen kan utnyttja:
Ett kausalt mindset får dig att testa riktade interventioner (ablations, perturbationer) istället för att förfölja sammanfallande metriksrörelser.
Inte nödvändigtvis. Feature-importance förklarar vad som påverkade prediktionen, inte vad ni borde ändra.
En högt rankad feature kan vara en proxy eller ett symptom (t.ex. supporttickets förutspår churn). Att ingripa på proxyn ("gör support svårare att nå för att minska tickets") kan slå tillbaka. Kausala förklaringar kopplar betydelse till giltiga spakar och till förväntade effekter under intervention.
Randomiserade A/B-tester är bäst när det går, men du kan behöva alternativ när:
I sådana fall, överväg quasi-experimentella metoder som difference-in-differences, regression discontinuity, instrumentvariabler eller matching/weighting — och var tydlig med antagandena.
Lägg till en kort sektion som tvingar klarhet innan analysen:
Det håller teamet inriktat på en kausal fråga istället för efterhands-berättelser från dashboards.