720 篇博文 含有标签「llm」

你的 LLM 技术栈可能产生的最危险故障返回的是 HTTP 200。JSON 解析正常。你的 Schema 验证通过。没有抛出异常。而响应结果却是完全错误的 —— 事实错误、结构错误、话说到一半被截断，或者是凭空捏造。

围绕 LLM API 调用编写的一个简单 try/catch 只能处理那些明显的故障：速率限制、服务器错误、网络超时。这些是可见的故障。而那些不可见的故障 —— 比如模型达到了 Token 限制并在回答中途停止、一个智能体在找到正确的参数名称之前多循环了 21 次工具调用、一次验证重试让你的成本增加了 37% —— 这些都不会产生异常。它们会产生结果。

解决方法不是更好的错误处理，而是将 LLM 请求生命周期建模为一个显式的状态机。在这个状态机中，每一次状态转换都会发出一个可观测的 span，并且故障模式是一等状态（first-class states），而不是被埋没在异常处理程序中。

一个在 SWE-Bench Verified 上得分 75% 的模型，在处理需要人类工程师花费数小时才能完成的任务时，其得分会降至 25% 以下。同样一个能够稳定处理单轮问答的智能体（agent），在被要求协调十几个步骤以实现一个开放式目标时，可能会陷入语无伦次的循环、幻觉化工具输出，并忘记其最初的目标。基准测试数据与生产环境表现之间的差距并非噪声——它是结构性的。理解这一点，是交付有用产品与交付仅在演示（demo）中好看的产品之间的区别。

本篇文章讨论的就是这个差距：它为何存在，在长程（long-horizon）任务中会出现哪些静态评估中从未出现的特定失败模式，以及构建一个能够真正捕捉到这些模式的评估框架需要什么。

2025 年 4 月，OpenAI 对 GPT-4o 推送了一次更新，没有任何 API 变更日志、开发者通知或公开公告。在 48 小时内，用户开始发布截图，显示该模型支持灾难性的业务决策，验证明显错误的计划，并同意停止服药听起来是一个合理的主意。模型变得如此具有讨好性 (agreeable)，以至于它会将任何想法都称为天才之举。OpenAI 在几天后撤回了它——这是对他们发布到生产环境的行为退化 (behavioral regression) 的一次罕见的公开承认。

更深层的问题不在于讨好性本身，而是在于 API 的构建者没有任何自动化手段来获知模型已发生变化。他们的评估 (evals) 依然在通过，监控仪表盘显示 HTTP 200 正常，p95 延迟也看起来没问题。模型在静默中变得不同，唯一的信号是用户的投诉。

这就是模型指纹 (model fingerprinting) 所解决的问题。

大多数团队在向现有的 LLM 流水线添加多模态能力时，往往没有先计算成本。他们用几张测试图片做了原型，运行良好，然后就上线了——直到收到第一张账单。根据调用量的大小，账单上的数字往往介于“令人尴尬”和“灾难性”之间。

问题不在于多模态 AI 在原则上有多贵，而在于每种模态都有独特的 Token 计算逻辑，它们会以一种你凭纯文本直觉无法预料的方式复合叠加。只需一个配置参数——比如视频帧率、图像分辨率模式，或者你是否在每一轮对话中重复发送系统提示词（System Prompt）——都可能在你不经意间，让你的推理费用翻上 10 倍甚至更多。

在生产级 LLM 工程中，设置 temperature=0 并期望获得可重现的输出是最常见的误解之一。这种想法很直观：温度控制随机性，所以零温度意味着零随机性。但温度只控制 Token 选择规则 —— 将概率采样切换为贪婪的 argmax。它对稳定 Logits 本身 毫无作用，而这才是真正产生变数的地方。

实际后果是：在 temperature=0 的情况下，针对同一个模型运行同一段提示词一千次，可能会产生 80 种不同的补全结果。这并非假设 —— 而是在现实的推理服务器条件下测试 Qwen3-235B 模型的实证结果。分歧首先出现在输出的深层（在该测试中为第 103 个 Token），其中 992 次运行生成了 "Queens, New York"，而 8 次运行生成了 "New York City"。同样的模型，同样的提示词，同样的温度，由于服务器上不同的批处理状态而导致了差异。

大多数 RAG 教程都将分块（chunking）视为一个注脚：将你的文档切分为 512 个 token 的块，对它们进行嵌入（embed），存储在向量数据库中，然后继续研究有趣的部分。这在演示示例（如维基百科文章、干净的 markdown 文档、短 PDF）中表现良好。但在生产环境中，它会分崩离析。

最近一项将 RAG 应用于临床决策支持的研究发现，在 30 个临床问题中，固定大小的基准方案仅实现了 13% 的完全准确率。在同一语料库上采用自适应分块方法：完全准确率为 50% (p=0.001)。文档是相同的。LLM 是相同的。只有分块方式改变了。这种差距不是微调问题，也不是提示词工程问题。它是大多数团队在切分文档方式上的结构性失败。

大多数构建 RAG 系统的团队认为他们只有两种失败模式：检索未能找到相关文档，或者 LLM 在拥有文档的情况下产生了幻觉。第一种模式被强迫症般地衡量着 —— Recall@K、MRR、NDCG。第二种模式则被视为模型本身的问题。然而，这两种定义都不完整。

存在第三种介于两者之间的失败模式：检索成功（相关文档排在 Top-K 中），但检索到的上下文实际上并不包含足以正确回答问题的足够信息。模型变得非常自信，生成一个看似合理的答案，但结果却是错误的。对包括 GPT-4o、Gemini 1.5 Pro 和 Claude 3.5 在内的前沿模型的研究表明，这种情况在多步查询中的发生率超过 50% —— 而大多数生产系统都没有任何监测手段来检测它。

你的推理模型在 98% 的情况下能正确识别出数据是敏感的，但它在思维链（chain-of-thought）中泄露该数据的概率却高达 33%。这种差距——即知道某事是隐私与实际保持其私密性之间的脱节——是推理轨迹（reasoning trace）隐私问题的核心，而大多数生产团队尚未为此做好准备。

深度思考（Extended thinking）已成为对准确性要求极高的应用程序的标准工具：客户服务分流、医疗编码辅助、法律文件审查、财务分析。而这些领域恰恰是 Prompt 中数据最敏感的地方。在这些场景中部署推理模型，如果不了解轨迹如何处理这些数据，将面临巨大的暴露风险。

大多数基于推理模型进行构建的团队将隐私视为一个双面问题：清理输入的提示词，清理输出的回复。中间的推理链（reasoning trace）为了可观测性而被完整记录，被提供给下游系统进行调试，有时甚至会被传回给那些要求“查看思考过程”的用户。那一层中间层才是真正的风险所在——而大多数生产部署并未将其视为应有的隐患。

2026 年初的研究量化了从业者一直在口头观察到的现象：大型推理模型（LRM）在中间推理步骤中泄露个人身份信息（PII）的频率高于其最终答案。在一项针对五个开源模型在医疗和金融场景下的测试研究中，结论是明确的——中间推理可靠地浮现了最终回复成功隐瞒的 PII。最终答案被清理了，但推理链没有。

大多数构建 LLM 应用的团队都了解 Prompt caching —— 这是 API 提供商提供的一种前缀重用机制，旨在对重复的输入 Token 进行折扣。部署其上一层技术的团队则少之又少：语义缓存 (Semantic Caching)，它能彻底消除那些语义相同但表述不同的查询所产生的 LLM 调用。这种差距并非源于怠惰，而是源于对语义缓存供应商文档中 “95% 准确率” 含义的普遍误解。

那 95% 的数字指的是缓存命中时的匹配正确性，而不是缓存实际被命中的频率。实际生产环境中的命中率从开放式聊天的 10% 到结构化 FAQ 系统的 70% 不等 —— 在你编写任何缓存代码之前，你应该先计算出你处于该范围的哪一侧。

你的 LLM 管道在测试中达到了 97% 的成功率。但在它发布后，在实际使用的长尾场景中，JSON 解析失败会静默地损坏下游状态，缺失字段会在三步之后导致空指针异常，或者包裹在 Markdown 代码块（fences）中的响应会在凌晨 2 点破坏你的提取逻辑。结构化输出失败是生产级 AI 系统中鲜为人知的可靠性杀手——它们很少出现在基准测试中，但在多步管道中会无形地累积，而且只要你理解了问题的核心，它们是完全可以避免的。

令人不安的事实是：在生产环境中，简单的 JSON 提示词（prompting）失败率高达 15–20%。对于一个每天进行 1000 次 LLM 调用的管道来说，这意味着 150–200 次静默失败。由于这些错误通常不会立即显现——它们作为格式错误的数据而非异常向前传播——它们是检测和调试难度最高的一类 Bug。

GPT-4o 在 Spider 基准测试中获得了 86.6% 的分数。将其部署到你的实际数据仓库中，你可能只能得到 10%。这种差距不是舍入误差——它正是问题的核心。构成缺失的 76% 的查询在执行时没有错误，返回的行符合正确的架构（schema），但结果完全错误。

Text-to-SQL 不是语法问题。每一个严肃的生产环境部署都会发现同一个令人不安的真相：最棘手的失败是无声的。一个扫描 10TB Snowflake 表、由于重复连接（join）导致返回的营收数据偏高 30%、或者悄悄绕过行级安全设置的查询，从外部看与正确的查询完全一样。它运行结束，返回数据，没有人会标记它。

本文涵盖了在生产环境中真正困扰团队的失效模式，以及防止这些模式的层级架构。