从模型到系统

多年来，数据科学家的形象非常容易识别。

一台笔记本电脑。 一个 Jupyter notebook。 一个大型数据集。 一些 Python。 几个图表。 也许中间有一个随机森林、XGBoost 模型或神经网络。

训练模型。检查指标。展示结果。

完成。

除了……并非如此。

因为迟早有人会问一个非常危险的问题：

"酷。我们可以把它投入生产吗？"

突然之间，准确率、F1 分数和 RMSE 不再是唯一重要的事情。

有人需要通过 API 暴露模型。 有人需要对代码进行版本控制。 有人需要打包依赖项。 有人需要部署它。 有人需要确保两个更改同一代码库的开发人员不会破坏一切。 有人需要监控它。 有人需要在凌晨 2 点发现它何时中断。 最终有人需要在不关闭整个应用程序的情况下更新它。

在那个时候，有些事情变得清楚：

我们不再构建模型了。我们正在构建系统。

而系统需要软件工程。

1、Notebook 从来不是最终目的地

Notebook 没有什么问题。

它们是出色的工具。

我使用它们。你可能也使用它们。几乎每个处理数据的人都使用它们。

它们非常适合探索、实验、可视化和快速测试想法。

典型的工作流程可能如下所示：

数据
  ↓
探索
  ↓
特征工程
  ↓
模型
  ↓
评估
  ↓
漂亮的图表

如果准确率看起来不错，每个人都很高兴。

但生产引入了一个完全不同的世界。

想象一下，你创建了一个预测客户是否会取消订阅的模型。

在你的 notebook 中，这可能出奇地简单：

model.fit(X_train, y_train)
predictions = model.predict(X_test)
accuracy_score(y_test, predictions)

也许你会得到：

准确率：92%

很好。

现在想象你的公司希望每次客户打开移动应用程序时都使用此预测。

突然之间，你的模型需要成为这样的东西的一部分：

客户
   ↓
移动应用
   ↓
后端 API
   ↓
特征服务
   ↓
ML 模型
   ↓
数据库
   ↓
业务规则
   ↓
客户收到优惠

而在所有这些周围：

        ┌──────────────────────┐
        │     监控       │
        │ 日志 • 指标    │
        │ 跟踪 • 告警    │
        └──────────────────────┘
                   ↑
                   │
应用 → API → 服务 → 模型 → 数据库
                   │
                   ↓
        ┌──────────────────────┐
        │ 安全 • CI/CD        │
        │ 测试 • 版本控制      │
        └──────────────────────┘

模型不一定变得更复杂。

模型周围的系统变得更复杂了。

这种差异是理解现代数据和 AI 工作最重要的事情之一。

2、你的模型只是一个组件

通过现代 AI 应用程序，这一点变得更加清晰。

考虑一个由大型语言模型驱动的聊天机器人。

从外部看，它可能看起来很简单：

用户 → LLM → 答案

但真实的系统很少看起来像那样。

它们看起来更像：

                         ┌──────────────┐
                         │ 向量数据库    │
                         └──────▲───────┘
                                │
用户 → 前端 → API → AI 代理 → LLM
                         │       │
                         │       ├── 外部 API
                         │       │
                         │       ├── 数据库
                         │       │
                         │       └── 工具
                         │
                         ▼
                日志 / 跟踪 / 指标

现在想象这个代理可以搜索文档、调用 API、访问数据库和执行工具。

有趣的 ML 问题可能是：

我们应该使用哪个模型？

但工程问题很快变得更大：

当外部 API 失败时会发生什么？ 当 LLM 需要 30 秒来回答时会发生什么？ 如果模型产生无效的 JSON 会怎样？ 我们如何重试失败的请求？ 我们如何防止同一个工具被调用 100 次？ 我们如何控制对敏感数据的访问？ 我们如何知道哪个步骤导致了错误的答案？ 我们如何部署新版本？ 我们如何回滚它？ 我们如何测试部分概率性的东西？

这些主要是机器学习问题。

它们是软件工程问题。

3、角色开始重叠

这种转变正在多个职业中发生。

数据科学家

传统上专注于：

• 统计学；
• 实验；
• 建模；
• 特征工程；
• 可视化。

但越来越期望理解：

• Git；
• API；
• 测试；
• 打包；
• 云环境；
• 部署基础知识。

数据工程师

他们已经更接近软件工程了。

现代数据平台涉及分布式系统、编排、API、基础设施、测试和可靠性。

数据管道是软件。

而每天处理数十亿条记录的管道绝对不仅仅是"SQL"。

机器学习工程师

这个角色一直存在于 ML 和软件工程之间。

ML 工程师必须理解模型，但也要理解如何将这些模型转化为可靠的服务。

在许多组织中，工作本质上是：

机器学习
      +
软件工程
      +
基础设施

AI 工程师

生成式 AI 使这种重叠更加强烈。

现代 AI 应用程序涉及：

• LLM API；
• 代理；
• RAG；
• 向量数据库；
• 队列；
• 缓存；
• 身份验证；
• 工具执行；
• 提示管理；
• 可观察性；
• 评估框架。

AI 模型可能是最复杂的组件。

但它仍然只是一个组件。

4、那么……每个人都需要成为软件工程师吗？

不。

这种区别很重要。

数据科学家不需要知道高级后端工程师所知道的一切。

ML 工程师不一定需要成为前端开发专家。

数据工程师不需要花六个月时间研究编译器设计。

重点不同。

数据和 AI 专业人员越来越需要软件工程素养。

把它想象成一种通用的工程语言。

你应该理解足够多的内容，以便参与关于系统如何构建的对话。

至少我认为，现代数据和 AI 专业人员从理解以下领域受益匪浅：

你不需要在所有领域都有专家级的知识。

但不知道它们是什么正变得越来越昂贵。

5、从"它能工作"到"它能持续工作"

软件工程引入了一种重要的思维方式转变。

在数据科学中，我们经常庆祝这个：

它能工作。

在软件工程中，问题变成了：

它能持续工作吗？

听起来很相似。

但并非如此。

想象一下，你训练了一个欺诈检测模型。

它表现得很出色。

然后你部署了它。

一周后：

• 输入模式发生变化；
• 一个上游服务开始发送空值；
• 请求翻倍；
• 响应延迟增加；
• 依赖项被更新；
• 内存使用量增长；
• 模型端点开始返回错误。

模型本身可能仍然完全正常。

系统失败了。

这就是为什么可靠性、可观察性、测试和容错等概念很重要。

生产系统必须经受住现实的考验。

而现实是混乱的。

6、一个简单的例子：notebook 与生产

假设我构建了一个推荐模型。

实验版本可能需要：

1 个 notebook
1 个数据集
1 个模型

生产版本可能需要：

Git 仓库
      ↓
数据管道
      ↓
特征处理
      ↓
模型训练
      ↓
模型注册表
      ↓
API 服务
      ↓
Docker 容器
      ↓
云基础设施
      ↓
CI/CD 管道
      ↓
监控
      ↓
告警

相同的模型。

完全不同的工程问题。

这就是为什么组织有时会发现一些令人惊讶的事情：

构建模型是容易的部分。

运营它是困难的部分。

7、另一个算法可能不是你最大的职业升级

这有点令人不舒服。

数据专业人员喜欢学习模型。

我们学习线性回归。

然后是逻辑回归。

决策树。

随机森林。

XGBoost。

SVM。

神经网络。

Transformer。

然后是上周二 arXiv 上出现的任何东西。

学习算法很重要。

但在某个时候，学习再多一个算法的边际价值可能小于学习如何：

• 编写干净的 Python 模块；
• 构建 API；
• 创建自动化测试；
• 使用 Docker；
• 配置 CI 管道；
• 部署服务；
• 监控应用程序。

对于许多数据科学家来说，下一个主要的职业升级可能不是另一个机器学习课程。

它可能是学习软件工程。

不是因为机器学习不那么重要。

而是因为当你能把它变成人们实际使用的东西时，机器学习变得更加有价值。

8、AI 让编码变得更容易——但工程更重要

这里有一个有趣的悖论。

生成式 AI 大大降低了编写软件的门槛。

今天我可以问一个 LLM：

"为此模型创建一个 FastAPI 端点。"

几秒钟后，我就有了代码。

我可以问：

"编写单元测试。"

完成。

"创建一个 Dockerfile。"

完成。

"生成一个 GitHub Actions 管道。"

完成。

很容易得出结论，软件工程知识因此变得不那么重要。

我认为相反的情况可能正在发生。

AI 让代码生成变得更容易。

但生成代码和工程系统是非常不同的活动。

仍然需要有人决定：

架构应该是什么样子？ 状态应该在哪里？ 哪个组件负责哪个职责？ 当某事失败时会发生什么？ 服务应该如何通信？ 我们应该监控什么？ 我们应该测试什么？ 我们应该如何保护系统？ 何时应该使用队列而不是同步 API 调用？ 如果流量增加 100 倍会怎样？

AI 助手可以生成 Kubernetes 清单。

这并不自动意味着你知道 Kubernetes 是否合适。

它可以生成十个微服务。

这并不意味着你的应用程序需要十个微服务。

它可以极快地生成代码。

而这实际上可能使工程判断更有价值，而不是更少。

这里有一个有用的区别：

AI 可以帮助你编写代码。你仍然需要理解系统。

9、T 型数据和 AI 专业人员的崛起

我认为未来越来越属于通常所说的 T 型专业人员。

T 的水平部分代表广泛的工程知识：

Git | API | 测试 | 云 | Docker | CI/CD | 数据库 | 可观察性
──────────────────────────────────────────────────────────────────────────
                              │
                              │
                              │
                              ▼
                     深度专业化

而垂直部分代表你的专业。

对于一个人：

统计学
机器学习
实验

对于另一个人：

数据平台
分布式处理
数据架构

对于另一个人：

LLM
代理
RAG
AI 系统

你不放弃专业化。

你用足够的工程知识围绕它，使专业化在更大的系统中有用。

这是一个重要的区别。

10、模型存在于系统中

也许总结一切最简单的方法是：

模型不是孤立存在的。

它消费另一个系统产生的数据。

它在另一个系统维护的基础设施上运行。

它通过另一个系统暴露预测。

它的输出影响另一个系统。

它生成另一个系统消费的日志。

它被另一个系统监控。

它通过另一个系统更新。

一旦你通过这个镜头看待机器学习和 AI，软件工程看起来就不再像一个可选的相邻学科。

它成为基础的一部分。

11、从模型到系统的转变

未来几年最有价值的数据和 AI 专业人员可能不是那些知道每个算法的人。

也不会每个人都突然成为传统的软件工程师。

相反，最强的专业人员可能是那些能够轻松地说两种语言的人：

数据和模型的语言

以及

软件和系统的语言。

他们可以在 notebook 中进行实验。

但他们也理解 notebook 之后必须发生的事情。

他们可以评估 ML 模型。

但他们也可以讨论 API、部署、可观察性和可靠性。

他们理解概率。

但他们也理解生产。

因为真正的挑战不再仅仅是：

我们能构建一个好的模型吗？

越来越多的是：

我们能围绕它构建一个可靠的系统吗？

这就是从模型到系统的旅程。

我怀疑这将在未来几年定义数据和 AI 工作的很大一部分。

原文链接：From Models to Systems

汇智网翻译整理，转载请标明出处