990 篇博文 含有标签「insider」

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。

每个评测套件（eval suite）最终都会被精简。有人注意到套件运行需要 9 分钟，每次运行成本 40 美元，而且里面充满了没人记得为什么要写的用例。他们提交了一个名为 “清理陈旧评测用例” 的 PR，删除了 40 条 “看起来不再相关” 的条目，CI 运行时间降到了 4 分钟。PR 获得了点赞。没人反对，因为删除测试看起来就像是在做维护。

这不是维护。每一个评测用例都是团队对自己做出的承诺：这种失败模式不会再静默地发生。 删除用例就意味着撤销了这项保证。通过率没有变化，仪表板依然是绿色的，唯一消失的是团队对这项保证曾经存在过的记忆。六个月后，一次模型迁移重新引入了被删除用例所防范的回归，复盘（postmortem）重新发现了团队已经支付过代价的教训，然后有人写道 “我们应该为此添加一个测试” —— 而这个测试正是之前在清理 PR 中被删除的那个。

你构建过的每个分布式系统都依赖于一个隐形的假设：超时后的重试是安全的。操作是幂等的，因此如果客户端放弃等待并重新发送，最坏的情况也只是重复工作，并最终收敛到相同的状态。两个 PUT 请求落地同一行。两个 DELETE 请求留下同样的空缺。重试只是伪装成第二次尝试的“无操作”（no-op）。

LLM 调用打破了这一假设，而且是悄无声息地打破。重试并不会重新获取相同的答案 —— 它会采样一个新的答案。当客户端因为响应在传输中丢失而在网络层超时，但提供商实际上已经完成了生成时，重试会产生第二个、不同的答案。现在，对于一个逻辑请求，存在两个不同的输出，而你的技术栈中没有任何部分知道哪一个是权威的。

这并非罕见的极端情况。在模型背后运行超时机制的从业者报告称，即使底层调用最终成功，仍有 5–10% 的请求会触发完整的超时加重试循环。其中的每一次重试都是一次抛硬币，而你的系统从未被设计成去裁定这种结果。

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。

当你第一次尝试像调试服务那样调试 Agent 时，你会发现以往的肌肉记忆完全派不上用场。你设置了一个假设的断点——虽然 IDE 中没有面板可以放置它，但你在脑海中想象了一个——就在 planner 选错工具的那一步。你使用相同的输入重新运行。这一次，planner 选择了正确的工具。你再次运行。它又选了一个你从未见过的第三种工具。Bug 是真实存在的，你的同事今天早上复现了两次，而你用了十五年的调试器突然间变成了博物馆里的陈列品。

这里失效的心智模型并不是“使用调试器”，而是背后更深层的假设：即一个程序在给定相同输入的情况下，会产生相同的执行过程。现代调试器中的每一项功能——断点、单步跳过 (step-over)、观测表达式 (watch expressions)、条件断点、热重载——都是建立在这种确定性之上的。你暂停执行是因为暂停是有意义的。你向前单步执行是因为下一步是可预知的。你检查一个变量是因为它的值是一个事实，而不是从某种分布中随机抽取的结果。

你正在对接的采购团队最终会提出一个重置你架构的问题：“我们可以自带模型 API 密钥吗？”回答“可以”能赢得订单。但回答“可以”同时也意味着你的信任边界、成本边界和运营边界发生了转移 —— 而大多数产品团队只有在合同签署、第一个月的使用产生了一个没人知道如何回答的服务工单后，才会发现这一点。

BYOK 在公司内部推销时被视为一个开关。客户粘贴一个密钥，你的代码从保险库（Vault）读取它而不是从你自己的账户读取，然后推理流程照常进行。但这并不是一个开关。这是一场由销售驱动的架构重构，它会波及成本分摊、安全事件响应、可观测性、速率限制、模型版本锁定以及值班问责。那些在没有意识到这一点的情况下就交付产品的团队，最终会在一年后为了修复这些问题而重构整个平台层，而付费企业客户则在焦急等待。

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你的状态页是一片绿色。你的错误率为零。你的运行时间仪表盘连续第七个月显示为 100%。然而，在周二上午 9:14，你的客户团队给你转来了一条来自一家财富 500 强客户的消息，上面写着：“我们的团队注意到这周助手的表现变差了。你能告诉我们发生了什么变化吗？”午饭前，你又收到了 12 条类似的反馈。现有的事故沟通手册（incident-comms playbook）无法回答其中任何一个问题，因为那套手册是为停机事故准备的，而现在没有任何东西崩溃。

这就是面向客户的 AI 复盘难题，也是我在将 LLM 功能交付给企业合约的团队中看到的最普遍的差距。可靠性的维度已经从“系统是否在线”转向了“系统是否和上周一样好”，而几乎没有任何沟通基础设施跟上了这一变化。状态页上没有相应的展示块。严重性等级标准（Severity rubrics）没有对其进行评分。支持服务的回复模版默认为“我们发现了一个问题并已解决”，这取决于客户当天的情绪，听起来要么是敷衍，要么是危言耸听。

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。