# 不是模型的错，是你的数据的错。 大多数 AI 项目都失败了——MIT 发现 95% 的生成式 AI 试点没有带来任何可衡量的利润，RAND 把总体失败率定在 80% 左右。出问题时，本能反应是怪模型：不够聪明、选错了、提示词不好。但数据说的是另一回事。被引用最多的失败原因是数据质量差，而只有大约 12% 的组织拥有干净到足以支撑 AI 的数据。你很可能根本不是模型出了问题，而是一个披着模型问题外衣的数据问题。下面教你怎么分辨。 - **Author:** Fedor Chishchin - **Published:** 2026-06-15 - **Tags:** architecture, methodology - **Source:** https://fedorthinks.com/zh/blog/it-wasnt-the-model-it-was-your-data --- 企业 AI 的失败数字残酷得值得大声说出来。MIT 的研究发现 [95% 的生成式 AI 试点对利润没有任何可衡量的影响](https://trullion.com/blog/why-95-of-ai-projects-fail-and-why-the-5-that-survive-matter/)， 而 RAND 把 [AI 项目的总体失败率定在 80% 左右](https://talyx.ai/insights/enterprise-ai-implementation-failure)。 大多数 AI 项目不是悄悄地表现不佳，而是直接失败。 每当这种情况发生，几乎所有人都抓住同一个解释：模型。我们选错了，它不够聪明，提示词不对， 该试试新版本了。这种本能让人安心，因为换一个就能修。它通常也是错的。AI 项目失败被引用最多的 原因根本不是模型—— [而是数据质量差，约 85% 的失败项目都点了它的名，而且首先只有大约 12% 的组织拥有干净到足以支撑 AI 的数据](https://talyx.ai/insights/enterprise-ai-implementation-failure)。 让我把这个道理讲清楚，因为这是一个真正有效的修复，和一年时间白白花在换模型上之间的区别。 ## 模型是看得见的那部分，所以挨骂的是它 当一个 AI 功能给出糟糕的答案时，你看到的是模型在出错，所以你怪的就是它。但模型是链条上的 最后一环，它最多只能和流进它的东西一样好。喂给一个出色的模型一堆零散、矛盾、过时、半数无法访问的数据， 它就会自信地输出胡话——不是因为它是个差模型，而是因为它忠实地反映了一个糟糕的输入。 这就是为什么换模型常常什么都改变不了。你从一个前沿模型换到一个更新的，演示依旧令人失望， 于是你得出结论说 AI「还没准备好」。而实际发生的是，你升级了唯一没坏的那部分。数据在换之前是 瓶颈，换之后仍然是瓶颈，因为新模型现在读的还是旧模型读过的那堆乱摊子。 ## 数据很无聊，所以这活儿没人愿意干 这种事不断重演是有原因的：修数据枯燥又看不见，选模型却刺激又快。选模型感觉像是进步——有排行榜、 有发布、有演示。而搞清楚你的数据住在哪里、它们意味着什么、是否还有效、系统能不能够到它们， 则是没有任何高光时刻的苦力活。于是团队做了有趣的那部分，跳过了真正决定结果的那部分。 数字也显示了跳过它的代价。Gartner 预计很大一部分 AI 项目会 [在 2026 年之前被放弃，原因恰恰是数据没有准备好](https://www.folio3.ai/blog/ai-project-failure-rate-stats)。 不是因为模型太弱——它们从未如此强大——而是因为它们底下那个不起眼的地基从来没有打好。 前沿一路飞奔向前，数据的管道却还停在原地。 ## 在怪模型之前该做什么 下次当一个 AI 项目交付不力时，在动模型之前先过一遍数据清单： - **数据准确且及时吗？** 如果来源错误或陈旧，更聪明的模型只会更快、更有说服力地给你错误答案。 - **系统真的能够到它们吗？** 被困在 PDF、数据孤岛和 AI 无法查询的系统里的数据，等于不存在。 能不能访问是一半的战斗。 - **它们的含义和你以为的一样吗？** 不一致的定义、重复项和缺失的上下文会悄悄地搞坏 AI—— 输出看起来合理，却在细微处出错。 - **然后才看模型。** 十有八九，你在走到这一步之前就已经找到了问题。 修数据又慢又不起眼。但结果恰恰就活在那里。 ## 底线 前沿模型非凡得很，而这恰恰是它们极少成为你 AI 项目失败原因的理由。薄弱环节几乎总是它们底下那 无聊的一层。 **在怪模型之前，先查数据——因为 AI 失败最常见的原因是输入，而不是智能。** 换模型是那种感觉很 高效、但通常并不高效的修复。清理你的数据是那种没人想干、却真正有效的修复。