3.1 3 Implementierungstechniken 3.1 Kompression von invertierten Dateien Warum? Parameter des Index: N = Anzahl Dokumente n = Anzahl Terme f t = Dokumentfrequenz f = f t Anzahl Dokumentverweise Dokumente sind intern mit durchnumeriert (DocId: 1, ,N), also keine URL o.ä. Index im Hauptspeicher Keine Plattenzugriffe Effiziente Anfragebearbeitung

3.2 Kompression.... Fehlt noch

3.3 Repräsentation von Inverslisten Repräsentation der Dokumentverweise Darstellung der DocId als 32-Bit-Integer? Sehr aufwendig Darstellung in ld N Bits: bei N = 1 Mio Dokumente mehr als ein Drittel Speicherplatz gespart, dennoch ebenfalls nur bei Externspeichereinsatz brauchbar Beobachtung: Während der Anfragebearbeitung müssen Postinglisten aller Terme, die in Anfrage vorkommen, vollständig bearbeitet werden (im Vektorraummodell) Folgerung: Invers- (Posting-)liste enthält Differenzen aufeinanderfolgender DocIds (Differenzliste) Beispiel: [ 3211, 3213, 3219, 3225] Direkte DokIds [ 3211, 2, 6, 6] Differenzliste

3.4 Anfrageauswertung (Inverslisten) 3.2 Anfrageauswertung mit Inverslisten Datenstruktur term1, ft1 Termi, fti Term n, ft´n (d1,fd1t) (dk,fdkt).... (d ft1,.. ) (dk,)... (dj,)....., d ftn ),.. Term-Wörterbuch, Eintrag für Term t verweist auf Postingliste, enthält zusätzlich das die Dokumentfrequenz f ti Neben den Verweisen in der Posting- (oder Invers-) liste auf Dokumente dj werden meist auch die Termfrequenzen f djt gespeichert. Zunächst sortiert nach Dokid d

3.5 Anfragebearbeitung mit Inverslisten Inversliste mit Termfrequenzen Dokumentfrequenzen ft und Termfrequenzen fdjt können bei ausschließlich booleschen Anfragen entfallen Termfrequenzen werden statt der daraus abgeleiteten (reellwertigen) Termgewichte für jedes Dokument gespeichert, da reelle Zahlen schwer komprimierbar. Kompression mit unärem Code sinnvoll: Empirische Werte: Bibel-KollektionTREC Termvorkommen F ~884 Tsd.~333 Mio Dkumentverweise f ~ 701 Tsd.~ 134 Mio F/f 1-2 bzw. 3 Unärer Code sinnvoll Speicherbedarf für Postinglisten wächst um F Bits

3.6 Boolesche Anfragen AND, OR, NOT werden auf Schneiden, Mischen und Komplement von Inverslisten zurückgeführt. AND Besonderheiten: Kandidatenmenge kann nie kleiner werden Deshalb: initiale Treffermenge = kürzeste Inversliste -> auch im rein Booleschen Fall sollte Dokumentfrequenz f t für Term t im Wörterbuch enthalten sein. Frage: wie verwaltet man das Wörterbuch? A) effizienter Zugriff zu Termen (Baum, Hash, Feld?) B) geordnet nach f t B) ist nicht wichtig. Anzahl der Frageterm klein gegenüber Gesamtanzahl Terme n -> Lesen der WB-Einträge, sortieren nach f t -Wert

3.7 Boolesche Anfragen Mit jeder Reduktion der Treffermenge wird der Anteil der DocIds aus der Inversliste des nächsten konjunktiven Terms kleiner, der überhaupt betrachtet werden muss (Mengenschnitt) Kompression hier hinderlich: trotz nach DocId sortierter Postinglisten keine binäre Suche möglich Bsp: t1 AND t2... AND tk : Treffermenge enthält noch 100 Treffer, tk – Postingliste enthält Verweise pro Treffer ca. 500 Vergleichoperationen Indexierung der Inverslisten? Problem bei Booleschen Anfragen: kleine Änderungen können Antwortmengen dramatisch vergrößern t1 AND t2 im Vergleich zu NOT (t1 AND t2 ) !

3.8 Rangfolgebestimmung mit Cosinusmaß Zur Erinnerung: Cos2(dj,q) = 1/ (Wj*Wq) * ( 1 + log f t,j ) * log (1 + N/f t ) W j = ( w t,j 2 ) w t,j = g(f t, f tj ) Anfrageunabhängige Normierungsgröße W j vorab berechenen Akkumulatoren für Gewichte aller in Frage kommender Dokumente Prinzipielle Auswertung für Anfrage q Lies für jeden Term t aus q (t, f t, Zeiger auf Inversliste) aus Wörterbuch Für jede Inversliste: Für jedes Dokument d: berechne Gewicht wtj und addiere auf Akkumulator [d] Normiere die A-Werte mit W d Suche die r Dokumente mit maximalen Akkumulatorwerten

3.9 Rangfolgebestimmung mit Cosinusmaß Algorithmus 1. Initialisiere leere Akkumulatordatenstruktur 2. Für jeden Term t in q - ggf linguistische Vorbehandlung - lies Wörterbucheintrag (t, ft, Pointer) 3. Sortiere absteigend nach ft-Werten (Warum) 4. Für jeden Term t - berechne wt = f(N, ft) - lies Posting-Liste - für jeden Eintrag (dj, fd,t) in Postingliste - wenn kein Acc[dj] erzeuge Acc[dj]=0 - Acc[dj] = Acc[dj] + f'(fd,t) * wt 5. Für alle Acc: Acc[d] = Acc[d] / Wd 6. Selektiere die mit höchstem Rang

3.10 Rangfolgebestimmung mit Cosinusmaß Größenordnung : Anzahl f tmittel = Dokumentverweise / Anzahl verschiedener Terme: Bibel: ~ 90, TREC: ~ 260 (Gleichverteilung angenommen) In Webkollektionen sehr viel mehr -> Suchmaschinen Gesamtzahl Dokumentgewicht-Akkumulatoren: acc q = f tmittel * Anzahl Anfrageterme Dokumentgewichte W d Effiziente Verwaltung von Dokumentgewichten W d Für jedes Dokument individuelles, vorab berechnetes Gewicht -> Hintergrundspeicher Organisationsform hängt von erwartetem acc q ab (Anfrage- und Kollektionsabhängig) accq klein gegen N : direkter Zugriff über Hash-Tabelle oder Baumstruktur, sonst: alle Gewichte einlesen Heuristik zur Verringerung: Zusammenfassen mehrer Werte d1, d2, dN 0,00 0,050,931,00 1N' << N

3.11 Rangfolgebestimmung mit Cosinusmaß Akkumulatoren Wenn zuviel während Anfrageabareitung entstehen: Heuristiken - quit: Bearbeitung abbrechen Vorteil: Schnelle Antwort Nachteil: Hohe Termfrequenzen gehen evtl. verloren (wt ist gering – Sorierung -, fdt kann hoch sein und damit Rangfolge verändern - continue: Bearbeitung fortsetzen, aber keine neuen Dokumente berücksichtigen (Acc-Anzahl einfrieren)

3.12 Rangfolgebestimmung mit Cosinusmaß r ranghöchste Dokumente ausgeben Einfache Methode: Acc nach Größe sortieren Beachte: r << k = Anzahl Acc Heapdatenstruktur (Max-Heap) O(k) Schritte, Auslesen der r Ranghöchsten Besser: Suche der r ranghöchsten Dokumente mit Min-Heap: (Kleinstes Element "oben") Erzeuge Min-Heap mit den ersten r Acc-Werte Für alle weiteren acc[d] : wenn acc[d] < als Min verwirf acc[d], sonst entferne Min (Min = acc[d'] mit minimalem Wert unter den r im Heap) Zum Schluss bleiben die r Ranghöchsten übrig

3.13 Frequenzsortierte Inverslisten Vorteile Ein-Term-Anfragen t : Inversliste für t ist das Ergebnis Unvollständige Auswertung der Inverslisten bei korrektem Ergebnis, wenn r << N Dokumente reichen. Voraussetzung: acc[d] (r+1) = Gewicht des derzeit (r+1)-ten Dokuments bekannt Inverslisten werden parallel abgearbeitet: jeweils der i-te Eintrag aller Inverslisten wird bearbeitet, i=1,2,... Wieviel Gewichtszuwachs maxG kann ein beliebiges Element maximal noch erfahren, wenn schon bis Position i abgearbeitet?? Wegen monoton fallender Termfrequenzen f t,d in Inversliste für t gilt: maxG <= g(f t,i+1 ) * g'(f t ) g, g' Funktionen, die Gewicht in Abhängigkeit von f t,i+1, f t berechnen, z.B. Cosinusmaß Abbruchkriterium: acc[d] (r+1) + g(f t,i+1 ) * g'(f t ) <= acc[d] r d.h. max. Gewichtszuwachs kann Dokument auf Rang r+1 nicht verbessern

3.14 Frequenzsortierte Inverslisten Nachteil: keine Kompression? Beobachtung: Termfrequenz im allgemeinen klein (z.B. ~ 3 in TREC-Daten) Idee: fasse Dokumente mit gleicher Termfrequenz zusammen. Postingliste: [(f' t, k, [docId]) mit k = Anzahl Docs mit Termfrequenz f' t Beispiel: [(5,17=, (3,15), (3,11), (1,11)] [(5;1,[17]), (3;2,[10,4]), (1,1,[11]) Differenzliste der partiellen DocId-Folge