解读

面试官想验证三件事：

1. 你是否具备“AI 系统级”视角，能把异常从业务层穿透到数据、模型、工程、运维、合规全链路；
2. 你是否能在高压、信息稀缺的情况下，用结构化方法快速收敛假设、降低试错成本；
3. 你是否能调动跨职能团队（算法、数据、工程、运营、法务、客服）用同一套语言协作，而不是把根因分析做成“算法组自查”或“甩锅大会”。

“从未见过”意味着没有历史 case、没有监控阈值、没有现成标签，传统 IT 的“告警-日志-回滚”三板斧可能失效，必须回到 AI 系统的本质：数据分布漂移、隐形反馈环路、标注噪声、特征穿越、奖励劫持、Prompt 注入、算力随机误差、合规灰区都可能同时存在。

知识点

1. AI 异常三维分类：

   • 数据层：分布漂移、概念漂移、标注腐败、隐性反馈、穿越特征。
   • 模型层：梯度爆炸、量化误差、奖励 hacking、泛化失效、版本回退。
   • 系统层：特征管道延迟、批实时不一致、A/B 分流污染、灰度未生效、缓存穿透、GPU 随机误差、合规策略拦截。

2. 中文互联网特有踩坑：

   • 内容合规触发“黑盒关键词”导致模型输出为空，但平台方不会返回具体词表；
   • 小程序/APP 双端埋点口径差异，导致训练样本被“重复加密-解密”后特征值移位；
   • 数据标注外包团队为冲产能，把“相似问法”批量复制，引发局部标签泄漏。

3. 根因分析七步法（AI 版）：
   ① 现象封存→② 复现最小闭环→③ 假设树+概率打分→④ 数据验证实验→⑤ 反事实仿真→⑥ 修复+灰度→⑦ 复盘沉淀监控。

4. 工具与合规：

   • 国内云厂商的“模型可解释”服务（阿里云 PAI、腾讯云 TI、百度千帆）只能给出特征重要性，不能给出因果图，需二次验证；
   • 《生成式 AI 管理办法》要求 10 个工作日内完成“有害内容”根因报告并上报属地网信办，必须留痕。

答案

我会把整个过程拆成“3 个会议、4 条红线、7 个步骤”，确保 24 小时内给出初步结论、3 天内给出修复方案，并满足合规留痕。

1. 立即启动“异常战情室”（第一会议）

   • 参会人：我（主持人）、算法负责人、数据运维、工程 SRE、客服值班长、法务合规、业务 VP；
   • 输出物：《现象封存单》：记录异常首次出现时间、影响面、业务损失估算、用户投诉原声截图、模型版本、数据版本、代码镜像地址；
   • 立 4 条红线：
     a) 任何人员不得重启服务或回滚模型，除非经我书面同意；
     b) 所有调试操作必须在影子环境完成；
     c) 用户投诉数据不得私自删除，需加密落盘备查；
     d) 对外口径统一由 PR 与法务共同拟定，防止二次舆情。

2. 24 小时内完成“最小可复现闭环”

   • 数据组：抽取异常时段 1% 随机样本，连同特征日志、原始输入、模型输出、后置规则结果，打包成“黑盒镜像”；
   • 算法组：用同版本模型在影子环境重跑，确认是否能复现；若不能复现，则把随机种子、GPU 卡型、batch size、量化参数全部锁定后再跑；
   • 工程组：检查特征管道延迟、缓存命中、A/B 分流哈希值，排除系统抖动。

3. 构建“假设树”并概率打分
   用鱼骨图把可能根因拆成数据、模型、系统、合规四大支，每支再细拆 3-4 子项。
   采用“贝叶斯快速打分”法：
   P(假设|现象) ∝ P(现象|假设) × P(假设)
   其中 P(假设) 用历史同类事故频率做先验；P(现象|假设) 用 30 分钟内的对照实验更新。
   把得分最高的前 3 个假设标记为 H1、H2、H3，写入《假设清单》。

4. 设计“数据验证实验”

   • 对 H1（数据分布漂移）：用 PSI、KS、Chi-square 分别对比昨日与上周的连续特征、离散特征、文本 embedding 均值；
   • 对 H2（特征穿越）：检查“用户次留”特征是否用了未来 24 小时数据；
   • 对 H3（合规关键词误杀）：把异常输出为空的结果单独捞取，用内部合规词库跑一遍前缀匹配，看是否触发黑盒策略。
     所有实验代码、结果、日志统一 Git 留痕，方便法务抽查。

5. 反事实仿真与修复

   • 若证实 H1：立即触发“数据分布告警”阈值重算，把最新 4 小时样本做 online fine-tune，学习率调低 10 倍，灰度 5% 流量；
   • 若证实 H2：回滚特征管道到昨日版本，对穿越特征补“时间戳白名单”校验；
   • 若证实 H3：与法务共建“可解释关键词”映射表，把黑盒策略改成“可审计日志+人工复核”双通道，减少误杀。

6. 灰度与监控
   灰度采用“时间-人群-场景”三维切片，每 2 小时观察业务核心指标（支付转化率、次留、投诉率）是否回归基线；同时把本次新增的所有分布指标、合规指标接入 Prometheus+Grafana，并设置“7 日漂移累计 >0.2 自动电话告警”给值班经理。

7. 复盘与知识沉淀（第二会议）
   48 小时后召开“根因复盘会”，用 5W2H 模板输出《AI 事故报告》，含：

   • 现象描述、影响范围、业务损失；
   • 根因图、数据证据、代码 commit；
   • 修复方案、灰度结果、长期监控；
   • 责任划分、后续 action、知识库链接。
     报告由法务审核后，10 个工作日内上传属地网信办备案。

第三会议：一周后做“事故演练”桌面推演，把本次异常包装成 red team 案例，随机注入预发布环境，验证监控能否提前 30 分钟捕获。

拓展思考

1. 如果异常只在“微信小程序”端出现，而 APP 端正常，如何排除“前端埋点加密”差异？
   答：让工程组在 nginx 层打印同一 user_id 的双端请求体 md5，对比加密后特征是否一致；同时检查微信通道是否自动把特殊字符做 unicode 转义，导致后续分词器切出 oov token。

2. 若异常输出表现为“模型置信度突然整体抬高 20%”，但业务指标未跌，是否还要升级？
   答：必须升级。置信度整体抬高可能是温度系数被误改、校准层失效，属于“模型人格突变”前兆；一旦遇到边缘输入，可能瞬间滑向极端回答，触发合规风险。

3. 当根因涉及第三方数据供应商“标注造假”，如何在合同中设置追溯条款？
   答：在 SLA 里加入“数据真实性保证金”机制：若因供应商标注造假导致线上事故，按实际业务损失 3 倍扣减保证金，并触发“数据溯源审计权”，允许甲方在 48 小时内进入乙方标注系统全量拉取操作日志，乙方不得拒绝。