678 篇博文 含有标签「ai-engineering」

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

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

你的 LLM 功能开始返回胡言乱语。值班工程师呼叫 ML 团队。他们看了看输出，和提示词本应产生的结果对比了一下，不到一小时就关闭了工单："提示词有问题——已调整并重新部署。"事件关闭，事后复盘完成，行动项：改进提示词工程流程。

两周后，同类故障再次发生。不同的提示词，不同的功能——但是同样隐性的根因。

"修提示词"的反射动作，是 AI 工程领域版本的"甩锅给最后一个碰过这个文件的开发者"。它给事后复盘一个干净的结局，却无需任何人真正理解到底是什么出了问题。而与传统软件不同——那里这种反射动作只是懒散——在 AI 系统中，它在结构上是危险的：因为非确定性系统的失败方式，是提示词修改无法解决的。

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

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

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

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

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

你的 GPU 监控面板正在欺骗你。利用率显示 60%，推理集群看起来健康无虞。用户却在经历 8 秒的首 Token 时间（TTFT）。值班工程师检查内存——正常。计算——正常。然而队列在增长，延迟在飙升。这就是将传统容量规划应用于 LLM 工作负载时会发生的事：你信赖的指标指向了错误的地方，真正的瓶颈在用户开始抱怨之前一直不可见。

根本问题在于：LLM 消耗的是一种本质上不同的资源。CPU 服务交换的是计算和内存。LLM 服务交换的是 Token——而 Token 的行为与请求截然不同。

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

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

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

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

一场持续 90 分钟的客服会话。一个已经浏览文档一小时的研究助手。一个已经处理十几个文件的编程 Agent。所有这些最终都会撞上同一堵墙——但撞上时，它们不会大声报错。它们只会变得迟钝。

模型开始遗忘二十分钟前做出的决定。它自相矛盾。本应显而易见的检索结果莫名消失。用户察觉到有些不对劲，却说不清助手为何变差了。这就是上下文窗口悬崖：不是一个硬性错误，而是一种渐进的质量崩塌——而你的监控系统几乎肯定没有衡量它。

扩大上下文窗口并不能解决这个问题。拥有百万 Token 窗口的模型在处理中间位置内容时仍然会退化；即便不退化，你也在为多出 100 倍的 Token 买单，而模型实际关注的只是其中一小部分。解决方案是应用层的上下文管理——明确策略什么留在窗口里、什么被压缩为摘要、什么完全移到窗口之外。

你的部署流水线是绿色的。延迟处于正常水平。错误率：0.02%。新的模型版本已成功发布——或者说你的仪表盘是这么显示的。

与此同时，你面向客户的 AI 正在微妙地以较低的精度总结文档，对以前能直接回答的问题含糊其辞，并不时地压平下游流水线所依赖的结构化输出。没有警报响起。没有触发值班呼叫。你收到的第一个信号是两周后的一张支持工单。

这就是 AI 部署中的隐性回归问题。传统的回滚信号——HTTP 错误、p99 延迟、异常率——是为确定性软件构建的。它们无法察觉行为漂移。随着团队更频繁地升级语言模型，“基础设施健康”与“AI 运行正确”之间的鸿沟成了回归问题的藏身之处。

大多数工程团队把系统提示词当作配置文件对待——需要快速迭代的技术字符串，存储在环境变量中，部署时的仪式感和修改一个超时值差不多。系统提示词有内联注释。错误提示一条也没有。能力披露就是产品经理在上线当天往 Notion 文档里打的那段话。

这正是整整一类 AI 产品故障的根源——这类问题不会出现在你的评估套件里。模型回答了问题，延迟没有问题，JSON 验证通过了。但用户在三次会话之后就停止信任这款产品，周活跃用户曲线再也没能回升。

缺失的那门学科叫对话设计。它影响输出质量的方式，大多数工程监控在架构上是盲目的。

大多数团队会在最糟糕的时机发现同一个事实：下线一个 AI 功能与废弃一个 API 完全不同。你在文档中添加了停用日期，发送了常规的三封系列邮件，切换了标志位——然后眼睁睁地看着支持队列激增 80%，而用户则大声解释替代方案“运行方式不一样”。他们的意思是：旧智能体的怪癖、特定的故障模式、以及它独有的错误答案，都已经变成了业务中不可或缺的支撑。他们在那些直到消失才被察觉的行为基础上，构建了整个工作流。

这就是 AI 功能废弃的核心问题。确定性 API 具有明确的契约（contracts）。如果你移除一个端点，每个依赖它的调用者都会收到 404 错误。损坏是可追踪、有限且可预测的。概率性 AI 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。

每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。

对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。