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

当生产环境出现 Bug 时，第一个仪式总是相同的：打开 git blame，找到写下那行代码的人，问他们为什么要这么写。这个仪式假设作者是有原因的——他们知道的某个限制、刻意处理的边缘情况，或者从三个季度的复盘报告中内化而来的业务规则。在软件史的大部分时间里，git blame 回答的是关于意图的问题。

现在，对于比例日益增长的提交，git blame 指向的是合并代码的人和生成代码的 AI。人类可能只花了 90 秒阅读 diff。而 AI 除了 prompt 之外没有任何上下文。那些让 git blame 变得有用的“为什么”——即组织知识——从未在任何地方被记录下来。

这就是代码所有权衰减。它不会自我宣告。没有哪一个单一的提交会破坏系统。相反，理解力会慢慢被掏空，直到团队到达一个决策点——一次重构、一次事故或一名新员工入职——才发现再也没有人能从内部解释这个系统了。

大多数关于幻觉的研究都集中在单次模型调用的输出上。这种框架忽略了一个更可怕的问题：在四阶段的工作流（pipeline）中，如果每个阶段都无条件地信任前一个阶段的输出，会发生什么。第一阶段中一个虚构的事实不仅会持续存在，还会成为后续每一次推理的承重前提。到第四阶段，工作流会给出一个自信且逻辑自洽的答案，但结果却是完全错误的。

这不是一个可以通过更强大的模型来解决的能力问题。这是一个系统架构问题，需要从系统层面进行修复。

你的智能体在第三轮对话时明确说过"绝对不要使用 eval()"。到了第三十轮，它调用了 eval()。你的保险处理系统规定"未经有效身份验证，不得批准理赔"。经过十五个压缩周期后，它批准了一笔。这些不是模型失败——是压缩失败。智能体的推理本身没有问题，是摘要中间件把那条唯一关键的约束丢掉了。

上下文压缩如今已成为长时运行智能体系统的标准基础设施。当对话历史增长到超出上下文窗口时，你就会进行压缩——把旧的轮次汇总成摘要，进行修剪、分块或精炼。问题在于，现代摘要器并不是随机破坏信息，而是可预测地沿着特定的断裂线破坏信息，而大多数团队只在生产环境中才发现这些断裂线。

在一个生产环境中的 LLM 功能上线半年后，一名工程师提交了一个 bug：模型在上个季度的某个时间点开始给出错误的输出。没人记得改过提示词（Prompt）。Git blame 显示它为了“提高可读性”被清理过。之前的版本已经找不到了。调试工作只能从零开始。

就在这一刻，团队才发现他们的上下文窗口（context window）从未被真正工程化过——它只是被拼凑出来的。

上下文窗口是你的系统与模型之间的契约。进入其中的每一个标记（token）——系统指令、检索到的文档、对话历史、工具架构、用户查询——都是对一个函数调用的输入，这个调用既费钱又耗时，且会产生非确定性的输出。然而，大多数团队将上下文组合视为实现细节，而非 API 表面。提示词被就地编辑，没有版本控制。各部分通过累加增长。没有人负责布局。变化在无声无息中传播。调试体验比 LLM 时代之前的任何东西都要糟糕，因为至少堆栈跟踪（stack traces）会告诉你什么是改变了的。

每个 AI 融资演讲稿中都会包含一张关于数据飞轮的幻灯片。故事听起来很诱人：用户与你的 AI 功能交互，交互产生数据，数据训练出更好的模型，更好的模型吸引更多用户，循环往复。只要规模足够大，你就能拥有一道难以逾越的竞争护城河。

问题在于，大多数发布 AI 功能的团队并没有飞轮。他们只有一个日志文件。一个非常巨大、存储成本极高，但从未改进过模型，也永远不会改进模型的日志文件——因为实现真正飞轮的三个前提条件缺失了，而且没有人问过这些条件是否存在。

你的 AI 系统在上午 9 点将一条患者查询路由到了自托管模型。上午 11 点，该模型的 Pod 在部署时重启。请求队列积压，路由器检测到超时，随即回退到你用于通用查询的云端 LLM。请求成功完成，没有告警触发，监控面板一片绿色。而就在这次交互中，受保护的健康信息悄然流向了一个你根本没有签署《业务伙伴协议》的供应商。

这不是假设，而是几乎所有未经专门设计来防范此类问题的 AI 路由栈的默认行为。

你的 LLM API 调用在 P99 分位下于 500 毫秒内完成。但你的用户却在等待 12 秒。这两个数字都是准确的，谁都没有撒谎——它们只是在测量完全不同的东西。两者之间的差距正是大多数 Agent 系统性能无声流失的地方，而且大多数团队从未对其进行过监控（instrumentation）。

问题是结构性的：P99 LLM 延迟是一个应用于多步执行模型的单次调用指标。一个 ReAct Agent 进行五次连续的工具调用、重试一个幻觉化的函数、组装不断增长的上下文并生成 300 个 token 的推理链，这并不是一次 LLM 调用。这是一个分布式工作流，其中 LLM 只是一个节点，而其他每个节点都有其自身的延迟开销。

一个中型公司的团队在发布文档摘要功能三个月后，对提示词进行了优化。新提示词在他们手动测试的 5 个示例上表现更好。他们在周五下午部署了它。周一上午，Slack 里堆满了用户反馈：摘要现在会截断一半文档，却将截断后的内容呈现为完整版本。功能看起来没问题，变更通过了代码审查，没有人发现，因为根本没有评估机制——没有黄金测试集，没有回归基线，没有自动检查。棘轮已经悄悄转动了数月。

这就是评估债务最典型的表现形式。团队跳过评估并非因为粗心大意，而是因为为 AI 功能编写评估比听起来难得多，功能发布快且看起来运行良好，没有人想拖慢一个高速运转的团队。现在，他们正在偿还复利。

AI评估的命运遵循着一条可以预测的弧线。冲刺零阶段：所有人都认同评估至关重要。上线周：套件运行顺畅，演示效果完美。第六周：CI任务开始被跳过。第十周：有人调高了失败阈值以消除告警。第四个月：绿色仪表盘已毫无意义，人人心知肚明，却无人点破。

这就是评估疲劳周期，它几乎普遍存在。尽管业界在自动化评估工具上持续投入多年，其市场渗透率仍仅有38%——这意味着大多数团队依然依赖人工审查作为主要的质量门控。当下一个模型版本升级，或本周Prompt已是第三次更改时，这些人工审查往往第一个被牺牲掉。

你的 AI 评估测试集（eval suite）有 800 个测试用例。你又增加了 200 个。现在你的模型在评估中得分 94%，你满怀信心地发布了。三天后，一名用户发现了一个回归（regression）问题，而你那 1000 个测试用例中没有一个捕获到它。

这不是运气不好 —— 而是结构性问题。回归问题的存在恰恰是因为你扩充测试集的方式，而不是尽管你扩充了测试集才存在。当出现故障时增加更多评估指标（evals）的本能在理论上是正确的，但在实践中却适得其反。更多的测试并不自动意味着对重要事项的覆盖率更高。它们意味着对那些易于测试的事项有了更好的覆盖，而这完全是两回事。

你的流式传输正常工作。你的重试逻辑正常工作。你的安全过滤器正常工作。你的个性化功能也正常工作。但当你将它们部署在一起时，奇怪的事情发生了：流式传输中途出现的速率限制错误导致用户看到的是一段被截断的响应，而系统却将其记录为成功。重试机制触发了，但流式传输已经结束。个性化层提供了一个定制化的响应，而安全过滤器本应拦截这个响应——除非过滤器看到的是 Prompt 的脱敏版本，而不是个性化层所处理的那个版本。

每一个功能都通过了你编写的各项测试。然而系统还是让用户失望了。

这就是功能交互故障（feature interaction failure），它是当今 AI 系统中最容易被误诊的生产环境 Bug。

中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队，统一工具链，建立治理机制，让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见，在董事会演示中无懈可击。然而在实践中，它可靠地生产出一种失败模式，看起来恰恰就像它本要消除的碎片化。

中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了；一个 9 个月的安全审查把它埋葬了。

2025 年，企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。