Personalisierung
im Query Understanding
Felix Wende
Martin-Luther-Universität Halle-Wittenberg
felix.wende@student.uni-halle.de
1 Einleitung
der Google-Personalisierungsprozess anhand unseres präsentierten Interesses an
Event Streaming Software davon ausgeht, dass unser Informationsbedürfnis
nach der Suchanfrage eher durch Apache
Kafka befriedigt wird.
Mit Hilfe der Personalisierung wird sich
somit vom überholten „one size fits all“Verhalten abgewendet, bei dem Suchmaschinen sich einzig auf die Schlagwortbasierte Suchanfrage als Informationsquelle verlassen. Im Artikel Issues in Personalizing Information Retrieval (Gabriella Pasi) [2] werden die Hauptprobleme in der Entwicklung von Personalisierungsverfahren vorgestellt und erörtert,
bei denen der Kontext des Suchenden
als Informationsquelle für die Suchanfrage einbezogen wird. Die vorgestellten
Hauptprobleme sind: Wie wird der Nutzerkontext (Informationen, die der Nutzer durch sein Verhalten während Suchsitzungen der Suchmaschine übermittelt
hat) von der Suchmaschine repräsentiert
und wie genau ist der Prozess definiert,
mit dem das Kontextwissen ausgenutzt
wird, um die Relevanz der Suchergebnisse zu verbessern[2].
Viele Personalisierungsverfahren beziehen sich auf einen Aspekt des Nutzerverhaltens, der besonders starke Signale zur Weiterverarbeitung bietet: auf den
Suchverlauf des einzelnen Nutzers und
die jeweils angeklickten Dokumente [1,
3]. Ein wichtiger Forschungspunkt dabei
ist das Zusammenspiel von kurzfristigem
Verhalten (Sitzungsverhalten, also Daten
über die Suchanfragen und Clicks während der gleichen Sitzung im Suchbrow-
Personalisierung ist ein interdisziplinärer
Ausdruck, der über die Websuche hinaus geht. Er wird bei Vorgängen angewandt, die ein Produkt oder einen Service anpassen, um den Bedürfnissen einer einzelnen Person oder eines bestimmten Bevölkerungsteils gerecht zu
werden. Im Kontext des Query Understandings bedeutet Personalisierung die
Nutzung von Informationen über den
Suchenden, um die Dokumentbewertung (den sogenannten Score) bezüglich
der eingegebenen Anfrage anzupassen
oder die Anfrage zu ergänzen. In beiden
Fällen wird mittels der gesammelten Informationen dem Suchenden eine Intention für seine Anfrage zugeschrieben, die
sich auf das Query Understanding auswirkt [1]. Sucht der Nutzer beispielsweise nach dem Schlagwort „Kafka“ wird
ihm von der Google-Suchmaschine im
Inkognito-Modus (d. h. weitgehend ohne
Nutzung vorhandener Nutzerdaten, wie
des Verlaufs) zunächst eine Reihe Suchergebnisse präsentiert, bestehend zum
einen aus Artikeln über den Autor Franz
Kafka und zum anderen aus der freien
Software Apache Kafka. Weiterhin wird
eine Infobox mit Daten zu Franz Kafka
angezeigt. Sucht der Nutzer nun in der
gleichen Sitzung nach den Queries „java event streaming“, „event streaming“
und „apache“ und führt darauf die Suche nach „kafka“erneut durch, bleiben
zwar die Suchergebnisse gleich, aber die
Infobox zeigt nun Informationen zu der
Apache Kafka Software. Dies zeigt, dass
1
2 Framework
ser) und langfristigem Verhalten (historisch, also Daten über Nutzerverhalten in
den vorherigen Sitzungen) und wie diese
isoliert voneinander oder in Kombination genutzt werden können, um die Relevanz der Suchergebnisse durch Personalisierung zu optimieren. Dafür wurde im
Artikel Modeling the Impact of Short- and
Long-Term Behavior on Search Personalization (Paul N. Bennett et al.) [3] ein Framework vorgestellt, mit Hilfe dessen untersucht wird, wie historische Suchverlaufsaktivitäten mit den jeweiligen Sitzungsverlaufsaktivitäten interagieren. Es
werden verschiedene Zeitspannen untersucht und die Relevanz der Suchergebnisse vorhergesagt. Es ergibt sich, dass
historisches Verhalten gerade am Anfang der Sitzung erhebliche Vorteile bietet, Sitzungsverhalten speziell bei ausgedehnten Sitzungen besonders von Vorteil
ist und dass die Kombination von beidem sowohl die alleinige Nutzung des
Sitzungsverhaltens als auch des historischen Verhaltens übertrifft. Indem das
Modell eine Kombination dieser 3 Views
lernt, werden Gewichte je nach Anfrage und vorherigem Verhalten erstellt, die
die Relevanz der Suchergebnisse so besser anpassen können [3].
Es wird sich im Folgenden deutlich zeigen, dass die Anfrage selbst, wenngleich
notwendig trotzdem nicht hinreichend
ist, um die Intention des Suchenden zu
bestimmen und damit ermitteln zu können, welche Suchergebnisse relevant für
den Suchenden sein werden und welche
nicht. Obwohl die Anfrage selbst für das
Query Understanding weiterhin die primäre Quelle ist, hilft Personalisierung dabei, Wissen über den Suchenden zu liefern und damit einen Kontext zur Anfrage zu liefern, der die Relevanz der Suchergebnisse in vielen Fällen drastisch verbessern kann [1, 2, 3].
Die 3 Rankingmethoden zur Bearbeitung der Suchanfrage (Ausschließliche
Betrachtung kürzlicher Nutzeraktivitäten, ausschließliche Betrachtung historischer Aktivitäten und die vermischte Betrachtung der Aktivitäten) stellen Views
dar, also Ausschnitte der vorher getätigten Suchanfragen und Suchinteraktionen in verschiedenen Zeitintervallen, die
bis zur zu bearbeitenden, jetzt getätigten Suchanfrage reichen. Mit Hilfe dieser Views wird ein Framework aufgebaut,
mit diesem die Vor- und Nachteile der
jeweiligen Rankingmethoden evaluiert
werden können. Um das Framework aufzubauen, wird eine Reihe verschiedener
Faktoren berücksichtigt. Hat der Nutzer
eine Anfrage q gestellt, dann sei ein zeitlich begrenzter View auf die vergangene
Suchinteraktion view(q) und alle mit der
Anfrage verwandten anderen Anfragen
related(q, u I ). Dabei soll u I das Set der
in der Vergangenheit ausgeführten Anfragen des Nutzers sein, sowie deren Ergebnisse und interaktives Verhalten des
Nutzers mit den Ergebnissen.
Bei Interaktionen des Nutzers mit den
Suchergebnissen liegt hier der Fokus auf
Clicks (hier: ein Ergebnis anklicken und
die Seite mindestens 30 Sekunden offen
haben oder ein Ergebnis anklicken und
damit die Suche beenden). Aber auch
Skips (explizites Ignorieren eines Ergebnisses, beispielsweise Anklicken des 2.
Ergebnisses statt dem 1.) und Misses (ein
eigentlich relevantes Ergebnis wird vom
Nutzer nicht registriert) könnten in das
Framework mit aufgenommen werden.
Die Funktion related(q, u I ) gibt ein Set
von Anfragen zurück, die mit q zusammenhängen. Für jede dieser zurückgegebenen Anfragen q r wird darauf die Stärke der Verbindung zu der ursprünglichen
Anfrage q durch w(q r , q, u I ) (abgekürzt
2
w qr ) abgebildet. Für jede verwandte Anfrage gibt die Suchmaschine ein Set von
Ergebnissen r esul t s(q r ) zurück, dessen
Elemente als d qr bezeichnet werden. Für
jedes dieser Dokumente d qr wird darauf
zum einen die Similarity zu einem Dokument d von der jetzigen Anfrage betrachtet, sowie zum anderen die Aktion, die
der Nutzer mit dem Dokument vorgenommen hat. Hier impliziert beispielsweise ein Click, dass das Dokument relevant ist. Mit Hilfe dieser beiden Werte Similarity und Aktion soll nun die Relevanz des ursprünglichen Dokumentes
d für den Nutzer bestimmt werden. Eine simple Darstellung all dieser Faktoren
mit Hilfe einer sogenannten Feature Familie, die durch die Anpassung der verschiedenen Funktionen spezifiziert werden kann, wäre:
der verwandten Anfrage mit denen der
ursprünglichen Anfrage übereinstimmt
und ansonsten 0. Die Aktion wäre die Anzahl der Clicks, die der Nutzer bereits auf
dem Dokument der verwandten Anfrage
getätigt hat.
Mit dieser Feature-Familie lassen sich
damit die verschiedenen zeitlichen
Views mit unterschiedlichen Personalisierungsfeatures untersuchen. Zur Einfachheit wird nun angenommen, dass
alle Anfragen in der Nutzerhistorie einheitlich gewichtet seien und dass eine
Aktion ein Click sei. Desweiteren wird ein
Dokument d als Vektor φ(d ) von TopicWahrscheinlichkeiten repräsentiert. Damit wird jedem Thema, das durch ein
Dokument adressiert wird, eine entsprechende Wahrscheinlichkeit zugeordnet.
Sind Themen vom Dokument nicht repräsentiert, werden diese mit 0 im Vektor aufgefüllt. Eine Similarity Funktion
si m sei nun das Skalarprodukt der TopicWahrscheinlichkeitsvektoren vom Dokument d und den verwandten Dokumenten d qr , also si m(d qr ) = ⟨φ(d qr ), φ(d )⟩.
Mit Hilfe dieser Darstellung lässt sich
der Feature-Vektor f (q, d , u I ) umstellen.
Dieser setzt sich nun zusammen aus dem
Skalarprodukt von dem Topic-Vektor von
d und dem Gewichtsvektor für das verwandte Dokument.
f (q, d , u I )
P
=
w qr
q r ∈r el at ed (q,u I )|q r ∈vi ew(u I )
P
si m(d qr , d ) ac t i on(q r , d qr )
d qr
Also die Summe der Verbindungsstärken
zwischen der ursprünglichen Anfrage q
und allen verwandten Anfragen q r der
vorherigen Suchinteraktionen, die sich
im entsprechenden zeitlichen Intervall
befinden, multipliziert mit der Summe
der Ähnlichkeiten der Dokumente der
ursprünglichen Anfrage zu denen der
verwandten Anfrage und der Aktion, die
der Nutzer an dem Dokument ausgeführt
hat. Mit Hilfe dieser Feature Familie lassen sich verschiedene Features darstellen und untersuchen, um herauszufinden, auf welche Weisen die Personalisierung verbessert werden kann. Beispielhafte Vorgehen wären die Stärke der Verbindung der verwandten Anfragen auf
1 zu setzen, wenn diese alle Anfragen
der vergangenen Interaktion des Nutzers umfasst; oder die Similarity auf 1 zu
setzen, wenn die URL der Dokumente
f (q, d , u I )
P
= ⟨φ(d ),
w qr
q r ∈r el at ed (q,u I )|q r ∈vi ew(u I )
P
φ(d qr ) ac t i on(q r , d qr )⟩
d qr
= ⟨φ(d ), ω(q, d , u I )⟩
Dabei kann ein Dokument-Vektor nicht
nur Topics repräsentieren, sondern auch
für URLs eingesetzt werden. Trifft das
Dokument die URL erhält der Vektor an
der Stelle der URL den Wert 1, sonst
0. Dies wird bei Features angewendet,
bei dem Ähnlichkeit exakte Übereinstim-
3
mung, also das gleiche Dokument, bedeuten soll. Im weiteren werden einige
Funktionen vorgestellt, die für die verwandten Anfragen, die Gewichtung, die
Ähnlichkeit und die Aktionen eingesetzt
werden können. Diese werden schlussendlich in einen maschinell lernenden
Ranker eingesetzt und analysiert.[3]
hingegen wahrscheinlich nicht relevant,
da das gesuchte Ergebnis wohl nicht gefunden wurde.[3]
5 Profilinformationsmaße
Studien über Personalisierung haben
auch häufig Features eingeführt, die die
Menge der über den Benutzer bekannten Informationen oder die Angemessenheit der Personalisierung für eine Anfrage messen. Wenn die gewählten Maße
der Beziehungsgewichte der Repräsentation und der Aktion alle nicht negativ sind, kann ω(q, d , u I ) durch Normalisierung über die Feature-Dimensionen
als Beschreibung eines Wahrscheinlichkeitsraums über dem Repräsentationsraum φ(·) behandelt werden. Handelt
es sich bei dem Vektor um eine Repräsentation von URLs in Kombination mit
den Click-Aktionen, dann ist die Entropie des resultierenden Vektors die sogenannte QueryClickEntropy. Da jedoch
das Tracking jeder URL durch den Nutzer sehr kostspielig sein kann, wird zur
Vereinfachung die geklickte Rangposition der Dokumente verwendet, anstelle
der URL.
Wenn stattdessen die thematische Zuordnung im Vektor verwendet wird, ist
die Entropie des Vektors ω(q, d , u I ) summiert über die Nutzer die QueryTopicEntropy. Abhängig vom Nutzer für alle Anfragen wird die UserTopicEntropy
erhalten und bedingt von Nutzer und
Anfrage wird die UserQueryTopicEntropy erhalten.[3]
3 Thematische
Repräsentation
Um die Dokumente Thematisch darzustellen, werden den Dokumenten mittels einem text-basiertem Klassifizierer
aus den obersten 2 Ebenen einer ODP
Hierarchie (Open Directory Project (ODP,
dmoz.org)) die Themen samt Wahrscheinlichkeiten zugeordnet, begrenzt
auf die 3 wahrscheinlichsten ThemenKlassen. Dies ermöglicht Features zu entwickeln, die die Nutzerpräferenzen über
alle Anfragen, für die jetzige Anfrage, sowie für eine Generalisierung der Anfrage
q und für eine Spezifizierung der Anfrage
q repräsentieren.[3]
4 Suchaktionen
Während oftmals eine Vielzahl von Verhaltenssignalen untersucht wird, wird
sich hier nur auf die sogenannten SATClicks beschränkt, also Clicks, bei denen der Benutzer mindestens 30 Sekunden auf dem Ergebnis bleibt – das Ergebnis also als Hauptfenster offen hat –
oder die Suchsitzung beendet, nachdem
er das Ergebnis geöffnet hat. Das ergibt
sich daraus, dass eine Verweilzeit auf einem Ergebnis auf Relevanz hinweist beziehungsweise ein Abbrechen der Suche
nach dem Öffnen eines Ergebnisses auf
die Erfüllung des Informationsbedürfnisses deutet. Clicks mit kurzen Verweilzeiten, die sogenannten „Quick Backs“ sind
4
6 Feature Übersicht
Nachfolgend ist ein Auszug der genutzten Feature-Übersicht. Für alle parametisierten
Features sei ac t i on(q r , d qr ) = S AT cl i ck. Wenn eine Reihe ein Kreuz im Feld „Zeitliche
Auswahl“ hat, werden Instanzen für die Werte Session, Historic und All für vi ew(u I )
erstellt. Wenn eine Reihe ein Kreuz im Feld „Gewicht“ hat, werden Instanzen für die
Werte uniform und decay für w qr erstellt. Uniform bedeutet, dass die Gewichtung der
verwandten Anfragen unabhängig der zeitlichen Distanz zum „Jetzt“ gleich bleibt, decay bedeutet, dass die Gewichtung mit zunehmender zeitlichen Distanz abnimmt. Somit können Reihen maximal 3 Views × 2 weight = 6 Features erzeugen.[3]
Tabelle 1: Auszug Feature Übersicht
Zeitliche Auswahl
Gewicht
Feature
Beschreibung
Anfrage-Dokument-Nutzer Features
×
×
DocTopicCosineUserTopicProfile : Kosinus von
φ(d ), ω(q, d , u I ) mit r el at ed (q, u I ) = al l , φ(·) = Topi c
Topic Similarity zur gesamten Nutzerhistorie zu dieser URL
×
×
UserClicksOnUrl : Skalarprodukt von
φ(d ), ω(q, d , u I ) mit r el at ed (q, u I ) = al l , φ(·) = U RL
Click-Anzahl der gesamten Nutzerhistorie zu dieser URL
×
×
DocTopicCosineUserTopicProfileForQuery : Kosinus von
φ(d ), ω(q, d , u I ) mit r el at ed (q, u I ) = q, φ(·) = Topi c
Klassen-Similarity von gewählter Nutzerhistorie
(exakte Anfrage) zu dieser URL
×
×
UserClicksOnUrlForQuery : Skalarprodukt von
φ(d ), ω(q, d , u I ) mit r el at ed (q, u I ) = q, φ(·) = U RL
Click-Anzahl von gewählter Nutzerhistorie
(exakte Anfrage) zu dieser URL
Anfrage Features
Anfrage-Mehrdeutigkeits-Maße
QueryClickEntropy
(häuig Click Entropy in Literatur genannt)
Misst die Diversität von Clicks verteilt über Nutzer. Eine
höhere Entropie weist auf Anfragen mit mehreren Intentionen hin.
QueryTopicEntropy
Eine höhere Entropie weißt auf eine thematische Mehrdeutigkeit hin.
PositionInSession
Einfache Anfragen kommen früh in der Sitzung mit
späteren Reformulierungen.
Anfrage-Schwierigkeits-Maße
QueryLength
Anfrage-Länge wurde gezeigt, dass sie auf Schwierigkeit hindeutet.
QueryFrequency
Öftere Anfragen beinhalten häufig mehr Click-Informationen
Rank
Rang des Base-Rankers –
nicht-personalisierte Schätzung der Relevanz
Anfrage-Dokument
Anfrage-Historie-Features
Anfrage-Anzahl Features in Profil
×
NumberOfQueries
Anzahl verschiedener Anfragen im Interaktions-View
×
NumberOfSessionsWithQuery
Anzahl von Sitzungen im View, die den Query beinhalten
Fokus auf Nutzer-Profil
×
×
UserTopicEntropy : Entropie von normalisiertem
ω(q, d , u I ) mit r el at ed (q, u I ) = al l , φ(·) = Topi c
Misst die Diversität von den observierten Bedürfnissen des Nutzers
×
×
UserQueryTopicEntropy : Entropie von normalisiertem
ω(q, d , u I ) mit r el at ed (q, u I ) = q, φ(·) = Topi c
Misst die Diversität von Themen, die die Bedürfnisse des Nutzers
für diese exakte Anfrage in der Vergangenheit erfüllt haben.
×
×
UserPositionEntropy : Entropie von normalisiertem
ω(q, d , u I ) mit r el at ed (q, u I ) = al l , φ(·) = Posi t i on
Höhere positionelle Entropie bedeutet, dass der Nutzer häufiger
nicht mit den Top-Ergebnissen zufrieden ist.
×
×
UserQueryPositionEntropy : Entropie von normalisiertem
ω(q, d , u I ) mit r el at ed (q, u I ) = q, φ(·) = Posi t i on
Höhere positionelle Entropie bedeutet, dass der Nutzer häufiger
nicht mit den Top-Ergebnissen für diese Anfrage zufrieden ist.
Wenn die Ergebnisse für eine Anfrage stets tabil sind,
ist dies die personalisierte Click Entropie.
5
7 Experimentelle
Methodik und
Evaluation
ten. Die Leistung wird schließlich gemessen anhand der mittleren durchschnittlichen Genauigkeit der neu eingestuften Ergebnislisten. 80% der Daten werden zum Trainieren des Machine Learning Models verwendet, 20% der Daten
zum Testen des Models, wobei zwischen
den verschiedenen Views beim Trainieren unterschieden wird. Zum Trainieren
wurde der LamdaMart-Lernalgorithmus
verwendet.[3]
Mit Hilfe der dargestellten Features lässt
sich die Frage beantworten, wie die verschiedenen Aspekte der Suchhistorie die
Qualität der Personalisierung beeinflussen. Dabei werden 4 verschiedene Arten der Suchhistorie betrachtet: Session
(die Aktionen aus dieser Sitzung), Historic (alle Aktionen, außer die der jetzigen
Sitzung), Aggregate (alle Aktionen vor
der jetzigen Anfrage) und Union (Kombination von Session, Historic und Aggregate mit verschiedenen Wichtungsmöglichkeiten). Unter diesen 4 Bedinungen werden Modelle trainiert, die die
Web-Suchergebnisse einer großen kommerziellen Suchmaschine neu ordnen.
Verwendet wird hier die Microsoft-BingSuchmaschine. Als Baseline sind die Top
10 Ergebnisse der Engine der Suchmaschine gesetzt. Diese stellt eine wettbewerbsfähige und überdurchschnittliche
Leistung dar. Als primäre Datenquelle
fungiert ein Datensatz mit anonymisierten Log-Dateien von Benutzern der BingSuchmaschine. Dabei wird darauf geachtet, dass andere Personalisierungstools
im Vornherein deaktiviert wurden.
Zur Bewertung erhält jedes Ergebnis eine
personalisierte Relevanzbeurteilung. Betrachtet werden die TOP-10-URLs. Kann
eine URL einen SAT-Click vorweisen bzw.
wird ein SAT-Click in den nächsten beiden Anfragen erzielt, wenn diese sich
je mindestens 1 Ergebnis in den TOP10-Vorschlägen teilen, so erhält das Ergebnis eine positive Relevanz. Die Verbleibenden URLs in den TOP-10 erhalten einen negativen Wert. Die Rangposition der positiven Beurteilungen wird
darauf verwendet, um die Abrufleistung
vor und nach dem Ranking zu bewer-
8 Ergebnisse und
Performance
Die folgenden Diagramme zeigen die Änderung der mittleren durchschnittlichen
Genauigkeit (MAP) der Ergebnislisten
von der Baseline zu der jeweiligen Art der
betrachteten Suchhistorie:
Abbildung 1: Performance über alle Anfragen
Über alle Anfragen hinweg lässt sich also
sagen, dass je mehr Informationen über
den Nutzer in den Suchprozess einbezogen werden bezüglich seiner Suchhistorie, desto besser ist die Performance der
Suchmaschine. Auch wenn nur die Anfragen der jetzigen Sitzung in die Ergebnisliste einbezogen werden, verbessert
sich die durchschnittliche Leistung der
Suchmaschine um etwa 25%. Dieser Wert
erhöht sich je nach Größe der einbezogenen Historie. Werden alle Anfragen außer der derzeitigen Sitzung betrachtet,
was üblicherweise mehr sind als in einer
Sitzung verbessert sich die Leistung er-
6
neut. Kombiniert man die Anfragen der
jetzigen Sitzung mit denen vergangener
Sitzungen steigt die Leistung noch mehr
um etwa 60%. Verwendet man diese 3
Modi gewichtet in der Union verbessert
sich der Wert nochmal ein wenig.
die positive Veränderung durch Session
die von Historic schon an der 3. Position in der Sitzung überholt hat und den
Abstand zunehmend vergrößert. Zusätzlich verbessern sich Aggregate und Union durch die hinzugekommenen Informationen der Sitzung konstant. Je größer
die Session desto besser werden Aggregate und Union, doch das Verhältnis der
beiden bleibt in etwa gleich. Union bleibt
dabei stets der die Leistung am meisten
steigernde Modus.[3]
9 Fazit
Abbildung 2: Effekt der Anfrage-Position
in Session
Zusammenfassend lässt sich sagen, dass,
um Personalisierung zu verbessern, historisches Verhalten zu Beginn einer
Suchsitzung einen erheblichen Vorteil
bietet. In längeren Sitzungen trägt das
Sitzungsverhalten das meiste bei und eine Kombination von beidem übertrifft
beide alleine stehend. Alle Methoden
übertreffen jedoch die Variante einer
Suchmaschine ohne Personalisierungsautomatismen. Es lässt sich also sagen,
dass die Anfrage selbst zwar notwendig
ist, um die Intention des Nutzers herauszufinden, aber sicher nicht immer ausreichend ist, um bestmögliche Ergebnisse zu liefern. Zwar bleibt die Anfrage die
primäre Quelle zum Verstehen des Inputs, aber das Wissen über den Suchenden liefert wertvollen Kontext.[1, 2, 3]
Auch hier lässt sich im Allgemeinen das
gleiche Phänomen beobachten, nur ist es
hier genauer aufgeschlüsselt. Ist die Anfrage, die gestellt wird, die erste der Sitzung gibt es logischerweise keinen Sitzungsverlauf, weswegen Historic, Aggregate und Union alle etwa das gleiche Ergebnis liefern, da Session Aggregate und
Union ohne vorhandene Daten nicht viel
beeinflussen kann/sollte. Ist die Anfrage
die zweite in der Sitzung ergibt sich die
Verteilung wie in Abbildung 1. Wenig Informationen aus der derzeitigen Sitzung
helfen ein wenig das Ergebnis zu verbessern. Mit fortlaufender Position wird die
Session jedoch immer wichtiger. An 2.
Position sind historische Daten hier noch
eine größere Hilfe, aber weniger als bei
Anfragen in Position 1. Das kommt daher, dass längere Sitzungen häufig ein Indiz sind, dass das Thema des Informationsbedürfnisses ein weniger bekanntes
Thema für den Nutzer ist, was die Wahrscheinlichkeit verringert, dass er in vorherigen Sitzungen schon nach dem Thema gesucht hat. Das Phänomen der sinkenden Verbesserung durch Historic verstärkt sich damit auch mit Anstieg der
Anfrageposition in der Sitzung, sodass
Literatur
[1] https://queryunderstanding.com/
personalization-3ed715e05ef
TUNKELANG, Daniel. Personalization. 2017, abgerufen 06.12.2020
[2] PASI, Gabriella. Issues in Personalizing Information Retrieval. IEEE Intell. Informatics Bull., 2010, 11. Jg.,
Nr. 1, S. 3–7.
7
[3] BENNETT, Paul N., WHITE, Ryen W.,
CHU, Wei, DUMAIS, Susan T., BAILEY, Peter, BORISYUK, Fedor, CUI,
Xiaoyuan. Modeling the Impact of
Short- and Long-Term Behavior on
Search Personalization. In: Proceedings of the 35t international ACM SIGIR conference on Research and development in information retrieval.
2012. S. 185–194.
8