Vladislav Ladyzhenskiy, Sebastian Staudenmaier, und Mohsen Zarei

Transkript

1 ProjektINF: Entwicklung eines Testbed für den empirischen Vergleich verschieder Methoden des maschinellen Lernens im Bezug auf die Erlenung von Produktentwicklungswissen Vladislav Ladyzhenskiy, Sebastian Staudenmaier, und Mohsen Zarei Abstract Weka(Waikato Environmental for Knowledge Analysis) ist ein mit Java geschriebenem frei verfgbares Data-Mining-Tool und läuft unter allen Betriebssystemen, wo Java läuft. Weka wurde an der University of Waikato entwickelt und seine Quelltexte wurden als OpenSource bereitgestellt. In Weka sind viele Algorithmen aus den Bereichen Maschinelles Lernen und Data Mining insbesondere Klassifikatoren implementiert. Dieses Dokument liefert die Erklärung, wie man WEKA im eigenen Programm verwenden kann. Als Beispiel dafür dient die Online - Plattform fr das Ausrechnen von Daten im CSV oder ARFF - Format mit Hilfe der Klassifikations - und Clustering - Algorithmen und abschliessende Auswertung der Ergebnisse. Index Terms Klassifizierung und Clusterng, WEKA, ARFF - Format. 1 EINLEITUNG Klassifikationsalgorithmen spielen in der Mathematik eine wichtige Rolle. Sie vereinfachen die Berechnungen, zeigen Gemeinsamkeiten und lassen Schlüsse ber die zukünftige Entwicklungen von Prozessen ziehen. Aus diesem Grund existiert eine grosse Palette von Werkzeugen, die diesen Prozess automatisieren. In unserem Projekt haben wir WEKA (Waikato Environmental for Knowledge Analysis) verwendet, eine OpenSource - Anwendung, geschrieben in JAVA. Aus diesem Grund geniesst WEKA eine grosse Beliebtheit und hat deswegen in letzten Jahren viele Erweiterungen erlebt. Obwohl es möglich ist, eigene Algorithmen selber zu schreiben und sie dann in WEKA einbinden, haben wir nur bereits vorhandene Implementierungen verwendet. Obwohl WEKA fast alle Aspekte der Datenaufbereitung und Analyse umfasst, ist sie aber auch sehr komplex in der Bedienung. Sie besitzt einen umfangreichen Editor, unterschiedliche Ausgabemöglichkeiten, sowie die Möglichkeit, Ergebnisse graphisch in Form von ROC - Kurven darzustellen. Aus diesem Grund haben wir im Rahmen von ProjektINF eine MIddleWare entwickelt, mit deren Hilfe man einige Schwierigkeiten umgehen kann, die bei der Benutzung von WEKA entstehen. Auf den nächsten Seiten werden wir einzelne Elemente unserer Software beschreiben, sowie die essentielle Bestandteile der Klassifizierung und die Ergebnisevaluierung erläutern. 2 ARFF - DATENFORMAT ARFF (Attribute-Relation File Format ) ist ein File in ASCII - Textformat, der die Liste von Instanzen mit gleichen Attributen beschreibt. ARFF - Files haben zwei separate Bereiche. Der erste Bereich ist der Kopf(engl. header), gefolgt von Datenbereich. Der Kopf beinhaltet den Namen der Beziehung, die Liste der Attribute (Spaten in der Datentabelle) und deren Typen. Figure 1 zeigt ein Beispiel fr den Kopf der ARFF - Datei. Im Folgenden werden wir eine kurze Erklärung zu einzelnen Elementen beschreibt den Namen der beschreibt einzelne Attribute, die in einer geordneten Liste aufgefhrt sind. Jeder Attribut wird durch seinen Namen und den Datentyp gekennzeichnet. Die Reihenfolge der Deklarationen ist dabei wichtig und muss später in der Instanz - Deklaration eingehalten werden, denn sie bestimmt die Ordnung der Spalten in der Datentabelle. Als Typen knnen numerische, Zeichenketten, Datum oder zusammengesetzte Typen. Im Datenbereich des ARFF - Files wird die Liste der Instanzen festgelegt. Eine Instanz ist eine Zeile in der Datentabelle, die mit Werten gefühlt ist. Die Werte der Attribute werde dabei durch Kommata getrennt. Ein Beispiel dafür ist in Figure 2 dargestellt. Wie man sieht, stellt ARFF - Format Daten auf einfache und verständliche Art die Daten dar. WEKA stellt die Klasse ArffLoader bereit, mit dessen Hilfe man einen ARFF - File Zeile fr Zeile auslesen kann. Zusätzlich bietet WEKA die Mglichkeit, ARFF in CSV - File umzuwandeln. Die Konvertierung fällt dabei sehr leicht, weil die Werte in den Zeilen eines CSV - Files ebenfalls durch Kommata getrennt werden, und im Allgemeinen die identische Struktur haben. 3 ALGORITHMEN WEKA stellt eine Vielzahl an Algorithmen bereit. Wir haben in unserem Projekt lediglich auf drei der bekanntesten konzentriert: Naive Bayes, K - NEAREST - NIGHBOUR und K - MEANS. Wir unterscheiden hier zwei Arten von Algorithmen: die Klassifikationsalgorithmen und Clustering -Algorithmen. Unter Clustering versteht man die Gruppierung der Daten auf Basis ihrer Gemeinsamkeiten. Dadurch wird die Datenmenge durch eine begrenzte Anzahl an Clustern repräsentiert und somit vereinfacht. Eine solche Aufteilung ist entscheidend fr z.b. Bild - und Texterkennung. Neben der Instanzmenge selbst sind für das Clustering eine Distanz-/Abstandsfunktion und eine Qualittsfunktion ntig. Das Ziel des Clusterings lässt sich mit Hilfe einer Abstandsfunktion so formulieren, dass der Abstand der Individuen innerhalb eines Clusters kleiner als der Abstand zu den Individuen anderer Cluster sein soll. Klassifikation hingegen teilt einen Gegenstandbereich in die Klassen ein. Anhand einer vorgegebenen Trainingsmenge von bereits bekannten Objekten wird ein Modell aufgebaut. Dieses wird dann an Testdaten geprüft und gegebenenfalls korrigiert, bis es auf den Testdaten eine noch sehr geringe Fehlerrate erfüllt. Dabei sind sowohl die Klassen als auch die Zugehörigkeit der Trainingsobjekte zu einer dieser Klassen vorher bekannt. Im Folgenden werden wir die von uns verwendeten Algorithmen erläutern. Vladislav Ladyzhenskiy Sebastian Staudenmaier Mohsen Zarei {ladyzhvv staudesn zareimn}@studi.informati.uni-stuttgart.de K - MEANS - Algorithmus Der K-Means Algorithmus ist ein bekanntes iteratives Clusterverfahren, der einerseits relativ leicht zu verstehen und umzusetzen ist und andererseits hinsichtlich der Laufzeitkomplexität im

2 Figure 1: ARFF - Hader. Quelle: WEKA Manual Ver Figure 3: K-MEANS - Verfahren: Figure 2: ARFF - Datenbereich. Quelle: WEKA Manual Ver Grossen und Ganzen linear bezüglich der Anzahl der Cluster und der Mächtigkeit der Datenmenge funktioniert. K-Means produziert eine Clusterstruktur, in der die Cluster sich nicht überschneiden. In einfachen Worten minimiert das Verfahren die Abstände der Datenpunkte zur jeweiligen Clustermitte. Über diese Eigenschaft könnte auch formal gezeigt werden, dass die Iteration in K-Means gegen ein lokales Optimum konvergiert. Das K im Namen des Verfahrens drückt aus, wie viele Cluster zu erzeugen sind. Für jeden der K Cluster wird zufälligerweise zunächst einen einzelnen Datenpunkt aus den Eingabedaten herausgesucht. Diese einzelnen Datenpunkte werden dann als Repräsentant für ihre jeweiligen Cluster angesehen. Danach werden diese zwei Schritte iterativ so lange wiederholt, bis die Konvergenz der Cluster einsetzt. Im ersten Schritt wird für jeden Datenpunkt geprüft, zu welchem Cluster bzw. zu welchem Repräsentanten der Cluster es den geringsten Abstand hat, erst dann erfolgt die Zuweisung. Somit werden beim ersten Durchlauf alle Datenpunkte einem Cluster zugewiesen. Der zweite Schritt bestimmt einen neuen Repräsentanten fr die veränderten Cluster. In der Standard-K-Means dienen Zentroiden als Repräsentanten. Danach geht die Iteration in den zweiten Schritt und die Datenpunkte werden zu den Clustern bezüglich der veränderten Repräsentanten neu zugeteilt. Wenn sich die Repräsentanten der Cluster nicht mehr ändern, wird die Iteration abgebrochen. Figure 3 stellt die Vorgehensweise des K-Means-Algorithmus bildlich dar. (a) Auswahl der initialen Repräsentanten (b) Zuordnung der Datenpunkte zu den Reprsentanten (c),(d) Aktualisierung der Zentroiden und die Zuordnungen Als andere einzusetzende Abbruchkriterien kann man eine bestimmte Anzahl von Iterationen vorgeben. Oder alternativ kann es genügen, dass die Repräsentanten sich ganz wenig ändern. Daraus kann man schliessen, dass das Verfahren sich kurz vor der Konvergenz befindet und die Clustern sich nicht viel ändern werden. Eine weitere Variation des Verfahrens könnte so funktionieren, dass zu Beginn nicht einzelne Datenpunkte als Repräsentanten ausgew ahlt, sondern alle Daten rein zufällig einem der Cluster zugeteilt werden. Dann fängt man direkt mit der Bestimmung der Mittelpunkte an. Zu den Schwächen des K-Means-Algorithmus gehört zunächst einmal die Abhängigkeit von einer zufälligen Initialkonfiguration an Repräsentanten. Auswahl der verschiedenen Repräsentanten kann zum anderem Verlauf des Verfahrens führen, was das Konvergieren gegen ein anderes lokales Optimum zur Folge haben kann. Daraus entstehen schlechte Ergebnisse, die wegen einer ungünstigen Lage Figure 4: Bildung der Ausreisser: (a) Zusammenhngende Cluster (b) Bildung der Ausreisser der Initialreprsentanten geliefert werden. Um diesen Problem zu beseitigen lässt man K-Means mehrfach laufen. Somit sucht er sich dann das Ergebnis aus, in dem die Abstände der Datenpunkte zu ihren Cluster-Zentren am geringsten sind. Bei K-Means können Ausreisser unter den Daten problematisch sein. Die verursachen, dass ein Cluster nur aus dem Ausreisser selbst besteht. Das geschieht insbesondere, wenn ein Ausreisser am Anfang zufällig als Repräsentant fr einen Cluster ausgewählt wird. Dieser Sachverhalt ist in der Figure 4 dargestellt. Ein weiteres Problem sind leere Cluster, die whrend des Verfahrens entstehen. Schliesslich gibt es das systematisches Problem des K-Means- Algorithmus, dass er manche Clusterformen nicht erkennen kann. Zwei solche Fälle sind in der Figure 5 zu finden. 3.2 K - NEAREST - Algorithmus Das K-Nearest-Neighbour (KNN) Klassifikationsverfahren entscheidet auf der Basis von Abständen zu Vektoren, welcher Kategorie das neue Objekt zugeordnet wird. Dabei kann es f r jede Kategorie nicht nur einen, sondern mehrere Vektoren geben, die die Kategorie repräsentieren. Fr die optimale Ausnutzung der Trainingsdaten wird dann jede Kategorie durch alle zur Verfügung stehende Trainingsbeispiele dargestellt. Dementsprechend gibt es bei KNN keine wirkliche Trainingsphase. Stattdessen werden die Trainingsdaten komplett im Klassifikator gespeichert und fr die Klassifikationsphase vorgehalten. Die Klassenzuordnung eines neuen zu klassifizierenden Datenpunktes wird dann unter Berücksichtigung seiner k nächstgelegenen Figure 5: Erkennung von Clusterformen 2

3 Figure 6: Entstehung leerer Cluster Figure 7: Kommunikation zwischen Tomcat-Server und Google App Engine Nachbarn vorgenommen wird. Die Vorgehensweise ist dabei so, dass zunächst Abstand zu allen Trainingsdaten berechnet wird und dann von allen Trainingsdaten die k nächsten ausgewählt werden. Schlielich wird die Kategorie, die unter diesen k nächsten Nachbarvektoren am häufigsten vorkommt, dem Datenpunkt zugewiesen. Die Wahl des Parameters k ist bei KNN sehr entscheidend. Bei k = 1 müssen wir immer nur den nächsten Vektor eines Trainingsdatenpunktes berücksichtigen. Nachteil bei der Auswahl von k = 1 ist, dass es sehr instabil auf Ausreisser in den Trainingsdaten reagieren wird. Das kann eine Fehlklassifikation oder eine zufällige Zuordnung verursachen. Figure 6 zeigt ein 1NN Klassifikation. Im Allgemeinem sorgt ein grösseres k für eine besseres Stabilitt. Typisch ist Auswahl eines ungeraden Wertes fr k, um die Gefahr eines Unentscheidens unter den Kategorien der nächstgelegenen Nachbarn abzumildern. Alternativ kann man einen geeigneten Wert von k über die Trainingsdaten bestimmen. Dazu werden die Trainingsdaten in zwei Teilmengen, Trainings- und Optimierungsdaten, aufgeteilt. man benutzt die Datenpunkte, die in der ersten Teilmenge drin liegen, wie üblich als Trainingsdatensatz. Mit der zweiten Teilmenge wird dann die Einstellung des Parameters k optimiert. Mit den Optimierungsdaten wird geprüft, bei welchem Wert fr k die geringsten Fehler auf dem zuvor trainierten Klassifikator entstehen. Es ist noch anzumerken, dass man danach für eine überzeugende Evaluation weitere Testdaten benötigt. Man kann noch als eine Variante zu KNN der Einfluss der Nachbarn auf die endgültige Klassifikation mit Gewichten bezeichnen. Beispielsweise erfolgen die Gewichtungen über den Abstand der k nächsten Nachbarn, wobei die n näherliegende unter den nächsten Nachbarn einen wichtigere Rolle bei der Klassifikation spielen und die weiter entfernten einen kleineren Einfluss auf die Klassifikation nehmen. Bezüglich der Laufzeitkomplexität ist KNN linear von der Anzahl der verwendeten Trainingsbeispiele abhängig. Daher für mehr Trainingsdaten wird die Laufzeit fr die Berechnung der Abstände, um die k nächsten Nachbarn zu finden, auch steigen. KNN-Klassifikationsverfahren ist hauptsächlich fr die Anwendung auf Vektorraumdarstellungen von Daten geeignet. Aber es wurde nicht speziell fr Dokumentvektoren entwickelt und da auer der Abstandsberechnung keine Operationen auf den Vektordarstellungen stattfinden, kann es auch auf anderen Daten eingesetzt werden. 3.3 Naive Bayes Algorithmus Naive Bayes (kurz: NB) ist ein Klassifikator, der sich auf dem Bayesschen Theorem basiert. Bei diesem Klassifikator wird ein probabilistisches Modell zu den Kategorien und den darin vorkommenden Datenpunkten erlernt. Die Wahrscheinlichkeitsverteilungen aus den Trainingsdaten werden dabei berechnet. Ein neuer Datenpunkt wird dann einer Kategorie, fr die der Wahrscheinlichkeitswert maximal wird, zugeordnet. NB-Klassifikator hat das Ziel, zu einem gegebenen Datenpunkt zu schätzen, mit welcher Wahrscheinlichkeit er in eine Kategorie fällt, und dann dem Datenpunkt die Kategorie zuzuweisen, in welcher der Datenpunkt wohl am wahrscheinlichsten enthalten wre. Bei dem Einsatz der Naive Bayes-Klassikatoren wird angenommen, dass die Attribute der zu klassifizierenden Objekte von einander nicht abhängen und nur von der Kategorie abhängig sind, was in der Realität selten zutrifft. Daher heissen die Klassifikatoren naive. Trotz der unrealistischen Annahme liefern naive Bayes-Klassifikatoren bei praktischen Anwendungen, solange die Attribute nicht zu stark korrelieren, häufig gute Ergebnisse. Im Falle der starken Abhängigkeiten zwischen den Attributen ist dann eine Erweiterung des naiven Bayes-Klassifikators um einen Baum zwischen den Attributen notwendig. 4 USER INTERFACE UND SERVER WEKA bietet bereits eine umfangreiche graphische Oberflche. Doch sie ist in den meisten Fällen zu umfangreich. Aus diesem Grund haben wir unsere eigene Oberflche entwickelt und sie gleichzeitig in einen Internet Browser integriert. Dafür haben wir Google App Engine benutzt, eine Unser Ziel bestand jedoch darin, unter Ausnutzung von WEKA eine Online - Plattform 4.1 Implementierung Die von uns entwickelte Webanwendung kann die Klassifizierungsalgorithmen Naive-Bayes-Updateable und k-nearest, sowie Clustering mit dem k-means-algorithmus ausführen. Es können Daten im ARFF-Format oder im CSV-Format angegeben werden, welche die Anwendung entsprechend als Trainingsset nutzt, und anschlieend jeweils weiter für einen Vergleich der genannten Algorithmen verwendet. Ebenso lassen sich dann in einem weiteren Schritt in den gleichen Formaten Daten als Testset einlesen, welche dann anhand des Trainingssets klassifiziert oder geclustert werden. Hier erfolgt als Ausgabe, welcher Datensatz wie klassifiziert bzw. welchem Cluster zugewiesen wurde. Unsere Implementierung besteht im Wesentlichen aus zwei Komponenten: Dem Frontend, das auf der Google App Engine läuft, und dem Backend, welches auf einem Tomcat-Server läuft. Die zwei Module kommunizieren über HTTP mit von uns festgelegten Parametern und entsprechend formatierten Antworten miteinander. Der Benutzer sieht nur die Weboberfläche, die auf der Google App Engine läuft, und kann ohne groes Vorwissen die Anwendung bedienen, sofern er die Daten in einem geeigneten Format vorliegen hat. Um die Ergebnisse aus den Klassifizierungsverfahren mit dem Clustering vergleichbar zu machen, und dem Benutzer anzuzeigen, welcher Algorithmus ein Testset wahrscheinlich am besten auswerten wird, wurde eine Art Klassifizierung mit Clustern eingebaut. Die vom Benutzer angegebene Clusteranzahl wird für diesen Prozess ignoriert. Stattdessen wird die Clusteranzahl durch die Anzahl an verschiedenen Elementen für das Zielattribut ermittelt, für welches auch die Klassifikationsalgorithmen ausgewertet werden. Für diese Anzahl werden die Cluster berechnet. Im nächsten Schritt wird ein Mapping erzeugt, welches jedem Element des Zielattributs den Cluster zuweist, der es wahrscheinlich abbildet. Im letzten Schritt wird überprüft, ob der einem Element zugewiesene Cluster mit dem Mapping übereinstimmt, oder ob es mit dem falschen Cluster klassifiziert wurde. Der Erfolg dieser Klassifizierung kann dann mit den anderen Algorithmen verglichen werden. 3

4 Figure 8: Eingabemaske mit einem ARFF - File 4.2 Verwendete Technologie Neben für das Web üblichen Technologien wie HTTP, HTML, CSS und JavaScript in Verbindung mit JQuery kommt auf dem Server hauptsächlich Java-Software zum Einsatz. Nicht nur in den Java- Servlets in der Google App Engine und Tomcat, sondern auch im Waikato Environment for Knowledge Analysis kurz Weka, auf dessen API für dieses Projekt zurückgegriffen wird. Weka bietet eine groe Auswahl an Filtern, Klassifizierungs-, Clustering- und Assoziations-Algorithmen sowie Methoden für den Umgang mit Daten in verschiedenen Formaten. Die Open-Source Software Weka lässt sich sehr gut in andere Java-Programme einbinden. Mit nur wenigen API-Aufrufen kann man z.b. eine Instanz eines Klassifikationsalgorithmus erzeugen, diese mit Daten versorgen und eine Auswertung ausgeben lassen. 4.3 Google App Engine Die Google App Engine ist eine von Google angebotene Platform, auf welcher Webanwendungen platziert werden können. Es wird unter anderem eine Servelt-Umgebung, der sogenannte Datastore, der keine relationale Datenbank ist sondern mit Datenobjekten arbeitet, und zahlreiche integrierbare Google-Dienste zur Verfügung gestellt. Die Anwendungen, die der Ersteller auf der App Engine deployt und insbesondere auch der Datastore werden stark verteilt, und können somit auch mit vielen Anfragen umgehen. Hierum kümmert sich die Google-Platform, ohne dass der Ersteller der Anwendung dies programmieren müsste. Eine grundlegende Nutzung der Funktionalitäten der App Engine, mit einigen Beschränkungen, was unter anderem die Speicherkapazität, den Traffic und die maximale Rechenzeit pro Tag betrifft, ist kostenlos mit einem Google- Account möglich. Es können bis zu zehn Anwendungen erstellt werden. Google bietet ausführliche Statistiken der Anwendungen, sowie Verwaltungsoberflächen an. Von den Programmiersprachen her wird in der App Engine Java unterstützt, es können aber auch Programme in Python oder GO geschrieben werden. Allerdings sind die Java-Klassen, welche verwendet werden können, eingeschränkt. Zum einen Fehlt ein groer Teil von java.io, welches unter anderem von Weka insbesondere im Umgang von Methoden für Instanzen benötigt wird. Deshalb kann die Weka-API (zumindest in nicht angepasster Form) nicht direkt auf der Google App Engine verwendet werden. Zum anderen fehlt z.b. auch Unterstützung für java.rmi (Remote Method Invocation), welches wir zuerst für die Kommunikation zwischen dem Frontend und dem Backend nutzen wollten. 4.4 Unser Code Der Aufbau der Struktur der normalen Servlet-Umgebung im Backend-Server und die der Google App Engine sind sehr ähnlich. Zwar unterscheiden sich die Namen für Verzeichnisse teilweise, wie etwa das WebContent - oder war -Verzeichnis, in welchem statische (HTML-Dateien, CSS-Dateien usw.) oder dynamische Webinhalte (JSP-Dateien) abgelegt werden, jedoch sind viele Elemente wie die sich wiederum in einem Unterverzeichnis befindliche web.xml, die die Struktur der Servlets beschreibt, identisch. Die Google App Engine bringt jedoch noch weitere Dateien, wie die appengine-web.xml mit sich, in welcher App Engine spezifische Eigenschaften gesetzt werden können. Dynamische Inhalte können, wie von uns verwendet, direkt über Ausgaben einer Servlet-Klasse generiert, oder aber auch mit JavaServer Pages erzeugt werden, welche dann wiederum auf Methoden aus den Servlets zugreifen können. Um die Weka-API zu nutzen, muss die weka.jar-datei korrekt eingebunden werden. Anders als bei einem normalen Java- Programm genügt es hier nicht, mit einem Rechtsklick auf das Projekt in Eclipse ->Build Path ->External Archives... die Datei ins Projekt einzubinden. Zusätzlich muss die Datei danach auch noch in das Verzeichnis WebContent/WEB-INF/lib kopiert werden, damit es bei der Ausführung auf dem Tomcat-Server später auch in der.war-datei enthalten ist Die Backend-Server Implementierung Zunächst muss zwischen der doget-methode, die HTTP-GET- Aufrufe abhandelt, und der dopost-methode, für entsprechende POST-Aufruf unterschieden werden. Da hier nur POST-Aufrufe erwartet werden, ist die doget-methode bis auf die Ausgabe einer Fehlermeldung weitergehend leer. Der Code in der dopost-methode beginnt mit dem speichern der übergebenen Parametern in Variablen. Da diese als Strings ankommen, müssen Werte die z.b. als Integer vorliegen sollen erst umgewandelt werden. Da nicht klar ist, ob tatsächlich auch ein Integer- Wert eingegeben wurde, wird hier als Absicherung ein Standard-Wert gesetzt. Im nächsten Schritt unterscheidet die Serveranwendung zwischen zwei Modi: Im Modus 1 werden die initialen Aufrufe mit einem Trainingsset behandelt und verglichen, in Modus 2 werden Testsets klassifiziert oder geclustert. In Modus 1 wird zunächst für jeden Modus eine Instanz für die Daten angelegt, welche aus dem übergebenen ARFF- oder CSV- String durch die Methode makeinstance extrahiert wird. In den weiteren Schritten werden jeweils Objekte der Klassifizierungs- oder Clustering-Algorithmen sowie ein Evaluationsobjekt angelegt. Für die Algorithmen können vorab einige Einstellungen gesetzt werden, wie sie auch in Weka verwendet werden. Im nächsten Schritt werden die Daten des Insctance-Objekts den jeweiligen Algorithmen zugewiesen, und daraus die jeweilige Klassifizierung oder das Clustering erzeugt. Eine Besonderheit bildet das Clustering-Verfahren, bei dem zusätzlich zur der Auswertung über ein von Weka zur Verfügung gestelltes Evaluation-Objekt auch noch die oben bereits 4

5 Figure 9: Ergebnisse Testset erwähnte Berechnung eines vergleichbaren Wertes für den Vergleich der Algorithmen stattfindet. Sollte die alles geklappt haben gibt der Server die erzeugten Werte und Auswertungen in einem entsprechend formatierten Textformat aus. Im Fehlerfall wird zur Anzeige in der Google App Engine zurückgegeben, dass es zu einem Fehler auf dem Backend-Server kam. Im Modus 2 wird prinzipiell zunächst gleich vorgegangen wie in Modus 1. Hier gibt es aber zwei unterschiedliche Instanzen aus Daten zu erzeugen: Eine für das Testset und eine für das Trainingsset. Auerdem wird in einer Schleife für jeden Datensatz aus der Instanz eine Klassifizierung bzw. Zuweisung zu einem Cluster vorgenommen und diese ausgegeben Frontend-Server Implementierung Die in der Google App Engine implementierte Weboberfläche wird direkt aus den Ausgaben eines Servlets erzeugt. Auch hier gibt es die dopost- und doget-methoden. Nach dem Aufruf einer statischen Seite, auf welcher die initialen Daten für das Trainingsset sowie die URL des Backend-Servers und die Anzahl der Cluster angegeben wird, ruft man die dopost-methode des startservlet auf. In diesem werden zunächst die Variablen mit den jeweiligen übergebenen Werten initialisiert und diverse Fehleingaben abgefangen. Auch auf dem Programmteil auf der Google App Engine wird zwischen den zwei Modi 1 (Trainingsset einlesen und Algorithmen vergleichen) und 2 (Testset klassifizieren oder clustern) unterschieden. Wesentliche Aufgabe des Servelts ist es in Modus 1 die Parameter und Daten für die Weiterleitung an den Backend-Server zu sammeln und zu übertragen, sowie für die Ausgabe das entsprechende HTML-Dokument aus der Antwort des Servers zu erzeugen. Die übertragung und den Empfang der Daten an den Backend-Server übernimmt die httpservlet-klasse. Sie schickt die Daten jeweils mit einem HTTP-Post-Aufruf an den Backend-Server, als Rückgabe wird die von diesem erzeuge mit einem entsprechend formatierte Text-Seite verwendet. Die zurückgegebenen Daten werden von der parseservlet-klasse anhand von Trennzeichen zerlegt und in für das Programm nutzbare und ausgabefähige Teile umgewandelt. In Modus 2 passiert zunächst das gleiche wie in Modus 1, nur dass zusätzlich noch die jeweils angegebenen Daten für das Trainingsset an den Backend-Server geschickt und ausgegeben werden müssen. 5 PROGRAMMBEISPIEL ANHAND EINER PROBLEMSTEL- LUNG Als Problemstellung nehmen wir hier die weather.arff-datei aus den Weka-Beispielen. Diese enthält verschiedene numerische Werte, wie z.b. die Temperatur oder die Luftfeuchtigkeit sowie auch nominale Werte, wie ob es windig ist oder nicht. Als letztes Attribut enthält dieses Beispiel einen Wert play, der vermutlich beschreiben soll, ob sich das beschriebene Wetter zum Spielen drauen eignet. Im ersten Schritt nach dem Aufruf der Webseite unseres Projekts auf der Google App Engine wird der Inhalt der weather.arff-datei im Textfeld eingegeben. Als Dateiformat lässt man dementsprechend ARFF ausgewählt. Die Clusteranzahl von 2 erscheint wegen den zwei verschiedenen Werten des Zielattributs play sinnvoll. Nun wird noch die URL des Backend-Servers benötigt, danach kann man die Eingabe abschicken. Nun kommt man auf die Seite mit mehreren Tabs, hinter welchen sich die Ergebnisse der jeweiligen Algorithmen angewandt auf das Trainingsset verbergen. Die Anzahl korrekt klassifizierter oder geclusterter Datensätzen wird als Grundlage für den Vergleich der Algorithmen herangezogen. Es sind auch noch einige andere statistische Werte der Auswertung in den jeweiligen Tabs zu sehen. In diesem Fall wurden von den 14 Datensätzen durch den Bayes-Algorithmus 9 richtig klassifiziert, 11 durch den k-nearest- Algorithmus und 8 Stück wurden dem richtigen Cluster durch das k-means-clustering zugeordnet. Deshalb wird für die Auswertung von Testinstanzen der k-nearest-algorithmus empfohlen. Hier fügen wir nun einige Daten im CSV-Format ein, und lassen diese mit dem k-nearest-algorithmus klassifizieren. Als Ergebnis erhält man eine Auswertung, die für jeden Datensatz unter anderem anzeigt, wie der eigentliche Wert des Zielattributs ist, und was der Algorithmus als Klassifizierung anhand der anderen Attribute errechnet hat. 6 EINRICHTUNG EINER INSTALLATION AUF GOOGLE APP ENGINE UND EINES TOMCAT-SERVERS Möchte man unser Projekt einfach nur ausführen, so ist die Einrichtung einer Installation relativ schnell möglich. Hierzu wird ein Server mit Apache Tomcat benötigt. Den dienst der Google App Engine kann man direkt im Web unter der URL nutzen. Einen Tomcat-Server kann 5

6 man unter Windows beispielsweise mit XAMPP schnell und einfach einrichten. Hierzu lädt man sich unter folgender URL XAMPP herunter (allerdings nicht die Lite-Version, diese kommt ohne Tomcat): die von uns zur Verfügung gestellte Web Archive-Datei (pinfserver.war) und kopiert diese in den Ordner /tomcat/webapps im Tomcat-Verzeichnis. Nach dem Start sollte Tomcat die Anwendung automatisch deployen. Nun ist der serverseitige Teil der Anwendung über den Port 8080 und dem Unterverzeichnis /pinfserver/pinf zugänglich. Im Falle des lokalen Ausführens mit dem XAMPP-Paket also z.b. unter der URL: Diese URL trägt man nun beim Ausführen auf der Google App Engine als Backend-Server-URL ein. Damit dies auch mit der lokalen Installation funktioniert, muss diese aus dem Internet erreichbar sein. Hierzu richtet man im Router eine Weiterleitung des Ports 8080 auf die IP-Adresse des Rechners ein, auf welchem der Tomcat-Server, z.b. von der XAMPP-Installation läuft. Nun kann man noch über den Dienst DynDNS dafür sorgen, dass der Server auch bei einer dynamischen IP-Adresse stets unter der gleichen URL erreichbar ist. Hierfür benötigt man einen kostenlosen Account bei dyn.com sowie einen Router, der einen solchen Dienst unterstützt. Nach erfolgreichem Einrichten ist der Server dann unter einer URL wie etwa folgender zu erreichen: 7 EINRICHTUNG EINER LOKALEN INSTALLATION ZU TEST- UND ENTWICKLUNGSZWECKEN Möchte man an unserem Projekt weitere Features einbauen, so wird etwas mehr Software benötigt. Zunächst ist die Eclipse IDE in der Version Eclipse IDE for Java EE Developers notwendig, welche man unter folgender URL kostenlos beziehen kann: In dieser Eclipse-Installation müssen noch die Google-Plugins für die Entwicklung mit der Google App Engine installiert werden. Dies erreicht man, indem man im Eclipse-Menü auf Help - Install New Software... klickt. Dort trägt dort unter Work with: die folgende URL ein: Hierbei entspricht 4.2 der Eclipse-Version. Diese Zahl muss man entsprechend an die eigene verwendete Version anpassen. Nun wählt man unter SDK Google App Engine Java SDK aus, sowie unter Google Plugin for Eclipse (required) das Google Plugin for Eclipse 4.2 und installiert diese. Nach einem Neustart von Eclipse kann mit der Entwicklung von Anwendungen für die Google App Engine, wie etwa dem Frontend unseres Projekts, begonnen werden. Möchte man die Anwendung auch auf einer eigenen Installation bei der Google App Engine platzieren, so wird ein kostenloser Google- Account benötigt. Nach dem Login mit diesem in Eclipse kann man Anwendungen deployen. Für das Backend wird wieder ein Tomcat-Server benötigt. Nachdem dieser installiert ist (etwa via XAMPP wie oben beschrieben), muss man ihn noch unter Eclipse hinzufügen. Dazu klickt man im Eclipse-Menü auf File ->New ->Other... dort wählt man unter Server wiederum Server aus. Im Nächsten Schritt wählt man unter Apache die jeweilige Tomcat-Version, die man verwenden möchte, und gibt im wieder nächsten Schritt noch den Installationspfad des Tomcat-Servers an. Nun kann sowohl das Frontend mit Google App Engine als auch das Backend auf dem Tomcat-Server lokal ausgeführt werden. Lokal ausgeführte Anwendungen auf Google App Engine sind unter der URL erreichbar, der Tomcat-Server ist dann wie oben bereits beschrieben üblicherweise unter erreichbar. Wahl des Zielattributs: Wir gehen davon aus, dass jeweils das letzte Attribut einer Instanz das Zielattribut für die Klassifizierungsverfahren ist, wie es auch bei Weka vorausgewählt ist. Indem aus der Instanz auf dem Backend-Server die jeweiligen Attribute extrahiert und an die App Engine zurückgegeben werden, um daraus auszuwählen, könnte man dies noch flexibilisieren. Speichern von Experimenten: Die Google App Engine bietet mit dem Datastore und der möglichen Nutzung von Logins mit dem Google-Account prinzipiell eine gute Möglichkeit, Experimente zu speichern. Man könnte sowohl die Daten bis zu einer gewissen Gröe, als auch die Auswertungen oder die erzeugten trainierten Modelle der Klassifizierungs- oder Clustering-Algorithmen speichern. Eigene Parameter: Die Parameter für die von Weka verwendeten Algorithmen sind bisher bis auf die Clusteranzahl festgeschrieben. Mit einer entsprechenden Anpassung in der Oberfläche könnte man diese mit abfragen, auf dem Server müssen diese dann überprüft werden. Ausgabe von Grafiken: Eine Visualisierung der Daten sowie der Klassifizierung und vor allem der Cluster wäre denkbar. Aus den CSV formatierten Daten, die sich mit Weka leicht erzeugen lassen, könnte man z.b. im Browser anzeigbare Grafiken wie etwa eine Scatterplot-Matrix mit D3.js generieren. Filter und weitere Algorithmen: Weka bietet eine Vielzahl von Filtern für Daten und weiterer Algorithmen an, um welche die Implementierung noch erweitert werden könnte. Bessere Daten-Eingabe: Die maximale gröere der verwendbaren Daten ist bei unserer Implementierung durch die Gröenbegrenzung für HTTP-Post-Daten begrenzt. Diese Grenze variiert je nach Browser und Webserver. Hier bestünde die Möglichkeit den Direktupload von Dateien zu implementieren oder die Anbindung an eine Datenbank zu realisieren, statt auf ein Textfeld zu setzen, um auch gröere Datenmengen hochladen zu können. Weka in Google App Engine: Ohne Anpassungen sind viele relevante Methoden von Weka aufgrund der Beschränkungen nicht direkt in der Google App Engine nutzbar. Wenn der Code von Weka entsprechend angepasst wird, dass insbesondere auf den Zugriff auf java.io verzichtet werden kann, wäre es möglich den Code komplett auf der Google App Engine laufen zu lassen. REFERENCES [1] R. R. Bouckaert, E. Frank, M. Hall, R. Kirkby, P. Reutemann, A. Seewald, and D. Scuse. WEKA Manual for Version The University of WAIKATO, January [2] P. D. J. Cleve. Data mining, [3] D. T. Gottorn. Information retrieval, [4] C. D. Manning and P. R. Schtze. Introduction to information retrieval. Cambridge University Press, 1, MÖGLICHE WEITERENTWICKLUNGEN 6