真实面经题目 · 原创解析
这题的关键是小样本场景不是简单“数据少”，而是抢购等场景的用户意图、价格敏感度、库存稀缺、时间压力和 CTR/CVR 分布都与主场景不同。只用主场景大数据训练一个统一模型，容易在小场景上校准偏、排序目标错或过度拟合主场景。可行方案包括增量学习、样本重加权、多任务/多场景建模、场景特征注入和 PPNet。PPNet 的核心是用场景/人群/上下文作为 gating 或 personalized parameter generator，对底层网络的 hidden units 或专家输出做个性化缩放，让主模型共享大样本知识，小场景通过参数调制适配分布差异。回答还要覆盖数据构造、冷启动、负迁移、校准、在线 A/B 和防遗忘。
我会先把问题定义成多场景分布偏移：主场景样本多，但抢购场景的用户意图、价格、库存、时间窗口和 CTR/CVR 基准率都不同，所以不能简单把小样本混进主场景训练后期待模型自动学会。方案上有三层。第一是数据和目标层：给样本加 `scenario_id`、活动类型、库存、倒计时、折扣、曝光位置等特征，按场景重采样或加权，CTR/CVR 分别做校准。第二是增量学习：用主模型 warm start，在新场景数据上小学习率微调，可冻结 embedding/底层，只调高层、bias、adapter 或 LoRA，并混入主场景 replay 防止遗忘。第三是 PPNet/多场景结构：用场景特征和用户特征生成 gate，对 hidden vector 做 `h' = h * g(s,u)` 的逐维调制，或者对专家权重做动态加权，让共享网络保留主场景知识，小场景通过 gate 改变特征组合。验证时离线看分场景 AUC、LogLoss、校准 ECE、TopK 转化收益，线上看抢购 CTR/CVR/GMV、库存消耗效率、主场景护栏和长期稳定性。
抢购场景中用户往往有更强即时购买意图，商品折扣、库存、倒计时、活动入口和社交热度会显著改变点击和转化机制。CTR 可能因强刺激上升，CVR 也可能因库存不足、排队失败或冲动点击而出现不同方向变化。主场景数据虽然多，但学到的是常规浏览和购买分布；直接迁移到抢购场景会出现预测校准偏差、排序偏好错误和对稀缺特征不敏感。面试时要先指出这是 covariate shift、label prior shift 和样本不平衡共同存在的问题。
需要显式补充场景特征，例如 `scenario_id`、活动类型、活动阶段、倒计时、折扣力度、库存余量、库存变化速度、是否限购、入口来源、曝光位置、用户历史活动偏好、价格敏感度和品类偏好。样本层要按场景、阶段和人群做分桶，避免小场景被主场景淹没。标签上 CTR 和 CVR 要分开分析，因为抢购可能点击强但支付受库存/履约影响。对 CVR 还要注意延迟反馈、转化窗口和未支付/缺货等特殊负样本定义，否则会把系统不可售误学成用户不感兴趣。
增量学习可以用主场景训练好的模型作为初始化，在抢购样本上继续训练。为了避免小样本过拟合，通常采用小学习率、较少步数、早停、正则化，并冻结底层 embedding 或部分 shared layers，只训练高层 MLP、场景 bias、adapter、校准层或少量 LoRA 参数。为了避免主场景能力遗忘，训练 batch 中混入主场景 replay，或加入约束项 `L = L_flash + λ L_main_replay + μ ||θ - θ_base||^2`。如果场景周期性强，还可以按活动前、中、后做滚动增量更新，并设置模型回滚。
PPNet 可以理解为在主网络旁边加一个 gate 网络，用个性化/场景特征生成逐维缩放系数，对主网络隐层进行调制：`g = sigmoid(MLP([user, scenario, context]))`，`h' = h ⊙ (1 + αg)` 或 `h' = h ⊙ g`。这样共享网络仍从主场景大样本中学习通用 user-item 表达，小样本场景不需要独立训练一整套参数，而是通过 gate 改变哪些隐含维度更重要。抢购场景可以让折扣、库存、倒计时、价格敏感等特征影响 gate，从而调整 CTR/CVR 预测。相比简单拼接 `scenario_id`，PPNet 对特征交互和参数个性化更强；相比完全独立模型，它更省样本且更容易共享知识。
离线评估要分主场景、抢购场景、活动阶段、人群和品类看 AUC、GAUC、LogLoss、NDCG@K、Recall@K、校准误差 ECE、预测均值与真实 CTR/CVR 的偏差。小场景样本少时，AUC 波动大，需要置信区间和时间切片验证。业务侧可看 TopK 预估收益、库存消耗效率、活动 GMV、支付成功率、用户投诉和缺货点击率。校准尤其重要：抢购 CTR/CVR 分布变了，排序模型如果只会相对排序但概率偏高/偏低，会影响出价、流量分配和多目标融合。
A/B 可以按用户或流量分桶，将 baseline 主模型与增量/PPNet 模型对比；如果抢购流量集中在短时间窗口，实验要覆盖活动全周期，并关注峰值 QPS 和库存状态。核心指标包括抢购场景 CTR、CVR、GMV、订单数、库存售罄效率、活动页跳失；护栏包括主场景 CTR/CVR、用户体验、投诉、延迟和模型稳定性。若只在抢购场景提升但主场景明显下降，可以考虑场景路由模型或只在 `scenario_id=flash_sale` 下启用 PPNet gate。
常见失败包括把小场景样本直接 oversampling，导致模型牺牲主场景；小样本微调过度，活动结束后能力失效；场景特征泄漏，例如使用曝光后才知道的库存变化或支付结果；CVR 负样本把缺货、排队失败和用户无意愿混为一谈；PPNet gate 过强导致模型在小场景上不稳定。还有一种是只看整体 AUC，主场景样本太多掩盖抢购场景改善，或者抢购样本太少导致误判。
直接拼接 scenario_id 依赖主 MLP 自己学交互，在小样本场景下信号容易被主场景淹没。PPNet 用场景/用户特征生成 gate，直接调制隐层维度或专家权重，相当于让不同场景使用不同的参数组合，表达能力更强，也更适合主场景共享、小场景适配的结构。
如果场景足够大、分布长期稳定、工程资源允许，可以单独模型。但抢购通常样本少、周期短、变化快，独立模型容易过拟合且维护成本高。更常见的是共享底座加场景适配层，或者只在关键场景启用 adapter/PPNet gate，兼顾样本效率和工程稳定性。
需要定义清楚转化窗口，并区分用户不购买、库存不足、支付失败、履约失败等原因。对缺货或系统不可售导致的未转化，不能简单当成普通负样本；可以做样本过滤、单独特征建模或多任务预测支付意愿与可售成功率。否则模型会把供给问题误学成用户兴趣问题。
可以冻结底层参数，只训练场景相关高层；训练时混入主场景 replay；加入参数约束 `||θ-θ_base||`；对主场景设置验证集早停；线上只在抢购场景路由到新模型。最终要用主场景护栏指标证明没有明显负迁移。
