第三方数据质量管理平台
数据质量管理平台3.0简介
龙石数据质量管理平台的核心思想，是以源头管控为手段，以绩效考核为抓手，建立数据质量评测、修复和考核的长效工作机制，为数据仓库建设保驾护航。
2024年1月
DQMIS|第三方数据质量管理模型和实践经验分享
2024年01月13日，龙石数据创始人练海荣在深圳"2024第七届数据质量管理论坛"发布并解读了第三方数据质量管理模型论坛聚焦数据质量行业趋势洞察与前瞻研判。
2024年1月
回顾《数据资产入表百家讲坛》|第三方数据质量管理实践分享
2024年7月4日，《数据资产入表百家讲坛》系列活动第十一期通过线上直播的形式召开。龙石数据数据质量业务总监杨毓慧女士在活动上分享了龙石数据针对数据质量的管理经验。
2024年7月
2024DAMA中国数据管理峰会|第三方数据质量管理模型和实践经验分享
2024年DAMA中国数据管理峰会于18至19日在深圳成功举办。龙石数据的创始人兼总经理练海荣出席并发表了题为“第三方数据质量管理模型与实践经验分享”的演讲。
2024年10月
文章动态
查看更多
DCMM 2.0背景下，数据质量平台和中台质量模块怎么选？
某企业数据治理项目立项，两份方案摆在了决策桌上：数据质量厂商推荐独立部署一套数据质量管理平台，数据中台厂商则说"中台自带质量模块，不需要重复采购"。预算有限，治理团队内部为此讨论了好几轮——质量团队担心模块能力不够深，中台团队担心重复建设。 这个场景在 DCMM 2.0（GB/T 36073-2025）[1] 实施后越来越常见。两类方案不是简单的"谁替代谁"，而是定位不同、能力边界不同、适用场景不同。选错带来的不只是预算浪费，后续治理的深度和运营方式都会受牵连。本文从六个维度给出对照框架，供读者结合自身情况判断。 一、DCMM 2.0 对数据质量的要求，先说清楚"要什么" DCMM 2.0 于 2026 年 7 月 1 日正式实施，在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析、数据质量提升[1]。注意一个容易被忽略的细节——"检查"只是四个环节之一。 这意味着标准要求的质量管理是一个体系，而不是一个检测工具。只看"能不能检测问题"，与标准要求的差距是比较明显的。从企业实践看，很多质量项目恰恰卡在这里：规则配了不少，告警每天在出，但问题认领、根因分析和流程改进长期缺位，质量问题反复出现。 在定义"什么算好数据"时，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 提供了起点：规范性、完整性、准确性、一致性、时效性、可访问性六个维度。六个维度除可访问性外，其余五个直接影响数据应用效果，也是质量需求定义时被引用较多的框架。 先谈标准，是因为选型的前提是明确目标：如果只是要"检测问题"，两类工具都能做到；如果要建的是覆盖需求、检查、分析、提升四环节的体系，评估重点就完全不同。截至 2025 年 11 月，全国已有超过一万家企业完成 DCMM 贯标评估[4]，贯标实践中数据质量域往往是差距较大的能力域之一，原因多半不是没有规则，而是规则与闭环之间存在断裂。另一个常被提及的判断是，数据质量是数据共享的第一前提——脏数据跨部门共享只会放大错误。 二、两类产品的定位差异 2.1 独立数据质量平台：质量为主业的"专精"型 独立数据质量管理平台把数据质量作为核心主业，能力围绕质量闭环展开：标准管理、规则创建、质量评测、问题闭环管理、质量评价。这类产品通常沉淀了可复用的规则资产——以龙石数据质量管理平台为例，内置标准库与规则库开箱即用，质量规则覆盖五大类，支持零代码可视化配置，采用旁路监测模式不侵入原始业务库，可应对百亿级数据量评测[5]。 更关键的是闭环深度：问题数据支持自动派发、源头修复、督办考核与审计追溯，全流程留痕。部分平台还提供 AI 智能评测，覆盖 DCMM 数据质量四个能力项、DAMA 数据管理知识体系与 GB/T 36344 的评价维度[5]。 独立平台的另一个特征是中立性。它以第三方视角开展质量评测，可以出具对外使用的评估报告，这在数据资产入表、数据交易挂牌、监管报送等场景中是硬需求。 2.2 数据中台质量模块：一体化治理中的"嵌入"型 数据中台质量模块是"理采存管用"方法论中"管"环节的子能力，与数据集成、标准管理、元数据管理、数据共享处于同一平台。质量不再是独立系统，而是随数据流转内嵌在治理链路里：数据标准定义了字段口径，质量规则校验数据是否符合标准，元数据记录了数据来源，质量结果又可以反馈给标准迭代。 其核心运行模式是旁路监测——数据正常入仓，质检规则并行扫描，发现问题打标记、发告警、生成整改工单，不拦截不阻断原有的数据链路。这种方式对业务系统无侵入，规则通过可视化界面配置，业务人员也可以参与。落标，即把已发布的数据标准关联到真实表字段上、检查实际数据是否符合标准，在中台里与标准管理模块天然联动。在多数中台产品中，质量规则同样支持完整性、准确性、一致性、时效性等多类检查，规则配置方式与独立平台类似，差异主要体现在规则资产的沉淀深度和问题闭环的组织方式上。 以龙石数据中台为例，质量模块作为"管"环节的一部分，随中台按需装配——可以单独启用，也可以与数据集成、标准、元数据等模块组合使用[5]。 2.3 两类形态的对照 对比项 独立数据质量平台 数据中台质量模块 定位 质量为主业的专精型系统 一体化治理中的嵌入型子模块 核心能力 标准-规则-评测-问题-评价全流程闭环 旁路监测 + 与集成/标准/元数据联动 规则体系 标准库、规则库沉淀与复用 常用质检规则，随标准管理联动 闭环深度 问题派发、源头修复、督办考核、审计追溯 检测、告警、工单、整改跟踪 中立性 第三方视角，可出具对外评估报告 内嵌于治理体系，服务于内部管理 部署成本 独立部署，需单独采购与运维 随中台装配，与现有平台共用底座 适用边界 全域多系统、规则复杂、需对外报告 中台数据域内治理、随中台统一运维 需要说明的是，上表按两类产品的通用形态归纳差异，供对照参考，不构成优劣结论——闭环深浅、规则体系强弱取决于各厂商的具体实现，两类形态均有深浅之分。以龙石为例，其独立数据质量管理平台与数据中台的质量模块在规则配置体验上保持一致，差异主要体现在标准库、规则库、问题派发与考核审计等深度能力是否具备。 三、六个选型维度：不预设答案的对照框架 六个维度只提供对照视角。每个维度先看"判断问题"，再看两类产品在该维度上的形态差异，最终由读者对照自身情况判断。 维度一：治理范围。 质量治理要覆盖哪些数据——仅中台、数仓内的数据，还是包括各业务系统源端、跨部门共享数据、对外交换数据？范围不同，工具的接入边界就不同：全域治理需要对接多个系统源端并统一管理；域内治理跟随数据汇聚位置即可。先画出质量工作的覆盖边界，再对照两类产品的接入能力。 维度二：数据来源复杂度。 数据源的数量、类型与异构程度，以及是否存在跨系统一致性比对需求——例如 CRM 与订单系统的客户信息是否一致、多系统指标口径能否核对。来源越复杂，对工具的接入广度、规则适配与联动能力要求越高；来源集中时，轻量方案即可胜任。政务场景中，华东某市监局的数据治理平台就包含跨系统的数据关联比对能力，用于核对同一主体在不同系统中的登记信息是否一致；华东某国控集团则在数据中台内配置了完整性、准确性、一致性、及时性、唯一性稽核规则，实现自动检测、异常告警、问题定位、整改跟踪的闭环——这两类场景考察的都是对多来源数据的处理能力，只是承载方式不同。 维度三：质量规则复杂度。 需要管理的规则分几个层次——基础完整性、唯一性检查，跨字段校验，时效性规则，以及业务自定义规则？DCMM 2.0 四个能力项意味着规则不止于"检测"；GB/T 36344 的六维度可以作为规则体系设计的起点。DAMA-DMBOK2[3] 将数据质量评估分为初始评估与持续监测两类，规则体系的组织方式同样可以参照这个思路。规则层次多、需要长期沉淀复用时，对规则引擎的独立管理能力要求更高；规则简单直接时，嵌入式方案也能覆盖。行业里一个常见的情形是，制造企业围绕物料、客户等主数据配置编码和校验规则，从几十条逐步积累——华东某电子制造企业的主数据治理就是这样起步的，规则能否沉淀、复用、演进，直接影响后续治理的边际成本。 维度四：组织模式。 质量工作由谁主导、向谁汇报？是否有专职质量团队或岗位，还是依托中台运维团队？组织上是否需要以独立于使用方的身份对外出具质量评估报告，用于数据资产入表、数据交易挂牌或监管报送？组织定位决定工具形态的适配性：需要第三方身份出具报告时，出具主体的独立性与资质是硬约束，需要向候选厂商确认；组织内统一运维时，模块化方式与现有体系衔接更顺。一个参照是，数据交易平台普遍要求上架产品经第三方质量评估并出具报告，江苏某数据交易所的挂牌流程即是如此——这类场景天然指向具备独立评测身份的产品或服务。 维度五：已有技术架构。 当前是否已有数据中台或数仓底座、技术栈是否统一？已有中台、且质量工作在其数据范围内时，模块化扩展的衔接成本较低；没有底座时，从质量平台起步的投入更轻，但需要与后续的数据架构规划一并考虑——如果企业计划建设中台或数仓，先上的质量平台能否与后续底座对接，值得提前确认。 维度六：长期运营方式。 质量工作如何长期运转——专职团队常态化运营，以月报、考核、审计追溯为周期，还是随中台统一运维？运营主体与考核机制一旦确定，工具形态应与之匹配。数据中台不是一次性项目，而是持续运营的能力平台；运营机制先于工具选型，是较为稳妥的做法。 需要强调的一点是：六个维度没有固定权重，关键是识别当前的主要矛盾是范围、规则还是组织机制。对照自查后，两类产品各有适配场景，不存在普适的"更强"。 四、场景画像与组合使用建议 按六个维度自查后，多数企业会落在以下典型情形。画像仅作匹配参考，不作优劣判断。 画像 A：独立质量平台更适配的情形。 治理范围覆盖全域、目前没有现成数据底座、规则体系复杂、需要第三方评估报告、由专职团队常态化运营。华东某数据局的数据质量管理服务是这类场景的典型：各委办局数据标准各异，跨部门协同困难，项目以"标准先行、监测常态化、修复闭环化"为核心，建立质量监测规则，问题纳入"质量监测→发现问题→派发工单→部门修复→复验归档"的闭环，并沉淀规则库与问题修复知识库[5]。华东某大数据中心则在此基础上，形成了"制度+标准+监测"三位一体的治理体系，以月为周期出具质量评估报告，规则库沉淀数千条，问题修复率超过九成[5]。这类制度化、运营化的质量工作，独立平台的组织成本更低。 画像 B：中台质量模块更适配的情形。 已有数据中台、治理范围集中在中台数据、规则以检测加告警为主、随中台统一运维。华东某国控集团是典型：中台内建质量稽核规则，自动检测财务填报错误、投资项目信息缺失等问题，自动预警、精准整改，质量管控与统一标准、主数据、资产目录在同一平台内联动。质量作为"管"环节的一部分嵌入治理链路，不需要单独维护一套系统的账号、权限和运维。 画像 C：组合使用。 两类产品不是非此即彼。常见做法是：中台模块承担日常旁路监测，独立平台或第三方服务承担专项评测与对外报告。例如日常监测发现的高频问题在中台内闭环处理，年度质量评估、入表前的质量核验等专项工作交给独立评测。组合使用的前提是先明确分工，避免两套系统重复配置规则。 起步建议。 如果预算有限、团队规模小，不急于一步到位，可以从一次免费的质量体检起步——市场上已有免费可用的数据质量工具，例如龙石数据质量管理平台·社区版，支持十余类质检规则，一条命令即可部署，先跑通"发现→修复→验证"的闭环，再依据体检结果定选型方向，按六个维度决定升级路径[5]。治理能力的建设是渐进的过程，先摸清家底再决定投入规模，通常比一步到位上重型平台更稳妥。 工具选型只是起点，质量能力的长期运转最终要靠组织与运营。龙石在交付工具的同时提供培训与陪跑服务，帮助客户团队自己掌握规则配置、问题分析和闭环运营的方法，实现从"厂商主导"向"企业自主运营"的能力转移[5]。这一点在评估长期运营方式维度时，值得一并纳入考量。 五、FAQ Q1：企业已经上了数据中台，还需要单独采购数据质量平台吗？ 没有标准答案，回到六个维度对照即可：治理范围是否超出中台数据、质量规则复杂度是否超出"检测+告警"、组织上是否需要独立出具报告——对照结果指向哪类，再决定是否单独采购。判断方法见第三节。 Q2：数据质量平台和数据中台质量模块可以一起用吗？会不会重复建设？ 可以组合使用，且组合是不少企业的实际选择：中台模块做日常监测，独立平台做专项评测和对外报告。关键在分工——日常规则在哪个系统配置、专项评估由谁出具、问题台账以哪边为准，先明确再采购，可以避免两套系统重复配规则。 Q3：预算有限、团队小，从哪一类起步更稳妥？ 可以先做一次免费的质量体检摸家底，以结果定选型方向——第四节起步建议中的社区版路径就是具体做法，部署快、规则覆盖常用场景，先跑通闭环再决定升级方向。 Q4：数据资产入表需要第三方质量评估报告，中台质量模块能出吗？ 关键在组织维度：对外评估报告对出具主体的独立性有要求，数据交易挂牌等场景也普遍要求第三方评估。是否由中台模块出具，取决于厂商的评测身份与资质能否满足要求，建议先与候选厂商确认，再对照第三节维度四判断。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 [2] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》 [3] DAMA International,《DAMA数据管理知识体系指南（第二版）》(DAMA-DMBOK2) [4] 中国电子信息行业联合会，DCMM 贯标统计数据（2025年11月） [5] 龙石数据，数据质量管理平台产品介绍，https://www.longshidata.com/products/quality.html
2026-08-14 15:05
高质量数据集怎么建？企业要先解决这五类数据质量问题
AI团队负责人找到数据团队："模型训练跑出来的结果不对，排查发现数据集里的客户姓名有空的、手机号格式乱的、性别字段有六种写法。这些数据你们不做检查吗？" 这位负责人的遭遇并非个例。很多企业在建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），国家标准化管理委员会 [4] 龙石数据质量管理平台（社区免费版），https://www.longshidata.com/community/products/quality-community.html
2026-08-14 15:03
龙石数据质量模块实战：配置一条完整的质量监控规则
一、场景钩子 业务部门的运营同事对着BI报表犯了难：上周出的客户分析报表，不同页面展示的客户数量对不上，营销部门据此做的短信推送要么发给了空号，要么漏掉了关键客户。追溯原因后发现，CRM（客户关系管理系统，Customer Relationship Management）同步过来的客户信息表中，联系方式字段空了1,200多行，手机号有800多条格式明显异常——有的8位、有的12位，还有的夹杂着座机号码。业务负责人直说："这数据谁敢用？能不能在数据入库的时候自动扫一遍，把有问题的找出来？" 这不是个别现象。企业数据中台每天汇聚多个业务系统的数据，源系统的录入规范、历史数据质量、接口传输稳定性，任何一个环节都可能引入脏数据。如果每一批数据都要靠人工写SQL去排查，效率低、覆盖面窄，而且查完这批下批又来了。更务实的做法是建立一套自动化的旁路监测机制——数据正常入库，质量检查并行扫描，发现问题的同时不阻断业务链路。配好几条规则，系统就能每天自动把问题数据标记出来。 二、前置准备：理解旁路监测 在动手配置规则之前，有必要厘清一个关键概念：旁路监测与强校验的本质区别。强校验模式在数据入库前执行检查，不合格的数据被拦截、无法写入。这种模式逻辑上没有问题，但在实际项目中风险很大——凌晨的ETL（数据抽取、转换、加载，Extract-Transform-Load）任务可能因为一条正则表达式配错而卡住整条数据管道，导致所有下游报表和业务系统当日无数据可用。旁路监测则采用不同的策略：数据正常完成入库，质量评测任务在入库后独立并行运行，扫描结果生成问题清单、触发告警或工单，但不阻断数据流转。这一设计符合DAMA（国际数据管理协会）DMBOK2（《数据管理知识体系指南》第二版）中"质量管理应优先保障业务连续性"的原则。 龙石数据中台的质量管理模块采用旁路监测模式——不侵入现有数据链路、不阻断数据入库、支持从发现到修复再到验证的完整闭环。龙石是DAMA大中华区实训基地，也是中国信通院《数据治理产业图谱3.0》入选厂商。 在确定监测模式之后，还需要一个衡量"什么叫高质量数据"的标准框架。GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个评价维度：完整性、准确性、一致性、规范性、时效性、可访问性。其中，除可访问性外，其余五个维度直接影响数据在业务中的应用效果，也是日常质量监控中最常配置规则的维度。下文的操作演示将依次覆盖完整性（字段是否为空）、规范性/准确性（手机号格式是否合规）、一致性（性别编码是否在标准字典范围内）三个核心维度。 三、操作步骤：配置一条完整的质量监控规则 以下配置以CRM客户信息表customer_info为例。该表每天从CRM系统增量同步到DW（治理层数据仓库，Data Warehouse治理层）中，业务要求自动检查三件事：客户姓名和手机号不能为空、手机号格式符合中国大陆手机号规范、性别代码必须在标准字典规定的取值范围内。以下八个步骤均可在龙石数据中台的「数据质量」模块中独立完成。 第一步：创建评测模型 评测模型是按业务域组织质检规则的容器，一个模型对应一个评测库，内部可挂载多个评测对象和若干条规则。进入「数据质量 → 评测模型管理」页面，点击"新增模型"，模型名称填写"客户信息质量评测"，评测库选择治理库（DW）。评测库的选择决定了后续规则扫描的数据范围，模型创建后若修改关联评测库，已配置的规则需要重新绑定——因此建议在创建之初就确认好评测库，避免后期返工。 第二步：添加评测对象 在新建的评测模型中新增评测对象，选择customer_info表作为被评测的数据表。被评测的表必须具备物理主键或逻辑主键。逻辑主键是指业务层面能够唯一标识一条记录的字段组合，例如客户编号、合同编号等——当数据库表中没有设置物理主键时，可以通过指定逻辑主键来确保每条问题数据可被精确定位。此外，还需要设置业务标识字段，指定一个业务含义明确的字段（如customer_name），这样在后续的问题数据列表中，每条记录会优先展示客户姓名，而不是难以辨认的技术ID，方便业务人员快速识别是哪条客户记录出了问题。 第三步：配置空值检查规则（覆盖完整性维度） 在评测对象下新增规则，规则类型选择「空值检查」，检查字段勾选customer_name和phone，检查方式选择"每个字段都不能为空"。这种规则解决的是"数据有没有"的问题——确保核心业务字段不缺失。配置规则参数时，有三项内容需要认真填写： 配置项 填写内容 说明 规则权重 高 客户姓名和手机号是营销触达的核心字段，缺失直接影响业务效果 错误描述 客户姓名或联系电话存在空值，影响客户画像生成、营销分组和短信触达 用业务语言说明什么问题、影响什么场景 修复建议 请核对CRM系统中对应客户的基础信息是否完整录入，补全后重新同步 给出可操作的具体步骤，而非仅描述状态 错误描述的撰写有一个实用原则：回答三个问题——什么数据出了什么问题（用业务语言而非技术字段名）、影响了下游哪个业务环节、应该怎么修。这条原则适用于所有规则类型的错误描述撰写。 第四步：配置格式规范性检查规则（覆盖规范性/准确性维度） 规则类型选择「格式规范性检查」，检查字段选择phone。格式规范性检查与空值检查的区别在于：空值检查回答"有没有"，格式规范性检查回答"对不对"。这里使用EL表达式（Expression Language，一种简单的表达式语言，用于在平台上进行轻量级规则配置，无需编写Java代码）来定义手机号的校验规则。在表达式输入框中填入： #phone REGEXP '^1[3-9][0-9]{9}$' 这条表达式的含义是：phone字段的值必须是以1开头、第二位为3到9之间的数字、后面跟随9位数字的11位手机号格式。EL表达式支持直接复制使用，配置完成后可先在页面上点击「表达式测试」输入几个样例值验证逻辑是否正确。规则权重设为"高"，错误描述写为"客户手机号格式不符合中国大陆手机号规范，影响短信触达和客户回访"，修复建议写为"请核对CRM源系统中客户手机号的录入格式，按11位手机号规范修正后重新同步"。 第五步：配置引用完整性检查规则（覆盖一致性维度） 规则类型选择「引用完整性检查」，检查字段选择gender（性别）。引用完整性检查又称字典校验，用于验证字段的取值是否在预先定义的标准字典范围之内。前提是数据标准模块中已经定义了"性别代码"标准字典：M代表男、F代表女。在规则配置中关联该字典后，系统会自动比对customer_info表中gender字段的每一个值是否在{M, F}的合法范围内。引用完整性检查的一个关键特性是：当数据标准模块中的字典定义发生变更时（如新增了"U=未知"的取值），所有引用该字典的质检规则会自动同步更新，不需要逐条手动修改。规则权重设为"中"，错误描述写为"客户性别编码不在标准字典范围内，影响客户分群和画像标签的准确性"，修复建议写为"请核对CRM源系统中对应客户的性别信息，按标准字典（M=男/F=女）修正后重新同步"。 第六步：抽检验证 三条规则配置完毕后，不要急于创建正式评测任务。先在评测模型页面点击「抽检」功能，系统会在评测表中随机抽取少量数据进行规则试跑，快速验证各项规则的参数配置是否正确。抽检结果会即时展示匹配到的问题数据数量和明细，如果发现误报（如格式正确的手机号被判定为异常），可以当场调整EL表达式或规则参数。这一步骤虽然简单，但能有效避免将规则错误留到正式评测时才发现。 第七步：创建评测任务并调度 确认抽检结果无误后，进入「评测任务管理」页面创建评测任务，关联刚配置的"客户信息质量评测"模型。首次执行必须选择手工触发——手动跑一次全量评测，逐条查看结果，判断是真实质量问题还是规则配置导致的误报。确认问题清单合理之后，再将执行策略切换为定时模式。平台支持四种执行策略：手工触发、定时执行（指定一个具体时间点）、重复执行（按固定间隔周期性运行）、Cron表达式（一种Linux系统中的定时任务表达式，支持灵活定义执行时间规则，如"0 6 * * *"表示每天早上6点执行）。日常运维推荐采用重复执行-按天策略，设置在每天早上6点自动扫描前一天的增量数据，与业务使用数据的时间窗口错开。 第八步：查看结果与问题闭环 评测任务执行完成后，进入「问题数据查看」页面，可以按评测主题、评测模型、规则类型、问题状态、发现日期等多个维度进行筛选和查看。每条问题数据会展示违规字段、违反的规则、当前实际值、发现时间、状态等信息。问题闭环的完整流程是：系统扫描发现问题数据→自动标记为"待处理"状态→数据责任人认领并推动源系统修复→修复后下次评测任务自动重新扫描→验证通过后状态自动关闭。整个闭环过程中，问题的产生、分配、修复、验证都有记录可追溯。 四、执行与结果 以上述三条规则对某客户数据仓库中的86万条customer_info记录执行首次全量评测，实际产出结果如下：手机号缺失4,200条（占比0.49%），客户名称缺失1,200条（占比0.14%），手机号格式异常800条（占比0.09%），性别编码不在标准字典范围3,500条（占比0.41%），四项合计问题数据9,700条，整体问题率约1.03%。这个结果说明即便在运行多年的业务系统中，数据质量问题也并非个例——百分之一的异常率在百万级数据量下就是近万条需要处理的问题记录。 每条问题数据都可以点开查看详情：哪个字段违反了哪条规则、当前的实际值是什么、问题发现于何时。修复完成后，下一次评测任务会自动重新扫描对应记录，验证通过后问题状态自动关闭。这种"发现-标记-修复-验证-关闭"的闭环机制，让数据质量治理从一次性的人工排查变成了持续运转的日常机制。 五、项目实战中的四个常见坑 坑一：规则越多越好——认为质量监控就是要把能想到的检查项全部配上。 这个假设忽略了一个基本事实：告警的价值取决于被关注和处理的程度。实际项目中常见的情况是，团队第一次使用质量模块时热情高涨，一口气配置了三四十条规则，覆盖了几乎所有字段。第二天早上打开系统，几千条告警扑面而来，团队花了两天时间也只处理了不到三分之一。到第二周，通知被静音，第三周，质量模块实质上已被弃用。正确的做法是：先选择一到两个核心业务域，配置三到五条覆盖面广、业务影响大的高价值规则（如客户姓名空值、手机号格式、订单金额范围），跑通"发现→认领→修复→验证"的完整闭环，团队适应了节奏之后再逐批扩展规则覆盖范围。 坑二：把低价值字段等同于核心字段——没有区分"应该检查的"和"值得检查的"。 并非所有字段的缺失或异常都会对业务产生同等影响。手机号缺失直接阻断营销触达，确实值得告警；但备注字段（remark）为空，本身就是一个可空的自由文本字段，对其配置空值检查只会制造噪音。区分方法很简单：面对一个候选字段，问一句"这个字段的值出错了，下游哪个具体的业务环节会受影响？"回答不上来的字段，大概率不值得配置监控规则。 坑三：规则刚建好就设定时任务——主观认为抽检验证通过就等于规则完美。 抽检只覆盖少量样本，无法完全暴露规则在大规模数据下的表现。假设团队周五下午配置了五条规则并完成抽检，顺手设定了"每天晚上0点自动执行"的定时策略，然后下班。周末两天，系统每天凌晨定时触发评测，产生数百条误报告警堆积在系统中，周一早上团队面临的是需要逐条甄别的混乱局面。正确的流程是：规则配置完成后，第一步手工触发全量评测，第二步逐条确认问题数据的真实性，第三步剔除误报并调整规则参数，第四步确认问题清单无异常后再切换为定时策略。 坑四：错误描述用技术语言写——认为"phone字段不满足EL表达式REGEXP"这样的描述足够清楚。 技术团队可能看得懂"phone字段不满足NOT NULL约束"，但业务部门看到这样的描述完全无法判断问题的严重性和处理优先级。即便是技术团队，也很难从"不满足REGEXP"中看出这条数据对业务的具体影响。正确的写法是用业务语言回答三个问题：是什么问题（"客户手机号格式不符合11位手机号规范"）、影响什么（"导致短信触达失败，客户无法收到营销通知"）、怎么修（"请核对CRM源系统中客户手机号的录入格式，按11位标准修正"）。好的错误描述应该让业务人员一眼看懂问题严重性，让技术人员立刻知道去哪里修。 六、小反转：真正难的，不是发现问题 按照上述步骤配置三五条规则，几十分钟就能让系统自动扫描出近万条问题数据。但真正棘手的事情在扫描完成之后才浮出水面。你标记了4,200条手机号缺失、3,500条性别编码异常，这些数据谁来补？客服部门说"这些历史数据是前任同事录的，跟我没关系"，IT部门说"源系统的录入校验我们加不了，那是业务系统厂商的事"，而业务部门说"数据质量问题不解决，我们的报表永远不准"。 大部分数据质量问题并非系统故障导致的，而是业务过程的产物——录入时图省事跳过了非必填字段、历史数据迁移时未做清洗、不同系统的编码规则长期不统一。质量监控规则能扫描出来的，往往只是冰山浮在水面的一角，水面之下还沉积着大量历史遗留的脏数据。 旁路监测的真正价值并不在于发现问题的能力——配几条规则就能做到的事，门槛很低。它的价值在于提供了一套持续推动问题修复的抓手：每周生成按来源系统分类的问题清单，明确"哪个系统产生的数据出了什么问题、影响范围多大、建议谁来修复"；用数据说话——"本季度CRM系统产生的质量问题占全量的67%，主要集中在客户联系方式缺失"——这比任何口头的"数据质量很重要"都更有推动力。质量管理最终要解决的，不是一次性的数据清洗，而是建立一种让问题能够回到业务源头并得到修复的能力。 七、附：十二类质检规则一览 上文以客户信息表为例，演示了空值检查、格式规范性检查、引用完整性检查（字典校验）三类质检规则的配置方法。龙石数据质量模块共内置十二类质检规则，全部支持可视化配置，无需编写SQL或代码。其余规则的使用方式类似——选择规则类型、指定检查字段、配置校验参数、填写业务化的错误描述与修复建议： 规则类型 用途 典型场景 空值检查 校验必填字段是否存在空值 客户姓名、手机号不能为空 数据缺失检查 检测数据归集或共享过程中的数据丢失 源库1,000条记录，目标库仅950条 唯一性检查 检测是否存在重复数据记录 同一个学号在表中出现两次 值域检查 校验字段取值是否在合理范围内 交易金额必须大于0、年龄在0-120之间 格式规范性检查 校验字段格式是否符合规范 手机号、身份证号、邮箱格式 引用完整性检查 校验字段值是否在标准字典范围内 性别只能是男/女、省份代码在行政区划字典内 一致性检查 跨表比对数据是否一致 CRM与订单系统的客户信息保持一致 逻辑检查 验证多字段之间的逻辑关系 毛利率是否等于（收入-成本）/收入 交叉比对检查 多表联合验证数据一致性 订单状态、出库记录、物流信息三方校验 SQL检查 通过自定义SQL实现深度验证 已发货订单的承诺送达日期是否逾期 关联关系检查 验证表间的引用关系完整性 每个员工有且仅有一张工卡记录 自定义扩展 对接外部API服务进行专项校验 调用第三方地址校验接口验证地址有效性 八、常见问题 Q&A Q1：旁路监测会影响数据同步的性能吗？ 通常不会。质量评测任务在数据同步任务完成后独立运行，与数据同步链路不争抢计算资源。对于千万级以上的首次全量扫描，建议使用过滤条件（如按日期范围或分区字段）限定评测范围，或采用分批评测的方式降低单次负载。后续的增量评测只扫描当日新增数据，性能压力远小于首次全量。 Q2：系统发现质量问题后，会自动修复数据吗？ 不会。质量管理模块的职责是发现问题和推动治理，而不是直接修改业务数据——擅自修改源数据可能引入更严重的业务风险。问题数据被扫描出来后，进入问题库并标注所属规则、当前值和修复建议。业务侧在源系统中完成数据修正并重新同步后，下一次评测任务会自动重新扫描对应记录，验证通过后问题状态自动关闭。 Q3：什么时候用旁路监测，什么时候用强校验？ 两者并不冲突，适用于不同场景。身份证号、统一社会信用代码等对数据准确性要求极高、且错误可能引发合规风险的核心字段，适合在入库环节采用强校验。客户信息、设备日志、业务标签等数据量大、更新频繁、个别脏数据不影响核心业务的场景，更适合旁路监测——既不让少数问题数据卡住整条数据链路，又能持续发现并推动修复。 Q4：规则配错了导致大量误报，怎么快速修正？ 评测模型管理页面支持对已有规则进行编辑和禁用操作。如果已经产生了大量误报告警，建议先使用「清除所有问题」功能清理垃圾数据，然后修改规则参数（如调整EL表达式或放宽值域范围），修改完成后重新手工触发全量评测进行验证。这也是第七步强调"首次执行必须手工触发"的原因——给规则留出验证和调整的窗口。 Q5：业务表新增了字段，已有规则需要重新配置吗？ 如果新增字段与已有规则无关，不需要任何改动。如果新增字段需要纳入质量监控，直接在对应的评测模型中新增一条规则即可，不需要重建评测模型或修改已有规则。评测模型的规则之间相互独立，支持按需灵活增减。 Q6：评测任务执行到一半失败了怎么办？ 在评测任务管理页面查看失败任务的执行日志，定位具体失败原因。常见的三种情况：一是数据库连接超时，检查网络连通性和数据库连接池配置；二是规则中引用的字段在表中已被删除或重命名，需要同步更新元数据中的表结构信息，然后修正规则中引用的字段名；三是EL表达式存在语法错误，回到规则编辑页面使用抽检功能提前验证表达式的正确性。 九、方法论收尾 数据质量管理的目标，并不是一次性把所有问题都清理干净——这在企业数据环境中几乎不可能做到。更务实的目标是：在不影响业务正常运行的前提下，让数据质量问题能够持续被发现、被跟踪、被修复。规则不在多，从一个核心业务域的三到五条高价值规则起步，跑通闭环之后再逐批扩展。这一思路体现了数据治理的核心理念：不是项目验收时的一次专项行动，而是融入日常运营的持续性工作。 龙石数据中台的质量管理模块正是围绕这一理念设计——旁路监测保障业务连续性、可视化配置降低使用门槛、闭环追踪推动持续改进。在实际落地中，江苏某大数据中心通过这套机制沉淀了超过5,000条质量规则，累计评测超10亿条数据，问题修复率达到95%；华东某数据局沉淀了1,000余条监测规则，问题修复率超过93%，数据目录合格率从6.34%提升至94.74%。 规则持续运行，质量持续提升——数据治理才能真正成为日常工作的一部分。 十、参考来源 GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 DAMA International，《DAMA数据管理知识体系指南》（DMBOK2），机械工业出版社 中国信通院，《数据治理产业图谱 3.0》，2024
2026-07-10 13:26
做 AI 之前，我建议先看一眼你的数据
AI 时代最贵的成本，不是模型采购费用。而是在错误数据基础上的反复试错。 做 AI 之前，先看一眼你的数据。花一两周做一次数据质量体检，可能会省下半年甚至一年的试错。这可能是整个 AI 项目中投入最小、回报最高的一步。
2026-06-16 10:22
为什么数据质量成为人工智能领域最重要的问题
简而言之：传统的基于人工编写规则和被动检查的数据质量体系，从未针对智能体人工智能进行设计。到2026年，当自主代理处理错误数据时，没有人会介入以发现问题。那些在人工智能领域取得成功的组织，并非从更好的模型入手，而是从构建数据信任层入手，该信任层能够在代理采取行动之前检测、修复并自我修复数据。这才是现代自主数据质量的真谛。 大多数组织都认为他们已经解决了数据质量问题。他们制定了一些规则，设置了一些检查机制，组建了数据治理团队并为其提供了一套框架。在很长一段时间里，这些就足够了。 这已经不够了。 如今大多数企业所处的数据环境与当初设计的数据治理框架所针对的环境几乎截然不同。十几年前，一个典型组织的数据来自少数几个ERP和CRM系统。结构化的表格，可预测的模式，范围可控，规则易于维护。理论上，一个人就能理解全局。 如今，平均每个企业管理着超过900个应用程序。每个应用程序都会生成数据。但它们之间大多无法有效通信。而几乎所有这些数据最终都应该流入企业领导层公开承诺、已列入预算并正面临交付责任的AI项目。 正是在这里，现代人工智能驱动的数据质量不再仅仅是数据团队需要关注的问题，而变成了业务连续性问题。 这些数字揭示了一个比大多数组织愿意听到的更残酷的真相。 Gartner 估计，平均每个组织每年因数据质量差而损失 1290 万美元。超过四分之一的组织报告称，每年损失超过 500 万美元，7% 的组织损失超过 2500 万美元。多年来，这些数字经常在董事会会议上被提及，通常是为了证明购买数据质量平台的必要性，然后就被悄悄地束之高阁。 到2026年，真正改变讨论走向的不是具体的金额，而是当下糟糕数据所造成的后续影响。 在传统的分析领域，人总是参与其中。一份报告显示数字错误，有人发现了，有人上报了情况。由于有人在问题扩大之前及时发现并处理，损失被控制在了有限范围内。 智能体人工智能彻底消除了这种缓冲。当自主智能体基于损坏的数据做出决策时，它不会停下来进行健全性检查，而是直接行动。它会配置错误的基础设施，触发错误的工作流程，并向客户提供错误的建议。而且，由于智能体以机器速度在深度互联的系统中运行，因此，在任何人意识到发生了什么之前，单个数据质量故障就可能蔓延到整个流程。 这是自动化数据质量基础设施在2026年需要解决的核心问题：不是为分析师发现错误，而是在客服人员采取行动之前就发现错误。 到2026年，全球人工智能支出预计将超过2万亿美元。每一美元的投资都取决于流经其中的数据质量。数据质量差不仅会降低人工智能的投资回报率，在智能体环境中，它还会造成大规模的危害。 我们一直以来衡量人工智能准备度的方式都是错误的。 57% 的组织表示，他们的数据尚未准备好用于当前或未来的 AI 应用场景。考虑到过去十年在数据基础设施方面投入的巨额资金，这一比例令人震惊。这不仅暴露出数据问题，也暴露出衡量标准问题。 大多数组织会从完整性、准确性和一致性三个方面评估数据质量。这些维度固然重要，但它们的设计初衷是基于最终用户是经过深思熟虑的人类分析师这一前提。对于自主人工智能系统而言，标准则截然不同，而且要高得多。 人工智能代理不仅需要知道某个字段是否有数据，还需要知道数据在上下文中语义是否正确，其值在相关数据点的背景下是否合理，数据来源是否可信，以及数据是否足够新，足以支持正在做出的决策。现代人工智能驱动的数据质量框架现在包括语义验证、跨源一致性检查、漂移检测和质量评分，这些功能可以告诉代理在特定时间点应该对特定数据源赋予多大的权重。 这是对质量的根本性不同定义，也需要采用根本性不同的方式来实现。 规则时代已经结束了 传统数据质量的根本问题在于：它的设计初衷就是被动的。人预先设想出某种故障模式，编写规则来捕获它，然后系统根据这条规则进行检查。这种模式在数据环境稳定、维护规则手册的人员能够及时应对变化时是有效的。 这两个条件都不再成立了。 如今，数据来自数百个来源，格式瞬息万变，并且被输入到原本设计时并未考虑互操作性的系统中。任何分析团队都无法快速编写规则来应对这种变化。任何静态的规则手册也无法预见数百个系统以始料未及的方式交互时出现的各种故障模式。 现代智能体人工智能数据质量的转变在于，它从人类定义的规则转向机器发现的模式。这体现在数据量、速度和分布方面的行为异常，以及由于数据集之间的关系从未被正式记录而导致的、任何规则都无法预料的参照漂移。此外，还体现在时间上的不一致性，这种不一致性只有在观察数据随时间推移的行为时才会显现，而不仅仅是观察其是否通过了某个特定时间点的检查。 当发现的模式与既定规则相结合时，质量系统便真正具备了自适应能力。它能够学习每个数据集的正常状态，检测偏离该基线的情况，并在不良数据到达任何处理环节之前及时上报。 举个具体的例子。零售平台的订单表应该反映美国数千个司法管辖区的准确州和地方销售税。这些税率不断变化。基于规则的系统可以对照已知表格进行核对。但是，如何才能在错误累积到数万笔交易之前，就发现新产品类别中税费计算错误的模式呢？这种检测需要行为建模，而不是规则匹配。 79%的AI代理未能投入生产环境的真正原因 近五分之四的企业已经以某种形式采用了人工智能代理。但只有九分之一的企业将其大规模地应用于生产环境。这一差距是2026年企业人工智能面临的核心挑战，而围绕这一挑战的大部分讨论都集中在模型成熟度、编排复杂性和人才短缺等方面。 这些都是真实存在的因素。但最容易被忽视的因素是数据信任。 智能体故障几乎总是上下文故障。语言模型或自主智能体需要的不仅仅是数据，还需要数据背后的上下文：这些值的含义、当前生效的定义版本、数据来源、数据经历了哪些转换，以及数据是否足够新，足以支持所请求的决策。缺少这些上下文，智能体就会产生错觉，获取错误的信息，并根据技术上有效但语义上错误的信号采取行动。 自愈式数据管道和自动化数据质量基础设施之所以引人注目，并非因为它们能减少数据团队的手动工作量（尽管它们确实能做到这一点），而是因为它们能够确保将自主代理安全地部署到生产工作流程中，并信任其行为。到2026年，那些在智能体人工智能领域取得成功的组织，并非因为它们拥有更优秀的模型，而是因为它们首先构建了数据信任层。 自主数据质量在实践中究竟是什么样子 现代数据质量管理方法并非每天早上由专人查看的监控仪表盘，而是一个持续运行的系统。该系统能够理解其处理的每个数据集的预期行为，实时检测偏离预期行为的情况，评估其对下游数据的影响，并自动进行修复，或者提供足够的信息以便人工快速处理。 到2027年，那些不优先考虑人工智能就绪数据的组织，在扩展全人工智能和智能体解决方案时，预计将面临15%的生产力损失。这并非是对数据质量的警告，而是对基础架构错误造成的累积性损失的警告，尤其是在构建于其上的系统不断扩展的情况下。 那些最终脱颖而出的组织，是那些将自动化数据质量视为基础设施，与计算和存储归为同一类，而不是将其视为与实际工作并行开展的项目的组织。 这就是转变所在。数据质量不再是补救措施，而是决定人工智能能否可靠运行的关键因素。 来源（公众号）：数据驱动智能
2026-04-02 10:03
专家解读 | 推动高质量数据集建设，加快实施“人工智能+”行动
文 | 中国信息通信研究院副院长 魏亮 习近平总书记指出，数据是数字经济时代的基础性资源、重要生产力和关键生产要素。近年来大模型技术不断取得突破，其中大规模高质量训练数据的投入，起到了关键作用，也进一步将“以数据为中心的人工智能”推向一个新阶段。 近期发布的 Deep Seek 系列模型训练中大量高质量推理数据集的使用更加凸显了高质量数据的重要性，而大模型要与垂直领域深度融合同样需要高质量数据集的支撑。国家数据局围绕高质量数据集建设相关工作开展了一系列工作部署。2025年2月19日，高质量数据集建设工作启动会在北京组织召开，国家发展改革委、教育部、科技部、工业和信息化部等27个部门参会。下一步，高质量数据集建设工作将积极推进落实“人工智能+”行动，加快推动形成一批标志性成果，赋能行业高质量发展。 01 准确认识高质量数据集建设取得的进展和面临的挑战 高质量数据集构建是一项复杂而关键的任务，需要了解模型应用场景和需求，进而开发、构建和维护数据资源，提供持续有效的高质量数据集。当前，在顶层设计层面，国家数据局等17部门联合印发《“数据要素×”三年行动计划（2024—2026年）》，强化场景需求牵引，带动数据要素高质量供给、合规高效流通，高质量数据集建设取得积极进展。在地方层面，湖北、江苏、浙江等多省市明确了建设高质量数据集的数量、时间及激励机制； 湖北省数据局发布首批10个高质量数据集，推动构建高质量“数据集市”；苏州市发布首批30个工业制造、交通运输、金融服务等高质量数据集。在行业层面，智源研究院发布全球最大的多行业中英双语数据集IndustryCorpus 1.0，包含3.4TB开源行业预训练数据，覆盖18类行业；中国信通院推出我国首个面向行业的人工智能数据集质量评估体系，为数据质量提供客观、公立的评价能力和方法体系；北京国际大数据交易所累计发布约300个高质量数据集，形成10余个应用领域数据资源地图。与此同时，还应看到目前高质量数据集建设还存在不少挑战。 一是政府和业界不清楚行业高质量发展需要什么样的数据。一方面，行业大模型数据具有需求多样性的特点。不同行业部门对模型场景数据的需求各不相同，涉及分析、决策和生成不同的任务需求，这种多样性要求在人工智能高质量数据集建设中，必须深刻理解业务场景。另一方面，行业大模型数据具有需求复杂性的特点。大模型涉及预训练、微调、反馈强化学习等不同阶段，不同阶段都涉及到数据训练构建和优化策略，需要多个数据源、多种数据类型融合对齐，这增加了数据处理和管理的复杂度。 二是行业企业不知道高质量数据集如何构建。构建大模型数据集主要包含数据采集、数据清洗、数据标注、质量评估等核心环节。各环节需要根据大模型数据集具有的规模大、多样性足、行业垂直属性强等特点进行针对性的技术研发和适配。但是，行业企业对于数据的理解程度不同，面向大模型的数据治理方法和经验不足，传统的数据处理工具和技术无法满足大模型需求，需要引入先进的数据处理技术和工具提高数据处理效率和准确性。 三是业界不了解行业数据集质量如何评价。不同行业、不同数据源的数据完整性和准确性可能参差不齐，严重影响大模型的训练效果和预测准确性，造成训练资源浪费。此外，训练数据获取往往需要耗费大量时间和经济成本，包括数据收集、清洗、标注等环节。在行业大模型的实际建设中，对于构建和采买的数据没有统一的衡量标准，造成无法有效获取高质量数据集资源。 02 分类推动高质量数据集供给体系建设 数据之于大模型就像石油之于汽车，汽车无法直接使用原油，原油只有经过一系列复杂的过程炼化成汽油后，才能给汽车使用。同样，海量原始数据需要经过“炼化”形成高质量数据集，才能真正有效地用于大模型训练。行业大模型训练所需数据集，既要覆盖行业通识，也要蕴含专门知识。其中，通识数据是通用大模型能力提升的基础，行业通识数据是行业大模型训练的基底，行业专业数据是企业推动行业大模型的应用、部署私域模型能力的底座。为此要根据急用先行、分类推进、合理使用的原则，推进高质量数据集建设。 一是加快通识类高质量数据集建设。通识类高质量数据集是指由政府机构、科研机构、开源社区或大型互联网企业等公开数据构建的数据集，具有广泛性和通用性，覆盖多个领域，如自然语言处理、计算机视觉、语音识别等，能够为企业提供丰富的训练资源和基准测试环境，有助于行业大模型快速验证算法、提升模型的基础能力。此外，公共数据集还有助于促进跨行业、跨领域的数据共享和知识融合，推动行业大模型的持续进步和快速发展。 二是加快行业通用类高质量数据集建设。行业通用类高质数据集，是指针对某一特定行业或领域知识的具有事实性数据集，具有高度的专业性和针对性。这类数据集通常包含某一特定行业特有的知识、术语、场景和业务流程等信息，对于训练出适用于行业应用的大模型至关重要，能够覆盖行业领域专业知识，提高模型在行业通识领域的泛化能力。 三是加快行业专用类高质量数据集建设。行业专用数据集，是指根据行业企业自身业务场景和需求收集的数据集。这类数据集通常包含行业企业内部业务流程、用户行为、产品信息等关键信息，具有针对性和定制化的特点，能够为行业企业提供高度个性化的训练数据资源，构建专属大模型。通过行业企业场景化数据集的训练，可以定制化地优化大模型算法和参数设置，深度挖掘内部数据价值，实现模型的定制化优化与业务高度适配，使其更好地服务于业务需求和发展战略，带来更加精准和有效的业务洞察和决策支持。 03 加快提升高质量数据集构建能力 推动高质量数据建设，是一项系统工程，核心是提升行业数据集管理与运营效率、提升数据集质量和数量、充分挖掘数据资源价值、保障模型数据安全可信，需要系统性地加强能力建设。 一是完善行业数据集管理体系。编制行业数据资源目录，细化数据集的分类与分级，明确结构化、半结构化及非结构化等多种数据类型，按照数据清洗处理程度（手动、半自动至全自动），开展数据集资源管理。构建高效协同的组织架构，确保从数据采集到模型应用的每一步都能够得到有效管理和支持，建立数据治理与模型开发的协同架构。围绕数据技术、平台、应用及安全，制定详尽标准，涵盖数据生产、服务、质量评估及数据集管理。培养跨学科、跨专业的数据工程团队，强化数据科学与模型训练能力，为大模型的成功部署与持续优化奠定坚实基础。 二是提升行业数据集开发维护能力。着力提升数据采集汇聚、数据预处理、数据标注等关键环节，以及指令微调、反馈对齐关键阶段的技术工具能力。数据采集汇聚需具备高效的数据抓取、清洗与整合能力，确保数据的全面性和多样性；数据预处理阶段涵盖数据清洗、去噪、归一化等技术，以提升数据质量；数据标注环节要求深入理解数据特性，掌握高效的自动化和智能化标注技术。行业大模型数据集主要应用于指令微调阶段和反馈对齐阶段，通过有标注的指令数据对模型进行精细化调整，增强其任务执行能力，利用用户反馈优化模型提升实际应用效果。此外，还需要制定详细的数据技术处理要求和方案，以保证不同阶段的数据分布一致性。 三是增强行业数据集质量控制。在质量管理方面，从流程管理、质量评估和组织规范三方面对大模型数据集生产到管理的各环节进行能力规范和等级评定，从源头上确保数据集高质量生产和管理。在质量评估方面，针对行业大模型对数据质量进行更多维度的要求，提升数据集在模型应用上的实用效果。设计具体规则和方法，采用自动化标注和人工抽样的方式对数据集自身质量进行前置检测，采用模型验证和消融实验的方式对数据集在大模型的应用效果进行后置检测，通过模型效果反馈进行数据集质量优化。 做实、做深、做细高质量数据集建设工作，就要深入贯彻落实党中央、国务院决策部署，做好系统谋划、加强统筹协调、做好部门协调。此次高质量数据集建设工作启动会，为推动相关工作发出了动员令、吹响了集结号。相信通过国家数据局协同行业主管部门的政策牵引和政、产、学、研、用多方协同，我国高质量数据集建设步伐将越来越快，也必将为人工智能赋能实体经济注入强劲动力。 来源（网站）：国家数据局
2025-03-13 10:12
