861 篇博文 含有标签「insider」

你的团队花了三个月时间将 LLM 集成到产品中。模型运行正常，延迟在可接受范围内，演示效果也非常棒。你上线了产品，然后眼睁睁地看着使用率指标停留在 4% 不动了。

这是一个典型的过程。大多数 AI 功能的失败并非发生在模型层面，而是在采用（adoption）层面。其根本原因并非技术问题，而是一系列围绕可发现性（discoverability）、信任和习惯养成而做出（或未做出）的产品决策。理解为什么采用率会失败，以及实际上应该衡量和改变什么，是交付“有用 AI”的团队与仅交付“令人印象深刻的演示”的团队之间的分水岭。

你的 AI 功能在第三季度上线了。评估结果看起来不错。用户很满意。六个月后，满意度评分下降了 18 分，但你的仪表盘依然显示 99.9% 的可用性和低于 200 毫秒的延迟。没有任何地方看起来坏了。从传统意义上讲，也没有任何地方真的坏了。模型在响应，基础设施很健康。只是这个功能在悄无声息地出错。

这就是生产环境 AI 系统中“时间衰减”（temporal decay）的样子。它不会通过报错来提醒你。它以模型所知与现实世界现状之间的差距形式不断累积——等到你的支持队列反映出这一点时，损害已经持续数月之久。

你的智能体（agent）刚刚做了一些它不该做的事情。也许它给错误的人发了邮件。也许它执行了本应是读取操作的数据库写入。也许它给出的医疗建议让用户进了医院。你现在正处于一场 AI 事故中——而你一直以来使用的应对软件停机的策略（playbook）对你毫无帮助。

传统的事故应对指南建立在一个基本假设之上：给定相同的输入，系统会产生相同的输出。这个假设让你能够重现故障、二分定位原因并验证修复。但在处理基于自然语言的随机（stochastic）系统时，这些都不适用。同一个提示词（prompt）通过同一个流水线，在不同的运行、供应商、区域和时间下，可能会产生不同的结果。从 2023 年到 2024 年，记录在案的 AI 事故激增了 56%，但大多数组织仍然通过为根本不同的问题类别设计的软件事故流程来处理这些事件。

这就是他们本该编写的应对指南。

大多数团队在选择标注策略时，都会比较单价：众包工人大约 $0.08/条，LLM 生成不到$0.003/条，人类领域专家约 $1/条。跑一遍表格，选出看起来"足够好"的最便宜选项，然后上线。这套算法经常让团队陷入麻烦。

真正的决策并非只看单条标签的成本。每种标签来源都有一个隐藏的质量税——以垃圾梯度、误导性评估曲线，或花费数月排查生产故障的形式复利叠加；而干净的标签本可以在训练阶段就捕获这些问题。最便宜的来源往往是计入下游信任成本后最昂贵的一种。

大多数构建 AI 产品的团队会花费数周时间设计评分组件、星级点击、点赞/点踩按钮。然而六个月后，他们查看数据时发现响应率仅为 2% —— 数据偏向于极端体验，被那些带有强烈偏好的人主导，而且在区分 7/10 和 9/10 的输出方面几乎毫无用处。

与此同时，每一个用户会话都在产生源源不断的真实、明确的行为信号。接受代码建议并继续操作的用户是满意的。立即按下 Ctrl+Z 的用户则不满意。连续四次重新组织问题的用户正在告诉你一些显式评分永远无法捕捉到的信息：前三次回答都失败了。无论你是否收集，这些信号都存在。问题在于你是否正在闭合这个反馈回路。

当GPT-4在MMLU上得到88%时，感觉是一个里程碑时刻。MMLU——大规模多任务语言理解基准——涵盖从小学数学到专业法律的57个学科。在如此广泛领域达到88%的准确率，看起来是真正广泛智能的有力证据。后来研究人员创建了MMLU-CF，一个无污染变体，替换掉了与已知训练语料库存在可疑相似性的问题。GPT-4o下降到73.4%——差距高达14.6个百分点。

这个差距不是小的舍入误差。它代表的是"在复杂学术问题上可靠正确"与"在见过这道题时可靠正确"之间的区别。对于基于排行榜分数做模型选择决策的团队来说，这意味着购买了一种并不真正存在的能力。

一个日历日期选择器让一个生产环境浏览器 Agent 连续失效三天，无人察觉。设计师在一次小型 UI 改版中，将原生 <input type="date"> 替换为自定义 React 组件。没有 API 变化，没有内容移动，只是新布局中 24px 的单元格——而此前一直可靠点击正确日期的视觉模型，现在偏移了一格，悄悄地把预约订在了错误的日期。

这就是 DOM 脆弱性税：在从未为机器操作而设计的 Web 之上构建自动化 Agent，所持续付出的运营成本。与大多数基础设施税不同，它会复利累积。Web 在变化，反爬虫防御在进化，SPA 越来越动态，而你的 Agent 在悄然退化。

黑色星期五的流量峰值来了。传统 API 服务的应对方式是启动更多容器。60 秒之内，你的容量就扩充到三倍。自动扩缩容器做了它一贯的事，你安然入睡。

但如果用同一个自动扩缩容器跑 LLM，结果就大相径庭了。新的 GPU 实例要在四分钟的模型权重加载之后才能上线。等那时候，你的请求队列已经塞满，现有 GPU 在半途生成的请求的内存压力下颠簸挣扎，用户盯着转圈圈的加载动画发呆。增加更多算力没有任何帮助——瓶颈根本不在你以为的地方。

AI 推理负载打破了让响应式自动扩缩容在传统服务中奏效的大多数假设。理解其中的原因，是构建能够扛住流量峰值的系统的前提。

你升级到了最新模型，结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高，能处理更难的问题，拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力？退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出，而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感，现在像是在自动驾驶。

这就是能力激发差距：模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环，这个差距系统性地扩大。

AI 生产力研究中有一个几乎无人提及的数字：39 个百分点。一项针对有经验开发者的研究中，参与者预测 AI 工具会让他们快 24%。完成任务后，他们仍然认为自己快了 20%。实际测量结果：他们慢了 19%。感知差距是 39 个百分点——而且每次迭代、每次代码审查、每个交付的功能都在累积。

这就是认知负载倒置。AI 工具擅长卸载廉价的认知工作——编写语法正确的代码、起草模板、建议函数名——同时产生了一类更难的认知工作：对不确定输出的持续评估。你并没有消除认知努力，而是将简单的一半自动化了，然后把困难的一半留给了自己。

在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。

这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。

大多数工程团队对待 LLM 上下文窗口的方式，就像早期 Web 开发者对待全局变量：先塞进去，问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档，以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了，而那时已经很难判断究竟是哪里出了问题。

上下文窗口不是堆内存。它更接近于 CPU 寄存器文件：容量有限、单位成本高昂，且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时，程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时，LLM 会以悄无声息且代价高昂的方式退化。