快手GREAT框架：视频搜索查询推荐的创新实践

1. 项目概述

在当今短视频平台蓬勃发展的背景下，用户观看视频时常常会产生搜索相关信息的冲动。然而，传统搜索流程存在两个主要痛点：一是用户需要手动输入查询词，增加了操作成本；二是用户自发的查询可能不够准确，无法精准表达搜索意图。针对这一问题，快手团队提出了视频相关搜索中的查询推荐任务（Item-to-Query，I2Q），即在视频播放界面底部推荐与当前视频内容相关的搜索词，用户可以直接点击进入搜索结果页。

这个看似简单的功能背后蕴含着巨大的技术挑战。不同于传统推荐系统仅关注点击率等单一指标，I2Q推荐需要同时兼顾四个维度的目标：效果（用户消费指标）、搜索结果页消费（引流后的二次转化）、相关性（查询与视频内容的匹配度）以及文本质量（查询本身的规范性）。现有的检索式方法虽然能保证查询质量，但由于缺乏视频与查询间的深度交互，效果存在瓶颈；而新兴的生成式方法虽然相关性较好，却常常产生错别字、谣言等低质量内容。

2. 技术方案解析

2.1 GREAT框架整体设计

GREAT（Guiding Query Generation with a Trie）框架的创新之处在于巧妙结合了检索式和生成式方法的优势。其核心思想是：利用高质量查询构建的trie树作为"导航仪"，引导大语言模型在正确轨道上生成查询。这种方法既保留了生成式方法的语义理解能力，又通过trie树的约束确保了查询质量。

框架包含五个关键模块：

1. Prompt构造模块：将视频内容（标题和OCR识别的封面文字）转化为LLM可理解的输入格式
2. 基于查询的trie树：从历史高曝光高点击查询中构建的字典树
3. NTTP训练任务：让模型学习在trie树范围内预测下一个token
4. 基于Trie的解码：推理时限制生成路径必须在trie树中存在
5. Logits过滤器：基于概率分布的后处理模块，进一步确保质量

2.2 核心技术创新点

2.2.1 查询trie树的构建与维护

trie树的构建质量直接决定了GREAT的效果上限。我们的实践表明，一个优秀的trie树应该具备以下特征：

• 全面性：覆盖平台主流搜索场景和热点话题
• 高质量：经过严格的内容审核，去除低质查询
• 时效性：每日更新以反映用户兴趣变化

具体构建流程包括：

1. 数据采集：收集过去15天内曝光量>1000且点击量>10的查询
2. 质量过滤：人工审核团队去除含错别字、敏感内容、谣言的查询
3. 分词处理：使用与LLM相同的tokenizer将查询转换为token序列
4. 树形构建：将token序列按前缀组织成树形结构

实践发现，维护一个规模在200-300万查询量的trie树能在效果和性能间取得较好平衡。过大的trie树会增加内存压力，而过小则可能限制生成多样性。

2.2.2 NTTP训练任务设计

传统的语言模型训练只关注下一个token预测（NTP），而GREAT创新性地引入了Trie中下一个Token预测（NTTP）作为辅助任务。这个设计的精妙之处在于：

1. 它让模型不仅学习通用的语言规律，还专门强化了对高质量查询模式的记忆
2. 通过α系数（实验表明0.1左右最佳）平衡通用能力和领域特异性
3. 在损失函数层面确保模型输出与业务期望的查询分布对齐

从技术实现看，NTTP任务的损失计算只考虑trie树中实际存在的路径分支，这相当于为模型学习增加了一个"注意力遮罩"，使其更聚焦于有效查询空间。

2.2.3 两阶段推理优化

GREAT的推理过程采用了双重质量保障机制：

基于Trie的解码阶段

• 将候选token集合限制在trie树当前节点的子节点范围内
• 有效避免生成不存在的词汇组合
• 通过束搜索（beam size=5）保持一定的生成多样性

Logits过滤阶段

• 全局过滤器：确保整个查询的平均生成概率高于阈值（θ_G=0.2）
• 局部过滤器：要求每个token的生成概率都高于下限（θ_L=0.05）
• 两者配合可以剔除低置信度的生成结果

这种设计类似于"宽进严出"的筛选策略：首先生成相对多样的候选，然后通过严格的标准筛选最优结果。

3. 实现细节与优化

3.1 模型选型与训练

考虑到工业场景的实时性要求，我们选择了Qwen 2.5 1.5B作为基础模型。这个规模的模型在效果和推理延迟之间取得了良好平衡。训练过程中的关键参数配置如下：

训练中的几个实用技巧：

1. 梯度裁剪（max norm=1.0）防止梯度爆炸
2. 混合精度训练（AMP）节省显存
3. 数据并行+梯度累积提高吞吐量

3.2 线上服务优化

为了将GREAT部署到快手的生产环境，我们进行了多项工程优化：

性能优化

• 使用Triton推理服务器实现模型并行
• 对trie树采用前缀缓存，减少内存访问
• 批量处理请求（batch size=32）提高GPU利用率

稳定性保障

• 请求超时设置（200ms）避免雪崩
• 降级策略：当GREAT超时时自动回退到检索式方法
• 实时监控生成质量，触发异常自动报警

效果迭代

• 建立A/B测试平台快速验证新策略
• 构建自动化评估流水线，每小时统计关键指标
• 支持模型热更新，无需重启服务

4. 实验分析与洞察

4.1 离线实验结果

我们在KuaiRS数据集上对比了GREAT与多种基线方法。为了公平评估生成式方法，特别设计了Edit@k指标，它衡量生成查询与真实查询的编辑距离。实验结果揭示了一些有趣现象：

1. 生成式方法整体优于检索式方法，特别是在长尾视频上优势更明显
2. GREAT相比纯生成式方法（微调Qwen）在Edit@k上提升15.6%
3. 模型规模并非越大越好，1.5B参数的GREAT优于3B参数的BGE模型

4.2 在线A/B测试

为期5天的线上实验获得了令人振奋的结果：

更值得关注的是，这些提升是在不增加资源消耗的情况下实现的，体现了算法创新的价值。

4.3 失败案例分析

在项目推进过程中，我们也积累了一些宝贵教训：

1. 初始trie树更新频率不足：早期采用每周更新，导致无法及时捕捉热点变化。改为每日更新后，时效性指标提升22%。
2. 忽略tokenizer差异：曾尝试使用其他LLM的trie树，由于tokenizer不一致导致效果下降。必须确保trie树与生成模型使用相同的tokenizer。
3. 过滤阈值设置不当：初期θ_G设置过高（0.3），导致生成多样性不足。通过网格搜索找到0.2是最佳平衡点。

5. 应用场景扩展

GREAT的方法论不仅适用于视频搜索推荐，还可以迁移到其他内容理解场景：

1. 电商标题生成：基于商品详情生成吸引人的标题
2. 新闻摘要推荐：根据新闻正文推荐相关阅读
3. 广告创意生成：结合产品信息产出高质量广告文案

关键是要根据具体场景调整trie树的构建策略和prompt设计。例如在电商场景中，trie树应该包含高频搜索词和商品属性词，prompt则需要强调卖点提取。

6. 未来优化方向

基于当前成果，我们规划了以下几个演进方向：

1. 多模态扩展：结合视频内容分析（而不仅是OCR文字）来增强理解
2. 个性化推荐：引入用户画像，生成更符合个人偏好的查询
3. 交互式生成：支持多轮对话式的查询优化过程
4. 低资源适配：探索参数高效微调方法，降低计算成本

特别在个性化方面，我们观察到不同用户群体对同一视频的搜索意图差异很大。例如美食视频，年轻用户更关注"做法教程"，而家庭用户更关心"营养搭配"。如何在不增加太多计算开销的前提下实现个性化生成，是一个值得深入探索的方向。