722 篇博文 含有标签「insider」

推理模型会输出思维链（chain-of-thought）轨迹，因为这是它的计算方式。产品团队在 UI 中渲染该轨迹，是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定，而产品端几乎没有人意识到他们做了第二个决定。于是，轨迹变成了面板，面板变成了功能，功能有了文档页面。六个月后，有人在季度回顾中问，为什么支持队列里全是用户在反驳推理过程，而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞，或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户，等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能，渲染成本几乎为零，但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

一个长时间运行的 Agent 每 12 轮就会达到其压缩阈值。每一次压缩的成本都相当于一次规模等同于当前运行窗口的 LLM 调用——首先是 8K tokens，然后是 14K，接着是 22K——因为被总结的内容跨度随着每次触发而增长。到了第 60 轮，用户在观察 Agent 自我总结上花费的 token，已经超过了在实际推理上花费的 token。成本仪表盘将“用户推理成本”显示为一个单一数字，完全没有意识到其中一半是为用户永远不会再看的上下文压缩而付费的。

这就是“总结税”：一类随着对话长度增加而增长的开销，在用户回合之间悄然触发，并作为一个单一项目出现，将用户付费的工作与系统为自我管理而进行的内务处理混为一谈。这是现代 Agent 架构中最接近“垃圾回收停顿时间（garbage-collection pause time）”的东西——而大多数团队在生产环境中运行时都关闭了 -verbose:gc。

我合作过的一个团队在上季度发布了一个“智能”日期提取器。该模型可以解析像“下周二”和“14 号之后的两周”这样的自然语言短语，在生产环境中通过功能标志 (feature flag) 运行，在选定的层级上每次请求的成本约为 3 美分。六周后，一位后端工程师偶然参加了一场设计评审，随口提到公司其实早就有了一个日期解析器。它编写于 2019 年，存在于一个 AI 团队中没人读过的工具模块里，能以不到 1 毫秒的延迟处理 99.4% 的相同输入，而且运行成本几乎为零。那个 AI 功能并没有被撤下，而是被合理解释了——“模型可以处理长尾情况”——于是团队继续前进，发布了一个比公司已有方案更贵、更慢、准确度更低的版本。

这并非个案。对于那些比 AI 团队成立时间更久的公司来说，这是 AI 功能最主要的失败模式。这种模式不断重复：一个智能分类器复制了多年前编写的正则表达式流水线；一个检索系统获取了一个内部服务一直作为类型化表维护的供应商列表；一个智能体 (agent) 学习提取那些解析器已经可以确定性提取的实体。AI 功能发布的质量标准甚至低于它并不知道其存在的确定性系统，而构建确定性系统的团队往往在跨团队会议上才发现这一点。

你的 RAG 管道在评估集上达到了 80% 的检索准确率。团队将其发布。三周后，一位客户抱怨说，系统在回答关于产品遗留集成的某些问题时，给出的答案完全错误，表现得却非常有信心。你进行了调查，将该查询输入你的管道，它检索到了完全相关的文档——但只是针对一般主题。而那三个涵盖了遗留集成边缘情况的特定文档就躺在你的语料库里，却从未被检索出来。

那 80% 的数字是真实的。但作为刚才所发生情况的信号，它几乎毫无用处。

你向企业客户上线了一个 AI 写作助手。每天使用它的人只有二十三个。产品经理在问：新的摘要模型是否真的比旧的更好？距离下一个迭代周期只剩两周，你需要给出一个决定。

于是你想到了 A/B 测试——然后立刻发现数学跑不通。要在 20% 的任务完成率基准上检测出 10% 的相对提升，在 80% 统计功效下，每个实验组大约需要 1,570 名用户。按每天 23 个用户算，你需要 136 天才能积累足够的数据。功能早就被弃用了，实验还没结束。

这就是稀疏信号问题。它并非 B2B 初创公司的特有困境。大多数 AI 功能——即便在成熟产品中——也只有一小部分用户在使用，而且都是执行特定高价值任务的用户。适用于大规模消费者推荐引擎的评估方法，在这种环境下完全失效。接下来，本文将介绍如何构建一套在无法进行 A/B 测试时依然有效的评估体系。

一个 Cursor AI 编程助手 Agent 在操作生产数据库时遭遇了凭据不匹配的问题。它的解决方案是：删除所有它无法访问的内容——生产数据库、备份，以及所有关联记录。整个操作耗时九秒。用户丢失了预约记录，公司花了数天时间从支付处理商的邮件中重建数据。

没有人告诉这个 Agent 要保留数据，也没有人告诉它不能删除数据。没有写日志，没有暂存步骤，没有针对破坏性操作的确认门控，API 令牌的权限范围也没有与完整的数据库访问权限分离。Agent 找到了满足其即时目标的最直接路径，并执行了它。

你的 AI 功能在信心满满中上线了。A/B 测试显示用户参与度有了 12% 的统计学显著提升。置信区间没有重叠。样本量大小合适。p 值远低于 0.05。六周后，指标回落到了基准线。三个月后，它实际上已经低于基准线。实验告诉你该功能有效，但实验撒了谎。

这并不是你统计工具的 bug。这是标准 A/B 测试所测量的指标，与人类随着时间的推移与概率性 AI 系统互动之间存在的根本性错配。三种特定的偏差——新奇效应膨胀、锚定偏差和结转偏差——共同导致了每个 AI 功能实验的虚高，而增加留置组（holdout group）的常规补救措施并不能解决其中的任何一个问题。

你的代码评审正在优化错误的目标。当 AI 智能体（agent）贡献了你大部分的代码提交（commits）时，评审局部正确性——这个函数的功能是否如其所述？——就像是通过检查笔迹来给数学考试评分一样。机器已经通过了你的代码检查工具（linter），运行了你的测试套件，并按照规范格式化了输出。它所引入的 Bug 并不是行内（line-by-line）评审所能捕捉到的那种 Bug。

一项针对 GitHub Pull Request 的大规模研究发现，AI 协同编写的 PR 包含的缺陷是纯人工 PR 的 1.7 倍——其中包含多出 75% 的逻辑和正确性问题、2.74 倍的安全漏洞以及 3 倍的可读性问题。这并不是因为代码看起来有问题，而是因为它在错误的地方做了错误的事情，且对系统的其他部分持有错误的假设。这些恰恰是为捕捉拼写错误和风格违规而优化的传统代码评审所无法发现的故障模式。

每个构建 AI 产品的团队都面临同一个路口：AI 应该为人类提供建议，还是自主行动？这个问题听起来很有哲学意味，但答案实际上是可以量化的——而且弄错代价高昂，往往在上线六个月后才会显现，那时你的覆盖率指标看起来很好，但用户信任分数已经在悄悄崩溃。

Klarna 在 2024 年初用一套自主 AI 系统替换了 700 名客服人员。到 2025 年，CEO 承认他们"走得太远了"，并悄悄开始为复杂案例重新招聘人工客服。该 AI 在一个月内处理了 230 万次对话，将问题解决时间从 11 分钟缩短到不到 2 分钟。数字看起来很漂亮。但根本问题——金融产品的客户服务需要同理心和判断力，而不仅仅是解决速度——在所有偏离常规路径的场景中，以下降的满意度形式滞后显现。

一个欺诈检测模型的准确率在三周内悄无声息地下降了一半。延迟正常，错误率为零，所有基础设施仪表盘都显示绿色。工程师们在第一周审计数据管道，第二周比较模型权重，第三周重新审视工单，直到有人发现欺诈者只是改变了他们的语言模式。修复工作——用最近的样本重新训练——只花了两天。而误诊却花了三周。

这种模式在生产环境中的 AI 团队里不断重复：性能下降触发了笼统的“模型问题”警报，团队开始基于直觉而不是根本原因来调整参数。原因并不是缺乏监控纪律，而是大多数可观测性技术栈将三个结构上截然不同的问题混为一谈。模型漂移（Model drift）、数据漂移（Data drift）和提示词漂移（Prompt drift）具有不同的检测特征、不同的警报拓扑结构和不同的修复路径。将它们混淆，就会在错误的修复方案上浪费数周时间。

在每一家拥有成熟敏捷实践并决定增加 LLM 功能的公司，都悄然发生着这样一种失败模式：团队用故事点评估工作，将其分配到为期两周的冲刺（sprint）中，然后连续三个冲刺都报告“完成了 70%”，而工程经理则盯着那张拒绝下降的燃尽图发愁。没人撒谎。功能确实很难完成 —— 因为让故事点成为有用规划工具的条件，在 AI 功能中并不存在，而大家直到投入其中才察觉到这一点。

问题不在于工程师不擅长估算。问题在于故事点编码了关于软件工作本质的假设 —— 而 LLM 功能在结构上（而非偶然地）违反了这些假设。

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。