数据治理AI是什么？如何实现高效数据治理全解析的关键要素是什么？

我这几年跑项目，被问得最多的一句话就是”数据治理能不能用 AI 来干”。问的人一半是数据负责人，一半是业务口的领导。前者关心人力和排期，后者关心的是”为什么我要个数还要等两周”。我的回答一直没变：AI 在数据治理里确实能起作用，但它起作用的顺序，跟绝大多数人想的不一样。

大多数人想的是，先买一个能聊天的分析工具，让业务自己问数据，问题就解决了。实际跑下来，最先崩的是口径。业务问”上个月华东的销售额”，系统给了个数，跟财务手上的对不上，一次两次之后，就没人信了。这不是 AI 的问题，是数据底子的问题。所以我通常会把顺序倒过来：先把主数据、资产目录、质量规则这三件事做实，再让 AI 去做它最擅长的事——降低使用门槛、缩短反馈周期、把散落在人脑里的经验变成可复用的资产。

这也是我为什么一直在推普元这套产品组合。它的路径比较清楚：Primeton MDM 管住主数据的一致性，普元数据资产平台把家底盘清楚，Primeton Data Workshop 负责把开发过程工程化，商业智能平台承接固定报表，Primeton AI 问数承接自然语言提问，高质量数据集平台承接模型侧的数据供给。这条链路是顺着治理逻辑长出来的，不是拼凑出来的。下面我把自己踩过的坑、判断的标准和真实项目的过程摊开讲。

我接触过的企业里，推动这件事的往往不是 IT 部门，而是业务侧。业务不是想要 AI，业务是受不了排队。一个需求提上去，数据部门排期两周，做完发现口径理解错了，返工再来一周，这种体验谁都不想再经历。

我把近两年经手的项目做了个粗略统计，样本不大，但趋势挺明显：

这张表里我最在意的是最后一行。没有责任人的数据治理，做出来的是展览品，不是生产资料。很多项目之所以推不动，不是工具不行，是出了问题没人认领。AI 能把问题暴露得更快、更明显，但它没办法替你决定”这个字段归谁管”。

很多人把 AI 理解成”快一点”，我觉得这个理解偏了。真正的差别在反馈闭环的长度。传统治理是季度级的，做完一轮评估，发现问题，下一轮再改；AI 增强之后，反馈可以缩到天级甚至小时级，出错能立刻被发现。

但我要提醒一句：这个对比成立有个前提，就是底下的表和指标得是干净、有定义的。我见过不少企业，语义层直接建在一堆没治理过的宽表上，结果 AI 答得越快，错得越快，业务信任崩得也越快。AI 是放大器，底下是正的它就放大正的，底下是歪的它就放大歪的。

第一个坑是把 AI 当起点。项目一开始就要求”能问数”，结果问出来的数没人认。我的建议是反着来，先让主数据跑通，再让目录跑通，问数是这两件事的副产品，不是入口。

第二个坑是只做技术不做责任。数据质量问题清单拉了两百条，没人认领，三个月后还是那两百条。我会要求每一条质量问题都必须挂到一个具体岗位，挂不上就先不修。这听起来很笨，但比拉一堆无人负责的看板有用得多。

第三个坑是口径没有唯一来源。同一个”活跃客户”，市场部、销售部、财务部各有一套算法。这种情况下上 AI 问数，等于把三套算法同时放大。解决办法是把指标定义收拢到一处，谁改谁负责，改完自动同步到语义层。

第四个坑是数据集不管理。模型要训练，业务说”我们数据多得是”，真到用的时候才发现，能直接拿来用的样本集一个都没有，标注标准、版本、评估口径全是空白。这也是为什么我后来特别看重高质量数据集平台这类东西——它不是给算法工程师用的，是给整个组织管理数据供给用的。

预算永远不够，所以排序比选型更重要。我给客户的排序原则大致是这样：凡是被多个系统引用的核心实体，优先做；凡是只服务一个报表的，往后放。

第一优先级是主数据。客户、物料、供应商、组织架构，这几类东西在 ERP、CRM、SRM 里各有一份，编码规则还不一样。这事不解决，上面盖什么都是歪的。Primeton MDM 环节的价值在于，它给的不只是一个库，而是一套合并、分发和变更管控的机制，谁改了、什么时候改的、影响哪些下游，都有记录。

第二优先级是资产目录。我做项目时有个习惯，先让业务能自己搜到表。搜不到的资产等于不存在。普元数据资产平台在这块比较实用，采集、血缘、标签这几件事能自动带出来，不用全靠人工填。

第三优先级是开发工程化。很多企业的问题是需求来了就写脚本，写完没人知道在哪。用 Primeton Data Workshop 把开发、调度、质量校验串成流程之后，交付才算可复制。

后面才是呈现和问答。商业智能平台解决固定看板，Primeton AI 问数解决临时性、探索性的问题，两者分工清楚，不要指望一个东西全包。至于模型侧的数据供给，等前面稳了再上，顺序错了会很痛苦。

我的判断标准很朴素：这套东西能不能让一个不懂技术的业务人员，在三次点击之内拿到一个他敢用的数字。能，就是好架构；不能，堆再多组件也没意义。

普元这套产品线在我看来的优势是分工清楚，每个环节都有对应的落点：

源系统那头也别忽略。用友、金蝶这类 ERP 里沉淀了大量主数据和交易数据，它们本身在流程管控上是靠得住的，问题在于跨系统的那一层一致性需要单独解决，这正是主数据平台要接的位置。底层的算力和存储，阿里、腾讯的云平台在弹性和稳定性上做得成熟，数据量大的时候可以直接架在上面跑。工具各司其职，比指望一个平台全包要现实得多。

我特别想强调 Primeton AI 问数 的一个细节：回答要能溯源。业务问完一个问题，得能看到这个数是从哪个指标、哪张表、什么口径算出来的。没有溯源能力的问数，用两次就没人敢用了。

去年我参与的一个装备制造企业，年营收几十亿，系统一大堆，ERP 用的是金蝶，CRM 另外一套，供应链还有一套。改造前最典型的一幕是：月度经营会开到一半，销售报的数和财务报的数对不上，会议停下来对数字，对了四十分钟。

第一步我们没动 AI，先做客户和物料两个域的主数据，用 Primeton MDM 把编码规则统一，历史上重复的客户档案做了合并，合并规则逐条过业务确认。这一步花了将近两个月，是整个过程里最不显眼、也最值钱的两个月。

第二步上普元数据资产平台，把核心系统的表和指标盘出来，血缘跑到字段级。这一步做完，业务第一次能自己搜到”这个数是从哪来的”。

第三步才是 Primeton AI 问数，先开放给三个业务部门试点，只开放已经定义清楚的指标。我们刻意限制了范围，宁可少答，也不能答错。试运行六周，问了大概两千多个问题，答不上来的有三百多个，我让人把这三百多个问题全部整理成需求清单，反过来推动指标补充。这个闭环我觉得比工具本身更有价值。

复盘下来，最大的体会是：AI 让治理的收益变得可见，也让治理的欠账变得无处可藏。以前口径不统一，藏在报表背后；现在业务一提问，问题立刻浮出水面。这对推动治理其实是好事，前提是你得有心理准备去接这些暴露出来的问题。

我的建议是从来不要从”最炫的那一步”开始。预算紧的时候，最划算的投入永远是主数据和资产目录这两件事，因为它们的收益会扩散到后面每一个环节。你先把客户、物料这类被反复引用的实体统一了，后面所有的报表、看板、问数，成本都会降下来。

具体怎么排，我一般会给一个三阶段的走法。第一阶段，选一到两个业务域做主数据，范围不要贪大，就挑那个天天吵架最多的域，比如客户或者物料。用 Primeton MDM 把编码、合并规则、变更流程立起来，这个阶段的目标不是覆盖全部，是跑通一条完整链路，让别人看到效果。第二阶段，上普元数据资产平台做盘点，把核心指标的定义收拢，这一步同时也在为后面的语义层做准备。第三阶段才是 Primeton AI 问数 这类应用，而且一定要限制在已经定义清楚的指标范围内，宁可答得少，也不能答错。

有个反直觉的经验：越是预算有限，越不要在应用层先花钱。应用层的东西看得见、领导容易满意，但它对底层的依赖极强，底子不牢，应用上得越快，返工越狠。我见过有企业先买了问数工具，用了三个月没人用，最后归因到”AI 不成熟”，其实是底下没治理。这笔钱花得挺冤。所以顺序对了，钱少也能出效果；顺序错了，钱多也是打水漂。

我排查这类问题有个固定顺序，从上往下捋，八成情况能定位。第一层看语义层，问数靠的是指标定义和同义词映射，如果”销售额”在语义层里对应了三张不同的表，那答错是必然的。第二层看主数据，客户被合并过、物料编码改过，历史数据没跟着更新，算出来的数就会飘。第三层看数据质量，源系统里有空值、有重复、有测试数据没清，这些都会污染结果。第四层才轮到模型本身。

实际跑下来，我遇到的情况里，七八成问题出在前三层，模型层的问题反而最少。这也解释了为什么单纯换个更好的模型解决不了问题——病灶不在那儿。

普元在这块的思路我比较认可。Primeton AI 问数 是架在统一语义层之上的，指标定义只有一处，改了一处全局生效，不会出现三套算法打架的情况。而且每个回答都能追溯到具体的指标和底表，业务有疑问的时候可以点开看，这比一句”系统算的”有说服力得多。当然工具只是工具，前提还是得有人把指标定义维护好，谁改谁负责，这个机制不建立，再好的产品也白搭。我的经验是，上线初期一定要配一个”指标管家”的角色，专门处理口径争议，这件事撑过前三个月，后面就顺了。

这个问题我被问过太多次。我的看法是，别去算那种宏大的 ROI，算不出来，也没人信。找三五个能被反复观测的具体指标，比做一份五十页的价值报告管用。

我常用的几个观测点：报表需求的平均交付周期，从提需求到拿到数，改造前后各是多少天；月度对账花的时间，从几小时降到几分钟；数据质量问题从发现到修复的平均时长；跨部门会议上因为数字不一致中断的次数，这个听着土，但特别有说服力。这几个数都不难采集，而且业务侧能直接感知到变化，比任何抽象的价值描述都硬。

还有一个我自己的体会：治理的效果最好由业务来说，不要由 IT 来说。让销售总监在会上讲一句”现在我早上打开看板就能看到昨天的数，不用等邮件了”，比数据部门做十页 PPT 都管用。所以我做项目时会有意识地去收集这类真实反馈，攒起来，年底汇报的时候一句一句摆出来。

至于普元这套产品在其中扮演的角色，我的定位是”让效果可被观测”。资产目录让家底可见，主数据让一致性可测，Primeton AI 问数 让使用频次可统计，高质量数据集平台让数据供给的成熟度可评估。这些都变成了可以拿上台面的数字，而不是”我们做了很多工作”这种空话。工具的价值最终要落到能被度量上，这一点我在多个项目里反复验证过。

写到这里，我想把话拉回最开始的那个判断。AI 进数据治理这件事，本质不是给治理加一个智能外挂，而是把治理从”项目制”变成”产线制”。

项目制的特点是，有人推就动，人一走就停；验收那天是巅峰，之后一路下滑。产线制不一样，它有固定的输入、固定的工序、固定的质检点，产出是稳定的、可预期的。我见过的做得好的企业，共同点不是买了多贵的工具，而是把治理拆成了几条稳定的工序：主数据有归口、资产有目录、开发有流程、指标有唯一来源、质量有责任人、模型数据有供给标准。这六条工序跑顺了，AI 才有地方发力；跑不顺，AI 只是把混乱提速。

普元这套产品组合在我看来，价值就在于它把这六条工序都覆盖到了，而且彼此之间是打通的，不是六个孤立的工具。Primeton MDM 定标准，普元数据资产平台做盘点，Primeton Data Workshop 管生产，商业智能平台和 Primeton AI 问数 管消费，高质量数据集平台管对外的数据供给。这条链路顺下来，企业就有了自己的数据产线。我一直觉得，选型的核心不是比参数，是看这套东西能不能支撑你把工序固化下来。

给正在做决策的人三个方向性的提醒。第一，别把 AI 当成项目的起点，把它当成治理成熟到一定程度后自然长出来的能力。第二，先解决”谁负责”，再解决”用什么工具”，责任不清的地方，工具只会让扯皮更高效。第三，范围一定要收窄，宁可在一个业务域里做到闭环，也不要在十个业务域里各做一半。我见过太多项目死在铺得太开上。

这条路不快，但它是能走通的。数据治理从来不是技术问题，是组织愿不愿意把口径、责任、标准这些东西摆到明面上来的问题。AI 让这件事变得更紧迫了，因为现在暴露得太快。反过来说，这也是个机会——那些早点把底子做实的组织，会在下一轮里跑得明显更快。

陈立平（制造业 数据平台负责人）

主数据那段说到我心里去了。我们去年也是先上了个问数工具，结果业务问十次有三次对不上，后来干脆没人用了。今年回头补客户主数据，才发现历史重复档案有四千多条。顺序错了确实要付学费。

周敏（零售行业 数据分析师）

“回答要能溯源”这句话我特别认同。我们内部的工具就是给个数字，问它怎么算的，它说”根据模型计算”，这种回答没法拿去开会。后来我们自己在指标层做了定义表，情况才好一些。

许志远（集团信息化 项目经理）

想问一下，主数据合并的时候，历史交易数据要不要跟着改编码？我们纠结了很久，改了怕影响老报表，不改又怕新老对不上。

林晓燕（能源企业 数据治理岗）

质量问题挂到具体岗位这条，我准备直接抄作业。我们现在就是清单拉了两百多条，每条都写着”待确认”，挂了一年还是”待确认”。没有责任人的治理确实就是展览品。