多模型一致性：当你的流水线中的连续 LLM 调用相互矛盾时

你的摘要步骤判断出客户投诉是关于账单的。你的提取步骤提取出了“订阅层级：Pro”。你的生成步骤写了一封跟进邮件，提到了他们的“Enterprise 方案”。三次 LLM 调用，一个流水线，一个完全错误的输出 —— 而且整个过程中没有触发任何错误。

这就是多模型一致性失效：复合 AI 系统的无声杀手。它看起来不像是一个异常。它不会触发你的错误率 SLO。它只是自信地向用户发布错误的内容。

大多数 LLM 驱动系统的工程工作都集中在单次调用的可靠性上：提示词质量、输出解析、重试逻辑。但随着流水线增长到将三次、五次甚至十次模型调用串联在一起 —— 每一个都在之前输出的基础上进行摘要、提取、分类或生成 —— 一类新的故障出现了。模型在单次响应中并不会自相矛盾，它们是在整个流水线中相互矛盾。

为什么顺序 LLM 调用会产生分歧

每次 LLM 调用都是一次独立的推理。当你将调用串联起来时，你并不是在运行一个连续的推理过程 —— 你是在运行一系列恰好共享文本的、不相关的采样事件。每次调用只能看到你显式传递给它的内容，并且每次调用都会基于其局部上下文自信地产生输出，而不管之前的步骤得出了什么结论。

考虑一个客户支持流水线：

1. 调用 1 (分类器)："此消息主要关于账单。"
2. 调用 2 (提取器)："客户姓名：Sarah。方案：Pro。问题：3 月 14 日的重复收费。"
3. 调用 3 (生成器)：写一封回信，确认 Sarah 对其 Enterprise 账户的疑虑。

调用 3 捏造了 "Enterprise"。这个词并没有出现在原始消息或提取器的输出中 —— 但生成器的提示词模板提到了账户层级，而模型根据模式匹配将 "Enterprise" 视为账单投诉中一个合理的层级。没有任何调用失败。流水线运行成功。但邮件是错误的。

这种故障模式出现在各个领域。在文档分析流水线中，摘要生成器可能会将 "营收同比下降 3.2%" 转述为 "营收轻微下降" —— 然后下游的事实提取器根据摘要而非原始来源，输出 "营收趋势：轻微下降"。随后报告生成器写道 "管理层注意到轻微的营收增长压力"。原来的 -3.2% 经过两次合法的转换，被“洗”成了中性语言。

更深层次的问题在于，语言模型会优化局部连贯性。每次调用都会产生在其输入下读起来很通顺的输出。但 "在输入下读起来通顺" 并不等同于 "与流水线中其他调用的结论一致"。编排框架为你提供了在调用之间传递输出的粘合代码。但在强制执行跨调用的语义一致性方面，它们几乎没有提供任何帮助。

为什么大多数框架都搞错了

当前的编排框架 —— LangChain、LlamaIndex、crew 风格的多智能体设置 —— 从根本上说都是执行框架。它们处理路由、重试、工具分发和状态传递。它们不处理所传递内容的含义。

这并不是设计上的疏忽 —— 而是一种哲学选择。试图在框架层强制执行语义一致性的框架往往会变得僵化且难以使用。但后果是，一致性保证被完全推给了应用开发者，而大多数开发者直到生产环境出现故障时才意识到自己承担了这一责任。

具体缺陷包括：

没有共享实体注册表。 如果调用 1 将 "客户" 识别为账户 ID 4821，大多数框架中没有任何机制可以阻止调用 3 对上下文中出现的另一个账户 ID 进行推理。

没有矛盾检测。 如果调用 2 提取了 "方案：Pro"，而调用 4 随后提到了 "方案：Enterprise"，没有任何内置机制能在输出发布前将其标记为问题。

没有语义锁定。 在流水线早期建立的事实可能会被后续具有不同上下文或先验知识的调用悄悄覆盖。这种覆盖不会引发错误；它就那么发生了。

其结果是，随着流水线深度的增加，复合 AI 系统在能力上呈线性增长，但在一致性风险上却呈超线性增长。

真正起作用的三种模式

实体锚定 (Entity Pinning)

核心思想：流水线早期阶段对关键实体做出的决策应被视为锚定事实，后续阶段不能隐式覆盖。

在实践中，这意味着从早期调用中提取一个结构化的 "实体清单"，并将其显式注入到所有下游提示词中。不要将其作为自然文本流的一部分（模型可能会忽略或反驳它），而是作为一个类型化、带标签的块：

[锚定实体 - 请勿覆盖]
客户：Sarah Chen
账户 ID：4821
方案：Pro
问题日期：2026-03-14
[锚定实体结束]

结构化分离至关重要。当锚定实体嵌入在流动的散文中时，模型会将其视为暗示性的上下文。当它们被格式化为一个独立的、带标签的块时，指令遵循行为就会生效，模型会可靠地尊重这些约束。

实体锚定最适用于高基数事实：专有名词、标识符、日期、数值、枚举类型。这些正是微小的不一致会导致严重下游损害的领域。

共享事实寄存器

实体锚定处理的是“值”。共享事实寄存器处理的是“声明”——即在流水线运行过程中累积的、更丰富的命题。

事实寄存器是一个结构化文档，它随着流水线的执行而累积经验证的声明。每次调用既负责读取当前的寄存器（作为强制性的上下文），也负责贡献下游调用可以依赖的新条目。

它与简单地传递所有先前输出的区别在于其“精确性”。你不是把调用 2 的完整文本响应倾倒进调用 3 的上下文中，而是提取调用 2 确立的具体事实声明并使其显式化。“营收同比下降 3.2%”会存入寄存器，而调用 2 的其余分析则不会。

这有两个好处。首先，下游调用拥有一个已确立事实的紧凑且权威的记录。其次，当下游调用试图生成与寄存器条目相矛盾的内容时，提示词设计可以使这种违规行为变得可见，而不是悄无声息地发生。

一些团队将事实寄存器实现为结构化的 JSON，这还实现了调用之间的程序化一致性检查。如果提取器写入了 {"plan": "Pro"}，而生成器的输出 JSON 包含了 {"plan": "Enterprise"}，那么在任何内容发布之前，这就是一个可检测到的不匹配。

一致性验证环节

最稳健的方法是在流水线阶段之间增加一个显式的验证步骤——这是一个专门的调用，其唯一工作就是在执行继续之前，检查先前步骤的输出在内部是否一致。

验证环节的提示词大致如下：“这是我们流水线目前确立的内容。这是提议的下一步。在继续之前，请识别出任何矛盾、不支持的声明或实体不匹配。”

这更昂贵——这是一个额外的模型调用，会增加延迟和成本。问题在于将其放置在哪里。验证环节在以下场景中最有价值：

• 高风险分支点：在根据提取的事实生成面向用户的内容之前。
• 较长的中间链条之后：自上次事实对齐 (grounding) 操作以来，已经运行了 3 个以上的推理步骤。
• 执行不可逆操作之前：发送电子邮件、更新记录、进行无法撤销的 API 调用。

验证环节不应尝试检查所有内容。它们应该检查那些至关重要的声明：实体引用、数值、枚举字段，以及任何同时出现在上游输出和下游操作中的内容。范围受限的验证速度足够快，在 p50 延迟预算内是切实可行的。

架构设计原则

除了特定的模式，一些架构原则也能全面降低一致性风险。

最小化调用之间流动的内容。 你传递给下游的每一个输出，都是下游调用进行解释、重构或反驳的机会。尽可能传递特定事实的结构化提取物，而不是完整的纯文本输出。目标是为下游调用提供“信息”，而不是“暗示信息的文本”。

在使用事实之前先确立事实。 在同一次调用中既提取又使用事实的流水线阶段实际上是在做两份工作，而其中一份通常会胜过另一份。如果你需要提取账户等级并编写针对该等级的消息，请将它们拆分为两次调用。提取器确立事实真相 (ground truth)，生成器接收锚定的事实，而不是模棱两可的上下文。

使一致性失败可见。 如果调用 3 输出的内容包含一个调用 2 未确立的实体，你需要知道这一点。添加输出解析来根据你的事实寄存器验证提取的实体。这无法捕捉到所有的一致性失败，但它能捕捉到那类不一致性在结构化字段中显式存在的失败——而这正是造成下游损害最严重的一类失败。

设计验证边界。 针对每个流水线，决定哪些事实在确立后是不容置疑的，哪些可以由后续调用合理地细化。并非所有的下游变化都是 Bug。生成器添加提取器未包含的细节是可以接受的，但生成器反驳提取器得出的结论则不行。要明确定义每种事实类型属于哪一类。

复合效应

单次调用的幻觉率听起来是可控的——在事实性任务的生产部署中，通常在 1–3% 之间。但复合 AI 系统会成倍增加风险。如果四个流水线阶段中的每一个都有 2% 的概率引入与先前阶段不一致的情况，那么完整的端到端运行保持一致的复合概率大约只有 92%。对于大规模处理生产用户数据的流水线，这意味着 8% 的运行至少包含一次一致性失败——而其中大多数对你的监控系统来说是不可见的。

关于多 LLM 临床系统的研究文献发现，模型会对植入的虚假信息进行详述，而不是纠正它——在对抗性环境下，这种情况发生的比例高达 83%。生产流水线面临着类似动态的温和版本：当模型在上下文中看到内部合理但事实错误的声明时，它会基于这些声明继续推进，而不是挑战它们。模型越先进，它融入不一致信息的方式就越流畅。

优秀的标准

一个处理多模型一致性的流水线（pipeline）并不依赖于任何单次调用与其上游上下文的一致性。它将一致性转化为流水线设计中的结构化属性：

• 早期阶段提取并固定关键实体
• 事实寄存器（fact register）随着每个步骤累积经过验证的陈述
• 下游阶段接收明确的、结构化的上下文，而不是全文本转储
• 验证环节为高风险的转换过程提供保障
• 在使用结果之前，输出解析器会根据已注册的事实校验结构化字段

这比简单地将 LLM 调用串联起来要复杂得多。这也是交付具有生产可靠性的复合 AI 系统（compound AI systems）所需的最低工程要求。另一种方案——即寄希望于每次调用都能从共享上下文中推断出相同的实体——这种做法会导致产生那些通过了所有单元测试、却在内容上极其自信地出错的邮件和报告。

令人鼓舞的是：大部分机制都是可重用的。设计良好的事实寄存器模式可以被提取为流水线组件。实体固定是一种提示词模板（prompt template）惯例。验证环节是一个单一的可重用调用模式。在构建第一个流水线之后，前期的投入将在你后续构建的每一个流水线中产生回报。