KNN: Natur als Vorbild – Biologische Neuronen

Bisher ist die genaue Funktionsweise des Gehirns bei der Verarbeitung sensorischer Informationen nicht bekannt. Neue Erkenntnisse im Bereich der Neurowissenschaften liefern jedoch einen Einblick über grundlegende Prinzipien wie das Gehirn von Säugetieren sensorische Informationen repräsentiert. Einer der wichtigsten Punkte ist dabei die Erkenntnis, dass der Neocortex, einem ankommenden Signal erlaubt ein komplexes Netzwerk von Neuronen zu durchlaufen, wodurch es zu einer abstrakten Repräsentation des ursprünglichen Eingabesignals kommt. Auch ist das Gehirn in der Lage die Leitfähigkeit der Verbindungen zwischen den Neuronen zu modifizieren, was sich auf eine Änderung der Abbildungsvorschrift auswirkt. Beobachtungen können dadurch noch besser getrennt und effizienter repräsentiert werden. Die Entdeckung dieses Verhaltens motivierte die Entstehung des Forschungszweiges Deep Machine Learning, welcher sich darauf fokussiert Modelle zu entwickeln, die ähnliche Charakteristiken wie der Neocortex aufweisen.

Das Eingabesignal durchläuft das Netzwerk bis zu einer Ausgabeschicht. Das Resultat dieser nicht linearen Transformation lässt sich dann beispielsweise mit einem Klassifizierungsalgorithmus auswerten. Die praktischen Anwendungen solcher Algorithmen sind sehr vielfältig. Deep Machine Learning Algorithmen liefern zurzeit die besten Ergebnisse zu vielen Problemen in Anwendungsdomänen wie Bilderkennung, Spracherkennung und der Verarbeitung natürlicher Sprache. Mit Hilfe dieser Algorithmen wurden beispielsweise neue elementare Teilchen gefunden, entdeckte Galaxien noch besser klassifiziert und Auswirkungen von Mutationen innerhalb von DNA vorhergesagt.

Das Neuron

Das Neuron ist die Basis-Recheneinheit des Gehirns. Ungefähr 86 Milliarden solcher Neuronen befinden sich im menschlichen Nervensystem, welche durch ca. 10^15 Synapsen miteinander vermascht sind. In Abbildung unten links wird eine Schemazeichnung eines biologischen Neurons dargestellt. Dieses besteht unter Anderem aus Dendriten, dem Zellkörper, der den Zellkern beinhaltet und einem Axon. Die Dendriten gehen aus dem Zellkörper hervor und sind über Synapsen mit sensorischen Zellen oder Axonen anderer Neuronen verbunden. Ihre Aufgabe ist die Aufnahme von ankommenden Signalen in Form von elektrischen Spannungsänderungen und der Transport dieser in den Zellkörper des Neurons, der Recheneinheit einer Nervenzelle. Dort angekommen entscheiden bestimmte Faktoren, ob ein Aktionspotential anhand einer Schwellwertfunktion ausgelöst wird oder nicht. Ist dies der Fall leitet das Neuron elektrische Energie über sein Axon an weitere angeschlossene Dendriten anderer Neuronen weiter.

Neuronen
Das biologische Neuron diente als Inspiration für das Software-Neuron. Beim mathematischen Modell eines Software-Neurons (Künstliches Neuron eines KNN) wird davon ausgegangen, dass die verschiedenen Dendriten unterschiedlich stark ausgeprägt sind und ein Signal daher auch verschieden stark gewichtet in den Zellkörper übertragen wird. Jedes Dendrit enthält demnach einen Faktor(θi), der das Signal(xi) vor dem Eintreffen in den Zellkörper skaliert (θixi). Diese Faktoren werden auch als Gewichte bezeichnet. Im Zellkörper selbst werden die Signale die von unterschiedlichen Neuronen stammen aufsummiert bis schließlich ein fester Bias-Wert(b) auf das Ergebnis der Summation aufaddiert wird. Anschließend bestimmt eine nicht-lineare Aktivierungsfunktion über den finalen Ausgangswert des Neurons.

Bildquelle: Wikipedia

Ähnliche Artikel:

KNN: Künstliche Neuronen

Es gibt sehr ausführliche Definitionen und Abbildungen für ein künstliches Neuron, die in diesem Artikel aber nicht behandelt werden. Der Grund dafür ist pragmatischer Natur. Es soll eine gewisse Konsistenz zu den anderen KNN-Beiträgen dieser Reihe bestehen und das Thema soll nicht zu einer wissenschaftlichen Abhandlung mutieren.

In dem Beitrag  KNN: Was sind künstliche neuronale Netze  geht es um den grundsätzlichen Aufbau von künstlichen neuronalen Netzwerken. Zusammengesetzt werden die Strukturen aus einer oftmals großen Anzahl von künstlichen Neuronen. Die nachfolgende Abbildung zeigt auf der Linken Seite einen extrahierten Ausschnitt aus einem Netzwerk. Es kann auch als einfaches allein stehendes Netzwerk betrachtet werden. Auf der rechten Seite ist eine allgemeingültigere Form zu sehen. Die Bias Unit (VB) wird üblicherweise als X0 bezeichnet und hat immer den Wert 1.

 

neuronen-netzwerk1 neuronen-netzwerk2

 


Um den Ausgangswert Y zu berechnen wird zunächst jeder Eingangswert X mit seinem dazugehörigen Gewicht \theta (Theta) multipliziert und die Ergebnisse aufsummiert. Das Zwischenergebnis ist die Aktivierungsstärke z:

    \[ z = X_0 \cdot \theta_0 + X_1 \cdot \theta_1 + X_2 \cdot \theta_2 \]

Im nächsten Schritt wird der eigentliche Ausgangswert Y errechnet, indem die Aktivierungsstärke z an eine Aktivierungsfunktion angelegt wird. Es gibt zwar verschiedene Funktionen, häufig wird aber die Logistische bzw. Sigmoid-Funktion verwendet. Sie ist nicht-linear und hat einen Ausgangswertebereich zwischen 0 und 1.

sigmoid-funktion

    \[ sigmoid(z) = \frac{1}{1+e^{-z}} \]

Wird das Bias Neuron und sein Gewicht nicht beachtet, bestimmen die eingehenden Daten die Aktivierungsstärke und damit den Ausgang der Funktion. Unter Verwendung der Bias Unit verschiebt sich die Funktion entlang der Y-Achse, was einer Verschiebung von einem Schwellwert gleich kommt.

Die endgültige Formel für die Aktivierung eines Neurons sieht sehr ähnlich zu der Logistischen Regression aus. Werden die Werte von X und Theta zu Vektoren zusammengefasst, lässt sich die Berechnung stark vereinfachen:

    \[ Y = sigmoid(X\theta) \]

Als Programmcode müsste diese Berechnung dennoch mit einer Schleife realisiert werden oder noch besser mit einer Bibliothek für lineare Algebra.

Ähnliche Artikel:
KNN: Was sind künstliche neuronale Netze
KNN: Vorteile und Nachteile

Interview – Big Data Analytics in der Versicherungsbranche

big-data-in-versicherungsbranche-interview
norbert-schattner

Welche Rolle spielt Big Data in der Versicherungsbranche? Ist Data Science bereits Alltag in einer Versicherung? Wenn ja, welche Analysen werden bereits durchgeführt?
Hierzu haben wir den Datenarchitekt Norbert Schattner befragt und sehr interessante Antworten erhalten:

Norbert Schattner ist Informations- & Datenarchitekt bei der Helsana AG in der Schweiz. Die Helsana AG ist ein Versicherungskonzern mit Schwerpunkt auf Kranken- und Unfallversicherung. Der Konzern beschäftigt rund 3.500 Mitarbeiter und macht 5,5 Milliarden Franken Umsatz.

Data Science Blog: Herr Schattner, welcher Weg hat Sie in die Datenarchitektur und in das Data Warehouses bei Helsana geführt?

Schattner: Ich habe in meiner Berufslaufbahn kontinuierlich im Umfeld Business Intelligence und Data Warehousing gearbeitet und konnte mich zum Experten für unternehmensübergreifende Architektur von Daten- und Informationsflüssen weiter entwickeln.

Nachdem ich eine Zeit lang als Senior Consultant für eine Unternehmensberatung tätig war, bin ich zur UBS Bank nach Zürich gegangen und war für das Rollout Management im Data Warehouse Kontext tätig. Schlussendlich wechselte ich dann zur Helsana Versicherungsgruppe, denn dort konnte ich in ein Projekt einsteigen, bei dem ich die Datenarchitektur von Grund auf neu aufbauen durfte. Durch dieses Projekte hatte ich die Gelegenheit eine nachhaltige Datenarchitektur von Grund auf aufzubauen und in weiteren Grossprojekten mitwirken.

Data Science Blog: Die Medien überschlagen sich in letzter Zeit geradezu beim Thema Big Data, 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 Versicherungsbranche aus?

Schattner: Big Data ist sicherlich ein großes Schlagwort der IT geworden. In der Versicherungsbranche ist Big Data ein großes und sehr aktuelles Thema. Auch die Helsana spricht von Big Data und versteht darunter große und verteilte Mengen an strukturierten und unstrukturierten Daten.

Zum gegenwärtigen Zeitpunkt sind die wichtigsten und größten Datenbestände der Helsana in strukturierter Form vorliegend. Strukturierte Geschäftsdaten sind für uns der wichtigste Anteil vom Big Data Kuchen. Oftmals gehen in der Diskussion von Big Data die strukturierten Daten unter, obwohl auch diese eine enorme Menge und Vielfalt darstellen und somit zur Herausforderung werden können – ganz egal, was aktuelle Technologieanbieter hier versprechen mögen.

In der nahen Zukunft werden auch Social Media Daten wichtig, beispielsweise um die Kundenzufriedenheit besser zu erfassen. Erste Ansätze verfolgen wir zwar schon, dennoch muss ehrlicherweise gesagt werden, dass die Projekte noch in den Kinderschuhen stecken.

Data Science Blog: Welche Rolle spielt Data Science in der Versicherungsbranche?

Schattner: Data Science spielt eine große Rolle, auch wenn wir in unserer Versicherung das Wort Data Science nicht aktiv verwenden, denn auch unsere Analysen von unstrukturierten Daten und mit statistischen Modellen laufen bei uns unter dem Begriff Business Intelligence.
Daten sind der einzige „Rohstoff“, den Versicherungen haben und da wir uns mit den Themen Gesundheit und Unfällen beschäftigen, spielen wir auch für die Forschung eine wichtige Rolle. Einige Kennzahlen sind teilweise von öffentlichem Interesse, wie etwa der Krankenstand, und bei der Ermittlung gibt es aus Sicht der Datenerhebung und statistischen Auswertung sehr viele Aspekte zu berücksichtigen.

Data Science Blog: Arbeiten Data Scientist eher in eigenen abgekapselten Abteilungen oder in der IT-Abteilung oder in den Fachbereichen?

Schattner: Wir haben keine zentrale Data Science Abteilung, sondern trennen zwei Bereiche:

Das Data Warehouse ist in der IT angesiedelt und hat die Aufgabe, alle erfassten und erfassbaren Daten zu sammeln und den Fachbereichen zur Verfügung zu stellen. In der Regel werden vom Data Warehouse strukturierte Daten bereit gestellt, vermehrt werden jedoch auch unstrukturierte Daten, beispielsweise aus eingescannten Dokumenten, von den Fachbereichen angefordert.

Die gezielten Analysen finden dann weitgehend unabhängig voneinander in den einzelnen Fachbereichen statt, wobei einige Fachbereiche natürlich eigene Analyse-Teams aufgebaut haben.

Data Science Blog: Welche Tools werden für die Datenauswertung bei der Helsana überwiegend eingesetzt?

Schattner: Wir arbeiten überwiegend mit den Business Intelligence Lösungen IBM Cognos Suite, QilikTech QlikView und für statistische Analysen setzen wir vor allem auf SAS Analytics und zunehmend auch auf die Open Source Statistiksprache R ein.

Data Science Blog: Welche technischen Herausforderungen haben Sie ganz besonders im Blick in Sachen Big Data Analytics? Und auf welche Strategien zur Bewältigung setzen Sie?

Schattner: Es gibt nicht einige wenige besonders große Herausforderungen, sondern sehr viele kleinere über den gesamten Workflow hinweg. Big Data Analytics beginnt mit der Datenerhebung und ETL-Prozessen, umfasst weiter die Datenaufbereitung, statistische und visuelle Analyse und geht noch weiter bis hin zum Reporting mit Handlungsempfehlungen.

Zurzeit arbeiten wir sehr daran, den Umfang an Datenbeständen zu erweitern, Daten zu konsolidieren und die Datenqualität zu verbessern, denn die besten Analyseverfahren nützen wenig, wenn die Datenquellen nicht gut sind. Basierend auf den Datenquellen entwickeln wir für uns wichtige Informationsprodukte, mit denen wir unsere Leistungs- und Servicequalität erhöhen können, daher lohnt sich jede Investition in das Data Warehouse.

Wir verfolgen derzeit zwei Strategien parallel:

Auf dem Fast-Track stellen wir unternehmenskritische und für die dringende Einführung wichtige Informationen schnell zur Verfügung stellen. Dies läuft über einen agilen Ansatz, so dass wir hier schnell reagieren können und flexibel bleiben.

Dann verfolgen wir parallel dazu einen langfristigen Weg, gesicherte Datenflüsse nachhaltig aufzubauen, die viel besser administrierbar und erweiterbar sind.

Data Science Blog: Gerade in der Versicherungsbranche ist sicherlich der Datenschutz ein besonders wichtiges Thema, was können Sie dazu sagen?

Schattner: Die Informationen aus dem Data Warehouse unterliegen vielen Schutzauflagen, da unser Geschäft reich an Personen- und Diagnosedaten ist. Datenschutz und auch Datensicherheit haben höchste Priorität. Wir haben dabei auch Schutzmaßnahmen eingeführt, dass sich Mitarbeiter aus den Systemen heraus nicht über Diagnosen anderer Mitarbeiter informieren können.

Data Science Blog: Was für Analysen betreiben die Fachbereiche beispielsweise? Werden auch bereits unstrukturierte Daten systematisch analysiert?

Schattner: Wir unterstützen mit unseren statistischen Analysen die Forschung. Ein Beispiel aus der Gesundheitsökonomie ist die Ritalin-Forschung. Ritalin ist ein Medikament, das gegen die Aufmerksamkeitsstörung ADHS eingesetzt wird und die Konzentration betroffener Patienten steigert. Wir können basierend auf unseren Daten streng anonymisierte Analysen betreiben,  ob in bestimmten Regionen mit ansonsten vergleichbaren Gesundheitsstrukturen unterschiedliche Häufigkeiten und Dosen auftreten. Finden wir sogenannte Hotspots, können kausale Zusammenhänge gesucht werden. Ursachen könnten beispielsweise Hypes unter lokalen Ärztegruppen sein oder schwierige soziale Verhältnisse unter Familienverbänden.

Ferner vergleichen wir Leistungserbringer und analysieren unterschiedliche Kostenverhältnisse unter Ärztestrukturen und Krankenhäusern.

Auch unstrukturierte Daten fließen in Form von Texten in manche unserer Analysen ein. Alle Dokumente zu Schadensfällen werden von unserer hausinternen Post eingescannt. Die Textinformationen aus den Schadensmeldungen speist unser Data Warehouse in BLOBs relationaler Datenbanken, auf die dann wieder der Fachbereich parsend zugreift.

Darüber hinaus stehen für uns Daten über unsere Leistungen und die Kundenzufriedenheit im Vordergrund, denn dadurch können wir uns als Unternehmen kontinuierlich verbessern.

Data Science Blog: Data Scientist gilt als Sexiest Job of the 21st Century. Welchen Rat würden Sie jungen Leuten geben, die Data Scientist bzw. Business Analyst werden möchten? Welche Kenntnisse setzen Sie voraus?

Schattner: Stellen wir uns einen Schieberegler vor, den wir nur in die eine oder andere verschieben könnten, sich dabei ganz links das Wissen über das Business stehen würde und ganz rechts sich das IT-Wissen befindet. Ich würde den Regler auf 80% auf die Business-Seite schieben. Es sollte natürlich auch  Wissen über SQL, ETL und Programmierung vorhanden sein, aber alleinige IT- bzw. Tool-Experten helfen uns leider wenig. In der Versicherungsbranche ist vor allem ein Wissen über das Geschäft von Bedeutung. Heutzutage ermöglichen interaktive Tools recht einfach die Erstellung von Datenbankabfragen sowie eine multidimensionale und visuelle Datenanalyse.

Das verdeutlichen auch die zwei Architekturen: Zum einen haben wir die Datenarchitektur, die die Datenflüsse von den Datenquellen ausgehend beschreibt, und zum anderen haben wir eine Informationsarchitektur, die die Daten über Geschäftslogiken in Business Objects fasst, so werden aus Daten Informationen.

Folgende Metapher verwende ich hierzu auch gerne in meinen Vorträgen: Ein Tischler beherrscht sein Handwerk Möbel zu bauen, ein CNC-Fräser fertigt Maschinenwerkzeug.

Der Tischler merkt schnell, dass er mit einer elektrischen Säge schneller und genauer vorankommt, als mit einer Handsäge. Der Drehmaschinenarbeiter verfügt zwar über perfekt arbeitende und computergesteuerte Gerätschaften, ist jedoch nicht in der Lage,  gute Holzmöbel zu bauen, weil er es niemals gelernt hat.

Genauso muss der Business Experte zwar erstmal lernen, bestimmte Tools zu bedienen, aber dafür hat er stets ein genaues Ziel im Kopf, was er damit erreichen will. Die Bedienbarkeit der Tools am Markt lässt sich heute leichter erlernen als früher.

Gute Data Scientists schauen, welche Nutzen aus Daten erzeugt werden könnten und welche Daten zur Verfügung stehen oder erfasst werden können, um bestimmte Resultate erzielen zu können.

Branchenwissen allein reicht jedoch auch nicht unbedingt aus, beispielsweise ist es beim Customer Analytics wichtig, branchenspezifische Vertriebsstrategien im Kopf zu haben und auch aus der Praxis zu kennen, denn nur so lassen sich die Informationen in praxisnahe Strategien umwandeln.

Data Science Blog: Wird die Nachfrage nach Data Science weiter steigen oder ist der Trend bald vorbei?

Schattner: Ich denke, dass dieser Hype noch nicht ganz erreicht ist. Irgendwann wird er aber erreicht sein und dann schlägt die Realität zu. Beispielsweise wird gerade viel über Predictive Analytics gesprochen, dabei betreiben einige Fachbereiche bereits seit mindestens einem Jahrhundert Vorhersagen. Im Controlling, aus dem ich komme, waren bereits recht komplexe Prognosen in Excel üblich, nur hätten wir das nicht Predictive Analytics oder Data Science genannt. Natürlich werden die Prognosen nun dank leistungsfähigerer Technologien immer besser und genauer, nur ist es nichts substanziell Neues. Der Trend verstärkt aber die Bemühungen im Bereich Business Intelligence und lockert auch Budgets für neue Analyseverfahren.


 

Die Redaktion sucht Interview-Partner aus Wirtschaft und Wissenschaft!

Sie sind Professor einer Hochschule, CEO, CIO oder Chief Data Scientist? Dann laden wir Sie herzlichst dazu ein, mit uns in Kontakt zu treten. Als erster deutscher Data Science Blog möchten wir die Bedeutung von Big Data und Data Science für die mitteleuropäische Wirtschaft an die Gesellschaft herantragen. Wenn Sie etwas zum Thema zu sagen haben, dann schreiben Sie uns eine Mail an redaktion@data-science-blog.com.

Kontrolle und Steuerung von Spark Applikationen über REST

Apache Spark erfreut sich zunehmender Beliebtheit in der Data Science Szene da es in Geschwindigkeit und Funktionalität eine immense Verbesserung bzw. Erweiterung des reinen Hadoop MapReduce Programmiermodells ist. Jedoch bleibt Spark ebenso wie Hadoop eine Technologie für Experten. Es erfordert zumindest Kenntnisse von Unix-Skripten und muss über die Command-Line gesteuert werden. Die vorhandenen Weboberflächen bieten nur sehr rudimentäre Einblicke in den Status von Spark Applikationen:

spark basic ui

Der Spark JobServer ist ein Open-Source Projekt, das eine REST-Schnittstelle (Representational State Transfer) für Spark anbietet. (In diesem YouTube Video wird anschaulich erläutert, was ein REST API ist und wozu es verwendet werden kann.) Vereinfacht gesagt, ermöglicht es der JobServer, Spark über diese REST-Schnittstelle als Webservice zu nutzen. Es ist möglich, über den JobServer Spark Kontexte und Applikationen (Jobs) zu managen und Kontexte über verschiedene Aufrufe der REST-Schnittstelle hinweg wiederzuverwenden. Jar Files mit Job Implementierungen können vorab über die gleiche Schnittstelle installiert werden, so dass es z.B. möglich ist, auch sehr feingranulare Jobs über die Schnittstelle zu steuern (vollständige Liste der Features).

Der Spark JobServer ist bereits bei verschiedenen Organisationen (u.a. Netflix, Zed Worldwide, KNIME, Azavea und Maana) im Einsatz. Diese Nutzer des JobServers verwenden ihn meist versteckt „unter der Haube“, um so ihre jeweiligen Werkzeuge Big-Data tauglich zu machen. So nutzt KNIME ab dem nächsten Release (Oktober 2015) den JobServer. Anwendern können dann Spark Jobs über eine grafische Oberfläche bequem von ihrem lokalen Rechner aus starten, monitoren und stoppen. In der folgenden Abbildung sehen Sie, wie Trainingsdaten auf den Server hochgeladen werden, um daraus verschiedene Machine Learning Modelle zu erstellen. Diese Modelle können dann auf Testdaten angewandt werden, die z.B. aus einer HIVE-Tabelle nach Spark importiert werden:

spark knime hive jobs

Jeder der dargestellten Knoten mit der Überschrift „Spark ***“, wie z.B. „Spark Decision Tree“, ist ein Spark Job im Sinne des JobServers. Weitere Beispiele für Spark Jobs sind verschiedene Vorverarbeitungsaufgaben wie das Sampling einer Tabelle oder ein Join über mehrere Tabellen.

Spark kann über den JobServer im Standalone-, Mesos- oder im Yarn-Client-Modus angesteuert werden. Eine sehr hilfreiche Erweiterung der eigentlichen Spark-Funktionalität bietet der JobServer über die sogenannten „Named RDDs“ an. Ein Resilient Distributed Dataset (RDD) ist im Prinzip ein Datensatz bzw. eine Tabelle in Spark. „Named RDDs“ erlauben die Weiterverwendung von RDDs über einzelne Jobs hinweg. So kann man Jobs modularer aufbauen und leichter Zwischenergebnisse inspizieren.

Ich kann aus eigener Erfahrung sagen, dass der JobServer die geeignete Middleware zwischen einer benutzerfreundlichen Oberfläche und Spark ist. Die Open-Source Community ist hier sehr aktiv und der JobServer lässt sich bei Bedarf gut erweitern.

KNN: Vorteile und Nacheile

Wie jedes Verfahren haben auch künstliche Neuronale Netzwerke (KNN) ihre Vor- und Nachteile. Im Folgenden sollen einige benannt werden.

Vorteile

  • KNN können bessere Ergebnisse liefern als existierende statistische Ansätze, wenn das Problem ausreichend komplex ist. Das heißt, wenn das Problem nicht linear ist und es viele Eingabedaten mit vielen Variablen gibt.
  • Es gibt zwar sogenannte Hyperparameter, die je nach Einstellung das Netzwerk besser oder schlechter trainieren lassen, diese müssen aber nur manuell geändert werden, wenn neue Rekordwerte erreicht werden sollen. Ansonsten gibt es verhältnismäßig wenige Parameter.
  • Auch für stark nicht lineare Probleme, werden gute Lösungen gefunden. Dazu zählen fast alle Probleme die aus einer Datenbasis stammen, wo menschliche oder andere unvorhersehbare Einflüsse wirken.
  • Für große Datenmengen und viele Datendimensionen (Einflussfaktoren) können sinnvolle Ergebnisse ermittelt werden.

Nachteile

  • Künstliche Neuronale Netzwerke sind oftmals wie eine Blackbox. Dadurch ist es nicht möglich nachzuverfolgen wieso ein Netzwerk eine bestimmte Entscheidung getroffen hat.
  • Damit ein allgemeingültiges gutes Ergebnis berechnet werden kann, bedarf es vieler Beispiel-/Trainingsdaten.
  • Aufgrund der hohen Datenmenge, ist es sinnvoll die Berechnungen auf einer Grafikkarte durchzuführen.
  • Während des Trainings finden sehr viele Gewichtsänderungen in kurzer Zeit statt. Daher ist ein Aufteilen der Arbeit in ein verteiltes System wie Apache Hadoop oder Apache Spark nur schwer möglich und führt oftmals zu drastischen Performanz Einbußen.
  • Ist das Problem mathematisch beschreibbar sind KNNs oftmals schlechter oder maximal genauso gut.
  • Es ist zu keinen Zeitpunkt bekannt ob die gefundene Lösung das globale Optimum ist oder ob es noch bessere Lösungen gibt.

In der Forschung gibt es viele Ansätze um einige der Nachteile aufzuheben.

 

Komplexe Abläufe verständlich dargestellt mit Process Mining

Stellen Sie sich vor, dass Ihr Data Science Team dabei helfen soll, die Ursache für eine wachsende Anzahl von Beschwerden im Kundenservice-Prozess zu finden. Sie vertiefen sich in die Daten des Service-Portals und generieren eine Reihe von Charts und Statistiken zur Verteilung der Beschwerden auf die verschiedenen Fachbereiche und Produktgruppen. Aber um das Problem zu lösen, müssen die Schwachstellen im Prozess selbst offengelegt und mit dem Fachbereich kommuniziert werden.

Nach Einbeziehen der CRM-Daten sind Sie mit Process Mining schnell in der Lage etliche unerwünschte Schleifen und Verzögerungen im Prozess zu identifizieren. Und diese Abweichungen werden sogar vollautomatisch als graphische Prozesskarte abgebildet! Der Fachbereichsleiter sieht auf den ersten Blick, wo das Problem liegt, und kann umgehend Verbesserungsmassnahmen einleiten.

Genau hier sehen wir eine zunehmende Begeisterung für Process Mining über alle Branchen hinweg: Der Datenanalyst kann nicht nur schnell Antworten liefern sondern auch die Sprache des Prozessmanagers sprechen und die entdeckten Prozessprobleme eindrücklich visuell machen.

Data Scientists bewegen sich geschickt durch eine ganze Reihe von Technologien. Sie wissen, dass 80% der Arbeit in der Aufbereitung und dem Säubern der Daten besteht. Sie können mit SQL, NoSQL, ETL-Tools, Statistik, Skriptsprachen wie Python, Data-Mining-Werkzeugen und R umgehen. Aber für viele von ihnen ist Process Mining noch nicht Teil der Data-Science-Tool-Box. Read more

Auswertung von CSV- und Log-Dateien auf der Command Line mit awk

Die Programmiersprache awk ist klein und unscheinbar, unter Data Science at the Command Line-Verfechtern allerdings ein häufiges Tool zur schnellen Analyse von CSV-Datein und vergleichbar strukturierten Daten (z. B. Logfiles) mit über Trennzeichen differenzierten Spalten. Auch in Shell-Skripten kommt awk meistens dann zum Einsatz, wenn es um den Zugriff, aber auch um die Manipulation von solchen Dateien geht.

Data Science at the Command Line: Facing the Future with Time-Tested Tools

awk wird als Skriptsprache mit nahezu jeder Linux-Distribution ausgeliefert und ist recht einfach eingehalten, kann jedoch auch schnell kryptisch werden. awk wird meistens ad-hoc auf der Kommandozeile ausgeführt, es können jedoch auch Skripte in awk-Dateien erstellt werden. Häufiger Grund für den Einsatz von awk ist die Anwendung von regulären Ausdrücken (Textmustersuche) auf Logdateien.

Nachfolgend ein kleines Tutorial für den Schnelleinstieg in diese interessante Analysetool auf Kommandozeile. Die CSV-Datei einfach hier downloaden: (einen Überblick über den Inhalt bietet auch eine Einführung in Python, die ebenfalls auf dieser CSV-Datei basiert)

CSV-Datei gedownloaded? Dann kann es losgehen im Terminal jeder beliebiger Linux-Distribution:

Anweisungen, so auch die obige, beginnen stets mit “awk”. Da diese CSV-Datei nicht mit dem Standardchar (Komma), sondern einem vertikalen Strich (Pipe) getrennt ist, muss dies via “-F’|'” angegeben werden. Wäre das Trennzeichen ein Semikolon, wäre der Parameter “-F’;'” korrekt. Der Befehl gibt jede Zeile des CSV in der Kommandozeile aus, so dass wie nachfolgend den gesamten Dateiinhalt sehen:

Viele CSV- und Logdateien haben keinen Header, diese hier hat jedoch die erste Zeile als Header, die daher bei der Analyse nicht als Werte-Zeile fehlinterpretiert werden darf, daher wird nachfolgend von nun an die Anweisung “NR>1” mitgegeben:

Spalten werden in awk über das Dollarzeichen angesprochen, folgende Anweisung zeigt uns alle Zeilen der zweiten Spalte:

Diese Skriptsprache beherrscht assoziative Arrays. Es können demnach auch nicht-numerische Schlüssel für den Zugriff auf Datenfelder verwendet werden. Dies machen wir uns für das Anzeigen aller Standorte mit Angabe der jeweiligen Mitarbeiterzahl an dem Standort zu nutze. Die Variable a speichert alle Mitarbeiterzahlen in Spalte 4 über den Schlüssel des Standortnamens in Spalte 2, dann endet der Anweisungsblock und es folgt eine For-Schleife, die alle Schlüsselwerte ausgibt und den dazugehörigen Speicherwert (Mitarbeiterzahl) ausgibt.

Auch If-Anweisungen sind einfach machbar. Folgendes Beispiel unterscheidet die Zeilennummern (Spalte1) nach geraden und ungeraden Zahlen und gibt den dazugehörigen Standortnamen (Spalte 2) aus.

Folgendes Beispiel klassifiziert alle Standorte mit weniger als 10 Mitarbeitern, allerdings nicht über “if…else…”, sondern über die Kurzabfrage nach dem Schema a>b?”True”:”False”.

Folgendes Code-Beispiel zeigt die Zählung der Vorkommnisse (Entsprechung: GROUP BY Spalte3, Count(*)).

Etwas umformuliert, können wir auch die Werte pro Gruppe aufsummieren, nachfolgend beispielhaft der Gewinn (Einnahmen aus Spalte 5 – Kosten aus Spalte 6) und die Mitarbeiterzahl über die jeweilige Gruppe.

Das Zusammenführen von Zeichenketten erfolgt simpel durch Aneinandereihung:

Ein letztes Beispiel möchte keine einzelnen Zeilen des Datensatzes auflisten und auch keine Gruppierung unterscheiden, sondern die Zusammenfassung über die Angabe der gesamten Mitarbeiteranzahl und der Gewinn-Summe über alle Standorte angeben.

Fazit

Als Programmiersprache ist awk sicherlich nur ein nice-to-have, aber wenn man das Prinzip dieser Sprache erstmal verstanden hat, kann sie ein interessantes Tool darstellen, um schon auf Kommandozeilenebene sich schnell einen Überblick über Datenbestände zu beschaffen und auch um Datenqualitätstests durchzuführen.

 

KNN: Was sind künstliche neuronale Netze?

Ein künstliches neuronales Netzwerk (KNN) besteht aus vielen miteinander verbundenen künstlichen Neuronen. Die einzelnen Neuronen haben unterschiedliche Aufgaben und sind innerhalb von Schichten (layer) angeordnet. Sogenannte Netzwerk Topologien geben vor, wie viele Neuronen sich auf einer Schicht befinden und welche Neuronen miteinander vernetzt sind. Neuronale Netze werden im Bereich der künstlichen Intelligenz eingesetzt und sind ein Ansatz im Machine Learning, haben hier jedoch besondere Vor- und Nachteile.

Es gibt drei Schicht- und vier grundlegende Neuronen-Arten. Bei den Schichten wird unterschieden zwischen Eingabe-, Ausgabe- und verborgener Schicht (Visible, Output & Hidden Layer). Alle eingehenden Daten werden an den Eingabe-Neuronen (Visible Unit) in der Eingabeschicht angelegt. Diese wiederum geben die Daten weiter an die verbundenen Ausgabe- oder verborgenen Neuronen (Output, Hidden Unit). Zusätzlich kann in jeder Schicht noch ein Bias Neuron (Bias Unit) zum Einsatz kommen. Read more