Ursachenfindung: Lässt der Hahnenschrei die Sonne aufgehen?

10 Zeilen Python-Code zur Automatisierung der Ursachenermittlung, die Sie sehen müssen

Der Schwerpunkt meiner jüngsten Forschung war Kausalschluss Angetrieben durch die zunehmenden Anfragen, die ich von Kunden bekomme, über die Vorhersagen des maschinellen Lernens hinauszugehen und „Was wäre wenn?“ zu beantworten. Geben Sie Fragen ein, um Auswirkungen und Ergebnisse zu erzielen.

Eines der Dinge, die mich anfangs faszinierten, war: „Wie werden Kausaldiagramme konstruiert?“ In vielen Online-Beispielen scheinen sie vollständig zum Leben zu erwachen, ohne dass erklärt wird, wie die Knoten und Links identifiziert wurden.

Dies brachte mich dazu, „The Book of Why“ von Judea Pearl und Dana Mackenzie zu lesen (mehrmals!) und eine geäußerte Ansicht ist, dass man aus den Daten kein Kausaldiagramm, auch Directed Asymmetric Graph (DAG) genannt, zurückentwickeln kann allein.

Daten können Korrelationen, aber keine Kausalität aufdecken. Wie ist es also möglich, Kausalitäten zu „entdecken“?

Hinweis: Alle Datensätze in diesem Artikel sind für die öffentliche Nutzung lizenziert. Alle Quellen und Referenzen finden Sie im Abschnitt „Referenzen“ am Ende des Artikels.

Bevor wir uns mit der Ursachenforschung befassen, bedenken Sie bitte …

Treten Sie Medium mit meinem Empfehlungslink bei (Ich erhalte einen Teil der Gebühren, wenn Sie sich über diesen Link anmelden.)

Abonnieren Sie eine kostenlose E-Mail, wenn ich eine neue Geschichte veröffentliche.

Werfen Sie einen kurzen Blick auf meine vorherigen Artikel.

Laden Sie mein kostenloses Framework zur strategischen, datengesteuerten Entscheidungsfindung herunter.

Besuch meiner Data-Science-Website – Der Datenblog.

Betrachten Sie die Wertanzahl aus dem folgenden Binärdatensatz …

Hinweis: Bei dem Sonnenaufgangs-/Hahn-Datensatz handelt es sich um synthetische Daten, die vom Autor erstellt wurden. Die vollständigen Quellen- und Referenzdetails finden Sie im Abschnitt „Referenzen“ am Ende des Artikels.

Wir können in 90.25 % der Beobachtungen sehen, dass der Hahn kräht, wenn die Sonne aufgeht. Aber woher wissen wir allein anhand der Daten, ob der Sonnenaufgang den Hahn zum Krähen bringt oder das Krähen des Hahns den Sonnenaufgang?

Die Anzahl der Fälle, in denen der Hahn kräht, wenn die Sonne nicht aufgeht, oder wenn die Sonne aufgeht, der Hahn aber schweigt, ist praktisch identisch (50,000 gegenüber 47,500), sodass die kausale Antwort nicht durch einen Vergleich der relativen Datenmengen gefunden werden kann.

Ein Ansatz könnte darin bestehen, den zeitlichen Aspekt zu betrachten. Wenn die Sonne regelmäßig aufgeht, bevor der Hahn kräht, ist das ein guter Indikator für die Kausalität. Aber was ist, wenn unser Hahn ein Frühaufsteher ist?

Die Antwort besteht darin, die Domänenexperten zu konsultieren. Wenn wir ein Team aus einem Astrologen, einem Physiker und einem Geflügelzüchter zusammenstellen könnten, würden sie zu dem Schluss kommen, dass die Sonne den Hahn zum Krähen bringt und nicht umgekehrt!

Unbeeindruckt von aufgehenden Sonnenstrahlen und krähenden Hähnchen machte ich mich auf die Suche nach etwas, das es bereits da draußen gab und das in der Lage sein könnte, die Magie der kausalen Entdeckung auf der Grundlage der Daten zu vollbringen.

Es gibt einen Algorithmus namens „NOTEARS“, der behauptet, kausale Entdeckung implementieren zu können, also probieren wir ihn mal aus und sehen, was er kann …

Hinweis: Bei dem Pockendatensatz handelt es sich um vom Autor erstellte synthetische Daten. Die vollständigen Quellen- und Referenzdetails finden Sie im Abschnitt „Referenzen“ am Ende des Artikels.

Dieser Datensatz modelliert die Ursache-Wirkungs-Beziehungen bei Pockenimpfungen. Lassen Sie uns den NOTEARS-Algorithmus dagegen ausführen und sehen, was er tun kann …

[('Reaktion?', 'Impfung?'),
(„Pocken?“, „Reaktion?“),
(„Tod?“, „Reaktion?“),
(„Tod?“, „Pocken?“)]

Wenn wir die von NOTEARS erzeugten Ergebnisse visualisieren würden, würde das so aussehen …

Es sieht nicht sehr gut aus, oder? Laut NOTEARS verursacht der Tod Pocken. Der zeitliche Aspekt sagt uns, dass Pocken zuerst auftreten und daher nicht durch den Tod verursacht werden können. Auch Pocken können die Reaktion nicht hervorrufen (der Impfstoff verursacht die Reaktion), und die Reaktion kann schon gar nicht die Impfung hervorrufen.

Mit dem Wissen von Fachexperten können wir leicht feststellen, dass die Impfung einen kausalen Einfluss darauf hat, ob der Patient eine Reaktion zeigt und ob er die Krankheit weiter entwickelt, und dass sowohl die Reaktion als auch Pocken einen kausalen Zusammenhang mit dem Tod haben …

Wir haben also festgestellt, dass selbst in einem sehr einfachen Kausalmodell der NOTEARS-Algorithmus zur Kausalerkennung keine korrekten Ergebnisse liefert. Außerdem hat ein Leser eines meiner vorherigen Artikel darauf hingewiesen, dass NOTEARS in Python 3.9 nicht funktioniert und dass dies ein weiteres großes Problem darstellt, da ich gerade dabei bin, ein Upgrade durchzuführen.

Wenn Sie mehr über die Ungeeignetheit von NOTEARS für Kausalität lesen möchten, finden Sie hier eine ausgezeichnete wissenschaftliche Arbeit – https://arxiv.org/pdf/2104.05441.pdf (Marcus Kaiser und Maksim Sipos).

Bevor wir die vollautomatische Kausalerkennung aufgeben, werfen wir einen Blick auf eine Alternative zu NOTEARS, den „Lasso“-Algorithmus –

Hinweis: Der Datensatz zu Volkszählungseinnahmen/Absolventenverdiensten ist für die öffentliche Nutzung lizenziert. Die vollständigen Quellen- und Referenzdetails finden Sie im Abschnitt „Referenzen“ am Ende des Artikels.

Oh je, Lasso ist eine Katastrophe! Es hat vorhergesagt, dass alles alles andere verursacht und dass die Knoten auch sich selbst verursachen!

Meine letzten Versuche bestanden darin, die Algorithmen GES, GIES und LINGAM auszuprobieren, aber diese erfordern alle R-Bibliotheken. Ich verwende kein R und selbst wenn es mir gelingen würde, die Konfiguration richtig hinzubekommen, wäre ich nie in der Lage, portablen Code zu erstellen, den andere Datenwissenschaftler verwenden könnten.

Die verfügbaren Bibliotheken und Algorithmen zur Kausalerkennung funktionieren nicht und dies hat die in „The Book of Why“ zum Ausdruck gebrachte Ansicht bestärkt, dass Kausalität nicht allein aus Daten rückentwickelt werden kann.

Diese Schlussfolgerung führte dazu, dass ich meinen eigenen Ansatz entwickelte …

Karten auf dem Tisch, ich habe keinen kausalen Entdeckungsalgorithmus geschrieben. Vielmehr implementiert mein Algorithmus eine korrelative Entdeckung mit einer Wendung (kein Wortspiel beabsichtigt!).

Als ich die Kausal-Discovery-Bibliotheken aufgegeben hatte, brauchte ich immer noch eine Möglichkeit, Kausalität als Ausgangspunkt für das Gespräch mit Fachexperten zu visualisieren.

Ich kam zu dem Schluss, dass ich die Korrelationen zwischen den Features/Knoten leicht berechnen könnte und dass dies zumindest ein guter Ausgangspunkt wäre.

Ich habe mein Denken wie folgt entwickelt: In kausalen Entdeckungsmodellen identifizieren wir normalerweise den „Effekt“, d. h. das Datenmerkmal, an dem wir interessiert sind (wie das „Ziel“ bei Vorhersagen des maschinellen Lernens). Im Pocken-Beispiel ist dies „Tod?“ und im Beispiel für den Verdienst des Hochschulabsolventen ist es der Verdienst „greaterThank50k“.

Wenn also Korrelationen zwischen einem Merkmal und der „Wirkung“ bestehen, muss die kausale Richtung von den anderen Merkmalen zur Wirkung gehen, da sie am „Ende der Linie“ liegt.

Mein nächster Schritt bestand darin, einen rekursiven Algorithmus zu entwickeln, der sich wie folgt visualisieren lässt …

Duplikate und bidirektionale Links müssen zwingend ausgeschlossen werden. Ich wollte auch in der Lage sein, Verbindungen (Kanten) explizit ein- oder auszuschließen und Features (Knoten) explizit auszuschließen.

Dies sind die 10 Zeilen rekursiven Python-Codes, die ich mir zur Implementierung der Kausalerkennung ausgedacht habe

Um zu zeigen, wie die Lösung funktioniert, habe ich einige Daten zu Stornierungsdaten von Hotelbuchungen ausgewählt.

Beginnen wir damit, die Daten einzulesen und einen Blick auf die Zusammenhänge zu werfen …

Hinweis: Der Hotelbuchungsdatensatz ist für die öffentliche Nutzung lizenziert. Die vollständigen Quellen- und Referenzdetails finden Sie im Abschnitt „Referenzen“ am Ende des Artikels.

Der erste Durchlauf des Erkennungsalgorithmus besteht darin, die Iterationen auf 1 zu beschränken, sodass wir nur die Korrelationen (die kausal sein sollten) mit dem „Effekt“ betrachten, d. h. ob die Hotelbuchung storniert wird oder nicht …

Okay, das ist kein schlechter Anfang. Erhöhen wir die Anzahl der Iterationen/Rekursionen/Ebenen auf 3, passen den Korrelationsschwellenwert ein wenig an und sehen, was wir bekommen …

OK, auch nicht so schlimm, aber es ist ein bisschen „geschäftig“, also besteht der nächste Schritt darin, einige der Knoten auszuschließen, von denen wir vermuten, dass sie etwas Lärm verursachen könnten (Hinweis: In einem realen Geschäftsfall würden wir mit ihnen sprechen). unsere Domain-Experten zu diesem Zeitpunkt).

Das sieht langsam besser aus. Denken Sie daran, dass mein Algorithmus sicher ist, dass Links zu „IsCancelled“ kausal sind, da es sich um den „Effekt“ handelt und daher nichts danach folgt.

Die anderen Ebenen des Baums sind jedoch nur korrelativ. Die Richtung der Pfeile wurde einfach basierend auf der Reihenfolge hinzugefügt, in der der Algorithmus sie gefunden hat.

Bei der Zusammenarbeit mit den Domain-Experten (oder in diesem Fall meiner eigenen Erfahrung mit Hotelbuchungen!) ist mir Folgendes aufgefallen:

• Der Link von „DifferentRoomAssigned“ zu „LeadTime“ geht in die falsche Richtung, da eine lange Buchungsvorlaufzeit die Wahrscheinlichkeit erhöht, dass sich die Zimmerbuchung ändert und nicht umgekehrt.
• Die Korrelation zwischen „BookingChanges“ und „DifferentRoomAssigned“ liegt unter dem Schwellenwert, kann jedoch ein erheblicher Kausalzusammenhang sein und muss daher berücksichtigt werden.

Der nächste Versuch weist den Algorithmus an, diese Korrekturen vorzunehmen –

Ein „unbeobachteter Störfaktor“ ist ein Faktor, von dem wir glauben, dass er sich auf unser Kausalmodell auswirkt, indem er eine Verbindung zwischen einigen Knoten herstellt, der jedoch nicht gemessen wurde und daher nicht in das Diagramm aufgenommen wurde.

Meine Erfahrung mit Hotelbesuchen und meine Kenntnis des Hoteldatensatzes ließen mich vermuten, dass es einen „unbeobachteten Störfaktor“ gibt, der die Hoteldaten beeinflusst.

In den Daten gibt es zwei Hotels – ein „Stadthotel“ und ein „Resort“-Hotel. Dies führte mich zu der Hypothese, dass der unbeobachtete Störfaktor in diesem Kausalmodell der ist „Grund für den Hotelaufenthalt“.

Meine Hypothese ist, dass Urlauber übernachten überwiegend im Resorthotel, Geschäftsreisende und Städtereisende überwiegend im Stadthotel.

Darüber hinaus habe ich die Hypothese aufgestellt, dass sich diese beiden Gruppen unterschiedlich verhalten und dass dies der „unbeobachtete Störfaktor“ ist (unbeobachtet, weil die Daten den „Grund des Aufenthalts“ nicht erfassen).

NOTEARS und andere ähnliche Algorithmen können „unbeobachtete Störfaktoren“ nicht berücksichtigen, aber der von mir entwickelte Algorithmus kann sie berücksichtigen, indem er sie wie folgt explizit einbezieht …

Das Ergebnis der letzten Iteration ist eine plausible, lesbare und verständliche Visualisierung der Kausalität in den Hoteldaten, die ich gerne gemeinsam mit den Fachexperten untersuchen und verfeinern würde. Das sind die Kernpunkte …

• Es gibt einen „unbeobachteten Confounder“, der den Hauptgrund für den Aufenthalt darstellt (Urlaub vs. Geschäftsreise/Städtereise).
• Das „Land“ hat einen kausalen Effekt auf den unbeobachteten Störfaktor – Reisende aus einigen Ländern sind eher im Urlaub.
• Gleiches gilt für „TotalGuests“. Große Gruppen sind eher im Urlaub, Singles auf Geschäftsreisen und Doppelte auf Städtereisen.
• Der unbeachtete „Aufenthaltsgrund“ wirkt sich ursächlich auf „LeadTime“, „HotelType“ und „DepositType“ aus.
• „LeadTime“, „DifferentRoomAssigned“, „HotelType“, „DepositType“ und „Reason for Stay“ (U) haben alle einen kausalen Einfluss auf „IsCanceled“.

Kausale Entdeckung ist der Prozess, über korrelative Verbindungen hinauszugehen und kausale Zusammenhänge zu entdecken (z. B. zu welchem ​​Ende einer Korrelationslinie gehört der Pfeil?). Dies ist mit Algorithmen wie NOTEARS nicht möglich oder zumindest unerschwinglich schwer zu automatisieren, da die Antworten nicht allein in den Daten vorliegen.

Es besteht jedoch immer noch ein dringender Bedarf, die Ursache zu visualisieren, damit sie mit Fachexperten untersucht werden kann, um ein Kausaldiagramm (auch als gerichteter azyklischer Graph oder DAG bezeichnet) zu erstellen.

In diesem Artikel wurde ein Algorithmus vorgeschlagen, der auf der Verbesserung der Korrelationserkennung basiert und nur 10 Zeilen Python-Code verwendet, der von Domänenexperten verwendet werden kann, um die Empfindlichkeit (Schwellenwert) wiederholt zu verfeinern und die Links (Pfeile) zu korrigieren, hinzuzufügen oder zu entfernen und irrelevante auszuschließen Knoten.

In zukünftigen Artikeln werden diese Kausaldiagramme verwendet, um ein vollständiges Kausalmodell für maschinelles Lernen zu erstellen, das komplexe „Was wäre wenn?“-Fragen beantworten kann. Geben Sie Fragen von Kunden und Unternehmensleitern ein.

Wenn Ihnen dieser Artikel gefallen hat, denken Sie bitte darüber nach …

Treten Sie Medium mit meinem Empfehlungslink bei (Ich erhalte einen Teil der Gebühren, wenn Sie sich über diesen Link anmelden.)

Abonnieren Sie eine kostenlose E-Mail, wenn ich eine neue Geschichte veröffentliche.

Werfen Sie einen kurzen Blick auf meine vorherigen Artikel.

Laden Sie mein kostenloses Framework zur strategischen, datengesteuerten Entscheidungsfindung herunter.

Besuch meiner Data-Science-Website – Der Datenblog.

Daten zum Sonnenaufgang / Krähen des Hahns

Pockendaten

Daten zu Absolventenverdiensten/Volkszählungseinkommen

Hotelbuchungsdaten

Kausale Entdeckung: Verursacht das Krähen des Hahns den Sonnenaufgang? Neu veröffentlicht von der Quelle https://towardsdatascience.com/causal-discovery-does-the-cockerel-crowing-cause-the-sun-to-rise-f4308453ecfa?source=rss—-7f60cf5620c9—4 über https://towardsdatascience. com/feed

<!–

->