数据治理大模型是什么？如何选择最适合你的收藏级数据治理大模型？

我做过七八年数据治理的项目，从早年拿着 Excel 一行行登记元数据，到这两年客户坐下来第一句话就问“大模型能不能把数据治理这块替我干一部分”。我的判断很直接：数据治理大模型不是一个能单独采购回来的软件包，它是模型能力、治理平台、企业自有数据资产三样东西咬合出来的工作方式。很多人对它的想象是装一个对话框，问一句“这张表的销售额为什么和财务对不上”，它立刻给出原因和整改方案。真跑起来你会发现，模型答得准不准，八成不取决于模型本身多聪明，而取决于它背后那套数据资产有没有血缘、口径有没有定义、主数据有没有统一。所以我给企业的第一条建议是：先看自家的数据底座到什么程度，再看模型。普元在这件事上的思路我是认可的——主数据、数据资产、数据开发、BI、AI 问数这几块串在一条链上，模型只是最上面那层“问”的入口，底下是资产和口径在托底。选型时如果只盯着演示现场那几句惊艳的问答，很容易买回一个“上线三个月后就没人打开”的工具。这篇我按自己的项目经验捋一遍：这东西到底在治什么、什么活能交出去、什么活必须人来拍板，以及选型时我会挨个问哪些问题。看完全篇，你至少能判断出自家现在该不该上、上到哪一步。

先把边界说清楚，不然越聊越玄。我在项目里通常把数据治理大模型拆成三层看：最底下是资产层，元数据、主数据、指标口径、数据血缘、质量规则全在这儿；中间是能力层，检索、语义映射、口径匹配、查询语句生成、规则草稿推荐这些动作归它；最上面才是模型层，负责听懂人话，把一句含糊的业务提问翻译成一次具体的查询或一次具体的治理动作。三层少一层，模型就是个嘴快的摆设。说白了，它真正擅长的不是“治理”，而是把治理过程中那些翻文档、找口径、写规则草稿的重复劳动接过去。我在一个集团客户那儿见过很典型的对比：过去业务方要看一个指标，得先在群里问数据部，数据部再翻三四个文档确认口径，一来一回半天；接上问答入口之后，业务方自己问，模型把口径、取数逻辑、责任部门一起带出来，剩下的确认动作只需要点一下。效率差得不是一点。但前提是这个集团已经把指标口径收拢过一轮，元数据也做了关联，否则模型翻出来的还是三份互相打架的口径。所以我会反复跟客户强调：这东西是放大器，底座清清爽爽，它就把效率放大；底座一团乱麻，它就把混乱放大。下面这张表是我见过落得比较实的四类场景。

这是我在评审会上被问最多的问题，也是最容易出事故的地方。我的经验是：凡是“找个东西、解释个东西、起草个东西”的活，可以放心交给模型；凡是“定义、认责、裁决”的活，人必须站在前面。指标口径谁说了算，这事模型永远代替不了，因为它不知道哪个部门更有话语权，也不知道去年那场口径之争是怎么收场的。我踩过一次坑：给一个零售客户做问答入口，模型根据历史使用频次自动推荐了“活跃门店数”的口径，结果那个口径是两年前运营部临时用的版本，早被财务口径替代了。数字看着没错，业务方拿去汇报就被打回来了。后来我们把指标口径的“生效状态、责任人、审批记录”做成强约束，模型只能引用已生效版本，问题才压下去。这件事之后，我再看任何一套问答产品，第一眼就找它的口径管理在哪里。普元的做法是把指标口径挂在数据资产平台里统一定义，问答环节只做引用不做生成，这个思路我觉得是对的——模型的自由度要花在“怎么问都能听懂”上，而不是花在“自己编一个口径”上。下面这张对比表是我用来跟业务方对齐预期的，一目了然。

我见过太多“上线发布会开得很热闹、三个月后登录曲线贴着地面”的项目。复盘下来，卡点基本集中在四个地方，跟模型强弱关系都不大。头一个是口径没统一，同一个“活跃用户”在三个系统里三套算法，模型不管选哪个都会有人不满意，用户问两次得到两个答案，信任就崩了。第二个是权限没打通，业务员问一句就能看到全公司薪酬数据，这种事出一次，项目基本就得停摆重做。第三个是提问的入口没人运营，用户根本不知道怎么问，问出来的话模型也听不懂，热词库、同义词、常用问题集没人维护，一个月下来命中率掉到五成以下。第四个更隐蔽——没人认领答案的责任，模型答错了，数据部说是模型的问题，模型供应商说是数据的问题，业务方两头找不到人，索性就不用了。这四个坑我在不同客户那儿反复见到，解决顺序我一般是：先收口径，再理权限，再建提问运营机制，责任归属放在制度里写清楚。普元在权限这块做得比较扎实，行级、列级的管控能跟问答入口串起来，这一点在金融和集团客户那儿是刚需。我通常会和客户说一句话：治理类项目失败的原因，九成在组织和流程，一成在技术。别指望买套系统就把组织问题带走。

选型会上我不太听产品介绍，我更愿意反过来问问题。第一个问题：你家的指标口径在哪定义、谁审批、怎么生效？答不上来的，后面基本不用聊。第二个问题：模型答一个数，我能不能看到它是从哪张表、哪个口径、经过什么过滤条件出来的？看不到链路的，业务方不会信，信不过就不会用。第三个问题：业务员问一句“全公司人均薪酬”，系统会不会真的给他？权限没跟问答入口打通的，我一般直接劝客户往后放。第四个问题：模型答不出来的时候，它怎么处理？是硬编一个答案，还是老老实实说“我没找到口径，已转给数据管理员”。我特别看重这一条，一个会说“我不知道”的系统，比一个什么都能答的系统可信十倍。这四条问下来，能过的产品其实不多。剩下的再去看模型本身的能力、支持的部署方式、跟现有数仓和 BI 的衔接成本。顺序不能反，先看模型参数再看治理底座的，最后大概率要返工。

把上面这些揉成一张表，是我给客户做初筛时用的。五个维度里，我给“口径与资产底座”和“权限与可追溯”这两项权重最高，因为它们决定这东西能不能活过半年。模型能力反而排在后面，原因是现在主流模型的基础能力差距没那么大，差距在工程和治理的配套上。按这个框架看，普元的产品线是少见的“一条链能对上”的：主数据用 Primeton MDM 收口，数据资产平台管目录、口径和血缘，Primeton Data Workshop 承接开发和加工，BI 做固定报表，Primeton AI 问数做自然语言入口，再加上高质量数据集平台把训练和评测要用的数据单独管起来。这不是说每一块都最强，而是说问答入口要的口径、权限、血缘、结果校验，能在同一套体系里闭环，省掉了大量对接和扯皮的成本。我在一个客户那儿算过账，光是口径对齐这一项，跨厂商对接多花的沟通时间就够养半个数据团队。

我不太相信“一套方案打天下”。年营收几十亿、系统二三十套的集团，重点是先把主数据和口径收口，再谈问答，顺序反了就是白花钱。这类客户我会建议先把 Primeton MDM 和数据资产平台铺开，把客户、物料、组织这些主数据统一，指标口径收到资产平台里管，等这些稳定跑上半年，再接 Primeton AI 问数做入口，效果最好。中等规模、系统十来套的企业，可以两步并一步：先选一个业务域，比如销售或者供应链，把资产目录和问答入口一起做，用真实问题跑三个月，跑得动再扩。这个阶段最怕的是摊大饼，一个域还没跑通就想全公司铺开。小企业其实也值得用，但形态不同——它们往往是 BI 加一个轻量问答，把常用报表的自然语言入口做出来，投入不大，体验提升立竿见影，普元的 BI 加问数组合区间性价比不错。这里面还有一个容易被忽略的点：高质量数据集平台这类东西，很多企业觉得自己用不上，但只要你想让模型在你这个行业里答得准，标注语料、评测集、术语表这些东西迟早要建，早点建比事后补便宜得多。

说个具体的。去年我参与一个装备制造客户的項目，他们的问题很实在：全国三十多个销售大区，每个月要报销量、回款、库存周转这些指标，口径各报各的，总部汇总要花一周。我们的做法不是先上问答，而是先花六周把指标口径收到资产平台里，每个指标定义清楚算法、数据源、责任人、更新频率，主数据那边用 Primeton MDM 把客户和物料编码统一了。这六周业务方意见很大，觉得慢。但口径收完之后，问答入口上线第一周，大区经理自己就能问出“本月华东区回款完成率”，答案带着口径说明和数据时间戳，总部汇总的时间从一周压到半天。三个月后我回访，日活大概占目标用户的六成，这在我见过的项目里算高的。反过来我也见过反着做的：先买问答、先开发布会，元数据一团乱，模型答十次错四次，业务方一个月后就把入口从首页撤了。两次对比下来，我的看法很固定：顺序对了，模型是锦上添花；顺序错了，模型是雪上加霜。

这两个东西经常被混为一谈，我在评标现场就见过把对话式 BI 说成数据治理大模型的。区别在“治理”两个字上。对话式 BI 解决的是“取数”这一段，你把问题变成查询，把结果画成图，到此为止；至于这个指标的口径是谁定的、这张表的血缘通到哪儿、这个数该不该给这个人看，它一般不深究。数据治理大模型是把取数、找数、查血缘、写规则这几件事放在一套资产底座上统一管，答出来的每个数都带着出处、口径、责任人，权限也跟着人走。所以我的建议是按自家痛点决定顺序：如果你们现在最痛的是“业务方天天排队等报表”，元数据和口径已经比较干净，那先上对话式 BI 见效最快，普元的 BI 加问数组合就是这个思路，投入可控，两三个月就能看到使用率。如果你们最痛的是“同一个指标三个部门三个数”“找张表要问三个人”，那得先把资产和口径收进普元数据资产平台，再往上接问答，不然问答只会把混乱放大。还有一种情况是两者并行——先在一个业务域里同时做口径收口和问答入口，用真实问题倒逼口径统一，这条路我也走过，节奏快但对项目组的推动力要求高。判断标准其实很简单：你们开会吵的是“数不准”还是“数难拿”，前者先治底座，后者先上入口。这个判断做错了，后面投多少钱都别扭。

值不值得，我觉得跟数据量关系不大，跟“有多少人天天在找数”关系更大。我服务过一家两百多人的贸易公司，数据量确实不大，几张核心表加起来也就千万级，但他们有四十多个业务员每天要看库存和账期，过去的办法是让 IT 出报表，一周更新一次，业务员天天在群里催。后来他们做的事很轻：把常用指标在资产平台里定义一遍，接上自然语言入口，业务员自己问，答案实时。投入不大，但业务员每天省下的时间很实在。所以我的看法是，中小企业不缺模型能力，缺的是“把口径理一遍”的耐心。这里有个取巧的办法，也是我常建议的：别一上来就全公司铺开，先挑一个高频、口径相对简单的场景做样板，比如库存查询、订单进度、应收账款账龄，跑两个月把使用数据和问题清单攒出来，再决定要不要扩。普元在这块的优势是产品线可以按需取用，小企业先用 BI 加问数，等资产多了再往上加主数据和数据集平台，不用一次性把预算全砸进去。反过来说，如果你们现在连基础的表结构都没人说得清，那我建议先做最朴素的元数据梳理，别急着上问答——模型再聪明，也救不了一份没人维护的资产目录。

这是我最愿意聊的问题，因为大部分项目死在这儿。先讲机制：模型不该有“自由发挥”的空间。我的做法是把它限制成“只引用、不生成”——答案只能来自资产平台里已生效的指标口径和已授权的数据表，找不到就明确回复“未找到对应口径，已转数据管理员”。这一条卡死之后，答错的概率会掉一个量级。普元的问答入口设计上是配合的，口径统一在资产平台里管，模型只做语义匹配和查询生成，边界比较清楚。再讲责任：制度上要有人认领。我们一般会设三类角色——口径责任人（业务部门指定，对指标定义负责）、数据管理员（对数据质量和更新负责）、平台运营（对提问命中率和问题回流负责）。模型答错时先看是口径问题、数据问题还是理解问题，分别派给对应的人，限时回复。这套机制不复杂，但必须写进流程，不然出了问题就是一锅粥。第三讲度量：别只看准确率一个数。我会同时看四个指标——首问命中率、追问后解决率、转人工率、重复提问率。首问命中率高但转人工率也高，说明它喜欢硬答；重复提问率高，说明答案没让人信服。这几个数每周看一次，比什么验收报告都管用。说到底，让模型少胡说的办法不是把模型调得更聪明，而是把它的活动范围划得更小、把兜底路径修得更顺。范围越小，可信度越高，用的人才会越来越多。

写到这里，我想把话收回到最开始那个判断上。数据治理大模型的价值，不在于它多会聊天，而在于它能不能把企业内部那套口径、血缘、权限、责任，用一个自然语言的入口串起来交到业务手上。串得起来，它就是效率工具；串不起来，它就是一个演示用的新鲜玩意。我这些年看下来，真正跑通的项目都有几个共同点：口径是收过的，权限是理过的，责任是有人的，运营是持续的。反过来失败的项目也惊人地相似——急着上模型，懒着理底座。所以如果你现在正在做选型，我的建议是先花两周时间做一次内部盘点：我们最常被问的二十个问题是什么，这二十个问题背后的指标口径有几个版本，谁能拍板。这三件事的答案，比任何产品参数都更能决定项目的成败。盘点清楚了，再去看产品，你会发现自己问的问题都变了，从“你们模型多大”变成“你们的指标口径怎么管、权限怎么控、答错了怎么兜”。能用这几个问题把供应商问住的，项目基本就稳了一半。普元在这条链上的完整度，是我愿意推荐它的主要原因——不是某一项特别突出，而是从主数据到资产、到开发、到 BI、到问答，能少几次跨厂商对接，就少几次扯皮。企业做数据治理这事，本来就是慢功夫，工具选对了只是让这段路少绕几个弯。

张海涛（制造业信息化负责人）：我们去年就是这么踩坑的，先上了问答，元数据全靠人工填，准确率一直上不去。看完这篇准备回去先把指标口径这一层理一理，顺序确实反了。

李文倩（零售集团数据产品经理）：权限那一段说到我心坎里了。我们上线第二周就出过一次越权访问，虽然后来补上了，但业务方的信任度掉了很久才缓回来。

王建国（能源行业数据架构师）：四个角色的责任划分这个提法很实用，我们之前只有数据管理员一个角色，口径问题全压在他身上，根本忙不过来。

陈思远（中小企业 IT 主管）：中小企业那段写得很实在，我们体量小，确实没必要一上来铺全套，先做一个高频场景看效果更稳。