Data Science & AI

Am PROSET-Forschungsprojekt arbeiteten die TU München, die ETH Zürich und b.telligent für insgesamt drei Jahre, von Februar 2011 bis Februar 2014. Im Mittelpunkt standen Fragestellungen, für deren Bearbeitung im gewöhnlichen Arbeitsalltag meist keine Zeit bleibt. Dabei werden oftmals Fragen behandelt, die nicht nur für die Praxis relevant sind, sondern auch neue Erkenntnisse für die Forschung ans Licht bringen. Im PROSET-Projekt haben wir uns der Frage der Produktivitätssteigerung durch Service Experience Management gewidmet.

Eine besonders fruchtbare aktuelle Diskussion dreht sich um die Frage, was ein Data-Science-Team eigentlich sinnvollerweise herstellt. Die beiden Möglichkeiten sind dabei schnell benannt: Auf der einen Seite steht die "Analyse", also ein einmalig erstelltes, eher statisches Endergebnis; die meisten denken hier sofort an eine PowerPoint-Präsentation. Auf der anderen Seite steht die "App", also ein interaktives, ständig mit frischen Daten versorgtes Endprodukt, häufig in Form einer Website oder einer Mobile App.

Ich bin vor kurzem umgezogen und wurde von meiner alten Hausverwaltung gebeten, die Wände und die Decken der verlassenen Wohnung zu streichen. Ich habe mich sogleich im Internet um Vergleichsangebote von Malerbetrieben bemüht. Dort sollte ich gleich zu Beginn die zu streichende Fläche in Quadratmetern angeben ... mmh, ich hätte natürlich sofort die Grundfläche und die Anzahl Räume angeben können und gehofft, dass die Betriebe eine einfache Hochrechnung für die Angebotserstellung verwenden. Aber direkt die zu streichende Fläche zu ermitteln, schien mir etwas komplexer als eine Schätzung aus dem Stegreif.

Die Behauptung „Python ist keine typisierte Sprache“ erhöht meinen Puls mittlerweile genauso wie das vor vielen Jahren übliche „Python ist nur eine Scriptsprache“.Man muss nur schnell eine Python-Konsole öffnen und 1+"1" eingeben. Das Ergebnis ist nicht, wie z. B. bei PHP, eine 2, sondern ein TypeError. Python ist sehr wohl stark typisiert und unterscheidet zudem auch noch zwischen mutable und immutable types. Da der Code in Python erst zur Laufzeit kompiliert wird, fällt der gerade genannte Additionsfehler an sich nicht beim Programmieren, sondern erst bei der Ausführung auf.‍

SAS und R sind Themen, die dicht beieinanderliegen: Beides sind populäre Werkzeuge für Leute wie uns, die Probleme aus dem Umfeld von Statistik und Machine Learning auf mehr oder weniger großen Datenmengen lösen möchten. Trotz dieser scheinbaren Nähe gibt es wenig Berührungspunkte zwischen den beiden Communitys, und nur wenige arbeiten mit beiden Werkzeugen. Als passionierte Über-den-Tellerrand-Blicker finden wir das schade und möchten mit diesem Blogeintrag eine Miniserie starten, in der wir uns in loser Folge mit Themen beschäftigen, die beide Welten miteinander verbinden. Für diesen ersten Blogeintrag werden wir uns mit den Möglichkeiten beschäftigen, Daten zwischen den Systemen auszutauschen. Da es eine große Vielzahl an Wegen gibt, beschränken wir uns für diese Folge auf den Transfer von SAS zu R; der entgegengesetzte Weg folgt in einem späteren Eintrag.

Uplift-Modeling kann Kampagnenmanager bei der Kampagnensteuerung und -planung unterstützen, da es das klassische Response-Modell des Kampagnenscorings ergänzt. Uplift-Modeling geht von der Grundidee aus, dass man die Kampagnenreagierer in zwei Gruppen einteilt: diejenigen, die auch ohne die Kampagne reagiert hätten, und die, die das ohne die Kampagne nicht getan hätten. Während klassisches Scoring unterschiedslos auf beide Gruppen abzielt, versucht das Uplift-Scoring, exklusiv nur die zweite Gruppe zu isolieren und dabei die erste möglichst zu ignorieren. Zu diesem Zweck werden die Responseinformationen aus der Kontrollgruppe verwendet, die im klassischen Kampagnenscoring ungenutzt bleiben.