3. Automatische Indexierung:
3.4 Text REtrieval Conference (TREC)
Die Text Retrieval Conference(s) (TREC) sind eine Evaluierungsinitiative und werden seit 1992 immer im November am „National Institute of Standards and Technology (NIST)“ abgehalten. Die Konferenz wird vom „Information Technology Office of the Defense Advanced Research Projects Agency” und dem „US Department of Defense Advanced Research and Developement Activity“ unterstützt (Vgl. Voorhees/Harman, 2002).
Die Konferenz will die Forschung von Informations-Retrieval-Technologien fördern und hat sich deswegen vier Ziele gesetzt:
· Retrievalforschung für große Testkollektion anregen
· Die Kommunikation zwischen der Industrie, der Wissenschaft und der Regierung zu steigern, indem ein offenes Forum für den Austausch von Forschungsideen geschaffen wurde.
· Eine Beschleunigung des Technologietransfers von Forschungseinrichtungen in kommerzielle Produkte zu erreichen. Substantielle Verbesserungen in Retrieval-methoden, die der reellen Welt entsprechen, sollen veranschaulicht werden.
· Die Verfügbarkeit von passenden Evaluierungstechniken, die von der Industrie und den Wissenschaften genutzt werden können, zu erhöhen. Das beinhaltet auch die Förderung der Entwicklung von neuen Evaluierungstechniken, die ge-eignet für die derzeitigen Systeme sind (Ebd.).
Am TREC 2001 nahmen 87 Gruppen aus 21 Ländern teil, die sowohl wissenschaftli-che Einrichtungen (die Hauptgruppe) als auch kommerzielle Firmen und Regierungs-institutionen umfassten (Ebd.). Die Anzahl der Teilnehmer bedeutete eine Steigerung von 25 % gegenüber dem Vorjahr und zeigt somit eine deutliche Bedeutungssteige-rung der Konferenz, die mit 25 Teilnehmern in TREC 1 (Vgl. Harman, 1993) anfing.
TREC 2001 (die 10. Konferenz) verzeichnete sechs Tracks und zwar:
· „Cross-Language Information Retrieval Track“
· „Filtering Track“
· „Interactive Track“
· „Question Answering (QA) Track”
· „Video Track“
· „Web Retrieval Track“ (Voorhees/Harman, 2002)
Die Tracks sind von TREC zu TREC immer etwas unterschiedlich. Erstmalig wurde der „Video Track“ abgehalten. Die anderen „Tracks“ fanden sich schon in früheren Konferenzen, jedoch änderten sich im Jahr 2001 teilweise die einzelnen Aufgaben-stellungen innerhalb der Tracks (Vgl. Ebd.). Nicht übernommen in den TREC 2001 wurde der „Spoken document Track“ sowie der „Query Track“ (Vgl.
Voorhees/Harman, 2001).
Die Track-Struktur begann in TREC 3. Diese Tracks dienen verschiedenen Zwecken.
Hier sollen zum einen neue Forschungen berücksichtigt werden. Außerdem soll die Robustheit von Kernretrievaltechniken in verschiedenen Aufgabenstellungen getestet werden. Zuletzt sollen diese Tracks in TREC attraktiv für die Forschung sein, indem deren Forschungsinteressen in größerem Maße berücksichtigt werden (Vgl.
Voorhees/Harman, 2002).
In TREC werden drei Retrieval-Aufgabentypen unterschieden, die „ad hoc-retrieval task“, eine „known-item-search“ und eine „document routing oder filtering task“
(Ebd.).
Die „ad-hoc retrieval task“ reflektiert die willkürliche und kurze Literatursuche in ei-ner Bibliothek. Hier ist die Dokumentensammlung bekannt, aber man kennt nicht die Fragen, die an diese Sammlung gestellt werden. Andere Beispiele sind Internet- und Patentrecherchen oder die Suche von Analysten nach bestimmten, archivierten Be-richten (Ebd.).
Eine „known-item-search“ ähnelt der „ad-hoc retrieval task“, hat allerdings zum Ziel, ein bestimmtes Dokument (oder eine kleine Sammlung) zu finden, deren Existenz der Nutzer kennt (Ebd.).
In der „document routing oder filtering task“ ist der Gegenstand des Interesses bekannt, aber die Dokumentensammlung ändert sich laufend. Die „filtering task“ be-nötigt für diese Aufgabe ein Retrievalsystem, das eine binäre Entscheidung trifft, ob ein Dokument passend für ein Thema ist oder nicht. Dadurch ist das Ergebnis eher eine unsortierte Liste, im Gegensatz zu den ersten beiden Typen, die eine Liste der gefundenen Dokumente, gerankt nach Ähnlichkeit, ausgeben (Ebd.).
Information Retrieval konzentrierte sich traditionell darauf, ganze Dokumente als Er-gebnis zurückzugeben. Mit dem „Question Answering Track“, der seit 1999 existiert, wurde ein neuer Weg beschritten. Hier wird versucht, die exakte Antwort einer Frage zu erhalten (Ebd.).
Die Testkollektionen bestehen aus 3 Teilen: der Dokumentensammlung, den Infor-mationsbedürfnissen (Topics), aus denen die Suchfragen erzeugt werden, und den Relevanzbeurteilungen für die Dokumente (Ebd.). Außerdem können die Kollektio-nen der Vorjahre als Trainingsdaten verwendet werden (Mandl, 2000, S. 91).
Die englische Dokumentensammlung besteht in erster Linie aus Zeitungsartikeln so-wie einigen Regierungsdokumenten und Abstracts aus der Informatik (Vgl.
Voorhees/Harman, 2002).
Ein Topic verzeichnet das Informationsbedürfnis eines Suchenden. Hier als Beispiel ein Topic aus dem Web track:
<num> Number: 508
<title> hair loss is a symptom of what diseases
<desc> Description:
Find diseases for which hair loss is a symptom
<narr> Narrative:
A document is relevant if it positively connects the loss of head hair in humans with a specific disease. In this context, “thinning hair” and “hair loss” are synonymous. Loss of body and/or facial hair is irrelevant, as is hair loss caused by drug therapy (Ebd.).
Aus diesem Informationsbedürfnis können dann die Teilnehmer entweder maschinell oder intellektuell (egal aus welchem Feld) die Suchfragen erzeugen. Es gibt außer-dem eine Topic-Gruppe, die es ermöglicht, Experimente mit ganz kurzen Suchanfra-gen durchzuführen (Vgl. Ebd.).
Die meisten Topics werden von verschiedenen Personen entworfen, die anschlie-ßend auch die Relevanzbestimmungen für die Dokumente durchführen. Diese Vor-gehensweise ist im „Web Track“ und dem „Question Answering Track“ nicht über-nommen worden, hier werden aktuelle Suchanfragen aus Query logs von Suchma-schinen gefiltert, um Realitätsnähe zu gewährleisten.
Die extrahierten Fragen für den „Web Track“ können immer auch mehrdeutige Wör-ter enthalten wie beispielsweise „cat“. Nach der Extraktion der Fragen muss die To-picbeschreibung ergänzt werden. Im Jahr 2001 wurden außerdem die Schreibfehler der Suchanfragen korrigiert (Vgl. Ebd.).
Die Relevanzbeschreibungen haben eine binäre Ausprägung, d.h. entweder ist ein Dokument relevant oder nicht (etwas anders im „Web Track“). Relevant wird verge-ben, wenn der Beurteiler danach einen Report über das Topic schreiben würde und ein zu beurteilendes Dokument eine Information dazu beitragen kann. Auch wenn ein Dokument eine bereits bekannte Information (aus einem anderen Dokument) enthält, wird es als relevant angesehen. Um nicht die ganze Menge an Dokumenten beurtei-len zu müssen, was für 800.000 Dokumente einen Zeitaufwand von über 6500 Stun-den bedeuten würde, wird bei TREC eine Methode namens „Pooling“ benutzt. Dieser
„Pool“ ist eine Untermenge an Dokumenten, wobei von diesen Dokumenten die Re-levanz stellvertretend für die Gesamtmenge beurteilt wird (Vgl. Ebd.).
Die Retrievaldurchläufe können verschiedentlich evaluiert werden. Für die „ac-hoc-task“ und den „Cross-Language-Task“ kann ein „trec_eval package“ benutzt werden, das Recall und Precision an verschiedenen Cut-Off-Levels und davon abgeleitete Summenmaße misst. Oft gemessen wird dabei die „recall-precision curve“ und die
„mean (non-interpolated) average precision“ (Ebd.). Der Recall-Precison-Graph stellt die Precision als eine Funktion des Recalls dar. Wenn die Erstellung dieses Graphs zu beschwerlich ist, wird auf den Precision-Mittelwert ausgewichen (Vgl. Ebd.).
Nun folgt eine kurze Beschreibung der 6 Tracks von TREC 2001, wobei die für ein monolinguales deutsches Textretrieval (wegen des evtl. Bezugs zum Kapitel 4) inte-ressanteren Tracks in Unterkapiteln genauer erläutert werden (Vgl. Ebd.).
1. „Cross-Language Information Retrieval (CLIR) Track“: dieser Track gehört zu den
“ad-hoc-retrieval-tasks”. Die Dokumente sind dabei in einer Sprache und die To-pics in einer anderen. In TREC 2001 wurden arabische Dokumente und englische oder französische Topics verwendet38. 10 Teilnehmer.
2. „Filtering Track“: Siehe Kapitel 4.1
3. „Interactive Track“: Ist einer der Tracks, der schon lange dabei ist. In diesem Track wird sowohl der Suchprozess als auch das Resultat begutachtet. Im TREC 2001 wurde ein Teil eines Zwei-Jahres-Planes für metrikbasierte Vergleiche sol-cher Systeme umgesetzt. In TREC 2001 mussten deswegen Beobachtungen über „subjects using publicly-accessible tools and the live web to accomplish a search task“ (Voorhees/Harman, 2002) gemacht werden. Jeder Forscher befass-te sich mit 4 Suchproblemen. 6 Teilnehmer
4. „Questian Answering (QA) Track”: Siehe Kapitel 4.2.
5. „Video Track“: Hier soll der Fortschritt im inhaltsbasierten Retrieval bezogen auf Videos getestet werden. Es gab 3 verschiedene Aufgaben: „shot boundary task“, eine „know-item-search“ und eine „ad-hoc search task“. 12 Teilnehmer
6. „Web Track“: Siehe Kapitel 4.3 (Vgl. Ebd.)
38 TREC 6, 7 und 8 waren schwerpunktmäßig ausgerichtet auf die europäischen Sprachen (Englisch, Französisch, Deutsch und später Italienisch). Danach wurden mit der Schaffung des „Cross-Language Evalution Forums (CLEF)“ in Europa die europäischen Sprachen ausgegliedert aus TREC (Vgl.
Grey/Oard, 2002, S. 2)
Im TREC 2002 (der im November 2002 stattfand, aber noch nicht ausgewertet ist39) bleibt es bei den 6 bisherigen Tracks. Eine neu gestellte Aufgabe soll das Vorkom-men der gleichen Information in verschiedenen DokuVorkom-menten erkennen. Damit muss das System eine Dublette melden. Außerdem soll es einen „pre track“ für das Retrie-val von genomischen Daten geben (Vgl. Ebd.).
Die Ergebnisse der einzelnen Teilnehmer werden eingereicht, von NIST ausgewertet und in Gesamtberichten über die einzelnen Tracks zusammengefasst. Außerdem erstellen die Teilnehmer noch eigene Berichte über ihre Ergebnisse (Vgl. Ebd.).
Mandl (2000, S. 91) fasst die Kritik an den Testkollektionen aus verschiedenen Be-richten wie folgt zusammen: Die eingesetzten Retrieval-Verfahren könnten außerhalb TREC mit anderen Dokumentenarten zu anderen Ergebnissen führen. Damit könne durch TREC nicht das „beste“ System bestimmt werden.
Bayraktar/Wormer-Hacker (1998) kritisieren, dass die Benutzer keine Rolle spielen40. Die Entwickler versuchen, das Beste unter optimalen Bedingungen aus ihren Syste-men zu holen. Dass die Benutzer eines Systems völlig anders reagieren könnten, wird nicht beachtet. Zudem ist die TREC-Studie lückenhaft, da nicht alle möglichen IR-Funktionalitäten getestet werden. Das Boolsche Retrieval41 spielt keine Rolle, es werden nur Ranking-Systeme benutzt. Somit spielen v.a. Gewichtungsfunktionen, Relevance Feedback und die Optimierung der Anfrage die tragenden Rollen. Die Teilnehmer können jedes Mal auch aufs Neue entscheiden, mit welcher Variante ih-res Systems sie teilnehmen. Deswegen sind generelle Fragestellungen wie „Lohnt sich die Kombination von NLP-Techniken mit statistischen Verfahren?“ (Ebd., S. 435) schwierig zu beantworten.
Beim Durchsehen von einigen Einzelberichten von TREC 8 bis 1042 konnte festge-stellt werden, dass OKAPI (Genaueres siehe Kapitel 3.1.2.2) und SMART (Genaue-res siehe Kapitel 3.1.2.1) entweder als ganze Systeme oder Teile derselben (v.a.
Gewichtung von OKAPI bzw. Stoppwortliste und Stemmer von SMART) zum Testen immer wieder genutzt werden.
Bei den englischen Stemmern scheint eine Mehrheit den Porter Stemmer zu benut-zen, außer dem bereits erwähnten Stemmer von SMART wird auch der von Lovins verwendet (Der Stemmer von Porter und Lovins sind detaillierter im Kapitel 3.1.1.3 bereits beschrieben worden).
3.4.1 Filtering Track
Der „Filtering Track“ ist eine „Routing-task“, es werden nur die Dokumente extra-hiert, die eine Antwort auf ein Informationsbedürfnis (repräsentiert durch ein Topic) enthalten können. In TREC 2001 gab es drei Unteraufgaben: „adaptive filtering task“,
„batch filtering task“ und ein „routing task“. Im „adaptive filtering task“ lernt das
39 Siehe http://trec.nist.gov
40 Realitätsnähe hat inzwischen der Web Track und der QA Track bekommen, da Suchanfragen von Benutzern aus Query logs extrahiert werden.
41 Beim Boolschen Retrieval muss die Suchanfrage mit den Ergebnisdokumenten übereinstimmen (Exact-Match), d.h. es gibt danach 2 Teilmengen an Dokumenten, eine bei der die Begriffe mit der Suchanfrage übereinstimmen und eine, die dies nicht erfüllt (Hengartner, 1996, S. 35).
42 Siehe die Einzelberichte unter http://trec.nist.gov
tem anhand von relevanten Beispieldokumenten und erzeugt somit ein Profil. Bei je-dem Einzeldokument, welches aus je-dem Strom der Gesamtmenge an Dokumenten kommt, wird entschieden, ob es relevant ist oder nicht. Wenn es relevant ist, erhält das System die Relevanzbeurteilung des Dokuments und kann so sein Profil anpas-sen. Der „batch filtering task“ ist eine simplere Variante des “adaptive filtering task”.
Aus dem Profil wird eine Regel vom System erzeugt, welche die Dokumente als rele-vant oder nicht einstufen soll. Bei der „routing task“ wird ebenfalls ein Profil erzeugt, allerdings werden die Dokumente gerankt. 19 Teilnehmer (Vgl. Voorhees/Harman, 2002).
Die TREC 10 Filtering-Experimente benutzten nicht die übliche TREC Dokumenten-kollektion. Hier wurde eine Nachrichtensammlung von Reuters aus den Jahren 1996/97 verwendet. Die Kategorien von Reuters, bezogen auf die Themen („topic“) der Dokumente, wurden verwendet. Damit diente diese Kategorien als Vorgabe für die Systeme zur Klassifikation des Dokumente. Die eingesetzten Systeme benutzten v.a. „Support-Vector-Machines“ oder die Rocchio-Methode zur Klassifikation (Zur Klassifikation Näheres siehe Kapitel 3.2.6) (Vgl. Robertson/Soboroff, 2002).
Im „adaptive filtering task“ schnitt Oracle mit seinem Textretrievalsystem (aufgebaut auf einem Relationalen Datenbanksystem) ganz gut ab. Oracle vergibt Konzepte aus einem Thesaurus an die Dokumente. Die Konzeptvektoren der relevanten Dokumen-te werden summiert und es wird das besDokumen-te Konzept bestimmt, das eine „Topic-Kategorie“ aus der Reuterssammlung repräsentiert.
Der „batch filtering task“ zeigte keine sehr großen Unterschiede für die einzelnen Systeme. Im „routing task“ konnte sich ein System mit „Support Vector Machines hingegen klar absetzen, welches auch im „batch filtering task“ ganz vorn war.
Das beteiligte deutsche System „SER Brainware“ (Kurzbeschreibung siehe Kapitel 3.2.6) rangiert im Ergebnis nur im „low-middle range of the spectrum“ (Ruján, 2002).
3.4.2 Question Answering (QA) Track
Den “Question Answering (QA) Track” gibt es erst seit 1999. Hier soll die definitive Antwort extrahiert und nicht das ganze Dokument als Ergebnis präsentiert werden.
Als Antwort wird eine gerankte Liste mit 5 Antwortpaaren (bestehend aus der Doku-menten-ID und dem Antwortstring) erwartet, wobei als Neuheit in diesem TREC die Möglichkeit der Null-Antwort (d.h. zu der Frage gab es keine passende Antwort) be-stand. Die Antwort darf nur aus einem Textbruchstück („snippet“) der Größe 50 Bytes (d.h. Buchstaben) bestehen. Zu dieser Hauptaufgabe („main task“) konnte zusätzlich eine Teilaufgabe gelöst werden, die vorsah, die „final answer“ zu extrahieren. Die
„main task“ wurde auf zwei Weisen von den Systemen gelöst: Systeme, die versuch-ten die Fragen vollständig zu verstehen und solche, die einen eher „shallow data-driven approach“ benutzen (Vgl. Voorhees/Harman, 2002) .
Außerhalb des „main task“ wurden noch zwei weitere Aufgaben vergeben und zwar den:
· „list task“: Ausgabe einer unsortierten Liste an Antworten auf eine Frage, die eine bestimmte Art an Antwortinstanzen erwartet. Evtl. doppelte Antworten aus
ver-schiedenen Dokumenten dürfen aber nur einfach in der Ergebnisliste erscheinen (Beispielfrage: alle „Chuck Berry songs“)
· „context task“ (Serienfragen): Eine Antwort soll in einer zweiten Frage (und deren Antwort in einer dritten Frage) Verwendung finden, d.h. eine interaktive Aufgabe für das System (Ebd.).
Der Unterschied zum ersten QA-Track war, dass für die Fragen Query logs ausge-wertet wurden und zwar von MSNSearch und ASK Jeeves, die Fragen des „list task“
und des „context task“ wurden allerdings konstruiert. 36 Teilnehmer (Voorhees/Harman, 2002).
Der QA Track startete 1999 mit dem Ziel, Retrievalsysteme weg vom reinen Doku-mentenretrieval zum „Information Retrieval“ zu führen. Außerdem sollten damit die Communities des Dokumentenretrieval und der Informationsextraktion zusammenge-führt werden. TREC 8 und 9 ließen Antworten in der Form von Textbruchstücken mit 50 oder 250 Bytes zu, wobei eine Extraktion von 250 Bytes natürlich die einfachere Aufgabe darstellt. In TREC 9 wurde die Fragestellung verschärft, indem reelle Fra-gen aus Query logs gefiltert und benutzt wurden. Die meisten Teilnehmer verwenden das gleiche Rahmenwerk („framework“) bzw. haben dieselbe Vorgehensweise bei dieser Aufgabe. Zuerst wird der Fragentyp bestimmt (Who [...]? ist eine Frage nach einer Person; When [...]? fragt nach einem Datum etc.). Dann wird eine kleine Menge an Dokumenten mit Standard Textretrievaltechniken isoliert. Die Systeme wenden ein Oberflächenparsing („shallow parsing“) auf die Dokumente an und versuchen En-titäten des Fragentyps zu entdecken. Diese Entität wird dann als Antwort ausgege-ben. Wenn keine exakte Antwort gefunden wird, werden „best-matching passage techniques“ eingesetzt (Vgl Voorhees, 2002).
In TREC 9 konnten die Fragen besser klassifiziert werden und es wurden unter-schiedlichere Methoden als in TREC 8 eingesetzt (in TREC 8 waren und agierten die Systeme relativ ähnlich). Viele Systeme in TREC 10 benutzten das WordNet (Ge-naueres hierzu siehe Kapitel 3.2.1) als semantische Ressource. Um mehr Realitäts-nähe im QA Track zu gewährleisten, wurden 2001 der „list task“ und der „context task“ neu eingeführt (Ebd.).
Die Hauptaufgabe in TREC 2002 lautet, die exakte Antwort zu extrahieren anstelle ein Textbruchstück mit der Antwort (Vgl. Voorhees, 2002).
Als bisher bestes System seit TREC 8 erwies sich das QA-System der Language Computer Corporation (in TREC 8 und 9 lief es als System FALCON der Southern Methodist University (Vgl. Harabagui et al., 2001).
Der Question-Answering Server von der Language Computer Corporation (LCC) verwendet lt. Harabagiu et al. (2002) drei Module: das „Question Processing Mod-ule“, das „Document Processing Module“ und „Answer Processing Module“.
Um Fragen beantworten zu können, benötigt es „bridging inferences“ zwischen der Frageformulierung und der aktuellen Form der Antwort. Beispielsweise die Frage
„How do you measure earthquakes“ wird beantwort mit dem Textbruchstück „Richter scale that measures earthquakes“. Hier ist eine einfache Schlussfolgerung („inferen-ce“) zu ziehen und zwar über das Verb „measures“, das sowohl in der Frage wie auch der Antwort vorkommt und „Richter scale“ hat eine Verbindung über das davor stehende Verb. Solche „inferences“ können auch meronyme Verbindungen sein. Hier
wird dann WordNet eingesetzt. Wörter aus den Fragen können z.B. mit den Syn-onymen-Synset von WortNet erweitert werden. WordNet kann bei der Beispielfrage:
„What is the esophagus used for“ folgendermaßen verwendet werden:
· Erweiterung des Wortes „esophagus“ um die Synonyme aus dem Synset {„esophagus, gorge, gullet“},
· Verwendung zusätzlich des Holonyms „gastrointestinal tract“ oder Funktionen des Holonyms wie „digestion“ (Ebd.).
3.4.3 Web Track
Das Ziel im „Web Track“ ist das Retrievalverhalten in einer verlinkten Struktur wie dem WWW zu untersuchen. Der „Web Track“ besteht aus zwei Aufgaben: eine „ad-hoc task“ und die „homepage finding task“ (= „known-item-task“, dieses Jahr zum ersten Mal). Die Dokumentenkollektion besteht aus einem 10 Gigabyte großen Aus-schnitt des WWW aus dem Jahre 1997, der die letzten Jahre auch schon verwendet wurde. Die Fragen wurden aus den Query logs von MSNSearch ausgesucht. Die Bewertung erfolgte hier in 3 Stufen à relevant, nicht relevant und höchstwahrschein-lich relevant. Die Ergebnisse zeigten, dass die zwei Teilaufgaben unterschiedhöchstwahrschein-liche Techniken benötigen. Für die „ad-hoc task“ ist eine inhaltsbasierte Methode43 am ef-fektivsten. Die „homepage finding task“ erfordert die Verwertung von zusätzlichen In-formationen wie dem URL-Text oder Linkstrukturen. 30 Teilnehmer
(Voorhees/Harman, [2002?])
Die Teilnehmer sollten im „Web Track“ spezifischere Webretrieval-Probleme untersu-chen wie:
· Können verteilte („Distributed“) Information-Retrieval-Techniken benutzt werden, um Retrievaleffektivität und/oder –effizienz zu verbessern?
· Wie gut gehen die Systeme mit falsch geschriebenen Wörtern um? (Vgl. Hawk-ing/Craswell, 2002)
In der „ad-hoc task“ durften die Suchfragen nur in einem Titelfeld des Systems ge-stellt werden. Zur Realitätsspiegelung des Web waren keine andere zusätzliche Fel-der zugelassen. Allerdings konnten die Teilnehmer zusätzliche interaktive, intellektu-elle und volle Topic-Statements beim Durchlaufen durch das System benutzen, um die Entdeckungsrate bzgl. relevanter Dokumente zu erhöhen.
Der „homepage finding task“ wurde gewertet, indem die erste richtige Antwort ge-zählt wurde. Intellektuelle oder interaktive Fragenmodifikationen waren nicht gestattet (Ebd.).
Die Ergebnisse im „ad-hoc-task“ zeigten, dass die topplazierten ersten 4 Retrieval-systeme unterschiedliche Techniken benutzten, auch für die Indexierung:
1. Das erstplatzierte FUB-System benutzte keine Linkinformationen noch Dokumen-tenstrukturen oder den URL-Text. Die Indexierung erfolgte ohne Stemming, inde-xiert wurden Einzelwörter. Des Weiteren wurde eine auf Probabilistischen Model-len beruhende Gewichtung sowie automatische „Query Expansion“ genutzt.
43 Somit wäre auch das inhaltsbasierte Indexieren von Vorteil
2. Das zweitbeste Ergebnis verzeichnete JuruFull (IBM-Haifa) das Dokumentstruktu-ren und refeDokumentstruktu-renzierte „anchortexts“ benutzt. Das System beruht auf dem Vekto-renmodell, verwendet „lexical affinites, den Porter Stemmer und „slight stopword filtering“
3. Auf dem dritten Platz findet sich das System von Ricoh, welches nur den Doku-menteninhalt benutzt. Merkmale: Probabilistisches Modell, „Query Expansion“, automatische Parameterwertbestimmung
4. Das viertplazierte JustSystem verwendet wiederum Linkinformationen (allerdings ist unklar welche). Merkmale: Vektorenmodell, Referenz-Datenbank, Pseudo-Relevance Feedback44 (Ebd.).
Im Ergebnis konnten also mit dem Parsen des reinen Dokumenteninhalts gute Posi-tionen erreicht werden. Die automatische „Query Expansion“ wurde von vorn plazier-ten Systemen oft eingesetzt. Weder das Vektoren- noch das Probabilistische Modell konnten sich klar voneinander absetzen (Ebd.).
Bei der „home page finding task“ benutzten die Systeme auf den besten Rängen alle entweder URL-Text oder URL-Links (oder beides) (Ebd.).
Da die Fragen des „Web Track“ (z.B. im TREC 9) immer wieder fehlerhafte Wörter enthielten, mussten die Systeme diese Fehler beheben. Dabei benutzten die
Da die Fragen des „Web Track“ (z.B. im TREC 9) immer wieder fehlerhafte Wörter enthielten, mussten die Systeme diese Fehler beheben. Dabei benutzten die