级联架构：降低RAG推理成本六倍的秘诀

大多数为高风险分类任务构建检索增强生成(RAG)系统的团队都做出了相同的架构选择：将所有模糊案例直接路由到语言模型，并期望检索到的上下文能够解决问题。这种方法在演示中表现良好，但当系统需要接受审计、应对监管机构或合规官员询问半年前的特定决策原因时，就会崩溃。

过去一年，我在受监管的企业环境中构建基于RAG的分类系统，在这里，错误答案的代价不是糟糕的聊天机器人回复，而是一个必须经得起长期审视的决策。这种环境迫使采用不同于大多数AI工程内容所假设的设计理念。

当你无法对所有事情都保持概率性思维时，情况会发生怎样的变化，以及级联架构如何解决这些问题。

全LLM管道的隐形代价

将所有内容都通过大语言模型(LLM)路由的吸引力显而易见：更少的组件、更快的迭代速度、模型能够处理意外的边缘案例。但问题会在后续三个地方显现。

首先是可审计性。”模型根据检索到的上下文做出决策”不是可接受的答案。你需要一条人类无需重新运行推理并期望得到相同输出就能重建的决策路径。

其次是规模化成本。如果你的系统每天处理数万个案例，且每个案例都调用LLM并附带多个检索到的文档作为上下文，那么你的推理账单和延迟都会随着规模增长，而基于规则的逻辑则不会出现这种情况。

第三，也是讨论最少的一点，是在简单案例上的模型漂移。LLM擅长微妙的判断，但对于应该有确定性答案的案例，它们的表现却难以察觉地不一致。对已知标准的清晰结构匹配不应依赖于语言模型的状态。

级联方法

解决方案：不要将LLM视为前线，而是将其视为升级路径。在实践中，这意味着一个三阶段管道。

第一阶段是确定性的。精确匹配、结构化字段比较以及任何有明确规则的案例都在此阶段解决，完全不需要调用模型。这一阶段应该处理大部分案例，根据数据质量不同通常超过一半，每个决策都是完全可解释的，因为它是查找而非推理。

第二阶段是检索发挥作用的地方。对于通过第一阶段但未被明确解决的案例，你构建一个检索层，提取与模糊性相关的具体证据：类似案例的先前审查决定、解释明显冲突的上下文文档，或阐明边缘案例的历史先例。在这里，检索步骤比生成步骤更重要。如果检索到错误的上下文，即使是世界上最好的语言模型也会产生自信、合理但错误的答案。

第三阶段是LLM调用，它只应看到前两个阶段无法解决的剩余部分。这是人们在设计第一个版本时跳过的部分，同时也是成本和质量方面最大的杠杆。在我参与的一个系统中，仅将真正模糊的10-15%的案例路由到LLM，与全LLM基准相比就将推理成本降低了约6倍，同时将确定性多数情况的一致性提升到近乎完美。

为不对称风险设计提示

一旦案例到达LLM阶段，大多数团队默认使用中性提示：”评估此案例是否应被批准或标记”。这种表述对高风险分类来说是错误的，因为两种错误类型的代价并不对称。漏掉真正需要关注的事项可能导致下游的实际伤害；错误地标记正常情况则消耗审查人员的时间并造成延误。这两种结果很少同等糟糕，但中性提示却要求模型将它们视为同等重要。

不对称风险提示明确向模型展示了这种权衡，而不是让它猜测你的风险承受能力。具体来说，这意味着指导模型将不确定性视为升级的原因而非清晰判断，提供两种错误类型及其后果的校准示例，并要求模型在分类之外提供置信度评分，而非二进制答案。置信度评分成为你的第二个级联点：无论模型的分类结果如何，低于特定阈值的任何内容都会转给人审阅，而不是自动解决。

这听起来像是一个微小的提示工程细节，但实际上，这是区分一个减轻审查人员工作量的系统与一个表面上看起来正常但悄然增加风险的系统的关键所在。