AI框架太多了

我们都经历过这种时刻。一项新技术出现，各种框架层出不穷以使其易于使用，最终，我们达到了框架成为瓶颈的临界点。我们现在正处于人工智能开发的这个转折点。

如果你用 LangChain、AutoGen 或类似的框架构建过任何非平凡的东西，你可能已经感受到了摩擦。当你需要优化性能、调试意外行为或与不符合框架假设的现有系统集成时，让你快速入门的抽象概念会很快变成约束。

框架陷阱

当前一代的人工智能框架解决了一个重要的引导问题——它们使开发人员能够在不需要博士级别Transformer架构知识的情况下构建人工智能应用程序。但它们也引入了熟悉的问题：

不透明的抽象使调试成为一场噩梦。当你的 RAG 管道失败时，你通常会被困在框架代码的层层追踪中，以了解你的查询发生了什么。

• 性能开销 变得不可避免。框架针对通用性进行优化，而不是针对你的特定用例。额外的抽象层会消耗你的延迟和 token。
• 不灵活的执行模型 迫使你采用预定的模式。需要实现自定义的重试策略或回退逻辑？你是在与框架作斗争，而不是解决你的问题。
• 版本锁定 造成长期的技术债务。框架更新通常会破坏现有的实现，并且迁移路径很少顺畅。

这不是对这些工具的批评——它们实现了自己的目的。但是生产系统需要不同的权衡。

原语优于框架

替代方案不是从头开始重新发明一切。而是使用 代理原语 ——小的、可组合的构建块，你可以将它们组合起来以创建你需要的系统。

可以把它想象成使用 CMS 和用 HTTP 库构建的区别。CMS 可以让你更快地入门，但是当你需要自定义行为时，你需要直接控制请求、路由和状态管理。

在人工智能上下文中，原语通常包括：

• 原子代理 可以很好地完成一件事。与其使用单一的助手，不如构建专门的组件：一个只关注安全问题的代码审查员，一个针对技术文档进行调整的摘要器，一个了解你的特定领域的查询路由器。
• 显式状态管理 ，你可以精确地控制要保留哪些上下文以及保留多长时间。不再有神秘的“记忆”，其中可能包含或不包含你需要的内容。
• 声明式编排 ，它允许你将工作流程定义为数据结构而不是过程代码。这使得它们更容易测试、可视化和修改，而无需重建。

你关心的工程优势

这种方法提供了具体的工程优势：

• 可调试性：当每个组件都只有一个职责时，你可以快速隔离故障。日志变得有意义。你可以重放单个步骤。
• 性能优化：你可以为不同的任务选择不同的模型。在同一工作流程中使用快速、廉价的模型进行分类，并使用强大的模型进行复杂的推理。
• 可测试性：小型、纯函数比依赖于框架的链更容易进行单元测试。你可以模拟单个组件并独立验证行为。
• 增量部署：你可以在不影响系统其余部分的情况下更新一个代理。如果出现问题，可以回滚单个组件。
• 成本控制：可以细粒度地了解哪些组件消耗最多的 token 或计算时间。在最重要的地方进行优化。

真实世界的实现模式

在实践中，这通常看起来像是构建一个小型的编排层，用于协调专门构建的代理。每个代理本质上都是一个函数，它接受结构化的输入并返回结构化的输出，LLM 交互封装在内部。

例如，你可以组合以下内容，而不是框架的“文档 QA 链”：

• 一个将问题路由到适当处理程序的查询分类器
• 一个查找相关上下文的检索代理
• 一个生成答案的合成代理
• 一个检查幻觉的验证代理

每个部分都可以独立测试和优化。编排器处理它们之间的数据流。

人工智能工程的成熟

这种转变反映了我们对人工智能系统思考方式的更广泛的成熟。早期的框架针对“首次演示的时间”进行了优化。但是生产系统需要可靠性、可观察性和可维护性。

这需要的技能并非全新的——它们是应用于新领域的核心软件工程原则。系统设计、接口合约、错误处理、监控。不同之处在于，你系统中的“函数”恰好由语言模型提供支持。

这并不意味着框架会一夜之间消失。它们将继续服务于重要的用例，尤其是在原型设计和标准化应用程序方面。但是对于自定义的、生产级的系统，原语提供了一条更可持续的道路。

人工智能开发的未来不是寻找完美的框架。而是要恢复工程规范，以使用户需要的工具精确地构建用户需要的东西，并使用对你的特定要求有意义的工具。

如果你遇到了基于框架的开发的限制，请考虑是否应该降低级别。你将增加的复杂性远远超过你将获得的控制。

• 原文链接： extremelysunnyyk.medium....
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～