Lingvistik och användbarhet i sökmotorer

(1)

UPTEC IT 10 004

Examensarbete 30 hp

Januari 2010

Lingvistik och användbarhet

i sökmotorer

(2)

(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Linguistics and Usability of Search Engines

Sven Vidén

This is a master thesis from Uppsala University in collaboration with B Locket AB (more known as www.blocket.se). B Locket AB is a large ad-company from Sweden, located in Stockholm.

Search engines on the market today are becoming more and more complex. When they were first introduced, they only had one function and that was to produce search results containing the string that the user had typed. Today, users want it to be able to spellcheck, produce more results and sort search results on specific fields as well. Preferably, all these features should not affect the performance as a whole. The reason to why these demands have come up is that users are getting more and more used to internet services as a whole and they want everything to be as easy as possible.

The user ability has become a substantially more important area in the computer industry and this needs to be taken into account when it comes to B Locket AB and its search engine. This is one of the reasons to why this report has been made, another one is that B Locket AB:s search engine is a bit outdated and lacks some of the new features.

This report is a further development and a small evaluation of a search engine at B Locket AB. The search engine was evaluated in cooperation with B Locket AB:s head-developer and the person responsible for new features on the site. Further development was only done in consultation with both of them.

The evaluation showed flaws in B Locket AB:s search engine. These flaws were the reports key issues when starting the development of an improved model. The key issues were autocomplete, spelling and stemming. The final result was a prototype with these features implemented.

Examinator: Anders Jansson

(4)

(5)

Sammanfattning

Detta ¨ar ett examensarbete f¨or Uppsala Univestitet i samarbete med B Locket AB1_{. B}

Locket AB är ett stort annonsföretag i Sverige. De tillhandah˚aller en tjänst där användare lägger in annonser och kan ta kontakt med andra annonsörer för att p˚a s˚a sätt köpa och sälja begagnade saker.

Sökmotorer är n˚agot som f˚ar högre och högre krav p˚a sig fr˚an användarna idag. Tidi-gare var kravet enbart ett sökfält och resultat som innehöll den eftersökta söktermen, idag vill användaren att sökmotorn ska hjälpa denna att söka, stava och sortera sökresultaten. Dessutom ska allt detta fortfarande ske precis lika snabbt som tidigare och det f˚ar inte p˚averka användaren negativt.

Anledningen till alla dessa krav är att användarvänligheten har blivit en allt större aspekt inom IT-branschen. I stort sett all ny mjukvara har genomg˚att en ganska stor pro-cess där en kontroll av användbarheten hos just den produkten gjorts. Detta kan göras p˚a olika sätt, t.ex genom att l˚ata vanliga användare testa produkten och därefter säga vad de tyckte eller bara helt enkelt att utvecklarna g˚ar igenom och testar användarvänligheten. Detta examensarbete är en vidareutveckling och en mindre utvärdering av en sökmotor p˚a B Locket AB. Sökmotorn utvärderades tillsammans med B Locket AB:s chefsutveck-lare och publiceringsansvarig. Vidareutvecklingen skedde endast i samr˚ad med dessa.

Resultatet av utvärderingen visade brister hos B Locket AB:s nuvarande sökmotor. Dessa brister blev fokus-fr˚agorna i vidareutvecklingen av den nya sökmotorn. De tydli-gaste bristerna var att sökmotorn inte klarade av rättstavning, autocomplete och att den hade problem med stemming2. I slutet gjordes därför en prototyp med dessa delar och andra förbättringar av den redan existerande sökmotorn implementerade.

1_{Mer k¨}_{ant som www.blocket.se} 2

(6)

(7)

Inneh˚

all

1 Introduktion och bakgrund 4

1.1 Problembeskrivning . . . 5

1.2 Syfte och fr˚agest¨allningar . . . 6

(8)

2.7.4 Utv¨ardering . . . 24

2.7.5 Gr¨anssnitt . . . 24

2.7.6 Krav p˚a s¨okmotorn . . . 24

3 Resultat och utv¨ardering 25 3.1 R¨attstavning . . . 25

3.2 S¨arskrivning . . . 28

3.3 Stemming och Lemmatization . . . 28

3.4 Synonymer . . . 29

3.5 Autocomplete . . . 30

4 Slutsats, diskussion och framtida arbete 33 4.1 Slutsats och Diskussion . . . 33

4.2 Framtida arbete . . . 36 Litteraturf¨orteckning 37 Appendix 41 A Autos.java 41 B Auto.java 44 C main.c 47

D Mailkonversation med Martin Hassel p˚a KTH:s spr˚akvetenskapliga

in-stitution 54

E Resultat av rättstavningsjämförelse 56

(9)

Kapitel 1

Introduktion och bakgrund

B Locket AB är ett företag inom annonsbranschen. Affärsidén g˚ar ut p˚a att sälja annons-platser till privatpersoner och företag p˚a nätet. All försäljning sker över nätet genom dessa annonser och B Locket AB:s kunder använder p˚a s˚a vis enbart en webtjänst. Kunderna sköter allts˚a själva kontakten mellan annonsör och köpare.

Tjänsten som B Locket AB tillhandah˚aller fungerar genom att användaren matar in sökord och f˚ar d˚a upp annonser som inneh˚aller dessa sökord. Resultatet är annonser inneh˚allande sökordet användaren är intresserad av. Annonserna presenteras i form av bilder och text, samt annonsörens kontaktinformation. Denna tjänst finns inte bara i Sverige utan i mer än tio länder, där marknadsför sig B Locket AB p˚a ungefär samma sätt som i Sverige men med andra företagsnamn.

För att hitta de annonser användaren är intresserad av finns en sökmotor. Denna ska hjälpa användaren att hitta information s˚a fort som möjligt, men även precis den information som användaren faktiskt är ute efter. Det vill säga, användaren ska f˚a resultat som är s˚a precisa som möjligt utefter hans sökning. Detta helst utan att behöva vara en expert p˚a sökning via sökmotorer.

Sökmotorer har ända sedan de uppfanns använts för att hitta information ˚at användaren, n˚agot som har utvecklats mer och mer, speciellt under de senaste ˚aren. Med andra ord s˚a blir sökmotorerna mer och mer användarvänliga, men samtidigt mer avancerade. De har blivit snabbare efter hand som nya sökalgoritmer har uppfunnits och mer användarvänliga efter hand som MDI1 har blivit viktigare och viktigare inom IT-branschen.

Den sökmotor som används p˚a www.blocket.se idag är dock n˚agot för˚aldrad och kan definitivt förändras till det bättre. I dagsläget klarar sökmotorn inte av att hjälpa

(10)

användaren särskilt mycket, vilket i längden gör att användaren inte hittar de annonser han eller hon letar efter, ˚atminstone inte lika fort och enkelt. Detta är n˚agot som skulle kunna p˚averka B Locket AB:s framg˚ang.

I dagsläget när n˚agon nämner ordet ”sökmotor” tänker de flesta p˚a www.google.com2_.

Denna sökmotor har blivit världsledande under de senaste ˚aren, till stor del p˚a grund av dess enorma enkelhet och användarvänliga gränssnitt. Oavsett vad användaren söker p˚a försöker den peka denne i rätt riktning. Det här gör att oavsett hur d˚alig användaren är p˚a att använda sökmotorn s˚a kommer träffar fortfarande att visas inom det omr˚ade som sökningen gjorts p˚a. Det är dessa funktionaliteter som gör dagens sökmotorer bra och användarvänliga. M˚anga företag inklusive B Locket AB strävar efter att uppn˚a liknande funktionalitet i sina sökmotorer.

www.blocket.se har haft ett särskilt tänk med sin design ända sedan starten 1996. Detta tänk är att allt ska vara s˚a enkelt som möjligt och det ska inte finnas n˚agra speciella finesser som kan p˚averka användaren negativt. M˚alet med detta är att de ska kunna n˚a ut till alla, gamla som unga, varför denna rapport speglats av detta tänk p˚a enkelhet. Hur kan användarna f˚a s˚a mycket hjälp som möjligt utan att p˚averka dem negativt med nya häftiga funktioner?

1.1 Problembeskrivning

Som sagts tidigare s˚a är www.blocket.se:s sökmotor n˚agot för˚aldrad och klarar inte av en del användarvänliga krav som företaget har satt upp. De krav som B Locket AB vill att sökmotorn ska klara av i framtiden är:

• Rättstavning och särskrivning • Synonymsökning

• En förbättrad form av ordstamssökning • Autocomplete

Om användaren f˚ar mycket hjälp kommer annonserna bli enklare att hitta och an-nonsörerna kommer att f˚a fler intresseanmälningar p˚a sina annonser. Det gör att upp-levelsen p˚a www.blocket.se blir bättre och användaren slipper frustrationen över att inte hitta det som eftersöks. Tyvärr finns väldigt lite information om dessa omr˚aden i företaget. Därför ska de undersökas och analyseras för att till slut ge en klar bild över vad som kan anses vara användarvänligt i B Locket AB:s fall.

2

(11)

1.2 Syfte och fr˚

agest¨

allningar

Syftet med detta projekt var att ta reda p˚a vilka delar som behövs för att göra B Locket AB:s sökmotor mer användarvänlig och effektiv. Dessutom ska en prototyp visas upp med de funktionaliteter som efterfr˚agats. Denna prototyp ska vara väldigt enkel d˚a huvudsyftet med den är att visa de nya funktionaliteterna och inte en snygg design.

Tv˚a huvudfr˚agor genomsyrade projektet. • Vad g¨or att anv¨andaren p˚averkas negativt?

• P˚a vilka sätt kan användaren f˚a hjälp genom att enbart titta p˚a sökfältet?

Användaren ska allts˚a inte behöva tänka p˚a att stava rätt eller om det finns annonser inneh˚allandes den söktermen och allts˚a känna sig säker p˚a det som matats in. Användaren ska ocks˚a kunna använda förkortningar p˚a diverse produkter som kan tänkas finnas i annonserna. Om användaren hittar fler annonser som stämmer in p˚a sökningen s˚a är ocks˚a sannolikheten större att tjänsten används mer frekvent.

Syftet med projektet var som sagt att f˚a fram en fungerande prototyp som han-terar sökfr˚agor p˚a ett användarvänligt vis med hjälp av lingvistik. Detta genom olika hjälpmedel som undersökts under arbetets g˚ang. De hjälpmedel som undersökts övervägdes noggrant d˚a de var tvungna att vara de bästa i sin kategori för att sedan kunna imple-menteras i den nya sökmototrn.

1.3 Metod

Tillsammans med handledare och publiceringsanvsarig p˚a B Locket AB har en lista p˚a specifika önskem˚al fr˚an användare och anställda p˚a B Locket AB tagits fram. Denna lista används för att undersöka de olika delar som pekats ut som bristfälliga eller som saknas helt.

Varje punkt p˚a denna lista g˚as igenom noggrant och varje ämne studeras genom att läsa vetenskapliga artiklar, söka information p˚a internet och studera litteratur inom de intressanta omr˚adena. Detta görs för att ett beslut ska kunna tas om vilken metod som bäst löser varje delproblem. När informationen insamlats och behandlats fattas ett beslut tillsammans med handledare och publiceringsansvarig.

(12)

lilla prototypen kommer de att g˚a vidare till en stor implementation in i ett helt system d¨ar alla delproblem ska finnas representerade.

Varje del i den slutgiltiga prototyputvecklingen sker enligt den agila metoden ”XP”[6]3. Detta innebär kortfattat att de problem som implementationen innebär delas upp i mind-re delar. Varje problem blir en lapp p˚a en tavla, detta problem delas sedan upp i mindre delproblem som ocks˚a är representerade p˚a lappar. När alla delproblem är lösta ska allts˚a huvudproblemet var löst. För att detta ska fungera smidigt estimeras hur l˚ang tid varje lapp kommer att ta, angivet i mantimmar. P˚a s˚a sätt f˚as en tydligare överblick och au-tomatiskt, en deadline att följa. Om prototypen uppfyller de krav som handledaren satt upp kan lappen bockas av och arbetet kan fortsätta p˚a nästa lapp. Anledningen till att metoden användes var främst för att B Locket AB redan arbetar utefter denna. Detta gjorde att handledaren snabbt kunde se hur arbetet fortgick och kunde ge tips inom de omr˚aden där arbetet faktiskt befann sig just d˚a.

Alla bibliotek som användes i prototypen var utvecklade enligt Open-Source4 d˚a B Locket AB ville ha möjlighet att kunna modifiera s˚a mycket som möjligt efter eget tycke. Den största anledningen var dock att de inte ville köpa n˚agon färdig produkt utan utveckla större delen för egen maskin. Under tiden som arbetet med själva sökmotorn fortgick

Figur 1.1: www.blocket.se idag. F¨or mer information se www.blocket.se

3_{Extreme Programming, en arbetsmetod f¨}_{or mjukvaruutveckling.}

(13)

skrevs denna rapport. ˚Atminstone en dag i veckan för att minska arbetsbördan i slutet p˚a projektterminen. Rapporten kom sedan att presenteras del för del för ämnnesgranskaren p˚a Uppsala Universitet och för B Locket AB, detta för att säkerställa att rapporten fortfarande hade bra struktur och se till s˚a att rätt delar togs med i rapporten.

1.4 Begr¨

ansningar

(14)

Kapitel 2

Analys

Allmän information om olika delar som berörts inom denna rapport och en djupare be-skrivning av de omr˚aden som B Locket AB velat ha mer information om. En jämförelse mellan olika lösningar inom samma omr˚ade görs här för att kunna dra en slutsats om vilken som är bäst anpassad till detta problem. Det ing˚ar även en del information om vilka bibliotek som använts i utvecklandet av prototypen.

2.1 En s¨

okmotors uppbyggnad

En sökmotor[26] är ett verktyg som hjälper användaren att hitta det han eller hon söker. En webbsökmotor som detta projekt innefattar söker igenom webbsidor för att presen-tera sitt resultat. Dessa resultat kallas för träffar och sorteras vanligtvis i en lista som presenteras för användaren.

Dagens s¨okmotorer[34] arbetar i tre steg. N¨amligen: • Spindling, insamlande av data

• Indexering, strukturering av data • F¨orfr˚agning, h¨amta resultat fr˚an index

2.1.1 Spindling

(15)

blir sedan den information som sökmotorn använder sig av för att hitta det användaren ¨

ar ute efter. Efter att spindeln har samlat in dessa länkar g˚ar den igenom sin lista för att hämta hem den information som finns p˚a varje webbplats. Informationen kan vara vanlig text, HTML-taggar eller länkar m.m. Hur informationen ser ut och används beror lite p˚a vad sökmotorn används i för system. Det som beskrevs tidigare är typiskt för en webbsökmotor, t.ex. Google.

I Blockets fall däremot spindlas inte informationen in. När en användare skapar sin annons s˚a läggs informationen automatiskt in i databasen. Den data som läggs in i da-tabasen är ren text, men denna är först˚as uppdelad i olika fält, s˚asom ”Rubrik”, ”Pris” och ”Information”. Ett undantag till all text är om användarna lägger in bilder till sina annonser. Det stora steget för sökmotorn blir därför indexeringen[10].

2.1.2 Indexering

Detta steg innebär att informationen som samlats in m˚aste indexeras. Här m˚aste, p˚a ett smart sätt, datan f˚a en sorts nyckel, för att snabbare kunna hitta rätt information. Nyckeln i det här fallet motsvarar vad själva sökmotorn sedan kommer att söka p˚a, detta för att undvika sökningar p˚a hela webbplatser vilket skulle ta oerhört mycket längre tid. Indexering gör allts˚a att datamängden som ska sökas igenom blir n˚agot mindre. Den allra vanligaste metoden inom indexering är hashing[7]. Här används en hashfunktion för att indexera datamängden. Med hjälp av samma hashfunktion f˚as sedan resultatet ur tabellen när detta fr˚agas efter av användaren. De allra viktigaste punkterna att ha i ˚atanke för att indexeringen ska fungera s˚a bra som möjligt är:

• Sammanslagningsfaktorer, hur den nya datan matas in i det befintliga indexet. • Lagringstekniker, hur indexet ska sparas, dvs. om informationen ska vara

kompri-merad1 eller filtrerad2.

• Indexets storlek, hur mycket utrymme behövs egentligen för att lagra all data. • Snabbhet, hur snabbt ett värde kan hittas, detta är den viktigaste delen för en

s¨okmotor.

• Underh˚all, hur indexet uppdateras ¨over tid.

1

Innebär att datan omkodas s˚a att mindre utrymme krävs för att lagra samma information.

(16)

• Feltolerans, hur viktigt det är för tjänsten att inte ge m˚anga fel.

Blocket ˚a andra sidan använder sig av ett par taggar som bestäms när varje ny annons skapas. Varje annons är kategoriserad, tillhör ett visst län och en viss ort. Detta används vid indexeringen och informationen om detta hittas i deras databas. B Locket AB har sju huvudkategorier och flera underkategorier i varje huvudkategori.

2.1.3 F¨

orfr˚

agningar

Det sista steget är helt enkelt själva sökningen. Skillnaden mot att sl˚a mot en helt vanlig databas är i stort sett storleken. De vanligaste sökningarna som en användare gör kan sammanfattas i dessa tre olika sorters förfr˚agningar[35]:

• Informationsförfr˚agningar, fr˚agor som täcker in ett väldigt brett omr˚ade, här kan det finnas massor med relevanta resultat.

• Navigerbara f¨orfr˚agningar, fr˚agor som riktar sig till en specifik webbplats, i www. blocket.se:s fall kan det vara kategori.

• Affärsbesluts-förfr˚agningar, fr˚agor som användaren använder sig av för att fatta affärsbeslut, köpa bil eller liknande.

Det är fortfarande vanliga SQL-fr˚agor till den stora databasen som skapats av all den information som spindeln samlat in. Detta ger användaren dess resultat. Fr˚agan mot databasen bildas d˚a användaren sl˚ar in sina sökord. Här letar sökmotorn med hjälp av sitt index igenom hela datamängden för att till slut visa sitt resultat för användaren. För Blocket är dock detta n˚agot annorlunda. De personer som använder www.blocket.se tar inte sökfältet till s˚a mycket hjälp. Detta beror p˚a att Blocket redan har delat in alla annonser i kategorier som är väldigt detaljerade. Användaren klickar sig vanligtvis vidare genom att välja kategori och under-kategori. Detta är allts˚a förinställda fr˚agor mot databasen vilket gör att användaren upplever det som att sökning p˚a det här sättet g˚ar fortare. Eftersom dessa fr˚agor redan har ställts mot databasen är det ocks˚a ett snabbare sätt att f˚a fram information p˚a.

(17)

2.2 R¨

attstavning

Det är allmänt känt att särskrivning och felstavning är väldigt stora problem i dagens samhälle. Vi är helt enkelt för vana vid att datorer rättar oss när vi skriver fel. Om alla ordbehandlare hanterar stavfel och särskrivningar ˚at användarna, vilket de flesta faktiskt gör, s˚a är det givet att ocks˚a sökmotorerna ska klara av denna uppgift. I dagsläget är det tyvärr bara n˚agra enstaka sökmotorer som har lyckats lösa denna uppgift(exempelvis Googles sökmotor).

Datorerna har inte bara medfört att vi stavar fel p˚a grund av för mycket hjälpmedel, ¨

aven tangentbordet gör att orden kan bli felaktiga. Det är nämligen väldigt enkelt att tryc-ka p˚a fel tangent. De fyra vanligaste felen som förekommer vid sökningar p˚a sökmotorer och i texter som skrivs i ordbehandlare är:

1. Att en bokstav har f¨orsvunnit.

2. Att det har kommit till en extra bokstav. 3. Att en bokstav har bytts ut mot en annan. 4. Att tv˚a bokst¨aver har bytt plats i ordet.

Dessa felstavningar kan faktiskt hittas i ända upp till 80 procent av alla felstavade ord. Detta har pressat utvecklare och andra att försöka komma fram till olika sätt att lösa problemen p˚a. Anledningen till att www.blocket.se vill ha denna funktionalitet är för att hjälpa användaren att f˚a fler träffar p˚a sina sökord. Detta kommer göra annonser mer lättillgängliga och förhoppningsvis blir annonsörerna och köparna mer nöjda d˚a an-nonsörernas annonser visas mer, respektive att köparen faktiskt hittar fler annonser. Rättstavningen kommer att ske utan att användaren behöver fundera p˚a om han eller hon faktiskt stavat rätt ifall f˚a annonser skulle visas, det kommer att visas ett förslag till annan stavning om det skulle finnas ett annat alternativ som är bättre.

2.2.1 Algoritmer

I dagsläget finns det massor med olika alternativ för att kontrollera om ett ord är rätt stavat eller inte. Ett antal av dessa kommer att förklaras här nedan. N˚agra av de alternativ som finns idag för att hantera problemet med felstavning är:

(18)

• Edit-distance algoritmer • Bloom-filter

• Jaro-Winkler Fonetiska algoritmer

Fonetiska algoritmer[30] ger varje ord en viss kod, denna kod motsvarar ordets fonetiska skrift. Detta innebär att flera ord kan ha samma kod d˚a vissa uttal är väldigt lika, eftersom uttal är den enda faktorn kan detta bli en väldigt stor begränsning.

F¨or att denna variant ska fungera m˚aste algoritmen ha tillg˚ang till en ordlista, denna ¨

ar indexerad enligt algoritmens koder för fonetisk skrift. Efter att ha matchat det inma-tade och felstavade ordets kod med n˚agon kod i den indexerade ordlistan f˚as ett antal alternativ p˚a vilket ord användaren kunde menat egentligen. Denna algoritm ger oftast inte ett enda alternativ allts˚a. Det här innebär att enbart denna variant inte räcker för att klara av en ”Menade du”-implementation3_.

N-grams

N-grams[24] delar upp ord i n stora delar, algoritmen indexerar även sin ordlista enligt denna metod. När en användare skriver sitt ord delar n-gram algoritmen upp detta i delar av n storlek. Dessa delar jämförs sedan med orden i ordlistan. Desto fler delar som det inmatade ordet har gemensamt med n˚agot ord i ordlistan desto större sannolikhet är det att det inmatade ordet faktiskt är ordet i ordlistan. Ett exempel är ordet ”hund” som d˚a blir uppdelat i ”hu”, ”un” och ”nd”, detta förutsatt att 2-grams används.

N-grams används ofta för att föresl˚a ord inom rättstavning, framförallt använder ordbehandlare sig av denna teknik för att indexera sin ordlista. Precis som föreg˚aende algoritm kan inte heller denna föresl˚a ett enda ord för användaren utan plockar ut ett visst antal ord som inneh˚aller n antal delar N-grams av det inmatade ordet.

Edit-distance algoritmerna

Edit-distance algoritmerna[18] använder sig av att räkna p˚a avst˚andet mellan tv˚a ord. Med avst˚andet menas hur m˚anga operationer som krävs för att ord1 ska bli ord2. Opera-tionerna kan vara borttagning av och införande av, samt utbyte av bokstav eller bokstäver.

(19)

Precis som föreg˚aende algoritmer s˚a används ocks˚a här en ordlista för jämförelse. P˚a se-nare tid har även algoritmer av denna sort utvecklats till att klara av transposition4 av tv˚a bokstäver. Operationerna har olika värden beroende p˚a hur tunga de är, kostnaden ¨

ar enligt f¨oljande:

• Kopiering av bokstav fr˚an ord1 till ord2 har kostnad 0 • Borttagning av bokstav fr˚an ord1 till ord2 har kostnad 1 • Till¨agg av bokstav fr˚an ord1 till ord2 har kostnad 1 • Utbyte av bokstav fr˚an ord1 till ord2 har kostnad 1

Edit-distance algoritmerna är de som är vanligast bland rättstavningsimplementationer enligt KTH5:s spr˚akvetenskapliga avdelning[16]. Den stora anledningen till detta är att den är väldigt snabb, väl dokumenterad och har funnits under l˚ang tid, vilket innebär att den är väl testad och väl använd. Fördelen är ocks˚a att den klarar av att hitta ett specifikt ord i en ordlista och har möjlighet att bara ge ett alternativ till det felstavade ordet.

Jaro-Winkler distance

Jaro-Winkler[13] är en variant p˚a edit-distance. Precis som föreg˚aende algoritm räknar Jaro-Winkler ut avst˚andet mellan tv˚a ord för att till slut hitta ett bra förslag p˚a vad användaren matat in. Skillnaden dem emellan är att ju högre värde i Jaro-Winkler desto närmre är orden varandra i likhet, men i den vanligare varianten av edit-distance är det ett s˚a l˚agt värde som möjligt mellan tv˚a ord som anger likhet. Avst˚andet mellan tv˚a ord ges av formel 2.1. Ytterligare delar som denna algoritm kan använda sig av är att

dj = 1 3 m |s1| + m |s2| + m − t m (2.1)

Tabell 2.1: m = antal matchande bokst¨aver i s1 och s2, s1 = ord1, s2 = ord2, t = antalet

transpositioner, dj = avst˚and mellan s1 och s2

ranka strängar som matchar p˚a prefix högre än de som matchar senare. Detta kan vara en fördel vid exempelvis namnuppslagning men kan ocks˚a vara en nackdel när det gäller produkter eller andra strängar som inneh˚aller n˚agot slumpmässiga teckenföljder.

(20)

Jaro-Winkler är anpassad för att hantera kortare strängar eftersom den inte är riktigt lika snabb som edit-distance. dj som var avst˚andet mellan tv˚a ord anges mellan 0 och 1

i flyttal, där 0 anger ingen likhet och 1 säger att de är exakt lika. Bloom-filter

Bloom-filter[3] används för att detektera delelement i större element, till exempel inom lingvistik s˚a kan man se om ett specifikt ord tillhör ett annat större ord. Precis som flera av de tidigare algoritmerna använder ocks˚a Bloom-filter en ordlista. När ordlistans storlek ökar s˚a finns risken att ord som skulle markerats som felaktiga faktiskt tolkas som rätt, dock s˚a ger den aldrig felaktiga svar p˚a de ord som faktiskt är fel.

Detta är dock en metod som kan vara sv˚ar att implementera i en sökmotor, med tanke p˚a att den faktiskt ger fler fel när ordlistan blir större. Eftersom ordlistan kommer vara ganska stor i www.blocket.se:s fall s˚a kan detta göra att sökningarna blir helt felaktiga i längden vilket kommer att resultera i en uppsjö av arga kunder, dessutom blir det sv˚art att bygga en ordlista av annonser med denna metod.

2.2.2 Lucene

Lucene[19] är en sökmotor som helt är uppbygd enligt Open-source-principen. Det g˚ar allts˚a att använda denna sökmotor i vilket projekt som helst.

Inom omr˚adet rättstavning finns det en hel del färdiga komponenter[20] till denna sökmotor vilket gör den till en intressant kandidat för att sköta denna uppgift p˚a www. blocket.se. Den använder sig av edit-distance-algoritmer för att kontrollera vilket ord som kan tänkas vara det rätta. Det finns även tillägg för att använda Jaro-Winkler-algoritmen. För att snabbare hitta de ord i ordlistan som byggs upp av annonserna använder sig Lucene av N-grams för att indexera hela denna lista. Nackdelen med just denna variant är att den är n˚agot anpassad för det engelska spr˚aket, vilket gör att den inte kan hantera särskrivningar.

(21)

2.2.3 Hunspell

Hunspell ¨ar ett bibliotek6 _{som ¨}_{ar byggt f¨}_{or att utf¨}_{ora bland annat r¨}_{attstavning. Detta}

bibliotek används i m˚anga ordbehandlare och även webbläsare för just rättstavning. Hun-spell använder sig av edit-distance-algoritmer för att kontrollera likhet mellan ord och N-grams för att indexera sin ordlista, allts˚a liknande algoritmer som Lucene använder sig av. Den stora skillnaden är att Hunspell har utvecklats under en längre period samt att det är utvecklat enbart för lingvistik och har stöd för väldigt m˚anga spr˚ak, samt att det klarar av särskrivning.

2.2.4 Utv¨

ardering

En kombination av edit-distance och N-grams är de vanligaste som finns implementerade i dagens ordbehandlare[25]. Ordbehandlare behöver dock inte tänka p˚a prestanda lika mycket som sökmotorer d˚a de inte behöver vara fullt s˚a snabba, samt att de inte har lika stor datamängd att hantera.

Vad gäller ordlistor s˚a är detta ett alternativ som används mest i ordbehandlare. Anledningen till detta är för att det mest handlar om skriftspr˚ak när dessa används. Ordlistorna som finns idag är uppbyggda manuellt och uppdateras n˚agra g˚anger per ˚ar, detta gör att de kan bli n˚agot förlegade när de används under l˚ang tid och i en sökmotors värld behöver de uppdateras väldigt frekvent.

Sökmotorer i allmänhet använder inte ordlistor i samma utsträckning, detta eftersom de ska klara av talspr˚ak p˚a ett helt annat sätt. I B Locket AB:s fall är det dock lite speciellt eftersom annonser inneh˚aller lite av b˚ada delar, därför kommer fokus att ligga p˚a b˚ade skriftspr˚ak och talspr˚ak.

2.3 S¨

arskrivning

Särskrivning är när ett ord skrivs som tv˚a, denna del innefattar även det läget som är tvärtom, allts˚a där tv˚a ord skrivs som ett.

Vad gäller särskrivning s˚a är detta ett ämne som är betydligt mycket sv˚arare att lösa. I dagsläget finns ingen algoritm som är välkänd för att lösa detta fenomen. Det beror delvis p˚a att ordbehandlare med mera, främst utvecklas för det engelska spr˚aket, där särskrivningar inte förekommer i särskilt stor utsträckning. Samt att m˚anga lösningar är patenterade och väldigt sv˚ara att hitta information om.

(22)

N˚agra av de bibliotek som finns i dag använder sig av edit-distance algoritmen för att lösa även särskrivningar. Ett antagande görs om att det har införts ett extra tecken, i detta fall ett mellanslag, när detta tas bort f˚as en träff p˚a ett helt ord i ordlistan. Tyvärr fungerar inte detta om även det särskrivna ordet finns i ordlistan, vilket är fallet i denna rapport d˚a ordlistan kan inneh˚alla felstavade ord.

De algoritmer som löser särskrivningen p˚a bättre sätt använder sig istället av mor-fologisk analys[22]. Här specificeras speciella regler för vad som är en särskrivning och inte.[37]

2.3.1 Morfologisk analys

Morfologisk analys innebär att ordens struktur tas fram, form och böjning. En morfologisk analys tittar p˚a hur stor del av ordet som kan passa ihop med ett annat ord i ordlistan, vilket leder till att de föresl˚ar en sammansättning av tv˚a ord istället för den särskrivna formen.

För att detta ska fungera används en ordlista med samtliga ord taggade enligt svenska spr˚akets regler för rättstavning. De ord som kan förekomma i en sammansättning av tv˚a ord f˚ar en tagg för detta, det specificeras även om de kan vara en början p˚a en sammansättning eller ett slut p˚a den. När användaren matar in sitt ord särskrivet tittar allts˚a rättstavaren i sin ordlista efter ord som kan förekomma i sammansättningar. Om den hittar ord som liknar det användaren har matat in fast sammansatt s˚a föresl˚ar den det ordet istället.

Denna metod är allts˚a säkrare än att göra antagandet att mellanslaget är en felaktig bokstav. Finns särskrivningen i ordlistan kan problem uppst˚a, vilket kommer att vara fallet för B Locket AB och deras ordlista. En lösning p˚a detta kan vara att varje ord i ordlistan rangordnas och när förslag ska tas fram kontrolleras vilket av dem som rankas högst, det ord som d˚a rankas högst kommer att föresl˚as som det rätt stavade.

2.4 Stemming

(23)

omr˚ade som det han eller hon sökt p˚a. Detta fungerar eftersom ordets stam tas fram och inte tvärtom, dvs. försöker skapa nya ord. Denna funktionalitet finns redan p˚a www. blocket.se men fungerar inte fullt ut, därför ska en undersökning göras p˚a det alternativ som används idag och se ifall det finns n˚agot som är bättre, eller om den funktion som redan finns kan förbättras p˚a annat sätt.

2.4.1 Algoritmer

De tv˚a olika varianterna som undersökts i denna rapport är en algoritm utan ordlista och en variant med ordlista. Dessa varianter är egentligen tv˚a bibliotek för programmerings-spr˚aket C, nämligen Snowball som klarar sig utan ordlista och Hunspell som använder en ordlista. Anledningen till att det bara är tv˚a varianter som undersökts är för att ett av B Locket AB:s grundläggande krav var att de färdiga delar som skulle användas var gratis och helst Open-source alternativ. Den främsta anledningen till att detta krav kom upp är för att företaget vill undvika onödiga kostnader till andra företag.

De tv˚a algoritmerna beskrivs h¨ar nedan.

Snowball

Detta är den variant som inte använder n˚agon ordlista för att lista ut ordens stam. Här tittar algoritmen helt enkelt p˚a ordet och ser vad det slutar p˚a, vilket betyder att denna ”stemmer” utan ordlista enbart tittar p˚a suffix. Detta är en begränsning som kan innebära vissa felaktigheter i sökresultaten.

I denna variant m˚aste regler deklareras för hur varje ord f˚ar ändras, vilka ändelser som kan tas bort och p˚a vilket sätt detta ska göras. Detta gör att det ganska snart blir en väldigt komplex och stor lista med regler, dessutom oavsett hur mycket regler som införs s˚a blir det nästan omöjligt att täcka alla fall.

Fördelarna med de algoritmer som inte använder ordlistor är att de är väldigt snabba och kräver väldigt lite utrymme, de kan allts˚a vara bra vid fall där prestanda är viktigare ¨

an precisa resultat och framförallt när prestandan är begränsad. Nackdelen är dock att de kan ta bort för stor del av ordet s˚a att det f˚ar en helt annan betydelse7_{, men ¨}_{aven att}

ett ord som inte finns uppkommer. Om detta inträffar s˚a är stemmingen helt bortkastad, användaren kommer att f˚a träffar p˚a helt andra saker än det han faktiskt sökt p˚a, eller inga alls, vilket kan leda till en allvarlig bugg.

Det Open-Source alternativ som finns f¨or den h¨ar sortens stemming heter Snowball[28].

(24)

Hunspell

Hunspell[9] använder sig av en ordlista uppbyggd med hjälp av morfologisk analys för att ta reda p˚a ordets morfem8_.

Med hjälp av den morfologiska analysen hittas allts˚a den minsta gemensamma nämnaren mellan orden i ordlistan och det användaren har matat in. Ordets stam, som blir resul-tatet, är det som den totala sökningen baseras p˚a för att f˚a fler träffar, precis som sagts tidigare.

Den morfologiska analysen utförs p˚a ordlistan vid indexeringstillfället, ordlistan byggs d˚a upp med s˚a kallade taggar. Varje ord f˚ar en taggning som beskriver vilken ordklass det tillhör, hur det kan böjas och även dess struktur. Här kopplas ord samman med varandra om de tillhör samma grundform, detta med hjälp av de regler som satts upp av den affix-fil programmet använder. En affix-fil inneh˚aller regler p˚a hur ord kan kortas ner, detta baserat p˚a spr˚akets vanliga prefix och suffix.

Nackdelen med dessa affix-filer och ordlistor är att de byggs upp manuellt, anledningen till detta är att det blir oerhört sv˚art att bygga detta automatiskt eftersom lingvistiken ¨

ar s˚a oerhört komplex. Andra alternativ som kan ställas in i en affix-fil är bland annat: • Hur m˚anga bokstäver varje ord som ing˚ar i en sammansättning m˚aste ha

• Om programmet ska ge förslag p˚a tv˚a separata ord som en sammansättning • Vilka ord som kan ing˚a i en sammansättning

• Vilken ordklass varje ord tillh¨or. . .

2.4.2 Utv¨

ardering

Stemming utan ordlista hittar ordets stam men gör väldigt ofta fel, Hunspell däremot hittar ordets korrekta stam betydligt mer frekvent. Om användaren matar in ordet ”ka-jakerna” s˚a lyckas den med ordlista att f˚a fram ordet ”kajak” som d˚a är ordets stam. Detta skulle stemming utan ordlista f˚a fram ordet ”kajaker” utav, om ordet hade varit mindre komplext hade även denna metod lyckats hitta rätt ordstam.

Hunspell är inte lika snabb som stemming utan ordlista men ger betydligt färre fel, dessutom är sammanflätning inte alls lika vanligt, detta gör att användaren f˚ar mer precisa resultat och framförallt rätt resultat.

(25)

2.5 Lemmatization

Denna metod liknar stemming som nämnts tidigare i 2.4. Den stora skillnaden är att istället för att hitta ordets stam hittas ordets lemma. Lemma är ordets grundform, t.ex. ”sämre” som har grundformen ”d˚alig”. För att bestämma ordets lemma behöver algo-ritmen veta vilket spr˚ak det är och i vilket sammanhang ordet används. En nackdel här ¨

ar allts˚a att vissa ord faktiskt har flera betydelser vilket kan leda till väldigt komplexa operationer. De komplexa operationerna gör att det kan bli stora p˚afrestningar p˚a den maskin som utför dem och själva systemet kan upplevas som segt, dessutom fungerar denna metod bäst när ordet sätts i ett sammanhang, vilket sällan är fallet i en sökterm. Fördelen är att Lemmatization[17] övervinner problemet med att liknande, ickerele-vanta ord hämtas. Det här problemet uppkommer däremot ofta vid stemming.

Lemmatization är fortfarande en väldigt bra metod för att hjälpa användaren hitta vad han eller hon letar efter. Antalet fel är väldigt sm˚a i förh˚allande till vad som skulle kunna hända med stemming och den är framförallt väldigt exakt.

2.6 Synonymer

För att en sökmotor ska bli riktigt bra m˚aste den klara av att först˚a synonymer. Synony-mer är ord som har samma betydelse som ett specifikt annat ord. I sökmotorns fall innebär detta att användaren kan f˚a fler träffar, om han eller hon t.ex. söker p˚a ”rullbräda” s˚a ska träffar även ges p˚a ordet ”skateboard” och andra synonymer. www.blocket.se har i dagsläget inte n˚agon s˚adan implementation och när det gäller annonser är denna funk-tion väldigt viktig. Anledningen till detta är för att B Locket AB används av s˚a skilda ˚aldersgrupper, därför kan de skriva väldigt olika ord men faktiskt mena exakt samma

sak. Vad finns det d˚a f¨or alternativ som g¨or detta?

Vad gäller Open-source alternativ finns det bara ett som är vanligt och ordentligt beskrivet, detta heter MyThes och används i bland annat OpenOffice9.

MyThes[23] använder sig av tv˚a filer för att kontrollera ord och dess synonymer. Huvudfilen är uppbyggd enligt denna struktur:

Ord — antal betydelser

betydelse1 — syn1 — syn2 . . . .

.

(26)

.

betydelseX — syn1 — syn2 ...

Ord – ordet som matats in och som finns i ordlistan

Antal betydelser – hur m˚anga olika sorters betydelser det ordet kan ha

Varje rad som f¨oljer denna inneh˚aller en betydelse och den har i sin tur sina synonymer efter sig enligt denna ordning:

1. betydelse – specifik betydelse f¨or ordet

2. syn1 – synonym nummer ett f¨or den specifika betydelsen 3. syn2 – synonym nummer tv˚a f¨or samma betydelse osv.

Den andra filen byggs upp med hj¨alp av denna huvudfil genom att enbart ta med antal synonymer totalt och siffran p˚a detta i toppen av filen, samt var i huvudfilen som orden kan hittas. Denna fil kan ses som en indexfil och totala antalet synonymer inneb¨ar alla synonymer som ing˚ar i databasen.

När ett ord matas in i sökfältet av användaren kontrollerar programmet i sin indexfil var den kan hitta andra betydelser av det inmatade ordet i sin synonymordlista. Om den hittar n˚agra synonymer matas dessa ut enligt betydelse och med dess synonymer uppradade, detta kan användas för att användaren ska f˚a fler träffar inom samma omr˚ade och även för att hitta det som kan vara lite sv˚arare att lokalisera.

2.7 Autocomplete

Autocomplete[15] hjälper användaren genom att föresl˚a ord för denne, dessa ord baseras p˚a vad användaren har slagit in för bokstäver i sökfältet, exempel p˚a hur detta kan se ut kan ses i figur 2.1.

Denna metod är framförallt väldigt effektiv när det är enkelt att gissa vad användaren vill skriva. De fall när det blir enkelt är när antalet möjliga förslag är begränsade eller att datamängden inte är s˚a stor, med andra ord, desto fler ord användaren matar in i sökfältet desto färre alternativ finns det att välja bland och sökningen g˚ar snabbare.

(27)

Figur 2.1: Ett exempel p˚a autocompletion i ett textf¨alt fr˚an den f¨orsta prototypen som gjordes.

s˚a enkelt som möjligt p˚a hela sidan. Den förslagslista som dyker upp för användaren kommer att sorteras enligt de specifikationer som utvecklaren bestämmer. B Locket AB:s idé är att titta p˚a alla annonsrubriker och implementera autocomplete med hjälp av dessa. När användaren matar in bokstäver i sökfältet f˚ar denne allts˚a förslag p˚a olika annonsrubriker inneh˚allandes den sträng användaren matat in, n˚agra andra exempel p˚a vilken data förslagslistan kan skapas av är:

• Historiska sökningar, dessa loggas av sökmotorn och presenteras för användaren i fallande ordning baserat p˚a hur m˚anga g˚anger de gjorts.

• Personliga historiska sökningar, sorterade p˚a antal g˚anger de gjorts för just den användaren, sv˚art med datamängd.

• Nyligen gjorda s¨okningar, mindre datam¨angd

Hur detta ska sorteras baseras p˚a vilken sorts applikation det är som ska använda tjänsten, men för att f˚a den s˚a snabb som möjligt är det bra att basera det p˚a en s˚a liten datamängd som möjligt, den f˚ar dock inte vara för liten eftersom det kan leda till d˚aliga förslag eller inga alls.

Den andra delen av förslagslistan är själva ordningen p˚a den. Hur detta ska ordnas bestäms ocks˚a av utvecklaren men även här finns ett antal olika förslag.

• Beräknad sannolikhet, t.ex. Hur ofta sökningen gjorts historiskt sett. • Senast förfr˚agningen gjordes, Om det är intressant ur historisk synpunkt.

(28)

Normalt uppdateras förslagslistan efter varje tangenttryckning, vilket leder till en ganska kostsam operation för servern. Om ett s˚ant här anrop ska göras för varje användare flera g˚anger under en kort period s˚a är det stor risk att den maskin som hanterar förfr˚agningarna blir överansträngd. För att undvika att detta problem uppst˚ar används submission throttling[33] och cache[5].

2.7.1 Submission throttling

Submission throttling innebär att istället för att l˚ata Autocomplete-metoden anropa ser-vern vid varje tangenttryckning s˚a sker anropen med ett visst tidsintervall. Anropen sker allts˚a mer sällan och problemet med att de användare som skriver väldigt snabbt f˚ar konstiga förslag undviks. De konstiga förslagen uppkommer helt enkelt eftersom servern inte hinner med att hantera varje anrop. Om fokus istället läggs p˚a cache för att försöka ¨

oka snabbheten s˚a kan detta g¨oras med olika metoder, tex Browser-side-cache[4] eller memcache[21].

2.7.2 Browser-side-cache

Browser-side-cache använder sig av cache-minnet som finns i webbläsaren, nackdelen med detta är att denna cache begränsas till en viss storlek, ju mer data som cachas desto längre tid tar det för webbläsaren att visa sidan. Detta kan p˚averka användarens surfupplevelse, speciellt om han eller hon har en äldre dator, det här är allts˚a ett typiskt exempel p˚a hur användaren kan p˚averkas negativt även om m˚alet är att göra sidan mer användarvänlig, därför är inte detta att rekommendera om datamängden är stor.

Hur länge cachen ska sparas beror helt p˚a utvecklaren, detta d˚a han kan sätta specifika villkor p˚a hur länge cachen ska h˚allas kvar lokalt hos användaren. Det kan göras med bland annat bäst före datum eller med senast ändrad taggar. Utvecklaren f˚ar dock inte sätta vilka villkor som helst för denna cache, vissa lagar m˚aste följas och dessa finns specificerade i HTTP:s-specifikation[8].

2.7.3 Memcache

(29)

användare som utnyttjar tjänsten, men även hur mycket data som m˚aste behandlas. Detta kan vara ett aktuellt alternativ i B Locket AB:s fall.

2.7.4 Utv¨

ardering

Oavsett metod s˚a är själva idén med cache att minska antalet förfr˚agningar till servern, detta dels för att snabba upp systemet men även för att minska p˚afrestningen p˚a den. Cache fungerar p˚a s˚a vis att det har en lista p˚a de ord, som exempelvis söks p˚a oftast, sparad. För att undvika att denna lista växer till oändlighet, vilket skulle leda till ett lika slött system som utan cache, m˚aste det d˚a och d˚a kastas ut ord. Detta kan exempelvis göras genom att de ord som sökts p˚a mindre än andra kastas ut, ord som förekommer mindre frekvent än andra knuffas helt enkelt ner˚at i listan. För att undvika att listan bli inaktuell m˚aste denna uppdateras ganska frekvent.

När användaren börjar mata in sitt sökord kommer allts˚a den första förfr˚agningen att ske mot cachen och om ord som liknar användarens finns där kommer dessa att visas i förslagslistan, om s˚a inte skulle vara fallet kommer en förfr˚agning ske mot servern direkt. Det kommer d˚a att ta n˚agot längre tid att f˚a fram listan p˚a förslag men förslaget kommer fortfarande att visas.

2.7.5 Gr¨

anssnitt

Det finns flera bibliotek som klarar av autocompletion, de flesta skrivna i javascript[14] eller AJAX[1]. De fungerar p˚a liknande sätt allihopa, n˚agra exempel p˚a bibliotek för autocompletion är, scriptaculous[27] och jquery[15]. Valet föll p˚a jQuery enbart för att B Locket AB redan använder det och s˚aledes utfördes ingen analys p˚a dessa delar.

2.7.6 Krav p˚

a s¨

okmotorn

(30)

Kapitel 3

Resultat och utv¨

ardering

Här beskrivs varje del för sig samt vilka resultat som uppn˚atts inom varje omr˚ade, även hur dessa delar har implementerats eller inte i den slutgiltiga prototypen.

3.1 R¨

attstavning

Efter att ha vägt de olika algoritmerna mot varandra kunde en slutsats dras om att en kombination mellan edit-distance och N-grams var det bästa alternativet för denna typ av problem, detta för att N-grams är en väldigt snabb algoritm som ger väldigt f˚a fel och edit-distance är väldokumenterad.

I den här rapporten används N-grams för att indexera ordlistan, detta gör att orden kan lokaliseras snabbare än om enbart edit-distance hade använts. Edit-distance används istället för att kontrollera de ord som N-grams plockar fram och ser vilket som är mest likt det ord användaren redan matat in. Anledningen till att edit-distance valdes är för att den är specialkonstruerad för att jämföra tv˚a ord och skillnaden dem emellan, just den valda varianten klarar av transposition ocks˚a, vilket är lite mer effektivt och gör den ¨

annu b¨attre.

För att minska arbetsbördan, men ocks˚a för att det var sv˚art att uppn˚a n˚agot lika bra, valdes ett bibliotek med dessa egenskaper för rättstavning kallat Hunspell och en separat sökmotor kallad Lucene ut. Hunspell används vanligen i de flesta Open-Source1 -projekten som behöver rättstavning. Lucene ˚a andra sidan används främst när det behövs en sökmotor med stor funktionalitet och enkel utbyggnad.

Ordlistan som Lucene och Hunspell anv¨ander byggs nu upp av blockets

(31)

ker, den sorteras enligt hur ofta varje ord f¨orekommer i fallande ordning.

När användaren matar in sitt ord i sökfältet kontrolleras ordet mot ordlistan. Om ordet inte finns med i ordlistan kommer en sökning att genomföras p˚a användarens felstavade ord, men han kommer även att f˚a upp ett förslag p˚a vad han kan ha menat egentligen. Det förslag som användaren f˚ar upp är baserat p˚a hur m˚anga g˚anger det förekommer i alla annonser och hur pass likt det är ordet användaren matade in. Störst vikt läggs p˚a hur pass likt ordet är det inmatade ordet. För att bestämma vilket av de tv˚a alternativen som

Figur 3.1: P˚a detta sätt kommer ordlistan att byggas upp när Hunspell implementeras i det färdiga systemet.

(32)

klarar av m˚anga spr˚ak är att detta ska kunna lanseras i fler länder än Sverige.

Det finns dock vissa problem med Hunspell, speciellt när ordlistan inneh˚aller felsta-vade ord, ordlistan är nämligen lag för Hunspell. Detta betyder att ordlistan inte f˚ar inneh˚alla n˚agra felstavade ord eller ˚atminstone s˚a f˚a felstavade ord som möjligt, d˚a det inte ser särskilt bra ut när ett felstavat ord visas för användaren. Anledningen till att detta problem uppst˚ar är för att ordlistan skapas av alla annonser. En lösning är dock att Hunspell väljer det ord som rankas högst beroende p˚a frekvens i alla annonser, p˚a s˚a vis undviks detta problem.

Det viktigaste med denna funktion är att den blir snabb och att resultatet syns tydligt för användaren. Implementationen gör att användaren kan söka och f˚a träffar även om han eller hon har sv˚art med stavning. Dessutom eftersom en felsökning aldrig korrigeras kommer de annonser som stavats fel ocks˚a att visas. En stor aspekt i detta problem är att det m˚aste se s˚a enkelt ut som möjligt för användaren, som sagts tidigare är B Locket AB:s filosofi att allt ska se s˚a enkelt ut som möjligt. Därför har det lagts stor vikt vid designen av detta, det är ocks˚a n˚agot som kommer att vidareutvecklas även efter detta projekt.

För att ge en bild över hur det skulle kunna se ut ges ett exempel i figur 3.2. I detta projekt togs designbesluten i diskussion med handledare och de ansvariga för designen p˚a siten. Eftersom företaget vill ha sitt att säga till om blev designen inte helt fullständig under projektets g˚ang.

(33)

3.2 S¨

arskrivning

Den implementation som testats av Hunspell klarar av särskrivning väldigt bra förutsatt att ordlistan inneh˚aller det rätta ordet. Nackdelen med Hunspell i det här läget är att den inte klarar av att skilja p˚a särskrivning och tv˚a helt skilda ord. T.ex om söktermen ”volvo v70” matas in ger Hunspell förslaget ”volvo”, vilket i det här fallet är helt fel eftersom användaren faktiskt var ute efter den specifika modellen ”v70”. Kan detta förhindras p˚a n˚agot sätt och hur kan Hunspell tvingas till att föresl˚a rätt ord?

Sättet att lösa detta problem blev att varje mening delas in i ordpar och s˚a vidare, t.ex ”volvo v70’ blir ”volvo”, ”volvo v70” och ”v70”. Det här tvingar Hunspell att välja ”volvo v70”, förutsatt att det alternativet finns och är högt prioriterat. Tyvärr har inte denna lösning implementerats i den riktiga prototypen vilket gör att särskrivningar kan accepteras som godkända söktermer. Anledningen till att detta inte implementerats var för att tiden blev för knapp.

3.3 Stemming och Lemmatization

De alternativ som fanns var stemming utan ordlista eller med ordlista, samt lemmatiza-tion. De tester som utförts visade ganska snart att stemming utan ordlista inte fungerar eftersom den plockar ut s˚a pass m˚anga felaktiga ordstammar. Hade denna använts ha-de användaren kunnat f˚a väldigt konstiga träffar och framförallt f˚att träffar p˚a andra omr˚aden än det han eller hon var ute efter (se appendix F).

(34)

ger färre felaktiga ordstammar. Denna metod är allts˚a bättre och eftersom skillnaden i hastighet dem emellan är s˚a pass l˚ag finns det ingen anledning till att inte välja den metod som ger lägre antal fel.

För att stemming ska fungera s˚a bra som möjligt m˚aste konstanta uppdateringar av ordlistan ske, tyvärr kommer m˚anga av dessa att behöva ske manuellt, d˚a det kan vara sv˚art att täcka in precis alla fall. Även den svenska ordlistan uppdateras idag manuellt eftersom det hela tiden läggs till nya ord i det svenska spr˚aket.

Stemming är n˚agot som redan ing˚ar i dagens sökmotor p˚a www.blocket.se och även i de flesta moderna sökmotorer p˚a marknaden. Med denna rapport tillkommer dock en förbättring av den redan existerande varianten av stemming med Hunspell.

Det stora problemet som fanns tidigare var att ord kunde sammanflätas och vissa ord kunde kortas ner för l˚angt s˚a att de inte längre hade n˚agon betydelse, detta löstes i och med att ordlistan fick en konstant uppdatering. Nackdelen är att det tar lite tid att uppdatera ordlistan och det kan vara sv˚art att se vilka ord som kortas ner felaktigt, men när uppdateringarna görs kommer ocks˚a förbättringen vilket gör att tiden som läggs ner p˚a uppdatering tas igen i effektivitet.

Den här förbättringen av sökmotorn är inget som användaren kommer att se men det gör att träffarna han eller hon f˚ar blir fler. Stemming gör allts˚a sökmotorn förbättrad i fr˚aga om att presentera fler relevanta resultat för användaren, vilket i sin tur gör att fler annonser kommer synas och fler personer f˚ar möjlighet att sälja sina begagnade prylar.

3.4 Synonymer

Synonymerna används för att l˚ata användaren f˚a fler träffar. Det kommer framförallt att användas för produkter som kan benämnas p˚a flera olika sätt. T.ex. ”playstation 3”2 och ”ps3”. Detta kommer att användas varje g˚ang en sökning görs.

När användaren har matat in sin sökterm skickas den termen till synonymbehand-laren. Här kommer söktermen att jämföras mot synonymordlistan, därefter plockas dess synonymer ut och används i den totala sökningen. Den stora nackdelen med implementa-tionen är 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ärr blir detta n˚agot omständigt men samtidigt uppn˚as en väldig kontroll p˚a vilka ord som faktiskt ska ing˚a och förhoppningsvis kommer det att minska antalet fel.

Synonymimplementationen leder till en breddad s¨okning d¨ar varje synonym och den

(35)

ursprungliga söktermen kommer användas för att göra förfr˚agningar mot databasen. I förlängningen kan det här göra att sökmotorn blir n˚agot mer belastad men det ska inte p˚averka den s˚a mycket att det inte är möjligt att genomföra, detta har tagits i beaktande av B Locket AB innan valet föll p˚a att det faktiskt skulle implementeras.

3.5 Autocomplete

Eftersom sökmotorn som används idag inte klarar av de delar som behövs för att utföra autocomplete p˚a det sätt som B Locket AB vill, byggdes en egen utefter en Open-source-sökmotor kallad Lucene. Denna sökmotor är anpassad för just textsökning i stora sy-stem och med stora datamängder. För att kunna utnyttja denna sökmotor p˚a bästa sätt används en sökserver kallad Solr[29], Solr är anpassad till Lucene och har m˚anga redan färdigbyggda komponenter för att b˚ade indexera och söka med hjälp av Lucene. Sättet som autocomplete lösts p˚a är att sökmotorn enbart indexerar alla annonsrubriker.

(36)

unikt för alla entiteter)som används 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ökta termen desto längre tid tar det att f˚a förslagen.

Varje annonsrubrik best˚ar av max 40 tecken vilket specificerats av B Locket AB som därmed vill begränsa användarna för att rubriken ska vara s˚a kort och koncis som möjligt. Annonsrubriken ska helt enkelt bara inneh˚alla nödvändig information om produkten. Vid indexeringstillfället ses varje ord i varje rubrik som ett N-gram, vilket innebär att varje rubrik indexeras ord för ord. Detta ger m˚anga fler platser i indexet, vilket kan göra sökningen seg, men detta löses genom n˚agot som liknar memcache. S˚a stora delar som möjligt av datan sparas i RAM-minnet, vilket gör att den är mer lättillgänglig och därför g˚ar snabbare att sl˚a upp. Ett exempel p˚a hur denna uppdelning fungerar är rubriken ”volvo v40 2,0” som efter indexering ser ut enligt följande:

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ätt är för att användaren ska f˚a förslag p˚a just det ord han eller hon börjar skriva och inte en hel rubrik p˚a en g˚ang.

När användaren börjar mata in sin sökterm kommer ett anrop ske mot själva autocomplete-delen. Här kontrolleras sedan vilka ord som kan passa ihop med det användaren redan har skrivit.

Varje annonsrubrik har indexerats enligt tidigare f¨orklarat s¨att, detta kallas inverted index3[11, 12].

De bokstäver användaren slagit in matchas mot alla rubriker, därmed hämtas de rubri-ker ut som inneh˚aller den textsträng användaren matat in. Nästa steg är att användaren f˚ar upp en förslagslista med ett specifikt antal ord och ordpar som inneh˚aller just den sträng han eller hon matat in, dessa förslag är allts˚a delar av annonsrubriker som in-neh˚aller den sträng användaren matat in. Hur m˚anga ord och ordpar som ska visas i denna förslagslista kan enkelt ställas in genom att ändra p˚a en variabel.

Fördelen med denna teknik är att användaren snabbare kommer fram till vad han eller hon vill söka efter och eftersom förslagen är rubriker p˚a annonser kommer träffarna att vara mer exakta. Dessutom kommer användaren att f˚a n˚agra fler alternativ om listan presenteras p˚a detta sätt, vilket i sin tur gör att fler annonser kommer f˚a uppmärksamhet. B Locket AB strävar nämligen efter att alla annonser ska f˚a lika mycket utrymme eftersom

(37)

alla betalar samma pris inom samma kategori, enligt företaget självt strävar de efter att uppn˚a n˚agot som liknar allemansrätten[2].

Det stora problemet med denna implementation förutom hur själva förslagslistan skul-le skapas var att f˚a designen att se s˚a enkel ut som möjligt p˚a www.blocket.se. Just att det ska se enkelt ut är n˚agot som B Locket AB verkligen st˚ar för och jobbar h˚art för. Ett förslag p˚a hur autocomplete kan se ut p˚a www.blocket.se kan ses i figur 3.4.

(38)

Kapitel 4

Slutsats, diskussion och framtida

arbete

Vilka förbättringar har skett och vad kan göras för att förbättra dem ytterligare?

4.1 Slutsats och Diskussion

(39)

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.

(40)

användaren hade f˚att upp helt meningslösa förslag. Annonsrubriker användes istället för hela annonser eftersom en s˚a liten men fortfarande relevant datamängd skulle användas. P˚a samma sätt skapas ordlistan för rättstavning, tyvärr är inte den slutgiltiga lösningen för rättstavning implementerad i prototypen eftersom denna kom till först i slutet av projektet. Versionen av rättstavning som är implementerad i prototypen är inte helt felfri d˚a den ibland kan ge konstiga förslag, men själva grundidén finns där och den kommer vidareutvecklas av B Locket AB under detta ˚ar. De största delarna som tar hand om autocomplete i prototypen kan ses i bilaga A och bilaga B.

Det stora problemet inom rättstavning är framförallt särskrivning. Hunspell borde lösa detta när det implementeras, men det är väldigt viktigt att ordlistan som skapas uppdateras frekvent eftersom annonser kommer och g˚ar ofta. Hunspell löste detta problem när det utfördes tester p˚a sm˚a datamängder, risken är dock att den blir för l˚angsam när datamängden ökar. För att se ungefär hur det fungerar idag kan bilaga C vara intressant. Ett förslag är att ordlistan skapas samtidigt som indexeringen sker, mest för att mins-ka antalet tillfällen som s˚a tunga operationer görs. Slutsatsen som kan dras av hela rättstavningsimplementationen är att det egentligen inte är en rättstavare. Det är mer korrekt sagt, en förslagsgivare som ger förslag p˚a vad det är användaren kan ha menat som sökord, där förslaget ger fler träffar.

Om Hunspell blir för krävande är väldigt sv˚art att svara p˚a i dagsläget. Det här beror p˚a att en modifikation har gjorts av själva biblioteket där det blir en slags förslagsgivare istället för en rättstavare som det är i grunden. Det kan dock inte fattas ett slutgiltigt beslut om det är för krävande eller ej förrän det faktiskt testats fullt ut, vilket tyvärr inte tidsramen tillät.

P˚a relativt sm˚a datamängder (ca 100 000 ord) klarar Hunspell av att leverera ett förslag inom en tillfredsställande tid, nämligen under 0,5 sekunder.

Autocomplete däremot var n˚agot som den nuvarande sökmotorn 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 är för att den enbart behövde kunna söka i stora textmängder tidigare. Lucene däremot har denna funktionalitet och därför användes denna.

Lucene är väldigt enkelt och har ett väldigt tydligt API1, vilket gjorde att det gick betydligt snabbare att implementera autocomplete-funktionaliteten än om en sökmotor skulle byggts fr˚an grunden. Autocomplete fungerar s˚a pass bra att den skulle kunna

(41)

implementeras nästan p˚a en g˚ang, anledningen till detta är för att den testats med www.blocket.se:s alla annonser redan och ger d˚a svar inom 0-100ms, vilket är en till-fredsställande tid enligt B Locket AB.

4.2 Framtida arbete

Vad kan göras för att förbättra de undersökta delarna i framtiden? Autocomplete

Om annonsmängden blir större kan denna funktionalitet behöva f˚a sig en omstrukturering, ifall effektiviteten skulle p˚averkas avsevärt vill säga.

Eftersom autocomplete m˚aste vara en snabb tjänst är det bra om datamängden h˚alls nere, anledningen till kravet p˚a snabbhet är för att det ska vara ett hjälpmedel och inte ett störande moment i användarens upplevelse av besöket p˚a www.blocket.se. Detta skulle till exempel kunna göras genom att indexeringen sker enligt huvudkategori eller till och med kategori. P˚a s˚a vis minskar datamängden, men samtidigt visas enbart funk-tionaliteten när huvudkategori eller som i andra fallet kategori valts, vilket kan vara en nackdel.

För att undvika autocomplete först nere i kategoriläge behöver applikationen testas med större datamängd och se ifall det p˚averkar snabbheten avsevärt eller om det fortfa-rande rör sig inom ungefär samma tidsram. Dessutom m˚aste denna funktionalitet testas p˚a www.blocket.se för att f˚a reda p˚a om det kommer att fungera i verkligheten, med verkligheten menas att flera personer använder tjänsten samtidigt.

Efter diskussion med personal p˚a B Locket AB kom en lösning fram som innebär att sorteringen sker p˚a län, kategori och underkategori. Om detta sen blir den slutgiltiga versionen kommer autocomplete att finnas i alla steg och dessutom ge mer relevanta förslag till användaren.

R¨attstavning

(42)

me-ning delas upp i ordpar och rangordnas efter hur m˚anga g˚anger varje ord eller ordpar förekommer. Detta gör att särskrivningar undviks till största delen även om det finns en liten risk för att det kan hända att en särskrivning kommer som förslag änd˚a. Detta skulle kunna förbättras enbart om algoritmerna som finns idag hanterade särskrivning p˚a andra sätt. Med andra ord behöver det testas nya sätt att komma runt detta problem. Synonymer

Här m˚aste det göras en ordentlig lista p˚a vilka ord som är synonymer till vilka för att f˚a s˚a m˚anga träffar som möjligt. Detta skall ocks˚a implementeras i B Locket AB:s nuvarande sökmotor, vilket inte gjorts under detta projekt.

Stemming

(43)

Litteraturf¨

orteckning

[1] Ajax, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Ajax_ (programming).

[2] Allemansr¨atten, kontrollerad senast 20100104. http://www.sverigeturism.se/ smorgasbord/smorgasbord/natrecspo/nature/every.html.

[3] Bloomfilter f¨or r¨attstavning, kontrollerad senast 20100104. http://en.wikipedia. org/wiki/Bloom_filter.

[4] Browser-side-cache, kontrollerad senast 20100104. http://ajaxpatterns.org/ Browser-Side_Cache.

[5] Cache, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Cache. [6] Extreme programming, the agile method, kontrollerad senast 20100104. http://

www.extremeprogramming.org/.

[7] Hashing, functions and tables, kontrollerad senast 20100104. http://www.itl. nist.gov/div897/sqg/dads/HTML/hash.html.

[8] HTTP och dess specifikationer, kontrollerad senast 20100104. http://www.w3.org/ Protocols/rfc2616/rfc2616.html.

[9] Hunspell, spellchecking, stemming and morphological analysis, kontrollerad senast 20100104. http://hunspell.sourceforge.net/.

[10] Indexering, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Index_ (search_engine).

[11] Inverted index, kontrollerad senast 20100104. http://www.itl.nist.gov/div897/ sqg/dads/HTML/invertedIndex.html.

(44)

[13] Jaro-winkler, algoritm f¨or avst˚andsm¨atning mellan ord, kontrollerad senast 20100104. http://www.itl.nist.gov/div897/sqg/dads/HTML/jaroWinkler. html, http://en.wikipedia.org/wiki/Jaro-Winkler_distance.

[14] Javascript kontrollerad senast 20100104. http://en.wikipedia.org/wiki/ JavaScript.

[15] jquery autocompletion, kontrollerad senast 20100104. http://plugins.jquery. com/project/auto-complete.

[16] Kth:s spr˚akvetenskapliga avdelning, implementering av en r¨attstavningsalgoritm, kontrollerad senast 20100104. ftp://ftp.nada.kth.se/pub/documents/Theory/ Viggo-Kann/TRITA-NA-9813.pdf.

[17] Lemmatization, kontrollerad senast 20100104. http://www.diegesis.co.uk/ glossary.html#L.

[18] Levenshteins distance algorithm for comparison between strings, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Levenshtein_distance.

[19] Lucene search engine, kontrollerad senast 20100104. http://lucene.apache.org/ java/docs/.

[20] Lucenes r¨attstavningsimplementation, kontrollerad senast 20100104. http://wiki. apache.org/jakarta-lucene/SpellChecker.

[21] Memcached, ett s¨att att f¨ordela belastningen, kontrollerad senast 20100104. http: //www.danga.com/memcached/.

[22] Morphological analysis, kontrollerad senast 20100104. www.cl.ut.ee/yllitised/ smugri_toolbox_2001.rtf.

[23] Mythes, a method for synonym fetching, kontrollerad senast 20100104. http:// lingucomponent.openoffice.org/thesaurus.html.

[24] N-grams, kontrollerad senast 20100104. http://www.w3.org/TR/ngram-spec/. [25] Open-office, open-source alternative to microsofts office package, kontrollerad senast

20100104. http://www.openoffice.org/.

(45)

[27] Scriptaculous autocompletion, kontrollerad senast 20100104. http://wiki.github. com/madrobby/scriptaculous/ajax-autocompleter.

[28] Snowball stemming, a library for stemmingalgorithms, kontrollerad senast 20100104. http://snowball.tartarus.org/.

[29] Solr search platform, kontrollerad senast 20100104. http://lucene.apache.org/ solr/#intro.

[30] Soundex, kontrollerad senast 20100104. http://www.creativyst.com/Doc/ Articles/SoundEx1/SoundEx1.htm.

[31] Spider in search engines, also called web crawling, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Web_crawling.

[32] Stemming, kontrollerad senast 20100104. http://people.dsv.su.se/~hercules/ papers/karlgrendalianisjongejan-LREC2008_final.pdf.

[33] Submission-throttling, kontrollerad senast 20100104. http://ajaxpatterns.org/ Submission_Throttling.

[34] S¨okmotorns beskrivning, kontrollerad senast 20100104. http://en.wikipedia.org/ wiki/Web_search_engine.

[35] S¨okstr¨ang, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Web_ search_query.

[36] Bart Jongejan Jussi Karlgren, Hercules Dalianis. Experiments to investigate the connection between case distribution and topical relevance of search terms in an information retrieval setting, kontrollerad senast 20100104. http://people.dsv. su.se/~hercules/papers/karlgrendalianisjongejan-LREC2008_final.pdf. [37] Johan Carlberger Viggo Kann Rickard Domeij, Ola Knutsson. Granska - ett effektivt

(46)

Bilaga A

Autos.java

Spellchecking code for Lucene/Solr. 1 import j a v a . i o . I OE x ce pt i on ; 2 import j a v a . i o . P r i n t W r i t e r ; 3 4 import j a v a x . s e r v l e t . S e r v l e t E x c e p t i o n ; 5 import j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t ; 6 import j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e q u e s t ; 7 import j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e s p o n s e ; 8 9 import o r g . apache . s o l r . c l i e n t . s o l r j . S o l r Q u e r y ; 10 import o r g . apache . s o l r . c l i e n t . s o l r j . S o l r S e r v e r E x c e p t i o n ;

11 import o r g . apache . s o l r . c l i e n t . s o l r j . i m p l . CommonsHttpSolrServer ; 12 import o r g . apache . s o l r . c l i e n t . s o l r j . r e s p o n s e . S p e l l C h e c k R e s p o n s e ; 13 import o r g . apache . s o l r . common . params . M o d i f i a b l e S o l r P a r a m s ;

14 15 /∗ ∗

16 ∗ S e r v l e t i m p l e m e n t a t i o n c l a s s Autos 17 ∗ Handles t h e ” Did You Mean : ” r e q u e s t s 18 ∗/

19 public c l a s s Autos extends H t t p S e r v l e t {

20 private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 1L ; 21

(47)

24 private S t r i n g q u e r y ( S t r i n g q ) { 25 S t r i n g sugg = n u l l ; 26 CommonsHttpSolrServer s e r v e r = n u l l ; 27 28 try { 29 s e r v e r = new CommonsHttpSolrServer ( ” h t t p : / / l o c a l h o s t : 8 9 8 3 / s o l r ” ) ; 30 } catch ( E x c e p t i o n e ) { e . p r i n t S t a c k T r a c e ( ) ; } 31 32 // e s c a p e s p e c i a l c h a r a c t e r s 33 M o d i f i a b l e S o l r P a r a m s params = new M o d i f i a b l e S o l r P a r a m s ( ) ; 34 S o l r Q u e r y q u e r y = new S o l r Q u e r y ( ) ; 35 params . s e t ( ” q t ” , ” / s p e l l ” ) ; 36 params . s e t ( ” s p e l l c h e c k ” , ” t r u e ” ) ; 37 params . s e t ( ” s p e l l c h e c k . onlyMorePopular ” , ” t r u e ” ) ; 38 params . s e t ( ” s p e l l c h e c k . c o l l a t e ” , ” t r u e ” ) ; 39 params . s e t ( ” s p e l l c h e c k . q” , q ) ; 40 q u e r y . add ( params ) ; 41 q u e r y . s e t Q u e r y ( ” ∗ : ∗ ” ) ; 42 43 try { 44 S p e l l C h e c k R e s p o n s e q r = s e r v e r . q u e r y ( q u e r y ) . g e t S p e l l C h e c k R e s p o n s e ( ) ; 45 i f ( q r != n u l l ) { 46 s ugg = q r . g e t C o l l a t e d R e s u l t ( ) ; 47 } 48 } catch ( S o l r S e r v e r E x c e p t i o n e ) { 49 50 } 51 52 return sugg ; 53 } 54