Large Scale Multilayer Perceptron

LARGE SCALE MULTILAYER PERCEPTRON
Abschlussarbeit
zur Erlangung des akademischen Grades
Master of Science (M.Sc.)
an der
Hochschule für Technik und Wirtschaft Berlin
Fachbereich Wirtschaftswissenschaften II
Studiengang Angewandte Informatik
1. Prüfer: Prof. Dr. Christian Herta
2. Prüfer: Prof. Dr. Hermann Hessling
Eingereicht von
Sascha Jonas (B.Sc.)
10. Februar 2014
© Copyright 2013 Sascha Jonas (B.Sc.). Alle Rechte vorbehalten.

iii
Kurzbeschreibung:
In dieser Arbeit wurde ein Software-Framework entwickelt, auf der Basis von Apache
Hama, einer Implementierung des bulk-synchronous parallel model (BSP). Das Framework
bietet die Möglichkeit, ein künstliches neuronales Netz in einem Rechner-Cluster verteilt
zu trainieren. Es bietet weiterhin die Möglichkeit, sowohl auf Mini- als auch auf Big-Batch
basierende Trainingsalgorithmen zu benutzen. Skalierbarkeit und Performance wurden unter
anderem anhand des Trainings eines Denoising Autoencoders mit 1.000 Eingabe- und Ausga-
beneuronen ermittelt.
Abstract:
In this study the ability of bulk-synchronous parallel model (BSP) for scaling out the
training of an artiﬁcial neural networks is analyzed. Comparable distributed training al-
gorithms based on mini-batch and big-batch scheme were developed. For this purpose
the framework Apache Hama was used. The scalability of the diﬀerent approaches has be-
en determined by the training of an denoising autoencoder with 1,000 input and output neurons.
Keywords: autoencoder, bulk-synchronous parallel computing (BSP), deep
learning, Multilayer Perceptron, Apache Hama

Inhaltsverzeichnis
Inhaltsverzeichnis v
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 5
2.1 Künstliche neuronale Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Initialisierung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . 8
2.1.2 Gradientenbasierte Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Backpropagation of Error . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4 Momentum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5 ADAGRAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.6 Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.7 Autoencoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Bulk-Synchronous Parallel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Apache Hama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Anforderungsanalyse 21
3.1 Verwandte Studien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Studie 1: Using the BSP Cost Model to Optimize Parallel Neural Network
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Studie 2: Large Scale Distributed Deep Networks . . . . . . . . . . . . . . 22
3.2 Analyse des MLP Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Speicherung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 25

INHALTSVERZEICHNIS vi
3.3.2 Nicht-Funktionale-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Abgrenzungskriterium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Entwurf 29
4.1 Systembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 Datenvorverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 verteiltes Training mit BSP . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Sparse Autoencoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Implementierung 39
5.1 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 MLP-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Initialisierung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . 41
5.2.2 Matrizen-Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 Trainingsalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 verteiltes Training mit BSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.1 Initialisierung & Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Apache Hama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5.1 Stabilitätsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.2 Job-Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Software-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6.1 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Auswertung 49
6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Validitätstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.1 Experiment: XOR-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.2 Experiment: MONK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Skalierungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3.2 Vertikale Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.3 horizontale Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4 Laufzeittests einzelner Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.1 Einﬂuss des Caches auf die Ladezeit . . . . . . . . . . . . . . . . . . . . . 60
6.4.2 Vergleich von sequentieller und Binary Tree Kommunikation . . . . . . . 60

INHALTSVERZEICHNIS vii
6.4.3 Vergleich von Apache Mahout und jblas . . . . . . . . . . . . . . . . . . . 61
6.5 Untersuchung des Arbeitsspeicherverbrauchs . . . . . . . . . . . . . . . . . . . . . 63
6.6 Performancetests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6.1 Messung: Iterationsanzahl bis zur Erreichung eines Zielfehlerwerts . . . . 65
6.6.2 Messung: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . 66
6.7 Xing-Proﬁldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.7.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.7.2 Datenaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.7.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.7.4 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7 Fazit 75
7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A Klassendiagramme 79
B Einzelergebnisse der Performancetests 83
B.1 MONK: Anzahl Iterationen bis zum Fehlerwert 0,1 . . . . . . . . . . . . . . . . . 83
B.2 MONK: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 Xing20: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . 87
C Fehlerrechnung 89
D Metriken 91
D.1 Precision/Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
D.2 F-measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
D.3 Speedup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
E Normalisierung von Trainingsdaten 93
F Verteiltes Training mit BSP in Pseudocode 95
G Abkürzungsverzeichnis 97
H Abbildungsverzeichnis 99
I Sourcecodeverzeichnis 101
J Tabellenverzeichnis 103
K Literaturverzeichnis 105
L Eigenständigkeitserklärung 111

Kapitel 1
Einleitung
1.1 Motivation
Das Multilayer Perceptron (MLP) ist ein künstliches neuronales Netz und wird bereits seit
den 80er Jahren erfolgreich zur Lösung verschiedener Probleme, wie z.B. Klassiﬁzierung und
Regression, genutzt (siehe Abschnitt 2.1[Seite 7]).
Ausgelöst unter anderem durch die Arbeit Geoﬀrey E. Hintons im Jahr 2006, der einen Auto-
encoder (siehe Unterabschnitt 2.1.7[Seite 15]) benutzte, um ein künstliches neuronales Netzwerk
mit mehreren versteckten Schichten zu trainieren (deep learning), ist das MLP auch heute noch
im Fokus aktueller Forschung (siehe [HS06a], [Hin07]).
Eine Gruppe von Forschern bei Google verfolgte 2012 einen Ansatz mit horizontaler Ska-
lierung (scale out). Ihnen gelang es ein lokal verbundenes neuronales Netz mit einer Milliarde
Neuronenverbindungen auf einem Cluster mit 1.000 Rechnern und 16.000 CPUs zu trainie-
ren (siehe [LRM+
12]). Die selbe Gruppe untersuchte 2013 den Ansatz der vertikalen Skalierung
(scale up), anhand eines Clusters mit 16 Rechnern und 64 GPUs (siehe [CHW+
13]). Mit diesem
Cluster gelang es ihnen, ein lokal verbundenes Netz mit 10 Milliarden Neuronenverbindungen
in der gleichen Zeit zu trainieren.
Die obigen Beispiele zeigen, dass es unter Benutzung des Autoencoder-Ansatzes möglich
ist, neuronale Netze mit sehr vielen Parametern in kurzer Zeit zu trainieren. Beide Ansätze
scheinen eine gute Skalierbarkeit aufzuweisen, sind jedoch nicht als Open Source frei verfügbar.
Im Big Data Bereich gibt es eine Reihe von Open Source Frameworks, die nur Standard-
Hardware benötigen und eine gute Skalierbarkeit versprechen. Das Training eines neuronalen
Netzwerks ist ein iteratives Verfahren, d.h. dass auch entsprechende Anforderungen an ein
Framework gestellt werden. Im Rahmen dieser Arbeit wird das Framework Apache Hama (siehe
Abschnitt 2.2, Seite 16)verwendet, das eine Implementierung des bulk-synchronous parallel
model (BSP) ist. Es unterstützt explizit Iterationen, außerdem bietet es, im Gegensatz zur Map

KAPITEL 1. EINLEITUNG 2
Reduce1
Implementierung von Apache Hadoop (siehe [Whi11], Seiten 129ff), die Möglichkeit
an Daten über mehrere Iterationen hinweg im Arbeitsspeicher zu halten.
1.2 Zielstellung
Im Rahmen dieser Arbeit soll eine prototypische Anwendung zum verteilten Trainieren eines
künstlichen neuronalen Netzes erstellt werden. Diese Anwendung soll auf der Implementierung
eines MLP, das von der Hochschule zur Verfügung gestellt wurde, basieren. Um eine korrek-
te Funktion der daraus resultierenden Anwendung zu gewährleisten, wird als erstes Ziel die
Untersuchung und Validitätsprüfung des MLP-Frameworks festgelegt.
Den Trainingsvorgang zu beschleunigen ist ein weiteres Ziel dieser Arbeit. Zum Erreichen
dieses Ziels sollen folgende Ansätze verfolgt werden: Zum einen die Verwendung performanter
Trainingsalgorithmen, zum anderen die Verteilung der Berechnungen in einem Rechner-Cluster.
Teil der Untersuchung des MLP-Frameworks sind deshalb die verwendeten Trainingsalgor-
tithmen, die um zusätzliche Verfahren erweitert werden sollen. Das bereits vorhandene MLP-
Framework arbeitet sequentiell. Als erstes stellt sich deshalb die Frage, welcher Teil der Berech-
nungen parallelisiert erfolgen kann. Weiterhin muss ermittelt werden, wie die Parallelisierung
mit Apache Hama und BSP erfolgen sollte, um eine gute Skalierbarkeit zu gewährleisten. Insbe-
sondere muss untersucht werden, wie die Kommunikation über Rechnergrenzen hinweg ablaufen
sollte.
Zum Abschluss müssen die erfolgte Implementierung, die Eignung von Apache Hama und
die verwendeten Trainingsalgorithmen bewertet werden. Aus diesem Grund sollen Performanz
und Skalierbarkeit untersucht werden, dabei sind unter anderem Speedup und Overhead durch
Netzwerkkommunikation Gegenstand der Untersuchung. Als praktischer Anwendungsfall soll
das Trainieren einer „collocate tag cloud“ anhand von Xing-Profildaten untersucht werden.
Bei Xing (siehe [Xin]) handelt es sich um ein soziales Netzwerk, für hauptsächlich berufli-
che Zwecke. Die Benutzer dieser Webseite, können hier ihr Profil z.B. Ausbildung, beruflicher
Werdegang und eine Liste ihrer fachlichen und sozialen Kompetenzen veröffentlichen. Letzteres
wurde von Prof. Dr. Herta im Rahmen eines Forschungsprojekts für eine Reihe von Profilen
gecrawlt, anonymisiert und dem Autor zur Verfügung gestellt.
1.3 Aufbau der Arbeit
Kapitel 2 (siehe Seite 5ff) beinhaltet die Grundlagen dieser Arbeit: eine Einführung in künstliche
neuronale Netze, verwendete Trainings- und Optimierungsverfahren, sowie eine Beschreibung
des Frameworks Apache Hama (siehe Abschnitt 2.2, Seite 16).
1Map/Reduce sind zustandslose Funktionen und weisen Ähnlichkeiten zur funktionalen Programmierung auf.

KAPITEL 1. EINLEITUNG 3
In Kapitel 3 (siehe Seite 21ff) werden zwei Studien analysiert, die ebenfalls das verteilte
Training eines MLP in einem Cluster zum Inhalt haben. Weiterhin wird das bereits vorhandene
MLP-Framework analysiert. Diese beiden Analysen bilden die Grundlage, für die am Ende des
dritten Kapitels formulierte Zielstellung.
Kapitel 4 ist eine Zusammenfassung der Entwurfsphase (siehe Seite 29ff). Es beinhaltet eine
Systembeschreibung, geht auf die einzelnen Systemkomponenten ein und erläutert die grund-
sätzliche Vorgehensweise zur Implementierung eines Sparse Autoencoder (siehe Abschnitt 4.2,
Seite 37), auch wenn diese aus Zeitgründen entfallen musste.
In Kapitel 5 wird näher auf die eigentliche Implementierung eingegangen (siehe Seite 39ff).
Hier finden sich konkrete Details zur Implementierung ausgewählter Systemkomponenten, die
anhand von Codeausschnitten und Klassendiagrammen erläutert wird.
Die Auswertung der Validitäts-, Performance- und Skalierungstests ist Inhalt von Kapitel 6
(siehe Seite 49ff). Die Feststellung der Validität eines trainierten neuronalen Netzes, erfolgte
anhand des MONK-Problems, aus dem UCI-Repository für maschinelles Lernen (siehe [BL13],
„MONK’s Problems Data Set“), und anhand der XOR-Funktion. Die Performanz der Trainings-
verfahren, wurde sowohl anhand der Xing-Daten als auch anhand der MONK-Daten geprüft.
Die Xing-Daten wurden zusätzlich zum Testen der vertikalen und horizontalen Skalierbarkeit
verwendet. Der letzte Teil dieses Kapitels beschreibt Vorgehen und Ergebnisse der Extraktion
von syntagmatischer und paradigmatischer Relation mit Hilfe eines Denoising Autoencoder.
Das Kapitel 7 (siehe 75ff) bildet den Abschluss dieser Arbeit. Es enthält eine Zusammen-
fassung der Ergebnisse und den Ausblick.

Kapitel 2
Grundlagen
Im ersten Teil dieses Kapitels, werden künstliche neuronale Netze im Allgemeinen und meh-
rere im Rahmen dieser Arbeit verwendete Optimierungsverfahren erläutert. Dazu gehören das
Backpropagation Verfahren, Momentum, Denoising Autoencoder und Sparse Autoencoder, die
im vorliegenden Framework bereits implementiert wurden. Dieses Framework wurde im Rah-
men dieser Arbeit um Improved Resilient Propagation (iRprop+), ADAGRAD und verschiedene
Verfahren zur Initialisierung der Verbindungsgewichte erweitert, die zusätzlich kurz beschrieben
werden. Außerdem wird der Autoencoder Algorithmus vorgestellt, der die Grundlage für den
in Abschnitt 6.7 auf Seite 69 beschriebenen Anwendungsfall ist.
Im zweiten Teil dieses Kapitels werden das BSP Modell und das Framework Apache Hama
beschrieben.
2.1 Künstliche neuronale Netze
Ein künstliches neuronales Netz wird durch Simon Haykin (siehe [Sim05, Seite 24]) folgender-
maßen deﬁniert:
„A neural network is a massively parallel distributed processor made up of simple processing
units, which has a natural propensity for storing experiential knowledge and making it available
for use. It resembles the brain in two respects:“
• Knowledge is acquired by the network from its environment through a learning process.
• Interneuron connection strengths, known as synaptic weights, are used to store the acquired
knowledge.
Es besteht also aus mehreren einfachen Prozessoren (Neuronen), die miteinander verbunden
sind. Es erlangt Wissen im Rahmen eines Lernprozesses und speichert Wissen, durch die Verbin-
dungen (Synapsen) zwischen den Neuronen, denen unterschiedliche Gewichtungen zugeordnet
werden. Diese Verbindungsgewichte werden im Rahmen des Lernprozesses angepasst.

KAPITEL 2. GRUNDLAGEN 6
Man unterscheidet hier zwischen überwachtem („supervised“), unüberwachtem („unsuper-
vised“) und bestärkendem („reinforcement“) Lernen. Ziel des Lernvorganges ist, das neuronale
Netz so zu trainieren, dass es sowohl für bekannte als auch unbekannte Eingaben sinnvolle
Ausgaben liefert, z.B. indem es Handschriften erkennt, mit denen es nicht trainiert wurde.
Im Rahmen dieser Arbeit wird das MLP beschrieben und verwendet, welches zur Klasse
der künstlichen neuronalen Netze gehört. Das MLP ist ein Verfahren, das ausschließlich für
überwachtes Lernen benutzt werden kann. Beim überwachtem Lernen wird Wissen durch Geben
von gelabelten Datensätzen gewonnen, dabei besteht ein Datensatz aus einem oder mehreren
Eingabewerten und dem erwarteten Ergebnis.
Weiterhin wird im Rahmen dieser Arbeit ein Autoencoder verwendet, der auf dem MLP
aufsetzt. Der Autoencoder ist ein Beispiel für unüberwachtes Lernen. Hier werden ungelabelte
Daten zum Trainieren verwendet, dabei bedient sich der Autoencoder eines „Tricks“, indem
die Identität trainiert wird. Die Eingabe ist also gleich der Ausgabe, sodass das MLP auch mit
ungelabelten Daten benutzt werden kann (siehe Unterabschnitt 2.1.7, Seite 15).
Neuronenmodell
Abbildung 2.1: Neuronenmodell1
Ein künstliches neuronales Netz besteht aus mindestens einem Neuron, welches in Abbil-
dung 2.1 für ein Neuron schematisch dargestellt wird. Xi stellt den Eingabevektor mit m-
Dimensionen dar und Wij das Verbindungsgewicht zur jeweiligen Eingabe. X0 und W10 stellen
eine besondere Eingabe, nämlich den Bias bzw. dessen Gewichtung dar (In der Abbildung als
b1 dargestellt).
Der Bias ist immer gleich plus eins. Man kann den Bias, in Verbindung mit dem jeweiligem
Verbindungsgewicht, als einen Schwellwert betrachten. Erst wenn dieser Schwellwert überschrit-
ten wird, erzeugt das Neuron einen Output.
1Quelle: Original von [Sim05][Seite 33] wurde angepasst.

Die gewichteten Eingaben werden summiert (z1 =
m
j=1
xjW1j + b1). und bilden die Eingabe
für die Aktivierungsfunktion f. Der daraus resultierende Funktionswert a1 stellt schließlich die
Ausgabe des Neurons dar. Ein Beispiel für eine Aktivierungsfunktion ist die sigmoide-Funktion
f(x) = 1
1+e−x , deren Funktionswerte im Bereich [0,1] liegen.
Multilayer Perceptron
Das Multilayer Perceptron ist ein Netz von mehreren miteinander verbundenen Neuronen. Es
besteht aus einer Eingabeschicht („input layer“), einer oder mehreren versteckten Schichten
(„hidden layer“) und einer Ausgabeschicht („output layer“).
In der Abbildung 2.2 wird ein MLP exemplarisch dargestellt. Auf der linken Seite des neu-
ronalen Netzes befindet sich die Eingabeschicht, auch „feature“ Vektor genannt, mit drei Ein-
gaben. In der Mitte des Netzes befindet sich eine versteckte Schicht, mit drei Neuronen. Auf
der rechten Seite befindet sich schließlich die Ausgabeschicht mit einem Neuron. Der Bias wird
nicht mitgezählt, er ist in der Abbildung als „+1“ dargestellt.
Im Rahmen dieser Arbeit werden ausschließlich voll verbundene neuronale Netze betrach-
tet, d.h. jede Komponente des Eingabevektors ist mit jedem Neuron der benachbarten Schicht
verbunden. Die Neuronen in den versteckten Schichten, sind Schicht für Schicht mit allen Neu-
ronen in der jeweils benachbarten versteckten Schicht bzw. der Ausgabeschicht verbunden. Die
Verbindungen sind gerichtete Graphen, daher wird das MLP auch als „feedforward-Netz“ be-
zeichnet.
Abbildung 2.2: Multilayer Perceptron mit einem hidden layer2
Den Notationen von Ng folgend (siehe [And][Seite 4ff]), hat das oben gezeigte MLP die
Parameter (W, b) = (W(1)
, b(1)
, W(2)
, b(2)
), dabei stellt W
(l)
ij das Gewicht dar, welches der Ver-
bindung zwischen dem j-ten Neuron in der Schicht l und dem i-ten Neuron in der Schicht l+1
zugeordnet wird. Weiterhin ist b
(l)
i der Bias, der dem i-ten Neuron in der Schicht l+1 zugeord-
2Quelle: siehe [And][Seite 3]

net wird. Die Ausgabe eines Neurons wird durch a
(l)
i dargestellt. Die Ausgabe des dargestellten
MLP wird folgendermaßen berechnet:
a
(2)
1 = f(W
(1)
11 x1 + W
(1)
12 x2 + W
(1)
13 x3 + b
(1)
1 ) (2.1)
a
(2)
2 = f(W
(1)
21 x1 + W
(1)
22 x2 + W
(1)
23 x3 + b
(1)
2 ) (2.2)
a
(2)
3 = f(W
(1)
31 x1 + W
(1)
32 x2 + W
(1)
33 x3 + b
(1)
3 ) (2.3)
hW,b(x) = a
(3)
1 = f(W
(2)
11 a2
1 + W
(2)
12 a2
2 + W
(2)
13 a2
3 + b
(2)
1 ) (2.4)
Um dieses neuronale Netz zu trainieren, werden die Trainingsdaten (x(i)
, y(i)
), mit x(i)
∈ R3
und y(i)
∈ R1
, benötigt. Die Variable x steht für den Eingabevektor und enthält die Eingabe-
daten. Die Variable y steht für den Zielvektor und enthält die für dieses Beispiel erwarteten
Ausgabedaten.
Trainingsalgorithmen, werden unterschieden in Online-, Mini-Batch- und Batch-
Lernverfahren (siehe Seiten 9 und 10).
Ein weiteres Unterscheidungsmerkmal ist, welche Ableitung der Fehlerfunktion (siehe Ka-
pitel 2.1.2) benutzt wird. Man unterscheidet hier zwischen Verfahren erster und zweiter Ord-
nung. Bei Verfahren erster Ordnung wird ausschließlich die erste Ableitung der Fehlerfunktion
benötigt (Gradient). Im Rahmen dieser Arbeit wird sich auf diese Verfahren beschränkt. Bei
Verfahren zweiter Ableitung wird zusätzlich die zweite Ableitung benötigt (siehe z.B. Hesse-
Matrix [Chr96][Seiten 150-160])).
Nachfolgend werden die Initialisierung der Verbindungsgewichte, mehrere Verfahren erster
Ordnung, zur Ermittlung der Gewichtsänderungen, und das Backpropagation Verfahren, zur
Ermittlung der ersten Ableitung, beschrieben.
2.1.1 Initialisierung der Verbindungsgewichte
Bevor ein neuronales Netz trainiert werden kann, müssen die Verbindungsgewichte initialisiert
werden. Hier gilt es zu beachten, dass sie mit unterschiedlichen Werten initialisiert werden
müssen. Würde man jedes Verbindungsgewicht mit dem gleichen Wert initialisieren, dann wür-
den alle Neuronen einer Schicht die selbe Funktion lernen und die gleiche Ausgabe erzeugen
(siehe [And][Seite 7] und Unterabschnitt 2.1.3).
Laut LeCun et al. hat die Initialisierung einen großen Einﬂuss auf den Lernprozess (sie-
he [LBOM98][Kapitel 4.6]). Eine schlechte Initialisierung z.B. auf einem Plateau kann den
Lernvorgang stark verlangsamen (siehe Beispiel d in Abbildung 2.4, Unterabschnitt 2.1.4). Le-
Cun et al. schlagen folgende Normalverteilung für die zufällige Initialisierung der Gewichte vor:
N(0, 1√
fanin
). Die Variable fanin steht für die Anzahl der jeweils eingehenden Verbindungen.
Im Rahmen dieser Arbeit werden nur voll verbundene Netze betrachtet. Sie steht deshalb im-
mer für die Anzahl der Neuronen in der vorhergehenden Schicht. Diese Form der Initialisierung
wird in dem vorliegenden Framework bereits benutzt.

Nguyen & Widrow sowie Glorot & Bengio berechnen die Gewichtswerte unter Berücksich-
tigung der Neuronenanzahl in zwei Schichten (siehe [NW90][Seite 25] und [GB10][Seite 253]).
Glorot & Bengio schlagen eine Uniformverteilung der Gewichtswerte vor, die sie als nor-
malisierte Initialisierung bezeichnen. Die Initialisierung hängt laut Glorot & Bengio von der
Aktivierungsfunktion ab. Mit fanout gleich der Anzahl Neuronen in der betrachteten Schicht,
gilt für die Aktivierungsfunktion tanh:
W U −
√
6
√
fanin + fanout
,
√
6
√
fanin + fanout
(2.5)
Die Initialisierung der Gewichte erfolgt mit dem Verfahren von Nguyen & Widrow in meh-
reren Schritten. Im ersten Schritt werden die Gewichte zufällig initialisiert. Es gilt folgende
Uniformverteilung:
W U[−1, 1] (2.6)
Sei Wl
i der Gewichtsvektor des i-ten Neurons in der Schicht l, dann wird im zweiten Schritt die
Norm von Wl
i geändert, so dass gilt:
|Wl
i | = 0.7 · (fanout)fan−1
in (2.7)
2.1.2 Gradientenbasierte Lernverfahren
Das Training eines neuronalen Netzes gehört zu der Klasse der Minimierungsprobleme, da es gilt
den Fehler, also den Abstand zwischen der tatsächlichen und der erwarteten Ausgabe des Netzes,
zu verringern. Für diesen Zweck sei als erstes eine Fehlerfunktion auf Basis des quadratischen
Fehlers aufgestellt, welche die Parameter W, b, x und y berücksichtigt.
Für ein Trainingsbeispiel wird folgende Fehlerfunktion (siehe [And][Seite 6ff]) definiert:
J(W, b; x, y) =
1
2
||hW,b(x) − y||2
(2.8)
Batch Gradient Descent
Benutzt man Batch Gradient Descent (BGD), so gilt folgende Fehlerfunktion über alle m-
Trainingsdaten:
J(W, b) = [
1
m
m
i=1
(
1
2
||hW,b(x(i)
) − y(i)
||2
)] +
λ
2
nl−1
l=1
sl
i=1
sl+1
j=1
(W
(l)
ij )2
(2.9)
In obiger Fehlerfunktion stellt der erste Term, den Durchschnitt über den quadratischen Fehler
dar. Der zweite Term ist der sogenannte Regularisierungs-Term, der Overfitting, also das Aus-
wendiglernen der Trainingsdaten, verringern soll. Hier stellt λ den weight decay parameter dar,
der die Gewichtung des Regularisations-Term bestimmt. Der Parameter nl steht für die Anzahl
an Schichten im MLP und sl für die Anzahl an Neuronen in der jeweiligen Schicht, ohne Bias.

Abbildung 2.3: Gradientenabstieg auf zweidimensionaler Fehlerfunktion3
Bei gradientenbasierten Verfahren wird das Optimum (meist jedoch nur ein lokales Minima)
der Fehlerfunktion in einer Reihe von Iterationen ermittelt (siehe obige Abbildung). Die jeweili-
ge Schrittweite ( W) ist proportional zum Gradienten der Fehlerfunktion und zeigt in Richtung
des steilsten Abstiegs (siehe [GGKK07], Seite 64). Sie wird unter der Annahme ermittelt, dass
der Anstieg der Fehlerfunktion größer ist, je weiter das Optimum entfernt ist (siehe Unter-
abschnitt 2.1.4[Seite 12]). Je geringer der Anstieg, umso kleiner ist die gewählte Schrittweite.
Während jeder Iteration werden die Parameter W und b folgendermaßen angepasst:
W
(l)
ij := W
(l)
ij − α
∂
∂W
(l)
ij
J(W, b; x, y) (2.10)
b
(l)
i := b
(l)
i − α
∂
∂b
(l)
i
J(W, b; x, y) (2.11)
In den Gleichungen 2.10 und 2.11 stellt α die Lernrate dar, welche in der vorliegenden Im-
plementierung eines MLP immer fest gewählt wird, d.h. die für die Problemstellung optimale
Lernrate müsste im Rahmen mehrere Versuche ermittelt werden. Einen Ansatz zur automati-
schen Anpassung der Lernrate, stellt zum Beispiel ADAGRAD (siehe Unterabschnitt 2.1.5[Seite
13]) dar.
Mini Batch Gradient Descent
Wie in den Gleichungen 2.9 und 2.10 zum BGD-Verfahren ersichtlich, wird im ersten Schritt
der Gradient über alle Trainingsbeispiele gebildet und summiert. Daraus wird dann im zweiten
Schritt der Durchschnitt gebildet und das Modell, genauer die Gewichtsmatrizen des neuronalen
Netzes, verändert. Daraus folgt, je größer das Trainingsset um so länger dauert die Berechnung
eines Iterationsschrittes.
Beim Mini Batch Gradient Descent (MBGD) Lernverfahren gilt auch die Gleichung 2.9, nur
steht hier die Variable m für die Batchgröße und nicht für die Gesamtzahl an Trainingsbei-
spielen. Ist die Batchgröße z.B. gleich 200, dann wird der durchschnittliche Gradient nur über
3Quelle: siehe [GGKK07][Seite 64]

200 Trainingsbeispiele gebildet und das Modell verändert. Das wird so lange wiederholt, bis das
Modell mit allen Trainingsbeispielen trainiert wurde, dann beginnt das Training wieder mit den
ersten m-Trainingsdaten.
Ein weiteres auf Gradienten basierendes Verfahren ist Stochastic Gradient Descent (SGD).
SGD ist ein Online-Lernverfahren, d.h. das Modell wird nach jedem Trainingsbeispiel ange-
passt (siehe [Bot98][Seite 5ff]). Ein weiterer Unterschied ist, dass vor Beginn des Trainings die
Trainingsdaten nach dem Zufallsprinzip neu geordnet werden.
2.1.3 Backpropagation of Error
Wie in Gleichung 2.10 ersichtlich, muss zur Berechnung der Gewichtsänderung zuerst die
Ableitung der Fehlerfunktion an der Stelle [x, y] berechnet werden. Dies erfolgt mit dem
Backpropagation-Verfahren (siehe [And][Seiten 7-9]), das nachfolgend erläutert wird.
Im ersten Schritt wird die Ausgabe/Aktivierung a
(l)
i für alle Neuronen, in den versteckten
Schichten Ll und der Ausgabeschicht Lnl, berechnet (forward pass). Im zweiten Schritt wird
der Fehlerwert δl
i für alle Neuronen ermittelt. Für die Neuronen der Ausgabeschicht, stellt δnl
i
jeweils die Differenz zwischen yi und der Netzausgabe dar. Daraus ergibt sich folgende Gleichung
für die Neuronen der Ausgabeschicht:
δ
(nl)
i =
∂
∂z
(nl)
i
1
2
||y − hW,b(x)||2
= −(yi − a
(nl)
i )f (z
(nl)
i ) (2.12)
In obiger Gleichung stellt zi die Summe der gewichteten Eingaben dar. Die Variable zi entspricht
vk aus Abbildung 2.1. Die Variable f steht für die Aktivierungsfunktion des jeweiligen Neurons.
Für die Berechnung des Fehlerwerts δl
i, der Neuronen in den versteckten Schichten, wird der
gewichtete Durchschnitt über alle Fehlerwerte berechnet, die ai als Eingabe benutzen. Daraus
ergibt sich folgende Gleichung:
δ
(l)
i =
sl+1
j=1
(W
(l)
ji δl+1
j )f (z
(l)
i ) (2.13)
Der Fehlerwert wird also beginnend bei der Ausgabeschicht berechnet und zu den davor lie-
genden Schichten propagiert. Mit den Fehlerwerten kann schließlich die Ableitung berechnet
werden:
∂
∂W
(l)
ij
J(W, b; x, y) = a
(l)
j δ
(l+1)
i (2.14)
∂
∂b
(l)
i
J(W, b; x, y) = δ
(l+1)
i (2.15)
Die Komplexität des Backpropagation Algorithmus, verhält sich linear zur Anzahl der Gewich-
te im neuronalen Netz (O(W)). Damit ist das Backpropagation Verfahren sehr effizient. Die
Bestimmung der Ableitung z.B. mit finiten Differenzen wäre deutlich langsamer, da dessen
Komplexität bei O(W2
) liegt (siehe [Chr96][Seiten 146-148]).

2.1.4 Momentum
Abbildung 2.4: Mögliche Probleme beim Gradientenabstieg4
Die in Abschnitt 2.1.2 erwähnte Ermittlung von W kann zu Problemen führen, da sie
auf einer Annahme basiert, die nicht immer korrekt ist. So ist es z.B. möglich, dass Minima
in der Nähe starker Anstiege übersprungen werden (Beispiel d in obiger Abbildung), oder dass
das Verfahren an Plateaus hängenbleibt (Beispiel b in obiger Abbildung), die einen geringen
Anstieg haben aber kein Minima der Fehlerfunktion darstellen.
In der vorliegenden Implementierung des MLP wurde deshalb Gleichung 2.10 erweitert und
der Momentum Term µ eingeführt5
(siehe [RHW88]). Für die Berechnung der Gewichtsverän-
derung, gilt:
W
(l)
ij := W
(l)
ij − ( W
(l)
ij (t) + µ W
(l)
ij (t − 1)) (2.16)
In der obigen Formel steht t für die aktuelle und t-1 für die letzte Gewichtsänderung. Zur Ge-
wichtsänderung wird also die letzte Gewichtsänderung hinzu addiert, die mit dem Momentum-
Term multipliziert wird. Der Momentum Term verstärkt die Gewichtsänderung, wenn W
(l)
ij (t)
und W
(l)
ij (t − 1) das gleiche Vorzeichen haben. Dadurch wird die Gewichtsänderungsrate auf
Plateaus erhöht und bei wechselndem Vorzeichen verringert (siehe Beispiel c in obiger Abbil-
dung). Allerdings ist es auch hier möglich, dass ein lokales Minima wieder verlassen wird, da
nicht zwischen einem Plateau und einem Minima unterschieden werden kann.
4Quelle: siehe [GGKK07][Seite 66]
5Die Variable µ ist in dem MLP-Framework standardmäßig auf 0.8 festgelegt und wird im Rahmen dieser
Arbeit nicht verändert.

2.1.5 ADAGRAD
Wie im Abschnitt 2.1.2 erwähnt, ist die Lernrate in der vorliegenden Implementierung eine
Konstante. Mit ADAGRAD existiert ein Algorithmus, der die Lernrate für jedes Verbindungs-
gewicht wi,j individuell anpasst. ADAGRAD steht für „adaptive gradient“ (siehe [DHS11]).
Dieser Algorithmus setzt voraus, dass die vorherigen und die aktuelle partielle Ableitung
für jede Gewichtsverbindung in einem Vektor w
(l)
ij gespeichert sind. Dann ergibt sich folgende
Lernrate α für das Verbindungsgewicht W:
α(t) =
η
|w
(l)
ij |
=
η
t
τ=1
( ∂
∂W J(τ))2
(2.17)
In obiger Gleichung stellt η eine globale konstante Lernrate dar, die durch die l2-Norm,
über alle vorherigen und die aktuelle partielle Ableitung, dividiert wird. Daraus folgt, dass die
Schrittweite bei großen Gradienten kleiner ist, als bei kleinen Gradienten.6
Eine weitere Folge
ist, dass die Lernrate in jeder Iteration reduziert wird, bis die Gewichtsänderungen nahe Null
sind.
Das ADAGRAD-Verfahren wurde von Dean et al. mit Downpour SGD benutzt und erzielte
dort sehr gute Ergebnisse (siehe [DCM+
12][Seite 5]). Inwieweit sich ADAGRAD für MBGD oder
BGD eignet, wird in Abschnitt 6.6 untersucht.
An dieser Stelle sei, auch wenn es im Rahmen dieser Arbeit nicht verwendet wird, noch
auf das ADADELTA-Verfahren (siehe [Zei12]) verwiesen. Es erweitert ADAGRAD, so dass die
globale Lernrate η entfällt, basiert jedoch zum Teil auf Verfahren zweiter Ordnung (Hesse-
Matrix).
2.1.6 Resilient Propagation
Resilient Propagation (Rprop) ist ein von Riedmiller et al. entwickeltes Batch Lernverfahren
(siehe [RB92]). Eine Besonderheit von Rprop ist, dass das Gewichtsupdate nicht von der Größe
des Gradienten, sondern nur von dem Vorzeichen des Gradienten beeinﬂusst wird. Es ähnelt
Momentum und ADAGRAD dahingehend, dass Gradienten aus vorhergehenden Iterationen mit
in die Berechnung einbezogen werden.
Rprop wurde unter anderem von Igel et al. weiterentwickelt (siehe [IH00]). Nachfolgend wird
deshalb deren verbesserte Variante: iRprop+ vorgestellt.
6Diese Vorgehensweise entspricht einem Vorschlag von Haykin (siehe [Sim05][Seite 206, 4.6.8]), zur Bestim-
mung der Lernrate in den unterschiedlichen Schichten des künstlichen neuronalen Netzes.

Die Schrittweite ij(t) mit Wij(t+1) = Wij(t)+ ij(t) wird für Rprop und davon abgeleitete
Verfahren folgendermaßen festgelegt:
ij(t) :=



η+
· ij(t − 1) , für ∂J(W,b)
∂Wij
(t − 1) · ∂J(W,b)
∂Wij
(t) > 0
η−
· ij(t − 1) , für ∂J(W,b)
∂Wij
(t − 1) · ∂J(W,b)
∂Wij
(t) < 0
ij(t − 1) , sonst
(2.18)
Allgemein gilt: 0 < η−
< 1 < η+
. Das heißt, dass die Schrittweite verringert wird, wenn sich
das Vorzeichen im Vergleich zur letzten Iteration geändert hat und gleich bleibt, wenn sich das
Vorzeichen nicht ändert. Dieses Vorgehen hilft, die bereits in Unterabschnitt 2.1.4 geschilderten
Probleme zu mildern.
1 for each Wij do
2 if ∂J(W,b)
∂Wij
(t − 1) · ∂J(W,b)
∂Wij
(t) > 0 then
3 ij(t) := min( ij(t − 1) · η+
, max)
4 Wij(t) := −sign ∂J(W,b)
∂Wij
(t) · ij(t)
5 Wij(t + 1) := Wij(t) + Wij(t)
6 elseif ∂J(W,b)
∂Wij
(t − 1) · ∂J(W,b)
∂Wij
(t) < 0 then
7 ij(t) := max( ij(t − 1) · η−
, min)
8 if(J(W, b)t
> J(W, b)t−1
) then
9 Wij(t + 1) := Wij(t) − Wij(t − 1)
10 else
11
∂J(W,b)
∂Wij
(t) := 0
12 elseif ∂J(W,b)
∂Wij
(t − 1) · ∂J(W,b)
∂Wij
(t) = 0 then
13 Wij(t) := −sign ∂J(W,b)
∂Wij
(t) · ij(t)
14 Wij(t + 1) := Wij(t) + Wij(t)
15 fi
16 od
Listing 2.1: iRprop+ in Pseudocode
Die Zeilen 3 und 7 in obigem Listing zeigen, dass die Schrittweite nach oben ( max) und
unten ( min) begrenzt ist. Die Zeilen 8 bis 11 zeigen, wie „weight backtracking“ mit iRprop+
durchgeführt wird. Im Gegensatz zu Rprop wird hier nach einem Vorzeichenwechsel überprüft,
ob die Änderung des Vorzeichens auch zu einem größeren Fehlerwert führt. Ist dies der Fall,
dann wird die letzte Gewichtsänderung rückgängig gemacht.
Riedmiller et al. untersuchten in ihrer Arbeit, welche Werte für η+
, η−
, min und max opti-
mal sind. Im Rahmen dieser Arbeit sind, wie von Riedmiller et al. empfohlen (siehe [RB92][Seite
3]), diese Werte folgendermaßen festgelegt: η+
= 1.2, η−
= 0.5, min = 1e−6
, max = 50.

2.1.7 Autoencoder
Der Autoencoder Algorithmus wurde von Hinton et al. zum Trainieren von neuronalen Netzen
mit mehreren versteckten Schichten („deep learning“) entwickelt (siehe [HS06b]). Diese Form
von neuronalen Netzen lässt sich sonst laut Hinton et al. nur sehr langsam trainieren, da der
Gradient kleiner ist, je weiter eine versteckte Schicht von der Ausgabeschicht entfernt ist. Dieses
Problem ist als „vanishing gradient“ bekannt und wurde von Hochreiter im Zusammenhang mit
rekurrenten neuronalen Netzen beschrieben (siehe [Hoc98]), gilt aber auch für „feed-forward“
Netze.
Aus diesem Grund wird der Autoencoder im „deep learning“ benutzt, um die versteckten
Schichten des neuronalen Netzes in mehreren Schritten nacheinander zu initialisieren („pre-
training“). Es zeigte sich, das mit einem Autoencoder trainierte neuronale Netze eine deutlich
bessere Performance erzielen können, als vergleichbare Ansätze (siehe z.B. [LRM+
12]). Dies sei
aber nur zur Motivation, der Verwendung eines Autoencoder im „deep learning“, erwähnt, da
die im Rahmen dieser Arbeit benutzten neuronalen Netze lediglich über eine versteckte Schicht
verfügen.
Ein weiterer Anwendungsfall für Autoencoder ist die Dimensionsreduktion bzw. Hauptkom-
ponentenanalyse (PCA, siehe z.B. [GKWZ07]). Dafür eignet sich z.B. der nachfolgend erläuterte
Sparse Autoencoder.
Sparse Autoencoder
Wie zu Beginn dieses Kapitels erwähnt, gilt bei Benutzung eines Autoencoder, dass die Eingabe
gleich der Ausgabe ist, also y(i)
= x(i)
. Die Lösung hierfür scheint trivial, da ein Netzwerk, bei
dem Eingabe-, versteckte und Ausgabeschicht die gleiche Größe haben, die Eingabe einfach
weiterleiten müsste, z.B. mit Wij = 1 wenn i = j und Wij = 0 wenn i <> j.
Ist jedoch die Anzahl der Neuronen in der versteckten Schicht geringer, als die Größe
des Eingabevektors, dann muss die Eingabe vom neuronalen Netz rekonstruiert werden (sie-
he [And][Seiten 12-16]), z.B. durch das Finden von Korrelationen zwischen Eingabedaten.
ˆp =
1
m
m
i=1
a
(2)
j (x(i)
) (2.19)
Um dies auch für Netze mit versteckten Schichten beliebiger Größe zu ermöglichen wird der
„sparsity parameter“ p und der Begriﬀ des Sparse Autoencoder eingeführt. In einem Sparse
Autoencoder wird erzwungen, dass die durchschnittliche Ausgabe ˆp eines Neurons (siehe Glei-
chung 2.19) in einer versteckten Schicht über alle m-Trainingsdaten gleich p ist, mit kleinem p
z.B. p = 0.0001.
Um das zu erreichen, wird die Berechnung des Fehlerwerts (vgl. Gleichung 2.13), in ei-
nem neuronalen Netz mit einer versteckten Schicht, folgendermaßen um einen „penalty“ Term

erweitert:
δ
(2)
i =
s2
j=1
W
(2)
ji δ3
j + β −
p
ˆpi
+
1 − p
1 − ˆpi
f (z
(2)
i ). (2.20)
Bevor das Backpropagation Verfahren angewendet werden kann, muss also ˆpi für alle i-Neuronen
der versteckten Schicht berechnet werden.
Denoising Autoencoder
Mit dem Denoising Autoencoder, wurde eine weitere Variante des Autoencoder von Vincent et
al. entwickelt (siehe [VLBM08]). Wie im Standardverfahren gilt hier y(i)
= x(i)
. Allerdings wird
beim Training der Eingabevektor „beschädigt“, so dass statt x(i)
der Vektor ˜x(i)
als Eingabe
dient. Als Ausgabe wird weiterhin x(i)
erwartet.
Der Eingabevektor ˜x(i)
wird erzeugt, indem nach dem Zufallsprinzip eine oder mehrere Ein-
gaben auf null gesetzt werden. Dadurch wird das neuronale Netz gezwungen den Vektor x(i)
aus der „beschädigten“ Eingabe zu rekonstruieren. Das bedeutet weiterhin, dass das neuronale
Netz in jeder Iteration mit leicht veränderten Eingabedaten aber gleichen Ausgabedaten/Er-
wartungswerten trainiert wird.
Laut Vincent et al. konnte hiermit, im Vergleich mit den besten Verfahren, eine mindes-
tens ähnliche bis deutliche bessere Performance erreicht werden. Im Vergleich mit einem Au-
toencoder, wies der Denoising Autencoder in allen Tests eine bessere Performance auf (sie-
he [VLBM08][Seite 7]).
2.2 Bulk-Synchronous Parallel Model
In den folgenden Unterkapiteln wird das BSP Modell beschrieben. Es wird im Rahmen dieser
Arbeit zum Verteilen aller Berechnungen in einen Cluster mit mehreren Rechnern benutzt.
Weiterhin wird das Java-Framework Apache Hama vorgestellt, welches eine Implementierung
des BSP Modells ist.
2.2.1 Algorithmus
Das BSP Modell ist ein Verfahren, zum parallelen Ausführen von Berechnungen. Dieses Verfah-
ren kann sowohl auf Hard- als auch auf Softwareebene implementiert werden und wurde von
Leslie G. Valiant entwickelt (siehe [RS98]).
Valiant beschreibt BSP als eine Kombination der folgenden drei Attribute (vgl. mit Abbil-
dung 2.5):
1. Eine beliebige Anzahl von Komponenten, die Berechnungs- und/oder Speicherfunktiona-
litäten bieten.
7Quelle: siehe http://en.wikipedia.org/wiki/Bulk_synchronous_parallel

Barrier
Synchronisation
Local
Computation
Communication
Processors
Abbildung 2.5: bulk-synchronous parallel modell7
2. Ein Router, der Nachrichten über Punkt-zu-Punkt-Verbindungen zwischen den einzelnen
Komponenten ausliefert.
3. Es gibt die Möglichkeit alle oder einen Teil der Komponenten zu synchronisieren. Dies
soll in einem festen Zeitintervall L geschehen. Eine Berechnung ist eine Abfolge aus einem
oder mehreren Supersteps. In jedem Superstep erhält jede Komponente eine Aufgabe,
die eine Kombination aus lokalen Berechnungen und dem Empfangen bzw. Senden von
Nachrichten sein kann. Im ﬁxen Zeitabstand L wird überprüft, ob der Superstep von
allen Komponenten abgeschlossen wurde. Erst wenn dieser der Fall ist, wird der nächste
Superstep gestartet.
Ein vergleichbarer Ansatz für das Verteilen von Berechnungen in einen Cluster ist z.B.
Message Passing Interface (MPI) (siehe [GLS94]). Auch hier erfolgt die Kommunikation mit
Hilfe von Nachrichten. Allerdings mit dem Unterschied, dass MPI nicht nur Punkt-zu-Punkt
Verbindungen, sondern auch Punkt-zu-Mehrpunkt Verbindungen (Broadcast, Multicast) expli-
zit unterstützt. Außerdem werden hier mehrere Abstufungen zur Synchronisation von mehreren
Rechnern unterstützt, was in dem BSP-Framework Apache Hama sehr strikt geregelt ist.

2.2.2 Apache Hama
Architektur
Abbildung 2.6: Architektur von Apache Hama8
In Abbildung 2.6 wird die in mehrere Schichten unterteilte Architektur (siehe
[SYK+
10][Seiten 1-2]) von Apache Hama dargestellt. Es besteht aus den drei Komponenten
Hama Core, Hama Shell und der Hama API und unterstützt die Verfahren MapReduce (sie-
he [DG08]), BSP und Dryad.
Das Framework: Zookeeper (siehe [Whi11][Seiten 441-476]) wird zur Manipulation verteilter
Metadaten und zur Transaktionskontrolle verwendet. Zur Ablage und zum Einlesen von Daten
kann unter anderem das verteilte Dateisystem Hadoop Distributed Filesystem (HDFS) (siehe
[Whi11][Seiten 41-128]) verwendet werden, dass u.a. den Vorteil der Datenlokalität bietet.
Ein BSP-Job wird von einem oder mehreren BSP-Peers (Threads) ausgeführt und besteht
aus mindestens einem Superstep. In der Job-Konﬁguration kann unter anderem festgelegt wer-
den, wie viele BSP-Peers insgesamt benutzt werden sollen.
In der Konﬁgurationsdatei eines Rechners wird festgelegt, wie viele BSP-Peers auf diesem
Rechner gestartet werden können. Das Framework verteilt die BSP-Peers nicht gleichmäßig im
Cluster, sondern auf möglichst wenige Rechner, um die Kommunikationskosten so gering wie
möglich zu halten.
Lesen/Schreiben von Daten
Bevor man einen BSP-Job starten kann, muss im ersten Schritt die Klasse
org.apache.hama.bsp.BSP erweitert und mindestens die bsp()-Methode überschrieben
werden. Dessen Signatur sieht wie folgt aus:
8Quelle: siehe [SYK+10][Seite 1]

1 public abstract void bsp(BSPPeer<K1, V1, K2, V2, Mextends Writable> peer) throws ...;
Listing 2.2: Methodensignatur von BSP.bsp()
In der obigen Methodensignatur werden Eingabe, Ausgabe und Kommunikation für den gesam-
ten BSP-Job festgelegt. K1 und V1 stehen für die Eingabe, die aus dem Schlüssel (K1) und dem
dazugehörigen Wert (V1) bestehen. K2 und V2 bilden das Äquivalent für die Ausgabe. M steht
für das zur Kommunikation benutzte Nachrichtenformat. Das Hama Framework kennt bereits
einige Standardformate z.B. Text, LongWritable und NullWritable.
Eine Besonderheit dieser Methode ist, dass sie während der gesamten Laufzeit des Pro-
gramms, auf jedem BSP-Peer nur einmal aufgerufen wird. Wird diese Methode wieder verlassen,
dann endet der BSP-Job, der wiederum aus einem oder mehreren Supersteps bestehen kann.
Diese Besonderheit ermöglicht es Daten über mehrere Supersteps hinweg im Arbeitsspeicher
zu halten. Im MapReduce-Verfahren ist das z.B. nicht möglich, da Map- bzw. Reduce-Methode
statuslos sind und mehrmals aufgerufen werden.
Die Dateneingabe kann aus einer oder mehreren Text- oder Sequenzdateien (siehe
[Whi11][Seiten 116-123]) bestehen. Das Framework übernimmt standardmäßig das Aufsplit-
ten der Daten in möglichst gleich große Teile, um auch die Rechenlast möglichst gleichmäßig
zu verteilen. Es kann auch eine eigene Splitfunktion angegeben werden.
Innerhalb der bsp()-Methode erfolgt die Datenein- und -ausgabe mit Hilfe der BSPPeer-
Klasse. Jeder BSP-Peer kann nur auf seinen Teil der Daten zugreifen, die jeweils lokal vorliegen
und sich während eines BSP-Jobs nicht ändern.
Jeder BSP-Peer kann den Dateizeiger wieder auf den Anfang setzen, so dass in einer Iteration
wieder von vorne begonnen werden kann. Es wird jedoch vom Framework nicht die Möglichkeit
gegeben, z.B. zu einem bestimmten Datensatz zurück springen. Dazu müsste der Dateizeiger
auf den Anfang und dann nicht benötigte Datensätze übersprungen werden, bis der gewünschte
Datensatz erreicht ist. Auch ein Zwischenspeichern von Datensätzen im Arbeitsspeicher ist von
Apache Hama zur Zeit nicht vorgesehen.
Kommunikation und Synchronisation
Jeder BSP-Peer wird durch einen eindeutigen Namen adressiert, der sich aus dem Rechnernamen
und einen IP-Port zusammensetzt. Die Adressierung von BSP-Peers erfolgt mit Hilfe dieses
eindeutigen Namens. Jeder BSP-Peer auf einem Rechner kommuniziert über seinen eigenen
IP-Port.
Die BSPPeer-Klasse hat Methoden um den eigenen Peer-Namen und um alle Peer-Namen
abzufragen, der Peers die mit diesem Job beschäftigt sind. Außerdem bietet sie die Möglichkeit
einzelne Nachrichten und die Gesamtanzahl an Nachrichten abzurufen.
Die BSPPeer-Klasse bietet mit der peer.send(String peerName, BSPMessage msg)-Methode
die einzige Möglichkeit zur Kommunikation zwischen BSP-Peers.

Im Listing 2.3 wird die Kommunikation zwischen BSP-Peers an einem kleinem Beispiel
gezeigt. Der BSP-Job führt in diesem Beispiel 100 Supersteps aus (siehe Zeile 4), in denen jeder
BSP-Peer jedem BSP-Peer eine Nachricht sendet.
Die Synchronisation der einzelnen BSP-Peers erfolgt in Zeile 8. Die Nachrichten werden in
der Synchronisationsphase (Barriere) verteilt und sind erst nachdem alle BSP-Peers die Barriere
verlassen haben verfügbar. Diese Methode muss von allen BSP-Peers aufgerufen werden, da
sonst eine SyncException geworfen und der Job beendet wird. Es gibt also nicht die Möglichkeit
z.B. nur ausgewählte BSP-Peers miteinander zu synchronisieren.
1 @Override
2 public void bsp (BSPPeer<NullWritable, NullWritable, Text, DoubleWritable, Text> peer)
3 throws ... {
4 for (int i=0; i<100; i++) {
5 for (String peerName : peer.getAllPeerNames()) {
6 peer.send(peerName, new Text("Hello from " + peer.getPeerName()));
7 }
8 peer.sync();
9 }
10 }
Listing 2.3: Beispiel der Kommunikation zwischen BSP-Peers

Kapitel 3
Anforderungsanalyse
In diesem Kapitel werden zu Beginn zwei Studien vorgestellt, welche unterschiedliche Ansätze
zur Verteilung eines künstlichen Neuronalen Netz in einem Cluster untersuchen. Im zweiten
Unterkapitel wird das MLP-Framework analysiert. Sowohl die Erkenntnisse aus den Studien als
auch die Analyse des Frameworks sind die Grundlage, für die am Ende des Kapitels formulierte
Zielstellung.
3.1 Verwandte Studien
3.1.1 Studie 1: Using the BSP Cost Model to Optimize Parallel
Neural Network Training
In ihrer Arbeit untersuchen Rogers et al. verschiedene Methoden zur Verteilung eines MLP mit
dem BSP Modell und BGD (siehe [RS98]). Sie unterscheiden zwischen Exemplar Parallelism
(EP), Block Paralellism (BP) und Neuron Parallelism (NP).
Bei EP erhält jeder BSP-Peer das Modell, so dass alle Rechner den gleichen Stand haben.
Die BSP-Peers berechnen den Gradienten für ihren Teil der Daten, berechnen den Gradienten-
Durchschnitt und das Gewichtsupdate. Zum Ende einer Iteration hat jeder BSP-Peer ein Modell,
das mit allen Trainingsdaten trainiert wurde. Bei BP wird das Modell in Blöcke von benachbar-
ten Neuronen aufgeteilt, dabei ist ein BSP-Peer für die Berechnungen eines Blocks zuständig.
Wenn jeder Block alle Neuronen einer Schicht enthält, wird das Layer Parallelism genannt.
Bei NP wird jedem BSP-Peers die gleiche Anzahl von Neuronen zugewiesen, dabei werden die
Neuronen zufällig zugeteilt. Die Lokalität wird bei NP also nicht berücksichtigt.
Rogers et al. beweisen in Ihrer Arbeit, dass sich EP am besten zur Parallelisierung eines
MLP eignet. Dies liegt darin begründet, dass hier die Anzahl an Supersteps und Synchronisati-
onsphasen am geringsten ist. Die Kommunikationskosten sind bei EP demzufolge ebenfalls am
kleinsten.

KAPITEL 3. ANFORDERUNGSANALYSE 22
3.1.2 Studie 2: Large Scale Distributed Deep Networks
Dean et al. beschreiben in ihrer Arbeit (siehe [DCM+
12]) die Verteilung der Berechnung eines
neuronalen Netzes in einen Cluster, mit ihrem Framework: „DistBelief“. Zur Verteilung be-
Abbildung 3.1: Verteilung eines neuronalen Netzwerks, am Beispiel lokal verbundener Neuro-
nen.2
nutzen sie Block Parallelism. Das Modell wurde, wie in Abbildung 3.1 dargestellt, in mehrere
Partitionen gesplittet und dann auf mehrere Rechner verteilt.
Diese Form der Modellverteilung wurde u.a. auf ihre horizontale Skalierbarkeit untersucht.
Dabei stellte sich hier heraus, dass neuronale Netze mit lokal verbundenen Neuronen eine bes-
sere Skalierbarkeit aufweisen, als Netze mit voll verbundenen Neuronen. Das liegt laut Dean
et al. darin begründet, dass neuronale Netze mit lokal verbundenen Neuronen geringere An-
forderungen an die Kommunikation stellen. In Abbildung 3.1 wird der Kommunikationsﬂuss
zwischen den Rechnern durch die dickeren Linien dargestellt.
Abbildung 3.2: Links: Downpour SGD. Rechts: Sandblaster L-BFGS3
2Quelle: siehe [DCM+12]
3Quelle: siehe [DCM+12]

Dean et al. beschreiben unterschiedliche Vorgehensweisen für SGD- und BGD-Verfahren, die
in Abbildung 3.2 schematisch dargestellt werden. Beiden Ansätzen ist gemein, dass nicht alle
Rechner eines Clusters auf einen oder mehrere langsamere Rechner warten müssen.
Bei SGD wird das Modell auf voneinander unabhängige Rechnergruppen verteilt. Jede Rech-
nergruppe komuniziert asynchron mit einem Parameterserver. Die einzelnen Rechnergruppen
berechnen Gewichtsupdates für ihren Teil der Daten, senden das Gewichtsupdate an den Pa-
rameter Server und erhalten im Gegenzug das neueste Modell. Dies hat zur Folge, dass jede
Gruppe mit einem leicht unterschiedlichen Modell arbeitet.
Eine Besonderheit des hier vorgestellten BGD-Ansatzes ist, dass für N-Rechnergruppen, die
Batchgröße durch einen Wert kleiner N geteilt wird. Die Kommunikation außerhalb der Rech-
nergruppen erfolgt auch hier asynchron und wird zusätzlich durch einen Coordinator-Server
gesteuert.
Die hier benutzten Verfahren stellen eine Mischung aus Exemplar und Block Parallelism
dar. Die einzelnen Rechnergruppen benutzen Block Parallelism. Die Arbeit wird aber wie bei
Exemplar Parallelism, durch Aufteilen der Datensätze auf die einzelnen Rechnergruppen para-
llelisiert. Zusammenfassend lässt sich hier feststellen, dass durch die asynchrone Kommunikation
eine hohe Flexibilität erreichbar ist, die mit BSP nicht realisierbar ist.
Zusammenfassung
Wie gut sich ein künstliches neuronales Netz in einem Cluster verteilt trainieren lässt, dass hängt
u.a. davon ab wie die Berechnungen verteilt werden bzw. wie das neuronale Netzes aufgebaut
ist. In den untersuchten Studien wurden zwei unterschiedliche Ansätze untersucht. Rogers et
al. verfolgten einen synchronen Ansatz mit BSP und betrachteten voll verbundene künstliche
neuronale Netze. Dean et al. verfolgten einen asynchronen Ansatz und untersuchten sowohl voll
als auch lokal verbundene Netze.
Sowohl Rogers et al. als auch Dean et al. kamen zu dem Schluss, dass sich voll verbundene
Netze mit Block Parallelism nur stark begrenzt verteilen lassen. Dean et al. stellten weiter-
hin fest, dass lokal verbundene Netze mit Block Parallelism besser als voll verbundene Netze
skalieren, da hier die Kommunikationskosten geringer sind. Lokal verbundene Netze skalieren
laut Dean et al. mit BP, in Abhängigkeit von der Modellgröße, je größer um so besser ist die
Skalierbarkeit.
Rogers et al. empfehlen die Benutzung von Exemplar Parallelism. Dean et al. kombinieren
Exemplar und Block Parallelism miteinander, was so aber nicht mit BSP sinnvoll realisierbar
ist.
Im Rahmen dieser Arbeit sind lokal verbundene Netze nicht Gegenstand der Untersuchung.
Aus den oben genannten Gründen wird deshalb Exemplar Parallelism verwendet.

3.2 Analyse des MLP Frameworks
An dieser Stelle soll das verwendete MLP Framework näher betrachtet werden, um daraus
folgend die Zielstellungen zu deﬁnieren.
3.2.1 Speicherung der Verbindungsgewichte
In dem Framework werden Verbindungsgewichte, wie in Abschnitt 2.1 beschrieben, in Form von
Matrizen gespeichert. Als Eingabe werden Vektoren erwartet. In Folge daraus werden auch alle
Rechenoperationen entweder auf Matrizen- oder Vektoren angewandt.
Die dafür benutzten Klassen entstammen der Mathe-Bibliothek des Apache Mahout Pro-
jekts (siehe [Apa]). Bei genauerer Untersuchung der Mathe-Bibliothek wurde im Rahmen dieser
Arbeit festgestellt, dass die Multiplikation zweier Matrizen recht einfach mit der Standard-
Matrizenmultiplikation gelöst wurde. Hier existieren u.a. der Strassen oder der Winograd Al-
gorithmus, die eﬃzienter als das Standardverfahren sind (siehe [CH13]).
Laut mehreren Benchmarks (siehe [Abe]) gibt es eine Reihe von leistungsfähigen Frameworks
für die lineare Algebra. Ein performantes Framework scheint laut diesen Benchmarks z.B. jblas
(siehe [Bra]) zu sein, dass ein Java-Wrapper für BLAS/LAPACK (siehe [TCCDL]) und ATLAS
(siehe [det]) ist.
Daraus folgt, dass die im MLP-Framework verwendete Matrizenbibliothek austauschbar sein
und dessen Performanz mit anderen Bibliotheken verglichen werden sollte.
3.2.2 Lernverfahren
In dem MLP Framework wurde ein auf Verfahren erster Ordnung basierender SGD implemen-
tiert, dass heißt, dass jedes Trainingsbeispiel auch ein Gewichtsupdate zur Folge hat. Dies kann
mit BSP und EP nicht unverändert verwendet werden. Hier gilt es also die Berechnung der Gra-
dienten von den Gewichtsupdates zu trennen. Auch der implementierte Sparse Autoencoder ist
ein Online-Lerner und muss angepasst werden.
Zur Berechnung der Gradienten wird das Backpropagation Verfahren verwendet. Als Opti-
mierungsverfahren wurde Momentum implementiert.
3.2.3 Tests
Es wurden eine Reihe von Softwaretests implementiert. Hervorzuheben ist der Test des Backpro-
pagation Verfahrens. Hier wird der vom Framework berechnete Gradient mit einem numerischen
Annäherungsverfahren überprüft (siehe [And][Seiten 10-12]).
Laut diesen Tests, ist das MLP korrekt implementiert worden. Ein Test des Sparse Auto-
encoder fehlt. Allerdings wird der Sparse Autoencoder im Rahmen dieser Arbeit auch nicht
verwendet.

3.3 Zielstellung
In dem folgenden Kapitel wird die Zielstellung detailliert formuliert. Die darin formulierten
funktionalen Anforderungen, bezüglich der Initialisierung des MLP und der Trainingsalgorith-
men, ergeben sich aus den bereits in den Grundlagen beschriebenen Verfahren. Die restlichen
funktionalen Anforderungen entstammen der Entwurfsphase, siehe Kapitel 4.
3.3.1 Funktionale Anforderungen
Cache
• Cache:
Beschreibung: Es soll die Möglichkeit geben, die Eingabedaten im Arbeitsspeicher zu
halten.
Datenformat
• Datenformat:
Beschreibung: Es soll für diese Anwendung ein allgemeingültiges Datenformat entwickelt
werden.
Datenaufbereitung
• Dictionary:
Beschreibung: Es soll die Möglichkeit geben, die Eingabe- und Ausgabeneuronen mit
einem Wörterbuch zu verknüpfen, um die Ergebnisse im Falle der von Xing extrahierten
Proﬁldaten evaluieren zu können.
• Normalisierung:
Beschreibung: Je nach Anwendungsfall sollen Eingabedaten beim Parsen normalisiert wer-
den können.
• Parser:
Beschreibung: Es sollen Quell-Daten geparst und in das eigens entwickelte Datenformat
überführt werden.
Datenspeicherung
• Datenspeicherung:
Beschreibung: Es soll die Möglichkeit geben, das trainierte neuronale Netz abzuspeichern,
um es später weiter trainieren oder auswerten zu können.

Evaluierung der Ergebnisse
• Datenformat:
Beschreibung: Es soll die Möglichkeit geben, ein trainiertes neuronales Netz zu evaluieren.
Die Metriken Precision, Recall und F-measure sollen zur Auswahl stehen.
Fehlerwert
• Fehlerwert:
Beschreibung: Es soll die Möglichkeit geben, den durchschnittlichen Fehlerwert über alle
Trainingsdaten zu berechnen.
Kommunikation
• Kommunikation:
Beschreibung: Es sollen verschiedene Kommunikationsstrategien implementiert werden.
Initialisierung der Gewichte
• Glorot-Bengio:
Beschreibung: Es soll möglich sein, das Verfahren von Glorot-Bengio zur Initialisierung
des neuronalen Netzes zu benutzen.
• Ngyen-Widrow:
Beschreibung: Es soll möglich sein, das Verfahren von Ngyen-Widrow zur Initialisierung
• Yann Lecun:
Beschreibung: Es soll möglich sein, das Verfahren von Yann Lecun zur Initialisierung des
neuronalen Netzes zu benutzen.
Matrizenbibliothek
• Matrizenbibliothek:
Beschreibung: Es soll die Möglichkeit geben, die Matrizenbibliothek auszutauschen.
Trainingsalgorithmen
• Adagrad:
Vorbedingung: Es wird nicht Resilient Propagation benutzt.
Beschreibung: Es soll die Möglichkeit geben, Adagrad zum Trainieren des neuronalen
Netzes zu benutzen.
• Batch Gradient Descent:
Beschreibung: Es soll die Möglichkeit geben, Big-Batch Lernverfahren zum Trainieren des

• Mini-Batch Gradient Descent:
Beschreibung: Es soll die Möglichkeit geben, Mini-Batch Lernverfahren zum Trainieren
• MLP-Framework:
Beschreibung: Es soll das bereits bestehende MLP-Framework in die Anwendung integriert
werden.
• Momentum:
Beschreibung: Es soll die Möglichkeit geben, bei Bedarf Momentum zu benutzen.
• Resilient Propagation:
Vorbedingung: Big-Batch Lernverfahren. Der Fehlerwert wurde für die letzten beiden
Iterationen berechnet.
Beschreibung: Es soll die Möglichkeit geben, Resilient Propagation zum Trainieren des
• Denoising Autoencoder:
Beschreibung: Es soll die Möglichkeit geben, die Eingabedaten in Verbindung mit einem
Autoencoder zu verrauschen.
3.3.2 Nicht-Funktionale-Anforderungen
Skalierung
• Skalierung:
Beschreibung: Das System sollte eine gute horizontale und vertikale Skalierbarkeit auf-
weisen.
3.3.3 Abgrenzungskriterium
Im Rahmen dieser Arbeit werden nur MLP mit einer versteckten Schicht betrachtet. Weiterhin
wird davon ausgegangen, dass das zu trainierende Modell in den Arbeitsspeicher passt. Die
Berechnungen werden nach Exemplar Parallelism verteilt. Der Sparse Autoencoder wird nicht
implementiert.

Kapitel 4
Entwurf
In diesem Kapitel wird die Anwendung entworfen. Es werden das System und einzelne System-
komponenten beschrieben und verschiedene Ansätze zur Realisierung diskutiert. Der Sparse
Autoencoder wurde zwar nicht implementiert, dennoch wird für zukünftige Arbeiten das hierzu
nötige Vorgehen am Ende des Kapitels beschrieben.
4.1 Systembeschreibung
Datenvorverarbeitung
Daten
bereinigen

(op.onal)

Daten
normalisieren

(op.onal)

Trainings-‐/

Evalua.onsdaten

erzeugen

Training des künstlichen neuronalen Netzes
(MLP)
Modell

verteilen

MLP

ini.alisieren/

verteilen

Trainingsdaten
lesen
/

GradientendurchschniA

berechnen

Quelldaten

einlesen

Einstellungen

laden

Gewichtsupdate
berechnen
/

Modell
updaten

Modell

speichern

(op.onal)

Evaluation
Modell

laden

Metriken

berechnen

Ergebnisse

ausgeben

Evalua.onsdaten

einlesen

Daten
cachen

(op.onal)

X-Iterationen
Abbildung 4.1: Systemübersicht

KAPITEL 4. ENTWURF 30
Im Rahmen dieser Arbeit soll eine Anwendung zum verteilten Trainieren eines MLP erstellt
werden. Diese Anwendung muss eine Reihe von Aufgaben erfüllen, die sich in Datenvorverar-
beitung, Training und Evaluation des trainierten MLP gliedern lassen (siehe Abbildung 4.1).
Innerhalb der Datenvorverarbeitung findet das Parsen der Quelldaten statt. Je nach Anwen-
dungsfall findet an dieser Stelle auch eine Bereinigung und Normalisierung der Daten statt. Der
Trainingsvorgang ist ein iteratives Verfahren mit mehreren Einzelschritten. Bevor das Trai-
ning beginnt werden Einstellungen geladen, das MLP auf allen BSP-Peers mit den gleichen
Werten initialisiert und falls gewünscht die Trainingsdaten gecacht. Die Evaluation erlaubt die
Bewertung des trainierten Netzwerks.
Diese Schritte werden in den nachfolgenden Unterkapiteln genauer beschrieben.
4.1.1 Datenvorverarbeitung
Die Datenvorverarbeitung erfolgt in einer Pipeline von mehreren aufeinander aufbauenden
Schritten. Nachdem sie eingelesen wurden, müssen die Quelldaten eventuell bereinigt werden.
Im Falle der Textverarbeitung sind hier eine Reihe von Schritten denkbar. So könnten Stoppwör-
ter entfernt werden. Das sind z.B. bestimmte/unbestimmte Artikel oder Konjugationen, die mit
Hilfe einer „part of speech“ (POS) Erkennung ermittelt werden. Sie kommen meist sehr oft vor,
sind aber für die eigentliche Analyse nicht von Bedeutung. Ein Beispiel für die POS Erkennung,
ist der Log-linear Part-Of-Speech Tagger der Stanford NLP-Gruppe (siehe [TKMS03]).
Außerdem könnten z.B. Texte einer nicht unterstützten Sprache entfernt werden, wenn nur
deutsche Texte verarbeitet werden sollen. Im nächsten Schritt müssen je nach Anwendungs-
fall die Quelldaten normalisiert werden. Im Falle von Textdaten könnten einzelne Wörter auf
ihren Wortstamm zurückgeführt werden (stemming, Lemmatisierung, siehe [MS99] Seiten 131-
134). Andernfalls kann es vorkommen, dass Wörter mit dem gleichen Wortstamm mehrmals im
Eingabevektor vorkommen.
Die Wörter im Eingabevektor, könnten weiterhin mit der Term Frequenz und der Dokumen-
tenhäufigkeit gewichtet werden (Term weighting, siehe [MS99] Seiten 541f). Mit dieser Form
der Gewichtung, werden Wörter die sehr oft vorkommen, aber evtl. geringen Informationsge-
halt haben, geringer gewichtet, als Wörter die sehr selten vorkommen, aber evtl. einen großen
Informationsgehalt haben. In einem binären Wortvektor erfolgt keine solche Gewichtung, da
hier nur enthalten ist, ob ein Wort in einem Satz vorkam oder nicht, was eventuell negative
Auswirkungen auf die Ergebnisse des Trainings hat.
Sollen Zahlenwerte als Eingabe benutzt werden, die in unterschiedlichen Wertebereichen
vorkommen, dann sollten diese laut Cabreira et al. (siehe [CTM09]) in einen gemeinsamen
Wertebereich überführt werden (siehe Anhang E, Seite 93). Die Skalierung kann laut Cabreira
et al. zu besseren Resultaten führen. Im Falle der MONK-Daten erfolgte deshalb eine Skalierung
aller Eingabedaten auf den Wertebereich: [0, 1].
Zum Schluss müssen die Daten schließlich geparst und gespeichert werden. Die Daten werden
im verteilten Dateisystem HDFS gespeichert. Hier wurde sich für ein Textformat entschieden,

um die Trainingsdaten leicht mit anderen Frameworks austauschen zu können. Das zugrunde-
liegende Datenformat wird in dem folgenden Unterkapitel beschrieben.
Datenformat
< data >:=< labels > | < features > (4.1)
< labels >:=< indexL1 >:< valueL1 > < indexL2 >:< valueL2 > ... (4.2)
< features >:=< indexF1 >:< valueF1 > < indexF2 >:< valueF2 > ... (4.3)
Im Rahmen dieser Arbeit wird zum Beschreiben von Trainingsdaten, dass in Gleichung 4.1,
Gleichung 4.2 und Gleichung 4.3 dargestellte Datenformat genutzt. Es entspricht einer Erwei-
terung des u.a. in LIBSVM (siehe [CL11]) verwendeten Datenformats.
Die Ein- (Features) und Ausgabedaten (Labels) werden durch „|“ voneinander getrennt. Im
Gegensatz zu LIBSVM werden mehrere Label unterstützt, die genau wie die Features durch ein
Leerzeichen voneinander getrennt sind.
Jedes Wertepaar besteht aus einem Index und einem Wert. Die Indizes müssen vom Typ
Integer sein. Sie entsprechen dem Index im Ein- bzw. im Ausgabevektor, beginnend bei null. Die
dazugehörigen Werte müssen vom Typ Double sein. Es müssen nur Werte angegeben werden,
die ungleich null sind. Die Werte fehlender Indizes werden als gleich null betrachtet und belegen
unter Verwendung eines „sparse Vector“ keinen Arbeitsspeicher.
Um Trainingsdaten zu erzeugen, die dem oben beschriebenen Datenformat entsprechen,
muss für jeden Anwendungsfall ein Parser geschrieben werden. Der Parser überführt dann die
Quelldaten in das Trainingsdatenformat.
4.1.2 verteiltes Training mit BSP
Wie in Abbildung 4.1) auf der Seite 29 dargestellt, ist der Trainingsvorgang ein iteratives Ver-
fahren, das eine Reihe von Einzelkomponenten voraussetzt. Dieses Kapitel gibt einen Überblick
über das Trainingsverfahren und beschreibt das Cachen von Daten im Arbeitsspeicher, die Feh-
lerwertberechung und mehrere Ansätze der Kommunikation. Der Trainings-Algorithmus wird
noch einmal detaillierter in Form von Pseudo-Code in Anhang F auf der Seite 95 dargestellt.
In Abbildung 4.2 (Seite 32) wird das verteilte Training eines neuronalen Netzes für eine
Iteration dargestellt. Die Parallelisierung des Trainings ergibt sich aus Gleichung 2.9 auf Seite 9,
indem die Berechnung des Gradienten parallelisiert wird. Die Trainingsdaten werden in mehrere
Partitionen gesplittet. Die Anzahl an Partitionen entspricht der Anzahl an BSP-Peers. Das
Training erfolgt in zwei Phasen.
In der ersten Phase berechnet jeder BSP-Peer den Gradienten, für seinen Anteil an den
gesamten Trainingsdaten. Die Gradienten werden aufsummiert und zum Ende dieser Phase
durch die Batchgröße geteilt. Wenn alle BSP-Peers damit fertig sind, senden sie ihre partielle
Summe an einen Master-Peer.

Par$$on
I
Par$$on
III
Par$$on
II

Par$al
Gradient
Sum
Par$al
Gradient
Sum
Par$al
Gradient
Sum

Gradient
Sum

Synchroniza$on
Barrier

Synchroniza$on
Barrier

Compute
Model
Update
&
Distribute
Model

Abbildung 4.2: Schematische Darstellung des Vorgehens innerhalb einer Iteration.
In der zweiten Phase berechnet der Master-Peer aus den partiellen Summen den Gradien-
ten1
. Der Gradient wird dann zur Berechnung des Gewichtsupdates benutzt, das dann auf das
Modell angewendet wird. Das neue Modell wird schließlich an alle BSP-Peers verteilt und die
nächste Iteration beginnt. Das Vorgehen entspricht Exemplar Parallelism.
Das hier beschriebene Vorgehen, ließe sich auch mit dem MapReduce Ansatz realisieren. Die
erste Phase ließe sich mit der Map-Phase und die zweite Phase mit der Reduce-Phase abbilden.
Zumindest die MapReduce Implementierung von Apache Hadoop (siehe [Whi11][Seiten 167ﬀ])
hat jedoch den Nachteil, dass sie keine Iterationen unterstützt. Das heißt hier müsste für jede
Iteration ein neuer Job gestartet werden, wodurch auch für jede Iteration das Modell neu geladen
und gespeichert werden müsste.
Caching
Um ein MLP mit den hier vorgestellten Verfahren zu trainieren, bedarf es eine große Anzahl von
Iterationen. In jeder Iteration müssen die gleichen Trainingsdaten geladen und geparst werden.
Hier bietet es sich an, Trainingsdaten im Arbeitsspeicher zu halten. Dies wird aber von Apache
Hama nicht direkt unterstützt.
Hier sind mehrere Vorgehensweisen denkbar. Zum einen könnte man die geparsten Daten im
Arbeitsspeicher halten. Zum anderen könnte man die Daten serialisieren, komprimieren, kom-
primiert im Speicher halten und nur bei Bedarf dekomprimieren und de-serialisieren. Letztere
Variante würde sich anbieten, wenn der Arbeitsspeicher der Rechner nicht ausreichend groß ist.
1Die Gradientensumme wird bei der Binary Tree Kommunikation bereits in der Kommunikationsphase ge-
bildet (siehe Abschnitt 4.1.2, 35).

Für diese Arbeit wird die erste Variante implementiert. Von jedem BSP-Peer wird der jeweils
zugewiesene Anteil an den Trainingsdaten komplett im Speicher gehalten. Weitere Strategien
zur Realisierung eines Caches sollten in zukünftigen Arbeiten untersucht werden.
Apache Hama bietet wie bereits erläutert keine Methoden zum Cachen von Daten. Der
Cache könnte aber mit einem Wrapper, um die von Apache Hama gebotene Funktionalität zum
Laden von Daten, realisiert werden. Hier bietet sich z.B. die Aspektorientierte Programmierung
mit aspectj (siehe [Fou]) an, da es sich bei dieser Anforderung um einen „cross-cutting concern“
handelt. Aus Zeitgründen musste jedoch auf aspectj verzichtet werden.
Fehlerwertberechnung
Die Berechnung des Fehlerwerts ist für das Trainieren eines Netzwerks essentiell. Er ist ein Maß
dafür, wie gut sich ein künstliches neuronales Netz an die Trainingsdaten angepasst hat.
Für die Fehlerwertberechnung wird festgelegt, dass der Fehlerwert sowohl bei BGD als auch
bei MBGD über alle Trainingsdaten berechnet wird. Der Fehlerwert wird bei beiden Verfahren
außerdem nur dann berechnet, wenn das MLP mit allen Trainingsdaten trainiert wurde. Zum
einen schwanken dadurch die Fehlerwerte nicht so stark, als wenn sie nur für einen Teil der Daten
berechnet würden, zum anderen lassen sich mit BGD oder MBGD ermittelte Fehlerwerte besser
vergleichen.
Der Zeitpunkt zur Berechnung des Fehlerwerts bei MBGD bzw. bei BGD kann unterschied-
lich gewählt werden. Zur Berechnung des Gradienten,für ein Trainingsbeispiel, wird der Output
des neuronalen Netzes benötigt (siehe Gleichung 2.12 auf Seite 11). Dieser Output wird auch
zur Berechnung des Fehlerwertes für dieses Trainingsbeispiel verwendet (vgl. mit Gleichung 2.8
auf Seite 9). Um den Output nicht zweimal zu berechnen, sollte der Fehlerwert bei BGD zu-
sammen mit dem Gradienten berechnet werden. Dabei gilt es zu beachten, dass der Fehlerwert
für das in der vorherigen Iteration berechnete Modell gilt.
Bei MBGD kann dieser Vorteil nicht genutzt werden, da sich mit jedem Mini-Batch auch
das Modell ändert, was den Fehlerwert verfälschen würde. Der Fehlerwert kann bei MBGD also
nur dann berechnet werden, wenn über alle Trainingsdaten iteriert wurde.
Kommunikation
Bei der Betrachtung der Kommunikation, gilt es einige Dinge zu berücksichtigen. So muss
zwischen der Kommunikation von Prozessen auf dem selben Rechner und der Kommunikation
über Rechnergrenzen hinweg unterschieden werden.
Bei letzterem erstellt man üblicherweise eine Kostenmatrix und einen Verbindungsgraphen,
in dem dargestellt wird welcher Rechner mit welchem Rechner verbunden ist. In den Ver-
bindungsgraphen ﬂießen die Verbindungskosten ein. Dazu gehört nicht die rein physikalische
Entfernung zwischen zwei Rechnern, sondern die verfügbare Bandbreite und die Latenz. Der
kürzeste Weg zwischen zwei Rechnern würde z.B. mit dem Dijkstra-Algorithmus berechnet wer-
den. Dadurch könnte u.a. die Kommunikation zwischen Rechnern in unterschiedlichen Rechen-

zentren optimiert werden. Darauf muss allerdings im Rahmen dieser Arbeit aus Zeitgründen
verzichtet werden.
Im Rahmen dieser Arbeit wird angenommen, dass die Kommunikationskosten für alle Rech-
ner gleich groß sind, unabhängig davon mit welchem Rechner sie kommunizieren. Es wird weiter
angenommen, dass alle Rechner sich in dem selben physikalischen Netzwerk befinden und über
einen Switch miteinander verbunden sind. Die Rechner kommunizieren über Punkt-zu-Punkt
Verbindungen und teilen sich nicht die verfügbare Bandbreite, wie es in einem über Hub ver-
bundenen Netzwerk der Fall wäre.
Das in Listing F.1 auf der Seite 95 beschriebene Verfahren stellt unterschiedliche Anfor-
derungen an die Kommunikation. Die Synchronisation der Rechner wird durch Apache Hama
geregelt und hier nicht weiter betrachtet.
In den Zeilen 12-13 bzw. 20-21 wird ein Durchschnitt berechnet. Das heißt, hier müssen
Daten von mehreren BSP-Peers eingesammelt und daraus dieser Wert berechnet werden. In der
Fachliteratur ist diese Kommunikationsform als „all-to-one reduction“ bekannt (siehe [Kri94],
Seite 147ff).
Im Gegensatz dazu, muss in Zeile 13 bzw. in Zeile 25 ein Wert von einem BSP-Peer an
alle anderen BSP-Peers verteilt werden. In der Fachliteratur ist diese Kommunikationsform als
„one-to-all broadcast“ bekannt (siehe [Kri94], Seite 147ff).
Wie bereits beschrieben unterstützt Apache Hama nur Punkt-zu-Punkt Verbindungen, wes-
halb im Rahmen dieser Arbeit verschiedene Kommunikationsstrategien entwickelt wurden. In
den folgenden Unterkapiteln werden diese Ansätze näher betrachtet.
Sequentielle Kommunikation. Sequentiell bedeutet, dass Aufgaben nacheinander und
nicht parallel verarbeitet werden. Das trifft streng genommen, nur für den ersten, der nach-
folgend beschriebenen Abläufe zu.
Im „one-to-all broadcast“ werden Daten von einem BSP-Peer an alle BSP-Peers gesendet.
Das erfolgt in diesem Ansatz sequentiell. Der BSP-Peer sendet also nacheinander die Daten
an die anderen BSP-Peers, dabei wird nicht zwischen lokalen BSP-Peers und BSP-Peers auf
entfernten Rechnern unterschieden. Die Gesamtdauer der Kommunikation verhält sich linear
zur Anzahl an BSP-Peers. Die verfügbare Bandbreite, zwischen zwei BSP-Peers, kann durch die
Punkt-zu-Punkt Verbindung voll ausgenutzt werden. Ein Nachteil dieses Ansatzes ist jedoch,
dass immer nur zwei BSP-Peers miteinander kommunizieren, während die restlichen BSP-Peers
warten müssen.
Die Berechnung des Durchschnitts erfolgt auf jedem BSP-Peer2
. Die daraus resultierenden
Daten werden dann von allen BSP-Peers zur gleichen Zeit an den Master-Peer gesendet. Der
Master-Peer bildet nur noch die Summe der Einzelergebnisse. Auch bei dieser Kommunikati-
2Die von jedem BSP-Peer berechneten Einzelergebnisse werden lokal aufsummiert und durch die gesamte
Anzahl an Trainingsdaten bzw. bei MBGD durch die Mini-Batch-Größe mulipliziert mit der Anzahl an BSP-
Peers geteilt.

onsstrategie wird nicht zwischen lokalem und entfernten BSP-Peer unterschieden. Die Kom-
munikation erfolgt parallel, es wird allerdings auch die verfügbare Bandbreite zwischen allen
BSP-Peers aufgeteilt.
Die sequentielle Kommunikation ist bei beiden Strategien innerhalb eines Supersteps abge-
schlossen. Sie ist sehr einfach zu implementieren und ausreichend schnell, wenn ausschließlich
lokale Prozesse miteinander kommunizieren, da zwischen lokalen Prozessen die Kommunikati-
onskosten vernachlässigbar gering sind.
Abbildung 4.3: Binary Tree Kommunikation in drei Phasen am Beispiel von acht Rechnern3
Binary Tree Kommunikation. In diesem Verfahren, werden Daten in mehreren Supersteps
verteilt. Das Vorgehen ist beispielhaft in Abbildung 4.3 für acht Rechner dargestellt. Jedem
Rechner wurde eine eindeutige Zahl als Name zugewiesen, beginnend mit der Zahl: eins.
Sei m die gesamte Anzahl an Rechnern, x die Nummer des Rechners der Daten sendet, y
die Nummer des Rechners an den Daten gesendet werden, n die Schrittnummer und nmax die
maximale Zahl von Schritten. Dann kommunizieren in jedem Schritt 2n
Rechner miteinander.
Die Schrittnummer beginnt mit der Zahl: eins und wird für jede Iteration um eins hochgezählt.
Welcher Rechner jeweils mit welchem Rechner kommuniziert, ergibt sich dann aus der For-
mel: y = x + 2n−1
. Ein Rechner kommuniziert nur dann, wenn gilt: y <= 2n
. Daraus folgt
schließlich: nmax = log2 m. Ist Es muss log2 m, wenn es keine ganze Zahl ist, auf die nächste
ganze Zahl aufgerundet werden.
Bei der „all-to-one“ Kommunikation, wird dieses Verfahren einfach umgedreht. Diesmal wird
die Schrittnummer n runtergezählt und zu Beginn gilt: n = nmax = log2 m. Weiterhin gilt:
y = x − 2n−1
. Ein Rechner kommuniziert nur, wenn gilt: 0 < y <= 2n−1
. Das Aufsummieren,
der durch die Batch-Größe geteilten Daten, erfolgt hier, im Gegensatz zum sequentiellen Ansatz,
bereits während der Kommunikation. Jeder Empfänger einer Nachricht bildet die Teilsumme,
über die in der Nachricht enthaltenen und den lokal vorliegenden Daten
Für die Binary Tree Kommunikation wird zwischen lokalen und entfernten BSP-Peers diﬀe-
renziert. Ansonsten würden sich die miteinander kommunizierenden BSP-Peers die Netzwerk-
Bandbreite teilen, was wieder zu Lasten der Performance gehen würde. Bevor also über das
Netzwerk kommuniziert wird, senden alle lokalen BSP-Peers ihre Daten an einen lokalen BSP-
Peer. Die gesamte Kommunikation ist in nmax + 1 Supersteps abgeschlossen.

Binary Tree ist optimal, wenn die Rechneranzahl eine Potenz von zwei ist. Der worst case
ist gegeben, wenn die Rechneranzahl um eins größer als eine Potenz von zwei ist, da hier in der
letzten Kommunikationsphase bis auf zwei Rechner alle Rechner warten müssen.
Zusammenfassung Die Kommunikationskosten werden maßgeblich von zwei Faktoren be-
stimmt, der zu übertragenden Datenmenge und der Kommunikationsform. Die Datenmenge
wird dominiert von der Anzahl an Neuronenverbindungen. Sie verhält sich linear zur Anzahl
an Neuronenverbindungen, außerdem besteht ein quadratischer Zusammenhang zur Anzahl an
Neuronen. Verdoppelt man die Zahl der Neuronen, dann vervierfacht sich die Anzahl an Neu-
ronenverbindungen, in einem voll verbundenen Netz mit einer versteckten Schicht.
Bezüglich der Kommunikationsform ist zu erwarten, dass die sequentielle Kommunikation
langsamer als die Binary Tree Kommunikation ist, sobald über Rechnergrenzen hinweg kommu-
niziert wird. Die Kommunikationskosten werden hier vermutlich deutlich schneller steigen, so
dass ab einer bestimmten Rechneranzahl keine nennenswerte horizontale Skalierung mehr ge-
geben ist. Es wurden dennoch beide Ansätze implementiert, da für lokale Tests die sequentielle
Kommunikation ausreicht.
Das Problem der „one-to-all broadcast“ Kommunikation, gleicht dem Problem von verteilten
Dateisystemen und Peer-2-Peer Netzen. Ein interessanter Ansatz könnte z.B. „Chunk based
parallel tree“ sein (siehe [BRF04][Seite 10]), der aber aus Zeitgründen nicht weiter untersucht
werden konnte. Hier gilt es in zukünftigen Arbeiten eine optimale Vorgehensweise zu ﬁnden.
4.1.3 Evaluation
Die Evaluation dient der Qualitätsmessung und wird nach dem Training des künstlichen neu-
ronalen Netzes ausgeführt. Üblicherweise wird die Evaluation mit einem Satz von Daten („gold
standard“4
) durchgeführt, die nicht Teil der zum Trainieren verwendeten Daten sind, um ein
Auswendiglernen zu erkennen bzw. zu vermeiden.
Für die Evaluation spielen in dieser Arbeit, sowohl die Neuronen in der versteckten Schicht,
als auch die Neuronen in der Ausgabeschicht eine Rolle. Welche Form der Evaluation angewen-
det wird hängt vom Anwendungsfall ab.
Im Falle der Klassiﬁzierung und der Regression sind nur die Neuronen in der Ausgabeschicht
von Bedeutung. Es werden nacheinander alle Daten des Testsets als Eingabe angelegt, dabei
wird jeweils die Ausgabe ausgewertet. Im Falle der MONK-Daten liegen die Ausgabewerte im
Bereich: [0, 1]. Ein Wert größer 0.5 gilt als zu Klasse I gehörig. Ein Wert kleiner 0.5, gilt als
nicht zu Klasse I gehörig. Mit Hilfe aller Messwerte und der Metriken: Precision, Recall und
F-measure (siehe Anhang D, 91), wird dann die Qualität bestimmt. Außerdem wird für jede
Klasse der Durchschnittswert und die Standardabweichung aller Ergebnisse berechnet (siehe
4Manning et al. beschreiben hier (siehe [MRS08], Kapitel 8.1) zwar die Evaluation von „information retrieval“
Systemen mit einem „gold standard“ das Prinzip ist jedoch das gleiche.

Anhang C, Seite 89), um die Verteilung der Ergebnisse zu bestimmen. Je näher die Ergebnisse
des Testsets bei null bzw. bei eins liegen, um so besser ist das Netzwerk zumindest im Falle der
MONK-Daten trainiert worden.
Im Falle der Xing-Daten werden zusätzlich die Neuronen in der versteckten Schicht be-
trachtet. Jedes versteckte Neuron lernt ein bestimmtes Feature. Welches Features das ist, wird
ermittelt durch das Finden des Inputs, der den höchsten Ausgabewert bei dem versteckten
Neuron verursacht, dabei wird die Norm des Vektors begrenzt (siehe [And], Seiten 16-18). Mit
z gleich der Anzahl an Neuronen der Eingabeschicht, x gleich dem Eingabevektor und unter
der Bedingung: ||x2
|| =
z
i=1 x2
i ≤ 1 gilt,
xj =
W
(1)
ij
z
j=1(W
(1)
ij )2
(4.4)
Die obige Formel wird auf alle Neuronen der versteckten Schicht angewendet. Für jedes ver-
steckte Neuron erhält man einen Vektor, der zumindest im Falle der Xing-Daten nach der Größe
sortiert wird 5
. Der Inhalt des Vektors kann dann weiter ausgewertet werden.
4.2 Sparse Autoencoder
1 filePointer <- SaveFilePointer();
2 for(batchProcessed<= batchSize) {
3 activationSum <- activationSum+CalculateHiddenNeuronActivation();
4 }
5 SetFilePointer(filePointer);
6 CalculateAverageNeuronActivation();
7 DistributeAverageNeuronActivation();
Listing 4.1: Sparse Autoencoder mit BSP in Pseudocode
Wie in Gleichung 2.20 auf Seite 16 ersichtlich, muss das Backpropagation Verfahren bei Ver-
wendung des Sparse Autoencoder angepasst werden. Hier muss zusätzlich die Berechnung der
durchschnittlichen Neuronenaktivierung der Neuronen in der versteckten Schicht erfolgen (siehe
Listing 4.1, Zeilen 2-4). Dabei gilt es zu beachten, dass die durchschnittliche Neuronenaktivie-
rung nur für die im (Mini-) Batch zu verwendenden Trainingsdaten berechnet werden muss.
Bedingt durch den Datenzugriﬀ von Apache Hama, muss hierfür der Dateizeiger gespeichert
werden (siehe Listing 4.1, Zeile 1), z.B. durch das Zählen von bereits verarbeiteten Datensätzen.
Zum Abschluss dieses Zwischenschritts, muss der Dateizeiger wieder zurück gesetzt werden
(siehe Listing 4.1, Zeile 5), damit der Gradient für die gleichen Datensätze berechnet wird.
5Zum Beispiel bei Bilddaten, mit einzelnen Pixeln als Eingabe, muss man die Reihenfolge beibehalten.

Jeder BSP-Peer berechnet die Teilsumme der durchschnittlichen Aktivierung aller Neuronen
und sendet sie an den Master-Peer (siehe Listing 4.1, Zeile 6). Die durchschnittliche Neuro-
nenaktivierung wird je nach Kommunikationsstrategie auf dem Master-Peer oder als Teil der
Kommunikation ausgerechnet. Der Master-Peer verteilt die durchschnittliche Neuronenaktivie-
rung dann auf alle BSP-Peers (siehe Listing 4.1, Zeile 7), damit diese den Gradienten berechnen
können.
Die Neuronenaktivierung für jedes Trainingsbeispiel, wird auch für das danach folgende
Backpropagation Verfahren zur Berechnung des Gradienten benötigt (siehe Gleichung 2.12 und
Gleichung 2.13 auf Seite 11). Um diesen Schritt nicht zweimal auszuführen, könnte die Neuro-
nenaktivierung im Arbeitsspeicher gehalten und dort wiederverwendet werden.
Mit der sequentiellen Kommunikation werden zwei Supersteps benötigt. Mit der Binary Tree
Kommunikation werden 2 ∗ log2 m Supersteps benötigt.

Kapitel 5
Implementierung
Dieses Kapitel beschreibt im Detail, die Implementierung der im Entwurf vorgestellten System-
komponenten: Datenverarbeitung, Training und Evaluation. Außerdem enthält es am MLP-
Framework vorgenommene Änderungen, Details die bei der Verwendung von Apache Hama
beachtet werden mussten und eine Beschreibung der Softwaretests.
5.1 Datenverarbeitung
5.1.1 Cache
Der Cache wurde implementiert, indem die I/O-Methoden von Apache Hama in einer Methode
gekapselt wurden. Jeder BSP-Peer speichert nur seinen Teil der Daten in seinem Cache. In der
ersten Iteration, werden die I/O-Methoden von Apache Hama genutzt und der Cache gefüllt. Ab
der zweiten Iteration werden die Daten nur noch aus dem Cache geladen. Der Cache wurde in
Form einer Liste realisiert, dabei wurde davon ausgegangen, dass der verfügbare Arbeitsspeicher
immer für die Trainingsdaten ausreicht.
Die Eingabedaten werden in dem in Abschnitt 4.1.1 beschriebenen Format erwartet und
liegen in Form von Textdateien vor. Das MLP erwartet aber Vektoren, die mit Double-Werten
gefüllt sind. Beim Füllen des Caches, werden die Textdaten deshalb geparst und in Form von
Vektoren gespeichert.
Durch die Benutzung des Caches muss zum einen das Parsen der Trainingsdaten nur einmal
durchgeführt werden, zum anderen werden die Daten aus dem Arbeitsspeicher schneller als von
der Festplatte geladen.
5.1.2 Trainingsdaten
Die Trainingsdaten werden in dem in Abschnitt 4.1.1 beschriebenen Datenformat erwartet.
Quelldaten müssen also vorher in dieses Format überführt werden.

KAPITEL 5. IMPLEMENTIERUNG 40
IParser <<interface>>
+parse(String input): List<MLDataEntry>
XingParser MonkParser
Abbildung 5.1: Parser-Klassen
Für die beiden Anwendungsfälle MONK (siehe Unterabschnitt 6.2.2, Seite 51) und Xing-
Daten (siehe Abschnitt 6.7, Seite 69) wurden Parser zum Überführen der Quelldaten in Trai-
ningsdaten implementiert (siehe Abbildung 5.1). Beide Parser implementieren das Interface
IParser, erwarten einen Textzeile als Eingabe und geben eine Liste mit dem geparsten Inhalt,
in Form eines MLDataEntry (siehe Abbildung 5.2), zurück. Ein Trainingsbeispiel besteht aus
einem Feature- und einem Zielvektor, dessen Größe von der Anzahl an Eingaben bzw. der
Neuronenanzahl in der Ausgabeschicht abhängt. Der jeweilige Vektor ist ein RandomAccess-
SparseVector, d.h. es werden nur Daten im Speicher gehalten, die ungleich null (0) sind.
MLDataEntry
+targetVector:,RandomAccessSparseVector
+featureVector:,RandomAccessSparseVector
+MLDataEntry(nbInputUnits:int,nbOutputUnits:int)
Abbildung 5.2: Trainingsdaten-Klasse
Bezüglich der MONK-Daten musste beachtet werden, dass die Features/Eingabedaten in
unterschiedlichen Wertebereichen liegen. Hierfür musste also vorher eine Normalisierung (siehe
Anhang E, Seite 93) durchgeführt werden.
Die für den zweiten Anwendungsfall benötigten Xing-Daten wurden von Prof. Dr. Herta
zur Verfügung gestellt. Sie wurden von der Xing-Webseite gecrawlt und mussten in mehreren
Schritten vor-verarbeitet werden. Hier wurden zum einen die Rohdaten vor-verarbeitet und zum
anderen eine Wörterliste erstellt, da „bag of words“ als Features verwendet werden. Genaueres
dazu in Abschnitt 6.7.
Für die Erstellung der Trainingsdaten zur XOR-Funktion wurde kein extra Parser geschrie-
ben, da diese Funktion nur vier verschiedene Zustände kennt und somit ein Parser nicht not-
wendig gewesen ist.

5.2 MLP-Framework
Das MLP-Framework enthält eine Reihe von Klassen, wie z.B. Kostenfunktion, die Matrizenbi-
bliothek sowie Java-Factories zum Erzeugen von Matrizen und Vektoren. Für diese Arbeit am
wichtigsten war die Java-Klasse de.mlp_distributed.mlp.core.MultiLayerPerceptron, da sie die
Algrorithmen zum Trainieren eines MLP enthält. Sie ist in Abbildung A.3 auf der Seite 80 in
Form eines UML-Diagramms dargestellt. Die Abbildung beschränkt sich aus Platzgründen auf
die wichtigsten Methoden.
Die ursprüngliche Implementierung war ein reiner Online-Lerner, d.h. das mit jedem Trai-
ningsbeispiel auch das Modell angepasst wurde. Aus diesem Grund wurden Berechnung des
Gradienten und Berechnung des Gewichtsupdates voneinander getrennt. Die Klasse MultiLayer-
Perceptron wurde außerdem dahingehend abgeändert, dass sich der Momentum-Term abschal-
ten lässt, indem man den Momentum-Wert auf null setzt. Ansonsten würde Speicher für die
letzte Gewichtsänderung reserviert werden, auch wenn Momentum nicht verwendet wird.
Diese Klasse wurde außerdem um die Initialisierungsmethoden von Glorot & Bengio und
Nguyen & Widrow, sowie um die adaptive Lernrate ADAGRAD und das Lernverfahren iRprop+
erweitert.
5.2.1 Initialisierung der Verbindungsgewichte
Bevor das MLP trainiert werden kann müssen die Verbindungsgewichte mit einem zufällig ge-
wählten Wert initialisiert werden (siehe Unterabschnitt 2.1.1, Seite 8). Das MLP-Framework in-
itialisiert die Verbindungsgewichte standardmäßig nach dem Verfahren von LeCun. Im Rahmen
dieser Arbeit erfolgte die Implementierung von zwei weiteren Algorithmen zur Initialisierung
der Verbindungsgewichte, die nachfolgend genauer anhand von Codeausschnitten vorgestellt
werden.
1 final double distValue =Math.sqrt(6) / Math.sqrt(fanOut+ fanIn);
2 for (int i = 0; i < fanOut; i++) {
3 for (int j = 0; j < fanIn; j++) {
4 double weight= (2 * distValue * randomNumberGenerator.nextDouble()) - distValue;
5 this.weights[l].setQuick(i, j, weight);
6 }
7 }
Listing 5.1: Initialisierung der Verbindungsgewichte mit dem Verfahren von Glorot-Bengio
Im obigem Codeausschnitt ist die Initialisierung der Verbindungsgewichte nach dem Algorith-
mus von Glorot & Bengio ausschnittsweise in Form von Java-Code dargestellt. Der Wertebereich
in dem die Verbindungsgewichte liegen wird in Zeile eins festgelegt und wird unter Einbeziehung
der Anzahl an eingehenden bzw. ausgehenden Verbindungen einer Schicht bestimmt. In Zeile

vier wird für jedes Gewicht eine Zufallszahl ermittelt und in den vorher bestimmten Wertbereich
überführt.
Das Verfahren von Nguyen & Widrow ist ausschnittsweise in Listing 5.2 dargestellt. Auch
hier erfolgt die Berechnung des Verbindungsgewichts in Abhängigkeit zur Anzahl an Verbin-
dungsgewichten in zwei Schichten (siehe Zeile eins).
Im ersten Schritt erfolgte eine zufällige Initialisierung der Verbindungsgewichte, die dann
im Wertebereich [−1, 1] liegen (Zeile 2). Im zweiten Schritt wird für jedes Neuron die Vektor-
norm über die eingehenden Verbindungsgewichte berechnet (Zeilen 4-9). Damit die Vektornorm
|Wl
i | = 0.7 · (fanout)fan−1
in entspricht, werden die Verbindungsgewichte (Zeilen 11-15) entspre-
chend angepasst.
1 final double beta = 0.7 * Math.pow(this.nbUnits[1] + 1, 1.0 / (this.nbUnits[0] + 1));
2 initializeWeightsRandomly(-1,1);
3 // Berechne die Norm.
4 double norm= 0.0;
5 for (int j = 0; j < weightMatrix.columnSize(); j++) {
6 final double weight=weightMatrix.getQuick(i, j);
7 norm+=weight * weight;
8 }
9 norm=Math.sqrt(n);
10 // Passe das Gewicht an.
11 for (int j = 0; j < weightMatrix.columnSize(); j++) {
12 double weight=weightMatrix.getQuick(i, j);
13 weight= (beta * weight) / norm;
14 weightMatrix.setQuick(i, j, weight);
15 }
Listing 5.2: Initialisierung der Verbindungsgewichte mit dem Verfahren von Nguyen-Widrow
5.2.2 Matrizen-Bibliotheken
Wie im Entwurf beschrieben, sollte die Matrizenbibliothek austauschbar sein. Das ist nur mög-
lich, durch die Deﬁnition einer gemeinsamen Schnittstelle. An dieser Stelle werden die bereits
in Apache Mahout enthaltenen Schnittstellen „org.apache.mahout.math.Vector“ (siehe Abbil-
dung A.4, Seite 81) und „org.apache.mahout.math.Matrix“1
als gemeinsame Schnittstelle be-
nutzt. Diese Schnittstellen werden bereits vom MLP-Framework verwendet, so dass an dem
MLP-Framework keine Änderungen vorgenommen werden mussten.
1Die Klassenhierarchie der Matrizen-Klassen ähnelt der Darstellung in Abbildung A.4, deshalb wurde auf
eine Darstellung verzichtet.

Die Klassen de.mlp_distributed.mlp.math.jblas.JDenseVector und de.mlp_distributed.mlp.
math.jblas.JDenseMatrix kapseln die jblas-Bibliothek, indem sie intern die Klasse DoubleMa-
trix aus dieser Bibliothek benutzen. Es wurden jeweils nur die Methoden der Schnittstelle
implementiert, die vom MLP-Framework auch tatsächlich verwendet werden.
Das MLP-Framework wurde dahingehend geändert, dass Matrizen und Vektoren nicht mehr
direkt, sondern mittels Factory Klassen erzeugt werden. Diese Factories werden wiederum von
einer Factory-Klasse zur Verfügung gestellt, die ausschnittsweise unten dargestellt wird. Die
Factory Klassen werden mittels Dependency Injection geladen (siehe Listing 5.3, Zeilen 1-4).
Hierzu wurde das Framework guice von Google verwendet (siehe [Goo]). Das Binding erfolgt
über von der Klasse com.google.inject.AbstractModule abgeleitete Klassen (Zeilen 11-17). In
diesem Beispiel wird standardmäßig die Mahout-Bibliothek verwendet. Es existiert allerdings
auch eine Methode mit der das Binding verändert werden kann.
1 @Inject
2 MatrixFactory matrixFactory;
3 @Inject
4 VectorFactory vectorFactory;
5 public static Factory getInstance() {
6 if (Factory.instance==null) {
7 return Factory.getInstance(new FactoryModule());
8 }
9 return Factory.instance;
10 }
11 private static class FactoryModule extends AbstractModule {
12 @Override
13 protected void configure() {
14 this.bind(VectorFactory.class).to(MahoutVectorFactory.class);
15 this.bind(MatrixFactory.class).to(MahoutMatrixFactory.class);
16 }
17 }
Listing 5.3: Factory-Klasse zur Erzeugung von Matrix von Matrix- und Vektor-Factories
Durch diese Schritte, kann die Matrizenbibliothek jederzeit ausgetauscht werden, ohne das
Änderungen am MLP-Framework nötig sind. Ein Vergleich der Performance zwischen Mahouts
Matrizenbibliothek und jblas erfolgt in Unterabschnitt 6.4.3 auf Seite 61.
5.2.3 Trainingsalgorithmen
Die adaptive Lernrate ADAGRAD wurde wie in Gleichung 2.17 dargestellt implementiert. Um
zu große Lernraten zu verhindern, musste jedoch der Divisior angepasst werden. Der Divi-

sor wird nun auf eins festgelegt, wenn er kleiner als 10−8
ist. Ansonsten kam es bei kleinen
Mini-Batch Größen und daraus folgend vielen Gewichtsupdates bereits sehr früh vor, dass die
Gewichtsverbindungen gegen plus oder minus unendlich gingen. Für ADAGRAD wird für jedes
Gewicht die letzte Quadratsumme über die Gradienten in einer Matrix gespeichert, allerdings
nur auf dem Master-Peer, da nur die Lernrate zur Berechnung des Gewichtsupdates benötigt
wird.
Das Batch-Lernverfahren iRprop+ wurde wie in Listing 2.1 dargestellt implementiert. Hier
musste die letzte Gewichtsänderung in einer Matrix gespeichert werden. Außerdem wird immer
der aktuelle und der letzte Fehlerwert benötigt. Für iRprop+ muss demzufolge zwingend der
Fehlerwert in jeder Iteration berechnet werden. Sowohl Fehlerwert als auch die Matrix mit der
letzten Gewichtsänderung werden nur auf dem Master-Peer gespeichert.
Der Denoising Autoencoder verrauscht den Feature Vektor. Dazu musste die Methode zum
Laden eines Trainingsbeispiels angepasst werden. Der Denoising Autoencoder wurde so imple-
mentiert, dass nur Trainingsdaten verrauscht werden, deren Feature Vektor größer zwei ist.
Mit 20-prozentiger Wahrscheinlichkeit, werden bis auf eine Ausnahme alle Werte des Feature-
Vektors auf null gesetzt. Ansonsten werden zufällig 50-Prozent des Feature Vektors auf null
gesetzt. Diese Werte entstammen dem MLP-Framework und wurden übernommen.
5.3 verteiltes Training mit BSP
Die Anwendung zum verteilten Training des MLP wird mit Hilfe von Apache Maven gebaut,
dabei wird eine JAR-Datei erzeugt. Das Training wird mit Hilfe dieser JAR-Datei und der Klas-
se de.distMLP.Train_MultilayerPerceptron gestartet, die den Pfad zu einer Property-Datei als
Eingabe erwartet (siehe nächstes Unterkapitel). Diese Klasse führt wenn notwendig das Auf-
splitten der Trainingsdaten in mehrere Dateien durch und startet den BSP-Job. Der BSP-Job
kann lokal oder auf einem BSP-Cluster ausgeführt werden. Wird ein BSP-Job lokal ausgeführt,
dann wird ein BSP-Cluster emuliert.
Die Klassenhierarchie der zum Training verwendeten BSP-Klassen wird in Abbildung A.5
auf der Seite 82 in Form eines UML-Diagramms dargestellt.
Die Klasse Base_MLP_Trainer ist eine abstrakte Klasse und erweitert die BSP-Klasse. Hier
ﬁnden sich mehrere Methoden, die beim Starten und beim Beenden des BSP-Jobs aufgerufen
werden. Außerdem ﬁndet hier die Kapselung der I/O-Methoden von Apache Hama für den
Cache statt. Die Eingabedaten können hier für den Denoising Autoencoder verrauscht werden,
was bei jeder Iteration erneut durchgeführt wird. Sie regelt weiterhin das regelmäßige Speichern
des MLP-Modells und das Updaten des Modells auf dem Master-Peer.
Die Klasse MLP_MiniBatchGD ist von dieser Klasse abgeleitet. Sie überschreibt die bsp()-
Methode, in der das eigentliche Training des MLP geregelt wird (siehe Listing F.1, Seite 95).
Diese Klasse unterstützt BGD und MBGD in Verbindung mit den Lernverfahren Momentum
und ADAGRAD. Das Lernverfahren iRprop+ kann mit Hilfe der von dieser Klasse abgeleite-

Large Scale Multilayer Perceptron

Large Scale Multilayer Perceptron

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Viewers also liked

Viewers also liked (20)

Similar to Large Scale Multilayer Perceptron

Similar to Large Scale Multilayer Perceptron (20)

Large Scale Multilayer Perceptron