Benjamin Aunkofer

Ensemble Learning

/in , , , , , , , /by

Stellen Sie sich vor, Sie haben die Frage Ihres Lebens vor sich. Die korrekte Beantwortung dieser Frage wird Ihr Leben positiv beeinflussen, andernfalls negativ. Aber Sie haben Glück: Sie dürfen einen Experten, den Sie auswählen dürfen, um Rat fragen oder Sie dürfen eine annonyme Gruppe, sagen wir 1.000 Personen, um Rat fragen. Welchen Rat würden Sie sich einholen? Die einzelne Experten-Meinung oder die aggriegierte Antwort einer ganzen Gruppe von Menschen?
Oder wie wäre es mit einer Gruppe von Experten?

Ensemble Learning

Beim Einsatz eines maschinellen Lernalgorithmus auf ein bestimmtes Problem kann durchaus eine angemessene Präzision (Accuracy, eine Quote an Prädiktionsergebnissen, die als korrekt einzustufen sind) erzielt werden, doch oftmals reicht die Verlässlichkeit eines einzelnen Algorithmus nicht aus. Algorithmen können mit unterschiedlichen Parametern verwendet werden, die sich bei bestimmten Daten-Situationen verschieden auswirken. Bestimmte Algorithmen neigen zur Unteranpassung (Underfitting), andere zur Überanpassung (Overfitting).

Soll Machine Learning für den produktiven Einsatz mit bestmöglicher Zuverlässigkeit entwickelt und eingesetzt werden, kommt sinnvollerweise Ensemble Learning zum Einsatz. Beim Ensemble Learning wird ein Ensemble (Kollektiv von Prädiktoren) gebildet um ein Ensemble Average (Kollektivmittelwert) zu bilden. Sollte also beispielsweise einige Klassifizierer bei bestimmten Daten-Eingaben in ihren Ergebnissen ausreißen, steuern andere Klassifizierer dagegen. Ensemble Learning kommt somit in der Hoffnung zum Einsatz, dass eine Gruppe von Algorithmen ein besseres Ergebnis im Mittel erzeugen als es ein einzelner Algorithmus könnte.

Ich spreche nachfolgend bevorzugt von Klassifizierern, jedoch kommt Ensemble Learning auch bei der Regression zum Einsatz.

Voting Classifiers (bzw. Voting Regressors)

Eine häufige Form – und i.d.R. auch als erstes Beispiel eines Ensemble Learners – ist das Prinzip der Voting Classifiers. Das Prinzip der Voting Classifiers ist eine äußerst leicht nachvollziehbare Idee des Ensemble Learnings und daher vermutlich auch eine der bekanntesten Form der Kollektivmittelwert-Bildung. Gleich vorweg: Ja, es gibt auch Voting Regressors, jedoch ist dies ein Konzept, das nicht ganz ohne umfassendere Aggregation auf oberster Ebene auskommen wird, daher wäre für die Zwecke der akkurateren Regression eher das Stacking (siehe unten) sinnvoll.

Eine häufige Frage im Data Science ist, welcher Klassifizierer für bestimmte Zwecke die besseren sind: Entscheidungsbäume, Support-Vector-Machines, k-nächste-Nachbarn oder logistische Regressionen?

Warum nicht einfach alle nutzen? In der Tat wird genau das nicht selten praktiziert. Das Ziel dieser Form des Ensemble Learnings ist leicht zu erkennen: Die unterschiedlichen Schwächen aller Algorithmen sollen sich – so die Hoffnung – gegenseitig aufheben. Alle Algorithmen (dabei können auch mehrere gleiche Algorithmen mit jedoch jeweils unterschiedlichen Paramtern gemeint sein, z. B. mehrere knN-Klassifizierer mit unterschiedlichen k-Werten und Dimensionsgewichtungen) werden auf dasselbe Problem hin trainiert.

Stacking

Bei der Prädiktion werden entweder alle Klassifizierer gleich behandelt oder unterschiedlich gewichtet (wobei größere Unterschiede der Gewichtungen unüblich, und vermutlich auch nicht sinnvoll, sind). Entsprechend einer Ensemble-Regel werden die Ergebnisse aller Klassifizierer aggregiert, bei Klassifikation durch eine Mehrheitsentscheidung, bei Regression meistens durch Durchschnittsbildung oder (beim Stacking) durch einen weiteren Regressor.

Abgesehen davon, dass wir mit dem Ensemble-Klassifizierer bzw. Regressoren vermutlich bessere Ergebnisse haben werden, haben wir nun auch eine weitere Information hinzubekommen: Eine Entropie über die Wahrscheinlichkeit. Bestenfalls haben alle Klassifizierer die gleiche Vorhersage berechnet, schlechtestensfalls haben wir ein Unentschieden. So können wir Vorhersagen in ihrer Aussagekraft bewerten. Analog kann bei Regressionen die Varianz der Ergebnisse herangezogen werden, um das Ergebnis in seiner Aussagekraft zu bewerten.

Betrachtung im Kontext von: Eine Kette ist nur so stark, wie ihr schwächstes Glied

Oft heißt es, dass Ensemble Learning zwar bessere Ergebnisse hervorbringt, als der schwächste Klassifizier in der Gruppe, aber auch schlechtere als der beste Klassifizierer. Ist Ensemble Learning also nur ein Akt der Ratlosigkeit, welcher Klassifizierer eigentlich der bessere wäre?

Ja und nein. Ensemble Learning wird tatsächlich in der Praxis dazu verwendet, einzelne Schwächen abzufangen und auch Ausreißer-Verhalten auf bisher andersartiger Daten abzuschwächen. Es ist ferner jedoch so, dass Ensemble Learner mit vielen Klassifizieren sogar bessere Vorhersagen liefern kann, als der beste Klassifizierer im Programm.

Das liegt an dem Gesetz der großen Zahlen, dass anhand eines Beispiels verdeutlicht werden kann: Bei einem (ausbalanzierten) Münzwurf liegt die Wahrscheinlichkeit bei genau 50,00% dafür, Kopf oder Zahl zu erhalten. Werfe ich die Münze beispielsweise zehn Mal, erhalte ich aber vielleicht drei Mal Kopf und sieben mal Zahl. Werfe ich sie 100 Mal, erhalte ich vielleicht 61 Mal Kopf und 39 Mal Zahl. Selbst nur 20 Mal die Zahl zu erhalten, wäre bei nur 100 Würfen gar nicht weit weg von unwahrscheinlich. Würde ich die Münze jedoch 10.000 Male werfen, würde ich den 50% schon sehr annähern, bei 10 Millionen Würfen wird sich die Verteilung ganz sicher als Gleichverteilung mit 50,0x% für Kopf oder Zahl einpendeln.

Nun stellt man sich (etwas überspitzt, da analog zu den Wünzwürfen) nun einen Ensemble Learner mit einer Gruppe von 10.000 Klassifiziern vor. Und angenommen, jeder einzelne Klassifizierer ist enorm schwach, denn eine richtige Vorhersage trifft nur mit einer Präzision von 51% zu (also kaum mehr als Glücksspiel), dann würde jedoch die Mehrheit der 10.000 Klassifizierer (nämlich 51%) richtig liegen und die Mehrheitsentscheidung in den absolut überwiegenden Fällen die korrekte Vorhersage treffen.

Was hingehen in diesem Kontext zutrifft: Prädiktionen via Ensemble Learning sind zwangsläufig langsam. Durch Parallelisierung der Klassifikation kann natürlich viel Zeit eingespart werden, dann ist das Ensemble Learning jedoch mindestens immer noch so langsam, wie der langsamste Klassifizierer.

Bagging

Ein Argument gegen den Einsatz von gänzlich verschiedenen Algortihmen ist, dass ein solcher Ensemble Learner nur schwer zu verstehen und einzuschätzen ist (übrigens ein generelles Problem im maschinellen Lernen). Bereits ein einzelner Algorithmus (z. B. Support Vector Machine) kann nach jedem Training alleine auf Basis der jeweils ausgewählten Daten (zum Training und zum Testen) recht unterschiedlich in seiner Vorhersage ausfallen.

Bagging (kurze Form von Bootstrap Aggregation) ist ein Ensemble Learning Prinzip, bei dem grundsätzlich der gleiche Algorithmus parallel mit unterschiedlichen Aufteilungen der Daten trainiert (und natürlich getestet) wird. Die Aufteilung der Daten kann dabei komplett (der vollständige Datensatz wird verteilt und verwendet) oder auch nur über Stichproben erfolgen (dann gibt es mehrfach verwendete Datenpunkte, aber auch solche, die überhaupt nicht verwendet werden). Das Ziel ist dabei insbesondere, im Endergebnis Unter- und Überanpassung zu vermeiden. Gibt es viele Dichte-Cluster und Ausreißer in den Daten, wird nicht jeder Klassifizierer sich diesen angepasst haben können. Jede Instanz der Klassifizierer erhält weitgehend unterschiedliche Daten mit eigenen Ausreißern und Dichte-Clustern, dabei darf es durchaus Überschneidungen bei der Datenaufteilung geben.

Pasting

Pasting ist fast genau wie Bagging, nur mit dem kleinen aber feinen Unterschied, dass sich die Datenaufteilung nicht überschneiden darf. Wird ein Datenpunkt durch Zufallsauswahl einem Klassifizierer zugewiesen, wird er nicht mehr für einen anderen Klassifizierer verwendet. Über die Trainingsdaten des einen Klassifizierers verfügt demnach kein anderer Klassifizierer. Die Klassifizierer sind somit völlig unabhängig voneinander trainiert, was manchmal explizit gewollt sein kann. Pasting setzt natürlich voraus, dass genug Daten vorhanden sind. Diese Voraussetzung ist gleichermaßen auch eine Antwort auf viele Probleme: Wie können große Datenmengen schnell verarbeitet werden? Durch die Aufteilung ohne Überschneidung auf parallele Knoten.

Random Forest

Random Forests sollten an dieser Stelle im Text eigentlich nicht stehen, denn sie sind ein Beispiel des parallelen Ensembles bzw. des Voting Classifiers mit Entscheidungsbäumen (Decision Trees). Random Forests möchte ich an dieser Stelle dennoch ansprechen, denn sie sind eine äußerst gängige Anwendung des Baggings oder (seltener) auch des Pastings für Entscheidungsbaumverfahren. Die Datenmenge wird durch Zufall aufgeteilt und aus jeder Aufteilung heraus wird ein Entscheidungsbaum erstellt. Eine Mehrheitsentscheidung der Klassifikationen aller Bäume ist das Ensemble Learning des Random Forests.

Random Forest ist ein Verfahren der Klassifikation oder Regression, das bereits so üblich ist, dass es mittlerweile längst in (fast) allen Machine Learning Bibliotheken implemeniert ist und – dank dieser Implementierung – in der Anwendung nicht komplizierter, als ein einzelner Entscheidungsbaum.

Stacking

Stacking ist eine Erweiterung des Voting Classifiers oder Voting Regressors um eine höhere Ebene (Blending-Level), die die beste Aggregation der Einzel-Ergebnisse erlernt. An der Spitze steht beim Stacking (mindestens) ein weiterer Klassifikator oder Regressor

Stacking ist insbesondere dann sinnvoll, wenn die Ergebnisse der einzelnen Algorithmen sehr unterschiedlich ausfallen können, was bei der Regression – da stetige Werte statt wenige Klassen – nahezu immer der Fall ist. Stacking-Algorithmen können sogar mehrere Schichten umfassen, was ihr Training wesentlich schwieriger gestaltet.

Boosting (Sequential Ensemble Learning)

Bagging, Pasting und Stacking sind parallele Verfahren des Ensemble Learning (was nicht bedeutet, dass die parallel dargestellten Algorithmen in der Praxis nicht doch sequenziell abgearbeitet werden). Zwangsweise sequenziell durchgeführt wird hingegen das Boosting, bei dem wir schwache Klassifizierer bzw. Regressoren durch Iteration in ihrem Training verstärken wollen. Boosting kann somit als eine Alternative zum Deep Learning gesehen werden. Während beim Deep Learning ein starker Algorithmus durch ein mehrschichtiges künstliches neuronales Netz dafür entworfen und trainiert wird, um ein komplexes Problem zu lösen (beispielsweise Testerkennung [OCR]), können derartige Herausforderungen auch mit schwächeren Klassifikatoren unter Einsatz von Boosting realisiert werden.

Boosting bezieht sich allein auf das Training und ist aus einer Not heraus entstanden: Wie bekommen wir bessere Prädiktionen mit einem eigentlich schwachen Lernalgorithmus, der tendenziell Unteranpassung erzeugt? Boosting ist eine Antwort auf Herausforderungen der Klassifikation oder Regression, bei der ein Algorithmus iterativ, also in mehreren Durchläufen, durch Anpassung von Gewichten trainiert wird.

Eines der bekanntesten Boosting-Verfahren ist AdaBoost. Der erste Schritt ist ein normales Training. Beim darauffolgenden Testen zeigen sich Klassifikations-/Regressionsfehler. Die fehlerhaft vorhergesagten Datenpunkte werden dann für einen nächsten Durchlauf höher gewichtet. Diese Iteration läuft einige Male, bis die Fehlerquote sich nicht mehr verbessert.

Bei AdaBoost werden falsch vorhergesagte Datensätze im jeweils nächsten Durchlauf höher gewichtet. Bei einem alternativen Boosing-Verfahren, dem Gradient Boosting (auf Basis der Gradientenmethode), werden Gewichtungen explizit in Gegenrichtung des Prädiktionsfehlers angepasst.

Was beispielsweise beim Voting Classifier der Random Forest ist, bei dem mehrere Entscheidungsbäume parallel arbeiten, sind das Äquvivalent beim Boosting die Gradient Boosted Trees, bei denen jeder Baum nur einen Teil der Daten akkurat beschreiben kann, die sequentielle Verschachtelung der Bäume jedoch auch herausfordernde Klassifikationen meistert.

Um bei dem Beispiel der Entscheidungsbäume zu bleiben: Sowohl Random Forests als auch Gradient Boosted Trees arbeiten grundsätzlich mit flachen Bäumen (schwache Klassifikatoren). Gradient Boosted Trees können durch die iterative Verstärkung generell eine höhere Präzision der Prädiktion erreichen als Random Forests, wenn die Feature- und Parameter-Auswahl bereits zu Anfang sinnvoll ist. Random Forests sind hingegen wiederum robuster bei der Feature- und Parameter-Auswahl, verstärken sich jedoch nicht gegenseitig, sondern sind in ihrem Endergebnis so gut, wie die Mehrheit der Bäume.

Buchempfehlungen

Mehr zum Thema Machine Learning und Ensemble Learning gewünscht? Folgende zwei Buchempfehlungen bieten nicht nur Erklärungen, sondern demonstrieren Ensemble Learning auch mit Beispiel-Code mit Python Scikit-Learn.

Hands-On Machine Learning with Scikit-Learn and TensorFlow: Concepts, Tools, and Techniques for Building Intelligent Systems Machine Learning mit Python: Das Praxis-Handbuch für Data Science, Predictive Analytics und Deep Learning (mitp Professional)
Benjamin Aunkofer

Lineare Regression in Python mit Scitkit-Learn

/in , , , , , /by

Die lineare Regressionsanalyse ist ein häufiger Einstieg ins maschinelle Lernen um stetige Werte vorherzusagen (Prediction bzw. Prädiktion). Hinter der Regression steht oftmals die Methode der kleinsten Fehlerquadrate und die hat mehr als eine mathematische Methode zur Lösungsfindung (Gradientenverfahren und Normalengleichung). Alternativ kann auch die Maximum Likelihood-Methode zur Regression verwendet werden. Wir wollen uns in diesem Artikel nicht auf die Mathematik konzentrieren, sondern uns direkt an die Anwendung mit Python Scikit-Learn machen:

Haupt-Lernziele:

  • Einführung in Machine Learning mit Scikit-Learn
  • Lineare Regression mit Scikit-Learn

Neben-Lernziele:

  • Datenvorbereitung (Data Preparation) mit Pandas und Scikit-Learn
  • Datenvisualisierung mit der Matplotlib direkt und indirekt (über Pandas)

Was wir inhaltlich tun:

Der Versuch einer Vorhersage eines Fahrzeugpreises auf Basis einer quantitativ-messbaren Eigenschaft eines Fahrzeuges.

Die Daten als Download

Für dieses Beispiel verwende ich die Datei “Automobil_data.txt” von Kaggle.com. Die Daten lassen sich über folgenden Link downloaden, nur leider wird ein (kostenloser) Account benötigt:
https://www.kaggle.com/toramky/automobile-dataset/downloads/automobile-dataset.zip
Sollte der Download-Link unerwartet mal nicht mehr funktionieren, freue ich mich über einen Hinweis als Kommentar 🙂

Die Entwicklungsumgebung

Ich verwende hier die Python-Distribution Anaconda 3 und als Entwicklungs-Umgebung Spyder (in Anaconda enthalten). Genauso gut funktionieren jedoch auch Jupyter Notebook, Eclipse mit PyDev oder direkt die IPython QT-Console.

Zuerst einmal müssen wir die Daten in unsere Python-Session laden und werden einige Transformationen durchführen müssen. Wir starten zunächst mit dem Importieren von drei Bibliotheken NumPy und Pandas, deren Bedeutung ich nicht weiter erläutern werde, somit voraussetze.

Wir nutzen die Pandas-Bibliothek, um die “Automobile_data.txt” in ein pd.DataFrame zu laden.

Schauen wir uns dann die ersten fünf Zeilen in IPython via dataSet.head().

Hinweis: Der Datensatz hat viele Spalten, so dass diese in der Darstellung mit einem Backslash \ umgebrochen werden.

Gleich noch eine weitere Ausgabe dataSet.info(), die uns etwas über die Beschaffenheit der importierten Daten verrät:

Einige Spalten entsprechen hinsichtlich des Datentypes nicht der Erwartung. Für die Spalten ‘horsepower’ und ‘peak-rpm’ würde ich eine Ganzzahl (Integer) erwarten, für ‘price’ hingegen eine Fließkommazahl (Float), allerdings sind die drei Spalten als Object deklariert. Mit Trick 17 im Data Science, der Anzeige der Minimum- und Maximum-Werte einer zu untersuchenden Datenreihe, kommen wir dem Übeltäter schnell auf die Schliche:

Datenbereinigung

Für eine Regressionsanalyse benötigen wir nummerische Werte (intervall- oder ratioskaliert), diese möchten wir auch durch richtige Datentypen-Deklaration herstellen. Nun wird eine Konvertierung in den gewünschten Datentyp jedoch an den (mit ‘?’ aufgefüllten) Datenlücken scheitern.

Schauen wir uns doch einmal die Datenreihen an, in denen in der Spalte ‘peak-rpm’ Fragezeichen stehen:

Zwei Datenreihen sind vorhanden, bei denen ‘peak-rpm’ mit einem ‘?’ aufgefüllt wurde. Nun könnten wir diese Datenreihen einfach rauslöschen. Oder mit sinnvollen (im Sinne von wahrscheinlichen) Werten auffüllen. Vermutlichen haben beide Einträge – beide sind OHC-Motoren mit 4 Zylindern – eine ähnliche Drehzahl-Angabe wie vergleichbare Motoren. Mit folgendem Quellcode, gruppieren wir die Spalten ‘engine-type’ und ‘num-of-cylinders’ und bilden für diese Klassen den arithmetischen Mittelwert (.mean()) für die ‘peak-rpm’.

Und schauen wir uns das Ergebnis an:

Ein Vier-Zylinder-OHC-Motor hat demnach durchschnittlich einen Drehzahl-Peak von 5155 Umdrehungen pro Minute. Ohne nun (fahrlässigerweise) auf die Verteilung in dieser Klasse zu achten, nehmen wir einfach diesen Schätzwert, um die zwei fehlende Datenpunkte zu ersetzen.

Wir möchten jedoch die Original-Daten erhalten und legen ein neues DataSet (dataSet_c) an, in welches wir die Korrekturen vornehmen:

Nun können wir die fehlenden Peak-RPM-Einträge mit unserem Schätzwert ersetzen:

Was bei einer Drehzahl-Angabe noch funktionieren mag, ist für anderen Spalten bereits etwas schwieriger: Die beiden Spalten ‘price’ und ‘horsepower’ sind ebenfalls vom Typ Object, da sie ‘?’ enthalten. Verzichten wir einfach auf die betroffenen Zeilen:

Datenvisualisierung mit Pandas

Wir wollen uns nicht lange vom eigentlichen Ziel ablenken, dennoch nutzen wir die Visualisierungsfähigkeiten der Pandas-Library (welche die Matplotlib inkludiert), um uns dann die Anzahlen an Einträgen nach Hersteller der Fahrzeuge (Spalte ‘make’) anzeigen zu lassen:

Oder die durchschnittliche PS-Zahl nach Hersteller:

Vorbereitung der Regressionsanalyse

Nun kommen wir endlich zur Regressionsanalyse, die wir mit Scikit-Learn umsetzen möchten. Die Regressionsanalyse können wir nur mit intervall- oder ratioskalierten Datenspalten betreiben, daher beschränken wir uns auf diese. Die “price”-Spalte nehmen wir jedoch heraus und setzen sie als unsere Zielgröße fest.

Interessant ist zudem die Betrachtung vorab, wie die einzelnen nummerischen Attribute untereinander korrelieren. Dafür nehmen wir auch die ‘price’-Spalte wieder in die Betrachtung hinein und hinterlegen auch eine Farbskala mit dem Preis (höhere Preise, hellere Farben).

Die lineare Korrelation ist hier sehr interessant, da wir auch nur eine lineare Regression beabsichtigen.

Wie man in dieser Scatter-Matrix recht gut erkennen kann, scheinen einige Größen-Paare nahezu perfekt zu korrelieren, andere nicht.

Korrelation…

  • …nahezu perfekt linear: highway-mpg vs city-mpg (mpg = Miles per Gallon)
  • … eher nicht gegeben: highway-mpg vs height
  • … nicht linear, dafür aber nicht-linear: highway-mpg vs price

Nun, wir wollen den Preis eines Fahrzeuges vorhersagen, wenn wir eine andere quantitative Größe gegeben haben. Auf den Preis bezogen, erscheint mir die Motorleistung (Horsepower) einigermaßen linear zu korrelieren. Versuchen wir hier die lineare Regression und setzen somit die Spalte ‘horsepower’ als X und ‘price’ als y fest.

Die gängige Konvention ist übrigens, X groß zu schreiben, weil hier auch mehrere x-Dimensionen enthalten sein dürfen (multivariate Regression). y hingegen, ist stets nur eine Zielgröße (eine Dimension).

Die lineare Regression ist ein überwachtes Verfahren des maschinellen Lernens, somit müssen wir unsere Prädiktionsergebnisse mit Test-Daten testen, die nicht für das Training verwendet werden dürfen. Scitkit-Learn (oder kurz: sklearn) bietet hierfür eine Funktion an, die uns das Aufteilen der Daten abnimmt:

Zu beachten ist dabei, dass die Daten vor dem Aufteilen in Trainings- und Testdaten gut zu durchmischen sind. Auch dies übernimmt die train_test_split-Funktion für uns, nur sollte man im Hinterkopf behalten, dass die Ergebnisse (auf Grund der Zufallsauswahl) nach jedem Durchlauf immer wieder etwas anders aussehen.

Lineare Regression mit Scikit-Learn

Nun kommen wir zur Durchführung der linearen Regression mit Scitkit-Learn, die sich in drei Zeilen trainieren lässt:

Aber Vorsicht! Bevor wir eine Prädiktion durchführen, wollen wir festlegen, wie wir die Güte der Prädiktion bewerten wollen. Die gängigsten Messungen für eine lineare Regression sind der MSE und R².

MSE = \frac{\sum_{i=1}^n (y_i - \hat{y_i})^2}{n}

Ein großer MSE ist schlecht, ein kleiner gut.

R^2 = 1 - \frac{MSE}{Var(y)}= \frac{\frac{1}{n} \cdot \sum_{i=1}^n (y_i - \hat{y_i})^2}{\frac{1}{n} \cdot \sum_{i=1}^n (y_i - \hat{\mu_y})^2}

Ein kleines R² ist schlecht, ein großes R² gut. Ein R² = 1.0 wäre theoretisch perfekt (da der Fehler = 0.00 wäre), jedoch in der Praxis unmöglich, da dieser nur bei absolut perfekter Korrelation auftreten würde. Die Klasse LinearRegression hat eine R²-Messmethode implementiert (score(x, y)).

Die Ausgabe (ein Beispiel!):

Nach jedem Durchlauf ändert sich mit der Datenaufteilung (train_test_split()) das Modell etwas und auch R² schwankt um eine gewisse Bandbreite. Berauschend sind die Ergebnisse dabei nicht, und wenn wir uns die Regressionsgerade einmal ansehen, wird auch klar, warum:

Bei kleineren Leistungsbereichen, etwa bis 100 PS, ist die Preis-Varianz noch annehmbar gering, doch bei höheren Leistungsbereichen ist die Spannweite deutlich größer. (Nachträgliche Anmerkung vom 06.05.2018: relativ betrachtet, bleibt der Fehler über alle Wertebereiche ungefähr gleich [relativer Fehler]. Die absoluten Fehlerwerte haben jedoch bei größeren x-Werten so eine Varianz der möglichen y-Werte, dass keine befriedigenden Prädiktionen zu erwarten sind.)

Egal wie wir eine Gerade in diese Punktwolke legen, wir werden keine befriedigende Fehlergröße erhalten.

Nehmen wir einmal eine andere Spalte für X, bei der wir vor allem eine nicht-lineare Korrelation erkannt haben: “highway-mpg”

Wenn wir dann das Training wiederholen:

Die R²-Werte sind nicht gerade berauschend, und das erklärt sich auch leicht, wenn wir die Trainings- und Testdaten sowie die gelernte Funktionsgerade visualisieren:

Die Gerade lässt sich nicht wirklich gut durch diese Punktwolke legen, da letztere eher eine Kurve als eine Gerade bildet. Im Grunde könnte eine Gerade noch einigermaßen gut in den Bereich von 22 bis 43 mpg passen und vermutlich annehmbare Ergebnisse liefern. Die Wertebereiche darunter und darüber jedoch verzerren zu sehr und sorgen zudem dafür, dass die Gerade auch innerhalb des mittleren Bereiches zu weit nach oben verschoben ist (ggf. könnte hier eine Ridge-/Lasso-Regression helfen).

Richtig gute Vorhersagen über nicht-lineare Verhältnisse können jedoch nur mit einer nicht-linearen Regression erreicht werden.

Nicht-lineare Regression mit Scikit-Learn

Nicht-lineare Regressionsanalysen erlauben es uns, nicht-lineare korrelierende Werte-Paare als Funktion zu erlernen. Im folgenden Scatter-Plot sehen wir zum einen die gewohnte lineare Regressionsgerade (y = a * x + b) in rot, eine polinominale Regressionskurve dritten Grades (y = a * x³ + b * x² + c * x + d) in violet sowie einen Entscheidungsweg einer Entscheidungsbaum-Regression in gelb.

Nicht-lineare Regressionsanalysen passen sich dem Verlauf der Punktwolke sehr viel besser an und können somit in der Regel auch sehr gute Vorhersageergebnisse liefern. Ich ziehe hier nun jedoch einen Gedankenstrich, liefere aber den Quellcode für die lineare Regression als auch für die beiden nicht-linearen Regressionen mit:

Python Script Regression via Scikit-Learn

Weitere Anmerkungen

  • Bibliotheken wie Scitkit-Learn erlauben es, machinelle Lernverfahren schnell und unkompliziert anwenden zu können. Allerdings sollte man auch verstehen, wei diese Verfahren im Hintergrund mathematisch arbeiten. Diese Bibliotheken befreien uns also nicht gänzlich von der grauen Theorie.
  • Statt der “reinen” lineare Regression (LinearRegression()) können auch eine Ridge-Regression (Ridge()), Lasso-Regression (Lasso()) oder eine Kombination aus beiden als sogenannte ElasticNet-Regression (ElasticNet()). Bei diesen kann über Parametern gesteuert werden, wie stark Ausreißer in den Daten berücksichtigt werden sollen.
  • Vor einer Regression sollten die Werte skaliert werden, idealerweise durch Standardisierung der Werte (sklearn.preprocessing.StandardScaler()) oder durch Normierung (sklearn.preprocessing.Normalizer()).
  • Wir haben hier nur zwei-dimensional betrachtet. In der Praxis ist das jedoch selten ausreichend, auch der Fahrzeug-Preis ist weder von der Motor-Leistung, noch von dem Kraftstoffverbrauch alleine abhängig – Es nehmen viele Größen auf den Preis Einfluss, somit benötigen wir multivariate Regressionsanalysen.
Benjamin Aunkofer

Process Mining: Innovative Analyse von Datenspuren für Audit und Forensik

/in , , , , , , , , /by

Step-by-Step:

Neue Möglichkeiten zur Aufdeckung von Compliance-Verstößen mit Process Analytics

Im Zuge der fortschreitenden Digitalisierung findet derzeit ein enormer Umbruch der alltäglichen Arbeit hin zur lückenlosen Erfassung aller Arbeitsschritte in IT-Systemen statt. Darüber hinaus sehen sich Unternehmen mit zunehmend verschärften Regulierungsanforderungen an ihre IT-Systeme konfrontiert.

Der unaufhaltsame Trend hin zur vernetzten Welt („Internet of Things“) wird die Möglichkeiten der Prozesstransparenz noch weiter vergrößern – jedoch werden bereits jetzt viele Prozesse im Unternehmensbereich über ein oder mehrere IT-Systeme erfasst. Jeder Mitarbeiter, aber auch jeder automatisiert ablaufende Prozess hinterlässt viele Datenspuren in IT-Backend-Systemen, aus denen Prozesse rückwirkend oder in Echtzeit nachgebildet werden können. Diese umfassen sowohl offensichtliche Prozesse, wie etwa den Eintrag einer erfassten Bestellung oder Rechnung, als auch teilweise verborgene Prozesse, wie beispielsweise die Änderung bestimmter Einträge oder Löschung dieser Geschäftsobjekte. 

english-flagRead this article in English:
“Process Analytics – Data Analysis for Process Audit & Improvement”

1 Das Verständnis von Process Analytics

Process Analytics ist eine datengetriebene Methodik der Ist-Prozessanalyse, die ihren Ursprung in der Forensik hat. Im Kern des dieser am Zweck orientierten Analyse steht das sogenannte Process Mining, eine auf die Rekonstruktion von Prozessen ausgerichtetes Data Mining. Im Zuge der steigenden Bedeutung der Computerkriminalität wurde es notwendig, die Datenspuren, die potenzielle Kriminelle in IT-Systemen hinterließen, zu identifizieren und zu analysieren, um das Geschehen so gut wie möglich zu rekonstruieren.

Mit dem Trend hin zu Big Data Analytics hat Process Analytics nicht nur neue Datengrundlagen erhalten, sondern ist als Analysemethode weiterentwickelt worden. Zudem ermöglicht die Visualisierung dem Analysten oder Berichtsempfänger ein tief gehendes Verständnis auch komplexerer Geschäftsprozesse.

Während in der konventionellen Prozessanalyse vor allem Mitarbeiterinterviews und Beobachtung der Mitarbeiter am Schreibtisch durchgeführt werden, um tatsächlich gelebte Prozesse zu ermitteln, ist Process Analytics eine führende Methode, die rein faktenbasiert und damit objektiv an die Prozesse herangeht. Befragt werden nicht die Mitarbeiter, sondern die IT-Systeme, die nicht nur alle erfassten Geschäftsobjekte tabellenorientiert abspeichern, sondern auch im Hintergrund – unsichtbar für die Anwender – jegliche Änderungsvorgänge z. B. an Bestellungen, Rechnungen oder Kundenaufträgen lückenlos mit einem Zeitstempel (oft Sekunden- oder Millisekunden-genau) protokollieren.

2 Die richtige Auswahl der zu betrachtenden Prozesse

Heute arbeitet nahezu jedes Unternehmen mit mindestens einem ERP-System. Da häufig noch weitere Systeme eingesetzt werden, lässt sich klar herausstellen, welche Prozesse nicht analysiert werden können: Solche Prozesse, die noch ausschließlich auf Papier und im Kopf der Mitarbeiter ablaufen, also typische Entscheiderprozesse auf oberster, strategischer Ebene, die nicht in IT-Systemen erfasst und dementsprechend nicht ausgewertet werden können. Operative Prozesse werden hingegen in der Regel nahezu lückenlos in IT-Systemen erfasst und operative Entscheidungen protokolliert.

Zu den operativen Prozessen, die mit Process Analytics sehr gut rekonstruiert und analysiert werden können und gleichermaßen aus Compliance-Sicht von höchstem Interesse sind, gehören beispielsweise Prozesse der:

  • Beschaffung
  • Logistik / Transport
  • Vertriebs-/Auftragsvorgänge
  • Gewährleistungsabwicklung
  • Schadensregulierung
  • Kreditgewährung

Process Analytics bzw. Process Mining ermöglicht unabhängig von der Branche und dem Fachbereich die größtmögliche Transparenz über alle operativen Geschäftsprozesse. Für die Audit-Analyse ist dabei zu beachten, dass jeder Prozess separat betrachtet werden sollte, denn die Rekonstruktion erfolgt anhand von Vorgangsnummern, die je nach Prozess unterschiedlich sein können. Typische Vorgangsnummern sind beispielsweise Bestell-, Auftrags-, Kunden- oder Materialnummern.

3 Auswahl der relevanten IT-Systeme

Grundsätzlich sollte jedes im Unternehmen eingesetzte IT-System hinsichtlich der Relevanz für den zu analysierenden Prozess untersucht werden. Für die Analyse der Einkaufsprozesse ist in der Regel nur das ERP-System (z. B. SAP ERP) von Bedeutung. Einige Unternehmen verfügen jedoch über ein separates System der Buchhaltung (z.B. DATEV) oder ein CRM/SRM (z. B. von Microsoft), die dann ebenfalls einzubeziehen sind.

Bei anderen Prozessen können außer dem ERP-/CRM-System auch Daten aus anderen IT-Systemen eine entscheidende Rolle spielen. Gelegentlich sollten auch externe Daten integriert werden, wenn diese aus extern gelagerten Datenquellen wichtige Prozessinformationen liefern – beispielsweise Daten aus der Logistik.

4 Datenaufbereitung

Vor der datengetriebenen Prozessanalyse müssen die Daten, die auf Prozessaktivitäten direkt oder indirekt hindeuten, in den Datenquellen identifiziert, extrahiert und aufbereitet werden. Die Daten liegen in Datenbanktabellen und Server-Logs vor und werden über ein Data Warehousing Verfahren zusammengeführt und in ein Prozessprotokoll (unter den Process Minern i.d.R. als Event Log bezeichnet) umformuliert.

Das Prozessprotokoll ist in der Regel eine sehr große und breite Tabelle, die neben den eigentlichen Prozessaktivitäten auch Parameter enthält, über die sich Prozesse filtern lassen, beispielsweise Informationen über Produktgruppen, Preise, Mengen, Volumen, Fachbereiche oder Mitarbeitergruppen.

5 Prüfungsdurchführung

Die eigentliche Prüfung erfolgt visuell und somit intuitiv vor einem Prozessflussdiagramm, das die tatsächlichen Prozesse so darstellt, wie sie aus den IT-Systemen extrahiert werden konnten.

Process Mining – Beispielhafter Process Flow mit Fluxicon Disco (www.fluxicon.com)

Das durch die Datenaufbereitung erstellte Prozessprotokoll wird in eine Datenvisualisierungssoftware geladen, die dieses Protokoll über die Vorgangsnummern und Zeitstempel in einem grafischen Prozessnetzwerk darstellt. Die Prozessflüsse werden also nicht modelliert, wie es bei den Soll-Prozessen der Fall ist, sondern es „sprechen“ die IT-Systeme.

Die Prozessflüsse werden visuell dargestellt und statistisch ausgewertet, so dass konkrete Aussagen über die im Hinblick auf Compliance relevante Prozess-Performance und -Risiken getroffen werden können.

6 Abweichung von Soll-Prozessen

Die Möglichkeit des intuitiven Filterns der Prozessdarstellung ermöglicht auch die gezielte Analyse von Ist-Prozessen, die von den Soll-Prozessverläufen abweichen.

Die Abweichung der Ist-Prozesse von den Soll-Prozessen wird in der Regel selbst von IT-affinen Führungskräften unterschätzt – mit Process Analytics lassen sich nun alle Abweichungen und die generelle Prozesskomplexität auf ihren Daten basierend untersuchen.

6 Erkennung von Prozesskontrollverletzungen

Die Implementierung von Prozesskontrollen sind Bestandteil eines professionellen Internen Kontrollsystems (IKS), die tatsächliche Einhaltung dieser Kontrollen in der Praxis ist jedoch häufig nicht untersucht oder belegt. Process Analytics ermöglicht hier die Umgehung des Vier-Augen-Prinzips bzw. die Aufdeckung von Funktionstrennungskonflikten. Zudem werden auch die bewusste Außerkraftsetzung von internen Kontrollmechanismen durch leitende Mitarbeiter oder die falsche Konfiguration der IT-Systeme deutlich sichtbar.

7 Erkennung von bisher unbekannten Verhaltensmustern

Nach der Prüfung der Einhaltung bestehender Kontrollen, also bekannter Muster, wird Process Analytics weiterhin zur Neuerkennung von bislang unbekannten Mustern in Prozessnetzwerken, die auf Risiken oder gar konkrete Betrugsfälle hindeuten und aufgrund ihrer bisherigen Unbekanntheit von keiner Kontrolle erfasst werden, genutzt. Insbesondere durch die – wie bereits erwähnt – häufig unterschätzte Komplexität der alltäglichen Prozessverflechtung fallen erst durch diese Analyse Fraud-Szenarien auf, die vorher nicht denkbar gewesen wären. An dieser Stelle erweitert sich die Vorgehensweise des Process Mining um die Methoden des maschinellen Lernens (Machine Learning), typischerweise unter Einsatz von Clustering, Klassifikation und Regression.

8 Berichterstattung – auch in Echtzeit möglich

Als hocheffektive Audit-Analyse ist Process Analytics bereits als iterative Prüfung in Abständen von drei bis zwölf Monaten ausreichend. Nach der erstmaligen Durchführung werden bereits Compliance-Verstöße, schwache oder gar unwirksame Kontrollen und gegebenenfalls sogar Betrugsfälle zuverlässig erkannt. Die Erkenntnisse können im Nachgang dazu genutzt werden, um die Schwachstellen abzustellen. Eine weitere Durchführung der Analyse nach einer Karenzzeit ermöglicht dann die Beurteilung der Wirksamkeit getroffener Maßnahmen.

In einigen Anwendungsszenarien ist auch die nahtlose Anbindung der Prozessanalyse mit visuellem Dashboard an die IT-Systemlandschaft zu empfehlen, so dass Prozesse in nahezu Echtzeit abgebildet werden können. Diese Anbindung kann zudem um Benachrichtigungssysteme ergänzt werden, so dass Entscheider und Revisoren via SMS oder E-Mail automatisiert über aktuellste Prozessverstöße informiert werden. Process Analytics wird somit zum Realtime Analytics.

Fazit

Process Analytics ist im Zuge der Digitalisieurng die hocheffektive Methodik aus dem Bereich der Big Data Analyse zur Aufdeckung Compliance-relevanter Tatbestände im gesamten Unternehmensbereich und auch eine visuelle Unterstützung bei der forensischen Datenanalyse.

 

Redaktion

Weiterbildungsangebote zu Data Science und R an der TU Dortmund

/in , , , , , , /by

Anzeige: Interessante Weiterbildungsangebote zu Data Science und Programmiersprache R an der TU Dortmund

Das Zertifikatsstudium „Data Science and Big Data“ an der Technischen Universität Dortmund startet im Januar 2018 in den zweiten Durchgang. Aufbauend auf datenwissenschaftlichen Erkenntnissen steht die praxisnahe Umsetzung eines eigenen Big-Data Projekts im Fokus der Weiterbildung. Mithilfe von Methoden aus den Disziplinen Statistik, Informatik und Journalistik erwerben die Teilnehmerinnen und Teilnehmer wertvolle Kompetenzen in den Bereichen Datenanalyse, Datenmanagement und Ergebnisdarstellung. Die Bewerbungsphase läuft noch bis zum 8. November 2017. Mehr Infos finden Sie unter: https://data-science-blog.com/tu-dortmund-berufsbegleitendes-zertifikatsstudium/

Ganz neu ist ein weiteres Tagesseminarangebot im Bereich Data Science ab Frühjahr 2018: Dortmunder R-Kurse. Hier vermitteln Experten in Kursen für Anfänger und Fortgeschrittene die praktische Anwendung der Statistiksoftware R. Näheres dazu gibt es hier: www.zhb.tu-dortmund.de/r-kurse

 

Benjamin Aunkofer

Data Science Knowledge Stack – Was ein Data Scientist können muss

/in , , , , , , , /by

Was muss ein Data Scientist können? Diese Frage wurde bereits häufig gestellt und auch häufig beantwortet. In der Tat ist man sich mittlerweile recht einig darüber, welche Aufgaben ein Data Scientist für Aufgaben übernehmen kann und welche Fähigkeiten dafür notwendig sind. Ich möchte versuchen, diesen Konsens in eine Grafik zu bringen: Ein Schichten-Modell, ähnlich des OSI-Layer-Modells (welches übrigens auch jeder Data Scientist kennen sollte).
Ich gebe Einführungs-Seminare in Data Science für Kaufleute und Ingenieure und bei der Erläuterung, was wir in den Seminaren gemeinsam theoretisch und mit praxisnahen Übungen erarbeiten müssen, bin ich auf die Idee für dieses Schichten-Modell gekommen. Denn bei meinen Seminaren fängt es mit der Problemstellung bereits an, ich gebe nämlich Seminare für Data Science für Business Analytics mit Python. Also nicht beispielsweise für medizinische Analysen und auch nicht mit R oder Julia. Ich vermittle also nicht irgendein Data Science, sondern eine ganz bestimmte Richtung.

Ein Data Scientist muss bei jedem Data Science Vorhaben Probleme auf unterschiedlichsten Ebenen bewältigen, beispielsweise klappt der Datenzugriff nicht wie geplant oder die Daten haben eine andere Struktur als erwartet. Ein Data Scientist kann Stunden damit verbringen, seinen eigenen Quellcode zu debuggen oder sich in neue Data Science Pakete für seine ausgewählte Programmiersprache einzuarbeiten. Auch müssen die richtigen Algorithmen zur Datenauswertung ausgewählt, richtig parametrisiert und getestet werden, manchmal stellt sich dabei heraus, dass die ausgewählten Methoden nicht die optimalen waren. Letztendlich soll ein Mehrwert für den Fachbereich generiert werden und auch auf dieser Ebene wird ein Data Scientist vor besondere Herausforderungen gestellt.

english-flagRead this article in English:
“Data Science Knowledge Stack – Abstraction of the Data Scientist Skillset”

Data Science Knowledge Stack

Mit dem Data Science Knowledge Stack möchte ich einen strukturierten Einblick in die Aufgaben und Herausforderungen eines Data Scientists geben. Die Schichten des Stapels stellen zudem einen bidirektionalen Fluss dar, der von oben nach unten und von unten nach oben verläuft, denn Data Science als Disziplin ist ebenfalls bidirektional: Wir versuchen gestellte Fragen mit Daten zu beantworten oder wir schauen, welche Potenziale in den Daten liegen, um bisher nicht gestellte Fragen zu beantworten.

Der Data Science Knowledge Stack besteht aus sechs Schichten:

Database Technology Knowledge

Ein Data Scientist arbeitet im Schwerpunkt mit Daten und die liegen selten direkt in einer CSV-Datei strukturiert vor, sondern in der Regel in einer oder in mehreren Datenbanken, die ihren eigenen Regeln unterliegen. Insbesondere Geschäftsdaten, beispielsweise aus dem ERP- oder CRM-System, liegen in relationalen Datenbanken vor, oftmals von Microsoft, Oracle, SAP oder eine Open-Source-Alternative. Ein guter Data Scientist beherrscht nicht nur die Structured Query Language (SQL), sondern ist sich auch der Bedeutung relationaler Beziehungen bewusst, kennt also auch das Prinzip der Normalisierung.

Andere Arten von Datenbanken, sogenannte NoSQL-Datenbanken (Not only SQL)  beruhen auf Dateiformaten, einer Spalten- oder einer Graphenorientiertheit, wie beispielsweise MongoDB, Cassandra oder GraphDB. Einige dieser Datenbanken verwenden zum Datenzugriff eigene Programmiersprachen (z. B. JavaScript bei MongoDB oder die graphenorientierte Datenbank Neo4J hat eine eigene Sprache namens Cypher). Manche dieser Datenbanken bieten einen alternativen Zugriff über SQL (z. B. Hive für Hadoop).

Ein Data Scientist muss mit unterschiedlichen Datenbanksystemen zurechtkommen und mindestens SQL – den Quasi-Standard für Datenverarbeitung – sehr gut beherrschen.

Data Access & Transformation Knowledge

Liegen Daten in einer Datenbank vor, können Data Scientists einfache (und auch nicht so einfache) Analysen bereits direkt auf der Datenbank ausführen. Doch wie bekommen wir die Daten in unsere speziellen Analyse-Tools? Hierfür muss ein Data Scientist wissen, wie Daten aus der Datenbank exportiert werden können. Für einmalige Aktionen kann ein Export als CSV-Datei reichen, doch welche Trennzeichen und Textqualifier können verwendet werden? Eventuell ist der Export zu groß, so dass die Datei gesplittet werden muss.
Soll eine direkte und synchrone Datenanbindung zwischen dem Analyse-Tool und der Datenbank bestehen, kommen Schnittstellen wie REST, ODBC oder JDBC ins Spiel. Manchmal muss auch eine Socket-Verbindung hergestellt werden und das Prinzip einer Client-Server-Architektur sollte bekannt sein. Auch mit synchronen und asynchronen Verschlüsselungsverfahren sollte ein Data Scientist vertraut sein, denn nicht selten wird mit vertraulichen Daten gearbeitet und ein Mindeststandard an Sicherheit ist zumindest bei geschäftlichen Anwendungen stets einzuhalten.

Viele Daten liegen nicht strukturiert in einer Datenbank vor, sondern sind sogenannte unstrukturierte oder semi-strukturierte Daten aus Dokumenten oder aus Internetquellen. Auch hier haben wir es mit Schnittstellen zutun, ein häufiger Einstieg für Data Scientists stellt beispielsweise die Twitter-API dar. Manchmal wollen wir Daten in nahezu Echtzeit streamen, beispielsweise Maschinendaten. Dies kann recht anspruchsvoll sein, so das Data Streaming beinahe eine eigene Disziplin darstellt, mit der ein Data Scientist schnell in Berührung kommen kann.

Programming Language Knowledge

Programmiersprachen sind für Data Scientists Werkzeuge, um Daten zu verarbeiten und die Verarbeitung zu automatisieren. Data Scientists sind in der Regel keine richtigen Software-Entwickler, sie müssen sich nicht um Software-Sicherheit oder -Ergonomie kümmern. Ein gewisses Basiswissen über Software-Architekturen hilft jedoch oftmals, denn immerhin sollen manche Data Science Programme in eine IT-Landschaft integriert werden. Unverzichtbar ist hingegen das Verständnis für objektorientierte Programmierung und die gute Kenntnis der Syntax der ausgewählten Programmiersprachen, zumal nicht jede Programmiersprache für alle Vorhaben die sinnvollste ist.

Auf dem Level der Programmiersprache gibt es beim Arbeitsalltag eines Data Scientists bereits viele Fallstricke, die in der Programmiersprache selbst begründet sind, denn jede hat ihre eigenen Tücken und Details entscheiden darüber, ob eine Analyse richtig oder falsch abläuft: Beispielsweise ob Datenobjekte als Kopie oder als Referenz übergeben oder wie NULL-Werte behandelt werden.

Data Science Tool & Library Knowledge

Hat ein Data Scientist seine Daten erstmal in sein favorisiertes Tool geladen, beispielsweise in eines von IBM, SAS oder in eine Open-Source-Alternative wie Octave, fängt seine Kernarbeit gerade erst an. Diese Tools sind allerdings eher nicht selbsterklärend und auch deshalb gibt es ein vielfältiges Zertifizierungsangebot für diverse Data Science Tools. Viele (wenn nicht die meisten) Data Scientists arbeiten überwiegend direkt mit einer Programmiersprache, doch reicht diese alleine nicht aus, um effektiv statistische Datenanalysen oder Machine Learning zu betreiben: Wir verwenden Data Science Bibliotheken, also Pakete (Packages), die uns Datenstrukturen und Methoden als Vorgabe bereitstellen und die Programmiersprache somit erweitern, damit allerdings oftmals auch neue Tücken erzeugen. Eine solche Bibliothek, beispielsweise Scikit-Learn für Python, ist eine in der Programmiersprache umgesetzte Methodensammlung und somit ein Data Science Tool. Die Verwendung derartiger Bibliotheken will jedoch gelernt sein und erfordert für die zuverlässige Anwendung daher Einarbeitung und Praxiserfahrung.

Geht es um Big Data Analytics, also die Analyse von besonders großen Daten, betreten wir das Feld von Distributed Computing (Verteiltes Rechnen). Tools (bzw. Frameworks) wie Apache Hadoop, Apache Spark oder Apache Flink ermöglichen es, Daten zeitlich parallel auf mehren Servern zu verarbeiten und auszuwerten. Auch stellen diese Tools wiederum eigene Bibliotheken bereit, für Machine Learning z. B. Mahout, MLlib und FlinkML.

Data Science Method Knowledge

Ein Data Scientist ist nicht einfach nur ein Bediener von Tools, sondern er nutzt die Tools, um seine Analyse-Methoden auf Daten anzuwenden, die er für die festgelegten Ziele ausgewählt hat. Diese Analyse-Methoden sind beispielweise Auswertungen der beschreibenden Statistik, Schätzverfahren oder Hypothesen-Tests. Etwas mathematischer sind Verfahren des maschinellen Lernens zum Data Mining, beispielsweise Clusterung oder Dimensionsreduktion oder mehr in Richtung automatisierter Entscheidungsfindung durch Klassifikation oder Regression.

Maschinelle Lernverfahren funktionieren in der Regel nicht auf Anhieb, sie müssen unter Einsatz von Optimierungsverfahren, wie der Gradientenmethode, verbessert werden. Ein Data Scientist muss Unter- und Überanpassung erkennen können und er muss beweisen, dass die Vorhersageergebnisse für den geplanten Einsatz akkurat genug sind.

Spezielle Anwendungen bedingen spezielles Wissen, was beispielsweise für die Themengebiete der Bilderkennung (Visual Computing) oder der Verarbeitung von menschlicher Sprache (Natural Language Processiong) zutrifft. Spätestens an dieser Stelle öffnen wir die Tür zum Deep Learning.

Fachexpertise

Data Science ist kein Selbstzweck, sondern eine Disziplin, die Fragen aus anderen Fachgebieten mit Daten beantworten möchte. Aus diesem Grund ist Data Science so vielfältig. Betriebswirtschaftler brauchen Data Scientists, um Finanztransaktionen zu analysieren, beispielsweise um Betrugsszenarien zu erkennen oder um die Kundenbedürfnisse besser zu verstehen oder aber, um Lieferketten zu optimieren. Naturwissenschaftler wie Geologen, Biologen oder Experimental-Physiker nutzen ebenfalls Data Science, um ihre Beobachtungen mit dem Ziel der Erkenntnisgewinnung zu machen. Ingenieure möchten die Situation und Zusammenhänge von Maschinenanlagen oder Fahrzeugen besser verstehen und Mediziner interessieren sich für die bessere Diagnostik und Medikation bei ihren Patienten.

Damit ein Data Scientist einen bestimmten Fachbereich mit seinem Wissen über Daten, Tools und Analyse-Methoden ergebnisorientiert unterstützen kann, benötigt er selbst ein Mindestmaß an der entsprechenden Fachexpertise. Wer Analysen für Kaufleute, Ingenieure, Naturwissenschaftler, Mediziner, Juristen oder andere Interessenten machen möchte, muss eben jene Leute auch fachlich verstehen können.

Engere Data Science Definition

Während die Data Science Pioniere längst hochgradig spezialisierte Teams aufgebaut haben, suchen beispielsweise kleinere Unternehmen eher den Data Science Allrounder, der vom Zugriff auf die Datenbank bis hin zur Implementierung der analytischen Anwendung das volle Aufgabenspektrum unter Abstrichen beim Spezialwissen übernehmen kann. Unternehmen mit spezialisierten Daten-Experten unterscheiden jedoch längst in Data Scientists, Data Engineers und Business Analysts. Die Definition für Data Science und die Abgrenzung der Fähigkeiten, die ein Data Scientist haben sollte, schwankt daher zwischen der breiteren und einer engeren Abgrenzung.

Die engere Betrachtung sieht vor, dass ein Data Engineer die Datenbereitstellung übernimmt, der Data Scientist diese in seine Tools lädt und gemeinsam mit den Kollegen aus dem Fachbereich die Datenanalyse betreibt. Demnach bräuchte ein Data Scientist kein Wissen über Datenbanken oder APIs und auch die Fachexpertise wäre nicht notwendig…

In der beruflichen Praxis sieht Data Science meiner Erfahrung nach so nicht aus, das Aufgabenspektrum umfasst mehr als nur den Kernbereich. Dieser Irrtum entsteht in Data Science Kursen und auch in Seminaren – würde ich nicht oft genug auf das Gesamtbild hinweisen. In Kursen und Seminaren, die Data Science als Disziplin vermitteln wollen, wird sich selbstverständlich auf den Kernbereich fokussiert: Programmierung, Tools und Methoden aus der Mathematik & Statistik.

Benjamin Aunkofer

Entscheidungsbaum-Algorithmus ID3

/in , , , , , , /by

Dieser Artikel ist Teil 2 von 4 der Artikelserie Maschinelles Lernen mit Entscheidungsbaumverfahren.

Entscheidungsbäume sind den Ingenieuren bestens bekannt, um Produkte hierarchisch zu zerlegen und um Verfahrensanweisungen zu erstellen. Die Data Scientists möchten ebenfalls Verfahrensanweisungen erstellen, jedoch automatisiert aus den Daten heraus. Auf diese Weise angewendet, sind Entscheidungsbäume eine Form des maschinellen Lernens: Die Maschine soll selbst einen Weg finden, um ein Objekt einer Klasse zuzuordnen.

Der ID3-Algorithmus

Den ID3-Algorithmus zu verstehen lohnt sich, denn er ist die Grundlage für viele weitere, auf ihn aufbauende Algorithmen. Er ist mit seiner iterativen und rekursiven Vorgehensweise auch recht leicht zu verstehen, er darf nur wiederum nicht in seiner Wirkung unterschätzt werden. Die Vorgehensweise kann in drei wesentlichen Schritten zerlegt werden, wobei der erste Schritt die eigentliche Wirkung (mit allen Vor- und Nachteilen) entfaltet:

  1. Schritt: Auswählen des Attributes mit dem höchsten Informationsgewinn
    Betrachte alle Attribute (Merkmale) des Datensatzes und bestimme, welches Attribut die Daten am besten klassifiziert.
  2. Schritt: Anlegen eines Knotenpunktes mit dem Attribut
    Sollten die Ergebnisse unter diesem Knoten eindeutig sein (1 unique value), speichere es in diesem Knotenpunkt und springe zurück.
  3. Schritt: Rekursive Fortführung dieses Prozesses
    Andernfalls zerlege die Daten jedem Attribut entsprechend in n Untermengens (subsets), und wiederhole diese Schritte für jede der Teilmengen.

Der Informationsgewinn (Information Gain) – und wie man ihn berechnet


Der Informationsgewinn eines Attributes (A) im Sinne des ID3-Algorithmus ist die Differenz aus der Entropie (E(S)) (siehe Teil 1 der Artikelserie: Entropie, ein Maß für die Unreinheit in Daten) des gesamten Datensatzes (S) und der Summe aus den gewichteten Entropien des Attributes für jeden einzelnen Wert (Value i), der im Attribut vorkommt:
IG(S, A) = E(S) - \sum_{i=1}^n \frac{\bigl|S_i\bigl|}{\bigl|S\bigl|} \cdot E(S_i)

Wie die Berechnung des Informationsgewinnes funktioniert, wird Teil 3 dieser Artikel-Reihe (erscheint in Kürze) zeigen.

Die Vorzüge des ID3-Algorithmus – und die Nachteile

Der Algorithmus ist die Grundlage für viele weitere Algorithmen. In seiner Einfachheit bringt er gewisse Vorteile – die ihn vermutlich zum verbreitesten Entscheidungsbaum-Algorithmus machen – mit sich, aber hat auch eine Reihe von Nachteilen, die bedacht werden sollten.

Vorteile Nachteile
  • leicht verständlich und somit schnell implementiert
  • stellt eine gute Basis für Random Forests dar
  • alle Attribute spielen eine Rolle, der Baum wird aber tendenziell klein, da der Informationsgewinn die Reihenfolge vorgibt
  • funktioniert (mit Anpassungen) auch für Mehrfachklassifikation
  • aus der Reihenfolge durch den Informationsgewinn entsteht nicht unbedingt der beste bzw. kleinste Baum unter allen Möglichkeiten. Es ist ein Greedy-Algorithmus und somit “kurzsichtig”
  • die Suche nach Entscheidungsregeln ist daher auch nicht vollständig/umfassend
  • da der Baum via ID3 solange weiterwachsen soll, bis die Daten so eindeutig wie möglich erklärt sind, wird Overfitting geradezu provoziert

Overfitting (Überanpassung) beachten und vermeiden

Aus Daten heraus generierte Entscheidungsbäume neigen zur Überanpassung. Das bedeutet, dass sich die Bäume den Trainingsdaten soweit anpassen können, dass sie auf diese perfekt passen, jedoch keine oder nur noch einen unzureichende generalisierende Beschreibung mehr haben. Neue Daten, die eine höhere Vielfältigkeit als die Trainingsdaten haben können, werden dann nicht mehr unter einer angemessenen Fehlerquote korrekt klassifiziert.

Vorsicht vor Key-Spalten!

Einige Attribute erzwingen eine Überanpassung regelrecht: Wenn beispielsweise ein Attribut wie „Kunden-ID“ (eindeutige Nummer pro Kunde) einbezogen wird, haben wir – bezogen auf das Klassifikationsergebnis – für jeden einzelnen Wert in dem Attribut eine Entropie von 0 zu erwarten, denn jeder ID beschreibt einen eindeutigen Fall (Kunde, Kundengruppe etc.). Daraus folgt, dass der Informationsgewinn für dieses Attribut maximal wird. Hier würde der Baum eine enorme Breite erhalten, die nicht hilfreich wäre, denn jeder Wert (IDs) bekäme einen einzelnen Ast im Baum, der zu einem eindeutigen Ergebnis führt. Auf neue Daten (neue Kundennummern) ist der Baum nicht anwendbar, denn er stellt keine generalisierende Beschreibung mehr dar, sondern ist nur noch ein Abbild der Trainingsdaten.

Prunning – Den Baum nachträglich kürzen

Besonders große Bäume sind keine guten Bäume und ein Zeichen für Überanpassung. Eine Möglichkeit zur Verkleinerung ist das erneute Durchrechnen der Informationsgewinne und das kürzen von Verzweigungen (Verallgemeinerung), sollte der Informationsgewinn zu gering sein. Oftmals wird hierfür nicht die Entropie oder der Gini-Koeffizient, sondern der Klassifikationsfehler als Maß für die Unreinheit verwendet.

Random Forests als Overfitting-Allheilmittel

Bei Random Forests (eine Form des Ensemble Learning) handelt es sich um eine Gemeinschaftsentscheidung der Klassenzugehörigkeit über mehrere Entscheidungsbäume. Diese Art des “demokratischen” Machine Learnings wird auch Ensemble Learning genannt. Werden mehrere Entscheidungsbäume unterschiedlicher Strukturierung zur gemeinsamen Klassifikation verwendet, wird die Wirkung des Overfittings einzelner Bäume in der Regel reduziert.

Benjamin Aunkofer

Überwachtes vs unüberwachtes maschinelles Lernen

/in , , , , , , , /by

Dies ist Artikel 1 von 4 aus der Artikelserie – Was ist eigentlich Machine Learning?

Der Unterschied zwischen überwachten und unüberwachtem Lernen ist für Einsteiger in das Gebiet des maschinellen Lernens recht verwirrend. Ich halte die Bezeichnung “überwacht” und “unüberwacht” auch gar nicht für besonders gut, denn eigentlich wird jeder Algorithmus (zumindest anfangs) vom Menschen überwacht. Es sollte besser in trainierte und untrainierte Verfahren unterschieden werden, die nämlich völlig unterschiedliche Zwecke bedienen sollen:

Während nämlich überwachte maschinelle Lernverfahren über eine Trainingsphase regelrecht auf ein (!) Problem abgerichtet werden und dann produktiv als Assistenzsystem (bis hin zum Automated Decision Making) funktionieren sollen, sind demgegenüber unüberwachte maschinelle Lernverfahren eine Methodik, um unübersichtlich viele Zeilen und Spalten von folglich sehr großen Datenbeständen für den Menschen leichter interpretierbar machen zu können (was nicht immer funktioniert).

Trainiere dir deinen Algorithmus mit überwachtem maschinellen Lernen

Wenn ein Modell anhand von mit dem Ergebnis (z. B. Klassifikationsgruppe) gekennzeichneter Trainingsdaten erlernt werden soll, handelt es sich um überwachtes Lernen. Die richtige Antwort muss während der Trainingsphase also vorliegen und der Algorithmus muss die Lücke zwischen dem Input (Eingabewerte) und dem Output (das vorgeschriebene Ergebnis) füllen.

Die Überwachung bezieht sich dabei nur auf die Trainingsdaten! Im produktiven Lauf wird grundsätzlich nicht überwacht (und das Lernen könnte sich auf neue Daten in eine ganz andere Richtung entwickeln, als dies mit den Trainingsdaten der Fall war). Die Trainingsdaten

Eine besondere Form des überwachten Lernens ist die des bestärkenden Lernens. Bestärkendes Lernen kommt stets dann zum Einsatz, wenn ein Endergebnis noch gar nicht bestimmbar ist, jedoch der Trend hin zum Erfolg oder Misserfolg erkennbar wird (beispielsweise im Spielverlauf – AlphaGo von Google Deepmind soll bestärkend trainiert worden sein). In der Trainingsphase werden beim bestärkenden Lernen die korrekten Ergebnisse also nicht zur Verfügung gestellt, jedoch wird jedes Ergebnis bewertet, ob dieses (wahrscheinlich) in die richtige oder falsche Richtung geht (Annäherungslernen).

Zu den überwachten Lernverfahren zählen alle Verfahren zur Regression oder Klassifikation, beispielsweise mit Algorithmen wir k-nearest-Neighbour, Random Forest, künstliche neuronale Netze, Support Vector Machines oder auch Verfahren der Dimensionsreduktion wie die lineare Diskriminanzanalyse.

Mit unüberwachtem Lernen verborgene Strukturen identifizieren

Beim unüberwachten Lernen haben wir es mit nicht mit gekennzeichneten Daten zu tun, die möglichen Antworten/Ergebnisse sind uns gänzlich unbekannt. Folglich können wir den Algorithmus nicht trainieren, indem wir ihm die Ergebnisse, auf die er kommen soll, im Rahmen einer Trainingsphase vorgeben (überwachtes Lernen), sondern wir nutzen Algorithmen, die die Struktur der Daten erkunden und für uns Menschen sinnvolle Informationen aus Ihnen bilden (oder auch nicht – denn häufig bleibt es beim Versuch, denn der Erfolg ist nicht garantiert!).Unüberwachte Verfahren des maschinellen Lernens dienen dem Data Mining, also der Erkennung von Inhalten in Daten anhand von sichtbar werdenden Strukturen. Die Verfahren müssen nicht unbedingt mit Datenvisualisierung arbeiten, oft ist das aber der Fall, denn erst die visuellen Strukturen ermöglichen unseren menschlichen Gehirnen die Daten in einen Kontext zu bringen. Mir sind zwei Kategorien des unüberwachten Lernens bekannt, zum einem das Clustering, welches im Grunde ein unüberwachtes Klassifikationsverfahren darstellt, und zum anderen die Dimensionsreduktion PCA (Hauptkomponentenanalyse). Es gibt allerdings noch andere Verfahren, die mir weniger vertraut sind, beispielsweise unüberwacht lernende künstliche neuronale Netze, die Rauschen lernen, um Daten von eben diesem Rauschen zu befreien.

Anne Rozinat & Christian W. Günther

Establish a Collaborative Culture – Process Mining Rule 4 of 4

/in , , , , , , , , , /by

This is article no. 4 of the four-part article series Privacy, Security and Ethics in Process Mining.

Read this article in German:
“Datenschutz, Sicherheit und Ethik beim Process Mining – Regel 4 von 4“

Perhaps the most important ingredient in creating a responsible process mining environment is to establish a collaborative culture within your organization. Process mining can make the flaws in your processes very transparent, much more transparent than some people may be comfortable with. Therefore, you should include change management professionals, for example, Lean practitioners who know how to encourage people to tell each other “the truth”, in your team.

Furthermore, be careful how you communicate the goals of your process mining project and involve relevant stakeholders in a way that ensures their perspective is heard. The goal is to create an atmosphere, where people are not blamed for their mistakes (which only leads to them hiding what they do and working against you) but where everyone is on board with the goals of the project and where the analysis and process improvement is a joint effort.

Do:

  • Make sure that you verify the data quality before going into the data analysis, ideally by involving a domain expert already in the data validation step. This way, you can build trust among the process managers that the data reflects what is actually happening and ensure that you have the right understanding of what the data represents.
  • Work in an iterative way and present your findings as a starting point for discussion in each iteration. Give people the chance to explain why certain things are happening and let them ask additional questions (to be picked up in the next iteration). This will help to improve the quality and relevance of your analysis as well as increase the buy-in of the process stakeholders in the final results of the project.

Don’t:

  • Jump to conclusions. You can never assume that you know everything about the process. For example, slower teams may be handling the difficult cases, people may deviate from the process for good reasons, and you may not see everything in the data (for example, there might be steps that are performed outside of the system). By consistently using your observations as a starting point for discussion, and by allowing people to join in the interpretation, you can start building trust and the collaborative culture that process mining needs to thrive.
  • Force any conclusions that you expect, or would like to have, by misrepresenting the data (or by stating things that are not actually supported by the data). Instead, keep track of the steps that you have taken in the data preparation and in your process mining analysis. If there are any doubts about the validity or questions about the basis of your analysis, you can always go back and show, for example, which filters have been applied to the data to come to the particular process view that you are presenting.
Benjamin Aunkofer

Was ist eigentlich Machine Learning? Artikelserie

/in , , , , , , , /by

Machine Learning ist Technik und Mythos zugleich. Nachfolgend der Versuch einer verständlichen Erklärung, mit folgenden Artikeln:

Machine Learning ist nicht neu, aber innovativ!

Machine Learning oder maschinelles Lernen ist eine Bezeichnung, die dank industrieller Trends wie der Industrie 4.0, Smart Grid oder dem autonomen Fahrzeug zur neuen Blüte verhilft. Machine Learning ist nichts Neues und die Algorithmen sind teilweise mehrere Jahrzehnte alt. Dennoch ist Machine Learning ein Innovationsinstrument, denn während früher nur abstrakte Anwendungen, mit vornehmlich wissenschaftlichen Hintergrund, auf maschinellem Lernen setzten, finden entsprechende Algorithmen Einzug in alltägliche industrielle bzw. geschäftliche, medizinische und gesellschaftsorientierte Anwendungen. Machine Learning erhöht demnach sowohl unseren Lebensstandard als auch unsere Lebenserwartung!

Maschinelles Lernen vs künstliche Intelligenz

Künstliche Intelligenz (Artificial Intelligence) ist eine Bezeichnung, die in der Wissenschaft immer noch viel diskutiert wird. Wo beginnt künstliche Intelligenz, wann entsteht natürliche Intelligenz und was ist Intelligenz überhaupt? Wenn diese Wortkombination künstliche Intelligenz fällt, denken die meisten Zuhörer an Filme wie Terminator von James Cameron oder AI von Steven Spielberg. Diese Filme wecken Erwartungen (und Ängste), denen wir mir unseren selbstlernenden Systemen noch lange nicht gerecht werden können. Von künstlicher Intelligenz sollte als mit Bedacht gesprochen werden.

Maschinelles Lernen ist Teilgebiet der künstlichen Intelligenz und eine Sammlung von mathematischen Verfahren zur Mustererkennung, die entweder über generelle Prinzipien (das Finden von Gemeinsamkeiten oder relativen Abgrenzungen) funktioniert [unüberwachtes Lernen] oder durch das Bilden eines Algorithmus als Bindeglied zwischen Input und gewünschten Output aus Trainingsdaten heraus.

Machine Learning vs Deep Learning

Deep Learning ist eine spezielle Form des maschinellen Lernens, die vermutlich in den kommenden Jahren zum Standard werden wird. Gemeint sind damit künstliche neuronale Netze, manchmal auch verschachtelte “herkömmliche” Verfahren, die zum einen mehrere Ebenen bilden (verborgene Schichten eines neuronalen Netzes) zum anderen viel komplexere Zusammenhänge erlernen können, was den Begriff Deep Learning rechtfertigt.

Machine Learning vs Data Mining

Data Mining bezeichnet die Erkenntnisgewinnung aus bisher nicht oder nicht hinreichend erforschter Daten. Unüberwachte Verfahren des maschinellen Lernens, dazu gehören einige Verfahren aus dem Clustering und der Dimensionsreduktion, dienen explizit dem Zweck des Data Minings. Es sind Verfahren, die uns Menschen dabei helfen, vielfältige und große Datenmengen leichter interpretieren zu können. Machine Learning ermöglicht jedoch noch weit mehr als Data Mining.

Scikit-Learn Machine Learning Roadmap

Darstellung der vier Gebiete des Machine Learning: Die scikit-learn-Roadmap. Die Darstellung ist nicht vollständig, sondern umfasst nur die in scikit-learn implementierten Verfahren. Das Original-Bild ist interaktiv und zu finden auf scikit-learn.org

Conny Dethloff

Geht mit Künstlicher Intelligenz nur „Malen nach Zahlen“?

/in , , , , , , , , , /by

Mit diesem Beitrag möchte ich darlegen, welche Grenzen uns in komplexen Umfeldern im Kontext Steuerung und Regelung auferlegt sind. Auf dieser Basis strebe ich dann nachgelagert eine Differenzierung in Bezug des Einsatzes von Data Science und Big Data, ab sofort mit Big Data Analytics bezeichnet, an. Aus meiner Sicht wird oft zu unreflektiert über Data Science und Künstliche Intelligenz diskutiert, was nicht zuletzt die Angst vor Maschinen schürt.

Basis meiner Ausführungen im ersten Part meines Beitrages ist der Kategorienfehler, der von uns Menschen immer wieder in Bezug auf Kompliziertheit und Komplexität vollführt wird. Deshalb werde ich am Anfang einige Worte über Kompliziertheit und Komplexität verlieren und dabei vor allem auf die markanten Unterschiede eingehen.

Kompliziertheit und Komplexität – der Versuch einer Versöhnung

Ich benutze oft die Begriffe „tot“ und „lebendig“ im Kontext von Kompliziertheit und Komplexität. Themenstellungen in „lebendigen“ Kontexten können niemals kompliziert sein. Sie sind immer komplex. Themenstellungen in „toten“ Kontexten sind stets kompliziert. Das möchte ich am Beispiel eines Uhrmachers erläutern, um zu verdeutlichen, dass auch Menschen in „toten“ Kontexten involviert sein können, obwohl sie selber lebendig sind. Deshalb die Begriffe „tot“ und „lebendig“ auch in Anführungszeichen.

Ein Uhrmacher baut eine Uhr zusammen. Dafür gibt es ein ganz klar vorgegebenes Rezept, welches vielleicht 300 Schritte beinhaltet, die in einer ganz bestimmten Reihenfolge abgearbeitet werden müssen. Werden diese Schritte befolgt, wird definitiv eine funktionierende Uhr heraus kommen. Ist der Uhrmacher geübt, hat er also genügend praktisches Wissen, ist diese Aufgabe für ihn einfach. Für mich als Ungelernten wird diese Übung schwierig sein, niemals komplex, denn ich kann ja einen Plan befolgen. Mit Übung bin ich vielleicht irgendwann so weit, dass ich diese Uhr zusammen gesetzt bekomme. Der Bauplan ist fix und ändert sich nicht. Man spricht hier von Monokontexturalität. Solche Tätigkeiten könnte man auch von Maschinen ausführen lassen, da klar definierte Abfolgen von Schritten programmierbar sind.

Nun stellen wir uns aber mal vor, dass eine Schraube fehlt. Ein Zahnrad kann nicht befestigt werden. Hier würde die Maschine einen Fehler melden, weil jetzt der Kontext verlassen wird. Das Fehlen der Schraube ist nicht Bestandteil des Kontextes, da es nicht Bestandteil des Planes und damit auch nicht Bestandteil des Programmcodes ist. Die Maschine weiß deshalb nicht, was zu tun ist. Der Uhrmacher ist in der Lage den Kontext zu wechseln. Er könnte nach anderen Möglichkeiten der Befestigung suchen oder theoretisch probieren, ob die Uhr auch ohne Zahnrad funktioniert oder er könnte ganz einfach eine Schraube bestellen und später den Vorgang fortsetzen. Der Uhrmacher kann polykontextural denken und handeln. In diesem Fall wird dann der komplizierte Kontext ein komplexer. Der Bauplan ist nicht mehr gültig, denn Bestellung einer Schraube war in diesem nicht enthalten. Deshalb meldet die Maschine einen Fehler. Der Bestellvorgang müsste von einem Menschen in Form von Programmcode voraus gedacht werden, so dass die Maschine diesen anstoßen könnte. Damit wäre diese Option dann wieder Bestandteil des monokontexturalen Bereiches, in dem die Maschine agieren kann.

Kommen wir in diesem Zusammenhang zum Messen und Wahrnehmen. Maschinen können messen. Messen passiert in monokontexturalen Umgebungen. Die Maschine kann messen, ob die Schraube festgezogen ist, die das Zahnrad hält: Die Schraube ist „fest“ oder „lose“. Im Falle des Fehlens der Schraube verlässt man die Ebene des Messens und geht in die Ebene der Wahrnehmung über. Die Maschine kann nicht wahrnehmen, der Uhrmacher schon. Beim Wahrnehmen muss man den Kontext erst einmal bestimmen, da dieser nicht per se gegeben sein kann. „Die Schraube fehlt“ setzt die Maschine in den Kontext „ENTWEDER fest ODER lose“ und dann ist Schluss. Die Maschine würde stetig zwischen „fest“ und „lose“ iterieren und niemals zum Ende gelangen. Eine endlose Schleife, die mit einem Fehler abgebrochen werden muss. Der Uhrmacher kann nach weiteren Möglichkeiten suchen, was gleichbedeutend mit dem Suchen nach einem weiteren Kontext ist. Er kann vielleicht eine neue Schraube suchen oder versuchen das Zahnrad irgendwie anders geartet zu befestigen.

In „toten“ Umgebungen ist der Mensch mit der Umwelt eins geworden. Er ist trivialisiert. Das ist nicht despektierlich gemeint. Diese Trivialisierung ist ausreichend, da ein Rezept in Form eines Algorithmus vorliegt, welcher zielführend ist. Wahrnehmen ist also nicht notwendig, da kein Kontextwechsel vorgenommen werden muss. Messen reicht aus.

In einer komplexen und damit „lebendigen“ Welt gilt das Motto „Sowohl-Als-Auch“, da hier stetig der Kontext gewechselt wird. Das bedeutet Widersprüchlichkeiten handhaben zu müssen. Komplizierte Umgebungen kennen ausschließlich ein „Entweder-Oder“. Damit existieren in komplizierten Umgebungen auch keine Widersprüche. Komplizierte Sachverhalte können vollständig in Programmcode oder Algorithmen geschrieben und damit vollständig formallogisch kontrolliert werden. Bei komplexen Umgebungen funktioniert das nicht, da unsere Zweiwertige Logik, auf die jeder Programmcode basieren muss, Widersprüche und damit Polykontexturalität ausschließen. Komplexität ist nicht kontrollier-, sondern bestenfalls handhabbar.

Diese Erkenntnisse möchte ich nun nutzen, um das bekannte Cynefin Modell von Dave Snowden zu erweitern, da dieses in der ursprünglichen Form zu Kategorienfehler zwischen Kompliziertheit und Komplexität verleitet. Nach dem Cynefin Modell werden die Kategorien „einfach“, „kompliziert“ und „komplex“ auf einer Ebene platziert. Das ist aus meiner Sicht nicht passfähig. Die Einstufung „einfach“ und damit auch „schwierig“, die es im Modell nicht gibt, existiert eine Ebene höher in beiden Kategorien, „kompliziert“ und „komplex“. „Einfach“ ist also nicht gleich „einfach“.

„Einfach“ in der Kategorie „kompliziert“ bedeutet, dass das ausreichende Wissen, sowohl praktisch als auch theoretisch, gegeben ist, um eine komplizierte Fragestellung zu lösen. Grundsätzlich ist ein Lösungsweg vorhanden, den man theoretisch kennen und praktisch anwenden muss. Wird eine komplizierte Fragestellung als „schwierig“ eingestuft, ist der vorliegende Lösungsweg nicht bekannt, aber grundsätzlich vorhanden. Er muss erlernt werden, sowohl praktisch als auch theoretisch. In der Kategorie „kompliziert“ rede ich also von Methoden oder Algorithmen, die an den bekannten Lösungsweg an-gelehnt sind.

Für „komplexe“ Fragestellungen kann per Definition kein Wissen existieren, welches in Form eines Rezeptes zu einem Lösungsweg geformt werden kann. Hier sind Erfahrung, Talent und Können essentiell, die Agilität im jeweiligen Kontext erhöhen. Je größer oder kleiner Erfahrung und Talent sind, spreche ich dann von den Wertungen „einfach“, „schwierig“ oder „chaotisch“. Da kein Rezept gegeben ist, kann man Lösungswege auch nicht vorweg in Form von Algorithmen programmieren. Hier sind Frameworks und Heuristiken angebracht, die genügend Freiraum für das eigene Denken und Fühlen lassen.

Die untere Abbildung stellt die Abhängigkeiten und damit die Erweiterung des Cynefin Modells dar.

Data Science und „lebendige“ Kontexte – der Versuch einer Versöhnung

Gerade beim Einsatz von Big Data Analytics sind wir dem im ersten Part angesprochenen Kategorienfehler erlegen, was mich letztlich zu einer differenzierten Sichtweise auf Big Data Analytics verleitet. Darauf komme ich nun zu sprechen.

In vielen Artikeln, Berichten und Büchern wird Big Data Analytics glorifiziert. Es gibt wenige Autoren, die eine differenzierte Betrachtung anstreben. Damit meine ich, klare Grenzen von Big Data Analytics, insbesondere in Bezug zum Einsatz auf Menschen, aufzuzeigen, um damit einen erfolgreichen Einsatz erst zu ermöglichen. Auch viele unserer Hirnforscher tragen einen erheblichen Anteil zum Manifestieren des Kategorienfehlers bei, da sie glauben, Wirkmechanismen zwischen der materiellen und der seelischen Welt erkundet zu haben. Unser Gehirn erzeugt aus dem Feuern von Neuronen, also aus Quantitäten, Qualitäten, wie „Ich liebe“ oder „Ich hasse“. Wie das funktioniert ist bislang unbekannt. Man kann nicht mit Algorithmen aus der komplizierten Welt Sachverhalte der komplexen Welt erklären. Die Algorithmen setzen auf der Zweiwertigen Logik auf und diese lässt keine Kontextwechsel zu. Ich habe diesen Fakt ja im ersten Teil eingehend an der Unterscheidung zwischen Kompliziertheit und Komplexität dargelegt.

Es gibt aber auch erfreulicherweise, leider noch zu wenige, Menschen, die diesen Fakt erkennen und thematisieren. Ich spreche hier stellvertretend Prof. Harald Walach an und zitiere aus seinem Artikel »Sowohl als auch« statt »Entweder-oder« – oder: wie man Kategorienfehler vermeidet.

„Die Wirklichkeit als Ganzes ist komplexer und lässt sich genau nicht mit solchen logischen Instrumenten komplett analysieren. … Weil unser Überleben als Art davon abhängig war, dass wir diesen logischen Operator so gut ausgeprägt haben ist die Gefahr groß dass wir nun alles so behandeln. … Mit Logik können wir nicht alle Probleme des Lebens lösen. … Geist und neuronale Entladungen sind Prozesse, die unterschiedlichen kategorialen Ebenen angehören, so ähnlich wie „blau“ und „laut“.

Aus diesen Überlegungen habe ich eine Big Data Analytics Matrix angefertigt, mit welcher man einen Einsatz von Big Data Analytics auf Menschen, also in „lebendige“ Kontexte, verorten kann.

Die Matrix hat zwei Achsen. Die x-Achse stellt dar, auf welcher Basis, einzelne oder viele Menschen, Erkenntnisse direkt aus Daten und den darauf aufsetzenden Algorithmen gezogen werden sollen. Die y-Achse bildet ab, auf welcher Basis, einzelne oder viele Menschen, diese gewonnenen Erkenntnisse dann angewendet werden sollen. Um diese Unterteilung anschaulicher zu gestalten, habe ich in den jeweiligen Quadranten Beispiele eines möglichen Einsatzes von Big Data Analytics im Kontext Handel zugefügt.

An der Matrix erkennen wir, dass wir auf Basis von einzelnen Individuen keine Erkenntnisse maschinell über Algorithmen errechnen können. Tun wir das, begehen wir den von mir angesprochenen Kategorienfehler zwischen Kompliziertheit und Komplexität. In diesem Fall kennzeichne ich den gesamten linken roten Bereich der Matrix. Anwendungsfälle, die man gerne in diesen Bereich platzieren möchte, muss man über die anderen beiden gelben Quadranten der Matrix lösen.

Für das Lösen von Anwendungsfällen innerhalb der beiden gelben Quadranten kann man sich den Fakt zu Nutze machen, dass sich komplexe Vorgänge oft durch einfache Handlungsvorschriften beschreiben lassen. Achtung! Hier bitte nicht dem Versuch erlegen sein, „einfach“ und „einfach“ zu verwechseln. Ich habe im ersten Teil bereits ausgeführt, dass es sowohl in der Kategorie „kompliziert“, als auch in der Kategorie „komplex“, einfache Sachverhalte gibt, die aber nicht miteinander ob ihrer Schwierigkeitsstufe verglichen werden dürfen. Tut man es, dann, ja sie wissen schon: Kategorienfehler. Es ist ähnlich zu der Fragestellung: “Welche Farbe ist größer, blau oder rot?” Für Details hierzu verweise ich Sie gerne auf meinen Beitrag Komplexitäten entstehen aus Einfachheiten, sind aber schwer zu handhaben.

Möchten sie mehr zu der Big Data Analytics Matrix und den möglichen Einsätzen er-fahren, muss ich sie hier ebenfalls auf einen Beitrag von mir verweisen, da diese Ausführungen diesen Beitrag im Inhalt sprengen würden.

Mensch und Maschine – der Versuch einer Versöhnung

Wie Ihnen sicherlich bereits aufgefallen ist, enthält die Big Data Analytics Matrix keinen grünen Bereich. Den Grund dafür habe ich versucht, in diesem Beitrag aus meiner Sicht zu untermauern. Algorithmen, die stets monokontextural aufgebaut sein müssen, können nur mit größter Vorsicht im „lebendigen“ Kontext angewendet werden.

Erste Berührungspunkte in diesem Thema habe ich im Jahre 1999 mit dem Schreiben meiner Diplomarbeit erlangt. Die Firma, in welcher ich meine Arbeit verfasst habe, hat eine Maschine entwickelt, die aufgenommene Bilder aus Blitzgeräten im Straßenverkehr automatisch durchzieht, archiviert und daraus Mahnschreiben generiert. Ein Problem dabei war das Erkennen der Nummernschilder, vor allem wenn diese verschmutzt waren. Hier kam ich ins Spiel. Ich habe im Rahmen meiner Diplomarbeit ein Lernverfahren für ein Künstlich Neuronales Netz (KNN) programmiert, welches genau für diese Bilderkennung eingesetzt wurde. Dieses Lernverfahren setzte auf der Backpropagation auf und funktionierte auch sehr gut. Das Modell lag im grünen Bereich, da nichts in Bezug auf den Menschen optimiert werden sollte. Es ging einzig und allein um Bilderkennung, also einem „toten“ Kontext.

Diese Begebenheit war der Startpunkt für mich, kritisch die Strömungen rund um die Künstliche Intelligenz, vor allem im Kontext der Modellierung von Lebendigkeit, zu erforschen. Einige Erkenntnisse habe ich in diesem Beitrag formuliert.