一家中型制造企业在部署大模型后，内部测试阶段效果不错，问"本月华东区销售情况"能给出清晰的数据和趋势判断。正式上线第一天就出了问题——系统告诉业务副总"华东区上月销售额3200万"，但财务系统里是2800万，差了整整400万。
排查结果指向了一个简单的事实：ERP、CRM 和财务系统对"华东区"的定义不同，对"销售额"的计算口径也不一样。模型本身没有出错——它忠实汇总了它能看到的全部数据。问题出在它"看到"的数据本来就不一致。
这个场景折射出一个正在加速的趋势：当大模型从技术验证走向业务一线，最关键的瓶颈往往不是模型能力，而是数据供给质量。Data-Centric AI 的研究反复验证了一个判断——AI 效果的上限由数据质量决定，而非模型参数。DCMM 2.0（GB/T 36073-2025）[1]更从国家标准层面确认了这一方向：L4 量化管理级明确要求企业具备 AI 支撑能力，数据治理在 AI 时代已从"最好有"变成了战略级要求。
大模型时代，数据质量的容错率被大幅压缩
传统 BI 场景下，数据质量问题的后果相对可控。报表上一个数字偏差，使用者在业务层面往往能察觉——"上个月华东没做过这么大单子"——然后人工核查修正。数据错了，人的经验还能兜底。
大模型把这个容错空间压到了几乎不存在。从架构层面看，原因是三个机制同时起作用。
第一，大模型的输出模式是完整分析结论而非单个数值。当它在回答"今年哪个产品线增长最快"时，会调用多张表、关联多次查询、形成综合判断。链条中某一个环节的数据有问题，可能让整段结论偏离事实。业务人员面对一段逻辑完整的分析文本，很难逐环节拆解验证——这不是看一个数字对不对，而是判断一整套推理是否站得住脚。
第二，大模型在架构上天然倾向于信任输入数据。模型推理层不会主动质疑"这个字段的值从上下文推断可能不对"，也不会在发现多个数据源对同一指标给出不同数值时触发"口径不一致"的提示。它会基于读取到的全部信息，输出一个它认为最合理的回答。如果输入数据本身相互矛盾，这个"最合理的回答"实际上建立在不可靠的数据基础之上。
第三，问题定位的复杂度呈非线性放大。传统 BI 场景下排查一个数字偏差，通常追溯到一两张源表就能定位。而大模型关联了多系统、多口径的数据，一次质量问题可能需要回溯多个数据源、对比多套业务口径、跨部门确认数据定义——从单点排查变为全链路追踪，排查周期从小时级拉长到天级。
Data-Centric AI 提出者吴恩达的判断在这里找到了最具体的注脚："与其花80%精力调模型参数，不如花80%精力提升数据质量。"当企业发现花了几百万调优的大模型，在实际业务场景中的表现还不如一个治理到位的中小模型时，数据治理在 AI 战略中的优先级自然被重新排列。
国家标准已在推动数据供给升级
DCMM 2.0（GB/T 36073-2025）[1]于 2026 年 7 月 1 日正式实施，带来的变化不止是能力域从 8 个扩展为 9 个。更值得关注的是成熟度评估体系中对 AI 能力的明确要求。
新标准将数据管理能力划分为五个成熟度等级：初始级→受管理级→稳健级→量化管理级→优化级。到了 L4 量化管理级，标准要求企业在数据管理全过程中具备量化评估能力，并引入人工智能等先进技术支撑数据管理决策。这意味着 AI 应用在 DCMM 体系中不再是一个可选项——企业若想在评估中达到 L4 及以上，必须在数据架构、数据质量、数据标准等关键能力域中储备 AI 用数能力。
九大能力域的重新划定也释放了明确信号。新增的"数据资产"域排在第四位，包含权属管理、价值评估和资产运营三个能力项，与"数据二十条"[3]确立的数据要素市场化政策方向直接呼应。"数据应用"更名为"数据应用流通"，将数据服务、外部数据管理和数据开放纳入统一框架。从标准结构来看，DCMM 2.0 正在从"管好数据"向"用好数据"倾斜——而这一转变恰好与 AI 时代企业对高质量数据供给的需求同频。
与 DCMM 2.0 互补的是 GB/T 36344-2018[2]《信息技术 数据质量评价指标》。该标准定义了六个数据质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。从架构角度看，前五个维度构成了 AI 数据供给质量的评估框架——规范性决定了数据格式的一致性和可解析性；完整性和准确性决定了推理基础的信息完备度；一致性和时效性决定了跨系统关联分析的可信度。
政策层面，高质量数据集建设也在加速从概念走向落地。江苏省 2026 年率先推动高质量数据集先行先试，147 个项目入选省级试点，覆盖制造、医疗、交通等多个领域，探索数据治理成果向 AI 训练数据的高效转化路径。
这些标准和政策的交汇，指向同一个方向：高质量数据供给正从一个技术课题上升为制度性要求。以江苏某大数据中心为例，该中心对 300 余个高频共享数据资源、超过 10 亿条数据进行了系统性质量评测，累计定位近 1000 万个数据质量问题，经过持续修复后修复率达到 95%，200 个高频应用资源的准确率达到 100%。公共数据供给从"能用"提升到"好用"——这个跃迁的逻辑，同样适用于企业 AI 场景下的数据供给。
图片描述：从数据可用到数据可训的三层进阶架构。底层"数据可用"确保数据可被采集和查询；中间层通过元数据管理、数据标准统一和数据质量治理三个子系统，为数据注入可解析、可关联、可追溯的能力；顶层"数据可训"实现 AI 模型对数据的稳定消费，各层之间通过标准化接口耦合。
从"数据可用"到"数据可训"：供给架构的三层设计
传统数据治理以满足业务报表和运营分析为主要目标，关注的是数据"能用"——能从不同系统中取到数据、能跑通报表、能支撑日常决策。但大模型对数据的要求不止于此。它需要数据"可训"——能被模型稳定解析、跨系统关联时不产生口径冲突、输出结论可以被追溯和验证。从架构设计角度看，从"可用"到"可训"需要补上三层基础能力。
元数据层：数据语义的抽象与建模
元数据层在架构中扮演的是数据语义抽象的角色——它记录了数据从哪里来、经过了哪些加工链路、每个字段映射到什么业务实体。
对传统 BI 而言，元数据层的作用是辅助性的：分析师查一下表结构、确认一下字段含义。但对大模型而言，元数据层是数据可解释性的基础。模型在处理数据时，看到的是字段名和数值，但无法理解字段背后的业务语境。一个标注为 customer_name 的字段，在 ERP 系统里指签约主体，在 CRM 系统里指联系人。如果模型在关联这两个系统的数据时不做区分，"客户"的统计口径就直接出错。
当监管或审计要求企业说明"训练数据来源和加工过程"时，元数据层是唯一可以提供完整追溯链条的依据。从架构角度看，元数据层应作为独立子系统存在，通过标准化的元数据模型（如业务元数据、技术元数据、操作元数据三层模型）与数据存储层和计算层解耦，确保数据血缘的完整性和可追溯性。
数据标准层：跨系统语义互通的翻译层
大模型的一大优势是跨数据源关联分析。但这个优势的前提，是不同系统对同一业务概念的定义可以通过标准层实现映射。
现实中的典型场景是：同一家制造企业，ERP 系统按事业部划分"产品线"，MES 系统按生产工艺划分，CRM 系统按销售目录划分。三套"产品线"对应三种分类逻辑和编码体系。当大模型尝试关联这三个系统的数据做综合分析，它面对的是一堆同名字段指向不同实体——口径不统一导致的结论偏差，比数据缺失更难排查。
数据标准层在架构中的定位是跨系统的语义互通层：建立主数据编码映射规则、定义核心业务实体的统一编码体系和分类口径、提供不同系统间字段级的数据字典映射。这不是单纯的 ETL 字段映射——而是为 AI 提供一组"业务词典"，让模型在处理跨系统数据时能够自动消解语义冲突。
数据质量层：数据可信的守卫层
这是最直接的一层，但从架构设计角度看也最容易被简化为事后校验。
GIGO 原则（Garbage In, Garbage Out）在大模型场景下被放大——一条脏数据可能被模型在多轮推理中反复调用，第一次分析引用错误值，第二次趋势对比基于这个结果推导，第三次优先级排序又把这个推导作为权重依据。脏数据的"污染半径"在模型推理链中被大幅扩张。
治理模块的架构设计原则
从技术架构角度看，支撑"从可用到可训"这一转变的数据治理模块，需要满足以下几项设计原则：
治理模块应与数据主链路解耦。 数据标准管理、质量稽核、元数据管理、资产目录等治理能力，应作为独立的服务模块存在，通过事件驱动或 API 网关与数据采集、存储、计算等核心链路交互，而非嵌入主链路内部。解耦确保了治理模块的独立演进和按需启用。
质量校验宜采用旁路监测架构。 数据正常流转入库，质量稽核并行扫描，发现问题自动记录标记、生成告警，不阻断数据链路。旁路架构的核心优势在于业务连续性——质量检测不会成为数据流转的性能瓶颈，同时企业对数据质量状态保持持续感知。
治理规则应嵌入数据管道而非事后外挂。 数据从源头采集到入仓的每一个环节，质量校验和标准匹配都应作为数据管道的内置步骤。这要求数据管道引擎原生支持规则配置和策略注入，而非依赖外部调度系统的事后批量检验。目前已有企业在实践中将 GB/T 36344 的六个质量维度指标嵌入数据接入 Pipeline，在数据进入存储层之前完成规则校验。
三层之间的关系不是串行的——不需要等元数据层"建设完成"再启动标准层。它们之间存在互相增强的正反馈：元数据缺失时数据标准难以落地，质量检测的结果反过来暴露标准不一致的位置。从工程实践来看，选取一个核心业务域，三层子系统并行启动、定义清晰的接口契约、快速迭代验证，比逐层推进更高效。
CDO 和 CIO 现在可以着手的技术路径
大模型还在快速迭代，但对数据供给的架构要求方向已经足够明确。不需要等到"治理完美"再启动 AI 应用，但启动之前有几项技术准备工作可以先做。
先做一次数据质量体检。 选取 AI 应用瞄准的核心业务域，用 GB/T 36344[2]的六个维度做一次系统性评测。摸清现状后再定优先级：如果多个系统对同一指标口径不一致，优先建立数据标准映射层；如果核心表的缺失率或异常值比例偏高，先部署质量监控基线。体检的目的是定位问题域，不是追求满分。
建立"数据就绪"的最小技术栈。 不需要一开始就覆盖全部数据资产——从 AI 应用会用到的核心表和字段切入。元数据层至少记录来源、加工链路和业务语义映射。数据标准层统一核心业务实体的编码规则和主数据映射。数据质量层在数据接入环节建立完整性、准确性、一致性的自动校验 Pipeline。这个最小技术栈跑通后，再向更多数据域横向扩展。
AI 用数与数据治理并行推进。 不必等治理体系建设完成再上 AI。一个有效的工程策略是：用 AI 用数的需求反向暴露治理体系的短板。当业务人员用自然语言问数据时得到的答案不准，自然会暴露出标准层映射缺失、元数据语义不完整、质量规则覆盖不足。这比自上而下推动治理体系建设更容易获得业务部门的配合和资源投入。
关注 DCMM 2.0 的 AI 能力架构要求。 DCMM[1] L4 以上要求企业储备 AI 用数能力，这涉及的是评估时间表而非远期规划。评估现有数据中台的 AI 就绪度——是否具备自然语言查询接口、数据资产目录是否支持语义搜索和自动推荐、是否支持数据不出域的私有化部署——是一个务实的起点。目前已有实践表明，将数据治理成果通过 AI 用数接口层暴露为消费服务，可以让治理体系的投入更快见到业务价值。
常见问题
问：大模型项目要不要等数据治理做完再启动？
不需要。选取核心业务域先做质量评估和标准映射，治理体系建设与 AI 用数可以并行推进。内测阶段用受控数据集验证效果，是比较稳妥的做法。
问：怎么判断是模型能力问题还是数据质量问题？
选取一个已知数据质量情况的业务域做测试。如果在该域中模型输出准确度明显高于其他域，说明问题更可能出在数据供给侧。借助数据质量评估工具对输入数据做系统检测，将检测结果与模型输出效果做对照分析，通常能快速定位根因。
问：DCMM 2.0 L4 要求 AI 能力，大部分企业 L3 都不到，怎么办？
DCMM 是能力建设的方向标，不是紧急合规线。企业可以根据自身所处阶段，先锚定与 AI 效果最直接相关的 2-3 个能力域重点建设——尤其是"数据质量"和"数据标准"两个域。先做到 L3 稳健级的核心能力，再向 L4 量化管理级演进。标准提供的是一条可参照的路径，不是一张时间表。
大模型代表了企业 AI 应用的前沿方向，但它的上限取决于数据供给质量而非模型参数规模。Data-Centric AI 的核心理念在 DCMM 2.0[1]标准中得到了制度性确认——数据治理已成为 AI 基础设施的组成部分，而非应用上线前的一项准备工序。
对企业 CDO 和 CIO 而言，眼下最务实的做法是从数据供给架构中最薄弱的环节切入，在 AI 用数中暴露问题、迭代优化。当模型能力不再是稀缺资源，高质量的数据供给就是 AI 应用效果的分水岭。这一能力，正在从技术课题转变为企业 AI 战略的核心竞争力。
