Információ Visszakeresés

Az előadások a következő témára: "Információ Visszakeresés"— Előadás másolata:

1 Információ Visszakeresés
A diák nagyban támaszkodnak a Stanford Egyetem „Information Retrieval and Web-mining” kurzusának anyagára:

2 Áttekintés Mi az IR? Indexelés Rangsorolás Google röviden
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 Invertált index Minden T tokenre, tároljuk a T-t tartalmazó dokumentumok listáját. Miben tároljuk? tömb Brutus 2 4 8 16 32 64 128 Calpurnia 1 2 3 5 8 13 21 34 Caesar 13 16 Mi van akkor ha a Caesar szó bekerül a 14-es dokumentumba?

11 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 Szótár Brutus Calpurnia Caesar 1 2 3 5 8 13 21 34 13 16 Napló Dokumentum ID szerint rendezve!

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

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 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 2 34 128 2 4 8 16 32 64 1 3 5 13 21 4 8 16 32 64 128 Brutus Caesar 2 8 1 2 3 5 8 13 21 34 Ha a két lista hossza m és n, az összefésülés időigénye O(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 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: A kód egy kettes szorzó mellett optimális!
9 = <1110,001> (7 bit) 23 = <11110, 0111> (9 bit) 1040 = < , > (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 Teljes hossz =
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ó Szótár Index Kb 45 MB 4 byte gyakoriságra
4 byte a Napló pointer 3 byte a szó 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 Stopwords
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 Feldolgozás ugrólistákkal
16 128 128 2 4 8 16 32 64 8 31 31 1 2 3 5 8 17 21

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
Legyen a = (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 aP a helyzetünket leíró vektor Ha a az egyensúlyi állapot, akkor a=aP Megoldva a mátrixegyenletet kapjuk a-t Tehát a a P má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 (mondjuk x=(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án xP2 , utána xP3 … Kellően nagy k-ra, xPk = a. Algoritmus: szorozzuk x-et a P má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 Here is a great picture of a tiger
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