Getreu dem Motto „Wir bringen Licht ins Dunkel“, sollen Data-Mining-Methoden Wissen sichtbar machen, welches derzeit noch irgendwo in den Untiefen einer Datenbank schlummert und nur darauf wartet entdeckt zu werden. Um uns dabei nicht selber im Dschungel aus Entscheidungsbäumen und linearen Regressionen zu verlaufen oder uns möglicherweise in einem künstlichen neuronalen Netz zu verfangen, atmen wir kurz durch und schauen in die Box mit dem täglichen Brot des Data Scientists. Von dort nehmen wir etwas mit, für den Fall, dass uns in diesem Blogartikel noch ein Beispiel über den Weg läuft.
Die Methoden
Vereinfacht gesagt lassen sich Data-Mining-Methoden in
- Supervised Learning (Regression, Klassifikation) und
- Unsupervised Learning (Segmentierung, Assoziationsregeln)
unterteilen. In letzterem Fall versucht man z. B. Segmente für bestimmte Zielgruppen zu finden oder typisches Kaufverhalten von Kunden offenzulegen, um diese für ein weiteres Produkt zu werben. Hier gibt es kein richtig oder falsch, was die Bewertung dieser Modelle oft erschwert. Beim Supervised Learning geht es um die Vorhersage/Zuordnung diskreter Werte (Größe, Absatz,…) oder bestimmter Klassen, wie z. B. Tieren (Hund, Katze, Maus,…). Die entsprechenden Modelle lassen sich an bekannten Daten „trainieren“. Dies geschieht indem man die Parameter einer vorgegebenen Modellgleichung so bestimmt, dass die Trainingsdaten „möglichst gut“ reproduziert werden (daher Supervised Learning). Das bekannteste Beispiel ist sicher die lineare Regression.
Die Bike Buyer
In diesem Blogartikel möchte ich mich einer einfachen Evaluierungsmethode für binäre Klassifikationsmodelle widmen. Was das ist sollte direkt aus der Beschreibung des folgenden Datensatzes über 10.000 Kunden eines Fahrradgeschäfts ersichtlich werden. Um die Kunden zu anonymisieren und dennoch unterscheiden zu können, wurden sie zunächst mit einer ID versehen. Danach wurden über jeden Kunden Informationen wie z. B. Geschlecht, Alter, Gehalt oder die Länge des täglichen Arbeitsweges gesammelt. Diese Infos werden auch Features genannt. Im Nachhinein wurde für jeden festgestellt, ob er in einem bestimmten Zeitraum ein Fahrrad gekauft hat oder nicht. Dies wurde durch das Label BikeBuyer (yes/no) festgehalten. Insgesamt haben sich 10% ein Fahrrad gekauft. So erhalten wir eine Tabelle, in der jede Zeile die Daten eines bestimmten Kunden enthält (siehe Tabelle 1).
Tabelle 1: Auszug aus dem Datensatz BikeBuyer im typischen ML-Studio-Design
Unser Anliegen ist es letztlich ein Modell zu erstellen, welches neue Kunden zuverlässig als zukünftige BikeBuyer oder non-BikeBuyer klassifiziert und somit z. B. ein Fahrradverkäufer eine Prognose erhält, ob jemand ein Fahrrad kaufen wird. Genau dafür brauchen wir die Werte aus Tabelle 1. Anhand der bekannten Kombinationen aus Features und Label ist es möglich, die Parameter eines Modells optimal einzustellen. In diesem Szenario bedeutet das, dass der Zusammenhang zwischen Features und der Klassifikation BikeBuyer oder non-BikeBuyer, durch eine Formel ausgedrückt werden kann. Die üblichen Modellgleichungen machen dies allerdings noch eine Stufe genauer: Sie berechnen nämlich eine Wahrscheinlichkeit, mit der ein Kunde ein BikeBuyer ist. Intuitiv würde ein Verkäufer wohl vermuten, dass jemand ein BikeBuyer ist, sofern die Wahrscheinlichkeit hierfür über 50% beträgt und genauso ist es auch bei den meisten Modellen voreingestellt. Manchmal macht es auch Sinn den Schwellwert (p) für die Entscheidung zu variieren, doch dahin radeln wir lieber erst später.
Ein Modell in ML
Zunächst habe ich im neuen Microsoft Cloud-Dienst Azure Machine Learning (ML) ein paar Klassifikationsmodelle aus 70% der BikeBuyer-Daten erstellt. Um zu schauen wie ein Modell bei neuen Kunden funktioniert, habe ich mir die restlichen Datensätze zum Testen aufgespart. Auf jeden der 3000 verbleibenden „Testkunden“ habe ich mein favorisiertes Modell angewendet und somit aus den Features eine Wahrscheinlichkeit berechnet. Ein Kunde mit einer „Scored Probability“ von über 50% erhielt das „Scored Label“ yes, wodurch dieser als BikeBuyer klassifiziert wurde. In Tabelle 2 sieht man die Ergebnisse.
Tabelle 2: Auszug aus den Testdaten nach Anwendung eines „Two-Class Boosted Decision Trees“ in Azure ML. (Zuvor wurden die Daten u. a. normalisiert. Trainings- und Testdaten wurden zufällig ausgewählt, wobei in beiden Datensätzen der Anteil der BikeBuyer 10% beträgt.)
Mit den grünen Häkchen habe ich gekennzeichnet, dass der Wert für Scored Label und BikeBuyer übereinstimmt. Offensichtlich lag das Modell mit der Klassifikation in den ersten sieben Fällen richtig. Für den letzten Kunden aus Tabelle 2 liegt das Modell jedoch deutlich daneben. Die berechnete Kaufwahrscheinlichkeit war nur 0,5% und dennoch hat sich der Kunde ein Fahrrad zugelegt.
Ein wenig Verwirrung
Wie gut unser Modell funktioniert, können wir natürlich erst beurteilen, wenn wir uns ein paar Kennzahlen anschauen, die die Ergebnisse aller 3000 Testdaten beinhalten. Diese werden mittlerweile standardmäßig von den meisten Programmen ausgegeben – so auch in Azure ML, welches zusätzlich die Wahrheitsmatrix anzeigt (siehe Abbildung 3, links). Diese (auch passenderweise als „confusion matrix“ bezeichnete) Tabelle ist der Schlüssel zur Berechnung aller weiteren Bewertungsmetriken (u. a. in Abbildung 3, rechts). Ihre Felder geben jeweils an, in wie vielen Fällen das Modell mit der Klassifikation BikeBuyer oder non-BikeBuyer („Positive“ vs. „Negative“) gleichzeitig richtig oder falsch liegt („True“ vs. „False“).
Abbildung 3: Wahrheitsmatrix (links) und verschiedene Bewertungsmetriken (rechts).
Von den 300 Fahrradkäufern (obere Zeile der Matrix) wurden 119 richtig vorhergesagt (Recall=39,7%). Bei den 231 „Positives“ (linke Spalte) klassifizierte das Modell 119 Mal korrekt als BikeBuyer (Precision=51,5%). Insgesamt stimmten 2707 Klassifizierungen (Trues), was bei 3000 Entscheidungen einer Accuracy von 90,2% entspricht. Der F-Score ist eine Kombination aus Recall und Precision, die manchmal gebraucht wird, da diese Kennzahlen gegenläufig sind.
Unser Modell ist gar nicht mal so schlecht. Es liegt mit 90,2% seiner Vorhersagen richtig (Accuracy) und findet dabei immerhin 39,7% der relevanten Kunden (Recall). Mit 51,5% Precision haben mehr als die Hälfte der klassifizierten BikeBuyer tatsächlich ein Fahrrad erstanden. Dennoch gibt es wahrscheinlich noch bessere Modelle, denn durch die richtige Vorarbeit und ein paar Kniffe bei der Modellierung lassen sich anfangs fast immer weitere Prozentpunkte aus den Trainingsdaten herauskitzeln. Festhalten können wir jedoch, dass wir nun wissen wie ein binäres Klassifikationsmodell funktioniert und was die wichtigsten Kennzahlen aussagen.
Variation des Schwellwerts
Natürlich kann es sein, dass der Fahrradverkäufer individuelle Kriterien an ein Modell hegt und ihm z. B. eine möglichst zuverlässige Klassifizierung von BikeBuyern (hohe Precision) wichtiger ist als wirklich alle BikeBuyer zu erwischen (hoher Recall). Ein Modell, das diesen Präferenzen entspricht, kann er sich recht einfach aus dem bisherigen ableiten, indem er den bereits oben angesprochenen Schwellwert p für die Wahrscheinlichkeit von 50% auf z. B. 90% anhebt. So werden nun nur noch diejenigen als BikeBuyer klassifiziert, für die das Modell wirklich „sehr sicher“ ist (Wahrscheinlichkeit mindestens 90%). Gleichzeitig fallen viele potentielle BikeBuyer mit Wahrscheinlichkeiten von 50-90% aus dem Radar des Fahrradverkäufers (siehe Tabelle 4).
Tabelle 4: Die hier beispielhaft angegebenen Kaufwahrscheinlichkeiten führen zu unterschiedlichen Einteilungen in BikeBuyer (dunkelgrün) oder non-BikeBuyer (hellgrün), je nach verwendetem Schwellwert p.
Wie angekündigt steigt durch ersteres die Precision bzw. fällt durch letzteres der Recall (für den Vergleich der Modelle siehe auch Abbildung 5).
Abbildung 5: Evaluierungsmetriken des obigen Modells mit Schwellwert p=0,5 (oben) und p=0,9 (unten). Beim Erhöhen des Schwellwerts steigt die Precision, doch es fällt der Recall.
Die ROC curve rockt
Durch die soeben beschriebene Variation des Schwellwerts kann man sich nun stets beliebig viele weitere Modelle kreieren. Diese Modelle basieren allerdings alle auf denselben Wahrscheinlichkeiten, die vom eingangs erstellten „Grundmodell“ berechnet wurden (gemeint sind die Scored Probabilities in Tabelle 2). Für den Vergleich zweier „Grundmodelle“ (z. B. eines Entscheidungsbaumes mit einem neuronalen Netzwerk) ist es also naheliegend, Kennzahlen anzugeben, die die Güte des Modells unabhängig vom gewählten Schwellwert beschreiben. Durchgesetzt hat sich die Kombination zweier Kennzahlen, die in Abhängigkeit vom Schwellwert eine Kurve, die „receiver operating characteristic“ (kurz ROC curve), bilden. Der Name stammt noch von ihrer ersten Anwendung im zweiten Weltkrieg, in dem die Briten mit Hilfe der ROC curve Radarsignale als Signal (Flugzeuge) bzw. Noise (z. B. Vogelschwärme) klassifizieren konnten. Die erste dafür benötigte Kennzahl, der Recall, war schon bei den von Azure ML ausgegebenen Kennzahlen dabei. Ein hoher Recall ist immer wünschenswert, jedoch ergibt sich der genaue Wert zwischen 0 und 1, je nach festgelegtem Schwellwert und verwendetem (Test-)Datensatz. Die zweite Kennzahl ist der Fallout. Während der Recall der Quote von richtig klassifizierten Fahrradkäufern entspricht, beschreibt der Fallout die Quote von falsch klassifizierten Nicht-Fahrradkäufern. Die Berechnung von Recall und Fallout für verschiedene Schwellwerte wird in Tabelle 6 durchgeführt und erklärt.
Tabelle 6: Die benötigten Kennzahlen zur Konstruktion der ROC curve. Recall=TP/(TP+FN)=TP/300 und Fallout=FP/(FP+TN)=FP/2700. Die Kurzbezeichnungen T, F, P, N stehen für True, False, Positive und Negative. Die jeweiligen Vereinfachungen der Formeln ergeben sich, da auch in den 3000 Testdaten 10% (also 300) BikeBuyer sind und somit TP+FN=300 (BikeBuyer) bzw. FP+TN=2700 (non-BikeBuyer).
Durch Eintragen der Kombinationen von Fallout- (x-Achse) und Recallwerten (y-Achse) aus Tabelle 6) in einem Koordinatensystem erhält man die ROC curve unseres Modells, welche ebenfalls von Azure ML mitgeliefert wird (siehe Abbildung 7).
Abbildung 7: ROC curve für die Testdaten nach Anwendung des Two-Class Boosted Decision Trees (Tabelle 2). In Azure ML werden die Achsen mit False Positive Rate (=Fallout) und True Positive Rate (=Recall) bezeichnet. Die Kreuze sind die jeweiligen Punkte der Modelle für p=10%, 20% usw. (siehe Tabelle 6). Die ROC curve verläuft immer im Einheitsquadrat und geht stets durch die Punkte (0,0) und (1,1). Vorteilhaft ist ein Verlauf „möglichst weit oben links“, wie in der Abbildung zu sehen ist.
Es ist klar, dass der Recall möglichst hoch sein soll (am besten Recall=1). Der Fallout hingegen sollte möglichst niedrig sein, da er ja mit (wünschenswerten) 0 False Positives zu 0/(0+TN)=0 werden würde. Daher wäre eine Fallout-Recall-Kombination von 0 und 100% optimal, was dem Punkt (0,1) in Abbildung 7 entsprechen würde. Da die Kurve allerdings mit p=1 immer unten rechts im Punkt (0,0) beginnt, wäre es wünschenswert, wenn sie möglichst schnell steigt. Das bedeutet, dass eine „gute“ ROC curve „irgendwo bzw. möglichst weit oben links verläuft“. Dieses Wissen ist hilfreich, denn wenn wir mal zwei Modelle miteinander vergleichen wollen, können wir jenes auswählen, dessen ROC curve über den anderen liegt (was nicht immer, aber sehr häufig, der Fall ist).
Doch was ist mit einem „guten Modell“ gemeint? Bezieht sich das „gut“ auf einen Vergleich mit einem anderen Modell oder kann ein Modell auch irgendwann ausreichend gut sein? Wahrscheinlich gibt es hier mehrere Meinungen. Schließlich kann man ein Modell häufig durch Kenntnis der richtigen Ansätze oder eine bessere Datenqualität/-verfügbarkeit verbessern. Dabei ist zu beachten, dass dies mit mehr Aufwand für die Datenerhebung verknüpft sein kann und die Anwendung eines Modells grundsätzlich einen gewissen Aufwand und Kosten mit sich bringt. Daher ist ein Modell immer dann gut genug, wenn es diesen Aufwand für den Benutzer durch irgendeinen Vorteil rechtfertigt. Dies könnte also nur der Fahrradverkäufer entscheiden.
Würfeln im Datendschungel
Die Idee für diesen Blogartikel entstand aus der Behauptung, dass ein bestimmtes Modell „besser als Würfeln“ sei. Würfeln – im übertragenen Sinne – würde bedeuten, dass wir einfach jedem Testkunden zufällig eine Wahrscheinlichkeit zwischen 0 und 1 zuordnen und dann unser Modell klassifizieren lassen. Je nach Schwellwert p würden wir einen anderen Recall bzw. Fallout erhalten. Allerdings wäre der jeweils erwartete Wert stets derselbe, nämlich 1-p. Für unterschiedliche Schwellwerte erhält man somit Tabelle 8.
Tabelle 8: Zunächst füllen wir die Spalten TP und FP von unten nach oben auf. Wenn p=0, werden alle 3000 als Positives klassifiziert. Demzufolge gibt es 300 TP und 2700 FP. Wenn p=0,1 werden nur noch 2700 als Positives klassifiziert. Davon sind 10% wirklich Positives, also TP=270 und weiter FP=2430. Für p=0.2, 0.3 etc. fallen die Einträge von TP und FP um jeweils 30 bzw. 270. Nach dem Füllen der beiden Spalten ergibt sich die FN-Spalte, da TP+FN=300 gilt und die TN-Spalte kann wegen FP+TN=2700 aufgefüllt werden. Der Recall und Fallout können dann für jedes p berechnet werden. Man kann relativ schnell nachrechnen, dass sowohl der erwartete Recall als auch der erwartete Fallout in diesem Modell 1-p entsprechen.
Auch für das Würfelmodell können wir die ROC curve einzeichnen. Sie entspricht der Diagonalen, die durch die Punkte (0,0) und (1,1) verläuft (siehe Abbildung 9).
Abbildung 9: Die ROC curves des Two-Class Bossted Decision Trees (blau) und des „Würfelmodells“ (schwarz). Die Kreuze sind die jeweiligen Fallout-Recall-Kombinationen aus Tabelle 8. Offensichtlich bringt unser Modell einen Mehrwert.
Wie gut unser eingangs erstellter Two-Class Boosted Decision Tree letztendlich ist, sagen uns nur ein paar Kennzahlen und die Zufriedenheit des Fahrradverkäufers. Sicherlich kann man dieses Modell noch optimieren. Doch da die ROC curve des Decision Trees über der Diagonalen liegt, ist er immerhin (bei weitem) besser als Würfeln. Somit haben wir unser Ziel erreicht und kehren fürs Erste zufrieden zurück aus dem Dickicht des Datendschungels.
Aus dem Dschungel in den Dschungel
Neben den üblichen Links, die man beim Schreiben eines Blogartikels findet, bin ich auf ein beeindruckend gutes Video gestoßen, in dem die Zusammenhänge ebenfalls erklärt werden:
http://www.dataschool.io/roc-curves-and-auc-explained/
Der Schieberegler, der im Video unterstützend zum Einsatz kommt, ist hier zu finden: