639 篇博文 含有标签「llm」

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

在技术领域，LLM 虚构（confabulation）的阴险之处不在于模型会给出明显的错误答案。而在于它会生成结构优美、语气自信、技术上看似合理的答案，但其中的细微错误只有领域专家才能发现——而且往往是在造成损失之后。

一个 Monte Carlo 物理模拟，它初始化正确，但在每一步都从头重新采样粒子位置，而不是进行增量更新。一个符合命名规范但氧化态错误的化学公式。一份引用了正确标准、参考了正确单位，但载荷系数完全错误的设计规范。每个输出看起来都是正确的。每个听起来都极具权威。但每一个都是错误的，且这些错误只有在有人运行实验、对组件进行压力测试或仔细阅读推导过程时才会浮现。

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%，p=0.03。他们将其视为胜利并向所有人发布。六个月后，一次客户审计发现，新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的：按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下，输出是稳定的，方差较小且易于理解，教科书中的样本量计算公式也适用。然而，对于由 LLM 驱动的功能，这些属性都不成立。如果团队不考虑这一点，他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

2023 年初，大量企业 AI 培训项目带着同一个卖点涌现：我们将教你的工程师提示工程。然而大多数项目完成第一批学员培训时，所教的具体技术已被模型自身自动化淘汰。到 2025 年，曾短暂标价 20 万美元年薪的"提示工程师"职位实际上已走向消亡。而那些培训项目依然在运转。

这就是 AI 课程陷阱。它不是努力或预算的问题。各组织在结构化 AI 培训、认证项目和以工具熟练度为核心的招聘标准上投入了大量资源。但工具的迭代速度快于任何课程所能追赶的速度，结果是一种永久性的结构性滞后：培训项目始终在教 18 个月前的 AI 工程。