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

El paper presenta WeWrite, un marco innovador de reescritura de consultas para búsqueda de video que utiliza una estrategia de minería posterior para determinar cuándo personalizar, un entrenamiento híbrido (SFT y GRPO) para optimizar cómo reescribir y una arquitectura de "Fake Recall" para garantizar baja latencia, logrando mejoras significativas en el volumen de clics y la reducción de reformulación de consultas en pruebas A/B a gran escala.

Lo esencial

¡Claro que sí! Imagina que el buscador de videos de una aplicación (como los canales de WeChat) es como un bibliotecario gigante que tiene millones de libros (videos) pero a veces no entiende bien lo que quieres.

Aquí te explico el paper "WeWrite" como si fuera una historia sobre cómo mejorar a ese bibliotecario, usando analogías sencillas:

🎯 El Problema: El Bibliotecario Confundido

Imagina que entras a la biblioteca y dices: "Quiero ver a Guang Liang".

• El problema: "Guang Liang" puede ser un cantante famoso o una marca de licor.
• El error antiguo: El bibliotecario tradicional te da resultados para ambos o adivina al azar. Si tú en realidad querías el licor porque estás planeando una fiesta, pero te muestra videos del cantante, te frustras y tienes que volver a preguntar: "¡No, el licor!". Esto es molesto y lento.

Además, si buscas algo muy específico como "cómo usar una freidora de aire", el bibliotecario no debería cambiar tu búsqueda basándose en que ayer viste videos de chistes de parejas. ¡Eso sería confundir tus intenciones!

💡 La Solución: "WeWrite", el Bibliotecario Inteligente

Los autores crearon un sistema llamado WeWrite que actúa como un bibliotecario con "superpoderes" que lee tu mente (tu historial) pero solo cuando es realmente necesario. Se plantean dos preguntas clave: ¿Cuándo escribir? y ¿Cómo escribir?

1. ¿Cuándo escribir? (El Semáforo de la Necesidad)

Antes, el bibliotecario intentaba reescribir todo lo que decías, lo cual generaba ruido.

• La analogía: Imagina un semáforo inteligente.
• Cómo funciona: El sistema observa tu comportamiento. Si buscas algo y no haces clic en nada (te aburres en 2 segundos), el semáforo se pone en ROJO (¡Error! No le gustó). Si luego cambias la búsqueda y ves un video por más de 10 segundos, el semáforo se pone en VERDE (¡Éxito!).
• La magia: El sistema solo aprende a reescribir cuando ve que el usuario realmente necesitó ayuda para encontrar lo que quería. Si tu búsqueda original fue perfecta, el sistema dice: "¡No toques nada!" y deja que sigas buscando tal cual. Esto evita que te recomiende cosas raras solo porque ayer viste un video de gatos.

2. ¿Cómo escribir? (El Entrenamiento de Estilo)

Una vez que saben que deben ayudar, ¿cómo lo hacen? Aquí usan una técnica de entrenamiento de dos pasos para la Inteligencia Artificial (IA):

• Paso A (SFT - Supervisión): Le enseñan al bibliotecario ejemplos de "buenas correcciones". Es como darle un libro de reglas: "Si el usuario busca 'Guang Liang' y antes vio videos de licor, la respuesta correcta es 'Licor Guang Liang'".
• Paso B (GRPO - Refinamiento por Recompensa): Aquí está la parte genial. A veces, la IA puede inventar palabras muy raras que el bibliotecario no encuentra en sus estantes. Para evitar esto, usan un sistema de premios y castigos.
  • Si la IA sugiere una frase que la gente suele buscar y le da muchos "me gusta" (clics), gana puntos.
  • Si inventa una frase que nadie usa, pierde puntos.
  • El resultado: La IA aprende a hablar el "idioma" que el sistema de búsqueda entiende mejor, sin perder la esencia de lo que tú quieres.

3. El Truco de Magia: "Recall Falso" (Fake Recall)

El mayor miedo al usar IA en búsquedas en tiempo real es la velocidad. Si la IA tarda 2 segundos en pensar, el usuario se va.

• La analogía: Imagina que el bibliotecario tiene un asistente fantasma que trabaja en paralelo.
• Cómo funciona: Mientras el sistema principal busca tus videos (la búsqueda normal), el asistente fantasma (la IA) empieza a pensar tu nueva búsqueda al mismo tiempo.
• El truco: El asistente tiene una "lista de resultados pre-cargada" (un índice falso) con los videos más populares. Si la IA piensa en una nueva búsqueda, consulta esa lista instantáneamente.
• El efecto: Cuando el sistema principal termina su búsqueda, el asistente ya tiene los resultados listos. Se unen los dos resultados y te los muestra. Tú no sientes ningún retraso. Es como si el bibliotecario hubiera adivinado lo que querías antes de que terminaras de hablar.

🏆 Los Resultados (El Final Feliz)

Cuando probaron esto en la vida real con millones de usuarios:

1. Más videos vistos: La gente vio más videos durante más de 10 segundos (porque encontró lo que quería más rápido).
2. Menos frustración: La gente dejó de tener que corregir sus búsquedas tantas veces.

En resumen:
"WeWrite" es como darle a un bibliotecario un mapa de tus gustos, enseñarle a esperar a que realmente necesites ayuda antes de intervenir, y darle un asistente fantasma para que todo sea instantáneo. ¡Así, cuando buscas algo, la app simplemente "te entiende"!

Resumen técnico

Resumen Técnico: WeWrite

1. El Problema

En los sistemas de búsqueda de videos de formato corto (como los Canales de WeChat), las consultas de los usuarios suelen ser breves y ambiguas. Los motores de búsqueda tradicionales a menudo fallan al satisfacer intenciones latentes específicas (por ejemplo, distinguir entre un cantante y una marca de licores con el mismo nombre) porque dependen de características de historial implícitas que sufren de:

• Dilución de señales: El historial de comportamiento es ruidoso y no siempre indica la intención actual.
• Retraso en la retroalimentación: Las señales de satisfacción (como el tiempo de visualización) llegan tarde.
• Reescritura indiscriminada: Los métodos existentes que intentan personalizar todas las consultas corren el riesgo de causar una desviación de la intención (intent drift). Por ejemplo, reescribir una consulta funcional (como "air fryer" para recetas) basándose en un historial de entretenimiento puede llevar al usuario a resultados irrelevantes.
• Latencia: La integración directa de Modelos de Lenguaje Grande (LLM) en la ruta síncrona de búsqueda en tiempo real es prohibitiva debido a su alto costo de inferencia.

2. Metodología: El Framework WeWrite

Los autores proponen WeWrite, un marco de reescritura de consultas consciente de la demanda personalizada que aborda dos preguntas fundamentales: ¿Cuándo escribir? y ¿Cómo escribir?. El sistema consta de tres módulos principales:

A. Minería de Muestras Basada en Posterior (¿Cuándo Escribir?)
Para evitar la reescritura innecesaria, el sistema identifica automáticamente escenarios donde la personalización es estrictamente necesaria utilizando el comportamiento posterior del usuario (reformulación de consultas y tiempo de permanencia).

• Muestras Positivas (Rewrite): Se extraen pares de consultas donde el usuario falló inicialmente (bajo tiempo de permanencia, < 2.4s) y luego tuvo éxito tras reformular la consulta (alto tiempo de permanencia, > 10s).
  • Filtro de Superposición de Contexto: Se verifica que los nuevos términos añadidos en la reformulación aparezcan en el historial del usuario (videos vistos, búsquedas previas).
  • Verificación de Intención con LLM: Un modelo maestro (Qwen3-32B) actúa como anotador experto para confirmar que la reformulación está explícitamente respaldada por el contexto del usuario y no es solo una corrección ortográfica.
• Muestras Negativas (Reject): Se identifican consultas originales que satisficieron al usuario inmediatamente (larga permanencia sin reformulación). El modelo aprende a emitir un token especial <reject> en estos casos, deteniendo el proceso de reescritura.

B. Ajuste Fino de LLM Alineado al Estilo (¿Cómo Escribir?)
Una vez determinado cuándo reescribir, el modelo debe generar consultas que sean semánticamente correctas y compatibles con el índice de búsqueda del sistema. Se utiliza un paradigma de entrenamiento híbrido:

1. Ajuste Fino Supervisado (SFT): Entrena al modelo (base Qwen) para aprender a generar la consulta reformulada o el token de rechazo basándose en el contexto y la consulta original.
2. Optimización de Política Relativa de Grupo (GRPO): Se introduce una fase de Aprendizaje por Refuerzo (RL) para alinear el estilo de salida del LLM con el índice de recuperación real.
   • Función de Recompensa: Se basa en el historial de búsqueda (180 días) y considera la frecuencia de búsqueda y la tasa de clics (CTR). Se penaliza la generación de términos desconocidos o "alucinados" que no existen en el índice.
   • Objetivo: Maximizar la probabilidad de que la consulta generada tenga un "acierto en el índice" (Index Hit Rate) y alta satisfacción del usuario, evitando el problema de "cero recuperaciones" (zero-recall).

C. Despliegue: Arquitectura "Fake Recall" (Recuperación Falsa)
Para resolver el problema de la latencia, se propone una arquitectura paralela que desacopla la inferencia del LLM de la ruta principal de búsqueda:

1. Construcción de Índice Falso: Se crea previamente un índice clave-valor (I_fake) que mapea consultas válidas a sus documentos de alto rendimiento (Top-K), utilizando tanto datos de interacción como logs de búsqueda históricos.
2. Ejecución Paralela: Cuando llega una solicitud de usuario:
   • La ruta de búsqueda tradicional (Texto/Vectores) se ejecuta simultáneamente.
   • El LLM genera la consulta reescrita (Q_rew) de forma asíncrona.
3. Fusión: Si la consulta reescrita existe en el I_fake, se recuperan candidatos instantáneamente (O(1)). Estos se fusionan con los resultados tradicionales.
   • Resultado: La latencia total no aumenta, logrando una personalización con "latencia cero percibida".

3. Contribuciones Clave

1. Estrategia "Cuándo" basada en Posterior: Un mecanismo automatizado de minería que utiliza retroalimentación explícita del usuario para filtrar cuándo la personalización es necesaria, mitigando la desviación de la intención.
2. Entrenamiento Híbrido SFT + GRPO: Un enfoque novedoso que combina el ajuste supervisado con optimización de política de refuerzo para asegurar que las consultas generadas no solo sean personalizadas, sino también "buscables" y compatibles con el índice del sistema.
3. Arquitectura de Despliegue "Fake Recall": Una solución de ingeniería que permite integrar LLMs en sistemas de búsqueda de video en tiempo real sin comprometer la latencia, mediante la recuperación asíncrona y la fusión de candidatos.

4. Resultados

El framework se evaluó mediante pruebas A/B a gran escala en una plataforma de video real:

• Volumen de Videos Clickeados (VV > 10s): Aumento del 1.07%. Esto indica una mayor satisfacción del usuario y una mejor relevancia de los resultados.
• Tasa de Reformulación de Consultas: Reducción del 2.97%. Esto demuestra que el sistema resuelve la ambigüedad en la primera consulta, reduciendo la necesidad de que el usuario busque nuevamente.

5. Significado e Impacto

El trabajo de WeWrite es significativo porque cierra la brecha entre la capacidad de los LLMs para entender el contexto y la necesidad práctica de los sistemas de búsqueda de alta velocidad.

• Superación de métodos implícitos: Muestran que el modelado explícito de la intención basada en el historial es superior a las aproximaciones tradicionales.
• Viabilidad Industrial: Demuestran que es posible desplegar modelos generativos complejos en entornos de producción con restricciones de latencia estrictas mediante arquitecturas inteligentes como "Fake Recall".
• Calidad de la Recuperación: Al alinear la generación del LLM con el índice de búsqueda (mediante GRPO), evitan el problema común de que los LLMs generen consultas creativas pero inútiles para el motor de búsqueda subyacente.

En resumen, WeWrite proporciona un marco robusto para la búsqueda de videos personalizada, equilibrando la precisión semántica, la relevancia del usuario y la eficiencia del sistema.