双塔召回模型最近几年在推荐、搜索、广告这些场景里几乎成了标配方案。不管是刚入门做推荐系统的工程师还是已经在业务里摸爬滚打几年的同学应该都绕不开这个名字。简单说双塔召回就是把用户和物品分别编码成两个向量然后在向量空间里做最近邻检索从百万甚至亿级的候选池里快速捞出几百上千个最可能相关的物品。这篇文章我就结合自己做推荐召回这几年踩过的坑、调过的参、重构过的模型把这个模型从原理到落地再到排查问题完整拆一遍。1. 双塔召回模型的核心思想与设计动机1.1 召回问题到底在解决什么先说清楚召回在整个推荐链路里的位置。一个完整的推荐系统大致是召回、粗排、精排、重排这几层。召回阶段面对的是全量物品池少则几十万多则上亿精排模型再强也不可能把全量物品都过一遍所以召回必须在十几毫秒甚至几毫秒内从超大候选池里筛出一个几百到几千的候选集合交给下游排序。召回这个东西本质上是检索问题不是排序问题。排序讲究的是对每个物品都算一个精准的分数而召回讲究的是快、准、狠——快是指延迟要低准是指真正相关的物品不能漏掉狠是指哪怕牺牲一点精度也要保证覆盖率。早期业界常用的召回方式有协同过滤、向量召回、规则召回、热榜召回等双塔召回属于向量召回这一支里最经典、最稳定的实现方式。双塔模型做的事情翻译成人话就是给每个用户算一个 embedding 向量给每个物品也算一个 embedding 向量然后用内积或者余弦相似度去衡量用户和物品之间的相关性。训练的时候用户塔和物品塔各自学各自的表示推理的时候预先算好所有物品的 embedding存在向量索引里来一个用户实时算他的 embedding然后走 ANN近似最近邻检索就能在毫秒级把最相关的物品捞出来。1.2 为什么双塔结构是工业界的主流选择双塔能成为主流核心原因就一条训练和推理的解耦。左边用户塔右边物品塔两个塔在结构上完全独立只在 loss 层汇合。这个结构天然适配工业界的部署方式——物品侧是静态的、海量的可以离线算好向量存进索引用户侧是动态的、请求驱动的可以在线实时算向量然后去查索引。如果换成传统的拼接式模型用户特征和物品特征在最后一层全连接层才融合那线上推理时必须把候选物品的特征一个个喂给模型这个计算量在召回阶段是完全扛不住的。我见过团队一开始用的是 FM 或者 DeepFM 做召回实际上就是拿精排模型硬扛召回。结果线上延迟到了 80 毫秒还只能扫 5 万个物品覆盖率远远不够。后来切到双塔用户侧一次前向传播算一个向量物品向量全部预计算整体延迟降到 3 毫秒以内候选池能撑到千万级。这不是说 FM 这类模型不好而是把交互模型用错了地方——交互计算在召回阶段成本太高双塔牺牲了部分特征交叉能力换来了工程上的可行性这个 trade-off 在工业场景里是划算的。1.3 什么场景下适合用双塔什么场景下不适合双塔不是万能的。如果你的候选池只有几千个比如企业内部知识库检索、某个垂类小场景的物品推荐那直接用交互模型比如 DIN、DCN 甚至简单的 FM 都行全量打分很快没必要非得向量化。但一旦候选池到了十万级、百万级以上或者你对响应延迟有严格要求双塔就是性价比最高的方案。另外双塔擅长的是“相关性”而不是“个性化”。用户塔能学到用户的长期兴趣分布但很难表达用户在某一次请求里的即时意图。举个例子用户今天想买一个儿童安全座椅他过去的历史行为全是数码产品这种场景下双塔单塔的向量很可能偏向长期兴趣短期意图的表达能力就弱。这种情况一般靠两个手段弥补一是给用户塔加实时行为序列特征把最近一次点击、最近一次加购放进去做 attention二是双塔和其他策略召回形成多路互补别让单路双塔扛所有召回量。2. 双塔模型的结构设计与特征处理细节2.1 用户塔和物品塔各自该输入哪些特征用户塔的特征来源一般分三类用户基础属性年龄、性别、城市等级、注册时长、用户行为统计近 7 天点击次数、近 30 天购买类目分布、用户行为序列最近点击的 item id 序列、最近收藏的 item id 序列。物品塔的特征来源也分三类物品基础属性物品 id、类目 id、品牌 id、价格档位、物品内容属性标题分词、标签集合、图文向量、物品统计属性近 7 天曝光量、点击率、收藏率、购买转化率。这里有个关键原则用户塔和物品塔的特征可以重叠一部分但千万不要把用户侧的强特征塞进物品塔里或者反过来。比如物品的“近 7 天点击率”作为它自己的统计特征没问题但如果你把“当前请求用户对该物品的点击率”这个特征塞进去这在训练时可以通过特征交叉学得不错但上线推理时这个特征根本拿不到因为你正在做召回用户和物品的交叉信息是未知的。这就是特征穿越里最常见的坑后面我单独讲。2.2 连续特征怎么处理分桶与归一化双塔模型里连续特征的预处理非常影响效果但很多团队的做法特别随意直接 z-score 归一化就丢进去了。我自己的经验是连续特征优先做分桶离散化把连续值映射成离散 id再走 embedding 层。比如物品的价格可以按分位数切成 50 个桶每个桶一个 embedding。这样做的好处有三个第一能表达非线性关系一个原始价格数字要拟合非线性关系MLP 得自己学但分桶相当于预先做了特征变换第二能天然处理缺值缺值单独设一个桶第三在线推理时查 embedding 表比实时算连续特征的前向传播更快更可控。如果特征本身是稠密向量比如图文内容的预训练 embedding、用户主题偏好向量这类特征就不要分桶了直接 concat 拼到 tower 输入里即可。不过要注意这类稠密 embedding 向量最好也做一下归一化防止它们的模长过大把其他特征的梯度带偏。2.3 多值特征与序列特征的聚合方式物品有标签集合比如一部电影有“喜剧”“爱情”“经典”三个标签用户有最近点击序列比如 50 个点击过的 item id。这类多值特征的处理常见做法是把每个值都查成 embedding然后用 sum pooling、mean pooling、attention pooling 聚合成一个向量。很多团队图省事直接用 mean pooling效果也不错但要注意一个问题物品标签的重要性差异很大“喜剧”这个标签对用户的判断权重可能远高于“2023年上映”这个标签mean pooling 把这个信息抹平了。我推荐的做法是加一层简单的 attention为每个特征位学习一个注意力权重这个权重可以是一个没有隐层的单层 MLP输入是特征 embedding 本身输出一个标量。这个结构简单不增加多少参数量但在实际效果里能显著提升表达力尤其是在用户行为序列上。用户点击的 50 个 item用户点击它们时状态差别很大——他三秒前点的和三天前点的意图强度完全不同。用时间衰减加权或者 attention 都能改善这个问题。2.4 MLP 塔的层数与维度怎么定塔的网络结构一般就是几层全连接加激活函数每层逐渐降维。比如输入特征拼接后维度是 500然后走 512 - 256 - 128 - embedding 维度 64每层之间加 ReLU 或 LeakyReLU。embedding 的输出维度常见是 32 到 128 之间。维度太小表达力不足维度太大不仅训练开销大而且 ANN 检索的精度和速度都会下降因为高维向量索引的“维度灾难”很明显。关于层数我踩过一个坑把塔做得太深用了 5 层全连接参数量大了不少但效果反而变差了。原因是双塔模型的训练信号非常稀疏——每个训练样本只是一个用户和一个物品的匹配交叉信息通过 loss 反传塔内部每一层都要在这种稀疏信号下学习过深的网络容易过拟合和梯度不稳定。我的经验是 2~3 层全连接就够用瓶颈在于特征质量的提升而不是模型深度的增加。2.5 用户塔和物品塔要不要共享参数这个问题不同团队有不同答案。如果用户侧特征和物品侧特征的分布差异很大——用户侧是行为序列和画像物品侧是内容属性和统计强行共享参数反而有害。但如果两侧特征都很稀疏、同质性强比如都是 id 类特征共享一部分 embedding 表能显著减少参数还能解决冷启动问题。比如快手早期做视频推荐用户侧有交互过的视频 id物品侧是视频 id两边都指向同一个 embedding 表这样新视频只要出现过就能通过共享 embedding 被用户塔感知。我自己实践下来比较稳妥的做法是id 类 embedding 表按场景决定是否共享非 id 类的塔内参数各自独立。共享不共享要在实验里 A/B 验证不能拍脑袋。共享逻辑在代码里不复杂容易实现值得多试两种方案。3. 训练样本、损失函数与采样策略3.1 正样本怎么构造最合理正样本一般取用户与物品之间有正向反馈的交互对。不同业务对“正向”的定义不同电商场景加购、购买比点击重要得多内容场景完整播放、点赞、关注比曝光高广告场景点击和转化都要。实践经验是训练正样本要有主次之分核心动作样本要给更高的权重次要动作样本也不能完全不要。一个常用的降权方式是给正样本加一个重要性权重。比如购买权重是 1.0加购是 0.5点击是 0.1这个权重要么直接乘到 loss 上在 CE loss 里体现为样本权重要么通过重复采样来凑比例。我见过有团队把点击样本疯狂重复采样导致模型全学成了“点击偏好”而忽略了“购买偏好”方向就偏了。我会在后文讲 batch 内负样本采样时再提到相关细节。3.2 负样本采样的三种经典策略与对比负样本的设计是双塔模型里最影响效果的环节。孪生塔的负样本为每一次正样本配对随机制造一个不与用户互动的物品。太简单的负样本学了没意义全是“用户没点过”的简单样本模型学到的只是用户和所有非交互物品之间的大致差异根本分不清用户是“没兴趣”还是“没看过”这个物品稍繁杂一些的负样本能提供更完整的语义信息因此业界演化出几种策略。随机负采样直接从全量物品里均匀地抽一批作为负样本。实现最简单能保证负样本分布覆盖全量物品池但问题在于随机抽的负样本大多是低频长尾物品用户的注意力基本上都在喂养模型时的头部物品上所以模型对头部物品的判别能力其实很差。经验值随机负样本占比大概七到八成。batch 内负采样拿一个 batch 内其他用户的正样本来充当当前用户负样本。一个 batch 里用户 A 的正样本是物品 X用户 B 的正样本是物品 Y那么用户 A 的训练中物品 Y 就成了负样本。这个策略实现简单训练快而且最关键的是这些负样本恰好都是实体物品不会像随机采样那样给了用户完全没见过的物品。隐患在于热门物品更容易成为别人的负样本误伤率偏高——热门物品被降权严重长期后尾部物品更容易被推向头部物品的排名位置因此要加修正。hard negative 采样字面意思是给用户看和他有部分相似但绝对不匹配的物品。比如用户喜欢篮球鞋把跑步鞋当负样本特别能锻炼模型的判别边界。先训练一个简单版本的双塔再用它给每个正样本配几个难负样本难度大了模型学出来的向量会更「紧凑」——相似物品近、不相似的远。hard negative 比例一般为 5%~20%太多模型会更难收敛训练不稳定。混合采样的通用做法以 80% 随机负采样 10% batch 内负样本 10% 难负样本为基础再根据业务场景不断调比例。有些场景里难负样本提升明显有些则不然这点需要用实验来定比例。3.3 Loss 函数与 temperature为什么不是简单的内积sigmoid双塔模型里最常用的 loss 是 CE loss也可以叫 InfoNCE loss。给定一个 batch 的样本batch 内用户 i 的正样本是物品 i其他物品都是负样本对用户 i 的 loss 就是 softmax 输出的交叉熵。L_i -log( exp(sim(u_i, v_i)/τ) / Σ_j exp(sim(u_i, v_j)/τ) )sim 常用内积或余弦相似度temperature 是缩放系数。很多同学刚上手时 temperature 直接设成 1效果会非常差。原因在于内积的取值范围可以很大尤其没有归一化时可能到几百直接进 softmax 会让梯度几乎消失模型很难学到东西。temperature 的作用就是控制相似度分布的“尖锐度”temperature 越小越能拉大正负样本的差距让模型更用力地学习最难区分的样本。一般经验值在 0.05~0.2 之间具体可以先设 0.1再根据 loss 收敛情况和评测指标微调。这里还要注意用了 temperature 之后训练时的 AUC 曲线会虚高不代表线上真实效果就好。我见过一个团队调 temperature 从 0.1 调到 0.01离线 recall 涨了 8 个点线上 AB 反而跌了 3 个点。原因是模型过度专注于难负样本之间的区分把简易正样本的质量拉低了。3.4 归一化要不要把 embedding 归一化成单位向量关于用户塔和物品塔输出的 embedding 是否要做 L2 归一化业界的做法不完全统一。归一化之后内积就等于余弦相似度数值范围固定在 [-1, 1]训练稳定且便于 ANN 检索时使用余弦距离的索引。不归一化内积可以表达“模长”和“方向”两重信息这在有些场景下是有意义的——比如高消费用户的 embedding 模长偏大能反映用户行为的强度。我的建议是首选归一化理由有两点。第一召回阶段更关注方向而非模长一个用户的强烈兴趣应该体现在方向一致性上第二归一化后向量分布更均匀做向量索引时量化误差更小检索精度更高。如果业务上确实需要模长信息可以把模长拆成一个单独的标量特征加在精排阶段使用召回阶段仍然归一化。4. 线上推理与向量检索的工程落地4.1 物品 embedding 的产出与更新机制双塔模型在线上推理时大概可以拆成两个环节物品向量的预计算和动态产出以及用户向量的实时推理。物品向量的更新是个需要精心设计的事。至少四小时一次的离线全量增量任务跑一个全量索引更新太频繁的话全量任务的资源消耗又太大。增量部分的任务可以补偿一部分指标只算新物品、被修改的物品、以及最近一周内有点击行为的物品把这些物品的向量增量更新到索引里。流式通道通常时延控制在分钟级适用于用户上传内容等实时性要求极高的场景。调这套系统时要格外关注的一点是将物品的向量更新频率与用户和物品特征的更新频率对齐。举例来说假如你给物品统计“近 7 天点击率”这个特征而这个特征每 4 小时更新一次但是你的流式通道按分钟更新物品 embed那用户拿到的新向量并不包含最新的点击率变化产生严重的线上线下不一致。4.2 向量索引选型flat 与 ANN 怎么权衡向量检索是双塔工程落地的第二个核心决策。小规模场景比如十万级物品暴力扫描全量向量是完全可行的这个量级可以毫秒级跑完所有向量。百万级往上必须引入 ANN 索引常见的有 IVF、PQ、HNSW具体的选型建议flat暴力扫描虽然精确但只适合候选集五万以下的小场景上线后再换索引是件很麻烦的事。IVF倒排分桶空间开销小先聚类再查桶可以搭配 PCA 降维缺点是召回率不够稳定对簇界附近的样本易丢失。HNSW 是基于图的算法是目前综合表现最好的选择召回率高、查询延迟低适合绝大多数场景。如果内存紧张可再考虑加上 PQ 量化。实际业务中我最终的典型搭配是 HNSWefSearch 调至 128 或 256离线召回率大概能保持在 95% 以上内存占用也还在可控范围。4.3 embedding 与检索的 Score 一致性陷阱这里有一个特别隐蔽的工程坑训练时模型的相似度是内积但线上做 ANN 检索时用的距离度量可能是欧氏距离或余弦距离如果这三个东西不一致线上分数分布和离线完全不同。解决的方法很粗暴但有效在训练的最后一步强制用户塔和物品塔的输出层都过 L2 归一化让内积等效于余弦相似度线上检索一致地采用余弦距离。如果你的某个场景坚持不归一化而用内积那 ANN 索引就得用 IP 内积索引类型别混着用。我见过一次线上事故训练用内积检索用 L2 距离结果线上推荐质量崩得没法看把这个对齐后就好多了。4.4 多路召回结果怎么融合实际系统中双塔往往不是唯一的一路召回。还会有热榜召回、规则召回、同路人召回等。多路召回结果融合时有一个细节值得注意不同路的分数不在一个量纲上直接排序或加权是会出问题的。比较成熟的做法是先用并集去重再把所有路的结果当作特征送进粗排模型里让粗排模型决定谁能进入精排。粗排可以理解为特征交叉能力弱一些的精排模型输入是所有路召回来的物品由它对这些物品打分排序取头部几百个进精排。这里要注意粗排能获取的交叉特征虽然有限它收到的向量特征是最有价值的信号之一所以不要把召回路产生的特征给丢了。5. 常见问题与实战排查5.1 特征穿越线下刷分线上扑街的头号杀手特征穿越是召回模型里最常踩的坑之一。出自“当前用户对当前物品的行为统计”这类特征。比如你在训练时使用“该用户是否在最近一次曝光中点击过该视频”作为物品统计特征训练时模型当然能把这个特征学得很好但召回线上这个特征根本拿不到——你说你不知道用户会不会点这个视频因为这个预测本来就是正在做的事模型学到的是穿越特征里的信息等于作弊。上线后这类特征全部缺失指标自然跳水。排查特征穿越有个简单手段把模型特征做一次“可获取性审计”逐个检查每个特征在召回推理时是否有真实值可取。凡是依赖交叉信息的、依赖未来信息的、依赖线上没有实时更新的信息的都算穿越特征。另外我个人的习惯是上线新特征前跑一个只含旧特征的影子模型做对比如果加了新特征离线指标突飞猛进那多半有穿越问题。5.2 训练与 Servcing 不一致除了特征穿越双塔常见的问题还有模型定义与线上打分路径不一致。训练时你用的是内积加 temperature但线上召回时直接用余弦相似度排中间多了一层转换线下数据又看不出任何毛病或者你训练时用了采样修正但线上的物品向量没做对应修正热门和冷门物品的分数被扭曲。这个问题的排查思路是制定一份“模型-特征-服务”一致性清单每一项线上都要做到离线完全一致。具体到代码上可以把线上打分用的逻辑抽成一个共享函数训练和推理共用避免两套代码漂移。5.3 冷启动问题双塔的冷启动痛点有两个方向新用户和新物品。对新用户行为序列几乎为空用户塔只能靠基础统计特征这样算出来的用户向量比较弱。对这种情况业界的两个补救手段一是靠着入口uid embedding 用相似框架的邻居的偏好来初始化二是用内容特征来弥补迭代比如新用户首次请求时把他选择的兴趣标签作为伪行为喂给用户塔。对物品的冷启动相对好处理。因为物品塔有内容侧的丰富特征新品即使没有交互数据也能学到一个方向合理的物品向量。很多团队新增物品先靠热度和内容召回顶上等有足够交互后进入双塔候选被点击样本过少时容易学歪所以单品最少要等有一定交互量再进向量索引是行业里比较实用的做法。5.4 模型退化与向量趋同训练跑着跑着你发现推荐结果几乎都是同一个类别这就是向量趋同问题。用户塔和物品塔都在往某一个方向收缩。常见原因有两个一是负采样不足的极端情况全是热门物品做负样本模型学到的是“别推任何热门”二是特别稀疏的特征负责把 embedding 的中心拉到一起了。解法第一个是补足随机的负样本。第二个是加正则项对 embedding 做 L2 约束。第三个就是上面提到的难负样本策略它可以强制模型学出更有区分度的逻辑边界。向量趋同的问题一旦出现需要尽快把召回离线评测的多样性指标降下来看直接看 recall 有时候察觉不出来——因为头部的 recall 一直都在但种类已经全聚到一起了。6. 效果评估与后续迭代扩展6.1 离线评估recallk 与 指标多层验证训练完双塔模型常规的操作是先做一个 recallk 的离线验证。在测试集上取用户的真实交互物品用模型检索出 top k 的物品看看真实物品是否被召回。例如用户有 10 个真实交互取这 10 个物品的向量去与全量候选集做召回若检索结果里有 r 个命中那么 recall r / 10。 后缀是 k所以 recall50、recall100 是常用指标。不过 recallk 这个指标有一个天生缺陷它只评价“目标物品是否在里面”不评价“最后召回的东西中间有没有用户实际上很反感的东西”。所以我建议离线评估时不要只盯着一个指标至少看三组recall100、hitrate100、以及一个多样性指标比如召回结果里类目分布的熵或者覆盖率。这三组数据放在一起才能比较完整地看出模型演进方向对不对。6.2 线上 A/B 测试的关键指标线上评估要关注双塔造成的前置漏斗变化而不是只盯最终成交。因为召回这个环节距离最终成交隔了很多层精排会修正部分召回的偏差双塔提升的效果传到最终指标时已经很弱。开始决策时建议数倍放大实验流量把召回队列曝光后的点击率、停留时长和后续转化对比做出来效果会清楚很多。一个良好的 A/B 观测周期至少要 7~14 天因为召回链路有一天到一周不等的长期偏好塑造效果一周内的数据容易有新鲜效应偏差。6.3 双塔之后还能怎么演进双塔的上限受限于结构和学到的表达方式进化的方向主要有三个。第一个是多向量召回。把用户塔的输出从单向量扩成 k 个向量对应不同兴趣方向再把物品向量也映射到相同的 k 个兴趣空间里最后在检索阶段做各方向的相似度加权和。实际效果上对一个拥有多种兴趣的用户比如既看篮球又看动漫双塔会把两个方向平均成一个区域两头都不讨好多向量可以显著改善这类场景的召回效果。第二个是双塔 交互模型的级联结构。双塔先召回候选再用一个轻量级的交互模型如 DIN、DCN 或者简单版的 transformer对召回结果做二次排序用交互模型的高精度来兜住双塔召回中不够准确的边界。这相当于多了一道粗排阶段工程上是顺理成章的事情。第三个是图召回与双塔的融合。用户在行为数据里天然带着一份物品共现图从这个图上做随机游走能产出高质量的路径序列把这些序列作为样本喂给双塔混合训练可以获得比纯行为序列更好的效果。一点经验总结这些内容做下来我对双塔模型最深的体会是模型本身并不复杂真正的壁垒在数据处理和工程细节上。负样本怎么配、特征有没有穿越、训练和检索的度量是否一致、索引选的合不合理每一个环节都会实实在在影响线上效果。如果你也是刚上手做召回我建议不要一上来就深挖模型结构先把样本和特征这两件事做扎实双塔能有七成的效果提升都在这里。后面想再往上走就看看你的业务瓶颈是兴趣多样性还是实时敏感性再决定往哪个方向进化。
双塔召回模型最近几年在推荐、搜索、广告这些场景里几乎成了标配方案。不管是刚入门做推荐系统的工程师还是已经在业务里摸爬滚打几年的同学应该都绕不开这个名字。简单说双塔召回就是把用户和物品分别编码成两个向量然后在向量空间里做最近邻检索从百万甚至亿级的候选池里快速捞出几百上千个最可能相关的物品。这篇文章我就结合自己做推荐召回这几年踩过的坑、调过的参、重构过的模型把这个模型从原理到落地再到排查问题完整拆一遍。1. 双塔召回模型的核心思想与设计动机1.1 召回问题到底在解决什么先说清楚召回在整个推荐链路里的位置。一个完整的推荐系统大致是召回、粗排、精排、重排这几层。召回阶段面对的是全量物品池少则几十万多则上亿精排模型再强也不可能把全量物品都过一遍所以召回必须在十几毫秒甚至几毫秒内从超大候选池里筛出一个几百到几千的候选集合交给下游排序。召回这个东西本质上是检索问题不是排序问题。排序讲究的是对每个物品都算一个精准的分数而召回讲究的是快、准、狠——快是指延迟要低准是指真正相关的物品不能漏掉狠是指哪怕牺牲一点精度也要保证覆盖率。早期业界常用的召回方式有协同过滤、向量召回、规则召回、热榜召回等双塔召回属于向量召回这一支里最经典、最稳定的实现方式。双塔模型做的事情翻译成人话就是给每个用户算一个 embedding 向量给每个物品也算一个 embedding 向量然后用内积或者余弦相似度去衡量用户和物品之间的相关性。训练的时候用户塔和物品塔各自学各自的表示推理的时候预先算好所有物品的 embedding存在向量索引里来一个用户实时算他的 embedding然后走 ANN近似最近邻检索就能在毫秒级把最相关的物品捞出来。1.2 为什么双塔结构是工业界的主流选择双塔能成为主流核心原因就一条训练和推理的解耦。左边用户塔右边物品塔两个塔在结构上完全独立只在 loss 层汇合。这个结构天然适配工业界的部署方式——物品侧是静态的、海量的可以离线算好向量存进索引用户侧是动态的、请求驱动的可以在线实时算向量然后去查索引。如果换成传统的拼接式模型用户特征和物品特征在最后一层全连接层才融合那线上推理时必须把候选物品的特征一个个喂给模型这个计算量在召回阶段是完全扛不住的。我见过团队一开始用的是 FM 或者 DeepFM 做召回实际上就是拿精排模型硬扛召回。结果线上延迟到了 80 毫秒还只能扫 5 万个物品覆盖率远远不够。后来切到双塔用户侧一次前向传播算一个向量物品向量全部预计算整体延迟降到 3 毫秒以内候选池能撑到千万级。这不是说 FM 这类模型不好而是把交互模型用错了地方——交互计算在召回阶段成本太高双塔牺牲了部分特征交叉能力换来了工程上的可行性这个 trade-off 在工业场景里是划算的。1.3 什么场景下适合用双塔什么场景下不适合双塔不是万能的。如果你的候选池只有几千个比如企业内部知识库检索、某个垂类小场景的物品推荐那直接用交互模型比如 DIN、DCN 甚至简单的 FM 都行全量打分很快没必要非得向量化。但一旦候选池到了十万级、百万级以上或者你对响应延迟有严格要求双塔就是性价比最高的方案。另外双塔擅长的是“相关性”而不是“个性化”。用户塔能学到用户的长期兴趣分布但很难表达用户在某一次请求里的即时意图。举个例子用户今天想买一个儿童安全座椅他过去的历史行为全是数码产品这种场景下双塔单塔的向量很可能偏向长期兴趣短期意图的表达能力就弱。这种情况一般靠两个手段弥补一是给用户塔加实时行为序列特征把最近一次点击、最近一次加购放进去做 attention二是双塔和其他策略召回形成多路互补别让单路双塔扛所有召回量。2. 双塔模型的结构设计与特征处理细节2.1 用户塔和物品塔各自该输入哪些特征用户塔的特征来源一般分三类用户基础属性年龄、性别、城市等级、注册时长、用户行为统计近 7 天点击次数、近 30 天购买类目分布、用户行为序列最近点击的 item id 序列、最近收藏的 item id 序列。物品塔的特征来源也分三类物品基础属性物品 id、类目 id、品牌 id、价格档位、物品内容属性标题分词、标签集合、图文向量、物品统计属性近 7 天曝光量、点击率、收藏率、购买转化率。这里有个关键原则用户塔和物品塔的特征可以重叠一部分但千万不要把用户侧的强特征塞进物品塔里或者反过来。比如物品的“近 7 天点击率”作为它自己的统计特征没问题但如果你把“当前请求用户对该物品的点击率”这个特征塞进去这在训练时可以通过特征交叉学得不错但上线推理时这个特征根本拿不到因为你正在做召回用户和物品的交叉信息是未知的。这就是特征穿越里最常见的坑后面我单独讲。2.2 连续特征怎么处理分桶与归一化双塔模型里连续特征的预处理非常影响效果但很多团队的做法特别随意直接 z-score 归一化就丢进去了。我自己的经验是连续特征优先做分桶离散化把连续值映射成离散 id再走 embedding 层。比如物品的价格可以按分位数切成 50 个桶每个桶一个 embedding。这样做的好处有三个第一能表达非线性关系一个原始价格数字要拟合非线性关系MLP 得自己学但分桶相当于预先做了特征变换第二能天然处理缺值缺值单独设一个桶第三在线推理时查 embedding 表比实时算连续特征的前向传播更快更可控。如果特征本身是稠密向量比如图文内容的预训练 embedding、用户主题偏好向量这类特征就不要分桶了直接 concat 拼到 tower 输入里即可。不过要注意这类稠密 embedding 向量最好也做一下归一化防止它们的模长过大把其他特征的梯度带偏。2.3 多值特征与序列特征的聚合方式物品有标签集合比如一部电影有“喜剧”“爱情”“经典”三个标签用户有最近点击序列比如 50 个点击过的 item id。这类多值特征的处理常见做法是把每个值都查成 embedding然后用 sum pooling、mean pooling、attention pooling 聚合成一个向量。很多团队图省事直接用 mean pooling效果也不错但要注意一个问题物品标签的重要性差异很大“喜剧”这个标签对用户的判断权重可能远高于“2023年上映”这个标签mean pooling 把这个信息抹平了。我推荐的做法是加一层简单的 attention为每个特征位学习一个注意力权重这个权重可以是一个没有隐层的单层 MLP输入是特征 embedding 本身输出一个标量。这个结构简单不增加多少参数量但在实际效果里能显著提升表达力尤其是在用户行为序列上。用户点击的 50 个 item用户点击它们时状态差别很大——他三秒前点的和三天前点的意图强度完全不同。用时间衰减加权或者 attention 都能改善这个问题。2.4 MLP 塔的层数与维度怎么定塔的网络结构一般就是几层全连接加激活函数每层逐渐降维。比如输入特征拼接后维度是 500然后走 512 - 256 - 128 - embedding 维度 64每层之间加 ReLU 或 LeakyReLU。embedding 的输出维度常见是 32 到 128 之间。维度太小表达力不足维度太大不仅训练开销大而且 ANN 检索的精度和速度都会下降因为高维向量索引的“维度灾难”很明显。关于层数我踩过一个坑把塔做得太深用了 5 层全连接参数量大了不少但效果反而变差了。原因是双塔模型的训练信号非常稀疏——每个训练样本只是一个用户和一个物品的匹配交叉信息通过 loss 反传塔内部每一层都要在这种稀疏信号下学习过深的网络容易过拟合和梯度不稳定。我的经验是 2~3 层全连接就够用瓶颈在于特征质量的提升而不是模型深度的增加。2.5 用户塔和物品塔要不要共享参数这个问题不同团队有不同答案。如果用户侧特征和物品侧特征的分布差异很大——用户侧是行为序列和画像物品侧是内容属性和统计强行共享参数反而有害。但如果两侧特征都很稀疏、同质性强比如都是 id 类特征共享一部分 embedding 表能显著减少参数还能解决冷启动问题。比如快手早期做视频推荐用户侧有交互过的视频 id物品侧是视频 id两边都指向同一个 embedding 表这样新视频只要出现过就能通过共享 embedding 被用户塔感知。我自己实践下来比较稳妥的做法是id 类 embedding 表按场景决定是否共享非 id 类的塔内参数各自独立。共享不共享要在实验里 A/B 验证不能拍脑袋。共享逻辑在代码里不复杂容易实现值得多试两种方案。3. 训练样本、损失函数与采样策略3.1 正样本怎么构造最合理正样本一般取用户与物品之间有正向反馈的交互对。不同业务对“正向”的定义不同电商场景加购、购买比点击重要得多内容场景完整播放、点赞、关注比曝光高广告场景点击和转化都要。实践经验是训练正样本要有主次之分核心动作样本要给更高的权重次要动作样本也不能完全不要。一个常用的降权方式是给正样本加一个重要性权重。比如购买权重是 1.0加购是 0.5点击是 0.1这个权重要么直接乘到 loss 上在 CE loss 里体现为样本权重要么通过重复采样来凑比例。我见过有团队把点击样本疯狂重复采样导致模型全学成了“点击偏好”而忽略了“购买偏好”方向就偏了。我会在后文讲 batch 内负样本采样时再提到相关细节。3.2 负样本采样的三种经典策略与对比负样本的设计是双塔模型里最影响效果的环节。孪生塔的负样本为每一次正样本配对随机制造一个不与用户互动的物品。太简单的负样本学了没意义全是“用户没点过”的简单样本模型学到的只是用户和所有非交互物品之间的大致差异根本分不清用户是“没兴趣”还是“没看过”这个物品稍繁杂一些的负样本能提供更完整的语义信息因此业界演化出几种策略。随机负采样直接从全量物品里均匀地抽一批作为负样本。实现最简单能保证负样本分布覆盖全量物品池但问题在于随机抽的负样本大多是低频长尾物品用户的注意力基本上都在喂养模型时的头部物品上所以模型对头部物品的判别能力其实很差。经验值随机负样本占比大概七到八成。batch 内负采样拿一个 batch 内其他用户的正样本来充当当前用户负样本。一个 batch 里用户 A 的正样本是物品 X用户 B 的正样本是物品 Y那么用户 A 的训练中物品 Y 就成了负样本。这个策略实现简单训练快而且最关键的是这些负样本恰好都是实体物品不会像随机采样那样给了用户完全没见过的物品。隐患在于热门物品更容易成为别人的负样本误伤率偏高——热门物品被降权严重长期后尾部物品更容易被推向头部物品的排名位置因此要加修正。hard negative 采样字面意思是给用户看和他有部分相似但绝对不匹配的物品。比如用户喜欢篮球鞋把跑步鞋当负样本特别能锻炼模型的判别边界。先训练一个简单版本的双塔再用它给每个正样本配几个难负样本难度大了模型学出来的向量会更「紧凑」——相似物品近、不相似的远。hard negative 比例一般为 5%~20%太多模型会更难收敛训练不稳定。混合采样的通用做法以 80% 随机负采样 10% batch 内负样本 10% 难负样本为基础再根据业务场景不断调比例。有些场景里难负样本提升明显有些则不然这点需要用实验来定比例。3.3 Loss 函数与 temperature为什么不是简单的内积sigmoid双塔模型里最常用的 loss 是 CE loss也可以叫 InfoNCE loss。给定一个 batch 的样本batch 内用户 i 的正样本是物品 i其他物品都是负样本对用户 i 的 loss 就是 softmax 输出的交叉熵。L_i -log( exp(sim(u_i, v_i)/τ) / Σ_j exp(sim(u_i, v_j)/τ) )sim 常用内积或余弦相似度temperature 是缩放系数。很多同学刚上手时 temperature 直接设成 1效果会非常差。原因在于内积的取值范围可以很大尤其没有归一化时可能到几百直接进 softmax 会让梯度几乎消失模型很难学到东西。temperature 的作用就是控制相似度分布的“尖锐度”temperature 越小越能拉大正负样本的差距让模型更用力地学习最难区分的样本。一般经验值在 0.05~0.2 之间具体可以先设 0.1再根据 loss 收敛情况和评测指标微调。这里还要注意用了 temperature 之后训练时的 AUC 曲线会虚高不代表线上真实效果就好。我见过一个团队调 temperature 从 0.1 调到 0.01离线 recall 涨了 8 个点线上 AB 反而跌了 3 个点。原因是模型过度专注于难负样本之间的区分把简易正样本的质量拉低了。3.4 归一化要不要把 embedding 归一化成单位向量关于用户塔和物品塔输出的 embedding 是否要做 L2 归一化业界的做法不完全统一。归一化之后内积就等于余弦相似度数值范围固定在 [-1, 1]训练稳定且便于 ANN 检索时使用余弦距离的索引。不归一化内积可以表达“模长”和“方向”两重信息这在有些场景下是有意义的——比如高消费用户的 embedding 模长偏大能反映用户行为的强度。我的建议是首选归一化理由有两点。第一召回阶段更关注方向而非模长一个用户的强烈兴趣应该体现在方向一致性上第二归一化后向量分布更均匀做向量索引时量化误差更小检索精度更高。如果业务上确实需要模长信息可以把模长拆成一个单独的标量特征加在精排阶段使用召回阶段仍然归一化。4. 线上推理与向量检索的工程落地4.1 物品 embedding 的产出与更新机制双塔模型在线上推理时大概可以拆成两个环节物品向量的预计算和动态产出以及用户向量的实时推理。物品向量的更新是个需要精心设计的事。至少四小时一次的离线全量增量任务跑一个全量索引更新太频繁的话全量任务的资源消耗又太大。增量部分的任务可以补偿一部分指标只算新物品、被修改的物品、以及最近一周内有点击行为的物品把这些物品的向量增量更新到索引里。流式通道通常时延控制在分钟级适用于用户上传内容等实时性要求极高的场景。调这套系统时要格外关注的一点是将物品的向量更新频率与用户和物品特征的更新频率对齐。举例来说假如你给物品统计“近 7 天点击率”这个特征而这个特征每 4 小时更新一次但是你的流式通道按分钟更新物品 embed那用户拿到的新向量并不包含最新的点击率变化产生严重的线上线下不一致。4.2 向量索引选型flat 与 ANN 怎么权衡向量检索是双塔工程落地的第二个核心决策。小规模场景比如十万级物品暴力扫描全量向量是完全可行的这个量级可以毫秒级跑完所有向量。百万级往上必须引入 ANN 索引常见的有 IVF、PQ、HNSW具体的选型建议flat暴力扫描虽然精确但只适合候选集五万以下的小场景上线后再换索引是件很麻烦的事。IVF倒排分桶空间开销小先聚类再查桶可以搭配 PCA 降维缺点是召回率不够稳定对簇界附近的样本易丢失。HNSW 是基于图的算法是目前综合表现最好的选择召回率高、查询延迟低适合绝大多数场景。如果内存紧张可再考虑加上 PQ 量化。实际业务中我最终的典型搭配是 HNSWefSearch 调至 128 或 256离线召回率大概能保持在 95% 以上内存占用也还在可控范围。4.3 embedding 与检索的 Score 一致性陷阱这里有一个特别隐蔽的工程坑训练时模型的相似度是内积但线上做 ANN 检索时用的距离度量可能是欧氏距离或余弦距离如果这三个东西不一致线上分数分布和离线完全不同。解决的方法很粗暴但有效在训练的最后一步强制用户塔和物品塔的输出层都过 L2 归一化让内积等效于余弦相似度线上检索一致地采用余弦距离。如果你的某个场景坚持不归一化而用内积那 ANN 索引就得用 IP 内积索引类型别混着用。我见过一次线上事故训练用内积检索用 L2 距离结果线上推荐质量崩得没法看把这个对齐后就好多了。4.4 多路召回结果怎么融合实际系统中双塔往往不是唯一的一路召回。还会有热榜召回、规则召回、同路人召回等。多路召回结果融合时有一个细节值得注意不同路的分数不在一个量纲上直接排序或加权是会出问题的。比较成熟的做法是先用并集去重再把所有路的结果当作特征送进粗排模型里让粗排模型决定谁能进入精排。粗排可以理解为特征交叉能力弱一些的精排模型输入是所有路召回来的物品由它对这些物品打分排序取头部几百个进精排。这里要注意粗排能获取的交叉特征虽然有限它收到的向量特征是最有价值的信号之一所以不要把召回路产生的特征给丢了。5. 常见问题与实战排查5.1 特征穿越线下刷分线上扑街的头号杀手特征穿越是召回模型里最常踩的坑之一。出自“当前用户对当前物品的行为统计”这类特征。比如你在训练时使用“该用户是否在最近一次曝光中点击过该视频”作为物品统计特征训练时模型当然能把这个特征学得很好但召回线上这个特征根本拿不到——你说你不知道用户会不会点这个视频因为这个预测本来就是正在做的事模型学到的是穿越特征里的信息等于作弊。上线后这类特征全部缺失指标自然跳水。排查特征穿越有个简单手段把模型特征做一次“可获取性审计”逐个检查每个特征在召回推理时是否有真实值可取。凡是依赖交叉信息的、依赖未来信息的、依赖线上没有实时更新的信息的都算穿越特征。另外我个人的习惯是上线新特征前跑一个只含旧特征的影子模型做对比如果加了新特征离线指标突飞猛进那多半有穿越问题。5.2 训练与 Servcing 不一致除了特征穿越双塔常见的问题还有模型定义与线上打分路径不一致。训练时你用的是内积加 temperature但线上召回时直接用余弦相似度排中间多了一层转换线下数据又看不出任何毛病或者你训练时用了采样修正但线上的物品向量没做对应修正热门和冷门物品的分数被扭曲。这个问题的排查思路是制定一份“模型-特征-服务”一致性清单每一项线上都要做到离线完全一致。具体到代码上可以把线上打分用的逻辑抽成一个共享函数训练和推理共用避免两套代码漂移。5.3 冷启动问题双塔的冷启动痛点有两个方向新用户和新物品。对新用户行为序列几乎为空用户塔只能靠基础统计特征这样算出来的用户向量比较弱。对这种情况业界的两个补救手段一是靠着入口uid embedding 用相似框架的邻居的偏好来初始化二是用内容特征来弥补迭代比如新用户首次请求时把他选择的兴趣标签作为伪行为喂给用户塔。对物品的冷启动相对好处理。因为物品塔有内容侧的丰富特征新品即使没有交互数据也能学到一个方向合理的物品向量。很多团队新增物品先靠热度和内容召回顶上等有足够交互后进入双塔候选被点击样本过少时容易学歪所以单品最少要等有一定交互量再进向量索引是行业里比较实用的做法。5.4 模型退化与向量趋同训练跑着跑着你发现推荐结果几乎都是同一个类别这就是向量趋同问题。用户塔和物品塔都在往某一个方向收缩。常见原因有两个一是负采样不足的极端情况全是热门物品做负样本模型学到的是“别推任何热门”二是特别稀疏的特征负责把 embedding 的中心拉到一起了。解法第一个是补足随机的负样本。第二个是加正则项对 embedding 做 L2 约束。第三个就是上面提到的难负样本策略它可以强制模型学出更有区分度的逻辑边界。向量趋同的问题一旦出现需要尽快把召回离线评测的多样性指标降下来看直接看 recall 有时候察觉不出来——因为头部的 recall 一直都在但种类已经全聚到一起了。6. 效果评估与后续迭代扩展6.1 离线评估recallk 与 指标多层验证训练完双塔模型常规的操作是先做一个 recallk 的离线验证。在测试集上取用户的真实交互物品用模型检索出 top k 的物品看看真实物品是否被召回。例如用户有 10 个真实交互取这 10 个物品的向量去与全量候选集做召回若检索结果里有 r 个命中那么 recall r / 10。 后缀是 k所以 recall50、recall100 是常用指标。不过 recallk 这个指标有一个天生缺陷它只评价“目标物品是否在里面”不评价“最后召回的东西中间有没有用户实际上很反感的东西”。所以我建议离线评估时不要只盯着一个指标至少看三组recall100、hitrate100、以及一个多样性指标比如召回结果里类目分布的熵或者覆盖率。这三组数据放在一起才能比较完整地看出模型演进方向对不对。6.2 线上 A/B 测试的关键指标线上评估要关注双塔造成的前置漏斗变化而不是只盯最终成交。因为召回这个环节距离最终成交隔了很多层精排会修正部分召回的偏差双塔提升的效果传到最终指标时已经很弱。开始决策时建议数倍放大实验流量把召回队列曝光后的点击率、停留时长和后续转化对比做出来效果会清楚很多。一个良好的 A/B 观测周期至少要 7~14 天因为召回链路有一天到一周不等的长期偏好塑造效果一周内的数据容易有新鲜效应偏差。6.3 双塔之后还能怎么演进双塔的上限受限于结构和学到的表达方式进化的方向主要有三个。第一个是多向量召回。把用户塔的输出从单向量扩成 k 个向量对应不同兴趣方向再把物品向量也映射到相同的 k 个兴趣空间里最后在检索阶段做各方向的相似度加权和。实际效果上对一个拥有多种兴趣的用户比如既看篮球又看动漫双塔会把两个方向平均成一个区域两头都不讨好多向量可以显著改善这类场景的召回效果。第二个是双塔 交互模型的级联结构。双塔先召回候选再用一个轻量级的交互模型如 DIN、DCN 或者简单版的 transformer对召回结果做二次排序用交互模型的高精度来兜住双塔召回中不够准确的边界。这相当于多了一道粗排阶段工程上是顺理成章的事情。第三个是图召回与双塔的融合。用户在行为数据里天然带着一份物品共现图从这个图上做随机游走能产出高质量的路径序列把这些序列作为样本喂给双塔混合训练可以获得比纯行为序列更好的效果。一点经验总结这些内容做下来我对双塔模型最深的体会是模型本身并不复杂真正的壁垒在数据处理和工程细节上。负样本怎么配、特征有没有穿越、训练和检索的度量是否一致、索引选的合不合理每一个环节都会实实在在影响线上效果。如果你也是刚上手做召回我建议不要一上来就深挖模型结构先把样本和特征这两件事做扎实双塔能有七成的效果提升都在这里。后面想再往上走就看看你的业务瓶颈是兴趣多样性还是实时敏感性再决定往哪个方向进化。
