Maskininlärning och Kaggle-Swe

[See this in English]

Kaggle är en sajt som hostar olika tävlingar inom maskininlärning. Det här blogginlägget kommer beskriva den första av de kaggletävlingar som jag deltagit i, vad jag gjorde och hur resultatet blev.

Kaggle beskriver sig själva som

The world’s largest community of data scientists compete to solve your most valuable problems

AXA Driver Telematics Analysis

AXA Driver Telematics Analysis gick ut på att “Använda telematisk data för att identifiera en förarsignatur”. Kort sagt så¨fick man tillgång till en enorm mängd bilturer (beskrivna med GPS koordinater) som utförts av olika förare. Olika bidrag bedömdes på hur väl man lyckades identifiera vilken förare som utfört vilken biltur.

I tävlingen deltog 1528 deltagare och jag lyckades, efter mycket arbete, komma på plats 17. Av de 16 bidrag som kom före mig så lämnades 7 in av team och resten av enskilda individer. Jag valde att utveckla all min kod själv, från scratch, vilket kan verka opraktiskt, men det är så jag lär mig. Hitta en cool algoritm och sedan implementera den själv.

Anonymisering av data

Målsättningen för AXA, som betalade ut $30,000 i vinstpengar (plus pengar till Kaggle för att administrera tävlingen), var att försöka identifiera när “fel” förare framför ett fordon. Om det t.ex. blivit stulet eller utlånat.

Kaggle/AXA hade blandat upp körningar från en given förare med slumpvis valda körningar från någon annan förare. Målet var att identifiera de körningar som inte tillhörde huvudföraren. Detta innebar att dessa körningar utfördes i en annan stad än de körningar som den egentliga föraren utfört. Så för att hitta missmatchande körningar så räckte det att hitta körningar som kom från ett annat område och peka ut dessa som de felande körningarna.

Kaggle/AXA hade förutspått detta, så de gjorde om alla GPS koordinater till relativa koordinater, mätta i meter, med 0-punkten satt där körningen började. Utöver detta så klippte de bort ett stycke i början och ett stycke i slutet av varje körning. Sedan spegelvändes hälften av körningarna och de roterades mellan 0 och 360 grader. Detta för att försvåra att a) identifiera området och därmed göra tävlingen för lätt och b) identifiera den verkliga adressen som personen kom ifrån/åkte till. B utfördes för att skydda de personer som ingick i underlaget.

Så två identiska körningar (hur man nu åstadkommer detta) skulle se radikalt olika ut i underlaget. Bilden ovan visar de körningar som en speciell förare utfört. Lägg märke till att de åker slumpvis åt alla håll – så ser det förstås inte ut i verkligheten, de flesta åker hemifrån till vissa fasta punkter och tillbaka igen, så många körningar borde överlappa.

En modell som AXA kunde ha nytta av kan inte vara baserad på var föraren kör utan endast *hur* föraren kör, hur fort personen tar kurvor, hur personen ökar och minskar hastigheten etc. Därför försökte AXA/Kaggle se till att endast denna information gick att utvinna ur data.

Allt slutade i tårar

Det hela gick dock förfärligt snett så att inga utav de modeller som placerade sig högt gick att använda till något användbart. Man identifierade snabbt att det enda sättet att få konkurrenskraftiga resultat var att ändå försöka hitta vilka körningar som matchade andra körningar i databasen, detta kallades Trip Matching och bilden nedan visar ett antal trippar som matchats upp mot  varandra av en annan Kagglare. Min lösning påminner mycket om den lösningen de beskriver. Det faktum att rutten roterats gör att man istället för att titta på koordinaterna tittar på svängar som utförts och sedan försöker man hitta andra rutter som under en viss period har liknande svängar. Den som hade bäst Trip Matching metod vann. Man kunde försöka matcha resultatet med lite verklig Machine Learning, men utan bra Trip Matching så var man såld.

Processorkraft

Det krävdes enorm processorkraft för varje test som utfördes. Varje ändring av koden behövde köra igenom alla tripper för att skapa sitt resultat och mot slutet, när koden var som mest avancerad, så tog detta minst ett dygn. Så det handlade om gör en liten ändring, vänta ett dygn, gör en ny liten ändring, vänta ett dygn. Sedan dess har jag köpt en snabbare dator (6 cores, 12 hyperthreads med 32 GB RAM) men även den nya datorn har för lite RAM för de tävlingar jag jobbar med nu.

På slutet av denna Kaggle så hyrde jag in 3 stycken stora burkar på molnet (Microsoft Azure) för att kunna testa flera olika varianter parallellt…

Varför jag placerade så högt

Om sanningen skall fram så finns det tre huvudingredienser i mitt recept

1. Jag hade tur när jag valde metod, det fanns tusentals andra där många av dessa hade varit sämre. Tyvärr finns det oftast ingen tydlig riktning att gå i när man får dåligt resultat. Så man måste testa åt ett par olika håll och fortsätta åt det håll som verkar mest lovande, men man famlar i blindo för att varje körning tar så lång tid.
2. Jag har programmerat i 30 år så ingen algoritm är för krånglig för att implementera. Hade jag en idé kunde jag implementera och provköra den
3. Jag nötte som *fan*

Oftast så försöker jag bygga en metod som låter mig iterera rykande fort, för att jag aktivt skall kunna testa olika varianter, det blir mer kreativt och man minns mellan körningarna vad man var ute efter att göra. I den här tävlingen var det svårt.

Just nu tävlar jag i en Kaggle som handlar om resebranschen där jag försöker evolvera fram en lösning.