907 篇博文 含有标签「insider」

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

你支持团队的一位高级 CSM 花了一个周末搭建了一个内部 Slack 机器人。他们自己编写了系统提示词（system prompt），并将其指向了公开文档、Zendesk 已解决工单的导出数据以及变更日志（changelog）。六周后，它能回答团队以前需要手动输入的约 40% 的一级（tier-1）问题。你的工程团队架构中没人知道它的存在。当平台团队第一次发现它时，安全部门的人会问，为什么一个服务账号会在凌晨 3 点访问 Zendesk 的 API。

默认的反应是恐慌。封锁 API 令牌。发送一封关于未经授权 AI 的全公司邮件。在下一次治理审查中增加一张幻灯片。然后承诺平台团队将在下个季度，按照正式的路线图（roadmap）构建“官方版本”。

这种反应忽略了实际发生的情况。CS 团队并没有擅自行动 —— 他们构建了一个工程团队尚未交付的产品的可用原型。他们拥有真实的反馈数据、真实的提示词迭代周期和真实的用户反馈。而你的平台路线图里这些都没有。将这个机器人视为合规违规行为，会丢掉你的 AI 计划今年能获得的最准确的优先级信号。

你的评估流水线分数在稳步上升。响应质量在持续改善。LLM 评判者（LLM judge）捕获到了更多劣质输出。仪表盘一片绿色。

与此同时，支持工单零星涌来："助手老是给我冗长正式的回答，我只是随口问了个简单的问题。"紧接着又来了一条："它不再主动给出下一步建议了，以前会的。"然后你们的产品经理给你看了一张图表：上个季度用户满意度下跌了 12%，而这段时间，恰恰与你自动化评估指标爬升最快的那段时期高度吻合。

这就是评估自动化陷阱。你的度量体系开始为自身的优化而服务，而非为用户真正看重的事情服务 —— 由于整个反馈循环完全自动化，没有人察觉到问题，直到伤害已经落地生产。

大多数 AI 功能发布时只有两种状态：正常工作和彻底挂掉。模型调用成功，功能就有响应；模型调用失败，用户就会看到错误。这相当于在构建 Web 服务时没有负载均衡、没有缓存，且只有一个数据库副本——在出事之前，它在技术上是可行的。

不同之处在于，工程师在 20 世纪 90 年代就学会了数据库弹性模式，并将其深刻内化。 AI 功能的弹性仍处于通过一次次生产事故进行艰难探索的阶段。一家支付处理器在一次时长 4 小时的 AI 停机中损失了 230 万美元。一家物流公司在其路由模型宕机时，错过了 30,000 个包裹的交付窗口。这两起失败都有一个共同的根本原因：当主模型不可用时，没有可以回退的方案。

AI 功能上线后的 Bug 数量并非质量问题。它是一个发现序列——一个非常可预测的序列，以至于你可以在发布公告发布之前，在白板上逐周、逐个工单地勾勒出来，并且在仪表盘数据跟上时，你会发现自己预测得惊人地准确。每个上线 AI 功能的团队都会经历这个序列。唯一的选择是，你是带着操作手册（runbook）去执行，还是通过一系列临时的紧急会议来应对。

我已经观察了足够多的发布，足以相信这个序列实际上与工程质量无关。它关乎信息差。发布前，团队拥有合成流量组合、精选的评测集（eval set）、理想路径的演示和董事会演示文稿。发布后，真实用户带着合成流量从未模拟过的意图蜂拥而至，市场团队开展了工程团队仅略有耳闻的营销活动，模型提供商发布了未经团队授权的更改，而隐私审查员在功能上线时正在休假。下面的序列就是当这两个世界碰撞时产生的摩擦。

你的 AI 功能上线时带有一个质量门禁：每个回复都会经过一个 GPT-4 提示词，根据帮助性、准确性和语气进行评分。绿色分值不会触发报警。仪表盘显示通过率为 97%。与此同时，你的支持工单翻了一倍。

问题出在结构上。你使用了与生成输出相同类型的系统来验证这些输出。当生成器产生一个听起来很合理的虚假事实（幻觉）时，基于相同互联网文本分布训练的评判模型会认为这个幻觉是可信的并予以通过。两个模型共享相同的盲点。你的质量门禁衡量的是置信度，而非正确性。

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。

在 “开放权重”（open-weight）这个词中，“开放” 二字承担了极大的重任。当一名工程师从模型中心下载 safetensors 文件时，他们往往倾向于将这种行为归类为与 npm install lodash 相同的心理范畴 —— 拉取依赖、上线功能、继续下一步。但伴随这些权重而来的许可证很少是 Apache 2.0 或 MIT。它通常是带有可接受使用例外项、署名要求、衍生品命名规则以及用户数量阈值的自定义社区许可证，一旦你的产品变得流行，这些阈值就会改变合同条款。而且，加载器几乎不会强制执行其中任何一项。无论你是否遵守，模型都会运行。

这就是合规债务如何悄无声息地累积的。如果团队将许可证审查视为一次性的下载检查，那么公司就在为一项审计结果埋单，而该结果将在点击 “我同意” 的开发者离职多年后才会显现。解决方法不是在入口处设置更严格的采购门槛，而是将模型权重视为供应链的一种严谨做法，具备来源追溯、定期重新审查以及一份能够将每条已部署的推理路径追溯回其上游许可证的清单。

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。

这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。