> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 从模型到系统 - URL: https://www.hubwiz.com/blog/from-models-to-systems/ - Published: 2026-09-06T12:50:25.000Z - Updated: 2026-09-06T12:50:25.000Z - Description: 为什么软件工程已成为数据和 AI 专业人员的核心技能 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 多年来，数据科学家的形象非常容易识别。 一台笔记本电脑。 一个 Jupyter notebook。 一个大型数据集。 一些 Python。 几个图表。 也许中间有一个随机森林、XGBoost 模型或神经网络。 训练模型。检查指标。展示结果。 完成。 除了……并非如此。 因为迟早有人会问一个非常危险的问题： **"酷。我们可以把它投入生产吗？"** 突然之间，准确率、F1 分数和 RMSE 不再是唯一重要的事情。 有人需要通过 API 暴露模型。 有人需要对代码进行版本控制。 有人需要打包依赖项。 有人需要部署它。 有人需要确保两个更改同一代码库的开发人员不会破坏一切。 有人需要监控它。 有人需要在凌晨 2 点发现它何时中断。 最终有人需要在不关闭整个应用程序的情况下更新它。 在那个时候，有些事情变得清楚： **我们不再构建模型了。我们正在构建系统。** 而系统需要软件工程。 ## 1、Notebook 从来不是最终目的地 Notebook 没有什么问题。 它们是出色的工具。 我使用它们。你可能也使用它们。几乎每个处理数据的人都使用它们。 它们非常适合探索、实验、可视化和快速测试想法。 典型的工作流程可能如下所示： ``` 数据 ↓ 探索 ↓ 特征工程 ↓ 模型 ↓ 评估 ↓ 漂亮的图表 ``` 如果准确率看起来不错，每个人都很高兴。 但生产引入了一个完全不同的世界。 想象一下，你创建了一个预测客户是否会取消订阅的模型。 在你的 notebook 中，这可能出奇地简单： ```python 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](https://medium.com/@cesarmontenegrosilva/from-models-to-systems-0036f68f1600?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处