722 篇博文 含有标签「insider」

仪表板显示一切进展顺利。分流率高达 65%。工单量下降。单次咨询成本减半。接着，支持团队开始有人离职，离职面谈中提到了一些仪表板上没有列出的东西：“每一个班次都是煎熬。”

这是 AI 增强型支持中隐藏的机制。分流率衡量的不是消除的难度，而是浓缩后的难度。到达人工客服手中的案例不再是客户现实情况的代表性样本——它们是残余物，是 AI 无法解决的案例。而这些残余物比平均水平要沉重得多。

一个计算机使用型智能体（computer-use agent）在客户的 CRM 上完成了一项任务，工作线程池将浏览器返回到空闲环中，几百毫秒后下一个请求到达，仪表板导航成功——唯一的问题是，它是作为错误的用户登录成功的。前一个会话的 OAuth cookie 仍留在配置文件（profile）中。追踪记录显示 navigation succeeded（导航成功）、screenshot captured（截图已捕获）、action performed（操作已执行）。运行日志中没有任何内容表明，智能体正在以一个从未授权过它的用户身份进行操作。

这是浏览器智能体从其构建所用的库中悄然继承的一类故障。无头浏览器（headless browser）框架被设计为每个配置文件仅供一个用户使用，因为这是浏览器三十年来的工作方式。当工作池为了摊销全新的 Chromium 实例长达八秒的冷启动时间而重用配置文件时，这种“单用户”假设就破裂了，而且这种破裂对于团队通常信任的每一层遥测数据来说都是不可见的。

一年前，你的评估套件（eval suite）表现得非常出色。候选模型的得分分布在 60 到 80 分之间，排名结果能为你提供有效的参考。新的微调模型比基准模型高出 6 分；更廉价的模型则低了 3 分。决策依据这些数字而产生。而今天，在同样的评估套件下，每个候选模型的得分都是 95、96 或 97 分，得分差距已经缩小成了噪音。你的团队仍在运行评估，仍在阅读报告，仍在利用它为迁移亮绿灯——但这份报告已经不再包含任何有效信息。

这不是基准测试污染（benchmark contamination），也不是世界漂移引起的衰减（world-drift decay）。这是一个测量工具的问题：你的测试用例是针对平台已经超越的难度水平而校准的。尺子没有坏；而是你正在测量的东西已经超出了它的量程。那些没有意识到这一点的团队，仍然在使用一个辨别范围与所比较的候选模型不再重叠的工具来进行模型决策。

你的黄金评估集（Golden eval set）是一个你的安全团队甚至不知道其存在的隐私边界。它是通过对生产环境的 Trace 进行采样构建的，这意味着它是一系列精心挑选的真实客户查询集合——通常包含姓名、电子邮件、账号、愤怒的通话记录、输入了一半的信用卡卡号——并配有标准正确回复，最后提交到评估流水线读取的任何存储桶中。

最后一部分正是评估数据具有独特危险性的原因。原始的生产 Trace 之所以敏感，是因为它记录了客户所说的话。而评估案例则以一种全新的方式变得敏感，因为它记录了客户所说的话 加上标注的正确答案。这个标签是一个衍生作品，由某人（通常是标注员或领域专家）有目的地添加。它标志着“这是标准答案”。它赋予了 Trace 原始日志从未有过的生命力——日志保留策略最终会将 Trace 轮转删除，但评估案例现在成为了一个永久的测试 fixture（固定数据），团队致力于保持其测试通过（keeping green）。

在生产级 LLM 评估中存在一种悄无声息的失败模式，这是任何排行榜都无法捕捉到的：你的测试集是基于留存用户构建的，因此它永远不会提出那些让其他用户离开的问题。季度复季度，评估分数攀升，仪表板一片绿，但净留存率（net retention）依然在下滑。团队在追问“评估是否可被操纵？”，而真正的故事更简单也更残酷：评估分布向幸存者偏移了，而幸存者恰恰是你最不需要其反馈的人群。

这是换了装束的二战轰炸机装甲问题。Abraham Wald 观察了返回的飞机，注意到弹孔聚集在哪里，并指出你应该加固的地方是那些没回来的飞机上的弹孔。把轰炸机换成用户，把弹孔换成失败的交互轮次，你就得到了从生产追踪（production traces）中提取评估集的中心病理。

一个团队从前沿模型升级到了其更快的后继版本。评估套件（eval suite）全绿。最终答案一致。工具调用的 Schema 完全相同。结构化输出通过了与以往一样的 JSON Schema 验证。他们发布了。不到一天，支持票据就堆积如山：“助手感觉太匆忙了”，“它不再真正思考了”，“感觉不对劲”。产品经理调取了遥测数据，发现任务完成率没有变化。工程团队反复检查了评估和 Schema，没发现任何问题。投诉是真实的，但团队定义的契约——就如团队所定义的那样——依然完好无损。

改变的是流的纹理（texture）。旧模型在调用工具前会停顿 800 毫秒，发出一句“让我查一下……”的前导词，并以每秒约 35 个 Token 的速度输出，在子句边界处有自然的节奏。新模型以每秒 90 个 Token 的速度输出，从不停顿，且完全跳过了前导词。这些都没有出现在任何文档记录的契约中。但所有这些都是不可或缺的“承重”部分。

这就是海勒姆定律（Hyrum's Law），而流式传输（streaming）让它的表面积变得巨大。系统的任何可观察行为都会被某人所依赖——而流式 AI 界面暴露的可观察行为远比团队意识到的要多。

一个 200 毫秒的工具调用在火焰图（flame graph）上看起来就像是杂音。但在 Agent 循环中堆叠七个这样的调用，杂音就变成了信号 —— 模型在 800 毫秒内完成了思考，但用户却等待了 4.5 秒，因为每一次工具调用都在重新支付首个调用已经吸收掉的启动成本。残酷之处在于，这种成本在任何单一的追踪（trace）中都不会显示为异常。它表现为干脆利落的 Demo 与反应迟缓的生产环境 Agent 之间的差异，而大多数团队会将其归咎于模型。

Model Context Protocol (MCP) 已成为 Agent 工具链的默认集成界面，这意味着它也成了延迟（latency）堆积的重灾区。MCP 的设计 —— 基于 stdio 或可流式 HTTP 的 JSON-RPC、能力协商（capability negotiation）、动态工具发现 —— 对于一个必须桥接任意客户端和服务器的协议来说是正确的。但它隐含的单次调用成本结构对于 Agent 实际的访问模式并不友好。Agent 的模式不是“每个会话调用一次工具”，而是“每轮对话调用七个工具，每个会话进行四十轮对话”。

这篇文章将探讨这种错配：冷启动税究竟存在于何处，为什么它在长生命周期的 Agent 中是叠加而非被摊销（amortize）的，以及如何通过“预热池”（warm-pool）规范将数秒的惩罚降低到 100 毫秒以下。

这张图片是一张红色八角形停止标志的照片。有人在中间的单词上贴了一张小贴纸，上面写着“YIELD”（让行）。你问多模态模型：“这个标志写了什么？”模型回答：“该标志指示驾驶员在交叉路口让行给迎面而来的车辆。” 表现得既自信又流利，却既不忠实于视觉证据，也不忠实于文本证据。它是一个混合体，在产生分歧的真相通道之间采取了折中方案。

这种故障模式目前还没有一个统一的名称。研究多模态幻觉（multimodal hallucination）的研究人员将其称为“语义幻觉”（semantic hallucination）、“跨模态偏差”（cross-modal bias）或“模态主导”（modality dominance），具体取决于撰写论文的细分领域。交付文档 AI、截图智能体和缺陷检测系统的从业者每周都会遇到这种情况，并在事故复盘中将其描述为“模型只是在瞎编”。它不是瞎编的。这是一种在最终层融合了两个通道、却没有任何原语来表示通道意见不一情况的架构的可预测输出。

提示词缓存（Prompt caching）是一种只要开启就能立即获益的优化手段。长系统提示词仅需哈希一次，KV 状态驻留在 GPU 显存中，随后任何复用该前缀的请求都能跳过预填充（prefill）成本。供应商报告称，对于缓存的请求，延迟降低了 80%，输入成本降低了 90%。在大规模应用中，这种经济效益是无法抗拒的：摊销到数百万次调用中的单一共享前缀，将一项支出变成了几乎可以忽略不计的尾差。

实现这种节省的机制本质上是一种共享资源，其命中或未命中的状态可以通过延迟来观察。这种可观察性就是侧信道（side channel）。在网络外部可以清晰分辨缓存命中与缓存未命中，这种差异巨大且具有确定性。这项在成本看板上占有一席之地的优化方案，还兼任了一份无人预料的工作：泄露同一供应商下其他租户当前正在进行的活动信息。

一个团队将 fp16 模型更换为 int4 量化模型，以将推理成本减半。评估套件在精心挑选的测试集上的得分与原始模型相比差距不到一个百分点。于是，在“基准测试表现无差异”的理由下，模型正式发布。六个星期后，支持团队收到了受监管客户关于灾难性故障的反馈——生成的代码完全是胡言乱语，低资源语言的回复漂移到了另一种文字，多步算术运算自信地给出了偏差一个数量级的数字。基准测试没有撒谎。它只是测量了中位数，而量化并不是对中位数的均匀征税，它是对长尾分布的非均匀征税。

这就是量化质量悬崖：你的评估套件、发布纪律和成本节约叙事同时崩溃，因为你用来批准更换的指标，对于你所摧毁的能力完全没有信号反馈。最近的基准测试让这种影响变得具体。在长上下文任务中，8-bit 量化保留了准确性，仅下降了约 0.8%，而 4-bit 方法在相同工作负载下损失高达 59%——这种退化对于任何没有对长尾输入进行过采样（oversample）的测试集来说都是不可见的。中位数移动了一个点，而长尾移动了十五、三十甚至五十个点。

周五下午，一封客户成功（customer-success）邮件发了过来：“德国用户的模型效果变差了。”团队打开评估仪表板，评分没变，p95 延迟也很正常。配置中的模型名称还是三周前发布的那一个。一切都没变。但其实有些东西变了。上个迭代中，美国的端点悄悄上线了新一代模型，而欧洲的端点由于供应商还没完成地区性的分阶段发布，仍在使用旧版本。而位于两者之前的负载均衡器，则在团队的所有仪表板上掩盖了这一差异。

这就是所谓的区域性模型发布博弈。你的“单一模型”抽象并不是单一的。当供应商跨大洲分阶段发布时，它就开始分化了——而在大多数年份、对大多数供应商而言，这种情况在大多数时间里都在发生。当这种情况发生时，客户端 SDK 中的版本字符串并不会改变。你的追踪（traces）看起来一模一样。你与供应商签订的合同也没有做出其他承诺。而你赖以捕捉行为回归的评估套件，几乎肯定运行在某个地区的 CI 机器上，并访问地理位置最近的端点。

一位客户提交了一份主体访问请求（Subject-Access Request），要求删除他们的数据。数据工程师清理了生产数据库、分析仓库、支持工单存档以及冷备。法务团队在数据清单中列出的每个系统都反馈清理完毕。随后，房间里有人提出了一个没人想第一个回答的问题：那模型呢？

三个月前，该客户的支持记录被用于一次微调运行。从那时起，由此生成的适配器（Adapter）就一直在为其他客户提供预测服务，其中嵌入了该客户的措辞、账户名称，偶尔甚至还有权重中的原句。你可以证明数据仓库中的数据已删除。但你无法证明模型中的数据已删除 —— 团队中最诚实的那位成员会大声说出这一点。