Tag Archive for: Data Science

Interview – die Zukunft des Data Science

Interview mit Herrn Dr. Helmut Linde von SAP über Data Science heute und in Zukunft

dr-helmut-lindeHerr Dr. Helmut Linde ist Head of Data Science bei SAP Custom Development. Der studierte Physiker und Mathematiker promovierte im Jahre 2006 und war seitdem für den Softwarekonzern mit Hauptsitz in Walldorf tätig. Dort baute Linde das Geschäft mit Dienstleistungen und kundenspezifischer Entwicklung rund um die Themen Prognose- und Optimierungsalgorithmen mit auf und leitet heute eine globale Data Science Practice.

Data Science Blog: Herr Dr. Linde, welcher Weg hat Sie in den Analytics-Bereich der SAP geführt?

Als theoretischer Physiker habe ich mich natürlich immer schon für die mathematische Modellierung komplexer Sachverhalte interessiert. Gleichzeitig finde ich es extrem spannend, geschäftliche Fragestellungen zu lösen und dadurch in der realen Welt etwas zu bewegen. Die SAP mit ihrer weltweiten Präsenz in allen größeren Branchen und ihrer umfassenden Technologie-Plattform hat mir die ideale Möglichkeit geboten, diese Interessen zusammenzubringen.

Data Science Blog: Welche Analysen führen Sie für Ihre Kundenaufträge durch? Welche Vorteile generieren Sie für Ihre Kunden?

Mein Team arbeitet global und branchenübergreifend, d.h. wir befassen uns mit einer großen Bandbreite analytischer Fragestellungen. Oft geht es dabei darum, das Verhalten von Endkunden besser zu verstehen und vorherzusagen. Auch die Optimierung von Lieferketten und Lagerbeständen ist ein häufiger Anwendungsfall. In unseren Projekten geht es z.B. darum, den Absatz von Tageszeitungen zu prognostizieren, Schichten für Call-Center-Mitarbeiter optimal zu planen, Lastspitzen in Stromnetzen zu vermeiden und vieles andere mehr.

Das Hauptaugenmerk meines Teams liegt dabei auf der Entwicklung von analytischen Software-Lösungen. Für unsere Kunden heißt das, dass sie nicht nur einmalig Wettbewerbsvorteile aus ihren Daten ziehen, sondern Prognosen und Optimierung wiederholbar, nachhaltig und skalierbar in ihre Geschäftsprozesse integrieren können. Außerdem profitieren Kunden natürlich von der Größe der SAP und unserer langjährigen Erfahrung. Bei den allermeisten Anfragen können wir sagen: „Ja, etwas sehr ähnliches haben wir schon einmal gemacht.“

Data Science Blog: Viele Unternehmen haben den Einstieg ins Data Science noch nicht gefunden. Woran hängt es Ihrer Erfahrung nach?

Zunächst einmal sehe ich – basierend auf der Menge an Anfragen, die auf meinem Schreibtisch landen – einen äußerst positiven Trend, der zeigt, dass in vielen Unternehmen das Thema Data Science enorm an Bedeutung gewinnt.

Andererseits gibt es sicherlich Fachgebiete, die leichter zugänglich sind. Nicht in jedem Unternehmen gibt es die kritische Masse an Expertise und Unterstützung, die für konkrete Projekte nötig ist.

Data Science Blog: Welche Möglichkeiten bietet Data Science für die Industrie 4.0?

Unter Industrie 4.0 verstehe ich eine immer stärkere Vernetzung von Maschinen, Sensoren und Erzeugnissen. Schon für das Zusammenführen und Bereinigen der dabei anfallenden Daten wird man einen steigenden Grad an Automatisierung durch Algorithmen benötigen, da ansonsten die manuellen Aufwände viele Anwendungsfälle unwirtschaftlich machen. Darauf aufbauend werden Algorithmen den Kern vieler neuer Szenarien bilden. Mit einigen unserer Kunden arbeiten wir beispielsweise an Projekten, bei denen die Qualität von Endprodukten anhand von Maschineneinstellungen und Sensorwerten vorhergesagt wird. Dies erlaubt eine präzisere Steuerung der Produktion und führt zu reduziertem Ausschuss.  Ein anderes Beispiel ist ein Projekt mit einer Eisenbahngesellschaft, bei dem wir automatisch gewisse Stromverbraucher wie Heizungen oder Klimaanlagen für wenige Minuten abschalten, wenn im Stromnetz eine unerwünschte Lastspitze vorhergesagt wird.

Data Science Blog: Welche Tools verwenden Sie bei Ihrer Arbeit? Setzen Sie dabei auch auf Open Source?

In unseren Projekten orientieren wir uns immer an den Notwendigkeiten des konkreten Anwendungsfalles und an der bereits vorhandenen IT-Landschaft beim Kunden. Schließlich muss unsere Lösung dazu passen und sauber integriert und gewartet werden können. Natürlich kommen häufig hauseigene Werkzeuge wie SAP Predictive Analysis für die Modellbildung oder SAP Lumira für schnelle Visualisierung zum Einsatz. Als Plattform spielt SAP HANA eine große Rolle – nicht nur zur Datenhaltung, sondern auch zur Ausführung von Algorithmen und als Anwendungsserver. In SAP HANA gibt es auch eine Schnittstelle zu ‚R‘, so dass in manchen Projekten auch Open Source zum Einsatz kommt.

Data Science Blog: Was sind aktuelle Trends im Bereich Data Science? Um welche Methoden dreht es sich aktuell besonders stark bei SAP?

Einer der größten Trends der letzten Jahre ist sicherlich die zunehmend ganzheitliche Nutzung von Daten, insbesondere auch von rohen, unstrukturierten Daten gepaart mit einem höheren Grad an Automatisierung. Wo vor vielleicht fünf oder zehn Jahren noch großer Wert auf Datenvorverarbeitung und Feature Engineering gelegt wurde, werden diese Schritte heute zunehmend von den Tools selbständig durchgeführt.

Gleichzeitig wachsen klassisches Business Intelligence und Data Science immer mehr zusammen. Wir sehen eine steigende Zahl von Projekten, in denen Kunden analytische Lösungen implementieren, welche in Komplexität und Funktionsumfang deutlich über traditionelle Berichte und Dashboards hinausgehen, dabei aber durchaus ohne fortgeschrittene Mathematik auskommen.

Data Science Blog: Sofern Sie sich einen Ausblick zutrauen, welche Trends kommen 2017 und 2018 vermutlich auf uns zu?

Data-Science-Methoden und traditionelle Geschäftsprozesse werden immer enger verzahnt. In Zukunft übernehmen Algorithmen viel mehr jener Tätigkeiten, die auch nach umfassender Prozessautomatisierung heute immer noch von Sachbearbeitern zu erledigen sind – zum Beispiel eingehende Zahlungen einer Rechnung zuzuordnen, Lebensläufe von Bewerbern vor zu sortieren, die Plausibilität von Abrechnungen zu prüfen und Ähnliches.

Data Science Blog: Gehört die Zukunft weiterhin den Data Scientists oder eher den selbstlernenden Tools, die Analysen automatisiert für das Business entwickeln, durchführen und verbessern werden?

Es gibt definitiv einen Trend zu stärkerer Automatisierung bei den Tools und den starken Wunsch, Kompetenzen näher an die Endanwender zu bringen. Analysen werden zunehmend in den Geschäftsbereichen selbst durchgeführt.

Gleichzeitig sehe ich einen Wandel in der Rolle des Data Scientist. Es reicht nicht mehr, viele Algorithmen und ein paar Data Mining Tools im Detail zu kennen, um wirklich Mehrwert zu stiften. Der Data Scientist der Zukunft ist ein Vordenker, der ganzheitliche Visionen entwickelt, wie geschäftliche Fragestellungen mit Hilfe von Analytik gelöst werden können. Dabei müssen neue oder geänderte Geschäftsprozesse, ihre technische Umsetzung und algorithmische Lösungen gleichermaßen angegangen werden. Nehmen Sie als Beispiel das Thema Predictive Maintenance: Es gibt viele Data Scientists, die aus Sensordaten etwas über den Zustand einer Maschine ableiten können. Aber nur wenige Experten verstehen es, dies dann auch noch sinnvoll in reale Instandhaltungsprozesse einzubetten.

Die Nachfrage nach einem solchen Rollenprofil, für das es heute noch nicht einmal einen wirklich treffenden und allgemein gebräuchlichen Namen gibt, wird auch in Zukunft weit höher sein als die Verfügbarkeit von qualifizierten Kandidaten.

Data Science Blog: Wie sieht Ihrer Erfahrung nach der Arbeitsalltag als Data Scientist nach dem morgendlichen Café bis zum Feierabend aus?

Unsere Arbeitstage sind sehr abwechslungsreich. Jeder Data Scientist hat meistens ein größeres Kundenprojekt, das 60% bis 90% der Arbeitszeit benötigt. Dazu gehören normalerweise Workshops beim Kunden vor Ort – je nach Projekt und Standort können das zwei Tage in der Schweiz oder auch mal zwei Wochen in China sein. Außerdem fließt natürlich viel Zeit in die Analyse und Visualisierung von Daten, das Programmieren von Algorithmen und Anwendungen sowie die Erstellung von Unterlagen. Manchmal arbeiten wir nebenbei noch an einem anderen kleineren Projekt, zum Beispiel der Entwicklung eines Prototyps für eine Kundenpräsentation.

Einen Großteil unserer Projektarbeit liefern wir remote, das heißt, wir sind nur zu Workshops oder bei besonderem Bedarf beim Kunden vor Ort. Die Entwicklungs- und Analysearbeit erfolgt dann aus dem Büro oder, je nach Präferenz, auch aus dem Home Office. Insgesamt ermöglicht die Arbeitsweise eine gute Work-Life-Balance für alle Lebensmodelle.

Data Science Blog: Welches Wissen und welche Erfahrung setzen Sie für Ihre Data Scientists voraus? Und nach welchen Kriterien stellen Sie Data Science Teams für Ihre Projekte zusammen?

Der Großteil unserer Data Scientists hat einen akademischen Hintergrund mit Promotion und teilweise auch Post-Doc-Erfahrung in einem quantitativen Feld. Man sollte neben oder nach dem Studium schon einige Jahre praktische Erfahrung in quantitativen Analysen und idealerweise auch in Software-Entwicklung gesammelt haben, um als Data Scientist in Projekten erfolgreich zu sein. Daneben ist uns eine hohe Selbständigkeit und Eigenmotivation sehr wichtig, da wir in Projekten mit sehr unterschiedlichen Herausforderungen und vielen neuen und wechselnden Technologien konfrontiert sind, die hohe Umsicht und Flexibilität erfordern.

Unsere Projektteams stellen wir je nach Anforderungen zusammen. Bei Projekten, die stärker auf das Ergebnis einer Analyse abzielen, stellen wir oft ein kleines Projektteam komplett aus geeigneten Data Scientists zusammen. Wenn der Fokus stärker in Richtung eines Software-Produkts geht, wird häufig nur der analytische Kern und ggf. Anforderungs- und Projektmanagement von Data Scientists aus meinem Team übernommen. Dazu stoßen dann noch Kollegen aus anderen Bereichen, die beispielsweise Erfahrung mit bestimmten Backend-Technologien, als Software-Architekt, oder als UX-Designer mitbringen.

Data Science Blog: Grenzen Sie auch andere Rollen ab, wie beispielsweise den Data Engineer? Oder sind beide Tätigkeitsfelder untrennbar miteinander verbunden?

Aus meiner Sicht ist es wichtig, dass der Data Scientist, der für die Analyse der Daten verantwortlich ist, so weit wie möglich auch in die Vorverarbeitung und Vorbereitung der Daten mit einbezogen wird. Je nach Projekt können gewisse Tätigkeiten auch von Kollegen mit anderem Profil übernommen werden, aber die dedizierte Rolle eines Data Engineers gibt es bei uns nicht.

Data Science Blog: Sind gute Data Scientists Ihrer Erfahrung nach tendenziell eher Beratertypen oder introvertierte Nerds?

Ein wirklich guter Data Scientist passt weder in die eine noch in die andere Schublade. Sie oder er überzeugt in erster Linie durch Kompetenz – und zwar sowohl in geschäftlichen Fragestellungen als auch in technischen und mathematischen. Gleichzeitig ist die Fähigkeit notwendig, gegenüber Projektpartnern und Kunden überzeugend aufzutreten und komplexe Sachverhalte klar und anschaulich zu strukturieren.

Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftslehre, abgeschlossen haben, was würden sie diesen jungen Damen und Herren raten, wie sie einen guten Einstieg ins Data Science bewältigen können?

Seien Sie neugierig und erweitern Sie Ihren Horizont! Die führenden Data Scientists sind Unternehmensberater, Software-Architekt und Mathematiker in einer Person. Versuchen Sie, systematisch Erfahrung in allen drei Bereichen aufzubauen.

Interview – Erfolgreicher Aufbau einer Data Science Kompetenz

Interview mit Dr. Dirk Hecker vom Fraunhofer IAIS über den erfolgreichen Aufbau einer Data Science Kompetenz

dr-dirk-heckerDr. Dirk Hecker ist Geschäftsführer der »Fraunhofer-Allianz Big Data«, einem Verbund von 28 Fraunhofer-Instituten zur branchenübergreifenden Forschung und Technologieentwicklung im Bereich Big Data. Außerdem leitet Dr. Hecker die Abteilung »Knowledge Discovery« am Fraunhofer-Institut für Intelligente Analyse- und Informationssysteme IAIS. Die Forschungs­schwerpunkte der Abteilung liegen im Data Mining und Machine Learning. Darüber hinaus verantwortet Dr. Hecker das Data-Scientist-Qualifizierungsprogramm bei Fraunhofer und leitet die Arbeitsgruppe »Smart Cities« im »Smart Data Innovation Lab«. Herr Hecker ist in Mitglied der »Networked European Software and Services Initiative (NESSI)« und hat langjährige Erfahrung in der Leitung von Forschungs- und Industrieprojekten. Seine aktuellen Arbeitsschwerpunkte liegen in den Bereichen Big Data Analytics, Predictive Analytics und Deep Learning.

Data Science Blog: Herr Dr. Hecker, welcher Weg hat Sie zu Fraunhofer geführt und wie treiben Sie Data Science bei Fraunhofer voran?

Ich habe bereits als Student bei Fraunhofer angefangen und nach Abschluss meines Studiums schnell die Leitung einer Arbeitsgruppe übertragen bekommen. Unser Schwerpunkt war damals das Thema Mobility Mining, die automatisierte Extraktion von Mustern aus GPS, Mobilfunkdaten sowie Induktionsschleifenmessungen, vor allem zur Verkehrsmodellierung. Als uns 2012 die Big-Data-Welle erreichte und ich die Abteilung „Knowledge Discovery“ übernahm, haben wir die erste Potenzialanalyse für Big Data in Deutschland veröffentlicht und es fiel der Startschuss für unser Data-Science-Schulungsprogramm, da wir das Unterstützungspotenzial für Unternehmen im Bereich Data Science sofort erkannt haben. Mit der Gründung der Fraunhofer-Allianz Big Data vor jetzt fast drei Jahren konnten wir unser Angebot „Beratung, Technologie, Schulung“ branchenübergreifend ausbauen. Ein Beispiel ist der „Big Data Business Club“, eine exklusive Plattform für Chief Digital oder Data Officers (CDOs) in Unternehmen. Wir beraten und unterstützen Unternehmen branchenübergreifend bei der Umsetzung ihrer Big-Data-Projekte und entwickeln die passenden Tools und Softwareprodukte.

Data Science Blog: Könnten Unternehmen die Projekte nicht einfach in den jeweiligen Fachbereichen direkt selbst umsetzen? Oder in der zentralen Unternehmens-IT-Abteilung?

Für die Datenanalyse braucht man Experten, also Data Scientists. Die gibt es in vielen Fachabteilungen zunächst nicht, und oft auch noch nicht in der zentralen IT. Da ist es ein guter Weg, die Kompetenzen beim eigenen Personal in Kooperationsprojekten mit erfahrenen Partnern aufzubauen.

Data Science Blog: Sie bieten bei Fraunhofer ein sogenanntes „Data Science Starter Toolkit“ an, wofür brauchen Unternehmen ein weiteres Toolkit?

Bevor sie in eine Big-Data-Plattform investieren und sich damit längerfristig binden, können Unternehmen in diesem Toolkit eine breite Palette aktueller Big Data- und In-Memory-Technologien  erproben und sich hier beraten lassen. Außerdem erleichtert das Toolkit die nicht-kommerzielle Kooperation mit akademischen Partnern. Das ist besonders in der Anfangsphase interessant, wenn überhaupt erst das Potenzial in den eigenen Daten exploriert werden soll.

Data Science Blog: Sie bearbeiten Anwendungsfälle unterschiedlicher Branchen. Können sich Branchen die Anwendungsfälle gegenseitig abschauen oder sollte jede Branche auf sich selbst fokussiert bleiben?

Gute Branchenkenntnis ist für uns unerlässlich, denn jede Branche hat ihre Besonderheiten, etwa was die Prozesse oder auch die Datenquellen anbelangt. Dennoch können sich Unternehmen an Best-Practice-Beispielen aus anderen Branchen orientieren. Darum arbeiten wir auch in der Fraunhofer-Allianz Big Data instituts- und branchenübergreifend zusammen. Unsere Kunden schätzen es gerade in der Bratungs- und Ideenfindungsphase, wenn sie über den Tellerrand schauen können und Beispiele aus anderen Branchen vorgestellt bekommen. Außerdem lassen sich externe Datenquellen in verschiedenen Branchen nutzen: Social Media, Mobilfunkdaten, Wikipedia, Nachrichtenkanäle.  Schließlich erwarten wir im Bereich des Deep Learning, dass man bild-, sprach- und textverarbeitende Module in Zukunft vortrainieren und dann mit weniger Aufwand auf die Anwendung spezialisieren kann.

Data Science Blog: Welche Trends im Bereich Machine Learning bzw. Deep Learning werden Ihrer Meinung nach im kommenden Jahr 2017 von Bedeutung sein?

Schon heute ist das maschinelle Lernen die Schlüsseltechnik für die Echtzeitanalyse von Big Data, also die Überwachung und Automatisierung von Prozessen jeglicher Art. Deep Learning erschließt aktuell insbesondere unstrukturierte Datenmengen, also die bekannte Dimension „Variety“. Die Technik rund um Deep Learning ist aktuell verantwortlich für die jüngsten Erfolge im Bereich der Künstlichen Intelligenz: maschinelles Sehen, Text- und Sprachverstehen, Text- und Sprachproduktion, maschinelle Übersetzung. Damit werden zunehmend intelligente Geräte gebaut und Systeme entwickelt, die uns einerseits Routine-Sacharbeiten und -Entscheidungen abnehmen und uns andererseits als Assistenten begleiten und beraten. In Zukunft werden wir immer weniger auf graphische Benutzeroberflächen angewiesen sein, sondern sprechen oder chatten mit smarten Geräten, Umgebungen und Assistenzsystemen.

Data Science Blog: Es heißt, dass Data Scientists gerade an ihrer eigenen Arbeitslosigkeit arbeiten, da zukünftige Verfahren des maschinellen Lernens Data Mining selbstständig durchführen können. Werden die Tools Data Scientists bald ersetzen?

Auf keinen Fall. In industriellen Datenanalyseprojekten gehen ja bis zu 80% des Aufwands in die Erarbeitung der Aufgabenstellung, in Datenexploration und -vorverarbeitung. Und die Digitalisierung und das Internet der Dinge werden uns noch auf viele Jahre hinaus mit neuen Fragestellungen versorgen. Methoden des Reinforcement-Lernens, die Feedback nutzen, um selbstständig weiter zu lernen, sind Gegenstand aktiver Forschung.  Praktisch stellt sich da auch die Frage, wie Reaktionen der Umwelt überhaupt als Feedback zu interpretieren sind. Und schließlich stellt sich das Problem der Haftung. In einigen Anwendungsbereichen werden wir selbstlernende Systeme vorerst ausschließen, bis sichergestellt werden kann, dass sie sich kein unerwünschtes Verhalten aneignen.  Solche Systeme zu bauen wird eine neue Kompetenz von Data Scientists sein.

Data Science Blog: Sollten Unternehmen erfahrene Data Scientists direkt einkaufen? Oder gibt es auch realistische Möglichkeiten, diese einfach selbst auszubilden?

Wir arbeiten mit etlichen Unternehmen zusammen, die ihren Mitarbeitern eine Fortbildung finanzieren, sei es durch ein berufsbegleitendes Studium, sei es durch Kompaktkurse. Die Fraunhofer-Allianz Big Data bietet zum Beispiel ein umfassendes, kompaktes Schulungsprogramm mit Zertifizierung an. Zudem sind Auftragsprojekte eine gute Gelegenheit, das erlernte Wissen praktisch zu vertiefen. Datenanalyseprojekte sind ja von Natur aus agil und erfordern eine enge Zusammenarbeit. Da ist es leicht, die anstehenden Arbeiten wöchentlich zwischen eigenen Mitarbeitern und externen Experten aufzuteilen. So arbeiten wir bereits mit einigen Unternehmen erfolgreich zusammen, teilweise sind die Fachkräfte sogar bei uns vor Ort oder wir unterstützen sie direkt im Unternehmen.

Data Science Blog: Sind gute Data Scientists Ihrer Erfahrung nach tendenziell eher Beratertypen oder introvertierte Nerds?

Data Scientists, die angefangen beim Geschäft und der Anwendungsdisziplin über die Big-Data-Tools bis zu statistischer Analyse und maschinellen Lernen alles selbst beherrschen, finden Sie selten und dann können Sie die Experten vielleicht nicht bezahlen. Allein schon deshalb arbeiten Data Scientists in Teams und bündeln unterschiedliche Kompetenzen und auch Charaktere. Kommunikative Fähigkeiten sind dabei unabdingbar.

Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftswissenschaften abgeschlossen haben, was würden Sie diesen jungen Damen und Herren raten, wie sie gute Data Scientists werden können?

Praxis und Neugier. In jedem Datenanalyseprojekt lernt man dazu – durch die Daten und durch die Zusammenarbeit mit den Kolleginnen und Kollegen. Darum würde ich nach einer Beschäftigung suchen, die immer neue Herausforderungen verspricht. Außerdem richten sich die Gehälter insbesondere nach den fortschrittlichen Tools, die man beherrscht – im Augenblick Spark und Python. Es ist also wichtig, den Blick auf technologische Entwicklungen nicht zu verlieren.

Anmerkung der Redaktion: Das Fortbildungsprogramm der Fraunhofer Acadamy zum Thema Data Science / Big Data ist im Aus- und Fortbildungskatalog enthalten.

 

R Data Frames meistern mit dplyr – Teil 1

Dieser Artikel ist Teil 1 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.

Data Frames sind das Arbeitspferd von R, wenn Daten in eine Struktur gepackt werden sollen, um sie einzulesen, zu säubern, zu transformieren, zu analysieren und zu visualisieren. Abstrakt gesprochen sind Data Frames nichts anderes als Relationen, also Mengen von Tupels, gebildet aus Elementen von geeigneten Mengen.

Dieses Konzept hat sich auch außerhalb des R-Universums bestens bewährt, umzusammengesetzte Daten, Beobachtungen oder Geschäftsobjekte zu repräsentieren. Der beste Beleg für diese Aussage sind die allgegenwärtigen Relationalen Datenbanksysteme (RDBMS). Dort werden Relationen als Tabellen (Tables) oder Sichten (Views) bezeichnet, und darauf wirkt eine mächtige, imperative Abfrage- und Manipulationssprache namens Structured Query Language, kurz:
SQL.

SQL ist in meiner Wahrnehmung die Lingua Franca der Datenverarbeitung, da sie im Kern über sehr viele Softwareprodukte gleich ist und nach erstaunlich geringem Lernaufwand mächtige Auswerte- und Manipulationsoperationen an den Daten ermöglicht. Hier eine SQL-Anweisung, um eine fiktive Tabelle aller Verkäufe (SALES) nach den Top-10-Kunden in diesem Jahr zu untersuchen:

SELECT customer_id, SUM(sales_amt) AS amount,
COUNT(*) AS n_sales, COUNT(DISTINCT product_id) AS n_products
FROM sales
WHERE sales_date LIKE ’2016-%’
GROUP BY customer_id
ORDER BY SUM(sales_amt) DESC
LIMIT 10

Dieser selbsterklärliche Code aus sieben Zeilen hat einen enormen Effekt: Er fast alle Verkäufe des Jahres 2016 auf Basis der Kundennummer zusammen, berechnet dabei die Summe aller Verkaufsbeträge, zählt die Anzahl der Transaktionen und der verschiedenen vom Kunden gekauften Produkte. Nach Sortierung gemäß absteigenden Umsatzes schneidet der Code nach dem 10. Kunden ab.

SQL kann aber mit der gleichen Eleganz noch viel mehr: Beispielsweise verbinden Joins die Daten mehrerer Tabellen über Fremschlüsselbeziehungen oder analytische Funktionen bestimmen Rankings und laufende Summen. Wäre es nicht toll, wenn R ähnlich effektiv mit Data Frames analoger Struktur umgehen könnte? Natürlich! Aber schon der Versuch, obige SQL-Query auf einem R Data Frame mit den althergebrachten Bordmitteln umzusetzen (subset, aggregate, merge, …), führt zu einem unleserlichen, uneleganten Stück Code.

Genau in diese Bresche springt der von vielen anderen Bibliotheken bekannte Entwickler Hadley Wickham mit seiner Bibliothek dplyr: Sie standardisiert Operationen auf Data Frames analog zu SQL-Operationen und führt zu einer wirklich selbsterklärlichen Syntax, die noch dazu sehr performant abgearbeitet wird. Ganz analog zu ggplot2, das sich an der Grammar of Graphics orientiert, spricht Wickham bei dplyr von einer Grammar of Data Manipulation. Die Funktionen zur Manipulation nennt er folgerichtig Verben.

Dabei treten naturgemäß eine Reihe von Analogien zwischen den Teilen eines SELECT-Statements und dplyr-Funktionen auf:

SELECT-Operation dplyr-Funktion
Bildung der Spaltenliste select()
Bildung eines Ausdrucks mutate()
WHERE-Klausel filter()
GROUP BY Spaltenliste group_by()
Bildung von Aggregaten wie sum() etc. summarise()
HAVING-Klausel filter()
ORDER BY Spaltenliste arrange()
LIMIT-Klausel slice()

Die ersten Schritte

Ich möchte die Anwendung von dplyr mithilfe des Standard-Datensatzes Cars93
aus dem Paket MASS demonstrieren:

> install.packages("dplyr")
> library(dplyr)
> cars <- MASS::Cars93
> str(cars)
’data.frame’: 93 obs. of 27 variables:
$ Manufacturer : Factor w/ 32 levels "Acura","Audi",..: 1 1 2 2 3 ...
$ Model : Factor w/ 93 levels "100","190E","240",..: 49 56 ...

Die erste Aufgabe soll darin bestehen, aus dem Data Frame alle Autos zu selektieren, die vom Hersteller “Audi” stammen und nur Model und Anzahl Passagiere auszugeben. Hier die Lösung in Standard-R und mit dplyr:

> # Standard R: Zu allen Audis das Model, Anzahl Insassen
> subset(cars,Manufacturer=="Audi")[,c("Model","Passengers")]
Model Passengers
3 90 5
4 100 6
>
> # Das gleiche mit dplyr
> select(filter(cars,Manufacturer=="Audi"),Model,Passengers)
Model Passengers
1 90 5
2 100 6

Man sieht, dass die neue Funktion filter() der Zeilenselektion, also der Funktion subset() entspricht. Und die Auswahl der Ergebnisspalten, die in Standard-R durch Angabe einer Spaltenliste zwischen [ und ] erfolgt, hat in dplyr das Pendant in der Funktion select().

select() ist sehr mächtig in seinen Möglichkeiten, die Spaltenliste anzugeben. Beispielsweise funktioniert dies über Positionslisten, Namensmuster und ggf. das auch noch negiert:

select(cars, -starts_with("L")) 

Die obige Abfrage projiziert aus dem Data Frame sämtliche Spalten, die nicht mit “L” beginnen. Das scheint zunächst ein unscheinbares Feature zu sein, zahlt sich aber aus, wenn analytische Data Frames Dutzende oder Hunderte von Spalten haben, deren Bezeichnung sich nach einem logischen Namensschema richtet.
Soweit ist das noch nicht spektakulär. dplyr hilft uns in obigem Beispiel, als erstes bestimmte Datensätze zu selektieren und als zweites die interessierenden Spalten zu projizieren. dplyr ist aber bezüglich der Verarbeitung von Data Frames sehr intuitiv und funktional, sodass wir früher oder später viele Operationen auf unserem Data Frame verketten werden. So erreichen wir die Mächtigkeit von SQL und mehr. Die funktionale Syntax aus dem letzten Beispiel wird dann ganz schnell unleserlich, da die Verabeitungsreihenfolge (zuerst filter(), dann select()) nur durch Lesen des Codes von innen nach außen und von rechts nach links ersichtlich wird.

Daher geht dplyr einen Schritt weiter, indem es den eleganten Verkettungsoperator %>% aus dem magrittr-Paket importiert und zur Verfügung stellt. Dadurch werden die verschachtelten Ausdrücke in Sequenzen von Operationen gewandelt und somit sehr viel lesbarer und wartbarer:

select(filter(cars,Manufacturer=="Audi"),Model,Passengers)
Model Passengers
1 90 5
2 100 6

> cars %>%
+ filter(Manufacturer=="Audi") %>%
+ select(Model,Passengers)
Model Passengers
1 90 5
2 100 6

Diese in meinen Augen geniale Syntax durch den neuen Operator %>% erlaubt einen sequenziellen Aufbau der Operationen auf einem Data Frame. Benutzer der Unix-Kommandozeile werden hier leicht die Analogie zu Pipes erkennen. Ganz abstrakt kann man sagen, dass damit folgende Operationen äquivalent sind:

Traditioneller Funktionsaufruf Verkettung mit %>%
f(a,b) a %>% f(b)
f(a,b,c) a %>% f(b,c)
g(f(a,b),c) a %>% f(b) %>% g(c)

Weiteres erklärt die Dokumentation zum %>%-Operator im Paket magrittr mithilfe
des Befehls ?magrittr::‘%>%‘.

Neue Variablen

Durch die Funtionen select() und filter() können wir aus Data Frames Spalten projizieren und Zeilen selektieren. Ergebnisse neuer Ausdrücke entstehen hingegen mit dem Verb mutate():

> # Mit Umrechnung der Mileage in Verbrauch und des
> # Kaufpreises von USD in EUR
> cars2 <-
+ cars %>%
+ filter(Manufacturer=="Audi") %>%
+ mutate(l_100km = 235 / MPG.city,
+ eur = Min.Price * 1000 / 1.1) %>%
+ select(Model,Passengers,l_100km,eur)
> cars2
Model Passengers l_100km eur
1 90 5 11.75000 23545.45
2 100 6 12.36842 28000.00
> class(cars2)
[1] "data.frame"

Im obigen Beispiel wird zunächst auf den Hersteller Audi selektiert und danach auf einen Streich zwei neue Spalten eingeführt, l_100km und eur. Durch Zuweisen auf eine neue Variable wird das fertige Ergebnis dauerhaft gespeichert. Hierbei handelt es sich wieder um ein natives Data Frame-Objekt. Die Operation transmute() arbeitet analog zu mutate(), verwirft aber nach Bildung der Ausdrücke alle nicht genannten Spalten. Somit können wir obiges Beispiel auch wie folgt schreiben:

cars3 <-
+ cars %>%
+ filter(Manufacturer=="Audi") %>%
+ transmute(Model = Model, Passengers = Passengers,
+ l_100km = 235 / MPG.city,
+ eur = Min.Price * 1000 / 1.1)
cars3
Model Passengers l_100km eur
1 90 5 11.75000 23545.45
2 100 6 12.36842 28000.00

Aggregate

Neben der Selektion von Zeilen und Spalten sowie der Bildung abgeleiteter Ausdrücke ist bei Datenbanktabellen die Gruppierung und Aggregation mit GROUP BY eine sehr wichtige Operation. Dies gilt auch für Data Frames in R, wenngleich hier der Funktionsumfang über diverse Funktionen wie table() oder aggregate() verteilt ist und wenig intuitiv ist.

Hier bringt dplyr ebenfalls eine großartige Verbesserung mit. Das entsprechende Verb heißt group_by(). Diese Operation wird zusammen mit einer Spaltenliste auf ein Data Frame angewendet:

grp_cars <- cars %>% group_by(Manufacturer)
> class(grp_cars)
[1] "grouped_df" "tbl_df" "tbl" "data.frame"

Das Ergebnis von group_by() ist ein Objekt, das “mehr” ist als ein Data Frame, sondern auch noch einige spezifische Strukturinformationen von dplyr enthält. In unserem Beispiel sind dies Indizes von Zeilen, die zum gleichen Hersteller gehören. Das ursprüngliche Data Frame wird hierbei nicht kopiert, sondern nur eingebettet.

Nach Anwenden einer group_by()-Operation ist das Data Frame optimal vorbereitet für die eigentliche Aggregation mit summarise():

> sum_cars <- cars %>%
+ group_by(Manufacturer) %>%
+ summarise(nCars = n(), avg_price = mean(Min.Price))
> str(sum_cars)
Classes ‘tbl_df’, ‘tbl’ and ’data.frame’: 32 obs. of 3 variables:
$ Manufacturer: Factor w/ 32 levels "Acura","Audi",..: 1 2 3 4 5 6 7 8 9 10 ...
$ nCars : int 2 2 1 4 2 8 1 2 6 2 ...
$ avg_price : num 21.1 28.4 23.7 20.8 35.2 ...

Das Resultat von summarise() ist wieder ein Data Frame, das neben den ursprünglichen Gruppierungskriterien nur noch die Aggregate enthält.

Daten in Reih’ und Glied

Zwischen Relationalen Datenbanken und R-Data Frames besteht ein wesentlicher konzeptioneller Unterschied: Die Ergebnisse eines SELECT-Befehls haben keine definierte Reihenfolge, so lange die Zeilen nicht mit der Klausel ORDER BY festgelegt wird. Im Gegensatz dazu haben die Zeilen von Data Frames eine konstante Reihenfolge, die sich aus der Anordnung derWerte in den Spaltenvektoren ergibt.

Dennoch ist es manchmal wünschenswert, Data Frames umzusortieren, um eine fachliche Reihenfolge abzubilden. Hierzu dient in dplyr das Verb arrange(), das im Standard-R weitgehend der Indizierung eines Data Frames mit Ergebnissen der order()-Funktion entspricht, aber syntaktisch eleganter ist:

cars %>%
+ arrange(desc(Horsepower),Manufacturer) %>%
+ select(Manufacturer, Model, Horsepower,Min.Price) %>%
+ slice(1:5)
Manufacturer Model Horsepower Min.Price
1 Chevrolet Corvette 300 34.6
2 Dodge Stealth 300 18.5
3 Cadillac Seville 295 37.5
4 Infiniti Q45 278 45.4
5 Mazda RX-7 255 32.5

Dieses Beispiel hat zum Ziel, die fünf PS-stärksten Autos zu selektieren. Die arrange()-Funktion sortiert hier zunächst absteigend nach der PS-Stärke, dann aufsteigend nach Herstellername. Die Selektion der 5 ersten Zeilen erfolgt mit der hilfreichen Funktion slice(), die aus einem Data Frame Zeilen anhand ihrer Reihenfolge selektiert.

Fazit und Ausblick

Mit dplyr wird die Arbeit mit Data Frames stark verbessert: Im Vergleich zu “nacktem” R bringt das Paket eine klarere Syntax, abgerundete Funktionalität und bessere Performance. In der Kürze dieses Artikels konnte ich dies nur oberflächlich anreissen. Daher verweise ich auf die vielen Hilfe-Seiten, Vignetten und Internet-Videos zum Paket. Im zweiten Teil dieses Artikels werde ich auf einige fortgeschrittene Features von dplyr eingehen, z.B. die Verknüpfung von Data Frames mit Joins, die Window-Funktionen und die Verwendung von Datenbanken als Backend.

Weiter zu R Data Frames meistern mit dplyr – Teil 2.

Interview – Mit Data Science Kundenverhalten vorhersagen

Frau Dr. Eva-Marie Müller-Stüler ist Associate Director in Decision Science der KPMG LLP in London. Sie absolvierte zur Diplom-Mathematikerin an der Technischen Universität München, mit einem einjährigen Auslandssemester in Tokyo, und promovierte an der Philipp Universität in Marburg.

linkedin-button xing-button

english-flagRead this article in English:
“Interview – Using Decision Science to forecast customer behaviour”

Data Science Blog: Frau Dr. Müller-Stüler, welcher Weg hat Sie bis an die Analytics-Spitze der KPMG geführt?

Ich hatte schon immer viel Spaß an analytischen Fragestellungen, aber auch ein großes Interesse an Menschen und Finance. Die Frage wie Menschen ticken und Entscheidungen treffen finde ich unglaublich spannend. Im Mathematikstudium und auch bei der Doktorarbeit kamen dann das Auswerten von großen Datenmengen und das Programmieren von Algorithmen hinzu. Die solide mathematische Ausbildung kombiniert mit dem spezifischen Branchen- und Finanzverständnis ermöglicht es mir das Geschäftsmodell meiner Kunden zu verstehen und Methoden zu entwickeln, die den Markt verändern und neue Wege finden.

Data Science Blog: Welche Analysen führen Sie für Ihre Kundenaufträge durch? Welche Vorteile generieren Sie für Ihre Kunden?

Unser Team beschäftigt sich hauptsächlich mit Behaviour und Customer Science. Daher auch der Slogan „We understand human behaviour and we change it“. Unser Focus ist der Mensch (z.B. Kunde oder der Mitarbeiter) und die Frage, wie wir ihn durch das Verständnis seiner Datenartefakte im Verhalten ändern bzw. zukünftiges Verhalten vorhersagen können. Auf dieser Basis entwickeln wir Always-on forecasting Modelle, die es dem Mandanten ermöglichen, bereits im Vorfeld zu agieren. Das kann z.B. bedeuten, durch ortgenaue Informationen spezifische Kundennachfrage an einem bestimmten Standort vorherzusagen, wie sie verbessert oder in die gewünschte Richtung beeinflusst werden kann oder durch welche Maßnahmen bzw. Promotions welcher Kundentyp optimal erreicht wird. Oder auch die Frage wo und mit welcher Produktmischung am besten ein neues Geschäft eröffnet werden soll, ist mit Predictive Analytics viel genauer vorherzusagen als durch herkömmliche Methoden.

Data Science Blog: Welche Voraussetzungen müssen erfüllt sein, damit prädiktive Analysen für Kundenverhalten adäquat funktionieren?

Die Daten müssen natürlich eine gewisse Qualität und Historie haben um z. B. auch Trends und Zyklen zu erkennen. Oft kann man sich aber auch über die Einbindung neuer Datenquellen einen Vorteil erschaffen. Dabei ist Erfahrung und Kreativität enorm wichtig, um zu verstehen was möglich ist und die Qualität verbessert oder ob etwas nur für mehr Rauschen sorgt.

Data Science Blog: Welche externen Datenquellen müssen Sie dafür einbinden? Wie behandeln Sie unstrukturierte Daten?

Hier in England ist man – was externe Datenquellen angeht – schon sehr verwöhnt. Wir benutzen im Schnitt an die 10.000 verschiedene Signale, die je nach Fragestellung unterschiedlich seien können: z. B. die Zusammensetzung der Bevölkerung, Nahverkehrsinformationen, die Nähe von Sehenswürdigkeiten, Krankenhäusern, Schulen, Kriminalitätsraten und vieles mehr. Der Einfluss eines Signals ist bei jedem Problem unterschiedlich. So kann eine hohe Anzahl an Taschendiebstählen ein Zeichen dafür sein, dass in der Gegend viel los ist und die Menschen im Schnitt viel Bargeld bei sich tragen. Das kann z. B. für einen Fast Food-Retailer in der Innenstadt durchaus einen positiven Einfluss auf sein Geschäft haben in einer anderen Gegend aber das Gegenteil bedeuten.

Data Science Blog: Welche Möglichkeiten bietet Data Science für die Forensik bzw. zur Betrugserkennung?

Da jeden Kunden tausende Datensignale umgeben und er durch sein Verhalten weitere produziert und aussendet, kann man gerade beim Online-Geschäft schon ein ziemlich gutes Bild über die Person bekommen. Jede Art von Mensch hat ein gewisses Verhaltensmuster und das gilt auch für Betrüger. Diese Muster muss man nur rechtzeitig erkennen oder vorherzusagen lernen.

Data Science Blog: Welche Tools verwenden Sie bei Ihrer Arbeit? In welchen Fällen setzten Sie auf proprietäre Software, wann hingegen auf Open Source?

Das hängt vom Arbeitsschritt und dem definierten Ziel ab. Wir unterscheiden unser Team in unterschiedliche Gruppen: Unsere Data Wrangler (die für das Extrahieren, Erzeugen und Aufbereiten der Daten zuständig sind) arbeiten mit anderen Tools als z. B. unsere Data Modeller. Im Grunde umfasst es die gesamte Palette von SQL Server, R, Python, manchmal aber auch Matlab oder SAS. Immer häufiger arbeiten wir auch mit auf Cloud-Technologie basierenden Lösungen. Data Visualisation und Dashboards in Qlik, Tableau oder Alteryx geben wir in der Regel jedoch an andere Teams weiter.

Data Science Blog: Wie sieht Ihrer Erfahrung nach der Arbeitsalltag als Data Scientist nach dem morgendlichen Café bis zum Feierabend aus?

Meine Rolle ist vielleicht am besten zu beschreiben als der Player-Coach. Da läuft von allem etwas mit ein. Am Anfang eines Projektes geht es vor Allem darum, mit den Mandaten die Fragestellung zu erarbeiten und das Projekt zu gewinnen. Teil dessen ist auch neue Ideen und Methoden zu entwickeln.  Während eines Projektes sind das Team Management, der Wissenstransfer im Team, der Review und das Hinterfragen der Modelle meine Hauptaufgaben. Am Schluss kommt dann der endgültige Sign-off des Projektes. Da ich oft mehrere Projekte in unterschiedlichen Stadien gleichzeitig leite, wird es garantiert nie langweilig.

Data Science Blog: Sind gute Data Scientists Ihrer Erfahrung nach tendenziell eher Beratertypen oder introvertierte Nerds?

Das hängt so ein bisschen davon ab wo man seinen Schwerpunkt sieht. Als Data Visualizer oder Data Artist geht es darum die Informationen auf das wesentlich zu reduzieren und toll und verständlich darzustellen. Dafür braucht man Kreativität und ein gutes Verständnis für das Geschäft und einen sicheren Umgang mit den Tools.

Der Data Analyst beschäftigt sich vor Allem mit dem „Slice and Dice“ von Data. Ziel ist es, die Vergangenheit zu analysieren und Zusammenhänge zu erkennen. Es ist wichtig zusätzlich zu dem finanziellen Wissen auch gute mathematische Fähigkeiten zu haben.

Der Data Scientist ist der mathematischste von allen. Er beschäftigt sich damit aus den Daten tiefere Zusammenhänge zu erkennen und Vorhersagen zu treffen. Dabei geht es um die Entwicklung von komplizierten Modellen oder auch Machine Learning Algorithmen. Ohne eine gute mathematische Ausbildung und Programmierkenntnisse ist es leider nicht möglich die Sachen in voller Tiefe zu verstehen. Die Gefahr falsche Schlüsse zu ziehen oder Korrelationen zu interpretieren, die sich aber nicht bedingen ist sehr groß. Ein einfaches Beispiel hierfür ist, dass im Sommer, wenn das Wetter schön ist, mehr Menschen Eis essen und in Seen baden gehen. Daher lässt sich eine eindeutige Korrelation zwischen Eis essen und der Anzahl an Ertrunkenen zeigen, obwohl nicht das Eis essen zum Ertrinken führt sondern die beeinflussende Variable die Temperatur ist. Daher ist ein Doktor in einem mathematiknahen Fach schon wichtig.

Genauso ist aber für den Data Scientist auch das entsprechende Finanz- und Branchenwissen wichtig, denn seine Erkenntnisse und Lösung müssen relevant für den Kunden sein und deren Probleme lösen oder Prozesse verbessern. Die tollste AI Maschine bringt keiner Bank einen Wettbewerbsvorteil, wenn sie den Eisverkauf auf Basis des Wetters vorhersagt. Das kann zwar rechnerisch 100% richtig sein, hat aber keine Relevanz für den Kunden.

Es ist im Grunde wie in anderen Bereichen (z. B. der Medizin) auch. Es gibt viele verschiedene Schwerpunkte und für ernsthafte Probleme wendet man sich am besten an einen Spezialisten, damit man keine falschen Schlüsse zieht.

Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftslehre, abgeschlossen haben, was würden sie diesen jungen Damen und Herren raten, wie sie gute Data Scientists werden können?

Nie aufhören mit dem Lernen!  Der Markt entwickelt sich derzeit unglaublich schnell und hat so viele tolle Seiten. Man sollte einfach mit Leidenschaft, Begeisterung und Kreativität dabei sein und Spaß an der Erkennung von Mustern und Zusammenhängen haben. Wenn man sich dann noch mit interessanten und inspirierenden Menschen umgibt, von denen man noch mehr lernen kann, bin ich zuversichtlich, dass man eine tolle Arbeitszeit haben wird.

Python vs R Statistics

Immer wieder wird mir von Einsteigern die Frage gestellt, ob sich der Einstieg und die Einarbeitung in die Programmiersprache Python eher lohnen würde als in R Statistics. Nun gibt es in den englischsprachigen Portalen bereits viele Diskussionen und Glaubenskriege zu diesem Vergleich – diese habe ich mir mit Absicht nicht weiter durchgelesen, sondern ich versuche hier meine Erfahrung aufs Blog zu bringen und bin auf Eure Meinungen/Erfahrungen gespannt!

Mit weniger R-Code schneller zum Ziel, und mit Python darüber hinaus

Was mir beim Einstieg in R gleich auffiel: Nach der Installation kann man sofort loslegen! Ein Plot oder eine Regressionsanalyse ist binnen weniger Code-Zeilen erledigt, denn die Sprache bringt diese Funktionen von Haus aus mit. In Python ist das Ziel auch nicht weit weg, allerdings müssen für die Plots erst die MatplotLib installiert werden, für Matrizenberechnung die Numpy-Bibliothek und um eine, mit der R-Datenstruktur Data.Frame vergleichbare Datenstruktur in Python zu erhalten, die Pandas-Bibliothek. Diese Python-Bibliotheken kann man zwar mit Fug und Recht als Bestandteil des Python-Universums ansehen, standardmäßig ausgeliefert werden sie aber nicht und auch sollten sie streng vom Standardpython in der Anwendung getrennt werden, im Klartext: Die Bibliotheken erfordern extra Einarbeitung und machen die Handhabung komplizierter, das einfache Python verliert ein Stück weit seine Einfachheit.

Auch die beliebte Entwicklungsumgebung R-Studio sucht seinesgleichen und ist IPython meiner Meinung nach hinsichtlich der Usability absolut überlegen. R ist einfach darauf ausgerichtet, Daten zu analysieren und zu visualisieren, aber beschränkt sich eben auch darauf.

“R is more about sketching, and not building,” says Michael Driscoll, CEO of Metamarkets. “You won’t find R at the core of Google’s page rank or Facebook’s friend suggestion algorithms. Engineers will prototype in R, then hand off the model to be written in Java or Python.”

Im Gegenzug ist Python eine Programmiersprache, die nicht nur an den einen Zweck gebunden ist. Mit Python können ebenfalls (Web-)Server- oder Desktop-Anwendungen und somit ohne Technologiebruch analytische Anwendungen komplett in Python entwickelt werden. Und auch wenn R ebenfalls unüberschaubar viele Packages mitbringt, bietet Python noch einiges mehr, beispielsweise zur dreidimensionalen Darstellung von Graphen.

Software-Entwickler lieben Python, Mathematiker eher R

Data Science ist ein äußerst interdisziplinäres Fachgebiet und Data Scientists können Mathematiker, Physiker, Informatiker, Ingenieure oder (wenn auch etwas seltener) Wirtschafts- oder auch Geisteswissenschaftler sein. Ein Großteil kommt aus der Mathematik oder äußerst mathematischer Fachgebiete wie der Physiker oder der Elektroingenieurwissenschaft. In diesen Studiengängen wird überwiegend mit Programmiersprachen gearbeitet, die von Mathematikern für Mathematiker entwickelt wurden, also R Statistics, MATLAB oder Octave. Beispielsweise ist meine Frau studierte Elektotechnikingenieurin und setzte alle ihre Prototypen des maschinellen Lernens in MATLAB um, sie findet sich aber auch in R gut zurecht.

Wer aus der Software-Entwicklung kommt, findet sich in Python vermutlich sehr viel schneller zurecht als in R. In meiner subjektiven Wahrnehmung stelle ich tatsächlich fest, dass diejenigen Data Scientists, die aus der Mathematik zum Data Science gekommen sind, meistens R präferieren und diejenigen, die aus der Anwendungsentwicklung kommen, eher mit Python arbeiten.

datascience

Python kollaboriert besser

Ein Data Scientist kommt selten allein, denn Data Science ist Teamarbeit. Und wo Teams ein gemeinsames Ziel erreicht sollen, werden besondere Anforderungen an die Arbeitsumgebung gestellt. Python gilt als eine syntaktisch leicht verständliche Programmiersprache, die manchmal sogar als “executable Pseudocode” bezeichnet wird (was allerdings dann doch leicht übertrieben ist…). Es ist also für alle Teammitglieder eine relativ einfach zu erlernende Sprache. Dabei muss Python nicht von allen Teammitgliedern favorisiert werden, denn eigene lokale Prototypen können in R, Octave oder was auch immer erstellt werden, lassen sich dann aber auch einfach in Python integrieren. Für richtig schnelle Anwendungen sind Python und R als Interpretersprachen sowieso zu langsam, solche Anwendungen werden am Ende in C/C++ umgesetzt werden müssen, aber selbst dann bietet Python nicht zu unterschätzende Vorteile: Der Erfolg von Python im wissenschaftlichen Rechnen beruht nämlich auch auf der unkomplizierten Integration von Quellcode der Programmiersprachen C, C++ und Fortran.

Neue Spieler auf dem Feld: Scala und Julia

Leider kann ich zu den beiden Programmiersprachen Scala und Julia (noch) nicht viel sagen. Scala scheint sich meiner Einschätzung nach als eine neue Alternative für Python zu entwickeln. Scala ist ein Produkt aus dem Java-Universum und war als eine Programmiersprache für unterschiedlichste Zwecke gedacht. Die Sprache setzt sich im Big Data Science immer weiter durch, einige Tools für Big Data Analytics (Apache Spark, Apache Flink) sind auf Scala ausgelegt und basieren selbst auf dieser Programmiersprache. Was Scala als eine stark von Java inspirierte Sprache sehr sympathisch macht, ist der enorm kompakte Code. Ein MapReduce-Algorithmus lässt sich in Scala mit einem Bruchteil an Code erstellen, als es in Java der Fall wäre, wie es auch die Code-Beispiele der Spark-Webseite eindrücklich zeigen: (Was ist eigentlich Apache Spark?)

Text Search in Python (Apache Spark)

textFile = sc.textFile("hdfs://...")

# Creates a DataFrame having a single column named "line"
df = textFile.map(lambda r: Row(r)).toDF(["line"])
errors = df.filter(col("line").like("%ERROR%"))
# Counts all the errors
errors.count()
# Counts errors mentioning MySQL
errors.filter(col("line").like("%MySQL%")).count()
# Fetches the MySQL errors as an array of strings
errors.filter(col("line").like("%MySQL%")).collect()
Text Search in Scala (Apache Spark)

val textFile = sc.textFile("hdfs://...")

// Creates a DataFrame having a single column named "line"
val df = textFile.toDF("line")
val errors = df.filter(col("line").like("%ERROR%"))
// Counts all the errors
errors.count()
// Counts errors mentioning MySQL
errors.filter(col("line").like("%MySQL%")).count()
// Fetches the MySQL errors as an array of strings
errors.filter(col("line").like("%MySQL%")).collect()
Text Search in Java (Apache Spark)

// Creates a DataFrame having a single column named "line"
JavaRDD<String> textFile = sc.textFile("hdfs://...");
JavaRDD<Row> rowRDD = textFile.map(
  new Function<String, Row>() {
    public Row call(String line) throws Exception {
      return RowFactory.create(line);
    }
  });
List<StructField> fields = new ArrayList<StructField>();
fields.add(DataTypes.createStructField("line", DataTypes.StringType, true));
StructType schema = DataTypes.createStructType(fields);
DataFrame df = sqlContext.createDataFrame(rowRDD, schema);

DataFrame errors = df.filter(col("line").like("%ERROR%"));
// Counts all the errors
errors.count();
// Counts errors mentioning MySQL
errors.filter(col("line").like("%MySQL%")).count();
// Fetches the MySQL errors as an array of strings
errors.filter(col("line").like("%MySQL%")).collect();

Julia wurde (ähnlich wie R) explizit für den Zweck der statistischen Datenanalyse entwickelt, wird auf Grund des aktuellen Beta-Status noch kaum produktiv eingesetzt. Da Julia auf sehr schnelle Anwendungen ausgerichtet ist, liegt in Julia die neue Hoffnung für jene, für die R und Python zu langsame Interpretersprachen sind.

Buchempfehlungen zum Einstieg in R oder Python

Es versteht sich von selbst, dass ich alle Bücher auch selbst besitze und mehr als nur das Vorwort gelesen habe…

Was ist Eure Erfahrung? Ihr seid gefragt!

Schreibt Eure Meinung einfach als Kommentar zu diesem Artikel! Wer meint, den Vergleich logischer, “richtiger” und nachvollziehbarer aufs digitale Papier bringen zu können, darf einen Artikelvorschlag übrigens gerne an redaktion@data-science-blog.com senden!

Data Driven Thinking

Daten gelten als vierter Produktionsfaktor – diese Erkenntnis hat sich mittlerweile in den meisten Führungsetagen durchgesetzt. Während das Buzzword Big Data gerade wieder in der Senke verschwindet, wird nun vor allem von der Data Driven Company gesprochen, oder – im Kontext von I4.0 – von der Smart Factory.
Entsprechend haben die meisten Konzerne in den Aufbau einer Big-Data-Infrastruktur investiert und auch die größeren Mittelständler beginnen allmählich damit, einen Anfang zu setzen. Für den Anfang bedarf es jedoch gar nicht erst eine neue IT-Infrastruktur oder gar eine eigene Data Science Abteilung, ein richtiger Start zum datengetriebenen Unternehmen beginnt mit dem richtigen Mindset – ein Bewusst sein für Datenpotenziale.

Data Driven Thinking

Auch wenn es spezielle Lösungsanbieter anders verkaufen, ist nicht etwa eine bestimmte Datenbank oder eine bestimmte Analysemethodik für die Bewerkstelligung der Digitalisierung notwendig, sondern die datengetriebene Denkweise. In den Datenbeständen der Unternehmen und jenen aus weiteren bisher unerschlossenen Datenquellen stecken große Potenziale, die erkannt werden wollen. Es ist jedoch nicht notwendig, gleich als ersten Schritt jegliche Potenziale in Daten erkennen zu müssen, denn es ist viel hilfreicher, für aktuelle Problemstellungen die richtigen Daten zu suchen, in denen die Antworten für die Lösungen stecken könnten.

Data Driven Thinking oder auch kurz Data Thinking, wie angeblich von einem der ersten Chief Data Officer als solches bezeichnet und auch von meinem Chief Data Scientist Kollegen Klaas Bollhoefer beworben, ist die korrekte Bezeichnung für das richtige Mindset, mit dem sowohl aktuelle Probleme als auch deren Lösungen aus Daten heraus besser identifiziert werden können. Hierfür braucht man auch kein Data Scientist zu sein, es reicht bereits ein in den Grundzügen ausgeprägtes Bewusstsein für die Möglichkeiten der Datenauswertung – Ein Skill, der zeitnah für alle Führungskräfte zum Must-Have werden wird!

Data Scientists als Design Thinker

Was gerade in Europa vordergründig kritisiert wird: Es treffen traditionelle Denkmuster auf ganz neue Produkte und Dienste, mit immer schnelleren Entwicklungsprozessen und tendenziell kürzeren Lebenszyklen – eine zum Scheitern verurteilte Kombination und sicherlich auch einer der Gründe, warum us-amerikanische und auch chinesische Internetunternehmen hier die Nase vorn haben.

Ein zeitgemäßer Ansatz, der im Produktmanagement bereits etabliert ist und genau dort das letzte Quäntchen Innovationskraft freisetzt, ist Design Thinking. Dabei handelt es sich um einen iterativen Ideenfindungs und -validierungsprozess, bei dem die Wünsche und Bedürfnisse der Anwender durchgängig im Fokus stehen, im Hintergrund jedoch steht ein interdisziplinäres Team, dass ein Geschäftsmodell oder einen Geschäftsprozess unter Berücksichtigung des Kundenfeedbacks designed. Nutzer und Entwickler müssen dabei stets im engen Austausch stehen. Erste Ideen und Vorschläge werden bereits möglichst früh vorgestellt, damit bereits lange vor der Fertigstellung das Feedback der Anwender in die weitere Realisierung einfließen kann. Somit orientiert sich die gesamte Entwicklungsphase am Markt – Zu spät erkannte Fehlentwicklungen und Flops lassen sich weitgehend vermeiden. Design Thinker stellen dem Nutzer gezielte Fragen und analysieren dessen Abläufe (und nichts anderes tut ein Data Scientist, er beobachtet seine Welt jedoch viel umfassender, nämlich über jegliche zur Verfügung stehende Daten).

Der Design Thinking Prozess führt crossfunktionale Arbeitsgruppen durch  sechs  Phasen:

In der ersten Phase, dem Verstehen, definiert die Arbeitsgruppe den Problemraum. In der darauffolgenden Phase des Beobachtens ist es entscheidend, die Aktivitäten im Kontext, also vor Ort, durchzuführen und Anwender in ihrem jeweiligen Umfeld zu befragen. In der dritten Phase werden die gewonnenen Erkenntnisse zusammengetragen. In der nachfolgenden Phase der Ideenfindung entwickelt das Team zunächst eine  Vielzahl von Lösungsoptionen. Abschließend werden beim Prototyping, in der fünften Phase, konkrete Lösungen entwickelt, die in der letzten Phase an den Zielgruppen auf ihren Erfolg getestet werden.

Beim Design Thinking mag es zwar eine grundsätzliche Vorgabe für den Ablauf der Ideenfindung und -erprobung geben – der eigentliche Mehrwert steckt jedoch in der dafür nötigen Denkweise und der Einstellung gegenüber dem Experimentieren sowie die Arbeit in einem interdisziplinären Team.

Data Driven Business Cycle

Data Driven Thinking überträgt diesen Ansatz auf die Mehrwert-Generierung unter Einsatz von Datenanalytik und leistet einen Transfer dieser systematischen Herangehensweise an komplexe Problemstellungen im Hinblick auf die Realisierung dafür angesetzter Big Data Projekte. Design Thinking unter Nutzung von Big Data ist überaus mächtig, wenn es darum geht, kundenorientierte Produkte und Prozesse zu entwickeln. Im Data Driven Business Cycle werden für immer neue Ideen und Fragestellungen:

  1. Daten generiert und gesammelt
  2. Daten gesichert, verwaltet und aufbereitet
  3. Daten analysiert
  4. daraus Erkenntnisse gezogen

Aus diesen sich iterativ kreisenden Prozessen der Datennutzung entsteht ein Data Pool (oftmals auch als Data Lake bezeichnet), der immer wieder zum für die Beantwortung von Fragen genutzt werden kann.

Prinzipien des maschinellen Lernen verstehen lernen

Data Driven Thinking entsteht mit dem Bewusstsein für die Potenziale, die in Daten liegen. Noch wirkungsvoller wird diese Denkweise, wenn auch ein Bewusstsein für die Möglichkeiten der Datenauswertung vorhanden ist.

„Kinder, die heute nicht programmieren können, sind die Analphabeten der Zukunft.“ schimpfte Vorzeige-Unternehmer Frank Thelen kürzlich in einer Politik-Talkrunde und bekräftigte damit meine noch davor verkündete Meinung “Karriere ohne Programmier-Erfahrung wird nahezu undenkbar”, denn “Systeme der künstlichen Intelligenz werden in der Zukunft unseren Einkauf und die Warenlieferung übernehmen, unsere Autos fahren, unsere Buchhaltung erledigen, unser Geld optimal auf den Finanzmärkten anlegen und unsere Krankheiten frühzeitig diagnostizieren und die bestmögliche medizinische Behandlung vorgeben.”

Jetzt muss niemand zum Experten für die Entwicklung künstlicher Systeme werden, um hier schritthalten zu können. Ein grundsätzliches Verständnis von den unterschiedlichen Prinzipien des maschinellen Lernen kann jedoch dabei helfen, solche Systeme und die dazugehörigen Chancen und Risiken besser einschätzen zu können, denn diese werden uns in Alltag und Beruf vermehrt begegnen, dabei einen entscheidenden Einfluss auf den Erfolg des Data Driven Business ausüben.

 

Handeln in Netzwerken ohne Enmesh-Effekt

Die Interaktion in Netzwerken ist mit der Entstehung von sozialen Netzwerken, der Einkauf in Online-Shops, die Finanzierungen mit Crowd-Funding oder die nächste Mitfahrgelegenheit ein wesentlicher Bestandteil in unserem Alltag geworden. Insbesondere in der Share Economy hat sich die Bildung von Netzwerken als Erfolgsfaktor digitaler Geschäftsmodelle bereits fest etabliert. Je nach Geschäftsmodell kommt hierbei im Allgemeinen folgende Fragestellung auf:

Was hängt miteinander zusammen und welcher Effekt löst die Verbindung aus?

Effekte können das Wachsen oder Schrumpfen beschleunigen bzw. zu Strukturveränderungen des Netzwerks selbst führen. Eine Besonderheit ist der mögliche Multiplikator-Effekt bis hin zum Erreichen des Tipping-Points, der zu einen überproportionalen Wachstum, nach Erreichen einer kritischen Masse hervorgerufen wird. Aus der Geschäftsperspektive sind vor allem die Wachstumseffekte für eine schnelle Umsatzgenerierung interessant. Daher ist das Erkennen solcher Effekte wesentlich für den Geschäftserfolg.

Aufgrund der Komplexität und der Dynamik solcher Netzwerke ist der Einsatz von Data Mining Methoden zur Erkennung solcher Effekte, anhand von Mustern oder Regeln, hilfreich. In diesem Blog-Beitrag wird der Effekt von Netzwerken anhand von Produktverkäufen erläutert. Diese können beim Einkauf in Online-Shops oder im stationären Handel stattfinden. Hierbei unterscheiden sich die Konsumentengewohnheiten deutlich vom gewählten Kanal des Einkaufs oder welche Produkte eingekauft werden. Ob es um Lebensmittel, Kleidung oder Autos geht, das Kaufverhalten kann sich deutlich unterscheiden ob hierbei regelmäßige oder Spontankäufe vorliegen. Auch wer mögliche Zielgruppen darstellt ist ein wesentlicher Faktor. All diese Überlegungen werden im analytischen Customer Relationship Management zusammengefasst und bilden eine Reihe an Methoden zur Analyse dieser Phänomene (u.a. Customer-Lifetime-Value, Klassifikation, Churn-Analyse).

Aus den benannten Eigenheiten ist ein Verständnis über das Geschäft entscheidend für die Auswahl geeigneter Data Mining Methoden und dessen Interpretation von Erkenntnissen. Bevor es jedoch zur Interpretation kommt, werden die erforderlichen Vorabschritte über einen strukturierten Prozess für die Analyse in diesem Beitrag vorgestellt.

Data Mining Prozess

Ein ausgewählter Prozess bildet der KDD-Prozess (Knowledge Discovery in Databases) nach Fayyad, Piatetsky-Shapiro und Smyth. Alternative Herangehensweisen wie CRISP-DM (Cross Industry Standard Process for Data Mining) oder SEMMA (Sample, Explore, Modify, Model, Asses) können hierbei zu ähnlichen Ergebnissen führen.

Der KDD-Prozess unterteilt Data Mining Vorhaben in die folgenden Schritte:

  1. Bereitstellung des Domänenwissen und Aufstellung der Ziele
  2. Datenauswahl
  3. Datenbereinigung und -verdichtung (Transformation)
  4. Modellauswahl
  5. Data Mining
  6. Interpretation der Erkenntnissen

Je nach Umfang des Data Mining Vorhaben können sich die sechs Schritte weiter ausdifferenzieren. Jedoch wird sich in diesem Beitrag auf diese sechs Schritte fokussiert.

Domänenwissen und Zielstellung

Aus der obigen Einleitung wurde dargestellt, dass ein Domänenwissen essentiell für das Data Mining Vorhaben darstellt. Aus diesem Grund muss vor Beginn des Projekts ein reger Austausch über die Zielstellung zwischen Data Scientists und Entscheidungsträger stattfinden. Insbesondere die explorative Natur von Analysevorhaben kann dazu genutzt werden, um neue Muster zu identifizieren. Hierbei haben diese Muster jedoch nur einen Neuigkeitswert, wenn diese von den Entscheidungsträgern als originell und wertstiftend interpretiert werden. Daher müssen beide Seiten einen möglichst tiefen Einblick in das Geschäft und möglicher Analysen geben, da ansonsten das Projekt im „Shit-In, Shit-Out“-Prinzip mündet. Dies gilt gleichermaßen für die bereitgestellten Daten.

In diesem Beitrag geht es um den Kauf von Produkten durch Konsumenten. Dabei wird die Platzierung von Produkten in Online-Shops und stationären Handel im Wesentlichen durch den Betreiber bzw. Anbieter bestimmt. Während in Online-Shops die Produkte durch Recommendation-Engines zusätzlich  platziert werden können ist im stationären Handel ein höherer Aufwand durch Point-of-Interest (POI) Platzierungen erforderlich. Jedoch gilt als Vision in der digitalen Transformation, das die Produkte durch das Konsumentenverhalten platziert werden sollen. Hierbei wird davon ausgegangen das die konsumentengetriebene Platzierung den höchstmöglichen Cross-Selling-Effekt erzielt. Dies lässt sich in einer Zielstellung für das Data Mining Vorhaben zusammenfassen:

Steigerung des Umsatzes durch die Steigerung des Cross-Selling-Effekts anhand einer konsumentengetriebenen Platzierung von Produkten

In dieser Zielstellung wird der Cross-Selling-Effekt als Treiber für die Umsatzsteigerung hervorgehoben. Hierbei wird davon ausgegangen, das gemeinsam platzierte Produkte, das Interesse von Konsumenten steigert auch beide Produkte zu kaufen. Dies führt zu einem insgesamt gesteigerten Umsatz anstatt, wenn beide Produkte nicht gemeinsam beworben oder platziert werden. Aus der Zielstellung lässt sich anschließend die Auswahl der Daten und erforderliche Aufbereitungsschritte ableiten.

Datenauswahl, -bereinigung und -verdichtung

Der Umsatz ist die Zielvariable für die Entscheidungsträger und dient als Kennzahl zur Messung der Zielstellung. Für den Cross-Selling-Effekt müssen die Verbindungen von gemeinsam gekauften Produkten identifiziert werden. Dies stellt das grundlegende Netzwerk da und wird durch das Konsumverhalten bestimmt.

Als Datengrundlage wird daher der Warenkorb mit den gemeinsam gekauften Produkten herangezogen. Dieser dient als Entscheidungsgrundlage und es lassen sich einerseits die erzielten Umsätze und Zusammenhänge zwischen den Produkten erkennen.

Aufgrund der Vertraulichkeit solcher Projekte und umfangreichen Datenaufbereitungsschritten wird zur Vereinfachung ein synthetisches Beispiel herangezogen. Insbesondere die erforderlichen Schritte zur Erreichung einer hohen Datenqualität ist ein eigener Beitrag wert und wird von diesem Beitrag abgegrenzt. Dies ermöglicht den Fokus auf die Kernerkenntnisse aus dem Projekt ohne von den detaillierten Schritten und Teilergebnissen abgelenkt zu werden.

Generell besteht ein Warenkorb aus den Informationen gekaufter Produkte, Stückzahl und Preis. Diese können noch weitere Informationen, wie bspw. Mehrwertsteuer, Kasse, Zeitpunkt des Kaufs, etc. enthalten. Für dieses Projekt sieht die allgemeine Struktur wie folgt aus:

{
"key":"basket1",
"children":[
{"description":"Product 1",”quantity”: 1, "price": 12.2},
{"description":"Product 2",”quantity”: 2, "price ": 1.8},
{"description":"Product 3",”quantity”: 5, "price ": 3.98},
…
{"description":"Product 99",”quantity”: 1, "price ": 16.95}
], … }

Dabei wird jeder Warenkorb mit einem eindeutigen Schlüssel („key“) und den enthaltenen Produktinformationen versehen. In den Rohdaten können sich eine Menge von Datenqualitätsfehlern verbergen. Angefangen von fehlenden Informationen, wie bspw. der Produktmenge aufgrund von Aktionsverkäufen, uneindeutigen Produktbezeichnungen wegen mangelnder Metadaten, Duplikaten aufgrund fehlgeschlagener Datenkonsolidierungen, beginnt die Arbeit von Data Scientists oft mühselig.

In dieser Phase können die Aufwände für die Datenaufbereitung oft steigen und sollten im weiteren Projektvorgehen gesteuert werden. Es gilt eine ausreichende Datenqualität in dem Projekt zu erzielen und nicht eine vollständige Datenqualität des Datensatzes zu erreichen. Das Pareto-Prinzip hilft als Gedankenstütze, um im besten Fall mit 20% des Aufwands auch 80% der Ergebnisse zu erzielen und nicht umgedreht. Dies stellt sich jedoch oft als Herausforderung dar und sollte ggf. in einem Vorabprojekt vor dem eigentlichen Data-Mining Vorhaben angegangen werden.

Modellauswahl und Data Mining

Nach der Datenaufbereitung erfolgen die eigentliche Modellauswahl und Ausführung der Analyseprozesse. Aus der Zielstellung wurde der Umsatz als Kennzahl abgeleitet. Diese Größe bildet eine Variable für das Modell und der anschließenden Diskussion der Ergebnisse. Das dahinterstehende Verfahren ist eine Aggregation der Umsätze von den einzelnen Produkten.

Der Cross-Selling-Effekt ist dagegen nicht einfach zu aggregieren sondern durch ein Netzwerk zu betrachten. Aus Sicht der Netzwerkanalyse bilden die Produkte die Knoten und die gemeinsamen Käufe die Kanten in einem Graphen. Ein Graph hat den Vorteil die Verbindungen zwischen Produkten aufzuzeigen, kann jedoch auch zu einer endlosen Verstrickung führen in der sich bei einer anschließenden Visualisierung nichts erkennen lässt. Dieser Enmesh-Effekt tritt insbesondere bei einer hohen Anzahl an zu verarbeitenden Knoten und Kanten auf. Wenn wir in eine Filiale oder Online-Shop schauen ist dieser Enmesh-Effekt durchaus gegeben, wenn wir anfangen die Produkte zu zählen und einen Blick auf die täglichen Käufe und erzeugten Kassenbons bzw. Bestellungen werfen. Der Effekt wird umso größer wenn wir nicht nur eine Filiale sondern global verteilte Filialen betrachten.

Aus diesem Grund müssen die Knoten und Verbindungen mit den angemessenen Ergebniswerten hinterlegt und visuell enkodiert werden. Auch eine mögliche Aggregation (Hierarchie), durch bspw. einem Category Management ist in Betracht zu ziehen.

Die Modellauswahl bildet daher nicht nur die Auswahl des geeigneten Analysemodells sondern auch dessen geeignete Visualisierung. In dem Beitragsbeispiel wird die Assoziationsanalyse als Modell herangezogen. In diesem Verfahren wird die Suche nach Regeln durch die Korrelation zwischen gemeinsam gekauften Produkten eruiert. Die Bedeutung einer Regel, bspw. „Produkt 1 wird mit Produkt 2 gekauft“ wird anhand des Lifts angegeben. Aus der Definition des Lifts lässt sich erkennen, dass dieses Verfahren für die Messung des Cross-Selling-Effekts geeignet ist. Hierbei können  unterschiedliche Algorithmen mit unterschiedlichen Ausgangsparametern herangezogen werden (z.B. AIS, Apriori, etc.). Entscheidend ist dabei nicht nur eine Modellkonstellation zu wählen sondern sich auf eine Menge von Modellen zu beziehen. Dabei kann das Modell mit den vielversprechendsten Ergebnissen ausgewählt werden.

Nach der Ausführung des Analyseverfahrens und der Bereinigung sowie -verdichtung der Warenkorbdaten ergeben sich einerseits die aggregierten Produktumsätze als auch die berechneten Modelldaten.

//Produktumsätze
{
"key":"revenues",
"children":[
{"description":"Product 1","revenue":1245354.2},
{"description":"Product 2","revenue":13818.8},
{"description":"Product 3","revenue":27565},
{"description":"Product 4","revenue":4245},
{"description":"Product 5","revenue":2450},
{"description":"Product 6","revenue":707897.69},
{"description":"Product 7","revenue":10398},
{"description":"Product 8","revenue":4688.8},
{"description":"Product 9","revenue":110713.5},
...
{"description":"Product 10","revenue":76141}
]}

Neben den Lift dienen die Hilfsvariablen Support und Confidence auch als Kenngrößen, um einen Aufschluss auf die Validität der errechneten Ergebnisse zu geben. Diese beiden Werte können dazu genutzt werden, einzelnen Knoten aufgrund ihrer unwesentlichen Bedeutung zu entfernen und damit das Netzwerk auf die wesentlichen Produktverbindungen zu fokussieren.

 

//Modelldaten
[{"source":"Product 1","target":"Product 2","lift":11, "parent": "revenues"},
{"source":"Product 2","target":"Product 6","lift":9, "parent": "revenues"},
{"source":"Product 3","target":"Product 20","lift":4, "parent": "revenues"},
{"source":"Product 4","target":"Product 59","lift":5, "parent": "revenues"},
{"source":"Product 5","target":"Product 46","lift":16, "parent": "revenues"},
{"source":"Product 6","target":"Product 17","lift":18, "parent": "revenues"},
{"source":"Product 7","target":"Product 6","lift":13, "parent": "revenues"},
{"source":"Product 8","target":"Product 56","lift":25, "parent": "revenues"},
...
{"source":"Product 26","target":"Product 49","lift":16, "parent": "revenues"}
]

Diese beiden Zieldatensätze werden für die Ergebnispräsentation und der Interpretation herangezogen. Generell findet in den Phasen der Datenauswahl bis zum Data Mining ein iterativer Prozess statt, bis die Zielstellung adäquat beantwortet und gemessen werden kann. Dabei können weitere Datenquellen hinzukommen oder entfernt werden.

Interpretation der Erkenntnisse

Bevor die Ergebnisse interpretiert werden können muss eine Visualisierung auch die Erkenntnisse verständlich präsentieren. Dabei kommt es darauf die originellsten und nützlichsten Erkenntnisse in den Vordergrund zu rücken und dabei das bereits Bekannte und Wesentliche des Netzwerks nicht zur vergessen. Nichts ist schlimmer als das die investierten Mühen in Selbstverständnis und bereits bekannten Erkenntnissen in der Präsentation vor den Entscheidungsträgern versickern.

Als persönliche Empfehlung bietet sich Datenvisualisierung als geeignetes Medium für die Aufbereitung von Erkenntnissen an. Insbesondere die Darstellung in einem „Big Picture“ kann dazu genutzt werden, um bereits bekannte und neue Erkenntnisse zusammenzuführen. Denn in der Präsentation geht es um eine Gradwanderung zwischen gehandhabter Intuition der Entscheidungsträger und dem Aufbrechen bisheriger Handlungspraxis.

In der folgenden Visualisierung wurden die Produkte mit ihren Umsätzen kreisförmig angeordnet. Durch die Sortierung lässt sich schnell erkennen welches Produkt die höchsten Umsätze anhand der Balken erzielt. Der Lift-Wert wurde als verbindende Linie zwischen zwei Produkten dargestellt. Dabei wird die Linie dicker und sichtbarer je höher der Lift-Wert ist.

netzwerk-visualisierung-javascript-cross-selling

Abbildung 1: Netzwerkvisualisierung von erkannten Regeln zu gekauften Produkten (ein Klick auf die Grafik führt zur interaktiven JavaScript-Anwendung)

[box type=”info” style=”rounded”]Dieser Link (Klick) führt zur interaktiven Grafik (JavaScript) mit Mouse-Hover-Effekten.[/box]

Es wurde versucht die Zieldatensätze in einem Big Picture zusammenzuführen, um das Netzwerk in seiner Gesamtheit darzustellen. Hieraus lässt sich eine Vielzahl von Erkenntnissen ablesen:

  1. Das „Produkt 37“ erzielt den höchsten Umsatz, zeigt jedoch keinen Cross-Selling-Effekt von gemeinsam gekauften Produkten.
  2. Dagegen das „Produkt 23“ erzielte weniger Umsatz, wird jedoch häufig mit anderen Produkten gemeinsam gekauft.
  3. Das „Produkt 8“ weist zwei starke Regeln (Assoziationen) für „Produkt 45 & 56“ auf. Ggf. lassen sich diese Produkte in Aktionen zusammenanbieten.

Im Erstellungsprozess der Ergebnispräsentation ergab sich die Erfahrungspraxis flexibel eine geeignete Visualisierung zu erstellen anstatt die Erkenntnisse in vordefinierte Visualisierungen oder Diagramme zur pressen. Dies kann einerseits den Neuigkeitswert erhöhen und die Informationen anschließend besser transportieren aber auf der anderen Seite den Aufwand zur Erstellung der Visualisierung und das Verständnis für die neu erstellte Visualisierung mindern.

Ein Blick hinter die Bühne zeigt, dass die Visualisierung mit D3.js erstellt wurde. Dies bietet ein geeignetes Framework für die Flexibilität zur Erstellung von Datenpräsentationen. Wer sich nach Bibliotheken in R oder Python umschaut, wird auch in diesen Technologiebereichen fündig. Für R-Entwickler existierten die Packages „statnet“ und „gplots“ zur Verarbeitung und Visualisierung von Netzwerkdaten. Für Ptyhon-Entwickler steht graph-tool als sehr leistungsfähiges Modul, insb. für große Mengen an Knoten und Kanten zur Verfügung.

In unserem Vorhaben haben wir uns für D3.js aufgrund der möglichen Implementierung von Interaktionsmöglichkeiten, wie bspw. Highlighting von Verbindungen, entschieden. Dies ermöglicht auch eine bessere Interaktion mit den Entscheidungsträgern, um relevante Details anhand der Visualisierung darzustellen.

Ein Abriss in die Entwicklung der D3-Visualisierung zeigt, dass die Daten durch eine Verkettung von Methoden zur Enkodierung von Daten implementiert werden. Hierbei wird bspw. den Produkten ein Rechteck mit der berechneten Größe, Position und Farbe (.attr()) zugewiesen.

svg.selectAll(".node_rect_shape")
 	.data(nodes.filter(function(n) { return !n.children; }))
 .enter().append("g")
 .attr("class", "node_rect")
 .attr("transform", function(d) { return "rotate(" + (d.x - 90) + ")translate(" + (d.y + rect_width)+ ")"; })
 	.append("rect")
 	.attr("x", function(d) { return -(rect_width/2.0); })
.attr("width", function(d) { return rect_width; })
 	.attr("height", function(d) { return rect_size_scale(parseFloat(d.values)); }) 
.attr("class", "node_rect_shape")
 	.attr("transform", function(d) { return "rotate(" + (-90) + ")"; })
 	.on("mouseover", mouseovered)
 	.on("mouseout", mouseouted);

Insbesondere die Höhe des Balkens zur Darstellung des Umsatzes wird mit der Implementierung von Skalen erleichtert.

var rect_size_scale = d3.scale.linear().domain([0, d3.max(revenue_data.children, function(d){return parseFloat(d.values);})]).range([0, rect_height]);

Für die verbindenden Linien wurde auch ein visuelles Clustering anhand eines Edge-Bundling herangezogen. Dies führt gemeinsame Verbindungen zusammen und reduziert den Enmesh-Effekt.

link.data(bundle(links)).enter().append("path")
 	.each(function(d) { d.source = d[0], d.target = d[d.length - 1]; })
 	.attr("class", "link")
 	.style("stroke-opacity", function(d, i){ return transparent_scale(link_data[i].lift); })
 	.style("stroke-width", function(d, i){ return size_scale(link_data[i].lift); })
 	.attr("d", line);

* Das vollständige Beispiel kann dem zip-File (siehe Download-Link unten) entnommen werden. Die Ausführung reicht mit einem Klick auf die index.html Datei zur Darstellung im Browser aus.
Eine kritische Betrachtung der Ergebnisvisualisierung zeigt auf, dass die Anordnung der Produkte (Knoten) das interpretieren der Darstellung vereinfacht aber auch hier der Enmesh-Effekt fortschreitet je höher die Anzahl an Verbindungen ist. Dies wurde mit verschiedenen Mitteln im Analyseverfahren (Modellparameter, Entfernen von Produkten aufgrund eines geringen Supprt/Confidence Wertes oder Pruning) als auch in der der Darstellung (Transparenz, Linienstärke Edge-Bundling) reduziert.

Fazit

Als Quintessenz lässt sich festhalten, dass eine Auseinandersetzung mit Netzwerken auch Überlegungen über Komplexität im gesamten Data-Mining Vorhaben mit sich bringt. Dabei unterscheiden sich diese Überlegungen zwischen Data Scientists und Entscheidungsträger nach dem Kontext. Während Data Scientists über das geeignete Analyseverfahren und Visualisierung nachdenken überlegt der Entscheidungsträger welche Produkte wesentlich für sein Geschäft sind. Auf beiden Seiten geht es darum, die entscheidenden Effekte herauszuarbeiten und die Zielstellung gemeinsam voranzutreiben. Im Ergebnis wurde die Zielstellung durch die Darstellung der Produktumsätze und der Darstellung des Cross-Selling-Impacts in einem Netzwerk als Big Picture aufbereitet. Hieraus können Entscheidungsträger interaktiv, die geeigneten Erkenntnisse für sich interpretieren und geeignete Handlungsalternativen ableiten. Dabei hängt jedoch die Umsetzung einer konsumentengetriebenen Produktplatzierung vom eigentlichen Geschäftsmodell ab.

Während sich diese Erkenntnisse im Online-Geschäft einfach umsetzen lassen, ist dies eine Herausforderungen für den stationären Handel. Die Produktplatzierung in Filialen kann aufgrund der begrenzten Fläche als auch den Gewohnheiten von Konsumenten nur bedingt verändert werden. Daher können auch Mischformen aus bspw. „Online-Schauen, Offline-Kaufen“ eruiert werden.

Nach der Entscheidung erfolgt sogleich auch die Überlegung nach den Konsequenzen, Veränderungen und Einfluss auf das Geschäft. Hieraus bildet sich für Data Scientists und Entscheidungsträger eine Kette von Überlegungen über erkannte Muster in Netzwerken, Implikation und möglicher Prognosefähigkeit. Letzteres ist eine besondere Herausforderung, da die Analyse der Dynamik vom Netzwerk im Vordergrund steht. Die Suche nach einer kritischen Masse oder Tipping-Point kann zu möglichen Veränderungen führen, die aufgrund des Informationsmangels nur schwer vorhersagbar sind. Dies kann vom Ablegen bisheriger Gewohnheiten zu negativen Kundenfeedback aber auch positiver Wirkung gesteigerter Absätze rangieren.

Hierbei zeigt sich das evolutionäre als auch das disruptive Potenzial von Data Mining-Vorhaben unabhängig davon welche Entscheidung aus den Erkenntnissen abgeleitet wird. Data Scientists schaffen neue Handlungsalternativen anstatt auf bestehende Handlungspraxen zu verharren. Die Eigenschaft sich entsprechend der Dynamik von Netzwerken zu verändern ist umso entscheidender „Wie“ sich ein Unternehmen verändern muss, um im Geschäft bestehen zu bleiben. Dies gelingt nur in dem sich auf das Wesentliche fokussiert wird und so der Enmesh-Effekt erfolgreich durch einen Dialog zwischen Entscheidungsträger und Data Scientists in einer datengetriebenen Geschäftswelt gemeistert wird.

Quellcode Download

Der vollständige und sofort einsatzbereite Quellcode steht als .zip-Paket zum Download bereit.
Bitte hierbei beachten, dass die meisten Browser die Ausführung von JavaScript aus lokalen Quellen standardmäßig verhindern. JavaScript muss daher in der Regel erst manuell aktiviert werden.

KNN: Rückwärtspass

Im letzten Artikel der Serie haben wir gesehen wie bereits trainierte Netzwerke verwendet werden können. Als Training wird der Prozess bezeichnet der die Gewichte in einen Netzwerk so anpasst, dass bei einem Vorwärtspass durch ein Netzwerk zu einen festgelegten Eingangsdatensatz ein bestimmtes Ergebnis in der Ausgangsschicht ausgegeben wird. Im Umkehrschluss heißt das auch, dass wenn etwas anderes ausgeliefert wurde als erwartet, das Netzwerk entweder noch nicht gut genug oder aber auf ein anderes Problem hin trainiert wurde.

Training

Das Training selbst findet in drei Schritten statt. Zunächst werden die Gewichte initialisiert. Üblicherweise geschieht das mit zufälligen Werten, die aus einer Normalverteilung gezogen werden. Je nachdem wie viele Gewichte eine Schicht hat, ist es sinnvoll die Verteilung über den Sigma Term zu skalieren. Als Daumenregeln kann dabei eins durch die Anzahl der Gewichte in einer Schicht verwendet werden.

Im zweiten Schritt wird der Vorwärtspass für die Trainingsdaten errechnet. Das Ergebnis wird beim ersten Durchlauf alles andere als zufrieden stellend sein, es dient aber dem Rückwärtspass als Basis für dessen Berechnungen und Gewichtsänderungen. Außerdem kann der Fehler zwischen der aktuellen Vorhersage und dem gewünschten Ergebnis ermittelt werden, um zu entscheiden, ob weiter trainiert werden soll.

Der eigentliche Rückwärtspass errechnet aus der Differenz der Vorwärtspassdaten und der Zieldaten die Steigung für jedes Gewicht aus, in dessen Richtung dieses geändert werden muss, damit das Netzwerk bessere Vorhersagen trifft. Das klingt zunächst recht abstrakt, die genauere Mathematik dahinter werde ich in einem eigenen Artikel erläutern. Zur besseren Vorstellung betrachten wir die folgende Abbildung.

    visuelle Darstellung aller Gewichtskombinationen und deren Vorhersagefehler

Das Diagramm zeigt in blau zu allen möglichen Gewichtskombinationen eines bestimmten, uns unbekannten, Netzwerks und Problems den entsprechenden Vorhersagefehler. Die Anzahl der Kombinationen hängt von der Anzahl der Gewichte und der Auflösung des Wertebereiches für diese ab. Theoretisch ist die Menge also unendlich, weshalb die blaue Kurve eine von mir ausgedachte Darstellung aller Kombinationen ist. Der erste Vorwärtspass liefert uns eine Vorhersage die eine normalisierte Differenz von 0.6 zu unserem eigentlichen Wunschergebnis aufweist. Visualisiert ist das Ganze mit einer schwarzen Raute. Der Rückwärtspass berechnet aus der Differenz und den Daten vom Vorwärtspass einen Änderungswunsch für jedes Gewicht aus. Da die Änderungen unabhängig von den anderen Gewichten ermittelt wurden, ist nicht bekannt was passieren würde wenn alle Gewichte sich auf einmal ändern würden. Aus diesem Grund werden die Änderungswünsche mit einer Lernrate abgeschwächt. Im Endeffekt ändert sich jedes Gewicht ein wenig in die Richtung, die es für richtig erachtet. In der Hoffnung einer Steigerung entlang zu einem lokalen Minimum zu folgen, werden die letzten beiden Schritte (Vor- und Rückwärtspass) mehrfach wiederholt. In dem obigen Diagramm würde die schwarze Raute der roten Steigung folgen und sich bei jeder Iteration langsam auf das linke lokale Minimum hinzubewegen.

 

Anwendungsbeispiel und Programmcode

Um den ganzen Trainingsprozess im Einsatz zu sehen, verwenden wir das Beispiel aus dem Artikel “KNN: Vorwärtspass”. Die verwendeten Daten kommen aus der Wahrheitstabelle eines X-OR Logikgatters und werden in ein 2-schichtiges Feedforward Netzwerk gespeist.

XOR Wahrheitstabelle

X1 X2 Y = X1 ⊻ X2
0 0 0
0 1 1
1 0 1
1 1 0

Der Programmcode ist in Octave geschrieben und kann zu Testzwecken auf der Webseite von Tutorialpoint ausgeführt werden. Die erste Hälfte von dem Algorithmus kennen wir bereits, der Vollständigkeit halber poste ich ihn noch einmal, zusammen mit den Rückwärtspass. Hinzugekommen sind außerdem ein paar Konsolenausgaben, eine Lernrate- und eine Iterations-Variable die angibt wie viele Trainingswiederholungen durchlaufen werden sollen.

 %--------------------- Daten -----------------------
 X = [0 0;       			% Eingangsdaten
      0 1;
      1 0;
      1 1] 
     
 Y = [0;1;1;0] 				% erwartete XOR Ausgangsdaten

 theta1 = normrnd(0, 1/(3*2), 3, 2); % 3x2 Gewichtsmatrix
 theta2 = normrnd(0, 1/(3*1), 3, 1); % 3x1 Gewichtsmatrix

 m = length(X)				% Anzahl der Eingangsdaten
 
 
 iteration = 10000			% Anzahl der Trainingsiterationen
 alpha = 0.8					% lernrate 

 printf("nnStarte Training ... ")
 for(i = 1:iteration) 
 
   %--------------------- Vorwärtspass -----------------------
   V = X;					% anlegen der Eingangsdaten an die Eingangsschicht

   % 1. berechne die Aktivierungen der verborgenen Schicht
   Vb = [ones(m,1) V];		% hinzufügen der Bias Units  (sind immer 1)
   Zv = Vb * theta1;			% Summe aus den Eingangswerten multipliziert mit deren Gewichten
   H = 1 ./ (1 .+ e.^-Zv);	% anwenden der Sigmoid Funktion auf die Aktivierungsstärke Zv

   % 2. berechne die Aktivierungen der Ausgangsschicht
   Hb = [ones(m,1) H];		% hinzufügen der Bias Units an die verborgene Schicht
   Zh = Hb * theta2;			% Produkt aus den Aktivierungen der Neuronen in H und Theta2
   O = 1 ./ (1 .+ e.^-Zh);	% Vorhersage von dem Netzwerk

   % 3. berechne die Vorhersageungenauigkeit
   loss = (O .- Y) .^ 2; 	% quadratischer Fehler von der Vorhersage und der Zielvorgabe Y
   mse = sum(loss) / m;		% durchschnittlicher quadratischer Fehler aller Vorhersagen
   
   %--------------------- Rückwärtspass -----------------------
   
   % 1. Ableitung der Fehlerfunktion
   d = O .- Y;					% Differenzmatrix zwischen der Vorhersage und der Zielvorgabe Y

   % 2. berechne die Änderungen für Theta2 und die Ableitung der Ausgangsschicht
   OMO = ones(size(O)) .- O;		% Zwischenvariable: 1-Minus-Vorhersage
   Zhd = d .* O .* OMO;			% Ableitung der Sigmoid Funktion
   theta2c = Hb' * Zhd;			% Änderunswunsch für Theta2
   Hd = Zhd * theta2';			% Ableitung von der Ausgangsschicht
   Hd(:,[1]) = [];				% Ableitung von der Bias Unit

   % 3. berechne die Änderungen für Theta1 und die Ableitung der verborgenen Schicht
   HMO = ones(size(H)) .- H;		% Zweischenvariable: 1 Minus Aktivierung der verborgenen Schicht
   Zvd = Hd .* H .* HMO;			% Ableitung der Sigmoid Funktion von der Aktivierungsstärke Zv
   theta1c = Vb' * Zvd;			% Änderunswunsch für Theta1
   								% weitere Ableitungen sind nicht notwendig

  theta1 -= theta1c .* alpha;	% ändere die Gewichte von Theta1 und Theta2
  theta2 -= theta2c .* alpha;	% der Änderungswunsch wird von der Lernrate abgeschwächt 
 
 endfor
 
 % Ausgabe von der letzten Vorhersage und den Gewichten 
 printf("abgeschlossen. n")
 printf("Letzte Vorhersage und trainierte Gewichten")
 O
 theta1
 theta2

Zu jeder Zeile bzw. Funktion die wir im Vorwärtspass geschrieben haben, gibt es im Rückwärtspass eine abgeleitete Variante. Dank den Ableitungen können wir die Änderungswünsche der Gewichte in jeder Schicht ausrechnen und am Ende einer Trainingsiteration anwenden. Wir trainieren 10.000 Iterationen lang und verwenden eine Lernrate von 0,8. In komplexeren Fragestellungen, mit mehr Daten, würden diese Werte niedriger ausfallen.

Es ist außerdem möglich den ganzen Programmcode viel modularer aufzubauen. Dazu werde ich im nächsten Artikel auf eine mehr objekt-orientiertere Sprache wechseln. Nichts desto trotz liefert der obige Algorithmus gute Ergebnisse. Hier ist mal ein Ausgabebeispiel:

X =                                                                                                                                                                                                                                                                                                                                                                                                               
   0   0                                                                                                                                                                                                          
   0   1                                                                                                                                                                                                          
   1   0                                                                                                                                                                                                          
   1   1                                                                                                                                                                                                          
                                                                                                                                                                                                                  
Y =                                                                                                                                                                                                                                                                                                                                                                                                                   
   0                                                                                                                                                                                                              
   1                                                                                                                                                                                                              
   1                                                                                                                                                                                                              
   0                                                                                                                                                                                                              
                                                                                                                                                                                                                  
theta1 =                                                                                                                                                                                                                                                                                                                                                                                                         
   0.114950   0.046125                                                                                                                                                                                            
   0.064683   0.139159                                                                                                                                                                                            
  -0.164288  -0.094688                                                                                                                                                                                            
                                                                                                                                                                                                                  
theta2 =                                                                                                                                                                                                                                                                                                                                                                                                         
   0.33607                                                                                                                                                                                                        
  -0.31128                                                                                                                                                                                                        
   0.13993                                                                                                                                                                                                        
                                                                                                                                                                                                                  
m =  4                                                                                                                                                                                                            
iteration =  10000                                                                                                                                                                                                
alpha =  0.80000                                                                                                                                                                                                  
                                                                                                                                                                                                                  
                                                                                                                                                                                                                  
Starte Training ... abgeschlossen.     
                                                                                                                                                                           
Letzte Vorhersage und trainierte Gewichte                                                                                                                                                                                    
O =                                                                                                                                                                                                                                                                                                                                                                                                                  
   0.014644                                                                                                                                                                                                       
   0.983308                                                                                                                                                                                                       
   0.986137                                                                                                                                                                                                       
   0.013060                                                                                                                                                                                                       
                                                                                                                                                                                                                  
theta1 =                                                                                                                                                                                                                                                                                                                                                                                                        
   3.2162  -3.0431                                                                                                                                                                                                
   6.4365   5.6498                                                                                                                                                                                                
  -6.3383  -5.8602                                                                                                                                                                                                
                                                                                                                                                                                                                  
theta2 =                                                                                                                                                                                                                                                                                                                                                                                                        
   4.4759                                                                                                                                                                                                         
  -9.5057                                                                                                                                                                                                         
   9.9795    

 

SMART DATA Developer Conference

SMART DATA Developer Conference macht Softwareentwickler und IT-Professionals fit für Big Data

Nahezu alle befragten Unternehmen geben in der aktuellen Studie „Big Data Use Cases 2015“ der Business Application Research Center – BARC GmbH an, dass strategische Entscheidungen von Daten gestützt sind oder sogar alleinig auf Grundlage von Ergebnissen aus Big-Data-Analysen getroffen werden. Der Studie zufolge ist die größte Herausforderung für Unternehmen derzeit das fehlende fachliche oder technische Know-how. Genau hier setzt die SMART DATA Developer Conference an.

Big Data & Smart Analytics – Durchblick im Markt

Das gesamte Programm der Veranstaltung finden Sie unter smart-data-developer-conference.de/#program

„Nicht die Technik ist heute die Hürde für erfolgreiche Geschäftsmodelle, sondern das Kundenverständnis. Das erreicht man nur mit Smart Data“, so Michael Nolting, Sevenval Technologies GmbH und Keynotesprecher der SMART DATA Developer Conference.

[box type=”tick”]15% Rabatt bei Eingabe des Werbe-Codes: SMART16science[/box]

In seiner eröffnenden Session entwickelt er eine Matrix, die den Teilnehmer befähigt, verfügbare Technologie-Stacks zu bewerten: Welche Technologie und welcher Anbieter sind für den speziellen Anwendungsfall am besten geeignet? Mit dieser Entscheidungshilfe lassen sich Verfahren schnell vergleichen, damit das passende zuverlässig ermittelt wird.

Weitere Themen im Programm sind:

  • Batch & Stream Processing mit Google Dataflow
  • Datenanalysen mit Python und ApacheSpark
  • Datenqualität und –visualisierung
  • uvm

Die SMART DATA Developer Conference vom 18. – 19. April 2016 in München macht Softwareentwickler mit den Herausforderungen von Big Data vertraut. Im Konferenzprogramm erlangen sie Wissen zu Speicherung, Analyse, Plattformen und Tools. In kleinen Gruppen können sie am Workshoptag diese Technologien intensiv trainieren.

Leser des Data Science Blog erhalten mit dem Code SMART16science einen Rabatt von 15 % bei Anmeldung. Damit ist die Teilnahme an der Konferenz ab EUR 425 zzgl. MwSt. möglich oder an beiden Tagen ab EUR 935. Programm und Anmeldung unter smart-data-developer.de.

Toolkits & Services für Semantische Textanalysen

Named Entity Recognition ist ein Teilgebiet von Information Extraction. Ziel von Information Extraction ist die Gewinnung semantischer Informationen aus Texten (im Gegensatz zum verwandten Gebiet des Information Retrieval, bei dem es um das möglichst intelligente Finden von Informationen, die u.U. vorab mit Information Extraction gewonnen wurden, geht). Named Entity Recognition (kurz NER) bezeichnet die Erkennung von Entitäten wie z.B. Personen, Organisationen oder Orten in Texten.

[box]Beispiel:
Albert Einstein war ein theoretischer Physiker, der am 14. März 1879 in Ulm geboren wurde. Er erhielt 1921 den Nobelpreis für Physik. Isaac Newton, Einstein und Stephen Hawking werden oft als die größten Physiker seit der Antike bezeichnet.”[/box]

Die Disambiguierung von Entitäten ist ein weiterer wichtiger Schritt auf dem Weg zu einem semantischen Verständnis von Texten. Wenn man so in obigem Text erkennen kann, dass “Albert Einstein“, “Er” und “Einstein” die gleiche Person bezeichnen, so kann ein Analyseverfahren z.B. daraus schließen, dass in diesem Text Einstein eine wichtigere Rolle spielt, als Newton, der nur einmal erwähnt wurde. Die Hyperlinks hinter den jeweiligen Entitäten zeigen eine Möglichkeit der semantischen Anreicherung von Texten an – in diesem Fall wurden die Entitäten mit entsprechenden Einträgen bei DBpedia automatisch verlinkt.

Named Entity Recognition dient vorrangig zwei Zwecken:

  • Anreicherung von Texten mit Metadaten
  • Abstraktion von Texten zur besseren Erkennung von Mustern

Punkt 1 dient direkt dem Information Retrieval. Anwender können so z.B. gezielt nach bestimmten Personen suchen, ohne alle möglichen Schreibweisen oder Berufsbezeichnungen auflisten zu müssen.

Punkt 2 dient der Vorverarbeitung von Texten als Input für Machine Learning Verfahren. So ist es (je nach Anwendung!) oft nicht von Bedeutung, welche Person, welcher Ort oder auch welche Uhrzeit in einem Text steht sondern nur die Tatsache, dass Personen, Orte oder Zeiten erwähnt wurden.

Sirrus Shakeri veranschaulicht die zentrale Bedeutung semantischer Analyse in seinem Beitrag From Big Data to Intelligent Applications:

intelligent-applications-cirrus-shakeri

Abbildung 1: Von Big Data zu Intelligent Applications von Cirrus Shakeri

Sein “Semantic Graph” setzt voraus, dass Entitäten mittels “Natural Language Processing” erkannt und zueinander in Beziehung gesetzt wurden.

Es ist interessant zu vermerken, dass Natural Language Processing und Data Mining / Machine Learning über viele Jahre als Alternativen zueinander und nicht als Ergänzungen voneinander gesehen wurden. In der Tat springen die meisten Vorgehensmodelle heutzutage von “Data Preparation” zu “Machine Reasoning”. Wir argumentieren, dass sich in vielen Anwendungen, die auf unstrukturierten Daten basieren, signifikante Qualitätsverbesserungen erzielen lassen, wenn man zumindest NER (inklusive Disambiguierung) in die Pipeline mit einbezieht.

Toolkits und Services für NER

Es existiert eine Vielzahl von Toolkits für Natural Language Processing, die Sie mehr oder weniger direkt in Ihre Programme einbinden können. Exemplarisch seien drei Toolkits für Java, Python und R erwähnt:

Diese Toolkits enthalten Modelle, die auf Korpora für die jeweils unterstützten Sprachen trainiert wurden. Sie haben den Vorteil, dass sie auch vollkommen neue Entitäten erkennen können (wie z.B. neue Politiker oder Fernsehstars, die zur Trainingszeit noch unbekannt waren). Je nach Einstellung haben diese Systeme aber auch eine relativ hohe Falsch-Positiv-Rate.

Wer NER nur ausprobieren möchte oder lediglich gelegentlich kleinere Texte zu annotieren hat, sei auf die folgenden Web Services verwiesen, die auch jeweils eine REST-Schnittstelle anbieten.

DBpedia

Das DBpedia Projekt nutzt die strukturierten Informationen der verschieden-sprachigen Wikipedia Sites für den Spotlight Service. Im Unterschied zu den reinen Toolkits nutzen die nun genannten Werkzeuge zusätzlich zu den trainierten Modellen eine Wissensbasis zur Verringerung der Falsch-Positiv-Rate. Die mehrsprachige Version unter http://dbpedia-spotlight.github.io/demo zeigt die Möglichkeiten des Systems auf. Wählen Sie unter “Language” “German“) und dann über “SELECT TYPES…” die zu annotierenden Entitätstypen. Ein Beispieltext wird automatisch eingefügt. Sie können ihn natürlich durch beliebige andere Texte ersetzen. Im folgenden Beispiel wurden “Organisation”, “Person”, und “Place“ ausgewählt:

DBprediaSpotlight

Abbildung 2: DBpedia Demo (de.dbpedia.org)

Die erkannten Entitäten werden direkt mit ihren DBpedia Datenbankeinträgen verlinkt. Im Beispiel wurden die Orte Berlin, Brandenburg und Preußen sowie die Organisationen Deutsches Reich, Deutsche Demokratische Republik, Deutscher Bundestag und Bundesrat erkannt. Personen wurden in dem Beispieltext nicht erkannt. Die Frage, ob man “Sitz des Bundespräsidenten” als Ort (Sitz), Organisation (das Amt des Bundespräsidenten) und / oder Person (der Bundespräsident) bezeichnen sollte, hängt durchaus vom Anwendungsszenario ab.

OpeNER

Das OpeNER Projekt ist das Ergebnis eines europäischen Forschungsprojekts und erweitert die Funktionalität von DBpedia Spotlight mit weiteren semantischen Analysen. Die Demo unter http://demo2-opener.rhcloud.com/welcome.action (Tab “Live Analysis Demo“, “Named Entity Recognition and Classification” und “Named Entity Linking” auswählen und “Analyse” drücken, dann auf der rechten Seite das Tab “NERC” anwählen) ergibt für den gleichen Beispieltext:

opeNER-projekt

Abbildung 3: OpeNER Projekt (opener-project.eu)

Organisationen sind blau hinterlegt, während Orte orange markiert werden. Auch hier werden erkannte Entitäten mit ihren DBpedia Datenbankeinträgen verknüpft. Die Bedeutung dieser Verknüpfung erkennt man wenn man auf das Tab “Map” wechselt. Berlin wurde als Ort erkannt und über die Geo-Koordinaten (geo:long = 13.4083, geo.lat = 52.5186) im DBpedia Eintrag von Berlin konnte das Wort “Berlin” aus obigem Text automatisch auf der Weltkarte referenziert werden.

Es gibt eine Vielzahl weiterer Services für NLP wie z.B. OpenCalais. Einige dieser Services bieten bestimmte Funktionalitäten (wie z.B. Sentiment Analysis) oder andere Sprachen neben Englisch nur gegen eine Gebühr an.

Listen Tagger

Der Vollständigkeit halber sei noch erwähnt, dass in den meisten Anwendungsszenarien die oben genannten Werkzeuge durch sogenannte Listen-Tagger (englisch Dictionary Tagger) ergänzt werden. Diese Tagger verwenden Listen von Personen, Organisationen oder auch Marken, Bauteilen, Produktbezeichnern oder beliebigen anderen Gruppen von Entitäten. Listen-Tagger arbeiten entweder unabhängig von den oben genannten statistischen Taggern (wie z.B. dem Standford Tagger) oder nachgeschaltet. Im ersten Fall markieren diese Tagger alle Vorkommen bestimmter Worte im Text (z.B. „Zalando“ kann so direkt als Modemarke erkannt werden). Im zweiten Fall werden die Listen genutzt, um die statistisch erkannten Entitäten zu verifizieren. So könnte z.B. der Vorschlag des statistischen Taggers automatisch akzeptiert werden wenn die vorgeschlagene Person auch in der Liste gefunden wird. Ist die Person jedoch noch nicht in der Liste enthalten, dann könnte ein Mitarbeiter gebeten werden, diesen Vorschlag zu bestätigen oder zu verwerfen. Im Falle einer Bestätigung wird die neu erkannte Person dann in die Personenliste aufgenommen während sie im Falle einer Ablehnung in eine Negativliste übernommen werden könnte damit dieser Vorschlag in Zukunft automatisch unterdrückt wird.

Regular Expression Tagger

Manche Entitätstypen folgen klaren Mustern und können mit hoher Zuverlässigkeit durch reguläre Ausdrücke erkannt werden. Hierzu zählen z.B. Kreditkarten- oder Telefon- oder Versicherungsnummern aber auch in vielen Fällen Bauteilbezeichner oder andere firmeninterne Identifikatoren.

Fazit

Natural Language Processing und insbesondere Named Entity Recognition und Disambiguierung sollte Teil der Werkzeugkiste eines jeden Anwenders bei der Analyse von unstrukturierten Daten sein. Es existieren mehrere mächtige Toolkits und Services, die allerdings je nach Anwendungsgebiet kombiniert und verfeinert werden müssen. So erkennt DBpedia Spotlight nur Entitäten, die auch einen Wikipedia Eintrag haben, kann für diese aber reichhaltige Metadaten liefern. Der Stanford Tagger hingegen kann auch vollkommen unbekannte Personennamen aus dem textuellen Kontext erkennen, hat aber bei manchen Texten eine relativ hohe Falsch-Positiv-Rate. Eine Kombination der beiden Technologien und anwendungsspezifischen Listen von Entitäten kann daher zu qualitativ sehr hochwertigen Ergebnissen führen.