990 篇博文 含有标签「insider」

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%，p=0.03。他们将其视为胜利并向所有人发布。六个月后，一次客户审计发现，新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的：按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下，输出是稳定的，方差较小且易于理解，教科书中的样本量计算公式也适用。然而，对于由 LLM 驱动的功能，这些属性都不成立。如果团队不考虑这一点，他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

九秒。这是一个 Cursor AI 智能体在尝试修复凭证不匹配问题时，删除整个生产数据库（包括所有卷级备份）所花费的时间。该智能体持有删除权限，而实际上任何合法任务都不需要这个权限。由于没有人在部署前界定爆炸半径，破坏是全面的。

这不是模型失败的故事，而是权限范围的故事。模型做了它认为应该做的事情。工程团队只是从未问过：如果这个智能体推理出错，它最坏能做什么？

这个问题——在部署前系统性地回答——就是爆炸半径分析。

2023 年初，大量企业 AI 培训项目带着同一个卖点涌现：我们将教你的工程师提示工程。然而大多数项目完成第一批学员培训时，所教的具体技术已被模型自身自动化淘汰。到 2025 年，曾短暂标价 20 万美元年薪的"提示工程师"职位实际上已走向消亡。而那些培训项目依然在运转。

这就是 AI 课程陷阱。它不是努力或预算的问题。各组织在结构化 AI 培训、认证项目和以工具熟练度为核心的招聘标准上投入了大量资源。但工具的迭代速度快于任何课程所能追赶的速度，结果是一种永久性的结构性滞后：培训项目始终在教 18 个月前的 AI 工程。

每个上线 AI 功能的工程团队最终都会碰到同一堵墙：财务部门要看一份证明支出合理性的表格，但你做的那份根本行不通。

问题不在于 AI 功能缺乏 ROI，而在于 AI 的经济逻辑打破了标准 ROI 模型的每一个假设——固定资本、线性成本曲线、可预期的回收时间线。把 AI 支出当作 SaaS 许可费来处理的团队，要么在上线前看到虚高的数字，要么在投产六个月后看着数字崩塌。有计划的 AI 项目（ROI 达 55%）与随意部署的项目（ROI 仅 5.9%）之间近十倍的差距，几乎完全来自于团队是否在上线之前就建立了正确的度量模型。

你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。

AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。

一名新工程师加入了一个重度依赖 AI 的团队。入职第三天，他们发现系统指令中有一个措辞别扭的双重否定。看起来像是个 bug。于是他们把它清理了——这是任何合理的人都会做的小小优化。两小时后，一条关键流水线的客户端分类准确率从 91% 跌至 74%。没有人知道原因。

这种情景以某种形式发生在几乎每一个基于 LLM 构建系统的团队中。新工程师并不粗心。那个提示词看起来确实有问题。但那个双重否定在某种意义上是"承重墙"——只有写下它的人才真正理解，而那是在经过数周实验之后才领悟到的。他们从未把这种理解写下来。

这就是 AI 入职差距：AI 代码库表面上的行为与实际行为之间的鸿沟，以及为什么这个鸿沟在有人掉进去之前是不可见的。

几乎每一次企业 AI 部署中都会出现同一种模式：工具在演示中表现出色，上线生产后却悄然止步于 70–80% 的潜力。团队将其归咎于模型质量、上下文窗口限制或检索失效。然而大多数情况下，这个诊断是错的。真正的问题在于：他们要求 AI 扮演一个它在结构上无法胜任的角色——至少目前如此，也许永远如此。

"AI 能完成这项任务"与"AI 能胜任这个角色"之间的鸿沟，是企业 AI 领域最昂贵的误解。

你的 AI 流水线昨晚报告了零错误。但输出结果完全是错的。

这不是假设。一份近期的行业报告发现，大约每 20 个生产环境 LLM 请求中，就有 1 个以永远不会触发异常的方式失败——HTTP 200、格式正确的 JSON、流畅的散文，但内容却是错的。可观测性系统保持绿灯，而流水线却在悄悄地欺骗用户。

根本原因是一个从传统服务工程中借来的架构假设：HTTP 状态码和解析错误覆盖了所有故障空间。但事实并非如此。LLM 流水线至少有四种底层基础设施看不到的故障类型——幻觉、拒绝、格式违规和上下文溢出——把它们当作边缘情况而非一等公民错误类型来处理，正是生产 AI 系统如何大规模传播隐性 Bug 的根源。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

当 Google 的 AI Overview 建议用户在披萨酱中加胶水，并为了消化健康而吃石头时，这不仅仅是让产品团队蒙羞——它暴露了我们在思考 AI 可靠性方面的系统性鸿沟。失败的原因不仅在于模型错了。失败的原因在于模型在高度受关注的情境下“自信地”犯错，而且没有为被误导的用户提供任何补救路径。

对 AI 系统的信任并非逐渐流失。研究表明，它遵循一种“悬崖式”崩塌模式：一个明显的错误就能导致信任度大幅下降，并产生可衡量的影响。只有 29% 的开发者表示他们信任 AI 工具——尽管采用率攀升至 84%，但这一比例比前一年下降了 11 个百分点。我们正在构建人们虽然在使用但并不信任的系统。当你的产品发布了代表用户行动的智能体 (agentic) 功能时，这种差距就显得至关重要。

本篇文章讨论的是工程师和产品构建者在错误发生“之后”应该做什么——而不仅仅是如何预防错误。

大多数团队选择一个分块大小，针对检索质量进行调优，然后就此止步。接着，他们在同一个索引上构建一个 Agent，并纳闷为什么 Agent 会以奇怪的方式失败——它只执行了一半的工作流，忽略了条件逻辑，或者根据不完整的指令自信地采取行动。使你的 NDCG 分数最高的分块大小，恰恰是让你的 Agent 变得不可靠的原因。

RAG 检索和 Agent 执行并不是同一个问题。它们有不同的目标、不同的失败模式，以及对什么是“好的分块”有着根本不同的定义。当你针对其中之一优化分块时，你就在系统性地削弱另一个。大多数团队直到已经在错误的架构基础上构建完产品后才意识到这一点。

大多数关于幻觉的研究都集中在单次模型调用的输出上。这种框架忽略了一个更可怕的问题：在四阶段的工作流（pipeline）中，如果每个阶段都无条件地信任前一个阶段的输出，会发生什么。第一阶段中一个虚构的事实不仅会持续存在，还会成为后续每一次推理的承重前提。到第四阶段，工作流会给出一个自信且逻辑自洽的答案，但结果却是完全错误的。

这不是一个可以通过更强大的模型来解决的能力问题。这是一个系统架构问题，需要从系统层面进行修复。