Oorzakelijke ontdekking: veroorzaakt het kraaien van de haan dat de zon opkomt?

10 regels Python-code om causale ontdekkingen te automatiseren die u moet zien

De focus van mijn recente onderzoek lag causale gevolgtrekking gedreven door de toenemende verzoeken die ik krijg van klanten om verder te gaan dan voorspellingen van machine learning en het beantwoorden van “wat-als?” type vragen om de impact en resultaten te stimuleren.

Een van de dingen die mij aanvankelijk intrigeerden was: “Hoe worden causale diagrammen opgebouwd?”. In veel van de online voorbeelden lijken ze volledig gevormd tot leven te komen, zonder uitleg over hoe de knooppunten en verbindingen werden geïdentificeerd.

Dit bracht mij ertoe om “The Book of Why” van Judea Pearl en Dana Mackenzie te lezen (meerdere keren!) en een standpunt dat naar voren werd gebracht is dat je geen causaal diagram, ook bekend als een Directed Acyclic Graph (DAG), kunt reverse engineeren op basis van de gegevens alleen.

Gegevens kunnen correlatie aan het licht brengen, maar geen causaliteit. Hoe is het dan mogelijk om causaliteit te ‘ontdekken’?

Let op: alle datasets in dit artikel zijn gelicentieerd voor openbaar gebruik. Zie de referentiesectie aan het einde van het artikel voor alle bronnen en referenties.

Voordat we in causaal onderzoek duiken, overweeg alstublieft …

Lid worden van Medium met mijn verwijzingslink (Ik ontvang een deel van de kosten als je je aanmeldt via deze link).

Abonneer u op een gratis e-mail wanneer ik een nieuw verhaal publiceer.

Kijk snel naar mijn eerdere artikelen.

Mijn gratis strategische datagestuurde besluitvormingskader downloaden.

Mijn data science-website bezoeken — De datablog.

Beschouw het aantal waarden uit de volgende binaire gegevensset …

Opmerking: de dataset voor zonsopgang / haan is synthetische gegevens die door de auteur zijn gemaakt. Zie de sectie met referenties aan het einde van het artikel voor de volledige bron- en referentiedetails.

In 90.25% van de waarnemingen kunnen we zien dat de haan kraait als de zon opkomt, maar hoe weten we op basis van alleen de gegevens of de opkomst van de zon ervoor zorgt dat de haan kraait of dat het kraaien van de haan ervoor zorgt dat de zon opkomt?

Het aantal gevallen waarin de haan kraait als de zon niet opkomt of wanneer de zon opkomt maar de haan stil blijft, is vrijwel identiek (50,000 versus 47,500), dus het causale antwoord kan niet worden gevonden door de relatieve hoeveelheden gegevens te vergelijken.

Eén benadering zou kunnen zijn om naar het temporele aspect te kijken. Als de zon consequent opkomt voordat de haan kraait, zal dat een goede indicator zijn voor de causaliteit, maar wat als onze haan een vroege vogel is?

Het antwoord is om de domeinexperts te raadplegen. Als we een team zouden kunnen samenstellen met een astroloog, een natuurkundige en een pluimveehouder, zouden ze tot de conclusie komen dat de zon de haan doet kraaien en niet andersom!

Niet afgeschrikt door opkomende zon en kraaiende hanen ging ik op zoek naar iets dat al bestond en dat op basis van de gegevens de magie van causale ontdekking zou kunnen bewerkstelligen.

Er is een algoritme met de naam “NOTEARS” dat beweert causale ontdekkingen te kunnen implementeren, dus laten we het eens proberen en kijken wat het kan doen …

Let op: de pokkendataset bestaat uit synthetische gegevens die door de auteur zijn gemaakt. Zie de referentiesectie aan het einde van het artikel voor de volledige bron- en referentiedetails.

Deze dataset modelleert de oorzaak-gevolgrelaties bij pokkenvaccinaties. Laten we het NOTEARS-algoritme er eens tegenaan gooien en kijken wat het kan doen...

[('Reactie?', 'Vaccinatie?'),
('Pokken?', 'Reactie?'),
('Dood?', 'Reactie?'),
('Dood?', 'Pokken?')]

Als we de resultaten van NOTEARS zouden visualiseren, zou het er als volgt uitzien …

Het ziet er niet erg goed uit, hè? Volgens NOTEARS veroorzaakt de dood pokken. Het temporele aspect vertelt ons dat pokken op de eerste plaats komen en dus niet door de dood kunnen worden veroorzaakt. Ook kunnen pokken de reactie niet veroorzaken (het vaccin veroorzaakt de reactie) en de reactie kan zeker niet de vaccinatie veroorzaken.

Met behulp van de kennis van domeinexperts kunnen we gemakkelijk vaststellen dat de vaccinatie een causaal effect heeft op de vraag of de patiënt een reactie krijgt en of hij of zij de ziekte blijft ontwikkelen, en dat de reactie en de pokken beide een causaal verband hebben met de dood …

We hebben dus vastgesteld dat zelfs in een heel eenvoudig causaal model het NOTEARS-algoritme voor causale ontdekking geen correcte resultaten oplevert. Ook wees een lezer van een van mijn eerdere artikelen erop dat NOTEARS niet werkt in Python 3.9 en aangezien ik op het punt sta te upgraden, is dit een ander groot probleem.

Als je meer wilt lezen over de ongeschiktheid van NOTEARS voor causaliteit, dan is hier een uitstekend academisch artikel: https://arxiv.org/pdf/2104.05441.pdf (Marcus Kaiser en Maksim Sipos).

Voordat we de volledig geautomatiseerde causale ontdekking opgeven, kijken we eerst naar een alternatief voor NOTEARS, het ‘Lasso’-algoritme:

Let op: de dataset van het censusinkomen / de inkomsten van afgestudeerden is gelicentieerd voor openbaar gebruik. Zie het gedeelte met referenties aan het einde van het artikel voor de volledige bron- en referentiegegevens.

Oh jee, Lasso is een ramp! Het heeft voorspeld dat alles al het andere veroorzaakt en dat de knooppunten zichzelf ook veroorzaken!

Mijn laatste pogingen waren het uitproberen van de GES-, GIES- en LINGAM-algoritmen, maar deze vereisen allemaal R-bibliotheken. Ik gebruik R niet en zelfs als het me zou lukken om de configuratie goed te krijgen, zou ik nooit draagbare code kunnen maken die andere datawetenschappers zouden kunnen gebruiken.

De causale ontdekkingsbibliotheken en algoritmen die beschikbaar zijn, werken niet en dit heeft de visie versterkt die verwoord wordt in “The Book of Why”, dat wil zeggen dat causaliteit niet kan worden teruggedraaid op basis van alleen data.

Deze conclusie heeft ertoe geleid dat ik mijn eigen aanpak heb ontwikkeld…

Kaarten op tafel, ik heb geen causaal ontdekkingsalgoritme geschreven. Mijn algoritme implementeert eerder correlatieve ontdekking met een twist (geen woordspeling bedoeld!).

Toen ik de causale ontdekkingsbibliotheken had opgegeven, had ik nog steeds een manier nodig om causaliteit te visualiseren als startpunt voor het gesprek met domeinexperts.

Ik redeneerde dat ik de correlaties tussen de features/nodes makkelijk kon berekenen en dat dit in ieder geval een goed uitgangspunt zou zijn.

Ik heb mijn manier van denken als volgt ontwikkeld: in modellen voor causale ontdekking identificeren we meestal het ‘effect’, dat wil zeggen het gegevenskenmerk waarin we geïnteresseerd zijn (zoals het ‘doel’ in voorspellingen van machinaal leren). In het pokkenvoorbeeld is dit “Dood?”, en in het voorbeeld van het inkomen van afgestudeerden is dit het inkomen “groterBedankt50k”.

Als er dus correlaties zijn tussen een kenmerk en het “effect”, moet de causale richting van de andere kenmerken naar het effect lopen, aangezien deze zich aan het “einde van de lijn” bevindt.

Mijn volgende stap was het ontwikkelen van een recursief algoritme dat als volgt kan worden gevisualiseerd …

Duplicaten en bidirectionele links moeten met geweld worden uitgesloten. Ik wilde ook verbindingen (randen) expliciet kunnen opnemen of uitsluiten en functies (knooppunten) expliciet kunnen uitsluiten.

Dit zijn de tien regels recursieve Python-code die ik heb bedacht om causale ontdekking te implementeren

Om te laten zien hoe de oplossing werkt, heb ik een aantal gegevens over de annuleringsgegevens van hotelboekingen geselecteerd.

Laten we beginnen met het inlezen van de gegevens en een kijkje nemen naar de correlaties …

Let op: de dataset voor hotelboekingen is gelicentieerd voor openbaar gebruik. Zie de referentiesectie aan het einde van het artikel voor de volledige bron- en referentiegegevens.

De eerste run van het ontdekkingsalgoritme houdt in dat de iteraties beperkt blijven tot 1, dus we kijken alleen naar de correlaties (die causaal zouden moeten zijn) met het “effect”, dat wil zeggen of de hotelboeking wordt geannuleerd of niet …

Oké, dat is geen slecht begin, laten we het aantal iteraties/recursies/lagen verhogen naar 3, de correlatiedrempel een beetje aanpassen en kijken wat we krijgen …

Oké, ook niet zo erg, maar het is een beetje “druk”, dus de volgende stap is het uitsluiten van enkele van de knooppunten waarvan we vermoeden dat ze een deel van de ruis veroorzaken (let op: in een echte businesscase zouden we praten met onze domeinexperts in dit stadium).

Dit begint er beter uit te zien. Onthoud dat het my-algoritme ervan overtuigd is dat links naar “IsCancelled” causaal zijn, omdat dit het “effect” is, en er dus niets achter komt.

De andere lagen van de boom zijn echter slechts correlatief; de richting van de pijlen is eenvoudigweg toegevoegd op basis van de volgorde waarin het algoritme ze heeft gevonden.

Door samen te werken met de domeinexperts (of in dit geval mijn eigen ervaring met hotelboekingen!) merkte ik het volgende op:

• De koppeling van “DifferentRoomAssigned” naar “LeadTime” gaat de verkeerde kant op, omdat een lange boekingsdoorlooptijd de kans vergroot dat de kamerboeking verandert en niet andersom.
• De correlatie tussen “BookingChanges” en “DifferentRoomAssigned” ligt onder de drempelwaarde, maar kan een significant causaal verband hebben en moet daarom worden opgenomen.

De volgende poging instrueert het algoritme om deze correcties aan te brengen:

Een ‘niet-waargenomen confounder’ is een factor waarvan we denken dat deze van invloed is op ons causale model door een verband te leggen tussen sommige knooppunten, maar die niet is gemeten en daarom niet in het diagram is opgenomen.

Mijn ervaring met het bezoeken van hotels en mijn kennis van de hoteldataset deden mij vermoeden dat er sprake is van een “niet-waargenomen confounder” die de hotelgegevens beïnvloedt.

Er zijn twee hotels in de gegevens: een “stadshotel” en een “resorthotel”. Dit bracht mij tot de hypothese dat de niet-waargenomen confounder in dit causale model de “reden voor hotelovernachting”.

Mijn hypothese is dat vakantiegangers verblijven vooral in het resorthotel en zakenmensen en stadsbezoekers verblijven vooral in het stadshotel.

Verder heb ik de hypothese opgesteld dat deze twee groepen verschillend gedrag vertonen en dat dit de ‘niet-geobserveerde confounder’ is (niet-geobserveerd omdat de gegevens de ‘reden voor het verblijf’ niet weergeven).

NOTEARS en andere soortgelijke algoritmen kunnen geen rekening houden met ‘niet-waargenomen confounders’, maar het algoritme dat ik heb ontwikkeld kan er wel rekening mee houden door ze als volgt expliciet op te nemen …

Het resultaat van de laatste iteratie is een plausibele, leesbare en begrijpelijke visualisatie van de causaliteit in de hotelgegevens die ik graag samen met de domeinexperts zou onderzoeken en verfijnen. Dit zijn de belangrijkste punten…

• Er is een ‘onopgemerkte confounder’ die de voornaamste reden voor het verblijf is (vakantie vs. zakenreis/stedentrip).
• Het ‘land’ heeft een causaal effect op de niet-waargenomen confounder: degenen die vanuit bepaalde landen reizen, hebben een grotere kans op vakantie.
• Hetzelfde geldt voor “TotalGuests”. Grote gezelschappen zijn vaker op vakantie, alleenstaanden op zakenreis en dubbelgangers op stedentrips.
• De niet-waargenomen “reden voor verblijf” heeft een causaal effect op “LeadTime”, “HotelType” en “DepositType”.
• “LeadTime”, “DifferentRoomAssigned”, “HotelType”, “DepositType” en “Reason for Stay” (U) hebben allemaal een causaal effect op “IsCanceled”.

Causale ontdekking is het proces van verder gaan dan correlatieve verbanden en het ontdekken van causale verbanden (dwz aan welk uiteinde van een correlatieve lijn hoort de pijl?). Dit is niet mogelijk, of op zijn minst onbetaalbaar, te automatiseren met algoritmen als NOTEARS, omdat de antwoorden niet alleen in de data bestaan.

Er is echter nog steeds een cruciale behoefte om causaliteit te visualiseren, zodat deze kan worden onderzocht met domeinexperts om een ​​causaal diagram op te bouwen (ook wel een Directed Acyclic Graph of DAG genoemd).

In dit artikel wordt een algoritme voorgesteld dat gebaseerd is op het vergroten van correlatieve ontdekking, waarbij gebruik wordt gemaakt van slechts 10 regels Python-code. Dit algoritme kan door domeinexperts worden gebruikt om herhaaldelijk de gevoeligheid (drempel) te verfijnen en de links (pijlen) te corrigeren, toe te voegen of te verwijderen en irrelevante uit te sluiten. knooppunten.

In toekomstige artikelen zullen deze causale diagrammen worden gebruikt om een ​​volledig causaal machine learning-model te bouwen dat complexe “wat als?” typ vragen van klanten en bedrijfsleiders.

Als je dit artikel leuk vond, overweeg dan …

Lid worden van Medium met mijn verwijzingslink (Ik ontvang een deel van de kosten als je je aanmeldt via deze link).

Abonneer u op een gratis e-mail wanneer ik een nieuw verhaal publiceer.

Kijk snel naar mijn eerdere artikelen.

Mijn gratis strategische datagestuurde besluitvormingskader downloaden.

Mijn data science-website bezoeken — De datablog.

Gegevens over opkomende zon / kraaiende haan

Gegevens over pokken

Inkomstengegevens van afgestudeerden / volkstelling

Hotelboekingsgegevens

Causale ontdekking: zorgt het kraaien van de haan ervoor dat de zon opkomt? Heruitgegeven vanaf bron https://towardsdatascience.com/causal-discovery-does-the-cockerel-crowing-cause-the-sun-to-rise-f4308453ecfa?source=rss—-7f60cf5620c9—4 via https://towardsdatascience. com/feed

<!–

->