AI 泛滥反模式：过度使用 LLM 只会让你的流水线更糟

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

"LLM 能做，就应该用 LLM"的问题

导致这种局面的思维模型是可以理解的：LLM 灵活、能优雅地处理边缘情况，还消除了编写显式规则的需要。既然 LLM 能解析，为什么还要维护基于正则的提取器？既然可以用自然语言描述规则让模型来解释，为什么还要写规则引擎？

问题在于"能做"和"应该做"是两个不同的问题，而将它们混淆的代价会在流水线的每一步上不断叠加。

以一类真实场景为例：将支持工单路由到正确的团队。一个 LLM 泛滥的朴素实现会调用模型，将工单文本发送给它，并让它对类别进行分类。这能工作。但它还会产生约 0.60–3.00 美元每千张工单的成本（取决于模型选择），每次请求增加 200–400 毫秒延迟，在供应商更新模型行为后以不可预测的方式失败，并在某一天对同一张工单给出不同的答案。而一个基于关键词匹配和主题查找表的路由函数，可以即时处理 80% 的工单，成本几乎为零，并且保证一致性。LLM 应该处理剩余的 20%——那些规则真正失效的模糊情况——而不是全部。

这里的比例很重要。如果你为 100% 的请求支付 LLM 的延迟和成本，但实际上只有 20% 真正需要模型，那么你引入了 5 倍的开销，而对于简单的大多数却没有任何质量提升。

反模式的根源

三股力量驱使团队走向 LLM 泛滥：

组织压力。 AI 项目吸引资金、关注和兴趣。将一个流水线描述为"每个阶段都由 AI 驱动"听起来很厉害。注意到低效问题但无法掌控话语权的工程师，很难提出反对意见。

工具诱惑效应。 一旦你的团队拥有了 LLM API 访问权限，每个问题看起来都像是语言理解问题。格式转换？LLM。日期规范化？LLM。判断这个字段值是正面、负面还是中性？LLM。这个模式在没有人主动选择的情况下成为默认值。

隐形的逐步成本。 单次 API 调用单独看来很便宜。只有当你把请求量和链条长度综合计算时，账单才会变成预算会议的议题。构建各个步骤的工程师往往在为时已晚、难以廉价重构之前，看不到累积成本。

何时不该使用 LLM：一个分类框架

有用的问题不是"LLM 能做这个吗？"而是"这个任务需要语言模型推理，还是只需要计算？"

不需要 LLM 推理的任务：

• 符合模式的解析。 如果你在从结构化表单、数据库记录或定义明确的模板中提取字段，确定性解析可以在微秒级延迟下达到 99%+ 的准确率。LLM 需要 200+ 毫秒，只能达到 80–95% 的准确率。你在用 200,000 倍更长的时间和可观的费用换来更低的可靠性。
• 边界清晰的分类。 根据发件人域名和邮件头模式判断垃圾邮件。根据产品领域分配路由。根据关键词判断支持工单优先级。这些都有可以枚举的决策边界。基于规则的分类器在微秒内运行并产生可审计的决策。
• 格式转换。 CSV 转 JSON。ISO 日期字符串转时间戳。规范化电话号码格式。这些都是函数。把它们写成函数。
• 验证。 字段是否存在、是否匹配正则、值是否在预期范围内——这些都是确定性检查。通过 LLM 运行它们会增加延迟、成本，以及模型"认为"某个值足够接近（即使它不是）的可能性。
• 查找和检索。 如果答案是键值查找、数据库查询或简单过滤，就这样做。模型能回答"法国的首都是哪里"，并不意味着你应该把这个查询路由给 LLM。

真正需要 LLM 推理的任务：

• 具有语义歧义的开放式文本理解。
• 中间结论依赖上下文的多步推理。
• 跨异构来源的综合与摘要。
• 语气和流畅度重要的自然语言回复生成。
• 只有少量示例且没有标注训练集时的少样本分类。
• 处理规则系统明确无法枚举的边缘情况。

分界线大致是：解决这个任务需要理解自然语言的含义，还是只需要执行一个函数？如果是后者，默认用函数。

复合可靠性问题

LLM 泛滥不仅仅是成本问题，它还是一个随链条增长而恶化的可靠性问题。

在合理质量层级下，单次 LLM 调用对相同输入的一致性可能在 85–90%（temperature=0 并不能完全解决这个问题——浮点非确定性、批处理效应和供应商侧的模型更新都会引入方差）。当你串联四个这样的步骤时，预期的端到端一致性降至约 52–66%。你的流水线看起来在工作，但其行为是一个移动目标。

这有具体的调试后果。当一个多步 LLM 流水线产生错误答案时，追踪哪个步骤引入了错误，需要在每个阶段捕获中间输出、跨运行进行比较，并对概率性失败进行推理——传统调试工具对此支持都很差。报错信息毫无帮助。日志显示流水线成功完成。模型返回了一个看起来合理的结果。找到有问题的步骤是法证工作。

确定性组件以明显、可追踪的方式失败。LLM 则以隐蔽、自信且不一致的方式失败。流水线中每一个你能引入的非 LLM 步骤，都是一个更可靠的锚点，能够缩小失败面。

流水线审计启发式方法

在审查现有流水线是否过度使用 LLM 时，对每个步骤最有用的问题是：这个决策能否被一个具有定义输入和输出的函数精确复制？

如果是，这个步骤就是替换候选。逐项检查以下清单：

1. 如果这个步骤出错，失败模式是什么？ 如果答案是静默的、难以检测的错误（模型返回了一个看似合理但错误的 JSON 字段值），那么不可预测性的风险很高，应该倾向于确定性逻辑。
2. 正确性是否依赖于本地不可用的上下文理解？ 如果该步骤只需要单个字段的文本或已知数据结构，它不需要模型。
3. 有多少比例的输入是模糊的？ 如果你的 5% 输入是真正模糊的，95% 遵循清晰模式，LLM 应该处理那 5%——而不是全部。构建一个分类器，只在确定性路径失败时才路由到 LLM。
4. 这个步骤是否在面向用户请求的热路径上？ 每次 LLM 调用会增加 100–400 毫秒的延迟。在同步请求链中，三次不必要的调用会增加半秒。
5. 你能审计这个决策吗？ 监管环境、支持工作流和金融应用通常需要对决策原因有清晰的解释。"模型决定的"不是一个可审计的答案。"因为工单包含关键词 Y 而路由到团队 X"是可以的。

真正有效的混合模式

对于复杂流水线，最可靠的架构是级联，而不是链式。

对于任何给定的任务，构建一个处理清晰情况的确定性快速路径，做到便宜且一致。在其上层叠加一个 LLM，只处理快速路径明确无法覆盖的情况——模糊输入、新颖模式、超出规则空间的边缘情况。使用置信度阈值或确定性层的明确"不知道"回退来路由到模型。

这种模式：

• 让大多数流量保持快速和廉价
• 将非确定性限制在真正需要它的输入上
• 使失败可追踪——如果确定性路径处理了 85% 的请求，你发现回归时，立即知道问题是在规则逻辑中还是在 LLM 中
• 允许用标准单元测试对快速路径进行穷举测试
• 使 LLM 的范围足够窄，其提示保持简单，失败模式更易于理解

关键纪律是积极抵制当快速路径"大部分能用"时扩展 LLM 范围的诱惑。大部分能用是生产确定性逻辑的标准，而不是移交给语言模型的标准。

组织层面的解决方案

一旦做出决定，技术重构通常是直接的。更难的问题是组织层面的。

工程师默认使用 LLM，部分原因是"你考虑过更简单的方法吗？"比"你为什么没有用 AI 做这个？"更不可能被问到。创造空间来深思熟虑地选择确定性方法，需要让成本和可靠性权衡变得可见。那些汇总每个功能的 token 成本、在追踪中测量逐步延迟，并要求解释为什么每次 LLM 调用是必要的——而不是为什么跳过它是合理的——的团队，往往能构建更精简的流水线。

有用的框架不是把"LLM 与确定性逻辑"作为一场哲学之争。而是：LLM 是昂贵的、非确定性的工具，应该在真正需要其特定能力的地方部署。其他一切都应该在解决问题的最便宜、最可靠的原语上运行。只在需要的地方使用 LLM、其他地方不用的流水线，是那种能在生产负载下撑得住、随量扩展可预测、在失败时依然可调试的系统。

大多数流水线还没做到这一点。大多数都可以通过一次审计、一个路由层，以及将"我们能用函数代替吗？"视为一等架构问题的纪律来实现。