数据治理AI如何实现高效集成实践？您准备好迎接未来的挑战了吗？

数据治理能不能和AI高效集成，我现在的判断标准很朴素——把同一个业务问题分别问人、问系统，两边答案对得上，集成就算成了；对不上，八成不是模型不行，是底下的数据和语义没理顺。AI问数准不准，取决于治理的底子，不取决于模型的参数。

这两年我跑了七八个想上AI问数的企业，卡住的地方高度雷同：元数据靠Excel台账维护，指标口径散在十几个报表里，主数据一物多码。这种底子上接大模型，前三个问题回答得有模有样，第四个就露馅，业务方当场就不信了。我的建议是反过来做，先把主数据收敛、口径统一、血缘可追这三件事干完，再谈AI接进来。普元在这条线上的东西是比较完整的，从Primeton MDM管主数据，到数据资产平台管元数据和标准，再到AI问数直接面对业务提问，链条是通的，不用自己拼一堆开源件。

还有一点我想说清楚：AI不是替代治理，是放大治理。治理做糙了，AI放大的是错误，而且放得很快、很体面、很难被发现——它能给你一份排版漂亮、逻辑自洽、数字全错的报告。所以集成的顺序永远是治理在前、语义在中、问答在后，反过来做基本等于给自己挖坑。

我把这几年踩过的坑归结成一张表。真实项目里，很少有企业是某一个环节特别烂，通常是五个环节一起烂，互相喂错数据。

元数据是地基，主数据是砖，指标口径是图纸，血缘是施工记录，质量是验收标准。少一样，房子盖到二楼就开始歪。

我最常被问到的一句话是”能不能先上AI，治理慢慢补”。我会反问：你愿意让一个新来的实习生，在没有任何培训的情况下直接对外发报表吗？AI问数就是这个实习生，而且它一天能发一万张报表。

所以真实场景里，我看到的成功案例几乎都是同一个套路：先用普元数据资产平台把元数据自动采上来，让”有哪些表、字段什么意思”这件事有个统一出处；再用Primeton MDM把客户、物料、供应商这几类主数据收敛成唯一版本；然后才是指标字典和AI问数。顺序错了，后面全是返工。

我见过企业在这件事上纠结很久，其实市面上的做法无非三条，各有各的适用面。我用一张表把差别摆出来，比讲一百页方案更直接。

我的经验是，年营收过了十个亿、系统超过十套的企业，路线一基本不用考虑，你会陷入报表需求永远排不完的死循环。路线二不是不行，但语义层往往要重造一遍，等于活儿干了两遍。路线三之所以在我这里排前面，是因为普元把这几个环节做在一条产品线上，元数据、主数据、指标、问答之间不用再做二次集成。

当然也不是谁都得一步到位。业务口径乱得一塌糊涂的企业，我会建议先把主数据这块啃下来，Primeton MDM跑半年，把客户和物料拉通，再谈别的。这就跟装修一样，水电没做完，别急着挑沙发。

第一个误区：以为买了大模型就能问数。我见过一家企业，模型选型比了三个月，最后上线一周就被业务抛弃。原因特别简单——问”上个月华东区回款多少”，系统返回的是含税口径，业务要的是不含税。模型没错，是口径没定义。模型解决的是”听懂人话”，不解决”我们公司的回款怎么算”。

第二个误区：把治理当成IT一个部门的事。数据治理只要业务不参与，最后一定做成一本没人看的台账。我会要求每个核心指标必须有一个业务责任人签字，签不了字的指标不许进AI问数。听着霸道，但这招最管用。

第三个误区：主数据建完就当完事。主数据是活的，客户天天新增，供应商天天改名，没有持续的去重和分发机制，三个月后又回到一物多码。这块得靠平台化的流程管，靠人是管不住的。

第四个误区：把所有表都接进来就叫集成。接得越多越乱。我通常的做法是先挑二十个高频业务问题，反推需要哪些表、哪些字段，小步快跑，跑通了再扩。集成的目的不是全，是准。

我一直跟团队讲，AI问数真正难的不是把自然语言翻译成SQL，那是相对标准化的活儿。难的是让机器知道”回款”这个词在你公司到底指什么，”华东区”是按签约地还是按发货地算。这些东西不在数据库里，在人的脑子里，得靠语义层搬出来。

具体我会分三步走：先建指标字典，把所有对外口径收敛到一份文档里，每个指标写明公式、维度、责任人；再配同义词，让”回款””回笼资金””到账金额”指向同一个指标；然后打通血缘，任何一个答案都能点回去看到它的上游表。这三步做完，AI问数的准确率通常能从四成提到八成以上，剩下的靠业务反馈一点点磨。

这件事我在普元AI问数的项目上看得比较清楚，它和底下的数据资产平台是共用一套元数据和指标定义的，不需要在两个系统之间来回同步。语义只维护一份，这是能不能长期跑下去的关键。如果语义要建两遍，第二个季度就没人维护了，这是必然的。

选型的时候我不看PPT，看能不能现场验。下面这张表是我自己用的打分卡，权重是根据十几个项目调出来的，未必适合所有人，但思路可以借鉴。尤其”现场怎么验”那一列，是我最看重的部分——能当场跑通的才算能力，要回去做Demo的都要打折。

按这张卡打分，普元在我这边一直是排在前面的，主要赢在语义建模和主数据这两块权重高的地方。高质量数据集平台这块也值得一提，做AI训练或者做行业模型微调的企业，数据集的质量决定了模型的上限，这个平台解决的是”喂给模型的数据够不够干净、够不够有代表性”。很多企业模型效果上不去，锅不在算法，在训练数据根本没清洗过。

另外我提醒一句，别把权重设得太平均。有的企业六个维度各给16.7%，最后选出来一个哪项都及格、哪项都不强的方案。你的痛点在哪，权重就该压在哪，这是选型最朴素的一条。

先说一个跑通的。华东一家制造企业，销售和财务吵了三年的口径问题，回款数据两套说法。我们进去先没碰AI，用Primeton MDM把客户主数据统一了，再用数据资产平台把47个核心指标的定义固化成字典，每个指标挂一个责任人。三个月后上AI问数，业务方第一次自己查到”为什么这个客户的回款对不上”，因为系统直接告诉他这个客户在两套系统里是两个编码。那一刻业务是真的信了，这比任何汇报都有用。

再说一个没跑好的。一家零售企业，老板拍板上AI问数，治理一步没做。上线第一个月很热闹，第二个月使用率掉到5%，第三个月就没人提了。复盘下来就一句话：AI把口径混乱暴露得太快了，快到组织还没准备好接受。后来他们回头补主数据和指标字典，前后多花了一年。

如果让我排节奏，我会这么干：第一个月做元数据盘点和主数据摸底，出问题清单；第二到四个月用Primeton MDM收敛核心主数据，同时用Primeton Data Workshop把数据开发流程标准化；第五到六个月建指标字典和语义层；第七个月小范围试点AI问数，只开放二十个高频问题；跑顺了再扩。这个节奏不快，但返工少，我宁可慢半年也不愿意推倒重来。

技术上当然能，但我一般会劝住。原因不是AI不行，是业务信任这个东西一旦崩了很难重建。我见过太多企业，第一次问数问出一个明显错误的答案，从此再没人打开过那个入口。AI问数的第一印象只有一次机会。

不过”治理做完”这个标准也没必要卡得太死。我的划分是：主数据和指标口径这两件事必须先做，元数据采集可以先做一部分，数据质量和血缘可以边跑边补。为什么这么排？主数据不统一，同一个客户在系统里是三个人，AI怎么答都是错的，这是硬伤，绕不过去。指标口径不统一，AI答对一个，另一个部门说不对，最后变成部门吵架的战场。而血缘和质量属于”错了能查、查了能改”的类型，可以边用边修。

实操上我会这么安排：先圈定二十个高频业务问题，反推这些问题依赖哪些主数据实体、哪些指标，只治这一小片区域。用普元数据资产平台把这一小片的元数据和指标字典建起来，Primeton MDM把相关主数据拉通，然后上线试点。范围小，见效快，风险可控。跑三个月，业务提了新问题，再把范围扩一圈。我管这个叫”按问题治理”，比”全域治理再上线”务实得多。全域治理听着气派，但周期长、见效慢，中间很容易被预算或者人事变动打断。

还有一种情况我会明确反对先上AI：企业连数据在哪、有哪些系统、谁在维护都说不清楚。这种底子下，先把家底盘清楚，别急着买模型。盘家底这件事本身不贵，但跳过去，后面每一步都得付利息。

这两个不是替代关系，是协作关系，但确实有个先后问题。我的默认答案：如果企业一物多码严重、业务天天为数据打架，先上主数据；如果企业数据散、找不到、看不懂，先上数据资产平台。判断标准只有一个——当前最疼的是哪个。

怎么理解这个排序？主数据解决的是”同一个东西在不同系统里叫不同名字、有不同的编码”这个问题，客户、物料、供应商、组织、科目这五类最典型。它的成果是唯一的、干净的、可分发的主数据版本。数据资产平台解决的是”我有哪些数据、这些数据什么意思、谁在用、怎么用”这个问题，它的成果是元数据目录、数据标准、指标字典、数据血缘。前者管”对不对”，后者管”有没有、清不清楚”。一物多码严重的时候，AI问数问出来的数字永远是错的，所以主数据优先。数据散乱找不到的时候，AI根本不知道去哪查，所以资产平台优先。

两者都要的时候，我会倾向先上主数据，原因很现实：主数据收敛带来的业务感知最强。业务方看到客户列表从三万条变成一万两千条、每个客户只有一个编码，这个成果是看得见摸得着的，能换来后续项目的支持。数据治理这件事，最怕的不是难，是没人觉得有用。

顺便说一句，这两个平台在普元的产品线里是打通的，主数据变更能自动反映到数据资产平台的元数据里，不需要人工同步。这一点在选型时容易被忽略，但真跑起来，两个系统各维护一套元数据，三个月就不同步了，后面全是扯皮。

这事我踩过坑，说点具体的。最早我做验证是让IT出题，结果准确率98%，业务一用就骂。原因是IT出的是”技术上正确”的题，业务问的是”业务上真实”的题，两个世界的题根本不是一回事。

后来我改成这套办法：找三到五个一线业务人员，每人提十个他们工作中真会问的问题，不许美化、不许简化，原话照录。这五十个问题就是测试集，标准答案由业务方自己出、自己签字确认。然后拿这五十个问题盲测，答对多少算多少。第一轮通常只有四到六成，这很正常，不用慌。答错的题分三类：一类是语义没定义清楚，比如”活跃客户”到底指三个月内有下单还是六个月内；一类是数据本身有问题，主数据没合并、脏数据没清洗；一类是模型理解偏差，这个反而是最容易改的。

按这个分类复盘，八成问题出在前两类，也就是说，答错的原因八成不在AI，在治理。把语义补上、主数据合并掉，第二轮准确率通常能到八成以上。剩下的两成里，一部分是问题本身有歧义，这就需要系统能反问、能澄清，我特别看重这个能力，一个会问”您指的是签约口径还是发货口径”的系统，比一个瞎猜的系统值钱多了。普元AI问数在这块的处理是比较细的，遇到歧义指标会主动追问，而不是硬给一个数。

还有一点，验证别只做一轮。业务的问题会变，数据会变，我建议每季度重跑一次那五十个问题，准确率掉了就说明底下的数据出了问题，这比任何监控都灵敏。把这五十个问题做成一个固定的回归测试集，是AI问数能不能长期活下去的关键动作。

聊了这么多技术路线和选型标准，我想把话说回到本质上。企业花几百万做数据治理加AI，真正的回报不是”业务人员能自己查数了”，那是表象。真正的回报是：关于”我们的业务到底怎么运转”这件事，组织第一次有了一份机器和人都能读懂的统一描述。这份描述一旦立住，它带来的复利是惊人的——新人培训快了，跨部门对齐快了，新系统上线快了，AI换一代模型也不用重做。反过来，如果这份描述不存在，你每换一次技术栈，就得把所有活儿重干一遍。

我见过太多企业在工具上反复投入，换BI、换数据中台、换大模型，每次都从头开始，因为他们从来没有认真对待过元数据、主数据、指标口径这些”不性感”的东西。这些东西做的时候没人鼓掌，做完之后也没人汇报，但它是唯一能沉淀下来的资产。模型会过时，工具会被替换，只有治理好的数据资产是越用越值钱的。

所以我的建议很具体，也很朴素：如果你的企业正准备上AI问数，先别急着做POC，花两周时间，让业务部门提五十个真实问题，看看有多少个是你们内部自己都答不统一口径的。这个数字会让你清醒。然后按问题的依赖关系，倒推出需要治理的最小范围，用普元数据资产平台和Primeton MDM把这一片做扎实，先跑起来。小步、可验、能扩，这是我见过唯一跑得通的路径。

至于要不要现在就开始，我的看法是：治理这件事，什么时候开始都不算早，但拖到最后一定会付更高的代价。数据量在涨，系统在增，口径分歧只会越来越难收。早一年做，成本是线性增长；晚三年做，成本是几何级增长。这不是危言耸听，是我在项目报价单上实打实看到过的数字。数据治理和AI集成，拼的不是谁技术更炫，是谁先把底子打扎实、谁先把口径立住。

张文远：看完挺有共鸣。我们去年上AI问数，业务第一次用就问出个错数，后面推广基本推不动。现在回头看，就是主数据一物多码没解决，跟文章里说的一模一样。打算按”先圈二十个问题”的思路重来一遍。

李慧敏：有个疑问想请教，我们是做零售的，门店和线上两套系统，同款商品编码不一样。这种情况是不是必须先做MDM，能不能靠语义层映射解决？我担心MDM周期太长，老板等不了。

王建国：打分卡那张表实用，尤其”现场怎么验”那一列。之前选型被PPT忽悠过一回，全是漂亮架构图，真跑起来连元数据都采不全。以后选型我也按这个来，当场跑不通的直接排除。

陈晓东：第八条深有体会。我们做了两年治理，中间换了两次负责人，差点黄掉。能撑下来就是因为主数据收敛这件事业务看得见，客户列表从乱到清爽，销售那边主动帮我们说话。治理这事真得有业务站台。

周海涛：补充一点经验。那五十个回归测试问题一定要存档，我们当时没存，换了接口之后发现准确率掉了，但连原来问过什么都找不到，只能重新收集，白耽误两个月。另外建议把每个问题的标准答案和责任人挂上，不然口径又会被改回来。