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.