dokumentation der lösungsansätze für den data-mining
Transcription
dokumentation der lösungsansätze für den data-mining
DOKUMENTATION DER LÖSUNGSANSÄTZE FÜR DEN DATA-MINING-CUP 2012 Teammitglieder: Jevgenij Jakunschin Christian Mewes Aufgabenstellung: Der Aufgabe liegt eine Datenmenge zu Grunde, die über einen Zeitraum von 6 Wochen (42 Tagen) auflistet, wie häufig und zu welchem Preis ein Produkt verkauft wurde. Dabei gibt es 570 verschiedene Produkte, die auch jeweils für jeden Tag gelistet sind. Diese Daten gelten als Trainingsmenge. Aufgabe ist es die Menge pro Produkt pro Tag für die nächsten 2 Wochen vorauszusagen. Dazu wird eine Klassifikationsmenge geliefert. Dabei handelt es sich um die gleichen Daten wie in der Trainingsmenge, mit dem Unterschied, dass die Spalte mit der Mengenangabe fehlt. Diese muss durch das zu entwickelnde Model möglichst genau hinzugefügt werden. Vorbetrachtungen: • Um selber ein entwickeltes Model testen zu können muss die bestehende Trainingsmenge in eine neue Trainingsmenge + Klassifikationsmenge aufgeteilt werden (dies wird vorwiegend im Verhältnis 4:2 geschehen) • Es wurde sich im Team darauf geeinigt grundsätzlich 2 verschiedene Ansätze zu verfolgen, zum einen ein Model auf Basis von Knime und zum andern ein Model auf Basis von Matlab zu entwickeln. • schneller Umgang von Matlab mit großen Datenmengen • bisherige Erfahrung im Umgang mit Matlab • Baukasten-Prinzip von Knime • Knime erlaubt es viele unterschiedliche Datamining Algorithmen schnell und bequem auszuprobieren • Matlab ermöglicht genauere Datenmanipulation und mehr Scriptingmöglichkeiten für ausgewählte Algorithmen • Zur Ergebnissynchronisation wird der Cloudservice von Dropbox verwendet. Ansatz 1: Matlab Ansatz1: Matlab: • Umwandeln der train.txt in ein für Matlab verständliches Format. Die Trenner ('|') wurden mittels Notepad++ in Kommas (',') umgewandelt und die geänderte Datei, als train.csv abgespeichert • Zur besseren Übersicht wurden die Daten zuerst in OpenOffice Dargestellt. Hier wurde dann versucht durch sortieren nach verschiedenen Spalten Muster und Abhängigkeiten zu erkennen. Da dies nicht ohne weiteres möglich war, wurden daraufhin diverse Graphen erstellt. Dabei wurde deutlich das es zumindest eine kleine Abhängigkeit in Sachen Tag und Menge zu geben scheint. So war ein Wochenrytmus erkennbar und es wurde eine zusätzliche Spalte mit der Information über den Wochentag angelegt • Da keine weiteren Muster zu erkennen waren, wurden verschiedenen Werte berechnet, die eine Hilfestellung für weitere Betrachtungen darstellen sollten. So wurde z.B. der Mittelwert des Preises/der Menge eines Produkts über den betrachteten Zeitraum gebildet. Diverse Statistiken und Werte können im Ordner Statistiken eingesehen warden • Da auch keine „falschen“ Werte, leere Felder, Formatverletzungen etc. festgestellt werden konnten und der Datenbestand somit korrekt schien, wurde versucht den bisher einzigen Ansatz in Matlab umzusetzen – der Bezug zwischen Menge und Wochentag. • Da keinerlei Abhängigkeit zwischen Preis und verkaufter Menge zu bestehen schien wurde der Preis komplett außer acht gelassen • Versuch1: Den Wochentag jedes Eintrages in der Klassifikationsmenge nehmen und den Durchschnitt über alle gleichen Wochentage zu dem jeweiligen Produkt bilden. Ergebnis: 9,56% • Versuch2: Experimentieren mit Minimum und Maximum, statt den Mittelwert zu bilden Ergebnis: MIN:15,73%, M1:20982, E2:481.3 MAX: 5,41% • Versuch3: Ausreißererkennung implementieren um bessere Ergebnisse zu erzielen Problem: Wie? Will man den Durchschnittswert nehmen und alle im bestimmten Rahmen drüber und drunter abschneiden verschlechtet sich das Ergebniss, wie Tests mit einem Matlab-Skript gezeigt haben. Das liegt daran, das die Ausreißer ja selbst den Durchschnitt beeinflussen und somit das Ergebnis verfälschen. Test: Um den Nutzen eines Ausreißer-Filters abschätzen zu können, wurden per Hand die augenscheinlichen Ausreißer der ersten 50 Produkte entfernt und über die gefilterte Liste getestet, was zu einer Verbesserung um ca.5% führte. Nun musste ein mathematischer Ansatz für diese Filterung gefunden werden. Lösung: Nach langem Suchen und Probieren wurde der iqr()-Befehl gefunden, der dazu verwendet werden kann, einen gewichteten Durchschnitt zu erstellen. Das Ergebnis war eine leichte Verbesserung der vorherigen Werte im Bereich um 1-2%, kam jedoch nicht an das Ergebnis einer manuellen Filterung heran. • Versuch4: Der Preis scheint zwar willkürlich, dennoch soll untersucht werden ob durch Miteinbeziehung eine Verbesserung erreicht werden kann. Dazu wird der Durchschnitt des Preises über alle 28 Tage pro 1 Manhattan-Distanz 2 Euklidische Distanz Produkt berechnet. Danach werden wieder nur die entsprechenden Wochentage betrachtet. Test1: Liegt der Durchschnitt der Wochentage über dem Durchschnitt aller Tage wird der Durchschnitt abgerundet („floor(DS)“), anderenfalls wird er aufgerundet („ceil(DS)“). Test2: Liegt der Durchschnitt der Wochentage über dem Durchschnitt aller Tage wird das Minimum der Wochentage genommen, anderenfalls das Maximum. Ergebnis: In beiden Fällen nur eine Steigerung um ca. 0,5% • Versuch5: Identische Datensätze finden. Für jede Zeile der vorauszusagenden Menge wird in der Trainingsmenge zuerst nach identischen Wochentag und anschließend nach identischen Preis gesucht. Wird ein Treffer gefunden, wird deren Menge direkt übernommen. Werden mehrere Treffer gefunden, wird das Mittel gebildet. Wird kein Treffer gefunden, wird wie zuvor vorgegangen. • Ergebnis: +1.5% (bei kein Treffer wird Minimum verwendet) • Versuch6: Clustering anhand von Mengen. Problem: Wie? Auch hier wurde lange nach einer geeigneten Methode gesucht um unter Matlab sinnvolle Cluster zu bilden. Am Ende wurde dazu K-Means verwendet. Ergebnis: Es konnte kein funktionsfähiges Skript erstellt werden, da sich die Einordnung der Einträge der Klassifikationsmenge in die Cluster nicht realisieren lies. Dies ist auf einen Denkfehler zurück zu führen, da vernachlässigt wurde, das in der Klassifikationsmenge ja keine Mengenangaben vorhanden sind. • Versuch7: Clustering nach Produkten, die immer verkauft werden und Produkten, die nicht immer verkauft werden. Problem: Ansatz für weiteres vorgehen fehlte und Versuch wurde fallen gelassen. • Versuch8: Zusammenführen vorheriger Versuche. Es wurde ein Skript erstellt, was die Aufteilung der train.csv Trainings- und Klassifikationsmenge automatisch übernimmt, sowie benötige Daten in zusätzliche Spalten einfügt. So wird ein Wochentag, eine Wochennummer und ein Index den Daten angehängt. Daraufhin wird jeden Eintrag der Vergleichsmenge einem Cluster zugeordnet. Dazu werden sämtliche Tage (Train+Class) eines Produkts miteinbezogen und über den Preis geclustert. Alle Einträge des Produkts aus der Trainingsmenge, die im selben Cluster liegen, werden weiter betrachtet. Existieren mehrere Datensätze des identischen Wochentags, wird darüber approximiert um den Mengenwert zu bestimmen, existiert nur einer, wird dieser übernommen, existiert keiner wird über alle ClusterDatensätze approximiert. Ergebnis: Guter Prozentwert, aber explodierende Distanzen Grund: Bei der Approximation kommen stellenweise extrem große Werte raus. • Versuch9: Beseitigen der durch die Approximation entstandenen Extremwerte. Dazu wird festgelegt, dass kein vorausgesagter Mengenwert A: den Maximal-Mengenwert des Produkts überschreiten darf und B: er nicht negativ sein darf. Lösung: Übertritt ein Wert eine dieser Grenzen, wird das Mittel über die Datensätze gebildet und als Mengen-Vorhersage übernommen. Anschließend wurde noch mit der Anzahl der Cluster und dem Polynomgrad der Approximation experimentiert um das Ergebnis zu optimieren. Ergebnis: 16,44% M:20948,E:461,89 • Versuch10: Integration des Ausreißer-Filters Ergebnis: Prozentwert stieg, Distanzen stiegen aber unverhältnismäßig. Rückblick: • Es wurde versucht die Teil-Erfolge der jeweiligen Ansätze möglichst auch im jeweils anderen mit einfließen zu lassen (Knime ↔ Matlab), wobei festgestellt werden musste, das dies aufgrund der Modularität von Knime nicht immer möglich ist. So ist für den Nutzer von Knime nicht zwingend ersichtlich wie ein Bauteil (z.B. Kstar) funktioniert, wodurch dieses auch nicht in Matlab implementiert werden kann • Da 29% der „Mengen“ = Null sind, erreicht man häufig eine relativ hohe Prozentzahl, wenn man, wie in den Versuchen das Minimum der Werte, statt den Durchschnitt verwendet. • eine kurze Beschreibung der einzelnen Skripte unter Matlab, sowie der Modelle in Knime liegt dieser Dokumentation bei (Skripte.txt) Ansatz 2: Knime Analyse der Die Tabelle ist komplett ausgefüllt. Es gibt keine fehlenden Zellen oder Datenqualität: Duplikate, wodurch eine Nachbearbeitung der Daten deutlich vereinfacht wird. Es treten jedoch starke Abweichungen in Zahlen und auch „Peaks“ - teilweise unerwartet hohe Verkaufszahlen auf. Alle Daten sind in numerischer Form und mit der Ausnahme des Preises auch aufzählbar. Vorverarbeitung: Über den Verlauf des Projekts wurden Zusätzliche zusätzliche Spalten und ableitbare Tabellen Tabellen angelegt. Diese beinhalten normalisierte (Z und 0:1 Min Max Normalisierung) und nominalisierte Spalten, für den schnellen Import und Verarbeitung der Werte in Matlab und Knime. Außerdem wurden Mittelwertspalten und Informationen wie Gewinn und Wochentag hinzugefügt. Darüber hinaus wurden (für Clusterungszwecke) Tabellen angelegt die eine Zuordnung Woche->Produkt anstatt von Tag->Produkt verwenden und die jeweiligen Tage, Preise und Verkaufszahlen als Spalten verwenden. Angehensweise Getestete Algorithmen (einige) Die Durchschnitts- und Summenwerte von Preisen, Gewinn und Verkäufen wurden verwendet um die Daten in Diagrammform zu Visualisieren. Aus diesen Graphen kann man eindeutig sehen, dass es um eine Art Periodizität bei den Verkäufen gibt, auch wenn diese sich verschiebt oder verändert. Ein Wochenzyklus ist sichtbar. Die Werte Schwanken sehr stark (bis zu 350%). Der Preis hingegen unterliegt einer deutlich schwächerer und deutlich weniger periodisch ausgeprägter Schwankung. Periodizität und stark schwankende Werte mit Wochenzyklus schlagen gleich mehrere Vorgehensweisen vor. Als aller erstes wurden allerdings strukturierte Scripts und Diagramme in Knime und Matlab erstellt, die das probieren, austauschen und schnelles Auswerten von Algorithmen erlauben. In diesen, kann man sehr einfach Spalten dazu/rausnehmen, Clusterung vornehmen, verändern und Auswerten, die Test und Trainingsdaten anpassen, Filtern und schnelles denormalisieren erlauben. Zusätzliche werden mehrere Darstellungsmöglichkeiten (Line Plot, Enrichment Plotter) und die wichtigsten Auswertungszahlen ausgerechnet: -Eukliddistanz -Manhattendistanz -Accuracy Algorithmen und Vorgehensweisen wurden danach ausgewertet. - Naive Bayus (unterschiedliche) - Linear Regression - Logistic Regression - Polynomial Regression - Kmeans - Xmeans - Kstar - Decission Trees (unterschiedliche) - LWL - MLP/PNN Neuronal Networks - Approximationen, Interpolationen - Zerlegung in harmonische Funktionen Auswertung erster Leider haben sich alle Vorgehensweisen vorerst als relativ ungenau erwiesen Versuche und gaben Werte im Bereich von 15% Accuracy und Euklidische Distanz über 2000. Diese Werte sind besonders niedrig, wenn man beachtet dass die Verkaufswerte in 30% aller Fälle durchschnittlich 0 beträgt, wodurch man durch einfaches null-setzen eine Accuracy von 30% erhalten würde. Die folgenden Algorithmen haben sich allerdings bis zu dem Punkt die besten Resultate ergeben: - Regression (Polynomial, Linear): Bis zu 20% Accuracy - Kstar: Ungenaue aber gute Tendenz erkennende Kurven (siehe Bild unten): Verfeinerung In diesem Stadium wurde versucht die Ergebnisse zu verbessern. Dazu wurden Testweise Spalten hinzugefügt, entfernt, Variablen verändert und vorgeclustert oder zusätzliche Algorithmen angehängt. Besonders erfolgreich zeigte sich die Clusterung. Durch ein Aufbrechen der Datenmenge nach Wochentagen, wurde das Resultat deutlich besser. Allerdings waren die Resultate noch besser wenn noch mehr Cluster erstellt wurde. Dies schlägt vor dass eine interne Klassifizierung bzw. Aufteilen der Produkte in unterschiedliche Produkttypen stattfindet. Dies wurde mit K-means analysiert und die Cluster wurden angepasst, was mit einer starken Verbesserung der Genauigkeit folgte. Interessanterweise (durch die hohe Anzahl von 0 Werte), führte eine noch stärkere Clusterung, zu noch besseren Ergebnissen (bis zu 42% Genaue Ergebnisse), allerdings auf starke Kosten der Eukliddistanz. Spezifische Versuche: Avarage Statistics – Erstellen von Statistik-Tabellen 1) (FAIL) Direct Decission Tree – Erste Versuche (mit Knime und dem Projekt). Unerfolgreich, weil Tabellenspalte „win“ die man im normalfall nicht erhalten kann in die Testdaten mit reingenommen wurde 2) (FAIL) Polynomial Regression – Erste polynomiale regression (fehlerhaft) siehe oben (win spalte problem) 3) (FAIL) Last Days Polynomial Regression – Vernünftige Partitionierung, aber auch fehlerhaft 4) (FAIL) Randndom Polynomial Regression – Experimente mit Schleifen und Versuche möglichst große Übereinstimmungen zu bekommen, durch Zufallsclustern. Fehlgeschlagen (siehe oben) 5) (FAIL) Neuronal – Erstes Neuronales Netz. Funktioniert gut, aber fehlerhaft (immer noch „win“ problem) 6) Normal Predictor – Neuer Aufbau, hat Normalisierung, Filterung, Splitten, Partitionierung und Auswerung – um schnell viele mögliche Knime Algorithmen zu testen. Erfolgreich, führte zu guten Regressionstests und neuronalen Tests (Werte allerdings niedrig) 7) Normalize Table – Aufbau für Erstellen von Wochen-Tabellen und CSV Datei schreiben. Keine direkten Ergebnisse, aber Tabellen später verwendet 8) Weka Predictor (später in Kstar Graph umbenannt) – Ähnlicher Aufbau wie Normal Predictor mit Doppelfilter, Distanzberechnung und angepasst um WEKA Module zu testen. Bestes Ergebniss: Kstar, 20% 9) Kstar Clustered – Testen mit Clustern mit Kstar Algorithmus – Gute Resultate, Werte teilweise über 25% 10) KSTAR+CLUSTER+NEURO – Versuch ein Neuronales Netz an das Kstar Algorithmus zu hängen. Ergebnisskurven sehr interessant, allerdings von kleinem praktischem Gebrauch, bzw konnte nicht effektiv verwendet werden (Ergebnisse bis 15%) 11) Ordner DL – Gefüllt mit Knime Testprojekten, vom Knime Example server, verwendet zu Studiumzwecken 12) Clustered Star – Weitere Versuche mit dem Kstar Algorithmus. Verwendung des Kmean Algorithmus, mit 7 Clustern, Werte bis über 35%, allerdings niedrige Euklid-Distanz 13) Clustered Kstar Var – Das gleiche nur mit anderen Parametern 14) Kstar Clustered SemiSuc – Erste experimente die guten Euklidwert (<600) mit Kstar Algorithmus abgeben. Clusteranzahl ist antiproportional zu guten Euklidwerten und Proportional zu guten Accuracy Werten (wegen den 0-Verkäufen), wie es aussieht – bis zu einem bestimmten Punkt 15) LoopNeuro & NeuroStar – weitere Versuche den Algorithmus mit anderen zu kombinieren, beste Ergebnisse mit Neuronalen Netzen, jedoch schlechter als ohne diese. 16) Final Kstar – Nicht unbedingt besser als 12) oder 14) aber erlaubt weitreichend mehr anpassung und Euklid Werte im Bereich von 700, mit Genauigkeitbesser als 12) oder 14) aber erlaubt weitreichend mehr anpassung und Euklid Werte im Bereich von 700, mit Genauigkeiten im Bereich von 20%. Rückblick Knime lieferte außergewöhnliche Möglichkeiten Algorithmen auszuforschen und zu testen, zum Beispiel innerhalb von Tagen hunderte von Algorithmen zu vergleichen, was es erlaubt sich mit den Daten vertraut zu machen und danach sich auf genauere Algorithmen zu spezialisieren. Auch wenn das Auswerten und anpassen danach problematisch werden kann. Aber genau da kommt Matlab ins Spiel, wo man selber alles verändern und einstellen kann. KStar gegen Regression Im Nachhinein betrachtet war es immer schwer das „bessere“ Ergebnis auszusuchen, da man teilweise Euklidische Distanz für Genauigkeit und umgekehrt austauscht oder gar nicht weiß welche Methode effektiver ist. Trotzdem war die Arbeit an dem DMC2012 Projekt interessant und informativ. Letztendlich muss eine Entscheidung zwischen den 2 Algorithmen getroffen werden. Kstar+Kmeans zeigten niedrigere Manhattan Distanzen (20000 in Vergleich zu 22000+), während Regression+Kmeans bessere Euklid Distanzen (461 im Vergleich zu 650+) aufweiste. Die Genauigkeit schwankt bei beiden Algorithmen im Bereich von 20-30%. Letztendlich wurde Regression als der bessere Algorithmus ausgewählt.