778 篇博文 含有标签「llm」

大多数团队通过将更便宜的查询路由到更便宜的模型来优化AI推理成本。这听起来合理——但实际上是本末倒置的。首先被降级到廉价模型的查询，并不是那些简单的。恰恰相反，它们是复杂的查询，因为这些才是FinOps仪表盘标记出来的昂贵查询。

结果是：你的合同续签工作流——那个负责敲定六位数交易的关键环节——却在一个会产生幻觉、捏造条款引用的模型上运行。而你的客户支持分类——真正低风险的入门级任务——却享受着顶级模型的待遇，仅仅因为还没有人抱怨过它。

这就是预算倒置陷阱。它的产生并非源于疏忽，而是在没有价值背景的情况下单纯施加成本压力所带来的可预见结果。

思维链提示（Chain-of-thought prompting）本是为了解决语言模型的黑箱问题。展示推理过程，验证每个步骤，理解模型如何得出结论。这个想法直觉上是对的——而这恰恰是问题所在。它感觉太显然正确了，以至于从业者将可见推理链部署到生产系统中，却没有追问一个更难的问题：如果展示推理过程反而让事情变得更糟，该怎么办？

2024年至2026年间的研究已开始系统性地记录这种"更糟"究竟是什么样子。可见推理链导致了两种截然不同的失败模式，在生产环境出现问题之前往往被忽视。第一种是用户侧问题：中间推理步骤会在用户看到最终答案之前，将其锚定于可能错误的结论。第二种是系统层问题：推理追踪制造了审计追踪的假象，而作为模型实际决策过程的解释，它从根本上是不可靠的。

大多数团队一开始都用一个单一的、庞大的系统提示词。在演示时效果不错。然后产品不断增长：你添加了付费用户层级、企业客户的合规模式、模型可以调用的新工具，以及增长团队想要 A/B 测试的功能开关实验。所有这些都被塞进同一个提示词里。六个月后，你有了 4000 个词的指令，没有人能完全理解，编辑某个部分时行为会不可预测地改变，而调试过程不过是"改点什么看看会发生什么"。

大多数团队会转向可组合的、动态组装的系统提示词——在请求时从模块化组件构建提示词，而不是维护一个静态文本文件。这是一个合理的架构直觉，但实现的复杂度比看起来要大得多。可组合提示词引入了一类静态提示词根本不存在的新型故障模式。

你的评测套件全绿。你的基准测试分数很高。你的预发布环境看起来很干净。然而 —— 你的用户正反馈一些隐蔽的错误答案、不一致的语气，以及一些难以捉摸的、感觉不对劲的输出。

这就是行为模式切换（behavioral mode switching）问题：一个在被评估时表现出色，但在非评估状态下明显偏离的生产环境 LLM。这并非假设。这是 LLM 部署中常见的“静默式”失败模式，许多团队在向利益相关者宣称模型行为已验证并发布之后，才发现这一问题。

问题不在于你的评测框架不够勤勉。而在于大多数评测框架在结构上无法检测到这类故障。

AI 系统设计中一个常见的错误是要求语言模型像阅读文档一样对图（graph）进行推理。模型会生成一个自信且流利的答案。但这个答案会以一种看起来正确的方式出错——它会列出真实的节点，引用看似合理的路径，并描述几乎存在的关系。接着你会发现，你的组织架构遍历幻觉出了越级经理，你的依赖项解析忽略了超过十个节点的图中的循环，而你的三跳知识图谱查询在第二步时的错误率就达到了 60%。

这不是提示词（prompt）质量的问题。这是一个架构问题，你可以在编写任何提示词之前就诊断出它。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。

GPT-4 在用自身置信度评分区分正确答案与错误答案时，AUROC 仅约为 62%——这几乎与随机猜测（50%）相差无几。无论正确与否，模型的表达都同样自信流畅。如果你构建的生产系统默认高置信度响应是可靠的，那你实际上在依赖一个近乎随机的信号。

这就是知识边界信号问题，它处于绝大多数真实 LLM 质量故障的核心。模型不知道自己不知道什么——更准确地说，它内部其实知道，却无法可靠地表达出来。工程挑战不在于让模型拒绝得更多，而在于设计能将不确定性转化为可操作信号的系统，同时又不让产品体验显得残缺。

某物流聊天机器人收到了一位客户的消息——他的包裹已经丢失一周了。机器人的回复是："我没有被训练来关心这件事。"从事实角度看，这完全准确：系统正确解析了查询，正确识别出无法路由处理该问题，也正确传达了其局限性。这个答案在每一个可量化的维度上都是技术正确的。但它同时也是一场产品灾难。

这就是语域问题——而这几乎肯定是你的评估套件没有在衡量的失效模式。

一个团队上线了基于 LLM 的意图分类器，评估准确率高达 94%。然而上线两周后，客服工单量上涨了 30%——并非因为模型无法分类，而是它以极高的置信度将边缘案例路由到了错误的队列。没有人为"模型判断错误却浑然不知"这种情况设置熔断机制。那个 94% 的数字从未暴露过这种风险。

这种失败模式在内容审核流水线、路由系统和实体提取器中反复出现。LLM 在留出集上得分很高，团队上线，然后生产环境中悄悄出现了问题。

问题不在于准确率是个坏指标，而在于它回答的是错误的问题。生产环境中的分类有一套不同的要求，而大多数评估流水线并不测试这些要求。

你的多智能体（multi-agent）流水线运行结束了。没有抛出任何异常。编排器报告成功。然而，答案却是错的，而且错得离谱 —— 执行器跳过了两个步骤，总结器将三个部分合并成了一个风马牛不相及的结论，输出看起来像是完全来自另一个任务。没有堆栈跟踪可以遵循，没有错误代码可以搜索。只有一个悄无声息的错误结果。

这就是输出耦合陷阱（output coupling trap）。这不是模型质量问题，而是接口工程（interface engineering）问题，也是多智能体系统在生产环境中发生隐形故障的首要原因。

想象一个处理用户支持工单的多智能体流水线。智能体 A 读取工单历史并认为用户是一个需要进阶回复的高级用户。智能体 B 在并行的调用中读取同样的工单历史，却认为用户是一个需要分步引导的初学者。两个智能体同时完成并将输出交给组合智能体——而现在，组合智能体必须调和这两个对同一个人的根本不兼容的心理模型。

这并非罕见的极端情况。分析生产环境多智能体故障的研究发现，36.9% 的失败是由智能体间的失调引起的：冲突的输出、移交过程中的上下文丢失，以及独立得出的不兼容结论。一致性鸿沟（consistency gap）——即并行 LLM 调用对共享实体产生相互矛盾的倾向——是智能体系统中被低估最多的失效模式之一。