5步从数据工程师转型AI工程师

听着，你不是非转不可，但如果你想转，那就来看看吧。另外，你可能应该去找找那些现在 LinkedIn 上突然冒出来的、满嘴智慧和远见的 AI 工程师。也许他们知道到底在发生什么。 不管怎样，我已经构建了几个多 Agent 的 POC，有些在 Databricks 平台上，有些是更定制化的。

我已经对各种"AI 的玩意儿"捣鼓够了，至少能让自己变得有点危险了。让我上吧，教练。

我只是互联网上一个注意到涉及"AI"或"Gen AI"（文艺青年这么叫的）的工作岗位在激增的人。而且，嘿，为什么不试试呢？大家已经在为被 AI 抢走工作而恐慌了。

1、AI 热潮

连那些银行家们也在趁 AI 的热潮捞一笔，把成千上万个岗位放在 AI 的砧板上。

嘿，甚至连我们的老朋友扎克伯格似乎也被卷入了这股疯狂，就像旅鼠一样；他们都要从同一个悬崖跳下去。一个跳了，你就知道其他的一定会紧跟其后。Meta 报告了创纪录的利润，但这并没有阻止他们。一旦老堤坝上戳了个洞，水就会迅速涌来。

那我们这些小虾米怎么办呢？最可能在末世后的未来中为了残羹剩饭而争斗。

不管怎样，如果能找到一线希望，我宁愿保持乐观。如果你知道去哪里找，希望是存在的。务实的态度、半杯满的心态在克服各种障碍时大有帮助。

我猜如果我们打不过他们，就必须加入他们。

我说的不是简单地在软件开发工作流中使用 AI；我说的是构建 AI 和 Agent 系统。 拉开帷幕，看看 Oz 在搞什么。

我当然有自己关于数据工程师必须学习什么才能成为 AI 工程师的想法，但与其猜测，不如去 LinkedIn 上做个非正式搜索，看看公司在"AI 工程师"职位描述中要求什么技能和技术。

归根结底，如果你想成为 Gen AI 工程师，就必须拥有和学习市场需要你具备的技能。让我们像正经工程师一样来做这件事。

老派的。说不定我们甚至会自己写代码，*倒吸一口气。

我把 LinkedIn 上 30 个 AI 工程师职位描述爬取到了文本文件中。我们可以做一个简单的词频统计，也许再加个词云，看看这个岗位到底需要什么技能。

2、代码

这是其中一个文本文件的示例。

现在，让我们写一些 Rust 代码来完成这些脏活，看看这些 AI 工程师岗位到底在说什么。

结果让我非常惊讶，也很有趣，和我的预期完全不同。我的意思是，确实有 RAG 和 Agents 之类的东西，但我以为会看到像……推理、langchain、langgraph、api、前端等等之类的词。

确实，恰恰相反。

往好的方面看，我亲眼所见，构建 AI 系统更多是关于系统设计和架构，再加上一些特定工具。

cargo run -- word-count

然后是词云……

cargo run -- word-cloud

我不确定这更能说明什么：是 AI 领域的整体状况，还是公司对什么造就了优秀 AI 工程师的看法。

再说一次，作为一个在 Databricks 和其他地方构建过不少 Agent 系统的人，我基本同意这些被要求的技能列表。学一个框架比如 LangChain 很容易；但如果没有经验，要拥有能帮助构建多 Agent 工作流的系统设计经验就没那么容易了……因为你处理的就是……多个系统连接在一起的东西。

让我们深入分析我们的发现，总结转型为 AI 工程师需要什么。

3、AI 工程师的前 5 项技能

我想让这些建议从我过去几年构建 AI 系统的实际经验出发，同时结合实际数据说了什么（双关语不是故意的）。好的意愿终究只是意愿，但看到这个对 30 个 AI 工程师职位描述的词频分析，有助于确认我们走在正确的道路上。

说实话，这听起来就像是一个优秀的数据工程师需要的技能，从我个人的经验来看，确实如此，只是多加了一些稀奇古怪的工具集。

3.1 理解系统设计（架构）

当我刚开始玩弄 Agent 和 AI 系统——也就是说构建它们——的时候，我注意到了一些意想不到的事情。基本上，我在构建一堆需要相互通信和协作的独立"系统"。

• 这是一个经典的系统设计问题。

我们看到这一点在 AI 工程师职位描述中最常见的词就是"系统"这个事实中得到了印证。为什么？因为 LLM 和 Agent 在实际业务中的用例通常需要跨一系列云资源、端点和工具的数据和集成。

        [ 用户 / 应用 ]
                |
                v
         +----------------+
         |   AI Agent     |
         | (推理)         |
         +----------------+
            /    |     \
           /     |      \
          v      v       v

  [向量数据库] [API 调用] [数据湖]
   (记忆)      (行动)      (原始数据)

          \      |      /
           \     |     /
            v    v    v

         +----------------+
         | 编排层         |
         |  (胶水逻辑)    |
         +----------------+
                |
                v
         [ 云服务 ]
    (计算、认证、存储)

每一个都是一个独立的系统，必须协同工作才能完成任务。如果你好奇这可能是什么样子，可以读读我的文章《傻瓜式 Agent AI》，或者也许我的另一篇文章《构建高级 Agent AI》。

显然，要转型为 AI 或 Gen AI 工程师，你必须精通系统设计，这是一个已经存在了很长时间的东西。

• 如果你想了解更多，可以看看 John Crickett 在 GitHub 上关于系统设计的资源。

与数据库、API、端点、工具、MCP 服务器、向量、其他 Agent 通信……清单列不完。再加上日志、可追溯性、监控、性能的复杂性……跨这些完成上述所有操作的复杂工作流和应用……这些都是经典的系统设计问题。

3.2 理解多模态数据（以及一般意义上的数据）

看到这个词的时候我忍不住笑了，但这也是我多次评论过的东西。构建 LLM 和 AI 系统 90% 是数据管道，加上一点编排。数据是第二常见的词。

大多数我接触过的 AI 和 Agent 系统都严重依赖数据。可能是 Delta Lake 或 Iceberg 中的湖屋数据，Postgres 表，RAG 支撑的非表格数据如 PDF 等。不管怎样，这些 AI Agent 通常需要大量的上下文和与数据的交互——无论是向量数据还是其他类型——才能被认为是有价值的。

我们生活在一个数据驱动的世界；这已经持续了很长时间，AI 热潮更是加剧了这一点。构建 AI 系统需要专家级别的数据理解力，这毫不令人意外。

这就是经典数据工程与 AI 系统所需技能分道扬镳的地方。是的，我们可以通过各种连接器把 Postgres 中的表格数据接入湖屋，但集成到 LLM 系统中所需的大部分数据并不是表格形式的。

• RAG 和向量
• 知识图谱

例如，读读下面我基于 PDF 和 Word 文档构建 Databricks 知识助手的文章。这不是普通的数据工程。

我们大多数人都不习惯处理这样杂乱无章的非结构化数据。你不能把所有东西都扔进一个 S3 存储桶里——我是说，也许你可以，但从长期和可扩展性的角度来看，这不是个好主意。

随着 Agent 工作流的兴起，我们不再只是处理以表格数据为主导的经典数据模型。嗯，是的，我们仍然在处理表格数据，但我们现在也在处理音频、视频、PDF……大量我们历史上从未集成到数据平台中的数据。

例如，以下是 AI 工程师职位描述中的一段摘录：

数据工程卓越

- 在处理来自不同来源、格式冲突的数据规范化方面有丰富经验
- 对准确性有执念，99% 是不够的——兼容性数据必须正确
- 有构建自动化验证和冲突解决系统的经验
- 能够对复杂的业务领域进行建模（你将学习重型设备相关知识）

……或者另一段：

具有 AI 云基础设施、数据管道、编排方面的经验

归根结底，AI 工程师似乎是专门处理数据和数据在系统间流动的系统架构师。

如果你对奇怪形状的数据、难题以及未来可能的样子感兴趣，读读 Byoyant Data 的这篇文章。

3.3 云为王

这个有点出乎我的意料，不知道为什么，但说起来也合理，同时也似乎是基本门槛。偶尔我会遇到一些没被 AWS 和 IAM 的岩石碾过的可怜灵魂。

通常是一些企业的情况，"云"被严加看管，远离一千个百无聊赖的开发人员的窥探之手。

我能感受到那位 CTO 的焦虑。

说实话，我不打算在这里花太多时间，只是想说，是的，任何从事 AI 系统工作的人很可能都在一家严重依赖云基础设施进行所有运营的"前瞻性公司"工作。

我个人的看法是，在这个语境下，"云"与以下内容有关……

• CI/CD
• IaC（基础设施即代码）
• SaaS 服务

以下是 AI 工程师职位描述中的一些摘录……

- 云数据库和生产部署。
- 熟悉 Docker、云（AWS/GCP）、快速迭代
- 云和 DevOps 经验
- AWS 等云环境

他们只是在说我们早就知道的事情：如果你想成为 AI 工程师，你将在很多公有云（AWS、GCP、Azure）等中工作。同样，也会使用许多 SaaS 提供的服务，也许用于推理，这些服务运行在别人的云上。

• 这些是被设计和部署的 AI 系统；它们必须在某处运行和部署，那个地方不是某人的桌子底下，而是在基于云的环境中通过 CI/CD 部署。

说真的，这只是一个很好的提醒：如果你还没有太多使用和部署到 AWS 等主要云提供商的经验，你可能应该注册一个账户开始摸索。

3.4 工作流

不骗你，当我看到这个词出现在列表顶部时，我可能发出了小小的欢呼。感觉像是得到了认可——一辈子的数据工程经验，竟然真的有用。

同时，这也验证了我对构建 Agent 系统的看法。构建这些 AI 系统本质上就是在构建管道和工作流。

例如，读读这篇关于构建多 Agent 系统挑战的文章。

核心来说，我们在构建数据系统和 Agent 之间的工作流。Agent 在工作流中使用工具；用户交互通过工作流完成；使用的数据和逻辑也被包裹在工作流中。

如果一个人从未构建过工作流，尤其是大型数据工作流，那要直接担任 AI 工程师这个职位会很困难，因为这份工作很大一部分就是在构建工作流来支撑 AI 系统和 Agent。

好的和差的 Agent 系统及其工作流之间的区别是很微妙的，这种知识来自于经验。

事实也是，随着 Agent 的兴起——不仅用于代码生成，还作为自主执行行动和完成工作流的实体——一个人如果要构建 Agent 和 AI 工具来完成或参与工作流，就必须熟悉工作流。你如何监控、观察和衡量那些黑盒 Agent 工作流的输出或结果？

• 一个例子是下面这篇文章和用例（一个真实的用例），其中 Agent（LLM）本身就是工作流和管道。

这是一个全新的前沿领域，有很多探索空间；所有人都在构建 Agent 并让它们"去做事"，这通常意味着完成一组任务，也叫工作流。

这引发了很多有趣的问题，比如如何构建"确定性"的 AI 系统？

因此，我们都可以同意，"工作流"作为 AI 工程师所需的前几项技能之一确实合理。继续前进。

3.5 框架和 Python

我有点作弊，把最后这两项技能合成了一个，因为它们基本上是一回事。Python 和 框架 基本并列。

当然，所有的 Rust 爱好者会嗤之以鼻，但这也没什么新鲜的。Python 在 LLM 出现之前就已经运行着机器学习世界很久了，而且在可预见的未来仍将继续如此。

为什么是"框架"和"Python"？

AI 世界还很年轻，但你已经可以看到哪些框架最常使用正在趋于固化。我确信各种框架的流行度会有起伏，但如果你想成为 AI 工程师，你需要熟悉人们用来构建这些 AI 系统的框架（主要是 Python）。

以下是职位描述中的一些摘录：

- NLP/LLM 工具：Transformers、LangChain、OpenAI APIs
- 扩展和改进我们的 Agent 框架（基于 pydantic-ai 构建）以及支撑它的基础设施
- ML/AI 框架：scikit-learn、TensorFlow、PyTorch、LangChain、OpenAI API 集成
- 熟练掌握 Python 等编程语言，熟悉 AI 框架（如 TensorFlow、PyTorch）
- 理解 Agent AI 框架和工具，如 CrewAI 和 Azure AI Foundry

诸如此类的还有很多。

这完全不令人惊讶。如果你是前端工程师，他们会问你最新的最火的 JavaScript 框架是什么，或者其他什么。

如果你是 Rust 工程师，他们会期望你是 Cargo 的专家，或者 Tokio 用于异步操作。如果你想成为 AI 工程师，那你就需要使用并熟悉常用的工具和框架。

• 我的大部分经验来自 LangChain 和 LangGraph，两者我都很推荐。它们是很好的起点。

4、所以你还在等什么？

好吧，我觉得这很有趣，即使你觉得不是，你这个爱抱怨的小家伙。在所有的 AI 热潮 + 末日恐慌中，很容易被卷入世界末日的列车。我能说什么，我也是这个的忠实粉丝。

不管怎样，如果其他都行不通，我猜我们都可以用转型为"AI 工程师"这扇逃生门。

现在我们已经拉开了那个神秘职位的帷幕，看到了需要什么技能，似乎没那么可怕了。也许吧。

我认为——可能因为我有偏见——数据工程师非常适合 AI 工程师的角色。与数据、工作流、框架、系统打交道……这是我们长期以来的生活。

我不知道未来对程序员和氛围编码者意味着什么。裁员来得又猛又快。我碰巧认为这更多与降低成本和图方便有关，而不是 AI。但同样真实的是，软件开发已经永远改变了，不管你喜不喜欢。

原文链接: 5 Steps to go from Data Engineer -> AI Engineer

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