📢 转载信息
原文链接：https://www.kdnuggets.com/beyond-giant-models-why-ai-orchestration-is-the-new-architecture
原文作者：Vinod Chugani
Image by Author
AI编排是新的架构范式
在过去的两年里，人工智能行业一直在进行一场竞赛，目标是构建越来越大的语言模型。GPT-4、Claude、Gemini：每一个都声称是解决所有AI问题的单一解决方案。但当各大公司竞相打造最强大脑时，一场静悄悄的革命正在生产环境中发生。开发者们不再问“哪个模型最好？”，而是开始问“我如何才能让多个模型协同工作？”
这一转变标志着AI编排（AI orchestration）的崛起，它正在改变我们构建智能应用的方式。
为什么一个AI无法统治一切
一个全能的AI模型的梦想很有吸引力。一次API调用，一次响应，一张账单。但现实已经证明更加复杂。
考虑一个客户服务应用。你需要情感分析来判断客户情绪，需要知识检索来查找相关信息，需要响应生成来组织回复，还需要质量检查来确保准确性。虽然GPT-4在技术上可以处理所有这些任务，但每项任务都需要不同的优化。一个在情感分析方面表现出色的模型，在架构权衡上与一个优化文本生成的模型是不同的。
突破点不在于构建一个统治一切的模型。而在于协调多个专家。
这与我们在软件架构中看到的模式相似。微服务取代了单体应用，不是因为任何单个微服务更优越，而是因为协调的专业化服务被证明更易于维护、更具可扩展性且更有效。AI正在经历它的“微服务时刻”。
三层架构栈
理解现代AI应用需要分层思考。从生产部署中涌现出的架构看起来惊人地一致。
// 模型层
模型层（The Model Layer）位于基础。这包括你的LLM，无论是GPT-4、Claude、Llama等本地模型，还是用于视觉、代码或分析的专业模型。每个模型都带来了特定的能力：推理、生成、分类或转换。关键的见解是，你不再是选择一个模型，而是组合一个集合。
// 工具层
工具层（The Tool Layer）实现了行动。语言模型可以思考，但它们本身无法做任何事。它们需要工具来与世界互动。这一层包括网页搜索、数据库查询、API调用、代码执行环境和文件系统。当Claude“搜索网络”或ChatGPT“运行Python代码”时，它们正在使用来自这一层的工具。Anthropic最近发布的模型上下文协议（MCP）正在规范模型如何与工具连接，使得这一层越来越像即插即用。
// 编排层
编排层（The Orchestration Layer）协调一切。系统的智能实际上就存在于此。编排器决定为哪个任务调用哪个模型，何时调用工具，如何将操作链接起来，以及如何处理失败。它是你AI交响乐的指挥家。
模型是音乐家，工具是乐器，而编排就是告诉每个人何时演奏的乐谱。
编排框架：理解模式
就像React和Vue标准化了前端开发一样，编排框架正在标准化我们构建AI系统的方式。但在讨论具体工具之前，我们需要理解它们所代表的架构模式。工具会来来去去，但模式是持久的。
// 链式模式（顺序逻辑）
链式模式（The Chain Pattern，即顺序逻辑）是编排中最基本的模式。把它想象成一个数据管道，其中每一步的输出都成为下一步的输入。用户提问、检索上下文、生成响应、验证输出。每个操作按顺序发生，由编排器管理交接。LangChain开创了这种模式，并围绕使其可组合和可重用而构建了整个框架。
链的优势在于其简单性：你可以推理流程、分步调试并优化单个阶段。局限性在于僵化。链条不会根据中间结果进行调整。如果第二步发现问题无法回答，链条仍然会继续执行第三步和第四步。但对于具有清晰阶段的可预测工作流程，链条效果很好。
// RAG模式（检索优先逻辑）
RAG模式（The RAG Pattern，即检索优先逻辑）源于一个特定问题：当语言模型缺乏信息时会产生幻觉。解决方案很简单：先检索相关信息，然后生成基于该数据的响应。
但从架构上看，RAG代表着更深层次的东西：即时上下文注入。把它想象成计算（Compute，即LLM）与内存（Memory，即向量存储）的分离。模型本身保持静态，它不会学习新事实。相反，你通过将相关上下文注入其提示窗口来替换模型“RAM”中的内容。你不是在重新训练大脑，而是在需要时精确地向它提供所需的信息。
这种架构原则（查询、搜索知识库、按相关性排序结果、注入上下文、生成响应）之所以成为持久的模式而非仅仅是一种技术，是因为它实现了关注点的分离。模型处理推理和综合。向量存储处理记忆和召回。编排器管理注入时机。LlamaIndex围绕优化这种模式构建了其整个框架，处理文档分块、嵌入生成、向量存储和检索排序等难题。你甚至可以通过简单的无代码工具看到RAG在实践中如何工作。
// 多智能体模式（委托逻辑）
多智能体模式（The Multi-Agent Pattern，即委托逻辑）代表了编排最复杂的演变。与其使用一个顺序流程或一个检索步骤，不如创建相互委托的专业智能体。一个“规划者”智能体分解复杂任务。“研究员”智能体收集信息。“分析师”智能体处理数据。“撰写者”智能体生成输出。“评论家”智能体审查质量。
CrewAI体现了这种模式，但其概念早于该工具。架构的洞察在于，复杂的智能来自于专家之间的协调，而不是一个试图做所有事情的通才。每个智能体都有狭窄的责任、明确的成功标准，以及向其他智能体请求帮助的能力。编排器管理委托图，确保智能体不会无限循环，并确保工作朝着目标推进。如果你想深入了解智能体如何协同工作，可以查阅关键的智能体AI概念。
选择哪种模式不取决于哪种“最好”。而在于将模式与问题相匹配。简单的、可预测的工作流程？使用链条。知识密集型应用？使用RAG。需要不同专业知识的复杂、多步骤推理？使用多智能体。生产系统通常会结合所有三种：一个多智能体系统，其中每个智能体在内部使用RAG并通过链条进行通信。
模型上下文协议值得特别提及，它是这些模式下正在形成的通用标准。MCP本身不是一种模式，而是一种模型如何连接到工具和数据源的通用协议。它于2024年底由Anthropic发布，正成为框架构建的基础层，是AI编排领域的HTTP协议。随着MCP的采用增长，我们正转向标准化接口，使得任何模式都可以使用任何工具，无论你选择了哪个框架。
从提示到管道：路由器改变一切
概念上理解编排是一回事。在生产中看到它揭示了它为何重要，并暴露了决定成功或失败的关键组件。
考虑一个帮助开发人员调试问题的代码助手。单一模型的方法会将代码和错误消息发送给GPT-4，然后听之任之。而编排系统的工作方式则不同，它的成功取决于一个关键组件：路由器（Router）。
路由器是每个编排系统的决策引擎核心。它检查传入的请求，并决定它们应该通过系统的哪个路径。这不仅仅是管道工程。路由的准确性决定了你的编排系统是优于单个模型，还是会因不必要的复杂性而浪费时间和金钱。
让我们回到调试助手。当开发人员提交问题时，路由器必须决定：这是语法错误？运行时错误？还是逻辑错误？每种类型都需要不同的处理。
智能路由器如何充当决策引擎，将输入引导至专业化路径 | 图片来源：作者
语法错误被路由到一个专门的代码分析器，这是一个针对解析违规进行微调的轻量级模型。运行时错误会触发调试器工具来检查程序状态，然后将发现传递给理解执行上下文的推理模型。逻辑错误则需要完全不同的路径：搜索Stack Overflow查找类似问题，检索相关上下文，然后调用推理模型来综合解决方案。
那么路由器如何决定呢？三种方法在生产系统中占主导地位。
语义路由使用嵌入相似性。将用户问题转换为向量，将其与每个路由的示例问题的嵌入进行比较，并沿着相似度最高的路径发送。对于明确区分的类别，这非常快速且有效。当错误类型定义明确且示例丰富时，调试器会使用此方法。
关键词路由检查明确的信号。如果错误消息包含“SyntaxError”，则路由到解析器。如果包含“NullPointerException”，则路由到运行时处理程序。这很简单、快速，并且在你有可靠指标时非常稳健。许多生产系统在添加复杂性之前都从这里开始。
LLM决策路由使用一个小型、快速的模型作为路由器本身。将请求发送给一个经过训练或提示的专门分类模型，使其做出路由决策。它比关键词更灵活，比纯粹的语义相似性更可靠，但会增加延迟和成本。GitHub Copilot和类似工具使用这种方法的变体。
这里有一个重要的洞察：你的编排系统成功的关键有90%取决于路由器的准确性，而不是下游模型的复杂性。一个完美的GPT-4响应被发送到错误的路径对任何人都没有帮助。一个被正确路由的专业模型的尚可的响应才能解决问题。
这产生了一个意想不到的优化目标。团队痴迷于为生成选择哪个LLM，却忽略了路由器工程。他们应该反其道而行之。一个做出正确决定的简单路由器胜过一个经常出错的复杂路由器。生产团队会严格衡量路由准确性。它是预测系统成功的指标。
路由器还处理失败和回退。如果语义路由没有信心怎么办？如果网络搜索没有返回任何内容怎么办？生产路由器实现决策树：首先尝试语义路由，如果置信度低则回退到关键词匹配，对边缘情况升级到LLM决策路由，并且始终为真正模糊的输入维护一个默认路径。
这解释了为什么编排系统尽管增加了复杂性，却能持续超越单个模型。并非编排神奇地使模型更智能。而是准确的路由确保专业模型只看到它们被优化来解决的问题。语法分析器只分析语法。推理模型只进行推理。每个组件都在其卓越区域内运行，因为路由器保护它们免受它们无法处理的问题的影响。
架构模式是通用的：前面是路由器，后面是专业处理器，流程由编排器管理。无论你是构建客户服务机器人、研究助手还是编码工具，把路由器做好决定了你的编排系统是成功还是会成为GPT-4昂贵且缓慢的替代品。
何时需要编排，何时保持简单
并非每个AI应用都需要编排。一个回答常见问题的聊天机器人？单一模型。一个对支持工单进行分类的系统？单一模型。生成产品描述？单一模型。
当需要以下情况时，编排才有意义：
没有单一模型能很好处理的多种能力。需要情感分析、知识检索和响应生成的客户服务受益于编排。简单的问答则不需要。
外部数据或操作。如果你的AI需要搜索数据库、调用API或执行代码，编排器比试图提示单个模型“假装”可以访问数据，能更好地管理这些工具的交互。
通过冗余实现可靠性。生产系统通常将一个快速、廉价的模型与一个能力强、昂贵的模型链接起来，用于复杂情况。编排器根据难度进行路由。
成本优化。对所有事情都使用GPT-4非常昂贵。编排允许你将简单任务路由到更便宜的模型，并将昂贵的模型保留给困难的问题。
决策框架很简单：从简单开始。使用单一模型，直到达到明显的限制。当复杂性带来了更好的结果、更低的成本或新能力时，再增加编排。
最后的思考
AI编排代表了该领域的成熟。我们正在从“我应该使用哪个模型？”转向“我应该如何架构我的AI系统？”这与每项技术从单体到分布式、从选择最好的工具到组合正确工具的演变过程相呼应。
框架已经存在。模式正在出现。现在的问题是，你将以旧方式（希望一个模型能做所有事）构建AI应用，还是以新方式：将专业模型和工具编排成一个大于其部件总和的系统。
AI的未来不在于找到完美模型。而在于学会指挥这个管弦乐队。
Vinod Chugani是一位AI和数据科学教育者，致力于弥合新兴AI技术与专业人士实际应用之间的差距。他的重点领域包括智能体AI、机器学习应用和自动化工作流程。通过他作为技术导师和讲师的工作，Vinod帮助数据专业人员发展技能并实现职业转型。他将量化金融领域的分析专长带入他的实践教学方法中。他的内容强调专业人士可以立即应用的、可操作的策略和框架。
评论区