1 / 14

3 Implementierungstechniken

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,2......,N), also keine URL o.ä.

ilana
Download Presentation

3 Implementierungstechniken

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Kompression.... Fehlt noch

  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, dennochebenfalls nur bei Externspeichereinsatz brauchbar • Beobachtung: Während der Anfragebearbeitung müssenPostinglisten 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    

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

  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-Kollektion TREC 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

  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 ft 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 ft • B) ist nicht wichtig. Anzahl der Frageterm klein gegenüber Gesamtanzahl Terme n -> Lesen der WB-Einträge, sortieren nach ft-Wert

  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 50000 Verweisepro 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 ) !

  8. Rangfolgebestimmung mit Cosinusmaß • Zur Erinnerung:Cos2(dj,q) = 1/ (Wj*Wq) * (1 + log ft,j ) * log (1 + N/ft) Wj = ( w t,j 2)w t,j = g(ft, ftj) • Anfrageunabhängige Normierungsgröße Wj 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 , ft, 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 Wd • Suche die r Dokumente mit maximalen Akkumulatorwerten

  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

  10. Rangfolgebestimmung mit Cosinusmaß • Größenordnung : • Anzahl ftmittel = Dokumentverweise / Anzahl verschiedener Terme: Bibel: ~ 90 , TREC: ~ 260 (Gleichverteilung angenommen) • In Webkollektionen sehr viel mehr -> Suchmaschinen • Gesamtzahl Dokumentgewicht-Akkumulatoren: accq = ftmittel * Anzahl Anfrageterme • Dokumentgewichte Wd • Effiziente Verwaltung von Dokumentgewichten WdFür jedes Dokument individuelles, vorab berechnetes Gewicht -> Hintergrundspeicher Organisationsform hängt von erwartetem accq 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 1 N' << N 0,00 0,05 0,93 1,00 d1, d2, ...........................dN

  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)

  12. Rangfolgebestimmung mit Cosinusmaß • r ranghöchste Dokumente ausgeben • Einfache Methode: Acc nach Größe sortierenBeachte: 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 Minverwirf acc[d], sonst entferne Min (Min = acc[d'] mit minimalem Wert unter den r im Heap) • Zum Schluss bleiben die r Ranghöchsten übrig

  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 ft,d in Inversliste für t gilt: maxG <=  g(ft,i+1) * g'(ft)g, g' Funktionen, die Gewicht in Abhängigkeit von ft,i+1, ft berechnen, z.B. Cosinusmaß • Abbruchkriterium: acc[d] (r+1) +  g(ft,i+1) * g'(ft) <= acc[d] rd.h. max. Gewichtszuwachs kann Dokument auf Rang r+1 nicht verbessern

  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

More Related