When & How to Write for Personalized Demand-aware Query Rewriting in Video Search

Das Paper stellt WeWrite vor, ein personalisiertes, bedarfsgesteuertes Framework für die Suchanfrage-Umschreibung in Videosuchsystemen, das durch eine automatische Mustererkennung für den Schreibzeitpunkt, ein hybrides Trainingsverfahren aus SFT und GRPO sowie eine latenzarme Architektur die Klickrate für Videos über 10 Sekunden um 1,07 % steigert und die Neukonfiguration von Suchanfragen um 2,97 % senkt.

Das Wesentliche

Stellen Sie sich vor, Sie sind in einer riesigen, lauten Videobibliothek (wie WeChat Channels) und suchen nach etwas Bestimmtem. Sie tippen nur zwei Wörter ein: „Guang Liang".

Das Problem: Die Bibliothekarin (der Suchalgorithmus) weiß nicht, ob Sie den Sänger Guang Liang oder die Schnapsmarke Guang Liang meinen. Wenn Sie nur nach dem Sänger suchen, aber die Schnapsmarke angezeigt bekommen, sind Sie frustriert.

Das ist das Problem, das die Autoren dieses Papiers mit ihrer neuen Erfindung namens „WeWrite" lösen wollen. Hier ist die Erklärung, wie das funktioniert, ganz einfach und mit ein paar bildhaften Vergleichen:

1. Das große Dilemma: Wann soll man eingreifen?

Stellen Sie sich vor, Sie haben einen sehr hilfsbereiten, aber manchmal etwas übertriebenen Assistenten.

• Der alte Weg: Der Assistent versucht, jede Ihrer Suchanfragen umzuformulieren, auch wenn Sie eigentlich schon genau wissen, was Sie wollen. Das ist wie jemand, der Ihnen hilft, die Schuhe zu binden, obwohl Sie gerade nur schnell zum Briefkasten laufen wollen. Das nervt und führt zu Fehlern (man nennt das im Papier „Intent Drift" – die Absicht geht verloren).
• Die WeWrite-Lösung: Der Assistent lernt erst einmal, WANN er eingreifen muss.
  • Er beobachtet Ihre Geschichte: Haben Sie kürzlich viele Videos über Schnaps gesehen? Dann ist es wahrscheinlich, dass Sie die Marke meinen.
  • Er schaut auf Ihre Reaktion: Wenn Sie nach „Guang Liang" suchen, sofort die Seite verlassen und sofort wieder eine neue Suche starten, weiß er: „Aha, die erste Antwort war falsch!"
  • Die Analogie: Es ist wie ein erfahrener Butler, der weiß, wann er Ihnen einen Regenschirm reicht (wenn es regnet) und wann er es besser lässt (wenn die Sonne scheint). Er greift nur ein, wenn es wirklich nötig ist.

2. Das zweite Problem: Wie schreibt man richtig?

Angenommen, der Assistent weiß, dass er helfen muss. Wie formuliert er die Suche dann?

• Das Problem: Wenn ein KI-Modell (ein großes Sprachmodell) einfach nur kreativ ist, könnte es etwas Erfinden, das im Suchsystem gar nicht existiert. Das wäre wie wenn der Assistent Ihnen sagt: „Suchen Sie nach 'Gläserne Wolken'". Aber in der Bibliothek gibt es keine Gläsernen Wolken. Die Suche wäre leer.
• Die WeWrite-Lösung: Sie haben eine spezielle Trainingsmethode entwickelt.
  • Schritt 1 (SFT): Der Assistent lernt aus Beispielen, wie man Suchanfragen umschreibt.
  • Schritt 2 (GRPO - Die Belohnung): Hier kommt der Clou. Der Assistent bekommt keine Punkte dafür, wie „kreativ" er ist, sondern dafür, ob seine neue Suchanfrage funktioniert.
  • Die Analogie: Stellen Sie sich vor, der Assistent spielt ein Videospiel. Er darf nicht einfach irgendetwas tippen. Er bekommt Punkte nur dann, wenn er einen Treffer landet (ein Video findet, das Sie wirklich ansehen). Wenn er etwas erfindet, das nicht existiert, bekommt er eine Strafe. So lernt er, kreativ zu sein, aber immer innerhalb der Grenzen dessen, was die Bibliothek tatsächlich hat.

3. Das dritte Problem: Die Geschwindigkeit (Warum dauert das nicht ewig?)

KI-Modelle sind oft langsam. In einer Live-Suche darf es aber keine Verzögerung geben. Wenn Sie auf „Suchen" klicken, wollen Sie sofort Ergebnisse sehen, nicht 2 Sekunden warten, bis der Assistent nachdenkt.

• Die WeWrite-Lösung: Sie nutzen eine Technik namens „Fake Recall" (Fake-Erinnerung).
• Die Analogie:
  • Normalerweise würde der Assistent erst nachdenken, dann zur Bibliothek laufen, die Regale durchsuchen und dann zurückkommen. Das dauert.
  • Bei WeWrite läuft alles parallel. Während die normale Suche (die schnellen, alten Methoden) schon losläuft, denkt der Assistent im Hintergrund parallel nach.
  • Der Assistent hat sich vorher eine Liste mit den besten Ergebnissen für die häufigsten Suchanfragen vorbereitet (eine Art „Vorratsschrank"). Wenn er eine neue Idee hat, schaut er sofort in diesen Vorratsschrank, statt erst die ganze Bibliothek zu durchsuchen.
  • Am Ende werden die Ergebnisse der normalen Suche und die des Assistenten einfach zusammengeklebt. Da der Assistent im Hintergrund gearbeitet hat, merken Sie keine Verzögerung. Es fühlt sich an, als wäre er immer schon da gewesen.

Das Ergebnis

Durch diese drei Tricks (Wann eingreifen, Wie schreiben ohne zu erfinden, und wie man es schnell macht) hat das Team getestet, wie gut es funktioniert:

• Die Leute haben mehr Videos angeschaut (die, die sie länger als 10 Sekunden sehen).
• Die Leute mussten seltener ihre Suche korrigieren (sie mussten nicht mehr zweimal tippen, weil die erste Antwort falsch war).

Zusammenfassend:
WeWrite ist wie ein super-intelligenter Bibliothekar, der genau weiß, wann er Ihnen helfen soll, der nicht zu kreativ ist (sondern das findet, was wirklich da ist), und der so schnell arbeitet, dass Sie gar nicht merken, dass er überhaupt mitgedacht hat.

Technische Zusammenfassung

1. Problemstellung

In Video-Suchsystemen (z. B. WeChat Channels) sind Suchanfragen der Nutzer oft kurz und mehrdeutig. Herkömmliche Methoden zur Abfrageumformulierung (Query Rewriting) nutzen oft implizite Historienmerkmale, was zu einer Verwässerung der Signale und verzögertem Feedback führt.

• Herausforderung 1 (Wann schreiben?): Eine unbedachte Umformulierung aller Anfragen kann zu einer „Intent Drift" (Absichtsverfälschung) führen. Funktionale Suchanfragen (z. B. „Fritteuse") sollten nicht basierend auf Unterhaltungshistorien umgeschrieben werden, da dies die Nutzerabsicht verwässert.
• Herausforderung 2 (Wie schreiben?): Generierte Anfragen müssen nicht nur semantisch korrekt sein, sondern auch mit dem bestehenden Suchindex kompatibel sein, um „Zero-Recall"-Probleme zu vermeiden.
• Herausforderung 3 (Latenz): Die hohe Inferenzkosten von Large Language Models (LLMs) machen eine direkte Integration in den synchronen Pfad von Echtzeit-Video-Suchsystemen mit strengen Latenzanforderungen unmöglich.

2. Methodik: Das WeWrite-Framework

Die Autoren stellen WeWrite vor, ein Framework für personalisierte, nachfragebewusste Abfrageumformulierung, das in drei Hauptmodulen besteht:

A. Posterior-basiertes Sample-Mining („Wann schreiben?")

Um zu bestimmen, wann eine Umformulierung notwendig ist, wird ein automatischer Mining-Prozess genutzt, der auf Nutzer-Feedback (Posterior) basiert.

• Positive Samples (Rewrite): Es werden Paare aus ursprünglicher Anfrage ($Q_{orig}$) und erfolgreicher Neuformulierung ($Q_{next}$) extrahiert, wenn der Nutzer bei der ersten Anfrage kurz verweilte ($< 2,4s$) und bei der zweiten lange ($> 10s$).
  • Filterung: Ein zweistufiger Filter stellt sicher, dass die Umformulierung tatsächlich auf dem Kontext (z. B. zuvor angesehene Videos) basiert und nicht nur eine Tippkorrektur ist. Ein LLM (Qwen3-32B) verifiziert die semantische Abhängigkeit.
• Negative Samples (Reject): Anfragen, die sofort zu einer langen Verweildauer führten, ohne dass der Nutzer die Anfrage änderte, werden als „Reject"-Beispiele markiert, um dem Modell beizubringen, wann es nicht umschreiben soll.

B. Stil-abgestimmtes LLM-Fine-Tuning („Wie schreiben?")

Das Modell wird in einem hybriden Trainingsparadigma trainiert, um sowohl semantische Genauigkeit als auch Systemkompatibilität zu gewährleisten.

• Supervised Fine-Tuning (SFT): Das Modell lernt aus den geminingen Daten, wann es umschreiben muss und wann es den Token <reject> ausgibt.
• Reinforcement Learning (RL) mit GRPO: Um sicherzustellen, dass die generierten Anfragen im Suchindex gefunden werden, wird eine Belohnungsfunktion (Reward Function) verwendet, die auf der historischen Suchfrequenz und der Click-Through-Rate (CTR) basiert.
  • GRPO (Group Relative Policy Optimization): Anstatt eines separaten Value-Netzwerks wird GRPO eingesetzt. Für jede Eingabe werden mehrere Rewrites generiert, und die Vorteile werden relativ zur Gruppe berechnet. Dies optimiert das Modell darauf, „suchbare" und index-freundliche Anfragen zu generieren, während die Abweichung vom Referenzmodell durch KL-Divergenz bestraft wird.

C. Deployment: „Fake Recall" Architektur

Um die Latenzprobleme zu lösen, wird eine parallele Architektur eingeführt:

• Fake Index: Ein vorbereiteter Key-Value-Index ($I_{fake}$) speichert die Top-Ergebnisse für gängige Suchanfragen.
• Paralleler Ablauf: Wenn eine Suchanfrage eingeht, läuft der traditionelle Suchpfad (Text/Vector Recall) parallel zum LLM-Inferenzpfad.
• Asynchrone Inferenz: Das LLM generiert die umformulierte Anfrage ($Q_{rew}$) asynchron. Falls diese im Fake Index vorhanden ist, werden die Ergebnisse sofort abgerufen.
• Fusion: Die Ergebnisse aus dem Fake Index werden mit den Hauptkandidaten fusioniert. Da die LLM-Inferenz parallel zum schweren Recall-Prozess läuft, entsteht keine zusätzliche wahrgenommene Latenz für den Nutzer.

3. Wichtige Beiträge

1. Posterior-basierte „Wann"-Strategie: Ein automatischer Mechanismus, der hochqualitative Trainingsdaten extrahiert und sicherstellt, dass Personalisierung nur dann erfolgt, wenn sie durch negatives Feedback auf die ursprüngliche Anfrage gerechtfertigt ist.
2. GRPO-abgestimmtes „Wie"-Training: Ein hybrides SFT- und RL-Training, das die Ausgabe des LLMs an den Suchindex anpasst und so die Retrieval-Effizienz maximiert.
3. Fake-Recall-Deployment: Eine innovative Architektur, die die Inferenzkosten von LLMs von dem kritischen Pfad entkoppelt und so eine personalisierte Suche ohne Latenzstrafe ermöglicht.

4. Ergebnisse

Das Framework wurde in großangelegten Online A/B-Tests auf einer großen Videoplattform evaluiert (Modell: Qwen3-4B + SFT + GRPO):

• Click-Through Video Volume (VV>10s): Steigerung um 1,07 %.
• Query Reformulation Rate: Reduktion um 2,97 % (Nutzer müssen weniger oft ihre Suchanfragen korrigieren).

5. Bedeutung und Fazit

Das Paper adressiert die Lücke zwischen generischen Suchmaschinen und personalisierten Nutzerbedürfnissen in der Videosuche. WeWrite beweist, dass explizite, generative Personalisierung effektiv Ambiguitäten auflösen kann, ohne die Systemleistung zu beeinträchtigen. Durch die Kombination von datengesteuertem Mining, stilorientiertem Reinforcement Learning und einer cleveren Parallelisierungsstrategie bietet das Framework einen skalierbaren Weg, um Large Language Models in Echtzeit-Suchsystemen mit strengen Latenzanforderungen einzusetzen. Dies stellt einen signifikanten Fortschritt gegenüber rein kontextunabhängigen oder rein statistischen Ansätzen dar.