990 篇博文 含有标签「insider」

你的 RAG 评估仪表盘显示为绿色。忠实度（Faithfulness）为 0.91，回答相关度（Answer Relevance）为 0.88，你花了两个迭代周期构建的 LLM-as-judge 评估框架显示系统运行良好。与此同时，一位用户刚刚问了一个问题，而答案就在你的检索器（retriever）从未提取出的文档中，你的模型写下了一个自信、结构清晰但完全没用的回答，内容与问题相关但风马牛不相及。评判员给了它高分。它读起来很顺畅。它基于模型 确实 获取到的片段。它只是用与用户需求无关的内容回答了一个错误的问题。

这是大多数团队评估检索增强生成（RAG）时存在的隐性结构缺陷：他们给文章打分，却从未检查学生是否拿到了正确的书。RAG 系统是两个连接在一起的机器——一个是决定 模型能看到什么 的检索器，另一个是决定 如何处理这些内容 的生成器。几乎生产环境中的每一个评估框架都只衡量第二个机器。第一个机器，也就是真正决定答案质量上限的那个，却在未经监控的情况下运行。

有一种特定类型的故障永远不会表现为宕机。服务状态保持绿色，延迟平稳，错误率为零，而搜索结果却悄然开始返回垃圾信息。这就是当你将一个新的嵌入模型（embedding model）指向由旧模型构建的索引时会发生的情况。没有任何程序崩溃。只是搜索结果不再有意义了。

原因在于几何学。嵌入模型不会为某个概念分配固定的坐标——它定义了一个 空间，而同一句话落在哪里完全取决于绘制地图的模型。去年模型产生的向量与今年模型嵌入的查询之间不存在“近”或“远”的关系。它们是根据不同的尺子衡量的。它们之间的余弦相似度（Cosine similarity）只是一个数字，而且这个数字毫无意义。

因此，当有人提交一个标题为“升级到新嵌入模型”的工单时，他们提交的并不是一个配置更改。他们提交的是一个披着单行代码差异（diff）外衣的完整数据迁移。如果你把它当作普通的库版本升级来处理，你就是在发布一个无声的故障。

一个研究员智能体向一个检索智能体请求一份文档。检索智能体在任务执行到一半时，决定需要研究员智能体澄清查询意图后才能继续搜索。而正在等待文档的研究员智能体，在拿到文档之前不会做出响应。它们谁都没有出错，也没有陷入死循环。它们只是都在礼貌地、无限期地等待着对方——而你的编排器（orchestrator）根本没有“这两个智能体正在互相阻塞”的概念，它会一直愉快地维持这个状态，直到你从未配置过的超时设置最终触发，或者直到某个大活人注意到这个运行已经“进行中”整整 40 分钟了。

这就是死锁（Deadlock）。它是计算领域最古老的故障模式之一，且与你的模型有多聪明毫无关系。它是工作协调方式的一种属性，而不是工作执行方式的属性。过去一年多智能体研究中一个令人不安的发现是：在智能体集群中，大部分出问题的地方都在这里，即协调层，而不是任何单个智能体的推理能力。

单智能体思维永远无法暴露这些 Bug。当一个模型运行工具调用循环时，它最坏的情况也就是空转——而空转至少是肉眼可见的。一旦你拥有两个或更多可以互相等待的智能体，你就继承了分布式系统所有的病理特征：循环等待、活锁、丢包、过早终止、共享状态下的竞态条件。没有人会坐下来决定构建一个分布式系统，但在你添加第二个智能体的那一天，你就已经构建了一个分布式系统。

当你为人类开发人员弃用一个 API 时，你会为此举行一整套“仪式”。你提升版本号，在 OpenAPI 规范中添加 deprecated: true，发送 Sunset HTTP 响应头，向开发人员邮件列表发送邮件，发布变更日志，并给人们六个月的时间进行迁移。信号到达阅读它的开发人员，他们提交工单，并在旧路径消失之前更新他们的客户端。

现在，将同样的弃用通知指向一个智能体。调用你工具的模型不会阅读你的变更日志，它不会订阅你的邮件列表。它永远看不到 Sunset 响应头，除非你刻意将其放在模型会查看的地方，即便如此，它也没有可靠的习惯去据此行动。你精心编写的弃用通知落入了一个没有读者的信箱。智能体会一直调用工具的旧形式，直到该形式彻底消失，然后它就会失败——通常是静默失败，通常是在生产环境中，通常是在凌晨 2 点。

这就是为智能体而非人类构建工具时所存在的隐性不对称。我们在 API 演进的二十年里建立的每一项准则，都假设在弃用和迁移之间坐着一个人类。把人类拿掉，整个机制就会失效。

你对生产系统的每一次更改都遵循某种纪律。代码在 feature flag 后发布，灰度测试（canary）到 1% 的流量，当仪表盘变红时可以一键回滚。Schema 迁移是分阶段且可逆的。即使是 CSS 的微调也要经过人工阅读的 pull request。然而 Prompt 却并非如此。有人在文本框中编辑一段文字，点击保存，你产品的行为就会立即对所有用户发生改变——没有灰度测试，没有经过审查的 diff，也没有真正能让你回到先前状态的回滚按钮。

令人不安的是，这并非粗心的团队所导致的疏忽，而是工具链产生的默认结果。Prompt 被归类为“配置（configuration）”，因为它们是存在于编译后的二进制文件之外的字符串，而配置一直以来被认为是可以快速更改且无需完整发布周期的东西。但 Prompt 并不是配置。它是一个用英语编写的程序，由一个你无法控制的非确定性解释器编译，其行为你只能通过统计学来观察。将它视为配置值，是导致一整类生产事故的范畴错误（category error）。

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

最危险的 eval set 是那些依然能通过测试的。变红的 regression suite 会引起关注：有人会打开失败的案例进行争论、修复 Bug 或更新预期。绿色的 suite 则会赢得信任。而这种信任恰恰是失效的 eval set 不配拥有的，因为得分保持绿色并非因为你的系统足够好，而是因为测试已经不再反映用户的真实行为。

这是 AI 评估中一种隐蔽的失败模式。你构建了一个 golden dataset —— 几百个精心标记的案例，代表了产品的工作任务。它能在一整个季度里发挥作用。每次部署都会运行它，每个分数都是绿色，每个人都睡得很香。与此同时，产品发布了三个新功能，企业级流量从查询量的 10% 攀升至 45%，用户开始以 18 个月前团队中没人写过的方式来表达请求。eval set 对此一无所知。它继续根据一个已经不存在的分布对模型进行评分。

在几乎每一个发布 AI 功能的团队中，都会上演这样一种“仪式”：有人运行负载测试，看着 p99 延迟攀升并超过 2 秒，然后提交了一个工单：“让它快一点。”这个工单落到了基建（infra）团队手中。他们调整批处理大小（batch sizes），增加 GPU，争论调度器（scheduler），最终费尽心思将这个数字降到了 1.4 秒。每个人都点头认可。p99 被“解决”了。

整个过程都建立在一个错误的前提之上。这个前提认为延迟目标是系统的一个既定事实——是基建团队发现并为之优化的一个物理常数。事实并非如此。目标是一个选择，而且是一个产品层面的选择。什么才算“足够快”，完全取决于用户等待时界面的表现，而界面并不在基建团队的设计范围内。

没人会刻意决定给智能体 (agent) 配备 40 个工具。这就像车库堆满杂物一样自然而然地发生了。你接入一个搜索工具，然后是一个数据库读取器，接着团队里有人发布了 Slack 集成，然后又安装了 ticketing MCP 服务器，因为这只需要一行配置。每次添加在当时看来都是合理的。没人会移除任何东西，因为移除工具感觉就像是在剥夺能力，而剥夺能力感觉就像是一种倒退。

六个月后，你的智能体有了一个工具带，其中有三个它经常使用的工具，十几个偶尔使用的工具，以及二十多个在生产环境中技术上从未被选中的长尾工具。这种“长尾”并非免费，甚至代价高昂。目录中每一个未使用的工具都在主动降低智能体从那些重要工具中做出正确选择的能力。

大多数团队在针对错误的层面进行威胁建模。他们加固了聊天框——速率限制、输入校验、监视用户输入内容的越狱分类器——却将模型读取的所有内容视为惰性的。Wiki 页面、支持工单、抓取的网页、日历邀请、某人上传的 PDF：在他们眼中这些只是数据，而不是指令。它们是供模型总结的背景材料，而不是让模型执行的命令。

这种假设本身就是漏洞。一旦你的 Agent 获取了内容并将其放入上下文窗口（Context Window），该内容的执行权限就与你的系统提示词（System Prompt）完全一致。在“这是你的指令”和“这是供参考的文档”之间没有权限边界。它们都只是 Token，而模型经过训练，会遵循出现在任何地方的指令。

你的智能体开始工作了。它处理工单、发放退款、更新记录、完成闭环——无需人工干预，且根据你的指标，其质量超过了执行同样任务的人类中位数。你已经准备好让智能体完全脱离人工干预。然而部署陷入了停滞，不是卡在工程环节，而是在一次会议中，法务或财务部门的人提出了一个你无法回答的问题：一旦出错，损失由谁承担？

这是智能体自主化过程中能力曲线无法触及的部分。你可以将准确率从 95% 提升到 99%，但上述问题依然存在。因为阻碍部署的从来不是“模型是否足够好”，而是由概率系统采取不可逆行动所带来的风险必须由人承担，而现在没人愿意承担。你的职业责任险（E&O 保险）是为人类失误编写的，且越来越多地将自动化失误排除在外。你的模型供应商合同声明对一切后果免责。而且，目前还没有哪家保险公司能为这类系统制作精算表——因为每当你修改一次提示词（Prompt），系统的失败率就会悄然发生偏移。

演示在一周内惊艳了执行团队。十八个月后，它依然只是个演示。模型仍在沙盒中回答问题，幻灯片依然被循环用于新的路演，每个季度都有人问为什么还没上线。没有人能给出一个好的答案，因为真相往往令人不安：让所有人印象深刻的部分是廉价的部分，而没有人为昂贵的部分做过规划。

这就是“试点炼狱”（pilot purgatory），而它现在已成为默认的结局。MIT 的 NANDA 计划发现，大约 95% 的企业生成式 AI 试点项目未能对损益表产生可衡量的影响。IDC 和 Lenovo 统计了另一项指标——即那些字面上从未上线的 POC——将这一比例定为 88%：企业每启动 33 个概念验证，只有 4 个能进入生产阶段。放弃大部分 AI 计划的公司比例从 2024 年的 17% 飙升至 2025 年的 42%。这些故事的主角并非模型能力不足，而是没有人为其预留预算的“毕业差距”。

令人不安的事实是，一个可以运行的演示仅代表了在生产环境中运行该系统所需工作的 10%，但正是这 10% 看起来像完成了 100%。所有让 AI 系统能 安全运行 的要素——评估（evals）、护栏（guardrails）、可观测性、成本控制、安全审查、值班（on-call）以及拥有预算的负责人——在演示中是不可见的，但在生产环境中却是不可逾越的底线。