重新思考面向智能体的软件供应链
近日，一项MIT研究报告指出，大约只有5%的生成式AI应用创造了真实、可衡量的商业价值。在我看来，这并非雄心壮志的失败。恰恰相反，大多数团队都在积极地进行实验。问题在于，我们用来交付软件的底层系统尚未适应AI的真正本质。
如今，构建原型或演示已经变得异常简单。只需进行几次提示调整，调用一个API，就能展示出令人印象深刻的东西。但是，将那个原型转化为可以在生产环境中信赖的产品，则是另一项挑战。这一部分需要真正的工程实践：可靠性、一致性、版本控制、监控和安全护栏。问题在于，我们多年来依赖的工具和工作流在设计之初，就从未考虑过支持那些行为会随时间而变化的系统。
持续集成或持续交付（CI/CD）管道是为了测试代码而建立的。它们回答诸如以下问题：
- 这个函数是否返回了预期结果？
- 应用程序是否能干净地部署？
但是，AI系统和智能体的行为并不像静态代码。它们的行为会随着上下文、数据和提示的不同而变化。因此，真正的问题变成了：即使在条件发生变化时，这个系统是否能做出我们信任的决策？
在本文中，我将探讨一些有助于我们构建成功的软件供应链方案的想法。
重新思考软件供应链
我们需要接受这样一个事实：多年来我们构建和交付软件的方式，已经不再适合智能的、具智能体的用例世界。
如今，CI/CD管道专注于检查代码是否有效，但对于智能体系统，重点则在于理解智能体如何在复杂环境中行为、适应和做出决策。
为了使其成为可能，我们的软件供应链需要超越持续集成，并向交付关于所构建和交付软件的持续智能演进。在新的管道中，每一步都需要确保我们正在学习和评估智能体，以建立更多信任。
我们需要将软件供应链视为一个活的、能不断学习、改进并与其支持的产品共同进化的系统。
从持续集成演进到持续智能
在智能体时代，我们对CI的目标已经改变。
- 从： “这段代码是否好到可以合并？”
- 到： “这种智能是否可靠到其行为可以被信任？”
从持续集成到持续智能的转变，改变了我们对构建和信任软件的思考方式。软件交付管道旨在检查代码是否正确运行，但智能体系统要求我们验证系统在现实世界、不可预测条件下的行为方式。
大语言模型（LLMs）是非确定性的，其结果不可预测，但当我们开发软件时，我们需要确保其行为在不断改进。因此，挑战在于确保基于非确定性的软件具有可靠性和一致性。
作为一个软件创造社区，我们需要演进我们的持续集成管道，使其能够为我们提供可靠性，并帮助我们确认软件随着时间的推移仍然可靠。
评估（Evals）即新的单元测试
在智能体系统的世界里，我们需要像思考非智能体软件的单元测试一样来思考评估（Evals）。它们超越了检查某物是否有效，而是衡量其在能力、可靠性和安全性方面的表现如何。评估有助于确定模型是否不仅产生了正确的输出，而且行为是否一致，并能在真实场景中被信任。
它们可以离线、在线或持续在线运行，提供关于系统行为的持续反馈。本质上，评估将自动化测试和运行时可观测性结合在一起，为智能系统创建了一个持续的评估和改进循环。
将评估集成到交付链中
将评估集成到交付链中，确保智能体软件在整个软件生命周期中得到持续验证。
在CI阶段，离线评估验证核心阈值，然后代码才能进入下一阶段。在CD期间，渐进式交付由评估分数指导，这些分数表明了在真实场景中的性能和可靠性。
一旦部署，始终在线评估在生产环境中运行，以监控诸如模型漂移、偏见、毒性和安全性等问题。通过组合这些层级，团队可以根据汇总的评估结果做出明智的晋升或回滚决策，从而创建一个能够学习、适应并在每次发布中保持信任的交付管道。
将你的供应链视为生命系统
在智能体世界中，软件交付过程必须演变成一个持续反馈循环，其行为就像一个生命系统。真实的用户信号直接反馈到内联评估中，触发反思和自动化改进操作。当检测到漂移或性能下降时，提示和工作流需要重新评估，智能体需要持续重新部署，以确保系统保持对齐和可靠。
随着时间的推移，系统会在数据、提示和行为模式中学习，不断适应，以持续交付不断提高的价值。CI/CD不再是从代码到生产的一条直线。它变成了一个修复循环，每一次交互都有助于持续学习和改进。
结论
尽管我们作为一个社区才刚刚起步，但我深信，软件交付的未来取决于将我们的焦点从代码正确性转移到行为信任。当前的CI/CD管道是为确定性系统设计的，但智能体和AI驱动的应用程序需要围绕持续学习和保障而构建的新方法。评估现在充当了新的单元测试，帮助团队在部署的每个阶段衡量可靠性、性能和安全性。
通过将供应链演进为一个反馈系统，组织可以创建不仅交付更快，而且能与其智能体一同学习和适应的管道，确保每一次发布既是智能的，又是值得信赖的。
参考