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

Á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)

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

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)

Egy keresőmotor sémája

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

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

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!

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

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?

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!

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

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.

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!!

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

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!

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

γ 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:

γ 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 = <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

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

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.

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

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”

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

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

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

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)

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

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

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!

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:

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!

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

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

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

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ó!

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)

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

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

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

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

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

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