Kap. 2: Web Retrieval. 2.1 Motivation: Problem des Web Retrievals

Transkript

1 Kap. 2: Web Retrieval Motivation: Problem des Web Retrievals Grösse des Internets und Abdeckung durch Suchmaschinen Ordnen der gefundenen Dokumente Einbezug von Kontext Hubs and Authorities What s Related Kontextsensitive Anfrageerweiterung Focused Crawling Aufbau einer Suchmaschine Übersicht Kap 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) Kap.2-2

2 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 5,480,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). Kap 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 Kap.2-4

3 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 Kap.2-5 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 Stelle eine Anfrage an Suchmaschine A resp. 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 (B resp. A). Wegen der Wahl der Terme erhält man höchstens ein paar Seiten. Erhöhe A B falls die Seite mit Suchmaschine A und B gefunden werden kann. Wiederhole die letzten drei Schritte genügend oft. Bestimme dann N AB = A * B / A B 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 Kap.2-6

4 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 -Server, 16 Mio. Web-Server insgesamt durchschnittlich 18,7 KB/Seite (ohne Bilder); 14 TByte Daten Jan. 2000: > 1Mrd.Seiten Einzelne Suchmaschinen haben zwischen 10%-15% des Webs indexiert 6.4 Mio. öffentliche -Server (wovon 2.2 Mio. Mirrors oder nicht erreichbar); davon sind 60% Apache Server, 25% MS-IIS Anzahl Links auf 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) 19 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.) 550 Mrd. Seiten im deep Web, ca TByte Daten Kap.2-7 Gegenwärtige Indexgrössen im Vergleich GG: FAST: AV: INK: NL: Google Fast AltaVista Inktomi NorthernLight [Quelle: SearchEngineWatch, Stand: ] Kap.2-8

5 Entwicklung der Suchmaschinengrössen GG: FAST: AV: INK: NL: Google Fast AltaVista Inktomi NorthernLight [Quelle: SearchEngineWatch, Stand: ] Kap 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 1,346,966,000 (Stand: ) 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) Kap.2-10

6 2.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 Positionenpaar 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) Kap.2-11 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 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 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 Kap.2-12

7 2.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. Bsp.: die Suche eth lausanne führt mit Google sofort zur Hauptseite der EPFL. Auf dieser aber, kann man die Wörter ETH und Lausanne nicht finden (nur EPFL ) 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 ) Kap.2-13 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 lim. Häufigkeit Gewicht Konsequenz: Google kann Namen und Begriffe recht gut mit den relevanten Seiten in Verbindung bringen. Kap.2-14

8 2.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 ( hoch bewerten sondern auch die Seite ( 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. Kap.2-15 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) Kap.2-16

9 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) Kap.2-17 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 B 0.2 C A und C haben gleichen PageRank, obwohl A nur einen eingehenden Link aufweist (C hat zwei) PR(C) Kap.2-18

10 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 Kap.2-19 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. Kap.2-20

11 2.3.4 Andere Ordnungskriterien Gekaufter Ranglistenplatz Viele Suchmaschinen verkaufen Ranglistenplätze für gewisse Suchbegriffe z.b. Google/AltaVista: Werbung RealName Kap.2-21 Länge der URL Eine Anfrage wie ford könnte z.b. folgende Seiten zurückliefern 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. Kap.2-22

12 2.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. Kap 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.: listet viele Internetseiten rund um die Star Wars Filme auf (alle zum gleichen Thema) z.b.: 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. Hubs and Authorities Folglich: 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) (Grouper, AskJeeves, metacrawler) Kap.2-24

13 2.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 Kap.2-25 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, 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 Kap.2-26

14 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 Kap.2-27 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: a( p) = 1 h( p) = 1 ( q, p ) E ( p, E 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 die gleichen Werte a(p) und h(p) Iteration: die neuen Gewichte werden aus den alten wie folgt bestimmt a ( p) = h( h( p) = ( q, p ) E ( p, a( E Wiederhole Iteration bis zur Konvergenz p V p V Bem.: Obige Bedingung für a(p) und h(p) muss noch berücksichtigt werden. Kap.2-28

15 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 -Anfrgae für die URL u erfolgen Kap.2-29 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, =1/k für jeden Link (p i,gesetzt. Falls es von einer Seite pllinks 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( h( p) = ( p, E hw ( p, a( Kap.2-30

16 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 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, p ) E h( h( p) = ( p, E hw ( p, s( a( Kap.2-31 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 referenzierten 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 Algorithmuses 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). Kap.2-32

17 2.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 sind 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 und haben, so bedeutet dies, das die beiden Seiten ein verwandtes Thema behandeln. Kap.2-33 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 Kap.2-34

18 Schritt 3: Bestimme Gewichte für die Kanten zwischen den Knoten Dies erfolgt analog zur Erweiterung des HITS Algorithmuses, 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 Algorithmuses (aber ohne Ähnlichkeitsgewichte), d.h. a ( p) = aw( q, p) ( q, p ) E h( h( p) = ( p, E hw ( p, a( Schritt 5: Bestimme das Resultat Die Seiten mit den höchsten Authority -Gewichten (ausser u) stellen die ähnlichsten Seiten zur Startseite u dar. Kap.2-35 Cocitation Algorithmus (Dean, Henzinger, 1999) Dieser einfachere Ansatz bestimmt, ausgehend von einer Seite u, wie häufig eine Seite q zusammen mit u referenziert wird. Die Seite mit den häufigsten cocitations werden als die ähnlichsten Seiten zu u betrachtet. Schritt 1: Bestimme maximal b Elternseiten von u. Schritt 2: Bestimme nun für jede Elternseite maximal bf Kindseiten, wobei die Links zu den Kindseiten in der Nähe des Links zu u liegen müssen. All diese Kindseiten sind Geschwister -Seiten von u. Schritt 3: Bestimme jene Seiten q i, welche am häufigsten zusammen mit u referenziert werden. Schritt 4: Falls nicht mehr als 15 Seiten mehr als zweimal zusammen mit u referenziert werden, so wird die Suche neu gestartet mit gekürzter URL. Z.B. falls u= war, so wird erneut für u = gesucht. Falls dies nicht zum Erfolg führt wird mit u = und dann mit u = gesucht. Kap.2-36

19 Diskussion: Die Vorschläge von Dean und Henzinger arbeiten im Durchschnitt deutlich besser als Alexa (es fehlen aber noch grosse, unabhängige Untersuchungen). Wegen der Ungewissheit, wie Alexa verwandte Seiten findet, kann aber kein qualitativer Vergleich gemacht werden. Letztlich ist auch unklar, welche Technologie bei Google (GoogleScout) eingesetzt wird (der billige Co-Citation Algorithmus oder der teure Companion Algorithmus) Kap Kontextsensitive Anfrageerweiterung Die Idee der kontextsensitiven Anfrageerweiterung besteht darin, dem Benutzer gezielt auf Mehrdeutigkeiten seiner Anfrage aufmerksam zu machen. Z.B. findet man für die Anfrage salsa heterogene Antworten aufgrund der mehrfachen Bedeutung des Wortes (Essen, Tanz, Musik). Einfache Ansätze: Tippfehler werden erkannt und es werden Korrekturvorschläge gemacht (Google) Falsche Verwendung/Konkatenation bei der Anfrage werden explizit gemacht (CiteSeer). Generische Anfrageterme werden mit spezifischeren Vorschlägen angereichert (AskJeeves, HotBot) MetaCrawler: Der MetaCrawler bedient sich mehrerer Suchmaschinen: eine Anfrage wird gleichzeitig an die Suchmaschinen geschickt; die Antwortmengen werden vereint, bereinigt und neu geordnet. Der MetaCrawler untersucht die erhaltenen Dokumente und versucht sie in Kategorien aufzuteilen gemäss der verwendeten Terme in den Dokumenten. Z.B. enthalten alle Tanzseiten den Term Tanz, Musik oder Schritt, während die Salsa -Seiten im Bereich Essen eher die Terme Rezept oder Zutaten verwendet. Kap.2-38

20 2.4.4 Focused Crawling Das Web umfasst mehrere Milliarden Seiten, welche nur mit enormen Aufwand eingelesen werden können. Google benötigt etwa 30 Tage um einen neuen Index mit 600 Millionen Seiten zu erzeugen (+700 Millionen Dokumente, von denen nur die Existenz über Links bekannt ist). Focused Crawling versucht diesen Aufwand zu reduzieren, indem nur wichtige Seiten im Web auch tatsächlich betrachtet werden. Zudem können sehr wichtige Seiten häufiger aufgefrischt werden als unwichtige. Google, auf der anderen Seite, verliert mit jedem Tag an Aktualität. Häufig können neue Seiten nicht gefunden werden (z.b. neue Zeitungsartikel). Einige Zahlen zu Crawlern (1999) AltaVista (Scooter) 4x533 MHz AlphaServer /300, 1.5GB memory, 30 GB RAID disk, 1GB/s IO bandwidth (network) Inktomi (HotBot,...) Cluster mit mehreren hundert Sun Sparc workstations, zusammen 75 GB memory und 1 TB disk 10MillionenSeitenproTag Google 4 Linux Rechner, Software in Python, eigene DNS lookup tables bis zu 100 Seiten pro Sekunde (ca Millionen Seiten pro Tag) Kap.2-39 Trotz eines Durchsatzes von 10 Millionen Seiten pro Tag dauert es mehrere Monate, bis alle Seiten des Internets gelesen wurden. Das Hauptproblem der Crawler von Inktomi, AltaVista und Google ist, dass sie für alle möglichen Anfragen Antworten im Internet finden müssen. Beim Focused Crawling hingegen werden nur Antworten für bestimmte Themen erzeugt. Solch einen Focused Crawler könnte man auch auf seinem eigenen Rechner laufen lassen, oder aber für spezialiserte Suchen verwenden (z.b. search engine für Biologie). Chakrabarti (1999) Der WebCrawler setzt sich aus drei Komponenten zusammen classifier: Analysiert die Relevanz des Dokumentes bzgl. der ausgewählten Themen. Falls das Dokument relevant ist (resp. die W keit relevant zu sein einen gewissen Wert überschreitet), so werden dessen Links ebenfalls untersucht. distiller: bestimmt ein Mass der Wichtigkeit der Dokumente welches eine Ordnung auf den Links definiert. So können die nächsten Links berechnet werden und auch wie häufig eine Seite besucht werden soll. crawler: besucht Seiten gemäss den berechneten Prioritäten Kap.2-40

21 2.5 Aufbau einer Suchmaschine Eine Suchmaschine besteht aus mehreren Komponenten (Brin, Page) Crawler/Repository: Ein Crawler (auch Spider genannt) iteriert selbständig durch die Datenkollektion (z.b. Web: verfolgen von Links). Falls die Suchmaschine auch Kontrolle über die Dokumentenkollektion hat, so braucht es keine Crawler dafür Repositories (d.h. Behälter und Schnittstelle zu den Dokumenten) Merkmalsextraktor: Extrahiert charakteristische Merkmale aus den Dokumenten. Bei Text sind dies Terme, bei Bilder Vektoren (für Farbe, Textur,...), bei Videos Sequenzen und Text, etc. Die Merkmalsextraktion dient auch dazu, die Datenmenge zu verkleineren und besser zu organisieren. Indexierer: Verwaltet die extrahierten Merkmale der Dokumente und erlaubt einen effizienten Zugriff über diese Merkmale (Bsp: invertierte Liste) Sortierer: Eine Anfrage liefert typischerweise sehr viele Dokumente zurück, aber ein Benutzer kann sich nur wenige davon anschauen. Der Sortierer ordnet die Dokumente gemäss ihrer (geschätzten) Relevanz für den Suchenden. Feedback Komponente: Informationssuche besteht häufig nicht nur aus einem isolierten Schritt sondern aus vielen Iterationen. Eine Feedback-Komponente unterstützt den Benutzer bei der Verfeinerung der Anfrage User Interface: Ermöglicht das Eingeben von Anfragen und präsentiert die Resultate in einer übersichtlichen Art und Weise Kap.2-41 Beispiel: Google [Brin Page] URL Server Crawler Store Server Anchors Indexer Repository URL Resolver Links Doc Index Barrels Sorter Lexicon PageRank Searcher Kap.2-42

22 2.6 Übersicht der Suchmaschinen Gute Übersichten zu den aktuellen Suchmaschinen und Crawlern, ihrer Qualität, ihrer Grösse, etc. findet man unter anderem auf folgenden Seiten: SearchEngineWatch: BrightPlanet Studie: Inktomi WebMap : SearchEngineShowdown: Internet Domain Survey: Evaluating the size of the Internet : Internet Surveys & Statistics : Crawler: Die folgende Tabelle zeigt eine Zusammenstellung der wichtigeren Suchmaschinen (z.t. auch spezialisierte Suchmaschinen) Kap.2-43 Übersicht Suchmaschinen Name Wie? Was? freshness coverage Sonstiges google.com Volltextsuche ca. alle 30 Tage 1.5 Mrd., aber ca. 2 Mrd. Seiten coverage über Link- Struktur berücksichtigte als erste SE Link- Struktur! altavista.com raging.com Volltextsuche plus spezielle Dienste (z.b. Audio/Bildsuc he), mind. Alle 28 Tage ca. 550 Mio. Seiten seit 1995, enthält auch einen Translation Service inktomi.com Volltext alle 60 Tage ein Crawl... Inktomi Engine: 110(+390) Mio. Seiten, zweistufiger Index. Technologie von Inktomi, ebenso Snap, Yahoo, HotBot,Microsoft,.. alltheweb.com Volltextsuche 625 Mio. Seiten Stellt Technologie für Portale... Volltextsuche mit Gruppierung der Resultate N.A. 1,5 Mrd Seiten (?) Kap.2-44

23 Name Wie? Was? freshness coverage Sonstiges northernlight. com Volltext, aber auch spezielle Inhalte ( special collection ), die nicht direkt ueber (öffentl.) verfuegbar 390 Mio. Seiten unterstützt: and, or, not,(),+,- lycos.com Portal mit Kategorien, aber auch Volltextsuche ca. 575 Mio. Volltextsuche von Fast yahoo.com hotbot.com Kategorien + Volltext Kategorien + Volltext ca. 500 Mio. ca. 500 Mio. Volltext von Inktomi, es gibt aber auch google.yahoo.co m Volltext von Inktomi metacrawler.co m Meta- Suchmaschine n.a. n.a. Bei Anfrage werden andere SEs abgefragt Kap.2-45 Name Wie? Was? freshness coverage Sonstiges directhit.co m Volltextsuche, aber unter Einbeziehung von Benutzerverhalte(Feedback) wird u.a. bei HotBot und Lycos eingesetzt... iwon.com Volltextsuche, Inktomi ca. 500Mio, Datenbestand ist GEN3 von Inktomi Portal, wo man Bonuspunkte sammelt mit jeder Suche citeseer.com Volltextsuche, Citationmatching PDF/PS- Dokumente, die im erreichbar sind mehr als Dokumente, über 4 Mio. Referenzen search.ch Volltextsuche speziell für schweizer - Seiten. Die wenigsten dead links.ch-domain vivisimo.com Meta-Suchmaschine mit clustering der Resultate nach Kategorien n.a. n.a. Kap.2-46

24 Name Wie? Was? freshness coverage Sonstiges groups.google. com ehemals: Volltext Newsgroups über Newsgroups (12/97) >700 Mio Mitteilungen reicht mittlerweile zurück in die Anfänge des USENET (1981)! copernic.com Meta-Suchmaschine Client-side, kann 80 SEs verwenden, wie AltaVista, DirectHit, Google,... qbsearch.com Meta- Suchmaschine, Resultatseiten verschiedener SEs werden in einer Seite dargestellt. n.a. n.a. Bei Anfrage werden andere SEs abgefragt teoma.com Volltext, clustering und proprietäres Linkanalyse- Verfahren, um relevante Seiten zu identifizieren. momentan noch kleiner Datenbestand (ca. 100Mio. Seiten?) Beta-Phase Kap.2-47 Software für Agenten, Roboter und Merkmalsextraktion Software für Suchmaschinen (Glimpse & WebGlimpse) (Harvest) (AltaVisa SearchEngine) Remote Search Services Kap.2-48

25 Literatur und Links Google Inc. Google: S. Brin, L. Page, The Anatomy of a Large-Scale Hypertextual Web Search Engine, 7, 1998 L. Page et. al., The PageRank Citation Ranking: Bringing Order to the Web, work in progress, Monika Henzinger: Monika Henzinger, "Web Information Retrieval", Tutorial, ICDE'2000 (16th International Conference on Data Engineering); What s Related AlexaResearch ( What s Related ) direct hit: Google: Jeffrey Dean and Monika R. Henzinger. Finding Related Web Pages in the World Wide Web. Proceedings of the 8th International World Wide Web Conference (8), 1999, pp Grouper: Kap.2-49 Literatur und Links (2) Leitzahlen des Internets [Bharat98] Krishna Bharat and Andrei Broder, A technique for measuring the relative size and overlap of public Web search engines, 7, 1998, [Giles99] - Steve Lawrence, Lee Giles, "Accessibility of information on the web", Nature, Vol. 400, pp , 1999 [SEW] SearchEngineWatch: [BP] BrightPlanet Studie: [Ink00] Inktomi WebMap : [SES] SearchEngineShowdown: Internet Domain Survey: Evaluating the size of the Internet : Internet Surveys & Statistics : Übersicht WebRetrieval [SEW] Übersicht WebIR-Systeme: Links to image database systems: Multimedia Information Sources: Kap.2-50