702 篇博文 含有标签「llm」

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

我认识的一个团队构建了一个带有智能体循环的金融助手。第一周，API 费用是 127 美元。第十一周，费用飙升至 47,000 美元——同样的系统，同样的功能，范围上没有任何有意的变化。智能体触及了速率限制，重试逻辑忠实地进行了重试，循环没有熔断器，成本在悄无声息中不断累积，直到有人注意到他们设置得太高的计费告警。

这不是一个 bug 的故事，而是一个架构的故事。团队的思维模型将速率限制视为需要被动处理的错误。他们构建的系统完全反映了这种模型。那 47,000 美元的那一周，正是系统按设计运行的结果。

每个 AI 产品团队的某个角落都有一个安全仪表板，显示着被拒绝的请求。触发了哪些过滤器，拦截了哪些越狱尝试，抓住了哪些违反政策的行为。运营团队通过它来确保防护栏（guardrails）稳固，而其他人都对其视而不见。

这是一个错误。AI 拒绝的请求是你所能接触到的最集中、最真实的用户调研信号。如果一个用户尝试了三种不同的措辞，想让你的产品去做它不愿做的事情，他是在以极其清晰的方式告诉你，他到底想要什么以及无法得到什么。将这一信号视为安全产物而非产品产物，是在浪费你所能收集到的最宝贵的反馈。

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

大多数 LLM 系统故障并非源于模型出错。而是源于系统误判了模型能够强制执行的约束。当你在系统提示词中写下“绝不泄露客户数据”并将其等同于“撤销数据库凭据”时，你引入了一个范畴错误。这最终会导致安全事件、可靠性故障或受损的用户体验——而你直到故障在生产环境中发生时才会察觉。

软约束与硬约束之间的区别是架构层面的，而非风格层面的。搞错这一点不会导致风格退化，而是会导致安全漏洞。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。

Google Research 有一个令人不安的发现：当 RAG 系统检索到不足或过时的上下文时，幻觉率并不会保持不变——它会从 10.2% 飙升至 66.1%。增加一个陈旧的知识库并不会让你的 AI 帮助中心保持中立。它会让你的 AI 给出自信错误答案的可能性比你什么都不发布还要高出六倍。

大多数构建 AI 驱动的搜索和帮助中心的团队都专注于检索质量、嵌入模型和分块大小。几乎没有人建立流程来追踪语料库中的文档是否仍然准确。这种差距——文档债（documentation debt）——现在正表现为生产环境的可靠性问题，而不仅仅是内容问题。

你的 AI 功能在上线时运行良好。六个月后，它有时给出简短的一两句话，有时写出五段长文，偶尔还会拒绝回答上个季度毫无障碍地处理过的问题。代码库中没有任何变化——至少你是这么认为的。实际上，系统提示在悄然改变，经过四名工程师跨两个团队提交的十一个拉取请求，逐步演变。每次改动单独来看都合情合理，但合在一起，却将你的提示变成了一台矛盾制造机。

这就是指令冲突问题。它不会抛出异常，不会出现在错误日志中，而是以行为漂移的形式表现出来——模型在细微不同的情境下做出细微不同的事，难以复现，更难溯源。等到用户提交 bug 报告时，提示可能已经被再次打过两个补丁了。

一对 LangChain 分析/验证智能体连续运行了 264 小时，产生了 47,000 美元的 API 费用，却没有任何有用的产出。验证智能体持续拒绝分析智能体的输出，但从未说明原因；分析智能体则默认再次尝试。没有人写过停止条件，循环一直运行，直到有人注意到账单。

这是架构图中从不出现的失败模式：知道如何调用工具，却不知道何时停止的智能体。经典的智能体循环是一个不断询问模型"我应该调用工具吗？"的 while True——但这个问题对"我已经看到足够的信息了"没有内置答案。没有收敛逻辑，你构建的不是智能体，而是一个昂贵的轮询函数。

一家物流公司花费了 80 万美元、历时十二个月，尝试用 AI 优化路线规划。项目结束时，他们的路线效果仅比原有启发式规则略有提升。高管层随后否决了接下来三个 AI 提案。一家外卖公司面临同样的路线问题，却用一套显式业务规则在一个晚上就解决了。

两支团队都学到了一个代价高昂的教训：在实时约束、司机偏好和时间窗口交织的路线优化问题中，AI 并非 正确的解法——这是一个组合调度问题。你想要学习的模式并不隐藏在数据里；它们是运营部门的人早就知道的显式领域逻辑。

这种情况在各行各业不断上演。2025 年麻省理工学院的一项研究发现，95% 的企业 AI 试点项目未能产生任何可衡量的业务影响，尽管总投资高达 300 至 400 亿美元。最主要的失败原因不是模型差或数据不足，而是团队在 AI 根本不是正确工具的问题上构建了 AI 解决方案。

一个构建基于LLM的文献筛选工具的团队在测试集上庆祝96%的准确率。按照任何标准工程指标，他们的模型表现都非常出色。但有一个问题：它找到了零个真正的阳性结果。该模型学会了将所有内容归类为无关内容，但仍然获得了近乎完美的准确率，因为相关论文在数据集中极为罕见。失败不在于模型——而在于指标。

这种失败模式并不罕见。它每周都在AI团队中悄然上演，工程师在没有产品输入的情况下选择评估指标——就像选择排序算法一样，视其为有正确答案的技术选择。这种框架是错误的。指标选择是一个产品决策。它编码了你愿意容忍哪些失败模式、你在为哪些用户优化，以及在你的特定场景中"好"究竟意味着什么。搞错这一点会产生看起来严谨却衡量了错误事物的评估套件。