Question 1

一个二分类业务问题，你怎么选模型？逻辑回归和 XGBoost 怎么取舍？

Accepted Answer

我的原则是约束驱动选型，而不是背性能排行榜。先问三个约束：可解释性要求——风控、信贷、医疗等强监管场景需要给出每个变量的影响方向，LR 加评分卡几乎是标配；数据形态——特征以连续值和少量类别为主、近似线性可分时 LR 够用，特征交互复杂、表格数据量大时树模型优势明显；工程成本——上线延迟、特征回填、模型更新频率都要算进去。我的实际流程是先跑 LR 基线，它同时充当特征质检器——该显著的特征不显著往往说明数据有问题；之后再上 XGBoost 对比，如果 AUC 提升不到一个点而解释性代价很大，我会选 LR。最后一定用离线加线上双指标验证：离线赢不代表线上赢，这是选型的最终裁判。

Question 2

拿到一份原始业务数据，你的特征工程流程是什么？

Accepted Answer

我的流程分四步，前两步最容易被跳过但决定成败。第一步数据审计：缺失率、异常值、字段口径，尤其是泄漏检查——最典型的是时间穿越特征，比如用「结果发生后才更新的状态字段」预测该结果，离线指标漂亮上线即崩。第二步按业务假设造特征而不是暴力枚举：行为频次、时间窗聚合（7 天/30 天）、关键字段交叉，每个特征我都要求讲得出业务含义，讲不出来的特征即使重要性高也要警惕泄漏。第三步验证：特征重要性排序加消融实验，确认每组特征的真实增益。第四步算工程账：一个提升 0.3% 的特征如果需要实时取数链路，上线成本可能不值——特征表的维护成本是长期的。我的经验是好特征来自业务理解，机器学习平台可以自动化建模，但不能替你理解业务。

Question 3

模型离线指标很好，上线效果差，你怎么排查？

Accepted Answer

我按固定顺序排查，因为三类原因的出现概率和验证成本不同。第一查特征穿越和泄漏：离线训练时用了线上预测时刻拿不到的信息，这是最常见的原因——验证方法是把每个特征的生成时间和预测时刻对齐审计一遍。第二查线上线下特征口径不一致：同名特征两套计算逻辑，我会抽样真实请求，逐特征对比线上取值和离线回算值，不一致率超过 1% 就是重大嫌疑。第三查分布漂移：训练样本和线上流量的人群结构不同，分桶看效果——如果效果衰减集中在某个人群切片，多半是训练集里该人群欠采样。我处理过一个真实案例：推荐模型离线 AUC 高但线上 CTR 平，最后定位是曝光偏差——训练样本全部来自旧策略曝光过的物品，新物品根本没有正样本，用随机流量做探索集之后问题解决。

Question 4

设计一个 AB 实验验证新推荐策略，样本量和周期怎么定？

Accepted Answer

样本量我从 MDE 倒推而不是拍脑袋：先和业务定「多小的提升值得上线」，比如 CTR 相对提升 1%，再结合指标方差、显著性水平 0.05 和功效 0.8 算出每组所需样本量，除以日均流量得到最短周期。周期上我坚持覆盖至少一个完整业务周期——通常 7 天起，因为工作日和周末的用户行为差异会让短实验的结论失真；同时警惕新奇效应，新策略上线初期的效果高估需要看第二周是否持续。推荐场景我会主动讲干扰问题：如果策略影响供给侧（比如改变内容分发），用户级随机分流会互相污染，需要考虑时间片轮转或集群分流。最后是实验纪律：指标和决策规则预先注册，不做实验中途偷看提前收割——peeking 导致的假阳性是实验平台最普遍的暗坑。

Question 5

核心指标昨天突然掉了 8%，你怎么归因？

Accepted Answer

我先验真再归因——大约一半的「指标暴跌」其实是数据问题：先查埋点是否丢数（对比服务端日志量）、数据管道是否延迟或故障、指标口径是否有人改过定义，再查日历因素——去年同期是否也有同样跌幅、是否节假日或大促后回落。确认是真实下跌后做多维下钻：按渠道、客户端版本、地区、新老用户拆分，找异动最集中的切片——如果 8% 的跌幅里有 6 个点来自某个渠道，问题范围立刻收窄。定位切片后关联同期变更：昨天有没有发版、策略调整、运营活动结束、竞品动作，把候选原因和切片证据对齐形成证据链。我的纪律是给结论时必须能回答「为什么是这个原因而不是别的」——单一假设加一张对得上的下钻图不够，要有反证排除过程，否则很容易把相关当因果。

Question 6

写 SQL：求每个用户最近一次购买距今天数，并按活跃度分层。

Accepted Answer

我先口述思路再写：对订单表按用户分组取最近购买时间，可以用 GROUP BY user_id 加 MAX(order_time)，也可以用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) 取 rn=1——需要带出整行订单信息时用后者。然后 DATEDIFF(CURRENT_DATE, last_time) 得到间隔天数，用 CASE WHEN 分层：30 天内活跃、31-90 天沉默、90 天以上流失。我会主动处理两个边界：从未购买的用户——必须从用户维表 LEFT JOIN 订单表，NULL 单独归为「未转化」层，直接查订单表会漏掉这批人；同一秒多笔订单对 MAX 无影响，但用 ROW_NUMBER 时要加第二排序键保证确定性。最后提性能：大表按日期分区裁剪、避免全表扫描，先按用户聚合再关联维表比先关联再聚合的代价小得多。

Question 7

讲一个你的模型/分析真正改变业务决策的案例。

Accepted Answer

我讲一个决策前后对比清晰的案例。背景：业务方原计划对全量流失用户发放同额度召回券，预算固定。我的分析发现流失用户的召回概率和券敏感度差异极大：高消费低频用户对券几乎无反应（他们流失是因为需求消失），而中消费高频用户的券弹性最高。我建了一个召回响应模型按弹性分层，建议把预算集中到弹性最高的 30% 人群并对不同层差异化券额。业务方最初不信任模型分层，我做了两件事建立信任：给出每层的可解释画像让运营直觉能对上，以及先用 10% 流量小规模验证。试点结果召回率提升 45%，全量后同预算下召回成本降了三分之一——增量口径用的是对照组差值而不是简单前后对比。这个案例我的心得是：数据科学的交付物是被采纳的决策，可解释性和小流量验证是让业务方敢采纳的两把钥匙。

Question 8

模型上线后你怎么做监控和迭代？

Accepted Answer

我按三层建监控，因为故障会在不同层先暴露。数据层：特征缺失率、取值分布、上游表延迟——多数线上事故的根因是上游数据变更而不是模型本身；模型层：打分分布漂移（PSI）、特征重要性变化、预测值与真实标签的滚动校准度；业务层：核心指标分人群监控，防止整体平稳但某个切片恶化。迭代上我定义清晰的重训触发条件——PSI 超阈值、滚动 AUC 下降超过设定幅度、或业务季节切换——而不是固定周期盲目重训；每次重训走影子模式先并行打分对比，再灰度放量，回滚预案是保留上一版模型可一键切回。还有一个容易被忽略的点：持续保留一小部分 holdout 流量不受模型干预，作为反事实基线——推荐类模型会通过自己的曝光决定自己的训练数据，没有这个基线，自我强化偏差会让离线评估越来越失真。

数据科学家高频面试题：8 道必考题与作答要点