Downloaden Sie, um offline zu lesen
![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. Klassifizierung und
Regression, genutzt (siehe Abschnitt 2.1[Seite 7]).
Ausgelöst unter anderem durch die Arbeit Geoffrey 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](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-9-320.jpg)
![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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-10-320.jpg)
![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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-11-320.jpg)
![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 definiert:
„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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-13-320.jpg)
![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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-14-320.jpg)
![KAPITEL 2. GRUNDLAGEN 7
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]](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-15-320.jpg)
![KAPITEL 2. GRUNDLAGEN 8
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 Einfluss 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-16-320.jpg)
![KAPITEL 2. GRUNDLAGEN 9
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-17-320.jpg)
![KAPITEL 2. GRUNDLAGEN 10
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]](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-18-320.jpg)
![KAPITEL 2. GRUNDLAGEN 11
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]).](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-19-320.jpg)
![KAPITEL 2. GRUNDLAGEN 12
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-20-320.jpg)
![KAPITEL 2. GRUNDLAGEN 13
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 beeinflusst 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-21-320.jpg)
![KAPITEL 2. GRUNDLAGEN 14
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-22-320.jpg)
![KAPITEL 2. GRUNDLAGEN 15
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 Begriff 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](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-23-320.jpg)
![KAPITEL 2. GRUNDLAGEN 16
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](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-24-320.jpg)
![KAPITEL 2. GRUNDLAGEN 17
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 fixen 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-25-320.jpg)
![KAPITEL 2. GRUNDLAGEN 18
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-Konfiguration kann unter anderem festgelegt wer-
den, wie viele BSP-Peers insgesamt benutzt werden sollen.
In der Konfigurationsdatei 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]](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-26-320.jpg)
![KAPITEL 2. GRUNDLAGEN 19
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-27-320.jpg)
![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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-29-320.jpg)
![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 Kommunikationsfluss
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]](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-30-320.jpg)
![KAPITEL 3. ANFORDERUNGSANALYSE 24
3.2 Analyse des MLP Frameworks
An dieser Stelle soll das verwendete MLP Framework näher betrachtet werden, um daraus
folgend die Zielstellungen zu definieren.
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 effizienter 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-32-320.jpg)
![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,](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-38-320.jpg)
![KAPITEL 4. ENTWURF 31
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-39-320.jpg)
![KAPITEL 4. ENTWURF 32
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 167ff])
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).](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-40-320.jpg)
![KAPITEL 4. ENTWURF 33
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 fließ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-](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-41-320.jpg)
![KAPITEL 4. ENTWURF 34
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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-42-320.jpg)
![KAPITEL 4. ENTWURF 36
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 finden.
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 Klassifizierung 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-44-320.jpg)
![KAPITEL 4. ENTWURF 37
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 Datenzugriff 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-45-320.jpg)
![KAPITEL 5. IMPLEMENTIERUNG 41
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](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-49-320.jpg)
![KAPITEL 5. IMPLEMENTIERUNG 42
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 Definition 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.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-50-320.jpg)
![KAPITEL 5. IMPLEMENTIERUNG 43
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-](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-51-320.jpg)
![KAPITEL 5. IMPLEMENTIERUNG 45
ten Klasse MLP_RPROP verwendet werden, welche die Methode zum Updaten des Modells
überschreibt.
5.3.1 Initialisierung & Cleanup
Bevor ein BSP-Job startet müssen Einstellungen geladen und das MLP initialisert werden.
Alle Einstellungen sind in einer Properties-Datei gespeichert, die beim Starten des BSP-Jobs
interpretiert wird. Um eine Evaluierung des MLP vornehmen zu können oder ein abgebrochenes
Training fortzusetzen, kann an dieser Stelle auch ein bereits trainiertes MLP geladen werden.
Die Properties-Datei erlaubt das Verändern von ca. 40 Standardwerten. Dazu gehören un-
ter anderem der Aufbau des neuronalen Netzes, der Speicherort der Trainingsdaten, dass zu
verwendende Trainingsverfahren und dessen Parameter, der Speicherintervall und der Zielfeh-
lerwert. Zur Initialisierung des MLP wurde die setup()-Methode der BSP-Klasse überschrieben
(siehe Abschnitt 2.2.2, Seite 18). Hier musste beachtet werden, dass alle BSP-Peers den gleichen
Seed-Wert zur zufälligen Initialisierung des MLP verwenden, damit auch alle BSP-Peers mit
dem gleichen Modell starten.
Ist ein BSP-Job zu Ende, dann wird die cleanup()-Methode der BSP-Klasse aufgerufen, die
ebenfalls überschrieben wurde. An dieser Stelle wird, falls gewünscht, dass Modell in eine Datei
gespeichert.
5.3.2 Kommunikation
Serialisierung
Die Kommunikation zwischen BSP-Peers basiert auf Nachrichten. Diese Nachrichten müssen
als einzige Bedingung die Writable Klasse erweitern.
Bei den zu versendenden Daten handelt es sich um Java Objekte, die vor dem Versen-
den serialisiert werden müssen. Im Rahmen dieser Arbeit wurden Java-Serialisierung und das
Framework kryo (siehe [eso]) in Betracht gezogen. Da kryo laut deren Webseite sowohl beim
Serialisieren als auch Deserialisieren vier bis fünfmal schneller als die von Hama benutzte Java-
Serialisierung ist, wurde schließlich kryo verwendet. Die Nachrichten werden vor dem Versenden
mit kryo serialisiert und in einem Byte-Array zwischengespeichert. Wird die selbe Nachricht von
einem BSP-Peer mehrmals verschickt, dann wird die Serialisierung nur einmal durchgeführt.
Kommunikation
Es wurden jeweils Klassen für die unterschiedlichen Kommunikationsstrategien implementiert
(siehe Abbildung A.1, Seite 80). Weiterhin wurden Nachrichten implementiert, zum Versenden
von Double Werten und zum Versenden der Gradienten bzw. des Modells (WeightMatrixMes-
sage, siehe Abbildung A.2 auf der Seite 80).
Die WeightMatrixMessage wird zusätzlich im Falle von BGD benutzt, um die Fehlerwerte zu
übermitteln. Weiterhin wird sie zum Benachrichtigen aller Peers verwendet, falls ein Abbruch-](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-53-320.jpg)
![KAPITEL 5. IMPLEMENTIERUNG 47
5.5.1 Stabilitätsprobleme
Das Problem der Instabilität ließ sich auf die zu optimistischen Einstellungen der Standard-
konfiguration zurückführen. Das Framework überprüft regelmäßig, ob alle Rechner im Cluster
verfügbar sind. Wird die Zeitspanne überschritten, innerhalb der ein Rechner antworten muss,
dann wird dieser als fehlerhaft oder nicht verfügbar markiert. Durch die hohe Last auf den
Rechnern, kam es regelmäßig zu Timeouts. Mit dem Hochsetzen dieser Zeitintervalle lief Apa-
che Hama sehr stabil und die Stabilitätsprobleme konnten damit abschließend gelöst werden.
5.5.2 Job-Verteilung
Die für einen Job benötigte Anzahl an BSP-Peers, wird vom Framework über die Anzahl an
Eingabedateien bzw. bei großen Dateien anhand der Anzahl von Datei-Blöcken ermittelt2
. Die
Eingabedateien können vom Framework gesplittet werden, dann erhält jeder BSP-Peer einen
Split. Hier stellte sich heraus, dass die Anzahl der Splits immer gleich der Hälfte anstatt der
gewünschten Anzahl ist.
Um dieses Problem zu lösen, werden die Trainingsdaten nun vor dem Starten eines BSP-
Jobs mit Hilfe eines eigens entwickelten Verfahrens gesplittet. Dabei wurde darauf geachtet, dass
jeder BSP-Peer, unter Berücksichtigung der Mini-Batch-Größe, die gleiche Anzahl an Trainings-
daten erhält. Es wird also unter Umständen ein Rest, der sich nicht gleichmäßig verteilen lässt,
verworfen. Das betrifft im Rahmen dieser Arbeit nur die Xing-Daten, da nur diese zum verteil-
ten Training benutzt wurden. Die Anzahl an Xing-Daten war jedoch sehr hoch, so dass hier
auf einige wenige Trainingsdaten zu Gunsten der Skalierbarkeit verzichtet werden konnte. Je
nach Anwendungsfall sollte das Splitverfahren denoch in zukünftigen Arbeiten weiter angepasst
werden.
5.6 Software-Tests
Die kritischen Komponenten, des im Rahmen dieser Arbeit erstellten Frameworks, sind Daten-
verarbeitung, Kommunikation und Training des künstlichen neuronalen Netzes. Für die bereits
im MLP Framework implementierten Trainingsalgorithmen existieren bereits Tests. Die hinzu
gekommenen Verfahren iRprop+ und ADAGRAD, wurden mit Validitätstests überprüft (siehe
Abschnitt 6.2).
Datenverarbeitung und Kommunikation sind mit Hilfe von JUnit-Tests überprüfbar. Alle
Tests werden automatisch beim Einchecken von Code ausgeführt. Zum Ausführen der Tests
dient ein Hudson Server (siehe [Ora]), da er dem Autor bereits bekannt war.
2In der MapReduce Implementierung von Apache Hadoop, wird die Anzahl von Mappern und Reducern mit
der gleichen Vorgehensweise ermittelt. Die Blockgröße entspricht der Blockgröße von HDFS. Die Standardblock-
größe beträgt 128 Megabyte.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-55-320.jpg)
![KAPITEL 6. AUSWERTUNG 50
Gast-Betriebssystem: Ubuntu 13.04 LTS 64-Bit
Apache Hama Version: 0.6.3
Apache Hadoop Version: hadoop-0.20.2-cdh3u6
Tabelle 6.2: Softwareausstattung der virtuellen Maschine
Metriken sich verbessern.
Die Bewertung der Qualität des Trainings erfolgte anhand der Metriken Precision/Recall
(siehe Abschnitt D.1) und F-measure (siehe Abschnitt D.2). Normalerweise werden diese Werte
anhand eines Testsets ermittelt, dass sind Daten die nicht zum Training des Netzes verwendet
wurden1
. Validitätstests mit einem Testset waren im Rahmen dieser Arbeit jedoch nur mit
den MONK-Daten möglich, da das XOR-Problem nur die vier zum Trainieren verwendeten
Zustände kennt.
Für alle Validitätstests gilt, dass der Output des MLP immer einer reelle Zahl zwischen null
und eins ist. Aus diesem Grund wird festgelegt, dass ein Wert kleiner gleich 0,5 als zur Klasse
I gehörig bzw. als null bewertet wird. Ist ein Wert größer 0,5, dann wird er als zur Klasse II
gehörig bzw. als eins bewertet.
6.2.1 Experiment: XOR-Funktion
Problembeschreibung
Bei der XOR-Funktion handelt es sich um eine Boolesche Funktion (siehe [Wikb]) mit zwei
Eingängen, die unter anderem zur Addition von binären Zahlen eingesetzt werden kann. Sie
gibt eine eins aus, wenn die Eingänge unterschiedlich sind. Ansonsten gibt sie eine null (0) aus.
Es gibt insgesamt vier unterschiedliche Eingaben, die in der unten stehenden Tabelle aufgelistet
sind. Bei dieser Problemstellung handelt es sich demzufolge um ein Regressions-Problem.
x1 x2 y
0 0 0
0 1 1
1 0 1
1 1 0
Tabelle 6.3: XOR-Funktion
Vorgehensweise
Das zum Trainieren verwendete Netz hat zwei Eingaben, eine versteckte Schicht mit drei Neuro-
nen und eine Ausgabeschicht mit einem Neuron. Das Training erfolgte in mehreren Durchläufen,
1Ein künstliches neuronales Netz muss generalisieren können, d.h. es muss auch gute Werte liefern für Daten
mit denen es nicht trainiert wurde. Da die Gefahr des Auswendiglernens besteht, wird deshalb mit Daten getestet,
die nicht zum Trainieren verwendet wurden.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-58-320.jpg)
![KAPITEL 6. AUSWERTUNG 51
jeweils bis zu einem gewissen Fehlerwert. Mit den Trainingsdaten erfolgte dann die Ermittlung
von Precision/Recall und F-measure anhand der „true negative“ (TN), „false negative“ (FN),
„true positive“ (TP) und „false positive“ (FP) Werte.
Das Training wurde mit verschiedenen Fehlerwerten als Zielwert und allen Trainingsalgo-
rithmen in unterschiedlichen Kombinationen durchgeführt. Die nachfolgende Auswertung er-
folgt anhand des Trainings mit dem iRprop+ Algorithmus. Die anderen Trainingsalgorithmen
erreichten ähnliche Werte.
Auswertung
Die Tabelle 6.4 enthält die Ergebnisse für unterschiedliche Fehlerwerte, dabei gibt der Wert
innerhalb der Klammer an, wie viele Datensätze jeweils zugeordnet wurden. Die Werte für TP,
FN, FP und TN entsprechen dem Mittelwert unter Angabe der Unsicherheit. Anhand dieser
Tabelle lässt sich erkennen, was der eher abstrakte Fehlerwert darstellt. Je kleiner der Fehlerwert
ist, um so mehr nähern sich die Ergebnisse dem Zielwert null bzw. eins an und um so geringer
ist auch die Varianz. Diese Daten erlauben den Schluss, dass das MLP für die Trainingsdaten
korrekt funktioniert.
Fehlerw. TP FN FP TN Prec. Recall F1-meas.
0,1 0,91 ±0, 1 (0) (0) 0,07 ±0, 14 100% 100% 100%
(2) (2)
0,2 0,83 ±0, 3 (0) (0) 0,16 ±0, 3 100% 100% 100%
(2) (2)
0,3 0,97 0.44 (0) 0,13 ±0, 24 100% 50% 66%
(1) (1) (2)
0,4 0,71 ±0, 3 (0) 0,54 0,02 66% 100% 80%
(2) (1) (1)
0,5 0,71 ±0, 1 (0) 0,68 0,06 66% 100% 80%
(2) (1) (1)
0,7 0,68 0,48 0,51 0,35 50% 50% 50%
Tabelle 6.4: XOR: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert
6.2.2 Experiment: MONK
Problembeschreibung
Die Daten des MONK Problems entstammen dem UCI-Repository für maschinelles Lernen
(siehe „MONK’s Problems Data Set“, [BL13]). Sie wurden ursprünglich zum Vergleichen von
verschiedenen Algorithmen des maschinellen Lernens erstellt (siehe [TBB+
91]), was auch der
Grund für ihre Verwendung im Rahmen dieser Arbeit ist.
Die Problemdomäne dieser Daten ist die Klassifizierung von Robotern. Ein Roboter wird
anhand von sechs Attributen beschrieben, z.B. Kopf- oder Körperform (siehe Tabelle 6.5). Es](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-59-320.jpg)
![KAPITEL 6. AUSWERTUNG 52
gibt insgesamt 432 mögliche Kombinationsmöglichkeiten der einzelnen Attributausprägungen,
mit dazugehöriger Klassifizierung. Davon wurden 30% zufällig ausgewählt und zum Trainieren
verwendet. Die restlichen Daten bilden das Testset. Es handelt sich um ein binäres Klassifika-
tionsproblem (2-Klassen-Problem), ein Roboter gehört zu einer spezifischen Klasse oder nicht.
Es gibt insgesamt drei MONK-Probleme, wovon aber nur das erste hier Verwendung fand.
Für das erste MONK-Problem gilt, dass ein Roboter zur Klasse gehört, wenn seine Kopf- gleich
seiner Rumpfform oder die Jackenfarbe rot ist.
x1 : head_shape ∈ round (1), square (2), octagon (3)
x2 : body_shape ∈ round (1), square (2), octagon (3)
x3 : is_smiling ∈ yes (1), no (2)
x4 : holding ∈ sword (1), balloon (2), flag (3)
x5 : jacket_color ∈ red (1), yellow (2), green (3), blue (4)
x6 : has_tie ∈ yes (1), no (2)
Tabelle 6.5: MONK: Auflistung aller Attribute und ihrer Ausprägungen. Der Wert in den Klam-
mern gibt an, welche Zahl dieses Attribut im Eingabevektor repräsentiert.
Datenaufbereitung
Die Rohdaten liegen in Textform vor und enthalten Klasse, Attributausprägungen und einen
eindeutigen Namen. Der fünfte Datensatz sah zum Beispiel so aus:
1 1 1 1 1 3 1 data_5
Die Werte der Attribute befinden sich in unterschiedlichen Wertebereichen, z.B. Wx1 = [1, 3]
und Wx3 = [1, 2]. Im ersten Schritt erfolgte deshalb eine Normalisierung der Daten (siehe
Anhang E). Im zweiten Schritt wurden die Daten in das bereits beschriebene Datenformat
überführt.
Vorgehensweise
Das zum Trainieren verwendete Netz hat sechs Eingaben, eine versteckte Schicht mit sieben
Neuronen und eine Ausgabeschicht mit einem Neuron. Die Validitätstests mit MONK-Daten
erfolgten auf die gleiche Art und Weise wie die Tests mit der XOR-Funktion. Auch hier wurde
das MLP so lange trainiert, bis eine bestimmte Fehlerrate erreicht wurde. Dabei stellte sich her-
aus, dass das Training mit einer Lernrate von 0,1 im Durchschnitt mehr als 200.000 Iterationen
benötigte. Das traf auf alle Verfahren bis auf iRprop+ zu. Aus diesem Grund wurde für die
MONK-Daten, eine Lernrate von 0,01 festgelegt, da hier deutlich weniger Iterationen benötigt
wurden.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-60-320.jpg)
![KAPITEL 6. AUSWERTUNG 62
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Seq.
Komm.
(1)
Seq.
Komm.
(2)
Seq.
Komm.
(4)
Seq.
Komm.
(8)
Binary
Tree
(1)
Binary
Tree
(2)
Binary
Tree
(4)
Binary
Tree
(8)
Gradientenberechnung
KommunikaFon
Abbildung 6.12: Prozentualer Anteil von Kommunikation und Gradientenberechnung an der
gesamten Iterationsdauer.
lesen, dass die Berechnungen unter Verwendung der Mathe-Bibliotheken von Apache Mahout
am schnellsten erfolgten. Das gilt auch für die Berechnung des Gewichtsupdates, auf dessen
Darstellung verzichtet wurde.
Um genauer herauszufinden wie die Laufzeiten der einzelnen Methoden sind, wurde die
aspektorientierte Programmierung mit Aspectj (siehe [Fou]) benutzt. Aspectj bot den Vorteil,
dass hiermit deutlich weniger Code benötigt wird. Andernfalls hätte für jeden Methodenaufruf
die Implementierung einer Zeitmessung erfolgen müssen.
In Listing 6.1 findet sich der zum Profiling des MLP verwendete Code. In Zeile zwei ist der
pointcut dargestellt, der bestimmt an welcher Stelle die sparse-Methode (Zeilen 4-10) in den
ursprünglichen Programmablauf eingebunden werden soll. Sie dient der Zeitmessung und wird
vor jedem Methodenaufruf aufgerufen, außer es handelt sich bei der aufzurufenden Methode
um eine main-Methode oder um Methoden der Klasse „MLP_Profiler“.
1 private final Map<String, Long> methodTimes=newHashMap<String, Long>();
2 pointcut sparse() : execution(* *(..)) && !execution(* main(..)) && !within(MLP_Profiler);
3
4 Object around(): sparse() {
5 final long start =System.nanoTime(), end;
6 Object result = proceed();
7 end=System.nanoTime();
8 this.methodTimes.put(getJoinPointName(thisJoinPoint), end - start);
9 return result;
10 }
Listing 6.1: Ermittlung der benutzten Methoden und deren Laufzeit mit Aspectj](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-70-320.jpg)
![KAPITEL 6. AUSWERTUNG 63
Das Profiling des MLP erfolgte für die Gradientenberechnung und die Berechnung des Ge-
wichtsupdates, wodurch die Methoden mit der längsten Laufzeit und dem größten Optimie-
rungspotential ermittelt wurden. Für diese Methoden erfolgte dann ein Vergleich der Laufzei-
ten, für die beiden zur Verfügung stehenden Bibliotheken. Die Ergebnisse sind in Tabelle 6.8
dargestellt.
Framework / Rechenmethode DenseMatrix (Mahout) JDenseMatrix (jblas-Wrapper)
Multiplikation 111,27 ±6, 8 11,56 ±2, 6
Addition 46,07 ±3, 4 49,98 ±7, 8
DoubleDouble Funktion 22,17 ±2, 6 171,42 ±3
Vektor
DenseVector (Mahout) JDenseVector (jblas-Wrapper)
Cross 113,02 ±5, 12 280,54 ±7, 86
Tabelle 6.8: Linux: Zeitmessung verschiedener Rechenoperationen in ms für eine 1000x1000
Matrix und einen Vektor mit 1000 Zeilen.
Wie in der obigen Tabelle ersichtlich, erfolgt die Multiplikation zweier Matrizen mit jblas
deutlich schneller als mit der Mathe-Bibliothek von Apache Mahout. In den anderen dargestell-
ten Rechenoperationen ist es jedoch teils deutlich langsamer. Das ist auch der Grund dafür,
dass das Training unter Verwendung von jblas langsamer ist. Warum dies im Detail der Fall
ist, wurde aus Zeitgründen nicht weiter untersucht. Für zukünftige Arbeiten scheint es jedoch
sinnvoll, die Matrizenmultiplikation von jblas zu benutzen und Apache Mahout für alle anderen
Rechenoperationen zu verwenden oder weitere Bibliotheken in Betracht zu ziehen.
6.5 Untersuchung des Arbeitsspeicherverbrauchs
Im Rahmen dieses Unterkapitels wird untersucht, wie viel Arbeitsspeicher von dem Framework
Apache Hama bzw. von dem verteilten MLP benötigt werden. Der erste Teil dieses Unterkapitels
beruht auf empirischen Untersuchungen mit dem Linux-Tool top, während der zweite Teil eine
theoretische Betrachtung dieses Problems ist.
Wie bereits beschrieben, wurde im Rahmen dieser Arbeit das verteilte Dateisystem HDFS
von Apache Hadoop verwendet. Dementsprechend liefen auf allen Rechnern nicht nur Dienste
von Apache Hama sondern auch Dienste von HDFS. Das heißt, dass auf allen Rechnern ein
Datanode von Apache Hadoop sowie ein Groom-Server von Apache Hama liefen. Auf fünf
Rechnern lief zusätzlich der Dienst Zookeeper aus dem Framework Apache Zookeeper (siehe
[Whi11], Seite 441-474), zur Synchronisation der einzelnen Rechner. Weiterhin liefen zusätzlich
auf einem Rechner die Dienste Namenode, Secondary Namenode von Apache Hama und der
Dienst BspMaster von Apache Hama, nachfolgend Master-Rechner genannt.
Die Dienste Datanode, Zookeeper und Groom-Server reservieren ungefähr 100 MB Ar-
beitsspeicher, während die restlichen Dienste noch einmal zusätzlich ca. 180 MB reservieren.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-71-320.jpg)
![KAPITEL 6. AUSWERTUNG 69
6.7 Xing-Profildaten
6.7.1 Problembeschreibung
Ein Ziel dieser Arbeit war es, herauszufinden, ob die syntagmatische und paradigmatische Rela-
tion mit Hilfe eines MLP extrahiert werden kann. Zuerst soll deshalb geklärt werden, was diese
Begriffe im Allgemeinen und bezogen auf den Anwendungsfall der Xing-Profildaten bedeuten.
Manning und Schütze definieren diese Begriffe folgendermaßen (siehe [MS99], Seite 94):
„All elements that can be replaced for each other in a certain syntactic position ... are
members of one paradigm. In costrast, two words bear a syntagmatic relationship if they form
a phrase (or syntagma) like skewed clothes or sewed a dress. An important class of
syntagmatically related words are collocations.“
Das wird in dem folgenden allgemeinen Beispiel (aus [MS99], Seite 94) noch einmal verdeut-
licht. Alle dort vertikal innerhalb einer Klammer angeordneten Elemente sind untereinander
austauschbar und somit ein Beispiel für eine paradigmatische Relation. Alle horizontal ange-
ordneten Elemente haben eine syntagmatische Beziehung zueinander.
She
the woman
the tall woman
the very tall woman
the tall woman with sad eyes
...
saw
him
the man
the short man
the very short man
the short man with red hair
...
.
Bezogen auf die Xing-Daten könnte das z.B. wie unten dargestellt aussehen. Innerhalb einer
Klammer finden sich jeweils außer-fachliche oder berufstypische Qualifikationen, die untereinan-
der austauschbar sind. Jede Spalte würde dann eine Klasse von Qualifikationen repräsentieren.
In diesem Beispiel würde die zweite Spalte die Klasse der Programmiersprachen darstellen.
Eine Zeile mit einem oder mehreren Elementen aus jeder Spalte könnte z.B. das Profil eines
Software-Entwicklers darstellen.
Ein Anwendungsfall wäre z.B. die Verbesserung eines Suchalgorithmus. So könnte die Suche
nach einem Software-Entwickler unter dem Suchbegriff Eclipse auch Profile als Ergebnis liefern
die den Begriff Netbeans enthalten.
Eclipse
Netbeans
IntelliJ
JDeveloper
V isual Studio
...
Java
C
PHP
C#
Scala
...
Webdesign
Webentwicklung
Softwareentwicklung
Qualitätsmanagement
Projektleitung
...
Zuverlässigkeit
Führungserfahrung
Flexibel
Kommunikationsfähigkeit
Eigeninitiative
...
](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-77-320.jpg)
![KAPITEL 6. AUSWERTUNG 71
dargestellt. In diesem Beispiel würde das Benutzerprofil die Worte Eclipse, Network und OSGi
enthalten.
Abbildung 6.17: Training des MLP mit der Identität ohne verrauschten Eingabevektor.
Die Evaluation des trainierten MLP erfolgte wie bereits in Unterabschnitt 4.1.3 beschrieben,
anhand der Ausgabe des MLP, sowie anhand der Neuronen in der versteckten Schicht.
Um die syntagmatische Relation zu ermitteln, wurde nacheinander immer ein Wert der Ein-
gabe auf eins gesetzt und die dazugehörige Ausgabe des MLP untersucht. Das ist beispielhaft in
Abbildung 6.18(a) dargestellt. Allerdings liegen in Abweichung zur Abbildung die Ausgabewerte
in dem Wertebereich [0, 1] und mussten nach dem höchsten Wert sortiert werden.
(a) Syntagmatische Relation (b) Paradigmatische Relation
Abbildung 6.18: Analyse von Ausgabe- bzw. versteckter Schicht in Abhängigkeit der gesuchten
Beziehung
Die Untersuchung bezüglich der paradigmatischen Relation wird in Abbildung 6.18(b) bei-
spielhaft dargestellt. Hier wurde für jedes Neuron in der versteckten Schicht überprüft, welche
Eingabe zu einer maximalen Aktivierung dieses Neurons führt. Der Eingabevektor wurde dann](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-79-320.jpg)
![KAPITEL 7. FAZIT 77
Ein Nachteil von Apache Hama ist die Begrenzung der Kommunikation zwischen Prozessen
auf eine synchrone Kommunikation. So kam es vor, dass einzelne BSP-Peers aufgrund der syn-
chronen Verarbeitungsweise mehrere Sekunden warten mussten, bis die Berechnungen von allen
BSP-Peers abgeschlossen wurden. Die bereits in der Anforderungsanalyse erwähnte Forschungs-
arbeit (siehe Unterabschnitt 3.1.2) zeigt, dass insbesondere bei großen neuronalen Netzen eine
Kombination aus asynchroner und synchroner Kommunikation von Vorteil sein kann, die mit
Apache Hama nicht umsetzbar ist.
Apache Hama unterstützt ausschließlich die Kommunikation in Form von Punkt-zu-Punkt
Verbindungen. Die Implementierung der Binary Tree Kommunikation zeigte, dass sich damit
die Kommunikation zwischen verteilten Prozessen effizient gestalten lässt. In zukünftigen Ar-
beiten sollten noch weitere Algorithmen zur Inter-Prozess-Kommunikation untersucht werden.
Interessant könnte z.B. „Chunk based parallel tree“ sein (siehe [BRF04][Seite 10]).
Zum Trainieren des künstlichen neuronalen Netzes wurden im Rahmen dieser Arbeit aus-
schließlich Verfahren erster Ordnung verwendet und auf ein Netz mit nur einer versteckten
Schicht angewendet. In zukünftigen Arbeiten sollten Verfahren zweiter Ordnung in Betracht
gezogen werden. Sowohl die adaptive Lernrate ADAGRAD als auch die Initialisierung der Neu-
ronengewichte mit dem Verfahren von Nguyen und Widrow wurden für künstliche neuronale
Netze mit mehreren versteckten Schichten entwickelt. Sie sollten dementsprechend noch anhand
von Netzen mit mehreren versteckten Schichten untersucht werden.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-85-320.jpg)
![Anhang A
Klassendiagramme
de.distMLP.communication.MessageDistributor <<abstract>>
-peer:ABSPPeer<?,A?,A?,AHamaMessage>
-peerMap:AMap<Integer,AString>
-peerToIntMap:AMap<String,AInteger>
-loaclPeerMap:AMap<Integer,AString>
-localPeerToIntMap:AMap<String,AInteger>
+distributeMessageToAllPeers(senderName:String,
msg:HamaMessage,
peerNames:String[]):AHamaMessage
+distributeAndAggregateMessageToMasterPeer(msg:HamaMessage,
masterPeer:String):AHamaMessage
de.distMLP.communication.SimpleMessageDistributor
de.distMLP.communication.BTreeMessageDistributor
Abbildung A.1: Klassen zur Verteilung von Nachrichten](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-87-320.jpg)
![ANHANG A. KLASSENDIAGRAMME 80
org.apache.hadoop.io.Writable <<interface>>
+write(output:java.io.DataOutput)
+readFields(input:java.io.DataInput)
de.distmlp.messages.HamaMessage
de.distmlp.messages.DoubleMessage
-doubleValue:[double
de.distmlp.messages.WeightMatrixMessage
-matrix:[Matrix[]
-stopTraining:[boolean
-cost:[double
Abbildung A.2: Klassen zur Realisierung der Nachrichten
<<interface>>
org.apache.hadoop.io.Writable
<<nterface>>
de.mlp_distributed.mlp.learning.OnlineLearner
<<abstract>>
de.mlp_distributed.mlp.classfier.AbstractVectorClassifier
AclassifyFullginstance:VectorR
de.mlp_distributed.mlp.core.MultiLayerPerceptron
AMultiLayerPerceptrongnbInputUnits:intDnbOutputUnits:intD
nbHiddenUnits:int[]D
mutuallyExclusiveClasses:booleanD
momentum:doubleR
AassignRegularizationAndLearningrateggradients:Matrix[]R
AgetDerivativeOfTheCostWithoutRegularizationginput:VectorD
target:VectorR
AtrainOnlineginput:VectorDtarget:VectorR
Abbildung A.3: Darstellung der wichtigsten Methoden und Klassen des verwendeten MLP-
Frameworks.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-88-320.jpg)
![ANHANG A. KLASSENDIAGRAMME 82
<<abstract>>
org.apache.hama.bsp.BSP<K1,LV1,LK2,LV2,LMLextendsLWritable>
fbspdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E:LVector
fsetupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E
fcleanupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E
<<abstract>>
de.distMLP.train.Base_MLP_Trainer
Wmlp:LMultiLayerPerceptron
fsetupdpeer:BSPPeer<LongWritablehLTexthLNullWritableh
TexthLHamaMessage>E
fcleanupdpeer:BSPPeer<LongWritablehLTexth
NullWritablehLTexthLHamaMessage>E
freadNextTrainingExampledpeer:BSPPeer<LongWritableh
TexthLNullWritableh
TexthLHamaMessage>h
ex:TrainingExampleE:Lboolean
freopenInputdpeer:finalLBSPPeer<LongWritableh
TexthLNullWritablehLTexthLHamaMessage>E
WupdateWeightMatrixdgradients:Matrix[]E
fsaveMLPdpeer:BSPPeer<LongWritablehLTexth
NullWritablehLTexthLHamaMessage>h
iterationNumber:intE
de.distMLP.train.MLP_MiniBatchGD
fbspdpeer:BSPPeer<LongWritablehLTexthLNullWritableh
TexthLHamaMessage>E
de.distMLP.train.MLP_RPROP
WupdateWeightMatrixdgradients:Matrix[]E
Abbildung A.5: Darstellung der BSP-Jobklassen.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-90-320.jpg)
![Anhang C
Fehlerrechnung
Bei der Aufnahme von mehreren Messwerten für den gleichen Vorgang, lassen sich oftmals
Abweichungen aufgrund zufälliger Fehler feststellen. Bei der Performancemessung von Java-
Programmen können Abweichungen z.B. durch den Just-in-Time Compiler oder den Garbage
Collector ausgelöst werden. Damit nun einzelne Ausreißer nicht die Messwerte verfälschen,
muss eine Fehlerrechnung durchgeführt werden. Als Quelle für die folgenden Ausführungen
diente [Wikc].
Für N Messwerte erlaubt das arithmetische Mittel eine bessere Aussage als Einzelwerte (vj).
Es gilt folgende Gleichung für das arithmetische Mittel ¯v:
¯v =
1
N
N
j=1
vj. (C.1)
Die empirische Standardabweichung s ist, in Kombination mit der Unsicherheit u, ein Maß für
die Streuung der Messwerte. Die empirische Standardabweichung wird folgendermaßen berech-
net:
s =
1
N − 1
N
j=1
vj − ¯v
2
. (C.2)
Für die der Berechnung der Unsicherheit, gilt:
u =
1
√
N
· s. (C.3)
Für alle im Rahmen dieser Arbeit vorgenommenen Messungen, gilt N >= 40, ein Konfi-
denzniveau von 95% und damit der Konfidenzintervall: ¯v − 2 · u · · · ¯v + 2 · u.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-97-320.jpg)
![Anhang D
Metriken
Die Metriken Precision/Recall und f-measure werden oft in der statistischen Sprachverarbeitung
verwendet (NLP) und dienen im Rahmen dieser Arbeit als Qualitätsmaß für Klassifikatoren.
Als Quelle wurde hier [MS99] benutzt (Seiten 267-271).
Der Speedup wird zur Bewertung der Skalierbarkeit eines verteilten Systems benutzt (Quel-
len: [Wikd], [Wika]).
D.1 Precision/Recall
Zur Berechnung von Precision und Recall müssen als erstes die Anteile von „true negative“
(TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) an der Gesamtmenge
gemessen werden.
Im Rahmen der Klassifizierung eines Zwei-Klassen-Problems gilt folgende Matrix:
Deklariere als Klasse I Deklariere als Klasse II
Ist Klasse I TP FN
Ist Klasse II FP TN
Tabelle D.1: Confusion Matrix
Die Precision wird folgendermaßen ermittelt:
Precision =
tp
tp + fp
. (D.1)
Die Precision wird also berechnet, indem die Anzahl der korrekt gelabelten Daten durch die
Gesamtzahl, der als zu dieser Klasse gehörigen Daten, geteilt wird. Ein Wert von 1.0 gibt
an, dass alle als zu dieser Klassen gehörig gelabelten Daten auch tatsächlich zu dieser Klasse
gehören. Er sagt aber nichts darüber aus, wie viele Daten, die auch zu dieser Klasse gehören,
nicht korrekt gelabelt wurden.](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-99-320.jpg)
![ANHANG D. METRIKEN 92
Der Recall wird folgendermaßen ermittelt:
Recall =
tp
tp + fn
(D.2)
Der Recall wird also berechnet, indem die Anzahl der korrekt als Klasse I gelabelten Daten
durch die Gesamtzahl an Daten, die insgesamt zur Klasse I gehören, geteilt wird. Ein Wert von
1.0 bedeutet hier, dass alle zur Klasse I gehörigen Daten auch als zu Klasse I gehörig gelabelt
wurden. Dieser Wert kann allerdings auch bedeuten, dass alle Werte als zu Klasse I gelabelt
wurden
D.2 F-measure
Der F-measure kombiniert Precision und Recall zu einem Maß, wodurch besser die Gesamt-
performance ermittelt werden kann. Es werden im Rahmen dieser Arbeit Precision und Recall
gleich gewichtet (auch F1 score genannt), so dass sich folgende Gleichung ergibt:
F1 = 2 ·
precision · recall
precision + recall
(D.3)
D.3 Speedup
Der Speedup ist folgendermaßen definiert:
Sp =
T1
Tp
(D.4)
Dabei gilt, dass p gleich der Anzahl an Prozessoren ist, T1 die Ausführungszeit des sequentiel-
len Algorithmus und Tp die Ausführungszeit des parallelen Algorithmus mit p Prozessoren ist.
Der Speedup ist ein Maß dafür, wie stark ein Algorithmus durch die Parallelisierung beschleu-
nigt wurde. Wenn die Ausführungszeit halbiert wird, durch die Verdoppelung der Anzahl an
Prozessoren, dann spricht man von einem linearen Speedup.
Ein weiteres Maß ist die Effizienz, die folgendermaßen definiert ist:
Ep =
Sp
p
(D.5)
Die Effizienz gibt an, wie viel Aufwand mit Kommunikation und Synchronisation verschwendet
wird. Es gilt Ep = 1, wenn ein linearer Speedup erreicht wurde.
Laut dem Amdahlschen Gesetz ist die Parallelisierbarkeit eines Algorithmus durch seinen
sequentiellen Anteil begrenzt. Nach dem Amdahlschen Gesetz gilt, mit B ∈ [0, 1] gleich dem
sequentiellen Anteil, folgende Gleichung:
Tp = T1 B +
1
p
1 − B (D.6)](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-100-320.jpg)
![Anhang K
Literaturverzeichnis
[Abe] Abeles, Peter: Java Matrix Benchmark. http://code.google.com/p/
java-matrix-benchmark/, Abruf: 2014.02.09
[And] Andrew Ng: Sparse autoencoder. http://www.stanford.edu/class/cs294a/
sparseAutoencoder_2011new.pdf, Abruf: 2014.02.09
[Apa] Apache Software Foundation: Apache Mahout. http://mahout.apache.org/,
Abruf: 2014.02.09
[BL13] Bache, K. ; Lichman, M.: UCI Machine Learning Repository. http://archive.ics.
uci.edu/ml. Version: 2013
[Bot98] Bottou, Léon: Online Algorithms and Stochastic Approximations. Version: 1998.
http://leon.bottou.org/papers/bottou-98x. In: Saad, David (Hrsg.): Online
Learning and Neural Networks. Cambridge, UK : Cambridge University Press,
1998. – revised, oct 2012
[Bra] Braun, Mikio: jblas: linear algebra for java. http://mikiobraun.github.io/jblas/,
Abruf: 2014.02.09
[BRF04] Biersack, Ernst W ; Rodriguez, Pablo ; Felber, Pascal A: Performance ana-
lysis of peer-to-peer networks for file distribution. In: QOFIS 2004, 5th Interna-
tional Workshop on Quality of Future Internet Services, September 29-October 1,
2004, Barcelona, Spain / Also published in "LNCS", Volume 3266/2004. Barcelona,
SPAIN, 09 2004
[CH13] Cenk, Murat ; Hasan, M. A.: On the Arithmetic Complexity of Strassen-Like
Matrix Multiplications. Cryptology ePrint Archive, Report 2013/107, 2013. – http:
//eprint.iacr.org/
[Chr96] Christopher M. Bishop: Neural Networks - for Pattern Recognition. Clarendon
Press, Oxford, 1996](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-113-320.jpg)
![ANHANG K. LITERATURVERZEICHNIS 106
[CHW+
13] Coates, Adam ; Huval, Brody ; Wang, Tao ; Wu, David J. ; Catanzaro, Bry-
an C. ; Ng, Andrew Y.: Deep learning with COTS HPC systems. In: ICML (3)
Bd. 28, JMLR.org, 2013 (JMLR Proceedings), 1337-1345
[CL11] Chang, Chih-Chung ; Lin, Chih-Jen: LIBSVM: A library for support vector ma-
chines. In: ACM Transactions on Intelligent Systems and Technology 2 (2011), S.
27:1–27:27. – Software available at http://www.csie.ntu.edu.tw/~cjlin/libsvm
[CTM09] Cabreira, A. G. ; Tripode, M. ; Madirolas, A.: Artificial neural networks for
fish-species identification. In: Ices Journal of Marine Science 66 (2009), S. 1119–
1129. http://dx.doi.org/10.1093/icesjms/fsp009. – DOI 10.1093/icesjms/fsp009
[DCM+
12] Dean, Jeffrey ; Corrado, Greg S. ; Monga, Rajat ; Chen, Kai ; Devin, Matthieu
; Le, Quoc V. ; Mao, Mark Z. ; Ranzato, Marc’Aurelio ; Senior, Andrew ; Tu-
cker, Paul ; Yang, Ke ; Ng, Andrew Y.: Large Scale Distributed Deep Networks.
In: NIPS, 2012
[det] details, See homepage f.: ATLAS homepage. http://math-atlas.sourceforge.net/,
Abruf: 2014.02.09
[DG08] Dean, Jeffrey ; Ghemawat, Sanjay: MapReduce: Simplified Data Processing on
Large Clusters. In: Commun. ACM 51 (2008), Januar, Nr. 1, 107–113. http:
//dx.doi.org/10.1145/1327452.1327492. – DOI 10.1145/1327452.1327492. – ISSN
0001–0782
[DHS11] Duchi, John ; Hazan, Elad ; Singer, Yoram: Adaptive Subgradient Methods for
Online Learning and Stochastic Optimization. In: J. Mach. Learn. Res. 12 (2011),
Juli, 2121–2159. http://dl.acm.org/citation.cfm?id=1953048.2021068. – ISSN
1532–4435
[eso] esoteric software: Kryo. https://github.com/EsotericSoftware/kryo, Abruf:
2014.02.09
[Fou] Foundation, Eclipse: aspectj. http://eclipse.org/aspectj/, Abruf: 2014.02.09
[GB10] Glorot, Xavier ; Bengio, Yoshua: Understanding the difficulty of training deep
feedforward neural networks. In: In Proceedings of the International Conference
on Artificial Intelligence and Statistics (AISTATS’10). Society for Artificial Intel-
ligence and Statistics, 2010
[GGKK07] Grama, A. ; Gupta, A. ; Karypis, G. ; Kumar, V.: Introduction to Parallel
Computing, Second Edition. 2007. – erhältlich auf http://www.dkriesel.com
[GKWZ07] Gorban, Alexander N. ; Kgl, Balzs ; Wunsch, Donald C. ; Zinovyev, Andrei:
Principal Manifolds for Data Visualization and Dimension Reduction. 1st. Springer
Publishing Company, Incorporated, 2007. – ISBN 3540737499, 9783540737490](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-114-320.jpg)
![ANHANG K. LITERATURVERZEICHNIS 107
[GLS94] Gropp, William ; Lusk, Ewing ; Skjellum, Anthony: Using MPI: Portable Par-
allel Programming with the Message-Passing Interface. MIT Press, 1994
[Goo] Google: Guice. http://code.google.com/p/google-guice/, Abruf: 2014.02.09
[Hin07] Hinton, Geoffrey E.: Learning multiple layers of representation. In: Trends in
Cognitive Sciences 11 (2007), S. 428–434
[Hoc98] Hochreiter, Sepp: The Vanishing Gradient Problem During Learning Re-
current Neural Nets and Problem Solutions. In: Int. J. Uncertain. Fuzziness
Knowl.-Based Syst. 6 (1998), April, Nr. 2, 107–116. http://dx.doi.org/10.1142/
S0218488598000094. – DOI 10.1142/S0218488598000094. – ISSN 0218–4885
[HS06a] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data with
neural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi.
org/10.1126/science.1127647. – DOI 10.1126/science.1127647
[HS06b] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data with
neural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi.
org/10.1126/science.1127647. – DOI 10.1126/science.1127647
[IH00] Igel, Christian ; Hüsken, Michael: Improving the Rprop Learning Algorithm. In:
Proceedings of the Second International ICSC Symposium on Neural Computation
(NC 2000), ICSC Academic Press, 2000, S. 115–121
[Kri94] Kriesel, David: Ein kleiner Überblick über Neuronale Netze. 1994
[LBOM98] LeCun, Yann ; Bottou, Leon ; Orr, Genevieve ; Müller, Klaus: Efficient Back-
Prop. Version: 1998. http://dx.doi.org/10.1007/3-540-49430-8_2. In: Neural
Networks: Tricks of the Trade. Springer Berlin / Heidelberg, 1998 (Lecture Notes in
Computer Science). – DOI 10.1007/3–540–49430–8_2. – ISBN 978–3–540–65311–0,
Kapitel 2, 546
[LRM+
12] Le, Quoc ; Ranzato, Marc’Aurelio ; Monga, Rajat ; Devin, Matthieu ; Chen,
Kai ; Corrado, Greg ; Dean, Jeff ; Ng, Andrew: Building high-level features
using large scale unsupervised learning. In: International Conference in Machine
Learning, 2012
[MRS08] Manning, Christopher D. ; Raghavan, Prabhakar ; Schütze, Hinrich: Introduc-
tion to Information Retrieval. New York, NY, USA : Cambridge University Press,
2008. – ISBN 0521865719, 9780521865715
[MS99] Manning, C. ; Schütze, H.: Foundations of statistical natural language processing.
1999](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-115-320.jpg)
![ANHANG K. LITERATURVERZEICHNIS 108
[NW90] Nguyen, D. ; Widrow, B.: Improving the learning speed of 2-layer neural networks
by choosing initial values of the adaptive weights. (1990), Juni, 21–26 vol.3. http:
//dx.doi.org/10.1109/IJCNN.1990.137819. – DOI 10.1109/IJCNN.1990.137819
[Ora] Oracle: Hudson. http://hudson-ci.org/, Abruf: 2014.02.09
[RB92] Riedmiller, Martin ; Braun, Heinrich: RPROP - A Fast Adaptive Learning
Algorithm / Proc. of ISCIS VII), Universitat. 1992. – Forschungsbericht
[RHW88] Rumelhart, D. E. ; Hinton, G. E. ; Williams, R. J.: Neurocomputing: foundati-
ons of research. Version: 1988. http://dl.acm.org/citation.cfm?id=65669.104449.
Cambridge, MA, USA : MIT Press, 1988. – ISBN 0–262–01097–6, Kapitel Learning
internal representations by error propagation, 673–695
[RS98] Rogers, R. O. ; Skillicorn, D. B.: Using the BSP cost model to optimise parallel
neural network training. In: Future Generation Comp. Syst. 14 (1998), Nr. 5-6, 409-
424. http://dblp.uni-trier.de/db/journals/fgcs/fgcs14.html#RogersS98
[Sim05] Simon Haykin: Neural Networks - A Comprehensive Foundation. Pearson, Pren-
tice Hall, 2005
[SYK+
10] Seo, Sangwon ; Yoon, Edward J. ; Kim, Jaehong ; Jin, Seongwook ; Kim, Jin-
Soo ; Maeng, Seungryoul: HAMA: An Efficient Matrix Computation with the
MapReduce Framework. In: Proceedings of the 2010 IEEE Second International
Conference on Cloud Computing Technology and Science. Washington, DC, USA
: IEEE Computer Society, 2010 (CLOUDCOM ’10). – ISBN 978–0–7695–4302–4,
721–726
[TBB+
91] Thrun, Sebastian ; Bala, J. ; Bloedorn, E. ; Bratko, I. ; Cestnik, B. ; Cheng,
J. ; Jong, K. D. ; Dzeroski, S. ; Hamann, R. ; Kaufman, K. ; Keller, S. ; Ko-
nonenko, I. ; Kreuziger, J. ; Michalski, R.S. ; Mitchell, Tom ; Pachowicz,
P. ; Roger, B. ; Vafaie, H. ; Velde, W. V. ; Wenzel, W. ; Wnek, J. ; Zhang,
J.: The MONK’s Problems: A Performance Comparison of Different Learning Algo-
rithms / Computer Science Department. Pittsburgh, PA, 1991 (CMU-CS-91-197).
– Forschungsbericht
[TCCDL] Tennessee, Univ. of ; California, Berkeley Univ. o. ; Colorado Denver, Univ.
of ; Ltd., NAG: LAPACK/BLAS homepage. http://www.netlib.org/lapack/,
Abruf: 2014.02.09
[TKMS03] Toutanova, Kristina ; Klein, Dan ; Manning, Christopher D. ; Singer, Yoram:
Feature-Rich Part-of-Speech Tagging with a Cyclic Dependency Network. In: IN
PROCEEDINGS OF HLT-NAACL, 2003, S. 252–259](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-116-320.jpg)
![ANHANG K. LITERATURVERZEICHNIS 109
[VLBM08] Vincent, Pascal ; Larochelle, Hugo ; Bengio, Yoshua ; Manzagol, Pierre-
Antoine: Extracting and Composing Robust Features with Denoising Autoencoders.
In: Proceedings of the 25th International Conference on Machine Learning. New
York, NY, USA : ACM, 2008 (ICML ’08). – ISBN 978–1–60558–205–4, 1096–1103
[Whi11] White, Tom: Hadoop: The Definitive Guide (2nd Edition). O’Reilly, 2011
[Wika] Wikipedia: Amdahl’s law. http://en.wikipedia.org/wiki/Amdahl%27s_law, Ab-
ruf: 2014.02.09
[Wikb] Wikipedia: Boolesche Funktion. http://de.wikipedia.org/wiki/Boolesche_
Funktion, Abruf: 2014.02.09
[Wikc] Wikipedia: Fehlerrechnung. http://de.wikipedia.org/wiki/Fehlerrechnung, Ab-
ruf: 2014.02.09
[Wikd] Wikipedia: Speedup. http://en.wikipedia.org/wiki/Speedup, Abruf: 2014.02.09
[Xin] Xing AG: Xing. http://www.xing.com/, Abruf: 2014.02.09
[Zei12] Zeiler, Matthew D.: ADADELTA: An Adaptive Learning Rate Method. In: CoRR
abs/1212.5701 (2012)](https://image.slidesharecdn.com/7b630282-6636-44c9-a766-76fde67e0a2f-150513085232-lva1-app6892/85/Large-Scale-Multilayer-Perceptron-117-320.jpg)
Large Scale Multilayer Perceptron
- 1. LARGE SCALE MULTILAYERPERCEPTRON 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.
- 3. iii Kurzbeschreibung: In dieser Arbeitwurde 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 artificial 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 different 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
- 5. Inhaltsverzeichnis Inhaltsverzeichnis v 1 Einleitung1 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
- 6. 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 Einfluss des Caches auf die Ladezeit . . . . . . . . . . . . . . . . . . . . . 60 6.4.2 Vergleich von sequentieller und Binary Tree Kommunikation . . . . . . . 60
- 7. INHALTSVERZEICHNIS vii 6.4.3 Vergleichvon 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-Profildaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
- 9. Kapitel 1 Einleitung 1.1 Motivation DasMultilayer Perceptron (MLP) ist ein künstliches neuronales Netz und wird bereits seit den 80er Jahren erfolgreich zur Lösung verschiedener Probleme, wie z.B. Klassifizierung und Regression, genutzt (siehe Abschnitt 2.1[Seite 7]). Ausgelöst unter anderem durch die Arbeit Geoffrey 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
- 10. KAPITEL 1. EINLEITUNG2 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.
- 11. KAPITEL 1. EINLEITUNG3 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.
- 13. Kapitel 2 Grundlagen Im erstenTeil 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 definiert: „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.
- 14. KAPITEL 2. GRUNDLAGEN6 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.
- 15. KAPITEL 2. GRUNDLAGEN7 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]
- 16. KAPITEL 2. GRUNDLAGEN8 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 Einfluss 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.
- 17. KAPITEL 2. GRUNDLAGEN9 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.
- 18. KAPITEL 2. GRUNDLAGEN10 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]
- 19. KAPITEL 2. GRUNDLAGEN11 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]).
- 20. KAPITEL 2. GRUNDLAGEN12 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.
- 21. KAPITEL 2. GRUNDLAGEN13 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 beeinflusst 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.
- 22. KAPITEL 2. GRUNDLAGEN14 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.
- 23. KAPITEL 2. GRUNDLAGEN15 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 Begriff 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
- 24. KAPITEL 2. GRUNDLAGEN16 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
- 25. KAPITEL 2. GRUNDLAGEN17 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 fixen 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.
- 26. KAPITEL 2. GRUNDLAGEN18 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-Konfiguration kann unter anderem festgelegt wer- den, wie viele BSP-Peers insgesamt benutzt werden sollen. In der Konfigurationsdatei 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]
- 27. KAPITEL 2. GRUNDLAGEN19 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.
- 28. KAPITEL 2. GRUNDLAGEN20 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
- 29. Kapitel 3 Anforderungsanalyse In diesemKapitel 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.
- 30. KAPITEL 3. ANFORDERUNGSANALYSE22 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 Kommunikationsfluss 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]
- 31. KAPITEL 3. ANFORDERUNGSANALYSE23 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.
- 32. KAPITEL 3. ANFORDERUNGSANALYSE24 3.2 Analyse des MLP Frameworks An dieser Stelle soll das verwendete MLP Framework näher betrachtet werden, um daraus folgend die Zielstellungen zu definieren. 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 effizienter 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.
- 33. KAPITEL 3. ANFORDERUNGSANALYSE25 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 Profildaten 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.
- 34. KAPITEL 3. ANFORDERUNGSANALYSE26 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 des neuronalen Netzes zu benutzen. • 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 neuronalen Netzes zu benutzen.
- 35. KAPITEL 3. ANFORDERUNGSANALYSE27 • Mini-Batch Gradient Descent: Beschreibung: Es soll die Möglichkeit geben, Mini-Batch Lernverfahren zum Trainieren des neuronalen Netzes zu benutzen. • 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 neuronalen Netzes zu benutzen. • 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.
- 37. Kapitel 4 Entwurf In diesemKapitel 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
- 38. KAPITEL 4. ENTWURF30 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,
- 39. KAPITEL 4. ENTWURF31 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.
- 40. KAPITEL 4. ENTWURF32 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 167ff]) 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).
- 41. KAPITEL 4. ENTWURF33 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 fließ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-
- 42. KAPITEL 4. ENTWURF34 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.
- 43. KAPITEL 4. ENTWURF35 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 diffe- 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.
- 44. KAPITEL 4. ENTWURF36 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 finden. 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 Klassifizierung 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.
- 45. KAPITEL 4. ENTWURF37 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 Datenzugriff 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.
- 46. KAPITEL 4. ENTWURF38 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.
- 47. Kapitel 5 Implementierung Dieses Kapitelbeschreibt 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.
- 48. KAPITEL 5. IMPLEMENTIERUNG40 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.
- 49. KAPITEL 5. IMPLEMENTIERUNG41 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
- 50. KAPITEL 5. IMPLEMENTIERUNG42 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 Definition 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.
- 51. KAPITEL 5. IMPLEMENTIERUNG43 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-
- 52. KAPITEL 5. IMPLEMENTIERUNG44 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 finden sich mehrere Methoden, die beim Starten und beim Beenden des BSP-Jobs aufgerufen werden. Außerdem findet 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-
- 53. KAPITEL 5. IMPLEMENTIERUNG45 ten Klasse MLP_RPROP verwendet werden, welche die Methode zum Updaten des Modells überschreibt. 5.3.1 Initialisierung & Cleanup Bevor ein BSP-Job startet müssen Einstellungen geladen und das MLP initialisert werden. Alle Einstellungen sind in einer Properties-Datei gespeichert, die beim Starten des BSP-Jobs interpretiert wird. Um eine Evaluierung des MLP vornehmen zu können oder ein abgebrochenes Training fortzusetzen, kann an dieser Stelle auch ein bereits trainiertes MLP geladen werden. Die Properties-Datei erlaubt das Verändern von ca. 40 Standardwerten. Dazu gehören un- ter anderem der Aufbau des neuronalen Netzes, der Speicherort der Trainingsdaten, dass zu verwendende Trainingsverfahren und dessen Parameter, der Speicherintervall und der Zielfeh- lerwert. Zur Initialisierung des MLP wurde die setup()-Methode der BSP-Klasse überschrieben (siehe Abschnitt 2.2.2, Seite 18). Hier musste beachtet werden, dass alle BSP-Peers den gleichen Seed-Wert zur zufälligen Initialisierung des MLP verwenden, damit auch alle BSP-Peers mit dem gleichen Modell starten. Ist ein BSP-Job zu Ende, dann wird die cleanup()-Methode der BSP-Klasse aufgerufen, die ebenfalls überschrieben wurde. An dieser Stelle wird, falls gewünscht, dass Modell in eine Datei gespeichert. 5.3.2 Kommunikation Serialisierung Die Kommunikation zwischen BSP-Peers basiert auf Nachrichten. Diese Nachrichten müssen als einzige Bedingung die Writable Klasse erweitern. Bei den zu versendenden Daten handelt es sich um Java Objekte, die vor dem Versen- den serialisiert werden müssen. Im Rahmen dieser Arbeit wurden Java-Serialisierung und das Framework kryo (siehe [eso]) in Betracht gezogen. Da kryo laut deren Webseite sowohl beim Serialisieren als auch Deserialisieren vier bis fünfmal schneller als die von Hama benutzte Java- Serialisierung ist, wurde schließlich kryo verwendet. Die Nachrichten werden vor dem Versenden mit kryo serialisiert und in einem Byte-Array zwischengespeichert. Wird die selbe Nachricht von einem BSP-Peer mehrmals verschickt, dann wird die Serialisierung nur einmal durchgeführt. Kommunikation Es wurden jeweils Klassen für die unterschiedlichen Kommunikationsstrategien implementiert (siehe Abbildung A.1, Seite 80). Weiterhin wurden Nachrichten implementiert, zum Versenden von Double Werten und zum Versenden der Gradienten bzw. des Modells (WeightMatrixMes- sage, siehe Abbildung A.2 auf der Seite 80). Die WeightMatrixMessage wird zusätzlich im Falle von BGD benutzt, um die Fehlerwerte zu übermitteln. Weiterhin wird sie zum Benachrichtigen aller Peers verwendet, falls ein Abbruch-
- 54. KAPITEL 5. IMPLEMENTIERUNG46 kriterium erreicht wurde. Dies ist z.B. notwendig, wenn die Trainingsdaten ungleich verteilt sind und ein BSP-Peer bereits über alle Trainingsdaten iteriert hat. Ein weiteres Beispiel ist der Fehlerwert, der nur auf dem Master-Peer gespeichert und ausgewertet wird. Ist ein be- stimmter Fehlerwert erreicht, dann muss der Master-Peer alle BSP-Peers benachrichtigen. 5.4 Evaluation Die Evaluation eines trainierten MLP kann, wie in Unterabschnitt 4.1.3 beschrieben, anhand der Ausgabe des MLP bzw. anhand der Neuronen in der versteckten Schicht erfolgen. Die Eva- luation wurde in Form eines BSP-Jobs in der Java-Klasse de.distMLP.evaluation.MLPEvaluator realisiert, der durch die Java-Klasse de.distMLP.Evaluate_MultilayerPerceptron gestartet wird. Um einen BSP-Job zu starten wird eine Konfigurationsdatei erwartet, die die Pfade zu den Evaluierungsdaten, dem trainierten MLP und im Falle der Xing-Daten den Pfad zur Wortliste enthält. Bei der Evaluation wird unterschieden wie viele Neuronen die Ausgabeschicht des MLP enthält. Enthält sie ein Neuron, dann werden Precision/Recall und F-measure über alle Eva- luationsdaten berechnet und auf der Konsole ausgegeben. Zusätzlich wird für die Werte „true negative“ (TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) die Stan- dardabweichung berechnet und ausgegeben (siehe Anhang D, Seite 91). Enthält die Ausgabeschicht mehr als ein Neuron, dann wird davon ausgegangen, dass es sich bei dem zu evaluierenden Problem um die Xing-Daten handelt. Es wird dann ei- ne Datei erwartet, die eine Zuweisung der Zeilennummer des Eingabevektors zu einem Ele- ment der Wörterliste enthält. Das erwartete Format für eine Zeile in dieser Datei ist < Zeilennummer des Eingabevektors >:< Wort >, beginnend mit der Zeilennummer null (0). Für die Evaluation der Xing-Daten spielt nur die Zeilennummer des Eingabevektors eine Rolle, d.h. um das erste Element des Eingabevektors zu evaluieren müsste die Eingabedatei folgende Zeile enthalten 0 : 1|0 : 1. Für jede Eingabe wird die Ausgabe des MLP ermittelt. Die Werte des Ausgabevektors werden dann nach der Größe absteigend sortiert. Die 15 höchsten Werte werden ausgegeben, vorher erfolgte eine Zuordnung der Zeilennummer des Ausgabevek- tors zum dazugehörigen Element der Wortliste. Außerdem erfolgt immer eine Evaluation aller Neuronen der versteckten Schicht. 5.5 Apache Hama Apache Hama befindet sich zur Zeit in der Beta Phase und wurde in der Version 0.6.3 verwendet. Bei der Benutzung fielen zwei Dinge auf. Zum einen kam es sehr oft vor, dass BSP-Jobs bereits bei der Initialisierung abbrachen. Zum anderen wurde der BSP-Job nicht wie gewünscht auf alle verfügbaren BSP-Peers verteilt, sondern immer nur auf die Hälfte der möglichen Anzahl an BSP-Peers.
- 55. KAPITEL 5. IMPLEMENTIERUNG47 5.5.1 Stabilitätsprobleme Das Problem der Instabilität ließ sich auf die zu optimistischen Einstellungen der Standard- konfiguration zurückführen. Das Framework überprüft regelmäßig, ob alle Rechner im Cluster verfügbar sind. Wird die Zeitspanne überschritten, innerhalb der ein Rechner antworten muss, dann wird dieser als fehlerhaft oder nicht verfügbar markiert. Durch die hohe Last auf den Rechnern, kam es regelmäßig zu Timeouts. Mit dem Hochsetzen dieser Zeitintervalle lief Apa- che Hama sehr stabil und die Stabilitätsprobleme konnten damit abschließend gelöst werden. 5.5.2 Job-Verteilung Die für einen Job benötigte Anzahl an BSP-Peers, wird vom Framework über die Anzahl an Eingabedateien bzw. bei großen Dateien anhand der Anzahl von Datei-Blöcken ermittelt2 . Die Eingabedateien können vom Framework gesplittet werden, dann erhält jeder BSP-Peer einen Split. Hier stellte sich heraus, dass die Anzahl der Splits immer gleich der Hälfte anstatt der gewünschten Anzahl ist. Um dieses Problem zu lösen, werden die Trainingsdaten nun vor dem Starten eines BSP- Jobs mit Hilfe eines eigens entwickelten Verfahrens gesplittet. Dabei wurde darauf geachtet, dass jeder BSP-Peer, unter Berücksichtigung der Mini-Batch-Größe, die gleiche Anzahl an Trainings- daten erhält. Es wird also unter Umständen ein Rest, der sich nicht gleichmäßig verteilen lässt, verworfen. Das betrifft im Rahmen dieser Arbeit nur die Xing-Daten, da nur diese zum verteil- ten Training benutzt wurden. Die Anzahl an Xing-Daten war jedoch sehr hoch, so dass hier auf einige wenige Trainingsdaten zu Gunsten der Skalierbarkeit verzichtet werden konnte. Je nach Anwendungsfall sollte das Splitverfahren denoch in zukünftigen Arbeiten weiter angepasst werden. 5.6 Software-Tests Die kritischen Komponenten, des im Rahmen dieser Arbeit erstellten Frameworks, sind Daten- verarbeitung, Kommunikation und Training des künstlichen neuronalen Netzes. Für die bereits im MLP Framework implementierten Trainingsalgorithmen existieren bereits Tests. Die hinzu gekommenen Verfahren iRprop+ und ADAGRAD, wurden mit Validitätstests überprüft (siehe Abschnitt 6.2). Datenverarbeitung und Kommunikation sind mit Hilfe von JUnit-Tests überprüfbar. Alle Tests werden automatisch beim Einchecken von Code ausgeführt. Zum Ausführen der Tests dient ein Hudson Server (siehe [Ora]), da er dem Autor bereits bekannt war. 2In der MapReduce Implementierung von Apache Hadoop, wird die Anzahl von Mappern und Reducern mit der gleichen Vorgehensweise ermittelt. Die Blockgröße entspricht der Blockgröße von HDFS. Die Standardblock- größe beträgt 128 Megabyte.
- 56. KAPITEL 5. IMPLEMENTIERUNG48 5.6.1 Datenverarbeitung Die Datenverarbeitung wurde anhand von Beispieldaten getestet. Testkriterien waren die kor- rekte Überführung der Quelldaten in das Trainingsdatenformat und die korrekte Erstellung der Wörterliste. Bei der Normalisierung wurde überprüft, ob die korrekten Maxima und Minima gefunden und die Daten korrekt normalisiert und de-normalisiert werden. 5.6.2 Kommunikation Die Kommunikation wurde in Form von Komponenten- und Integrationstests überprüft. Da- bei mussten die unterschiedlichen Anwendungsfälle Broadcast und „all-to-one“ berücksichtigt werden. Bei der Broadcast Kommunikation muss erstens jeder BSP-Peer eine Nachricht enthalten und zweitens muss diese Nachricht die korrekten Werte beinhalten. Bei der „all-to-one“ Kommu- nikation werden Daten von allen BSP-Peers eingesammelt, aufsummiert und an einen BSP-Peer gesendet. Hier galt es zu prüfen, ob jeder BSP-Peer eine Nachricht sendet. Zum anderen musste geprüft werden, ob das Ziel die korrekte Summe erhält. Die Kommunikationsstrategien liegen in Form von eigenen Klassen vor. Für diese Klassen werden Komponententests in einem Pseudo-Cluster ausgeführt. Beide Kommunikationsstrategi- en werden mit unterschiedlicher Anzahl von BSP-Peers getestet, genauer mit einem BSP-Peer, sowie mit gerader und ungerader Anzahl an BSP-Peers. Zum Ausführen von Integrationstests wurde für das MLP ein sogenanntes Mock Objekt, also eine von der Klasse MultiLayerPerceptron abgeleitete Klasse mit eingeschränkter Funk- tionalität, erstellt. Das Mock Objekt wird mit einsen statt mit zufälligen Werten initialisiert. Die Gradientenberechung wurde dahingehend geändert, dass alle Felder der Gradientenmatrix eine eins enthalten. Außerdem wurde das Gewichtsupdate dahingehend geändert, dass weder Lernrate noch Regularisation Term einfließen. Auch die Berechnung der Fehlerrate ergibt für jedes Trainingsbeispiel den Wert: eins. Unter diesen Voraussetzungen, wird erwartet, dass die Nachrichten mit den durchschnitt- lichen Gradienten, eine Matrix enthalten, die mit Werten kleiner eins gefüllt ist. Weiterhin wird erwartet, dass das Gewichtsupdate eine Matrix gefüllt mit einsen ist. Das lässt sich leicht überprüfen, da nach jeder Iteration, das Modell mit einem Wert gefüllt sein muss, der der Itera- tionsnummer plus eins entspricht. Außerdem muss der für jede Iteration berechnete Fehlerwert gleich eins sein. Die Intergrationstests wurden in einem lokalen Pseudo-Cluster und in einem Cluster ausge- führt, dabei wurde die Anzahl der BSP-Peers variiert. Hier kann abschließend gesagt werden, dass die Kommunikation korrekt ausgeführt wird. Es konnten nur die üblichen auftretenden Abweichungen ermittelt werden, die sich aus der Berechnung mit Double Werten ergeben.
- 57. Kapitel 6 Auswertung Dieses Kapitelbeinhaltet verschiedene Tests zur Validität des verwendeten MLP, der Skalier- barkeit der Anwendung, sowie der Performanz in Abhängigkeit zum gewählten Lernverfahren. Außerdem werden Einfluss von Cache, Matrizenbibliothek und Kommunikationsform auf die Laufzeit des Programms untersucht. Zum Abschluss dieses Kapitels wird der Arbeitsspeicher- verbrauch in Abhängigkeit von verwendetem Lernverfahren und Rolle des BSP-Peers ermittelt, sowie die These untersucht, ob sich syntagmatische und paradigmatische Beziehungen mit einem MLP ermitteln lassen. 6.1 Testumgebung Für die Ausführung von Skalierungs- und Performancetests, konnte ein Labor der HTW Berlin zeitweise genutzt werden. Das Labor enthielt 21 Rechner, die über einen Switch miteinander verbunden waren. Die Rechner waren folgendermaßen ausgestattet: Prozessor: Intel Core i7-3770 3,40 GHz RAM: 8 GB DDR3 1600 MHz Host-Betriebssystem: Ubuntu 13.04 LTS 64-Bit Netzwerk: 2x Gigabit Ethernet Virtualisierung: Oracle VirtualBox 4.2.16 Tabelle 6.1: Hardware-/Softwareausstattung der Hostrechner Die Tests wurden innerhalb einer virtuellen Maschine ausgeführt, mit vier Prozessoren und 6 GB RAM. Die virtuelle Maschine lief mit der in Tabelle 6.1 aufgelisteten Software. 6.2 Validitätstests Die nachfolgenden Validitätstests dienen der Feststellung, ob das verwendete MLP richtig trai- niert. Das ist der Fall, wenn der Fehlerwert über mehrere Iterationen sinkt und die Werte der
- 58. KAPITEL 6. AUSWERTUNG50 Gast-Betriebssystem: Ubuntu 13.04 LTS 64-Bit Apache Hama Version: 0.6.3 Apache Hadoop Version: hadoop-0.20.2-cdh3u6 Tabelle 6.2: Softwareausstattung der virtuellen Maschine Metriken sich verbessern. Die Bewertung der Qualität des Trainings erfolgte anhand der Metriken Precision/Recall (siehe Abschnitt D.1) und F-measure (siehe Abschnitt D.2). Normalerweise werden diese Werte anhand eines Testsets ermittelt, dass sind Daten die nicht zum Training des Netzes verwendet wurden1 . Validitätstests mit einem Testset waren im Rahmen dieser Arbeit jedoch nur mit den MONK-Daten möglich, da das XOR-Problem nur die vier zum Trainieren verwendeten Zustände kennt. Für alle Validitätstests gilt, dass der Output des MLP immer einer reelle Zahl zwischen null und eins ist. Aus diesem Grund wird festgelegt, dass ein Wert kleiner gleich 0,5 als zur Klasse I gehörig bzw. als null bewertet wird. Ist ein Wert größer 0,5, dann wird er als zur Klasse II gehörig bzw. als eins bewertet. 6.2.1 Experiment: XOR-Funktion Problembeschreibung Bei der XOR-Funktion handelt es sich um eine Boolesche Funktion (siehe [Wikb]) mit zwei Eingängen, die unter anderem zur Addition von binären Zahlen eingesetzt werden kann. Sie gibt eine eins aus, wenn die Eingänge unterschiedlich sind. Ansonsten gibt sie eine null (0) aus. Es gibt insgesamt vier unterschiedliche Eingaben, die in der unten stehenden Tabelle aufgelistet sind. Bei dieser Problemstellung handelt es sich demzufolge um ein Regressions-Problem. x1 x2 y 0 0 0 0 1 1 1 0 1 1 1 0 Tabelle 6.3: XOR-Funktion Vorgehensweise Das zum Trainieren verwendete Netz hat zwei Eingaben, eine versteckte Schicht mit drei Neuro- nen und eine Ausgabeschicht mit einem Neuron. Das Training erfolgte in mehreren Durchläufen, 1Ein künstliches neuronales Netz muss generalisieren können, d.h. es muss auch gute Werte liefern für Daten mit denen es nicht trainiert wurde. Da die Gefahr des Auswendiglernens besteht, wird deshalb mit Daten getestet, die nicht zum Trainieren verwendet wurden.
- 59. KAPITEL 6. AUSWERTUNG51 jeweils bis zu einem gewissen Fehlerwert. Mit den Trainingsdaten erfolgte dann die Ermittlung von Precision/Recall und F-measure anhand der „true negative“ (TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) Werte. Das Training wurde mit verschiedenen Fehlerwerten als Zielwert und allen Trainingsalgo- rithmen in unterschiedlichen Kombinationen durchgeführt. Die nachfolgende Auswertung er- folgt anhand des Trainings mit dem iRprop+ Algorithmus. Die anderen Trainingsalgorithmen erreichten ähnliche Werte. Auswertung Die Tabelle 6.4 enthält die Ergebnisse für unterschiedliche Fehlerwerte, dabei gibt der Wert innerhalb der Klammer an, wie viele Datensätze jeweils zugeordnet wurden. Die Werte für TP, FN, FP und TN entsprechen dem Mittelwert unter Angabe der Unsicherheit. Anhand dieser Tabelle lässt sich erkennen, was der eher abstrakte Fehlerwert darstellt. Je kleiner der Fehlerwert ist, um so mehr nähern sich die Ergebnisse dem Zielwert null bzw. eins an und um so geringer ist auch die Varianz. Diese Daten erlauben den Schluss, dass das MLP für die Trainingsdaten korrekt funktioniert. Fehlerw. TP FN FP TN Prec. Recall F1-meas. 0,1 0,91 ±0, 1 (0) (0) 0,07 ±0, 14 100% 100% 100% (2) (2) 0,2 0,83 ±0, 3 (0) (0) 0,16 ±0, 3 100% 100% 100% (2) (2) 0,3 0,97 0.44 (0) 0,13 ±0, 24 100% 50% 66% (1) (1) (2) 0,4 0,71 ±0, 3 (0) 0,54 0,02 66% 100% 80% (2) (1) (1) 0,5 0,71 ±0, 1 (0) 0,68 0,06 66% 100% 80% (2) (1) (1) 0,7 0,68 0,48 0,51 0,35 50% 50% 50% Tabelle 6.4: XOR: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert 6.2.2 Experiment: MONK Problembeschreibung Die Daten des MONK Problems entstammen dem UCI-Repository für maschinelles Lernen (siehe „MONK’s Problems Data Set“, [BL13]). Sie wurden ursprünglich zum Vergleichen von verschiedenen Algorithmen des maschinellen Lernens erstellt (siehe [TBB+ 91]), was auch der Grund für ihre Verwendung im Rahmen dieser Arbeit ist. Die Problemdomäne dieser Daten ist die Klassifizierung von Robotern. Ein Roboter wird anhand von sechs Attributen beschrieben, z.B. Kopf- oder Körperform (siehe Tabelle 6.5). Es
- 60. KAPITEL 6. AUSWERTUNG52 gibt insgesamt 432 mögliche Kombinationsmöglichkeiten der einzelnen Attributausprägungen, mit dazugehöriger Klassifizierung. Davon wurden 30% zufällig ausgewählt und zum Trainieren verwendet. Die restlichen Daten bilden das Testset. Es handelt sich um ein binäres Klassifika- tionsproblem (2-Klassen-Problem), ein Roboter gehört zu einer spezifischen Klasse oder nicht. Es gibt insgesamt drei MONK-Probleme, wovon aber nur das erste hier Verwendung fand. Für das erste MONK-Problem gilt, dass ein Roboter zur Klasse gehört, wenn seine Kopf- gleich seiner Rumpfform oder die Jackenfarbe rot ist. x1 : head_shape ∈ round (1), square (2), octagon (3) x2 : body_shape ∈ round (1), square (2), octagon (3) x3 : is_smiling ∈ yes (1), no (2) x4 : holding ∈ sword (1), balloon (2), flag (3) x5 : jacket_color ∈ red (1), yellow (2), green (3), blue (4) x6 : has_tie ∈ yes (1), no (2) Tabelle 6.5: MONK: Auflistung aller Attribute und ihrer Ausprägungen. Der Wert in den Klam- mern gibt an, welche Zahl dieses Attribut im Eingabevektor repräsentiert. Datenaufbereitung Die Rohdaten liegen in Textform vor und enthalten Klasse, Attributausprägungen und einen eindeutigen Namen. Der fünfte Datensatz sah zum Beispiel so aus: 1 1 1 1 1 3 1 data_5 Die Werte der Attribute befinden sich in unterschiedlichen Wertebereichen, z.B. Wx1 = [1, 3] und Wx3 = [1, 2]. Im ersten Schritt erfolgte deshalb eine Normalisierung der Daten (siehe Anhang E). Im zweiten Schritt wurden die Daten in das bereits beschriebene Datenformat überführt. Vorgehensweise Das zum Trainieren verwendete Netz hat sechs Eingaben, eine versteckte Schicht mit sieben Neuronen und eine Ausgabeschicht mit einem Neuron. Die Validitätstests mit MONK-Daten erfolgten auf die gleiche Art und Weise wie die Tests mit der XOR-Funktion. Auch hier wurde das MLP so lange trainiert, bis eine bestimmte Fehlerrate erreicht wurde. Dabei stellte sich her- aus, dass das Training mit einer Lernrate von 0,1 im Durchschnitt mehr als 200.000 Iterationen benötigte. Das traf auf alle Verfahren bis auf iRprop+ zu. Aus diesem Grund wurde für die MONK-Daten, eine Lernrate von 0,01 festgelegt, da hier deutlich weniger Iterationen benötigt wurden.
- 61. KAPITEL 6. AUSWERTUNG53 Auswertung Die Tabelle 6.6 enthält die Ergebnisse für unterschiedliche Fehlerwerte. Auch hier ließ sich ein im Laufe mehrerer Iterationen abnehmender Fehlerwert und zunehmend bessere Werte der einzelnen Metriken feststellen. Fehler- TP FN FP TN Pre- Re- F1- wert cision call measure 0,03 0,96 ±0, 006 (0) 0,54 ±0, 02 0,06 ±0, 01 99% 100% 99% (156) (2) (152) 0,1 0,87 ±0, 02 0,47 0,67 ±0, 06 0,12 ±0, 02 91% 99% 95% (155) (1) (15) (139) 0,2 0,81 ±0, 02 0,47±0, 01 0,74 ±0, 04 0,18 ±0, 02 88% 95% 91% (148) (8) (20) (134) 0,3 0,83 ±0, 02 0,35±0, 03 0,68 ±0, 04 0,22 ±0, 02 74% 79% 77% (124) (32) (43) (111) 0,4 0,77 ±0, 02 0,32±0, 03 0,69 ±0, 03 0,27 ±0, 02 68% 70% 69% (124) (32) (43) (111) Tabelle 6.6: Monk: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert 6.3 Skalierungstests Für ein verteiltes System muss festgestellt werden, unter welchen Bedingungen es von zusätzli- chen Prozessoren bzw. zusätzlichen Rechnern profitiert. Ein Maß hierfür ist der Speedup (siehe D.3), der angibt wie gut ein Algorithmus parallelisierbar ist. Die vertikale bzw. horizontale Skalierbarkeit wurde im Rahmen mehrerer Tests überprüft und anhand des Speedups bewertet. Die Ergebnisse wurden mit einer linearen Skalierung verglichen, die das Optimum darstellt. Die Feststellung der vertikalen Skalierbarkeit erfolgte in einer verteilten (distributed- memory) und in einer nicht verteilten Umgebung, während die horizontale Skalierung aus- schließlich in einer verteilten Umgebung untersucht wurde. Die jeweiligen Testergebnisse und die Diskussion dieser Ergebnisse, bilden den Inhalt dieses Unterkapitels. 6.3.1 Vorgehensweise Allen Skalierungstests ist gemein, dass weder Momentum noch ADAGRAD oder iRprop+ ver- wendet wurden. Darauf wurde an dieser Stelle verzichtet, da diese Algorithmen nur auf einem Rechner und von einem Task ausgeführt werden, und damit nicht parallelisierbar sind. Alle Tests wurden unter Verwendung eines Caches und mit der Binary-Tree-Kommunikation ausgeführt. Die Berechnung des Speedups erfolgte anhand der Iterationsdauer, genauer deren Mittelwert, der über die Einzelergebnisse aus 40 Iterationen gebildet wurde. In allen Test gibt die Iterationsdauer an, für BGD und MBGD, wie lange ein Durchlauf über alle Trainingsdaten im Durchschnitt dauerte. Wie lange es dauert, bis ein Gewichtsupdate ausgeführt wird, ist nicht
- 62. KAPITEL 6. AUSWERTUNG54 Teil der Untersuchungen. Für alle Tests gilt weiterhin, dass die Anzahl der Eingaben, gleich der Anzahl an Neuronen in der versteckten und in der Ausgabeschicht ist. Das Training eines neuronalen Netzwerks besteht aus mehreren Einzelschritten. In den Ska- lierungstests werden die Zeiten zur Berechnung eines Gewichtsupdates bzw. für das Ausführen des Gewichtsupdates nicht weiter betrachtet, da sie nicht parallelisierbar sind. Die Zeiten hierfür liegen im ein- bis niedrigen zweistelligen Millisekundenbereich und sind gemessen an der Ge- samtdauer vernachlässigbar gering. Die Berechnung des durchschnittlichen Gradienten ist Teil der Kommunikation und wird auch nicht getrennt betrachtet. Die Berechnung des Fehlerwerts erfolgt zwar parallel, ist aber, außer bei iRprop+, zum Trainieren des MLP nicht zwingend erfor- derlich und ist daher nicht Teil der Untersuchungen. Der Vergleich von BGD und MBGD erfolgt ausschließlich anhand der Kommunikationszeiten und der benötigten Zeit zum Berechnen der Gradienten für alle Trainingsbeispiele. 6.3.2 Vertikale Skalierung Interprozesskommunikation zwischen Prozessen auf demselben Rechner Dieser Test gilt der Untersuchung der vertikalen Skalierbarkeit, unter Beschränkung der Kom- munikation auf einen Rechner. Der hierfür verwendete Rechner, verfügte über vier Prozessoren und zusätzlich durch Hyper-Threading über vier virtuelle Prozessoren. Das untersuchte Trai- ning, erfolgte anhand eines neuronalen Netzes mit 20 Neuronen, 84.000 Trainingsdaten, einem bis acht Tasks und dem BGD Lernverfahren. In den obigen Abbildungen sind Speedup und 1 1,5 2 2,5 3 3,5 4 1 Task 2 Tasks 3 Tasks 4 Tasks Op.mum BGD 500 (a) Speedup 0 200000 400000 600000 800000 1000000 1200000 1400000 1 Task 2 Tasks 3 Tasks 4 Tasks Itera&onsdauer in ms BGD 500 (b) Iterationsdauer für BGD und ein bis vier Tasks Abbildung 6.1: Gegenüberstellung von Speedup und Iterationsdauer Iterationsdauer für eine unterschiedliche Anzahl an Tasks dargestellt. Die Laufzeiten der Tests mit fünf bis acht Tasks glichen ungefähr der Laufzeit mit vier Tasks und sind deshalb nicht dargestellt. Der Speedup bricht bei vier Tasks ein, was auch der Anzahl an physikalischen Pro- zessoren entspricht. Vermutlich muss sich der vierte Task den Prozessor mit dem (Host- und Gast-) Betriebssystem und anderen Prozessen teilen, so dass hier keine so deutliche Geschwin- digkeitssteigerung mehr erreicht werden konnte.
- 63. KAPITEL 6. AUSWERTUNG55 Auf eine Darstellung der Kommunikationszeiten wurde an dieser Stelle verzichtet. Diese lag bei allen Tests zwischen 2 ms und 6 ms, sie ist im Vergleich zur gesamten Dauer also vernachlässigbar gering. Distributed-Memory mit konstanter Anzahl an Trainingsbeispielen pro Task In diesem Test wurde die vertikale Skalierbarkeit in einer verteilten Umgebung untersucht. Die Testdurchführung erfolgte immer mit 11 Rechnern, 180.000 Trainingsbeispielen und einem bis drei Tasks pro Rechner. Auf einen Test mit vier Tasks wurde an dieser Stelle verzichtet, da ein Einbruch des Speedups bereits im Test mit lokaler Interprozesskommunikation festgestellt wurde. Die zum Trainieren verwendeten Lernverfahren sind BGD und MBGD mit 100 bzw. 200 Trainingsbeispielen pro Task. Die Mini Batch Größe war in diesem Test nicht konstant, sondern hing von der Anzahl an Tasks ab, da jeder Task immer 100 bzw. 200 Trainingsbeispiele verarbeitete. 1 1,2 1,4 1,6 1,8 2 2,2 2,4 2,6 2,8 3 11 Tasks 22 Tasks 33 Tasks Speedup Op/mum BGD MBGD 100 MBGD 200 (a) Speedup 0 100000 200000 300000 400000 500000 600000 700000 800000 900000 1000000 11 Tasks 22 Tasks 33 Tasks Itera&onsdauer in ms BGD MBGD 100 MBGD 200 (b) Iterationsdauer für BGD und MBGD 100/200 mit 500 Neuronen Abbildung 6.2: Gegenüberstellung von Speedup und Iterationsdauer Die Ergebnisse dieser Tests, finden sich in Abbildung 6.2(b). Bei allen untersuchten Ver- fahren, ließ sich eine Verkürzung der Iterationsdauer, mit Erhöhung der Tasks pro Rechner, ermitteln. Das lässt sich damit begründen, dass die Kommunikationskosten der Interprozess- kommunikation zwischen Prozessen auf dem selben Rechner vernachlässigbar klein sind, so dass das Verfahren in hohem Maße von zusätzlichen lokalen Prozessoren profitiert. Am schnellsten war BGD, da hier die Kommunikationskosten am geringsten waren, danach folgt MBGD mit 200 Trainingsbeispielen pro Task. Am langsamsten war MBGD mit 100 Trai- ningsbeispielen pro Task. Auch das lässt sich anhand der Kommunikationskosten erklären. Eine Iteration über alle Trainingsdaten, besteht bei MBGD wiederum aus mehreren Iterationen. Je geringer die Mini Batch Größe, um so mehr Iterationen werden benötigt, um über alle Trai- ningsdaten zu iterieren. Je geringer die Mini Batch Größe, um so größer sind demzufolge auch die Kommunikationskosten. In Abbildung 6.2(a) sind die Speedup Werte, der einzelnen Verfahren dargestellt. Die MBGD Verfahren sind zwar am langsamsten, profitieren aber am stärksten von der Erhöhung der An-
- 64. KAPITEL 6. AUSWERTUNG56 0% 20% 40% 60% 80% 100% BGD 11 Tasks BGD 22 Tasks BGD 33 Tasks MBGD (11 T.) 100 MBGD (22 T.) 100 MBGD (33 T.) 100 MBGD (11 T.) 200 MBGD (22 T.) 200 MBGD (33 T.) 200 Anteil an Gesamtdauer in Prozent Gradientenberechnung KommunikaCon Abbildung 6.3: Prozentualer Anteil von Kommunikation und Gradientenberechnung an der gesamten Iterationsdauer. zahl lokaler Prozessoren und Erreichen die höchsten Speedup Werte. Das liegt darin begründet, dass mit steigender Taskanzahl auch die Mini Batch Größe erhöht wurde, wodurch auch mehr Daten pro Iteration verarbeitet werden. Eine Iteration über alle Daten besteht bei steigender Taskanzahl demzufolge aus weniger Iterationen. Das lässt sich gut in Abbildung 6.3 ablesen. Am geringsten ist der Anteil der Kommunika- tionskosten bei BGD. Die Größe der Kommunikationskosten bleibt bei steigender Taskanzahl ungefähr gleich, macht aber bei BGD einen steigenden Anteil an der Iterationsdauer aus. Das Verhältnis zwischen Kommunikation und Gradientenberechnung ist bei MBGD in allen Tests ungefähr konstant. Distributed-Memory mit konstanter Batchgröße Ziel dieses Tests ist es, herauszufinden, wie gut das System skaliert, wenn das Training mit geringer Anzahl an Trainingsdaten und konstanter Mini Batch Größe (384 Datensätze pro Iteration) erfolgt. Konstant bedeutet in diesem Fall, dass mit zunehmender Anzahl an Tasks, die Anzahl an Trainingsdaten pro Task abnimmt, die insgesamt verarbeitete Menge an Daten aber gleich bleibt. Die Testdurchführung erfolgte mit 3840 Trainingsdaten und 500 bzw. 1000 Neuronen. Zum Untersuchen der vertikalen Skalierbarkeit, wurden Tests mit 16 Rechnern und einem bis drei Tasks pro Rechner ausgeführt. Das Mini Batch Verfahren benötigt in diesem Test aufgrund der konstanten Batchgröße, immer zehn Iterationen, um mit allen Trainingsdaten zu trainieren. In Abbildung 6.4(b) sind die Laufzeiten für alle untersuchten Verfahren und Taskgrößen dargestellt. An dieser Abbildung lässt sich erkennen, dass sich die Iterationsdauer, mit Zunah- me der Anzahl an Tasks pro Rechner, nur in sehr geringem Maße verringert. Der Grund dafür sind die, im Verhältnis zur Berechnung des Gradienten, hohen Komunikationskosten. Wie in Abbildung 6.5 ersichtlich, nimmt zwar die Dauer der Gradientenberechnung mit zunehmender Taskanzahl ab. Die Kommunikationskosten überwiegen jedoch insbesondere bei den Mini Batch
- 65. KAPITEL 6. AUSWERTUNG57 1 1,5 2 2,5 3 16 32 48 Speedup Op,mum BGD 500 BGD 1000 MBGD 500 MBGD 1000 (a) Speedup 1 10 100 1000 10000 100000 1000000 BGD-‐500 BGD-‐1000 MBGD 500 MBGD 1000 Itera&onsdauer in ms 16 Tasks 32 Tasks 48 Tasks (b) Iterationsdauer für BGD und MBGD 384 mit 500 bzw. 1000 Neuronen. Abbildung 6.4: Gegenüberstellung von Speedup und Iterationsdauer Verfahren deutlich, sie machen dort mehr als 90 Prozent aus, so dass der Geschwindigkeitsge- winn durch mehrere Tasks pro Rechner nur sehr gering ist. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% BGD 500 (16) BGD 500 (32) BGD 500 (48) BGD 1000 (16) BGD 1000 (32) BGD 1000 (48) MBGD 500 (16) MBGD 500 (32) MBGD 500 (48) MBGD 1000 (16) MBGD 1000 (32) MBGD 1000 (48) Gradientenberechnung KommunikaCon Abbildung 6.5: Prozentualer Anteil von Kommunikation und Gradientenberechnung an der gesamten Iterationsdauer. In Abbildung 6.5 lässt sich auch ablesen, dass das Verhältnis von Kommunikation zu Berech- nungen günstiger ist, wenn die Anzahl an Neuronen größer ist. Im Ergebnis sind die Speedup Werte der neuronalen Netze mit 1000 Neuronen größer, als mit 500 Neuronen (siehe Abbildung 6.4(a)). Bei den Mini Batch Verfahren lässt sich nur ein Speedup nahe eins feststellen, das heißt dieses Verfahren skaliert zumindest in diesem Test nicht vertikal. Die im Vergleich mit 6.2(a) deutlich geringeren Speedup-Werte, lassen sich mit der geringen Anzahl an Trainingsdaten be- gründen. Zusammenfassend lässt sich hier sagen, dass die Skalierbarkeit, von der Problemgröße, der Anzahl an Trainingsdaten und dem verwendeten Trainingsverfahren abhängt. Je größer das Problem, also die Anzahl an Neuronenverbindungen, und je mehr Trainingsdaten pro Task vorliegen um so besser skaliert das System.
- 66. KAPITEL 6. AUSWERTUNG58 6.3.3 horizontale Skalierung In diesem Test wurde die horizontale Skalierung mit 500/1000 Neuronen, BGD/MBGD und vier Tasks pro Rechner untersucht. Die Mini Batch Größe betrug für alle Tests konstante 384 Datensätze pro Iteration. Die Tests erfolgten jeweils mit unterschiedlicher Anzahl von Rechnern, dabei entsprach die Rechneranzahl immer einer Potenz von zwei. Diese Rechneranzahl wurde gewählt, da sie für die verwendete Binary Tree Kommunikation optimal ist. 0 15000 30000 45000 60000 75000 90000 105000 120000 135000 150000 1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner Itera&onsdauer in ms BGD 500 Neuronen BGD 1000 Neuronen MBGD 500 Neuronen MBGD 1000 Neuronen Abbildung 6.6: horizontale Skalierung mit 3.840 Trainingsdaten In den Abbildungen Abbildung 6.6 und Abbildung 6.7 sind Iterationsdauer bzw. Speedup der einzelnen Testergebnisse dargestellt für 3.840 Trainingsdaten. Auf einem Rechner benötigen BGD und MBGD noch ungefähr die selbe Zeit für eine Iteration, der Overhead ist hier noch sehr gering. Für BGD wurde für alle Tests mit steigender Rechneranzahl eine kürzere Iterationsdauer und damit ein steigender Speedup festgestellt. Allerdings bricht der Speedup für BGD mit 500 Neuronen bei 16 Rechnern ein, so dass hier keine größere Steigerung mit weiteren Rechnern zu erwarten ist. Für MBGD lässt sich, wie beim Test der vertikalen Skalierbarkeit, ein geringer bis negativer Speedup feststellen, d.h. MBGD profitierte ab zwei Rechnern nicht mehr von weiteren Rechnern, da die Kommunikationskosten überwogen. 0 1 2 3 4 5 6 1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner BGD 500 Neuronen BGD 1000 Neuronen MBGD 500 Neuronen MBGD 1000 Neuronen Abbildung 6.7: Speedup für 3.840 Trainingsdaten
- 67. KAPITEL 6. AUSWERTUNG59 0 200000 400000 600000 800000 1000000 1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner Itera&onsdauer in ms BGD 500 BGD 1000 Neuronen Abbildung 6.8: horizontale Skalierung mit 38.400 Trainingsdaten Der selbe Test wurde mit 38.400 Trainingsdaten ausgeführt. Allerdings wurde diesmal auf MBGD verzichtet, da hier ähnliche Resultate zu erwarten waren. Mit zunehmender Rechneran- zahl sinkt in diesem Test auch die Anzahl an Trainingsdaten pro BSP-Peer. Sowohl bei einem Rechner als auch bei 16 Rechnern würden 100 Iteration mit MBGD benötigt, um das MLP mit allen Trainingsdaten zu trainieren. Das würde wiederum sehr hohe Kommunikationskosten und daraus folgend auch in diesem Test einen negativen Speedup bedeuten. Die Ergebnisse der Tests sind in Abbildung 6.8 und Abbildung 6.9 dargestellt. Mit ei- ner Verzehnfachung der Anzahl an Trainingsdaten verzehnfachte sich näherungsweise auch die Iterationsdauer. Der erreichte Speedup war teils doppelt so hoch, wie der Speedup für 3.840 Trainingsdaten. Bis zu einer Rechneranzahl von acht Rechnern ist er näherungsweise linear, dabei ist der Speedup für ein Netzwerk mit 1.000 Neuronen in allen Schichten größer als mit 500 Neuronen. Auch in diesem Test, ließ sich feststellen, dass die Skalierbarkeit von Modellgröße, Anzahl an Trainingsdaten und von der Batchgröße abhängt. Je größer diese Werte sind, um so besser ist auch die horizontale Skalierbarkeit. 1 3 5 7 9 11 13 15 1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner Op3mum BGD 500 Neuronen BGD 1000 Neuronen Abbildung 6.9: Speedup für 38.400 Trainingsdaten
- 68. KAPITEL 6. AUSWERTUNG60 6.4 Laufzeittests einzelner Komponenten Die Skalierungstests wurden mit aktiviertem Cache und der Binary Tree Kommunikation durch- geführt, ohne das auf diese Komponenten genauer eingegangen wurde. In den folgenden Un- terkapitel findet sich deshalb eine genauere Untersuchung dieser Komponenten, bezüglich ihres Einflusses auf die Laufzeit des Programms. Den Abschluss dieses Unterkapitels bildet der Ver- gleich der Matrizen Bibliotheken Apache Mahout und jblas. Für alle Tests gilt, dass sie 100 mal bzw. im Falle der Kommunikation 40 mal wiederholt wurden. Die jeweils dargestellten Ergebnisse sind die Mittelwerte dieser Testergebnisse. 6.4.1 Einfluss des Caches auf die Ladezeit 0 1 2 3 4 5 6 7 8 9 10 256 2560 25600 256000 Speedup (a) Speedup in Abhängigkeit zur Datenmenge. 1 10 100 1000 10000 256 2560 25600 256000 Zeit in ms mit Cache ohne Cache (b) Ladezeit in Abhängigkeit der Datenmenge. Abbildung 6.10: Cache: Gegenüberstellung von Speedup und Ladezeit In diesem Unterkapitel wird der Einfluss des Caches auf die Gesamtladezeit anhand ver- schiedener Datenmengen näher beleuchtet. In den Abbildungen 6.10(a) und 6.10(b) sind die Ergebnisse der Tests, in Form eines Speedup-Diagramms bzw. die Ladezeiten für unterschied- liche Datenmengen, dargestellt. Die Ladezeit steigen mit und ohne Cache ungefähr linear zur Datenmenge an, dabei verkürzt sich die Ladezeit um den Faktor vier, wenn die Daten im Ar- beitsspeicher gehalten werden. Die angegebenen Datenmengen gelten pro BSP-Peer, d.h. um eine signifikante Verkürzung der Trainingsdauer zu erreichen, müsste die Datenmenge pro BSP-Peer mindestens 250.000 Datensätze betragen. Für die im Rahmen dieser Arbeit verwendeten Datenmengen, ließ sich aus diesem Grund auch keine signifikante Verkürzung der Iterationsdauer unter Verwendung eines Caches ermitteln. 6.4.2 Vergleich von sequentieller und Binary Tree Kommunikation Im Rahmen dieser Arbeit wurden mit der sequentiellen und der Binary Tree Kommunikation zwei unterschiedlicher Verfahren zu Kommunikation implementiert, die nachfolgend miteinan-
- 69. KAPITEL 6. AUSWERTUNG61 der verglichen werden. Das hierfür verwendete MLP hatte einen Eingabevektor mit 1.000 Zeilen und 1.000 Neuronen in der versteckten bzw. in der Ausgabeschicht. Das Training erfolgte mit dem Lernverfahren BGD und 3.840 Trainingsdaten. Die Testdurchführung erfolgte in einer verteilten Umgebung mit vier BSP-Peers pro Rechner und einem, zwei, vier, acht und sech- zehn Rechnern. Der Testdurchlauf mit sequentieller Kommunikation und unter Verwendung von sechzehn Rechnern, wurde allerdings nach zehn Minuten abgebrochen, da kein Fortschritt feststellbar war. 0 1 2 3 4 5 6 7 8 9 1 Rechner 2 Rechner 4 Rechner 8 Rechner Op4mum Seq. Komm. Binary Tree Komm. (a) Speedup in Abhängigkeit zur Rechneranzahl 0 20000 40000 60000 80000 100000 120000 1 Rechner 2 Rechner 4 Rechner 8 Rechner Itera&onsdauer in ms Sequen1elle Komm. Binary Tree Komm. (b) Iterationsdauer in ms in Abhängigkeit zur Rech- neranzahl. Abbildung 6.11: Kommunikation: Gegenüberstellung von Speedup und Iterationsdauer In den obigen Abbildungen sind die Testergebnisse dargestellt. Die Iterationsdauer für bis zu zwei Rechner ist bei beiden Verfahren annähernd gleich. Wenn jedoch mehr als zwei Rechner verwendet wurden, zeigte sich, dass die sequentielle Kommunikation deutlich langsamer ist. Der Grund dafür lässt sich in Abbildung 6.12 ablesen. Der Anteil der Kommunikationsdauer an der gesamten Iterationsdauer wächst bei der sequentiellen Kommunikation deutlich schneller als bei der Binary Tree Kommunikation, wenn mehr Rechner verwendet werden. Aus diesem Grund wurde die Binary Tree Kommunikation standardmäßig in allen Tests genutzt. 6.4.3 Vergleich von Apache Mahout und jblas Wie bereits in Unterabschnitt 5.2.2 beschrieben, ist die vom MLP Framework verwendete Matrix-Bibliothek jederzeit austauschbar. Es stehen die Matrizen Bibliotheken von Apache Mahout und jblas zur Auswahl. Welchen Einfluss eine Verwendung dieser Bibliotheken auf die Laufzeit hat wird nachfolgend untersucht. Framework / Anzahl Neuronen Mahout jblas-Wrapper 500 Neuronen 20 ±2 41 ±2 1000 Neuronen 90 ±4 200 ±8 Tabelle 6.7: Zeitmessung der Gradientenberechnung für ein Trainingsbeispiel in ms In der obigen Tabelle finden sich die Zeiten zur Gradientenberechnung, in Abhängigkeit zur Neuronenanzahl und des verwendeten Frameworks. Aus den obigen Daten lässt sich ab-
- 70. KAPITEL 6. AUSWERTUNG62 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Seq. Komm. (1) Seq. Komm. (2) Seq. Komm. (4) Seq. Komm. (8) Binary Tree (1) Binary Tree (2) Binary Tree (4) Binary Tree (8) Gradientenberechnung KommunikaFon Abbildung 6.12: Prozentualer Anteil von Kommunikation und Gradientenberechnung an der gesamten Iterationsdauer. lesen, dass die Berechnungen unter Verwendung der Mathe-Bibliotheken von Apache Mahout am schnellsten erfolgten. Das gilt auch für die Berechnung des Gewichtsupdates, auf dessen Darstellung verzichtet wurde. Um genauer herauszufinden wie die Laufzeiten der einzelnen Methoden sind, wurde die aspektorientierte Programmierung mit Aspectj (siehe [Fou]) benutzt. Aspectj bot den Vorteil, dass hiermit deutlich weniger Code benötigt wird. Andernfalls hätte für jeden Methodenaufruf die Implementierung einer Zeitmessung erfolgen müssen. In Listing 6.1 findet sich der zum Profiling des MLP verwendete Code. In Zeile zwei ist der pointcut dargestellt, der bestimmt an welcher Stelle die sparse-Methode (Zeilen 4-10) in den ursprünglichen Programmablauf eingebunden werden soll. Sie dient der Zeitmessung und wird vor jedem Methodenaufruf aufgerufen, außer es handelt sich bei der aufzurufenden Methode um eine main-Methode oder um Methoden der Klasse „MLP_Profiler“. 1 private final Map<String, Long> methodTimes=newHashMap<String, Long>(); 2 pointcut sparse() : execution(* *(..)) && !execution(* main(..)) && !within(MLP_Profiler); 3 4 Object around(): sparse() { 5 final long start =System.nanoTime(), end; 6 Object result = proceed(); 7 end=System.nanoTime(); 8 this.methodTimes.put(getJoinPointName(thisJoinPoint), end - start); 9 return result; 10 } Listing 6.1: Ermittlung der benutzten Methoden und deren Laufzeit mit Aspectj
- 71. KAPITEL 6. AUSWERTUNG63 Das Profiling des MLP erfolgte für die Gradientenberechnung und die Berechnung des Ge- wichtsupdates, wodurch die Methoden mit der längsten Laufzeit und dem größten Optimie- rungspotential ermittelt wurden. Für diese Methoden erfolgte dann ein Vergleich der Laufzei- ten, für die beiden zur Verfügung stehenden Bibliotheken. Die Ergebnisse sind in Tabelle 6.8 dargestellt. Framework / Rechenmethode DenseMatrix (Mahout) JDenseMatrix (jblas-Wrapper) Multiplikation 111,27 ±6, 8 11,56 ±2, 6 Addition 46,07 ±3, 4 49,98 ±7, 8 DoubleDouble Funktion 22,17 ±2, 6 171,42 ±3 Vektor DenseVector (Mahout) JDenseVector (jblas-Wrapper) Cross 113,02 ±5, 12 280,54 ±7, 86 Tabelle 6.8: Linux: Zeitmessung verschiedener Rechenoperationen in ms für eine 1000x1000 Matrix und einen Vektor mit 1000 Zeilen. Wie in der obigen Tabelle ersichtlich, erfolgt die Multiplikation zweier Matrizen mit jblas deutlich schneller als mit der Mathe-Bibliothek von Apache Mahout. In den anderen dargestell- ten Rechenoperationen ist es jedoch teils deutlich langsamer. Das ist auch der Grund dafür, dass das Training unter Verwendung von jblas langsamer ist. Warum dies im Detail der Fall ist, wurde aus Zeitgründen nicht weiter untersucht. Für zukünftige Arbeiten scheint es jedoch sinnvoll, die Matrizenmultiplikation von jblas zu benutzen und Apache Mahout für alle anderen Rechenoperationen zu verwenden oder weitere Bibliotheken in Betracht zu ziehen. 6.5 Untersuchung des Arbeitsspeicherverbrauchs Im Rahmen dieses Unterkapitels wird untersucht, wie viel Arbeitsspeicher von dem Framework Apache Hama bzw. von dem verteilten MLP benötigt werden. Der erste Teil dieses Unterkapitels beruht auf empirischen Untersuchungen mit dem Linux-Tool top, während der zweite Teil eine theoretische Betrachtung dieses Problems ist. Wie bereits beschrieben, wurde im Rahmen dieser Arbeit das verteilte Dateisystem HDFS von Apache Hadoop verwendet. Dementsprechend liefen auf allen Rechnern nicht nur Dienste von Apache Hama sondern auch Dienste von HDFS. Das heißt, dass auf allen Rechnern ein Datanode von Apache Hadoop sowie ein Groom-Server von Apache Hama liefen. Auf fünf Rechnern lief zusätzlich der Dienst Zookeeper aus dem Framework Apache Zookeeper (siehe [Whi11], Seite 441-474), zur Synchronisation der einzelnen Rechner. Weiterhin liefen zusätzlich auf einem Rechner die Dienste Namenode, Secondary Namenode von Apache Hama und der Dienst BspMaster von Apache Hama, nachfolgend Master-Rechner genannt. Die Dienste Datanode, Zookeeper und Groom-Server reservieren ungefähr 100 MB Ar- beitsspeicher, während die restlichen Dienste noch einmal zusätzlich ca. 180 MB reservieren.
- 72. KAPITEL 6. AUSWERTUNG64 Startet man einen BSP-Job, dann reserviert zusätzlich jeder BSP-Peer zwischen 300 und 500 MB an Arbeitsspeicher. Betrachtet man den theoretischen Arbeitsspeicherbedarf des MLP, dann hält jeder BSP- Peer eine Reihe von Einstellungen, das Modell und mit eingeschaltetem Cache einen Teil der Trainingsdaten im Arbeitsspeicher. Zusätzlich dazu muss ein Master-Peer noch weitere Daten im Arbeitsspeicher halten, die von dem verwendeten Lernverfahren abhängen2 . Die Trainingsdaten werden jeweils in einem Sparse Vector und standardmäßig mit Dou- ble Werten als Inhalt gespeichert. In einem Sparse Vector wird Arbeitsspeicher nur für Zeilen benötigt deren Wert ungleich null ist. In einem 64-Bit System sind das 8 Byte. Je nach An- wendungsfall und benötigter Genauigkeit könnten hier auch Werte vom Type Float mit 4 Byte bzw. Short mit 1 Byte Speicherbedarf verwendet werden. Für die im Rahmen dieser Arbeit verwendete Menge an Trainingsdaten ist der Bedarf an Arbeitsspeicher vernachlässigbar gering, so dass der Typ der Eingabe bei der Standardein- stellung belassen wurde. Der Arbeitsspeicherbedarf der Einstellungen, wie z.B. die Anzahl an Iterationen, ist ebenfalls vernachlässigbar gering und beträgt schätzungsweise weniger als 1 KB. Den größten Teil des Arbeitsspeicherbedarfs macht das auf jedem BSP-Peer gespeicherte Modell in Form der Neuronenverbindungen aus. Sie werden in einem Matrix-Array gespeichert, der Objekt-Typ ist dabei aus Gründen der Genauigkeit vom Typ Double. Die Matrix ist nicht Sparse, da die Gewichte zum größten Teil einen Wert ungleich null aufweisen. Das bedeutet, dass z.B. für ein MLP mit 1.000 Neuronen in allen drei Schichten und damit 2.000.000 Neu- ronenverbindungen ca. 15 MB benötigt werden. Der selbe Wert wird für das Versenden von Nachrichten (Gradient und Gewichtsupdate) benötigt, da vor dem Versenden eine Serialisie- rung der Nachricht in ein Byte Array stattfindet, was den gleichen Speicherbedarf aufweist. Der Speicherbedarf des Master-Peer steigt, wenn Momentum, ADAGRAD oder iRprop+ verwendet werden. Zur Berechnung des Momentum wird die letzte Gewichtsänderung benö- tigt. Dessen Speicherbedarf entspricht demzufolge dem Speicherbedarf der Neuronengewichte. Das selbe gilt für ADAGRAD, nur das hier die Summe der partiellen Ableitungen für jedes Neuronengewicht gespeichert wird. Der Speicherbedarf von iRprop+ entspricht der dreifachen Modellgröße, da die letzte Schrittweite, der letzte Gradient und das letzte Gewichtsupdate für die Berechnung des nächsten Gewichtsupdates benötigt werden. Diese Werte müssen vor dem Start des Trainings berücksichtigt werden, d.h. das die maxi- male Netzgröße vom kleinsten verfügbaren Arbeitsspeicher abhängt. Eine geeignete Maßnahme betrifft bei geringen verfügbaren Arbeitsspeicher betrifft den Master-Peer, der den höchsten Speicherbedarf hat und von der Anwendung gewählt wird. Ist ansonsten nicht genügend Ar- beitsspeicher vorhanden, könnte z.B. die Anzahl von BSP-Peers auf einem Rechner auf eins beschränkt und dieser Rechner zum Master-Peer bestimmt werden. 2Das betrifft nur einen BSP-Peer, da die Berechnung des Gewichtsupdates nur durch einen BSP-Peer erfolgt.
- 73. KAPITEL 6. AUSWERTUNG65 6.6 Performancetests Im Rahmen dieser Arbeit wurde eine Reihe an Performancetests, zum Vergleichen der verwen- deten Trainingsalgorithmen und Initialisierungsarten, durchgeführt. Die Aufnahme der Mess- werte erfolgte für jedes Verfahren in über 100 Durchläufen. Die MONK-Daten bzw. Xing-Profile wurden zum Trainieren verwendet, dabei entsprach der für die MONK-Daten verwendete Netz- aufbau dem in Unterabschnitt 6.2.2 beschriebenen Netzaufbau. Für die Xing-Profile wurde ein Netzwerk mit 20 Neuronen in allen drei Schichten verwendet. Damit alle Verfahren unter den gleichen Bedingungen getestet werden, erfolgt die Wahl des Seed-Werts zum Initialisieren der Verbindungsgewichte nicht zufällig. Für jeden Testdurchlauf eines Verfahrens wird der Seed- Wert um eins hochgezählt, beginnend mit dem Seed-Wert: 1. Als Vergleichskriterium dient der Fehlerwert, je geringer der Fehlerwert und die zum Errei- chen dieses Fehlerwerts benötige Anzahl an Iterationen sind, um so besser ist der Algorithmus. Für die Bewertung der Algorithmen spielt es zumindest in diesem Kapitel keine Rolle, wie groß die Kommunikationskosten sind. In den Grafiken dieses Unterkapitels werden nur die je- weils im Vergleich mit BGD schnellsten Algorithmen dargestellt. Die Einzelergebnisse für alle Algorithmen finden sich in Anhang B. 6.6.1 Messung: Iterationsanzahl bis zur Erreichung eines Zielfehler- werts Ziel dieses Tests war es, herauszufinden wie viele Iterationen ein Trainingsalgorithmus im Durch- schnitt benötigt, um den Fehlerwert 0, 1 zu erreichen. Die Testdurchführung erfolgte unter an- derem mit SGD und anhand der MONK-Daten, da dieses Problem ausreichend klein und die Anzahl an Trainingsdaten gering sind. Auf eine zufällige Verteilung der Trainingsdaten vor dem Training wurde in Abweichung zum Standardvorgehen mit SGD verzichtet, da sie bereits zufäl- lig ausgewählt wurden und im Gegensatz zu z.B. Timeseries-Daten keine Ordnung aufweisen. BGD BGD-‐Momentum iRprop+ SGD-‐ADAGRAD max 4690 920 123 107 min 3562 652 38 38 avg 4119,85 805 63,47 62,64 1 10 100 1000 10000 Anzahl Itera,onen Abbildung 6.13: MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand der Anzahl an Iterationen bis zum Fehlerwert 0,1, mit logarithmischer Skalierung.
- 74. KAPITEL 6. AUSWERTUNG66 In der obigen Tabelle sind die schnellsten Optimierungsverfahren für Batch- und Online- Lernverfahren zum Vergleich dargestellt. Unter den Batch-Lernverfahren wurde die Zielfehler- rate mit Momentum am schnellsten erreicht, wenn die Initialisierung durch LeCuns Algorithmus erfolgte. Vergleicht man die Ergebnisse aller Batch-Lernverfahren, dann war allerdings die In- itialisierung mit Ngyen/Widrow am erfolgreichsten. Mit ADAGRAD musste die Anzahl der Iterationen auf 50.000 begrenzt werden, da der Zielfehlerwert oftmals auch nach über 200.000 Iterationen noch nicht erreicht wurde. Vermutlich war die mit ADAGRAD ermittelte adaptive Lernrate zu hoch. Insgesamt gesehen waren die Verfahren iRprop+ und SGD am schnellsten. Bei iRprop+ ließ sich in diesem Test keine Abhängigkeit von der Initialisierungsform feststellen. Alle getesteten Verfahren erreichten hier ähnliche Werte. Das gilt mit Einschränkungen auch für SGD. Wenn ADAGRAD in Verbindung mit dem Initialisierungsalgorithmus von Glorot/Bengio verwendet wurde, dann war das Training im Mittel zwischen 30% (Momentum & ADAGRAD) und 100% langsamer als mit LeCun oder mit Ngyen/Widrow. 6.6.2 Messung: Fehlerwert nach 50 Iterationen In diesem Test wurde untersucht, welcher Fehlerwert nach 50 Iterationen in Abhängigkeit vom Lernverfahren erreichbar ist. Das Training erfolgte unter anderem mit einer Mini-Batch Größe von 100 und anhand eines MLPs mit 20 Neuronen in allen drei Schichten und 54.000 Xing- Profilen (siehe Abbildung 6.14). Außerdem erfolgte ein Training mit den MONK-Daten (siehe Abbildung 6.15). BGD BGD-‐ADAGRAD-‐ Momentum (Glorot/ Bengio) iRProp+ (Glorot/Bengio) MBGD-‐100 -‐ADAGRAD-‐ Momentum (Glorot/ Bengio) max 6,227 0,46 0,1732 0,132 min 5,503 0,29 0,1359 0,116 avg 5,762 0,37 0,154 0,122 0,1 1 10 Fehlerwert Abbildung 6.14: Xing (20): Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des Fehlerwerts nach 50 Iterationen, mit logarithmischer Skalierung. Für alle Tests mit den Xing-Profilen galt, dass der mit der Initialisierung von Glorot/Bengio ermittelte Fehlerwert im Mittel am geringsten war. Das gilt zum größten Teil auch für die MONK-Daten. Wenn man jeweils Maxima- und Minima des erreichten Fehlerwerts betrachtet,
- 75. KAPITEL 6. AUSWERTUNG67 dann scheint die Abhängigkeit von der Initialisierung bei den Xing-Daten geringer als beim MONK-Problem zu sein. Das lässt sich daran erkennen, dass sie bei den Xing-Daten für alle untersuchten Verfahren deutlich näher am Mittelwert sind als beim MONK-Problem. Auch in diesem Test erreichten iRprop+ und MBGD bzw. SGD die besten Ergebnisse. Beim Training mit den Xing-Daten schnitt ADAGRAD in Kombination mit Momentum sowohl mit BGD als auch mit MBGD am besten ab. Diese Kombination schnitt beim MONK-Problem im Gegensatz dazu am schlechtesten ab. Der Fehlerwert war hier sogar höher als BGD ohne weitere Optimierungen. BGD BGD-‐Momentum (Glorot/Bengio) iRprop+ SGD-‐Momentum (Glorot/Bengio) max 65,986 50,353 39,389 29,703 min 53,663 3,515 0,046 0,045 avg 61,419 24,654 5,181 4,615 0,010 0,100 1,000 10,000 100,000 Fehlerwert Abbildung 6.15: MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des Fehlerwerts nach 50 Iterationen. In Abbildung 6.16 sind beispielhaft die Fehlerkurven für die drei besten Verfahren im Ver- gleich mit BGD dargestellt. Die Fehlerkurve wird jeweils für die ersten 50 Iterationen und den Seed-Wert eins dargestellt. Anhand der Abbildung lässt sich ablesen, wie die einzelnen Verfahren agieren. Sie starten alle mit dem gleichen Fehlerwert. Die Änderungsrate des Fehlerwerts ist bei allen Verfahren zu Beginn am größten und flacht dann immer weiter ab. Sowohl iRprop+ als auch MBGD erreichen einen sehr geringen Fehlerwert, der wenn überhaupt von den anderen Verfahren erst nach sehr vielen Iterationen erreicht werden kann. MBGD scheint hier bereits nach der ersten Iteration einen sehr geringen Fehlerwert erreicht zu haben. Die Iterationszahl steht jedoch für das Training über alle Trainingsdaten, es fanden hier also bereits 5.400 Gewichtsupdates statt, was wiederum den geringeren Fehlerwert erklärt
- 76. KAPITEL 6. AUSWERTUNG68 0,1 1 10 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 Fehlerwert BGD BGD-‐ADA.-‐Mom. MBGD-‐ADA.-‐Mom. iRprop+ Abbildung 6.16: Xing (20): Fehlerkurve über 50 Iterationen in Abhängigkeit zum Lernverfahren, exemplarisch für den Seed-Wert eins.
- 77. KAPITEL 6. AUSWERTUNG69 6.7 Xing-Profildaten 6.7.1 Problembeschreibung Ein Ziel dieser Arbeit war es, herauszufinden, ob die syntagmatische und paradigmatische Rela- tion mit Hilfe eines MLP extrahiert werden kann. Zuerst soll deshalb geklärt werden, was diese Begriffe im Allgemeinen und bezogen auf den Anwendungsfall der Xing-Profildaten bedeuten. Manning und Schütze definieren diese Begriffe folgendermaßen (siehe [MS99], Seite 94): „All elements that can be replaced for each other in a certain syntactic position ... are members of one paradigm. In costrast, two words bear a syntagmatic relationship if they form a phrase (or syntagma) like skewed clothes or sewed a dress. An important class of syntagmatically related words are collocations.“ Das wird in dem folgenden allgemeinen Beispiel (aus [MS99], Seite 94) noch einmal verdeut- licht. Alle dort vertikal innerhalb einer Klammer angeordneten Elemente sind untereinander austauschbar und somit ein Beispiel für eine paradigmatische Relation. Alle horizontal ange- ordneten Elemente haben eine syntagmatische Beziehung zueinander. She the woman the tall woman the very tall woman the tall woman with sad eyes ... saw him the man the short man the very short man the short man with red hair ... . Bezogen auf die Xing-Daten könnte das z.B. wie unten dargestellt aussehen. Innerhalb einer Klammer finden sich jeweils außer-fachliche oder berufstypische Qualifikationen, die untereinan- der austauschbar sind. Jede Spalte würde dann eine Klasse von Qualifikationen repräsentieren. In diesem Beispiel würde die zweite Spalte die Klasse der Programmiersprachen darstellen. Eine Zeile mit einem oder mehreren Elementen aus jeder Spalte könnte z.B. das Profil eines Software-Entwicklers darstellen. Ein Anwendungsfall wäre z.B. die Verbesserung eines Suchalgorithmus. So könnte die Suche nach einem Software-Entwickler unter dem Suchbegriff Eclipse auch Profile als Ergebnis liefern die den Begriff Netbeans enthalten. Eclipse Netbeans IntelliJ JDeveloper V isual Studio ... Java C PHP C# Scala ... Webdesign Webentwicklung Softwareentwicklung Qualitätsmanagement Projektleitung ... Zuverlässigkeit Führungserfahrung Flexibel Kommunikationsfähigkeit Eigeninitiative ...
- 78. KAPITEL 6. AUSWERTUNG70 6.7.2 Datenaufbereitung Die Rohdaten wurden wie bereits beschrieben von Prof. Dr. Herta in Form einer Textdatei mit über 1.100.000 Benutzerprofilen zur Verfügung gestellt. Jede Zeile dieser Datei beinhaltete die Profilangaben eines Benutzers. Alle Qualifikationen eines Benutzers waren durch ein Se- mikolon voneinander getrennt und wurden vom Benutzer in Form eines Freitextes angegeben. Das heißt, dass eine Profilbeschreibung auch in Satzform erfolgte. Für die weitere Verarbei- tung wurde jedoch eine gewisse Form benötigt, die ausschließlich fachliche und außer-fachliche Qualifikationen beinhaltet. Die Datenaufbereitung erfolgte in mehreren Schritten. Zuerst wurden Sonderzeichen und Stoppwörter entfernt. Im nächsten Schritt wurden alle Leerzeichen entfernt, alle Großbuchsta- ben in Kleinbuchstaben umgewandelt und dann alle Zeichenfolgen entfernt die länger als 20 Zeichen sind, um möglichst alle Sätze zu entfernen bzw. eine einheitliche Schreibweise zu er- reichen. Im nächsten Schritt wurde eine nach der Anzahl an Vorkommen sortierte Wörterliste erstellt, die alle vorkommenden Wörter und deren Gesamtanzahl an Vorkommen enthält. Für den Anwendungsfall mit z.B. 500 Eingaben wurden die 500 häufigsten Wörter ausge- wählt, alle Profile auf diese Wörter hin untersucht und in das in Abschnitt 4.1.1 beschriebene Format überführt. Enthielt ein Profil weniger als drei Wörter aus dieser Liste, dann wurde es verworfen. Diese Vorgehensweise ist nicht unbedingt optimal, jedoch war eine andere Vorgehensweise aus Zeitgründen nicht möglich. Dies hat zur Folge dass eine Reihe von Qualifikationen verworfen wurden, wenn sie in einem längeren Satz vorkamen. Außerdem kam es zu Dopplungen innerhalb der Wörterliste, da Wörter nicht auf Ihren Wortstamm zurückgeführt wurden, wie z.B. flexibel und Flexibilität. In zukünftigen Arbeiten sollte untersucht werden, inwieweit z.B. eine „part- of-speech“ Ermittlung zum Erkennen der Qualifikationen möglich und sinnvoll ist. 6.7.3 Vorgehensweise Das Training des MLP erfolgte nach dem Denoising Autoencoder-Ansatz, bei dem die Eingabe verrauscht wird. Mit einer 50 prozentigen Wahrscheinlichkeit wurden bis auf einen zufällig ausgewählten Wert alle Eingaben auf null gesetzt. Ansonsten wurden 20 Prozent der Eingaben auf den Wert null gesetzt. Die erwartete Ausgabe entsprach in allen Fällen der ursprünglichen nicht verrauschten Eingabe. Auf die Nutzung eines Sparse Autoencoders musste verzichten werden, da eine Implementierung aus Zeitgründen nicht mehr erfolgen konnte. Stattdessen wurde eine Netzform gewählt, die deutlich weniger Neuronen in der versteckten Schicht hat als Eingaben bzw. Ausgabeneuronen. Als Eingabe diente ein sogenannter „bag-of-words“ Vektor, der nicht normalisiert wurde. Eine eins repräsentiert demzufolge das Vorhandensein eines Wortes in einem Profil, während eine null das Gegenteil darstellt. Wie ein Eingabevektor bzw. der erwartete Ausgabevektor und die Netzform aussehen könnte, ist beispielhaft für ein MLP mit sechs Eingaben in Abbildung 6.17
- 79. KAPITEL 6. AUSWERTUNG71 dargestellt. In diesem Beispiel würde das Benutzerprofil die Worte Eclipse, Network und OSGi enthalten. Abbildung 6.17: Training des MLP mit der Identität ohne verrauschten Eingabevektor. Die Evaluation des trainierten MLP erfolgte wie bereits in Unterabschnitt 4.1.3 beschrieben, anhand der Ausgabe des MLP, sowie anhand der Neuronen in der versteckten Schicht. Um die syntagmatische Relation zu ermitteln, wurde nacheinander immer ein Wert der Ein- gabe auf eins gesetzt und die dazugehörige Ausgabe des MLP untersucht. Das ist beispielhaft in Abbildung 6.18(a) dargestellt. Allerdings liegen in Abweichung zur Abbildung die Ausgabewerte in dem Wertebereich [0, 1] und mussten nach dem höchsten Wert sortiert werden. (a) Syntagmatische Relation (b) Paradigmatische Relation Abbildung 6.18: Analyse von Ausgabe- bzw. versteckter Schicht in Abhängigkeit der gesuchten Beziehung Die Untersuchung bezüglich der paradigmatischen Relation wird in Abbildung 6.18(b) bei- spielhaft dargestellt. Hier wurde für jedes Neuron in der versteckten Schicht überprüft, welche Eingabe zu einer maximalen Aktivierung dieses Neurons führt. Der Eingabevektor wurde dann
- 80. KAPITEL 6. AUSWERTUNG72 nach der Größe sortiert, unter der Annahme, dass die jeweils repräsentierten Wörter eine pa- radigmatische Beziehung zueinander aufweisen. Das eigentliche Training erfolgt mit iRprop+ und wurde nach 2.000 Iterationen abgebro- chen, da der Cluster nur für einen begrenzten Zeitraum zur Verfügung stand. Zum Vergleich wurde ein MLP mit 500 Eingaben und ca. 260.000 Profilen, sowie ein MLP mit 1.000 Eingaben bzw. Ausgabeneuronen und ca. 400.000 Profilen trainiert. Beide neuronalen Netze hatten eine versteckte Schicht mit 25 Neuronen. 6.7.4 Auswertung Wie bereits erläutert, lag für diese Daten weder ein „gold standard“ (siehe Unterabschnitt 4.1.3, Seite 36) vor noch konnte dieser aus Zeitgründen erstellt werden. Zur Auswertung der Ergebnisse wurde deshalb untersucht, ob für ausgewählte Daten die Ergebnisse den Erwartungen des Autors entsprechen, die bereits zu Beginn dieses Kapitels vorgestellt wurden. Als erstes soll eine Aussage über die allgemeine Güte des Trainings getroffen werden. Die neuronalen Netze wurden mit der Identität trainiert, d.h. das im Optimalfall die Ausgabe eines Netzes der Eingabe entspricht. Wenn zum Beispiel der Eingabevektor nur in der ersten Zeile eine eins enthält, dann sollte der Ausgabevektor in der ersten Zeile einen Wert nahe eins enthalten. Um das zu überprüfen, wurde die Ausgabe nacheinander für alle Zeilen des Eingabevektors ermittelt, wobei immer nur eine Zeile des Eingabevektors einen Wert ungleich null enthielt. Der Wert der gleichen Zeile des Ausgabevektors wurde gespeichert. Daraus wurde der Mittelwert für alle Zeilen berechnet. Dieser Wert lag bei dem Netz mit 500 Eingaben bei ca. 0,12 und bei dem Netz mit 1.000 Eingaben bei ca. 0,04. Beide Netze weisen demnach auch einen entsprechend hohen Fehlerwert auf und sollten wahrscheinlich noch weiter trainiert werden. Wie bereits beschrieben, sollte die Vermutung überprüft werden, dass sich mit Hilfe der Ausgabe eines MLP Wörter ermitteln lassen, die eine syntagmatische Beziehung zur Eingabe aufweisen. Die Begriffe Webdesign und PHP wurden als Beispiel gewählt und die dazugehörige Ausgabe für die Netze mit 500 bzw. mit 1.000 Neuronen ermittelt. Nachfolgend finden sich die ersten 15 Ergebnisse, nach der Größe des Ausgabewerts sortiert. Sowohl PHP als auch Webdesign wiesen den höchsten Ausgabewert auf. Webdesign (1000): grafikdesign, marketing, fotografie, beratung, php, illustration, pro- grammierung, kreativität, cms, seo, internet, teamfähigkeit, printdesign, screendesign Webdesign (500): grafikdesign, php, corporate design, cms, fotografie, programmierung, beratung, css, flash, html, internet, seo, projektmanagement, kreativität PHP (1000): mysql, java, html, css, javascript, webdesign, sql, c++, c#, typo3, xml, linux, perl, teamfähigkeit
- 81. KAPITEL 6. AUSWERTUNG73 PHP (500): mysql, html, css, java, javascript, sql, webdesign, xml, linux, ajax, c++, cms, typo3, c# Im Ergebnis lässt sich sagen, dass beide Netze trotz unterschiedlicher Fehlerwerte für diese Begriffe sehr ähnliche Ergebnisse liefern. Tatsächlich scheinen diese Wörter auch eine syntagma- tische Beziehung aufzuweisen. Sie könnten zusammengenommen das Profil eines Webdesigners oder PHP-Entwicklers darstellen, was darauf hindeutet, dass sich das MLP für diese Aufgabe eignen könnte. Eine weitere These war, dass die versteckten Neuronen Features lernen, die der paradigmati- schen Relation entsprechen. Nachfolgend die Daten am Beispiel des ersten versteckten Neurons: Neuron 1 (1000): kommunikation, pr, rechnungswesen, it, teamfähig, php, vertrieb, web 2.0, ausdauer, vbnet, c#, solaris, moderation, css, kreativität Neuron 1 (500): xml, erfahrungsaustausch, c++, projektleitung, offenheit, vertriebserfah- rung, schnelle auffassungsgabe, html, c, personalentwicklung, führungserfahrung, bildbearbei- tung, eigeninitiative, training, humor Sowohl die obigen Daten als auch die Ergebnisse der restlichen Neuronen sprechen nicht für diese These, die aber auch nicht widerlegt werden kann. Möglicherweise lassen sich bessere Ergebnisse mit mehr Neuronen in der versteckten Schicht oder mit dem Sparse Autoencoder erzielen. Hierzu sollten noch umfangreichere Tests durchgeführt werden, die im Rahmen dieser Arbeit aus Zeitgründen entfallen mussten.
- 83. Kapitel 7 Fazit Diese Arbeitbeschreibt die Entwicklung einer Anwendung zum verteilten Training eines MLP mit Apache Hama und einem von der Universität HTW-Berlin zur Verfügung gestellten MLP- Framework. Ein Ziel dieser Arbeit war es, die korrekte Funktionsweise des verwendeten MLP- Frameworks zu überprüfen, was anhand von MONK-Daten und der XOR-Funktion erfolgte. Weitere Ziele dieser Arbeit waren die Feststellung der Eignung von Apache Hama für diese Anwendung und die Beschleunigung des Trainingsvorganges (siehe Abschnitt 3.3, Seite 25). Letzteres sollte durch die Verteilung des Trainings in einen Rechnercluster und durch die Im- plementierung verschiedener Algorithmen erreicht werden, was anhand von Performanz- und Skalierungstests überprüft wurde. Weiterhin wurde die These untersucht, ob sich sowohl syntagmatische als auch paradigma- tische Beziehungen mit einem MLP extrahieren lassen, das mit einem Denoising Autoencoder trainiert wurde. 7.1 Ergebnisse Validität des Frameworks. Sowohl das MLP-Framework als auch die gesamte Anwendung wurden auf ihre korrekte Funktionsweise überprüft. Wie erwartet verringert sich der Fehlerwert im Laufe des Trainings, während die Werte für Precision/Recall und F-measure steigen. Für die MONK-Daten als auch für die XOR-Funktion lässt sich demzufolge eine korrekte Funktionsweise feststellen. Diese Tests und die JUnit-Tests weisen darauf hin, dass das MLP-Framework korrekt arbeitet. Die Funktionalität der gesamten Anwendung wurde mit Hilfe von JUnit-Tests evaluiert, die ebenfalls auf eine korrekte Funktionsweise schließen lassen. Performanz und Skalierbarkeit. Die gesamte Anwendung wurde auf ihre horizontale und vertikale Skalierbarkeit in Abhängigkeit von Batchgröße, Modellgröße und Anzahl an Trainings- daten untersucht. Als Maß diente der Speedup. Zusammenfassend lässt sich sagen, dass je größer
- 84. KAPITEL 7. FAZIT76 Modell, Batchgröße und Anzahl an Trainingsdaten sind, um so größer ist auch der Speedup. Das liegt darin begründet, dass je größer diese Werte sind umso geringer ist der Anteil der Kommunikationskosten an der Gesamtlaufzeit und umso mehr profitiert die Anwendung von weiteren Rechnern/Threads. Teilweise konnte eine nahezu lineare Skalierbarkeit erreicht werden, allerdings nur unter Verwendung der Binary-Tree-Kommunikation. Die Anwendung skalierte mit der sequentiellen Kommunikation nur bis zu zwei Rechnern. Mit mehr als zwei Rechnern verlangsamte sich mit ihr die Anwendung, da die Kommunikationskosten überwogen. Das Training des MLP beruht auf verschiedenen Rechenoperationen mit Matrizen bzw. mit Vektoren. Aus diesem Grund wurde untersucht, inwieweit ein Austauschen der Matrizenbiblio- thek zu einem Geschwindigkeitsgewinn führt. Die untersuchte Matrizenbibliothek jblas war in der Multiplikation zweier Matrizen um den Faktor 10 schneller als die Bibliothek von Apache Mahout, jedoch war insgesamt das Training unter Verwendung von jblas am langsamsten. Da diese Berechnungen zu einem großen Teil die Gesamtlaufzeit des Programms ausmachen, sollte der Grund hierfür in zukünftigen Arbeiten Gegenstand der Untersuchung sein, evtl. könnte auch eine Kombination der Algorithmen von jblas und Apache Mahout in Betracht gezogen werden. Bezogen auf den Fehlerwert schnitten MBGD bzw. SGD in den Performanztests am besten ab. Das zweitbeste Verfahren war iRprop+, das ein Big-Batch-Lernverfahren ist. Bezieht man die Erkenntnisse der Skalierbarkeit mit ein, dann ist iRprop+ das optimale Verfahren. Es er- reicht nicht nur einen geringen Fehlerwert innerhalb weniger Iterationen, sondern weist auch die geringsten Kommunikationskosten auf und ist damit für die betrachteten Problemstellungen am besten geeignet. Der Einfluss der Initialisierung des MLP auf den Fehlerwert wurde ebenfalls untersucht. Hier schnitt die Initialisierung mit dem Verfahren von Glorot und Bengio insgesamt gesehen am besten ab. Analyse der Xing-Daten. Es wurden zwei Netze mit 500 bzw. 1000 Eingaben und mit dem Denoising Autoencoder Ansatz trainiert. Die Ergebnisse lieferten den Hinweis, dass es möglich sein sollte die syntagmatische Relation zu extrahieren. Bezüglich der paradigmatischen Beziehung kann keine endgültige Aussage getroffen werden. In beiden Fällen sollten weitere Untersuchungen mit einem Goldstandard und evtl. mit einem Sparse Autoencoder durchgeführt werden. 7.2 Ausblick Zusammenfassend erlauben die Ergebnisse den Schluss, das sich Apache Hama zum verteilten Trainieren eines MLP eignet, zumindest für die hier betrachteten Netzgrößen. Sowohl die expli- zite Unterstützung von Iterationen als auch die Möglichkeit das Modell über mehrere Iterationen hinweg im Arbeitsspeicher zu halten sind Grund für die gute Eignung dieses Frameworks.
- 85. KAPITEL 7. FAZIT77 Ein Nachteil von Apache Hama ist die Begrenzung der Kommunikation zwischen Prozessen auf eine synchrone Kommunikation. So kam es vor, dass einzelne BSP-Peers aufgrund der syn- chronen Verarbeitungsweise mehrere Sekunden warten mussten, bis die Berechnungen von allen BSP-Peers abgeschlossen wurden. Die bereits in der Anforderungsanalyse erwähnte Forschungs- arbeit (siehe Unterabschnitt 3.1.2) zeigt, dass insbesondere bei großen neuronalen Netzen eine Kombination aus asynchroner und synchroner Kommunikation von Vorteil sein kann, die mit Apache Hama nicht umsetzbar ist. Apache Hama unterstützt ausschließlich die Kommunikation in Form von Punkt-zu-Punkt Verbindungen. Die Implementierung der Binary Tree Kommunikation zeigte, dass sich damit die Kommunikation zwischen verteilten Prozessen effizient gestalten lässt. In zukünftigen Ar- beiten sollten noch weitere Algorithmen zur Inter-Prozess-Kommunikation untersucht werden. Interessant könnte z.B. „Chunk based parallel tree“ sein (siehe [BRF04][Seite 10]). Zum Trainieren des künstlichen neuronalen Netzes wurden im Rahmen dieser Arbeit aus- schließlich Verfahren erster Ordnung verwendet und auf ein Netz mit nur einer versteckten Schicht angewendet. In zukünftigen Arbeiten sollten Verfahren zweiter Ordnung in Betracht gezogen werden. Sowohl die adaptive Lernrate ADAGRAD als auch die Initialisierung der Neu- ronengewichte mit dem Verfahren von Nguyen und Widrow wurden für künstliche neuronale Netze mit mehreren versteckten Schichten entwickelt. Sie sollten dementsprechend noch anhand von Netzen mit mehreren versteckten Schichten untersucht werden.
- 87.
- 88. ANHANG A. KLASSENDIAGRAMME80 org.apache.hadoop.io.Writable <<interface>> +write(output:java.io.DataOutput) +readFields(input:java.io.DataInput) de.distmlp.messages.HamaMessage de.distmlp.messages.DoubleMessage -doubleValue:[double de.distmlp.messages.WeightMatrixMessage -matrix:[Matrix[] -stopTraining:[boolean -cost:[double Abbildung A.2: Klassen zur Realisierung der Nachrichten <<interface>> org.apache.hadoop.io.Writable <<nterface>> de.mlp_distributed.mlp.learning.OnlineLearner <<abstract>> de.mlp_distributed.mlp.classfier.AbstractVectorClassifier AclassifyFullginstance:VectorR de.mlp_distributed.mlp.core.MultiLayerPerceptron AMultiLayerPerceptrongnbInputUnits:intDnbOutputUnits:intD nbHiddenUnits:int[]D mutuallyExclusiveClasses:booleanD momentum:doubleR AassignRegularizationAndLearningrateggradients:Matrix[]R AgetDerivativeOfTheCostWithoutRegularizationginput:VectorD target:VectorR AtrainOnlineginput:VectorDtarget:VectorR Abbildung A.3: Darstellung der wichtigsten Methoden und Klassen des verwendeten MLP- Frameworks.
- 89. ANHANG A. KLASSENDIAGRAMME81 <<interface>> de.mlp_distributed.mlp.math.mahout.Vector +assign(value:double):MVector +assign(f:DoubleDoubleFunction,y:double):MVector +plus(x:Vector):MVector +cross(other:Vector):MMatrix de.mlp_distributed.mlp.math.jblas.JDenseVector mjdm:MDoubleMatrix de.mlp_distributed.mlp.math.mahout.AbstractVector +size:Mint de.mlp_distributed.mlp.math.mahout.RandomAccessSparseVector Abbildung A.4: Darstellung der verwendeten Vektorklassen inkl. deren wichtigsten Methoden.
- 90. ANHANG A. KLASSENDIAGRAMME82 <<abstract>> org.apache.hama.bsp.BSP<K1,LV1,LK2,LV2,LMLextendsLWritable> fbspdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E:LVector fsetupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E fcleanupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E <<abstract>> de.distMLP.train.Base_MLP_Trainer Wmlp:LMultiLayerPerceptron fsetupdpeer:BSPPeer<LongWritablehLTexthLNullWritableh TexthLHamaMessage>E fcleanupdpeer:BSPPeer<LongWritablehLTexth NullWritablehLTexthLHamaMessage>E freadNextTrainingExampledpeer:BSPPeer<LongWritableh TexthLNullWritableh TexthLHamaMessage>h ex:TrainingExampleE:Lboolean freopenInputdpeer:finalLBSPPeer<LongWritableh TexthLNullWritablehLTexthLHamaMessage>E WupdateWeightMatrixdgradients:Matrix[]E fsaveMLPdpeer:BSPPeer<LongWritablehLTexth NullWritablehLTexthLHamaMessage>h iterationNumber:intE de.distMLP.train.MLP_MiniBatchGD fbspdpeer:BSPPeer<LongWritablehLTexthLNullWritableh TexthLHamaMessage>E de.distMLP.train.MLP_RPROP WupdateWeightMatrixdgradients:Matrix[]E Abbildung A.5: Darstellung der BSP-Jobklassen.
- 91. Anhang B Einzelergebnisse der Performancetests B.1MONK: Anzahl Iterationen bis zum Fehlerwert 0,1 Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow BGD Maximum: 4690 4697 4630 Minimum: 3562 3140 3551 Konfidenzintervall: 4119,85 ± 47,24 4160,71 ± 47,14 4095,93 ± 51,44 ADAGRAD η = 1 Maximum: 50000 35848 43024 Minimum: 2629 3047 2800 Konfidenzintervall: 6007 ± 1570,56 5739 ± 921,16 5006 ± 792,38 Momentum Maximum: 920 992 2072 Minimum: 652 655 565 Konfidenzintervall: 805 ± 10,9 821 ± 12,66 802,72 ± 28,82 ADAGRAD & Momentum Maximum: 50000 50000 18585 Minimum: 699 1009 696 Konfidenzintervall: 5930,67 ± 1186,14 4358 ± 1066,18 3521,2 ± 654,82 Tabelle B.1: BGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1
- 92. ANHANG B. EINZELERGEBNISSEDER PERFORMANCETESTS 84 Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow Maximum: 228 123 146 Minimum: 37 38 37 Konfidenzintervall: 62,97 ± 4,38 63,47 ± 3,4 65,61 ± 3,42 Tabelle B.2: iRprop+: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow SGD Maximum: 105 156 108 Minimum: 33 39 39 Konfidenzintervall: 63,45 ± 2,9 63,33 ± 17,03 66,49 ± 3,04 ADAGRAD (η = 1) Maximum: 107 8867 152 Minimum: 38 39 37 Konfidenzintervall: 62,64 ± 2,82 151,14 ± 176,1 66,74 ± 3,42 Momentum Maximum: 132 108 142 Minimum: 35 32 41 Konfidenzintervall: 64,45 ± 3,24 62,19 ± 3,08 64,78 ± 3,38 Momentum & ADAGRAD Maximum: 166 1674 125 Minimum: 38 38 36 Konfidenzintervall: 64,46 ± 3,34 81,87 ± 32,58 62,49 ± 3,26 Tabelle B.3: SGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1
- 93. ANHANG B. EINZELERGEBNISSEDER PERFORMANCETESTS 85 B.2 MONK: Fehlerwert nach 50 Iterationen Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow BGD Maximum: 65,98 69,2 65,91 Minimum: 53,66 48,68 55,99 Konfidenzintervall: 61,42 ± 0,553 58,69 ± 0,782 61,83 ± 0,489 ADAGRAD η = 1 Maximum: 62,22 60,93 59,32 Minimum: 19,27 18,70 27,601 Konfidenzintervall: 45,69 ± 1,662 45,46 ± 1,594 46,67 ± 1,487 Momentum Maximum: 51,65 50,35 57,65 Minimum: 4,73 3,52 4,80 Konfidenzintervall: 26,48 ± 2,3 24,65 ± 2,658 26,02 ± 2,375 ADAGRAD & Momentum Maximum: 40,92 37,05 26,79 Minimum: 83,03 86,03 86,01 Konfidenzintervall: 62,13 ± 2,35 68,76 ± 3,16 61,87 ± 2,55 Tabelle B.4: BGD: Fehlerwert nach 50 Iterationen Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow Maximum: 39,389 36,552 33,505 Minimum: 0,046 0,051 0,058 Konfidenzintervall: 5,181 ± 1,557 5,921 ± 1,776 7,373 ± 1,876 Tabelle B.5: iRprop+: Fehlerwert nach 50 Iterationen
- 94. ANHANG B. EINZELERGEBNISSEDER PERFORMANCETESTS 86 Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow SGD Maximum: 33,394 28,071 31,95 Minimum: 0,052 0,045 0,064 Konfidenzintervall: 5,998 ± 1,602 4,687 ± 1,316 7,272 ± 1,698 ADAGRAD (η = 1) Maximum: 29,43 38,42 47,64 Minimum: 0,036 0,058 0,061 Konfidenzintervall: 5,89 ± 1,61 5,57 ± 1,57 7,2 ± 1,87 Momentum Maximum: 51,48 29,70 40,69 Minimum: 0,037 0,044 0,051 Konfidenzintervall: 6,65 ± 2,07 4,61 ± 1,34 6,87 ± 1,85 Momentum & ADAGRAD Maximum: 33,57 36,44 48,37 Minimum: 0,047 0,051 0,052 Konfidenzintervall: 6,32 ± 1,64 5,69 ± 1,69 5,77 ± 1,82 Tabelle B.6: SGD: Fehlerwert nach 50 Iterationen
- 95. ANHANG B. EINZELERGEBNISSEDER PERFORMANCETESTS 87 B.3 Xing20: Fehlerwert nach 50 Iterationen Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow BGD Maximum: 6,227 5,68 6,45 Minimum: 5,503 4,85 5,82 Konfidenzintervall: 5,762 ± 0,026 5,16 ± 0,03 6,06 ± 0,002 Adagrad (η = 0.1) Maximum: 1,91 1,86 1,87 Minimum: 1,43 1,19 1,5 Konfidenzintervall: 1,61 ± 0,002 1,49 ± 0,02 1,67 ± 0,016 Momentum Maximum: 2,83 2,45 3,05 Minimum: 2,38 1,98 2,59 Konfidenzintervall: 2,58 ± 0,019 2,16 ± 0,018 2,82 ± 0,018 Adagrad & Momentum (η = 0.1) Maximum: 0,57 0,46 0,66 Minimum: 0,35 0,29 0,35 Konfidenzintervall: 0,43 ± 0,01 0,37 ± 0,006 0,45 ± 0,012 Tabelle B.7: Batch Lernverfahren: Fehlerwert nach 50 Iterationen. Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow Maximum: 0,1835 0,1732 0,1909 Minimum: 0,1383 0,1359 0,1333 Konfidenzintervall: 0,1597 ± 0,0018 0,154 ± 0,0015 0,1616 ± 0,024 Tabelle B.8: iRprop+: Fehlerwert nach 50 Iterationen.
- 96. ANHANG B. EINZELERGEBNISSEDER PERFORMANCETESTS 88 Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/Widrow MBGD 100 Maximum: 0,17 0,17 0,168 Minimum: 0,132 0,133 0,1336 Konfidenzintervall: 0,148 ± 0,0016 0,147 ± 0,0015 0,134 ± 0,0014 Momentum Maximum: 0,153 0,152 0,154 Minimum: 0,12 0,121 0,12 Konfidenzintervall: 0,134 ± 0,0014 0,132 ± 0,0014 0,133 ± 0,0014 ADAGRAD Maximum: 0,177 0,164 0,18 Minimum: 0,131 0,129 0,133 Konfidenzintervall: 0,152 ± 0,002 0,144 ± 0,0018 0,156 ± 0,002 ADAGRAD & Momentum Maximum: 0,134 0,132 0,132 Minimum: 0,117 0,116 0,116 Konfidenzintervall: 0,124 ± 0,001 0,122 ± 0,0008 0,122 ± 0,0008 Tabelle B.9: Mini Batch (100) Lernverfahren: Fehlerwert nach 50 Iterationen.
- 97. Anhang C Fehlerrechnung Bei derAufnahme von mehreren Messwerten für den gleichen Vorgang, lassen sich oftmals Abweichungen aufgrund zufälliger Fehler feststellen. Bei der Performancemessung von Java- Programmen können Abweichungen z.B. durch den Just-in-Time Compiler oder den Garbage Collector ausgelöst werden. Damit nun einzelne Ausreißer nicht die Messwerte verfälschen, muss eine Fehlerrechnung durchgeführt werden. Als Quelle für die folgenden Ausführungen diente [Wikc]. Für N Messwerte erlaubt das arithmetische Mittel eine bessere Aussage als Einzelwerte (vj). Es gilt folgende Gleichung für das arithmetische Mittel ¯v: ¯v = 1 N N j=1 vj. (C.1) Die empirische Standardabweichung s ist, in Kombination mit der Unsicherheit u, ein Maß für die Streuung der Messwerte. Die empirische Standardabweichung wird folgendermaßen berech- net: s = 1 N − 1 N j=1 vj − ¯v 2 . (C.2) Für die der Berechnung der Unsicherheit, gilt: u = 1 √ N · s. (C.3) Für alle im Rahmen dieser Arbeit vorgenommenen Messungen, gilt N >= 40, ein Konfi- denzniveau von 95% und damit der Konfidenzintervall: ¯v − 2 · u · · · ¯v + 2 · u.
- 99. Anhang D Metriken Die MetrikenPrecision/Recall und f-measure werden oft in der statistischen Sprachverarbeitung verwendet (NLP) und dienen im Rahmen dieser Arbeit als Qualitätsmaß für Klassifikatoren. Als Quelle wurde hier [MS99] benutzt (Seiten 267-271). Der Speedup wird zur Bewertung der Skalierbarkeit eines verteilten Systems benutzt (Quel- len: [Wikd], [Wika]). D.1 Precision/Recall Zur Berechnung von Precision und Recall müssen als erstes die Anteile von „true negative“ (TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) an der Gesamtmenge gemessen werden. Im Rahmen der Klassifizierung eines Zwei-Klassen-Problems gilt folgende Matrix: Deklariere als Klasse I Deklariere als Klasse II Ist Klasse I TP FN Ist Klasse II FP TN Tabelle D.1: Confusion Matrix Die Precision wird folgendermaßen ermittelt: Precision = tp tp + fp . (D.1) Die Precision wird also berechnet, indem die Anzahl der korrekt gelabelten Daten durch die Gesamtzahl, der als zu dieser Klasse gehörigen Daten, geteilt wird. Ein Wert von 1.0 gibt an, dass alle als zu dieser Klassen gehörig gelabelten Daten auch tatsächlich zu dieser Klasse gehören. Er sagt aber nichts darüber aus, wie viele Daten, die auch zu dieser Klasse gehören, nicht korrekt gelabelt wurden.
- 100. ANHANG D. METRIKEN92 Der Recall wird folgendermaßen ermittelt: Recall = tp tp + fn (D.2) Der Recall wird also berechnet, indem die Anzahl der korrekt als Klasse I gelabelten Daten durch die Gesamtzahl an Daten, die insgesamt zur Klasse I gehören, geteilt wird. Ein Wert von 1.0 bedeutet hier, dass alle zur Klasse I gehörigen Daten auch als zu Klasse I gehörig gelabelt wurden. Dieser Wert kann allerdings auch bedeuten, dass alle Werte als zu Klasse I gelabelt wurden D.2 F-measure Der F-measure kombiniert Precision und Recall zu einem Maß, wodurch besser die Gesamt- performance ermittelt werden kann. Es werden im Rahmen dieser Arbeit Precision und Recall gleich gewichtet (auch F1 score genannt), so dass sich folgende Gleichung ergibt: F1 = 2 · precision · recall precision + recall (D.3) D.3 Speedup Der Speedup ist folgendermaßen definiert: Sp = T1 Tp (D.4) Dabei gilt, dass p gleich der Anzahl an Prozessoren ist, T1 die Ausführungszeit des sequentiel- len Algorithmus und Tp die Ausführungszeit des parallelen Algorithmus mit p Prozessoren ist. Der Speedup ist ein Maß dafür, wie stark ein Algorithmus durch die Parallelisierung beschleu- nigt wurde. Wenn die Ausführungszeit halbiert wird, durch die Verdoppelung der Anzahl an Prozessoren, dann spricht man von einem linearen Speedup. Ein weiteres Maß ist die Effizienz, die folgendermaßen definiert ist: Ep = Sp p (D.5) Die Effizienz gibt an, wie viel Aufwand mit Kommunikation und Synchronisation verschwendet wird. Es gilt Ep = 1, wenn ein linearer Speedup erreicht wurde. Laut dem Amdahlschen Gesetz ist die Parallelisierbarkeit eines Algorithmus durch seinen sequentiellen Anteil begrenzt. Nach dem Amdahlschen Gesetz gilt, mit B ∈ [0, 1] gleich dem sequentiellen Anteil, folgende Gleichung: Tp = T1 B + 1 p 1 − B (D.6)
- 101. Anhang E Normalisierung von Trainingsdaten Jenach Anwendungsfall müssen die Daten aufbereitet werden, indem sie normalisiert werden. Die Daten werden dabei in einen neuen Wertebereich überführt, der vom Wertebereich der Aktivierungsfunktion abhängt. Im Rahmen dieser Arbeit traf dies auf das MONK Problem zu, da die Features in unterschiedlichen Wertebereichen lagen. Auf eine Denormalisierung konnte verzichtet werden, da es sich um ein Klassifizierungsproblem handelt, die Ausgabe also entweder eins oder null ist. Die Werte des neuen Wertebereichs liegen beim MONK Problem zwischen -1 und 1. Zur Normalisierung werden zuerst Maxima und Minima über alle Eingabedaten berechnet und ge- speichert. Die Berechnung erfolgt für jedes Feature getrennt. Die Normalisierung erfolgt mittels folgender Gleichung: EingabeNorm = (Eingabe−Minima)(1−(−1) Maxima−Minima − 1 Um die Bestimmung von Minima und Maxima zu beschleunigen, werden mehrere Threads benutzt. Die Anzahl der Threads entspricht dabei der Anzahl der verfügbaren Prozessoren. Die Implementierung erfolgte mit Hilfe von Thread-Pools und dem ExecutorCompletionService. Die Eingabe besteht jeweils aus einem Array, das die zu untersuchenden Daten enthält. Dieses Array wird in gleich große Bereiche unterteilt und jeweils von einem Thread bearbeitet. Falls das Array nicht in gleich große Bereiche aufgeteilt werden kann, dann übernimmt ein Thread zusätzlich den Rest. Zum Schluss werden die Ergebnisse der einzelnen Threads zusam- mengeführt und das endgültige Ergebnis berechnet. Durch die Verwendung mehrerer Threads konnte dieser Vorgang zumindest messbar beschleunigt werden, auch wenn zugegebenermaßen dieser Teil gemessen an der teils sehr langen Trainingszeit nur sehr gering ausfällt.
- 103. Anhang F Verteiltes Trainingmit BSP in Pseudocode Im ersten Schritt werden das MLP initialisiert, das Modell sowie global gültige Einstellungen auf alle BSP-Peers kopiert und ein Master-Peer gewählt (Zeile 1). Die nächsten Schritte werden so lange ausgeführt, bis entweder die Fehlerfunktion konvergiert1 , eine bestimmte Anzahl an Iterationen oder ein bestimmter Fehlerwert erreicht wurde (Zeilen 2 - 30). 1 global: model, parameter, masterPeer, iterationCounter <- 0; 2 while(true) { 3 ResetFilePointer(); 4 iterationCounter <- iterationCounter +1; 5 while(processedData<= dataSize) { 6 for(batchProcessed<= batchSize) { 7 gradientSum <- gradientSum+ CalculateGradient(); 8 } 9 CalculatePartialAverageGradient(); 10 SendAverageGradientToMaster(); 11 SynchronizePeers(); 12 if(masterPeer) { 13 UpdateModel(); 14 SendModelToAllPeers(); 15 } 16 SynchronizePeers(); 17 UpdateModel(); 1Ein lokales Minnimum wurde erreicht, erkennbar daran, dass die Änderungsrate des Fehlerwerts, über alle Trainingsdaten, unter einem gewissen Schwellwert liegt.
- 104. ANHANG F. VERTEILTESTRAINING MIT BSP IN PSEUDOCODE 96 18 } 19 CalculateError(); 20 if(StopTraining()) { break; } 21 } Listing F.1: Allgemeine Vorgehensweise in Pseudocode Zu Beginn einer Iteration wird der Dateizeiger wieder auf den Anfang gesetzt (Zeile 3). Dann wird der Iterationszähler hochgezählt (Zeile 4), da er ein Abbruchkriterium ist. Die nächsten Schritte für BGD einmal und für MBGD mehrmals ausgeführt (Zeilen 5-20). Als erstes werden die Gradienten für die lokal vorliegenden Daten berechnet und aufsummiert (Zeilen 9-11). Dann wird die Teilsumme durch die Batchgröße geteilt (Zeile 12) und an einen Master-Peer gesendet (Zeile 13). Der Master-Peer berechnet den durchschnittlichen Gradienten und das Gewichtsupdate (Zei- le 16). Das neue Modell wird dann an alle BSP-Peers gesendet. Wurde ein Abbruchkriterium erfüllt, dann wird das Training beendet ansonsten beginnt die nächste Iteration. Das Abbruch- kriterium wird in Zeile 20 geprüft, dabei gilt es zu beachten, dass je nach Abbruchkriterium die Prüfung nur durch den Master-Peer erfolgen kann. In dem Fall muss der Master-Peer eine Nachricht an alle BSP-Peers schicken, um das Training anzuhalten. Das Gewichtsupdate erfolgt wie beschrieben nur auf dem Master-Peer. Für Momentum, iRprop+ und ADAGRAD, bedeutet dies, dass die jeweils benötigten Daten auch nur auf dem Master-Peer im Arbeitsspeicher gehalten werden. Das ist z.B. im Falle von Momentum, eine Matrix mit der letzten Gewichtsänderung. Auf allen BSP-Peers muss das Modell, also die Ge- wichtsverbindungen der Neuronen, im Arbeitsspeicher gehalten werden. Die Anforderungen an den Arbeitsspeicher sind also, bis auf den Master-Peer, bei allen BSP-Peers gleich groß und hängen von der Anzahl an Gewichtsverbindungen ab.
- 105. Anhang G Abkürzungsverzeichnis BGD BatchGradient Descent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 BSP bulk-synchronous parallel model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 EP Exemplar Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 HDFS Hadoop Distributed Filesystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 iRprop+ Improved Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 MBGD Mini Batch Gradient Descent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 MLP Multilayer Perceptron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 MPI Message Passing Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Rprop Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 SGD Stochastic Gradient Descent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
- 107. Anhang H Abbildungsverzeichnis 2.1 Neuronenmodell1 .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Multilayer Perceptron mit einem hidden layer2 . . . . . . . . . . . . . . . . . . . 7 2.3 Gradientenabstieg auf zweidimensionaler Fehlerfunktion3 . . . . . . . . . . . . . . 10 2.4 Mögliche Probleme beim Gradientenabstieg4 . . . . . . . . . . . . . . . . . . . . 12 2.5 bulk-synchronous parallel modell5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.6 Architektur von Apache Hama6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Verteilung eines neuronalen Netzwerks, am Beispiel lokal verbundener Neuronen.7 22 3.2 Links: Downpour SGD. Rechts: Sandblaster L-BFGS8 . . . . . . . . . . . . . . . 22 4.1 Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Schematische Darstellung des Vorgehens innerhalb einer Iteration. . . . . . . . . 32 4.3 Binary Tree Kommunikation in drei Phasen am Beispiel von acht Rechnern9 . . . 35 5.1 Parser-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2 Trainingsdaten-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 54 6.2 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 55 6.3 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge- samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.4 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 57 6.5 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge- samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.6 horizontale Skalierung mit 3.840 Trainingsdaten . . . . . . . . . . . . . . . . . . . 58 6.7 Speedup für 3.840 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.8 horizontale Skalierung mit 38.400 Trainingsdaten . . . . . . . . . . . . . . . . . . 59 6.9 Speedup für 38.400 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . 59
- 108. ABBILDUNGSVERZEICHNIS 100 6.10 Cache:Gegenüberstellung von Speedup und Ladezeit . . . . . . . . . . . . . . . . 60 6.11 Kommunikation: Gegenüberstellung von Speedup und Iterationsdauer . . . . . . 61 6.12 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge- samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.13 MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand der Anzahl an Iterationen bis zum Fehlerwert 0,1, mit logarithmischer Skalierung. . . 65 6.14 Xing (20): Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des Fehlerwerts nach 50 Iterationen, mit logarithmischer Skalierung. . . . . . . . . . 66 6.15 MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des Fehlerwerts nach 50 Iterationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.16 Xing (20): Fehlerkurve über 50 Iterationen in Abhängigkeit zum Lernverfahren, exemplarisch für den Seed-Wert eins. . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.17 Training des MLP mit der Identität ohne verrauschten Eingabevektor. . . . . . . 71 6.18 Analyse von Ausgabe- bzw. versteckter Schicht in Abhängigkeit der gesuchten Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.1 Klassen zur Verteilung von Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 79 A.2 Klassen zur Realisierung der Nachrichten . . . . . . . . . . . . . . . . . . . . . . 80 A.3 Darstellung der wichtigsten Methoden und Klassen des verwendeten MLP- Frameworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 A.4 Darstellung der verwendeten Vektorklassen inkl. deren wichtigsten Methoden. . . 81 A.5 Darstellung der BSP-Jobklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
- 109. Anhang I Sourcecodeverzeichnis 2.1 iRprop+in Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Methodensignatur von BSP.bsp() . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3 Beispiel der Kommunikation zwischen BSP-Peers . . . . . . . . . . . . . . . . . . 20 4.1 Sparse Autoencoder mit BSP in Pseudocode . . . . . . . . . . . . . . . . . . . . . 37 5.1 Initialisierung der Verbindungsgewichte mit dem Verfahren von Glorot-Bengio . . 41 5.2 Initialisierung der Verbindungsgewichte mit dem Verfahren von Nguyen-Widrow 42 5.3 Factory-Klasse zur Erzeugung von Matrix von Matrix- und Vektor-Factories . . . 43 6.1 Ermittlung der benutzten Methoden und deren Laufzeit mit Aspectj . . . . . . . 62 F.1 Allgemeine Vorgehensweise in Pseudocode . . . . . . . . . . . . . . . . . . . . . . 95
- 111. Anhang J Tabellenverzeichnis 6.1 Hardware-/Softwareausstattungder Hostrechner . . . . . . . . . . . . . . . . . . 49 6.2 Softwareausstattung der virtuellen Maschine . . . . . . . . . . . . . . . . . . . . . 50 6.3 XOR-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.4 XOR: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert . . . . . 51 6.5 MONK: Auflistung aller Attribute und ihrer Ausprägungen. Der Wert in den Klammern gibt an, welche Zahl dieses Attribut im Eingabevektor repräsentiert. . 52 6.6 Monk: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert . . . . . 53 6.7 Zeitmessung der Gradientenberechnung für ein Trainingsbeispiel in ms . . . . . . 61 6.8 Linux: Zeitmessung verschiedener Rechenoperationen in ms für eine 1000x1000 Matrix und einen Vektor mit 1000 Zeilen. . . . . . . . . . . . . . . . . . . . . . . 63 B.1 BGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . . . 83 B.2 iRprop+: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . 84 B.3 SGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . . . 84 B.4 BGD: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . 85 B.5 iRprop+: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . 85 B.6 SGD: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . 86 B.7 Batch Lernverfahren: Fehlerwert nach 50 Iterationen. . . . . . . . . . . . . . . . . 87 B.8 iRprop+: Fehlerwert nach 50 Iterationen. . . . . . . . . . . . . . . . . . . . . . . 87 B.9 Mini Batch (100) Lernverfahren: Fehlerwert nach 50 Iterationen. . . . . . . . . . 88 D.1 Confusion Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
- 113. Anhang K Literaturverzeichnis [Abe] Abeles,Peter: Java Matrix Benchmark. http://code.google.com/p/ java-matrix-benchmark/, Abruf: 2014.02.09 [And] Andrew Ng: Sparse autoencoder. http://www.stanford.edu/class/cs294a/ sparseAutoencoder_2011new.pdf, Abruf: 2014.02.09 [Apa] Apache Software Foundation: Apache Mahout. http://mahout.apache.org/, Abruf: 2014.02.09 [BL13] Bache, K. ; Lichman, M.: UCI Machine Learning Repository. http://archive.ics. uci.edu/ml. Version: 2013 [Bot98] Bottou, Léon: Online Algorithms and Stochastic Approximations. Version: 1998. http://leon.bottou.org/papers/bottou-98x. In: Saad, David (Hrsg.): Online Learning and Neural Networks. Cambridge, UK : Cambridge University Press, 1998. – revised, oct 2012 [Bra] Braun, Mikio: jblas: linear algebra for java. http://mikiobraun.github.io/jblas/, Abruf: 2014.02.09 [BRF04] Biersack, Ernst W ; Rodriguez, Pablo ; Felber, Pascal A: Performance ana- lysis of peer-to-peer networks for file distribution. In: QOFIS 2004, 5th Interna- tional Workshop on Quality of Future Internet Services, September 29-October 1, 2004, Barcelona, Spain / Also published in "LNCS", Volume 3266/2004. Barcelona, SPAIN, 09 2004 [CH13] Cenk, Murat ; Hasan, M. A.: On the Arithmetic Complexity of Strassen-Like Matrix Multiplications. Cryptology ePrint Archive, Report 2013/107, 2013. – http: //eprint.iacr.org/ [Chr96] Christopher M. Bishop: Neural Networks - for Pattern Recognition. Clarendon Press, Oxford, 1996
- 114. ANHANG K. LITERATURVERZEICHNIS106 [CHW+ 13] Coates, Adam ; Huval, Brody ; Wang, Tao ; Wu, David J. ; Catanzaro, Bry- an C. ; Ng, Andrew Y.: Deep learning with COTS HPC systems. In: ICML (3) Bd. 28, JMLR.org, 2013 (JMLR Proceedings), 1337-1345 [CL11] Chang, Chih-Chung ; Lin, Chih-Jen: LIBSVM: A library for support vector ma- chines. In: ACM Transactions on Intelligent Systems and Technology 2 (2011), S. 27:1–27:27. – Software available at http://www.csie.ntu.edu.tw/~cjlin/libsvm [CTM09] Cabreira, A. G. ; Tripode, M. ; Madirolas, A.: Artificial neural networks for fish-species identification. In: Ices Journal of Marine Science 66 (2009), S. 1119– 1129. http://dx.doi.org/10.1093/icesjms/fsp009. – DOI 10.1093/icesjms/fsp009 [DCM+ 12] Dean, Jeffrey ; Corrado, Greg S. ; Monga, Rajat ; Chen, Kai ; Devin, Matthieu ; Le, Quoc V. ; Mao, Mark Z. ; Ranzato, Marc’Aurelio ; Senior, Andrew ; Tu- cker, Paul ; Yang, Ke ; Ng, Andrew Y.: Large Scale Distributed Deep Networks. In: NIPS, 2012 [det] details, See homepage f.: ATLAS homepage. http://math-atlas.sourceforge.net/, Abruf: 2014.02.09 [DG08] Dean, Jeffrey ; Ghemawat, Sanjay: MapReduce: Simplified Data Processing on Large Clusters. In: Commun. ACM 51 (2008), Januar, Nr. 1, 107–113. http: //dx.doi.org/10.1145/1327452.1327492. – DOI 10.1145/1327452.1327492. – ISSN 0001–0782 [DHS11] Duchi, John ; Hazan, Elad ; Singer, Yoram: Adaptive Subgradient Methods for Online Learning and Stochastic Optimization. In: J. Mach. Learn. Res. 12 (2011), Juli, 2121–2159. http://dl.acm.org/citation.cfm?id=1953048.2021068. – ISSN 1532–4435 [eso] esoteric software: Kryo. https://github.com/EsotericSoftware/kryo, Abruf: 2014.02.09 [Fou] Foundation, Eclipse: aspectj. http://eclipse.org/aspectj/, Abruf: 2014.02.09 [GB10] Glorot, Xavier ; Bengio, Yoshua: Understanding the difficulty of training deep feedforward neural networks. In: In Proceedings of the International Conference on Artificial Intelligence and Statistics (AISTATS’10). Society for Artificial Intel- ligence and Statistics, 2010 [GGKK07] Grama, A. ; Gupta, A. ; Karypis, G. ; Kumar, V.: Introduction to Parallel Computing, Second Edition. 2007. – erhältlich auf http://www.dkriesel.com [GKWZ07] Gorban, Alexander N. ; Kgl, Balzs ; Wunsch, Donald C. ; Zinovyev, Andrei: Principal Manifolds for Data Visualization and Dimension Reduction. 1st. Springer Publishing Company, Incorporated, 2007. – ISBN 3540737499, 9783540737490
- 115. ANHANG K. LITERATURVERZEICHNIS107 [GLS94] Gropp, William ; Lusk, Ewing ; Skjellum, Anthony: Using MPI: Portable Par- allel Programming with the Message-Passing Interface. MIT Press, 1994 [Goo] Google: Guice. http://code.google.com/p/google-guice/, Abruf: 2014.02.09 [Hin07] Hinton, Geoffrey E.: Learning multiple layers of representation. In: Trends in Cognitive Sciences 11 (2007), S. 428–434 [Hoc98] Hochreiter, Sepp: The Vanishing Gradient Problem During Learning Re- current Neural Nets and Problem Solutions. In: Int. J. Uncertain. Fuzziness Knowl.-Based Syst. 6 (1998), April, Nr. 2, 107–116. http://dx.doi.org/10.1142/ S0218488598000094. – DOI 10.1142/S0218488598000094. – ISSN 0218–4885 [HS06a] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data with neural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi. org/10.1126/science.1127647. – DOI 10.1126/science.1127647 [HS06b] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data with neural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi. org/10.1126/science.1127647. – DOI 10.1126/science.1127647 [IH00] Igel, Christian ; Hüsken, Michael: Improving the Rprop Learning Algorithm. In: Proceedings of the Second International ICSC Symposium on Neural Computation (NC 2000), ICSC Academic Press, 2000, S. 115–121 [Kri94] Kriesel, David: Ein kleiner Überblick über Neuronale Netze. 1994 [LBOM98] LeCun, Yann ; Bottou, Leon ; Orr, Genevieve ; Müller, Klaus: Efficient Back- Prop. Version: 1998. http://dx.doi.org/10.1007/3-540-49430-8_2. In: Neural Networks: Tricks of the Trade. Springer Berlin / Heidelberg, 1998 (Lecture Notes in Computer Science). – DOI 10.1007/3–540–49430–8_2. – ISBN 978–3–540–65311–0, Kapitel 2, 546 [LRM+ 12] Le, Quoc ; Ranzato, Marc’Aurelio ; Monga, Rajat ; Devin, Matthieu ; Chen, Kai ; Corrado, Greg ; Dean, Jeff ; Ng, Andrew: Building high-level features using large scale unsupervised learning. In: International Conference in Machine Learning, 2012 [MRS08] Manning, Christopher D. ; Raghavan, Prabhakar ; Schütze, Hinrich: Introduc- tion to Information Retrieval. New York, NY, USA : Cambridge University Press, 2008. – ISBN 0521865719, 9780521865715 [MS99] Manning, C. ; Schütze, H.: Foundations of statistical natural language processing. 1999
- 116. ANHANG K. LITERATURVERZEICHNIS108 [NW90] Nguyen, D. ; Widrow, B.: Improving the learning speed of 2-layer neural networks by choosing initial values of the adaptive weights. (1990), Juni, 21–26 vol.3. http: //dx.doi.org/10.1109/IJCNN.1990.137819. – DOI 10.1109/IJCNN.1990.137819 [Ora] Oracle: Hudson. http://hudson-ci.org/, Abruf: 2014.02.09 [RB92] Riedmiller, Martin ; Braun, Heinrich: RPROP - A Fast Adaptive Learning Algorithm / Proc. of ISCIS VII), Universitat. 1992. – Forschungsbericht [RHW88] Rumelhart, D. E. ; Hinton, G. E. ; Williams, R. J.: Neurocomputing: foundati- ons of research. Version: 1988. http://dl.acm.org/citation.cfm?id=65669.104449. Cambridge, MA, USA : MIT Press, 1988. – ISBN 0–262–01097–6, Kapitel Learning internal representations by error propagation, 673–695 [RS98] Rogers, R. O. ; Skillicorn, D. B.: Using the BSP cost model to optimise parallel neural network training. In: Future Generation Comp. Syst. 14 (1998), Nr. 5-6, 409- 424. http://dblp.uni-trier.de/db/journals/fgcs/fgcs14.html#RogersS98 [Sim05] Simon Haykin: Neural Networks - A Comprehensive Foundation. Pearson, Pren- tice Hall, 2005 [SYK+ 10] Seo, Sangwon ; Yoon, Edward J. ; Kim, Jaehong ; Jin, Seongwook ; Kim, Jin- Soo ; Maeng, Seungryoul: HAMA: An Efficient Matrix Computation with the MapReduce Framework. In: Proceedings of the 2010 IEEE Second International Conference on Cloud Computing Technology and Science. Washington, DC, USA : IEEE Computer Society, 2010 (CLOUDCOM ’10). – ISBN 978–0–7695–4302–4, 721–726 [TBB+ 91] Thrun, Sebastian ; Bala, J. ; Bloedorn, E. ; Bratko, I. ; Cestnik, B. ; Cheng, J. ; Jong, K. D. ; Dzeroski, S. ; Hamann, R. ; Kaufman, K. ; Keller, S. ; Ko- nonenko, I. ; Kreuziger, J. ; Michalski, R.S. ; Mitchell, Tom ; Pachowicz, P. ; Roger, B. ; Vafaie, H. ; Velde, W. V. ; Wenzel, W. ; Wnek, J. ; Zhang, J.: The MONK’s Problems: A Performance Comparison of Different Learning Algo- rithms / Computer Science Department. Pittsburgh, PA, 1991 (CMU-CS-91-197). – Forschungsbericht [TCCDL] Tennessee, Univ. of ; California, Berkeley Univ. o. ; Colorado Denver, Univ. of ; Ltd., NAG: LAPACK/BLAS homepage. http://www.netlib.org/lapack/, Abruf: 2014.02.09 [TKMS03] Toutanova, Kristina ; Klein, Dan ; Manning, Christopher D. ; Singer, Yoram: Feature-Rich Part-of-Speech Tagging with a Cyclic Dependency Network. In: IN PROCEEDINGS OF HLT-NAACL, 2003, S. 252–259
- 117. ANHANG K. LITERATURVERZEICHNIS109 [VLBM08] Vincent, Pascal ; Larochelle, Hugo ; Bengio, Yoshua ; Manzagol, Pierre- Antoine: Extracting and Composing Robust Features with Denoising Autoencoders. In: Proceedings of the 25th International Conference on Machine Learning. New York, NY, USA : ACM, 2008 (ICML ’08). – ISBN 978–1–60558–205–4, 1096–1103 [Whi11] White, Tom: Hadoop: The Definitive Guide (2nd Edition). O’Reilly, 2011 [Wika] Wikipedia: Amdahl’s law. http://en.wikipedia.org/wiki/Amdahl%27s_law, Ab- ruf: 2014.02.09 [Wikb] Wikipedia: Boolesche Funktion. http://de.wikipedia.org/wiki/Boolesche_ Funktion, Abruf: 2014.02.09 [Wikc] Wikipedia: Fehlerrechnung. http://de.wikipedia.org/wiki/Fehlerrechnung, Ab- ruf: 2014.02.09 [Wikd] Wikipedia: Speedup. http://en.wikipedia.org/wiki/Speedup, Abruf: 2014.02.09 [Xin] Xing AG: Xing. http://www.xing.com/, Abruf: 2014.02.09 [Zei12] Zeiler, Matthew D.: ADADELTA: An Adaptive Learning Rate Method. In: CoRR abs/1212.5701 (2012)
- 119. Anhang L Eigenständigkeitserklärung Hiermit versichereich, dass ich die vorliegende Masterarbeit Large Scale Multilayer Perceptron selbstständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt. Berlin, 10. Februar 2014