大家做推荐系统这么多年应该都体会过那种拧巴感召回阶段用双塔在向量空间里捞人排序阶段用精排模型在特征空间里较真两套模型、两套样本、两套训练pipeline谁都不服谁。召回觉得排序小题大做排序觉得召回粗枝大叶。最近圈子里讨论比较多的是“统一召回与排序”这个方向说白了就是不再把召回和排序当成两个孤立的算法模块而是用一套思路、一套模型去整体建模。这个方向下目前冒出了几条新路线我梳理下来大概能归成三条分别对应不同业务阶段和团队资源今天就把这三条路线的思路、技术细节和落地经验一次性讲清楚。1. 为什么大家开始聊“统一召回与排序”先把话说明白传统推荐链路长得像一条瀑布召回从千万级item里选几百个粗排再压到几十个精排最后排出一个十几条左右的列表。这套多级漏斗在工业界用了十几年结构清晰、问题隔离每一级都能单独调优。但它的问题同样出在“隔离”上。1.1 召回不懂排序排序够不着召回召回模型关注的是“相关性”和“覆盖面”目标是把用户可能感兴趣的东西尽量捞回来排序模型关注的是“点击率”“转化率”“时长”等业务指标目标是把概率高的排前面。两者目标不一样数学形式不一样数据分布更不一样。于是常见的情况就是召回阶段把一批items捞回来排序阶段拼命调特征却发现有些item在召回那边就注定了永远出不来——排序模型再精准也排不了它压根没见过的候选。我举一个特别典型的例子。你在视频App里做精排花了大力气把用户看完播率、完播时长都算得无比精准模型AUC提升了0.01线上CTR也涨了。但某一天做case study发现用户最喜欢的某个小众纪录片因为它的向量表征和热门内容的分布离得比较远召回阶段就把它筛掉了。排序模型根本没机会看到它。这就是信息损耗召回阶段只保留几百个候选它的目标天然和排序不一致漏斗每一层都在丢信息。打个比方这就像选秀节目海选只考颜值决赛只考才艺。评委在海选时用颜值刷掉了一批很有才艺但长相不突出的人那决赛环节再专业也没用因为舞台上都站不上。1.2 样本偏差与“曝光死”的恶性循环排序模型是在曝光日志上训练的而曝光日志来源于召回结果。换句话说排序模型的学习范围被召回模型圈死了。这里有个更隐蔽的问题叫“曝光死”。新item或者长尾item因为初期没有曝光机会所以没有训练样本没有训练样本排序模型就学不会给它们打高分排序模型不给高分它们就更难曝光。周而复始这些item的召回特征也被压制最后彻底沉底。行业里解决这个问题通常靠随机曝光、探索策略或者补充冷启动流量但这些都是打补丁底层原因还是因为召回和排序各管各的没有一个统一的信号通路去告诉模型“这个item应该被看见”。召回模型如果只跟向量相似度较劲它就天然倾向于推荐和用户历史上喜欢的东西相似的item多样性、探索性统统不在它的建模范围内。而排序模型看到的又是一堆已经过完一道筛子的样本两者的训练分布完全不同拼在一起自然有罅隙。1.3 工程账两到三套模型意味着两到三份成本还有一个很现实的原因是工程侧。传统链路里召回一个模型甚至多个策略召回、粗排一个模型、精排一个模型每套模型都有独立的特征工程、样本生成、训练任务、上线流程、监控告警。数据量大一点、链路复杂一点的时候光维护这些模型的一致性就够三个算法工程师忙半年。我见过一些中小团队明明只有几十万DAU却硬照着大厂的模板搭了“召回粗排精排”三件套。结果是人力全耗在修数据管道上精排模型半年没迭代一版召回侧的多路召回策略更是全靠手工调阈值。把召回和排序统一起来表面看是模型结构的问题本质上是工程效率的问题。一套样本、一套特征、一套模型训练和部署成本都会成倍下降这条账很多人算得过来。所以统一召回与排序并不是学术圈拍脑袋想出来的新概念它背后是实实在在的工程痛点在倒逼。2. 路线一共享底座、级联感知——一个底座两个头这是三条路线里最“保守”也最容易落地的一条。它的核心思想是召回和排序仍然各干各的但底层embedding和网络结构完全共享模型只在最后分叉成两个不同的head。你可以把它理解成一个人长了两套专业技能但身体是同一副。2.1 结构细节一个encoder两个head具体来说模型分成三块底层是共享的序列编码器负责把用户历史行为、上下文特征、item特征全部嵌入并融合产出统一的用户向量和item向量召回head是一个双塔打分结构或者多分类结构负责从全量item里捞候选它的输出是一个召回分数排序head是一个CTR/CVR预估结构输入是共享encoder产出的表征输出是排序分数。这里的重点是“共享”。传统做法里用户向量和item向量是两个模型各自训练出来的各说各的话。共享底座之后召回head和排序head看到的用户表征、item表征是同一套信息流通顺畅多了。排序模型能从召回塔拿到“这个人对这类item的整体偏好”的信号召回模型也能从排序塔拿到“这类item在曝光后表现如何”的信号。实际工程里这种结构往往由一个多任务学习框架承载底层的共享参数负责学习用户与item的通用交互模式两个head负责各自任务的专属信息。2.2 怎么训练两阶段蒸馏互通结构有了训练方法才是关键。我的建议是分两步走。第一步先用纯召回目标训练整个模型。具体做法就是在全量item里做batch内负采样或随机负采样用多分类的softmax损失把整个模型训练到收敛。这一步的目标是让共享encoder学到基本的用户和item表征。注意这步不用让排序head参与它会自动跟着学。第二步冻结或微调共享encoder同时用排序目标微调排序head并同步用“排序分数蒸馏”去修正召回head。蒸馏的做法是把精排模型或者排序head自己算出来的对候选集的分当作软标签让召回头的输出分布往这个软标签上靠。这样召回head就能学习到排序模型更偏好的信号从而在召回阶段就有意识地避开那些“排序根本不会点”的item。写成伪代码大概是这种感觉# pytorch风格伪代码只展示关键逻辑 user_emb encoder(user_features) item_emb item_encoder(item_features) # 召回head双塔内积打分 recall_score dot(user_emb, item_emb) # 排序head交叉特征 MLP sorting_input concat([user_emb, item_emb, cross_features]) sorting_score sort_mlp(sorting_input) # 召回损失in-batch softmax recall_loss cross_entropy(recall_score, positive_item_idx) # 排序损失CTR二分类 sorting_loss binary_cross_entropy(sorting_score, label) # 蒸馏损失KL散度让召回分靠近排序分的分布 distill_loss kl_divergence(recall_score_dist, sorting_score_dist) total_loss recall_loss * 0.6 sorting_loss * 1.0 distill_loss * 0.3这里有个细节早期训练时蒸馏损失的权重不应太大否则召回head会被排序head的偏见带偏丧失召回应当具备的recall能力。我在实际项目中通常把它从0.1开始每5000步往上调0.05封顶0.5。2.3 实操心得别让召回头拖垮排序头这个结构最大的坑在于两个head的梯度会互相干扰。排序head需要精细特征如item质量分、用户状态特征、上下文特征的交叉而召回head需要泛化能力强、能处理长尾的表征。当两者共用底层时排序任务产生的梯度和召回任务的梯度如果方向相反训练就会波动。我实践中有三个缓解手段一个是像上面伪代码里写的那样在排序head和召回head之间插入stop-gradient操作让排序head的梯度不回流到最底层只微调与之相连的几十层参数。召回head的表征更新靠自己的梯度同时加上蒸馏损失来接收排序任务的信息。第二个是给两个head配上不一样的学习率。召回head用默认学习率排序head的学习率调小到它的三分之一左右。这样排序任务能学到精细信号而召回任务保持相对稳定。第三个是样本上的隔离。召回任务可以用全量负样本包括未曝光样本排序任务只能用曝光样本。这两者的训练数据必须分开抽取否则样本分布会互相污染。这条路线适合谁适合已经有一套成熟召回模型和排序模型、但不想推倒重来的团队。改造幅度最小线上效果通常也能稳定涨几个点。我见过最快的一次一个团队两周内完成模型替换和AB实验上线。3. 路线二多任务联合式统一——一个模型两条腿走路路线一本质上还是“一个底座两个head”的物理分叉而路线二走得更彻底不再区分召回head和排序head而是用多任务学习框架把“召回”和“排序”定义成两个同级别的优化目标在一个模型内部同时优化。这个方向上最经典的结构是MMoE、PLE以及搜索引擎里常见的ESM/ESMM类框架。3.1 从MMoE到PLE共享专家、保留专属纯共享底层的多任务模型有个著名问题叫“跷跷板现象”两个任务共享参数时往往一个任务好了另一个任务就差了。原因是不同任务对特征空间的需求差异太大。MMoE的做法是用多个“专家网络”来分管不同的信息模式每个任务通过自己的门控网络去“软选”专家而不是强制所有任务走同一条路。推荐系统里的多任务统一就是把“预测用户是否点击”和“预测用户是否会喜欢某个类别的item”作为两个任务。前者本质上是排序目标的二分类后者可以理解成召回目标的多分类。两个任务共享一批专家网络但各自通过门控去组合它们。PLE在MMoE基础上额外加了每个任务专属的专家共享专家和专属专家最后一起被门控聚合。实际落地时效果更稳定因为每个任务都保留了自己专属的表达通道梯度冲突少了很多。用多任务框架做统一的代码如下简化的门控逻辑# 一个简化的PLE-like 门控逻辑 shared_experts [Expert(dim_in, dim_hidden) for _ in range(2)] task1_experts [Expert(dim_in, dim_hidden) for _ in range(1)] task2_experts [Expert(dim_in, dim_hidden) for _ in range(1)] def forward(x): # task1: 排序预估点击率 gate1 gate_mlp1(x) # softmax over [shared, task1] experts1 concat([e(x) for e in shared_experts task1_experts]) task1_out sum(gate1 * experts1) # task2: 召回多分类/向量匹配 gate2 gate_mlp2(x) experts2 concat([e(x) for e in shared_experts task2_experts]) task2_out sum(gate2 * experts2) return ctr_head(task1_out), recall_head(task2_out)当然这只是结构示意真正的工业级实现对参数量、门控初始化都有讲究。我第一次跑MMoE的时候门控权重初始化没做好效果反而比单任务模型差了一截后来才知道门控初始偏置应该偏向共享专家让模型先学通用特征再逐渐分化。3.2 训练与serving细节多任务联合式统一最大的难点不在结构而在“怎么定义召回目标”。排序目标好办就是曝光样本上的点击/转化二分类。召回目标就比较暧昧了工业界常用两种做法第一种叫“batch内softmax召回”把“当前这个用户正反馈的item”当作正样本同batch里其他item都当负样本做一个多分类。这种做法的好处是负样本数量大、随机性强模型能学到真实的全局item分布但坏处是容易把热门item学成万能选项。第二种叫“向量匹配损失”比如用带温度系数的对比学习损失让用户序列表征与其正反馈item表征更近。这种办法更接近传统召回模型的做法。实际项目里我建议把两种损失都建模一个是主损失一个是辅助损失权重比大概在21到31之间。同时注意一个细节排序任务的特征里如果包含item ID会对召回任务产生“信息泄漏”因为item ID是最强的记忆特征模型一旦学会直接记忆就不会再去学习泛化的用户兴趣表征。所以特征要分层排序任务可以用item ID这类强特征召回任务用的大部分是用户侧特征、上下文特征和item类目等泛化特征item ID要么不用要么用它的embedding办法并且加上dropout。serving的时候这个模型会同时输出召回分数和排序分数。召回分数可以直接用于向量检索系的召回通道排序分数用于最终排序。系统看起来是一套模型但线上仍然保留了“召回通道”和“排序通道”两个逻辑模块只是它们共享同一个模型权重。这算是工程上的取巧算法统一了系统不必大动。3.3 什么场景优先选路线二这条路线综合性价比最高也是我最推荐团队优先尝试的。如果你们业务已经有一套相对完备的特征体系用户画像、item画像、上下文特征并且排序模型已经积累了不错的AUC但召回侧策略陈旧、向量模型一直没升级这时用路线二是最合适的直接在原有特征体系上加一个召回目标形成多任务模型复用运营侧已就绪的训练和上线框架。我去年接触过一个电商推荐团队情况就是这个精排模型AUC 0.78但是召回侧还是几路简单的 “热门 协同过滤 双塔向量”。他们选了路线二用MMoE结构把CTR任务和向量召回任务合并训练上线三个月后召回侧的覆盖率提升17%且整体GMV有稳定正收益。关键是训练样本和特征几乎没动改动成本很低。4. 路线三生成式统一——从打分到写答案前面两条路线虽然叫“统一”但本质上还是给“召回”和“排序”分别建模或者分配任务。路线三更进一步直接把这个过程压成一个序列生成问题——推荐列表不是“被召回归并、被排序再排”而是像写文章一样模型一个token一个token地“写”出来。这大概是2022年以来最前沿的探索方向。4.1 把推荐列表当作一句话来生成我刚开始接触这个思路时也是有点懵的后来换了个角度才想明白假设把用户历史交互的item当作输入序列或者prompt把用户接下来最可能喜欢的item当作输出序列那么推荐任务就变成了一个条件生成任务。输出的每一个token对应一个item IDtoken的排列顺序就是最终的推荐顺序。第一个生成的token是模型认为最该排第一的item第二个token是模型认为第二该排的item。排序问题在结构上天然融合进来了——位置就是排序。这其实和平时说的“字符串排序、数据结构排序、选择排序”这些显式比较排序是不同层面的东西传统排序是在一个固定候选集上做大小比较生成式排序则是模型直接学习“哪些item该出现、以什么顺序出现”的隐式序关系。4.2 生成式模型的训练与解码训练阶段通常用类似“随机掩码 自回归”的方式。把用户历史交互过的item按时间顺序作为输入上下文预测未来交互的item。在解码阶段使用beam search生成多个候选序列每个序列本身就是一条可以直接展示给用户的推荐列表。这里有一个关键问题全量item可能有几百万上千万让模型直接输出item ID的词典就太大了。目前常见的做法有两类一是做两级生成先生成item所属的类目或seed再用该类目下细粒度生成具体的item二是把生成目标改为“生成item的基本属性组合”比如“类目 风格 价格带 品牌”每个属性值是小型词典组合起来映射到具体item。第二种做法在电商场景里更实用。因为电商item的文本和属性信息丰富模型可以基于属性组合生成唯一item降低词典规模。我见过有团队用T5结构的序列到序列模型做这个事训练数据是用户的历史行为序列样本构建方式跟NLP领域构造seq2seq训练集非常像。解码时还涉及一个探索与收敛的平衡问题。全贪心beam search生成出来的列表容易多样性不足用户越看越窄。我建议在beam search里加一个温度系数随机性调大一点让第二条、第三条生成路径有更大概率被选出来这样推荐结果会更有层次感。4.3 实操要点与坑这条路线在真实业务落地的难度实际上是三条路线里最大的我从实际操作中总结出几个必须处理好的问题。第一个是item ID稀疏性的问题。生成式模型要求每个item都有一个稳定的ID和表征但长尾item的交互数据非常稀疏模型很难学会它们。我的解法是训练时对长尾item做“ID文本化”——把item的类目、属性、标题关键词拼成一段文本让模型在文本语义空间里生成再映射回ID。第二个是训练序列构造。不能简单按时间把用户所有交互都塞进去要截断、去重、区分正负反馈。如果把点开却不喜欢的item也放进上下文模型学到的兴趣信号就是混乱的。通常我会保留用户有明确正向信号加购、收藏、完整观看的行为作为上下文把点击序列作为弱标签混合训练。第三个是线上serving的开销。自回归生成是要按token一步步解码的比传统双塔精排的一遍打分贵得多。实际部署通常得搭配“先生成候选池再基于生成序列做局部替换”的策略或者把beam search的结果缓存起来做成异步召回。4.4 这条路线适合谁坦率地说路线三不是给每天要卡在几十毫秒内必须返回结果的极低延迟场景准备的而是给item空间相对可控、序列信号很强、且算法团队有足够预研能力的团队。典型场景比如小说推荐、短视频的长期消费序列、以及电商的“猜你喜欢”这种商品浏览流。这些场景的共同点是用户前后行为之间有连续的消费意图用序列生成去模拟兴趣递进关系特别合适。如果你们的业务是强工具型的比如导航、天气查询、通讯录那就别碰路线三了传统方案已经足够好。5. 三条路线怎么选对比、决策清单与避坑建议说了这么多理论最后落到怎么选。我根据自己的实践经验和观察到的业界案例给出一套选型思路和避坑要点。5.1 三条路线的对比速查表对比维度路线一共享底座路线二多任务联合路线三生成式统一模型结构复杂度低改动小中MMoE/PLE类框架高seq2seq/生成框架训练样本质变需要增加蒸馏样本需要构造多任务样本需要构造行为序列特征体系依赖中高中偏文本/属性特征线上serving开销低低可复用原有两通道高需缓存或异步可解释性高两个分数明确中两个分数仍有含义低为什么生成这个item靠解读冷启动表现中中较好可基于文本语义泛化团队落地周期2-4周1-2个月2个月以上预研试点适合阶段存量系统渐进改造存量系统升级新业务 / 前沿探索5.2 我的选型建议如果团队从零开始搭推荐系统没有历史包袱我第一推荐路线二。多任务联合框架成熟、资料多、坑也已经被很多人踩过了而且线上系统还是可以按“召回通道排序通道”组织不会给工程团队带来认知负担。如果团队已经有很重的存量系统精排模型很成熟只想让召回变得更好我推荐路线一。改动小、见效快风险也可控。蒸馏让召回学排序偏好这个思路尤其适合在召回侧快速验证。如果团队是想做技术护城河、或者业务形态本身就很像“内容生成”小说、短视频、商品推荐流可以花钱花人去预研路线三。但一定要把它当预研项目去管理而不是直接定线上指标。我自己见过太多团队一上来就想用生成式推荐替代老链路结果模型在离线指标上很漂亮一上AB就被线上延迟和稳定性教做人。5.3 绕不开的六个坑最后分享六条来自实战的踩坑经验希望你们能少走弯路。第一统一模型上线必须留新老链路并行AB窗口至少跑两个完整的业务周期包括周末峰值和大型活动日不要只看两三天的AUC或GMV变化。不同模型对真实反馈的敏感周期不一样短窗口容易被噪声带偏。第二正负样本比例要特别小心。召回任务的负样本极大排序任务的正样本极少合并成一个模型后如果权重配比不当模型会直接退化成一个“什么都觉得不相关”的保守模型。我给过一个原则排序损失和召回损失的数值量级要scale到同一水平一般为11到11.5再根据线上做小范围调参。第三蒸馏信号的温度系数不要拍脑袋设。温度过高召回分布趋近于均匀温度过低召回分布几乎变成hard label每次都学排序模型的top 1导致召回多样性断崖式下降。通常设在0.5到1之间稳定性更好。第四别把特征无脑全塞给多任务模型。排序任务能用的强特征如item在某策略下的历史点击率不见得对召回任务有帮助甚至可能让门控网络过拟合这些记忆性特征。特征要分层、分流让门控自己选择可能更稳。第五生成式路线别忽略负反馈建模。我一开始做路线三时只用了正样本序列生成出来的列表越看越像“同质化内容大赏”。后来把反馈行为分级建模滑动、点击、完整观看、不感兴趣并显式把“最近一次不感兴趣”的信号作为负上下文传给模型多样性才有明显提升。第六最容易被忽略的一点统一模型不等于不需要特征体系。恰恰相反它需要一套更干净、更一致的特征分层体系。如果你们现在的特征服务还是一团乱麻一个特征好几个口径别急着换模型结构先把特征治理好否则无论哪条路线都只是在一个糟糕地基上盖新楼。我个人在实际操作中的体会是统一召回与排序不是一道“用哪个模型结构”的选择题而是一道“先想清楚业务目标再动手”的工程题。路线一教召回学会排序的偏好路线二让两个目标共享一套表征路线三彻底打碎原有的“召回-排序”二元框架。这三条路线不是替代关系更像不同成熟度的解题思路。如果让我给一个最朴素的建议老系统渐进改造走路线一新系统从零搭建直接上路线二有余力、业务匹配、团队硬核再去钻研路线三。排序这件事说到底是对用户意图的深度理解而统一的目的从来不是单纯地删代码减模型而是让信息在链路里流得更干净、更完整。
大家做推荐系统这么多年应该都体会过那种拧巴感召回阶段用双塔在向量空间里捞人排序阶段用精排模型在特征空间里较真两套模型、两套样本、两套训练pipeline谁都不服谁。召回觉得排序小题大做排序觉得召回粗枝大叶。最近圈子里讨论比较多的是“统一召回与排序”这个方向说白了就是不再把召回和排序当成两个孤立的算法模块而是用一套思路、一套模型去整体建模。这个方向下目前冒出了几条新路线我梳理下来大概能归成三条分别对应不同业务阶段和团队资源今天就把这三条路线的思路、技术细节和落地经验一次性讲清楚。1. 为什么大家开始聊“统一召回与排序”先把话说明白传统推荐链路长得像一条瀑布召回从千万级item里选几百个粗排再压到几十个精排最后排出一个十几条左右的列表。这套多级漏斗在工业界用了十几年结构清晰、问题隔离每一级都能单独调优。但它的问题同样出在“隔离”上。1.1 召回不懂排序排序够不着召回召回模型关注的是“相关性”和“覆盖面”目标是把用户可能感兴趣的东西尽量捞回来排序模型关注的是“点击率”“转化率”“时长”等业务指标目标是把概率高的排前面。两者目标不一样数学形式不一样数据分布更不一样。于是常见的情况就是召回阶段把一批items捞回来排序阶段拼命调特征却发现有些item在召回那边就注定了永远出不来——排序模型再精准也排不了它压根没见过的候选。我举一个特别典型的例子。你在视频App里做精排花了大力气把用户看完播率、完播时长都算得无比精准模型AUC提升了0.01线上CTR也涨了。但某一天做case study发现用户最喜欢的某个小众纪录片因为它的向量表征和热门内容的分布离得比较远召回阶段就把它筛掉了。排序模型根本没机会看到它。这就是信息损耗召回阶段只保留几百个候选它的目标天然和排序不一致漏斗每一层都在丢信息。打个比方这就像选秀节目海选只考颜值决赛只考才艺。评委在海选时用颜值刷掉了一批很有才艺但长相不突出的人那决赛环节再专业也没用因为舞台上都站不上。1.2 样本偏差与“曝光死”的恶性循环排序模型是在曝光日志上训练的而曝光日志来源于召回结果。换句话说排序模型的学习范围被召回模型圈死了。这里有个更隐蔽的问题叫“曝光死”。新item或者长尾item因为初期没有曝光机会所以没有训练样本没有训练样本排序模型就学不会给它们打高分排序模型不给高分它们就更难曝光。周而复始这些item的召回特征也被压制最后彻底沉底。行业里解决这个问题通常靠随机曝光、探索策略或者补充冷启动流量但这些都是打补丁底层原因还是因为召回和排序各管各的没有一个统一的信号通路去告诉模型“这个item应该被看见”。召回模型如果只跟向量相似度较劲它就天然倾向于推荐和用户历史上喜欢的东西相似的item多样性、探索性统统不在它的建模范围内。而排序模型看到的又是一堆已经过完一道筛子的样本两者的训练分布完全不同拼在一起自然有罅隙。1.3 工程账两到三套模型意味着两到三份成本还有一个很现实的原因是工程侧。传统链路里召回一个模型甚至多个策略召回、粗排一个模型、精排一个模型每套模型都有独立的特征工程、样本生成、训练任务、上线流程、监控告警。数据量大一点、链路复杂一点的时候光维护这些模型的一致性就够三个算法工程师忙半年。我见过一些中小团队明明只有几十万DAU却硬照着大厂的模板搭了“召回粗排精排”三件套。结果是人力全耗在修数据管道上精排模型半年没迭代一版召回侧的多路召回策略更是全靠手工调阈值。把召回和排序统一起来表面看是模型结构的问题本质上是工程效率的问题。一套样本、一套特征、一套模型训练和部署成本都会成倍下降这条账很多人算得过来。所以统一召回与排序并不是学术圈拍脑袋想出来的新概念它背后是实实在在的工程痛点在倒逼。2. 路线一共享底座、级联感知——一个底座两个头这是三条路线里最“保守”也最容易落地的一条。它的核心思想是召回和排序仍然各干各的但底层embedding和网络结构完全共享模型只在最后分叉成两个不同的head。你可以把它理解成一个人长了两套专业技能但身体是同一副。2.1 结构细节一个encoder两个head具体来说模型分成三块底层是共享的序列编码器负责把用户历史行为、上下文特征、item特征全部嵌入并融合产出统一的用户向量和item向量召回head是一个双塔打分结构或者多分类结构负责从全量item里捞候选它的输出是一个召回分数排序head是一个CTR/CVR预估结构输入是共享encoder产出的表征输出是排序分数。这里的重点是“共享”。传统做法里用户向量和item向量是两个模型各自训练出来的各说各的话。共享底座之后召回head和排序head看到的用户表征、item表征是同一套信息流通顺畅多了。排序模型能从召回塔拿到“这个人对这类item的整体偏好”的信号召回模型也能从排序塔拿到“这类item在曝光后表现如何”的信号。实际工程里这种结构往往由一个多任务学习框架承载底层的共享参数负责学习用户与item的通用交互模式两个head负责各自任务的专属信息。2.2 怎么训练两阶段蒸馏互通结构有了训练方法才是关键。我的建议是分两步走。第一步先用纯召回目标训练整个模型。具体做法就是在全量item里做batch内负采样或随机负采样用多分类的softmax损失把整个模型训练到收敛。这一步的目标是让共享encoder学到基本的用户和item表征。注意这步不用让排序head参与它会自动跟着学。第二步冻结或微调共享encoder同时用排序目标微调排序head并同步用“排序分数蒸馏”去修正召回head。蒸馏的做法是把精排模型或者排序head自己算出来的对候选集的分当作软标签让召回头的输出分布往这个软标签上靠。这样召回head就能学习到排序模型更偏好的信号从而在召回阶段就有意识地避开那些“排序根本不会点”的item。写成伪代码大概是这种感觉# pytorch风格伪代码只展示关键逻辑 user_emb encoder(user_features) item_emb item_encoder(item_features) # 召回head双塔内积打分 recall_score dot(user_emb, item_emb) # 排序head交叉特征 MLP sorting_input concat([user_emb, item_emb, cross_features]) sorting_score sort_mlp(sorting_input) # 召回损失in-batch softmax recall_loss cross_entropy(recall_score, positive_item_idx) # 排序损失CTR二分类 sorting_loss binary_cross_entropy(sorting_score, label) # 蒸馏损失KL散度让召回分靠近排序分的分布 distill_loss kl_divergence(recall_score_dist, sorting_score_dist) total_loss recall_loss * 0.6 sorting_loss * 1.0 distill_loss * 0.3这里有个细节早期训练时蒸馏损失的权重不应太大否则召回head会被排序head的偏见带偏丧失召回应当具备的recall能力。我在实际项目中通常把它从0.1开始每5000步往上调0.05封顶0.5。2.3 实操心得别让召回头拖垮排序头这个结构最大的坑在于两个head的梯度会互相干扰。排序head需要精细特征如item质量分、用户状态特征、上下文特征的交叉而召回head需要泛化能力强、能处理长尾的表征。当两者共用底层时排序任务产生的梯度和召回任务的梯度如果方向相反训练就会波动。我实践中有三个缓解手段一个是像上面伪代码里写的那样在排序head和召回head之间插入stop-gradient操作让排序head的梯度不回流到最底层只微调与之相连的几十层参数。召回head的表征更新靠自己的梯度同时加上蒸馏损失来接收排序任务的信息。第二个是给两个head配上不一样的学习率。召回head用默认学习率排序head的学习率调小到它的三分之一左右。这样排序任务能学到精细信号而召回任务保持相对稳定。第三个是样本上的隔离。召回任务可以用全量负样本包括未曝光样本排序任务只能用曝光样本。这两者的训练数据必须分开抽取否则样本分布会互相污染。这条路线适合谁适合已经有一套成熟召回模型和排序模型、但不想推倒重来的团队。改造幅度最小线上效果通常也能稳定涨几个点。我见过最快的一次一个团队两周内完成模型替换和AB实验上线。3. 路线二多任务联合式统一——一个模型两条腿走路路线一本质上还是“一个底座两个head”的物理分叉而路线二走得更彻底不再区分召回head和排序head而是用多任务学习框架把“召回”和“排序”定义成两个同级别的优化目标在一个模型内部同时优化。这个方向上最经典的结构是MMoE、PLE以及搜索引擎里常见的ESM/ESMM类框架。3.1 从MMoE到PLE共享专家、保留专属纯共享底层的多任务模型有个著名问题叫“跷跷板现象”两个任务共享参数时往往一个任务好了另一个任务就差了。原因是不同任务对特征空间的需求差异太大。MMoE的做法是用多个“专家网络”来分管不同的信息模式每个任务通过自己的门控网络去“软选”专家而不是强制所有任务走同一条路。推荐系统里的多任务统一就是把“预测用户是否点击”和“预测用户是否会喜欢某个类别的item”作为两个任务。前者本质上是排序目标的二分类后者可以理解成召回目标的多分类。两个任务共享一批专家网络但各自通过门控去组合它们。PLE在MMoE基础上额外加了每个任务专属的专家共享专家和专属专家最后一起被门控聚合。实际落地时效果更稳定因为每个任务都保留了自己专属的表达通道梯度冲突少了很多。用多任务框架做统一的代码如下简化的门控逻辑# 一个简化的PLE-like 门控逻辑 shared_experts [Expert(dim_in, dim_hidden) for _ in range(2)] task1_experts [Expert(dim_in, dim_hidden) for _ in range(1)] task2_experts [Expert(dim_in, dim_hidden) for _ in range(1)] def forward(x): # task1: 排序预估点击率 gate1 gate_mlp1(x) # softmax over [shared, task1] experts1 concat([e(x) for e in shared_experts task1_experts]) task1_out sum(gate1 * experts1) # task2: 召回多分类/向量匹配 gate2 gate_mlp2(x) experts2 concat([e(x) for e in shared_experts task2_experts]) task2_out sum(gate2 * experts2) return ctr_head(task1_out), recall_head(task2_out)当然这只是结构示意真正的工业级实现对参数量、门控初始化都有讲究。我第一次跑MMoE的时候门控权重初始化没做好效果反而比单任务模型差了一截后来才知道门控初始偏置应该偏向共享专家让模型先学通用特征再逐渐分化。3.2 训练与serving细节多任务联合式统一最大的难点不在结构而在“怎么定义召回目标”。排序目标好办就是曝光样本上的点击/转化二分类。召回目标就比较暧昧了工业界常用两种做法第一种叫“batch内softmax召回”把“当前这个用户正反馈的item”当作正样本同batch里其他item都当负样本做一个多分类。这种做法的好处是负样本数量大、随机性强模型能学到真实的全局item分布但坏处是容易把热门item学成万能选项。第二种叫“向量匹配损失”比如用带温度系数的对比学习损失让用户序列表征与其正反馈item表征更近。这种办法更接近传统召回模型的做法。实际项目里我建议把两种损失都建模一个是主损失一个是辅助损失权重比大概在21到31之间。同时注意一个细节排序任务的特征里如果包含item ID会对召回任务产生“信息泄漏”因为item ID是最强的记忆特征模型一旦学会直接记忆就不会再去学习泛化的用户兴趣表征。所以特征要分层排序任务可以用item ID这类强特征召回任务用的大部分是用户侧特征、上下文特征和item类目等泛化特征item ID要么不用要么用它的embedding办法并且加上dropout。serving的时候这个模型会同时输出召回分数和排序分数。召回分数可以直接用于向量检索系的召回通道排序分数用于最终排序。系统看起来是一套模型但线上仍然保留了“召回通道”和“排序通道”两个逻辑模块只是它们共享同一个模型权重。这算是工程上的取巧算法统一了系统不必大动。3.3 什么场景优先选路线二这条路线综合性价比最高也是我最推荐团队优先尝试的。如果你们业务已经有一套相对完备的特征体系用户画像、item画像、上下文特征并且排序模型已经积累了不错的AUC但召回侧策略陈旧、向量模型一直没升级这时用路线二是最合适的直接在原有特征体系上加一个召回目标形成多任务模型复用运营侧已就绪的训练和上线框架。我去年接触过一个电商推荐团队情况就是这个精排模型AUC 0.78但是召回侧还是几路简单的 “热门 协同过滤 双塔向量”。他们选了路线二用MMoE结构把CTR任务和向量召回任务合并训练上线三个月后召回侧的覆盖率提升17%且整体GMV有稳定正收益。关键是训练样本和特征几乎没动改动成本很低。4. 路线三生成式统一——从打分到写答案前面两条路线虽然叫“统一”但本质上还是给“召回”和“排序”分别建模或者分配任务。路线三更进一步直接把这个过程压成一个序列生成问题——推荐列表不是“被召回归并、被排序再排”而是像写文章一样模型一个token一个token地“写”出来。这大概是2022年以来最前沿的探索方向。4.1 把推荐列表当作一句话来生成我刚开始接触这个思路时也是有点懵的后来换了个角度才想明白假设把用户历史交互的item当作输入序列或者prompt把用户接下来最可能喜欢的item当作输出序列那么推荐任务就变成了一个条件生成任务。输出的每一个token对应一个item IDtoken的排列顺序就是最终的推荐顺序。第一个生成的token是模型认为最该排第一的item第二个token是模型认为第二该排的item。排序问题在结构上天然融合进来了——位置就是排序。这其实和平时说的“字符串排序、数据结构排序、选择排序”这些显式比较排序是不同层面的东西传统排序是在一个固定候选集上做大小比较生成式排序则是模型直接学习“哪些item该出现、以什么顺序出现”的隐式序关系。4.2 生成式模型的训练与解码训练阶段通常用类似“随机掩码 自回归”的方式。把用户历史交互过的item按时间顺序作为输入上下文预测未来交互的item。在解码阶段使用beam search生成多个候选序列每个序列本身就是一条可以直接展示给用户的推荐列表。这里有一个关键问题全量item可能有几百万上千万让模型直接输出item ID的词典就太大了。目前常见的做法有两类一是做两级生成先生成item所属的类目或seed再用该类目下细粒度生成具体的item二是把生成目标改为“生成item的基本属性组合”比如“类目 风格 价格带 品牌”每个属性值是小型词典组合起来映射到具体item。第二种做法在电商场景里更实用。因为电商item的文本和属性信息丰富模型可以基于属性组合生成唯一item降低词典规模。我见过有团队用T5结构的序列到序列模型做这个事训练数据是用户的历史行为序列样本构建方式跟NLP领域构造seq2seq训练集非常像。解码时还涉及一个探索与收敛的平衡问题。全贪心beam search生成出来的列表容易多样性不足用户越看越窄。我建议在beam search里加一个温度系数随机性调大一点让第二条、第三条生成路径有更大概率被选出来这样推荐结果会更有层次感。4.3 实操要点与坑这条路线在真实业务落地的难度实际上是三条路线里最大的我从实际操作中总结出几个必须处理好的问题。第一个是item ID稀疏性的问题。生成式模型要求每个item都有一个稳定的ID和表征但长尾item的交互数据非常稀疏模型很难学会它们。我的解法是训练时对长尾item做“ID文本化”——把item的类目、属性、标题关键词拼成一段文本让模型在文本语义空间里生成再映射回ID。第二个是训练序列构造。不能简单按时间把用户所有交互都塞进去要截断、去重、区分正负反馈。如果把点开却不喜欢的item也放进上下文模型学到的兴趣信号就是混乱的。通常我会保留用户有明确正向信号加购、收藏、完整观看的行为作为上下文把点击序列作为弱标签混合训练。第三个是线上serving的开销。自回归生成是要按token一步步解码的比传统双塔精排的一遍打分贵得多。实际部署通常得搭配“先生成候选池再基于生成序列做局部替换”的策略或者把beam search的结果缓存起来做成异步召回。4.4 这条路线适合谁坦率地说路线三不是给每天要卡在几十毫秒内必须返回结果的极低延迟场景准备的而是给item空间相对可控、序列信号很强、且算法团队有足够预研能力的团队。典型场景比如小说推荐、短视频的长期消费序列、以及电商的“猜你喜欢”这种商品浏览流。这些场景的共同点是用户前后行为之间有连续的消费意图用序列生成去模拟兴趣递进关系特别合适。如果你们的业务是强工具型的比如导航、天气查询、通讯录那就别碰路线三了传统方案已经足够好。5. 三条路线怎么选对比、决策清单与避坑建议说了这么多理论最后落到怎么选。我根据自己的实践经验和观察到的业界案例给出一套选型思路和避坑要点。5.1 三条路线的对比速查表对比维度路线一共享底座路线二多任务联合路线三生成式统一模型结构复杂度低改动小中MMoE/PLE类框架高seq2seq/生成框架训练样本质变需要增加蒸馏样本需要构造多任务样本需要构造行为序列特征体系依赖中高中偏文本/属性特征线上serving开销低低可复用原有两通道高需缓存或异步可解释性高两个分数明确中两个分数仍有含义低为什么生成这个item靠解读冷启动表现中中较好可基于文本语义泛化团队落地周期2-4周1-2个月2个月以上预研试点适合阶段存量系统渐进改造存量系统升级新业务 / 前沿探索5.2 我的选型建议如果团队从零开始搭推荐系统没有历史包袱我第一推荐路线二。多任务联合框架成熟、资料多、坑也已经被很多人踩过了而且线上系统还是可以按“召回通道排序通道”组织不会给工程团队带来认知负担。如果团队已经有很重的存量系统精排模型很成熟只想让召回变得更好我推荐路线一。改动小、见效快风险也可控。蒸馏让召回学排序偏好这个思路尤其适合在召回侧快速验证。如果团队是想做技术护城河、或者业务形态本身就很像“内容生成”小说、短视频、商品推荐流可以花钱花人去预研路线三。但一定要把它当预研项目去管理而不是直接定线上指标。我自己见过太多团队一上来就想用生成式推荐替代老链路结果模型在离线指标上很漂亮一上AB就被线上延迟和稳定性教做人。5.3 绕不开的六个坑最后分享六条来自实战的踩坑经验希望你们能少走弯路。第一统一模型上线必须留新老链路并行AB窗口至少跑两个完整的业务周期包括周末峰值和大型活动日不要只看两三天的AUC或GMV变化。不同模型对真实反馈的敏感周期不一样短窗口容易被噪声带偏。第二正负样本比例要特别小心。召回任务的负样本极大排序任务的正样本极少合并成一个模型后如果权重配比不当模型会直接退化成一个“什么都觉得不相关”的保守模型。我给过一个原则排序损失和召回损失的数值量级要scale到同一水平一般为11到11.5再根据线上做小范围调参。第三蒸馏信号的温度系数不要拍脑袋设。温度过高召回分布趋近于均匀温度过低召回分布几乎变成hard label每次都学排序模型的top 1导致召回多样性断崖式下降。通常设在0.5到1之间稳定性更好。第四别把特征无脑全塞给多任务模型。排序任务能用的强特征如item在某策略下的历史点击率不见得对召回任务有帮助甚至可能让门控网络过拟合这些记忆性特征。特征要分层、分流让门控自己选择可能更稳。第五生成式路线别忽略负反馈建模。我一开始做路线三时只用了正样本序列生成出来的列表越看越像“同质化内容大赏”。后来把反馈行为分级建模滑动、点击、完整观看、不感兴趣并显式把“最近一次不感兴趣”的信号作为负上下文传给模型多样性才有明显提升。第六最容易被忽略的一点统一模型不等于不需要特征体系。恰恰相反它需要一套更干净、更一致的特征分层体系。如果你们现在的特征服务还是一团乱麻一个特征好几个口径别急着换模型结构先把特征治理好否则无论哪条路线都只是在一个糟糕地基上盖新楼。我个人在实际操作中的体会是统一召回与排序不是一道“用哪个模型结构”的选择题而是一道“先想清楚业务目标再动手”的工程题。路线一教召回学会排序的偏好路线二让两个目标共享一套表征路线三彻底打碎原有的“召回-排序”二元框架。这三条路线不是替代关系更像不同成熟度的解题思路。如果让我给一个最朴素的建议老系统渐进改造走路线一新系统从零搭建直接上路线二有余力、业务匹配、团队硬核再去钻研路线三。排序这件事说到底是对用户意图的深度理解而统一的目的从来不是单纯地删代码减模型而是让信息在链路里流得更干净、更完整。
![【GATT】规范精讲[12]: GATT 的 BR/EDR 名片——SDP 记录里藏着哪条通道](http://pic.xiahunao.cn/yaotu/【GATT】规范精讲[12]: GATT 的 BR/EDR 名片——SDP 记录里藏着哪条通道)
