这位负责人的遭遇并非个例。很多企业在建AI数据集时，把"数据集"等同于"数据汇总"——把各业务系统的数据拉出来堆在一起就交付了。但数据集和原始数据汇总之间有本质区别：未经质量验证的数据投入模型训练，错误会被放大而非消除。GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个数据质量评价维度——规范性、完整性、准确性、一致性、时效性、可访问性，除可访问性侧重技术存取条件外，前五个维度直接影响AI应用效果。五类基础质量检查是高质量数据集建设的前提，但并非全部要求——数据集还需要在标准对齐、元数据标注等方面持续完善。
在这个方向下，市场上已有免费可用的数据质量工具。以龙石数据质量管理平台·社区版为例——作为信通院《数据治理产业图谱3.0》入选厂商和DAMA大中华区实训基地，龙石在这个领域已经有多个项目验证——它采用旁路监测模式：数据正常入库，质检规则在旁路并行扫描，发现问题后打标记、发告警，不阻断业务流程。社区版内置12类可视化配置的质检规则，覆盖五维质量评价，部署后即可对核心数据源进行系统的质量检测。以下操作均基于该平台展开。
一、前置准备：看清数据全貌
在开始配置质量规则之前，需要先让平台"认识"你的数据。这一步的核心是数据源接入和元数据管理——没有元数据，后续的规则配置和问题定位都缺少参照系。
1. 数据源接入
在社区版中接入业务数据库，填写连接信息后保存即可。平台支持MySQL、Oracle、SQLServer、PostgreSQL等关系型数据库，也兼容Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。接入时需确保数据源与平台服务器网络互通，连接池参数使用默认值即可，大数据量场景下可按需调整。
2. 元数据采集
数据源接入后，系统会自动创建元数据采集任务。点击"立即执行"后，平台同步当前数据库的最新表结构——包括表名、字段名、数据类型、长度、精度、主键、注释等信息。需要注意：每次表结构发生变更后，都必须重新执行元数据采集*，否则新增字段或变更的数据类型不会被后续的质检规则感知到。
3. 元数据维护
自动采集得到的是物理表名和字段名（通常为英文），需要为表和字段补充业务名称与业务描述。例如物理表 customer_info 补充为"客户基础信息表"，字段 phone 补充为"手机号码"。后续质量评测的规则配置和问题数据展示，都依赖这些业务元数据来提升可读性。
另外，被评测的表必须存在物理主键*（数据库层面定义的主键字段）或逻辑主键*（如果表没有物理主键，可指定一组字段共同作为唯一标识）。同时设置业务标识字段*——它决定了问题列表里优先展示哪个字段来代表"这是哪条记录出了问题"。
二、完整性保障：数据不能缺胳膊少腿
完整性是数据质量的底线。如果关键字段大量为空，后续所有分析、建模都失去基础。
典型场景*：CRM（客户关系管理系统）中客户姓名、手机号字段大量为空，AI模型训练时连"谁是客户"都搞不清楚；数据从源库归集到目标库后，发现丢了上千条记录——归集过程出了问题但无人察觉。
操作步骤*：
创建评测模型*：在"评测模型管理"中创建模型，命名如"CRM客户信息评测"，选择对应的数据库。
新增评测对象*：选择 customer_info 表作为评测对象，设置评测方式（全量同步）、逻辑主键和业务标识字段。
配置空值检查规则*：新增规则→选择"空值检查"→检查字段选 customer_name 和 phone→检查方式选"每个字段都不能为空"。规则描述可写为"客户姓名和手机号是客户身份的基础标识，不能为空"。
配置数据缺失检查规则*：新增规则→选择"数据缺失检查"→选择参照库和目标表→通过关联字段建立映射→检查归集前后数据条数是否一致。
DAMA-DMBOK将完整性列为数据质量的基础维度，DCMM 2.0（GB/T 36073-2025）数据质量域的"质量检查"能力项也明确覆盖完整性校验。从实践来看，完整性通常是企业数据质量问题中占比最高的一类，也是最适合作为质量治理起点的维度。
三、规范性保障：数据要能"对得上话"
如果说完整性解决的是"有没有"的问题，规范性解决的是"说不说得上话"的问题——不同系统对同一个信息的表达方式必须对齐。
典型场景*：同一个员工的性别字段，CRM写"M/F"，订单系统写"男/女"，BI报表里出现"0/1/未知"。三套系统三种口径，跨系统关联分析时直接翻车。
操作步骤*：
配置格式规范性检查规则*：使用EL表达式（EL是一种简单的表达式语言，平台用它来做轻量级规则配置，不需要写Java代码）校验格式是否合规。
手机号格式：#phone REGEXP '^1[3-9][0-9]{9}$'
身份证号、统一社会信用代码、邮箱等同理
配置引用完整性检查规则*（字典校验）：确保代码字段的取值在标准字典范围内。
性别代码引用标准字典（M=男/F=女）
注册状态、用户等级、合同状态等代码字段同理
需要注意：引用完整性检查引用的是数据标准模块的字典定义，空值不参与引用完整性评测*——这避免了"空值被当成字典外异常"的误报，让规则聚焦于"有值但值不对"的问题。
四、准确性保障：数据要"靠得住"
数据有值、格式合规，不代表它就是对的。准确性关注的是数据是否真实反映了业务现实——这是五个维度中最难检查但也最关键的一环。
典型场景*：销售流水表中出现了超出合理范围的金额记录（正常的退款冲销会产生负数，此处指明显的业务异常，如单笔金额远超合同上限）；财务系统中毛利率与BI报表的计算结果不一致——数据没有空值、格式也合规，但值本身就是错的。
操作步骤*：
配置值域检查规则*：限定字段的取值范围——交易金额必须大于0，库存数量不能为负数，年龄介于0-120之间。空值不参与评测。
配置逻辑检查规则*：用EL表达式或JAVA代码验证多字段间的业务逻辑关系。例如毛利率公式验证：
EL表达式：#orderAmount > 0（适合简单规则快速配置）
JAVA代码：适合复杂业务逻辑——如验证毛利率字段值是否等于(销售收入-销售成本)/销售收入
配置SQL检查规则*：复杂业务逻辑用自定义SQL深度验证——例如检查所有已发货订单，其实际发货日期是否不晚于承诺日期加3天。
五、一致性保障：数据要"对得上"
不同系统中存储的同一业务对象的信息应当一致。当CRM中的客户等级是"金牌"、订单系统里却是"银牌"时，跨系统分析的结果就失去了可信度。
典型场景*：同一个客户在CRM里客户等级为"金牌"，订单系统里显示为"银牌"；订单状态标记为"已发货"，但仓库无出库记录、物流无运单信息——存在矛盾的数据会让AI模型学到错误的关联模式。
操作步骤*：
配置一致性检查规则*：选择参照对象（如订单系统对应表），通过客户ID关联，检查客户等级、所在区域、联系方式等字段在两个系统中是否一致。空值不参与评测。
配置交叉比对检查规则*：多表联合验证——订单状态 vs 仓库出库记录 vs 物流运单信息，三者一致才算通过。交叉比对需要至少2个比对对象，且只有当评测对象与所有比对对象同时不一致时才标记为问题。
配置关联关系检查规则*：验证表间关系的完整性——每个员工有且仅有一张工卡（1:1关系），每个客户可以有多条订单记录（1:N关系）。
关联关系检查支持三种对应关系：1:1（一对一，如员工-工卡）、1:0-1（一对零或一，如员工-笔记本电脑）、1:N（一对多，如客户-订单）。
六、时效性保障：数据不能"过时"
数据完整、规范、准确、一致，但如果是半年前的快照——模型训练时上个月的新增客户完全没被覆盖，预测效果自然大打折扣。时效性检查的核心不是"有没有做"，而是先定义清楚"什么叫过时"，再通过调度持续执行。
定义时效规则：明确每张核心表的时效要求——
数据更新时间不得超过N小时/天
同步延迟不得超过M分钟
数据必须在业务有效期内（如合同数据不得超过合同截止日）
不同业务场景对时效的要求差异很大：交易数据可能是分钟级，客户主数据可能是天级，不能一刀切。
配置定时调度：定义时效规则后，通过评测任务调度持续执行。社区版支持四种执行策略：
首次执行建议：先用"手工触发"跑一次，确认规则无误且误报率在可接受范围内，再切换为重复执行——直接上定时调度可能会因为规则参数不合理而产生大量误报。
七、从检测到闭环：让质量问题能被管理起来
配置完规则只是开始——质量管理的目标是让问题能够持续被发现、被跟踪、被修复，形成可运转的闭环。
操作流程：
首次验证：先用"手工触发"跑一次，逐条确认问题数据是真的质量问题还是规则误报。如果误报率高，调整规则参数和过滤条件后再跑。
切换定时运行：规则验证无误后，切换为重复执行（按天），让质量检查成为日常自动化流程。
问题数据查看：在"问题数据查看"中按主题、模型、规则、问题状态（待修复/已关闭）、评测日期筛选问题。业务标识字段帮助快速定位"这是哪条记录出了问题"。
修复与复验：业务侧修改源数据后，下次评测任务运行时会重新检查该条记录——如果问题已修正，系统自动将状态更新为"已关闭"。
进度跟踪*：在"问题数据统计"中按层级查看各主题、模型、规则的问题数据量和修复率，跟踪治理进度。
数据质量管理的目标，并不是一次性清理所有问题，而是在不影响业务运行的前提下，让问题能够持续被发现、被跟踪、被修复。从一个核心业务域的三五条规则起步，跑顺畅了再逐批扩展覆盖范围。规则持续运行，质量持续提升，高质量数据集的建设才能真正成为日常工作的一部分，而不是项目验收时的一次专项行动。
附：五类质量问题 × 12类质检规则映射速查
上文第二至第六节演示了五类质量问题的核心规则配置方法，其余规则的使用方式类似——选定规则类型、指定检查字段、配置参数、补充描述即可。下表为完整映射速查：
12类规则中还包含唯一性检查和自定义扩展两类未在上述五类映射中展开。唯一性检查用于检测重复数据（如同一个学号出现两次），自定义扩展支持通过EL表达式/JAVA代码或对接外部API实现特殊校验需求。从多数使用经验来看，12类内置规则已覆盖绝大多数常见场景。
常见问题
Q1：部署社区版需要什么条件？
最低4核16G内存、100G磁盘，CentOS 7.9操作系统，一行命令10-20分钟即可完成部署。支持MySQL、Oracle、SQLServer、PostgreSQL及Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。
Q2：五类问题应该先解决哪一类？
没有适用于所有企业的统一顺序。如果当前最突出的是数据大量为空，就从完整性入手；如果跨系统口径打架最严重，优先做一致性和规范性。建议从一个核心业务域起步，每类问题先配置3-5条高价值规则，跑通闭环后再逐步扩展。
Q3：旁路监测会影响数据库性能吗？
质量扫描会消耗数据库资源，建议设置过滤条件限定扫描数据范围，并在低峰期（如夜间或周末）执行。首次全量扫描时如果数据量较大（千万级以上），用评测对象的过滤条件限定数据范围尤为重要。
Q4：规则配置后系统会自动修复数据吗？
不会。质量管理的职责是发现问题和推动治理，不是直接修改业务数据。问题数据进入问题库，标注清楚哪条记录、违反了什么规则、建议怎么修复。业务侧修改源数据后，下次评测任务运行时会重新检查该条记录并更新状态。
Q5：业务表新增了字段，规则需要全部重建吗？
如果新增字段不影响已有规则（比如只增加了备注列），现有规则不需要修改。如果新增字段需要纳入质量监控，直接在评测模型里新增对应的评测规则即可，不需要重建整个模型。同时不要忘记重新执行元数据采集以同步新字段信息。
Q6：12类规则之外还有特殊校验需求怎么办？
使用"自定义扩展"规则类型，支持通过EL表达式/JAVA代码或对接外部API服务实现定制化校验。不过从多数使用经验来看，12类内置规则已经覆盖了绝大多数常见数据质量校验场景。
数据集和原始数据的区别，在于前者经过了系统的质量验证。完整性让数据不缺失，规范性让数据可对话，准确性让数据不误导，一致性让数据不矛盾，时效性让数据不过时——这五件事做扎实了，模型训练才有可靠的信息基础。企业AI建设的瓶颈正在从模型能力转向数据能力，而数据质量的体系化治理，正是这个转型中最值得投入的一项基础工作。
参考来源
[1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家标准化管理委员会
[2] DAMA International,《数据管理知识体系指南》（DMBOK2，第二版）
[3] GB/T 36073-2025《数据管理能力评估模型》（DCMM 2.0），国家标准化管理委员会
