1. 项目概述从“货找人”到“人找货”的社区推荐挑战在电商平台推荐系统的核心逻辑是“货找人”——基于用户的历史行为精准预测其购买意向把商品推给最可能下单的人。但在得物这样的潮流社区事情变得复杂得多。用户来这里不只是为了买东西更是为了“逛”、为了“看”、为了获取潮流资讯、参与话题讨论、甚至只是欣赏穿搭。这里的“货”不仅是商品更是内容一篇球鞋评测、一张穿搭街拍、一个热门话题。因此得物社区的推荐系统其核心任务从单一的“促成交易”演变为“提升社区活跃与用户留存”这是一个典型的“人找货”与“货找人”混合的场景。精排模型作为推荐系统链路中离用户最近、最精细的一环承担着从海量候选内容由召回和粗排筛选后中精准预估用户对每一个内容“感兴趣程度”的重任。这个“感兴趣程度”在电商场景下通常被量化为点击率CTR但在社区场景下单一指标远远不够。用户可能“点赞”一篇深度评测但不“评论”可能“收藏”一套穿搭但暂时不“购买”也可能仅仅“完播”一个短视频就获得了满足感。因此得物社区精排模型的演进史本质上是一部如何更全面、更细腻地理解并量化用户在社区内复杂行为意图的历史。我作为推荐算法方向的从业者经历过从经典CTR模型到如今复杂多目标、多场景建模的完整周期。这次我想结合得物社区的业务特点拆解其精排模型演进背后的核心逻辑、技术选型的得失以及那些在论文和公开分享里不会写的“踩坑”实录。无论你是刚入行的推荐算法工程师还是对社区产品技术架构感兴趣的产品经理相信都能从中看到一些共通的挑战与解法。2. 演进第一阶段经典CTR模型的引入与局限当社区推荐开始系统化时最直接的需求就是提升内容的点击率。毕竟点击是任何交互的开始。因此早期模型架构的选择非常务实直接引入在电商领域被验证有效的经典CTR预估模型。2.1 模型选型DeepFM 为何成为起点在众多模型中DeepFM 成为了一个非常自然的起点。它并非最复杂的但它的设计哲学完美契合了社区推荐早期的数据特征和工程约束。核心结构解析DeepFM 由两部分组成FMFactorization Machine部分和 Deep 部分。FM部分擅长处理高维稀疏特征如用户ID、内容ID、品类标签的二阶组合交互。例如它能自动学习到“喜欢球鞋内容的男性用户”与“AJ1新款发售资讯”这个组合特征的重要性而不需要人工设计这样的交叉特征。这对于社区初期标签体系尚不完善、特征工程能力有限的阶段来说是一个巨大的效率提升。Deep部分一个标准的前馈神经网络用于学习高阶的特征组合和深层的非线性关系。它可以处理一些连续值特征如用户活跃度得分、内容热度值以及经过Embedding后的稀疏特征。为什么是DeepFM而不是单纯的FM或DNN工程与效果的平衡单纯的FM模型对于高阶特征组合能力弱而单纯的DNN模型在稀疏特征交互上效率不高容易“遗忘”重要的低频特征组合。DeepFM的“宽与深”结合在保证了对关键稀疏特征进行显式、低阶建模的同时又具备了强大的深层泛化能力。特征处理友好社区初期的特征类型相对简单主要是用户画像性别、年龄、兴趣标签、内容属性发布者、品类、标签和上下文时间、位置。DeepFM对这些特征的处理非常直接无需复杂的预处理。注意在模型上线初期我们曾尝试过更复杂的PNNProduct-based Neural Network或xDeepFM但发现其带来的微小效果提升无法抵消其训练和推理时显著增加的复杂度。在业务快速验证阶段模型的“性价比”和稳定性往往是更优先的考量。2.2 特征体系构建社区与电商的差异虽然模型是现成的但特征工程必须从头开始并且要深刻理解社区场景的特殊性。用户侧特征静态画像年龄、性别、注册渠道。这些是基础但效力有限。动态兴趣这是核心。我们基于用户短期最近7天和长期历史所有的交互行为点击、点赞、收藏、关注构建其兴趣标签向量。例如一个用户近期频繁点击“露营”相关内容其“户外”兴趣权重就会动态升高。社区活跃度日均发帖数、评论数、点赞数、在线时长。这用于区分“内容消费者”和“内容创作者”两者的推荐策略应有差异。内容侧特征内容本体文本标题、正文通过BERT等模型提取的Embedding图片通过CV模型提取的多标签风格、颜色、是否有明星同款等。内容元信息发布者影响力等级、所属圈子如“球鞋”、“穿搭”、“潮玩”、人工打标的优质标签。实时热度发布后一段时间内的曝光、点击、互动点赞、评论、分享速率。这是社区内容生命周期短、爆发性强的关键特征。上下文特征时间小时、工作日/周末。例如晚上8点后短视频和轻松图文的内容权重可能更高。场景用户是来自“关注”页、“推荐”页还是“搜索”后的推荐流。不同场景的用户意图明确性不同。与电商的差异点电商的特征更侧重于“商品”属性价格、品牌、销量、库存和明确的“交易”意图加购、下单。社区的特征则更侧重于“内容”的泛兴趣属性和“互动”意图且实时性要求极高。一条热门动态的生命周期可能只有几小时这就要求特征 pipeline 的延迟必须极低。2.3 遇到的瓶颈与反思经典CTR模型在社区跑了一段时间后瓶颈迅速显现目标单一化陷阱我们优化CTR模型就疯狂学习“标题党”和“封面党”的特征。点击率上去了但用户停留时长、互动深度、长期留存却可能下降。模型学会了“欺骗”点击而不是提供真实价值。生态健康度受损一味追求CTR会导致低质、擦边球内容获得过高曝光挤压优质创作者的空间破坏社区氛围。“点击”不等于“满意”在社区很多点击是“误点击”或“浅层好奇”用户看完即走甚至产生负面反馈快速划走、点“不感兴趣”。单一的CTR指标无法捕捉这种复杂的用户满意度。这个阶段给我们的核心教训是在社区推荐中你优化什么指标就会得到什么结果。用一个有缺陷的单一目标去驱动系统必然导致系统行为扭曲。是时候引入多目标建模了。3. 演进第二阶段多目标建模的探索与实践为了解决单一CTR目标的局限性我们进入了多目标建模阶段。其核心思想是同时预估用户对内容的多种反馈如点击、点赞、评论、分享、完播、停留时长并综合这些预估值进行排序。3.1 多目标模型的核心架构ESMM 与 MMoE我们并没有一开始就设计最复杂的模型而是遵循了从简到繁的迭代路径。第一步ESMMEntire Space Multi-Task Model我们首先引入ESMM来解决CTR与CVR转化率预估中的样本选择偏差问题。在社区场景下我们可以将其类比为“点击率”和“深度互动率”如点击后的点赞/评论率。原理ESMM通过“CTR”和“CTCVR”点击且转化率两个任务来间接学习“CVR”。它利用全空间样本所有曝光来训练CTR任务避免了传统CVR模型只用点击样本训练带来的数据偏差。我们的应用我们将主任务设为pCTR点击率辅助任务设为pCTIR点击且互动率。模型结构上底层共享特征Embedding上层有两个塔分别对应两个任务。最终排序分可以用pCTR * pCTIR来近似衡量用户点击并进行深度互动的概率。效果与局限ESMM结构简单易于实现和上线确实在一定程度上缓解了“高点击低互动”的问题。但它本质上仍是学习两个强相关目标对于“点击”、“点赞”、“分享”这些可能相互竞争或关联较弱的目标建模能力不足。第二步MMoEMulti-gate Mixture-of-Experts当我们需要同时优化3个及以上目标时MMoE成为了更合适的选择。原理MMoE设计了多个“专家”网络每个专家都是一个前馈神经网络。同时为每一个目标任务配备一个“门控网络”。门控网络学习根据当前输入样本动态地为该任务分配各个专家的权重。这样不同任务可以共享一部分专家共享知识也可以专注于不同的专家独有知识。我们的具体实现专家我们设置了4个专家网络每个专家是一个2层MLP。任务我们定义了4个核心目标点击、点赞、评论、有效停留时长是否大于15秒。门控网络每个任务对应一个门控网络输入是共享的Embedding层输出输出是4个专家的权重分布。模型结构示意图描述性 输入层特征Embedding - 共享层 - 【专家1 专家2 专家3 专家4】- - 任务1门控 - 加权融合专家输出 - 任务1塔 - 输出pCTR - 任务2门控 - 加权融合专家输出 - 任务2塔 - 输出pLike - 任务3门控 - 加权融合专家输出 - 任务3塔 - 输出pComment - 任务4门控 - 加权融合专家输出 - 任务4塔 - 输出pEffectiveView3.2 多目标损失函数设计与调参艺术模型结构搭好了但让多个目标和谐共处才是真正的挑战。这主要靠损失函数的设计和精细调参。1. 损失函数加权求和还是动态调整最常用的方法是加权求和总损失 w1 * Loss_CTR w2 * Loss_Like w3 * Loss_Comment ...这里的权重w1, w2, w3就是调参的关键。初期我们根据业务重要性手动设置例如点击权重0.5点赞0.3评论0.2。但这带来了问题不同目标损失的数值尺度Magnitude可能差异巨大例如CTR损失可能常年是0.1而评论损失是0.01导致模型主要被大数值的目标所主导。我们的解决方案损失归一化在计算加权和之前先对每个任务的损失进行归一化例如除以该任务损失近一段时间的移动平均值让所有损失处于相近的量级。GradNorm 动态权重我们尝试了更先进的GradNorm方法。其核心思想是动态调整权重使得不同任务训练时的梯度幅度Norm相近。这样可以自动平衡不同任务的学习速度。实现后我们发现模型收敛更稳定无需频繁手动调整权重。2. 样本权重与负样本定义多目标下样本的权重也变得复杂。一次曝光用户可能同时产生点击和点赞也可能只点击也可能无任何动作。我们这样处理每个目标独立构造正负样本。对于“点赞”任务只有有点击行为且点赞的样本才是正样本有点击但未点赞的为负样本无点击的样本不参与“点赞”任务损失计算通过样本权重为0实现。这样可以避免未曝光内容对互动类任务的噪声干扰。实操心得多目标上线初期的“跷跷板”现象首次上线MMoE模型时我们观察到一个典型现象点赞率、评论率显著提升但点击率轻微下降。这未必是坏事它可能意味着模型不再盲目追求“诱点击”而是找到了更能引发深度互动的内容。此时切勿盲目调高CTR的损失权重把指标拉回去。正确的做法是结合业务综合指标如人均互动次数、留存率来评估。如果综合指标上升说明模型优化方向正确应该给予它时间学习。我们当时稳住了权重一周后CTR指标也逐步回升并超过了基线模型学会了同时优化多个目标。3.3 线上线下指标对齐的挑战多目标模型最大的陷阱在于线上A/B测试的结果可能和离线评估不一致。离线评估我们通常用AUC、GAUC来评估每个目标预估的准确性。线上评估我们关心的是最终融合排序后的结果比如整体CTR、互动率、留存率。我们设计了一个多目标融合打分公式排序分 pCTR^α * pLike^β * pComment^γ * pEffectiveView^δ。这里的指数 α, β, γ, δ 是超参数用于控制不同目标的权重。如何调优这些融合权重离线仿真在离线测试集上尝试不同的权重组合模拟排序计算综合指标如加权和0.4CTR 0.3LikeRate 0.2CommentRate 0.1EffectiveViewRate。选择综合指标最高的组合。小流量实验将离线选出的Top 3组权重分别部署到线上1%的流量进行A/B测试用真实的用户行为验证。分析“帕累托前沿”我们将不同实验组的结果画在二维图上例如CTR vs. Like Rate。那些无法在提升一个指标的同时不损害另一个指标的实验组就构成了“帕累托前沿”。业务决策者可以在这个前沿上选择最符合当前阶段战略的平衡点例如当前优先拉互动就选择互动率最高的点。这个过程充满了博弈也是算法与产品、运营沟通最密集的环节。它让我们明白多目标建模不仅是技术问题更是业务目标的数学化表达。4. 演进第三阶段场景化与个性化精排当多目标模型成为基础能力后我们面临新的问题一个全局统一的模型能否满足所有用户在所有场景下的需求答案是否定的。于是场景化与个性化精排成为演进的新方向。4.1 为何需要场景化建模“场景”在这里指用户使用产品的不同入口和状态。主要分为两大类页面场景首页推荐流用户意图最模糊兴趣最发散需要探索与满足并存。关注流用户意图明确希望看到关注创作者的更新。模型应极度强化“发布者”特征弱化其他兴趣探索。搜索后推荐用户意图非常明确由搜索Query表达。精排模型需要与搜索Query进行强关联。内容详情页相关推荐用户对当前内容感兴趣推荐相似内容。模型应强化内容本身的相似度计算。用户状态场景新用户/冷启动特征稀少需要快速捕捉其初始点击行为偏向热门、大众化内容。老用户/活跃用户特征丰富可以进行深度兴趣挖掘和长尾内容探索。疲劳状态用户连续多次快速划走负反馈。模型需要临时引入“疲劳度”特征主动降低相似内容的权重增加多样性。用一个全局模型处理所有场景相当于让一个医生同时看内科、外科、儿科效果必然打折。场景化建模的核心思想是为不同的场景定制不同的模型或者在一个大模型内显式地区分场景。4.2 技术实现多塔结构与场景特征我们采用了“共享底层 场景独立塔”的架构可以理解为MMoE思想在场景维度的延伸。共享底层所有场景共享同一个庞大的特征Embedding层和几层共享的DNN。这部分学习通用的特征表示是模型的“基础知识库”。场景门控与独立塔为每个主要场景如首页推荐、关注流设置一个独立的“场景门控”和一个小型DNN塔。场景门控的输入是场景ID的Embedding以及一些场景特有的上下文特征如是否来自搜索、搜索词Embedding。在训练时每条样本都带有场景标签。前向传播时数据会流过共享底层然后根据其场景标签被路由到对应的场景门控和独立塔进行计算其他场景的塔对该样本的梯度不更新。在推理时根据请求所在的场景调用对应的场景塔进行预测。场景特征举例对于“搜索后推荐”场景我们将用户的搜索词经过BERT编码后的向量作为一个强特征输入到该场景的独立塔中。对于“关注流”场景我们大幅提高“发布者ID”以及“用户-发布者关系”是否关注、历史互动频次等特征的Embedding维度和塔内权重。4.3 个性化从“千人一面”到“千人千模”场景化是粗粒度的划分更极致的追求是真正的个性化——为每个用户适配其独有的模型微调。但这在工程上几乎是不可行的。我们退而求其次实现了“用户分群 个性化参数”的策略。用户分群建模我们利用聚类算法如K-means on user embedding将用户划分为多个群体如“硬核球鞋玩家”、“潮流穿搭爱好者”、“泛娱乐浏览者”。在模型结构上这与场景化类似。我们可以为每个核心用户群体设置一个独立的“群体塔”或者在MMoE中将“用户群体ID”作为一个重要的特征输入门控网络让模型学习到不同群体对专家权重的不同偏好。实时个性化干预模型预估是离线的或近线的分钟级。为了应对用户的实时兴趣变化我们引入了“实时干预层”。系统实时监控用户Session内的行为序列最近20次交互。如果发现连续对某一类内容产生正反馈点赞、长停留则对该类内容的排序分进行临时加权。反之对连续负反馈的内容类别进行降权。这相当于在精排模型的静态打分基础上增加了一个动态的、基于短期会话的调整因子使推荐结果更具时效性和灵敏性。踩坑实录场景化模型的“冷启动”与“跷跷板”当我们首次拆分首页模型和关注流模型时关注流模型的效果提升明显但首页模型的主要指标却出现了下滑。排查后发现两个问题1)数据不均衡首页样本量远大于关注流训练时首页场景主导了共享底层的更新反而损害了其特异性。我们通过采样或对关注流样本增加损失权重来解决。2)共享与独立的权衡初期独立塔设计得过于复杂层数多、参数多导致在首页数据上过拟合泛化能力下降。后来我们调整为“大共享小独立”的策略即共享层做大部分工作独立塔仅做轻量的场景特异性调整效果更稳健。5. 模型迭代中的工程实践与避坑指南精排模型的演进不仅仅是算法模型的升级更是一场对数据、工程、算力的全面考验。以下是一些关键的工程实践和容易踩的坑。5.1 特征平台与实时管道建设“垃圾进垃圾出”。没有高质量、高效率的特征再先进的模型也是空中楼阁。特征仓库我们建立了统一的特征仓库管理所有用户、内容、上下文特征的定义、生成逻辑和生命周期。确保离线训练和在线推理使用的特征完全一致避免线上线下不一致的灾难性问题。实时特征计算对于“用户最近1小时点击的品类”、“内容实时点击率”这类特征我们依赖Flink流计算引擎进行实时计算写入Redis或特征数据库保证精排模型能用到秒级新鲜的特征。特征监控这是血泪教训。我们曾因为一个特征生成Job的延迟导致连续3天线上模型使用了“过期”的用户兴趣标签推荐效果大幅下跌。现在我们对关键特征的产出延迟、分布变化如均值、方差突变进行严格监控和报警。5.2 模型训练与部署的稳定性分布式训练随着模型参数和样本量的激增多目标、多场景模型参数可达数亿单机训练已不现实。我们转向使用TensorFlow Distributed Strategy或PyTorch DDP进行分布式训练。这里的关键是数据并行下的梯度同步效率以及如何处理好Embedding Table的巨大通信开销。在线推理优化模型轻量化上线前对模型进行剪枝、量化在保证精度损失可控1%的前提下大幅减少模型体积和推理延迟。服务化与缓存将模型封装为高性能的gRPC服务。对于热门内容和用户对其模型预估结果进行短时间缓存减少重复计算。流量回放与影子测试任何新模型上线前都会先用线上真实流量进行“影子测试”即模型并行计算但不影响线上结果对比新老模型的预估分数分布提前发现异常。5.3 效果评估的复杂性精排模型的评估是一个系统工程绝不能只看离线AUC。离线评估分场景/分人群评估全局AUC高不代表在所有细分场景下都好。必须拆分评估。多目标一致性检查多个目标预估的AUC是否同步提升。如果只有一个目标AUC提升而其他下降需要警惕。在线A/B测试核心指标CTR、互动率、人均停留时长、留存率次留、7留。护栏指标内容多样性推荐内容品类数、创作者生态中长尾创作者曝光占比、负反馈率“不感兴趣”点击率。长期观察有些模型短期指标上涨但长期会使用户兴趣收窄信息茧房导致留存下降。因此重要的模型实验需要观察至少2-4周的长期留存数据。5.4 常见问题排查清单当线上推荐效果出现波动时可以按以下清单快速排查问题现象可能原因排查方向整体CTR/互动率突然下跌1. 特征数据延迟或异常2. 模型服务异常或版本错误3. 内容池出现大量低质内容1. 检查特征Pipeline监控看关键特征是否准时产出、数值是否异常。2. 检查模型服务日志确认加载的模型版本是否正确推理耗时是否激增。3. 分析曝光内容的质量分布检查内容审核或打标系统是否异常。某个场景如关注流效果变差其他正常1. 该场景专属特征出现问题2. 该场景独立塔模型更新失败或污染1. 检查该场景的专属特征如关注关系数据源。2. 检查该场景模型的训练样本是否混入了大量其他场景噪声数据。新用户/冷启动效果差1. 新用户特征缺失或默认值不合理2. 冷启动模型策略未生效1. 检查新用户画像补全逻辑。2. 确认流量是否正确路由到了冷启动模型或策略分支。模型离线AUC高但线上效果不显著甚至为负1. 线上线下特征不一致2. 样本穿越使用未来信息3. 线上融合排序公式参数设置不当1. 进行线上请求数据回放用离线模型重新预估对比分数差异。2. 严格检查特征生成逻辑确保训练时只用到了历史信息。3. 检查多目标融合权重的设置是否与离线仿真时一致。精排模型的演进之路没有终点。从DeepFM到多目标MMoE再到场景化、个性化每一次升级都是对业务理解更深一层的体现。技术是为业务目标服务的最复杂的模型不一定是最好的最适合当前业务发展阶段和数据现状的模型才是。未来我们还在探索引入强化学习来优化长期用户价值利用多模态大模型更好地理解图文/视频内容以及应对因果推断解决推荐中的偏差问题。这条路很长但每一次让推荐更准一点让用户更满意一点都是对我们工作最好的回报。 从DeepFM到MMoE：社区推荐系统精排模型演进与工程实践
1. 项目概述从“货找人”到“人找货”的社区推荐挑战在电商平台推荐系统的核心逻辑是“货找人”——基于用户的历史行为精准预测其购买意向把商品推给最可能下单的人。但在得物这样的潮流社区事情变得复杂得多。用户来这里不只是为了买东西更是为了“逛”、为了“看”、为了获取潮流资讯、参与话题讨论、甚至只是欣赏穿搭。这里的“货”不仅是商品更是内容一篇球鞋评测、一张穿搭街拍、一个热门话题。因此得物社区的推荐系统其核心任务从单一的“促成交易”演变为“提升社区活跃与用户留存”这是一个典型的“人找货”与“货找人”混合的场景。精排模型作为推荐系统链路中离用户最近、最精细的一环承担着从海量候选内容由召回和粗排筛选后中精准预估用户对每一个内容“感兴趣程度”的重任。这个“感兴趣程度”在电商场景下通常被量化为点击率CTR但在社区场景下单一指标远远不够。用户可能“点赞”一篇深度评测但不“评论”可能“收藏”一套穿搭但暂时不“购买”也可能仅仅“完播”一个短视频就获得了满足感。因此得物社区精排模型的演进史本质上是一部如何更全面、更细腻地理解并量化用户在社区内复杂行为意图的历史。我作为推荐算法方向的从业者经历过从经典CTR模型到如今复杂多目标、多场景建模的完整周期。这次我想结合得物社区的业务特点拆解其精排模型演进背后的核心逻辑、技术选型的得失以及那些在论文和公开分享里不会写的“踩坑”实录。无论你是刚入行的推荐算法工程师还是对社区产品技术架构感兴趣的产品经理相信都能从中看到一些共通的挑战与解法。2. 演进第一阶段经典CTR模型的引入与局限当社区推荐开始系统化时最直接的需求就是提升内容的点击率。毕竟点击是任何交互的开始。因此早期模型架构的选择非常务实直接引入在电商领域被验证有效的经典CTR预估模型。2.1 模型选型DeepFM 为何成为起点在众多模型中DeepFM 成为了一个非常自然的起点。它并非最复杂的但它的设计哲学完美契合了社区推荐早期的数据特征和工程约束。核心结构解析DeepFM 由两部分组成FMFactorization Machine部分和 Deep 部分。FM部分擅长处理高维稀疏特征如用户ID、内容ID、品类标签的二阶组合交互。例如它能自动学习到“喜欢球鞋内容的男性用户”与“AJ1新款发售资讯”这个组合特征的重要性而不需要人工设计这样的交叉特征。这对于社区初期标签体系尚不完善、特征工程能力有限的阶段来说是一个巨大的效率提升。Deep部分一个标准的前馈神经网络用于学习高阶的特征组合和深层的非线性关系。它可以处理一些连续值特征如用户活跃度得分、内容热度值以及经过Embedding后的稀疏特征。为什么是DeepFM而不是单纯的FM或DNN工程与效果的平衡单纯的FM模型对于高阶特征组合能力弱而单纯的DNN模型在稀疏特征交互上效率不高容易“遗忘”重要的低频特征组合。DeepFM的“宽与深”结合在保证了对关键稀疏特征进行显式、低阶建模的同时又具备了强大的深层泛化能力。特征处理友好社区初期的特征类型相对简单主要是用户画像性别、年龄、兴趣标签、内容属性发布者、品类、标签和上下文时间、位置。DeepFM对这些特征的处理非常直接无需复杂的预处理。注意在模型上线初期我们曾尝试过更复杂的PNNProduct-based Neural Network或xDeepFM但发现其带来的微小效果提升无法抵消其训练和推理时显著增加的复杂度。在业务快速验证阶段模型的“性价比”和稳定性往往是更优先的考量。2.2 特征体系构建社区与电商的差异虽然模型是现成的但特征工程必须从头开始并且要深刻理解社区场景的特殊性。用户侧特征静态画像年龄、性别、注册渠道。这些是基础但效力有限。动态兴趣这是核心。我们基于用户短期最近7天和长期历史所有的交互行为点击、点赞、收藏、关注构建其兴趣标签向量。例如一个用户近期频繁点击“露营”相关内容其“户外”兴趣权重就会动态升高。社区活跃度日均发帖数、评论数、点赞数、在线时长。这用于区分“内容消费者”和“内容创作者”两者的推荐策略应有差异。内容侧特征内容本体文本标题、正文通过BERT等模型提取的Embedding图片通过CV模型提取的多标签风格、颜色、是否有明星同款等。内容元信息发布者影响力等级、所属圈子如“球鞋”、“穿搭”、“潮玩”、人工打标的优质标签。实时热度发布后一段时间内的曝光、点击、互动点赞、评论、分享速率。这是社区内容生命周期短、爆发性强的关键特征。上下文特征时间小时、工作日/周末。例如晚上8点后短视频和轻松图文的内容权重可能更高。场景用户是来自“关注”页、“推荐”页还是“搜索”后的推荐流。不同场景的用户意图明确性不同。与电商的差异点电商的特征更侧重于“商品”属性价格、品牌、销量、库存和明确的“交易”意图加购、下单。社区的特征则更侧重于“内容”的泛兴趣属性和“互动”意图且实时性要求极高。一条热门动态的生命周期可能只有几小时这就要求特征 pipeline 的延迟必须极低。2.3 遇到的瓶颈与反思经典CTR模型在社区跑了一段时间后瓶颈迅速显现目标单一化陷阱我们优化CTR模型就疯狂学习“标题党”和“封面党”的特征。点击率上去了但用户停留时长、互动深度、长期留存却可能下降。模型学会了“欺骗”点击而不是提供真实价值。生态健康度受损一味追求CTR会导致低质、擦边球内容获得过高曝光挤压优质创作者的空间破坏社区氛围。“点击”不等于“满意”在社区很多点击是“误点击”或“浅层好奇”用户看完即走甚至产生负面反馈快速划走、点“不感兴趣”。单一的CTR指标无法捕捉这种复杂的用户满意度。这个阶段给我们的核心教训是在社区推荐中你优化什么指标就会得到什么结果。用一个有缺陷的单一目标去驱动系统必然导致系统行为扭曲。是时候引入多目标建模了。3. 演进第二阶段多目标建模的探索与实践为了解决单一CTR目标的局限性我们进入了多目标建模阶段。其核心思想是同时预估用户对内容的多种反馈如点击、点赞、评论、分享、完播、停留时长并综合这些预估值进行排序。3.1 多目标模型的核心架构ESMM 与 MMoE我们并没有一开始就设计最复杂的模型而是遵循了从简到繁的迭代路径。第一步ESMMEntire Space Multi-Task Model我们首先引入ESMM来解决CTR与CVR转化率预估中的样本选择偏差问题。在社区场景下我们可以将其类比为“点击率”和“深度互动率”如点击后的点赞/评论率。原理ESMM通过“CTR”和“CTCVR”点击且转化率两个任务来间接学习“CVR”。它利用全空间样本所有曝光来训练CTR任务避免了传统CVR模型只用点击样本训练带来的数据偏差。我们的应用我们将主任务设为pCTR点击率辅助任务设为pCTIR点击且互动率。模型结构上底层共享特征Embedding上层有两个塔分别对应两个任务。最终排序分可以用pCTR * pCTIR来近似衡量用户点击并进行深度互动的概率。效果与局限ESMM结构简单易于实现和上线确实在一定程度上缓解了“高点击低互动”的问题。但它本质上仍是学习两个强相关目标对于“点击”、“点赞”、“分享”这些可能相互竞争或关联较弱的目标建模能力不足。第二步MMoEMulti-gate Mixture-of-Experts当我们需要同时优化3个及以上目标时MMoE成为了更合适的选择。原理MMoE设计了多个“专家”网络每个专家都是一个前馈神经网络。同时为每一个目标任务配备一个“门控网络”。门控网络学习根据当前输入样本动态地为该任务分配各个专家的权重。这样不同任务可以共享一部分专家共享知识也可以专注于不同的专家独有知识。我们的具体实现专家我们设置了4个专家网络每个专家是一个2层MLP。任务我们定义了4个核心目标点击、点赞、评论、有效停留时长是否大于15秒。门控网络每个任务对应一个门控网络输入是共享的Embedding层输出输出是4个专家的权重分布。模型结构示意图描述性 输入层特征Embedding - 共享层 - 【专家1 专家2 专家3 专家4】- - 任务1门控 - 加权融合专家输出 - 任务1塔 - 输出pCTR - 任务2门控 - 加权融合专家输出 - 任务2塔 - 输出pLike - 任务3门控 - 加权融合专家输出 - 任务3塔 - 输出pComment - 任务4门控 - 加权融合专家输出 - 任务4塔 - 输出pEffectiveView3.2 多目标损失函数设计与调参艺术模型结构搭好了但让多个目标和谐共处才是真正的挑战。这主要靠损失函数的设计和精细调参。1. 损失函数加权求和还是动态调整最常用的方法是加权求和总损失 w1 * Loss_CTR w2 * Loss_Like w3 * Loss_Comment ...这里的权重w1, w2, w3就是调参的关键。初期我们根据业务重要性手动设置例如点击权重0.5点赞0.3评论0.2。但这带来了问题不同目标损失的数值尺度Magnitude可能差异巨大例如CTR损失可能常年是0.1而评论损失是0.01导致模型主要被大数值的目标所主导。我们的解决方案损失归一化在计算加权和之前先对每个任务的损失进行归一化例如除以该任务损失近一段时间的移动平均值让所有损失处于相近的量级。GradNorm 动态权重我们尝试了更先进的GradNorm方法。其核心思想是动态调整权重使得不同任务训练时的梯度幅度Norm相近。这样可以自动平衡不同任务的学习速度。实现后我们发现模型收敛更稳定无需频繁手动调整权重。2. 样本权重与负样本定义多目标下样本的权重也变得复杂。一次曝光用户可能同时产生点击和点赞也可能只点击也可能无任何动作。我们这样处理每个目标独立构造正负样本。对于“点赞”任务只有有点击行为且点赞的样本才是正样本有点击但未点赞的为负样本无点击的样本不参与“点赞”任务损失计算通过样本权重为0实现。这样可以避免未曝光内容对互动类任务的噪声干扰。实操心得多目标上线初期的“跷跷板”现象首次上线MMoE模型时我们观察到一个典型现象点赞率、评论率显著提升但点击率轻微下降。这未必是坏事它可能意味着模型不再盲目追求“诱点击”而是找到了更能引发深度互动的内容。此时切勿盲目调高CTR的损失权重把指标拉回去。正确的做法是结合业务综合指标如人均互动次数、留存率来评估。如果综合指标上升说明模型优化方向正确应该给予它时间学习。我们当时稳住了权重一周后CTR指标也逐步回升并超过了基线模型学会了同时优化多个目标。3.3 线上线下指标对齐的挑战多目标模型最大的陷阱在于线上A/B测试的结果可能和离线评估不一致。离线评估我们通常用AUC、GAUC来评估每个目标预估的准确性。线上评估我们关心的是最终融合排序后的结果比如整体CTR、互动率、留存率。我们设计了一个多目标融合打分公式排序分 pCTR^α * pLike^β * pComment^γ * pEffectiveView^δ。这里的指数 α, β, γ, δ 是超参数用于控制不同目标的权重。如何调优这些融合权重离线仿真在离线测试集上尝试不同的权重组合模拟排序计算综合指标如加权和0.4CTR 0.3LikeRate 0.2CommentRate 0.1EffectiveViewRate。选择综合指标最高的组合。小流量实验将离线选出的Top 3组权重分别部署到线上1%的流量进行A/B测试用真实的用户行为验证。分析“帕累托前沿”我们将不同实验组的结果画在二维图上例如CTR vs. Like Rate。那些无法在提升一个指标的同时不损害另一个指标的实验组就构成了“帕累托前沿”。业务决策者可以在这个前沿上选择最符合当前阶段战略的平衡点例如当前优先拉互动就选择互动率最高的点。这个过程充满了博弈也是算法与产品、运营沟通最密集的环节。它让我们明白多目标建模不仅是技术问题更是业务目标的数学化表达。4. 演进第三阶段场景化与个性化精排当多目标模型成为基础能力后我们面临新的问题一个全局统一的模型能否满足所有用户在所有场景下的需求答案是否定的。于是场景化与个性化精排成为演进的新方向。4.1 为何需要场景化建模“场景”在这里指用户使用产品的不同入口和状态。主要分为两大类页面场景首页推荐流用户意图最模糊兴趣最发散需要探索与满足并存。关注流用户意图明确希望看到关注创作者的更新。模型应极度强化“发布者”特征弱化其他兴趣探索。搜索后推荐用户意图非常明确由搜索Query表达。精排模型需要与搜索Query进行强关联。内容详情页相关推荐用户对当前内容感兴趣推荐相似内容。模型应强化内容本身的相似度计算。用户状态场景新用户/冷启动特征稀少需要快速捕捉其初始点击行为偏向热门、大众化内容。老用户/活跃用户特征丰富可以进行深度兴趣挖掘和长尾内容探索。疲劳状态用户连续多次快速划走负反馈。模型需要临时引入“疲劳度”特征主动降低相似内容的权重增加多样性。用一个全局模型处理所有场景相当于让一个医生同时看内科、外科、儿科效果必然打折。场景化建模的核心思想是为不同的场景定制不同的模型或者在一个大模型内显式地区分场景。4.2 技术实现多塔结构与场景特征我们采用了“共享底层 场景独立塔”的架构可以理解为MMoE思想在场景维度的延伸。共享底层所有场景共享同一个庞大的特征Embedding层和几层共享的DNN。这部分学习通用的特征表示是模型的“基础知识库”。场景门控与独立塔为每个主要场景如首页推荐、关注流设置一个独立的“场景门控”和一个小型DNN塔。场景门控的输入是场景ID的Embedding以及一些场景特有的上下文特征如是否来自搜索、搜索词Embedding。在训练时每条样本都带有场景标签。前向传播时数据会流过共享底层然后根据其场景标签被路由到对应的场景门控和独立塔进行计算其他场景的塔对该样本的梯度不更新。在推理时根据请求所在的场景调用对应的场景塔进行预测。场景特征举例对于“搜索后推荐”场景我们将用户的搜索词经过BERT编码后的向量作为一个强特征输入到该场景的独立塔中。对于“关注流”场景我们大幅提高“发布者ID”以及“用户-发布者关系”是否关注、历史互动频次等特征的Embedding维度和塔内权重。4.3 个性化从“千人一面”到“千人千模”场景化是粗粒度的划分更极致的追求是真正的个性化——为每个用户适配其独有的模型微调。但这在工程上几乎是不可行的。我们退而求其次实现了“用户分群 个性化参数”的策略。用户分群建模我们利用聚类算法如K-means on user embedding将用户划分为多个群体如“硬核球鞋玩家”、“潮流穿搭爱好者”、“泛娱乐浏览者”。在模型结构上这与场景化类似。我们可以为每个核心用户群体设置一个独立的“群体塔”或者在MMoE中将“用户群体ID”作为一个重要的特征输入门控网络让模型学习到不同群体对专家权重的不同偏好。实时个性化干预模型预估是离线的或近线的分钟级。为了应对用户的实时兴趣变化我们引入了“实时干预层”。系统实时监控用户Session内的行为序列最近20次交互。如果发现连续对某一类内容产生正反馈点赞、长停留则对该类内容的排序分进行临时加权。反之对连续负反馈的内容类别进行降权。这相当于在精排模型的静态打分基础上增加了一个动态的、基于短期会话的调整因子使推荐结果更具时效性和灵敏性。踩坑实录场景化模型的“冷启动”与“跷跷板”当我们首次拆分首页模型和关注流模型时关注流模型的效果提升明显但首页模型的主要指标却出现了下滑。排查后发现两个问题1)数据不均衡首页样本量远大于关注流训练时首页场景主导了共享底层的更新反而损害了其特异性。我们通过采样或对关注流样本增加损失权重来解决。2)共享与独立的权衡初期独立塔设计得过于复杂层数多、参数多导致在首页数据上过拟合泛化能力下降。后来我们调整为“大共享小独立”的策略即共享层做大部分工作独立塔仅做轻量的场景特异性调整效果更稳健。5. 模型迭代中的工程实践与避坑指南精排模型的演进不仅仅是算法模型的升级更是一场对数据、工程、算力的全面考验。以下是一些关键的工程实践和容易踩的坑。5.1 特征平台与实时管道建设“垃圾进垃圾出”。没有高质量、高效率的特征再先进的模型也是空中楼阁。特征仓库我们建立了统一的特征仓库管理所有用户、内容、上下文特征的定义、生成逻辑和生命周期。确保离线训练和在线推理使用的特征完全一致避免线上线下不一致的灾难性问题。实时特征计算对于“用户最近1小时点击的品类”、“内容实时点击率”这类特征我们依赖Flink流计算引擎进行实时计算写入Redis或特征数据库保证精排模型能用到秒级新鲜的特征。特征监控这是血泪教训。我们曾因为一个特征生成Job的延迟导致连续3天线上模型使用了“过期”的用户兴趣标签推荐效果大幅下跌。现在我们对关键特征的产出延迟、分布变化如均值、方差突变进行严格监控和报警。5.2 模型训练与部署的稳定性分布式训练随着模型参数和样本量的激增多目标、多场景模型参数可达数亿单机训练已不现实。我们转向使用TensorFlow Distributed Strategy或PyTorch DDP进行分布式训练。这里的关键是数据并行下的梯度同步效率以及如何处理好Embedding Table的巨大通信开销。在线推理优化模型轻量化上线前对模型进行剪枝、量化在保证精度损失可控1%的前提下大幅减少模型体积和推理延迟。服务化与缓存将模型封装为高性能的gRPC服务。对于热门内容和用户对其模型预估结果进行短时间缓存减少重复计算。流量回放与影子测试任何新模型上线前都会先用线上真实流量进行“影子测试”即模型并行计算但不影响线上结果对比新老模型的预估分数分布提前发现异常。5.3 效果评估的复杂性精排模型的评估是一个系统工程绝不能只看离线AUC。离线评估分场景/分人群评估全局AUC高不代表在所有细分场景下都好。必须拆分评估。多目标一致性检查多个目标预估的AUC是否同步提升。如果只有一个目标AUC提升而其他下降需要警惕。在线A/B测试核心指标CTR、互动率、人均停留时长、留存率次留、7留。护栏指标内容多样性推荐内容品类数、创作者生态中长尾创作者曝光占比、负反馈率“不感兴趣”点击率。长期观察有些模型短期指标上涨但长期会使用户兴趣收窄信息茧房导致留存下降。因此重要的模型实验需要观察至少2-4周的长期留存数据。5.4 常见问题排查清单当线上推荐效果出现波动时可以按以下清单快速排查问题现象可能原因排查方向整体CTR/互动率突然下跌1. 特征数据延迟或异常2. 模型服务异常或版本错误3. 内容池出现大量低质内容1. 检查特征Pipeline监控看关键特征是否准时产出、数值是否异常。2. 检查模型服务日志确认加载的模型版本是否正确推理耗时是否激增。3. 分析曝光内容的质量分布检查内容审核或打标系统是否异常。某个场景如关注流效果变差其他正常1. 该场景专属特征出现问题2. 该场景独立塔模型更新失败或污染1. 检查该场景的专属特征如关注关系数据源。2. 检查该场景模型的训练样本是否混入了大量其他场景噪声数据。新用户/冷启动效果差1. 新用户特征缺失或默认值不合理2. 冷启动模型策略未生效1. 检查新用户画像补全逻辑。2. 确认流量是否正确路由到了冷启动模型或策略分支。模型离线AUC高但线上效果不显著甚至为负1. 线上线下特征不一致2. 样本穿越使用未来信息3. 线上融合排序公式参数设置不当1. 进行线上请求数据回放用离线模型重新预估对比分数差异。2. 严格检查特征生成逻辑确保训练时只用到了历史信息。3. 检查多目标融合权重的设置是否与离线仿真时一致。精排模型的演进之路没有终点。从DeepFM到多目标MMoE再到场景化、个性化每一次升级都是对业务理解更深一层的体现。技术是为业务目标服务的最复杂的模型不一定是最好的最适合当前业务发展阶段和数据现状的模型才是。未来我们还在探索引入强化学习来优化长期用户价值利用多模态大模型更好地理解图文/视频内容以及应对因果推断解决推荐中的偏差问题。这条路很长但每一次让推荐更准一点让用户更满意一点都是对我们工作最好的回报。