龙石数据·数据质量

一、登记之前有两道题："有什么"与"能不能用" 华东某交投集团花了几个月完成数据资产盘点，企业级资产目录建了起来，上千张业务表的来源、归属、边界都标得清清楚楚。目录交付那天，团队觉得登记入表的事已经八九不离十。真正进入环节时，会计师事务所提出的要求却让项目组卡了壳——请提供这些数据"能不能用、可信度有多高"的量化依据。目录回答不了这个问题，企业一时也拿不出来。 这个场景在登记推进较快的地区并不少见。资产盘点回答的是"企业有什么数据"——来源、归属、边界、目录；而登记、评估真正采信的，是"这些数据能不能用"——可信不可信、有没有量化依据。两类问题在流程上前后衔接，性质上却是两道独立的题。许多企业把精力放在第一道题上，到了第二道题才发现，数据质量没有可验证、可追溯的结论。 把第二道题补上的动作，就是登记前的质量验证。从政策节奏看，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）自 2024 年起施行，数据资源正式进入企业资产负债表[3]；国家数据局《"数据要素×"三年行动计划（2024—2026年）》推动数据要素在重点行业深度应用[4]；多地数据交易所对挂牌产品普遍要求提供第三方质量评估报告。确权、估值、入表、流通四个环节环环相扣，而每一个环节的推进，都以"数据可信"为背书：确权要说得清边界，估值要算得准基数，入表要经得起审计，流通要建立买方信任。质量验证正是这道背书的来源。 二、验证到底验什么：从 GB/T 36344 的六个维度说起 质量验证的第一个问题是：验什么？总不能用"凭感觉"来回答。目前国内通行、且被登记与评估机构普遍认可的评价框架，是 GB/T 36344-2018《信息技术 数据质量评价指标》[1]。该标准定义了六个质量维度：规范性、完整性、准确性、一致性、时效性、可访问性。六个维度除可访问性外，其余五个与登记、估值场景直接相关——可访问性更多对应数据共享与安全边界，在登记材料中通常由合规审核环节覆盖。 把六个维度放到登记场景里看，含义并不抽象： 规范性，看数据的格式、编码、口径是否符合统一标准。登记时常见的情形是"口径说不清"——同一指标三种算法，资产边界就无法界定。 完整性，看该有的字段和记录是否齐全。缺失的记录会直接影响资产范围和估值基数的测算。 准确性，看数值与状态是否与真实情况一致。错误数据一旦进入估值模型，评估结果就会失真。 一致性，看同一对象在不同系统中的描述是否统一。同一客户在不同系统里三个编码，登记确权和交易对账都会对不上。 时效性，看数据是否在需要的时间窗口内保持有效。把已经过期的数据纳入登记范围，入表价值经不起推敲。 可访问性，看数据能否被授权方顺畅获取和使用，登记、审计、交易各环节的取数是否可行。 维度落位之后，还要落成规则。验证不是对整体数据"拍一个分"，而是把每个维度拆解为可解释、可追溯的检查规则集：空值检查对应完整性，唯一性检查对应规范性，跨表比对对应一致性，时间字段校验对应时效性。规则本身要经得起评估机构复核——评的是哪张表、按什么规则、查出多少问题、如何计算得分，每一步都要有依据。 从标准体系看，质量验证在 DCMM 2.0（GB/T 36073-2025，2026 年 7 月 1 日实施）中同样有清晰的落位[2]。该标准的数据资产域设权属管理、价值评估、资产运营三项能力，是登记确权与资产运营的制度依据；数据质量域设质量需求、质量检查、质量分析、质量提升四项能力，恰是登记前质量验证的能力前提。登记是资产域的正式动作，质量验证是质量域的前置功课，两者在标准层面本就相互衔接。 质量维度与登记环节对应关系示意 质量维度 大白话 登记/评估中对应的典型问题 规范性 格式、编码、口径是否统一 口径不一致，说不清"这到底是什么数据" 完整性 该有的字段、记录是否齐全 记录缺失，资产范围与估值基数算不准 准确性 数值、状态是否与事实一致 错误数据进入估值模型，结果失真 一致性 同一对象跨系统是否统一 多头编码，确权与交易对账对不上 时效性 是否在有效时间窗口内 过期数据入表，价值经不起推敲 可访问性 能否被授权获取使用 登记、审计、交易环节取数不畅 注：并非严格一一对应，按登记与评估场景择要列出。 三、验证怎么验：从"查一遍"到一份可审计的证据链 维度与规则解决了"验什么"，接下来是"怎么验"。三个层次，层层递进。 规则怎么定。 按 GB/T 36344 六个维度定义检查规则，规则可解释、可复核，而不是"凭经验挑几个字段看看"。每条规则要说得清业务依据——为什么要查这个字段、判定标准是什么、查出问题意味着什么。 怎么查。 全量自动化扫描代替人工抽查。按规则集逐表逐字段体检，覆盖全量而非抽样，问题记录逐条标记、逐条定位。这一环节通常采用旁路监测方式：数据正常流转，质量检查在旁路并行扫描，不侵入业务系统，不影响在用系统的运行。 怎么出证据。 验证不是一次扫描就结束，而是"体检—修复—复验—监测"的闭环：扫描输出问题清单，问题清单按归属认领，责任方整改，整改后复验，通过后纳入常态化监测。每一步留痕，最终产出可审计的质量评价报告。报告包含评估范围、评估方法、各维度得分、问题明细与修复建议，评估依据和评分方法一并附上。 一句话总结：验证的结果不是"查过了"，而是一份"拿得出手、经得起查"的证据链。 市场上已有部分数据质量管理平台把六维规则、闭环管理和质量报告整合为一套体系。以龙石第三方数据质量管理平台为例，它按 GB/T 36344 六维内置质量规则，采用旁路监测方式不侵入业务系统，扫描结果可输出符合审计要求的质量评价报告，并可联合律师事务所、会计师事务所、资产评估机构完成登记、评估与入表衔接。 四、验证结果怎么支撑登记与评估：质量报告是"入场券" 验证结果在登记链条的各个环节都有明确落点： 登记链条环节 验证结果的作用 采信依据 登记确权 量化依据支撑"资产可信"声明，资产边界说得清 六维评分 + 问题清单 价值评估 评估机构基于可信数据测算，评分可复核 质量评价报告 入表核算 会计师事务所据此审计确认，合规风险可控 质量评分 + 整改记录 流通交易 交易所要求第三方质量评估报告，定价有依据 第三方评估报告 从数据资产化的整体路径看，这一步的意义更清楚。数据资产化通常沿"资源化—资产化—资本化"三步推进：资源化阶段把散落的数据归集、盘清，形成数据资源；资产化阶段完成登记、评估、入表，让数据获得资产身份；资本化阶段实现质押融资、流通交易等金融价值。质量验证正处在资源化向资产化转换的关口——没有可信的质量结论，资产化阶段的登记与评估就缺少立足点。 验证结果之所以能从"内部自查"变成"外部采信"，靠的是三个条件：一是标准框架，评价依据采用 GB/T 36344 等通行标准，而非企业自定义口径；二是可追溯，评分和问题均能回溯到具体表、具体规则、具体记录；三是可复核，报告附评估依据和评分方法，评估机构、审计机构可以按图索骥。 五、案例验证：质量报告如何成为登记、交易的"入场券" 回到开头的华东某交投集团。这家企业汇聚了大量城市交通、支付、用户服务数据资源，希望将符合条件的自有数据集纳入资产负债表。彼时它的处境与多数企业相同：家底刚盘清，但从未对数据做过系统性质量评估，不知道哪些数据"干净"、哪些存在缺陷，更无法量化可信度——会计师事务所要求可审计的质量依据，企业拿不出来。 在数据资产入表服务中，质量评价被作为独立环节推进：以 GB/T 36344 为框架设计评价标准与模型，对拟入表的数据资源做全量自动化扫描，通过问题清单协助修复与整改，最终输出《数据质量评价报告》。评价过程中发现并修复了订单状态不规范、时间字段偏差、支付渠道不一致等多类问题，质量评价总分达到 99.53 分（满分 100）。会计师事务所据此确认质量符合入表要求，企业完成首批数据资产入表，数据资产正式进入资产负债表[5]。这批数据由此具备了可量化价值，为后续开展数据资产质押融资等金融创新奠定了基础。 流通环节的惯例同样印证了这一点。某传媒集团开发了"城市运行事件分析服务"数据产品，计划在数据交易所挂牌交易。交易所要求上架产品必须经过第三方质量评估并出具《数据质量评估报告》，作为交易定价和买受人决策的依据。评估按产品形态与业务场景设计"一产品一方案"，产品评分从评估前的预估 85 分提升至 99 分以上，整改完成后成功上架并达成交易意向。客户的一句话很有代表性："质量评估报告让我们有了'体检单'，交易所认、客户信——这不是一张纸，而是一张进入数据要素市场的'入场券'。" 两个案例合起来，指向同一件事：质量可量化，登记才可信、评估才有据、交易才能定价。这也是"理采存管用"方法论中"管"的题中之义——质量管理的价值，不只体现在日常运维，更体现在资产化关口为数据"背书"。 六、FAQ Q1：资产盘点不是已经摸清家底了吗，为什么还要单独做质量验证？ 盘点回答"有什么"——来源、归属、边界、目录；验证回答"能不能用"——可信度、量化依据。登记与评估采信的是后者。盘点通常先行，验证跟进，两者在登记环节衔接，具体分工与衔接方式见第三节、第四节。 Q2：数据质量验证是不是跑一遍质检规则就够了？ 不是。验证是"体检—修复—复验—持续监测"的闭环，单一扫描只能证明"查过"，不能支撑"可审计"。闭环路径的具体做法见第三节。 Q3：中小企业登记数据资产，也要做这么重的质量验证吗？ 不需要全量铺开。较为稳妥的做法是选一两个核心业务域建质量基线起步，先把数据资产化路径跑通，再逐批扩展。如果只是想先做一轮摸底，市面上也有免费工具可用，例如龙石数据质量管理平台·社区版，部署后即可对核心数据源按 GB/T 36344 框架做质量检测。 Q4：质量验证的结果，登记机构和会计师事务所认吗？ 按 GB/T 36344 标准框架开展、可追溯、可复核的量化报告才会被采信。前述交投集团案例中，会计师事务所即依据质量评价报告完成入表确认。 结语 登记的制度框架仍在完善，各地推进节奏不一，但质量验证作为前置环节的分量只会加重：确权要边界清楚，估值要基数可靠，入表要经得起审计，流通要建立信任。把质量验证前置到登记之前，是让登记"经得起查"的较为稳妥的做法。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》 [2] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0），2026 年 7 月 1 日实施 [3] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号） [4] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [5] 龙石数据，第三方数据质量管理平台产品介绍，https://www.longshidata.com/products/quality.html

某制造企业的数据治理团队花了近三个月时间，梳理了核心业务系统的数据字段，配置了上百条质量校验规则。规则上线后，系统每天自动扫描出数千条告警——空值、重复、格式不规范，各种问题被逐一标记。 半年后，团队负责人复盘时发现了一个尴尬的局面：告警数量在涨，但真正被修复的问题并没有同步增加。治理团队大量时间花在了"判断哪些告警值得处理"上，业务部门觉得这些告警和实际业务问题关系不大。一位业务主管的反馈很直白："我们知道数据有问题，但你们发的那个报表我们看不懂，也不知道这些问题对我们的业务到底有什么影响。" 这个场景引出了一个数据治理领域容易被忽视的问题：配了规则就等于做好了数据质量管理吗？ 国家标准 DCMM 2.0（GB/T 36073-2025）[1] 给出了不同的视角。在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析和数据质量提升。注意，"检查"只是四个环节之一。这意味着标准在意的不仅仅是"能否检测到问题"，更是"发现问题之后有没有一套持续改进的机制"。 一、当"发现问题"本身成了新的问题 在许多企业的数据治理实践中，质量管理的推进路径高度相似：选一个核心业务域 → 梳理数据资产 → 配置质检规则 → 产出问题报告。到这里为止，逻辑是通的。但问题的分岔出现在下一步——报告产出了，然后呢？ 较为常见的情况是，规则越配越多，但闭环始终没建起来。具体表现为三种典型症状： 规则数量在涨，但实际被修复的问题没有同步增加。 规则从几十条扩展到几百条，每天产出的告警从几百条升到几千条，但真正被修复、被验证、被归档的问题占比很低。治理团队在"发现"这个环节投入了大量资源，但在"解决"这个环节上缺乏对等的投入。 治理团队变成了"告警分类员"。 当告警量超过一定规模，治理团队大量时间消耗在判断哪些告警值得处理上——优先级排序、影响范围评估、与业务部门反复沟通确认。这些工作有价值，但它们本质上是在弥补"问题管理流程缺失"带来的手动成本。 业务部门对质量告警逐渐麻木。 同类告警反复出现，每次处理后过一段时间又冒出来。业务部门最初的配合意愿在一次次的"反复"中被消耗——"反正都是那些问题，修了还会再出现"。 从 DCMM 2.0 的视角审视这种状态，实质上是把"数据质量检查"从数据质量域四个环节中孤立了出来——做了检查，没做需求定义、根因分析和流程提升。行业观察显示，大量企业数据质量项目因缺乏闭环管理机制而难以达到预期效果。这个判断的指向很明确：单点检测和闭环管理之间的差距，才是数据质量能力真正的分水岭。 二、DCMM 2.0 数据质量域到底在要求什么 DCMM 2.0（GB/T 36073-2025）在第 11 章专门定义了数据质量管理能力域，包含四个能力项。这四个能力项之间的顺序关系和逻辑关联，恰恰是理解"为什么不能只做检测"的关键。 能力项 核心问题 如果缺失会怎样 数据质量需求 什么算"好数据"？质量标准在哪？ 没有统一的判断依据，每个系统各自定义，跨部门口径不一致 数据质量检查 数据是否符合既定标准？ — 数据质量分析 问题的根因是什么？影响范围多大？ 同类问题反复出现，无法从源头根治 数据质量提升 怎么防止问题复现？流程怎么改进？ 治理停留在发现-修复-再发现-再修复的循环中 DCMM 2.0 将这四个能力项放在同一个能力域中，不是偶然。它们构成了一条逻辑链：先定义标准，再检查合规性，然后分析问题根因，最后推动流程改进。 这是一条完整的质量管理链路，缺少任何一个环节，整个链条都会断裂。 从实践中观察，最容易出问题的两个断裂点分别位于"检查之后"和"分析之后"。检查之后——很多企业的质量工作到"出了报告"就停止了，缺少问题认领、责任指派和修复跟踪机制。分析之后——即使做了根因分析，也缺少将分析结论转化为流程改进动作的推力，导致同类问题在下一次业务操作中再次出现。 这可以类比为医疗场景：量体温只是诊断的起点，真正的治疗需要结合化验分析、开处方、用药、复查，以及根据疗效调整方案。量了体温但不开药，或者开了药但不复查——这个医疗过程是不完整的。 作为补充参照，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 从数据本身的特性出发，定义了六个质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。在制定数据质量需求（首个能力项）时，这个六维框架可以作为定义"好数据"标准的起点。 三、从检测到闭环：八个关键环节 DCMM 2.0 数据质量域的四个能力项提供了顶层框架，但落地到日常运营中，还需要更细颗粒度的操作步骤。从企业实践来看，较为有效的做法是将四环节展开为八个可操作的关键步骤： 标准定义 → 规则配置 → 评测 → 发现 → 认领 → 整改 → 复核 → 改进 这八个步骤环环相扣，以"改进"节点反馈到"标准定义"，形成持续优化的闭环。逐一来看每个步骤的定位： 标准定义是整个闭环的起点。它回答的是"什么是好数据"——哪个字段不能为空、哪个取值范围是合理的、哪些跨表数据需要保持一致。标准不是凭空制定的，需要基于业务规则、行业规范和监管要求来确立。行业实践中，业务规则的显式化定义也普遍被视为质量管理的首要步骤。 规则配置将标准转化为可自动执行的质检规则。这一步的关键在于让业务人员能够参与配置而非全部依赖 IT——业务部门对"什么是异常数据"有最直接的经验，但如果没有低门槛的配置工具，这个经验就无法转化为规则。 评测是运行质量扫描、生成问题报告的环节。采用旁路监测模式（数据正常入库，质量检查在旁路并行扫描）可以确保不阻断业务流程。DAMA-DMBOK2[3] 将数据质量评估分为初始评估和持续监测两类，评测环节承担的正是在不中断业务运行前提下的常态化监测职能。 发现将扫描结果提炼为可操作的问题项——不仅要标出"哪张表有异常"，还要精确到"哪个字段的哪些记录有问题"，标记字段级根因，为后续的认领和整改提供明确目标。 认领将问题推送到责任部门或责任人，明确整改期限。这一步在整个闭环中看似简单，却是最容易断裂的环节。如果问题没有明确的责任归属，前面的检测工作就全部悬空。 整改是对问题数据的实际修复。这一步经常是整个闭环中最脆弱的环节——涉及跨部门协同、业务系统操作权限和生产环境影响评估。如果整改动作长期未被跟踪和督促，闭环就是名义上的闭环。 复核在整改完成后自动复扫，确认问题确实被修复，而非被临时遮盖。这是对整改质量的验证，也是闭环"闭"起来的标志。 改进将高频问题归类，追溯系统性根因，反向优化质量规则和业务规范。例如，如果某类格式错误在三个月内出现了二十余次，不仅需要修复当前数据，还需要检查录入界面的校验逻辑是否缺失。 观察这八个步骤可以明显看到：检测（评测 + 发现）只是八步中的两步。后面的认领 → 整改 → 复核 → 改进才是质量闭环的核心价值所在。 单纯追求检测规则的覆盖率，而忽视闭环的完整性，从长期来看是投入产出比不高的做法。 市场上已有部分数据治理平台将这八个环节整合为可在线流转的闭环体系。以龙石数据质量管理平台为例，它将标准管理、规则配置、质量评测、问题分析和整改闭环串联在同一系统中——从标准到规则、从规则到扫描、从扫描到工单、从工单到复验归档，每一步都在同一平台上完成，避免了"系统A发现问题→线下沟通→系统B处理"的信息断裂。 四、以华东某电子制造企业为例 闭环的价值，在实际业务场景中看得更清楚。 华东一家中大型电子制造企业，日常运转依赖 ERP、MES、WMS 等多个业务系统。随着业务规模扩大，三个环节的数据问题逐步暴露：一是跨部门协同——同一个物料在研发、采购、仓库三个部门的系统中有不同的编码和名称，每次跨部门对账都是一场"翻译"；二是经营指标口径——财务和运营部门对"产值"的计算逻辑不同，月度经营会上管理层经常要先确认"以哪个数字为准"；三是报表周期——经营分析报表依赖人工从多个系统取数、手工汇总，一个完整的月度报告需要数天时间。 从数据层面看，根因集中在三个方向：主数据缺少统一编码和管理机制、数据标准缺失、以及数据质量问题缺乏闭环——业务人员虽然经常发现数据错误，但缺乏系统化的规则配置和问题追踪机制，同类问题反复出现。 企业在明确方向后，分四个阶段推进数据治理建设： 第一阶段：摸清家底。 从物料、客户、供应商等核心业务对象入手，逐一盘点各系统中的存量数据，识别重复、缺失和不一致问题。这一阶段产出了一份完整的数据质量评估报告，让管理层第一次看清了数据治理的起点在哪里。 第二阶段：建标准、立规则。 统一了多类核心主数据对象的编码规则，制定了数十项校验规则，明确了数据录入、审核和维护的权责边界。 第三阶段：系统对接与质量治理。 将核心业务系统的数据接入统一数据底座，配置质量检核规则，对已识别的百万级物料数据进行清洗去重。 第四阶段：服务化落地。 建设经营指标看板和数据服务门户，覆盖多个业务部门。在这个阶段，数据质量的闭环机制初步成型——系统自动扫描质量问题，定位责任部门，生成整改工单，修复后自动复验。 闭环带来的效果是直接的：核心物料数据重复率大幅压降，采购、生产和财务终于用上了"同一本账"；经营报表的生成周期从数天压缩到小时级；跨部门数据口径差异基本消除。更重要的变化在组织层面——各部门开始主动关注数据质量，不再把"数据不准"当作别人的问题。 这个案例的一个关键启示在于：质量规则要配闭环。发现数据问题不是终点——配置规则、自动检核、推动责任部门整改、跟踪处理结果，这个闭环跑通了，数据质量才能持续改善。企业最初面临的问题并非"检测不到问题"，而是"检测到了问题却没有有效的处理机制"。 五、从"能做到"到"能持续" DCMM 2.0 的五级成熟度模型为质量闭环的推进提供了一个清晰的进阶参照。 在 L2"受管理级"，数据质量管理通常在部门层面推进，规则是配了，但修复主要靠人工协调和催促。在 L3"稳健级"，组织建立了统一的质量管理体系，问题能被系统地发现和记录，修复有流程支撑。在 L4"量化管理级"，闭环数据可量化——平均修复时长、问题复发率、规则有效覆盖率等指标成为衡量质量能力的关键参数，标准要求在此阶段"引入人工智能等先进技术"[1] 驱动效能提升。 从大多数企业的实际情况来看，较为稳妥的做法是先从核心业务域做起。选三五个最痛的数据表，配十几条核心规则，把"发现 → 认领 → 整改 → 复核"的闭环先跑通，再根据运行数据逐步扩展覆盖范围和改进节奏。这种方式投入可控、见效快，也更容易获得业务部门的认可和支持。 对于那些希望先摸清数据质量现状再决定投入规模的企业，市场上已有免费可用的数据质量工具。例如，龙石数据质量管理平台·社区版覆盖了 GB/T 36344 标准定义的核心评价维度，支持空值检查、唯一性检查、值域检查、一致性检查等十余类质检规则，可以通过一次快速的部署获得一份系统化的数据质量体检报告。 截至 2025 年 11 月，全国已有超过一万家企业完成了 DCMM 贯标评估[4]。在贯标实践中，数据质量域往往是差距最大的能力域之一——不是因为企业没有质量规则，而是因为规则和闭环之间仍然存在断裂。从"能做到检测"到"能持续改进"，这一步的距离，正是 DCMM 2.0 数据质量域的核心关切所在。 六、FAQ Q1：我们已经有几百条质量规则了，为什么 DCMM 评估还是说我们的质量域不够？ DCMM 2.0 的评估看的不只是规则数量，而是质量管理的闭环机制。数据质量域的四个能力项——质量需求、质量检查、质量分析、质量提升——需要每个环节都有可验证的证据链支撑。有规则但缺少需求定义文件、有问题记录但缺少根因分析和提升记录、有整改但缺少复核验证，这些都会影响评估得分。换句话说，评估关注的是"管理"而非"工具"。 Q2：旁路监测会不会导致问题数据已经流入下游才被发现？ 旁路监测的执行延迟取决于数据量、调度频率和数据库性能，可根据业务时效要求配置执行频率。对于时效性要求极高的场景，可以在关键链路上配合前置强校验。在实际部署中，大多数企业场景下旁路监测的延迟在可接受范围内——质检结果在下一次调度周期（通常为数分钟到数十分钟）即可产出，不影响正常的业务数据流转。 Q3：闭环管理需要多大的组织投入？ 闭环的核心是责任机制，不是人力投入。关键是把三步跑通：问题能推送到具体责任人、整改有明确期限、修复后有复验确认。在平台支撑下，不一定需要新设独立的数据质量团队——但必须明确质量负责人、数据责任人和整改流程。从组织角度来看，把质量责任嵌入现有的数据管理和业务操作流程中，比新建一个专职团队更为可持续。 参考来源 [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年，江苏省持续推进高质量数据集先行先试和试点建设，越来越多的企业开始从"数据治理"走向"数据集交付"。但一个基础问题始终绕不过去："高质量数据集"中的"高质量"，究竟由谁来定义、谁来记录、谁来验证？ 答案指向三个基础设施能力——数据标准、元数据和数据质量。需要说明的是，三者并非高质量数据集建设的全部。数据安全与合规、数据来源与权属、标注与加工、版本与生命周期管理等同样重要。但数据标准、元数据和数据质量构成了数据可信、可理解和可验证的关键基础——没有这三者，其他工作就缺乏可靠的起点。 三者在日常工作中经常被并列提及，但它们之间的关系远比"三个模块各管一摊"复杂。数据标准负责规定数据应该是什么，元数据负责解释数据是什么、从哪来、如何加工，数据质量负责判断数据是否符合要求。关键在于：三者不是孤立的，而是一套从规则定义、落标映射、质量检核到反馈优化的闭环机制。 一、各自定位：标准、元数据、质量分别解决什么问题 1.1 数据标准：规定"应该是什么" 数据标准为数据提供统一的命名、格式、取值和口径规则。它的核心产出不是一份文档，而是一套可执行、可校验的规范。 从国家标准框架来看，DCMM 2.0（GB/T 36073-2025）[2]在数据标准域（第10章）中定义了五个能力项：业务术语、主数据、参考数据、数据元、指标数据。这其中，业务术语和指标数据与高质量数据集建设的关系尤为密切——前者统一"同一个业务概念叫什么"，后者统一"同一个指标怎么算"。 在高数据集建设中，数据标准扮演的角色可以理解为"尺子"：它提供了判断数据是否合格的基本依据。如果没有这把尺子，质量检查就失去了参照系——你不知道"准时交付率"应该按订单创建时间算还是按发货确认时间算，自然也就无法判断数据是否准确。 1.2 元数据：解释"是什么、从哪来、如何加工" 元数据是描述数据的数据。它分为两个层面：技术元数据记录表结构、字段类型、数据量等技术属性；业务元数据记录字段含义、计算口径、数据来源等业务属性。两者共同构成了数据资产的"说明书"。 在标准框架中，元数据管理归属于 DCMM 2.0 的数据架构域；在 DAMA 数据管理知识体系（DAMA-DMBOK2）[3]中，元数据管理是第12章，与数据质量管理（第13章）相邻。这种安排本身暗示了两者之间的紧密关联。 元数据在高数据集建设中的独特价值在于：它是连接标准和质量的桥梁。标准定义的是"应该怎样"，元数据记录的是"实际怎样"——两者的差异就是治理工作的直接对象。 1.3 数据质量：判断"是否符合要求" 数据质量不是简单地说"数据好不好"，而是对数据的符合性和可用性进行系统评价与改进的机制。GB/T 36344-2018《信息技术 数据质量评价指标》[1]定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度构成了质量评价的核心框架。 DCMM 2.0[2]在数据质量域（第11章）中进一步定义了四个能力项：数据质量需求、数据质量检查、数据质量分析、数据质量提升。这个序列本身就是一条从"发现问题"到"解决问题"的闭环路径。 在高数据集建设中，数据质量扮演的角色可以理解为"定位器"：它发现问题，但不会止步于发现问题——它需要借助元数据的血缘关系追溯到问题的源头，再回头检视标准的定义是否合理，从而推动整个治理链条的运转。 二、协同关系：标准、元数据与质量如何形成闭环 三者之间的关系不是简单的线性接力，而是一组双向或多向的咬合。以下从四个方向展开分析。 2.1 标准→质量：标准是质量的判断依据 这个方向的关系最直观，也最容易理解。质量检查的核心逻辑是"将数据现状与标准定义进行比对"——标准规定字段"订单金额"应为正数且保留两位小数，质量检查就按照这个规则扫描所有相关字段，标记不符合的记录。 反过来看，如果标准缺位，质量检查就会陷入"无尺可量"的困境。华东某电子制造企业在数据治理过程中就遇到过类似情况：ERP、MES、WMS三个系统各自维护自己的物料编码和指标口径，同一个"准时交付率"在不同系统中计算方式不同，质量检查根本无从下手——不知道该以哪个系统的定义为准。标准统一之后，质量检核规则才有了明确的参照。 2.2 标准↔元数据：从规范定义到字段落标 这个方向的关系容易被简化为单向——以为定义了标准，元数据就会自动对齐。实际情况是双向的。 标准→元数据方向：标准需要通过元数据落实到具体的表、字段和系统。一份标准文档定义"客户编码为10位数字"，元数据的任务是将这个定义映射到 CRM、ERP、订单系统各自的客户编码字段上，形成可执行的落标映射关系。 元数据→标准方向：元数据同时反映标准的落地情况和执行差距。如果元数据显示某个系统中的客户编码字段实际长度为12位且包含字母，说明标准未被有效执行——元数据在此时充当了"差距发现者"的角色。 标准变更后的流程更为复杂。变更不只是改文档——需要先通过元数据映射识别受影响的系统、表和字段，然后逐系统评估变更影响、制定调整方案、推动数据改造，最终更新元数据记录和同步调整质量检核规则。这个过程不会自动完成，需要治理机制来推动。 2.3 元数据→质量：元数据为质量问题定位根因 质量检查发现问题后，真正有挑战的工作是"定位根因"。一个字段的空值率超标，可能来自上游系统的录入规范缺失，也可能来自归集流程中的转换逻辑错误，还可能来自多个系统数据合并时的口径不匹配——不确定根因，修复往往是盲目的。 元数据的血缘关系在此时提供关键信息。通过解析数据从源系统到数据集的完整加工链路，可以定位到问题发生的具体环节。更进一步，元数据的影响分析能力可以评估修复某处问题可能波及的下游范围——哪些报表、哪些数据集、哪些AI模型使用了这个问题字段。这种追溯能力让质量问题的处理不再是"头痛医头"。 2.4 质量→标准：质量反哺标准迭代 这个方向的关系最容易被忽视。在实践中，持续积累的质量问题往往会暴露出标准的不合理之处。 一个典型的场景是：质量检查反复在某个字段上发现问题，经过根因分析后发现不是数据录入的问题，而是标准本身的定义脱离了业务实际。比如标准要求"客户等级"分为"大/中/小"三级，但业务运营中已出现了第四类客户形态。在这个反馈下，标准的迭代是必要的。 另一方面，质量的持续改进效果也为评估标准的有效性提供了数据支撑。某项标准落地后，相关字段的质量指标是否显著改善——这些反馈让标准的迭代从"凭经验决策"变成"凭数据决策"。 三、落地实践：从标准定义走向质量验证 第二章分析了三者的理论关系，本章聚焦在项目中如何将它们协同运转起来。 3.1 场景牵引、标准落地 高质量数据集首先要回答一个前置问题：这个数据集为哪个业务或AI场景服务？场景明确了，才能确定需要哪些字段、每个字段的业务口径、格式规范和质量要求。 实践中一个常见的弯路是"先建标准再找场景"——投入大量精力制定了一套覆盖全企业的大而全的数据标准，却发现很多标准在实际的数据集建设场景中用不上，真正需要的字段和规则反而没有覆盖。比较务实的做法是从具体场景倒推标准需求，在场景验证中逐步完善标准体系。 3.2 以元数据为桥梁，打通标准和执行 标准定义完成后，元数据承担"映射落实"的角色。这一阶段的核心任务是：将标准中的字段定义、编码规则、口径说明逐一映射到实际数据源的表和字段上，形成可查询、可校验的落标映射关系。 这种映射的价值在日常运维中尤为明显。当业务人员质疑某个数据集中的数值时，可以通过元数据快速追溯到原始数据表、字段和加工逻辑——这既是质量问题的排查入口，也是数据可信度的建立过程。 3.3 以质量为门槛，验证数据集可信度 标准落地、元数据对齐之后，质量评价是数据集交付前的最后一关。以 GB/T 36344-2018[1]的六个维度为框架，对数据集进行系统性质量扫描。 在实施方式上，不同场景可灵活选择。对于需要保持业务连续性的场景，可以采用旁路监测方式——数据正常流转，质量规则并行扫描，发现问题后打标记、告警和问题跟踪，不阻断现有业务流程。质量评价的结果应形成结构化的质量报告，作为数据集交付的附件之一。 3.4 协同落地实例 华东某电子制造企业在数据治理项目中经历了一个典型的协同过程。 起初的问题是一个典型的"标准缺位"场景：物料编码在不同系统中重复率较高，"一物多码"和"多物一码"的情况并存，采购、库存、生产和财务模块的数据因为编码不一致而无法关联。企业从核心业务对象入手统一编码规则和校验规范（标准），通过元数据映射将标准落实到各系统的字段级别（元数据），围绕关键数据链路配置自动化质量检核规则（质量）。 最终实现的不仅是数据质量的改善，更重要的是一种运转状态：标准定义了规则、元数据记录了现状、质量检查发现偏差、偏差驱动修复或标准迭代——这个闭环一旦建立，数据治理就从"一次性的项目交付"转变为"日常运转的组织能力"。 四、建设建议：从"分别建设"到"协同运营" 基于以上分析，企业建设数据标准、元数据和数据质量能力时，可以从四个角度规划。 场景牵引、标准落地。 先明确数据集的应用目标，再将场景需求转化为字段范围、业务口径、格式规范和质量要求。从一两个核心业务域起步，在场景验证中逐步完善标准体系，避免一步到位制定大而全的企业标准。 元数据不只管采集，更要管对齐。 技术元数据的自动采集是基础设施，但真正产生协同价值的是技术元数据与业务元数据的打通——让标准定义的"客户等级"和数据库中实际的"cust_level"字段之间的映射关系可查询、可校验。这种对齐能力是标准和质量的粘合剂。 质量不做一次性体检，做持续闭环。 质量基线建立后，持续监控、问题发现、根因定位（借助元数据血缘）、修复验证、标准反馈——这个闭环的持续运转比一次性搞一轮全面质量普查更有价值。 平台化支撑，模块可按需装配。 三者协同需要平台将标准定义、元数据采集、质量检核三个模块的数据和流程打通，而非各自独立的三个功能菜单。龙石数据中台以"理采存管用"方法论为骨架，将数据标准管理、质量稽核、元数据管理和资产目录打包为可按需装配的独立模块，企业可根据自身建设节奏选择性启用，无需一次性为全栈功能支付溢价。 五、结论：高质量数据集不是三个模块的简单叠加 数据标准负责建立共同规则——数据应该长什么样、叫什么、怎么算。元数据负责将规则映射到实际数据，并记录数据之间的关系和加工历史——数据库里的这张表的那个字段，对应的是标准里的哪条定义。数据质量负责评价执行结果，并通过元数据血缘追溯到问题根因，推动修复和改进——最终再反馈到标准的迭代优化。 三者不是三个孤立的功能菜单，而是一套从规则定义、落标映射、质量检核到反馈优化的闭环机制。高质量数据集建设的关键，也不是分别建好三个模块之后"拼接"到一起，而是让三者围绕具体的业务和AI场景协同运转。标准缺位，质量就没有判断依据；元数据断裂，问题和规则就对不上号；质量不做闭环，标准和元数据的建设成果就无法转化为可信的数据成果。 从政策层面看，高质量数据集建设的推进正在加速。龙石数据联合江苏省市场监督管理局数据中心和苏州大学共同申报的"高质量数据集智能底座"项目，已入选江苏省2026年高质量数据集先行先试试点。这一项目的核心逻辑正是将数据治理的基础设施能力转化为高质量数据集的生产能力——标准、元数据和质量的协同运转，是这条转化链上的关键一环。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，数据中台，https://www.longshidata.com/products/government.html

某企业数据治理项目立项，两份方案摆在了决策桌上：数据质量厂商推荐独立部署一套数据质量管理平台，数据中台厂商则说"中台自带质量模块，不需要重复采购"。预算有限，治理团队内部为此讨论了好几轮——质量团队担心模块能力不够深，中台团队担心重复建设。 这个场景在 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

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

一、场景钩子 业务部门的运营同事对着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

AI 时代最贵的成本，不是模型采购费用。而是在错误数据基础上的反复试错。 做 AI 之前，先看一眼你的数据。花一两周做一次数据质量体检，可能会省下半年甚至一年的试错。这可能是整个 AI 项目中投入最小、回报最高的一步。

简而言之：传统的基于人工编写规则和被动检查的数据质量体系，从未针对智能体人工智能进行设计。到2026年，当自主代理处理错误数据时，没有人会介入以发现问题。那些在人工智能领域取得成功的组织，并非从更好的模型入手，而是从构建数据信任层入手，该信任层能够在代理采取行动之前检测、修复并自我修复数据。这才是现代自主数据质量的真谛。 大多数组织都认为他们已经解决了数据质量问题。他们制定了一些规则，设置了一些检查机制，组建了数据治理团队并为其提供了一套框架。在很长一段时间里，这些就足够了。 这已经不够了。 如今大多数企业所处的数据环境与当初设计的数据治理框架所针对的环境几乎截然不同。十几年前，一个典型组织的数据来自少数几个ERP和CRM系统。结构化的表格，可预测的模式，范围可控，规则易于维护。理论上，一个人就能理解全局。 如今，平均每个企业管理着超过900个应用程序。每个应用程序都会生成数据。但它们之间大多无法有效通信。而几乎所有这些数据最终都应该流入企业领导层公开承诺、已列入预算并正面临交付责任的AI项目。 正是在这里，现代人工智能驱动的数据质量不再仅仅是数据团队需要关注的问题，而变成了业务连续性问题。 这些数字揭示了一个比大多数组织愿意听到的更残酷的真相。 Gartner 估计，平均每个组织每年因数据质量差而损失 1290 万美元。超过四分之一的组织报告称，每年损失超过 500 万美元，7% 的组织损失超过 2500 万美元。多年来，这些数字经常在董事会会议上被提及，通常是为了证明购买数据质量平台的必要性，然后就被悄悄地束之高阁。 到2026年，真正改变讨论走向的不是具体的金额，而是当下糟糕数据所造成的后续影响。 在传统的分析领域，人总是参与其中。一份报告显示数字错误，有人发现了，有人上报了情况。由于有人在问题扩大之前及时发现并处理，损失被控制在了有限范围内。 智能体人工智能彻底消除了这种缓冲。当自主智能体基于损坏的数据做出决策时，它不会停下来进行健全性检查，而是直接行动。它会配置错误的基础设施，触发错误的工作流程，并向客户提供错误的建议。而且，由于智能体以机器速度在深度互联的系统中运行，因此，在任何人意识到发生了什么之前，单个数据质量故障就可能蔓延到整个流程。 这是自动化数据质量基础设施在2026年需要解决的核心问题：不是为分析师发现错误，而是在客服人员采取行动之前就发现错误。 到2026年，全球人工智能支出预计将超过2万亿美元。每一美元的投资都取决于流经其中的数据质量。数据质量差不仅会降低人工智能的投资回报率，在智能体环境中，它还会造成大规模的危害。 我们一直以来衡量人工智能准备度的方式都是错误的。 57% 的组织表示，他们的数据尚未准备好用于当前或未来的 AI 应用场景。考虑到过去十年在数据基础设施方面投入的巨额资金，这一比例令人震惊。这不仅暴露出数据问题，也暴露出衡量标准问题。 大多数组织会从完整性、准确性和一致性三个方面评估数据质量。这些维度固然重要，但它们的设计初衷是基于最终用户是经过深思熟虑的人类分析师这一前提。对于自主人工智能系统而言，标准则截然不同，而且要高得多。 人工智能代理不仅需要知道某个字段是否有数据，还需要知道数据在上下文中语义是否正确，其值在相关数据点的背景下是否合理，数据来源是否可信，以及数据是否足够新，足以支持正在做出的决策。现代人工智能驱动的数据质量框架现在包括语义验证、跨源一致性检查、漂移检测和质量评分，这些功能可以告诉代理在特定时间点应该对特定数据源赋予多大的权重。 这是对质量的根本性不同定义，也需要采用根本性不同的方式来实现。 规则时代已经结束了 传统数据质量的根本问题在于：它的设计初衷就是被动的。人预先设想出某种故障模式，编写规则来捕获它，然后系统根据这条规则进行检查。这种模式在数据环境稳定、维护规则手册的人员能够及时应对变化时是有效的。 这两个条件都不再成立了。 如今，数据来自数百个来源，格式瞬息万变，并且被输入到原本设计时并未考虑互操作性的系统中。任何分析团队都无法快速编写规则来应对这种变化。任何静态的规则手册也无法预见数百个系统以始料未及的方式交互时出现的各种故障模式。 现代智能体人工智能数据质量的转变在于，它从人类定义的规则转向机器发现的模式。这体现在数据量、速度和分布方面的行为异常，以及由于数据集之间的关系从未被正式记录而导致的、任何规则都无法预料的参照漂移。此外，还体现在时间上的不一致性，这种不一致性只有在观察数据随时间推移的行为时才会显现，而不仅仅是观察其是否通过了某个特定时间点的检查。 当发现的模式与既定规则相结合时，质量系统便真正具备了自适应能力。它能够学习每个数据集的正常状态，检测偏离该基线的情况，并在不良数据到达任何处理环节之前及时上报。 举个具体的例子。零售平台的订单表应该反映美国数千个司法管辖区的准确州和地方销售税。这些税率不断变化。基于规则的系统可以对照已知表格进行核对。但是，如何才能在错误累积到数万笔交易之前，就发现新产品类别中税费计算错误的模式呢？这种检测需要行为建模，而不是规则匹配。 79%的AI代理未能投入生产环境的真正原因 近五分之四的企业已经以某种形式采用了人工智能代理。但只有九分之一的企业将其大规模地应用于生产环境。这一差距是2026年企业人工智能面临的核心挑战，而围绕这一挑战的大部分讨论都集中在模型成熟度、编排复杂性和人才短缺等方面。 这些都是真实存在的因素。但最容易被忽视的因素是数据信任。 智能体故障几乎总是上下文故障。语言模型或自主智能体需要的不仅仅是数据，还需要数据背后的上下文：这些值的含义、当前生效的定义版本、数据来源、数据经历了哪些转换，以及数据是否足够新，足以支持所请求的决策。缺少这些上下文，智能体就会产生错觉，获取错误的信息，并根据技术上有效但语义上错误的信号采取行动。 自愈式数据管道和自动化数据质量基础设施之所以引人注目，并非因为它们能减少数据团队的手动工作量（尽管它们确实能做到这一点），而是因为它们能够确保将自主代理安全地部署到生产工作流程中，并信任其行为。到2026年，那些在智能体人工智能领域取得成功的组织，并非因为它们拥有更优秀的模型，而是因为它们首先构建了数据信任层。 自主数据质量在实践中究竟是什么样子 现代数据质量管理方法并非每天早上由专人查看的监控仪表盘，而是一个持续运行的系统。该系统能够理解其处理的每个数据集的预期行为，实时检测偏离预期行为的情况，评估其对下游数据的影响，并自动进行修复，或者提供足够的信息以便人工快速处理。 到2027年，那些不优先考虑人工智能就绪数据的组织，在扩展全人工智能和智能体解决方案时，预计将面临15%的生产力损失。这并非是对数据质量的警告，而是对基础架构错误造成的累积性损失的警告，尤其是在构建于其上的系统不断扩展的情况下。 那些最终脱颖而出的组织，是那些将自动化数据质量视为基础设施，与计算和存储归为同一类，而不是将其视为与实际工作并行开展的项目的组织。 这就是转变所在。数据质量不再是补救措施，而是决定人工智能能否可靠运行的关键因素。 来源（公众号）：数据驱动智能

文 | 中国信息通信研究院副院长 魏亮 习近平总书记指出，数据是数字经济时代的基础性资源、重要生产力和关键生产要素。近年来大模型技术不断取得突破，其中大规模高质量训练数据的投入，起到了关键作用，也进一步将“以数据为中心的人工智能”推向一个新阶段。 近期发布的 Deep Seek 系列模型训练中大量高质量推理数据集的使用更加凸显了高质量数据的重要性，而大模型要与垂直领域深度融合同样需要高质量数据集的支撑。国家数据局围绕高质量数据集建设相关工作开展了一系列工作部署。2025年2月19日，高质量数据集建设工作启动会在北京组织召开，国家发展改革委、教育部、科技部、工业和信息化部等27个部门参会。下一步，高质量数据集建设工作将积极推进落实“人工智能+”行动，加快推动形成一批标志性成果，赋能行业高质量发展。 01 准确认识高质量数据集建设取得的进展和面临的挑战 高质量数据集构建是一项复杂而关键的任务，需要了解模型应用场景和需求，进而开发、构建和维护数据资源，提供持续有效的高质量数据集。当前，在顶层设计层面，国家数据局等17部门联合印发《“数据要素×”三年行动计划（2024—2026年）》，强化场景需求牵引，带动数据要素高质量供给、合规高效流通，高质量数据集建设取得积极进展。在地方层面，湖北、江苏、浙江等多省市明确了建设高质量数据集的数量、时间及激励机制； 湖北省数据局发布首批10个高质量数据集，推动构建高质量“数据集市”；苏州市发布首批30个工业制造、交通运输、金融服务等高质量数据集。在行业层面，智源研究院发布全球最大的多行业中英双语数据集IndustryCorpus 1.0，包含3.4TB开源行业预训练数据，覆盖18类行业；中国信通院推出我国首个面向行业的人工智能数据集质量评估体系，为数据质量提供客观、公立的评价能力和方法体系；北京国际大数据交易所累计发布约300个高质量数据集，形成10余个应用领域数据资源地图。与此同时，还应看到目前高质量数据集建设还存在不少挑战。 一是政府和业界不清楚行业高质量发展需要什么样的数据。一方面，行业大模型数据具有需求多样性的特点。不同行业部门对模型场景数据的需求各不相同，涉及分析、决策和生成不同的任务需求，这种多样性要求在人工智能高质量数据集建设中，必须深刻理解业务场景。另一方面，行业大模型数据具有需求复杂性的特点。大模型涉及预训练、微调、反馈强化学习等不同阶段，不同阶段都涉及到数据训练构建和优化策略，需要多个数据源、多种数据类型融合对齐，这增加了数据处理和管理的复杂度。 二是行业企业不知道高质量数据集如何构建。构建大模型数据集主要包含数据采集、数据清洗、数据标注、质量评估等核心环节。各环节需要根据大模型数据集具有的规模大、多样性足、行业垂直属性强等特点进行针对性的技术研发和适配。但是，行业企业对于数据的理解程度不同，面向大模型的数据治理方法和经验不足，传统的数据处理工具和技术无法满足大模型需求，需要引入先进的数据处理技术和工具提高数据处理效率和准确性。 三是业界不了解行业数据集质量如何评价。不同行业、不同数据源的数据完整性和准确性可能参差不齐，严重影响大模型的训练效果和预测准确性，造成训练资源浪费。此外，训练数据获取往往需要耗费大量时间和经济成本，包括数据收集、清洗、标注等环节。在行业大模型的实际建设中，对于构建和采买的数据没有统一的衡量标准，造成无法有效获取高质量数据集资源。 02 分类推动高质量数据集供给体系建设 数据之于大模型就像石油之于汽车，汽车无法直接使用原油，原油只有经过一系列复杂的过程炼化成汽油后，才能给汽车使用。同样，海量原始数据需要经过“炼化”形成高质量数据集，才能真正有效地用于大模型训练。行业大模型训练所需数据集，既要覆盖行业通识，也要蕴含专门知识。其中，通识数据是通用大模型能力提升的基础，行业通识数据是行业大模型训练的基底，行业专业数据是企业推动行业大模型的应用、部署私域模型能力的底座。为此要根据急用先行、分类推进、合理使用的原则，推进高质量数据集建设。 一是加快通识类高质量数据集建设。通识类高质量数据集是指由政府机构、科研机构、开源社区或大型互联网企业等公开数据构建的数据集，具有广泛性和通用性，覆盖多个领域，如自然语言处理、计算机视觉、语音识别等，能够为企业提供丰富的训练资源和基准测试环境，有助于行业大模型快速验证算法、提升模型的基础能力。此外，公共数据集还有助于促进跨行业、跨领域的数据共享和知识融合，推动行业大模型的持续进步和快速发展。 二是加快行业通用类高质量数据集建设。行业通用类高质数据集，是指针对某一特定行业或领域知识的具有事实性数据集，具有高度的专业性和针对性。这类数据集通常包含某一特定行业特有的知识、术语、场景和业务流程等信息，对于训练出适用于行业应用的大模型至关重要，能够覆盖行业领域专业知识，提高模型在行业通识领域的泛化能力。 三是加快行业专用类高质量数据集建设。行业专用数据集，是指根据行业企业自身业务场景和需求收集的数据集。这类数据集通常包含行业企业内部业务流程、用户行为、产品信息等关键信息，具有针对性和定制化的特点，能够为行业企业提供高度个性化的训练数据资源，构建专属大模型。通过行业企业场景化数据集的训练，可以定制化地优化大模型算法和参数设置，深度挖掘内部数据价值，实现模型的定制化优化与业务高度适配，使其更好地服务于业务需求和发展战略，带来更加精准和有效的业务洞察和决策支持。 03 加快提升高质量数据集构建能力 推动高质量数据建设，是一项系统工程，核心是提升行业数据集管理与运营效率、提升数据集质量和数量、充分挖掘数据资源价值、保障模型数据安全可信，需要系统性地加强能力建设。 一是完善行业数据集管理体系。编制行业数据资源目录，细化数据集的分类与分级，明确结构化、半结构化及非结构化等多种数据类型，按照数据清洗处理程度（手动、半自动至全自动），开展数据集资源管理。构建高效协同的组织架构，确保从数据采集到模型应用的每一步都能够得到有效管理和支持，建立数据治理与模型开发的协同架构。围绕数据技术、平台、应用及安全，制定详尽标准，涵盖数据生产、服务、质量评估及数据集管理。培养跨学科、跨专业的数据工程团队，强化数据科学与模型训练能力，为大模型的成功部署与持续优化奠定坚实基础。 二是提升行业数据集开发维护能力。着力提升数据采集汇聚、数据预处理、数据标注等关键环节，以及指令微调、反馈对齐关键阶段的技术工具能力。数据采集汇聚需具备高效的数据抓取、清洗与整合能力，确保数据的全面性和多样性；数据预处理阶段涵盖数据清洗、去噪、归一化等技术，以提升数据质量；数据标注环节要求深入理解数据特性，掌握高效的自动化和智能化标注技术。行业大模型数据集主要应用于指令微调阶段和反馈对齐阶段，通过有标注的指令数据对模型进行精细化调整，增强其任务执行能力，利用用户反馈优化模型提升实际应用效果。此外，还需要制定详细的数据技术处理要求和方案，以保证不同阶段的数据分布一致性。 三是增强行业数据集质量控制。在质量管理方面，从流程管理、质量评估和组织规范三方面对大模型数据集生产到管理的各环节进行能力规范和等级评定，从源头上确保数据集高质量生产和管理。在质量评估方面，针对行业大模型对数据质量进行更多维度的要求，提升数据集在模型应用上的实用效果。设计具体规则和方法，采用自动化标注和人工抽样的方式对数据集自身质量进行前置检测，采用模型验证和消融实验的方式对数据集在大模型的应用效果进行后置检测，通过模型效果反馈进行数据集质量优化。 做实、做深、做细高质量数据集建设工作，就要深入贯彻落实党中央、国务院决策部署，做好系统谋划、加强统筹协调、做好部门协调。此次高质量数据集建设工作启动会，为推动相关工作发出了动员令、吹响了集结号。相信通过国家数据局协同行业主管部门的政策牵引和政、产、学、研、用多方协同，我国高质量数据集建设步伐将越来越快，也必将为人工智能赋能实体经济注入强劲动力。 来源（网站）：国家数据局

在数字化浪潮的推动下，电子政务作为提升政府行政效率和公共服务能力的重要手段，正日益受到广泛关注。随着电子政务的不断深入，政务数据的积累量也在迅速增长。然而，数据的快速积累也带来了诸多挑战，尤其是数据质量问题，成为制约电子政务进一步发展的瓶颈。这不仅影响了政府决策的准确性和效率，也可能对公共服务产生负面影响。因此，如何有效提升政务数据质量，成为当前亟待解决的问题。 一、政务数据质量管理的重要性与现状 政务数据的质量管理是确保电子政务系统稳定运行和高效服务的基础。高质量的数据能够为政府决策提供准确依据，优化资源配置，提升公共服务质量。反之，低质量的数据则可能导致决策失误，影响政府公信力，甚至造成资源浪费和损失。尽管我国政务数据质量管理已取得一定成效，但实际操作中仍面临诸多挑战。数据来源复杂、质检工具不标准、人员素质参差不齐等问题，使得政务数据质量管理工作困难重重。此外，随着数据量的持续增长，传统质检方式已难以满足需求，急需自动化、智能化的质检工具来提高质检效率。 二、政务数据质量管理的新挑战 当前，政务数据质量管理面临着多重挑战。一方面，数据来源的多样性和复杂性要求质检规则能够更加灵活、智能地适应不同情况；另一方面，政务数据的敏感性和重要性也对质检工具的安全性和可靠性提出了更高要求。同时，随着电子政务的不断发展，政务数据质量管理还需要建立起长效机制，以持续监测和改进数据质量。 三、破局之道：“AI+准度领航” 面对政务数据质量管理的新挑战，国脉互联提出“AI+准度领航”数据质控合规系统，以“构筑质量屏障，守护合规标准”为目标，建立持续、系统的数据质量检测机制，实现从数据精准定位到数据质量治理的全流程精细化管控，确保数据的准确性、完整性、一致性、规范性、时效性和可靠性，全面强化数据合规管理，确保数据合法合规使用。通过“AI+准度领航”，我们可以实现对数据的智能化摸底、精准制定规则、高效质检与评估，以及建立长效机制。 1.智能化摸底 “AI+准度领航”拥有强大的数据处理能力，能够全面梳理来自各类源头的数据。它可以有效地对数据进行分类，帮助我们清晰地识别出哪些数据尚未经过质检，哪些数据已经过质检但质量未达到预期，以及哪些数据属于高质量数据。这种智能化的摸底过程，为后续的数据质检工作奠定了坚实的基础，使质检工作能够更加精准地针对存在的问题展开。 2.精准制定规则 结合国家数据管理相关标准及行业特定要求，“AI+准度领航”为不同的数据集量身定制质量标准。它充分利用AI大模型和深度学习技术，深入剖析数据特性，从而制定出既符合统一标准又满足本地实际需求的检测规则，确保数据质量的准确性与可靠性。 3.高效质检与评估 “AI+准度领航”具备强大的自动化质检能力。它能够根据制定的检测规则对相关数据进行自动化质检，快速识别问题数据并自动生成详细的评估报告。这提高了质检效率，还为各部门提供了明确的改进方向。 4.建立长效机制 “AI+准度领航”不仅关注当前的质检需求，还着眼于未来的可持续发展。它具备实时动态检测的能力，能够同步生成实时检测报告，快速识别并处理任何潜在的数据问题。通过设置预警机制和定期审查调整检测规则，“AI+准度领航”助力政务数据质量管理实现持续优化和提升。 四、“AI+准度领航”的价值 “AI+准度领航”以其独特的设计思路和预期效果，与当前政务数据质量管理的需求高度契合。它不但能够解决数据来源复杂、质检规则不灵活等问题，还能够提高质检效率、降低人为错误、增强数据安全性。通过“AI+准度领航”的智能化摸底功能，政府部门能够全面评估各类数据的质量，准确区分出质检质量不高的数据，从而为后续的数据质检工作提供明确的方向和重点。 这种精准的质检模式，有助于政府部门及时发现并修正数据中的问题，确保数据的准确性和可靠性。同时，“AI+准度领航”还能为政府部门提供科学、高效的决策支持，助力电子政务的健康发展。通过持续监测数据质量，政府部门可以更加及时地调整政策、优化服务，从而提高公共服务的质量和效率。 五、结论 综上所述，面对政务数据质量管理的新挑战，“AI+准度领航”以其独特的设计思路和预期效果，为电子政务的健康发展提供了新的可能性。我们期待着这款工具能够尽快落地应用，为政府部门带来更加精准、高效的数据质量管理体验。同时，我们也相信，在未来技术的不断进步和应用的深入下，“AI+准度领航”将在政务数据质量管理领域发挥更加重要的作用。 来源（公众号）：国脉研究院