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

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。你不需要更智能的模型，你需要的是一个任务状态机。

12 要素应用（12-Factor App）准则让开发/生产环境一致性（dev/prod parity）变得家喻户晓：尽可能保持开发、预发布和生产环境的相似。对于传统的 Web 服务，这基本是可以实现的。但对于 LLM 应用，这在结构上是不可能的 —— 且其中的差距远比大多数团队意识到的要大。

问题不在于开发者粗心大意。而是在于 LLM 应用依赖于一类特殊的基础设施（缓存计算、实时模型权重、不断演进的向量索引以及随机性生成），在这些设施中，预发布环境（staging）与生产环境之间的差异不仅是令人不便，而是本质上完全不同。一个看起来正确的预发布环境至少会在七个具体方面对你撒谎。

大多数工程团队是通过在截止日期前三周收到的一封法律邮件才了解到 GDPR 的。欧盟 AI 法案（EU AI Act）正在重演这一模式，而 2026 年 8 月 2 日针对高风险 AI 系统的强制执行日期已经非常临近，“以后再处理合规问题”已不再是一个可选项。GDPR 与 AI 法案的区别在于，GDPR 的合规大多是关于数据处理政策的。而 AI 法案的合规要求构建新的系统组件——这些组件在大多数生产环境中的 AI 系统中尚不存在。

法规中所谓的“人类监督义务”和“审计追踪要求”，转化为工程语言，就是一个仪表盘、一个事件日志和一个数据血缘系统。本文将欧盟 AI 法案视为一份工程规范而非法律文件，并逐步介绍你实际需要构建的内容。

一项针对 106 个企业 AI 系统的 appliedAI 研究发现，40% 的系统风险分类不明确。这一数字并不反映监管的复杂性——它反映的是有多少工程团队在交付 AI 功能时，从未追问该功能是否改变了合规层级。欧盟 AI 法案对高风险系统的强制执法日期定为 2026 年 8 月 2 日。届时，处于那 40% 之列不再是管理问题，而是一个架构问题——你将在监管机构注视之下，以四倍于原始成本的代价、在截止日期的压力下修复它。

本文不是法律概述，而是面向工程师的深度解读：哪些产品决策会悄然触发高风险分类，这些分类对应哪些具体交付物，以及为什么事后改造的成本远高于一开始就内置合规的成本。

大多数工程团队会花费数周时间来评估 LLM 提供商——对延迟进行基准测试、测试准确性、洽谈价格。然后，他们会在一个下午，仅仅根据一个设计精美的落地页和一篇好评博文，就选定了一个观测工具、一个护栏供应商和一个嵌入提供商。这种不对称性是本末倒置的。你的 LLM 提供商可能是一家资本充足且拥有稳定 API 的公司，但其周围的小众供应商通常并非如此。

AI 服务生态系统已经爆发式地增长到了几十个类别：护栏供应商、嵌入提供商、观测与追踪工具、微调平台、评估框架。每个类别都有十家初创公司在争夺同样的企业预算。其中一些会被收购，更多的会倒闭。少数公司会转型，并在发出 90 天通知邮件后弃用你的关键工作流。在没有经过严格评估的情况下基于这个生态系统进行构建，是一种直到演变成生产事故才会出现在你的待办事项中的技术债务。

企业团队基于基准测试和演示选择LLM供应商，然后在生产环境中才发现SLA实际保障的内容——通常远低于预期。你费力谈下来的99.9%可用性保证并不涵盖延迟。法务团队签署的数据处理协议，除非明确添加了相关条款，否则并不禁止供应商用你的输入数据进行训练。而没有人量化的供应商集中风险，在某次遥测部署级联影响Kubernetes控制平面导致核心产品中断四小时后，会以最惨烈的方式暴露出来。

这不是采购问题，而是采购单独无法解决的工程问题。构建AI系统的工程师需要理解这些合同实际说了什么——以及没说什么。