861 篇博文 含有标签「insider」

一个构建基于LLM的文献筛选工具的团队在测试集上庆祝96%的准确率。按照任何标准工程指标，他们的模型表现都非常出色。但有一个问题：它找到了零个真正的阳性结果。该模型学会了将所有内容归类为无关内容，但仍然获得了近乎完美的准确率，因为相关论文在数据集中极为罕见。失败不在于模型——而在于指标。

这种失败模式并不罕见。它每周都在AI团队中悄然上演，工程师在没有产品输入的情况下选择评估指标——就像选择排序算法一样，视其为有正确答案的技术选择。这种框架是错误的。指标选择是一个产品决策。它编码了你愿意容忍哪些失败模式、你在为哪些用户优化，以及在你的特定场景中"好"究竟意味着什么。搞错这一点会产生看起来严谨却衡量了错误事物的评估套件。

AI 平台团队最常见的失败模式不是技术问题，而是组织问题：中央平台团队成了每个产品团队将 AI 能力推上生产的必经关卡。请求队列不断增长，交付周期从几天膨胀到几周。产品团队愈发沮丧，开始拼凑非官方的绕道方案——硬编码 API 密钥、私下接入 LLM、用个人信用卡注册供应商账户。等平台团队察觉时，组织里已有一半的 AI 工作游离在任何治理体系之外。

问题不在于平台团队关心治理，而在于他们把治理实现成了审批流程，而非基础设施。

你的推荐模型在三个月前上线了。点击率增长了 18%。观看时长在不断攀升。仪表盘上一片飘绿。领导层很满意。

而你的模型正在悄悄地破坏它将用于训练下一个版本的数据。

这就是训练数据自中毒（training data self-poisoning）：一种反馈循环，其中已部署的 AI 功能会改变用户行为，其方式破坏了模型最初训练时学习的交互数据。最糟糕的是，你的标准参与度指标会告诉你一切正常 —— 直到它们失效的那一刻。

一个团队上线了一个改进的 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产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。