861 篇博文 含有标签「insider」

产品团队在每个 AI 建议旁边都附带了一个置信度徽章。≥85% 为绿色，60–84% 为黄色，低于此数值为红色。六周后，他们运行了一次 A/B 测试，发现在任何阈值下用户行为都没有变化。置信度为 0.92 的误报被接受的比例与置信度为 0.61 的误报完全相同。团队的直觉是调整校准——拟合一个温度缩放层（temperature scaling layer），重新生成徽章，再次运行 A/B 测试。数据变了，但行为没变。

问题不在于模型没有校准好，尽管它几乎肯定没校准好。问题在于校准后的概率是错误的输出。用户可以据此行动的信号不是模型“有多确定”，而是“模型具体没检查什么”。一个 0.87 的徽章无法告诉用户任何可以验证的信息。“我对地址相当有信心，但我还没有核对单元号”则准确地告诉了他们该看哪里。

A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。

这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。

研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。

黄金评估集的通过率为 94%。模型在本季度已经升级了两次，提示词修改了 11 次，工具库增加了 4 个，仪表盘依然是一片绿色。然而，一名销售工程师转发了一份对话记录，显示智能体（Agent）自信地将客户引导至一个两个月前就已停用的工作流；与此同时，支持团队负责人悄悄开启了一个讨论组，询问为什么在评估流水线显示没有回归的情况下，满意度评分已经连续下滑了六周。黄金集并没有撒谎。它只是在用上个季度的产品标准来衡量这个季度的流量，而除此之外没人要求它做别的事。

这是评估系统最难察觉的一种失效模式，因为本该检测质量回归的工具本身就是误报的源头。通过率是针对集合中的项目计算的；集合中的项目是根据某个时间点的使用快照精心筛选的；用户的使用方式已经演进，但通过率依然保持“干净”。团队信任绿色的仪表盘，发布了另一个模型升级，几个月后才发现生产环境的分布与评估集所衡量的东西已经南辕北辙，而这种状态持续的时间超出了所有人的想象。

解决方法并不是提高黄金集的更新频率。更新频率是一个错误的调节旋钮；正确的旋钮是拥有第二个针对不同时间窗口校准的工具，以便在用户发现问题之前，通过两者之间的分歧来暴露漂移。这第二个工具就是影子评估（Shadow Eval）—— 一个从当前生产流量中持续重建的并行评估集，它与黄金集并行运行，其明确的任务就是与黄金集唱反调。

我上个季度合作的一个团队在周二凌晨 2:14 向生产环境推送了一个回归错误。值班警报触发了，因为其摘要代理（summarization agent）下游的 JSON 解析器以“尾随逗号错误”拒绝了二十分之一的响应。模型没变。提示词（prompt）没变。评估套件在前一天晚上的通过率为 96.4%，稳稳高于 95% 的准入门槛。改变的只是 package.json 中的一行：模型提供商的 SDK 从 4.6.2 升级到了 4.6.3。补丁更新（Patch bump）。由依赖机器人自动合并。发布说明里写着“内部清理”。

所谓的“内部清理”是一个收紧的 JSON 模式解析器，它删除了一个宽容的后备路径，而这个路径此前一直在默默修复模型工具调用输出中反复出现的尾随逗号怪癖。模型的行为没有改变。但 SDK 对该行为的解释改变了。团队的评估套件从未发现这个回归，因为评估套件运行的 SDK 版本与依赖机器人刚刚推送的版本不同。

这就是 LLM SDK 升级税，它是当今生产环境 AI 中最隐蔽、代价最昂贵的故障模式之一。SDK 不是被动的传输工具。它是你提示词行为的积极参与者，而那些在没有评估的情况下升级 SDK 的团队，实际上是在进行一场伪装的模型发布。

目前你的系统中有一个损坏的 prompt 影响了约 3% 的流量，但你的仪表盘根本察觉不到它的存在。p99 延迟图表是绿色的。错误率保持平稳。模型调用成功率指标高达四个九。唯一的故障迹象出现在一张平台团队无法复现的客户支持工单中，而等这张工单进入调试环节时，相关的 trace 已经因为采样而被丢弃了。

这不是监控缺失，而是一个分类错误。你正在运行的 APM 是为维度受限（如 endpoint、status_code、region、service）的世界设计的，在这种情况下，增加一个标签的成本最多只是增加几个新的时间序列。LLM 工作负载完全不符合这种模式。真正有趣的维度是用户的 prompt、检索到的 context ID、工具调用序列、模型版本、prompt 模板版本、租户（tenant）、语言区域（locale），以及请求所属的 eval bucket。每一个维度都是高基数（high-cardinality）的，只要你用其中任何一个子集来标记 span，指标存储瞬间就会爆炸。

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

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

在国际化发布的财务规划电子表格中，有一个清晰的项目：“将评估覆盖范围扩展到七个新语言区域 —— 假设为当前评估成本的 7 倍。”英语评估套件耗时两周，花费 4 万美元构建，因此七个语言区域将花费 28 万美元和一个季度的工程时间。CFO 签字了。产品 VP 签字了。发布启动了。

六个月后，实际的评估账单已经突破 31 万美元，团队仍在搭建最后两个语言区域。标注供应商在葡萄牙语（巴西）人员库中已经换了三批人，因为前两批产生的人员间一致性（inter-rater agreement）分数，任何诚实的审查都会称其为随机。德语裁判模型（judge model）在相同内容上的评分比英语模型低 6% —— 团队最初将其解读为德语模型的退化（regression），直到人工审核发现裁判模型本身才是退化的根源。评估负责人每周要花 40% 的时间处理一个没人预算过的问题：我们如何知道语言区域 A 的通过率确实比语言区域 B 差，而不是因为跨语言区域的测量比差距本身的噪声更大？

一位拥有 8 年事故响应经验的平台工程师打开了一条凌晨 2 点的报警信息：“AI 助手性能下降 —— 错误率 12%”。她检查了模型延迟仪表盘：绿色。检查了模型 API 状态页：绿色。检查了部署日志：过去 72 小时内没有任何变更。她做了任何称职的值班人员接下来会做的事 —— 呼叫 AI 团队。AI 工程师醒来，打开了平台工程师甚至不知道存在的追踪 (trace) 仪表盘，发现一个检索工具在过去 4 小时内一直超时，原因是一个下游搜索索引丢失了一个副本，并在 11 分钟内解决了事故。AI 工程师在凌晨 3:14 重新入睡。第二天早上的复盘记录写道：“AI 功能故障，由 AI 团队解决”。没有人写下真正的教训：如果这位值班工程师曾被教导过 AI 功能的故障面 (failure surface) 长什么样，她本可以在 5 分钟内完成分流 (triage)。

这是 AI 功能在过去两年中，向我合作过的每一个工程团队悄悄征收的“轮换税”。曾经完美适用于无状态服务堆栈和几个数据库的共享值班轮换，在其中一个“服务”变成由 LLM 驱动的功能时就会崩溃。你的 SRE 团队通过十年的事故复盘建立的值班手册，是为一个“某处出错了”可以分解为 CPU、内存、网络、部署和依赖超时的世界而校准的。AI 功能增加了三个维度 —— 模型、提示词 (prompt)、检索管道 —— 以及四种值班人员从未接受过识别培训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。

上一季度发布的端侧 AI 演示在单台测试手机上运行了一个 4-bit Llama 变体，表现出色。六个月后，同样的功能却收到了一连串的一星差评，用户抱怨发热、耗电，或者更糟糕的是——无声的质量下降，用户只觉得“老手机上的 AI 变傻了”。模型没变，但机群（fleet）变了。那些原本以为是在交付模型的团队后来才发现，他们交付的其实是一个机群。

这就是导致大多数端侧 AI 发布失败的鸿沟：策略是围着选择“那个”模型转，而真正的难点在于如何为每类设备交付“合适的模型”，观察其运行情况，并在出问题时回滚。弥合这一鸿沟的学科更像是 CDN 运营，而非 ML 研究——清单驱动（manifest-driven）的交付、按分群的遥测、解耦的发布渠道，以及能从一个训练好的检查点生成 N 个量化分级的模型变体流水线。大多数团队并不具备这些，他们只有一个模型卡（model card）和一个构建产物。

一个新的嵌入模型发布了。基准测试数据提升了 4 %。一位 Staff 工程师提交了一个工单：“将 embedding 升级到 v3。”两周后，索引已完成重新嵌入，别名已切换，团队通过特性标志（feature flag）发布了变更。六周后，支持工单堆积如山。搜索结果“感觉不对劲”。复盘会召开了。没人能解释为什么出现了退化，因为没有系统崩溃，每个仪表盘显示的都是绿色。

问题不在于模型的更换。问题在于向量存储根本不知道哪些向量来自哪个模型。数据库里没有这一列。没有用于追踪哪些记录已回填的迁移表。没有 alembic_version 行，没有 schema_migrations 表，也没有先前状态的 pg_dump。团队将 embedding 升级视为一次简单的配置切换，而向量存储在模式（schema）层面缺乏能阻止他们犯错的概念。

Embedding 迁移需要数据库迁移二十年来一直依赖的相同产物：写入每个向量、在每次查询时检索、并作为切换和回滚准入准则的单条记录版本标签。这是大多数团队最容易忘记添加的一列，而后期补救的成本远高于前期添加。

系统提示词（system prompt）上一个四个词的修改——用 "respond using clean JSON"（使用干净的 JSON 响应）替换 "output strictly valid JSON"（输出严格有效的 JSON）——在评估（eval）中一度没有引起任何波动。它在周四发布，却在周五凌晨 4 点被回滚，因为结构化输出的错误率从 0.3% 飙升到了 11%。提示词并没有变糟。它只是变得“不同”了，而下游解析器在无人察觉的情况下，已经固化（pinned）在了 "strictly valid" 这个词组上。

这是大多数提示词工程（prompt-engineering）团队尚未建立工具来应对的失效模式：提示词被视为作者拥有的文本，而实际上它是与作者从未见过的消费者之间的一份合约。这些消费者中，有些是逐字引用原句的其他提示词；有些是 JSON 模式（JSON schema）字段锚定在特定形容词上的工具描述；有些是其评分标准（rubrics）要求裁判（judge）检查“严格有效格式”的评估（evals）；还有一些是解析器——最脆弱的一类——其正则表达式是根据模型输出的精确前导语（preamble）进行校准的。

一次“小小的措辞清理”会悄无声息地破坏解析器、导致裁判校准偏移，并使数周的评估运行失效。这些失败都不会在 PR（拉取请求）中显示出来，而是在一周后作为“偏移”（drift）出现在仪表盘上。

隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。

团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。