De alternativ som fanns var stemming utan ordlista eller med ordlista, samt lemmatiza-tion. De tester som utf¨orts visade ganska snart att stemming utan ordlista inte fungerar eftersom den plockar ut s˚a pass m˚anga felaktiga ordstammar. Hade denna anv¨ants ha-de anv¨andaren kunnat f˚a v¨aldigt konstiga tr¨affar och framf¨orallt f˚att tr¨affar p˚a andra omr˚aden ¨an det han eller hon var ute efter (se appendix F).
Lemmatization d¨aremot ¨ar enligt k¨allor alldeles f¨or ber¨akningstungt j¨amf¨ort med stemming, detta enligt doktor Martin Hassel vid spr˚akvetenskapliga institutionen p˚a KTH, se appendix D. De tester som utf¨orts av forskare inom lingvistik visar att stem-ming med ordlista som genomg˚att morfologisk analys ¨ar tillr¨ackligt bra f¨or s¨okningar efter artiklar[36]. Artiklar och annonser ¨ar liknande i den meningen att de b˚ada i stort sett enbart best˚ar av text som kan vara skriven med talspr˚ak och dessutom mycket fel-stavningar. D¨arf¨or faller valet p˚a stemming med ordlista, eftersom ordlistan kan byggas upp manuellt och kontrollerat. Dessutom ¨ar denna variant som sagt betydligt mindre ber¨akningstung vilket ¨ar ett stort krav d˚a antalet annonser ¨ar v¨aldigt m˚anga, trots att den kan ge fler fel ¨an lemmatization s˚a v¨ager effektiviteten n˚agot tyngre i det h¨ar fallet. Hunspell som kontrollerar stavningen kan ¨aven utf¨ora stemming. F¨or att f¨ortydliga fanns det tv˚a val med ordlista, stemming med ordlista som det ej utf¨orts morfologisk analys p˚a och stemming med ordlista d¨ar det har utf¨orts morfologisk analys. De ¨ar ungef¨ar lika snabba men den variant som anv¨ander morfologisk analys ¨ar n˚agot mer precis och
ger f¨arre felaktiga ordstammar. Denna metod ¨ar allts˚a b¨attre och eftersom skillnaden i hastighet dem emellan ¨ar s˚a pass l˚ag finns det ingen anledning till att inte v¨alja den metod som ger l¨agre antal fel.
F¨or att stemming ska fungera s˚a bra som m¨ojligt m˚aste konstanta uppdateringar av ordlistan ske, tyv¨arr kommer m˚anga av dessa att beh¨ova ske manuellt, d˚a det kan vara sv˚art att t¨acka in precis alla fall. ¨Aven den svenska ordlistan uppdateras idag manuellt eftersom det hela tiden l¨aggs till nya ord i det svenska spr˚aket.
Stemming ¨ar n˚agot som redan ing˚ar i dagens s¨okmotor p˚a www.blocket.se och ¨aven i de flesta moderna s¨okmotorer p˚a marknaden. Med denna rapport tillkommer dock en f¨orb¨attring av den redan existerande varianten av stemming med Hunspell.
Det stora problemet som fanns tidigare var att ord kunde sammanfl¨atas och vissa ord kunde kortas ner f¨or l˚angt s˚a att de inte l¨angre hade n˚agon betydelse, detta l¨ostes i och med att ordlistan fick en konstant uppdatering. Nackdelen ¨ar att det tar lite tid att uppdatera ordlistan och det kan vara sv˚art att se vilka ord som kortas ner felaktigt, men n¨ar uppdateringarna g¨ors kommer ocks˚a f¨orb¨attringen vilket g¨or att tiden som l¨aggs ner p˚a uppdatering tas igen i effektivitet.
Den h¨ar f¨orb¨attringen av s¨okmotorn ¨ar inget som anv¨andaren kommer att se men det g¨or att tr¨affarna han eller hon f˚ar blir fler. Stemming g¨or allts˚a s¨okmotorn f¨orb¨attrad i fr˚aga om att presentera fler relevanta resultat f¨or anv¨andaren, vilket i sin tur g¨or att fler annonser kommer synas och fler personer f˚ar m¨ojlighet att s¨alja sina begagnade prylar.
3.4 Synonymer
Synonymerna anv¨ands f¨or att l˚ata anv¨andaren f˚a fler tr¨affar. Det kommer framf¨orallt att anv¨andas f¨or produkter som kan ben¨amnas p˚a flera olika s¨att. T.ex. ”playstation 3”2 och ”ps3”. Detta kommer att anv¨andas varje g˚ang en s¨okning g¨ors.
N¨ar anv¨andaren har matat in sin s¨okterm skickas den termen till synonymbehand-laren. H¨ar kommer s¨oktermen att j¨amf¨oras mot synonymordlistan, d¨arefter plockas dess synonymer ut och anv¨ands i den totala s¨okningen. Den stora nackdelen med implementa-tionen ¨ar att synonymordlistan m˚aste byggas upp fr˚an noll. Den kommer allts˚a att byggas upp manuellt och varje ord som finns i ordlistan har d˚a kontrollerats av en utvecklare. Tyv¨arr blir detta n˚agot omst¨andigt men samtidigt uppn˚as en v¨aldig kontroll p˚a vilka ord som faktiskt ska ing˚a och f¨orhoppningsvis kommer det att minska antalet fel.
Synonymimplementationen leder till en breddad s¨okning d¨ar varje synonym och den
ursprungliga s¨oktermen kommer anv¨andas f¨or att g¨ora f¨orfr˚agningar mot databasen. I f¨orl¨angningen kan det h¨ar g¨ora att s¨okmotorn blir n˚agot mer belastad men det ska inte p˚averka den s˚a mycket att det inte ¨ar m¨ojligt att genomf¨ora, detta har tagits i beaktande av B Locket AB innan valet f¨oll p˚a att det faktiskt skulle implementeras.
3.5 Autocomplete
Eftersom s¨okmotorn som anv¨ands idag inte klarar av de delar som beh¨ovs f¨or att utf¨ora autocomplete p˚a det s¨att som B Locket AB vill, byggdes en egen utefter en Open-source-s¨okmotor kallad Lucene. Denna s¨okmotor ¨ar anpassad f¨or just texts¨okning i stora sy-stem och med stora datam¨angder. F¨or att kunna utnyttja denna s¨okmotor p˚a b¨asta s¨att anv¨ands en s¨okserver kallad Solr[29], Solr ¨ar anpassad till Lucene och har m˚anga redan f¨ardigbyggda komponenter f¨or att b˚ade indexera och s¨oka med hj¨alp av Lucene. S¨attet som autocomplete l¨osts p˚a ¨ar att s¨okmotorn enbart indexerar alla annonsrubriker.
Figur 3.3: Skillnaden mellan att spara f¨alt och inte vid uppslagning mot index. P˚a s˚a s¨att minskar datam¨angden, vilket ger en snabbare funktionalitet och effektivare f¨orslagshantering, men f¨orslagen blir fortfarande relevanta. F¨or att ytterligare ¨oka effek-tiviteten vid extrahering av data sparas f¨altet (ID ¨ar f¨altet som sparas och detta f¨alt ¨ar
unikt f¨or alla entiteter)som anv¨ands vid uppslagning i index, skillnaden mot att inte spa-ra datan kan ses i figur 3.3. Beroende p˚a hur mycket data som inneh˚aller den efters¨okta termen desto l¨angre tid tar det att f˚a f¨orslagen.
Varje annonsrubrik best˚ar av max 40 tecken vilket specificerats av B Locket AB som d¨armed vill begr¨ansa anv¨andarna f¨or att rubriken ska vara s˚a kort och koncis som m¨ojligt. Annonsrubriken ska helt enkelt bara inneh˚alla n¨odv¨andig information om produkten. Vid indexeringstillf¨allet ses varje ord i varje rubrik som ett N-gram, vilket inneb¨ar att varje rubrik indexeras ord f¨or ord. Detta ger m˚anga fler platser i indexet, vilket kan g¨ora s¨okningen seg, men detta l¨oses genom n˚agot som liknar memcache. S˚a stora delar som m¨ojligt av datan sparas i RAM-minnet, vilket g¨or att den ¨ar mer l¨attillg¨anglig och d¨arf¨or g˚ar snabbare att sl˚a upp. Ett exempel p˚a hur denna uppdelning fungerar ¨ar rubriken ”volvo v40 2,0” som efter indexering ser ut enligt f¨oljande:
volvo volvo v40 volvo v40 2,0 v40 v40 2,0
2,0
Denna mening f˚ar allts˚a 6 platser i indexet. Anledningen till att rubrikerna delas upp p˚a detta s¨att ¨ar f¨or att anv¨andaren ska f˚a f¨orslag p˚a just det ord han eller hon b¨orjar skriva och inte en hel rubrik p˚a en g˚ang.
N¨ar anv¨andaren b¨orjar mata in sin s¨okterm kommer ett anrop ske mot sj¨alva autocomplete-delen. H¨ar kontrolleras sedan vilka ord som kan passa ihop med det anv¨andaren redan har skrivit.
Varje annonsrubrik har indexerats enligt tidigare f¨orklarat s¨att, detta kallas inverted index3[11, 12].
De bokst¨aver anv¨andaren slagit in matchas mot alla rubriker, d¨armed h¨amtas de rubri-ker ut som inneh˚aller den textstr¨ang anv¨andaren matat in. N¨asta steg ¨ar att anv¨andaren f˚ar upp en f¨orslagslista med ett specifikt antal ord och ordpar som inneh˚aller just den str¨ang han eller hon matat in, dessa f¨orslag ¨ar allts˚a delar av annonsrubriker som in-neh˚aller den str¨ang anv¨andaren matat in. Hur m˚anga ord och ordpar som ska visas i denna f¨orslagslista kan enkelt st¨allas in genom att ¨andra p˚a en variabel.
F¨ordelen med denna teknik ¨ar att anv¨andaren snabbare kommer fram till vad han eller hon vill s¨oka efter och eftersom f¨orslagen ¨ar rubriker p˚a annonser kommer tr¨affarna att vara mer exakta. Dessutom kommer anv¨andaren att f˚a n˚agra fler alternativ om listan presenteras p˚a detta s¨att, vilket i sin tur g¨or att fler annonser kommer f˚a uppm¨arksamhet. B Locket AB str¨avar n¨amligen efter att alla annonser ska f˚a lika mycket utrymme eftersom
alla betalar samma pris inom samma kategori, enligt f¨oretaget sj¨alvt str¨avar de efter att uppn˚a n˚agot som liknar allemansr¨atten[2].
Det stora problemet med denna implementation f¨orutom hur sj¨alva f¨orslagslistan skul-le skapas var att f˚a designen att se s˚a enkel ut som m¨ojligt p˚a www.blocket.se. Just att det ska se enkelt ut ¨ar n˚agot som B Locket AB verkligen st˚ar f¨or och jobbar h˚art f¨or. Ett f¨orslag p˚a hur autocomplete kan se ut p˚a www.blocket.se kan ses i figur 3.4.
Figur 3.4: Ett exempel p˚a hur f¨orslagslistan kan komma att presenteras f¨or anv¨andaren p˚a www.blocket.se.
Kapitel 4
Slutsats, diskussion och framtida
arbete
Vilka f¨orb¨attringar har skett och vad kan g¨oras f¨or att f¨orb¨attra dem ytterligare?
4.1 Slutsats och Diskussion
De krav som sattes p˚a prototypen av B Locket AB i projektets uppstart har m¨otts till viss del. Alla delar som unders¨okts och som B Locket AB ville ha implementerade hann inte f˚a tillr¨ackligt bra resultat f¨or en implementation. Prototypen ¨ar inte heller klar f¨or att g˚a i produktion d˚a den m˚aste genomg˚a betydligt mer tester och framf¨orallt testas ur prestationssynpunkt n¨ar flera anv¨andare utnyttjar den samtidigt. Det var dock inte meningen fr˚an b¨orjan att den skulle bli klar f¨or produktion s˚a detta ¨ar inget misslyckande. N˚agra delar, som var mindre viktiga, ¨ar inte implementerade eftersom det bara in-nebar enklare modifieringar av det redan fungerande systemet. Dessa ¨ar stemming och synonyms¨okning. Stemming (se sida 17) finns som sagt sedan tidigare i B Locket AB:s s¨okmotor och d¨arf¨or ans˚ags det on¨odigt att implementera denna funktionalitet i prototy-pen. Stemming fungerar tillfredsst¨allande redan nu men kan f¨orb¨attras avsev¨art genom enkla uppdateringar i ordlistan, tyv¨arr manuella s˚adana. Inte heller synonyms¨okningen implementerades d˚a tidsramen inte r¨ackte till, dessutom ¨ar detta n˚agot som inte ¨ar helt om¨ojligt att implementera under en kortare period i det redan fungerande systemet. Sy-nonymdelen borde kunna g¨oras p˚a egen hand eftersom den i grunden enbart handlar om att koppla ord till andra ord. Den fr¨amsta anledningen till att de h¨ar b˚ada delarna inte implementerades var att de inte var lika viktiga f¨or B Locket AB. De delar som mest fokus lades p˚a var d¨arf¨or r¨attstavningen och autocomplete, efter ¨onskem˚al fr˚an B Locket
AB. Med hj¨alp av Lucene:s API och dess redan fungerande komponenter var det relativt
Figur 4.1: P˚a det h¨ar s¨attet skulle alla delar kopplas samman i slutprototypen om lite mer tid funnits att tillg˚a.
enkelt att implementera autocomplete i prototypen. Det som skapade problem var an-passningen till www.blocket.se. D˚a vilken ordlista som helst inte kunde anv¨andas var en egen tvungen att skapas, detta gjordes av alla annonsrubriker. Om en vanlig ordlis-ta hade anv¨ants hade det inte haft n˚agon som helst relevans till www.blocket.se och
anv¨andaren hade f˚att upp helt meningsl¨osa f¨orslag. Annonsrubriker anv¨andes ist¨allet f¨or hela annonser eftersom en s˚a liten men fortfarande relevant datam¨angd skulle anv¨andas. P˚a samma s¨att skapas ordlistan f¨or r¨attstavning, tyv¨arr ¨ar inte den slutgiltiga l¨osningen f¨or r¨attstavning implementerad i prototypen eftersom denna kom till f¨orst i slutet av projektet. Versionen av r¨attstavning som ¨ar implementerad i prototypen ¨ar inte helt felfri d˚a den ibland kan ge konstiga f¨orslag, men sj¨alva grundid´en finns d¨ar och den kommer vidareutvecklas av B Locket AB under detta ˚ar. De st¨orsta delarna som tar hand om autocomplete i prototypen kan ses i bilaga A och bilaga B.
Det stora problemet inom r¨attstavning ¨ar framf¨orallt s¨arskrivning. Hunspell borde l¨osa detta n¨ar det implementeras, men det ¨ar v¨aldigt viktigt att ordlistan som skapas uppdateras frekvent eftersom annonser kommer och g˚ar ofta. Hunspell l¨oste detta problem n¨ar det utf¨ordes tester p˚a sm˚a datam¨angder, risken ¨ar dock att den blir f¨or l˚angsam n¨ar datam¨angden ¨okar. F¨or att se ungef¨ar hur det fungerar idag kan bilaga C vara intressant. Ett f¨orslag ¨ar att ordlistan skapas samtidigt som indexeringen sker, mest f¨or att mins-ka antalet tillf¨allen som s˚a tunga operationer g¨ors. Slutsatsen som kan dras av hela r¨attstavningsimplementationen ¨ar att det egentligen inte ¨ar en r¨attstavare. Det ¨ar mer korrekt sagt, en f¨orslagsgivare som ger f¨orslag p˚a vad det ¨ar anv¨andaren kan ha menat som s¨okord, d¨ar f¨orslaget ger fler tr¨affar.
Om Hunspell blir f¨or kr¨avande ¨ar v¨aldigt sv˚art att svara p˚a i dagsl¨aget. Det h¨ar beror p˚a att en modifikation har gjorts av sj¨alva biblioteket d¨ar det blir en slags f¨orslagsgivare ist¨allet f¨or en r¨attstavare som det ¨ar i grunden. Det kan dock inte fattas ett slutgiltigt beslut om det ¨ar f¨or kr¨avande eller ej f¨orr¨an det faktiskt testats fullt ut, vilket tyv¨arr inte tidsramen till¨at.
P˚a relativt sm˚a datam¨angder (ca 100 000 ord) klarar Hunspell av att leverera ett f¨orslag inom en tillfredsst¨allande tid, n¨amligen under 0,5 sekunder.
Autocomplete d¨aremot var n˚agot som den nuvarande s¨okmotorn inte hade klarat av att implementera enligt B Locket AB:s krav. Detta eftersom den inte klarar av att indexera s˚a att ord kopplas till ord, anledningen till att den inte klarar detta ¨ar f¨or att den enbart beh¨ovde kunna s¨oka i stora textm¨angder tidigare. Lucene d¨aremot har denna funktionalitet och d¨arf¨or anv¨andes denna.
Lucene ¨ar v¨aldigt enkelt och har ett v¨aldigt tydligt API1, vilket gjorde att det gick betydligt snabbare att implementera autocomplete-funktionaliteten ¨an om en s¨okmotor skulle byggts fr˚an grunden. Autocomplete fungerar s˚a pass bra att den skulle kunna
1Application Programming Interface, en regelupps¨attning f¨or hur en programvara kan kommunicera med annan.
implementeras n¨astan p˚a en g˚ang, anledningen till detta ¨ar f¨or att den testats med www.blocket.se:s alla annonser redan och ger d˚a svar inom 0-100ms, vilket ¨ar en till-fredsst¨allande tid enligt B Locket AB.