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