> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/data-readiness-ai.md).

# 2027 年企业 AI 数据就绪度：为什么多数试点在模型发挥作用之前就停滞了

本文整理自 Duaer 文档站，探讨企业 AI 落地中数据就绪度的含义、常见误区，以及如何针对单个用例进行五维度评估，帮助团队在投入预算前判断数据能否支撑 AI 应用。

## 什么是数据就绪度

许多企业已经购买了模型访问权限，也做出了聊天机器人演示，却仍然无法从自身系统中得到一个可靠的基础业务问题答案。问题通常不在模型本身，而在更底层：客户记录分散在三个系统里，合同条款以扫描 PDF 的形式保存，两个团队对「活跃客户」的定义不同，而且没有人知道哪份报表才是权威数据来源。数据就绪度，就是在投入预算之前先弄清楚你的数据能否支撑某个 AI 用例的一门方法。

AI 数据就绪度指的是：某个具体用例所需的数据是否可以访问，准确度是否足以支撑其所服务的决策，是否有清晰的描述，是否获得了该用途的许可，以及更新频率是否与工作节奏相匹配。关键在于「针对具体用例」。就绪度不是一个可以全公司通用、一次获得便永久保留的分数。财务团队可能已经准备好自动化发票匹配，而同一家公司在回答客户流失问题方面却远远没有准备好。

这种视角改变了切入的方式。不要问「我们的数据够好吗？」，而应该问「我们今天能否使用被允许使用的数据，在业务期望的时效内，回答这二十个真实问题？」这个问题是可以回答的，而第一个问题则不行。

## 为什么比看起来更难

企业数据很少只存在于一个地方。运营类事实保存在 ERP 中，客户互动保存在 CRM 中，支持历史保存在工单工具中，政策放在共享盘里，而最有价值的推理过程往往藏在邮件往来和会议纪要中。每个来源都有自己的标识符、更新周期和访问规则。把它们连接起来并不是技术上的小细节，而恰恰是大部分工作量所在之处。

试点阶段会掩盖这个问题。概念验证通常建立在一位积极的分析师用几周时间手工清洗好的数据抽取之上。当同一个用例走向生产环境时，就会直接撞上原始系统：重复记录、多年来一直是可选却从未填写的空字段、从未打过标签的文档，以及从未为机器读取者设计过的权限体系。演示之所以成功，是因为数据已被悄悄修复过；而生产环境没有这个修复步骤。

## 三个常见误区

第一个误区是「数据量等于就绪」。团队常常用数 TB 的存储空间或数千份文档来证明自己已经准备好了。数据量只能说明有材料可用，并不能说明这些材料是否及时、一致，或是否有明确的负责人。一个庞大但过时的制度档案，可能会让助手更加自信地给出错误答案。

第二个误区是「数据清洗是一次性项目」。组织安排一个清理冲刺，宣布胜利，然后随着新流程和新系统的出现，眼看质量逐渐下滑。就绪度是一种需要持续维护的状态，需要有负责人、刷新规则和定期检查，就像财务结账需要日历来管理一样。

第三个误区是「模型会修复杂乱的数据」。现代模型能够容忍一定程度的噪声，也能调和某些不一致之处，但它们更常见的情况是放大歧义，而不是化解歧义。如果两个部门对同一个术语的定义不同，模型给出的答案会显得流畅可信，却悄悄混合了两种定义。语义对齐必须在生成之前完成，而不是之后。

## 如何评估单个用例的就绪度

从选定一个具体用例开始，写下它真正需要的数据，而不是你希望它能够使用的数据。然后对每个必需的数据来源，在五个维度上打分，采用从 1（受阻）到 3（就绪）的简单量表：

1. 访问：该用例能否在技术上读取这些数据？是否有已记录的连接方式和指定的联系人？

2. 质量：完成任务所需的字段是否完整、足够准确、足够新鲜？抽取五十条记录并统计其中的失败数量。

3. 语义：关键术语是否有书面定义，使用它们的团队是否达成一致？

4. 治理：是否有数据负责人、清晰的权限模型，以及关于数据可在何处处理的合规立场？如果监管要求数据必须保留在某一边界之内，这一约束从第一天起就应纳入评分表。关于更广泛的前提条件，请参阅我们的指南[企业 AI 采纳所需的前提条件](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-requirements/)。

5. 反馈：能否衡量回答是否正确，并将修正意见回传到数据源头？

举一个具体的例子。假设销售团队希望有一个能回答供应商条款问题的助手。所需的数据来源包括合同文件、价格表和过往的争议工单。合同确实存在，但许多是没有元数据的扫描件，因此访问和质量得分都很低。价格表有两个版本，由不同小组维护，因此语义得分很低。争议工单结构良好，并有明确的负责人，因此得分很高。这个结果并不是要求放弃该想法的判决，而是一张地图，告诉你应该先修复什么，以及现在就可以在范围更窄的情况下先行试点什么。

用电子表格打分可以运行，但它往往在一个月内就过时了。希望让检查清单持续有效的团队，通常会把它迁移到共享工作空间中，让数据来源、负责人和差距备注都与用例绑定在一起。Duaer 是团队用于此类结构化就绪度追踪的平台之一，可与 AI 规划一同使用，让差距在试点获得资金之前就保持可见，而不是在演示之后才冒出来。如果你的数据来源分散在许多系统中，而当前的追踪工作散落在各种文档里，那么它值得一试。

## 知识助手需要先行做好就绪度

内部知识助手是最常被跳过数据就绪度工作的用例。诱惑在于直接把检索系统指向文档库，然后开始提问。结果通常是：答案来自过时版本的政策，或者来自彼此矛盾的重复文档，又或者来自那些没有任何人被授权在部门之间共享的文件。问答只是可见的那一层，其底下的治理和策展工作才决定它是否值得信赖。如果你正处于这种情况，我们的[企业知识库 AI 采纳指南](https://doc.duaer.com/zh/guides/enterprise-knowledge-base-ai-adoption/)解释了为什么数据工作应当先于问答界面。

## 持续衡量与本周行动

就绪度需要能够变化的指标来衡量。有用的指标包括：拥有指定负责人的必需数据来源占比；配有书面定义的关键术语占比；从数据源发生变化到其出现在 AI 可访问数据中所需的时间；为保持数据集可用，每周所需的人工修正次数；以及对一组固定的真实业务问题测试集每月重新运行时的通过率。应避免索引文档总数、存储总量之类的虚荣指标，因为无论数据是否可用，它们都会持续增长。

还应记录回答失败的原因。一份简单的日志，将每次失败标记为「数据缺失」「数据过时」「定义冲突」或「权限受阻」，就能告诉你应该把资源投向哪里。多数团队会发现，少数几种原因就占了大部分失败，这使优先级排序比一次全面的清理计划要容易得多。

本周可以做的一件事是：选定一个候选用例，搭建它的五维度评分表。列出用户会提出的十个真实问题，并针对每个问题检查所需数据是否存在、是否及时、是否有清晰定义，以及是否获准使用。为每个得分低于 2 分的数据来源指定负责人。这一周结束时，你将得到一份简短而诚实的清单，写明哪些已经就绪、哪些需要修复、哪些应当等待。对于决定从哪里开始，这份清单比任何模型基准测试都更有价值。

如果你希望用更少的人工开销完成这项评估，可以访问 https://www.duaer.com 注册，并在那里尝试搭建你的就绪度评分表。从一个用例和一组数据来源开始，并以它是否揭示出团队能够采取行动的真实差距来评判结果。

数据就绪度不是一道只需通过一次的关卡，而是持续进行的工作，它决定了 AI 的回答是否值得信赖。越早将它与一个具体的问题对应起来，你的试点就越早摆脱对手工清洗数据抽取的依赖。

## 常见问题

### 什么是 AI 数据就绪度？

AI 数据就绪度是指某个具体用例所需的数据，是否可以访问、准确度是否足以支撑决策、是否有清晰定义、是否获得使用许可，以及更新频率是否匹配业务节奏。它是针对单个用例的评估，而不是全公司通用的一次性分数。

### 企业 AI 试点为什么容易停滞？

试点通常基于手工清洗过的数据抽取来证明可行性，而进入生产环境后，会直接面对重复记录、缺失字段、未打标签的文档、分散的系统和未为机器读取设计的权限。演示时数据已被悄悄修复，生产环境却没有这一步，因此试点容易卡住。

### 如何判断数据能否支撑某个 AI 应用？

先选定一个具体用例，列出它真正需要的数据来源，并从访问、质量、语义、治理和反馈五个维度，以 1 到 3 分对每个来源打分。再用该用例的十到二十个真实问题进行检查。得分低的来源需要指定负责人并优先修复，得分高的部分则可以先行试点。