FDE Times 数据在招 FDE 职位 862▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 70在招公司 180支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

书籍与课程

吴恩达这门 11 小时课程,讲清模型交付后为何退化

Machine Learning in Production 讲透了范围、基线和概念漂移,但每个客户的度量仍要自己搭。

2017 年,吴恩达在旧金山 TechCrunch Disrupt 大会的台上演讲。
图片:TechCrunch / CC BY 2.0
分享微博

要点速览

  • 中级课程,约 11 小时,要求中级 Python 水平,适合准备转向 FDE 工作的软件工程师。
  • 有三个观点值得记住:先有基线再有模型;把漂移当作常态;让项目可复现、可追溯、可验证。
  • 课程给的是框架;只有把它用到有真实度量的项目上,才能形成真正的能力。
横向条形图,显示 200 张样本工单中的答对数:员工 182 张(91%),交付时的模型 176 张(88%),关键词规则 156 张(78%),第六周的模型 148 张(74%),低于关键词规则基线。
到第六周,模型已跌到它本要替代的关键词规则之下。来源:本文关于客服工单分派的假设示例。

模型可能在交付当天表现正确,从下一周起却越来越差,哪怕没人改过一行代码。Machine Learning in Production 是 DeepLearning.AI 推出、由吴恩达(Andrew Ng)讲授的课程,它直接切入这个悖论:与一般的建模不同,生产环境中的系统必须应对不断变化的数据。

对前线部署工程师(FDE)来说,这种情况可能就发生在驻场期间,而客户的第一个问题不会是模型架构,而是“为什么?从什么时候开始的?”

这门课值得花 11 小时,因为它讲端到端系统设计、基线构建和概念漂移的处理。至于每个客户具体要怎么度量,仍然得自己搭建。

谁适合上,按什么顺序学?

吴恩达是 DeepLearning.AI 的创始人、Coursera 的联合创始人。这门课源自 2021 年推出的 MLOps 专项课程,当时他与 Google 的 Robert Crowe 和 Laurence Moroney 共同讲授,理由是构建和部署生产系统仍需要大量手工工作。

据官方页面介绍,这门课为中级难度,总时长约 11 小时,通常分 3 周完成,每周 5 小时。

学员需要具备中级 Python 水平,课程面向 ML 新手或软件工程师。Coursera 将其列为独立课程,技能标签包括 MLOps 和模型部署,评分为 4.8。

第 1 周讲项目生命周期和部署,第 2 周讲建模中的难题,第 3 周讲数据定义和基线。时间充裕的话,按顺序学。

如果下周就要见客户,先看第 1 周,跳到第 3 周,再回头学第 2 周。

第 2 周围绕构建模型本身的难点展开,所以没那么紧迫:第一次会议时还没有模型,但基线必须马上就有,这样才知道最终的模型要超过什么分数线。

这是推迟,不是删掉,所以开始训练之前要把第 2 周学完。

还要清楚这门课不讲什么。三周内容没有一周专门讲 LLM 或 Agent,因此正在为客户构建检索增强生成(RAG)的人,学到的是一套运维思路,而不是能立即照搬的方案。

基线是给客户的第一个答案

课程讲端到端设计,从项目范围、数据需求到建模策略和部署要求,也讲如何建立模型基线。这是最值得记住的观点,因为它会改变与客户的整场对话。

假设一家公司想自动分派客服工单。拿 200 张已标注的工单来测:现有的关键词规则答对 156 张(78%),员工答对 182 张(91%),你的模型答对 176 张(88%)。单看 88% 没有意义。放在另外两个分数旁边,它比规则多对 20 张,但仍比人少对 6 张。

这样,会议就有了值得讨论的问题:每 200 张工单多错 6 张,能换来多少员工时间?客户能否接受这个取舍?所以到了客户现场,先要一份真实数据样本,测出他们现在的做法效果如何,再打开 notebook。

漂移是常态,不是事故

吴恩达在 2021 年的课程介绍中,把发现并修复数据错误、识别数据漂移和概念漂移列为 MLOps 的任务。这两种漂移容易被混为一谈,处理方式却不同。

回到工单的例子。客户推出了新产品,工单里开始出现模型从没见过的词:输入变了,这是数据漂移。解决办法是标注一批关于新产品的工单,加入训练集后重新训练;旧标签仍然正确,可以保留。

后来客户调整了部门,账单投诉改由另一个团队处理。工单看起来和以前一模一样,但正确答案变了,这是概念漂移。再多补旧类型的数据也没用,因为旧标签本身已经错了。必须先按新的组织架构修正标签,或删掉过时的样本,再重新训练。

要尽早发现这两种漂移,就要建立每周度量。每周随机抽取 200 张新工单,请客户的员工在看不到模型答案的情况下标注,再统计模型答对多少。

把这个数字和已有的两个分数线记在一起:交付时的 176 张,以及关键词规则的 156 张。阈值可以事先定好:低于 168 张(84%)就排查;低于 156 张(78%),就与客户商量暂时退回旧规则。

假设到第六周,样本中只答对 148 张,即 74%,甚至低于模型当初要替代的关键词规则。逐一阅读那 52 张答错的工单:新词很多,说明偏向数据漂移;熟悉的工单答案却变了,说明偏向概念漂移。

没有这项度量,你会从客户的投诉电话里才得知问题。所以一开始就要约定:谁来标注样本,谁接收告警。

无法追溯,就无从辩护

课程明确的目标,是做出一个面向生产环境、可复现、可追溯、可验证的 ML 项目。这听起来很枯燥,直到客户问起:为什么周二那张工单被派错了团队?而你不知道当时跑的是哪个模型、用的是哪份数据。

起步成本很低:每次部署时,记下数据版本、代码 commit 和评测结果。有了这三行记录,争执就变成有线索可查的调查。

课程还提出了一个 FDE 应当细读的约束:系统必须持续运行,成本尽可能低,性能尽可能高。实际中这三个目标相互牵制,所以只有当客户明确说出优先什么、愿意放弃什么,部署要求才算真正定下来。

把 11 小时变成求职的证据

不要止步于证书。把这套框架用到一个有度量的问题上,哪怕是自己用公开数据选的问题,这样才有具体的东西可讲。

按这个格式写一行简历:你测出的基线、相对基线的结果,以及你如何发现漂移。阅读 FDE 岗位描述时,留意 model deployment、MLOps、drift 这类词,并为每个词准备一个故事。

如果你能向面试官讲清楚模型跌破基线的那一刻,以及你接下来做了什么,对方就会明白你不只会训练模型。

这门课只需三周,但真正的考验在后面:在客户现场的第六周,数据已经变了,而你仍然要用数字作答。

这篇文章对你有帮助吗?

3 个信源
路线图上的下一篇 · 阶段 5: 部署上线在客户生产环境里干活的 FDE,该读《Release It!》客户 API 每次卡 30 秒,5 秒就能耗尽线程池;Nygard 的模式在设计阶段就能截断这种级联故障。