生鲜电商级联生成推荐框架：融合微观画像与宏观主题

打破部门孤岛某头部生鲜电商级联生成推荐框架重构前台微观画像与宏观主题融合先说个事。我所在的团队花了将近一个季度给某头部生鲜电商平台下文用“I平台”代称做了一个新的推荐框架。项目代号叫“一本万利”正式一点的说法是“级联生成推荐框架”。这个项目解决了一个我忍了很久的问题推荐系统里的“部门孤岛”。相信很多做电商推荐的同学都有同感。我们的推荐分了很多叶子类目和叶子部门乳制品、肉禽、冻品、零食、日百……每个部门各自为战。用户上午在乳制品部门看了一圈加购了牛奶下午打开首页推荐流里大概率还是那几瓶牛奶相关的商品他不会收到酸奶、坚果、麦片哪怕他上个月刚买过。你说用户不想买吗不是是系统根本没有把“部门”和“部门”之间的关联打通。单个用户是一个孤岛单个部门也是一个孤岛推荐结果自然就缺了“全局感”。这个框架的核心理念是用“级联生成”的方式把前台的微观画像用户此刻想要什么、这个商品和什么搭配和宏观主题本周全站主打什么场景、什么季节商品在上升期拼到同一个决策链路里。效果立竿见影首页推荐位的客单价平均提升了不少购物篮从“11”变成了“13”连带率涨得很明显。这篇文章把我从设计到落地的完整过程、踩过的坑、以及最终线上稳定运行的框架结构从头到尾梳理一遍。里面涉及的技术点有序列建模、双塔召回、主题挖掘、两阶段级联排序也有大量工程侧的教训。想直接抄作业的建议重点看第4节和最后的避坑清单。1. 项目全貌为什么推荐系统不能继续“各显神通”1.1 部门孤岛的代价推荐系统最大的隐性损失我先给不熟悉业务背景的同学补个场景。生鲜电商和标品电商最大的区别是购物篮宽度的战略价值远大于单品转化率。用户今天买一盒草莓如果他顺手又加购了酸奶、燕麦脆和沙拉酱这一单的毛利可能翻两倍。而现实是用户看了草莓以后系统只知道“用户对草莓感兴趣”于是继续推草莓、蓝莓、樱桃……不会把“草莓”放进“周末轻食早餐”这个场景里去理解。传统分层推荐结构也就是常见的召回粗排精排是有天然缺陷的类目/部门这一层往往是被硬编码进特征的比如离线算用户在每个部门的活跃度然后在线按比例分配候选池。这种方式有三个致命问题候选生成完全跟着历史行为走用户没有买过的东西、没逛过的部门几乎永远进不了候选池部门之间的商品关系被切断了做不了“酸奶麦片”这类跨部门强关联推荐全站运营节奏比如火锅季、烧烤季、开学季很难传导给个性化模型运营只能靠手动改图、改入口无法实时影响排序。我们当时看了一个调研数据——大约40%的用户购物篮里只被推荐到了一个部门的商品。这意味着推荐系统本质上没有在“帮用户组一个篮子”只是在“把用户可能点一下的商品摆到他面前”。问题是用户点什么和用户这单想吃什么是两码事。1.2 级联生成式框架的设计取舍为什么不是纯召回也不是纯重排我对业界这两年“生成式推荐”的讨论一直有关注但说实话纯粹用一个大模型从零生成整个推荐列表在线上不太现实。生成结果不够稳定延迟压不下来而且没法精细地控制“要给用户解释为什么推荐这个”。所以我们最终选择的是级联生成不是端到端生成。两级结构第一级微观画像级负责生成“用户当前最想要的单个商品和商品组合”输入是用户实时行为序列、购物篮、商品语义特征输出是候选商品集合以及每个商品和用户的匹配分数。第二级宏观主题级负责生成“当前时段、当前用户最应该进入什么场景/主题”输入是宏观运营主题、季节节奏、全站热度和用户长期偏好输出是一个主题分布然后用主题信息去约束和调整第一级的候选排序。如果打个比方第一级像一个资深导购一眼看出你今天是想买鱼还是买牛排第二级像一个区域经理知道今天全店要推“火锅食材节”就让导购优先把黄喉、毛肚、火锅底料拿出来。导购懂人经理懂场。两者凑在一起才会有一个既符合个体意图、又符合全站节奏的推荐结果。这个设计还有一个隐性好处就是可解释性和可干预性。运营想强推某个主题只需要调第二级的主题权重不用改任何模型。算法同学想优化用户偏好只需要迭代第一级的序列模型。两边边界清晰出了问题也好回溯。1.3 适用范围与团队配置做这个项目团队不需要特别大。我们当时核心团队一共四个人一个算法工程师负责整体框架和微观模型一个算法工程师负责主题挖掘和统计模型一个后端工程师做特征服务和在线推理还有一个推荐平台工程师负责AB实验和数据回流。从开始设计到第一版上线大概用了六周又花了三周做稳定性优化和人工案例复盘。如果你所在的业务也是“用户会一次买多品类商品”的电商形态比如社区团购、综合超市到家、生鲜前置仓这个框架都有直接参考价值。如果是纯标品、纯单品转化的业务比如数码3C收益可能会打折因为用户购物篮本身就不宽跨部门融合的意义没那么大。2. 微观画像构建从“单点偏好”到“此刻需要什么”2.1 双塔召回与实时特征用户画像不能是“昨天”的微观画像的第一层是我们做了一套基于双塔结构的实时召回模型。这层负责从全站商品池里快速选出每个用户当下最可能有反应的几百个商品。用户塔的特征当时分了五组短期行为序列最近24小时内浏览、加购、收藏的商品ID序列按时间排序中期兴趣分布近7天在各部门的曝光点击率、人均浏览时长、品类占比以特征数组形式输入购物篮实况当前购物车内所有商品的部门、品类、价格段、热量、保质期等属性这个特征在生鲜电商里非常重要因为用户是先加购后结账的历史偏好兜底近90天的长期静态偏好embedding用来防止短期行为过强、导致推荐非常窄环境信号当前时间、星期、是否工作日、实时天气温度、是否是饭点这些信号对生鲜场景影响极大尤其是雨天和临近晚饭时段。商品塔这边除了常规的标题、类目、价格、品牌特征我们重点加了两个生鲜特有特征保存条件常温/冷藏/冷冻和履约距离这个商品从哪个仓发货、预计多久到。为什么加保存条件因为跨部门推荐的基础逻辑是“能放进同一个冰箱”你在推冷藏酸奶的时候绝对不应该搭配冷冻披萨。线上实现时用户塔是实时更新的。用户每产生一次浏览或加购行为行为序列变化通过消息队列实时更新用户embedding缓存。实测中这种“实时画像”比T1离线画像在加购率上提升了将近20%。代价是对特征服务压力更大后面再讲。2.2 序列模型与图嵌入两种微观建模的互补双塔结构适合做大规模召回但有个问题它对“用户行为之间的顺序关系”敏感性不够。比如“买了牛奶以后再买咖啡豆”和“买了咖啡豆以后再买牛奶”虽然商品相同但用户心智状态完全不同。所以我们在双塔的user tower里嵌了一个轻量GRU序列编码器输入最近20个行为商品的embedding输出一个行为序列向量和静态特征拼接。这个方案在初期是够用的。但后来我们发现一个现象很多连带购买关系不是显性的同一Session行为而是跨天、跨部门发生的。比如用户周一买了即食鸡胸肉周五又买了生菜周六买了全麦卷饼这个“健康轻食”的关系链长达三天。如果只看Session内行为根本捕捉不到。于是我们补了一个商品共现图模型把“同一个购物篮里同时出现”的商品看成一条边部门和部门之间用商品作为桥梁构建一个包含数十万节点、数百万边的异质图然后做graph embedding。最终把商品的图向量拼到item塔的输入里。图嵌入的效果非常直观跨部门推荐新商品的命中率明显提高。比如“三文鱼刺身”可以关联到“芥末”和“寿司酱油”这是传统语义模型很难学到的但在共现图里因为有大量真实购物篮支撑关系非常坚固。2.3 微观画像踩过的坑这个模块做了三周踩了三个坑值得说说。第一个是特征穿越。我们把“用户当前购物车的商品特征”放进了训练样本但训练样本的Label是“用户是否点击/购买了该商品”。坑在于如果商品已经在购物车里用户当然不会“点击”它导致这部分样本的负反馈是假的。解决方法是构造样本时把商品已在购物车的情况单独建模为“加购成功”目标不和点击目标混在一起。第二个是embedding维度不是越大越好。我们一开始拍脑袋用了128维结果离线AUC没提升线上延迟却涨了。后来改用64维并加了L2约束让向量分布更聚拢效果不降反升。经验是生鲜电商的商品总量比标品少很多几十万级商品规模64维足够表达维度太大反而会让向量空间稀疏相似商品距离变远。第三个是曝光偏差。线上推荐系统的样本天然只包含“被曝光过”的商品没被曝光的商品即便用户喜欢也没有样本。我们采用了业界常规的解决方式——随机曝光策略大约5%的流量给随机或低分商品这些样本统一带一个“is_random1”的标记训练时用来矫正分布。这个让新品的召回命中率从不到1%提升到接近5%。3. 宏观主题体系把“部门”升级为“场景”再用算法生成主题3.1 主题挖掘不是运营拍脑袋是数据里长出来的宏观主题这个概念的雏形可能很多平台都有就是“运营活动页”。比如“火锅节”“烧烤季”“开学早餐计划”。但传统运营主题有两个问题一是更新慢通常按周甚至按月换一次二是覆盖面窄只服务活动入口进不了首页信息流。我们想做的是算法生成的动态主题主题本身就是模型产出而不是人工配置。具体做法分三步从购物篮聚类。把近30天所有购物篮按商品共现强度聚类一个类簇就是一个候选主题。比如“火锅类”聚簇里出现的高频商品是肥牛卷、毛肚、火锅底料、虾滑、鸳鸯锅……这些商品的组合本身就定义了主题内容。用商品属性给主题做语义标注。每个聚簇的商品聚合出高频属性标签比如“辣的”“冷冻”“即食”“儿童”“进口”把这些标签组合成主题的描述性名称便于运营理解。用时间序列预测主题趋势。每个主题计算近7天热度、环比增长率、分时段活跃度然后做一个简单的时序预测预测未来24小时这个主题的热度变化。同时接入外部特征比如当地天气预报、节假日、二十四节气用这些预测下一个小时该主题是否处于上升期。这套主题体系跑起来以后我们发现了一些很有意思也很有价值的主题比如“露营冷餐组合”“加班深夜泡面局”“宝宝辅食周”这些主题在传统运营眼里不一定会被想到但对用户来说非常真实。而且它们天然是跨部门的一个“露营主题”包含熟食、蛋糕、饮料、零食、一次性餐具直接把部门孤岛打碎了。3.2 主题与部门KPIs宏观主题怎么吃下“部门战略”主题体系上线前运营团队很担心一件事如果首页全被主题占据那各个部门自己的主推品、清仓品、新品怎么办每个部门都有KPI的。我们在设计时专门加了一个软约束机制叫**“部门配比调节器”**。主题生成候选商品时不只看商品与主题的契合度还会参考该部门当前战略目标新品曝光率、动销率、清仓进度把业务约束编码成一个分数和主题契合度做加权相加。例如冷启动新品在新品期内有一个专门的“新品加乘”boost使这个商品在相关主题里更容易露头一旦动销上来就恢复正常概率。这个设计的好处是宏观主题不是一个独立的“运营位”它就像一个可编程的分发框架。各个部门的战略可以借主题的势能流动而不是反过来把主题拆成部门来运营。这样既保住了部门KPI又实现了跨部门融合。实际运行中部门和推荐算法团队的对齐效率高了很多以前改推荐策略要靠运营提需求单现在直接在框架配置台改权重就能完成。3.3 主题热度的实时化避免“昨天很热今天没人要”主题如果固定不变很快就会疲劳。我们要求主题的热度信号按小时更新。主链路的实时化方式是每小时的整点离线任务先计算所有候选主题的近24小时曝光/点击/加购/支付数据然后更新主题的趋势分。趋势分公式很简单就是趋势分 近3小时热度/近24小时热度 × 归一化系数如果某个主题近3小时热度显著高于全天均值就认为该主题正处于上升期在宏观层面加大它的注入比例反之如果热度持续走低就降低甚至下线。这套机制上线后主题推荐位的CTR比固定运营位高出将近一半因为用户看到的永远是“正在发生”的场。4. 级联融合与服务化实现微观×宏观在线决策的完整链路4.1 两阶段级联的推理流程先生成候选再注入主题这个框架的在线推理流程可以分成四步走第一步微观候选计算。根据用户当前Profile用双塔GRU打分从全站候选池里取回600个候选商品。这600个商品完全由“用户个性化”驱动不受主题影响保证用户的基本偏好不丢。第二步主题匹配。把当前时刻所有活跃主题按热度排序选出用户最可能感兴趣的5个主题再从每个主题的商品池里取回100个主题候选对这些主题候选做去重得到最多500个主题商品。第三步候选合并与级联打分。微观候选和主题候选合并成一个候选池交给精排模型打分。精排模型的输入包括四组特征微观匹配度用户塔和商品塔的内积主题契合度商品在主题高相关商品里的PageRank分数或商品和主题向量的余弦相似度上下文全局状态当前时段各主题热度、当前品类转化率、天气、价格弹性多样性约束与已展示商品的类目/部门/品牌差异度。精排模型是一个带注意力的DNN输出每个商品在这个“用户×时刻×主题”上下文下的预估CTR和预估加购概率。注意这里模型不看单一概率而是把CTR和加购率分开建模最后在业务层用可配的权重合成最终分。第四步主题穿插规则。最终排序结果出来以后我们会做一次“主题穿插”确保最终返回给用户的20个商品里至少有30%~40%的商品来自主题商品池。这个比例是动态可调的根据用户是否是新手、当日是否有大促等条件切换。用公式概括融合分数就是下面这个最终分 α × 微观匹配度 β × 主题契合度 γ × 上下文全局状态 − δ × 多样性惩罚α、β、γ、δ不是fixed参数而是根据用户和场景动态计算的。老用户α调高保持个性化新用户β调高用主题帮助他们发现冷门部门和商品大促期间γ权重上调把全站热度的影响放进来。4.2 在线部署与性能预算每一层都不能拖后腿做在线部署的时候我们定了几个硬指标P95延迟不超过85毫秒可用性不低于99.95%。具体的服务架构是特征服务层用户实时行为缓存Redis商品静态特征Tablestore实时天气/时间信号一个轻量HTTP接口包了一层缓存召回层两个独立召回服务并行跑——双塔召回用向量检索服务HNSW索引单机几百路QP主题召回走主题商品表因为主题数量有限事实上是离线把主题商品表直接缓存到内存按期更新在线查询时做过滤和打分精排层一个带GPU的TensorFlow SavedModel服务模型输入拼接所有特征成一个大Tensorbatch内部做动态padding支持单请求多商品打分规则层主题穿插、多样性控制、竞价约束、黑名单都放在精排后面的一层轻量规则引擎里。这里我特意强调一下向量检索的坑。双塔召回用的向量库我们一开始存在Elasticsearch里结果延迟到了200ms压不下来。后来换成专门的高性能向量检索服务把索引放在内存里延迟才降到10ms级别。经验是不要把向量检索和业务文档检索混在一个引擎里数据量大起来以后方方面面都是坑。另一个部署经验是关于嵌入式层模型和精排模型的版本兼容。因为推荐框架是级联的第一级“微观画像”的item embedding和第二级“精排模型”的输入特征里都用到了商品embedding如果两个模型同时升级但embedding版本不一致精排模型会学到“旧embedding新权重”的组合行为会很奇怪。我们上线一个自动化任务检测两个模型是否存在embedding版本不一致发现问题时自动回滚到兼容版本才把这个坑彻底堵住。4.3 AB实验设计不能只看CTR要看“购物篮宽度”这个框架上线的AB实验我们折腾了挺久很大的原因在于推荐系统团队和增长团队对指标的看法不一致。推荐团队习惯看CTR、GMV增长团队坚持还要看“购物篮宽度”——用户本单购买了多少个不同部门的商品。后来我们把两组指标都列下来作为这个实验的“北极星”体系用户侧CTR、点击后加购率、购物篮商品数、购物篮部门数、跨部门连带率业务侧客单价、GMV、新部门渗透率、部门KPI达成率健康侧曝光多样性、主题疲劳度、冷启动新品曝光占比。结果是很有意思的单纯看CTR新框架可能略降0.5%但购物篮宽度提升9%以上客单价提升4%以上GMV净增长非常可观。这说明微观匹配和宏观主题的融合牺牲了一点即时点击率换来了更强的跨部门连带转化全站层面是更健康的增长。所以做这类框架一定要把分析视角拉高从单次点击的胜负转移到用户整个购物旅程的完整度上来。5. 常见问题与排查技巧实录5.1 级联误差放大微观候选池把主题商品全剪掉了怎么办“级联”最大的风险就是误差传导。我们第一次上线时发现主题商品注入比例很低用户看到的还是老几样。排查后发现问题出在第一级微观候选池虽然我们设了600个候选但主题商品在池子里的数量很少。原因是精排模型学习到的分布是以往“纯个性化推荐”的信号。主题商品对老用户来说在微观打分上天然不如“用户最常点击的商品”。解决方式有两条候选池扩容600扩到1200并保证主题商品池在合并前至少有300个名额无论如何不被过滤人工规则兜底在精排阶段加一个“主题保护”通道模型预估分乘以一个主题加权系数。加权系数不设成0/1硬开关而是一个平滑函数避免分数突变导致排序抖动。这个调整上线后主题注入比例从5%提升到了35%且整体GMV没受影响。教训是级联系统里每一级的“通过率”都要监控不能只看最后一级的输出。5.2 疲劳与惊喜感的平衡老用户对主题越来越“无感”主题推荐跑了两周以后我们发现一个典型问题老用户对同样的主题商品开始无感主题商品点击率明显下滑但新用户反而越来越喜欢。这就是主题疲劳。解决办法是给每个主题加了一个**“用户级疲劳衰减因子”**主题最终分 主题热度分 × 用户对该主题的历史偏好分 × exp(−k × 该主题近期曝光数/用户)k值调参后如果用户近期已经看到某个主题超过10次该主题的权重会衰减到最初的40%左右。同时全局主题池会定期轮换把一些热度低于阈值但用户交互好的小众主题重新激活。经过这一轮调整主题商品点击率在上线三周后仍能维持在一个稳定的高位。5.3 新用户冷启动宏观主题是救星但不能“全是主题”新用户没有历史行为微观画像接近于零。这时候主题推荐成为最重要的信息来源。但有一次我们试验“新用户全主题化”后次日留存反而下降了。分析原因发现新用户如果看到的前几个商品都是跨部门组合会觉得自己“被疯狂推销”了反而失去信任感。所以最终的策略是新用户的前3个推荐位必须是“主流热门单品”也就是全站转化率最高的Top商品从第4个位置开始才进入主题商品区。这样既保留了主题的探索感又给新用户一个平稳的接受过程。上线后新用户的次日留存提升了近8%。5.4 数据质量是命脉购物篮数据的清洗不能嫌麻烦最后我想重点说说数据问题。生鲜电商的购物篮数据非常脏。用户会在购物车里放几周然后一起结账会把已经下架的商品留在车里会一次性买十件同款但最终取消会深夜下单然后早上起来退一半。我们一开始没有做严格的购物篮清洗导致图嵌入模型学到了一些“怪边”——比如“啤酒”和“尿布”这种经典玩笑关系居然出现了还有大量“囤货型”购物篮把并无关联的商品强行拉到一起。后来我们加了一套清洗规则只使用“结账后2小时内未退单”的订单作为图嵌入的样本剔除商品数超过20件的“批发型”购物篮加购超过3天未结账的商品不参与当前篮分析当购物篮同时包含冷冻和常温商品时降低该篮子的权重因为这种篮子大概率是“多目的混合购物”不反映真实搭配逻辑。数据干净了图嵌入的质量明显提升。所以我的强烈建议是任何推荐算法项目先花时间把数据清洗规则定好否则后面所有模型都在垃圾上跳舞调参都是白费功夫。结尾这个框架运行半年后我个人的几点体会说实话这个框架本身的技术难度并不是“颠覆式”的。双塔、GRU、图嵌入、主题挖掘、两阶段级联每一个模块单独拿出来业界都有一堆成熟实践。真正的难点在于把这些模块以“级联”的方式咬合在一起并且让推荐结果在“用户个性”和“全站节奏”之间找到那个动态平衡点。我个人最大的体会是推荐系统做到后期技术栈反而不容易拉开差距拉开差距的是对“人”和“场”的理解方式。用户不是一张静态画像他今天来打开App时的状态和昨天是完全不同的。部门也不该是静态商品类目它应该被组织成一个个可变化的场景。把这两层理解放进同一个决策链路里才是“级联生成推荐框架”真正的价值所在。如果你也要做类似的项目我最后再送你三个建议第一不要试图用一个超大规模模型解决所有问题两级或三级级联在工程上更好维护第二上线前就把“实验指标体系”定完整特别是购物篮宽度这类长期健康指标否则很容易被短期CTR误导第三保存一份“模型输入特征版本”和“embedding版本”的对应关系自动监控版本漂移这个能帮你省掉无数排查事故的夜晚。这个框架后续还有很多可扩展的方向比如把主题挖掘做成纯端上的实时聚类、把主题感知加到商品图模型里、甚至用主题序列给用户做“购物菜谱”推荐。每条路都值得再开一篇文章细聊有机会我们下次接着写。