持怀疑态度的软件工程师实用AI指南

为何要听我的？我并非科班出身的软件工程师，也不是计算机科学家，更不在大型AI实验室工作。我是科学家、农场主、小企业主、生物信息学家、计算生物学家、R和Python库开发者、管理者、数据分析师，偶尔也客串软件工程师。从这份清单你会发现，我关心的是解决真实问题，需要什么就学什么。例如，在gpt-1尚未发布时，我就用2500万篇科学论文训练过深度神经网络。最近我搭建了一个分布式AI推理平台，还开发了一款新的Markdown编辑器。我写过上线的代码。总体而言，我觉得自己对AI、软件以及实实在在的现实问题有着‘均衡’的经验。有人或许会称之为经验加上务实的态度。但我也有野心，希望事情变得更好。如今，我希望世界开始收获深度学习和大语言模型带来的真正、强大、有形的成果——而这一切有太多东西需要构建，软件工程师几乎拥有构建所需的全部条件。如果你想贡献力量，请继续读下去。

聊天机器人不是答案。它们不可靠，而且通常不是任务的最佳用户体验。但这并不意味着AI不是答案，也不代表AI不是任务的最佳工具。

如果你是一名软件工程师（无论站在技术栈的哪一层），被要求开发某个AI功能，结果发现它是个聊天机器人/对话系统，我理解你对AI的实用性、可靠性和可行性心存怀疑。

我们处于非常早期的阶段，ChatGPT的火爆掩盖了其他可能性，目前大多数（所有？）重大新闻级AI产品都以聊天形式出现——这让我们所有人产生了偏见：聚焦并关联聊天与AI。但AI比这更深层、更通用、更有用、更需要工程化。

对我而言，聊天机器人就像浏览器。最终只会剩下少数赢家。它们现在是、将来也是大事——人类是社会性动物，喜欢对话，对话式UI迎合了我们的这一面。但话说回来，人是多面体的。当人们想要完成一项任务时，他们很乐意将对话优先级降到命令与控制之下。骑马很惬意，但自动驾驶摩托车更容易操控。马需要对话，而浏览器虽然重要，但在其内部和周围构建和工程化的东西要多得多——那才是真正的机会所在，也是各类工程师找到有意义工作的地方。如今，聊天机器人内部、之上和周围都有大量东西等着构建。有成千上万的AI驱动功能、服务和系统，它们将安静地运行在其他产品内部——提取数据、分类输入、转换文档、大规模做决策。这是工程工作。它需要软件工程师。

在本文中，我将尽力向您展示真正的AI工程是什么样子，为什么您已有的技能比您想象的更重要，以及您可能需要学习什么（如果有的话）。

AI是一种新型计算方式，而不是新型同事

这是个类比。它并非字面真理。但我发现它很有用。您已经在使用不同类型的计算：CPU、GPU、数据库、第三方API。它们是系统中的组件。它们接收输入、产生输出、花费成本，有时还会失败。

现在又多了一种：语言模型，或更广义的深度神经网络。它们接收输入、产生输出、花费成本，有时还会失败。从这个意义上说，它们只是另一个组件。

但有一个真正的区别。在普通代码中，您编写函数体，编写将输入转换为输出的逻辑。而在AI程序中，您不这样做。相反，您指定您想要什么：输入类型、输出类型、对应该做什么的描述（一个轻量级文档字符串）、可能还有一些示例（从一开始或逐步提供），然后模型找出如何产生输出。其性能和输出无法通过其他原因解释，只能是：

数据中存在某种模式，并且它被成功建模了。

它是黑箱的，是概率性的，而非确定性的。你不会每次都得到完全相同的结果（除非在非常特定的设置下）。这种无法在机制和确定性层面解释和推导输出的能力，是新的部分。

其他所有事情——分解问题、定义契约、处理错误、测试、观察系统在生产中的行为……这都是工程。这是您已经在做的事情。

您已经具备的能力

如果您是软件工程师，您已经掌握了大部分所需。

分解。当您看到一个庞大而混乱的提示词时，您能发现其中隐藏的定义明确的任务。您可以将它们拆分开来。您的整个职业生涯都在与代码做同样的事情：分解、分离关注点、使事物可测试。同样的技能。

契约。您知道如何定义函数签名：输入类型、输出类型、预期行为描述。这是API设计，是规格说明。您做过这些。

错误处理。验证、重试、降级、优雅退化。您知道系统会失败，也知道如何构建处理失败的系统。

可观测性。日志、追踪、分析。在您不直接观察时了解正在发生什么。当出问题时知道去哪里查看。

组合。用小块构建系统：调用其他服务的服务、管道、图、编排。您思考过这个问题，可能思考得很多。

所有这些都适用于AI程序。形状相同，组件不同。

您可能只需要学习一件事

有一块可能是新的。我想明确地说出来，以免它被夸大。

就是评估思维。一点数据科学，一点测量哲学。

我的意思是：

在普通代码中，您编写测试：断言 assert f(x) == y。通过或失败，绿色或红色。

对于AI程序，情况不同。输出是概率性的。您无法断言精确相等。相反，您提供正确行为的示例——定义“工作”的输入-输出对——然后测量系统匹配的频率。

这意味着要问以下问题：

• 95%的准确率对这个用例够用吗？还是需要99%？或者99.9%？

• 如何构建一个真正代表实际输入的示例集？

• 当某些东西改变时，如何知道它是变好了还是变差了？

• 如何找到失败的情况并理解原因？

这是一项真正的技能。需要练习。您正在建立关于那些不会两次行为完全相同的系统的直觉。

但它是有限的。不是“去拿一个机器学习博士学位”。这是一个新的学科，是可以学会的。您可以从十个示例开始，然后逐步扩展。

这就是您需要学习的东西。其余您已经具备。

AI程序长什么样

让我具体化。

这是一个函数签名。输入类型：一段收据文本。输出类型：一个包含特定字段的结构化对象。一个简短描述，说明做什么。

这是一个契约、一个规格说明。您写过数百个这样的东西。

区别在内部。... 不是您编写的代码，而是一个经过优化的AI调用。您可能从一个简单的提示词开始。然后添加示例。然后尝试不同的模型。然后调整指令。您根据评估集进行测量。保留有效的内容。

函数签名保持稳定。实现通过数据优化。

现在想象一个更困难的问题：端到端处理收据图像。天真的方法是单个大调用。

这有时能工作。但当它失败时，您不知道失败位置或原因。您无法测试各个部分，也无法分别改进它们。

工程方法：分解。

现在每个部分都可以测试。每个部分都可以改进。当有东西失败时，你知道位置。在简单步骤中使用快速便宜的模型，在关键地方使用能力更强的模型。

还有另一个好处：您为模型提供了思考结构。将推理分散到多个步骤中，通常会使整个系统更准确。模型不必一次性解决所有问题。

这就是分解。与您处理混乱代码时的相同直觉。同样的技能。

组合系统

一旦有了AI程序，就可以连接它们。

有时是直线管道。有时有分支——并行路径然后合并。有时有循环——使用不同策略重试，或细化直到达到质量阈值。

系统的行为来自：

• 结构：谁调用谁

• 契约：每个节点的类型

• 路由：使用哪些模型、什么重试逻辑

• 优化：每个部分如何调优

这是服务编排。您以前考虑过这样的系统，只是组件不同。

而且由于每个部分都有清晰的契约，您可以追踪整个系统。可以在每个步骤记录输入和输出。可以看到失败聚集在哪里。可以构建仪表盘。可以运行分析。

您可以将工程带到这上面来。

需要完成的工作

很多。

从混乱输入中提取结构化数据的函数。对信息进行分类、总结、路由、转换的服务。接收模糊输入并产生类型化、已验证输出的程序。

这些工作并不光鲜，不会引起人们屏息惊呼的媒体报道。但它们有用。它们是使真实系统工作的那种东西。它们是建造大教堂的可靠砖块。

而且它们需要可靠。不是“演示中能工作”的可靠，而是真正的可靠。针对真实案例进行测试。在生产中监控。随时间改进。

这就是工程。这就是软件工程师擅长的事情。

邀请

有一种新型组件。它强大、奇特、黑箱（深度神经网络可解释性低）。它开辟了新的可能性。而用好它——可靠、深思熟虑、大规模地构建——是一个工程问题。

您的技能在这里很重要。分解、契约、类型、错误处理、可观测性、测试、组合。所有这些都适用。

只有一件新东西需要学：评估思维。如何用示例指定行为。如何测量那些无法通过逻辑证明或分析的系统。如何建立关于概率性输出的直觉。这是真实的，但有限。您可以学会。

聊天层将会整合。少数几个助手会胜出。可能会有泡沫，也可能会有修正。我不知道，但底层技术是真实的。

那些专注于构建真正有效东西的工程师——可靠系统、真实问题、可衡量的性能——将在世界上创造巨大价值。

我们这里需要软件工程师。

希望您能加入。

要了解更多关于构建可靠复合AI系统的信息，请参见DSPy和这篇博客文章。