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

Antony and Cleopatra Julius Caesar The Tempest Hamlet Othello Macbeth

Antony 1 1 0 0 0 1

Brutus 1 1 0 1 0 0

Caesar 1 1 0 1 1 1

Calpurnia 0 1 0 0 0 0

Cleopatra 1 0 0 0 0 0

mercy 1 0 1 1 1 1

worser 1 0 1 1 1 0

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

Calpurnia

Caesar

1 2 3 5 8 13 21 34

2 4 8 16 32 64128

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

Brutus

Calpurnia

Caesar

2 4 8 16 32 64 128

2 3 5 8 13 21 34

13 16

1

Szótár Napló

Dokumentum ID szerint rendezve!

Invertált index létrehozása

Tokenizáló

Token stream Friends Romans Countrymen

Nyelvi modulok

Normalizált tokenek friend roman countryman

Indexelő

Invertált index

friend

roman

countryman

2 4

2

13 16

1

Dokumentumok Friends, Romans, countrymen.

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.

34

1282 4 8 16 32 64

1 2 3 5 8 13 21

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

34

2 4 8 16 32 64

1 2 3 5 8 13 21

Brutus

Caesar2 8

Ha a két lista hossza m és n, az összefésülés időigényeO(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:

1log2 K

K2log KKeltolás 2log2

γ 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

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.

k2log2

ii k 22 1 12 i

12/2 iNi

Szótár mérete, első gondolat• Fix hosszú bejegyzések tömbje

– 500K token; 28 byte/token = ~14MB.

Terms Freq. Postings ptr.

a 999,712

aardvark 71

…. ….

zzzz 99

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

….systilesyzygeticsyzygialsyzygyszaibelyiteszczecinszomo….

Gyakoiság Napló ptr Szó ptr.

33

29

44

126

Binary searchthese pointers

Teljes hossz =500KB x 8 = 4MB

Pointerek 4Mpozícióra log24M =

22bits = 3bytes

• A szótár egyetlen karakterlánc– Pointer a szó kezdetére

– Köv. pointer mutatja a szó végét

Index mérete• Napló

– Kb 45 MB

• Szótár– 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

– 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

1282 4 8 16 32 64

311 2 3 5 8 17 21318

16 128

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:

–

tdtdt dfntfw log,,

n

i ki

n

i ji

n

i kiji

kj

kjkj

ww

ww

dd

ddddsim

1

2,1

2,

1 ,,),(

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

AT&T Alice

SprintBob MCI

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

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