702 篇博文 含有标签「llm」

成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。

没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。

账单在月初寄到，金额是你电子表格预测的三倍。没有人推送过系统提示词（system prompt）的更改。仪表盘显示请求量持平。p95 延迟看起来很正常。每个正确任务消耗的 token 比例（token-per-correct-task ratio）也没有变化。然而，你却欠了推理供应商额外的四万美元，而可观测性技术栈中唯一暗示了原因的信号，是一个大多数团队从未设置过报警的指标：缓存命中率（cache hit rate）。它在计费周期的第二周，也就是某个周二的太平洋时间上午 9:47，从 71% 掉到了 18%。而那个时刻，正是你最大的租户的客户成功团队为两百名新用户启动了一场协调一致的入驻活动。

欢迎来到提示词缓存抖动（prompt cache thrashing）—— 这种多租户故障模式本该在十年前就被 SaaS 策略手册消除，如今却通过推理供应商的共享前缀缓存（shared prefix cache）从后门溜了回来。供应商的缓存是在你组织的流量中共享的。无论你是否愿意，你的租户都在共享这个缓存，而一个租户的前缀形态在夜间发生改变，就可能逐出（evict）所有其他租户的单位经济效益（unit economics）所依赖的前缀。对于那些没做任何改变的租户来说，账单也会激增。财务部呼叫工程部，工程部指着显示一切正常的仪表盘，因为仪表盘并没有测量出那个已经损坏的环节。

你 Prompt 仓库中的 diff 显示有三行发生了变化。生产环境中的行为差异却显示一切都变了。安全团队将一条拒绝规则从第 14 行移动到了第 87 行，目的是为了“将其与相关的防护栏归类”；产品团队没有注意到这一点，因为措辞完全相同；一周后，评估套件显示在对抗性输入上的得分下降了 9 个百分点。没有人修改这条规则，只是有人移动了它。在一个拥有 2,400 token 的系统 Prompt 中，由于对防护栏存在首因效应（Primacy Bias），对指令遵循存在近因效应（Recency Bias），移动一条规则所带来的行为改变与重写它一样具有承重性——而你的工具对这两者都无法感知。

这是 AI 团队在回归评审结束时，而非开始时才会发现的合并冲突模式。系统 Prompt 在 2025 年底的某个时候增长到了 2K token 以上。安全团队负责顶部，产品团队负责中间，智能体（Agent）团队负责底部。三个月的“小幅编辑”在无声无息中重新排列了每个人的意图，因为原本适用于代码的基于行的 diff 工具无法告诉你一条指令已经跨越了区域边界。Bug 不在任何一次单一的编辑中。Bug 在于位置现在即策略，而你对位置却没有任何策略。

一个典型的 RAG 流水线包含两个模型，而不是一个。检索器从向量数据库中提取 50 到 100 个候选文档，而重排序器（reranker）——无论是交叉编码器（cross-encoder）、LLM-as-judge 提示词还是混合方案——都会对这些候选文档进行重新评分，并将前 5 个结果交给回答模型。你的评估套件测量端到端的回答质量，测量检索器的 recall@k，但它并不测量重排序器。因此，当重排序器发生隐性偏移（drift）时，仪表盘上显示的“回答质量下降了 4 个点”却没有任何因果线索，团队会花费三天时间去调试一个根本不是问题的提示词。

重排序器是那个隐性的第二个模型。它介于检索器和生成器之间，拥有自己的评分分布、自己的提示词（如果是基于 LLM）或自己的权重（如果是交叉编码器），并且它可以独立于其他任何组件发生性能退化（regress）。大多数团队从未单独对它进行评分。他们编写的评估套件将流水线视为一个具有长上下文窗口的单一模型，而实际上它是两个串联的模型，且其中间接口并不属于任何一个团队。

我在上季度接触的一个团队在他们的推理账单上发现了一笔 4200 美元的条目，没人能解释其来源。控制面板显示的流量正常，延迟图表也很平稳。原因最终被发现是一个 Agent 陷入了长达 6 小时的“礼貌”重试循环中，它不断地通过指数退避（最高限制为 30 秒后重启）来重放一个包含 4 万个 Token 的工具链。这套重试策略是直接从 2019 年为基于 HTTP 的 JSON 服务编写的内部 SRE 手册中照搬过来的。它运行得非常完美——只是用错了系统。

这就是那种不会出现在容量规划表中的账单。行业标准化的无状态 REST API 重试策略模式默认了三个前提，而 LLM 工作负载在悄无声息中违背了这些前提：故障是瞬时的、单次额外尝试的成本是有限的，以及重试有合理的成功机会。每一个前提曾是关键的支撑，而现在每一个都是错的。这种成本模型从未捕获的偏差，正潜伏在每一份月度账单的底部。

那些还没有根据 Token 经济学重建重试策略的团队，正在缴纳一种隐形税。这种税收随着你本就最担心的查询难度而增加——那些长文本、Agent 类以及带有深层工具链的查询。在 LLM 技术栈中，经典韧性工程提供给你的安全网，反而成了勒紧脖子的绞索。

打开你的结构化输出仪表盘。它自豪地显示着类似 “98.4% 的 Schema 合规率” 这样的数字。这就是成功率——即第一次尝试就生成有效 JSON 对象的请求比例。团队为剩下的 1.6% 构建了一个重试封装器（retry wrapper），发布上线，然后就没再管了。两个季度后，推理费用增长了 15%，而请求量仅增长了 4%。首席财务官（CFO）想要个解释。工程师们给不出解释，因为跟踪结构化输出成功率的仪表盘并不跟踪结构化输出的成本。

仪表盘隐藏的部分在于：失败路径并非只有一次重试。第一次重新提示（re-prompt）修复了缺失的 enum 字段，但引入了一个格式错误的嵌套数组。第二次重新提示修复了数组，但丢掉了一个必填键。第三次尝试终于通过了验证，但到那时，该请求已经消耗了四次完整的推理调用加上最初的生成过程，而你的单次请求 Token 计数器显示的是 总和，而不是循环过程。从计数器的角度来看，这是一个昂贵的请求。从成本线的角度来看，这是一个你从未定价的随机循环。

这篇文章将探讨该循环究竟对你的算力预算产生了什么影响，为什么你现有的观测能力（observability）无法察觉到它，以及哪些规范可以使其变得可见且可控。

我认识的一个团队花了三周时间追踪一个“上下文截断”的 Bug，这个 Bug 只在针对日本客户的生产环境中触发。他们的 CI 测试用例是英文的。他们的 tiktoken 计数显示 Prompt 符合 8K 的限制，且留有 600 个 Token 的余量。但供应商的账单显示，该请求因超过限制而被拒绝。这两个数字相差 11%，而安全余量正好落在在那 11% 之内，而且从未有人衡量过中日韩 (CJK) 文本上的这种差异。修复方案不是换一个新模型——而是不再将本地计数器作为事实标准。

这就是 Tokenizer 漂移那种隐蔽且昂贵的形式：不是一个简单的错误数字，而是一类在被你忽略的测试边界处累积的小型系统性误差。你 IDE 中的本地计数器、网关中的预算计算器、重试中间件中的速率限制评估器，以及供应商据以收费的权威计数——这些都不一致，而且差距恰恰在你用户所在的领域扩大。

你的代码库中有两种语言，但只有一种拥有编译器。一种是你的团队编写的严格类型的代码 —— 开启了 strict: true 的 TypeScript、CI 中运行 mypy 的 Python、强制返回值的 Go —— 另一种则是 Prompt：一个模板化的字符串，经过拼接后发送给远程模型，并返回另一个运行时希望能成功解析的字符串。在这两个区域之间，类型系统就成了瞎子。IDE 不会高亮任何内容。编译器不会发出任何报警。而那些凭借“但它通过了类型检查”就发布功能的团队，实际上将核心契约放在了契约检查器看不见的地方。

这个接缝伪装得很好。从外部看，它就像一个函数调用：generate(input: UserQuery): Promise<AgentResponse>。函数签名诚实地反映了输入和输出。而虚假的部分发生在调用点和响应之间：输入被插值到通过字符串引用字段名的 Prompt 模板中；模型被要求生成一个符合该 Prompt 内部以自然语言描述的 Schema 的 JSON 对象；响应作为一个字符串返回并交给解析器；最后解析器返回类型系统终于能再次看到的内容。两端的每一个类型化表达式都在对中间一个完全没有静态保证的区域做出断言。

这并非理论上的担忧。各团队报告称，在生产环境中，朴素的结构化输出基准 Schema 失败率为 10–20%，而且失败往往集中在那些你最无法承受无声丢弃的输入上 —— 长上下文、深层工具链、边缘情况用户。类型系统提供了一种虚假的正确感，直到格式错误的 JSON 返回且运行时将其吞下为止。

模型发布的公告在周二早上落地。博客文章开头是一张图表：HumanEval 提升了 4 个点，SWE-bench Verified 提升了 6 个点，MATH 提升了 3 个点，而当前流行的 Agent 测试套件提升的数值在一年之前足以写成一篇研究论文。到了周二下午，你公司的 Slack 频道里就会出现该图表的截图，随之而来的还有一个类似决策的问题：“我们要切换过去吗？”这个讨论线程将基准测试的增量视为一种预测 —— 仿佛这些数字描述了新模型在 你的 产品中、使用 你的 提示词、在 你的 工具链下、针对 你的 评估准则所能表现出的效果。事实并非如此。厂商给出的数字是你可能看到的性能上限。你实际获得的提升大约在零到该标题数值的一半之间，如果不运行一次厂商从未运行过的评估，你无法得知确切结果。

这并非在抱怨基准测试的有效性。基准测试是真实的。它们是针对真实的评估套件运行的。厂商没有撒谎。问题在于厂商的评估套件是一个理想化的环境，剥离了生产部署中引入的每一个变量，而在这些条件下生成的数字在结构上无法预测模型在你环境下的行为。将其视为一种预测是一种范畴错误 —— 它会导致采购决策、容量规划承诺以及发布时间表都基于虚构的事实进行校准。

模型团队可以演示新功能并展示十个令人信服的并排对比获胜案例。增长团队将其作为为期两周的 A/B 测试运行，得到 p = 0.31，读数显示“无显著效果”。两个团队都是正确的。实验是错误的。

这种模式在每个将 LLM 强行接入产品但未重建其实验栈的组织中不断重复。增长团队使用的数学模型是为按钮颜色、排名变化和定价页面设计的——这些功能的输出在给定用户和上下文的情况下是确定性的。LLM 功能打破了该数学模型赖以生存的两个假设，而标准的 80% 效能、5% 显著性、两周扩量模板在两个方向上都系统性地输出了错误的判断：真实的获胜被读取为无效结果，而噪声则被读取为置信的获胜。

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

仪表盘显示 p95 的 agent.run = 28s。用户反馈该功能感觉已经挂了。值班工程师打开 Trace（追踪），看到一个没有任何值得调查的子节点的“肥大”长条，然后开始盲猜。当有人重建出足够的心理模型，搞清楚瓶颈到底是模型、检索器，还是某个没人添加 Span 的工具调用时，故障已经变成了积压的任务单，而用户早已放弃了。

这就是 2026 年 Agent 运营核心的失败模式：传统的 APM 将 Agent 步骤视为一个黑盒，而“Agent 延迟”并不是一个单一指标——它是七个指标的总和，这些指标根据 Agent 在该轮次中的决策，以不同的方式分解实际用时 (Wall-clock time)。如果一个团队不暴露这七个数字，他们交付的功能虽然大家都能感觉到慢，但谁也无法修复。