小红书搜索优化：生成式查询理解模型QP-OneModel实践

1. 项目背景与核心价值

在小红书这类内容社区平台，搜索功能的质量直接影响用户体验和平台活跃度。传统搜索系统通常采用"召回+排序"的流水线架构，其中查询理解（Query Understanding）作为第一环，其准确性直接决定后续环节的效果上限。过去行业普遍采用多模型串联的方案——先做意图识别，再做实体抽取，最后进行查询改写，这种方案存在误差累积、计算冗余的问题。

QP-OneModel的突破性在于将查询理解的多个子任务统一到一个生成式框架中。我们团队通过分析小红书平台的海量搜索日志发现：超过62%的搜索查询存在模糊性（比如"春日穿搭"可能指搭配技巧、单品推荐或场景搭配），传统分阶段处理的模型难以捕捉这种复杂语义关联。而统一生成模型能够通过端到端学习，直接输出结构化的查询理解结果，在保证效果的同时大幅降低工程复杂度。

2. 技术架构解析

2.1 模型整体设计

采用encoder-decoder架构，核心创新点在于：

• 多任务统一编码：将意图分类、实体识别、查询扩展等任务统一建模为文本生成任务
• 动态模板机制：设计结构化输出模板，例如"[意图]穿搭推荐[实体]春日[扩展]韩系"，通过特殊分隔符区分不同任务输出
• 课程学习策略：训练时先易后难，初期单独训练各任务head，后期联合优化

实际部署时，单个生成请求的推理耗时控制在15ms以内，相比原有串联模型降低40%延迟

2.2 关键技术创新点

2.2.1 语义空间对齐

通过对比学习构建跨任务共享的表示空间，解决传统方法中：

• 意图识别模块与实体抽取模块特征空间不一致
• 长尾查询的稀疏表征问题 具体实现采用Triplet Loss，锚点样本（原始查询）、正样本（同意图不同表述）、负样本（不同意图相似表述）

2.2.2 增量式生成控制

设计分层约束机制：

1. 首token必须为预定义意图类别（共38类）
2. 实体部分采用CRF约束保证结构合法性
3. 扩展词需通过检索增强模块验证相关性

2.2.3 在线学习系统

构建双缓冲更新机制：

• 实时收集bad case（通过人工标注+自动检测）
• 每日凌晨增量训练（保留90%原参数）
• A/B测试流量逐步放量

3. 工程落地实践

3.1 模型训练细节

• 数据构造：人工标注5w+查询，通过回译增强至200w样本
• 基座模型：基于mT5-large微调，相比原生T5在中文混合query上准确率提升7.2%
• 关键参数：

  learning_rate = 3e-5 (带线性warmup) batch_size = 128 max_seq_len = 64 (输入)/128 (输出)

3.2 线上部署方案

采用Triton推理服务器+动态批处理，关键配置：

• 使用TensorRT优化计算图
• 设置最大批处理大小32
• 开启FP16加速

性能指标对比：

4. 效果验证与案例分析

4.1 离线评估

在自建测试集上（含2w查询）：

• 意图识别准确率：92.4% → 94.7%
• 实体抽取F1：85.1 → 88.3
• 扩展词相关性：76% → 83%

4.2 典型case解析

查询："适合梨形身材的牛仔裤"

• 旧系统输出：
  • 意图：商品搜索
  • 实体：牛仔裤
  • 扩展：无
• QP-OneModel输出：
  • 意图：商品搜索+搭配建议
  • 实体：牛仔裤[梨形身材]
  • 扩展：高腰 直筒 深色

bad case分析： 查询"怎么拍出ins风照片"被错误识别为"摄影器材购买"，主要原因是训练数据中"ins风"关联的购买意图样本过多。通过添加负样本和调整loss权重解决。

5. 优化方向与实用建议

5.1 持续迭代重点

• 构建更细粒度的意图分类体系（当前38类→计划扩展至100+）
• 引入视觉信息辅助理解（如结合搜索结果的图片特征）
• 探索用户个性化建模（历史行为融入生成过程）

5.2 落地经验分享

1. 数据质量比模型结构更重要，建议：

   • 至少保证5k高质量人工标注样本
   • 对高频query进行case-by-case分析
   • 建立持续的数据清洗pipeline

2. 上线初期建议：

   • 保留旧系统作为fallback
   • 设置严格的异常检测（如生成内容包含敏感词）
   • 对长尾query设置人工审核通道

3. 效果调优技巧：

   • 对高价值query（如电商类）可适当增加loss权重
   • 实体识别部分加入词典约束
   • 定期分析bad case中的pattern