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

Ce papier présente WeWrite, un cadre innovant de réécriture de requêtes pour la recherche vidéo qui détermine automatiquement le moment opportun pour personnaliser, utilise un entraînement hybride SFT-GRPO pour aligner le style de sortie, et déploie une architecture « Fake Recall » parallèle, améliorant ainsi le volume de vidéos cliquées et réduisant le taux de reformulation des requêtes.

L'essentiel

Imaginez que vous êtes dans une immense bibliothèque de vidéos (comme WeChat Channels), et que vous cherchez quelque chose. Le problème, c'est que vous ne savez pas toujours bien comment le dire.

Ce papier de recherche présente WeWrite, un nouveau système intelligent conçu pour aider les moteurs de recherche vidéo à mieux comprendre ce que vous voulez vraiment, même quand votre demande est floue.

Voici comment cela fonctionne, expliqué simplement avec des analogies :

1. Le Problème : La confusion du bibliothécaire

Parfois, vous tapez un mot comme "Guang Liang".

• Le problème : Est-ce que vous cherchez le chanteur Guang Liang ou la marque de liqueur Guang Liang ?
• L'ancien système : Il vous donne un mélange des deux, comme un bibliothécaire qui ne connaît pas vos goûts personnels.
• Le risque : Si vous cherchez juste une recette de cuisine ("Air fryer"), le système ne doit pas vous montrer des blagues sur les couples juste parce que vous avez regardé des vidéos drôles hier. Il faut savoir quand intervenir et quand rester tranquille.

2. La Solution : WeWrite, le "Super-Assistant"

L'équipe de Tencent a créé un assistant (basé sur une intelligence artificielle avancée) qui résout trois défis majeurs :

A. Quand écrire ? (Le détective de l'intention)

C'est la question : "Dois-je aider l'utilisateur à reformuler sa recherche ?"

• L'analogie : Imaginez un détective qui observe vos actions.
  • Si vous tapez une recherche, regardez les résultats pendant 2 secondes, puis changez immédiatement de recherche, le détective dit : "Ah ! Il n'a pas trouvé ce qu'il voulait. Je vais utiliser son historique (ce qu'il a regardé avant) pour deviner ce qu'il cherche vraiment."
  • Si vous tapez "Air fryer" et que vous regardez une vidéo de cuisine pendant 10 minutes, le détective dit : "Tout va bien, pas besoin d'intervenir."
• La méthode : Le système analyse vos "signaux" (temps de regard, changements de recherche) pour ne proposer une aide que lorsque c'est vraiment nécessaire, évitant ainsi de vous embêter inutilement.

B. Comment écrire ? (Le traducteur qui connaît la bibliothèque)

Une fois décidé d'aider, comment reformuler la recherche ?

• Le défi : Si l'IA invente une phrase trop compliquée ou bizarre, la bibliothèque (le moteur de recherche) ne trouvera aucun livre correspondant. C'est comme demander un livre avec un titre que personne n'a jamais écrit.
• La méthode (SFT + GRPO) :
  1. Apprentissage (SFT) : On apprend à l'IA à bien comprendre le contexte (votre historique).
  2. Entraînement par récompense (GRPO) : C'est comme un jeu de rôle. L'IA propose plusieurs reformulations. On lui donne des points si la reformulation ressemble à des mots que les gens utilisent souvent et qui fonctionnent bien dans la bibliothèque. Si elle invente des mots bizarres, elle perd des points.
  • Résultat : L'IA apprend à écrire des requêtes qui sont à la fois personnelles (pour vous) et compatibles avec le système de recherche.

C. Le déploiement : La "Fausse Mémoire" (Fake Recall)

C'est le défi technique le plus dur : La vitesse.

• Le problème : Les intelligences artificielles sont lentes à réfléchir. Si on attend qu'elle réfléchisse avant de vous montrer les vidéos, vous allez attendre trop longtemps et partir.
• La solution (Architecture "Fake Recall") :
  • Imaginez un restaurant. Au lieu d'attendre que le chef cuisine votre plat spécial (la reformulation) avant de vous servir, le serveur prépare deux assiettes en même temps :
    1. L'assiette standard (recherche classique).
    2. L'assiette "spéciale" (recherche personnalisée).
  • Pendant que le chef (l'IA) travaille sur l'assiette spéciale, le serveur a déjà pré-rangé les plats les plus probables dans un tiroir rapide (la "Fausse Mémoire").
  • Dès que le chef a fini, on mélange les deux assiettes. Pour vous, le client, le temps d'attente est le même, mais vous recevez des résultats beaucoup plus pertinents.

3. Les Résultats

En testant ce système sur une vraie plateforme vidéo :

• Les gens ont regardé plus de vidéos (ceux qui dépassent 10 secondes).
• Les gens ont moins souvent changé de recherche (ils ont trouvé ce qu'ils voulaient du premier coup).

En résumé : WeWrite est comme un bibliothécaire très attentif qui sait exactement quand vous aider à trouver votre chemin, qui parle le langage de la bibliothèque pour ne pas se tromper de rayon, et qui le fait si vite que vous ne remarquez même pas qu'il travaille.

Résumé technique

1. Problématique

Dans les moteurs de recherche de vidéos à court terme (comme WeChat Channels), les requêtes utilisateurs sont souvent brèves et ambiguës. Les méthodes traditionnelles de réécriture de requêtes souffrent de deux limitations majeures :

• Dilution du signal et feedback tardif : L'utilisation de fonctionnalités historiques implicites ne capture pas toujours l'intention réelle de l'utilisateur.
• Risque de dérive d'intention (Intent Drift) : Une réécriture indiscriminée peut biaiser une requête fonctionnelle (ex: « friteuse à air ») vers des résultats de divertissement basés sur l'historique de l'utilisateur, ce qui dégrade l'expérience.
• Latence : L'intégration directe de modèles de langage (LLM) dans le chemin de recherche synchrone est prohibitive en raison de leur coût d'inférence élevé.

L'objectif est donc de concevoir un système capable de déterminer quand la personnalisation est strictement nécessaire et comment générer des réécritures qui s'alignent à la fois sur l'intention de l'utilisateur et sur l'index de recherche existant, tout en respectant des contraintes de latence strictes.

2. Méthodologie : Le Framework WeWrite

Les auteurs proposent WeWrite, un cadre de réécriture de requêtes personnalisé et conscient de la demande, structuré en trois modules principaux :

A. Stratégie de « Quand écrire » : Minage d'échantillons basé sur le postérieur

Pour éviter la réécriture inutile, le système identifie automatiquement les scénarios où la personnalisation est cruciale en exploitant les logs de comportement utilisateur (feedback postérieur).

• Échantillons Positifs (Réécriture nécessaire) : Identification de paires de requêtes où l'utilisateur a échoué avec la requête originale ($Q_{orig}$, temps de visionnage < 2,4s) puis a réussi avec une reformulation ($Q_{next}$, temps de visionnage > 10s).
  • Filtrage : Un filtre de chevauchement contextuel et une vérification par un LLM (Qwen3-32B) assurent que les nouveaux termes de la reformulation sont explicitement soutenus par l'historique de l'utilisateur (vidéos regardées, géolocalisation).
• Échantillons Négatifs (Ne pas réécrire) : Identification des requêtes originales ayant conduit immédiatement à une satisfaction (temps de visionnage long) sans reformulation. Le modèle apprend à émettre un token <reject> dans ces cas.

B. Stratégie de « Comment écrire » : Alignement de style par Fine-Tuning Hybride

Une fois le moment déterminé, le modèle doit apprendre à générer des requêtes qui fonctionnent avec l'index de recherche.

• Supervised Fine-Tuning (SFT) : Entraînement initial sur les données minées pour apprendre la sémantique de la réécriture et la décision de rejeter.
• Reinforcement Learning (RL) avec GRPO : Pour résoudre le problème de « zero-recall » (où le LLM génère des requêtes sémantiquement correctes mais absentes de l'index), les auteurs utilisent l'optimisation de politique relative de groupe (GRPO).
  • Fonction de Récompense : Basée sur la fréquence historique de recherche et le taux de clic (CTR). Elle pénalise les termes inconnus (hallucinations) et favorise les requêtes populaires et bien indexées.
  • Cela aligne le style de sortie du LLM avec la distribution des requêtes du système de recherche réel.

C. Déploiement : Architecture « Fake Recall » Parallèle

Pour contourner la latence, l'inférence du LLM est découplée du chemin principal de recherche.

• Construction d'un Index Factice (Fake Index) : Un index clé-valeur pré-construit ($I_{fake}$) stocke les meilleurs documents pour les requêtes valides, combinant des données d'interaction (pour les requêtes populaires) et des logs de recherche (pour les requêtes de longue traîne).
• Fusion Parallèle :
  1. Le chemin de recherche traditionnel (Texte/Vecteur) et le chemin de réécriture personnalisée (LLM) sont lancés simultanément.
  2. Si le LLM génère une requête, elle est interrogée contre l'index factice en temps constant ($O(1)$).
  3. Les résultats sont filtrés par un modèle de pertinence léger puis fusionnés avec les résultats principaux.
  • Résultat : La latence totale reste inchangée car l'inférence LLM se fait en parallèle du processus de rappel lourd.

3. Contributions Clés

1. Stratégie « Quand » automatisée : Un mécanisme de minage basé sur le feedback postérieur qui identifie précisément les cas où la personnalisation est nécessaire, réduisant le bruit et la dérive d'intention.
2. Entraînement « Comment » aligné (SFT + GRPO) : Une approche hybride qui combine l'apprentissage supervisé avec une optimisation par renforcement axée sur la récupération (retrieval-oriented), garantissant que les requêtes générées sont à la fois personnalisées et récupérables par l'index.
3. Architecture de déploiement « Fake Recall » : Une solution ingénieuse permettant d'intégrer des LLM dans des systèmes de recherche vidéo en temps réel sans pénalité de latence, en utilisant un cache de résultats pré-calculés.

4. Résultats Expérimentaux

Des tests A/B à grande échelle sur une plateforme vidéo majeure ont démontré l'efficacité de WeWrite :

• Augmentation du volume de vidéos cliquées (VV > 10s) : +1,07 %.
• Réduction du taux de reformulation de requête : -2,97 % (les utilisateurs n'ont plus besoin de reformuler leur recherche car le système a correctement anticipé leur intention).

5. Signification et Impact

Ce travail marque une avancée significative dans l'application des LLM à la recherche d'information personnalisée. Il démontre que :

• La personnalisation explicite peut surpasser les modèles implicites traditionnels si elle est déclenchée de manière sélective.
• L'alignement des LLM avec les contraintes de l'index de recherche (via RL) est crucial pour éviter les échecs de récupération.
• Il est possible de déployer des modèles génératifs complexes dans des environnements de production à faible latence grâce à des architectures parallèles innovantes comme le « Fake Recall ».

En résumé, WeWrite résout le dilemme entre pertinence personnalisée et performance système, offrant une expérience de recherche vidéo plus fluide et précise.