你是一家餐厅的老板。现在你手里有一份野心勃勃的菜单:要让客人吃到 AI 做出来的菜。可开业第一天就乱套了——有人研究出惊艳的新菜却上不了桌,有人把菜做得千篇一律却没人爱吃,烤箱半夜炸了没人会修,更糟糕的是,客人点的明明是川菜,后厨却在做甜品。 你很快发现,问题不在厨师手艺差,而在没有人把“四件事”分清楚:谁负责想新菜、谁负责把菜量化成标准工序、谁负责保证厨房不断电、谁负责看客人脸色定菜单。想清楚这四个位置,餐厅才转得起来。 AI 团队的故事一模一样。想新菜的、上流水线的、守厨房的、看客人脸色的,正好对应四个岗位——后面会逐一介绍。这篇文就像一个老板手册,带你认识这四位“员工”:岗位边界、能力要求、日常产出、交接流程、经常吵架的坑,以及从小吃摊到大酒楼,怎么一步步配人。
学懂这四大角色的分工与协作,你能快速看懂一个 AI 项目是怎么跑起来的:团队怎么搭、交接怎么设计、坑在哪、人怎么配。无论你是组建团队的管理者,还是想选方向的从业者,都能少走弯路。
可视化演示
动态演示AI团队四大角色解析的核心机制,通过总览/传输/转换/输出四种模式展示关键概念与交互流程。
本节配有交互动效(进入视口后自动加载,约 3KB)。
AI团队四大角色解析:MLEn ML Engineer 职责与 Data Scientist 核心机制可视化 AI团队四大角色解析整体架构与关键组件
角色全景图
一家餐厅要转起来,后厨必须有四条线同时工作:研发线想新菜,出餐线把菜量化成标准工序,后勤线保水电气和食品安全,店长线管菜单和客人预期。少任何一条,餐厅就塌一角——没人创新就没了招牌菜,没人量化就只能靠运气出餐,没人保修就随时停业,没人看客人就白做一桌菜。
AI 项目也是一条“从问题到价值”的流水线,可以拆成四段:定义问题、实验建模、工程上线、持续运营。这四段正好对应四个角色:AI 项目经理(AI PM)定问题边界,数据科学家(Data Scientist)做实验探索,机器学习工程师(ML Engineer)把实验变成产品,MLOps 负责让产品稳定运行。分工原则很简单:每个角色只对一段负责,但对整条线的结果负责。
角色齐全不等于团队高效,四个人之间的“协作损耗”常常吃掉一半产出。评估一个 AI 团队是否健康,核心是看“有效产出”和“三类损耗”的比值:
所以别急着招人,先按四段流程拆一遍,看哪一段没人管。就像开店先画后厨动线图,把“谁站在哪一口灶前”定清楚,餐厅才不会在开业第一天就乱套。
- 分子是有效产出不是写了多少代码、开了多少会,而是真正上线且被业务方持续使用的模型效果。
- 分母是三类损耗沟通成本是角色之间反复对齐消耗的时间;等待成本是上游不交付、下游干等的时间;返工成本是做错了推倒重来的时间。
- 比值决定了配置方向同样产出下损耗越小效能越高,四大角色配置合理的目标就是让分母最小。
数据科学家
研发主厨通常在“实验厨房”里工作——那里没有顾客,只有试吃员。他的任务不是出菜,而是回答一个问题:这道菜能不能做出来、值不值得做。十次实验失败九次是常态,因为失败本身也是在积累“什么不可行”的知识。
数据科学家就是 AI 团队的研发主厨。他的职责边界是:定义问题、数据探索、特征工程、建模实验、效果评估。他不写生产级代码、不负责并发性能、不背可用性指标——那些是出餐大厨和后勤的事。他的核心交付物不是“一个能跑的模型”,而是一份“能说服人的实验证据”。能力要求上,他需要统计直觉、算法理解、SQL/Python 基本功,以及把业务问题翻译成建模问题的洞察力。日常节奏是“短周期实验-评估-再假设”的循环。
这份实验证据的核心是评估指标。分类任务里,数据科学家最常用 F1 分数——精确率和召回率的调和平均,用来回答“这个模型在正样本上到底准不准、全不全”:
主厨把实验报告递给出餐大厨时,那道好吃的菜才算正式进入厨房。记住:数据科学家的交付物是一份带指标、带复现步骤的“菜谱”,而不是那盘已经凉了的菜。
- 精确率(Precision)模型说“是”的样本里,真正是正例的比例——好比研发主厨端出的菜里,客人真正满意的比例。
- 召回率(Recall)真实正例里,模型找回了多少——好比该试的食材种类,主厨是不是都试到了。
- 调和平均 F1精确率和召回率任一偏低,F1 都会被显著拉低,防止团队“偏科”。
机器学习工程师
出餐大厨的工作是“去运气化”:研发主厨凭手感撒盐,出餐大厨就把盐写成 3 克;研发说“小火慢炖”,他就标注 85 度 40 分钟。标准工序的意义在于:哪怕换一百个学徒来操作,做出来的都是同一个味道。
机器学习工程师就是 AI 团队的出餐大厨。他接收数据科学家的实验代码,把它变成健壮的训练管道、特征管道和推理服务:补齐异常处理、加上单元测试、做性能优化、管理版本依赖。数据科学家的 Jupyter Notebook 像实验厨房的手写菜谱,MLE 则把它变成每天能自动开火的标准化流水线。能力要求是扎实的软件工程功底:分布式训练、容器化部署、性能剖析、代码质量意识。交付标准很明确——没有数据科学家在场,流水线也能自己跑出同样的模型。
工程化的核心考察指标之一是吞吐量:线上服务的推理服务每秒能处理多少预测请求。可以用简化版 Little 定律来估算:
出餐大厨交出的不是某一道菜,而是“任意客人点单都能稳定上菜”的能力。机器学习工程师的验收标准是:没有数据科学家在场,流水线也能自己训练、自己推理、自己不崩。
- 并发请求数同一时刻有多少顾客排队等菜,对应线上同时打进来的预测请求数量。
- 平均响应时间一道菜从下单到上桌的平均耗时,对应一次推理从进来到返回结果的平均时间。
- 吞吐量(QPS)每秒能稳定出多少道菜;并发越高、响应越快,吞吐量越大。
MLOps工程师
后勤运营是餐厅里最不露脸、但最不能缺的人。水电气断了、烤箱温度漂了、食材变质了,都归他管。客人吃到的每一口安全菜,都是后勤在看不见的地方守出来的。
MLOps 就是 AI 团队的后勤运营。他的职责边界是:把“训练-评估-部署-监控-回滚”串成自动化闭环。具体包括模型版本与实验追踪、CI/CD 流水线、数据漂移检测、线上效果监控、异常回滚预案。模型上线不是终点,而是 MLOps 开始值班的起点。能力要求上,他需要熟悉 DevOps 工具链、容器与编排、监控告警体系,并且理解模型的特有风险——数据会变、效果会衰减、特征会缺失,这些是普通运维不处理的。
衡量后勤合不合格,看一个指标——服务可用性 A,也就是系统真正能对外服务的时间占比:
没有后勤,餐厅的“稳定”只是运气。MLOps 的价值在于:让“偶尔不出事”变成“系统性地不出事”。
- MTBF(平均无故障时间)烤箱连续正常工作多久才出一次故障,对应系统稳定运行的平均时长。
- MTTR(平均修复时间)烤箱坏了,从发现到修好需要多久,对应故障发现与恢复的平均耗时。
- 可用性 A正常运行时间占总时间的比例;MTTR 压得越低,可用性越接近 100%。
AI项目经理
店长不炒菜,但决定后厨炒什么。客人翻台快,他就推荐快手菜;周末家庭客多,他就推套餐。研发主厨兴奋地说“我想做分子料理”,店长只问三个问题:客人要吗?成本扛得住吗?什么时候能上桌?
AI 项目经理就是这个店长。他的职责边界是:澄清业务需求、排序优先级、制定里程碑、协调四个角色、向上汇报、管理业务方预期。他不写模型、不写代码、不值班盯监控,但“项目做不做、先做什么、做到什么程度算完”由他拍板。他的核心本事是当“需求翻译器”:业务方说“我要智能一点”,他得翻译成“把审核准确率提到 95%、误杀率降到 1%”。能力要求是沟通协调、领域理解、商业敏感和风险嗅觉。
需求永远比资源多,先做哪个?AI PM 常用 RICE 打分来排序——四个因子的比值越高,优先级越高:
店长最值钱的本事不是会炒菜,而是从不允许后厨做一桌没人点的菜。AI 项目经理把“业务想要什么”和“团队能做什么”对齐,团队至少能少做一半无用功。
- 触达(Reach)这道菜能覆盖多少客人,对应这个功能会影响多少用户。
- 影响与信心影响是每个用户身上的效果强度;信心是店长对这两个估算的把握程度,把握越低乘数越小。
- 除以工作量分母是人月投入;同样收益下投入越少越该先做,避免资源被低价值需求占住。
协作机制
厨房要顺畅运转,靠三样东西:传菜口(标准交接物)、开市前对单(固定节奏)、打烊复盘(回顾机制)。没有这三样,厨师们各炒各的,客人等到天荒地老,还容易“三个和尚没水喝”。
AI 团队对应三件套。第一,标准交接物:数据科学家交“实验报告”(带指标、带复现步骤),机器学习工程师交“发布包”(可部署的服务产物),MLOps 交“上线记录”(版本、监控、回滚预案)。第二,固定节奏:每日站会同步阻塞、每周模型评审会定夺模型去留、每迭代回顾复盘协作问题。第三,责任矩阵:每一件事指定 R(负责执行)和 A(最终拍板),明确到人,防止推诿。冲突仲裁的原则是:技术争议由 MLE 和 MLOps 用实验数据说话,需求争议由 AI PM 用业务价值拍板。
为什么沟通机制如此重要?因为人一多,沟通渠道会爆炸式增长:
传菜口越标准,出错的菜越少。协作机制的本质,是把“靠默契”升级为“靠流程”——这样无论换人、加人还是接新项目,团队都不会散架。
- 人数 n厨房里同时参与协作的人数,对应团队中需要互相对齐的成员总数。
- 两两配对n(n-1) 是所有有序配对的组合数,相当于后厨里所有可能的“互相喊话”。
- 沟通渠道 C除以 2 去掉重复方向,得到真正需要维护的沟通链路数。
常见痛点
餐厅最常见的四种事故:客人中途改菜单、实验菜量产不了、没人看烤箱、主厨的秘诀只存在他脑子里。这四种事故有个共同点:越晚发现,代价越贵。
AI 团队对应的痛点一模一样。需求漂移:业务方不断改目标,模型指标反复推翻重定,团队像在跑一场终点会移动的马拉松。模型脱节:数据科学家实验环境里效果拔群,一到生产环境就崩,因为数据分布、依赖版本、资源环境全变了。运维盲区:模型上线后没人盯着,数据漂移发生了也不知道,效果悄悄下滑。数据断层:经验都留在个人脑子里,文档缺失,人一走项目就瘫。
为什么这些痛点这么烧钱?因为修复成本随“发现阶段”指数上涨,这就是著名的“1-10-100 法则”:
破解思路也就清楚了:需求漂移靠 AI PM 锁定基线和变更评审,模型脱节靠标准交接物和预生产环境验证,运维盲区靠 MLOps 监控告警,数据断层靠文档与代码评审。越早发现越便宜——就像餐厅打烊前检查冰箱,总比凌晨三点冰箱坏了再抢修便宜得多。
- 基础成本需求刚被提出时,改一个方向几乎不花钱,这是最便宜的时刻。
- 阶段指数 s缺陷被发现得越晚,s 越大——需求阶段是 0,设计是 1,开发是 2,上线后是 3。
- 十倍放大每后移一个阶段,修复成本乘 10;所以需求漂移和运维盲区最烧钱。
团队规模配置
路边摊和大酒楼的后厨配置完全不同,但四条职能线哪条都不能缺——区别只是由谁兼任。配置团队的基本逻辑不是“凑齐四个人”,而是“盘活四个职能”。
微型团队(1-3 人):一人身兼数职,通常是一个“全栈 ML 通才”——自己当数据科学家做实验、自己写工程代码,AI PM 由创始人或业务负责人兼任,MLOps 只做最轻量的监控和手动部署。成长团队(5-10 人):数据科学家和机器学习工程师专职化,AI PM 专职,MLOps 由 MLE 兼任或配 1 人。成熟团队(10+ 人):四大角色各自成组,MLOps 平台化,为多个项目组共用基础设施。扩展原则很简单:规模跟着“生产模型数 × 迭代频率”走,不跟着人头走。
什么时候该专职配 MLOps?可以用一个经验公式估算:
店开大了再雇专职后勤,但哪怕只有一口灶,也得有人负责看火。团队规模可以小,四个职能的“责任归位”却不能少——这就是从小吃摊到大酒楼,一路配人的核心心法。
- 生产环境模型数餐厅里实际在售的菜品数量,对应线上稳定运行的模型个数。
- 人均可维护模型数一个后勤员工能同时盯住的烤箱台数,对应一名 MLOps 能维护的模型数(通常 3-5 个)。
- 估算后向上取整模型只有 2 个时可以兼任,超过 10 个就必须组建专职 MLOps 小组。
AI 应用场景
场景1:银行反欺诈团队从“临时工”到“正式编制”
阶段:团队组建与角色配置(对应“角色全景图”与“团队规模配置”)
解决的问题:传统 IT 团队把 AI 项目当普通软件做:需求写死、上线完事、没人看模型效果。结果模型上线三个月就失灵,业务方抱怨“AI 是骗人的”。用四角色框架重新组队后,每条职责线都有了明确归属,模型的“研发-工程-运营”不再断链。
具体案例:某城商行把反欺诈建模外包给数据科学家,却没人做工程化和监控,模型每次更新要两个月。后来按四角色框架补了 2 名机器学习工程师和 1 名 MLOps,建立“实验报告 → 发布包 → 上线记录”的交接流,模型两周迭代一次,误报率下降 40%。
场景2:电商推荐系统“研产运”脱节的修复
阶段:协作机制与痛点破解(对应“协作机制”与“常见痛点”)
解决的问题:数据科学家在离线实验里 AUC 很高,线上效果却纹丝不动——典型的“模型脱节”。用标准交接物和预生产环境验证,加上 MLOps 的线上灰度与监控,把离线指标和线上指标对齐,让实验结论真正变成业务收益。
具体案例:某电商团队每季度大更新一次推荐模型版本,总在大促前翻车。引入“模型评审会”:数据科学家讲实验报告,机器学习工程师讲压测结果,MLOps 讲灰度计划,AI PM 拍板上不上线。从此大促前不再通宵回滚,推荐点击率稳定提升 12%。
场景3:创业公司 MVP 阶段“一人四角”
阶段:团队规模配置(对应“团队规模配置”)
解决的问题:预算有限,四个专职角色养不起。按“职能不缺口”原则,一个全栈 ML 通才 + 创始人兼职 AI PM + 云平台托管监控,把最轻量的 MLOps 交给托管服务,先跑通商业闭环再扩编。
具体案例:一家 3 人的 AI 法律文书工具初创团队,用 AutoML 做初版模型、云函数部署推理服务、第三方监控打点,跑通第一个付费客户。用户过万后,再逐步扩招专职 MLE 和 MLOps,把兼职变成专职。
Python 演示
# -*- coding: utf-8 -*-"""Simulate a four-role AI team: PM/DS/MLE/MLOps handoffs."""import random class DataScientist: def __init__(self, name): self.name = name self.exp_count = 0 def experiment(self, data_quality): self.exp_count += 1 if data_quality >= 0.7: f1 = round(0.85 + data_quality * 0.05, 3) return {"status": "ok", "model": "xgb_v%d" % self.exp_count, "f1": f1} return {"status": "fail", "model": None, "f1": 0.0} class MLEngineer: def __init__(self, name): self.name = name def productize(self, exp_result): if exp_result["status"] != "ok": return None return {"pipeline": "train_pipe_v1", "model": exp_result["model"], "qps": 1200} class MLOpsEngineer: def __init__(self, name): self.name = name self.deploy_count = 0 def deploy(self, artifact): if artifact is None: return None self.deploy_count += 1 return {"endpoint": "/v1/predict", "model": artifact["model"], "uptime": 0.999} class AIPM: def __init__(self, name): self.name = name def review(self, requirement, data_quality): if requirement != "risk_ctrl": return "pending" if data_quality < 0.3: return "rejected" return "approved" def run_rounds(team, rounds): results = [] for i in range(1, rounds + 1): quality = random.random() decision = team["pm"].review("risk_ctrl", quality) if decision != "approved": results.append("round %d: PM rejected, data too poor" % i) continue exp = team["ds"].experiment(quality) art = team["mle"].productize(exp) svc = team["mlops"].deploy(art) if svc is not None: results.append( "round %d: %s online, qps=%d, uptime=%.3f" % (i, svc["model"], art["qps"], svc["uptime"]) ) else: results.append("round %d: DS failed, back to experiment" % i) return results def main(): random.seed(7) # 固定随机种子让结果可复现 team = { "pm": AIPM("pm"), "ds": DataScientist("ds"), "mle": MLEngineer("mle"), "mlops": MLOpsEngineer("mlops"), } for line in run_rounds(team, 5): print(line) if __name__ == "__main__": main()
def experiment(self, data_quality):数据科学家的实验入口,“食材新鲜度”(数据质量)决定实验成败if data_quality >= 0.7:数据质量达标才产出候选模型,否则返回失败状态,不向下游交接{"status": "ok", "model": "xgb_v%d" % self.exp_count, "f1": f1}把模型名与评估指标打包成标准交接物def productize(self, exp_result):机器学习工程师只认数据科学家的交接物,交不出合格实验就拒绝接力if artifact is None:MLOps 对不合格产物直接打回,不部署到生产环境self.deploy_count += 1每次成功部署记一笔账,便于统计“上线了多少个模型”if decision != "approved":AI PM 把关:数据质量太差时先砍需求,避免团队白干random.seed(7)固定随机种子,让每次模拟的结果可以复现
常见误区
误区以为数据科学家的工作就是调模型参数,精度刷上去就完事,上线交给别人就行。
正解数据科学家的核心产出是“经过验证的业务假设 + 可复现的实验证据”,调参只是实验的一环。他还要做数据探索、特征工程、业务问题建模,并用 F1 等指标证明“这道菜值得上桌”。就像研发主厨要知道客人喜欢什么口味,而不是只会背菜谱。
为何常见:网上教程大多教你调参和跑模型,容易让人误以为“调模型 = 全部工作”。
误区觉得 MLOps 就是部署个服务、盯盯 CPU 和内存,和传统后端运维没区别。
正解MLOps 要管模型版本、数据漂移、特征一致性、灰度发布与回滚,还要把“训练-评估-部署-监控”串成自动化闭环。普通运维面对的是稳定的软件逻辑,而模型是会被数据变化“喂坏”的活物——这正是 MLOps 独有的战场。
为何常见:名字里带“Ops“,很容易被当成老运维换皮;其实它的难点全在”ML 特有的不确定性”。
误区觉得 PM 只要会开会、写周报、催进度,技术细节完全不用懂。
正解AI PM 至少要懂“数据、模型、工程”三者的边界,才能把业务需求翻译成可验收的量化指标,才能判断“准确率 0.9”是不是真的给业务带来了价值。好比店长不炒菜,但必须知道一道菜大概做多久、成本几何,否则会被厨师和客人同时牵着走。
为何常见:传统 PM 的“管人排期”印象太深,忽略了 AI 项目特有的技术不确定性。
误区以为加人就能提速,于是四大角色各配一堆人,结果更乱了。
正解沟通渠道按 n(n-1)/2 增长,每加一个人都在增加协作成本;AI 项目的瓶颈常常在数据质量和需求澄清,不在人头数量。正确的做法是先看流水线哪一环最堵——是实验没人做,还是上线没人管——再针对性补人。
为何常见:“人多力量大”的直觉太强,忽略了 AI 项目协作损耗远大于体力劳动。
误区认为模型部署上线就大功告成,后面出了问题再找人临时修。
正解上线只是开始。数据漂移、特征缺失、效果回退都是常态,需要 MLOps 的监控告警和反馈回流机制持续运转。没有“看火的人”,模型会悄悄“过期”。就像餐厅开业不等于一劳永逸,每天还要查食材、盯烤箱。
为何常见:项目管理思维普遍重视“交付”、轻视“运营”,而 AI 系统恰恰是需要长期照看的活系统。
面试题
Q1. 在一家“AI 餐厅”里,数据科学家最像哪个角色?
- A.研发新菜、试吃迭代的美食研究员← 正确答案
- B.端菜收银、招呼客人的服务员
- C.水电维修、清扫后厨的勤杂工
- D.定菜单、管预算、看店面的店长
答案:A。数据科学家的核心是探索与验证,对应研发新菜的美食研究员。服务员对应业务交付角色,勤杂工对应 MLOps,店长对应 AI PM,各自职责不同。
Q2. 数据科学家交给机器学习工程师的“菜谱”,本质上是?
- A.可复现的实验记录与模型评估结论← 正确答案
- B.已上线的生产级预测服务代码
- C.完整的商业计划书与财务预算表
- D.客户投诉意见的汇总统计表
答案:A。数据科学家的交付物是带指标、带复现步骤的实验报告,是“证据”而非“成品”。生产级代码由机器学习工程师写,商业计划书是 PM 的活,投诉统计不是模型交付物。
Q3. 谁最该对“模型上线后持续稳定运行”负责?
- A.数据科学家:模型是他调出来的
- B.机器学习工程师:代码是他写的
- C.MLOps 工程师:部署监控是他的主场← 正确答案
- D.AI 项目经理:一切责任由他来扛
答案:C。持续稳定运行属于 MLOps 的职责边界,包括监控、告警和回滚。DS 对实验效果负责,MLE 对工程实现负责,PM 是协调者而非最终兜底人。
Q4. AI 项目经理把业务需求“翻译”给团队时,核心动作是什么?
- A.转化为可量化的模型指标与验收标准← 正确答案
- B.自己直接替数据科学家挑选算法
- C.要求全员加班压缩项目排期
- D.原样转发需求文档给团队即可
答案:A。“智能一点”必须变成“准确率 95%、误杀率 1%”才算翻译完成。替 DS 选算法是越界,压榨加班和原样转发都不是需求翻译,只会让团队做错方向。
Q5. 一个 5 人 AI 团队,全员两两沟通的渠道有多少条?
- A.5 条
- B.10 条← 正确答案
- C.15 条
- D.20 条
答案:B。沟通渠道数 C = n(n-1)/2 = 5×4/2 = 10。这个公式解释了为什么人越多越需要标准化的沟通节奏,否则协作成本会迅速吞掉产出。
Q6. 下列哪些属于 MLOps 工程师的典型日常工作?
- A.搭建模型上线流水线并做灰度发布← 正确答案
- B.监控推理延迟与数据漂移告警← 正确答案
- C.撰写商业计划书和融资路演 PPT
- D.参与数据标注与清洗的排期
答案:AB。A 和 B 分别是 MLOps 的“自动化流水线”和“监控与运维”职责。商业计划书是 AI PM 或创始人的事,数据标注排期通常由 DS 或数据团队负责。
Q7. 模型离线指标很好,业务部门却迟迟不用,最可能缺哪个角色的作用?
- A.数据科学家:实验做得不够完整
- B.机器学习工程师:推理接口性能太差
- C.AI 项目经理:需求与预期管理没跟上← 正确答案
- D.MLOps 工程师:监控面板做得不好看
答案:C。离线指标好但业务不用,往往是“需求对齐”出了问题——模型解决的问题根本不是业务最痛的,或者验收标准没对齐。这属于 AI PM 的“需求翻译器”和“预期管理”职责;纯技术指标解决不了“没人用”。
Q8. 哪些现象说明团队正在经历“需求漂移”?
- A.模型评估指标反复推翻重定← 正确答案
- B.验收标准临近上线又大改← 正确答案
- C.模型效果好却没有人使用← 正确答案
- D.工程师频繁申请加班调休
答案:ABC。指标反复变、验收标准临上线大改、做出来没人用,都是“终点在移动”的需求漂移信号。加班调休只是工作状态,不是需求漂移的判据。
Q9. 3 人初创 AI 项目最合理的分工策略是?
- A.必须配齐四大专职角色缺一不可
- B.每人身兼数职按阶段动态补位← 正确答案
- C.全部外包给供应商不做内部团队
- D.只招算法博士工程问题以后再谈
答案:B。按“职能不缺口”原则,3 人团队应一人多岗:全栈 ML 通才兼 DS 和 MLE,创始人兼 AI PM,MLOps 用托管服务兜底。配齐专职不现实,全外包会失去核心能力,只招算法博士会埋下工程地雷。
Q10. 模型上线后 F1 从 0.9 掉到 0.7,合理的排查方式包括?
- A.先由 MLOps 触发告警排查数据分布漂移← 正确答案
- B.由数据科学家复查训练与推理数据一致性← 正确答案
- C.由项目经理确认业务标签口径是否已改变← 正确答案
- D.不做根因分析直接让工程师通宵重训
答案:ABC。效果下滑要系统性排查三种根因:数据漂移(MLOps 监控)、训练/推理数据不一致(DS 复查特征口径)、标签定义变化(PM 确认业务口径)。无脑重训不解决根因,是典型的“返工成本放大”行为。