你的 RAG 评估仪表盘显示为绿色。忠实度（Faithfulness）为 0.91，回答相关度（Answer Relevance）为 0.88，你花了两个迭代周期构建的 LLM-as-judge 评估框架显示系统运行良好。与此同时，一位用户刚刚问了一个问题，而答案就在你的检索器（retriever）从未提取出的文档中，你的模型写下了一个自信、结构清晰但完全没用的回答，内容与问题相关但风马牛不相及。评判员给了它高分。它读起来很顺畅。它基于模型 确实 获取到的片段。它只是用与用户需求无关的内容回答了一个错误的问题。
这是大多数团队评估检索增强生成（RAG）时存在的隐性结构缺陷：他们给文章打分，却从未检查学生是否拿到了正确的书。RAG 系统是两个连接在一起的机器——一个是决定 模型能看到什么 的检索器，另一个是决定 如何处理这些内容 的生成器。几乎生产环境中的每一个评估框架都只衡量第二个机器。第一个机器，也就是真正决定答案质量上限的那个，却在未经监控的情况下运行。
一位工程副总裁决定公司需要“做 AI”。公司已经有一个机器学习团队——三个人，他们构建了推荐模型，调整了反欺诈分类器，并维护着一个特征存储（feature store）。显而易见的举措是让他们负责新的 LLM 项目。他们懂数学，也发布过模型。能有多大区别呢？
六个月后，原型演示效果惊艳，但在生产环境中却惨遭失败。没人能解释为什么智能体（agent）偶尔会订错会议，每个请求的成本是预估的四倍，而且根本无法判断上周的提示词（prompt）更改是让情况变好了还是变坏了。机器学习团队感到很沮丧，因为他们擅长的所有工具——梯度下降、数据流水线、超参数搜索——在他们既无法重新训练也看不透内部构造的模型上都派不上用场。
这是目前 AI 领域最常见的组织架构错误，它源于一个听起来很合理的假设：构建模型的技术与基于模型构建应用的技术是同一份工作的不同标签。事实并非如此。它们之间的重合度甚至比“前端工程师”和“后端工程师”还要低。
你的轮值制度（on-call rotation）最初是为了捕获一种特定类型的故障，但绝非那种真正会让你的 AI 产品崩溃的故障。它监控的是停止响应的服务、飙升的延迟曲线、超过 1% 的错误率。这些都是阶跃函数（step functions）：原本运行正常的东西突然失效了，这种不连续性足以在凌晨 3 点叫醒一名工程师。整个体系——阈值、运维手册（runbooks）、升级策略——都假设故障会自我宣告。
对于一个包含模型在环（model in the loop）的系统，真正关键的失效模式恰恰相反。上周二，你的提取流水线准确率为 94%。这周二，它变成了 91%。没有服务崩溃。每个请求都返回了 200。延迟平稳。输出依然是格式良好的 JSON。但你 3% 的用户现在得到了微妙的错误答案，而且他们不会提交 Bug，因为答案看起来是正确的。由于没有触发条件，寻呼机（pager）保持沉默。等到有人注意到时——通常是愤怒的客户，通常是在几周后——这种回归（regression）在整个过程中一直在静默地累积恶化。
你需要更多的训练数据，于是你生成了它们。模型编写了几千个例子来填补数据集中的空白——边缘案例、代表性不足的意图，以及你真实日志从未涵盖的长尾数据。你抽检了一个样本。每个例子看起来都不错：语法正确、符合主题、标签准确。你将这一批数据加入到微调集中，然后继续工作。
三轮迭代之后，你的模型在那些你特意生成数据来覆盖的案例上表现反而变差了。并不是灾难性的变差——只是悄无声息地、均匀地变得平庸。以前偶尔能奏效的稀有意图现在完全失效了。用户实际输入的措辞被误读。而你的质量检查中没有任何一项发现异常，因为你生成的每一个独立案例确实都很正常。
失败不在于任何单个案例，而在于分布。合成数据在没有现实锚点的情况下被生成和反复生成，会向均值收缩——而长尾部分，即你求助于合成数据的根本原因，是首先消失的部分。
你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。
这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。
AI 领域的每个人都知道基准测试污染（benchmark contamination）的警示故事：模型厂商抓取公开网络，GSM8K 和 MMLU 最终出现在预训练语料库中，导致报告的分数衡量的是召回而非推理。这通常被视为别人的过错——是基础模型实验室的问题，是你继承下来的瑕疵。因此，你构建了自己的留存评估集，将其存放在私有仓库中，并认为自己是清白的。
你可能并不清白。在生产级 AI 系统中，最具破坏性的污染很少是继承来的，而是由心怀好意的工程师遵循看似合理的流程在内部制造出来的。你的评估集通过你自己建造的大门泄露到了训练流水线中，而且这种泄露是无声的：就在你的基准测试停止衡量任何真实事物的瞬间，每个仪表盘都会变成绿色。
这就是你亲手造成的污染。它比你继承的那种污染更值得关注，因为你是唯一能够检测到它的人——而几乎没有人会为此进行审计。
你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？
这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。
一家物流公司花费了 80 万美元、历时十二个月，尝试用 AI 优化路线规划。项目结束时，他们的路线效果仅比原有启发式规则略有提升。高管层随后否决了接下来三个 AI 提案。一家外卖公司面临同样的路线问题，却用一套显式业务规则在一个晚上就解决了。
两支团队都学到了一个代价高昂的教训：在实时约束、司机偏好和时间窗口交织的路线优化问题中，AI 并非 正确的解法——这是一个组合调度问题。你想要学习的模式并不隐藏在数据里；它们是运营部门的人早就知道的显式领域逻辑。
这种情况在各行各业不断上演。2025 年麻省理工学院的一项研究发现，95% 的企业 AI 试点项目未能产生任何可衡量的业务影响，尽管总投资高达 300 至 400 亿美元。最主要的失败原因不是模型差或数据不足，而是团队在 AI 根本不是正确工具的问题上构建了 AI 解决方案。
你的推荐模型在三个月前上线了。点击率增长了 18%。观看时长在不断攀升。仪表盘上一片飘绿。领导层很满意。
而你的模型正在悄悄地破坏它将用于训练下一个版本的数据。
这就是训练数据自中毒（training data self-poisoning）：一种反馈循环，其中已部署的 AI 功能会改变用户行为，其方式破坏了模型最初训练时学习的交互数据。最糟糕的是，你的标准参与度指标会告诉你一切正常 —— 直到它们失效的那一刻。
几乎每个经历过初期演示阶段的微调项目，都会重蹈同一个覆辙：团队遭遇质量平台期，决定需要更多数据，增加了 50% 的样本，重新训练，却发现模型要么一如既往地平庸，要么明显变差了。增加数据的直觉对大多数软件问题是对的——更多信号通常有帮助。但微调存在一个预训练所没有的饱和区间，大多数从业者并不能识别自己何时进入了这个区间。
2024 年一项在 Qasper 数据集上测试 LLM 微调的研究发现，将训练集从 500 条扩展到 1,000 条后，Mixtral 的准确率得分从 4.04 跌至 3.28，完整性得分从 3.75 跌至 2.58。这不是超参数问题，而是数据饱和：模型开始记忆分布噪声，而非学习可泛化的模式。团队在引擎已经淹没之后，继续往里加燃油。
你的 AI 个性化系统已经学会了用户是谁。它建立了用户画像，调优了向量表示，并给出了令人惊叹的精准推荐。然后，它悄悄地开始欺骗你——不是用错误，而是用过时的"真相"。上个季度痴迷于 Kubernetes 的用户加入了一家初创公司，现在需要了解销售漏斗。买了两年婴儿用品的客户刚刚把最小的孩子送去了幼儿园。你的模型仍然以为自己认识他们，但它并不了解。这就是个性化画像衰减，这是团队只有在用户抱怨 AI"不再懂我"时才会发现的静默失败模式。
大多数团队会先发布他们最大胆的 AI 功能。那个功能通常是他们研发了六个月、演示效果极佳、且让领导层倍感兴奋的作品。但它在生产环境中失败了——算不上灾难性的，但足以让用户感到不安——于是，随之而来的每一个 AI 功能都会继承这种怀疑。即使团队后来修复了最初的问题，接下来的整整一年里，他们依然会纳闷为什么采用率始终停滞不前。
这就是“第一个 AI 功能”的问题。你首先发布的内容建立了一个先例，这种影响在技术问题解决很久之后依然存在。用户对 AI 的信任建立在第一次失败之上，而非第一次成功。你发布功能的顺序比任何单一功能的质量都更重要。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
