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

推荐系统（十八）双塔模型实战：从DSSM到工业级向量召回的样本工程与部署优化

news 2026/6/11 21:22:00

1. 双塔模型的前世今生：从DSSM到工业级向量召回

第一次接触DSSM双塔模型是在2015年，当时还在为推荐系统的冷启动问题头疼。直到看到微软那篇经典论文，才发现原来语义匹配可以这样做。DSSM（Deep Structured Semantic Models）最初是为搜索引擎设计的，用来解决查询和文档的语义匹配问题。但很快，推荐系统工程师们就发现了它的妙用——这不就是完美的召回模型架构吗？

双塔结构的精妙之处在于它的对称性。左边是用户特征塔，右边是物品特征塔，两个塔就像镜像 twins 一样相互呼应。我特别喜欢用"相亲"来比喻这个过程：用户塔负责把用户的各种条件（年龄、兴趣、历史行为）打包成一份"征婚简历"，物品塔则把商品特征（类别、价格、标签）整理成"相亲资料"，最后通过向量内积计算"匹配度"。

在实际项目中，我发现双塔模型有三大优势特别适合工业场景：

特征隔离：用户和物品特征完全分离，这在分布式计算环境下简直是福音
线上高效：物品embedding可以预计算，线上只需要实时计算用户embedding
灵活扩展：可以轻松支持亿级物品库的ANN检索

不过早期版本有个坑我踩过——两个塔的维度必须严格一致。有次为了提升效果，我把用户塔最后一层改成512维，物品塔保持256维，结果相似度计算直接报错。这个教训让我明白：双塔模型就像情侣装，可以款式不同，但尺码必须匹配。

2. 样本工程的秘密：如何打造高质量训练数据

说到样本构造，真是血泪史一箩筐。记得第一次做双塔模型时，直接用了曝光未点击数据作为负样本，上线后效果惨不忍睹。后来才明白这是典型的样本选择偏差（SSB）问题——你的训练数据只包含曝光过的物品，但线上要从全量库召回。

经过多次实验，我总结出几种实用的负样本构造方法：

2.1 全局随机采样

就像在超市随机拿商品给顾客看，简单粗暴但效率低。优点是符合真实分布，缺点是负样本太"简单"，模型学不到区分细微差异的能力。建议可以这样实现：

def global_negative_sampling(items, n_neg=4): """从全量物品库随机采样负样本""" return random.sample(items, n_neg)

2.2 Batch内负采样

这个方法很巧妙，利用同一batch内其他用户的点击作为当前用户的负样本。在TensorFlow中只需要几行代码：

# 假设batch_size=1024, embedding_dim=256 user_emb = ... # shape=(1024,256) item_emb = ... # shape=(1024,256) # 计算所有用户与所有物品的相似度矩阵 logits = tf.matmul(user_emb, item_emb, transpose_b=True) # shape=(1024,1024)

2.3 流行度加权采样

热门物品被展示的机会多，如果用户没点击，就更可能是真负样本。我们可以这样实现流行度采样：

def popularity_sampling(items, pop_counts, n_neg=4): """根据物品流行度进行加权采样""" probs = np.array(pop_counts) / sum(pop_counts) return np.random.choice(items, size=n_neg, p=probs, replace=False)

在实际项目中，我建议采用混合采样策略。比如50%全局随机+30%batch内采样+20%流行度采样，这个比例需要根据具体场景调整。有个经验公式：物品库越大，全局随机的比例应该越高。

3. 工业级部署的五个关键点

第一次部署双塔模型到生产环境时，QPS直接飙红报警。经过多次优化，我总结了五个必须注意的关键点：

3.1 物品向量预计算

这是双塔模型的杀手锏。我们搭建了专门的向量计算服务，架构是这样的：

物品特征实时写入Kafka
Flink消费特征并触发向量计算
计算结果写入Redis和FAISS索引

# 物品特征更新处理示例 def process_item_update(item_features): # 实时计算物品embedding item_emb = item_tower.predict(item_features) # 更新向量数据库 faiss_index.add(item_emb) # 同时更新缓存 redis_client.set(f"item_emb:{item_id}", pickle.dumps(item_emb))

3.2 ANN检索优化

FAISS确实强大，但参数配置有讲究。对于亿级物品库，我的经验是：

先用PCA降维到128维
使用HNSW32索引
nprobe参数设置在32-128之间

实测下来，这种配置能在召回率和延迟之间取得很好平衡。记得有一次把nprobe从64调到128，虽然Recall@100提升了2%，但延迟增加了30ms，最终不得不调回去。

3.3 用户向量实时计算

用户特征往往包含实时行为，必须在线计算。这里有个优化技巧：把用户特征分为静态和动态两部分。静态特征（如性别、年龄）可以预计算，动态特征（最近点击）才需要实时计算。

3.4 缓存策略

我们设计了三级缓存：

热门物品向量缓存在本地内存
近期用户查询结果缓存在Redis
长期用户画像缓存在HBase

3.5 监控体系

部署了四个关键监控指标：

向量计算延迟百分位
ANN检索召回率
缓存命中率
线上AB测试效果对比

4. 效果提升的进阶技巧

4.1 特征工程的特殊处理

双塔模型不能做特征交叉？其实有变通方法。比如用户历史点击品类和当前物品品类的交叉，可以这样处理：

# 用户侧特征：加入历史点击品类的embedding user_hist_cates = get_hist_cates(user_id) cate_embs = [cate_embedding[cate] for cate in user_hist_cates] user_feature['hist_cate_emb'] = np.mean(cate_embs, axis=0) # 物品侧特征：加入品类embedding item_feature['cate_emb'] = cate_embedding[item_cate]

这样虽然没有显式交叉，但模型可以通过向量距离隐式学习到关联。