990 篇博文 含有标签「insider」

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

发现你上线了一个 AI 智能体的最糟糕时机是在事故复盘中。不是在设计文档里，不是在架构评审中，也不是在变更工单里 —— 而是在事故复盘现场，律师正询问为什么在未经授权的情况下给客户退了款，而一名工程师正翻找着一个上次进行实质性评审还是在 11 个月前的服务，然后在名为 enrichTicket 的函数第 40 行处，发现了一个模型调用，它读取客户记录、决定处理方案，并调用了计费 API。没有人画过它的架构图。没有人批准它作为一个智能体运行，因为对于编写它的人来说，它根本不是智能体。它“只是一个辅助工具”。

这就是影子 AI，它已经露出了獠牙。第一波浪潮是员工将公司数据粘贴到消费级聊天机器人中 —— 这是一个数据泄露问题，虽然严重但尚在可控范围内。第二波浪潮是智能体：嵌入内部工具的模型调用，它们读取真实数据并执行真实操作，潜伏在那些原本为完全不同的用途而获批的服务中。大约一半的员工承认使用了雇主从未批准过的 AI 工具，而且很大一部分比例的使用来自高层 —— 总监和高管是主要的“元凶”，而不是实习生。当这种本能延伸到你的代码库时，你得到的不再是一个泄露的电子表格。而是一个拥有生产环境凭据且未经任何人签字批准的自主代理人。

令人不安的是，影子智能体并非由鲁莽的人创建。它们是由优秀的工程师创建的，而他们只是在执行你的要求：快速交付价值、复用现有基础设施、不要为每一个微小的改动都提交工单。治理差距并不是纪律问题。它是一个定义问题 —— 你的评审流程中根本没有他们所构建内容的对应类别。

你的评估仪表盘是一片绿色。单轮准确率（turn-level accuracy）保持在 95%，LLM 裁判（LLM judge）与你的标注人员意见一致，每一项回归测试在上线前都顺利通过。然后，一名用户提交了一个 bug：在第九轮对话中，智能体推荐了一个 Postgres 索引，但这直接违反了用户在第一轮中设定的“我们使用的是 DynamoDB”这一约束。你调出对话记录。每一轮对话如果拆开来看，都是合理的回复。但如果把整个对话作为一个整体来看，那就是一场灾难。

这是单轮评估（turn-level evaluation）的核心谎言。它对“请求-响应”对进行评分，因为这是标注成本最低的单位，并且它默认假设一段对话仅仅是你可以取平均值的独立轮次的组合。事实并非如此。第九轮的响应是以之前发生的一切为条件的，而那些真正触达用户的失败几乎从未存在于单轮对话内部——它们存在于轮次之间的缝隙中，在那里状态丢失、假设变得僵化，微小的错误复合成一个完全错误的最终答案。

这次升级看起来就像是白捡的便宜。供应商发布了一个更新的模型，它在每一项公开基准测试中的得分都更高，每个 token 的成本更低，且生成 token 的速度更快。你在一个配置文件里修改了模型字符串，运行了评估套件，看着 340 个测试用例全部变绿，然后在周二下午发布上线。到了周四，客服工单不断增加，却没人能指出到底是哪一个测试失败了。

这是应用层 LLM 开发中最令人困惑的失效模式，因为它违反了其他所有软件与你达成的契约：如果测试通过，行为就保持一致。在这里，该契约失效了。模型升级不是对一个你可控接口的库进行版本更新。它是一次对概率函数的无声、大规模更替，而你的评估套件只检查了你想到要写下来的那一小部分行为。

真正带来伤害的退化往往存在于你从未编码定义过的行为中——语气、冗余度、格式习惯，以及模型如何处理请求中模糊的中间地带。这些恰恰是你的用户所依赖的东西，也恰恰是 pass/fail 断言无法察觉的东西。

事故的开端和大多数此类事件如出一辙：周二下午两点，一个面向客户的功能在生产环境中不断抛出 429 错误。没有新代码部署，没有流量激增，该功能自身的日志中也没有任何解释。值班工程师盯着仪表盘看了二十分钟，直到另一个频道的某人随口提到，他们刚刚启动了一个“快速回填（backfill）”任务，要对几十万份旧文档重新生成摘要。两个团队，两套代码库，两组值班轮换——而它们之间共用一个 API Key 的速率限制。回填任务吃光了配额，聊天机器人则被“饿死”了。

这就是“吵闹的邻居”（noisy neighbor）问题。而让模型 API 变得如此危险的转折点在于，这个“邻居”并不是共享云硬件上的某个匿名租户，而是你自己公司里的另一个团队。你们之间的那道墙比任何人想象的都要薄。

事故排查会议（incident bridge）安静得有些异样，这意味着大家都卡住了。一份支持工单显示，智能体（agent）告诉客户其退款已获批准，而事实并非如此。你有完整的追踪记录：提示词（prompt）、检索到的账户记录、工具调用、模型的推理过程以及最终的消息。你重放了一遍，智能体的操作是正确的。你又重放了一遍，依然正确。十次中有九次，产生该事故的追踪记录反而生成了正确的结果。会议上终于有人提出了那个复盘模板（retro template）无法处理的问题：那么，根本原因是什么？

根本没有。至少不是模板所指的那种。五个为什么（five-whys）的链条是这样运作的：“智能体告诉了客户错误的信息” → “因为模型生成了批准” → “因为它采样了一个断言批准的 Token 序列” → “因为……这是概率分布所允许的。”最后一个“为什么”最终以耸耸肩告终。“模型采样了一个错误的 Token”在技术上是正确的，但在操作上毫无用处。它没有指明修复方案，没有分配负责人，也没有弥补差距。你可以把它写进报告，但每个读到它的人都知道，你记录的是一个巧合，而不是一个原因。

一切都没坏。这正是让人困惑的地方。没有部署失败，没有延迟报警，错误率也没有上升。有人合并了一个只有一行的 PR，在系统提示词（system prompt）末尾添加了一句话——一个新工具的描述、一条政策提醒，或者是“今天的日期是”的页眉——结果第二天早上，推理账单就高出了三到五倍。流量平稳，模型没变，代码也完全按照预期运行。

改变的是那一行代码放错了位置，导致你集群中所有的缓存前缀（cached prefix）瞬间失效。你的缓存命中率在一个请求周期内从 90% 降到了零，原本几乎免费的每个 token 开始按全价计费。这就是 Prompt 缓存悬崖（prompt-cache cliff），它是生产环境下 LLM 系统中最昂贵的故障模式，而且没人会对它进行威胁建模，因为它看起来根本不像故障。

你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 API 的预发布副本。三十年来，整个预发布（pre-production）学科都建立在一个假设之上：你可以创建一个足够忠实于生产环境的副本，对其进行测试，并从中了解到发布后会发生什么的真实情况。

然后，你将托管模型添加到了关键路径中，这个假设便悄然瓦解了。那个现在主导你产品行为的组件——决定你的应用实际上在说什么、做什么的那个东西——正是你无法搭建预发布副本的唯一组件。它由别人进行版本管理，由别人进行速率限制，并由别人按照你无法察觉的时间表悄悄更新。你的预发布环境拥有一切的预发布副本，唯独没有预发布模型。

财务在月底打开发票。一个供应商。一个数字。它比上个月大，而且下个月还会更大。然后他们提出了唯一重要的问题 —— 这是哪个功能花的钱？ —— 房间里没人能回答。

这是在生产环境中运行 AI 的一种隐蔽失败模式。并不是说账单数额巨大；如果价值匹配，数额大也没关系。失败之处在于账单是无法归因的。它作为一个单一的费用项出现 —— OpenAI、Anthropic、Bedrock、Azure —— 没有任何财务部门真正需要的维度：没有按功能、按团队、按客户，也没有按成功的任务进行拆分。你能看到总额在上升。但你看不出 原因，而当发票寄到时，原本可以解释它的请求上下文早已消失了。

一名客服代理正准备办理退款。在触发工具调用（tool call）之前，你的团队添加了一个门控：只有当模型表示其置信度至少达到 90% 时才继续。模型尽职地返回了 "confidence: 0.95"，退款发出去了，而模型用来证明金额合理性的引用——一条关于损坏商品的政策条款——其实并不存在。它从未存在过。模型虚构了该条款，然后为自己的虚构给出了 95% 的评分。

这就是陷阱。团队倾向于使用模型的置信度数值，因为它看起来就像你从经过校准的分类器中获得的概率——即 0.9 意味着“十次中有九次是正确的”。但事实并非如此。大语言模型（LLM）自我报告的置信度就像其他任何 token 一样，只是听起来流畅的 token，它受到语气、措辞和训练激励的影响，而这些与底层声明是否属实几乎没有任何关系。

如果你根据那个数字来限制实际行动，你就是在根据一种“感觉（vibe）”来做决定。

你的智能体集群（agent fleet）本周开启了 40 个拉取请求（pull requests）。你审查了其中涉及支付代码的 6 个请求，浏览了几个正好在你打开标签页时提交的请求，然后只要通过了 CI 测试，就将其余的全部合并了。如果有人问你的审查政策是什么，你大概会描述成类似上面的做法——但这根本不是政策。这只是一种“心情”（mood）。

数据表明大多数团队都处于同样的境地。最近一项针对流行开源仓库中智能体生成的拉取请求的大规模研究发现，61% 的请求完全没有任何审查记录；而在确实经过审查的请求中，大多数也仅由其他智能体进行审查。与此同时，产量仍在攀升：智能体现在生成 PR、文档、支持响应和工单的速度，已经超出了任何人类审查流程的设计初衷。审查所有内容是不可能的，而完全不审查则是玩忽职守。因此，团队在两者之间即兴发挥，既没有明确的规则，也没有衡量的覆盖率，更无法判断当前的审查力度是过于偏执还是草率鲁莽。

制造业在一个世纪前就解决了这个问题。20 世纪 20 年代，当西部电气（Western Electric）大量生产电话设备时，对每一个单元进行检查在经济上是不可能的，而运送未检查的批次又是不可接受的——于是贝尔实验室的统计学家们建立了“验收抽样”（acceptance sampling）：这是一门具有数学依据的学科，用于决定一批产品中需要检查多少、何时拒绝整批产品，以及供应商何时赢得了放宽检查的信任。它在二战期间演变为 MIL-STD-105 标准，随后成为 ANSI/ASQ Z1.4 和 ISO 2859-1，至今仍规范着港口如何验收一整箱货物。这与智能体集群的对应关系几乎是直截了当的，但在 AI 工程领域几乎没有人采用它。

每个前沿实验室的发布公告现在都附带同样的脚注：“包含并行测试时计算 (parallel test-time compute)”。Sonnet 的 SWE-bench 分数因此提升了约 5 分。GPT-5 级别的模型利用它将错误率降低了两位数。Gemini 的 Deep Think 依靠它几乎将其 ARC-AGI-2 分数翻了一番。大多数工程团队将该脚注视为基准测试的“调味剂”——一种虚标排行榜数字的手段，且认为没有实际系统会为此买单——然后继续围绕他们能负担得起的最强模型，进行单次尝试 (one attempt) 的产品架构设计。

这种直觉大概落后了两年。实验室在专业版 (pro tiers) 中加入并行采样并非为了营销装饰；他们加入它是由于在单个答案背后运行 N 次尝试通常是获得高质量的最廉价方式，有时甚至是唯一方式。当一个廉价模型的三次尝试加上一个像样的选择器 (selector) 能够击败每个 token 成本高出十倍的模型的一次尝试时，Best-of-N 就不再是一个基准测试把戏，而变成了一个架构决策——它拥有自己的成本模型、延迟特征以及标志性的失败模式。以此方式对待它的团队，正悄无声息地以比那些仍在旗舰模型上进行单次推理 (one-shot inference) 的团队更低的成本，交付更好的答案。