多场景推荐：让一套模型驾驭首页、详情与购物车

可视化演示

演示独立建模、共享骨干结构和参数共享效率对比，理解多场景统一建模的优势与挑战。

多场景困境：三个窗口三套灶台

商场餐厅最容易犯的错，就是在门口、吧台、收银台三个位置各修一个独立小厨房：每个厨房都要买一遍锅碗瓢盆、烟机灶具、酱醋油盐，连招聘的师傅都要三份。结果菜还没卖出去多少，装修成本先翻了三个跟头。更尴尬的是，三个厨房各做各的菜，高峰时段彼此连食材都借调不了。独立建模的推荐系统差不多就是这个样子。

在电商平台里，首页推荐、详情页推荐、购物车推荐往往由不同的团队、不同的模型分别负责。每个模型都有自己的特征管线、训练样本和线上部署，相当于三套完整的工程链路。这样的模式有三大痛处：第一，购物车这类场景天然样本少，独立模型数据稀疏学不好；第二，模型数量随场景数线性增长，训练、存储、推理开销都成倍上升；第三，三个模型各自为政，用户在一个场景看到的推荐与其他场景缺乏连续性，体验割裂。

我们把这种成本关系写成一个公式：假设每个场景的独立建模成本是 $C_{s}$，一共有 $S$ 个场景，那么总成本就是所有场景之和。当每个场景规模相当时，总成本约为单场景成本的 $S$ 倍——场景越多，浪费越严重。

回到餐厅的例子：真正精明的老板不会开三个小厨房，而是建一个中央厨房统一备菜。推荐系统也一样，与其每个场景造一套轮子，不如思考如何让一套模型hold住所有场景——这就是「多场景统一建模」要解决的问题。

场景差异拆解：逛、比、买

中央厨房营业前，老板先要把三拨客人的心理摸透。门口等位的客人是来“逛”的，你给他摆一桌大鱼大肉他不一定动心，反而喜欢琳琅满目的新菜和当季热门；吧台前研究某道菜细节的客人是来“比”的，他需要看到“点这道菜的人还点了什么”，帮他横纵向比较；收银台前的客人是来“买”的，就差最后一步付款，你推荐一个满减凑单小菜，他大概率顺手就拿。三拨客人要的不是同一套话术。

推荐系统里这三个场景的用户意图差异同样显著。首页用户处于浏览探索阶段，没有明确目标，推荐要注重新颖性和多样性，让用户“逛得下去”；详情页用户已经对某个物品产生了兴趣，处于比较决策阶段，推荐相关品、互补品、相似款来帮用户“比得清楚”；购物车用户已经接近成交，处于临门一脚阶段，推荐凑单品、低客单价关联品来帮用户“买得痛快”。

除了意图，展示位置约束也各不相同：首页有首屏、信息流的丰富位置；详情页推荐位往往在详情下方，位置有限；购物车推荐区域更小更靠后。各场景的核心优化指标也不同——首页重点击率（CTR），详情页重加购率，购物车重转化和客单价。用统计语言说，在给定同一用户和同一物品的条件下，不同场景下用户发生行为的概率分布是不同的：

三拨客人三种心态，三套方案又不能真搞三套人马。老板的解题思路是：中央厨房统一做饭，但每个窗口挂一块牌子，告诉后厨“这批菜是要端给谁的”。推荐系统里，这块牌子就叫场景特征。

统一建模思想：一套厨房，多块招牌

中央厨房之所以能省下两倍开销，关键在于它把“切菜、备料、炖高汤”这些公共工序集中完成，每个窗口只需要最后的“回锅调味”按各自招牌做。老板不会要求三个窗口的菜一模一样，但也不会每个窗口重新养一群鸡鸭鱼——这就是“统一”的真意：共享的是底层的通用能力，差异的是上层的场景适配。

多场景统一建模的核心思想与此完全一致。它不追求“一个模型输出所有场景的相同结果”，而是训练一套主干网络来抽取用户和物品的通用表征，同时把“当前正在哪个场景”作为模型的一个输入信号。模型根据场景信号，在通用表征之上做差异化输出。这样一来，所有场景共享一套特征工程、一套训练流程、一套线上服务，而场景差异由模型自己学习。

形式化地看，统一模型的预测不再只依赖用户、物品、上下文，还要额外接收场景信号 $s$：

这套思路让“中央厨房”从口号变成了架构：底层参数全场景共享，数据量大的场景（首页）帮数据量小的场景（购物车）一起学。接下来关键问题是——场景信号 $s$ 到底怎么进到模型里去？答案是场景特征嵌入。

场景特征嵌入：每块招牌都是“风味代码”

中央厨房的每块招牌不只是挂给客人看的，更是写给后厨看的指令码。招牌上写着“川湘窗口”，后厨就知道这锅菜要多放辣椒花椒；写着“粤式窗口”，就知道要清淡提鲜。推荐系统里的招牌，就是场景特征的嵌入向量。

场景是一个离散的ID（比如0代表首页、1代表详情页、2代表购物车），不能直接当数值用。嵌入（Embedding）就是把离散ID映射成一个低维稠密向量——相当于给每个场景学一串“风味代码”，数值上相似的场景风味也相近。这个场景向量会和用户特征、物品特征拼接在一起，送入统一模型的主干网络，让模型每算一步都“看得见”当前场景。场景嵌入不仅能表达场景身份，还能顺带建模位置偏差：例如“首页第5屏的推荐位”和“首页第1屏的推荐位”也可以各用一个位置嵌入，让模型学会区分曝光位置的先天差异。

挂了“风味代码”之后，招牌只是一个参考信号；真正决定菜品的，是中央厨房的分配策略——哪些工序全场景共用，哪些工序各窗口各做各的。这就引出了参数共享策略。

参数共享策略：共享底料，各留酱汁

中央厨房里有两类东西。一类是全餐厅共用的“底料”：高汤、基础酱、冷链储备，每个窗口做菜都从这里取，保证品质一致又节省成本；另一类是每个窗口的“独家酱汁”：川湘窗口的麻辣油、粤式窗口的豉油汁，是各窗口立足的差异化之本。推荐系统的参数也分为这两类。

共享参数层是模型底部的多层神经网络，所有场景共用同一份权重，用来学习用户兴趣、物品表征等通用知识。场景特定塔是模型上层的输出结构，每个场景拥有自己的一份参数，用来适配本场景的独特偏好。更进一步，还有组合参数生成策略——不是让共享和特定完全隔离，而是把两者结合成每个场景实际使用的参数。比如共享权重提供一个基础变换，场景特定的缩放因子再对它进行调整，既借力共享知识，又保留场景个性。

把参数结构写出来：模型总参数 $\theta$ 是一个集合，包含一份全场景共享的参数 $\theta_{shared}$，外加每个场景各自专属的参数 $\theta_{s}$。

共享底料保证效率与一致，独家酱汁保证差异与品质。把这个思想推向极致、并在一线大规模落地验证的，就是著名的 STAR 模型。

STAR模型：星型配送台

在中央厨房的中央，老板设了一个“星型配送台”：所有菜品的半成品先送到配送台，再由配送台按各窗口的配方加工后分发出去。配送台不是简单地一锅分三份，而是对着每个窗口的配方卡，对半成品做不同的调味。这样既保证了中央生产的高效，又让每个窗口拿到的菜是自己客人要的味道。STAR（STAR: A Unified Model for Multi-Scene CTR Prediction）模型的结构，就是这座配送台。

星型FC结构是 STAR 的核心：每个场景的权重矩阵 $W_{s}$ 由两部分合成——一个所有场景共享的基权重 $W_{shared}$，和一个该场景特有的缩放矩阵 $W_{specific}^{(s)}$，两者逐元素相乘得到该场景实际使用的参数。直观理解：共享基权重知道“综合来看怎么推荐是好的”，场景缩放矩阵知道“我们这个窗口要把哪个分量放大、哪个分量调低”。此外 STAR 还引入了分区Softmax，让各个场景在各自的候选集上进行归一化，避免场景间候选规模差异影响概率比较；训练时则采用多任务联合训练，将各场景的损失合并优化。

星型结构让共享和差异在同一层参数内优雅共存。随之而来的一个巨大红利是：数据旺盛的“招牌窗口”会通过共享基权重，把自己的成功经验悄悄传递给其他窗口——这就是知识迁移。

知识迁移：招牌菜带火冷门窗

餐厅把招牌菜越做越好的过程中，积累了大量的顾客反馈：什么食材受欢迎、什么火候最合适。这些经验沉淀在中央厨房的“底料库”里，冷门窗口做新菜时，直接借用了这些成熟经验，避开试错成本。这就是知识迁移——数据多的场景把学到的模式通过共享参数传递给数据少的场景。

在推荐系统里，首页的曝光量和点击量通常是购物车、详情页的好几倍。独立建模时，购物车模型只能靠自己的少量样本“摸着石头过河”；统一建模后，购物车模型的计算图和首页模型共享主干网络，首页的海量样本训练出的用户兴趣表征，购物车模型天然就能用上。对于新上线的冷门场景，这种迁移几乎是“雪中送炭”——不必从零积累数据，就能继承整个平台的用户理解。

为了实现可控的迁移，训练时要把各场景的损失函数联合起来优化，并允许按业务重要性为每个场景分配权重 $\lambda_{s}$：

正向迁移让人振奋，但共享不是免费的午餐。招牌菜的经验是否适合冷门窗口，取决于窗口间的相似度；如果硬把南甜北咸的两种口味塞进同一口锅，做出来的菜可能两边都不讨好——这就是负迁移。

负迁移控制：别让臭鱼毁了一锅汤

中央厨房有个隐患：如果某个窗口的食材不新鲜，做出来的菜带着异味，而这套“坏手艺”被写进了共享底料库，其他窗口的菜也会被带偏。更麻烦的是，两个窗口的风格完全相反——一个主打重油重辣，一个主打清淡养生——共享参数在两者之间反复拉扯，谁都做不好。这就是负迁移：场景差异过大，共享参数反而互相干扰，导致各场景效果不升反降。

负迁移的成因在于不同场景的优化目标冲突。解决思路不是放弃共享退回独立建模，而是给共享加上“闸门”——门控机制。门控层根据当前输入和当前场景，动态计算一个 0 到 1 之间的调制向量，决定共享特征放行多少、场景特定特征补充多少。场景相似度高时门控大开，让迁移充分发生；场景冲突激烈时门控收窄，挡住干扰信号。此外，还可以通过场景相似度加权、对不相似场景减少共享梯度回传等手段控制风险。

中央厨房的闸门哲学是：共享不等于和稀泥，差异不等于重复造轮子。用一套模型服务多个场景，并用门控精细控制知识流动的边界，才能真正实现“一套模型吃遍全场景”。

AI 应用场景

Python 演示

import torchimport torch.nn as nnimport torch.nn.functional as F  class MultiSceneModel(nn.Module):    """Shared-bottom model with STAR-style scene-aware params."""     def __init__(self, feature_dim=16, num_scenes=3, hidden_dim=32):        super().__init__()        self.num_scenes = num_scenes        self.scene_embed_map = nn.Embedding(num_scenes, 8)        self.shared_fc1 = nn.Linear(feature_dim + 8, hidden_dim)        self.shared_fc2 = nn.Linear(hidden_dim, 1)        self.scene_scale = nn.Parameter(torch.ones(num_scenes, hidden_dim))        self.scene_bias = nn.Parameter(torch.zeros(num_scenes, hidden_dim))     def forward(self, features, scene_id):        scene_vec = self.scene_embed_map(scene_id)        x = torch.cat([features, scene_vec], dim=-1)        h = F.relu(self.shared_fc1(x))        scale = self.scene_scale[scene_id]        bias = self.scene_bias[scene_id]        h_scene = h * scale + bias        logit = self.shared_fc2(h_scene)        return torch.sigmoid(logit).squeeze(-1)  def make_demo_data(num_samples=1000):    torch.manual_seed(42)    features = torch.randn(num_samples, 16)    scene_id = torch.randint(0, 3, (num_samples,))    base = torch.randn(num_samples) * 0.6    scene_boost = torch.tensor([0.5, -0.3, 0.8])[scene_id]    prob = torch.sigmoid(base + scene_boost)    labels = torch.bernoulli(prob)    return features, scene_id, labels  def train_model():    features, scene_id, labels = make_demo_data()    model = MultiSceneModel()    optimizer = torch.optim.Adam(model.parameters(), lr=0.01)    loss_fn = nn.BCELoss()    for epoch in range(120):        pred = model(features, scene_id)        loss = loss_fn(pred, labels)        optimizer.zero_grad()        loss.backward()        optimizer.step()        if epoch % 40 == 0:            print("epoch", epoch, "loss", round(loss.item(), 4))    return model  if __name__ == "__main__":    demo_model = train_model()    test_feat = torch.randn(3, 16)    test_scene = torch.tensor([0, 1, 2])    with torch.no_grad():        preds = demo_model(test_feat, test_scene)    for sid, p in zip(test_scene.tolist(), preds.tolist()):        print("scene", sid, "CTR", round(p, 4))

1. self.scene_embed_map = nn.Embedding(num_scenes, 8)建立场景ID嵌入表，把“首页/详情/购物车”三个离散ID映射为8维稠密向量，相当于为每个窗口生成“风味代码”。
2. self.scene_scale = nn.Parameter(torch.ones(num_scenes, hidden_dim))场景缩放参数，训练中学习各场景对共享特征的放大/缩小强度，这是简化版星型结构。
3. scene_vec = self.scene_embed_map(scene_id)根据当前样本属于哪个场景，查出对应的场景嵌入向量。
4. x = torch.cat([features, scene_vec], dim=-1)把原始用户/物品特征与场景向量拼接，让模型每层计算都感知场景身份。
5. h_scene = h * scale + bias用场景缩放和偏置调制共享隐藏层输出，实现“共享底料 + 独家酱汁”。
6. scene_boost = torch.tensor([0.5, -0.3, 0.8])[scene_id]模拟三个场景的真实转化率差异：详情页（场景1）转化率偏低，购物车（场景2）最高。
7. loss.backward()反向传播时共享网络会同时收到三个场景的梯度，这是知识迁移发生的底层机制；若场景冲突大就需要门控来调停。

常见误区

面试题