LARGE SCALE MULTILAYER PERCEPTRON
Abschlussarbeit
zur Erlangung des akademischen Grades
Master of Science (M.Sc.)
an der
H...
iii
Kurzbeschreibung:
In dieser Arbeit wurde ein Software-Framework entwickelt, auf der Basis von Apache
Hama, einer Imple...
Inhaltsverzeichnis
Inhaltsverzeichnis v
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . ...
INHALTSVERZEICHNIS vi
3.3.2 Nicht-Funktionale-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Abgrenz...
INHALTSVERZEICHNIS vii
6.4.3 Vergleich von Apache Mahout und jblas . . . . . . . . . . . . . . . . . . . 61
6.5 Untersuchu...
Kapitel 1
Einleitung
1.1 Motivation
Das Multilayer Perceptron (MLP) ist ein künstliches neuronales Netz und wird bereits s...
KAPITEL 1. EINLEITUNG 2
Reduce1
Implementierung von Apache Hadoop (siehe [Whi11], Seiten 129ff), die Möglichkeit
an Daten ü...
KAPITEL 1. EINLEITUNG 3
In Kapitel 3 (siehe Seite 21ff) werden zwei Studien analysiert, die ebenfalls das verteilte
Trainin...
Kapitel 2
Grundlagen
Im ersten Teil dieses Kapitels, werden künstliche neuronale Netze im Allgemeinen und meh-
rere im Rah...
KAPITEL 2. GRUNDLAGEN 6
Man unterscheidet hier zwischen überwachtem („supervised“), unüberwachtem („unsuper-
vised“) und b...
KAPITEL 2. GRUNDLAGEN 7
Die gewichteten Eingaben werden summiert (z1 =
m
j=1
xjW1j + b1). und bilden die Eingabe
für die A...
KAPITEL 2. GRUNDLAGEN 8
net wird. Die Ausgabe eines Neurons wird durch a
(l)
i dargestellt. Die Ausgabe des dargestellten
...
KAPITEL 2. GRUNDLAGEN 9
Nguyen & Widrow sowie Glorot & Bengio berechnen die Gewichtswerte unter Berücksich-
tigung der Neu...
KAPITEL 2. GRUNDLAGEN 10
Abbildung 2.3: Gradientenabstieg auf zweidimensionaler Fehlerfunktion3
Bei gradientenbasierten Ve...
KAPITEL 2. GRUNDLAGEN 11
200 Trainingsbeispiele gebildet und das Modell verändert. Das wird so lange wiederholt, bis das
M...
KAPITEL 2. GRUNDLAGEN 12
2.1.4 Momentum
Abbildung 2.4: Mögliche Probleme beim Gradientenabstieg4
Die in Abschnitt 2.1.2 er...
KAPITEL 2. GRUNDLAGEN 13
2.1.5 ADAGRAD
Wie im Abschnitt 2.1.2 erwähnt, ist die Lernrate in der vorliegenden Implementierun...
KAPITEL 2. GRUNDLAGEN 14
Die Schrittweite ij(t) mit Wij(t+1) = Wij(t)+ ij(t) wird für Rprop und davon abgeleitete
Verfahre...
KAPITEL 2. GRUNDLAGEN 15
2.1.7 Autoencoder
Der Autoencoder Algorithmus wurde von Hinton et al. zum Trainieren von neuronal...
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 ...
KAPITEL 2. GRUNDLAGEN 17
Barrier
Synchronisation
Local
Computation
Communication
Processors
Abbildung 2.5: bulk-synchronou...
KAPITEL 2. GRUNDLAGEN 18
2.2.2 Apache Hama
Architektur
Abbildung 2.6: Architektur von Apache Hama8
In Abbildung 2.6 wird d...
KAPITEL 2. GRUNDLAGEN 19
1 public abstract void bsp(BSPPeer<K1, V1, K2, V2, Mextends Writable> peer) throws ...;
Listing 2...
KAPITEL 2. GRUNDLAGEN 20
Im Listing 2.3 wird die Kommunikation zwischen BSP-Peers an einem kleinem Beispiel
gezeigt. Der B...
Kapitel 3
Anforderungsanalyse
In diesem Kapitel werden zu Beginn zwei Studien vorgestellt, welche unterschiedliche Ansätze...
KAPITEL 3. ANFORDERUNGSANALYSE 22
3.1.2 Studie 2: Large Scale Distributed Deep Networks
Dean et al. beschreiben in ihrer A...
KAPITEL 3. ANFORDERUNGSANALYSE 23
Dean et al. beschreiben unterschiedliche Vorgehensweisen für SGD- und BGD-Verfahren, die...
KAPITEL 3. ANFORDERUNGSANALYSE 24
3.2 Analyse des MLP Frameworks
An dieser Stelle soll das verwendete MLP Framework näher ...
KAPITEL 3. ANFORDERUNGSANALYSE 25
3.3 Zielstellung
In dem folgenden Kapitel wird die Zielstellung detailliert formuliert. ...
KAPITEL 3. ANFORDERUNGSANALYSE 26
Evaluierung der Ergebnisse
• Datenformat:
Beschreibung: Es soll die Möglichkeit geben, e...
KAPITEL 3. ANFORDERUNGSANALYSE 27
• Mini-Batch Gradient Descent:
Beschreibung: Es soll die Möglichkeit geben, Mini-Batch L...
Kapitel 4
Entwurf
In diesem Kapitel wird die Anwendung entworfen. Es werden das System und einzelne System-
komponenten be...
KAPITEL 4. ENTWURF 30
Im Rahmen dieser Arbeit soll eine Anwendung zum verteilten Trainieren eines MLP erstellt
werden. Die...
KAPITEL 4. ENTWURF 31
um die Trainingsdaten leicht mit anderen Frameworks austauschen zu können. Das zugrunde-
liegende Da...
KAPITEL 4. ENTWURF 32
Par$$on	
  I	
   Par$$on	
  III	
  Par$$on	
  II	
  
Par$al	
  Gradient	
  Sum	
   Par$al	
  Gradien...
KAPITEL 4. ENTWURF 33
Für diese Arbeit wird die erste Variante implementiert. Von jedem BSP-Peer wird der jeweils
zugewies...
KAPITEL 4. ENTWURF 34
zentren optimiert werden. Darauf muss allerdings im Rahmen dieser Arbeit aus Zeitgründen
verzichtet ...
KAPITEL 4. ENTWURF 35
onsstrategie wird nicht zwischen lokalem und entfernten BSP-Peer unterschieden. Die Kom-
munikation ...
KAPITEL 4. ENTWURF 36
Binary Tree ist optimal, wenn die Rechneranzahl eine Potenz von zwei ist. Der worst case
ist gegeben...
KAPITEL 4. ENTWURF 37
Anhang C, Seite 89), um die Verteilung der Ergebnisse zu bestimmen. Je näher die Ergebnisse
des Test...
KAPITEL 4. ENTWURF 38
Jeder BSP-Peer berechnet die Teilsumme der durchschnittlichen Aktivierung aller Neuronen
und sendet ...
Kapitel 5
Implementierung
Dieses Kapitel beschreibt im Detail, die Implementierung der im Entwurf vorgestellten System-
ko...
KAPITEL 5. IMPLEMENTIERUNG 40
IParser <<interface>>
+parse(String input): List<MLDataEntry>
XingParser MonkParser
Abbildun...
KAPITEL 5. IMPLEMENTIERUNG 41
5.2 MLP-Framework
Das MLP-Framework enthält eine Reihe von Klassen, wie z.B. Kostenfunktion,...
KAPITEL 5. IMPLEMENTIERUNG 42
vier wird für jedes Gewicht eine Zufallszahl ermittelt und in den vorher bestimmten Wertbere...
KAPITEL 5. IMPLEMENTIERUNG 43
Die Klassen de.mlp_distributed.mlp.math.jblas.JDenseVector und de.mlp_distributed.mlp.
math....
KAPITEL 5. IMPLEMENTIERUNG 44
sor wird nun auf eins festgelegt, wenn er kleiner als 10−8
ist. Ansonsten kam es bei kleinen...
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Nächste SlideShare
Wird geladen in …5
×

Large Scale Multilayer Perceptron

437 Aufrufe

Veröffentlicht am

In dieser Arbeit wurde ein Software-Framework entwickelt, auf der Basis von Apache Hama, einer Implementierung des bulk-synchronous parallel model (BSP). Das Framework bietet die Möglichkeit, ein künstliches neuronales Netz in einem Rechner-Cluster verteilt zu trainieren. Es bietet weiterhin die Möglichkeit, sowohl auf Mini- als auch auf Big-Batch basierende Trainingsalgorithmen zu benutzen. Skalierbarkeit und Performance wurden unter anderem anhand des Trainings eines Denoising Autoencoders mit 1.000 Eingabe- und Ausgabeneuronen 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 algorithms 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 been determined by the training of an denoising autoencoder with 1,000 input and output neurons.

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
437
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Large Scale Multilayer Perceptron

  1. 1. LARGE SCALE MULTILAYER PERCEPTRON Abschlussarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) an der Hochschule für Technik und Wirtschaft Berlin Fachbereich Wirtschaftswissenschaften II Studiengang Angewandte Informatik 1. Prüfer: Prof. Dr. Christian Herta 2. Prüfer: Prof. Dr. Hermann Hessling Eingereicht von Sascha Jonas (B.Sc.) 10. Februar 2014 © Copyright 2013 Sascha Jonas (B.Sc.). Alle Rechte vorbehalten.
  2. 2. iii Kurzbeschreibung: In dieser Arbeit wurde ein Software-Framework entwickelt, auf der Basis von Apache Hama, einer Implementierung des bulk-synchronous parallel model (BSP). Das Framework bietet die Möglichkeit, ein künstliches neuronales Netz in einem Rechner-Cluster verteilt zu trainieren. Es bietet weiterhin die Möglichkeit, sowohl auf Mini- als auch auf Big-Batch basierende Trainingsalgorithmen zu benutzen. Skalierbarkeit und Performance wurden unter anderem anhand des Trainings eines Denoising Autoencoders mit 1.000 Eingabe- und Ausga- beneuronen ermittelt. Abstract: In this study the ability of bulk-synchronous parallel model (BSP) for scaling out the training of an 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
  3. 3. Inhaltsverzeichnis Inhaltsverzeichnis v 1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Grundlagen 5 2.1 Künstliche neuronale Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Initialisierung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . 8 2.1.2 Gradientenbasierte Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3 Backpropagation of Error . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.4 Momentum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.5 ADAGRAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.6 Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.7 Autoencoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Bulk-Synchronous Parallel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.2 Apache Hama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 Anforderungsanalyse 21 3.1 Verwandte Studien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 Studie 1: Using the BSP Cost Model to Optimize Parallel Neural Network Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2 Studie 2: Large Scale Distributed Deep Networks . . . . . . . . . . . . . . 22 3.2 Analyse des MLP Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.1 Speicherung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . . 24 3.2.2 Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.3 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 25
  4. 4. 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
  5. 5. INHALTSVERZEICHNIS vii 6.4.3 Vergleich von Apache Mahout und jblas . . . . . . . . . . . . . . . . . . . 61 6.5 Untersuchung des Arbeitsspeicherverbrauchs . . . . . . . . . . . . . . . . . . . . . 63 6.6 Performancetests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.6.1 Messung: Iterationsanzahl bis zur Erreichung eines Zielfehlerwerts . . . . 65 6.6.2 Messung: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . 66 6.7 Xing-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
  6. 6. 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
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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]
  12. 12. 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.
  13. 13. 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.
  14. 14. 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]
  15. 15. 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]).
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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
  20. 20. 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
  21. 21. 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.
  22. 22. 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]
  23. 23. 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.
  24. 24. KAPITEL 2. GRUNDLAGEN 20 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
  25. 25. 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.
  26. 26. 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]
  27. 27. KAPITEL 3. ANFORDERUNGSANALYSE 23 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.
  28. 28. 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.
  29. 29. KAPITEL 3. ANFORDERUNGSANALYSE 25 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.
  30. 30. KAPITEL 3. ANFORDERUNGSANALYSE 26 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.
  31. 31. KAPITEL 3. ANFORDERUNGSANALYSE 27 • 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.
  32. 32. Kapitel 4 Entwurf In diesem Kapitel wird die Anwendung entworfen. Es werden das System und einzelne System- komponenten beschrieben und verschiedene Ansätze zur Realisierung diskutiert. Der Sparse Autoencoder wurde zwar nicht implementiert, dennoch wird für zukünftige Arbeiten das hierzu nötige Vorgehen am Ende des Kapitels beschrieben. 4.1 Systembeschreibung Datenvorverarbeitung Daten  bereinigen   (op.onal)   Daten  normalisieren   (op.onal)   Trainings-­‐/   Evalua.onsdaten   erzeugen   Training des künstlichen neuronalen Netzes (MLP) Modell   verteilen   MLP   ini.alisieren/   verteilen   Trainingsdaten  lesen  /   GradientendurchschniA   berechnen   Quelldaten   einlesen   Einstellungen   laden   Gewichtsupdate  berechnen  /   Modell  updaten   Modell   speichern   (op.onal)   Evaluation Modell     laden   Metriken   berechnen   Ergebnisse   ausgeben   Evalua.onsdaten   einlesen   Daten  cachen   (op.onal)   X-Iterationen Abbildung 4.1: Systemübersicht
  33. 33. 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,
  34. 34. 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.
  35. 35. 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).
  36. 36. 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-
  37. 37. 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.
  38. 38. KAPITEL 4. ENTWURF 35 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.
  39. 39. 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.
  40. 40. 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.
  41. 41. KAPITEL 4. ENTWURF 38 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.
  42. 42. Kapitel 5 Implementierung Dieses Kapitel beschreibt im Detail, die Implementierung der im Entwurf vorgestellten System- komponenten: Datenverarbeitung, Training und Evaluation. Außerdem enthält es am MLP- Framework vorgenommene Änderungen, Details die bei der Verwendung von Apache Hama beachtet werden mussten und eine Beschreibung der Softwaretests. 5.1 Datenverarbeitung 5.1.1 Cache Der Cache wurde implementiert, indem die I/O-Methoden von Apache Hama in einer Methode gekapselt wurden. Jeder BSP-Peer speichert nur seinen Teil der Daten in seinem Cache. In der ersten Iteration, werden die I/O-Methoden von Apache Hama genutzt und der Cache gefüllt. Ab der zweiten Iteration werden die Daten nur noch aus dem Cache geladen. Der Cache wurde in Form einer Liste realisiert, dabei wurde davon ausgegangen, dass der verfügbare Arbeitsspeicher immer für die Trainingsdaten ausreicht. Die Eingabedaten werden in dem in Abschnitt 4.1.1 beschriebenen Format erwartet und liegen in Form von Textdateien vor. Das MLP erwartet aber Vektoren, die mit Double-Werten gefüllt sind. Beim Füllen des Caches, werden die Textdaten deshalb geparst und in Form von Vektoren gespeichert. Durch die Benutzung des Caches muss zum einen das Parsen der Trainingsdaten nur einmal durchgeführt werden, zum anderen werden die Daten aus dem Arbeitsspeicher schneller als von der Festplatte geladen. 5.1.2 Trainingsdaten Die Trainingsdaten werden in dem in Abschnitt 4.1.1 beschriebenen Datenformat erwartet. Quelldaten müssen also vorher in dieses Format überführt werden.
  43. 43. KAPITEL 5. IMPLEMENTIERUNG 40 IParser <<interface>> +parse(String input): List<MLDataEntry> XingParser MonkParser Abbildung 5.1: Parser-Klassen Für die beiden Anwendungsfälle MONK (siehe Unterabschnitt 6.2.2, Seite 51) und Xing- Daten (siehe Abschnitt 6.7, Seite 69) wurden Parser zum Überführen der Quelldaten in Trai- ningsdaten implementiert (siehe Abbildung 5.1). Beide Parser implementieren das Interface IParser, erwarten einen Textzeile als Eingabe und geben eine Liste mit dem geparsten Inhalt, in Form eines MLDataEntry (siehe Abbildung 5.2), zurück. Ein Trainingsbeispiel besteht aus einem Feature- und einem Zielvektor, dessen Größe von der Anzahl an Eingaben bzw. der Neuronenanzahl in der Ausgabeschicht abhängt. Der jeweilige Vektor ist ein RandomAccess- SparseVector, d.h. es werden nur Daten im Speicher gehalten, die ungleich null (0) sind. MLDataEntry +targetVector:,RandomAccessSparseVector +featureVector:,RandomAccessSparseVector +MLDataEntry(nbInputUnits:int,nbOutputUnits:int) Abbildung 5.2: Trainingsdaten-Klasse Bezüglich der MONK-Daten musste beachtet werden, dass die Features/Eingabedaten in unterschiedlichen Wertebereichen liegen. Hierfür musste also vorher eine Normalisierung (siehe Anhang E, Seite 93) durchgeführt werden. Die für den zweiten Anwendungsfall benötigten Xing-Daten wurden von Prof. Dr. Herta zur Verfügung gestellt. Sie wurden von der Xing-Webseite gecrawlt und mussten in mehreren Schritten vor-verarbeitet werden. Hier wurden zum einen die Rohdaten vor-verarbeitet und zum anderen eine Wörterliste erstellt, da „bag of words“ als Features verwendet werden. Genaueres dazu in Abschnitt 6.7. Für die Erstellung der Trainingsdaten zur XOR-Funktion wurde kein extra Parser geschrie- ben, da diese Funktion nur vier verschiedene Zustände kennt und somit ein Parser nicht not- wendig gewesen ist.
  44. 44. 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
  45. 45. 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.
  46. 46. 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-
  47. 47. KAPITEL 5. IMPLEMENTIERUNG 44 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-

×