你需要更多的训练数据，于是你生成了它们。模型编写了几千个例子来填补数据集中的空白——边缘案例、代表性不足的意图，以及你真实日志从未涵盖的长尾数据。你抽检了一个样本。每个例子看起来都不错：语法正确、符合主题、标签准确。你将这一批数据加入到微调集中，然后继续工作。
三轮迭代之后，你的模型在那些你特意生成数据来覆盖的案例上表现反而变差了。并不是灾难性的变差——只是悄无声息地、均匀地变得平庸。以前偶尔能奏效的稀有意图现在完全失效了。用户实际输入的措辞被误读。而你的质量检查中没有任何一项发现异常，因为你生成的每一个独立案例确实都很正常。
失败不在于任何单个案例，而在于分布。合成数据在没有现实锚点的情况下被生成和反复生成，会向均值收缩——而长尾部分，即你求助于合成数据的根本原因，是首先消失的部分。
你发布了一个模型升级。评估套件的分数从 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 的信任建立在第一次失败之上，而非第一次成功。你发布功能的顺序比任何单一功能的质量都更重要。
长期 AI 系统存在一种失效模式，在产品评测中鲜有人提及，却频繁出现在用户行为数据中：人们开始绕过自己的 AI 助手。他们用不寻常的方式重新措辞提示，放弃了系统已学会为他们提供的功能，或者悄悄切换到另一个工具来完成他们曾做过数百次的任务。系统成功了——它学习了——而这恰恰是它停止工作的原因。
这就是人设锁定问题。当 AI 适应你的过去行为时，它正在构建一个训练时期的"你"的模型。随着每次交互，该模型变得越来越自信。最终，它成了一座牢笼。
你的模型通过了公平性审查。人口统计学平价（demographic parity）在可接受范围内，机会均等指标（equal opportunity metrics）看起来很干净，审计报告也被贴上了绿色的勾，进入了 Confluence。三个月后，一名记者拿出的屏幕截图显示，你的系统对某一人口群体的贷款批准率仅为另一群体的一半——而你发布前的那些数据在技术层面一直都是准确的。
这就是偏差监控的缺口。发布前的公平性测试是根据运行测试时存在的数据集来验证你的模型的。但在生产环境中运行的 AI 系统并不处于那种静态的世界中。用户行为会发生变化，人口分布会产生偏移，特征相关性会演变，而那些在发布时无法衡量的差异可能在几周内演变成严重的失效模式。能够捕捉这些问题的系统，在当今大多数 ML 技术栈中都是缺失的。
每位产品负责人都听过这个论调：更多用户产生更多数据，更好的数据训练更好的模型，更好的模型吸引更多用户。数据飞轮是复利护城河，这正是AI巨头们能够赢得市场的原因。
这个论调并没有错。但实施几乎总是出了问题。在实践中，大多数数据飞轮都有多个泄漏点——反馈循环看似在运转，实际上却在放大偏差、强化陈旧模式，或者优化一个与真实目标背道而驰的代理指标。构建这些系统的工程师很少知道自己遇到的是哪种泄漏，因为所有泄漏从外部看起来都一样：参与度上升，模型在可测量的指标上持续改进，而系统却在难以归因的方式下变得越来越没用。
这就是数据飞轮陷阱。理解其失败模式，是构建真正有效飞轮的前提。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
