En rad i en databas är inte en observation av verkligheten. Den är en spårrest av att någon, eller något system, beslutade att skriva ner något vid ett visst tillfälle.
Skillnaden låter akademisk och är den mest kostsamma missuppfattningen jag stöter på. Den som tror sig titta på verkligheten ställer aldrig frågan varför just det här hamnade i tabellen, och missar därmed nästan allt som avgör om en modell kommer att fungera.
Varje metodval är ett påstående
Det här är den bärande poängen. Metodvalen ser ut som tekniska beslut och är i själva verket påståenden om hur datan blev till.
| Valet | Påståendet |
|---|---|
| Poisson | Händelserna är oberoende, intensiteten konstant |
| Slumpmässig korsvalidering | Raderna är utbytbara, ingen tidsordning, inga grupper |
| Medelvärde som sammanfattning | Fördelningen är symmetrisk nog att medelvärdet beskriver något |
| Nollor som “hände inte” | Det finns bara ett sätt att bli noll |
| Historisk data för att skatta effekt | Behandlingen tilldelades oberoende av utfallet |
Varje rad i tabellen är en hypotes om verkligheten som går att kontrollera genom att fråga någon som kan verksamheten. Ingen av dem går att kontrollera genom att titta på datan.
Det är också därför de flesta modellfel är tysta. Ett brutet antagande ger inte ett felmeddelande, det ger en siffra som ser rimlig ut.
Frågorna som avslöjar processen
De här ställer jag i varje uppdrag, och de tar sällan mer än en förmiddag.
När skrevs värdet, och vad skrev över vad? Ett statusfält som uppdateras vid uppsägning innehåller framtiden sett från varje tidigare tidpunkt. Det är den vanligaste källan till dataläckage, och den syns aldrig i datan, bara i hur systemet skriver.
Vem kunde se vad, när? Om säljaren såg en riskflagga innan hon ringde är samtalet inte oberoende av risken.
Vilket beslut producerade raden? En order finns för att någon valde att köpa och för att någon valde att visa produkten. Båda leden är beslut, och bara det ena är ofta loggat.
Varför saknas det som saknas? Ett tomt fält kan betyda att inget hände, att ingen registrerade, att systemet var nere, eller att fältet infördes först i fjol. De fyra kräver helt olika hantering, och de ser identiska ut.
Vad ändrades i systemen? Ett byte av affärssystem, en ny kampanjstruktur eller en ändrad definition av “aktiv kund” skapar ett brott i historiken som ingen modell klarar utan att bli tillsagd.
Selektion: ni ser bara det ni gjorde
Data innehåller utfall för de handlingar som faktiskt utfördes. Beviljade lån har en återbetalningshistorik; avslagna har ingen. Visade annonser har klick; osynliga har inga. Kontaktade kunder har ett svar.
Det kontrafaktiska finns inte i datan, och det går inte att räkna fram ur den. En modell tränad på beviljade lån lär sig hur beviljade lån beter sig. Det är en smalare fråga än den som ställdes.
Det här är samma sak som gör att kausalitet kräver att man ingriper i världen snarare än bara betraktar den.
Återkopplingen som gör det värre
När ett system fattar beslut hamnar dess egna tidigare beslut i träningsdatan.
Modellen bedömde ett segment som svagt, systemet slutade satsa där, segmentet slutade generera observationer, och nästa modell tränas på en värld som den förra modellen format. Mätvärdena ser bra ut hela vägen, eftersom allt som inte fungerade har försvunnit ur underlaget.
Spärrarna beskrivs under beslutsmodeller och återkoppling. Men de hjälper bara den som förstått att slingan finns, och den syns inte i något diagnostiskt mått.
Var det mänskliga bidraget ligger
En modell kan söka igenom ett stort hypotesrum snabbare än någon människa. Den kan inte veta att statusfältet skrevs över vid uppsägningen, att kolumnen med kundsegment fylldes i manuellt fram till 2023, eller att säljarna slutade registrera besök när bonusmodellen ändrades.
Den informationen finns inte i datan. Den finns hos den som arbetar i systemet.
Det är därför automatiserad modellering, hur bra den än blir, inte tar bort behovet av någon som förstår verksamheten. Uppgiften är inte att välja algoritm. Det valet är sällan det som avgör. Uppgiften är att veta vad siffrorna är spår av, och det kräver att man frågar människor.
Att stoppa in siffror i en modell utan det arbetet ger alltid ett svar. Det ger sällan rätt svar, och det ger aldrig ett svar man vet om man kan lita på.
Hur jag arbetar med det
Konkret betyder det tre saker.
Jag sitter med den som matar in datan. Den mest värdefulla timmen i ett uppdrag är oftast med handläggaren, säljaren eller planeraren, inte med datan. De vet vilka fält som är tillförlitliga och vilka alla vet är skräp.
Jag läser hur källsystemet skriver, inte bara vad det innehåller. Skillnaden mellan en logg som lägger till rader och en tabell som skriver över är avgörande för om historiken över huvud taget går att rekonstruera.
Jag frågar vad som förändrats. Systembyten, ändrade definitioner, nya processer. Varje sådant brott är en gräns för hur långt tillbaka datan är användbar, och den gränsen är nästan aldrig dokumenterad.
Det är också hela grunden för mätdesign: när man förstått hur datan blev till ser man omedelbart vad som borde ha loggats och inte gjorde det. Den insikten är svår att få på något annat sätt, och den är värd mer än ett modellbyte.