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

一名新工程师加入了一个重度依赖 AI 的团队。入职第三天，他们发现系统指令中有一个措辞别扭的双重否定。看起来像是个 bug。于是他们把它清理了——这是任何合理的人都会做的小小优化。两小时后，一条关键流水线的客户端分类准确率从 91% 跌至 74%。没有人知道原因。

这种情景以某种形式发生在几乎每一个基于 LLM 构建系统的团队中。新工程师并不粗心。那个提示词看起来确实有问题。但那个双重否定在某种意义上是"承重墙"——只有写下它的人才真正理解，而那是在经过数周实验之后才领悟到的。他们从未把这种理解写下来。

这就是 AI 入职差距：AI 代码库表面上的行为与实际行为之间的鸿沟，以及为什么这个鸿沟在有人掉进去之前是不可见的。

你的 AI 流水线昨晚报告了零错误。但输出结果完全是错的。

这不是假设。一份近期的行业报告发现，大约每 20 个生产环境 LLM 请求中，就有 1 个以永远不会触发异常的方式失败——HTTP 200、格式正确的 JSON、流畅的散文，但内容却是错的。可观测性系统保持绿灯，而流水线却在悄悄地欺骗用户。

根本原因是一个从传统服务工程中借来的架构假设：HTTP 状态码和解析错误覆盖了所有故障空间。但事实并非如此。LLM 流水线至少有四种底层基础设施看不到的故障类型——幻觉、拒绝、格式违规和上下文溢出——把它们当作边缘情况而非一等公民错误类型来处理，正是生产 AI 系统如何大规模传播隐性 Bug 的根源。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。

这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。

一个令人不安的事实：80% 的 AI 项目未能提供业务价值，但团队却一直在追求最复杂的解决方案。一个具备工具调用、记忆检索和自主规划的多 Agent 编排系统可以做一个引人入胜的演示。而一个将客户支持工单路由到正确队列的简单 Prompt，在第一年就能为你公司赚到 200 万美元。这两种结果的可能性并不相等，普遍程度也不同，而行业一直在做出错误的选择。

这种模式是可预测的。一个工程团队构建了一些令人印象深刻的东西，向领导层演示，获得发布批准——然后眼睁睁地看着它在生产环境中悄无声息地退化。与此同时，竞争对手悄悄部署了一个封装了分类器的两百行 Python 脚本，从未进行过演示，却在每一项重要的业务指标上都超越了他们。

大多数团队选择一个分块大小，针对检索质量进行调优，然后就此止步。接着，他们在同一个索引上构建一个 Agent，并纳闷为什么 Agent 会以奇怪的方式失败——它只执行了一半的工作流，忽略了条件逻辑，或者根据不完整的指令自信地采取行动。使你的 NDCG 分数最高的分块大小，恰恰是让你的 Agent 变得不可靠的原因。

RAG 检索和 Agent 执行并不是同一个问题。它们有不同的目标、不同的失败模式，以及对什么是“好的分块”有着根本不同的定义。当你针对其中之一优化分块时，你就在系统性地削弱另一个。大多数团队直到已经在错误的架构基础上构建完产品后才意识到这一点。

当生产环境出现 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 路由栈的默认行为。