12Customer Churn mit Keras/TensorFlow und H2O

Shirin Glander

Viele Unternehmen kämpfen mit dem Problem der Kundenabwanderung, das auch als Customer Churn bezeichnet wird. Da Kundenabwanderung finanzielle Verluste bedeutet und es häufig einfacher ist, bestehende Kunden durch Werbung oder andere Maßnahmen zu halten, als neue Kunden zu gewinnen, ist es das Ziel, die Abwanderungsquote mithilfe von Customer-Churn-Modellen zu verringern. Mit diesen Modellen lässt sich voraussagen, welche Kunden in naher Zukunft eventuell abwandern werden. Dazu werden Informationen über das Verhalten von Kunden gesammelt. Anhand eines Beispieldatensatzes wird gezeigt, wie ein typischer Analyseansatz aussehen kann. Diese Daten werden vorverarbeitet und mit neuronalen Netzen und Keras/TensorFlow zum Trainieren eines Customer-Churn-Modells verwendet. Alternativ zu Keras wird auch eine einfachere Bibliothek namens H2O eingesetzt, die automatisch mehrere Algorithmen vergleicht, um das bestmögliche Modell zu erhalten. Im letzten Schritt geht es um Bewertungsmethoden für Customer-Churn-Modelle, wie Performance-Metriken, Berechnungen von Kosten-Nutzen-Kalkulationen und den LIME-Algorithmus, der annäherungsweise Erklärungen für die Entscheidungen eines Modells ausgibt.

12.1Was ist Customer Churn?

Customer Churn beschreibt das Businessproblem der Kundenabwanderung, also von Kunden, die zum Beispiel einen bestehenden Vertrag kündigen, einen auslaufenden Vertrag nicht verlängern oder über einen gewissen Zeitraum hinweg nicht wieder bei einem (Online-)Handel eingekauft haben. Abgewanderte Kunden bedeuten oft einen großen finanziellen Verlust; darüber hinaus ist es häufig einfacher, bestehende Kunden durch Werbung, Aktionen oder andere Maßnahmen zu halten, als neue Kunden zu gewinnen. Customer Churn betrifft deshalb im Prinzip alle Geschäfte, die auf wiederkehrende Kunden angewiesen sind, also (Online-) Handelsfirmen, Telekommunikationsfirmen, Internet Service Provider und so weiter.

12.1.1Wie kann Predictive Analytics bei dem Problem helfen?

Unter Predictive (Business) Analytics fassen wir Techniken und Methoden aus dem Bereich Big Data, Machine Learning und Data Science zusammen, mit denen wir aus Businessdaten Vorhersagemodelle generieren. Die grundlegende Idee ist, dass Erkenntnisse, die aus historischen Daten gewonnen werden, genutzt werden können, um Extrapolationen für die Zukunft zu machen; so sollen diese Ergebnisse helfen, Businessprozesse zu optimieren, Gewinne zu steigern oder Kosten zu sparen.

Das Ziel von Customer-Churn-Modellen ist es, die Abwanderungsquote (also die Anzahl an abgewanderten Kunden in Relation zur Gesamtanzahl an Kunden) zu verringern [Nesper 2014]. Anhand von Informationen, die über das Verhalten von Kunden gesammelt wurden, können wir mit solchen Modellen voraussagen, welche Kunden in naher Zukunft eventuell abwandern werden. Um das zu erreichen, gibt es verschiedene Szenarien, wie eine Datenanalyse von Kunden dabei helfen kann, folgende Gruppen zu identifizieren:

Bei Customer-Churn-Analysen geht es im Prinzip darum, die Abwanderungswahrscheinlichkeit für jeden Kunden zu bestimmen und gegebenenfalls eine Segmentierung der Kunden in die oben genannten Gruppen vorzunehmen. Auch die Schlüsselfaktoren, die zum Abwandern führen, sollen identifiziert werden. Viele Organisationen und Firmen sammeln ohnehin eine große Menge an Daten über ihre Kunden, sodass solche Analysen mit modernen Machine-Learning-Verfahren ein typischer Anwendungsfall für Predictive Analytics sind.

12.1.2Wie können wir Customer Churn vorhersagen?

Customer-Churn-Modelle können mit verschiedenen Algorithmen trainiert werden. Im Prinzip eignen sich auch traditionelle statistische Methoden, wie logistische Regression, für das Trainieren solcher Modelle, aber häufig werden heutzutage Methoden aus dem Machine Learning verwendet, zum Beispiel neuronale Netze, aber auch Support Vector Machines, Random Forests oder Gradient-Boosting-Modelle. Machine-Learning-Modelle haben den Vorteil, dass sie in der Lage sind, deutlich komplexere Zusammenhänge zu lernen als traditionelle Methoden. Allerdings kommen sie mit dem Nachteil einher, dass ihre Entscheidungen schwierig (bis unmöglich) nachvollziehbar sind.

Welche Art von Modell wir nutzen können, hängt von der konkreten Fragestellung ab; in der Regel fallen Customer-Churn-Modelle in die folgenden Kategorien des überwachten Lernens (supervised learning):

12.2Fallstudie

In dieser Fallstudie wird exemplarisch gezeigt, wie Customer-Churn-Modelle mit zwei unterschiedlichen Herangehensweisen trainiert werden können:

Alle Analysen wurden mit R Version 3.50 durchgeführt [R Core Team 2018]. Der vollständige Code wird hier zur Verfügung stehen: https://shirinsplayground.netlify.com/2018/12/customer_churn_code.

12.2.1Der Beispieldatensatz

Der Beispieldatensatz, der in dieser Fallstudie verwendet wird, ist ein frei zugänglicher Datensatz über Kunden einer Telekommunikationsfirma, zur Verfügung gestellt von IBM Watson [IBM 2018].

Die Fragestellung, die wir hier beantworten wollen, lautet: Welche Kunden werden voraussichtlich abwandern?

In diesem Fallbeispiel kann nur gezeigt werden, wie die Abwanderungswahrscheinlichkeit (Churn) vorhergesagt werden kann; der Datensatz eignet sich nicht dazu, eine Kundensegmentierung zum Beispiel für eine Priorisierung oder ein gezieltes Marketing vorzunehmen. Auch kann hier nur eine mögliche Herangehensweise dargestellt werden; komplexere (und meistens genauere Modelle) beziehen Zeitreiheninformationen aus vergangenen Transaktionen und Verhalten des Kunden mit ein.

Feature

Beschreibung

customerID

einzigartiger Identifier pro Kunde

gender

Geschlecht

SeniorCitizen

Rentner ja (1)/nein (0)

Partner

hat einen Lebenspartner?

Dependents

hat Unterhaltsberechtigte?

tenure

Beschäftigungsdauer

PhoneService

hat Telefonservice abonniert?

MultipleLines

hat mehrere Leitungen?

InternetService

Art des abonnierten Internetservice

OnlineSecurity

hat Online-Security abonniert?

OnlineBackup

hat Online-Backup abonniert?

DeviceProtection

hat Device Protection abonniert?

TechSupport

hat Tech Support abonniert?

StreamingTV

hat TV-Streaming abonniert?

StreamingMovies

hat Film-Streaming abonniert?

Contract

Art des Vertrags

PaperlessBilling

zahlt papierlos?

PaymentMethod

Zahlungsmethode

MonthlyCharges

monatliche Kosten für den Kunden

TotalCharges

Gesamtkosten für den Kunden

Churn

Churn

Tab. 12–1Variablen/Features des Watson-Telco-Datensatzes von IBM

In Tabelle 12–1 ist eine Übersicht aller 21 Variablen (oder auch Feature) des Beispieldatensatzes gezeigt. Für 7043 Kunden haben wir Informationen über ihr Abwanderungsverhalten (Churn), welche Services sie abonniert haben (Telefon, Internet, Sicherheit etc.), Vertragsinformationen (Dauer, Zahlungsmethode, monatliche Beträge etc.) und demografische Daten (Geschlecht, Familienstand etc.) vorliegen. Die Variable Churn ist hier unsere Antwortvariable, die als Label für das überwachte Trainieren des Klassifikationsmodells genommen wird.

Explorative Datenanalyse

Explorative Datenanalyse (EDA) hilft dabei, den Datensatz besser zu verstehen und eventuelle Probleme, die das Modelling beeinflussen könnten, zu identifizieren.

Zunächst interessiert uns die Antwortvariable, mit der wir das Modell trainieren wollen: Churn. Hier wollen wir vor allem wissen, wie die Verteilung der Klassen ist. Bei ungleicher Verteilung müssen wir uns darüber Gedanken machen, ob und wie wir normalisieren wollen, denn dies wirkt sich auf die No-Information-Rate aus (also die Genauigkeit1, die wir durch rein zufälliges Zuweisen von Klassen erreichen würden) und somit auf die Evaluationsparameter des Modells. Wenn wir bei starkem Ungleichgewicht der Klassen ein Modell auf Genauigkeit trainieren, wird die häufigere Klasse dadurch überproportional stark zur Evaluation beitragen. Tabelle 12–2 zeigt das Zahlenverhältnis für unseren Datensatz: Wir haben 1869 Churn-Fälle gegen 5174 Nicht-Churn-Fälle, also ein Ungleichgewicht von circa 1:3. Für das neuronale Netz mit Keras werden wir die Klassen so lassen, wie sie sind, aber für das H2O-Modell werden wir die Klassen ausbalancieren.

Churn

n

No

5174

Yes

1869

Tab. 12–2Zahlenverhältnis der Klassen für die Antwortvariable Churn

Im nächsten Schritt schauen wir auf die Features; hierfür eignen sich Abbildungen besonders gut, denn sie erlauben uns, schnell ein Gefühl für die Daten zu bekommen und auf einen Blick Muster zu erkennen. Abbildung 12–1 zeigt die Übersicht aller Features des Beispieldatensatzes, aufgeteilt in Barplots für kategorische Features (vgl. Abb. 12–1) und Dichtediagramme für numerische Features (vgl. Abb. 12–2). Für alle Features ist die Klassenzugehörigkeit farblich kodiert, sodass wir direkt einfache Zusammenhänge erkennen können. So sehen wir zum Beispiel, dass Kunden mit zwei- und einjährigen Verträgen eine niedrigere Churn-Rate haben als Kunden mit monatlich kündbaren Verträgen, dass es keinen Unterschied zwischen den Geschlechtern gibt und dass Kunden mit höheren monatlichen Gebühren eher abwandern als Kunden, die weniger zahlen.

Andere interessante Methoden für die EDA können zum Beispiel Korrelationsanalysen, Clustering oder Dimensionalitätsreduktion (z.B. PCA, t-SNE oder Multidimensional Scaling) sein.

image

Abb. 12–1Übersicht aller kategorischen Features des Beispieldatensatzes; Anzahl Kunden pro Kategorie und Antwortvariable Churn

image

Abb. 12–2Übersicht aller numerischen Features des Beispieldatensatzes; Dichteverteilung über alle Kunden pro Antwortvariable Churn

12.2.2Vorverarbeitung der Daten

Viele Algorithmen können nicht mit fehlenden Werten in den Daten umgehen. Darum werden wir als Erstes überprüfen, ob und wo in unseren Daten Werte fehlen [van Buuren & Groothuis-Oudshoorn 2011]. Das einzige Feature mit teilweise fehlenden Daten ist hier TotalCharges, bei dem für 11 Kunden keine Angaben vorhanden sind. Es gibt mehrere Möglichkeiten, mit fehlenden Werten umzugehen, zum Beispiel:

Da es sich hier nur um einen geringen Anteil fehlender Daten handelt, wurden die entsprechenden Kunden in diesem Beispiel aus dem Datensatz entfernt.

In der Regel ist es sinnvoll, die Daten vor dem Trainieren des Modells zu normalisieren und vorzuverarbeiten. Bevor wir das tun, teilen wir die Daten aber zunächst in Trainings- und Testdaten auf. In welchem Verhältnis diese beiden Datentöpfe zueinander stehen, ist nicht fest vorgegeben; bei Datensätzen in der Größenordnung unter 10.000 Proben werden meistens ungefähr 70 bis 75% der Daten für das Trainieren der Modelle verwendet. Hier wurden 75% der Proben zufällig für das Modelltraining gewählt – stratifiziert anhand der Antwortvariablen Churn, um dasselbe Verhältnis der Klassen im Trainings- und Testset herzustellen. Das Trainingsset wurde ein weiteres Mal stratifiziert unterteilt, um ein Validierungsset zu erhalten [Kuhn & Wickham 2017; Wing et al. 2018].

Für die Normalisierung und Vorverarbeitung der Daten wurden folgende Schritte durchgeführt [Kuhn & Wickham 2018]:

12.2.3Neuronale Netze mit Keras und TensorFlow

Keras ist eine Open-Source-API für Deep Learning, mit der neuronale Netze einfach, schnell und flexibel gebaut werden können. Keras-Modelle sind modular aufgebaut und setzen sich aus aufeinander aufbauenden Schichten verschiedener Typen zusammen; so können Modelle beliebig komplex entworfen werden. Die eigentlichen mathematischen Operationen werden nicht von Keras selbst durchgeführt, sondern von einem darunter liegenden Backend. Das Default-Backend ist TensorFlow [Allaire & Chollet 2018; Chollet et al. 2015; Abadi et al. 2015].

Für dieses Fallbeispiel wurde ein einfaches neuronales Netz mit drei versteckten Schichten (mit 32, 16 und 8 Knoten) trainiert. Als Aktivierungsfunktion wurde Rectified Linear Units (ReLU) verwendet [Ramachandran et al. 2017; Nair & Hinton 2010] und als Optimizer AdaMax [Ruder 2016] mit binärer Cross-Entropy als zu minimierender Loss-Funktion. Trainiert wurde mit einer Batch-Größe von 32 Proben über 20 Epochen. Abbildung 12–3 zeigt die Bewertungskriterien Genauigkeit, Loss und Fehler über den gesamten Trainingslauf. Auf die theoretischen Grundlagen dieser Bewertungskriterien soll hier nicht weiter eingegangen werden (Erklärungen sind in [Goodfellow et al. 2016] nachzulesen), aber grundsätzlich wollen wir ein Modell erhalten, das eine möglichst hohe Genauigkeit und einen möglichst geringen Fehler für die Vorhersage von Trainings- und Validierungsdaten besitzt. Dabei sollten die Unterschiede zwischen Trainings- und Validierungsergebnissen nicht zu groß sein; wenn das der Fall ist (vor allem, wenn die Genauigkeit 100% beträgt), kann das auf Overfitting hinweisen [Dietterich 1995]. Eine Genauigkeit von 0,80 heißt, dass 80% der Vorhersagen richtig waren; den Fehler geben wir in der Regel als mittleren Quadratfehler an. Zusätzlich wird bei neuronalen Netzen der Loss als Bewertungskriterium genutzt. Die Loss-Funktion beschreibt den Unterschied zwischen Vorhersage und Wirklichkeit und soll während des Trainings minimiert werden [Rosasco et al. 2004]. Wann ein Modell »gut genug« ist, hängt von der spezifischen Problemstellung ab. Häufig reicht es aus, wenn ein Modell besser als ein Benchmark performt; das kann die Genauigkeit der zufälligen Vorhersage sein oder die Ergebnisse aus traditionellen Verfahren. Die finalen Ergebnisse für das Training des Modells waren: Loss = 0,430 (Validierung = 0,397), Genauigkeit = 0,798 (Validierung = 0,818) und mittlerer Quadratfehler = 0,139 (Validierung = 0,129). Mit diesen Werten ist unser Modell nicht perfekt, aber für einen ersten Trainingslauf ausreichend. Durch Hyperparameteroptimierung und Testen verschiedener Architekturen kann das Modell verbessert werden. Als Demonstrationsmodell für diese Fallstudie wollen wir es aber dabei belassen.

Die oben genannten Bewertungskriterien dienen nur zum Optimieren des Modells während des Trainings! Die endgültige Bewertung der Modelle erfolgt im letzten Schritt anhand von Testdaten, die nicht zum Training und zur Validierung genutzt wurden. Dieser Teil wird weiter unten in Abschnitt 12.3 behandelt.

image

Abb. 12–3Trainingskurven des Keras-Laufs über 20 Epochen mit Genauigkeit (binary accuracy), Loss und mittlerem Quadratfehler (mean squared error) für Trainings- und Validierungsdaten

12.2.4Stacked Ensembles mit H2O

Obwohl neuronale Netze sehr beliebte und effektive Algorithmen für das Trainieren von Klassifikationsmodellen sind, ist es meistens sinnvoll, andere Algorithmen und sogenannte Ensemble-Modelle zu vergleichen [Zhou 2012]. Dafür nutzen wir hier H2O [LeDell et al. 2018]. H2O ist eine frei nutzbare Machine-Learning-Plattform, die auf Java basiert und sowohl für R als auch für Python als Bibliothek zur Verfügung steht. H2O-Algorithmen sind auf einem Map/Reduce-Framework implementiert und für parallele Verarbeitung auf Clustern optimiert.

image

Abb. 12–4Die Receiver-Operating-Characteristic(ROC)-Kurve der Vorhersageergebnisse auf Testdaten mit dem H2O-Modell zeigt das Verhältnis von richtig zu falsch vorhergesagten Churn-Fällen; Area Under the Curve (AUC) = 0,85.

Das Vergleichsmodell mit H2O ist ein Stacked Ensemble mit balancierten Klassen aus jeweils dem besten Modell pro Algorithmus (Random Forest, DNN, Gradient Boosting, GLM). Zur Bewertung der Ergebnisse nutzen wir hier wieder den mittleren Quadratfehler und eine Loss-Funktion (siehe vorhergehenden Abschnitt) sowie die »Area under the ROC Curve« und Gini. Die ROC (Receiver Operating Characteristic) zeigt das Verhältnis von richtig zu falsch vorhergesagten Klassen [Bradley 1997] (vgl. Abb. 12–4). Der Gini-Koeffizient beschreibt einen Ungleichverteilungskoeffizienten, der genutzt werden kann, um die Vorhersagegenauigkeit von Klassifikationsproblemen zu bewerten [Raileanu & Stoffel 2004]. Die finalen Ergebnisse des Modells waren mittlerer Quadratfehler = 0,123 (Validierung = 0,128), LogLoss = 0,404 (Validierung = 0,403), mittlerer Fehler pro Klasse = 0,226 (Validierung = 0,220), Area under the Curve = 0,862 (Validierung = 0,860) und Gini = 0,723 (Validierung = 0,719) (siehe [Goodfellow et al. 2016; Zheng 2015; Bradley 1997] für detaillierte Erklärungen der Performance-Kriterien). Auch hier passiert die endgültige Bewertung des Modells im letzten Schritt anhand von Testdaten (siehe Abschnitt 12.3).

12.3Bewertung der Customer-Churn-Modelle

Oben haben wir zwei Arten von Machine-Learning-Algorithmen (neuronale Netze und Ensemble-Modelle) und ihre Umsetzung in zwei verschiedenen Bibliotheken (Keras/TensorFlow und H2O) kennengelernt. Während wir diese Modelle trainiert haben, haben wir bereits anhand der Trainings- und Validierungsdaten eine grobe Einschätzung über die Güte unserer Modelle erhalten. Die endgültige Bewertung der Modelle erfolgt im letzten Schritt anhand von Testdaten. Hier werden verschiedene Techniken für diese Bewertung anhand der beiden oben beschriebenen Modelle vorgestellt. Um keine redundante Information zu zeigen, werden abwechselnd das Keras- und H20-Modell genutzt; die beschriebenen Methoden können aber für beide Modelle genutzt werden.

In der Regel werden Customer-Churn-Modelle, wie sie in dieser Fallstudie dargestellt sind, nach allgemeinen Bewertungskriterien für binäre Klassifikationsmodelle beurteilt; dazu zählen unter anderem Genauigkeit, Sensitivität und F-Maß – gemessen an Testdaten, die nicht in das Training eingeflossen sind. Eine Übersicht über die folgenden Testwerte ist in Tabelle 12–3 exemplarisch für das Keras-Modell zu sehen (zum Vergleich mit dem H2O-Modell siehe https://shirinsplayground.netlify.com/2018/12/customer_churn_code).

image

Tab. 12–3Übersicht über Performance-Evaluation des Keras-Modells, gemessen an Testdaten.
accuracy: Genauigkeit – Anzahl richtiger Klassifikationen, bei denen die vorhergesagte Klasse gleich der tatsächlichen Klasse ist.
ROC: Receiver Operating Characteristic – zeigt das Verhältnis von richtig zu falsch vorhergesagten Klassen.
precision: positiver Vorhersagewert – Anzahl der als Churn klassifizierten Testfälle, die richtig vorhergesagt wurden.
recall: Sensitivität – Anzahl der Churn-Fälle im Testset, die richtig klassifiziert wurden.
F1: F-Maß – gewichtetes harmonisches Mittel aus positivem Vorhersagewert (precision) und Sensitivität (recall).

Aus dem Vergleich von vorhergesagter mit tatsächlicher Klasse aller Testfälle ergibt sich die Konfusionsmatrix (auch Fehler- oder Wahrheitsmatrix genannt); diese ist hier exemplarisch für das H2O-Modell in Tabelle 12–4 gezeigt.

image

Tab. 12–4Konfusionsmatrix über Testfälle, vorhergesagt mit dem H2O-Stacked-Ensemble-Modell

12.3.1Kosten-Nutzen-Kalkulation

Oft sind diese klassischen Bewertungskriterien aber schwer greifbar. Um den direkten Einfluss des Customer-Churn-Modells auf den Gewinn bzw. Umsatz des Unternehmens zu bestimmen, können wir eine einfache Kosten-Nutzen-Kalkulation durchführen. Für dieses Fallbeispiel ist so eine Rechnung exemplarisch an fiktiven Zahlen dargestellt. Die Zahlen können aber natürlich an jede Situation spezifisch angepasst werden, um die Effektivität eines Modells zu beurteilen.

Nehmen wir also Folgendes an:

Mit diesen Zahlen können wir nun das alte Vorgehen mit einem Vorgehen nach Empfehlungen des Customer-Churn-Modells rechnerisch vergleichen. Hierfür nutzen wir dieselben Testfälle wie zuvor. Für jeden Testfall gibt das Modell (in diesem Fall am Beispiel des H2O-Stacked-Ensemble-Modells) eine Art Abwanderungswahrscheinlichkeit (hier genannt p1) aus, das heißt einen Wert zwischen 0 (sehr sicher kein Churn) und 1 (sehr sicher Churn). Da wir eine Einteilung in Klassen vornehmen wollen, wird irgendwo zwischen 0 und 1 ein Schwellenwert definiert, anhand dessen die Einteilung erfolgt. Der Default-Schwellenwert ist 0,5; ein Testfall mit einem Wahrscheinlichkeitswert p1 von 0,6 wird also als Churn klassifiziert, während ein Testfall mit p1 = 0,2 als Nicht-Churn klassifiziert wird. Aus dem Wert 1 – p1 ergibt sich die Wahrscheinlichkeit für Nichtabwanderung, genannt p0. Dies können wir nun nutzen, um den optimalen Schwellenwert zu bestimmen (vgl. Abb. 12–5). Dabei beurteilen wir für jeden getesteten Schwellenwert die folgenden Parameter und Kosten/Nutzen des Modells:

Wenn wir eine Konversionsrate von 70% annehmen und den optimalen Schwellenwert bei 0,7 setzen, kommen wir durch unser Customer-Churn-Modell auf einen Nettogewinn von 2,6 Millionen Euro bzw. einen Nettogewinn im Vergleich zum alten Verfahren von circa 900.000 Euro (vgl. Tab. 12–5).

Schwellenwert

Nettogewinn

Nettogewinn im Vergleich zum alten Verfahren

0,7

2594400

892900

0,8

2593200

891700

0,9

2580000

878500

1.0

2580000

878500

0,6

2579800

878300

0,5

2555200

853700

0,4

2512800

811300

0,3

2453800

752300

0,2

2333800

632300

0,1

2110400

408900

0,0

1476800

-224700

Tab. 12–5Vergleich des Nettogewinns und des Nettogewinns im Vergleich zum alten Verfahren bei verschiedenen Schwellenwerten des H2O-Stacked-Ensemble-Klassifikationsmodells

image

Abb. 12–5Vergleich der Anteile richtig vorhergesagter Churn- und Nicht-Churn-Testfälle für verschiedene Schwellenwerte mit dem H2O-Stacked-Ensemble-Klassifikationsmodell

12.3.2Erklärbarkeit von Customer-Churn-Modellen

Ein Problem bei Machine-Learning-Modellen ist, dass wir die Herleitungen der einzelnen Vorhersagen nicht nachvollziehen können. Der Grund für diese »Blackbox« ist, dass die gelernten Zusammenhänge so komplex sind, dass wir geistig nicht mehr in der Lage sind, diese zu verstehen. Eine Möglichkeit, annähernde Erklärbarkeit zu schaffen, ist LIME (Local Interpretable Model-agnostic Explanations). LIME wurde erstmals 2016 beschrieben und ist ein mathematischer Ansatz, um Vorhersagen von Klassifikationsmodellen Modell-agnostisch zu erklären [Pedersen & Benesty 2018; Ribeiro et al. 2016]. LIME basiert auf drei Grundkonzepten:

  1. Erklärungen werden lokal und für jede Instanz unabhängig gegeben.
  2. Ein einfaches (z.B. lineares) Modell wird lokal an Vorhersagen des komplexen Modells angepasst.
  3. Erklärungen werden anhand der Ursprungsvariablen gefunden.

In unserem Fallbeispiel können wir den LIME-Algorithmus nutzen, um ein besseres Verständnis der Kundeneinteilung durch das Customer-Churn-Modell zu bekommen. So können wir zum Beispiel für einzelne Testfälle herausfinden, welche Features besonders stark für oder gegen die jeweilige Klassifikation sprechen (vgl. Abb. 12–6). Wir können LIME auch nutzen, um einen Überblick über globale Trends in den Features zu identifizieren, die mit den Klassen korrelieren (vgl. Abb. 12–7).

image

Abb. 12–6Der LIME-Algorithmus gibt für neun gezeigte Testfälle (Cases) annäherungsweise Erklärungen, welche Feature-Ausprägungen (x-Achse) des Customer-Churn-Modells besonders stark für (y-Achse positiv/schwarz) oder gegen (y-Achse negativ/grau) die jeweilige Klassifikation (Label + Probability) sprechen.

image

Abb. 12–7Diese Heatmap zeigt globale Muster in den annäherungsweisen Erklärungen des Customer-Churn-Modells durch LIME; Feature-Ausprägungen auf der x-Achse und Testfälle (Cases) auf der y-Achse sind durch eine kontinuierliche Farbskala als für oder gegen die Klassifikation sprechend dargestellt (positiv/schwarz = spricht für Erklärung; negativ/grau = spricht gegen Erklärung).

12.4Zusammenfassung und Fazit

Abgewanderte Kunden bedeuten oft einen großen finanziellen Verlust für Firmen. Das Ziel von Customer-Churn-Modellen ist, die Abwanderungsrate zu verringern, indem wir voraussagen, welche Kunden in naher Zukunft eventuell abwandern werden. Diese Kunden können dann mit gezielten Maßnahmen angesprochen werden. In dieser Fallstudie wurden zwei verschiedene Bibliotheken zur Generierung solcher Modelle vorgestellt: Keras/TensorFlow für neuronale Netze und H2O für Stacked Ensembles. Dabei wurde der gesamte Arbeitsablauf anhand von Beispieldaten gezeigt: Explorative Datenanalyse (EDA), um den Datensatz besser zu verstehen, Vorverarbeitung der Daten, um zum Beispiel fehlende Werte zu entfernen, Trainieren der Modelle und Bewertungskriterien für die Ergebnisse. Zusätzlich zu klassischen Bewertungskriterien für Machine-Learning-Modelle wurde eine beispielhafte Kosten-Nutzen-Kalkulation erstellt, die direkt den finanziellen Benefit eines Customer-Churn-Modells angibt. Mit dem LIME-Algorithmus (Local Interpretable Model-agnostic Explanations) wurde außerdem gezeigt, wie man annäherungsweise Erklärungen für die durch das Modell getroffenen Einteilungen in Churn und No-Churn finden kann.2