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

Dit artikel introduceert WeWrite, een nieuw raamwerk voor gepersonaliseerde query-herformulering in videosoeksystemen dat automatisch bepaalt wanneer personalisatie nodig is, een hybride trainingsparadigma gebruikt om de output van een LLM op zoekresultaten af te stemmen, en via een parallelle 'Fake Recall'-architectuur lage latentie garandeert, wat leidt tot een significante verbetering in kijkduur en een vermindering van query-herformuleringen.

De kern

Stel je voor dat je op zoek bent naar een video op je telefoon, maar je typt alleen maar "Guang Liang".

Voor een gewone zoekmachine is dit een raadsel. Bedoel je de beroemde Chinese zanger Guang Liang? Of bedoel je het merk Guang Liang drank? De machine raakt in de war en laat je misschien beide zien, of erger: de verkeerde.

De auteurs van dit paper (van Tencent) hebben een slimme oplossing bedacht, genaamd WeWrite. Het is als een super-vaardige persoonlijke assistent die meekijkt met wat jij eerder hebt gedaan, om precies te weten wat je wilt, voordat je zelfs maar je tweede zin typt.

Hier is hoe het werkt, vertaald in alledaags taalgebruik:

1. Het Grote Dilemma: "Moet ik nu ingrijpen?" (Wanneer schrijven?)

Stel je voor dat je een assistent hebt die altijd meepraat.

• Situatie A: Je typt "hoe maak ik een airfryer". Je assistent denkt: "Oh, je kijkt vaak naar grappige video's over koppels, dus ik ga je nu vertellen hoe je een airfryer gebruikt voor een date." Fout! Je wilde gewoon een recept. Je intentie is verdraaid.
• Situatie B: Je typt "Guang Liang" en kijkt naar niets. Je typt direct opnieuw: "Guang Liang drank". Je assistent denkt: "Ah, hij wilde de zanger niet, hij wilde de drank! Ik ga dat nu voor hem regelen." Goed!

De oplossing:
Deze assistent is niet dom; hij leert eerst wanneer hij moet praten. Ze hebben een slimme methode bedacht om te kijken naar wat gebruikers echt deden.

• Als iemand snel wegklikt en iets anders typt, is dat een teken: "Ik was niet tevreden, help me!" (Dit is een positief moment om in te grijpen).
• Als iemand direct een video lang kijkt, is dat een teken: "Ik was blij, laat me met rust." (Dit is een negatief moment; niet ingrijpen).

Zo leert de computer het verschil tussen "hulp nodig" en "alles is prima".

2. De Kunst van het Schrijven: "Hoe schrijf ik het?" (Hoe schrijven?)

Stel dat je assistent nu weet dat hij moet ingrijpen. Hoe schrijft hij de nieuwe zoekopdracht dan?

• Slecht: Hij schrijft iets heel creatiefs en complex, zoals "De beste Chinese drank voor een romantische avond met een knipoog". Dat klinkt mooi, maar de zoekmachine van de video-app begrijpt dat niet en vindt geen resultaten.
• Goed: Hij schrijft iets dat de zoekmachine graag ziet, zoals "Guang Liang drank merk".

De oplossing:
Ze hebben de assistent getraind in twee stappen:

1. Leren van voorbeelden (SFT): Ze gaven hem duizenden voorbeelden van goede zoekopdrachten.
2. Spelletjes spelen (RL/GRPO): Dit is het slimme deel. Ze lieten de assistent oefenen en gaven hem punten als hij zoekopdrachten bedacht die echt werkten in de database. Als hij iets bedacht dat de zoekmachine niet kon vinden, kreeg hij een straf. Zo leerde hij niet alleen wat je wilde, maar ook wat de computer kon vinden.

3. Het Snelheidsprobleem: "Hoe doen we dit zonder te wachten?"

Het grootste probleem met slimme AI-assistenten is dat ze vaak traag zijn. In een video-app wil je geen 2 seconden wachten op een zoekresultaat.

De oplossing: De "Valse Herinnering" (Fake Recall)
Dit klinkt raar, maar het is geniaal.
Stel je voor dat je in een supermarkt loopt.

• De oude manier: Je vraagt de manager (de AI) om te zoeken. De manager loopt naar de voorraadkamer, zoekt het product, en komt terug. Je wacht.
• De nieuwe manier (WeWrite): Terwijl de manager nog in de voorraadkamer loopt om het product te zoeken, heeft een andere medewerker al een voorbereide lijst met de populairste producten klaarstaan.
  • De AI schrijft je nieuwe zoekopdracht (in de achtergrond, terwijl je wacht).
  • Tegelijkertijd haalt de computer alvast de resultaten op uit die "voorbereide lijst" (de Fake Index).
  • Zodra de AI klaar is, worden de resultaten direct samengevoegd.

Voor jou, de gebruiker, voelt het alsof er geen enkele seconde is verstreken. Het is alsof je assistent al wist wat je wilde, voordat je het vroeg.

Wat is het resultaat?

Toen ze dit systeem live zetten bij een grote video-app (WeChat Channels), gebeurde er het volgende:

• Mensen keken meer video's (met meer dan 10 seconden).
• Mensen hoefden minder vaak hun zoekopdracht te herhalen.

Kortom:
WeWrite is een slimme, snelle en beleefde zoekassistent. Hij weet precies wanneer hij moet helpen, hij schrijft zoekopdrachten die de computer begrijpt, en hij doet dit zo snel dat je het niet eens merkt. Het maakt het zoeken naar video's veel persoonlijker en veel minder frustrerend.

Technische samenvatting

Titel: Wanneer en Hoe te Schrijven voor Gepersonaliseerde, Behoefte-bewuste Query-herformulering in Videozoekopdrachten

Auteurs: Cheng Cheng, Chenxing Wang, Aolin Li, Haijun Wu, Huiyun Hu, Juyuan Wang (Weixin Group, Tencent)

---

1. Het Probleem

In zoeksystemen voor korte video's (zoals WeChat Channels) zijn gebruikersquery's vaak kort en ambigu. Traditionele methoden voor query-herformulering (rewriting) hebben moeite om de intentie van de gebruiker correct te interpreteren zonder de context van eerdere gedragingen.

Er zijn twee hoofduitdagingen:

• Intentie-drift: Indiscriminatie herformulering kan leiden tot fouten. Bijvoorbeeld: een functionele zoekopdracht zoals "friteuse" (air fryer) wordt onterecht beïnvloed door de entertainmentgeschiedenis van de gebruiker, waardoor de resultaten irrelevant worden.
• Vertraging (Latency): Het gebruik van Large Language Models (LLM's) in de synchrone zoekpaden van real-time videozoeksystemen is vaak te traag vanwege de hoge inferentiekosten.
• Signaalverwatering: Traditionele methoden die gebruikmaken van impliciete geschiedeniskenmerken lijden vaak onder vertraagde feedback en verwaterde signalen.

2. Methodologie: Het WeWrite Framework

De auteurs stellen WeWrite voor, een nieuw raamwerk voor gepersonaliseerde, behoefte-bewuste query-herformulering. Het systeem bestaat uit drie kernmodules:

A. Wanneer Schrijven: Posterior-gebaseerde Steekproefmijnbouw

Om te bepalen wanneer een query herschreven moet worden, gebruiken de auteurs een geautomatiseerde strategie die gebruikmaakt van "posterior feedback" (gedrag na de zoekopdracht) om hoogwaardige trainingsdata te extraheren.

• Positieve Steekproeven (Rewrite): Het systeem identificeert sessies waarin de gebruiker ontevreden was met de oorspronkelijke query (korte kijktijd < 2,4s) en direct een nieuwe query invoerde die wel succesvol was (kijktijd > 10s).
  • Filtering: Er wordt gecontroleerd of de nieuwe termen in de herschreven query expliciet voorkomen in de gebruikersgeschiedenis (bijv. titels van eerder bekeken video's). Een LLM (Qwen3-32B) fungeert als "data-annotator" om te verifiëren of de herformulering daadwerkelijk door de context wordt gedreven.
• Negatieve Steekproeven (Reject): Sessies waarin de oorspronkelijke query direct leidde tot tevredenheid (lange kijktijd) worden gemarkeerd als "geen herschrijving nodig". Dit leert het model wanneer het niet moet ingrijpen.

B. Hoe Schrijven: Stijl-gealigneerde LLM Fine-tuning

Om te bepalen hoe de query herschreven moet worden, wordt een hybride trainingsparadigma gebruikt dat Supervised Fine-Tuning (SFT) combineert met Reinforcement Learning (RL).

• Supervised Fine-Tuning (SFT): Het model leert de basis van het genereren van herschreven queries of het token <reject> te gebruiken, gebaseerd op de gemineerde dataset.
• Reinforcement Learning (GRPO): Om ervoor te zorgen dat de gegenereerde queries ook daadwerkelijk goed werken in het bestaande zoekindex (en niet "hallucineren" of zeldzame termen gebruiken), wordt Group Relative Policy Optimization (GRPO) toegepast.
  • Reward Functie: De beloning is gebaseerd op historische zoeklogboeken en omvat:
    1. Zoekfrequentie (om populaire, goed geïndexeerde queries te stimuleren).
    2. Click-Through Rate (CTR) (voor gebruiksbevrediging).
    3. Een straf voor het genereren van onbekende termen.
  • Dit zorgt ervoor dat de output van de LLM past bij de stijl en de index van het terugroepsysteem (retrieval system).

C. Implementatie: "Fake Recall" Architectuur

Om het probleem van latentie op te lossen, wordt een parallelle architectuur gebruikt:

• Fake Index: Er wordt een vooraf opgebouwde Key-Value index (I_fake) gecreëerd die de top-documenten voor geldige system-query's cacheert.
• Parallelle Executie: Wanneer een gebruiker een zoekopdracht invoert, draait het traditionele zoekpad (tekst/vector) en het herschrijvingspad (LLM) parallel.
• Asynchrone Inferentie: De LLM berekent de herschreven query asynchroon. Als deze query een match vindt in de "Fake Index", worden de resultaten direct opgehaald.
• Fusie: De resultaten van de herschreven query worden gefuseerd met de hoofdresultaten. Omdat de LLM-inferentie parallel loopt met de zware terugroepfase, blijft de totale latentie ongewijzigd (zero-perceived-latency).

3. Belangrijkste Bijdragen

1. Posterior-gebaseerde "Wanneer"-strategie: Een mechanisme dat automatisch bepaalt wanneer personalisatie strikt noodzakelijk is, waardoor intentie-drift wordt voorkomen.
2. GRPO-gealigneerde "Hoe"-training: Een hybride trainingsaanpak (SFT + RL) die de output van de LLM afstemt op de index van het zoeksysteem, waardoor de gegenereerde queries zowel gepersonaliseerd als terugroepvriendelijk zijn.
3. Fake Recall-deployments: Een innovatieve parallelle architectuur die de latentieproblemen van LLM's in real-time systemen oplost.

4. Resultaten

Het framework is getest via grote online A/B-tests op een groot video-platform:

• Click-Through Video Volume (VV>10s): Een toename van 1,07%. Dit betekent dat gebruikers vaker video's bekijken die langer dan 10 seconden duren.
• Query Reformulering Rate: Een daling van 2,97%. Dit geeft aan dat gebruikers minder vaak hun zoekopdracht hoeven aan te passen omdat de eerste resultaten al relevant waren.

5. Betekenis en Conclusie

Dit paper toont aan dat expliciete, gepersonaliseerde query-herformulering met LLM's haalbaar en effectief is in productiesystemen, mits de juiste strategieën worden toegepast voor timing, training en implementatie.

• Het lost het probleem op van "wanneer" te herschrijven door te vertrouwen op feitelijke gebruikersfeedback in plaats van aannames.
• Het lost het probleem op van "hoe" te herschrijven door de LLM te trainen op de specifieke beperkingen en voorkeuren van het zoekindex.
• Het overwint de technische barrière van latentie door een slimme parallelle architectuur.

De resultaten bewijzen dat deze aanpak de gebruikerstevredenheid significant verhoogt bij het omgaan met ambiguïteit in zoekopdrachten voor korte video's.