Információ Visszakeresés

1. Információ Visszakeresés A diák nagyban támaszkodnak a Stanford Egyetem „Information Retrieval and Web-mining” kurzusának anyagára: http://www-csli.stanford.edu/~schuetze/information-retrieval-book.html

2. Áttekintés • Mi az IR? • Indexelés • Egyszerű index • Invertált index, Gamma-kódolás • Rangsorolás • TF-IDF rangsor • PageRank • Google röviden • Architektúra • További rangsorolási szempontok (amiket nem veszünk részletesen)

3. Információ Visszakeresés • IR alapprobléma • Adott egy korpusz(dokumentumok halmaza, internet) • Felhasználó az információigényét leginkább kielégítő dokumentumokat keresi • Lekérdezést fogalmaz meg • Cél a lekérdezésnek megfelelő dokumentumok listája

4. Egy IR rendszer legfontosabb jellemzői • Indexelés sebessége (nem fontos) • Lekérdezés sebessége • Lekérdező nyelv kifejezőereje (mit kérdezhetünk meg és mit nem?) • Pontosság (a legfontosabb, de a mérése összetett feladat)

5. Egy keresőmotor sémája

6. Indexelés vs. Adatbázis • Szövegek kollekciója feletti keresést támogat • De nem adatbázis! • Sok minden nem kell amit egy adatbázisszerver elvégez • Tranzakciók • Adatvesztés • A szöveget (az adatot) nem tároljuk, csak indexet • Optimalizálás szöveges lekérdezésre, nem pl. SQL-re

7. Egyszerű index • Szó-dokumentum mátrix (Di,j : i. szó szerepel-e a j-edik dokumentumban)

8. Egyszerű indexelés • Gyors • Az élet nem ilyen szép • Kivitelezhetetlen • 1 millió dokumentum, ~1000 token/dok, ~6byte/token • ~6GB korpusz • Legyen 500K különböző szóalak • 500K x 1M mátrix • ~60 GB index!

9. Invertált index • A szó-dokumentum mátrixban ~1 milliárd egyes van csak! (azaz rendkívül ritka) • Egyszerűbb, és jobb reprezentáció, ha csak az 1-esek pozícióit tároljuk • ekkor invertált indexről beszélünk

10. 2 4 8 16 32 64 128 1 2 3 5 8 13 21 34 Invertált index • Minden T tokenre, tároljuk aT-t tartalmazó dokumentumok listáját. • Miben tároljuk? • tömb Brutus Calpurnia Caesar 13 16 Mi van akkor ha aCaesarszó bekerül a 14-es dokumentumba?

11. Brutus Calpurnia Caesar Szótár Napló Listás megvalósítás jobb • Dinamikus helyfoglalás (különböző gyakoriságú szavak!!!)  • Könnyű beszúrás  • Pointerek extra helyfoglalás  2 4 8 16 32 64 128 1 2 3 5 8 13 21 34 13 16 Dokumentum ID szerint rendezve!

12. Tokenizáló Friends Romans Countrymen Token stream Nyelvi modulok friend friend roman countryman Normalizált tokenek roman Indexelő 2 4 countryman 1 2 Invertált index 16 13 Invertált index létrehozása Dokumentumok Friends, Romans, countrymen.

13. Az index használata • Hogyan dolgozunk fel 1 lekérdezést? • Milyen jellegű lekérdezéseket kezelünk? • Mit indexelünk? • Mindent, vagy csak fontos szavakat? (Mi fontos?) • Stopword lista: a leggyakoribb szavak elhagyhatók az indexből (sok hely, kevés haszon) • pl., the, a, an, of, to … • Nyelvfüggő elem, minden nyelvre kell stopword lista.

14. Brutus Caesar 13 128 2 2 4 4 8 8 16 16 32 32 64 64 8 1 1 2 2 3 3 5 5 8 8 21 21 13 34 Lekérdezés (naplólisták egyesítése) • Párhuzamosan megyünk végig a két naplólistán, időigény így arányos a listák összhosszával 128 2 34 Ha a két lista hosszamésn, az összefésülés időigényeO(m+n) Fontos: a listák dokID szerint rendezve legyenek!!

15. Mit kapunk, milyen áron? • Logikai (igen/nem) keresésre • Csak pontos egyezést ad vissza • Nincs rangsorolás • Sokáig ez volt az uralkodó technológia • Becslés a méretre? Vegyük az előző példát: • 1M dokumentum, átl. 1000 token hossz, átl. 6 byte/szó, ~500K különböző token

16. Becslés az invertált index méretére • Két különálló tényező szabja meg a méretet • Szótár mérete • Naplók mérete • Különböző dolgok jönnek szóba a méret optimalizálásakor • Szótárnál: pl. szótövezés (magyarban különösen fontos!) • Naplónál: dokID-ket tárolunk, tömörítés!

17. Napló tárolása • Tároljuk rendezve a dokumentum ID listát! • Ekkor elegendő csak az ID-k különbségeit tárolni („lyukak”) • ezek várhatóan átlagosan sokkal kisebb számok • Brutus: 33, 47, 154, 159, 202, … • Brutus: 33, 14, 107, 5, 43, … • Használjunk változó kódhosszúságú kódolást! • Calpurnia szó átlag minden egymilliomodik dokumentumban fordul elő, akkor azt log2 1M = ~20 biten szeretnénk tárolni • az szó szinte minden dokumentumban benne van, ezt az infot jó lenne ~1 bit helyen tárolni

18. γ kódolás • K számot egy <hossz, eltolás> párral írjuk le • hossz érték unáris kódolású(a számot leíró kód (eltolás) hosszát adja meg) • az eltolás bináris kódolású(megadja magát a számot) • K kódja • bites unáris kód • bites bináris kód • ahol:

19. γ kódolás • Példák: • 9 = <1110,001> (7 bit) • 23 = <11110, 0111> (9 bit) • 1040 = <11111111110,0000010000> (21 bit) • A kód egy kettes szorzó mellett optimális! • Ennél számottevően jobb tömörítést csak úgy érhetünk el, ha rendelkezünk információval a számok eloszlásáról

20. Zipf törvénye • A k-adik leggyakoribb szó gyakorisága nagyságrendileg ~1/k

21. Becslés Zipf törvénye alapján • A leggyakoribb szó N dokumentumban fordul elő (minden lyuk 1-es) 2. leggyakoribb N/2 dokumentumban (lyukak átlagosan 2 nagyságúak) … k-adik leggyakoribb N/k dokumentumban (átlagos lyuk nagyság N/k), bit tárolásra • Összegezve k = 1 … 500 ezerig • Összegzést végezzük úgy, hogy k darab csoportot tekintünk: • az i-edik csoportra , elemű, egyenként max . • N = 1 millió, i = 1 … 19-re szummázva kb 340 millió bit, azaz ~45 MB az index Napló részének mérete.

22. Szótár mérete, első gondolat • Fix hosszú bejegyzések tömbje • 500K token; 28 byte/token = ~14MB. 20 bytes 4 bytes each

23. A fix méret pazarló! • Angolra: • Átlagos szóhossz írott szövegben: 4,5 byte • Átlagos hossza az angol szavaknak: 8 karakter • Ráadásul a fix méret amúgy is problémás lehet! • „megszentségteleníthetetlenségeskedéseitekért”

24. Szótár tömörítése • A szótár egyetlen karakterlánc • Pointer a szó kezdetére • Köv. pointer mutatja a szó végét ….systilesyzygeticsyzygialsyzygyszaibelyiteszczecinszomo…. Teljes hossz = 500KB x 8 = 4MB Pointerek 4M pozícióra log24M = 22bits = 3bytes Binary search these pointers

25. Index mérete • Napló • Kb 45 MB • Szótár • 4 byte gyakoriságra • 4 byte a Napló pointer • 3 byte aszó pointer • Átl. 8 byte szavanként a szóláncban • 500K token~9.5MB • Index • ~55 MB

26. Indexméret • Szótövezés / kis-nagybetűs alak • Tokenek számát ~40%-al • Pointerek számát 10-20%-al • Méretet ~30%-al • Stopwords • 30-as szabály: ~30 szó tesz ki ~30%-ot az írott szövegekben! • A leggyakoribb szavak kivágása ~25% helyspórolást hozhat

27. Pár szó a lekérdezés sebességéről • Napló-listák lineáris időben egyesíthetők • Optimalizálás: • Célszerű a rövid listákkal kezdeni a műveletek elvégzését • Ugrólisták használata (index mérete növekszik így)

28. 128 31 17 2 4 8 16 32 64 1 2 3 5 8 21 Feldolgozás ugrólistákkal 128 16 31 8

29. Invertált index vége • Célszerű tárolni a dokumentumban a szóalak helyét • Kifejezés alapú lekérdezés támogatására • Ezzel az előbb nem törődtünk • Nagyobb index, de ezt használják a gyakorlatban • Alternatívája a bi- trigram alapú indexelés

30. Rangsorolás • Általában jó sok dokumentum illeszkedik 1-1 lekérdezésre • Több milliárdos korpuszból milliós nagyságrendű találat • Fontos, hogy a dokumentumokat rangsoroljuk, relevancia szerint!

31. tf-idf rangsorolás • Szavak súlya a tf, és idf szorzata: • Index készítésekor legyártható a súlyozás • „Ezt tároljuk el a szó-dokumentum mátrixban” • A lekérdezést is egy mini dokumentumra nézve a 2 vektor koszinusza adja a hasonlóságot:

32. PageRank • Ki a legbefolyásosabb ember? • Az Egyesült Államok elnöke • Az arab liga elnöke • A világbank elnöke • Ha én mind a hármat jól ismerem? • Egy adott ember fontossága függ az ismerősei befolyásától is! • Ez a web-gráfra is igaz • A jó lapokra sok (jó) lap mutat rá linkekkel!

33. Véletlen szörföző heurisztika • Egy robot véletlen bolyongást végez a weben • Linkek mentén lép tovább • Beragadást elkerülendő kis eséllyel (p) véletlen lapra lép tovább • Hosszú idő után az egyes lapok látogatottsága beáll egy stabil értékre, ami nagyon jól használható a lap fontosáságának mérésére

34. Bolyongás • A véletlen bolyongások Markov láncokkal modellezhetők • Az egyes állapotok közti átmenetek valószínűségeit sorsztochasztikus mátrixszal írhatjuk le

35. Az általunk leírt esetben • Minden állapotból mindegyikbe vezet él • Minden lépésben bármely állapotban >0 valószínűséggel lehetünk éppen • Irredúcibilis Markov lánc • A pontok hosszú távú látogatottsága egyértelműen definiált • Mindegy honnét indultunk

36. PageRank • Az oldalak rangja legyen a hosszú távú látogatottsági rátájuk! • Ez pontosan a web-gráfot leíró átmeneti mátrix sajátvektora lesz • Lekérdezésfüggetlen rangsor • Nehéz spammelni • A rangsorolást visszavezettük a sajátérték-sajátvektor problémára • Kiszámítható!

37. PageRank vektor számítása • Legyena= (a1, … an)a legnagyobb sajátértékhez tartozó sajátvektor (PageRank) • Ha az aktuális pozícióa, akkor a következő lépésben aPa helyzetünket leíró vektor • Haaaz egyensúlyi állapot,akkora=aP • Megoldva a mátrixegyenletet kapjuka-t • Tehátaa Pmátrix baloldali sajátvektora • (mely épp a legnagyobb sajátértékhez tartozik)

38. Hatványiteráció • Ismert algebrai módszer • Véletlen vektorból indulva minden iterációban a vektorunkat szorozzuk az átmeneti mátrixszal • Megállunk ha a vektor már alig változik (stabil) • Bárhonnan indulunk, a bolyongást leíró vektor a-hoz tart • Tehát induljunk egy egy weblapról (mondjukx=(10…0)). • Egy lépés után xPírja le az helyzetünket (valószínűségek) • Két lépés utánxP2 , utánaxP3… • Kellően nagy k-ra, xPk = a. • Algoritmus: szorozzukx-eta Pmátrixszal amíg a szorzat kellően nem stabilizálódik

39. PageRank értékelése • A lekérdezéstől független a lapok sorrendje • Nehéz spammelni • Nagyon sikeresnek bizonyult • Nem önmagában, hanem sok már heurisztikával karöltve használják

40. Adatbázisuk ~25-30 milliárd indexelt dokumentumot tartalmaz • A rendszert egyszerű PCk szolgálják ki • Tízezres nagyságrendű géppark • ~5PB RAM • Tárolják az indexelt dokumentumokat (offline feldolgozás) • Tömörítő (ZIP) algoritmus optimalizálása /sebesség-tömörítési ráta/ • Biztonság: szándékos redundancia (minden dokumentum 3-6 példányban) • Saját linux rendszer • Sikerük: • Testreszabott hardversturktúra • Nagyon jó rangsor

41. Google index • További, rangsorolásra használt elemek • Kiemelt helyen lévő előfordulás (pl. cím, hivatkozó szöveg /anchor-text/, …) • Query/Hit relevancia (milyen gyakran választják az adott találatot) • Hubs/authorities (hub – forrás; authority – szakértő)a gráfstruktúrát használja, de másképp mint a PageRank • Stb. • a kulcs a visszafejthetetlenség • a jó rangsor • optimalizálás

42. Hubs-Authorities Hub pontszám h(x) – Attól függ milyen jó szakértőket linkelek Authority pontszám a(x) – Attól függ mennyi, milyen jó forrás mutat rám  Iteratív módszer

43. Anchor text elemzés • A hivatkozó szöveg a linkelt dologra nézve reprezentatív! Here is a great picture of a tiger Cool tiger webpage