> 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-ai-readiness-assessment.md).

# 2027年数据AI就绪度评估：开工前需要检查什么

本文整理自 Duaer 文档站，说明企业在构建AI应用前如何围绕单一用例评估数据就绪度，涵盖评估维度、评分标准、用例匹配与季度复盘方法。

## 数据AI就绪度评估到底衡量什么

大多数企业AI项目停滞，并不是因为模型不够好，而是因为背后的数据分散、标注混乱、难以访问，或者没有明确的负责人。团队买了平台，接上几个文件夹，然后才发现制度文件已经过时，产品规格同时存在三个互相矛盾的版本，也没有人能说清哪个系统才是权威数据源。数据AI就绪度评估的作用，就是在这些问题变成昂贵的意外之前把它们找出来。做得好的话，它能告诉你现有数据能否支撑某个具体的AI用例，哪些问题必须先修，哪些可以暂缓。

就绪度评估并不是对公司所有数据做一次全面审计。那样的做法通常要耗时数月，最后产出一份没人会读的报告。有用的评估范围更窄：它从一个明确的目标用例出发，例如回答员工关于人事政策的问题，或起草客户支持回复，然后判断该用例所需的数据是否可获取、准确、可访问，并且有明确的治理规则。

在实践中，多数评估会看六个维度：来源覆盖（相关文档或记录是否存在？）、内容质量（是否及时、一致、完整？）、结构化程度（能否切分、打标签、建立关联？）、访问与权限（AI系统能否在不违反内部规定的前提下读取？）、责任归属（谁批准修改，谁回答关于内容的问题？）、反馈闭环（系统出错时能否及时发现？）。

评估的输出应当是每个维度的一条简短、具体的判断，而不是一个笼统的总分。一个团队如果来源覆盖得分高、责任归属得分低，它面对的问题与一个责任归属清晰、但缺少来源的团队完全不同。

## 为什么多数就绪度检查抓不住重点

第一个常见错误，是把就绪度当成技术问题。团队会问数据仓库够不够现代，是否已经有向量数据库。这些问题以后会有用，但它们很少决定某个AI用例能否跑通。一堆架构良好的存储，如果里面装的是相互矛盾的制度文件，无论检索层做得多好，都会给出相互矛盾的答案。

第二个错误，是一次性评估整个公司。如果同时覆盖财务、销售、运营、法务和工程，就绪度检查通常只会变成一份笼统的差距清单。结果是大家都同意数据需要改进，却没有人真正开始。把范围缩小到一个用例，以及它实际涉及的三到五个数据源，评估通常能在几周内完成。

第三个错误，是把数据量等同于就绪度。大规模的数据资产看起来很有前景，但对大多数AI用例来说，几百份维护良好、责任清晰的文档，往往胜过一百万份无人管理的文件。就绪度取决于是否适合特定目的，而不取决于你拥有多少数据。

第四个错误，是跳过权限问题。很多团队直到后期才发现，他们想让AI使用的内容受部门、角色或地区限制。试点之后再补做访问控制，比一开始就梳理权限难得多。如果你身处受监管环境，在确定评分之前，值得先参考[企业AI落地的五项基础要求](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-requirements/)中的基线条件。

## 用清晰的标准为每个维度打分

只有当评分对每位读者的含义一致时，就绪度评估才有效。一个简单的四级量表就够用。一级表示数据缺失、分散或情况不明；二级表示数据存在，但不一致，存在多个版本，负责人不清；三级表示数据大体及时、有人负责，但标签、关联或访问规则尚不完整；四级表示数据及时、有人负责、已结构化、有权限控制，并且有监控。

以来源覆盖为例，测试标准很具体：列出目标用户实际会问的前二十个问题，逐一检查答案是否存在于有据可查的来源中。如果能从可指明的来源中回答的问题比例不足大多数，就说明覆盖存在缺口，再怎么调优模型也无法弥补。

以内容质量为例，可以随机抽取五十份文档，检查最后更新日期、文档之间是否相互矛盾，以及是否仍然描述现行流程。这项抽样只需一个下午，通常比任何工具生成的质量报告更能说明问题。

以责任归属为例，对每个来源问一个简单的问题：如果内容有误，修正工作由谁负责？如果答案是一个共享邮箱，或者根本无人负责，那么无论文档看起来多好，该项得分都不能超过二。

把每个分数连同一句说明理由和一位指定的修复负责人一起记录下来。这样，评估就从诊断变成了可执行的工作计划。

这一步也是实用工具可以发挥作用的地方。在搭建试点的同时，你可以在 Duaer 中完成同样的清点、抽样和责任映射，让就绪度结论与试点实际使用的知识库保持关联。它不能替代领域负责人的判断，但能把证据集中在同一个地方。

## 让就绪度与第一个用例相匹配

就绪度始终是相对于用例而言的。同一套数据，可能已经足以支撑内部搜索，却还不能用于自动化客户回复，因为两者对错误的容忍度不同。在确定分数之前，先明确目标用例中一次错误回答的代价。内部常见问题中的日期写错，只是小麻烦；而向客户提供错误的政策说明，则可能引发合规问题。

因此，就绪度应当直接指导用例选择。第一个用例最好满足以下条件：所需数据已达到三级或以上，错误代价可控，并且有指定的业务负责人审核输出。如果一个用例需要五个二级数据源，那它就不是试点，而是披着AI外衣的数据项目。如果你还在候选用例之间做选择，[基于治理数据构建知识库、再添加问答功能](https://doc.duaer.com/zh/guides/enterprise-knowledge-base-ai-adoption/)中的思路可以直接适用：先为一个狭窄领域打好数据基础，再逐步扩展。

## 长期衡量就绪度

评估只是某一时点的快照，而快照会过时。更有用的做法是按固定节奏重复评估，对于活跃用例，通常每季度一次。两次评估之间，要追踪三件事：优先数据源中有多少提升了一个等级；系统有多少问题是依据有据可查的来源回答，又有多少是靠猜测；用户报告错误答案的频率，以及根本原因属于数据问题还是模型行为问题。

最后这一区分很重要。如果多数错误答案可以追溯到过时或相互冲突的文档，那么就绪度问题依然存在，再做模型工作也无济于事。如果错误主要来自检索或提示词问题，而数据评分保持稳定，那说明数据侧正在改善，工程侧需要关注。

## 本周可以做什么

选定一个目标AI用例，列出它必须处理的二十个最常见问题或任务。针对每一个，确定应当提供答案的文档或记录，并标注该来源是否存在、是否及时、是否有负责人、系统是否可以访问。请在共享电子表格中完成，而不是在演示文稿里完成。到本周末，你就能判断这个用例是否就绪，哪两三个数据缺口在阻碍它，以及每个缺口由谁来修复。

如果你希望用自己的文档而不是假设的列表来运行这一流程，可以注册 https://www.duaer.com ，用一小批真实来源测试工作流。在投入更大预算推进全面部署之前，从一个用例和一小份试验数据集开始，是最快弄清数据是否就绪的方法。

数据就绪不是一次性通过的关卡，而是决定此后每一个AI决策能否被信任的前提条件。

## 常见问题

### 数据AI就绪度评估一般需要多长时间？

如果范围限定在一个AI用例及其涉及的三到五个数据源，评估通常可以在几周内完成。范围越宽，越容易变成一份无人执行的笼统差距清单。

### 如何判断数据是否适合作为第一个AI试点？

可以看三点：该用例所需的数据是否已达到三级或以上，即大体及时、有人负责；一次错误回答的代价是否可控；是否有指定的业务负责人审核输出。三者都满足，才适合作为试点。

### 就绪度评估应该包括哪些维度？

通常包括来源覆盖、内容质量、结构化程度、访问与权限、责任归属和反馈闭环六个维度。建议为每个维度单独给出判断和一句理由，而不是只给一个总分。