Endorse me

Jag ser lärande processen i två steg. Det första är då man börjar lära sig ett ämne eller område helt från grunden. Låt oss ta inlärningen av SQL som ett exempel för att göra detta mindre abstrakt. Det är inte alls ovanligt att man springer på personer där ute som säger sig vara flytande på SQL. Det första man skulle kunna anmärka på är att många just använder begreppet flytande trots att de allra flesta Googlar eller använder databasdokumentationen för en hel del av syntaxen så fort man ska skriva en lite mer avancerad ad-hoc fråga, men man ser sällan någon som kan ett språk flytande sittandes med en ordbok så fort de ska skriva någonting oförberett.
När man börjar från grunden och inte kan SQL överhuvudtaget så känns det antagligen som att man har fått kläm på det när man har förstått de grundläggande syntaxen för att skapa tabelller och index, infoga och uppdatera data, läsa ut data med joins och sub-selects. Man tycker att man kan få ut allt det data man vill och då har man blivit flytande. Man kanske till och med är anställd som analytiker och sitter dagligen med en SQL klient och hämtar data ad-hoc och anses på företaget som expert i ämnet.

Det intressanta här är dock inlärningströskeln som man måste nå för att komma över en vi nivå för att inse att vad man faktiskt kan. Ifall man skulle vara intresserad och öppna en till dörr skulle man snabbt inse att det finns oftast en hel värld där bakom som man inte har upptäckt. Kanske han man ännu inte upptäckt alla analytiska queries eller möjligheter med stored procedures. Skrapar man vidare upptäcker man att det finns en mängd spännande saker som händer under huven. Givietvis väldig skillnad beroende på vilken databas man använder, men det kan vara allt från olika typer av indexeringar, komprimering och enkodning av olika datatyper till query-optimering.

Om jag skulle generaliserat riktigt mycket skulle jag påstå att den självupplevda inlärningskurvan för många ser ut som ett U. Ganska snabbt tycker man sig kunna detta nya område och man uttrycker sig bekvämt i situationer och konversationer i detta ämne. Inte ovanligt med CVn från nyutexaminerade studenter som listar sig själv som experter i de flesta områden som de tagit kurser. Inte för att luras eller översälja sig själva, utan enligt min tes för att de ännu bara har fått insikt om vad de kan, men inte vad de inte kan. De som är intresserade att lära sig mer märker ganska snart att det man kan är bara toppen på ett isberg och kurvan rasar neråt. Kanske har man lite ångest för hur naiv man varit som trott att man stått där uppe på toppen men nu blickar framåt på de som varit i branchen 4-5 gånger längre än en själv och passerat dalen och kommit tillbaka upp. Man inser också att det kräver hårt arbete att ta sig tillbaka upp.

Själv känner jag ofta att dessto mer literatur och artiklar jag läser, dessto mindre känns det som om man kan. För varje artikel som berör ett ämne som jag sedan tidigare är bekant med kanske jag lär mig en ny sak, men får insikt att det finns tio andra som jag inte kan. Denna inställning är såklart ganska destruktiv och knappast bättre än den naiva "jag kan allt" inställningen.

Men är detta verkligen något problem? Egentligen inte, förrutom när man ska försöka bedöma kompetensen hos någon man t.ex. eventuellt ska anställa eller arbeta tillsammans med. Var man befinner sig på U:et är inte alls direkt korrelerat till ålder eller erfarenhet i tid utan snarare hur mycket man har utmanats i det aktuella ämnet. Det är förstås kritiskt att kunna ställa rätt frågor för att kunna bilda en uppfattning var personen i fråga befinner sig i de olika områden hen påstår sig behärska. LinkedIn har insett värdet i att kunna bedömma olika erfarenheter hos personer i ens nätverk och branch och har introducerat möjligheten att "endorsa" eller rekommendera skills. De har gjort det otroligt smart och enkelt för att snabbt kunna bygga upp en kritisk massa som använder sig av denna funktionalitet. Enkelheten är kanske också deras egen fallgrop. Jag har t.ex. blivit "endorsad" av gamla kollegor för skills som jag skaffat mig efter att jag arbetat med dem, i vissa fall till och med efter att jag överhuvudtaget träffat dem. Vad är en sådan rekommendation egentligen värd? Kan det vara så att personen som rekommenderar befinner sig längst upp till vänster på U:et? Eller använder man "Endorse" knappen i syfte att bara vara vänlig och på ett diskret sätt säger "Endorse me"?

Fångens dilemma

En person jag följer på Google+ hade postat detta klipp och kände att jag var tvungen att dela med mig av det här. Finalen på detta tävlingsprogram är ett klassiskt exempel inom spelteori som kallas "fångens dilemma". Det intressanta är dock hur deltagaren till höger lyckas vända problemet så att motståndaren får en win-win situation. Vad han till höger än gör får han till vänster hälften pengarna om han väljer split ... så länge han kan lita på sin motståndare.

Data kommer inte från en svart låda

Inte allt för länge sedan satt jag med i ett möte där man diskuterade olika lösningar för både DW och BI. Det var en del av ett stort DW/BI projekt som skulle innebära stora förändringar för hela organisationen. Projektet hade fortlöpt under ganska lång period innan detta möte och det var många personer inblandade. De allra flesta hade deltagit i ett antal workshops både internt och externt med leverantörer och konsulter för att arbeta fram lösningen. Mitt i detta möte ställer helt plötsligt ekonomichefen frågan: "Alltså en databas, vad är det för någonting egentligen? Är det ett program? En burk? Eller vad?". Svaret på frågan som han fick från leverantören var någonting i stil med "Man lagrar data i en databas och det kan både vara mjukvara och hårdvara". Då kände man verkligen klyftan mellan leverantören, IT-avdelningen och verksamheten. Jag förväntar mig verkligen inte att en ekonomichef skall förstå sig på underliggande teknologier i databaser, men tycker att det är ett misslyckande om hela företagets DW/BI lösning uppfattas som ett stort svart magisk hål som spottar ur sig rapporter och KPIer. Om varken IT eller leverantörer kan göra ett bättre jobb i att förmedla vad det är som leverar allt data ut till slutanvändaren, vem ska då kunna göra det?

Vi föreställer oss att jag har en receptsamling på 1000 recept i en låda. Vem som helst kan komma och fråga mig om recept och mitt jobb är att kunna ta fram rätt recept. De första frågorna som ställs är i stil med "Kan du ge mig receptet på kladdkaka?". Ganska snabbt inser jag att det vore nog klokt att sortera recepten i bokstavsordning, på så sätt kan jag mycket fortare hitta rätt recept.

Sen börjar frågorna förändras "Kan du ge mig alla recept som innehåller nötter?". Hur ska jag lösa dessa frågor på ett effektivt sätt? Alla recept innehåller flera ingredienser så det går inte att sortera på något vettigt sätt. Tre alternativ skulle kunna vara:

1. Jag skaffar fler lådor, en låda per ingrediens. Sedan tar jag kopior av recepten och lägger en kopia i varje låda för varje ingrediens varje recept innehåller.
2. Jag köper ett gäng Post-it index och färgkodar alla recept med olika färger beroende på vilka ingredienser de innehåller.
3. Jag tar hjälp av fler personer.

Alternativ ett blir en grymt effektiv lösning. Ifall någon vill ha recept med nötter så tar jag bara alla recept i nötlådan. De går nästan inte att komma på en lösning som skulle gå snabbare. Nackdelarna är dock många och växer på sikt. Ju fler recept jag samlar på mig, dessto fler ingredienser kommer det att finnas och dessto fler lådor måste jag förvara någonstans. Potentiellt köpa nya hyllor. För varje nytt recept måste jag lägga tid på att kopiera receptet och sortera in det i rätt lådor. Ifall jag har skrivit fel någonstans, måste jag leta upp alla kopior och ändra på samtliga. Ifall jag missar att ändra på en av kopiorna kommer jag att ha olika recept för samma sak. Sen kommer det stora problemet. Frågor angående olika kombinationer börja ställas, "Kan du ge mig alla recept som innehåller nötter och grädde?". Shit, ska jag ha lådor och kopior för alla olika kombinationer av ingredienser!!! Den tekniska motsvarigheten till detta är att skapa silos (kuber, in-memory, materialiserade vyer, etc.) för att få prestanda.

Alternativ två är inte lika effektivt. För att hitta alla nötrecept måste jag plocka fram t.ex. alla blåa recept, men det går betydligt fortare än att läsa igenom alla recept och leta efter nötter. Fördelen är dock att jag har fortfarande bara en kopia av receptet. Det går lite fortare att klistra på mina Post-it index lappar än att göra kopior och sortera dem. Jag kan på ett lättare sätt hantera kombinationer då recept med nötter och grädde skulle innebära t.ex. blåa och röda recpet. Det blir dock lite jobbigare ifall jag bestämmer mig för att grädde inte längre ska vara röd utan gul. Då måste jag gå igenom alla röda och byta till gult index. Det börjar bli ännu jobbigare att få plats med alla möjliga färgkodningar för alla möjliga kombinationer rent fysiskt på receptet. Den tekniska motsvarigheten till detta alternativ är att försöka ha en generell modell i sitt DW och arbeta med inbyggd funktionalitet (index, hashmaps, projektioner, etc.) för att snabba upp sökningarna och hitta rätt.

Alternativ tre kan bli riktigt effektivt. Dessto fler personer som hjälper till dessto fortare går det att hitta rätt recept. Det är lätt att hantera ökade antal recept då det bara är att ta hjälp av fler. Spontant känns det som en väldigt dyr lösning att betala löner till alla som hjälper till, men när det kommer till de tekniska lösningarna finns det både dyra och billiga alternativ. Den tekniska motsvarigheten är att parallellisera och/eller distribuera beräkningarna (MPP, Hadoop, etc.) för att snabba upp sökningarna.

Exemplet är så klart väldigt förenklat, men ett sätt att illustrera att en databas är ingen svart låda. Man kan lagra allt data i en viss ordning på hårddisken och ha olika sätt för att sedan hitta delmängder baserat på vissa villkor men mycket mer än så kan man inte göra. Rent krasst kan man säga att blir lösningen snabb på en sak, blir den långsam på en annan. Poängen med detta exempel är att jag anser att det är viktigt att alla inblandade i ett DW/BI projekt bör ha en insikt på denna nivån. Alla måste förstå att oavsett vad någon säger eller lovar så finns det ingen silver bullet. Alla lösningar har begränsningar och det gäller att välja en lösning vars begränsningar får så liten inverkan som möjligt.

Trail and Error

Rätt så ofta springer man på personer som är rätt så väl bevandrade inom BI och DW och som har läst en del om predektiv analys och data mining. De har ganska bra koll på begreppen och uttrycker sig i ord som om de vet precis vad det handlar om. Om de aldrig har suttit med ett riktigt data mining problem saknar de dock insikten i vad som faktiskt krävs för att nå framgång i ett data mining projekt.

Först och främst kommer arbetet med att förbereda data för uppgiften som skall lösas. Har man bara läst lite data mining literatur så har man ganska snabbt insett att det inte hjälper mycket att ha en gedigen ETL process som modellerat datat i sitt DW i en stjärnmodell eller liknande. Mer än halva data mining processen består ändå i att förbereda data för att kunna bygga modeller. Här kommer första insikten som är svår att få utan att ha praktisk erfarenhet. Det är otroligt svårt att veta i förväg vilka variabler som är bra prediktorer för sin målvariabel. Ofta "vet" man det i förväg, men när man börjar ställa motfrågor visar sig dock snabbt motsatsen.

Gällande målvariabeln kan det vara lika svårt att veta hur den ska representeras. Låt säga att uppgiften är att ta fram en modell som predikterar vinsten. Det är lätt att tro att målvariabeln är "given" i uppgiften, men det kan visa sig att det är lättare att prediktera logaritmen av vinsten, eller vinsten i förhållande till omsättningen, eller att transformera om vinsten till en nominell variabel. Ett annat exempel kan vara att använda en overlay variabel om man t.ex. vet att man kommer att öka utbudet med 20% nästa år. Att använda en stegfunktion som går från 1 till 1.2 för att få in den informationen i modellen, tillför ofta inte mycket. Ofta är det bättre att t.ex. multiplicera den med någon annan variabel för att uppnå önskat resultat.

Slutsatsen jag vill komma till är att den största insikten är nog att det enda sättet att hitta en bra representation är att testa sig fram, och det tar tid. Det är lätt att framställa data mining som en svart låda där man slänger in lite siffror och får ut svar, men det är inte konstigare än trail-and-error i många fall. Med lite erfarenhet hittar man så klart rätt fortare, men det är fortfarande en stor del av mining processen.

Maskininlärnings- och data mining kurs

Det är svårt att hitta utbildningar inom data mining om man vill utbilda sig parallellt med sitt arbete. De flesta utbildningar inom data mining är vanliga universitetskurser som löper under en hel termin med föreläsningar dagtid och är för de allra flesta väldigt svåra att närvara på. Köpenhamns universitet bryter dock den trenden till hösten då de kommer att erbjuda en 5-dagars intensiv kurs i tillämpning av maskininlärning, mönsteringenkänning och data mining. Kursen kommer kräver förkunskaper i C++ då de kommer att använda Shark för alla praktiska övningar. Kursen verkar förvisso vara en introduktionskurs till området, men med detta upplägg kan man i alla fall locka alla som arbetar 9 till 5 och vill lära sig mer om data mining. Läs mer på kursens hemsida.

Weka 3.7.6

Förra veckan släpptes Weka 3.7.6. Det är inga stora förändringar utan mest bugg fixar och förbättringar av befintliga algoritmer och funktioner. Mark Hall skrev ett inlägg på Pentaho's wiki som listar nyheterna.

DFS Beslutsstöd

Dataföreningen har startat ett nätverk inom beslutsstöd och affärsanalys med syftet att

...lyfta fram bra användning av alla de möjligheter som beslutsstöd ger. De flesta har stött på områden som BI, datalager, integrerad verksamhetsuppföljning, data mining, etc. Tillsammans skapar vi bättre förståelse och användning av detta. T.ex. att inte bara jaga kostnader utan också lyfta verksamheters intäktssida. Självklart vill vi också följa metod- och teknikutvecklingen, t.ex.arkitektur och begreppssamordning.

Det är uppstartsmöte den 24 maj där man ska diskutera mål och arbetssätt för nätverket. Det blir avgörande för vilken inriktning nätverket får, men det finns en uttryckt önskan om fokus på verksamhetsaspekterna och mindre av det tekniska. Läs mer på nätverkets hemsida.