当前位置：首页 > news >正文

【第五章:计算机视觉-项目实战之推荐/广告系统】2.粗排算法-(3)理解粗排模型之在线部分：在线架构及对双塔的应用

news 2025/10/28 9:02:54

第五章：计算机视觉-项目实战之推荐/广告系统

第二部分：粗排算法

第三节：理解粗排模型之在线部分：在线架构及对双塔的应用

一、粗排模型从“训练”走向“线上”的最大挑战是什么？

上一节我们完成了粗排双塔的离线训练部分（Embedding 学习 + Faiss/HNSW 索引）。
但模型训练完，并不等于能上线。真正落地粗排系统，需要解决 3 类工业问题：

上线挑战	解释
低延迟	单次召回必须 ≤ 10ms，否则精排无法接住
实时性	用户向量要实时更新，“人变→召回变”
可扩展性	Item 数量从百万→亿级，索引要可水平扩展

因此粗排的在线架构必须：

User 实时生成 → ANN 向量检索 → TopK 粗排结果 → 精排 → 重排 → 策略 → 展示
这就是工业界典型推荐系统 TPS/QPS 路径。

二、线上粗排整体架构（工程视角）

在线粗排架构可以用一张图说明：

 ┌──────────────┐     ┌──────────────┐     ┌──────────────┐│ User Feature │ --> │ User Tower   │ --> │ User Vector  │└──────────────┘     └──────────────┘     └───────┬──────┘│▼┌────────────────────┐│   ANN Vector DB    ││ (Faiss / Milvus)   │└───────┬────────────┘│  TopK▼┌────────────────────┐│  Candidate Items   │└────────────────────┘│▼【下游精排模型】

说明：

模块	在线职责
User Tower（在线模型服务）	实时生成用户向量（10ms 内）
Item Tower（离线产出）	不在线推理，仅保存向量
ANN 检索服务	TopK 召回，如 `Faiss / Milvus / HNSW / Vespa`

粗排本质是将在线流量变向量 → 用向量当钥匙 → 在向量库中开锁找 TopK内容。

三、双塔在在线系统中的运行机制

角色	运行方式	调用频率
Item Tower（离线）	离线 Embedding + 索引构建	物料变化才更新
User Tower（在线）	实时推理生成用户向量	每次推荐调用一次

因此：

在线只跑半个模型（User Tower） → 延迟低
ANN 召回只查向量库 → QPS 极高（百万级）
物料多也能扩，因为塔解耦

这就是双塔在线表现优于精排 DNN、DIN、BERT 的核心原因。

四、在线流程用伪代码还原

def online_recall(user_feature):# 1) 用户特征输入 → User Tower 得到在线向量user_vec = user_model.predict(user_feature)   # < 10ms# 2) ANN 检索 TopK 粗排候选scores, item_ids = ann_index.search(user_vec, topk=300)  # < 5~10ms# 3) 返回粗排结果 → 进入精排return item_ids

粗排必须 < 20ms 完成全部动作，否则上线毫无意义。

五、ANN 选型与使用建议（踩坑经验）

方案	适用场景	QPS	特点
Faiss (CPU/GPU)	千万级向量以内	极高	单机强，不适合集群
Milvus	分布式召回	高	企业级最佳选择
HNSW	内存够、要求低延迟	极高	搜索质量最好
Faiss + HNSW 混合	多路召回	——	最常见工业配置

经验结论：

粗排要的是 TopK 足够准 + 延迟足够低，而不是精排级别的匹配准确率。

六、线上版本更新策略：如何优雅平滑不倒服务

更新任务	策略
User Tower 更新	A/B Test + 双模型切换
Item Embedding 更新	Shadow Index + 双索引切换
ANN Index 更新	异步重建 + 热切换

要点：

不允许全量下线重建
不允许用户线上向量与物料空间不一致
必须保证所有请求可回溯

粗排系统本质上是 “强工程系统 + 弱模型复杂度” 的架构部分。

七、本节总结

你已理解	状态
双塔在线为什么延迟低	✅
粗排在线架构职责与数据流	✅
User/Item 两塔如何解耦	✅
ANN 如何服务粗排召回	✅
完整工程化上线方案	✅

一句话总结：