LLM 流水线单体 vs. 链式架构的权衡：任务分解何时有益，何时有害

大多数构建 LLM 流水线的团队几乎立刻就会选择链式架构。复杂任务被拆分为多个步骤——提取、分类、摘要、格式化——每个步骤都有自己的提示词。这感觉很自然：更小的提示词更容易编写、调试和迭代。但很少有人会问：链式调用真的比在一次调用中完成所有工作更准确吗？在我见过的大多数代码库中，没有人测量过。

单体 vs. 链式的权衡是 AI 工程中最关键的架构决策之一，但几乎总是凭直觉做出的。本文将梳理实证依据，说明分解何时真正有帮助、何时会悄然使事情变得更糟，以及在生产环境中需要关注哪些信号。

"单体"与"链式"的真正含义

单体是指单次 LLM 调用，一次性接收所有相关上下文、指令和输入，并产生完整输出。一个提示词，一个响应，完成。

链式是指将任务拆分为顺序步骤，每次调用的输出作为下一次调用的输入。有些链是线性的（A → B → C），有些是分支的，有些还包含循环或反思步骤（模型对自己之前的输出进行评判）。

两者并非天生优劣之分。它们根据任务、模型以及"好"在应用中的定义，具有不同的性能表现。

链式真正提升准确率的情形

链式最有力的证据来自多步推理任务。思维链提示（一种轻量级链式形式，要求模型在给出答案之前产生中间推理过程）在基准测试中显示出显著的准确率提升：PaLM 在 GSM8K 数学基准上的表现从 17.9% 跃升至 58.1%，翻了三倍多。

其机制是真实存在的：复杂推理任务需要模型同时在工作记忆中维护许多内容，而外化的中间步骤降低了这种负担。当任务具有自然的顺序结构——起草、评审、修改——链式架构反映了这种结构，模型在每个阶段的输入范围更聚焦，因而表现更好。

任务分解在需要中间验证时也表现出色。如果第 2 步可以优雅地失败并以改进后的提示词重试，然后再进行第 3 步，那么你就获得了单体架构无法提供的错误恢复能力。出了问题时，链式架构能精确告诉你哪一步失败了——你调试的是具体输出，而不是一个 4000 个 token 的混合体。

实证研究有些值得注意的细微之处。2024 年的一项研究发现，单任务提示并不总是优于多任务提示——性能因模型和提示词模板而异。Wharton AI Lab 最近的研究发现，对于现代推理模型，由于模型在产生答案之前已经在内部进行逐步推理，思维链的收益正在递减。链式架构在模型需要可见工作空间时最有帮助，而不是在已经推理良好的模型上增加开销时。

链式悄然使事情变糟的情形

很少有人充分讨论的失败模式是错误级联。在链式架构中，每一步都将前一步的输出视为真实数据。如果第 1 步提取了错误的实体，第 2 步就会对错误的东西进行分类，第 3 步就会基于错误的分类进行摘要，到第 4 步你就会得到一个自信的错误答案，而且没有明显的追溯路径。

2026 年一项关于多智能体协作的研究发现，这种模式是系统性的，而非偶然噪声。早期步骤中事实性或忠实性上的微小偏差会被反复引用和重用，最终汇聚成作者所称的"集体虚假共识"——多个下游输出相互强化一个初始错误。链式架构不只是失败，而是以连贯且令人信服的方式失败。

这与token 成本相叠加：在多轮链式调用中，若对话历史被传递下去，成本不是线性的——而是几何级增长。一个十轮对话的成本大约是单轮交互的 55 倍，因为每一步都要重新发送所有之前的上下文。具有冗长中间输出的长链可能会出乎意料地快速耗尽预算。

还有协调开销：管理步骤间的状态、为交接设计 Schema、确保每一步的输出可被下一步解析。这种复杂性是不可或缺的。对清晰、格式良好的输入运作正常的链式架构，往往会在遇到格式不佳的中间输出时崩溃——因为与传统代码不同，LLM 在接收到垃圾输入时不会抛出异常，而是产生看似合理的输出。

上下文窗口问题

许多工程师认为，大上下文窗口使单体架构成为显而易见的选择。如果能将所有内容放入 128K token，为什么还要链式？

实证答案更为复杂。上下文窗口大小与有效上下文窗口大小并不相同。在实践中，模型在其宣传限制的 60-70% 左右开始性能下降。埋在长上下文中间的信息被关注的可靠性较低——"中间丢失"效应——即使在 1M token 窗口中也依然存在。在最大上下文长度下，前缀延迟可能超过两分钟。

实际含义：一个包含准确、聚焦信息的精心设计的 128K 上下文，往往会胜过一个臃肿的 1M 上下文（其中包含大量边缘相关内容）。大上下文窗口提高了上限，但并不使上下文整理变得无关紧要。一个经过精心构建提示词的单体架构，仍然往往优于简单地将所有内容堆入单次调用的做法。

判断哪种架构有效的实证信号

正确的问题不是"我应该链式吗？"而是"分解实际上给我带来了什么？"以下是需要测量的内容：

链式有帮助的信号：

• 错误定位：无需重新运行整个流水线，就能识别出哪一步引入了失败。
• 中间输出质量：第 2 步的输入看起来比第 2 步需要自行推断的要干净得多。
• 在步骤之间添加验证并在失败时重试后，准确率有所提高。
• 独立监控每个步骤可以获得有用信号——各步骤的失败率不同，意味着分解正在揭示真实的子问题结构。

链式有害的信号：

• 第 1 步引入的错误在最终输出中原封不动地出现——级联而未得到纠正。
• 每步准确率较高，但端到端准确率低于预期（协调开销在蚕食收益）。
• 延迟和每次成功输出的成本在增加，而质量改善并不成比例。
• 链式架构越来越长，因为每个新边缘情况都需要一个新步骤——架构在积累复杂性而非管理复杂性。

如果你还没有在代表性样本上对照单体基线测量端到端准确率，你实际上并不知道哪种更适合你的任务。这种基线对比是 AI 流水线工程中最未被充分利用的技术。

决策框架

面对复杂任务，使用以下问题来指导架构选择：

倾向单体的情形：

• 任务可以在单个提示词中完整描述，且不超过有效上下文限制。
• 延迟至关重要（亚秒级需求使多步往返令人痛苦）。
• 任务没有自然的顺序结构——分解将是人为强加的。
• 你使用的是已经在内部进行步骤分解的推理原生模型。

倾向链式的情形：

• 任务有真正不同的阶段，具有不同的专业要求。
• 中间输出在继续之前需要验证、人工审核或分支逻辑。
• 你需要精确的错误定位用于调试和监控。
• 错误恢复很重要——你想重试某个特定步骤，而不是整个任务。
• 任务足够长，限定每步的上下文范围可以改善模型专注度。

使用混合模式的情形：

• 保持链式简短：三到五步通常已经足够；更长的链积累的级联风险过大。
• 对每个交接点使用严格的 Schema（Pydantic、JSON Schema），使步骤在接收到错误输入时大声报错。
• 当步骤是确定性的或代价高昂时，缓存中间结果。
• 在任何产生供人类或下游系统消费的输出的步骤之前添加验证关卡。

生产系统实际上是怎么做的

成功扩展 LLM 流水线的团队往往收敛到类似的模式：短而边界清晰的链式架构，步骤之间有明确的验证，而非长链或单次整体调用。他们引用的最常见失败模式不是选错了架构——而是没有测量他们选择的架构是否真的在发挥作用。

大多数代码库中的默认做法是链式，因为单独迭代每个提示词很容易。这是一个足够好的起点。但当你向生产迈进时，问题从"每个步骤在正常运作吗？"转变为"流水线端到端在正常运作吗？"这是两个不同的问题，需要不同的指标。

运行基线对比。测量级联率——第 N 步的错误在最终输出中未得到纠正地出现的频率。跟踪每步准确率与端到端准确率，以查看你是否在支付协调成本却未获得准确率收益。这些测量成本低廉，而它们提供的信息远比任何架构直觉都更有价值。

单体 vs. 链式的争论看起来是一个技术架构问题，但实际上是一个测量纪律问题。做对的团队不是那些预先做出了更明智架构选择的团队——而是那些建立了足够可观测性、能够知道他们的选择何时停止有效的团队。