小红书搜索优化：多任务学习模型QP-OneModel实践

1. 项目背景与核心价值

在小红书这类内容社区平台中，搜索功能的质量直接影响用户体验和平台活跃度。传统搜索系统通常采用多模型串联的架构——先用一个模型理解查询意图，再用另一个模型处理改写，最后交给排序模型。这种方案存在两个明显痛点：

第一是响应延迟叠加。每个模型调用都会增加几十到几百毫秒的延迟，当多个模型串联时，整体延迟可能突破用户可忍受的阈值。我们实测发现，当搜索响应超过800ms时，用户跳出率会显著上升。

第二是信息传递损耗。前序模型的输出作为后续模型的输入时，不可避免会丢失部分原始query的语义信息。比如在"适合油皮的平价粉底液"这个query中，经过意图识别模型处理后，"平价"这个关键属性在后续改写阶段可能被弱化。

QP-OneModel正是为了解决这些问题而生。通过统一的多任务学习框架，我们让单个模型同时完成查询意图识别、语义改写、敏感词识别等核心任务。实测显示，端到端延迟降低57%，而在"美妆"、"穿搭"等垂类场景下的搜索准确率提升12.8%。

2. 模型架构设计解析

2.1 基础骨干网络选型

我们对比了T5、BART和LLaMA三种架构作为backbone的优劣：

• T5的encoder-decoder结构天然适合生成任务，但在分类任务上需要额外设计输出头
• BART的噪声恢复预训练目标与查询改写任务高度契合
• LLaMA的纯decoder架构在自回归生成上表现优异，但处理分类任务时需要特殊设计

最终选择BART-large作为基础架构，主要考虑三点：

1. 小红书搜索query平均长度在15-20字，BART处理短文本的效率优于T5
2. 改写任务需要保持原始语义，BART的文本重建能力更强
3. 通过添加多任务适配层，可以较好平衡生成与分类任务

2.2 多任务学习设计

模型需要同时处理三类任务：

1. 意图分类（7类：商品搜索、攻略查询、问答等）
2. 查询改写（生成标准搜索query）
3. 敏感词识别（二分类）

我们采用共享底层+任务特定头的设计：

• 前12层Transformer共享参数
• 最后3层分支出三个任务头：
  • 分类头：线性层+softmax
  • 生成头：标准自回归生成
  • 敏感词检测头：带注意力池化的MLP

损失函数采用加权求和： L_total = 0.4L_gen + 0.3L_intent + 0.3*L_safety

2.3 小红书场景适配技巧

针对社区内容特点，我们做了三项关键优化：

1. 表情符号处理：

   • 将emoji转换为[EMOJI_xxx]特殊token
   • 在生成任务中保留原始emoji分布
   • 例如"这个妆绝了[EMOJI_1f60d]"会被正确处理

2. 网络用语理解：

   • 在词典中添加"绝绝子"、"yyds"等社区高频词
   • 通过对比学习让模型理解这些词的语义

3. 多模态query处理：

   • 对"类似这张图片的裙子"类query
   • 用CLIP编码图像特征作为附加输入

3. 训练与优化细节

3.1 数据准备策略

构建了三个核心数据集：

1. 意图分类数据：

   • 人工标注20万条历史query
   • 通过聚类采样确保类别平衡
   • 添加对抗样本增强鲁棒性

2. 改写数据：

   • 基于用户点击日志构建pair
   • 原始query → 高CTR的标题
   • 清洗后获得150万高质量样本

3. 敏感词数据：

   • 平台审核日志中的违规query
   • 人工筛选出5万条正样本
   • 负样本来自正常搜索query

3.2 训练技巧实录

1. 渐进式训练：

   • 第一阶段：仅训练生成任务
   • 第二阶段：冻结底层，训练分类头
   • 第三阶段：联合微调所有参数

2. 动态温度采样： 在生成任务中采用变化温度： T = max(0.7, 1.2 - epoch*0.05) 早期鼓励探索，后期稳定输出

3. 对抗训练： 在embedding层添加FGM扰动： Δ = ε * g / ||g||₂ g为梯度，ε=0.3

3.3 关键参数配置

batch_size: 64 max_seq_len: 64 learning_rate: 3e-5 warmup_steps: 5000 gradient_accumulation: 2 label_smoothing: 0.1

4. 线上部署与性能优化

4.1 服务化架构

采用Triton推理服务器实现：

• 每个GPU卡加载1个模型实例
• 动态批处理(max_batch_size=32)
• 支持FP16量化

关键优化点：

1. 请求队列优先处理高优query
2. 对长尾query启动后备模型
3. 实现基于LRU的模型热更新

4.2 性能压测数据

在NVIDIA T4环境下的测试结果：

相比原有串联模型方案：

• 吞吐量提升2.1倍
• 99分位延迟降低57%

4.3 内存优化技巧

1. 注意力缓存共享： 不同任务共享KV cache
2. 激活值压缩： 对中间激活使用8bit量化
3. 动态卸载： 长时间无请求时释放部分权重

5. 效果评估与案例分析

5.1 离线评估指标

在测试集上的表现：

虽然单项指标略有下降，但端到端效果更好，说明多任务学习带来了协同效应。

5.2 典型case分析

1. 成功案例： 原始query："小个子怎么穿显高" 改写结果："150cm矮个子显高穿搭技巧" 意图识别：穿搭建议 敏感词：无

2. 改进案例： 原始query："怎么判断护肤品真假" 旧系统：识别为"购物咨询" 新系统：识别为"真假鉴别"并触发防伪攻略

3. 失败案例： 原始query："jk裙子" 错误改写："日本学生制服" 原因：对亚文化术语理解不足

5.3 A/B测试结果

在1%流量桶中观察7天：

6. 常见问题与解决方案

6.1 多任务冲突处理

现象：当提高生成任务权重时，分类准确率下降 解决方案：

1. 采用GradNorm进行梯度标准化
2. 添加任务不确定性权重
3. 在损失函数中加入相关性惩罚项

6.2 长尾query处理

对于低频query（如"汉服形制"）：

1. 构建领域专属词典
2. 在finetune时过采样垂类样本
3. 实现基于检索的增强生成

6.3 模型更新策略

采用双阶段更新：

1. 每周一更新意图分类模块 （用户搜索习惯变化较慢）
2. 每天更新敏感词库 （新风险词出现频率高）

7. 工程实践心得

1. 数据质量比数据量更重要

   • 清洗20%的低质量样本后，效果提升比增加50%数据更明显

2. 延迟优化要端到端考虑

   • 单模型优化到100ms后，发现网关序列化成了新瓶颈

3. 监控体系要立体化

   • 不仅监控模型指标，还要跟踪业务指标变化
   • 建立query质量分级报警机制

4. 模型解释性很重要

   • 用LIME方法生成解释报告
   • 帮助运营理解模型决策过程