Video: Predictive Analytics in Qlik mit DataRobot

Mit KI in die Zukunft schauen. DataRobot ist eines der praktikabelsten Tools für diesen Zweck. 

In dieser Demo zeigt Ihnen Daniel Brühlmeier Schritt für Schritt, wie man Daten aus Qlik, um sie in DataRobot zu analysieren und wiederum in Qlik auszuwerten.

Transkription:

Guten Tag sehr geehrte Damen und Herren

Mein Name ist Daniel Brühlmeier. Ich bin Data Scientist und BI Consultant bei Heyde

Im ersten Teil unserer zweiteiligen Demo von Predictive- und Szenario Applikationen hat Ihnen Philippe gezeigt, wie Simulationen in Qlik Sense eingesetzt werden können. Im heutigen Teil zeige ich Ihnen, wie ein Predictive-Modell erstellt und in QlikSense implementiert werden kann. Wir starten mit einem kleinen Rückblick auf den ersten Tag.

Unser Ziel ist es, eine Applikation zu bauen, um die Auslastung besser im Griff zu haben, so dass keine Engpässe mehr auftreten. Dafür können wir auf Grundlage der Fallzahlen, die wir in Qlik Sense haben, ein Modell bauen und voraussagen, was ein Wiedereintritt sein wird.

Ich könnte die Fallzahlen zum Beispiel hier in unsere DRG Applikation laden, die Wahrscheinlichkeit für einen Wiedereintritt dann über unser Produkt DataRobot berechnen lassen und die Vorhersage dann wieder zurückgeben.

Zunächst rufe ich in dieser Qlik Sense Applikation meine Bookmarks auf und suche Fälle, die schon kodiert sind – die kann ich dann zum Trainieren verwenden. Damit wir auch noch Testdaten haben, nehme ich am besten gleich Fälle, die "Bereit für Codierung" sind, die haben natürlich die Fall ID drin. Diese Fälle kann ich dann für DataRobot verwenden.

Wechseln wir also zu DataRobot:

Hier kann ich die exportierten Daten aus Qlik Sense hochladen. DataRobot analysiert die Daten und damit das Projekt schneller durchläuft, kann ich die 'workers' auf ein Maximum von 10 hochsetzen.

Wenn die Daten geladen sind, können wir unser Target selektieren. Vorher sollten wir jedoch prüfen, ob alles korrekt von Qlik Sense importiert wurde:

Links sehen wir alle Felder, die geladen wurden - bspw. Geschlecht, Alter und Kanton, dazu die Eintrittsdiagnose, die Hauptdiagnose und natürlich: ob dieser Falle in Wiedereintritt ist. Dieses Feld „Wiedereintritt“ wählen wir als Target aus.

Wir sehen auch, dass wir hier sehr viele kategorische Variablen haben, dazu eine Textvariable – die Eintrittsdiagnose, und auch numerische Variablen – das Alter und die Patienten-ID.

Hier oben gibt mir DataRobot auch die Rückmeldung, dass es keine Probleme mit den Daten gibt. Das haben wir natürlich vor, allem unserem professionellen DataEngineering zu verdanken, die Daten sind gut gepflegt.

Dazu zeigt uns DataRobot Informationen zu unserem Target an: nur sehr wenige Fälle sind ein Wiedereintritt, der Großteil von über zehntausend Fällen sind keine Wiedereintritte, also Erstaufnahmen ins Krankenhaus.

Als Modellierungsmodus wähle ich den Autopilot – mit Cross-Validation und fünf Buckets. Hier bietet mir DataRobot noch zusätzliche Anpassungsmöglichkeiten: Ich ziehe es vor, die Blenders auszuschließen. Weiter unten kann ich noch einmal die positive Klasse überprüfen – das ist hier die 1, das ist richtig, ich möchte ja die Wiedereintritte berechnen. Alles andere sieht auch gut aus und so können wir mit der Auswahl der Modelle starten.

Während DataRobot jetzt im Hintergrund arbeitet, können wir uns noch einige Informationen anschauen:

Nehmen wir bspw. das Geschlecht – hier haben wir eine weitestgehende Gleichverteilung zwischen Frau und Mann, das sieht gut aus.

In dieser Spalte zeigt uns DataRobot bereits mit einer grünen Markierung an, wie wichtig das Feature ist – hier sehen wir schon, dass die Hauptdiagnose, der Zuweiser und der Arzt deutlich wichtiger sind als bspw. Geschlecht, Kanton oder die Versicherungsklasse.

Der Blick auf die Hauptdiagnose zeigt viele verschiedene Werte, das ist gut... Einen besonders hohen Wert hat die Hauptdiagnose I21.4 – wenn ich das in unserem DRG-Katalog nachschlage, sehe ich: Die Diagnose I21.4 ist ein Krankheitsbild, das mit einer Herzschwäche zu tun hat.

Hier rechts sehe ich bereits, dass die verschiedenen Modelle durchgerechnet werden. Mit unserer Partner Version kann ich maximal 10 Modelle parallel laufen lassen.

Nach der Berechnung

Wenn DataRobot die Berechnung der Modelle abgeschlossen hat, wird angezeigt, welches davon am besten performt. Hier ist es das Light Gradient Boosting on ElasticNet Predictions – BluePrint 79. Das wurde auch schon zum Deployment fertiggestellt, aber zunächst schaue ich es mir noch näher an:

Hier sehen wir den BluePrint mit Darstellung aller Variablen:

Aus den Textvariablen wird eine Matrix von Wörtern gemacht, die letztendlich einem Classified hinzugefügt werden.

Kategorische Variablen werden entweder mit One-Hot-Encoding übersetzt oder mit dem Original Encoding übernommen.

Numerische Werte werden dem Light Gradient Boosting on ElasticNet Predictions entweder direkt hinzugefügt – oder sie durchlaufen noch einen Standardisierungsprozess über den ElasticNet Classifier.

Wenn wir zur Liste der verfügbaren Modelle zurückgehen, dann sehen wir, dass die obersten Listenplätze alle sehr nah beieinanderliegen. Wir könnten also auch den ExtraTrees Classifier verwenden oder ein Logistic Regression. Der Blick auf die Lernkurve zeigt, dass wir mit dem Modell 65, wo der Blueprint 79 ist, ein sehr gutes Ergebnis haben. Je mehr Daten das Modell für das Training erhält, desto besser wird der Validation Score.

Entscheidend für die Auswahl war aber vermutlich die Geschwindigkeit – da ist der Light Gradient Boosting on ElasticNet einfach viel schneller, wenn wir das auf dem 100 % Sample machen.

Gewichtung und Algorithmus verstehen

Schauen wir uns diesen Algorithmus also noch einmal näher an: Über den Menüpunkt „Understand“ zeigt mir DataRobot an, welchen Einfluss die einzelnen Features haben – ab Alter, Art, FallPatient geht es immer weiter herunter, ganz unten steht das Geschlecht oder der Kanton mit sehr wenig Aussagekraft für das Modell.

Über die FeatureEffects zeigt mir DataRobot, dass wir zum Beispiel bestimmte Zuweiser haben, bei denen ein Wiedereintritt sehr wahrscheinlich ist. Auf diese Zuweiser gilt es künftig also ein spezielles Augenmerk zu haben. Beim Blick auf die Hauptdiagnose sehe ich wieder die I21.4, den Herzinfarkt, als Diagnose, bei der es sehr viele Wiedereintritte gibt. Dazu gibt es einige weitere Diagnosen, bei denen es ähnlich viele Wiedereintritte gibt.

Interessant ist auch der Blick auf die ROC Kurve: Hier sehe ich, wie gut das Modell performt. Die Fläche unter der Kurve, das AUC hat einen Wert von 0,82 – das heißt, es bietet eine sehr zuverlässige Unterscheidung, in welchen Fällen es einen Wiedereintritt gibt.

Als wichtige Aufgabe bleibt mir hier noch, den Prediction Threshold zu setzen. Dabei verwende ich Werte zu den Kosten der verschiedenen Szenarien:

Ein True Negative wäre ein Patient, für den korrekt prädiktet ist, dass es keinen Wiedereintritt gibt – das kostet uns nichts.

Ein False Positive wäre ein Patient, für den es keinen Wiedereintritt geben würde und den wir trotzdem nochmal prüfen – das kostet uns 500.

Ein False Negative wäre ein Patient, dessen Wiedereintritt wir nicht erkennen – das ist der größte Kostenpunkt mit 2000.

Ein True Positive ist ein Patient, dessen Wiedereintritt wir verhindern können – hier sparen wir 1500.

Aus diesen Daten berechnet DataRobot den optimalen Threshold – dieser liegt hier bei 0,1547 und dieser Wert wird auch in der ROC Kurve verwendet. Den kann ich auch gleich weiterverwenden für das Deployment.

Modell Deployment

Wenn ich das Modell deployen möchten, habe ich zwei Möglichkeiten: Ich kann entweder täglich einen CSV-File hochladen, was natürlich sehr aufwändig wäre. Alternativ kann ich das über das API ansprechen:

Dafür prüfe ich ein letztes Mal die Einstellungen – das Modell, die positive Klasse, den Treshold.

Dazu lege ich fest, dass die Fälle über eine Fall-ID identifiziert werden – so ist klar, welche Fälle bereits klassifiziert wurden.

Dazu schalte ich auch den DataDrift ein.

Damit habe ich das Deployment vollständig konfiguriert – und nun warte ich auf die Resultate.

Hier bekomme ich gerade die Meldung, dass das Model vollständig deployed ist. Das kann ich mir auch anschauen – das sind die Parameter, wann wurde was erstellt... da gibt es aktuell noch keine Inhalte, da noch gar nichts über das API angesprochen wurde.

Damit das geschehen kann, brauche ich zusätzlich in Qlik Sense eine Server-Side Extension:

Hier habe ich mich entschieden, ein Docker Image zu erstellen, dieses in Microsoft Azure zu verwenden und damit eine Schnittstelle zwischen Qlik Sense und DataRobot zu implementieren. Damit das Laden der Ressourcen schneller geht, habe ich ein kleines Bash-Script geschrieben, das setzt alles automatisch auf.

Das Image wird jetzt auch in den ‚Resources‘ angezeigt... genau... und unter dieser URL kann ich das dann konfigurieren in der Qlik Management Console.

In der QMC kann ich eine neue Analytics Connection anlegen. Hier gebe ich ein:

• den Namen
• den Host – so wie in Azure konfiguriert
• den Port – den Default Port, den ich im Image gesetzt habe

Das bestätige ich mit [Apply] und dann kann ich diese Server-Side Extension in der Applikation verwenden.

In der Applikation kann ich dann versuchen, die Server-Side Extension anzusprechen. Dazu lade ich sie nochmals neu – und nach dem Reload sehe ich hier unten das Test-Sample. Um zu sehen, ob alles in Ordnung ist, rufe ich hier eine Funktion auf: Hier habe ich ein Datenfeld, und der Wert, den ich hier eingebe, wird mir durch die SSE Funktion HelloWorld wieder genauso zurückgegeben – soweit ist also alles in Ordnung.

Im nächsten Schritt gehe ich in den Data Load Editor, um die Daten und die Konfiguration für das DataRobot Deployment zu setzen. Das Skript ist hier sehr rudimentär und einfach aufgesetzt. Wir laden die Daten, die wir sowieso in der Faktentabelle hätten, über dieses CSV. Die FID ist natürlich das Schlüsselfeld – das wird später auch verwendet, um die in DataRobot predicteten Daten wieder zurückzuladen und mit den Stammdaten zu matchen.

Neben der Faktentabelle laden wir in einer zweiten Tabelle die Data to Predict – auch wieder mit der FID als Schlüsselfeld.

Beim Deployment müssen wir das aktuelle Deployment von DataRobot verwenden. Die Informationen dazu bekommen wir hier über -> Prediction -> Prediction API -> dort können wir das Deployment mit der ID rauslesen und hier einsetzen.

Dazu habe ich in Qlik Sense eine Funktion geschrieben, die die ganze Logik kapselt. Dieser Funktion geben wir folgende Argumente an:

• die Faktentabelle, wo wir unsere prädikteten Daten hinzufügen möchten
• die Tabelle, wo wir die Prediction drin haben
• für die Server-Side Extension gibt es allgemeine Argumente – bspw. ob es im Debug-Mode laufen soll, DataRobot-spezifische Argumente – die URL, die APIKey und die DataRobotKey ... und zum Schluss noch die oben gesetzte DeploymentID

Damit sind wir parat, die Daten zu laden:

Jetzt haben wir nach nur 2 Sekunden die neuen Werte und können sie hier im Datenmodell, also im Data Modell Viewer prüfen:

Hier habe ich also die Faktentabelle, die zum einen aus den bestehenden ERP-Daten gefüllt wird und zum anderen die Prediction drin hat. Daneben sieht man auch noch die Hello-World-Table, die ich zu Testzwecken erstellt habe.

Schauen wir uns das ganze in der Applikation an:

Hier sehen wir die ERP-Daten – natürlich ohne Prediction-Wert, aber mit den tatsächlichen Angaben zum Wiedereintritt, die für das Erstellen und Trainieren des Datenmodells verwendet wurden.

Gehen wir zu den Daten, die wir von DataRobot gesendet haben, sieht man hier die FID, kein Feld mit Wiedereintritt, aber dafür hier die Prediction.

Dazu kann ich natürlich prüfen, ob das an den richtigen Ort geschickt wurde: Hier sehe ich die Zahl der Requests auf dieser API. Dazu kann ich den DataDrift prüfen und auch die Endresultate, um zu sehen: Wie gut war die Prediction wirklich? Dazu kann ich die Daten hochladen und sehe dann in der ‚Accuracy‘, wie gut mein Modell abgeschnitten hat.

Die ganze Kommunikation zwischen Qlik Sense und DataRobot läuft weiterhin unter unserem Docker Image:

Hier sehen wir, dass die Extension oder das Image sehr sehr klein ist, aber auch gar noch nicht groß ausgelastet, das heißt wir brauchen aktuell eine CPU und gerade mal 500 MB Memory.

Zusammenfassung:

Fassen wir das Ganze noch einmal kurz zusammen:

ich habe für die Auslastung von Philipp ein Modell gemacht,

habe die Daten aus QlikSense exportiert

habe darauf ein Trainingsdaten erstellt, dieses in DataRobot reingeladen, das beste Modell genommen und es grundsätzlich geprüft, ob es einen Mehrwert geben wird – das war hier der Fall

habe es über die Server-Side Extension direkt an QlikSense gehängt, so dass ich in Zukunft täglich automatisch neue Predictions auf die offenen Fallzahlen erstellen kann –

und damit kann ich eben frühzeitig erkennen, ob ein Fall ein Wiedereintritt wird oder nicht.