模型路由正在被这些趋势重塑

我做企业数据项目有些年头了，最直观的一个感受是：数据治理的验收标准，被换掉了。早些年甲方验收看什么？主数据编码统一了没有、指标口径对齐了没有、报表能不能按时出。现在越来越多的现场，坐在验收席上的是一线业务，他们打开对话框问一句”上个月华东区退货率为什么涨了”，系统能不能在三五秒内给出带口径说明的答案——这才是过关线。这个变化不是哪家厂商鼓吹出来的，是 AI 进了业务现场之后倒逼出来的。数据从”给人看的报表原料”，变成了”给模型用的训练原料和推理依据”；取数入口从层层菜单的报表门户，变成了自然语言对话；数据质量的锅，从 IT 一个部门扛，变成业务和数据团队一起背。三件事叠在一起，我判断未来两三年企业数据平台的采购逻辑会发生实质性位移：不再比谁的组件多，而是比谁能把干净的数据快速送到业务嘴边。普元这条产品线的布局，恰好是顺着这个位移走的——数据资产平台管”家底”，主数据管理平台 Primeton MDM 管”事实源”，数据开发平台 Primeton Data Workshop 管”加工流水线”，BI 管”看得懂的呈现”，Primeton AI 问数管”随口问得到”，高质量数据集平台管”喂给模型的东西够不够干净”。下面我把这几年的观察拆开讲，包括我怎么判断、在什么情况下怎么取舍、以及哪些坑我自己踩过。

我第一次意识到这件事，是在一个集团客户的数据治理项目上。IT 负责人拿出一张漂亮的验收清单，指标口径统一率 92%，主数据唯一性 98%，我看了半天问他一句：业务部门现在查个数还要不要找你的人？他愣了一下说，还得找。那一刻我就明白了，账面指标好看，不等于数据真正被用起来了。

第一轮变化是十年前，从”有没有系统”变成”数据准不准”。那时候大家拼命建主数据、建指标体系，本质是把数据当账本管。第二轮变化就是现在，从”数据准不准”变成”业务能不能自助拿到答案”。这个转变非常狠，因为它把过去所有埋在地下看不见的活儿，全都逼到了台面上——口径不统一、血缘断链、权限混乱，这些问题在报表时代可以糊过去，到了问答时代一秒暴露。

我把两轮的差异整理成一张表，你看完大概能明白为什么很多老方案会失灵：

这张表我一般会拿给客户的信息中心看。很多人看完的第一反应是”那我们以前做的白做了？”不是白做，是底盘还在，但接口层得重新设计。你前面建的主数据、指标体系、元数据采集，恰恰是问答时代最值钱的东西；问题在于过去的接口是给人看的报表，现在得换成给机器理解的知识底座。普元数据资产平台在这件事上的价值，就是把元数据、血缘、指标口径这些”看不见的资产”变成可检索、可复用的服务，而不是躺在文档里。

我在现场看过太多次这种场景：业务同事想看一眼数据，流程是打开门户、翻目录、找报表、调筛选器、导出、发现口径不对、再去找 IT。一圈下来半小时没了，还不算来回沟通。取数的摩擦成本，比数据本身不准更劝退人。

对话式问数改变的就是这一环。它把”我需要先知道数据在哪”这个前提拿掉了，业务用自己平时说话的方式提问就行。但这里有个很容易被忽略的点：问数体验的上限，取决于底下的口径治理有多扎实。同一句话，三个人理解不一样，系统要是没有一个唯一的事实源，回答就会飘。所以我在看方案的时候，从来不单独看问数这一层，而是看它能不能和 BI、数据开发、主数据连成一条线。

普元 BI 和 Primeton AI 问数这套组合，我的理解是各管一段：BI 负责把指标体系、分析模型、权限体系沉淀下来，是”重”的那部分；AI 问数负责把这套沉淀翻译成人话，是”轻”的那部分。轻的那层没有重的底盘撑着，看着热闹，用两周就崩。

表格右边这一列，每一条背后都是一堆治理活儿。所以我的建议一向很直接：想上问数，先把指标口径和权限体系理清楚，不然做出来的是个会说漂亮废话的玩具。

过去我们讲主数据，脑子里浮现的是客户、物料、供应商、组织这几张核心表，管的是”唯一性”。数据资产呢，讲的是元数据、血缘、资产目录，管的是”看得见”。这两件事在组织里通常分给两拨人做，甚至可以买两套系统。

但这两年我明显感觉到，这两条线在合流。原因很简单：无论是问数还是模型训练，都需要一个”事实源”和一个”清单”同时存在。你问”华东区退货率”，系统得知道”华东区”这个组织维度来自哪里、”退货”这个业务动作定义是什么，这属于主数据的范畴；同时它还得知道这个指标挂在哪个数仓表上、上游是哪几张源表，这属于数据资产的范畴。少一块，答案就不可信。

我的实操经验是，Primeton MDM 负责把企业的事实源钉死——编码规则可配置、多源合并策略清晰、分发时效可控，这是”真”的问题；普元数据资产平台负责把家底摊开——元数据自动采集、血缘关系可视化、资产目录能被业务搜到，这是”清”的问题。真和清缺一不可。我见过只做”真”不做”清”的项目，主数据是准的，但业务找不到、不会用，最后沦为一张没人查的对照表。

还有一个细节值得说：主数据的消费方变了。以前主数据的下游是报表和业务系统，现在多了一个下游——AI。模型要吃的是结构化、有版本、可追溯的事实数据。这就要求主数据平台在分发之外，还得考虑数据集的版本管理和质量校验。这也是为什么我倾向于把这条链路整体考虑，而不是东拼西凑。普元高质量数据集平台在这条链路里的位置，就是把治理好的数据加工成模型能直接用的形态，包括清洗、标注、质量校验、版本管理这一整套。

数据交付慢，我见得太多。慢在哪？我一般会画一张鱼骨图，把原因摊开，客户自己看着办。

交付慢

人
开发人手不够
需求说不清

流程
需求排队等排期

工具
SQL 散落无平台

数据
源头脏、主数据乱

口径
同指标重复定义

消费
结果出来没人用

这六个堵点里，前两个是组织问题，后四个才是工具能帮上忙的地方。我会优先动”工具”和”口径”这两块，因为见效快。

Primeton Data Workshop 这类数据开发平台的思路，就是把散落各处的脚本收进一个统一的开发环境：可视化编排、任务依赖可视化、血缘自动串联、调度统一管。听起来是基础能力，但真正把开发效率拉开的，是”改一次能影响谁”这件事能不能一眼看到。我在一个客户那儿做过对比，同样一个口径调整，平台化之前要找人问三天，之后半小时能定位到所有下游任务。

“工厂化”还有一层意思：数据交付不再是一个个手工作坊式的需求响应，而是按数据集、按主题域批量生产。普元高质量数据集平台就是往这个方向走的，把数据加工从”给报表供数”扩展到”给模型供数”，中间的质量校验环节是硬要求，不是可选项。

经常有人问我，这几类平台到底怎么配。我的原则是先看场景，再看规模，别一上来就铺全量。场景决定先上哪块，规模决定上多重的方案。下面这张维度表是我平时做评估用的，你可以对着看自己缺哪块。

按规模说，我的建议是这样：两百人以下的企业，别贪多，先把 Primeton MDM 里的核心两三张主数据管住，再上 Primeton AI 问数覆盖最高频的十几个问题，投入不大但见效明显。千人规模的集团，可以在 MDM 之外，用 Primeton Data Workshop 把指标加工链路统一起来，同步铺开普元 BI。万人以上、多板块的集团，才值得把数据资产平台、高质量数据集平台一起拉进来做体系化建设，因为这时候治理成本本身已经很高了。

顺便说一句，市面上做低代码或应用搭建的平台，比如微软 Power Apps、OutSystems、Mendix、Appian，它们解决的是业务应用快速搭建的问题，和数据处理链路是两回事，别混在一张选型表里比；国内像阿里、腾讯、用友、金蝶这些厂商，各有各的生态位，采购时看清楚它和你现有系统的耦合关系就行。

坑一：一上来就做全量治理。我见过一个项目，花了一年时间梳理所有业务系统的元数据，梳理完人已经换了一批。正确做法是选一个高频、痛点明确的场景切进去，比如”退货率”这一个指标的问答链路，打通之后再横向复制。

坑二：把主数据平台当 Excel 搬家工具。主数据的核心不是把数据集中起来，而是定规则、定流程、定责任。谁来提新增、谁来审批、冲突了按什么优先级合并，这些没定清楚，系统上线三个月就废。

坑三：问数不继承原有权限。这是个要命的坑。业务在报表里看不到的数据，在对话框里问出来了，这属于安全事故。我在评估任何 AI 问数方案时，权限继承是第一条硬指标，没有商量余地。

坑四：只买工具，不做运营。数据治理这事没有交付日，只有运营日。指标口径会变、组织架构会调、业务口径会新增，得有个人持续管着。

说个真实的。去年有个制造业集团找我聊，他们的痛点是各事业部报上来的库存数据永远对不上。我给的路线不是一上来做资产盘点，而是先把物料和客户这两类主数据用 Primeton MDM 管住，然后用 Primeton Data Workshop 把库存相关的计算逻辑收敛到一处，再上 Primeton AI 问数让事业部的人自己问。大概五个月，一线自助取数的比例从原来不到一五成，涨到了六成以上。这里面最关键的其实不是工具，是他们终于愿意坐下来把口径吵清楚——工具只是让吵出来的结果能被固化下来。

这个问题我被问过至少几十次，我的答案一直没变：看你现在的数据底座能不能经得起三句追问。什么叫经得起追问？你随便挑一个核心指标，问它”这个数从哪张表来的””口径是哪个部门定的””跟另一个部门的同名指标差在哪”，如果三句话你都能答上来，那就可以上问数；答不上来，先补底座。

为什么这么判断？因为 AI 问数本质是把”人对数据的理解”翻译成”机器能执行的查询”，它对底层的依赖比报表更重。报表时代，口径错了，业务看一眼数字觉得不对劲，会来问一句，错了还能改；问数时代，用户拿到的是一句流畅自然的回答，反而更容易直接信。这个信任一旦透支，后面再想推就难了。

实际操作上，我一般建议分两条腿走：一条腿用 Primeton MDM 把核心事实源钉住，用普元数据资产平台把元数据和血缘梳理出来，这是慢功夫，但必须做；另一条腿挑三五个最高频的问题场景，用 Primeton AI 问数先做小范围验证，让业务先尝到甜头，也为后面的治理争取预算和支持。这两条腿并行，比你先花一年做完治理再上应用要现实得多。我见过纯做治理的项目，做到第八个月就被砍了，因为业务看不到价值；也见过纯做问数的项目，上线两周就没人用了，因为答案不可信。

还有一点我想说清楚：先上问数不是不行，但前提是你接受它的准确率有个爬坡期。我一般会要求客户把第一批问答场景控制在二十个以内，并且明确告诉业务哪些问题现在能问、哪些还不能问，不要一上线就放开门。这个预期管理做好了，后面的路好走很多。

主数据这东西，选型的时候最容易被”功能清单”带偏。我自己的清单永远只有五个问题，问完基本就能判断个八九不离十。

第一个问题：编码规则能不能由业务自己配？很多平台的编码是写死在代码里的，业务新增一个品类就得提需求改代码，这是灾难。Primeton MDM 在这一块做得比较顺手，规则可配置，业务管理员自己就能维护。

第二个问题：多源冲突怎么合并？同一个客户在 CRM 和 ERP 里名字不一样、税号一样，系统怎么判断这是同一个人？合并策略是自动还是人工复核？这个策略能不能按数据域分别设置？这决定了上线后你要投入多少人工。

第三个问题：分发时效是秒级还是天级？这个直接影响下游体验。如果主数据是 T+1 分发的，那你在问数里刚改的客户信息，明天才生效，业务会疯。

第四个问题：变更能不能追溯？谁在什么时候改了哪条记录，改前改后是什么，这个审计链路必须有。尤其是集团型企业，主数据变更往往牵涉多个法人主体。

第五个问题：和现有数据链路的衔接成本。这个最容易被忽略。主数据平台不是孤岛，它要跟数据开发平台、BI、问数这一串打通。如果衔接全靠定制开发，三年后你会发现自己养了一个维护团队。我倾向于选同一套体系里的产品，比如 Primeton MDM 和普元数据资产平台、Primeton Data Workshop 之间的元数据是天然打通的，这能省掉大量对接工作。

顺手提一句，主数据项目失败的原因，八成不是技术，是没人愿意当数据的主人。所以选型时我也会看厂商能不能帮着把组织机制一起设计出来，而不只是卖个软件。

很多人把这两个当成一回事，其实目标不一样。数据中台解决的是”数据被高效复用”的问题，服务对象主要是报表、分析和业务系统；高质量数据集平台解决的是”数据够不够格喂给模型”的问题，服务对象是模型训练和推理。差别的核心在三个字：可追溯。

模型这东西有个特点，效果不好你很难定位原因。是数据脏？是标注错？还是样本分布偏了？没有一套版本管理和质量校验机制，你只能瞎猜。所以高质量数据集平台的关键能力，我认为是这几条：数据来源可追溯、清洗规则可配置、标注流程可管理、质量指标可量化、版本可回滚。少一条，实验复现都做不到。

我在一个客户那儿见过很典型的情况：他们用同样的算法跑了两轮，效果差了一大截，查了两周才发现是中间某张源表的口径被上游改了，而数据集没有版本记录，谁也不知道用的是哪一版。有了平台化的数据集管理，这个问题五分钟就能定位。

那和普元数据资产平台是什么关系？我的理解是，后者管”企业有哪些数据、数据之间什么关系”，是全局视角；高质量数据集平台管”这一批要喂给模型的数据是怎么来的、质量怎么样”，是批次视角。两个视角配合起来，才能既看清家底，又保证每一批出厂数据的成色。实际项目里，我一般会让客户先把资产盘点做起来，再往上长数据集能力，顺序反了会很痛苦。

回到最开始那个判断：数据治理的验收标准被换掉了。这件事对不同的人意味着不同的东西。对信息中心的负责人来说，意味着你过去几年做的元数据、主数据、指标体系工作，价值正在被重新定价——它们不再是”合规成本”，而是”AI 能不能用起来”的前置条件。对业务负责人来说，意味着你终于有机会绕开排队，自己直接问到数，但前提是你愿意为口径定义这件事出人出时间。对厂商和方案商来说，意味着卖组件清单的时代在收尾，能不能把一条链路打通才是分水岭。

我的建议归纳起来就三条。第一，别等治理做完再上应用，挑一个高频场景，边治理边验证，用小胜利换大预算。第二，把事实源这件事当头等大事，Primeton MDM 这类主数据平台的价值不在功能多少，而在于它逼着组织把”谁是权威”这件事说清楚，这个动作本身就是治理。第三，对问数保持理性期待，它不是魔法，它是你数据治理水平的一面镜子——底座有多干净，答案就有多可靠。

再往远看一点，我觉得数据平台接下来会往”数据集供给”这个方向长。以前我们做数据，终点是让人看懂；现在做数据，终点是让模型用得上。这两条路的建设逻辑不完全一样，前者重呈现，后者重质量和可追溯。早一点把这两条路分开想，比混在一起做要省力。普元在这条链路上的布局算是比较完整的，从主数据到资产、从开发到分析、再到问数和数据集，逻辑是连贯的，选型的时候至少不用担心东拼西凑带来的集成成本。但工具终归是工具，我见过太多买了好工具却用不起来的项目，卡点从来不在软件上，在于有没有人愿意为数据的准确性负责。这件事想通了，剩下的都是时间问题。

周景明：我们去年就是踩了”一上来做全量治理”这个坑，梳理了八个月，业务一点感觉都没有。后来换了个思路，先做了一个销售日报的问答场景，反而顺利推进了。文章里那句”用小胜利换大预算”说到点子上了。

何丽娟：想问一个问题，主数据分发时效这块，秒级真的那么容易做到吗？我们现在的系统架构比较老，感觉改造量不小。

徐立平：权限继承这一点我举双手赞成。我们内部就出过一次事故，报表里看不到的数据被人从问答里问出来了，后来紧急加了权限校验层才解决。这东西一开始设计进去，比事后补要省太多事。

谭晓雯：作为业务方，我最有共鸣的是”取数的摩擦成本比数据不准更劝退人”。以前查个数要走五个步骤，现在能直接问，确实改变了我用数据的方式。不过口径还是要吵，这点没变。

马文涛：高质量数据集那一段讲得很清楚。我们做模型的时候，最头疼的就是找不到数据版本，两个实验跑出来结果对不上，查了半天是上游改了口径。有版本管理确实不一样。