Informatik / CS342 / WS06/07 Multimedia Retrieval Kapitel 3: Web Retrieval Dr. Roger Weber, weber@inf.ethz.ch 3.1 Motivation: Problem des Web Retrievals 3.2 Grösse des Internets und Abdeckung durch Suchmaschinen 3.3 Ordnen der gefundenen Dokumente 3.4 Einbezug von Kontext 3.5 Aufbau einer Suchmaschine
3.1 Motivation: Problem des Web Retrievals Kollektion Datenmenge Dokumente, Multimedia Struktur der Dokumente Dokumentenbeziehungen Qualität des Dokumenteninhalts Anfragen Klassisches Text Retrieval Kontrollierter Bestand; z.b. assortierte Bücher in einer Bibliothek; klein bis gross (1MB - 20 GB [TREC]); Zusammentragen der Daten ist einfach homogene Dokumente (z.b. nur Text, alle Daten in einer Datenbank) homogen (jedes Buch in Bibliothek hat Titel, Autor, Verlag, etc.) häufig keine; bei Artikeln und Bücher findet man Referenzen auf andere Werke; Qualität der Referenzen ist gut meistens gut bis sehr gut meist präzise und länger Web-Retrieval Unkontrollierter Bestand; jeder kann publizieren was er will ( my hompage,..., Schiller s Gedichte) sehr gross (alleine Textdokumente: >200GB); Zusammentragen der Daten ist ein grosses Problem (WebCrawler) und häufig unvollständig heterogene Dokumente; selbst Textdokumente kommen in verschiedenen Formaten daher (HTML, PDF, ASCII) heterogene Inhalte; der Inhalt eines Dokumentes kann beliebig präsentiert werden Dokumente enthalten viele eingehende und ausgehende Links (das Erfolgskonzept des Webs). Qualität der Links ist variabel variabel; Dokumente können fehlerhaft, grammatikalisch nicht korrekt oder unvollständig sein; zudem versuchen einige Leute Suchmaschinen mit (z.t. versteckten) Fehlinformationen auf ihre Seiten zu locken. kurze, z.t. unpräzise Angaben Antworten häufig wenige aber gute Treffer (<100) sehr viele Treffer (>100,000)
Problem des Ordnens Wegen der enormen Anzahl von Dokumenten und den relativ kurzen Anfragen (2-5 Wörter) erhält man häufig mehr als 100,000 Dokumente mit einem RSV>0 (auch mit Booleschem Retrieval). Aber nicht alle Treffer sind gleich relevant: z.b. liefert die Anfrage ford 84,800,000 Treffer in Google. Einige dieser Treffer sind offizielle Seiten von Ford, andere Seiten aber verunglimpfen die Marke. Google liefert aber trotzdem nur offizielle Seiten des Autoherstellers Ford. Der erste Eintrag ist aber nicht irgendeine Seite von Ford, sondern die Einstiegsseite Wie geht das? Google macht doch nur boolesche Suche! Die Suchmaschinen ordnen die Treffer nicht nur oder gar nicht nach dem RSV-Wert des Retrievals. Je nach RSV-Funktion würden sonst nur die Seiten oben erscheinen, welche genau die gleiche Häufigkeit der Terme haben wie die Anfrage (Kosinus- Mass), bei welchen die Anfrageterme am häufigsten auftreten (inneres Vektorprodukt), oder welche alle Anfrageterme enthalten (Boolesches Retrieval, Probabilistisches Retrieval [BIR]) Das Resultat wäre in allen Fällen inakzeptabel, da nicht unbedingt die relevanten Einstiegsseiten gefunden werden. Zudem kann man sich mit Spaming auf gewisse Wörter abonnieren (d.h. die entsprechend präparierten Seiten erscheinen stets zuoberst im Resultat).
3.2 Grösse des Internets und Abdeckung durch Suchmaschinen Wie gross ist eigentlich das Internet? Wie viele Server gibt es, wie viele Seiten, und wie viele Tera-Bytes belegen alle Seiten? Und: wie kann man die Grösse des Internets überhaupt schätzen, zumal ja keine der grossen Suchmaschinen wirklich alle Seiten kennt? Schätzen der Anzahl Server [Giles99]: Annahme: Die IP-Adressen der Web-Server sind gleichförmig über den ganzen 32-Bit Adressraum verteilt Vorgehen: Wähle N zufällige IP-Adressen und überprüfe, ob ein Web-Server mit dieser IP-Adresse läuft. M sei die Anzahl gefundener Web-Server. Dann ist M/N die Dichte der Belegung der IP-Adressen; Giles hat 1999 folgenden Wert ermittelt: M/N 1/269 Damit gibt es ungefähr 2 32 * M/N 16.0 Millionen [Stand: Juli 1999] Problem: Diese Schätzung enthält auch nicht öffentliche Server, z.b. Drucker, welche via HTML wartbar sind, oder private Server mit Zugangskontrolle
Schätzen der Anzahl Web-Seiten overlap analysis [Bharat98] : Annahme: Suchmaschinen arbeiten unabhängig voneinander und haben eine zufällige Teilmenge des Internets indexiert. Idee: Suchmaschine B Suchmaschine A A A B Web B Sei N= Web die Grösse des Webs. Ferner sei p(a), p(b) und p(a B) die Wahrscheinlichkeit, dass eine zufällig gewählte Seite von Suchmaschine A, B, resp. A und B gefunden wird. Wegen der Unabhängigkeit gilt: p(a B)=p(A)*p(B) Ferner ist: A =N*p(A), B =N*p(B), A B =N*p(A B) Falls man A, B und A B bestimmen kann, so kann man mit den obigen vier Gleichung auch N berechnen: N = A * B / A B Bemerkung: Da die Suchmaschinen im allgemeinen keine zufällige Teilmenge des Internets indexieren und häufig dieselben Ausgangspunkte haben, ist die obige Abschätzung eine untere Schranke für die effektive Anzahl Seiten
Schätzen der Anzahl Web-Seiten (2) Vorgehen: A und B können bei den meisten Suchmaschinen angefragt werden Ermittle die Auftretenswahrscheinlichkeiten von Termen in einer genügend grossen Menge von Web-Seiten l=0; Wiederhole k Mal: Stelle eine Anfrage an Suchmaschine B und wähle zufällig eine Seite im Resultat. Erzeuge eine Anfrage für diese Seite mit den seltensten Termen, die auf der Seite vorkommen. Suche mit Hilfe dieser Terme in der anderen Suchmaschine (A). Wegen der Wahl der Terme erhält man höchstens ein paar Seiten. Erhöhe l falls die gewählte Seite auch in A indexiert ist Schätze das Verhältnis B / A B mit k/l Bestimme dann N AB = A * B / A B = A * k / l Berechne N AB für verschiedene Kombinationen von Suchmaschinen A, B und schätze die Anzahl Seiten mit dem Mittelwert der erhaltenen N AB -Werte
Entwicklung und aktuelle Kennzahlen Dez. 1997: > 320 Mio. Seiten Einzelne Suchmaschinen haben 1/3 des Webs indexiert; alle 6 grossen zusammen ca. 60% Feb. 1999: ca. 800 Mio. Seiten, Einzelne Suchmaschinen haben maximal 16% des Webs indexiert; die 11 grossen Suchmaschinen zusammen 42% 2.8 Mio. öffentliche WWW-Server, 16 Mio. Web-Server insgesamt durchschnittlich 18,7 KB/Seite (ohne Bilder); 14 TByte Daten Jan. 2000: > 1 Mrd. Seiten Einzelne Suchmaschinen haben zwischen 10%-15% des Webs indexiert 6.4 Mio. öffentliche WWW-Server (wovon 2.2 Mio. Mirrors oder nicht erreichbar); davon sind 60% Apache Server, 25% MS-IIS Anzahl Links auf www.yahoo.com: 751.974 Ende 2000: 3-5 Mrd. Seiten Suchmaschinen haben zwischen 10%-15% des Webs indexiert; Google hat eine Abdeckung von gut 30% (enthält aber auch nicht besuchte Seiten) 30-50 TByte Daten (HTML-Format) BrightPlanet: unterscheidet zwischen surface und deep web;surface Web sind alle öffentlich zugänglichen Seiten; deep web enthält auch alle privaten Seiten (Dokus) und Seiten, die mit Skripten erzeugt werden (Telefonbuch, e-banking, etc.) 800 Mrd. Seiten im deep Web, ca. 8000 TByte Daten 2005: 8 Mrd Seiten Das Deep Web ist noch weiter gewachsen. Genauere Zahlen sind aber sehr schwer schätzbar.
Gegenwärtige Indexgrössen im Vergleich Search Engine Reported Size Page Depth Google 8.1 billion 101K MSN 5.0 billion 150K Yahoo 4.2 billion 500K Ask Jeeves 2.5 billion 101K+ [Quelle: SearchEngineWatch, Stand: 2005] PageDepth: Maximale Textlänge, welche indexiert wird. Google charakterisiert also nur die ersten 101 Kilo-Bytes einer Seite. Neuere Zahlen: Google s Index hatte 2005 8 Mrd Einträge (gemäss Google Homepage); heute sind keine Angaben mehr vorhanden (-> end of search index size war mit Yahoo) Anfragen an Google lieferen geschätzte Grössen der Trefferliste; einige aktuelle Beispiele: A -> 18.3 Mrd, the -> 14.4 Mrd, www -> 24.4 Mrd, 1 -> 19.5 Mrd
3.3 Ordnen der gefundenen Dokumente Im Folgenden betrachten wir das Ranking von Google (soweit dokumentiert), welches trotz boolescher Suche sehr gute Präzision vorweisen kann. Die anderen Suchmaschinen verwenden z.t. ähnliche Konzepte (die genauen Rankingfunktionen sind aber Betriebsgeheimnis) Das Ranking beginnt bereits beim Extrahieren der Terme: zu jedem gefundenen Term wird die Position im Dokument, die relative Fontgrösse, Fontattribute (bold, italic) und der Kontext (Term ist in URL, Titel, Meta-Tag, Linktext oder im restlichen Dokument) gespeichert (sog. hit list ) der Linktext (text zwischen <A>...</A>) wird auch dem Zieldokument zugewiesen. Damit können auch Dokumente indexiert werden, welche der Crawler nicht gesehen hat, oder welche nicht indexierbar sind (z.b. Bilder, Video, Audio). Daher kann Google in über 8'058'044'651 (Stand: 1.4.2005) Dokumenten suchen, obwohl der Crawler nicht mal die Hälfte davon gesehen hat. Das eigentliche Ranking setzt sich aus mehreren Faktoren zusammen: Proximity der Terme, d.h. die Entfernung der Anfrageterme im Dokument Position im Dokument (URL, Linktext, Titel, Meta-Tag, restliches Dokument), Fontgrösse und Fontattribute PageRank Andere Ordnungskriterien ( gekaufter Ranglistenplatz)
3.3.1 Proximity von Termen Anfragen wie White House implizieren, dass die gesuchten Wörter direkt nacheinander im Dokument stehen sollten. Mit anderen Worten, ein Dokument welches das Fragment white house enthält ist höher zu bewerten als ein Dokument, das z.b. die Fragmente white car am Anfang und red house am Ende des Dokumentes enthält. Das Boolesche Retrieval (und auch das Vektorraumretrieval) würde aber beide Dokumente als gleich gut betrachten. Umsetzung in Google (am Bsp. white house ) die Positionen der beiden Terme wird ermittelt (mit hit list ). für jedes Positionspaar wir ein Proximity -Wert berechnet. Google benutzt 10 verschiedene Werte von nebeneinander bis zu sehr weit entfernt. Die Häufigkeiten dieser Proximity -Werte ergeben einen 10-dimensionalen Vektor. Der Proximity -Vektor wird mit einem Gewichtsvektor multipliziert; dies ergibt dann den Proximity -Wert für das Dokument für die gegebene Anfrage (der Gewichtsvektor wird aufgrund von Benutzerstudien und Feedback bestimmt)
Bsp: hit list [ white ] = { 1, 81, 156 }, hit list [ house ] = { 2, 82, 115, 157 } Abbildung jedes Positionpaars {(1,2), (1,82), (1,115), (1,157), (81,2), (81,82), (81,115),...} auf Proximity -Vektor Pos 1 2... 81 82... 115... 156 157... Term white house white house house white house (1,2) (81,82) (1,157) Proximity 1 (nebeneinander) 2 (nahe) 3 (...) 4 (...) 5 (weitere Umgebung) 6 (...) 7 (...) 8 (entfernt) 9 (...) 10 (sehr weit entfernt) Häufigkeit 3 0 0 1 1 0 0 1 2 3 dies ergibt z.b. den folgenden Vektor: p = [3, 0, 0, 1, 1, 0, 0, 1, 2, 3] Proximity des Dokumentes : z.b. w = [1.0, 0.9, 0.8, 0.7,..., 0.1] dann p T w = 5.6
3.3.2 Position im Dokument, Fontgrösse, Fontattribute Die Wichtigkeit der Terme hängt von ihrer Position im Dokument ab: Die meisten Anfragen an Suchmaschinen zielen mehr auf den Titel des Dokumentes als auf den Inhalt. Z.B. sind Anfragen der Form Hauptsitz des amerikanischen Präsidenten seltener (würde auch nicht zum Ziel führen!) als Anfragen der Form White House. Häufig werden auch Markenname, Personennamen oder Firmennamen für die Suche verwendet. Ferner enthalten Linktexte sehr präzise und prägnante Beschreibungen des Inhalts der Zielseite oder beschreiben gewisse allgemein bekannte Aspekte der Seite (z.t. auch in verschiedenen Sprachen), welche dort selber nicht zu finden sind. Schlussfolgerung: Dokumente bei denen Suchterme im Titel auftauchen, oder speziell hervorgehoben sind (grosser Font, fettgeschrieben), oder in einem Linktext zu diesem Dokument auftreten scheinen wichtiger zu sein als Dokumente bei denen die Terme nur irgendwo im Text auftreten (z.b. in der Form ich arbeite an der ETH Lausanne )
Umsetzung in Google Google zählt die Häufigkeit der Auftreten der Terme in den oben genannten Formen, multipliziert diese Häufigkeiten mit speziellen Gewichten und summiert sie zu einem zweiten Relevanzwert für das Dokument. Die Häufigkeitswerte sind ferner nach oben limitiert (z.b. <100). Damit ist Spaming oder die Beeinflussung der Relevanzberechnung schwieriger. Pos <TITLE> <META> <P> <B> <I> <H1> <H2>... linktext Häufigkeit 1 1 672 14 7 1 12 892 lim. Häufigkeit 1 1 100 12 7 1 12 100 Gewicht 5.00 4.50 0.05 3.00 2.70 4.00 3.60 7.50 866.6 Konsequenz: Google kann Namen und Begriffe recht gut mit den relevanten Seiten in Verbindung bringen. Spamming: verwendet eine Seite einen Begriff zu häufig, so wird die ganze Seite ignoriert (z.b. Wort macht mehr als 10% des Textes aus -> Spam)
3.3.3 PageRank Trotz der beiden vorangegangen Kriterien kann es immer noch passieren, dass unwichtige Seiten ganz oben sind. Z.B. würde die Anfrage ETH Zurich nicht nur die Einstiegsseite (http://www.ethz.ch) hoch bewerten sondern auch die Seite (http://www.inf.ethz.ch), da letztere auch die Terme ETH und Zurich im Titel und im Text gross geschrieben enthält. Ebenso sollte die Home Page eines frustrierten Studenten mit dem Titel Ich hasse die ETH Zurich nicht zuoberst erscheinen. Die Idee von PageRank (Google) ist es, die objektive Wichtigkeit der Seiten zu messen und bei der Relevanzzuweisung zu berücksichtigen. Z.B. wird die Einstiegseite der ETH von sehr vielen Surfern benutzt und wird von Tausenden von Stellen im Netz referenziert. Die Seite des frustrierten Studenten hingegen wird kaum besucht und nur einige, wenige Links zeigen darauf. Im Wesentlichen bestimmt PageRank, mit welcher Wahrscheinlichkeit ein sogenannter random surfer eine bestimmte Web-Seite im Netz besucht. Je höher die W keit, desto relevanter (objektiv, nicht query abhängig) scheint die Web Seite zu sein. Im Beispiel würde die ETH Einstiegsseite bestimmt mit grösserer W keit besucht als die Seite des frustrierten Studenten.
Einfaches Modell (noch nicht PageRank) Idee man zählt die Anzahl eingehender Links einer Seite; je grösser diese Zahl, desto eher wird eine Surferin auf der Seite landen: z.b. A 1 C 6 C ist die wichtigste Seite, gefolgt von D, A und B B 1 D 3 Probleme: nicht jede Seite ist gleich wichtig. Falls eine Seite z.b. von Yahoo! referenziert wird, so ist die Seite wohl relevanter (bessere Qualität) als eine Seite die von irgend einer obskuren Seite referenziert wird. Spamming: Um das Ranking einer Seite zu Erhöhen kann man Dutzende von Web-Seiten im Netz platzieren, welche die eigene Seite referenzieren (wird z.t. auch mit Domain-Namen gemacht)
Berechnung des PageRank einer Seite Neue Idee: ein random surfer klickt auf einer Seite A mit Wahrscheinlichkeit p einen der N ausgehenden Links. Mit Wahrscheinlichkeit (1-p) hüpft er zufällig auf eine beliebige Seite (z.b. durch Eintippen einer URL; Bookmarks; Suchmaschine) der PageRank einer Seite ist dann die Wahrscheinlichkeit, dass der random surfer nach unendlich vielen Sprüngen auf dieser Seite landet. Umsetzung: Es werden die eingehenden Links einer Seite betrachtet; aber auch die Wichtigkeit der Linkquelle wird beim Zählen berücksichtigt Notationen: A eine beliebige Webseite L(A) Menge der Seiten, welche einen Link auf A haben N(A) Anzahl der ausgehender Links der Seite A PR(A) PageRank der Seite A p W keit, dass Surfer einen ausgehenden Link benutzt ( [0,1] ) Definition des PageRanks: PR( A) = (1 p) + p PR( B) B L ( A) N( B)
Intuitive Erklärung der Formel Der Wert eines Links ist gegeben durch den PageRank der Ursprungsseite und der Anzahl ausgehender Links von dieser Seite (d.h. jeder Link wird mit gleicher Wahrscheinlichkeit von einem random surfer verfolgt) (1-p) + p*... entspricht im random surfer Modell der Annahme, dass der Surfer mit W keit 1-p auf eine beliebige Seite wechselt und mit W keit p einen Link der Seite verfolgt. Beispiel: A 0.4 0.2 B 0.2 0.2 A und C haben gleichen PageRank, obwohl A nur einen eingehenden Link aufweist (C hat zwei) 0.4 0.2 C 0.4 PR(C)
Berechnung Die Formel ist rekursiv! Die PR()-Werte lassen sich aber via Fixpunktiteration berechnen (der Aufwand ist minimal im Vergleich zum Aufbau des Indexes für das boolesche Retrieval) Vorgehen: 1. Wähle zufällige Initialwerte für PR(A) für alle Dokumente A 2. Berechne PR (A) gemäss obiger Formel für alle Dokumente A 3. Falls PR (A)-PR(A) genügend klein ist, dann ist PR(A)=PR (A) die Lösung andernfalls setze PR(A)=PR (A) und gehe zu Schritt 2 Die Lösung der Fixpunktiteration erfordert nur wenige (<100) Schritte und kann in relativ kurzer Zeit (mehrere Stunden) berechnet werden
Anwendung PageRank liefert eine totale Ordnung der gefundenen Dokumente im Web. Diese Ordnung hängt nicht von den Suchtermen ab, d.h. bei allen Anfragen werden die Dokumente in der gleichen Reihenfolge geordnet Google verwendet PageRank zusammen mit allen anderen Kriterien. PageRank kann nicht leicht von aussen manipuliert werden, z.b. um eine gewisse Seite wichtiger erscheinen zu lassen als sie ist. Auch wenn sehr viele Links auf eine Seite zeigen, muss dies noch lange nicht bedeuten, dass die Seite einen hohen PageRank hat. Damit wird spamming fast unmöglich. Das Ordnen von Dokumenten nur mit PageRank wäre fatal. Sei A das Dokument mit dem grössten PageRank Anfragen mit Termen, welche alle in A vorkommen, hätten A als bestes Resultat, obwohl es noch relevantere Dokumente geben könnte.
3.3.4 Andere Ordnungskriterien Gekaufter Ranglistenplatz Viele Suchmaschinen verkaufen Ranglistenplätze für gewisse Suchbegriffe z.b. Google/AltaVista: Werbung RealName
Länge der URL Eine Anfrage wie ford könnte z.b. folgende Seiten zurückliefern http://www.ford.com/ http://www.ford.com/helpdesk/ http://www.careers.ford.com/main.asp http://www.ford.com/servlet/ecmcs/ford/index.jsp?section=ourservi ces&level2=rentalsfromdealers Suchmaschinen bewerten kurze URLs besser als lange URLs, in der Annahme, dass eine kurze URL eher auf eine Einstiegsseite verweist. User Feedback direct hit verwendet Feedback von Benutzern, um Seiten zu ordnen. Falls ein Dokument kontinuierlich ignoriert wird (d.h. die Suchenden klicken nicht auf dessen Link, obwohl es in der Antwort erscheint), so wird das Dokument bzgl. der Suchterme nicht relevant sein (ist evtl. sogar junk oder spam). In darauffolgenden Suchen wird das Dokument weiter hinten eingereiht. Intern wird dies ähnlich wie PageRank mit einem zusätzlichen Relevanzwert verwaltet. Falls ein Dokument in der Antwort angeklickt wird, so wir der Relevanzwert (bzgl. der Suchterme) erhöht, andernfalls verkleinert. Auch Google experimentierte mit Feedback
3.3.5 Overall Ranking Alle Suchmaschinen verwenden mehrere Ordnungskriterien. Google z.b. verwendet Proximity der Wörter Relevanzwert für die Position und Fontgrössen der Auftreten der Terme PageRank Die totale Relevanz ergibt sich aus einer gewichteten Summe der Einzelwerte. Die Gewichte und Zusammensetzung der Relevanzwerte ist das eigentliche Erfolgsrezept der Suchmaschinen.
3.4 Einbezug von Kontext Beobachtung: Im Web findet man viele Seiten zu demselben Thema (z.b. Star Wars); häufig sind diese Seiten eng miteinander verknüpft, d.h. sie referenzieren sich gegenseitig. Zudem findet man in Übersichtsseiten viele Links zu ähnlichen Seiten, welche dasselbe Thema diskutieren oder welche verwandte Seiten (related sites) auflisten z.b.: http://creativesoftwareinc.com/starwars/ listet viele Internetseiten rund um die Star Wars Filme auf (alle zum gleichen Thema) z.b.: http://www.carlynx.com/ listet Internetseiten für verschiedene Automarken auf (d.h. Zusammenstellung von verwandten Seiten) What s Related Ebenso: Falls viele Seiten, welche zu einem Thema T relevant sind, eine Seite A referenzieren, dann ist mit hoher W keit auch Seite A relevant für Thema T. Folglich: Hubs and Authorities Verbesserung der Suche durch explizite Benutzung von Kontextinformation über die Seiten (wie in den obigen Beispielen) Analog: Bereits bei der Anfrage den Kontext ermitteln (oder nachfragen beim Benutzer) (Teoma, AskJeeves, Gigablast)
3.4.1 Hubs und Authorities Eine Seite ist ein Hub für eine Anfrage Q, falls sie viele Links auf Seiten enthält, welche für Q relevant sind. Eine Seite ist eine Authority für Anfrage Q, falls sie für Q relevant ist (d.h. entsprechende Information zur Verfügung stellt). Typischerweise kann man Hubs und Authorities aufgrund der Linkstruktur erkennen: relevant bzgl. Anfrage Q relevant bzgl. Anfrage Q Hub Authority
Ferner gilt natürlich: ein guter Hub zeigt auf gute Authorities, und eine gute Authority wird von guten Hubs referenziert Aufgrund von Hub-Authority Beziehungen können auch relevante Dokumente identifiziert werden, welche die Anfrageterme nicht enthalten. Bsp: Eine Anfrage wie suche Autohersteller führt kaum auf die Webseiten von Honda, VW oder Ford. Mit der Analyse von Hub-Authority Beziehungen können solche Anfragen aber sinnvoll beantwortet werden. Idee von Kleinberg [1997]: HITS Algorithmus Das Web kann als gerichteter Graph betrachtet werden, wobei die Knoten die Seiten im Web und die Kanten die Links zwischen Dokumenten repräsentieren. Sei G = (V,E) dieser Graph, mit V der Menge der Dokumente (vertices; Knoten) und E der Menge der Links (edges; Kanten). Falls (p,q) E, so enthält Dokument p einen Link auf Dokument q. Schritt 1: Für eine Anfrage Q werden die ersten t (z.b. 200) Dokumente via AltaVista/Google bestimmt. Diese Menge von Dokumenten entspricht dem root set. Für dieses erste Resultat gilt i.a.: enthält viele relevante Dokumente enthält aber nicht alle guten Hubs/Authorities
Schritt 2: Das root set wird erweitert um Dokumente, welche von den Dokumenten im root set referenziert werden, oder welche Dokumente im root set referenzieren. Die so erhaltene Menge wird base set genannt. Damit diese Basismenge nicht zu viele Dokumente enthält, werden pro Dokument höchstens d (z.b. 50) Dokumente hinzugefügt, welche auf das Dokument zeigen (viele Seiten werden von mehreren Tausend Seiten referenziert) Links innerhalb derselben Domain werden entfernt (häufig stellen diese Links nur Navigationshilfen dar) root base
Schritt 3: Berechnen der Hub h(p) und Authority a(p) Gewichte für ein Dokument p. Dabei spielen die Anzahl eingehender Links und Anzahl ausgehender Links eine zentrale Rolle. eine einfache Lösung wäre: ( p) Dies führt aber dazu, das populäre Seiten wie Amazoon oder Yahoo! für die meisten Anfragen eine Authority darstellen würden (da sie sehr viele eingehende Links haben). Auf der anderen Seite wäre jede Linkliste (Bookmarks) ein guter Hub für eine Anfrage [falls die Seite im base set ist]. bessere Idee: ein guter Hub zeigt auf gute Authorities, und eine gute Authority wird von guten Hubs referenziert. Dies führt zu einer rekursiven Definition von a(p) und h(p): 2 2 a(p) und h(p) seien stets normalisiert, d.h. a( p) = 1 h( p) = 1 Initialisierung: alle Seiten haben die gleichen Werte a(p) und h(p) Iteration: die neuen Gewichte werden aus den alten wie folgt bestimmt a ( p) = h( q) Wiederhole Iteration bis zur Konvergenz a h( p) = = ( q, p ) E ( p, q) 1 h( p) = ( q, p ) E ( p, q) a( q) E p V 1 E p V Bem.: Obige Bedingung für a(p) und h(p) muss noch berücksichtigt werden.
Schritt 4: Berechne das Resultat falls Übersichtsseiten gewünscht werden, gebe die k besten Hubs zurück, d.h. die k Dokumente mit den höchsten h(p)-werten. falls Inhaltsseiten gewünscht werden, gebe die k besten Authorities zurück, d.h. die k Dokumente mit den höchsten a(p)-werten. Bemerkungen: Das interessante an diesem Ansatz ist, dass der Benutzer explizit zwischen Hubs und Authorities wählen kann. Eine Anfrage wie java kann zu einem Resultat mit vielen interessanten Linkseiten ( Hubs ) oder zu interessanten Dokumenten über dieses Thema ( Authorities ) führen. Die iterative Berechnung von a(p) und h(p) benötigt nur wenige Schritte (10-20). Im Gegensatz zum klassischen WebRetrieval dauert dies aber sicherlich länger. Antwortzeiten im Bereich von Minuten sind die Regel... Implementierung: eine einfache Implementierung benutzt z.b. AltaVista: das root set wird mit einer normalen Anfrage ermittelt die Bestimmung der ausgehenden Links erfolgt durch das Downloaden der Seite und dem Extrahieren der darin enthaltenen Links die Bestimmung der eingehenden Links kann mit Hilfe von AltaVista unter Benutzung einer link: u -Anfrage für die URL u erfolgen
Erweiterung von HITS (Henzinger, 1998) Der Algorithmus von Kleinberg kennt drei Probleme: 1. Falls alle Seiten einer Domäne eine einzelne, externe Seite referenzieren, so wird diese Seite zu stark als Authority gewichtet. Ebenso: falls eine Seite viele Seiten derselben Domäne referenziert, so wird diese Seite zu stark als Hub betrachtet. 2. Automatisch erzeugte Links (z.b. Werbebanner, Verknüpfung zum Hersteller des WebProduktes) führen zu falschen Authorities 3. Anfragen wie jaguar car führen dazu, dass generelle Seiten über Autos und Linkseiten über verschiedene Marken im Resultat dominieren (d.h. der Term car dominiert den Term jaguar ) Verbesserungen: Problem 1: Der gleiche Autor (=gleiche Domäne) kann nur eine Stimme für eine externe Seite abgeben. Analog: Ein Dokument kann insgesamt nur eine Stimme für die Seiten einer Domäne abgeben. Falls k Seiten p i einer Domäne ein Dokument q referenzieren, so wird das Gewicht aw(p i, q)=1/k für jeden Link (p i, q) gesetzt. Falls es von einer Seite p l Links zu Seiten q i einer anderen Domäne gibt, so wird das Gewicht hw(p, q i )=1/l für jeden Link (p, q i ) gesetzt. Damit wird der Iterationsschritt wie folgt geändert: a ( p) = aw( q, p) ( q, p ) E h( q) h( p) = ( p, q) E hw ( p, q) a( q)
Problem 2 und 3: Zur Lösung dieser Probleme werden Knoten aus dem Graphen entfernt, welche offensichtlich nichts oder nur wenig mit der Anfrage zu tun haben. Zu diesem Zweck wird eine künstliche Anfrage aus den Dokumenten im root set geformt und die Ähnlichkeit der Dokumente zu dieser Anfrage bestimmt: Die Anfrage setzt sich aus den ersten z.b. 1000 Wörter aller Dokumente im root set zusammen. Anfrage und Dokumente werden mit tf-idf Gewichtung in Vektoren transformiert (siehe Vektorraumretrieval) Die Ähnlichkeit s(p) (Dokument-Anfrage) wird mit dem Kosinusmass bestimmt. Für einen gegebenen Threshold t werden alle Knoten/Dokumente aus dem Graph entfernt, für welche s(p)<t gilt. Der Threshold kann mit einer der folgenden Funktionen bestimmt werden: t = median aller s(p)-werte t = median aller s(p)-werte der Dokumente im root set t = 1/10 max s(p) Dieser pruning Schritt erfolgt zwischen Schritt 2 und 3 im HITS Algorithmus. Ausserdem können die s(p)-werte bei der Berechnung der Hub- und Authority- Gewichte benutzt werden: a ( p) = aw( q, p) s( q) ( q, p ) E h( q) h( p) = ( p, q) E hw ( p, q) s( q) a( q)
Diskussion: Der HITS Algorithmus führt zu sehr viel besseren Resultaten als eine Suche mit nur der Suchmaschine (würde nur zu Dokumenten im root set führen). Vor allem weil auch Seiten, welche die Anfrageterme nicht enthalten, gefunden werden können. Google s Ansatz, den Linktext dem verlinkten Dokument zuzuweisen und die Benutzung von PageRank führen (wahrscheinlich) zu ähnlich guten Resultaten. Die Erweiterung des HITS Algorithmus bringt eine Steigerung der Precision bis zu 45%. Im Durchschnitt schneidet der erweiterte Algorithmus deutlich besser ab als HITS und kann auch von Google kaum übertroffen werden. Das Hauptproblem des HITS Algorithmus und dessen Erweiterung sind die recht langen Retrievalzeiten (30 Sekunden bis mehrere Minuten). Dies dürfte auch der Hauptgrund dafür sein, dass Google die Technologie nicht einsetzt. Im Vergleich zu PageRank arbeitet HITS query -spezifisch, d.h. die Ordnung der Dokumente hängt von der Anfrage ab. Die Ordnung, welche von PageRank induziert wird, ist hingegen statisch und beschreibt die objektive Wichtigkeit der Seite für einen durchschnittlichen Surfer. Obwohl PageRank ähnlich aufwendig in der Berechnung ist, fallen die Kosten aber nur einmal bei der Indexerzeugung an (HITS: bei jeder Anfrage).
3.4.2 What s Related Die Grundidee von Alexas What s Related ist, verwandte Dokumente zu einem bestehenden Dokument zu finden. Die Definition von What s Related basiert aber nicht auf der Ähnlichkeit der verwendeten Terme in zwei Dokumenten, sondern ob die Dokumente zwar über dasselbe Thema sprechen, aber in unterschiedlichen Varianten. Verwandte Seiten für www.ford.com sind www.toyota.com, www.vw.com, etc. Analog zu What s Related findet man auch in Google unter dem Stichwort Similar Page die Möglichkeit, verwandte Seiten zu suchen. Die Ansätze sind aber grundverschieden: Alexa ermittelt aufgrund von Crawlern und Data Mining Werkzeugen, welche Seiten verwandt sind (evtl. ähnlich wie Google). Während des Betriebs werden dann aber auch das Surfverhalten der Benutzer für die Verfeinerungen der What s Related Beziehungen benutzt. Das Hauptproblem dabei ist die Privatsphäre des Benutzers, da das Alexa Plug-in URLs und Benutzerdaten an einen zentralen Server sendet. Google verwendet nur die Linkstruktur der Web-Seiten, um verwandte Seiten zu finden. Ein Ansatz untersucht, welche Seiten zusammen in einem Dokument referenziert werden (co-citation). Falls z.b. sehr viele Seiten einen Link zu www.ford.com und www.toyota.com haben, so bedeutet dies, das die beiden Seiten ein verwandtes Thema behandeln.
Da keine (befriedigende) Informationen bzgl. des Algorithmus in Alexa existieren, betrachten wir im Folgenden zwei Vorschläge, welche im Umfeld von Google gemacht wurden (Dean, Henzinger, 1999). Die genaue Implementierung in Google ist mittlerweile auch nicht mehr öffentlich verfügbar. Companion Algorithmus (Dean, Henzinger, 1999) Der Ansatz basiert auf der eben besprochenen Erweiterung des HITS Algorithmus: Gegeben eine URL u: der Algorithmus findet all jene Seiten, welche verwandte Themen wie die Seite u enthalten. Terminologie: Falls die Seite w einen Link zur Seite v hat, so ist w eine Elternseite von v und v eine Kindseite von w. Schritt 1: Baue einen gerichteten Graphen in der Umgebung von u. Der Graph enthält dabei die folgenden Knoten u maximal b Elternseiten von u und für jede Elternseite maximal bf Kindseiten maximal f Kindseiten von u und für jede Kindseite maximal fb Elternseiten Schritt 2: Kontrahiere Duplikate oder fast -Duplikate. Zwei Dokumente sind fast -Duplikate, falls sie mehr als 10 Links besitzen, und 95% der Links in beiden Dokumenten vorkommen
Schritt 3: Bestimme Gewichte für die Kanten zwischen den Knoten Dies erfolgt analog zur Erweiterung des HITS Algorithmus, d.h. falls k Kanten von Dokumenten einer Domäne auf die gleiche externe Seite gerichtet sind, so haben diese Kanten das Gewicht 1/k. Umgekehrt, falls ein Dokument l Kanten zu Seiten einer Domäne besitzt, so bekommt jede dieser Kanten das Gewicht 1/l. Schritt 4: Berechne die Hub und Authority Gewichte für die Knoten gemäss der Erweiterung des HITS Algorithmus (aber ohne Ähnlichkeitsgewichte), d.h. a ( p) = aw( q, p) ( q, p ) E h( q) h( p) = ( p, q) E hw ( p, q) a( q) Schritt 5: Bestimme das Resultat Die Seiten mit den höchsten Authority -Gewichten (ausser u) stellen die ähnlichsten Seiten zur Startseite u dar.