Tag Archive for: Data Science

Interview – Data Science in der FinTech-Branche

Christian Rebernik ist CTO bei Number 26 und zuständig für die technische Entwicklung dieses FinTech-Unternehmens. Er studierte Informatik und Wirtschaftsinformatik und kann auf langjährige Erfahrung als Software-Entwickler zurückgreifen. Seit etwa 2010 war er als CTO und CIO bei diversen eCommerce-christian-rebernikUnternehmen, u.a. bei Immobilien.net (heute ImmobilienScout24), PARSHIP und Zanox, tätig und gilt daher als ein etablierter IT-Manager, der seine Kenntnisse als Mentor des Axel Springer Plug and Play Accelerators weitergibt.

Data Science Blog: Herr Rebernik, wie sind Sie als CTO zum FinTech Number26 gekommen?

Ich durfte die Gründer im Accelerator 2013 als Mentor begleiten. Damals war das Produkt ausgelegt auf Teenager als Zielgruppe. 2014 änderten die Gründer Valentin und Maximilian das Produkt auf Number26, ein mobile-first Gehaltskonto mit Mastercard und der Vision das weltbeste Bankerlebnis zu bieten. Damit hatten sie aus meiner Sicht den richtigen Nerv der Zeit getroffen. Mein Erfahrung mit Banken war nicht positiv bis dato. Number26 hat aus meiner Sicht das Potential Bankwesen zu verändern.

Data Science Blog: Die FinTech-Szene möchte vieles besser machen als traditionelle Banken. Welche Rolle spielt Data Science dabei?

Beim Online-Banking etablierter Banken erhält man meistens nur eine reine Ansicht des Bankkontos, quasi eine statische und nicht kundenorientierte Darstellung des Kontostandes und der Kontotransaktionen. Wir glauben, diese Auflistung ohne Intelligenz ist nicht ausreichend und wenig auf den Kundenutzen fokussiert, mit der heutigen Technik kann man deutlich mehr bieten.
Unser Ziel ist es, eine der besten Customer Experience zu schaffen. Dank moderner Technologien haben wir viele unterschiedliche Möglichkeiten, um das zu erreichen. Eine davon ist es Smart Banking anzubieten, hier kommt Data Science ins Spiel.

Data Science Blog: Wofür nutzt Number26 Data Science genau?

Wir starten in Sachen Data Science jetzt erst voll durch. Unser erster Data Scientist wurde letztes Jahr im Oktober eingestellt. Unser Team ist also noch im Aufbau. Aktuell steht die sichere und number26appautomatisierte Kategorisierung von Finanztransaktionen bei uns im Fokus. Damit bieten wir den Nutzern leicht verständliche und genaue Auswertungen ihrer finanziellen Situation sowie eine Übersicht ihrer Einnahmen und Ausgaben. Interessanterweise gibt es unseres Wissens nach noch keine Bank, die Transaktionen direkt für den Kundennutzen kategorisiert.
Abhängig von der Transaktionsart nutzen wir unterschiedliche Methoden des maschinellen Lernens, die wir für die Erkennung der übergeordneten Kategorie verwenden.

Data Science Blog: Welche Machine Learning Methoden kommen zum Einsatz? Und wo finden die Analysen statt?

Wir haben mehrere ML-Methoden ausprobiert und durch eine Prototyping-Phase hinsichtlich ihrer Treffgenauigkeit bewertet. Wir setzen auf Amazon Webservices (AWS) und nutzen das Amazon Machine Learning Framework, auf dem wir auch unsere Modelle testen und Algorithmen erstellen. Der Input ist beispielsweise eine Kontotransaktion.
Unsere Algorithmen versuchen dieses dann zu kategorisieren. Daraus gewinnen wir zusätzliche Informationen, die wir unseren Kunden als Mehrwert anbieten.
Handelt es sich um eine Peer-to-Peer-Transaktion, wenn beispielsweise ich einem Freund Geld überweise, parsen wir den Verwendungszweck und nutzen Textmustererkennung zur Kategorisierung der Überweisung. Dazu splitten wir den Überweisungstext in einzelne Wörter auf, deren Bedeutung über Wörterbücher erkannt werden. Dadurch entstehen Kategorien, die vom Nutzer auch manuell nachträglich geändert werden können. Dieses Nutzerfeedback fließt in den Algorithmus zurück und wird in zukünftige Kategorisierungen mit einbezogen. Wir arbeiten nach mehreren Experimenten nun vermehrt mit Vector Spacing Modellen, wie dem k-Nearest-Neighbour-Algorithmus, über zurzeit 12 Achsen (Vektordimensionen). Jeder Vektor stellt eine Eigenschaft einer Transaktion dar, beispielsweise Geldbetrag, Verwendungszweck, Empfänger oder Währung. Je näher die Eigenschaften, die im Vektorraum als Punkte dargestellt werden, an den Eigenschaften anderer Finanztransaktion im selben Vektorraum liegen, desto wahrscheinlicher ist die Gemeinsamkeit als Kategorie.
Natürlich gibt es immer wieder False-Positives, die die eigentliche Herausforderung in Data Science darstellen. Beispielsweise lassen sich seltene Transaktionen wie die Zahnarztrechnung nur schwer trainieren. Wir trainieren unsere Kategorisierung der Banktransaktionen unter Einbeziehung der MasterCard-Kreditkartentransaktionen. Alle Vertragspartner bei MasterCard müssen einige Angaben mahcen, z.B. welche Art von Händler sie sind, Das hilft natürlich bei der Kategorisierung.

Data Science Blog: Der Beruf des Data Scientist wurde schon öfter als„Sexiest Job des 21. Jahrhunderts“ zitiert, gilt das auch in der Finanzindustrie?

Wir als FinTech-Unternehmen sind technologiegetrieben und in unserer Branche macht es wirklich Spaß, Probleme des Finanzalltags zu lösen. Neue Lösungen anzubieten, auf die vorher noch niemand gekommen ist, ist zwar nicht jedermanns Sache, unser Schlag Menschen entwickelt aber genau dafür die größte Leidenschaft.

Data Science Blog: Was sind Ihrer Meinung nach die alltäglichen Aufgaben eines Data Scientists und welche Skills sollte ein Data Scientist dafür mitbringen?

Die Arbeit als Data Scientist ist meines Erachtens dreigeteilt: ein Drittel Datenaufbereitung, ein Drittel Software-Entwicklung und ein Drittel Analyse.
Zum ersten Drittel gehört die Sichtung der Daten und Identifikation der Datenqualität. Ein Data Scientist muss aber auch Software-Entwickler sein und ein Verständnis für Software-Architekturen mitbringen. Große Datenmengen lassen sich nur über skalierbare Anwendungen auswerten. Wichtige Hilfsmittel und Testumgebungen müssen dafür selbst entwickelt werden.
Für die Analyse ist ein gutes Verständnis von Mathematik unumgänglich. Hinzu kommt ein ausgezeichnetes Verständnis für das Kerngeschäft des Unternehmens, in unserem Fall das Finanzwesen, um dementsprechend relevante Analysen durchzuführen.

Data Science mit Neo4j und R

Traurig, aber wahr: Data Scientists verbringen 50-80% ihrer Zeit damit, Daten zu bereinigen, zu ordnen und zu bearbeiten. So bleibt nur noch wenig Zeit, um tatsächlich vorausschauende Vorhersagemodelle zu entwickeln. Vor allem bei klassischen Stacks, besteht die Datenanalyse zum Großteil darin, Zeile für Zeile in SQL zu überführen. Zeit zum Schreiben von Modell-Codes in einer statistischen Sprache wie R bleibt da kaum noch. Die langen, kryptischen SQL-Abfragen verlangsamen aber nicht nur die Entwicklungszeit. Sie stehen auch einer sinnvollen Zusammenarbeit bei Analyse-Projekten im Weg, da alle Beteiligten zunächst damit beschäftigt sind, die SQL-Abfragen der jeweils anderen zu verstehen.

Komplexität der Daten steigt

Der Grund für diese Schwierigkeiten: Die Datenstrukturen werden immer komplexer, die Vernetzung der Daten untereinander nimmt immer stärker zu. Zwängt man diese hochgradig verbundenen Datensätze in eine SQL-Datenbank, in der Beziehungen naturgemäß abstrakt über Fremdschlüssel dargestellt werden, erhält man als Ergebnis übermäßig komplizierte Schematas und Abfragen. Als Alternative gibt es jedoch einige NoSQL-Lösungen – allen voran Graphdatenbanken – die solche hochkomplexen und heterogenen Daten ohne Informationsverlust speichern können – und zwar nicht nur die Entitäten an sich, sondern auch besonders die Beziehungen der Daten untereinander.

Datenanalysen zielen immer stärker darauf ab, das Verhalten und die Wünsche von Kunden besser verstehen zu können. Die Fragen lauten z. B.:

  • Wie hoch ist die Wahrscheinlichkeit, dass ein Besucher auf eine bestimmte Anzeige klickt?
  • Welcher Kunde sollte in welchem Kontext welche Produktempfehlungen erhalten?
  • Wie kann man aus der bisherigen Interaktionshistorie des Kunden sein Ziel vorhersagen, bevor er selbst dort ankommt?
  • In welchen Beziehungen steht Nutzer A zu Nutzer B?

Menschen sind bekanntermaßen von Natur aus sozial. Einige dieser Fragen lassen sich daher beantworten, wenn man weiß, wie Personen miteinander in Verbindung stehen: Unsere Zielperson, Nutzer A ähnelt in seinem Kontext und Verhalten Benutzer B. Und da Benutzer B ein bestimmtes Produkt (z. B. ein Spielfilm) gefällt, empfehlen wir diesen Film auch Nutzer A. In diese Auswertung fließen natürlich auch noch weitere Faktoren mit ein, z. B. die Demographie und der soziale Status des Nutzers, seine Zuordnung zu Peer Groups, vorher gesehene Promotions oder seine bisherigen Interaktionen.

Visualisierung eines Graphen mit RNeo4j

Mit R und Neo4j lassen sich Graphen und Teilgraphen ganz einfach mit RNeo4j, igraph und visNetwork libraries visualisieren.

library(igraph)
library(visNetwork)
library(RNeo4j)

 

Das folgende Beispiel zeigt wie in einem Graphen Schauspieler und Filme sowie ihre Beziehungen zueinander anschaulich dargestellt werden können, z. B. um Empfehlungen innerhalb eines Filmportals zu generieren. Dabei sind zwei Schauspieler über eine Kante miteinander verbunden, wenn sie beide im gleichen Film mitspielen.

Im ersten Schritt werden dazu in Neo4j die Film-Datensätze importiert (Achtung: Dieser Vorgang löscht die aktuelle Datenbank).

graph = startGraph("http://localhost:7474/db/data/")

importSample(graph, "movies", input=F)

Als nächstes wird mit Cypher eine entsprechende Liste von Beziehungen aus Neo4j gezogen. Wie man sehen kann, ist die Darstellung des gewünschten Graph-Musters innerhalb der Abfrage sehr anschaulich.

query = "
MATCH (p1:Person)-[:ACTED_IN]->(:Movie)<-[:ACTED_IN]-(p2:Person)
WHERE p1.name < p2.name
RETURN p1.name AS from, p2.name AS to, COUNT(*) AS weight
"

edges = cypher(graph, query)

head(edges)
## from to weight
## 1 Brooke Langton Keanu Reeves 1
## 2 Jack Nicholson Kevin Bacon 1
## 3 Jerry O'Connell Kiefer Sutherland 1
## 4 Oliver Platt Sam Rockwell 1
## 5 John Goodman Susan Sarandon 1
## 6 Gary Sinise Kevin Bacon 1

Die visNetwork Funktion erwartet sowohl Kanten-Dataframes als auch Knoten-Dataframes. Ein Knoten-Dataframe lässt sich daher über die eindeutigen Werte des Kanten-Dataframes generieren.

nodes = data.frame(id=unique(c(edges$from, edges$to)))
nodes$label = nodes$id

head(nodes)
## id label
## 1 Brooke Langton Brooke Langton
## 2 Jack Nicholson Jack Nicholson
## 3 Jerry O'Connell Jerry O'Connell
## 4 Oliver Platt Oliver Platt
## 5 John Goodman John Goodman
## 6 Gary Sinise Gary Sinise

Im Anschluss können die Knoten- und Kanten-Dataframes in das visNetwork übertragen werden.
visNetwork(nodes, edges)

Nun kommt igraph mit ins Spiel, eine Bibliothek von Graph-Algorithmen. Durch Einbindung der Kantenliste lässt sich einfach ein igraph Graph-Objekt erstellen, das den Teilgraphen miteinschließt.

ig = graph_from_data_frame(edges, directed=F)

ig
## IGRAPH UNW- 102 362 --
## + attr: name (v/c), weight (e/n)
## + edges (vertex names):
## [1] Brooke Langton --Keanu Reeves
## [2] Jack Nicholson --Kevin Bacon
## [3] Jerry O'Connell --Kiefer Sutherland
## [4] Oliver Platt --Sam Rockwell
## [5] John Goodman --Susan Sarandon
## [6] Gary Sinise --Kevin Bacon
## [7] J.T. Walsh --Noah Wyle
## [8] Jim Broadbent --Tom Hanks
## + ... omitted several edges

Die Größe der Knoten kann als Funktion der Edge-Betweeness-Centrality definiert werden. In visNetwork entspricht dabei jede “value”-Spalte im Knoten-Dataframe der Größe des Knoten.
nodes$value = betweenness(ig)

head(nodes)
## id label value
## 1 Brooke Langton Brooke Langton 0.000000
## 2 Jack Nicholson Jack Nicholson 511.443714
## 3 Jerry O'Connell Jerry O'Connell 154.815234
## 4 Oliver Platt Oliver Platt 20.643840
## 5 John Goodman John Goodman 1.659259
## 6 Gary Sinise Gary Sinise 33.723499

Mit Einführung der “Value”-Spalte werden die Knoten nun alle unterschiedlich groß dargestellt.
visNetwork(nodes, edges)

Mit Hilfe eines Community-Detection-Algorithmus lassen sich im Graphen nun Cluster finden. In diesem Beispiel wird der „Girvan-Newman”-Algorithmus verwendet, der in igraph als cluster_edge_betweenness bezeichnet wird.

clusters = cluster_edge_betweenness(ig)

clusters[1:2]
## $`1`
## [1] "Brooke Langton" "Liv Tyler" "Charlize Theron"
## [4] "Emil Eifrem" "Dina Meyer" "Diane Keaton"
## [7] "Keanu Reeves" "Gene Hackman" "Ice-T"
## [10] "Al Pacino" "Carrie-Anne Moss" "Clint Eastwood"
## [13] "Orlando Jones" "Takeshi Kitano" "Laurence Fishburne"
## [16] "Richard Harris"
##
## $`2`
## [1] "Jack Nicholson" "Jerry O'Connell" "J.T. Walsh"
## [4] "Renee Zellweger" "Kiefer Sutherland" "Cuba Gooding Jr."
## [7] "Marshall Bell" "Aaron Sorkin" "Kevin Bacon"
## [10] "Kevin Pollak" "Christopher Guest" "Demi Moore"
## [13] "Regina King" "Kelly Preston" "John Cusack"
## [16] "Danny DeVito" "Bonnie Hunt" "Corey Feldman"
## [19] "Jay Mohr" "James Marshall" "Jonathan Lipnicki"
## [22] "River Phoenix" "Tom Cruise" "Noah Wyle"
## [25] "Wil Wheaton" "John C. Reilly"

In der Liste oben sind alle Schauspieler der ersten zwei Cluster zu sehen. Insgesamt konnten sechs Cluster identifiziert werden.

length(clusters)
## [1] 6

Durch Hinzufügen einer “Group”-Spalte im Knoten-Dataframe, werden alle Knoten in visNetwork entsprechend ihrer Gruppenzugehörigkeit farblich markiert. Diese Cluster-Zuordnung erfolgt über clusters$membership. Durch Entfernen der “Value”-Spalte lassen sich die Knoten wieder auf eine einheitliche Größe bringen.

nodes$group = clusters$membership
nodes$value = NULL

head(nodes)
## id label group
## 1 Brooke Langton Brooke Langton 1
## 2 Jack Nicholson Jack Nicholson 2
## 3 Jerry O'Connell Jerry O'Connell 2
## 4 Oliver Platt Oliver Platt 3
## 5 John Goodman John Goodman 4
## 6 Gary Sinise Gary Sinise 3

Werden die Knoten- und Kanten-Datenframes erneut in visNetwork übertragen, sind nun alle Knoten eines Clusters in derselben Farbe dargestellt.
visNetwork(nodes, edges)

Mit diesem Workflow lassen sich Teilgraphen in Neo4j einfach abfragen und Cluster-Algorithmen einfach darstellen.

Generell eignen sich Graphdatenbanken wie Neo4j besonders gut, um stark vernetzte und beliebig strukturierte Informationen zu handhaben – egal ob es sich um Schauspieler, Filme, Kunden, Produkte, Kreditkarten oder Bankkonten handelt. Zudem können sowohl den Knoten als auch den Kanten beliebige qualitative und quantitative Eigenschaften zugeordnet werden. Beziehungen zwischen Daten sind also nicht mehr bloße Strukturinformationen, sondern stehen vielmehr im Zentrum des Modells.

Cypher: intuitiv nutzbare Programmiersprache

Die Zeiten, in denen Data Science zum Großteil aus Datenbereinigung und -mapping besteht, sind damit vorbei. Mit dem entsprechenden Ansatz laufen Entwicklungsprozesse deutlich schneller und einfacher ab. Data Scientists kommen mit weniger Code schneller ans Ziel und können mehr Zeit in das tatsächliche Entwickeln von relevanten Modellen investieren. Dabei nutzen sie die Flexibilität einer quelloffenen NoSQL-Graphdatenbank wie Neo4j kombiniert mit der Reife und weiten Verbreitung der Statistiksprache R für statistisches Rechnen und Visualisierung. Programmierer müssen nicht mehr stundenlang komplexe SQL-Anweisungen schreiben oder den ganzen Tag damit verbringen, eine Baumstruktur in SQL zu überführen. Sie benutzen einfach Cypher, eine musterbasierte, für Datenbeziehungen und Lesbarkeit optimierte Abfragesprache und legen los.

Interview – Advanced Data Science in der Finanz- und Versicherungsbranche

Dr. Andreas Braun von der Allianz SE spricht exklusiv mit dem Data Science Blog über die Bedeutung von Data Science in der Finanz- und Versicherungsindustrie und was er von einem guten Data Scientist erwartet.

dr-andreas-braunDr. Andreas Braun ist Head of Global Data & Analytics bei der Allianz SE in München. Der promovierte Informatiker von der TU München begann seine Karriere als Berater bei Accenture, leitete danach verschiedene Abteilungen für Analyse und Digitalisierung und zuletzt den globalen Geschäftsbereich Business Applications bei der GfK SE. Er gilt heute als eine der erfahrensten Führungskräfte mit explizitem Know How in der Nutzung von Data & Analytics.

Data Science Blog: Herr Dr. Braun, welcher Weg hat Sie bis an die Analytics-Spitze der Allianz SE geführt?

Als Informatiker kam ich über Software-Entwicklung und Verteilte Systeme zur Datenanalyse. Schon während des Studiums war ich Mitbegründer einer Software-Firma, die Bildverarbeitungs- und Analyse-Software entwickelte. Der Schwenk hin zur Entwicklung von Systemen künstlicher Intelligenz kam während der Promotion an der TUM, insbesondere, da mein Doktorvater erst kürzlich von der Carnegie Mellon University (CMU) dorthin gewechselt hatte. (An der CMU wurde der Begriff Künstliche Intelligenz ja ursprünglich geprägt.) Dadurch hatte ich mir Schwerpunkte auf global verteilte Systeme und Künstliche Intelligenz gesetzt. Nach meinem akademischen Ausbildungsweg war ich dann in der Unternehmensberatung und später in der Marktforschung tätig. Als Global Head für Business Applications bei der GfK SE, der Gesellschaft für Konsumforschung, haben wir bereits 2011 auf Big Data Technologien, wie Hadoop und NoSQL,  gesetzt.

Als die Allianz sich auf Gruppenebene verstärkt im Bereich Digitalisierung und somit auch Data Analytics und Data Science aufstellte und konsequent ein eigenes Data & Analytics Team aufbaute, kam für mich die Gelegenheit zum Wechsel nach München. Seit Mai 2014 leite ich nun Global Data & Analytics (GD&A) bei der Allianz SE und setze vor allem auf Leute, die bereits Data Analytics und Data Science Expertise mitbringen, oft auch von außerhalb der Finanz- und Versicherungsindustrie.

Data Science Blog: Welche Rolle sehen Sie für Big Data Analytics in der Finanz- und Versicherungsbranche?

Aus meiner Sicht ist sogenannte „Big Data“ Technologie, also verteilte Systeme, neue Datenbanken usw., die eigentliche Maschinerie hinter der Digitalisierung. Es gibt zunehmend viele „Frontends“, also z. B. Benutzeroberflächen, (mobile) Geräte und Sensoren, für Anwender, mit denen Daten generiert werden. Webseiten, Apps, Smartphones und Connected Cars sind für sich gesehen jedoch noch nicht besonders intelligent und somit eingeschränkt nützlich. Die wirklich nutzbringende Intelligenz basiert auf Kontext, Daten und Analytics und ergibt sich erst durch die Vernetzung unzähliger Einzelkomponenten über Data Analytics Systeme. Auf dieser Basis lassen sich dann neue und digitale Geschäftsmodelle fördern.

Viele der heute gängigen Anwendungsfälle sind vielleicht von der Grundidee her manchmal ein alter Hut, lassen sich durch die jetzt verfügbare Technologie aber deutlich besser oder gar erstmalig lösen. Beispielsweise betreibt die Allianz Betrugserkennung schon sehr lange. Mittlerweile lassen sich jedoch komplexe oder gar organisierte Betrugsnetzwerke mit Ansätzen wie maschinellem Lernen (Machine Learning) und Graphen-Datenbanken sehr viel schneller, deutlich zuverlässiger und auch noch kostengünstiger aufdecken. Dadurch entstand bereits ein erheblich messbarer Vorteil für die Versichertengemeinschaft!

Data Science Blog: Wie arbeitet das Data & Analytics Team?

Im Data & Analytics Team werden daten-getriebene und analytische Anwendungsfälle („Use Cases“) pilotiert, prototypisch umgesetzt, methodisch validiert und auf unserer Referenzarchitektur („Stack“) aufgesetzt.

Ich glaube, die Data Scientists fühlen sich hier wohl, da wir für die unterschiedlichsten Fachbereiche und Landesgesellschaften tätig werden, die über große und sehr variantenreiche Datenquellen verfügen und sehr vielseitige Problemstellungen mitbringen. Abwechslung sowie beständiges Lernen sind somit garantiert. Für die Fachbereiche bieten wir alles aus einer Hand und geben einen schnellen Einstieg in die produktive Nutzung von großen und verteilten Datenbeständen.

Wir fühlen uns eigentlich fast wie ein eigenes Start-Up innerhalb des Konzerns und haben unsere eigene Infrastruktur. Das gibt uns Geschwindigkeit und Flexibilität bei gleichzeitig höchsten Standards für Sicherheits- und Datenschutz.

Data Science Blog: Finden die Analysen nur in Ihrem Team oder auch in den Fachbereichen statt?

Die Projekte werden in der Regel bei uns zentral durchgeführt, werden dabei aber meist vom Fachbereich angestoßen. Wir arbeiten dabei mit den jeweiligen Kollegen Hand in Hand. Die Fachbereiche sind stets eingeladen, möglichst eng mit uns zusammen zu arbeiten. Natürlich gibt es aber auch Projekte, die zentral ansetzen und im Wesentlichen erstmal von uns allein getrieben werden, insbesondere Themen, die eher R&D sind.

Data Science Blog: In wie weit werden unstrukturierte Daten in die Analysen einbezogen?

Unstrukturierte Daten spielen eine immer größere Rolle. Ich vermute, dass bereits etwa 70% der verwendeten Daten nach Volumen unstrukturiert oder semi-strukturiert sind.

Data Science Blog: Werden diese vollwertig genutzt oder sind diese nur eine Vorstufe, bevor sie in eine strukturierte Datenbank gespeist werden?

Unstrukturierte Daten werden bei uns nicht in eine strukturierte Datenbank überführt. Grundsätzlich belassen wir Rohdaten i.d.R. möglichst unverändert.

Aus technischer Sicht liegt unser Fokus vor allem auf den sogenannten NoSQL-Datenbanken und dazu passenden Datenformaten, wie z. B. großen, flachen Tabellen („Bigtable“), Parquet- und neuen Prozessmodellen, wie Streaming und Microbatches usw. Relationale Datenbanken spielen dabei eine eher untergeordnete Rolle, haben aber natürlich auch weiterhin ihre Berechtigung, beispielsweise für Meta-/ Stammdaten.

Data Science Blog: Die Allianz als Versicherer besitzt personenbezogene Datenbestände, welche Rolle spielt in Ihrer Arbeit der Datenschutz?

Wir befassen uns sehr viel mit IT-Sicherheit, Datenschutz (Data Privacy) und Datenethik. Die rechtlich zulässige Nutzung von Daten setzt für uns den Rahmen jeglicher Aktivitäten. Und während wir in Bezug auf IT-Sicherheit auf erhebliche Erfahrungswerte und Lösungsmuster zurückgreifen können, sind Data Privacy und Datenethik neue Themenkomplexe im Bereich der Datenanalytik, die sehr eng mit der Analyse verknüpft sind. Ich glaube, dass die letztliche Komplexität hierbei noch nicht vollständig erfasst ist, weswegen wir uns auch stark in der Forschung und Entwicklung in diesem Feld engagieren.

So hat die Allianz kürzlich einen Lehrstuhl für „Großskalige Datenanalyse und Maschinelles Lernen“ an der TU-München gestiftet, wovon wir uns u.a. einen Beitrag zur Erörterung entsprechender Fragen zur Datennutzung  erhoffen.

Data Science Blog: Welche Art von Data Scientists suchen Sie für Ihre zukünftigen Umsetzungen?

Data Scientists können bei uns abwechslungsreich arbeiten und für verschiedene Projekte unterschiedliche Rollen einnehmen und daran wachsen. Unsere Kollegen haben vorwiegend einen ingenieur- oder naturwissenschaftlichen Hintergrund, vor allem Informatiker, Physiker, Mathematiker und Statistiker, aber auch beispielsweise Psychologen.

Data Science Blog: Suchen Sie eher den introvertierten Nerd oder den kommunikationsstarken Beratertyp?

Wir suchen vor allem Hardcore Data Scientists, dazu gehören für mich eher die Naturwissenschaftler. Für uns ist Data Science programmatisch, also ganz klar abgegrenzt von „Klick“-orientierter Business Intelligence. Im Data Science kommen verschiedene Tools und Programmiersprachen zum Einsatz. Die meisten Data Scientists sind zwar keine Software-Entwickler, aber dennoch werden die Aufgaben im Kern durch Programmierung unter Einsatz von statistischen Verfahren und Methoden des maschinellen Lernens gelöst. Von einem Data Scientist erwarte ich darüber hinaus, dass die Qualität eines Modells nicht nur bloß eingeschätzt, sondern auch methodisch fundiert belegt werden kann.

Auf der anderen Seite haben wir auch Business Analysts, die vor allem in der Koordination der Use Cases eingesetzt werden. Ein Business Analyst versteht den Businesskontext und den Geschäftszweck von Daten und Analysen, unterstützt im Projektmanagement und kümmert sich um die Kommunikation und Implementierung in den Fachbereichen.

Data Science Blog: Unterscheiden Sie in Ihrem Bereich auch zwischen Data Scientist und Data Engineer?

Ja. In meinem Team arbeiten ungefähr 30% Data Engineers, 60% sind Data Scientists und 10% Business Analysts. Unsere Data Engineers kümmern sich um u.a. den Technologie und Tool-Stack und das Engineering.

Ich denke, viele der momentan kommerziell sehr erfolgreichen Use Cases sind sehr Engineering-lastig, haben also mit Datenhaltung, -transformation, -bewegung und Ausführbarkeit bzw. Anwendung zu tun. Dann spielt dabei Daten und Software Engineering sogar die größere Rolle als Data Science.

Und obwohl wir genau diese Jobtitel, also Data Scientist, Data Engineer und Business Analyst, haben, sind die Grenzen dazwischen fließend. Für unseren agilen Ansatz ist dabei vor allem wichtig, dass alle Mitarbeiter auf Augenhöhe in einem „self-contained“ Team zusammenarbeiten.

Interview – Wie der Einstieg in Data Science gelingt

dr-alexander-beckAlexander Beck ist promovierter Ökonom und Physiker und hat in seiner Karriere sowohl selbst als Quant wie auch als Consultant im Data Science Bereich gearbeitet. Heute leitet er ein Data Science Team beim Bezahldienstleister PAYMILL in München, einer der führenden Payment Service Provider in Europa. Die E-Payment Lösung von PAYMILL erlaubt sichere und einfache Online Zahlungen.

Data Science Blog: Herr Dr. Beck, wie waren Ihre ersten 100 Tage in der Arbeitswelt von Paymill?
Spannend. Obwohl Paymill mit sehr fähigen Entwicklern arbeitet, war die erste Zeit davon geprägt, die richtigen Grundsteine für skalierbare und hochautomatisierte Daten-Analytik zu legen. Hierbei haben wir bewusst auf Open Source Technologien gesetzt, so zum Beispiel das Datenanalyse-Framework Python Pandas. Zudem setzen wir zur automatisierten Workflow-Steuerung die Software Airflow ein, die von AirBnB als Open Source Projekt entwickelt wird. Damit haben wir ein System geschaffen, mit dem wir sehr schlank, flexibel und nutzenorientiert arbeiten können und uns nicht mit Lizenzen und ähnlichen Dingen herumschlagen müssen.

Data Science Blog: Wie nutzt Paymill Data Science und was lässt sich damit erreichen?
Die Bandbreite hier ist wirklich groß und reicht von vollautomatisiertem Reporting bis hin zum Einsatz von Natural Language Processing und Predictive Analytics. Dabei gehen wir immer vom Nutzen des End-Anwenders aus und versuchen, unsere Lösungen für den Anwender so einfach und treffend wir möglich zu gestalten – meistens ist das Endprodukt eine schlanke Website, die alle relevanten Informationen enthält und die natürlich regelmäßig aktualisiert wird. Hierbei setzen wir auf 100% automatisierbare Konzepte. Datenanalyse soll dem Unternehmen dabei helfen, proaktiv und informiert statt reaktiv und uninformiert zu sein, das gelingt uns an vielen Stellen schon recht gut.

Data Science Blog: Viele Entscheider beklagen, dass Big Data nur den Konzernen nutzt, während der deutsche Mittelstand eher außen vor bleibe. Welche Hürden haben Mittelständler hier zu überwinden?
Viele Mittelständler verfügen heute nicht über die Datengrundlage, die nötig wäre, von diesem Trend zu profitieren. Hier sollte der Mittelstand beherzt handeln und lieber einen Euro zu viel als zu wenig an den entscheidenden Stellen investieren. Fairerweise muss man wohl sagen, dass nicht jedes Geschäftsmodell für den Einsatz von Data Science geeignet ist bzw. davon profitieren wird. Hier lohnt sich in den meisten Fällen eine Analyse der drei vielversprechendsten Anwendungsfälle aus Sicht der Unternehmensführung. Dann sollte neben einer Investitionsrechnung auch eine Analyse der Datenlage und Schritte zur Verbesserung dieser vorgenommen werden. Hierfür habe ich beispielsweise das DIFA Framework entwickelt.

Data Science Blog: An welchen Stellen eines Unternehmens können am schnellsten Mehrwerte gewonnen werden?
Das hängt natürlich sehr vom Geschäftsmodell ab. Im eCommerce beispielsweise ist die Sicherung der Kundenbeziehung durch zielgerichtete und effektive Maßnahmen sicherlich einer der stärksten Hebel. Zudem ist dies ein Anwendungsfall, wo im Unternehmen auch ausreichend Daten vorliegen um mit Analytics echte Mehrwerte zu schaffen. Fraud ist ein weiteres Anwendungsgebiet das nebenbei auch sehr zukunftsfähig ist, schaut man sich die aktuellen Fraud-Zahlen beispielsweise beim Kreditkarten Betrug an. Hier hilft man übrigens gleich doppelt: Man schützt Kunden davor, Opfer von Betrug zu werden und erleichtert der hausinternen Abteilung die Arbeit im Umgang mit Fraud-Fällen.

Data Science Blog: Wie sollte ein mittelständisches Unternehmen in Big Data und Data Science einsteigen?
Ein mittelständisches Unternehmen sollte sich von einem unabhängigen Experten beraten lassen. Dieser sollte neben der Data Science Kompetenz auch Branchen- und Prozesskenntnisse besitzen. Es ist übrigens auch nicht per se für jedes Unternehmen gesetzt, dass es mit Big Data und Data Science Mehrwerte für sich generieren kann. Überall dort wo ein Prozess in hoher Frequenz abläuft, die äußeren Parameter eine gewisse Varianz vorgeben und eine monetäre Verknüpfung existiert, macht Datenanalyse aber vermutlich Sinn. Ein ganz klassisches Beispiel hierfür ist die Kreditvergabe.

Data Science Blog: Lässt sich Data Science auch outsourcen? Wenn ja, was spräche dafür oder dagegen?
Was dafür spricht: Das Skillset des Data Scientist ist schon ein Besonderes und der Markt an guten Data Scientists ist knapp. Zudem ist der Aufbau von Technologie natürlich auch immer mit Kosten für Installation und Wartung verbunden, die teilweise nicht unerheblich sind. Gegen Outsourcing sprechen aus meiner Sicht aber weit gewichtigere Gründe. Um echte Mehrwerte zu schaffen, muss ein Data Scientist einen barriereferien Zugang zu den Mitarbeitern und den Daten des Unternehmens haben. Nur so lassen sich meines Erachtens Prozesse, Daten und alle Besonderheiten im Detail verstehen und nachvollziehen. Der häufig zitierte 80/20 Berater-Ansatz funktioniert im Data Science Umfeld meistens nicht. Sie müssen sich also auf eine ganz andere Art und Weise in einem Unternehmen auskennen, als dies einem Außenstehenden in einem vernünftigen Kostenrahmen gelingen wird. Aus meiner eigenen Erfahrung kann ich sagen, dass wir bei Paymill auf unsere erfolgreichsten Anwendungsfälle durch Gespräche in der Kaffee-Ecke gestoßen sind, hierfür müssen Sie Teil des Teams sein.

Data Science Blog: Sie haben bereits viele Analytics-Projekte betreut. Wie hoch ist die Quote an erfolgreichen Projekten gegenüber den nicht erfolgreichen? Konnten Sie Gründe für das Scheitern von solchen Projekten identifizieren?
Wenn Sie Erfolg damit assoziieren, wie hoch die Quote ist, wo wir dem Kunden weiterhelfen konnten, dann sage ich: sehr hoch. Allerdings sind hier auch Fälle dabei, wo wir einem Kunden sagen konnten, wo noch Hausaufgaben beispielsweise in der Datenhaltung zu erledigen sind. So gab es einmal einen Fall, wo eine Vertriebsmannschaft mit Prognosen unterstützt werden sollte. Die Datenbasis bestand allerdings nur aus erfolgreichen Abschlüssen, die nicht-erfolgreichen Vertriebsaktivitäten waren nicht aufgezeichnet worden. Hier müssen also erst einmal Daten vervollständigt werden, bevor über Predictive Analytics gesprochen wird. Trotzdem haben wir dem Unternehmen mit dieser Erkenntnis und einer Anleitung für nächste Schritte weitergeholfen.

Data Science Blog: Sollten Data Scientists in den jeweiligen Fachbereichen oder in der IT angesiedelt sein oder sogar eine eigene Stabstelle darstellen?
Ich habe gute Erfahrungen damit gemacht, wenn Data Science als eigenständige Einheit funktioniert. So lassen sich Anwendungsfälle, die über einzelne Departments hinausgehen, besser umsetzen. Zudem ist es auch einfach abwechslungsreicher für die Data Scientists.

Data Science Blog: Wann ist mit einem Break-Even-Point zu rechnen, wenn ein Unternehmen die Investition plant, eine Data Science Abteilung aufzubauen? Sie sollten vor der Gründung einer Data Science Abteilung eine realistische Machbarkeitsstudie durchführen. Nicht jedes Unternehmen und Geschäftsmodell wird in gleichem Maße von einer Data Science Abteilung profitieren. Ich würde aber sagen, dass man schon mit 10 bis 12 Monaten rechnen muss. Diese Zahl hängt aber sehr stark davon ab, wie viel Aufbau- und Aufräumarbeit bei der Datanbasis geleistet werden muss. Schlussendlich sollten auch immer weiche Faktoren mit in die Rechnung genommen werden. Eventuell fühlen sich Kunden durch entsprechende Maßnahmen besser angesprochen oder strategische Entscheidungen können auf einer soliden Datengrundlage getroffen werden. Das werden Sie nicht 1:1 in einer monetären Kenngröße abgebildet sehen, der positive Effekt ist aber zweifelsfrei vorhanden.

Data Science Blog: Die Methodenvielfalt scheint groß zu sein: Predictive Analytics, Distributed Data Processing, Realtime Analytics, Machine Learning. Welche Methoden bringen den größten Mehrwert?
Ich glaube das lässt sich so allgemein nicht beantworten. Sehr gute Erfahrungen haben wir mit automatisierten Warnsystemen gemacht – diese liefern einen sehr direkten und messbaren Mehrwert und sind verhältnismäßig zügig und ohne große Kosten aufgebaut. Auch hier kommt interessante Analytics zum Einsatz. Nehmen Sie als Beispiel einen Anbieter von Webhosting der messen möchte, ob eine Webseite Opfer einer Massenanfragen-Attacke ist. Hier müssen Sie clevere Analytics verwenden, sonst klemmen Sie im schlimmsten Fall einem Ihrer Kunden zur besten Verkaufszeit die Webseite ab.

Data Science Blog: Was macht Ihrer Meinung nach einen guten Data Scientist aus? Welche Skills sollte ein Data Scientist haben und wie können Neulinge diese erwerben?
Sie sollten ihr Handwerk grundlegend verstehen. Damit meine ich das Verarbeiten von Daten und die Anwendung von Standard Analytics Verfahren. Selbstverständlich sollten Sie sehr flüssig programmieren können, meiner Ansicht nach idealerweise in Python. Diese beiden Eigenschaften sind nicht hinreichend, aber die Basis Ihres Erfolgs. Daneben sollten Sie eine absolute Umsetzer-Mentalität und ein Bewusstsein für hohe Qualität haben. Wenn Sie dazu noch Spaß daran haben, Ihre Arbeit anderen zu erklären und eigenständig werthaltige Anwendungsszenarieren aufzuspüren, sind Sie – denke ich – sehr gut aufgestellt. Neulinge sollten sich nicht vom Hype um Data Science verrückt machen lassen, sondern sich bewusst sein, dass auch hier der erste Schritt darin besteht, ein solides Handwerk zu erlernen mit dem Sie später viel anfangen können.

Data Science vs Data Engineering

Das Berufsbild des Data Scientsts ist gerade erst in Deutschland angekommen, da kommen schon wieder neue Jobbezeichnungen auf uns zu. “Ist das wirklich notwendig?”, wird sich so mancher fragen. Aber die Antwort lautet ganz klar: ja!

Welcher Data Scientist kennt das nicht: ein Recruiter ruft an, spricht von einer tollen neuen Herausforderung für einen Data Scientist wie man es sich ja offensichtlich auf seinem LinkedIn-Profil für sich beansprucht, doch bei der Besprechung der Vakanz stellt sich schnell heraus, dass man über fast keine der geforderten Skills verfügt. Dieser Mismatch liegt vor allem daran, dass unter den Job des Data Scientist alle möglichen Tätigkeitsprofile, Methoden- und Tool-Wissen zusammengefasst werden, die ein einzelner Mensch kaum in seinem Leben lernen kann.

Viele offene Jobs, die unter der Bezeichnung Data Science besetzt werden sollen, beschreiben eher das Berufsbild des Data Engineers.


english-flagRead this article in English:
“Data Scientist vs Data Engineer – What is the Difference?”


Was macht ein Data Engineer?

Im Data Engineering geht es vor allem darum, Daten zu sammeln bzw. zu generieren, zu speichern, historisieren, aufzubereiten, anzureichern und nachfolgenden Instanzen zur Verfügung zu stellen. Ein Data Engineer, je nach Rang oft auch als Big Data Engineer oder Big Data Architect bezeichnet, modelliert skalierbare Datenbank- und Datenfluss-Architekturen, entwickelt und verbessert die IT-Infrastruktur hardware- und softwareseitig, befasst sich dabei auch mit Themen wie IT-Security, Datensicherheit und Datenschutz. Ein Data Engineer ist je nach Bedarf teilweise Administrator der IT-Systeme und auch ein Software Entwickler, denn er erweitert die Software-Landschaft bei Bedarf um eigene Komponenten. Neben den Aufgaben im Bereich ETL / Data Warehousing, führt er auch Analysen durch, zum Beispiel solche, um die Datenqualität oder Nutzerzugriffe zu untersuchen.

Ein Data Engineer arbeitet vor allem mit Datenbanken und Data Warehousing Tools.

Ein Data Engineer ist tendenziell ein ausgebildeter Ingenieur/Informatiker und eher weit vom eigentlichen Kerngeschäft des Unternehmens entfernt. Die Karrierestufen des Data Engineers sind in der Regel:

  1. (Big) Data Architect
  2. BI Architect
  3. Senior Data Engineer
  4. Data Engineer

Was macht ein Data Scientist?

Auch wenn es viele Überschneidungspunkte mit dem Tätigkeitsfeld des Data Engineers geben mag, so lässt sich der Data Scientist dadurch abgrenzen, dass er seine Arbeitszeit möglichst dazu nutzt, die zur Verfügung stehenden Daten explorativ und gezielt zu analysieren, die Analyseergebnisse zu visualisieren und in einen roten Faden einzuspannen (Storytelling). Anders als der Data Engineer, bekommt ein Data Scientist ein Rechenzentrum nur selten zu Gesicht, denn er zapft Daten über Schnittstellen an, die ihm der Data Engineer bereitstellt.

Ein Data Scientist befasst sich mit mathematischen Modellen, arbeitet vornehmlich mit statistischen Verfahren und wendet sie auf die Daten an, um Wissen zu generieren. Gängige Methoden des Data Mining, Machine Learning und Predictive Modelling sollten einem Data Scientist bekannt sein, wobei natürlich jeder ganz individuell Schwerpunkte setzt. Data Scientists arbeiten grundsätzlich nahe am Fachbereich und benötigen entsprechendes Fachbereichswissen. Data Scientists arbeiten mit proprietären Tools (z. B. von IBM, SAS oder QlikTech) und programmieren Analysen auch selbst, beispielsweise in Scala, Java, Python, Julia oder R.

Data Scientists können vielfältige akademische Hintergründe haben, einige sind Informatiker oder Ingenieure für Elektrotechnik, andere sind Physiker oder Mathematiker, nicht wenige auch Wirtschaftswissenschaftler.

  1. Chief Data Scientist
  2. Senior Data Scientist
  3. Data Scientist
  4. Data Analyst oder Junior Data Scientist

Data Scientist vs Data Analyst

Oft werde ich gefragt, wo eigentlich der Unterschied zwischen einem Data Scientist und einem Data Analyst läge bzw. ob es dafür überhaupt ein Unterscheidungskriterium gäbe:

Meiner Erfahrung nach, steht die Bezeichnung Data Scientist für die neuen Herausforderungen für den klassischen Begriff des Data Analysten. Ein Data Analyst betreibt Datenanalysen wie ein Data Scientist, komplexere Themen, wie Predictive Analytics und Machine Learning bzw. künstliche Intelligenz, sind aber eher was für den Data Scientist. Ein Data Scientist ist sozusagen ein Data Analyst++.

Und ein Business Analyst?

Business Analysten können (müssen aber nicht) auch Data Analysten sein. In jedem Fall haben sie einen sehr starkem Bezug zum Fachbereich bzw. zum Kerngeschäft des Unternehmens. Im Business Analytics geht es um die Analyse von Geschäftsmodellen und Geschäftserfolgen. Gerade die Analyse von Geschäftserfolgen geschieht in der Regel IT-gestützt und da setzen viele Business Analysten an. Dashboards, KPIs und SQL sind das Handwerkszeug eines guten Business Analysten.

 

Interview – Big Data in der Industrie

Thomas Schott, CIO der Rehau GruppeThomas Schott ist seit den 01. Oktober 2011 als CIO für die REHAU Gruppe tätig. Kompetenz und Innovationsfreude haben REHAU zum führenden System- und Service-Anbieter polymerbasierter Lösungen in den Bereichen Bau, Automotive und Industrie gemacht. Höchste Professionalität von der Materialentwicklung bis zur Ausführung sowie die Leidenschaft für das faszinierende unbegrenzte Nutzenpotenzial polymerer Werkstoffe sind für REHAU Grundvoraussetzung, um als führende Premiummarke weltweit erfolgreich zu sein.
In 2008 wurde Herr Schott mit dem erstmals verliehenen „Green CIO Award“ ausgezeichnet. 2010 wurde er außerdem bei der Wahl zum „CIO des Jahres“ in der Kategorie „Global Exchange Award“ mit dem 3. Platz ausgezeichnet und landete in 2012 in der Kategorie Großunternehmen wieder unter den Top 6.

Data Science Blog: Herr Schott, welcher Weg hat Sie an die Spitze der IT bei REHAU geführt?

Ich hatte ursprünglich Elektrotechnik mit dem Schwerpunkt Datenverarbeitung an der TU München studiert und startete meine Karriere bei REHAU bereits im Jahr 1990. Schnell war ich in leitender Funktion für verschiedene IT-Bereiche zuständig und habe die Standardisierung, Konsolidierung und durchgängige Virtualisierung der IT-Systemlandschaft maßgeblich vorangetrieben. Die IT- und Collaboration-Systeme für weltweit mehr als 170 Niederlassungen der REHAU Gruppe laufen nun in einer konsolidierten Private Cloud, ein sehr wichtiges Ziel für das Unternehmen um schnell und flexibel agieren zu können.

Data Science Blog: Big Data und Industrie 4.0 gelten derzeit als zwei der größten Technologie-Trends, dabei scheint jede Branche diesen Begriff für sich selbst zu interpretieren. Was bedeutet Big Data für Sie? Wie sieht Big Data aus der Perspektive der verarbeiten Industrie aus?

An einer allumfassenden Definition mangelt es noch, unsere Bestrebungen zur Industrie 4.0 liegen unter anderem in den Themengebieten Predictive Maintenance, Qualitätsdatenmanagement, mobile Apps bis hin zur Lieferkette (Kunden und Lieferanten). Big Data ist dabei ein wichtiger Treiber für Industrie 4.0 und auch ein eigenes Thema, welches auch außerhalb der Produktion eine Rolle spielt.
Für die produzierende Industrie erlangt Big Data eine immer größere Bedeutung, denn es fallen immer mehr Produktionsdaten und Daten aus der Qualitätssicherung an. Wir sammeln unternehmensintern bereits Daten in solcher Vielfalt und Masse, Big Data ist bereits Realität, und das obwohl wir externe Daten noch gar nicht thematisiert haben.

Data Science Blog: Der Trend ist also seinem Ende noch nicht nahe?

Nein, denn abgesehen von Unternehmen, deren Kerngeschäft Industrie 4.0 Lösungen selbst sind, steht die traditionelle Industrie und unsere gesamte Branche in Sachen Produktionsdatenanalyse und Big Data Analytics eher noch am Anfang.

Data Science Blog: Sie haben die unternehmensweite Cloud bei REHAU bereits erfolgreich umgesetzt, führt an der Digitalisierung kein Weg um Cloud Computing herum?

Wir haben seit zehn Jahren den Ansatz einer Private Cloud konsequent verfolgt. Ein Unternehmen unserer Größe kommt um eine ausgeklügelte und konsolidierte Could-Sourcing Strategie nicht herum. Dazu gehören jedoch auch festgelegte Standards für die Nutzung.

Data Science Blog: Gerade beim Thema Cloud zucken jedoch viele Entscheider zusammen und verweisen auf Risiken für die Datensicherheit. Wie gehen Sie mit dem Thema um – Und bremsen diese Maßnahmen das Engagement, Daten zusammen zu führen und auszuwerten?

Datensicherheit wird ein immer wichtigeres Thema und wir sensibilisieren unsere internen Kunden und IT-Anwender dafür. Im Zuge der rasanten Entwicklung im Umfeld Industrie 4.0 und Industrialisierung benötigen wir zeitnah valide und zielführende Nutunzgsstandards für Cloud und Big Data Lösungen.

Data Science Blog: Wenn Sie von Analyse sprechen, denken Sie vor allem an die rückblickende Analyse oder eine solche in nahezu Echtzeit?

An beides gleichermaßen, denn je nach Problemstellung oder Optimierungsbestrebungen ist das richtige Analyseverfahren anzuwenden.

Data Science Blog: Kommen die Bestrebungen hin zur Digitalisierung und Nutzung von Big Data gerade eher von oben aus dem Vorstand oder aus der Unternehmensmitte, also aus den Fachbereichen, heraus?

In der traditionellen Industrie kommen die Bemühungen überwiegend vom Vorstand und mir als CIO. Es ist unsere Aufgabe, existierende und kommende Trends rechtzeitig zu erkennen. Big Data und Industrie 4.0 werden immer wichtiger. Es ist wettbewerbsentscheidend, hier am Ball zu bleiben. Und das nicht nur für die eigene Kosten- und Prozessoptimierung, sondern auch, um sich am Markt zu differenzieren. Wir müssen diese Technologien und Methoden in unseren Fachbereichen etablieren und die dafür notwendige Veränderungsbereitschaft anregen.

Data Science Blog: Finden die Analysen in den Fachbereichen oder in einer zentralen Stelle statt?

Das hängt sehr von den einzelnen Analysen und dem damit verbundenen Aufwand ab. Die Einrichtung eines zentralen Datenlabors mit der entsprechenden Kompetenz und ausgebildeten Daten Scientists ist allerdings ein guter Weg, um komplexe Analysen, für die die Fachbereiche keine Kapazitäten / Skills haben, experimentell umsetzen zu können.

Data Science Blog: Für die Data Scientists, die Sie für Ihre zukünftigen Umsetzungen von Big Data Analysen suchen, welche Kenntnisse setzen Sie voraus? Und suchen Sie eher den introvertierten Nerd oder den kommunikationsstarken Beratertyp?

Ein Data Scientist sollte meines Erachtens sehr gute Kenntnisse über moderne Datenbanken sowie Erfahrung in der Auswertung von unstrukturierte Daten haben, aber auch viel Kreativität für die Darstellung von Sachverhalten mitbringen und auch mal „querdenken können“.
Wir suchen eher Experten aus der Informatik und Mathematik, aber auch kommunikative, kreative Spezies und neugierige Menschen, die jedoch auch eine ausgeprägte analytische Denkweise aufweisen sollten.

Text Mining mit R

R ist nicht nur ein mächtiges Werkzeug zur Analyse strukturierter Daten, sondern eignet sich durchaus auch für erste Analysen von Daten, die lediglich in textueller und somit unstrukturierter Form vorliegen. Im Folgenden zeige ich, welche typischen Vorverarbeitungs- und Analyseschritte auf Textdaten leicht durchzuführen sind. Um uns das Leben etwas leichter zu machen, verwenden wir dafür die eine oder andere zusätzliche R-Library.

Die gezeigten Schritte zeigen natürlich nur einen kleinen Ausschnitt dessen, was man mit Textdaten machen kann. Der Link zum kompletten R-Code (.RMD) findet sich am Ende des Artikels.

Sentimentanalyse

Wir verwenden das Anwendungsgebiet der Sentimentanalyse für diese Demonstration. Mittels der Sentimentanalyse versucht man, Stimmungen zu analysieren. Im Prinzip geht es darum, zu erkennen, ob ein Autor mit einer Aussage eine positive oder negative Stimmung oder Meinung ausdrückt. Je nach Anwendung werden auch neutrale Aussagen betrachtet.

Daten einlesen

Datenquelle: ‘From Group to Individual Labels using Deep Features’, Kotzias et. al,. KDD 2015

Die Daten liegen als cvs vor: Die erste Spalte enhält jeweils einen englischen Satz, gefolgt von einem Tab, gefolgt von einer 0 für negatives Sentiment und einer 1 für positives Sentiment. Nicht alle Sätze in den vorgegebenen Daten sind vorklassifiziert.

Wir lesen 3 Dateien ein, fügen eine Spalte mit der Angabe der Quelle hinzu und teilen die Daten dann in zwei Datensätze auf. Der Datensatz labelled enthält alle vorklassifizierten Sätze während alle anderen Sätze in unlabelled gespeichert werden.

## 'readSentiment' liest csv ein, benennt die Spalten und konvertiert die Spalte 'sentiment' zu einem Faktor 
amazon <-readSentiment("amazon_cells_labelled.txt")
amazon$source <- "amazon"
imdb <-readSentiment("imdb_labelled.txt")
imdb$source <- "imdb"
yelp <-readSentiment("yelp_labelled.txt")
yelp$source <- "yelp"

allText <- rbindlist(list(amazon, imdb, yelp), use.names=TRUE)
allText$source <- as.factor(allText$source)

unlabelled <- allText[is.na(allText$sentiment), ]
labelled <- allText[!is.na(allText$sentiment), ]

Wir haben nun 3000 vorklassifizierte Sätze, die entweder ein positives oder ein negatives Sentiment ausdrücken:

text               sentiment 	source    
Length:3000        0:1500    	amazon:1000  
Class :character   1:1500    	imdb  :1000  
Mode  :character             	yelp  :1000

Textkorpus anlegen

Zuerst konvertieren wir den Datensatz in einen Korpus der R-Package tm:

library(tm)
corpus <- Corpus(DataframeSource(data.frame(labelled$text)))
# meta data an Korpus anfügen:
meta(corpus, tag = "sentiment", type="indexed") <- labelled$sentiment
meta(corpus, tag = "source", type="indexed") <- labelled$source

myTDM  <- TermDocumentMatrix(corpus, control = list(minWordLength = 1))

## verschieden Möglichkeiten, den Korpus bzw die TermDocumentMatrix zu inspizieren:
#inspect(corpus[5:10])
#meta(corpus[1:10])
#inspect(myTDM[25:30, 1])
# Indices aller Dokumente, die das Wort "good" enthalten:
idxWithGood <- unlist(lapply(corpus, function(t) {grepl("good", as.character(t))}))
# Indices aller Dokumente mit negativem Sentiment, die das Wort "good" enthalten:
negIdsWithGood <- idxWithGood &  meta(corpus, "sentiment") == '0'

Wir können uns nun einen Eindruck über die Texte verschaffen, bevor wir erste Vorverarbeitungs- und Säuberungsschritte durchführen:

  • Fünf Dokumente mit negativem Sentiment, die das Wort “good” enthalten: Not a good bargain., Not a good item.. It worked for a while then started having problems in my auto reverse tape player., Not good when wearing a hat or sunglasses., If you are looking for a good quality Motorola Headset keep looking, this isn’t it., However, BT headsets are currently not good for real time games like first-person shooters since the audio delay messes me up.
  • Liste der meist verwendeten Worte im Text: all, and, are, but, film, for, from, good, great, had, have, it’s, just, like, movie, not, one, phone, that, the, this, very, was, were, with, you
  • Anzahl der Worte, die nur einmal verwendet werden: 4820, wie z.B.: ‘film’, ‘ive, ’must’, ‘so, ’stagey’, ’titta
  • Histogramm mit Wortfrequenzen:

Plotten wir, wie oft die häufigsten Worte verwendet werden:

Vorverarbeitung

Es ist leicht zu erkennen, dass sogenannte Stoppworte wie z.B. “the”, “that” und “you” die Statistiken dominieren. Der Informationsgehalt solcher Stopp- oder Füllworte ist oft gering und daher werden sie oft vom Korpus entfernt. Allerdings sollte man dabei Vorsicht walten lassen: not ist zwar ein Stoppwort, könnte aber z.B. bei der Sentimentanalyse durchaus von Bedeutung sein.

Ein paar rudimentäre Vorverarbeitungen:

Wir konvertieren den gesamten Text zu Kleinbuchstaben und entfernen die Stoppworte unter Verwendung der mitgelieferten R-Stoppwortliste für Englisch (stopwords(“english”)). Eine weitere Standardoperation ist Stemming, das wir heute auslassen. Zusätzlich entfernen wir alle Sonderzeichen und Zahlen und behalten nur die Buchstaben a bis z:

replaceSpecialChars <- function(d) {
  ## normalerweise würde man nicht alle Sonderzeichen entfernen
  gsub("[^a-z]", " ", d)
}
# tolower ist eine built-in function
corpus <- tm_map(corpus, content_transformer(tolower)) 
# replaceSpecialChars ist eine selbst geschriebene Funktion:
corpus <- tm_map(corpus, content_transformer(replaceSpecialChars))
corpus <- tm_map(corpus, stripWhitespace)
englishStopWordsWithoutNot <- stopwords("en")[ - which(stopwords("en") %in% "not")]
corpus <- tm_map(corpus, removeWords, englishStopWordsWithoutNot)
## corpus <- tm_map(corpus, stemDocument, language="english")

myTDM.without.stop.words <- TermDocumentMatrix(corpus, 
                                      control = list(minWordLength = 1))

 

Schlagwortwolke bzw Tag Cloud

Schließlich erzeugen wir eine Tag-Cloud aller Worte, die mindestens 25 mal im Text verwendet werden. Tag-Clouds eignen sich hervorragend zur visuellen Inspektion von Texten, allerdings lassen sich daraus nur bedingt direkte Handlungsanweisungen ableiten:

wordfreq <- findFreqTerms(myTDM.without.stop.words, lowfreq=25)
termFrequency <- rowSums(as.matrix(myTDM.without.stop.words[wordfreq,])) 
# eine Alternative ist 'tagcloud'
library(wordcloud)
wordcloud(words=names(termFrequency),freq=termFrequency,min.freq=5,max.words=50,random.order=F,colors="red")

schlagwortwolke

Word-Assoziationen

Wir können uns für bestimmte Worte anzeigen lassen, wie oft sie gemeinsam mit anderen Worten im gleichen Text verwendet werden:

  • Worte, die häufig gemeinsam mit movie verwendet werden:
findAssocs(myTDM.without.stop.words, "movie", 0.13)
## $movie
##   beginning        duet fascinating        june       angel   astronaut 
##        0.17        0.15        0.15        0.15        0.14        0.14 
##         bec       coach     columbo   considers     curtain       dodge 
##        0.14        0.14        0.14        0.14        0.14        0.14 
##     edition   endearing    funniest    girolamo         hes         ive 
##        0.14        0.14        0.14        0.14        0.14        0.14 
##     latched         lid      makers     peaking     planned  restrained 
##        0.14        0.14        0.14        0.14        0.14        0.14 
##       scamp     shelves     stratus       titta        ussr      vision 
##        0.14        0.14        0.14        0.14        0.14        0.14 
##       yelps 
##        0.14
  • Worte, die häufig gemeinsam mit product verwendet werden:
findAssocs(myTDM.without.stop.words, "product", 0.12)
## $product
##        allot     avoiding        beats   cellphones       center 
##         0.13         0.13         0.13         0.13         0.13 
##      clearer   contacting       copier       dollar    equipment 
##         0.13         0.13         0.13         0.13         0.13 
##      fingers      greater      humming        ideal      learned 
##         0.13         0.13         0.13         0.13         0.13 
##       lesson        motor        murky   negatively          oem 
##         0.13         0.13         0.13         0.13         0.13 
##     official       online       owning         pens    petroleum 
##         0.13         0.13         0.13         0.13         0.13 
##     planning      related replacementr    sensitive     shipment 
##         0.13         0.13         0.13         0.13         0.13 
##        steer      voltage        waaay        whose    worthless 
##         0.13         0.13         0.13         0.13         0.13

 

Text-Mining

Wir erzeugen einen Entscheidungsbaum zur Vorhersage des Sentiments. Entscheidungsbäume sind nicht unbedingt das Werkzeug der Wahl für Text-Mining aber für einen ersten Eindruck lassen sie sich bei kleinen Datensätzen durchaus gewinnbringend einsetzen:

trainingData <- data.frame(as.matrix(myDTM))
trainingData$sentiment <- labelled$sentiment
trainingData$source <- labelled$source

formula <- sentiment ~ . 

if (rerun) {
  tree <- rpart(formula, data = trainingData)
  save(tree, file=sprintf("%s-tree.RData", prefix))
} else {
  load(file=sprintf("c:/tmp/%s-tree.RData", prefix))
}

myPredictTree(tree)

 

##          isPosSentiment
## sentiment FALSE TRUE
##         0  1393  107
##         1   780  720

Eine Fehlerrate von über 50% auf den Trainingsdaten für positive Sentiments ist natürlich nicht berauschend und daher testen wir zum Schluß noch Support Vector Machines:

library(e1071)
  if (rerun) {
    svmModel <- svm(formula, data = trainingData)
    save(svmModel, file=sprintf("%s-svm.RData", prefix))
  } else {
    load(file=sprintf("c:/tmp/%s-svm.RData", prefix))
  }

myPredictSVM <- function(model) {
  predictions <- predict(model, trainingData)

  trainPerf <- data.frame(trainingData$sentiment, predictions, trainingData$source)
  names(trainPerf) <- c("sentiment", "isPosSentiment", "source")
  
  with(trainPerf, {
    table(sentiment, isPosSentiment, deparse.level = 2)
  })
  
}
myPredictSVM(svmModel)
##          isPosSentiment
## sentiment    FALSE 	TRUE
##         0 	1456   	  44
##         1   	  23 	1477

Die Ergebnisse sehen deutlich besser aus, müssten aber natürlich noch auf unabhängigen Daten verifiziert werden, um z. B. ein Overfittung zu vermeiden.

Download-Link zum kompletten R-Code für dieses Text-Mining-Beispiel: https://www.data-science-blog.com/download/textMiningTeaser.rmd

Wie lernen Maschinen?

Im zweiten Teil wollen wir das mit Abstand am häufigsten verwendete Optimierungsverfahren – das Gradientenverfahren oder Verfahren des steilsten Abstiegs – anhand einiger Beispiele näher kennen lernen. Insbesondere werden wir sehen, dass die Suchrichtung, die bei der Benennung der Verfahren meist ausschlaggebend ist, gar nicht unbedingt die wichtigste Zutat ist.

Read more

Wie lernen Maschinen?

Machine Learning ist eines der am häufigsten verwendeten Buzzwords im Data-Science- und Big-Data-Bereich. Aber lernen Maschinen eigentlich und wenn ja, wie? In den meisten Fällen lautet die Antwort: Maschinen lernen nicht, sie optimieren. Fällt der Begriff Machine Learning oder Maschinelles Lernen, so denken viele sicherlich zuerst an bekannte “Lern”-Algorithmen wie Lineare Regression, Logistische Regression, Neuronale Netze oder Support Vector Machines. Die meisten dieser Algorithmen – wir beschränken uns hier vorerst auf den Bereich des Supervised Learning – sind aber nur Anwendungen einer anderen, grundlegenderen Theorie – der mathematischen Optimierung. Alle hier angesprochenen Algorithmen stellen dem Anwender eine bestimmte Ziel- oder Kostenfunktion zur Verfügung, aus der sich i.a. der Name der Methode ableitet und für die im Rahmen des Lernens ein Minimum oder Optimum gefunden werden soll. Ein großer Teil des Geheimnisses und die eigentliche Stärke der Machine-Learning-Algorithmen liegt nun darin, dass dieser Minimierungsprozess effizient durchgeführt werden kann. Wir wollen im Folgenden kurz erklären, wie dies in etwa funktioniert. In einem späteren Blogpost gehen wir dann genauer auf das Thema der Effizienz eingehen. Read more

Die üblichen Verdächtigen – 8 häufige Fehler in der Datenanalyse

Das eine vorab: eine Liste der meist begangenen Fehler in der Datenanalyse wird in jedem Fall immer eine subjektive Einschätzung des gefragten Experten bleiben und unterscheidet sich je nach Branche, Analyse-Schwerpunkt und Berufserfahrung des Analysten. Trotzdem finden sich einige Missverständnisse über viele Anwendungsbereiche der Datenanalyse hinweg immer wieder. Die folgende Liste gibt einen Überblick über die acht am häufigsten begangenen Fehler in der angewandten Datenanalyse von denen ich behaupte, dass sie universell sind.

  1. Statistische Signifikanz versus Relevanz

Die Idee der statistischen Signifikanz wird oft missverstanden und deswegen fälschlicherweise mit statistisch belegter Relevanz gleichgesetzt. Beide messen jedoch sehr unterschiedliche Dinge. Statistische Signifikanz ist ein Maß der Gewissheit, welches die Zufälligkeit von Variation berücksichtigt. „Statistisch signifikant“ bedeutet also, dass es unwahrscheinlich ist, dass ein bestimmtes Phänomen nur zufällig auftritt. „Statistisch nicht signifikant“ bedeutet, dass neben der zufälligen Variation keine systematische bewiesen werden konnte. Wichtig: dies bedeutet nicht, dass es keine Effekte gibt, sondern, dass diese nicht belegt werden konnten. Statistische Signifikanz lässt sich mit ausreichend vielen Beobachtungen allerdings auch für sehr kleine Unterschiede belegen. Generell gilt: je größer die Stichprobe, desto kleiner werden die Unterschiede, welche als statistisch signifikant getestet werden. Deswegen unterscheidet sich die statistische Relevanz von der statistischen Signifikanz.

Statistische Relevanz misst hingegen die Effektstärke eines Unterschiedes. Die Größe eines Unterschiedes wird dazu in Relation zur Streuung der Daten gesetzt und ist damit unabhängig von der Stichprobengröße. Je größer die Varianz der Zufallsvariablen, desto kleiner wird die Effektstärke.

  1. Korrelation versus Kausalität

Wird eine hohe Korrelation zwischen zwei Größen festgestellt, so wird oft geschlussfolgert, dass eine der beiden Größen die andere bestimmt. In Wahrheit können auch komplexe statistische und ökonometrische Modelle keine Kausalität beweisen. Dies gilt sogar, wenn die Modellierung einer theoretischen Grundlage folgt, denn auch die kann falsch sein. Regelmäßig lehnen sich Forscher und Analysten aus dem Fenster, indem sie Wirkungen behaupten, welche eine genaue Prüfung nicht aushalten. Standardfragen, die als Automatismus einer jeden Analyse folgen sollte, welche behauptet Effekte gefunden zu haben sind: Welche Rolle spielen unbeobachtete Heterogenitäten, umgekehrte Kausalität und Messfehler in den Variablen für das Schätzergebnis? Erst wenn diese drei Quellen von Endogenität kontrolliert werden und außerdem davon ausgegangen werden kann, dass die Stichprobe die Grundgesamtheit repräsentiert, kann ein kausaler Zusammenhang angenommen und quantifiziert werden.

  1. Unbeobachtete Einflussfaktoren

Nicht messbare und deswegen nicht erhobene Einflüsse verzerren die geschätzten Parameter der kontrollierbaren Faktoren, sofern letztere mit den unbeobachteten im Zusammenhang stehen. In anderen Worten: der geschätzte Effekt wird fälschlicherweise der beobachteten Größe zugeschrieben, wenn eigentlich eine dritte, nicht beobachtete Größe die Zielgröße bedingt und gleichzeitig mit der beobachteten Größe korreliert. Das Lehrbeispiel
für Verzerrungen durch unbeobachtete Größen ist die Lohngleichung – eine Gleichung die seit nunmehr 60 Jahren intensiv beforscht wird. Die Schwierigkeit bei der Quantifizierung des Effektes von Ausbildung liegt darin, dass die Entlohnung nicht nur über Alter, Berufserfahrung, Ausbildung und den anderen Kontrollvariablen variiert, sondern auch durch das unterschiedlich ausgeprägte Interesse an einem lukrativen Erwerb und die Fähigkeit des Einzelnen, diesen zu erlangen. Die Herausforderung: es gibt keinen statistischen Test, welche eine Fehlspezifikation durch unbeobachtete Größen angibt. Unabdingbar ist deswegen ein tiefgehendes Verständnis des Analyseproblems. Dieses befähigt den Analysten Hypothesen zu formulieren, welche unbeobachteten Größen über eine Korrelation mit dem getesteten Regressor im Fehlerterm ihr Unwesen treiben. Um Evidenz für die Hypothesen zu schaffen, müssen smarte Schätzdesigns oder ausreichend gute Instrumente identifiziert werden.statistische-verzerrung

  1. Selektionsverzerrung

Eine Selektionsverzerrung liegt vor, wenn Beobachtungen nicht für jedes Individuum vorliegen oder von der Analyse ausgeschlossen werden. Die Grundvoraussetzung für jeden statistischen Hypothesentest ist die Annahme einer Zufallsstichprobe, so dass die Zielpopulation repräsentativ abgebildet ist. In der Praxis ergeben sich allerdings oft Situationen, in denen bestimmte Merkmale nur für eine Gruppe, aber nicht für eine zweite beobachtet werden können. Beispielsweise kann der Effekt einer gesundheitsfördernden Maßnahme eines Großbetriebes für die gesamte Belegschaft nicht durch die freiwillige Teilnahme einiger Mitarbeiter gemessen werden. Es muss explizit dafür kontrolliert werden, welche Unterschiede zwischen Mitarbeitern bestehen, welche das Angebot freiwillig in Anspruch nehmen im Vergleich zu denen, die es nicht annehmen. Eine Gefahr der Über- oder Unterschätzung der Effekte besteht generell immer dann, wenn über die Beschaffenheit der Stichprobe im Vergleich zur Grundgesamtheit nicht nachgedacht wird. Auf Basis einer nicht repräsentativen Stichprobe werden dann fälschlicherweise Generalisierungen formuliert werden, welche zu falschen Handlungsempfehlungen führen können.

  1. Überanpassung und hohe Schätzervarianz

Überanpassung passiert, wenn der Analyst „zu viel“ von den Daten will. Wird das Model überstrapaziert, so erklären die Kontrollvariablen nicht nur die Zielgröße sondern auch das weiße Rauschen, also die Zufallsfehler. Die Anzahl der Regressoren im Verhältnis zur Anzahl der Beobachtungen ist in solch einer Spezifikation übertrieben. Das Problem: zu wenig Freiheitsgrade und das vermehrte Auftreten von Multikollinearität führen zu einer hohen Varianz in der Verteilung der Schätzer. Ein Schätzergebnis einer Spezifikation mit einer hohen Schätzervarianz kann also Schätzergebnisse produzieren, welche vom wahren Wert weiter entfernt sind als ein verzerrter Schätzer. Tatsächlich ist ein „falsches“ meistens ein Hinweis auf Multikollinearität.verlorene-effizienz-statistisches-modell

Oft macht es Sinn, die Spezifikation anzupassen, indem man die korrelierten Regressoren ins Verhältnis zueinander zu setzt. In der Praxis geht es immer darum, einen Kompromiss aus Verzerrung und Varianz zu finden. Das Kriterium hierfür ist die Minimierung des mittleren quadratischen Fehlers. Um zu überprüfen, ob der Analyst über das Ziel hinausgeschossen ist, gibt es zudem verschiedene Validierungsmethoden, welche je nach Methode einen bestimmten Anteil oder sogar keine Daten „verschwenden“, um das Modell zu überprüfen.kompromiss-quadratischer-fehler-statistisches-modell

  1. Fehlende Datenpunkte

Beobachtungen mit fehlenden Datenpunkten werden in der Praxis aus der Analyse in den meisten Fällen ausgeschlossen, einfach deswegen, weil das am schnellsten geht. Bevor das gemacht wird, sollte allerdings immer die Frage vorangestellt werden, wieso diese Datenpunkte fehlen. Fehlen sie zufällig, so führt der Ausschluss der Beobachtungen zu keinen unterschiedlichen Ergebnissen. Fehlen sie allerdings systematisch, beispielsweise wenn Personen mit bestimmten Merkmalen spezifische Daten lieber zurückhalten, so ergeben sich daraus Herausforderungen. Es sollte dann darum gehen, diese gesamte Verteilung zu ermitteln. Ist unklar, ob die Daten zufällig oder systematisch fehlen, so sollte sich der Analyst im Zweifel dieser Frage annehmen. Es müssen dann Informationen identifiziert werden, welche helfen die fehlenden Daten zu imputieren.

  1. Ausreißer

Ausreißer werden in vielen Anwendungen mit standardisierten Verfahren identifiziert und aus dem Datensatz entfernt. Dabei lohnt es sich in vielen Fällen, die Daten ernst zu nehmen. Die Voraussetzung hierfür: die Datenpunkte müssen legitim sein. Problemlos ausschließen lassen sich Datenpunkte, welche durch Eingabefehler und bewusste Falschmeldung erzeugt wurden. Legitime Datenpunkte sind hingegen “echte” Werte. Die Einbeziehung von Ausreißern kann mitunter einen inhaltlichen Beitrag zur Analyse leisten, da auch sie einen Teil der Population im Ganzen sind. Problematisch wird die Beibehaltung von Ausreißern, wenn durch sie Zusammenhänge identifizierbar werden, die auf den Rest der Population nicht zutreffen. Mögliche Verfahren, welche Ausreißer mit dem Rest der Beobachtungen versöhnen, sind Transformationen der Daten oder die Anwendung robuster Schätzverfahren. Beide Ansätze spielen mit einer stärkeren Gewichtung der mittleren Verteilung. Außerdem kann beispielsweise in Regressionen überprüft werden, inwieweit etwa ein nicht-linearer Fit die Ausreißer besser in die Schätzung aufnimmt.

  1. Spezifizierung versus Modellierung

Allzu oft werden komplizierte statistische Modelle gebaut, bevor überprüft wurde, was ein einfaches Modell leisten kann. Bevor jedoch komplexe Modelle gestrickt werden, sollte zuerst an der Spezifikation des Modells gearbeitet werden. Kleine Anpassungen wie die Inklusion verbesserter Variablen, die Berücksichtigung von Interaktionen und nicht-linearen Effekten bringen uns in manchen Fällen der Wahrheit näher als ein aufwendiges Modell und sollten in jedem Fall ausgereizt werden, bevor ein aufwendigeres Modell gewählt wird. Je einfacher das Modell, desto einfacher ist es in der Regel auch die Kontrolle darüber zu behalten. In jedem Fall sollten die gewählten Spezifikationen immer durch Sensitivitätsanalysen unterstützt werden. Unterschiede in der Variablendefinition und der Selektion der Daten, sollten sowohl getestet als auch berichtet werden. Einen guten Grund, das Modell zu wechseln hat der Analyst dann, wenn daraus ersichtlich wird, dass Annahmen des einfachen Modells verletzt werden und dieses deswegen keine validen Ergebnisse produziert.

Tag Archive for: Data Science

Nothing Found

Sorry, no posts matched your criteria