Reading Sample
2.1 Entscheidungsbäume für Klassifkationsprobleme
Bei den Verfahren des beaufsichtigten Lernens (siehe Abschnitt 1.2.2) geht es darum, Vorhersagemodelle zu entwickeln, die den Wert einer Zielvariablen auf Basis von Eingabevariablen prognostizieren. Wie schon im Einführungskapitel beschrieben, gibt es zwei grundlegende Problemstellungen beim beaufsichtigten Lernen:
- Klassifikationsprobleme für diskrete oder kategoriale Zielvariablen
- Regressionsprobleme für kontinuierliche Zielvariablen
Viele Algorithmen, wie Entscheidungsbäume oder neuronale Netze, lassen sich für beide Problemstellungen einsetzen.
Regression oder Klassifikation?
Betrachten Sie das Beispiel der Kündigungsanalyse aus Abschnitt 1.2.1, insbesondere Abbildung 1.3: Die dort skizzierte Datensammlung von aktiven und ehemaligen Kunden enthält Informationen wie Alter, Kontostand oder die Anzahl der genutzten Produkte. Zusätzlich gibt es ein Attribut »Kündigungsflag« (Spalte EXITED), das anzeigt, ob ein Kunde in den letzten drei Monaten gekündigt hat (entspricht der Ausprägung 1) oder als Kunde dem Unternehmen treu geblieben ist (entspricht der Ausprägung 0).
Dieses Attribut ist die Zielvariable, für die ein Prognosemodell erstellt werden soll. Das Modell prognostiziert auf Basis der informativen Merkmale, der Eingabevariablen, für jeden Kunden den Wert der Zielvariablen. Ein solches Modell ist ein Klassifikationsmodell, da die Zielvariable nur zwei mögliche Ausprägungen hat – im Beispiel entsprechend den Klassen »Kündigung«/»keine Kündigung«.
Möchten Sie hingegen das Attribut »Kontostand« vorhersagen, benötigen Sie ein Regressionsmodell, da dieses Attribut den Typ »Dezimalzahl« hat und somit als kontinuierliche Variable betrachtet werden muss.
Die Entwicklung des Modells läuft in zwei Schritten ab: Zunächst wird ein Klassifikationsmodell mit Trainingsdaten unter Verwendung der für jeden Datensatz bekannten, korrekten Klassenzuordnung trainiert. Dann wird das trainierte Modell durch eine Prognosebildung mittels Testdaten geprüft. Durch den Vergleich der tatsächlichen und der vom Modell vorhergesagten Klassenzuordnung ergibt sich die Verallgemeinerungsfähigkeit des Modells. Für die Testdaten ist demnach – ebenso wie für die Trainingsdaten – die Kenntnis der korrekten Klassenzuordnung notwendig, sie wird aber dem Modell während des Trainings nicht bekannt gemacht. Man bezeichnet die Testdaten daher auch als zurückgehaltene Daten, da sie während des Trainingsprozesses nicht verwendet werden dürfen.
Aus der PAL verwenden wir für das weitere Vorgehen die folgenden Funktionen:
_SYS_AFL.PAL_DECISION_TREE
: Trainieren eines Entscheidungsbaums_SYS_AFL.PAL_DECISION_TREE_PREDICT
: Prognosebildung mit einem trainierten Entscheidungsbaum_SYS_AFL.PAL_CONFUSION_MATRIX
: Berechnung der Konfusionsmatrix für die Beurteilung der Prognosegüte eines Modells
Lassen Sie uns das Vorgehen am Beispiel der Kündigungsvorhersage auf Basis der HANA-Tabelle CHURN (siehe Abschnitt 1.3 für den Import) aus dem Datenbankschema ML_DATA betrachten. Ich zeige Ihnen, wie Sie mit PAL einen Entscheidungsbaum trainieren, der das Kündigungsverhalten vorhersagt. Den trainierten Entscheidungsbaum wenden Sie dann auf eine Testmenge von Kundendaten an. Zum besseren Verständnis ist in Abbildung 2.1 ein Beispiel für einen einfachen Entscheidungsbaum gezeigt, der die Kunden auf Basis der Merkmale Bonität, Land und Alter klassifiziert.
Abbildung 2.1: Ein einfacher Entscheidungsbaum
2.1.1 Trainieren eines Entscheidungsbaums
Stellen Sie zunächst eine Verbindung zu Ihrem HANA-System her und öffnen Sie eine SQL-Konsole im Schema ML_DATA.
Betrachten wir die Tabelle CHURN, von der Sie einen Auszug in Abbildung 2.2 sehen.
Abbildung 2.2: Auszug aus der Tabelle CHURN
Die Zielvariable für das Modell ist die Spalte EXITED, die anzeigt, ob ein Kunde in den letzten drei Monaten gekündigt hat. Wenden wir uns zunächst der Verteilung der beiden Klassen (0 und 1) der Spalte EXITED in der Gesamtmenge der Kunden zu. Mit dem SQL-Code aus Listing 2.1 erhalten Sie die Gesamtzahl der Kunden in jeder Klasse, siehe Tabelle 2.2.
SELECT EXITED, count(*) FROM CHURN GROUP BY EXITED
Listing 2.1: SQL-Abfrage zur Zählung der Kunden nach EXITED
EXITED | COUNT(*) |
---|---|
0 | 7963 |
1 | 2037 |
Tabelle 2.2: Verteilung des Merkmals EXITED in den Kundendaten
Die Klasse 0 (keine Kündigung) kommt in den Kundendaten deutlich häufiger vor als die Klasse 1 (Kündigung). Zum Trainieren eines Modells eignet sich aber eine Datenmenge besser, in der die Häufigkeiten der einzelnen Klassen in etwa ausgeglichen sind.
Auswirkung von unausgewogenen Klassenverteilungen auf das trainierte Modell
Klingt das Erstellen einer ausgeglichenen Trainingsdatenmenge in Ihren Ohren manipulativ, als würde man damit die reale Situation verfälschen? Keine Sorge!
Da die Trainingsdaten nicht zur finalen Bewertung der Leistung des Modells verwendet werden, hat man eine gewisse Freiheit, sie für den Testzweck geeignet anzupassen.
Wenn in den Trainingsdaten eine Klasse sehr dominant ist, besteht die Gefahr, dass das trainierte Modell bevorzugt diese Klasse prognostiziert, um eine hohe Korrektklassifizierungsrate für die Trainingsdaten zu erreichen.
Instanzen, die zu der selteneren Klasse gehören, werden dann bei der späteren produktiven Anwendung des Modells nur ungenügend erkannt. Oft ist aber gerade die Erkennung dieser selteneren Klasse, etwa die einer drohenden Kündigung oder betrügerischen Banküberweisung, essenziell.
Es ist daher tatsächlich ein gängiges Verfahren, diesem Problem zu begegnen, indem die Trainingsdaten so aus der Grundmenge gebildet werden, dass die Häufigkeiten der einzelnen Klassen ausgewogen sind, z.B. annähernd übereinstimmen [1, S. 230ff.].
Mit dem Code in Listing 2.2 können Sie eine solche ausgewogene Trainingsdatenmenge erstellen. Zur Vereinfachung bilde ich hier eine Trainingsmenge, in der beide Klassen sogar gleich häufig sind. Betrachten wir das Coding im Detail: Durch verschiedene SELECT-Anweisungen werden schrittweise die folgenden Tabellenvariablen aufgebaut:
lt_input
: enthält von der Tabelle CHURN alle Spalten, die als Eingabevariablen verwendet werden, und die Spalte EXITED, die die Zielvariable darstellt.lt_id_train
: enthält die Kundennummern (Spalte CUSTOMERID) von 1000 Kunden, die gekündigt haben, und von 1000 weiteren Kunden ohne Kündigung aus der Tabellenvariablelt_input
. Die Tabellenvariablelt_id_train
umfasst somit exakt die Kundennummern der Datensätze, die für das Training verwendet werden sollen.lt_input_train
: enthält diejenigen Datensätze auslt_input
, deren Kundennummern inlt_id_train
vorkommen. Diese Sätze werden für das Training des Modells verwendet.lt_input_test
: enthält die Datensätze auslt_input
, die nicht für das Training ausgewählt wurden, also das Komplement zult_input_train
.
Die Daten in lt_input_train
werden als Trainingsdaten beim Aufruf der Trainingsprozedur PAL_DECISION_TREE
angegeben. Die Daten der Tabellenvariable lt_input_test
hingegen verwenden Sie später in Abschnitt 2.1.2 für die Bewertung des Modells.
Beachten Sie, dass ich die SQL-Anweisungen in einem anonymen Block kapsele, der durch die Anweisung DO BEGIN
geöffnet und durch die Anweisung END;
geschlossen wird, siehe Listing 2.2. Im weiteren Verlauf fügen Sie die Quellcodes aus Listing 2.3 und Listing 2.4 jeweils am Ende des anonymen Blockes vor dem Signalwort END
ein.
SET SCHEMA ML_DATA; DO BEGIN lt_input = SELECT CUSTOMERID, CREDITSCORE, GEOGRAPHY, GENDER, AGE, TENURE, BALANCE, NUMOFPRODUCTS, HASCRCARD, ISACTIVEMEMBER, ESTIMATEDSALARY, EXITED FROM CHURN; -- Ausgewogene Trainingsmenge erstellen lt_id_train = SELECT TOP 1000 CUSTOMERID FROM :lt_input WHERE EXITED = 1 UNION SELECT TOP 1000 CUSTOMERID FROM :lt_input WHERE EXITED = 0; lt_input_train = SELECT * FROM :lt_input AS a WHERE EXISTS (SELECT CUSTOMERID FROM :lt_id_train AS b WHERE b.CUSTOMERID = a.CUSTOMERID); lt_input_test = SELECT * FROM :lt_input AS a WHERE NOT EXISTS ( SELECT CUSTOMERID FROM :lt_id_train AS b WHERE b.CUSTOMERID = a.CUSTOMERID); -- Optional: Ausgabe der Trainingsdatenmenge: -- SELECT * FROM :lt_input_train; -- Hier Code der unten folgenden Listings einfügen END;
Listing 2.2: Erstellen einer ausgewogenen Trainingsdatenmenge
Anonyme Blöcke und Tabellenvariablen verwenden
Mit SQLScript lassen sich komplexe SQL-Anweisungen elegant in einzelne Anweisungen zerlegen. Hierzu sind anonyme Blöcke sehr hilfreich, da sie – auch ohne die Erstellung von Datenbankprozeduren – die Nutzung von Tabellenvariablen zum Referenzieren von Zwischenergebnissen erlauben. Mehr dazu finden Sie im Buch »SQLScript für SAP HANA« von Jörg Brandeis [7]. Dort wird auch beschrieben, wie man ab SAP HANA 2.0 SPS04 schreibende Operationen (Einfügen etc.) auf Tabellenvariablen ausführen kann. Dadurch lässt sich die in Listing 2.3 eingeführte temporäre Tabelle für die Parameter durch eine Tabellenvariable ersetzen.
Kompletter Code zum Trainieren und Testen
Den kompletten Quellcode für das hier behandelte Beispiel finden Sie im Quellcodeverzeichnis (Anhang B) in der Datei Ch_2_1_PAL_Churn_Dec_Tree_Train_Test.sql. Diese beinhaltet sowohl das Training als auch das im nächsten Abschnitt behandelte Testen des Modells.
Die Prozedur PAL_DECISION_TREE
besitzt zwei Eingabeparameter, siehe Tabelle 2.3. Der Parameter DATA
erwartet eine Tabelle mit den Trainingsdaten. Hierfür verwenden Sie die Tabellenvariable lt_input_train
aus Listing 2.2.
Name | Typ | Beschreibung |
---|---|---|
DATA | Tabelle | Trainingsdaten |
PARAMETER | Tabelle | Tabelle mit Hyperparametern zur Konfiguration des Trainingsalgorithmus |
Tabelle 2.3: Eingabeparameter von PAL_DECISION_TREE
Das Eingabeargument PARAMETER
enthält die Hyperparameter, mit denen Sie den Trainingsalgorithmus konfigurieren können. Die Prozedur erwartet für dieses Argument eine Tabelle mit den folgenden Spalten:
- NAME: Name des Hyperparameters
- INT_VALUE: Angabe des Parameterwertes als Ganzzahl
- DOUBLE_VALUE: Angabe des Parameterwertes als Dezimalzahl
- STRING_VALUE: Angabe des Parameterwertes als zeichenartiges Objekt
Ein Beispiel für eine solche Parametertabelle sehen Sie in Abbildung 2.3.
Abbildung 2.3: Tabelle PARAMETER
Jede Zeile der Tabelle PARAMETER
entspricht einem Hyperparameter. Diese Parameter beeinflussen den Ablauf des Trainings, die Verwendung der Variablen und die Struktur des erstellten Baums. Tabelle 2.4 zeigt eine Beispielkonfiguration.
Parameter | Wert | Beschreibung |
---|---|---|
ALGORITHM | 1 | Algorithmus zur Erstellung des Entscheidungsbaums |
HAS_ID | 1 | Erste Spalte ist Schlüssel und soll ignoriert werden |
CATEGORICAL_VARIABLE | EXITED | Kategoriale Variablen |
CATEGORICAL_VARIABLE | HASCRCARD | |
CATEGORICAL_VARIABLE | ISACTIVEMEMBER |
Tabelle 2.4: Einträge des Eingabeargumentes PARAMETER
Der verpflichtende Parameter ALGORITHM legt fest, welcher Algorithmus zum Aufbau des Entscheidungsbaums benutzt wird. Es stehen folgende Parameterwerte zur Verfügung:
- 1: C4.5
- 2: CHAID
- 3: CART (unterstützt Regression und Klassifikation)
Wissenswertes zu Entscheidungsbäumen
Mit der Wahl eines Algorithmus (Hyperparameter ALGORITHM) legen Sie die Strategie fest, mit der aus den Trainingsdaten die Entscheidungsregeln zur Prognose der Zielgröße extrahiert werden. Somit werden durch verschiedene Algorithmen auch unterschiedliche Entscheidungsbäume aufgebaut. Je nach Algorithmus ist sowohl eine Klassifikations- als auch eine Regressionsanalyse möglich. Eine anschauliche Erklärung zu Entscheidungsbäumen bietet Ihnen das Buch »Data Science für Unternehmen« [1, S. 92]. In der genannten Referenz werden diese als »Baumstrukturmodelle« bezeichnet.
Der optionale Parameter HAS_ID gibt an, ob die erste Spalte der Eingabedaten eine reine Identifikationsspalte (z.B. der Primärschlüssel) ist und somit beim Training ignoriert werden soll.
Mit dem Parameter CATEGORICAL_VARIABLE können Sie für Spalten vom Typ INTEGER
festlegen, dass diese als kategoriale Variable behandelt werden sollen. Dies ist insbesondere bei Variablen hilfreich, die eine boolsche Information (WAHR/FALSCH) darstellen oder bei denen der Wert keine Größenangabe, sondern nur eine Kategorienzuordnung darstellt.
Integer-Spalten als kategoriale oder ordinale Variablen
Die Spalte HASCRCARD (hat Kreditkarte) stellt eine boolsche JA/NEIN-Information dar. Sie hat nur die Ausprägungen 0 und 1. Der Trainingsalgorithmus soll sie also als kategoriale Variable behandeln. Die Spalte NUMOFPRODUCTS wird hingegen als nicht-kategoriale Variable interpretiert, da hier auch die Größe der Zahl relevant sein kann.
Standardmäßig bildet die letzte Spalte der Eingabedaten die Zielvariable. Gemäß Listing 2.2 steht für unser Beispiel die Spalte EXITED am Ende. Sie können aber durch Angabe des Parameters DEPENDENT_VARIABLE (in der Eingabetabelle PARAMETER
) auch eine andere Spalte als Zielvariable definieren.
In Listing 2.3 sehen Sie den SQL-Code zum Aufbau der lokalen Tabellenvariablen lt_parameters_tbl
. Diese verwenden Sie beim Aufruf von PAL_DECISION_TREE
als Eingabetabelle für das Eingabeargument PARAMETER
. Fügen Sie – wie oben beschrieben – den SQL-Code am Ende (vor dem END
-Befehl) von Listing 2.2 ein.
-- Einfügen in Quellcode aus Listing 2.2 vor END CREATE LOCAL TEMPORARY COLUMN TABLE
#PAL_PARAMETER_TBL( NAME VARCHAR (50), INT_VALUE INTEGER, DOUBLE_VALUE DOUBLE, STRING_VALUE VARCHAR (100)); INSERT INTO #PAL_PARAMETER_TBL VALUES ('ALGORITHM', 1, NULL, NULL); INSERT INTO #PAL_PARAMETER_TBL VALUES ('HAS_ID', 1, NULL, NULL); INSERT INTO #PAL_PARAMETER_TBL VALUES ('CATEGORICAL_VARIABLE', NULL, NULL, 'EXITED'); INSERT INTO #PAL_PARAMETER_TBL VALUES ('CATEGORICAL_VARIABLE', NULL, NULL, 'HASCRCARD'); INSERT INTO #PAL_PARAMETER_TBL VALUES ('CATEGORICAL_VARIABLE', NULL, NULL, 'ISACTIVEMEMBER'); lt_parameter_tbl = SELECT * FROM #PAL_PARAMETER_TBL; -- Optional: Ausgabe der Parameter-Tabelle -- SELECT * FROM :lt_parameter_tbl;
Listing 2.3: Vorbereiten der Parameter-Tabelle
Nachdem Sie die Tabellenvariablen lt_input_train
und lt_parameter_tbl
gefüllt haben, können Sie das Training durch Aufruf der Prozedur PAL_DECISION_TREE
starten. Ergänzen Sie dazu das Coding aus Listing 2.4 hinter dem Code von Listing 2.3.
_SYS_AFL.PAL_DECISION_TREE ( :lt_input_train, :lt_parameter_tbl, lt_model, lt_decision_rules, lt_confusion_matrix_train, lt_statistics, lt_cross_validation); -- Optional: Ausgabe der Entscheidungsregeln und der -- Konfusionsmatrix SELECT * FROM :lt_decision_rules; SELECT * FROM :lt_confusion_matrix_train;
Listing 2.4: Aufruf der Trainingsprozedur
Die Prozedur PAL_DECISION_TREE
liefert fünf tabellenartige Rückgabeparameter, die den entsprechenden Tabellenvariablen zugewiesen werden, siehe Tabelle 2.5.
Parameter | Beschreibung |
---|---|
MODEL | Das trainierte Modell |
DECISION_RULES | Entscheidungsregeln des Baums |
CONFUSION_MATRIX | Konfusionsmatrix für die Trainingsdaten |
STATISTICS | Statistiken bei Kreuzvalidierung |
CROSS_VALIDATION | Beste Parameterwahl bei Kreuzvalidierung (hier nicht betrachtet) |
Tabelle 2.5: Rückgabeparameter von DECISION_TREE
Der Parameter MODEL
enthält das trainierte Modell, das im nächsten Abschnitt als Eingabe für die PREDICT
-Prozedur eingesetzt wird.
Speichern des Modells zur späteren Verwendung
Da die Modellbeschreibung im Rückgabeparameter MODEL in Tabellenform vorliegt, können Sie sie direkt in einer HANA-Tabelle speichern und bei einer späteren Verwendung wieder laden. Es werden zwei Modellformate unterstützt: JSON und PMML. Das Modellformat steuern Sie durch Angabe des Konfigurationsparameters MODEL_FORMAT im Eingabeparameter PARAMETER
der Trainingsprozedur.
In dem Rückgabeparameter DECISION_RULES
werden die Entscheidungsregeln, nach denen der Entscheidungsbaum einen Kunden den Klassen 0 bzw. 1 zuordnet, in lesbarer Form ausgegeben. Ein Ausschnitt der Regeln ist in Abbildung 2.4 dargestellt.
Abbildung 2.4: Entscheidungsregeln für die Klassifikation
Der Rückgabeparameter CONFUSION_MATRIX
weist die Konfusionsmatrix aus. Diese Matrix zählt die Häufigkeit der Kombinationen aus tatsächlicher Klasse (Spalte ACTUAL_CLASS) und vorhergesagter Klasse (Spalte PREDICTED_CLASS) in der Trainingsmenge. Damit kann ermittelt werden, wie viele Sätze durch das Klassifikationsmodell korrekt und wie viele falsch klassifiziert werden. Einen beispielhaften Inhalt sehen Sie in Tabelle 2.6.
ACTUAL_CLASS | PREDICTED_CLASS | COUNT |
---|---|---|
1 | 1 | 831 |
1 | 0 | 169 |
0 | 1 | 195 |
0 | 0 | 805 |
Tabelle 2.6: Konfusionsmatrix für die Trainingsdatenmenge
In der Spalte ACTUAL_CLASS steht die tatsächliche Ausprägung der Zielvariable, also der Wert aus der Spalte EXITED in den Trainingsdaten. Die Spalte PREDICTED_CLASS enthält den vom trainierten Entscheidungsbaum vorhergesagten Wert. In der Spalte COUNT wird gezählt, wie oft die jeweilige Kombination aus ACTUAL_CLASS und PREDICTED_CLASS in den Trainingsdaten vorkommt.
Eine korrekte Klassifizierung liegt somit vor, wenn die Einträge in ACTUAL_CLASS und PREDICTED_CLASS übereinstimmen. Eine einfache Kennzahl zur Beurteilung des Modells ist die bereits in der Einleitung erwähnte Korrektklassifikationsrate (engl.: accuracy). Sie gibt an, wie hoch der Anteil der korrekt klassifizierten an der Gesamtzahl aller Datensätze ist. Für die Klasse 1 liegt dieser Anteil bei 831 Datensätzen und somit bei ca. 82%, für die Klasse 0 bei 805 Datensätzen. Das Modell klassifiziert also einen Großteil der Trainingsdaten korrekt. Allerdings bedeutet ein gutes Klassifikationsergebnis für die Trainingsdaten nicht unbedingt, dass das Modell auch gute Prognosen für neue Daten liefert, die während des Trainings nicht berücksichtigt wurden. Dazu ist es notwendig, das Modell auf Testdaten anzuwenden und dort die Korrektklassifizierungsrate neu zu ermitteln. Darum kümmern wir uns im nächsten Abschnitt.
Steuerung der Modellkomplexität
Der konstruierte Entscheidungsbaum lässt sich durch einige weitere Hyperparameter beeinflussen. So kann etwa die maximale Größe des Baums begrenzt oder ein Pruning (Stutzen) nach dem Training durchgeführt werden, das den Baum durch einen simpleren Baum mit ähnlich guter Prognoseleistung ersetzt.
Eine einfache Methode zur Steuerung der Komplexität des Baums bietet der Hyperparameter MAX_DEPTH, der die maximal erlaubte Tiefe des Baums vorgibt. Die Tiefe eines Baums entspricht der höchsten Anzahl an Vergleichsbedingungen in den Entscheidungsregeln, also der Anzahl der Verzweigungen entlang eines Pfades. Der einfache Baum in Abbildung 2.1 hat beispielsweise eine Tiefe von 2, da es pro Pfad nur zwei Entscheidungsregeln gibt. Sie können den Hyperparameter MAX_DEPTH durch Erweiterung von Listing 2.3 als ganzzahligen Wert beim Training festlegen. Weitere Hyperparameter finden Sie in der PAL-Dokumentation [9] unter PAL Procedures • Classification Algorithms • Decision Trees.
Overfitting vs. Underfitting
Wenn die Korrektklassifizierungsrate für Ihre Trainingsdaten sehr hoch, für die Validierungs- oder Testdaten hingegen deutlich niedriger sein sollte, ist das sogenannte Overfitting (Überanpassung) eingetreten. Durch die Wahl geeigneter Regularisierungsparameter können Sie das vermeiden, siehe [1]. Welche Regularisierungsparameter geeignet sind, hängt vom Modelltyp ab. Sie werden als Hyperparameter beim Training angegeben.
Wenn allerdings die Korrektklassifizierungsrate bereits für die Trainingsdaten zu niedrig ist, spricht man vom Underfitting (Unteranpassung). Auch in diesem Fall lohnt es sich, an den Hyperparametern zu schrauben, etwa einen anderen Algorithmus für die Extraktion der Entscheidungsregeln zu wählen (gemäß Tabelle 2.4 und den sich anschließenden Erläuterungen). Underfitting kann aber auch ein Hinweis darauf sein, dass der Modelltyp nicht geeignet ist oder die verwendeten Eingabevariablen der Grunddaten nicht ausreichen, die Zielvariable zu erklären.
2.1.2 Testen des trainierten Modells
In diesem Abschnitt wenden Sie das trainierte Modell (aus dem vorherigen Abschnitt) auf neue Daten an, die dem Lernalgorithmus zum Zeitpunkt des Trainings nicht präsentiert wurden. Durch den Vergleich zwischen vorhergesagter und tatsächlicher Klasse lässt sich die Verallgemeinerungsfähigkeit des Modells beurteilen.
Die Prognosebildung wird durch die Prozedur _SYS_AFL.PAL_DECISION_TREE_PREDICT
durchgeführt. Diese Methode hat folgende Eingabeargumente:
DATA
: die Tabelle mit den Eingabedaten für die PrognoseMODEL
: das trainierte Modell für die PrognosebildungPARAMETER
: Parametertabelle zur Steuerung der Prognose
Im Eingabeparameter DATA
übergeben Sie genau die Datensätze der Tabelle CHURN, die beim Training nicht verwendet wurden. Diese befinden sich – nach Ausführung des Codes aus Abschnitt 2.1.1 – in der Tabellenvariablen lt_input_test
(vgl. Listing 2.2). Anders als bei den Trainingsdaten wird aber die letzte Spalte EXITED
nicht übergeben. Diese soll nun vom Modell prognostiziert werden.
Den Befehl zum Aufbau der Eingabedaten finden Sie in Listing 2.5. Fügen Sie, wie gehabt, die Anweisung an das Ende des anonymen Blocks, den Sie im letzten Abschnitt erstellt haben. Beachten Sie, dass auch die weiteren Listings in diesem Abschnitt (Listing 2.6 bis Listing 2.9) immer innerhalb des anonymen Blocks aus Listing 2.2 ergänzt werden.
lt_input_prediction = SELECT CUSTOMERID, CREDITSCORE, GEOGRAPHY, GENDER, AGE, TENURE, BALANCE, NUMOFPRODUCTS, HASCRCARD, ISACTIVEMEMBER, ESTIMATEDSALARY FROM :lt_input_test;
Listing 2.5: Vorbereitung der Eingabedaten für die Prognosebildung
Im Eingabeparameter MODEL
wird das zu verwendende trainierte Modell mitgegeben. Nutzen Sie die lokale Tabellenvariable lt_model
aus Listing 2.4, in der das Modell nach dem Training gespeichert wurde. Die Tabelle PARAMETER
übergeben Sie leer. Das trainierte Modell lässt sich nun mit dem Coding aus Listing 2.6 ausführen.
-- Leere Parametertabelle erzeugen lt_parameters_predict = SELECT * FROM #PAL_PARAMETER_TBL WHERE NULL IS NOT NULL; _SYS_AFL.PAL_DECISION_TREE_PREDICT(:lt_input_prediction, :lt_model, :lt_parameters_predict, lt_pal_result);
Listing 2.6: Anwenden des trainierten Modells auf Testdaten
Die Funktion PAL_DECISION_TREE_PREDICT
hat einen Rückgabeparameter RESULT
. Dieser wird der Tabellenvariablen lt_pal_result
zugewiesen. In dieser Tabelle ist zu jedem Kunden (identifiziert durch CUSTOMERID) die vorhergesagte Klassenzuordnung eingetragen. Durch eine SELECT
-Abfrage wie in Listing 2.7 können Sie sich die ersten 20 Einträge ausgeben lassen.
SELECT TOP 20 * FROM :lt_pal_result;
Listing 2.7: Abfrage der Prognoseergebnisse
Das Ergebnis sehen Sie in Abbildung 2.5: Die Spalte SCORE enthält die vorhergesagte Klasse, die Spalte CONFIDENCE Werte zwischen 0 und 1. Letztere beschreibt, wie sicher die Prognose des Modells auf Basis der zugrunde liegenden Entscheidungsregeln ist.
Abbildung 2.5: Prognoseergebnisse
Als Nächstes berechnen wir auch für die Testdaten eine Konfusionsmatrix unter Verwendung der Funktion PAL_CONFUSION_MATRIX
und können damit die Verallgemeinerungsfähigkeit des Modells beurteilen. Diese Methode hat die folgenden Eingabeparameter:
DATA
: Tabelle, in der für jeden Testdatensatz die vorhergesagte Klassenzuordnung in der Spalte PREDICTED_LABEL und die tatsächliche Klassenzuordnung in der Spalte ORIGINAL_LABEL steht.PARAMETER
: Tabelle, in der Sie Parameter zur Berechnung bestimmter Gütekriterien (s. u.) mitgeben können. Für unsere Betrachtung sind diese Parameter aber nicht relevant.
Zunächst verknüpfen Sie die Prognoseergebnisse der Tabelle lt_pal_result
mit der tatsächlichen Klassenzuordnung aus der Tabelle CHURN. Dieses Ergebnis wird in der Tabellenvariablen lt_input_confusion
gespeichert. Damit können Sie, wie in Listing 2.8 gezeigt, die Methode PAL_CONFUSION_MATRIX
aufrufen.
lt_input_confusion = SELECT CHURN.CUSTOMERID, CONCAT('',CHURN.EXITED) AS original_label, t_predicted.SCORE AS predicted_label FROM CHURN JOIN :lt_pal_result AS t_predicted ON CHURN.CUSTOMERID = t_predicted.CUSTOMERID; lt_parameter_table = SELECT * FROM #pal_parameter_tbl WHERE NULL IS NOT NULL; _SYS_AFL.PAL_CONFUSION_MATRIX(:lt_input_confusion, :lt_parameter_table, lt_confusion_matrix, lt_classification_report); SELECT * FROM :lt_confusion_matrix;
Listing 2.8: Berechnung der Konfusionsmatrix
Betrachten wir die Konfusionsmatrix der Testdaten, siehe Tabelle 2.7. Die Spalte ORIGINAL_LABEL entspricht der Spalte ACTUAL_CLASS und die Spalte PREDICTED_LABEL der Spalte PREDICTED_CLASS von Tabelle 2.6. Der Anteil der falschen Klassifikationen im Vergleich zur Trainingsmenge hat erwartungsgemäß zugenommen: So werden nun 1860 Kunden, die nicht gekündigt haben, fälschlicherweise der Klasse »Kündigung« zugeordnet. Die Testdaten umfassen 8000 Sätze, von denen 5876 (5103 nicht kündigende und 773 kündigende Kunden) korrekt klassifiziert werden. Die Korrektklassifikationsrate liegt bei ca. 73,5% und ist somit für die Testdaten erwartungsgemäß schlechter als die weiter oben ermittelte Rate für die Trainingsdaten, da die Testdaten nicht für das Training verwendet wurden. Ihr Wert erlaubt aber eine realistischere Beurteilung der Verwendbarkeit des Modells.
ORIGINAL_LABEL | PREDICTED_LABEL | COUNT |
---|---|---|
0 | 0 | 5103 |
0 | 1 | 1860 |
1 | 0 | 264 |
1 | 1 | 773 |
Tabelle 2.7: Konfusionsmatrix für die Testdaten
Klassenverteilung in den Testdaten
Anhand von Tabelle 2.7 werden Sie erkennen, dass die Klasse 1 in den Testdaten unterrepräsentiert ist, da sie nur einen Anteil von ca. 13% (statt 20% in den Grunddaten) hat.
Das liegt daran, dass die Testdaten als Komplement zu den Trainingsdaten gebildet wurden, in denen wir absichtlich den Anteil der Klasse 1 erhöht haben.
Die berechnete Korrektklassifizierungsrate für die Testdaten erlaubt somit nur eine eingeschränkte Aussage darüber, welche Genauigkeit das Modell in der Praxis erreichen würde. Insbesondere Fehlklassifikationen von Instanzen der Klasse 1 würden weniger stark ins Gewicht fallen.
Um dem entgegenzuwirken, können Sie je nach Anwendungsfall die Testdaten mit einer für die Gesamtheit repräsentativen Klassenverteilung oder auch mit einer ausgewogenen Klassenverteilung (analog zu den Trainingsdaten) bilden.
Bei der Beurteilung von Klassifikationsmodellen ist es wichtig, die Treffsicherheit des Modells für die einzelnen Klassen mit geeigneten Gütekriterien zu ermitteln.
Ausgefeilte Methoden zur Bewertung eines Klassifikationsmodells berücksichtigen darüber hinaus weitere Faktoren, etwa die erwartete Verteilung der Klassen in den Daten oder die Kosten, die durch Falschklassifikationen entstehen [1, S. 238ff.].
Gütekriterien für die Bewertung von Klassifikationsmodellen
Neben der im letzten Abschnitt eingeführten Korrektklassifizierungsrate sind bei Klassifikationsproblemen weitere Gütekriterien gebräuchlich, mit denen ein Modell insbesondere danach beurteilt werden kann, wie gut die Instanzen einzelner Klassen passend eingeordnet werden. Das Ausgabeargument CLASSIFICATION_REPORT
der Prozedur PAL_CONFUSION_MATRIX
gibt drei häufig verwendete Kennzahlen aus (siehe »Beurteilung eines binären Klassifikators« [8]):
- Recall: Empfindlichkeit oder Sensitivität
- Precision: Genauigkeit
- F Measure: F-Maß
Tabelle 2.8 zeigt das Ergebnis einer SELECT-Abfrage auf die Tabellenvariable lt_classification_report
(Listing 2.9). Zusätzlich löscht das gezeigte Listing als Aufräumaktion die temporäre Tabelle #PAL_PARAMETER_TBL. Damit ist der anonyme Block aus Trainings- und Testphase nun fertig aufgebaut und lässt sich bei Bedarf erneut ausführen.
SELECT * FROM :lt_classification_report; -- Clean-up: Temporäre Tabelle für Parameter löschen DROP TABLE #PAL_PARAMETER_TBL;
Listing 2.9: Abfrage des Klassifikationsreports und Clean-up
CLASS | RECALL | PRECISION | F_MEASURE | SUPPORT |
---|---|---|---|---|
0 | 73,29% | 95,08% | 0,82774 | 6963 |
1 | 74,54% | 29,36% | 0,42125 | 1037 |
Tabelle 2.8: Ausgabe des Klassifikationsreports der Testdaten
Die Bedeutung der Kennzahlen lässt sich am besten an einem einfachen Beispiel veranschaulichen: Die Kennzahl »Recall« für die Klasse 1 zählt, wie viele der Kunden, die tatsächlich in Klasse 1 sind, vom Klassifikationsmodell korrekt in Klasse 1 eingeordnet werden. Aus der Konfusionsmatrix für die Testdaten (Tabelle 2.7) können wir ablesen, dass es insgesamt 1037 Kunden in Klasse 1 gibt, von denen 773 korrekt eingeordnet werden. Wir erhalten also als Recall 74,54%, siehe Formeln in Abbildung 2.6.
Abbildung 2.6: Recall für Klasse 1
Die Kennzahl »Precision« verwendet als Basis die Prognosen des Modells: Für die Klasse 1 wird gezählt, wie viele der Kunden, die vom Modell in Klasse 1 eingeordnet werden, tatsächlich zur Klasse 1 gehören. Erneut lesen wir aus der Konfusionsmatrix (Tabelle 2.7) ab, dass das Klassifikationsmodell von den Testdaten insgesamt 2633 Kunden in die Klasse 1 eingeordnet hat, von denen insgesamt 773 tatsächlich der Klasse 1 angehören. Wie in Abbildung 2.7 abzulesen ist, ergibt sich somit die Precision von 29,36%.
Abbildung 2.7: Precision für Klasse 1
Wie gut ist dieses Modell nun geeignet? Der Recall von ca. 75% bedeutet, dass ein Großteil der zur Abwanderung geneigten Kunden vom Modell erkannt wird und entsprechende Maßnahmen zur Verhinderung der drohenden Kündigung eingeleitet werden können. Umgekehrt bedeutet die Precision von ca. 30% für Klasse 1, dass das Modell zu oft eine drohende Kündigung meldet: In 70% der gemeldeten Fälle liegt nämlich keine Kündigungsgefahr vor und nach diesem Modell getroffene Maßnahmen zur Verhinderung einer Kündigung wären für viele Kunden unnötig. Im weiteren Verlauf des Buches werde ich das Beispiel der Kündigungsvorhersage weiter betrachten und darstellen, wie Sie auch andere Modelltypen für diese Aufgabe einsetzen können.
Bewertung von binären Klassifizierern
Die hier verwendeten Erfolgskennzahlen wie Korrektklassifizierungsrate, Recall etc. werden im Wikipedia-Artikel »Beurteilung eines binären Klassifikators« [8] gut erklärt. Wie man vorgeht, die Eignung eines Klassifikationsmodells fachlich zu bewerten, wird in [1, S. 227ff.] ausführlich erläutert.
All contents. Learn more. Discover now.
et.training - Your learning platform for SAP software
- Access to all learning content1
- Regular new releases
- Intelligent search algorithm
- Innovative reading experience
- Customized learning paths
- Certificates & QA tests2
1 You get access to all learning content. Online trainings, certificates are NOT part of the flat rate.
2 More information on request.