WeWrite: 个性化需求感知查询改写框架 — 深度解读

论文: WeWrite: When & How to Write for Personalized Demand-aware Query Rewriting in Video Search
链接: arXiv:2602.17667

1. 问题与动机

核心问题：短视频搜索场景中，用户查询通常简短且高度歧义，如何利用用户历史行为进行个性化查询改写，同时满足线上低延迟要求？

具体挑战：

• 歧义性：论文举了一个直觉的例子——用户搜索"光良"，可能指歌手光良，也可能指光良酒业。传统搜索系统对所有用户返回相同结果，无法区分个体意图。
• "何时改写"的决策缺失：现有方法通常对所有查询无差别改写，这会带来意图漂移风险。例如功能性查询"空气炸锅"不应因用户娱乐历史被改写为某个具体品牌。论文指出 indiscriminate rewriting（无差别改写）是一个被长期忽视的问题。
• 系统延迟瓶颈：LLM 推理的高计算成本与线上搜索系统严格的实时性要求存在天然矛盾。

为什么重要：

在大规模短视频平台上，搜索体验直接影响用户留存和消费深度。传统的统计同义词挖掘缺乏个性化能力，基于隐式历史特征的方法存在信号稀释和反馈延迟问题，而已有的生成式方法（如 Query2doc、CardRewriter）均是 context-agnostic 的。WeWrite 是首个显式提出"需求感知"（demand-aware）个性化改写的工作，填补了"何时改写"这一决策环节的空白。

2. 方法概述

WeWrite 框架围绕三个核心问题设计：When to Write → How to Write → How to Deploy。

整体流程

用户查询 Q + 用户上下文 Cᵤ
         │
    ┌────┴────┐
    │ When?   │  ← 后验挖掘策略判断是否需要改写
    └────┬────┘
         │ 需要改写
    ┌────┴────┐
    │ How?    │  ← SFT + GRPO 训练的 LLM 生成改写
    └────┬────┘
         │ 改写结果 Q'
    ┌────┴────┐
    │ Deploy  │  ← Fake Recall 并行架构，零感知延迟
    └─────────┘

用户上下文定义：Cᵤ = {Hquery（历史搜索序列）, Hvideo（近期观看视频标题/标签）, G（地理位置特征）}

优化目标：学习条件生成策略 πθ(Q′|Q, Cᵤ)，最大化反映用户满意度和系统可检索性的期望奖励：

θ* = argmax_θ E[R(Q', Isys)]

其中 Isys 表示线上搜索索引，R(·) 是奖励函数。这个目标函数的设计精妙之处在于同时考虑语义正确性和系统兼容性。

3. 核心技术贡献

贡献一：后验驱动的"何时改写"挖掘策略

这是论文最独特的贡献。通过用户反馈信号自动识别哪些查询真正需要个性化改写。

正样本挖掘（需要改写的场景）：

选取满足以下条件的查询对 (Qorig, Qnext)：

• 失败信号：原始查询停留时间 Torig < 2.4 秒（用户不满意）
• 成功信号：用户自行改写后的查询停留时间 Tnext > 10 秒（用户满意）

然后经过两阶段过滤确保质量：

1. 粗粒度：上下文重叠过滤 — 提取新增词项 ΔT = Terms(Qnext) \ Terms(Qorig)，要求至少一个新词出现在用户历史中，确保意图转变有行为根据
2. 细粒度：LLM 意图验证 — 使用教师模型（Qwen3-32B）进行二分类，判断改写是否确实由用户上下文驱动

负样本挖掘（不需要改写的场景）：

• 用户未改写且产生长时间消费（Torig > τlong）
• 训练目标为特殊 token <reject>，教会模型"拒绝改写"

这种设计的核心洞察是：不是所有查询都需要改写，学会说"不"同样重要。

贡献二：风格对齐的两阶段训练

阶段一：SFT — 在挖掘的正负样本上进行监督微调，让模型学会基本的改写和拒绝能力。

阶段二：GRPO 强化学习 — 解决零召回问题（zero-recall problem）：语义正确的改写可能在线上索引中没有对应文档。

奖励函数设计精巧：

R(Qrew) = λ₁·log(Freq(Qrew)) + λ₂·CTR(Qrew),  若 Qrew ∈ Vsys（系统可检索）
         = Rpenalty,                              否则（惩罚幻觉查询）

• Freq(Qrew)：历史搜索频率 — 鼓励生成高频、系统已索引的查询
• CTR(Qrew)：历史平均点击率 — 确保改写后的查询确实能带来好的用户体验
• Rpenalty：对不在系统索引中的"幻觉查询"施加惩罚

使用 GRPO（Group Relative Policy Optimization）而非 PPO 的优势在于无需训练 critic 模型，通过组内相对优势计算来归一化奖励：Aᵢ = (R(Q'ᵢ) - μ) / σ。

贡献三：Fake Recall 并行部署架构

解决 LLM 推理延迟问题的工程创新：

1. 预构建 Fake 索引：

- 头部查询：基于历史 CTR 和停留时间缓存 Top-50 文档（交互式构建）
- 长尾查询：使用历史检索日志补充（检索式构建）
- 实现 O(1) 查找时间

1. 并行执行：LLM 改写与传统检索（文本/向量召回）同时触发，LLM 结果命中 Fake 索引后直接获取候选文档，经相关性过滤后与主候选集融合。

关键创新：将 LLM 从搜索关键路径中解耦，实现"零感知延迟个性化"。

与现有方法的关键区别

4. 实验结果分析

线上 A/B 测试

论文在大规模短视频平台上进行了生产环境 A/B 测试，部署模型为 Qwen3-4B + SFT + GRPO：

结果分析：

1. VV>10s 提升 1.07%：在大规模搜索系统中，这是一个显著的在线提升。有效播放量是比 CTR 更深层的满意度指标，说明个性化改写确实帮助用户找到了更符合意图的视频内容。

1. 查询改写率降低 2.97%：这是一个非常有说服力的指标——用户不再需要自己费力地修改查询词，说明系统已经"理解"了用户真实意图。这个指标的下降幅度几乎是 VV 提升的 3 倍，暗示 WeWrite 在减少搜索摩擦方面效果尤为突出。

1. 模型选择：使用 4B 参数量的 Qwen3 而非更大模型，体现了工程实用性考量——在效果和推理成本之间取得平衡。

技术设计验证

• 两阶段过滤（粗粒度 + 细粒度）有效保证了训练数据质量
• <reject> 机制避免了无差别改写带来的意图漂移
• GRPO 阶段有效解决了 SFT 模型的零召回问题，生成的查询更匹配线上索引分布

5. 局限与未来方向

现有局限

1. Fake 索引覆盖度：预构建索引本质上是一种缓存策略，对于极端长尾查询或新兴热点话题，可能存在覆盖不足的问题。当改写结果未命中 Fake 索引时，个性化改写完全失效。

1. 用户上下文的局限性：当前仅使用历史搜索、观看视频和地理位置三类信号，未纳入社交关系、关注列表、创作行为等更丰富的上下文，个性化粒度有提升空间。

1. 后验挖掘的覆盖偏差：正样本挖掘依赖"用户先失败再成功"的行为模式，这意味着只能学习到用户已经自行解决的歧义场景，无法覆盖用户因歧义直接流失的情况（survivorship bias）。

1. 评估指标有限：论文仅报告了两个在线指标，缺少离线评估（如改写准确率、意图匹配率）和消融实验的详细数据，难以量化各模块的独立贡献。

1. 教师模型依赖：正样本挖掘依赖 Qwen3-32B 进行意图验证，这引入了额外的成本和潜在的级联错误。

未来方向

1. 动态 Fake 索引更新：引入实时或近实时的索引更新机制，提升对新内容和热点的覆盖。
2. 多模态上下文融合：结合用户观看视频的视觉/音频特征，而非仅使用标题标签，实现更深层的意图理解。
3. 端到端强化学习：探索直接使用用户在线反馈作为奖励信号的在线 RL 方案，减少对后验挖掘的依赖。
4. 改写置信度机制：为 <reject> 引入连续置信度分数，实现更细粒度的改写决策（部分改写 vs 完全改写 vs 不改写）。
5. 跨场景迁移：将框架扩展到电商搜索、音乐搜索等其他垂直领域。

6. 工业实践意义

对搜索系统的启示

1. "何时触发"比"如何执行"更重要：WeWrite 最核心的工程洞察是——在搜索链路中增加 LLM 能力时，精准的触发策略比改写质量本身更重要。盲目的全量改写不仅浪费算力，还会引入意图漂移。这对所有计划在搜索中引入 LLM 的团队都是重要提醒。

1. 后验挖掘是低成本获取高质量训练数据的范式：通过"用户先失败后自行修正"的行为模式来挖掘 (query, rewrite) 样本对，巧妙地利用了用户行为作为免费标注信号，避免了昂贵的人工标注。这种数据挖掘范式可以推广到任何有用户反馈的搜索/推荐场景。

1. <reject> 设计模式值得借鉴：在训练集中显式加入"不需要干预"的负样本，教会模型何时保持沉默。这一设计可以推广到查询纠错、查询补全、相关搜索推荐等多个模块。

对推荐系统的启示

1. GRPO 对齐检索系统的思路：用搜索频率和 CTR 作为奖励信号来约束 LLM 的生成分布，使其产出"系统友好"的查询——这种将下游系统指标作为 RL 奖励的思路，可以直接迁移到推荐理由生成、商品标题改写等场景。

1. Fake Recall 架构是一种通用的 LLM 上线模式：预构建索引 + 并行执行 + 异步融合的部署范式，本质上是用空间换时间，适用于所有需要在延迟敏感的实时系统中引入 LLM 的场景（如推荐系统的实时重排、广告创意生成等）。

对广告系统的启示

1. 个性化查询理解可直接迁移至广告检索：广告系统中的查询改写同样面临歧义问题（例如搜索"苹果"是要买手机还是水果），WeWrite 的个性化改写 + 需求感知机制可以显著提升广告相关性和转化率。

关键工程 Takeaway

核心原则：在工业搜索系统中引入 LLM，关键不是模型有多大、改写有多"智能"，而是：
- 精准识别需要干预的场景（When）
- 确保生成结果与线上系统兼容（System Alignment）
- 部署架构不增加用户感知延迟（Zero Latency）

WeWrite 在这三个维度上都给出了可落地的解决方案，是 LLM 赋能搜索系统的一个优秀工程实践范例。

Sources:

• WeWrite Paper (arXiv)
• WeWrite Full HTML Version