SAP reference books

Exceptionally Well Written !!

G. Mayer

Machine Learning mit SAP HANA

Seit einigen Jahren preist die SAP das intelligente Unternehmen als Wettbewerbsvorteil an. Mit diesem Buch springen Sie mitten hinein in die Welt der künstlichen Intelligenz (KI). Erfahren Sie, welche Algorithmen die leistungsstarke In-Memory-Datenbank SA...

10% discount

Get a 10% discount now! Sign up for our newsletter and receive a 10% discount on the digital subscription for our SAP learning platform!

Table of content

  • Vorwort
  • 1 Einleitung
  • 2 Predictive Analysis Library mit SQLScript
  • 3 Automated Predictive Library mit SQLScript
  • 4 Der Python Machine Learning Client für SAP HANA
  • 5 Text Mining
  • 6 Integration in SAP-Anwendungen
  • 7 Aufbau einer Testumgebung
  • 8 Fazit und Ausblick
  • A Der Autor
  • B Quellcodeverzeichnis
  • C Literaturverzeichnis
  • D Disclaimer

More informationen

Author:

Benedict Baur

Category:

SAP-Programming

Language:

German

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.

ALT

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.

ALT

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 Tabellenvariable lt_input. Die Tabellenvariable lt_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 aus lt_input, deren Kundennummern in lt_id_train vorkommen. Diese Sätze werden für das Training des Modells verwendet.
  • lt_input_test: enthält die Datensätze aus lt_input, die nicht für das Training ausgewählt wurden, also das Komplement zu lt_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.

ALT

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.

ALT

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 Prognose
  • MODEL: das trainierte Modell für die Prognosebildung
  • PARAMETER: 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.

ALT

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.

ALT

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%.

ALT

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

You already have an account?

1 You get access to all learning content. Online trainings, certificates are NOT part of the flat rate.

2 More information on request.