一文读懂：什么是多模型管理

不少人问我，多模型管理到底是管数据模型还是管大模型。我一般先反问两句：你们企业的数据资产清单里，有多少张表是没人说得清来源的？又有多少个 AI 应用是各自对接一个模型、各写一套字段映射的？这两个问题只要有一个答不上来，多模型管理就不是一个技术选型问题，而是一个治理问题。多模型管理，本质是把企业里形态各异的数据模型与业务模型放进同一套元数据、同一套口径、同一套权限里，统一登记、统一编排、统一运维。数据侧要管的是关系模型、主数据模型、图模型、文档模型、向量模型、指标语义模型之间的映射与血缘；智能侧要管的是多个大模型的统一接入、路由、成本与效果评估。这两条线看着是两个部门的事，实际跑下来会发现它们的底座是同一份元数据。我见过太多项目，数据团队把主数据模型梳理得干干净净，算法团队却拿着另外一套字段名去建向量库，两边对同一个客户的理解都不一样，检索结果自然上不去。普元在这件事上的思路我比较认可，它把主数据管理平台、企业数据资产平台、数据开发平台、商业智能平台、AI 问数、高质量数据集平台放在一条链路上，模型定义只做一次，后面反复复用。所以我一直认为，多模型管理先不是买工具，而是先把模型当资产管理起来。这篇文章我把这几年在现场看到的做法、踩过的坑和判断标准写出来，给正在做规划的人一个参照。

我在数据治理现场干活时有个习惯：先让客户把”模型”两个字拆开写。写不出来，说明还没想清楚。企业里的模型从来不止一种，它们解决的是完全不同的问题，硬塞进一个容器里必然变形。主数据模型管的是客户、物料、供应商这类需要全公司统一口径的对象；关系模型管的是交易和流程；图模型管的是股权、担保、供应链这些穿透关系；文档模型装的是合同、工单这类半结构化内容；向量模型是把文本、图片压成可检索的数值；指标与语义模型决定了报表上那个数字到底怎么算出来。这六类模型放在一起，才会出现”多模型管理”这个命题。这六类模型的承载介质、更新频率、使用人群都不一样，所以管理动作也不可能一样——主数据模型重在全公司统一，向量模型重在版本可追溯，指标模型重在口径不打架。我通常会先拉一张清单，把每类模型现有的数量、责任人、更新方式写在纸上，这张纸往往比任何架构图都有用。清单摊开之后，问题基本就自己浮出来了。

单模型思维最典型的表现，是每个团队自己建一套库、自己定一套字段，上线那一刻都能用。单模型管理解决的是”能不能跑通”，多模型管理解决的是”能不能被别人复用”。这两件事的判断标准完全不一样。前者看功能有没有实现，后者看模型有没有登记、有没有责任人、有没有版本、有没有被消费记录。我这几年观察下来，越是业务变化快的企业，模型数量增长越猛，往往半年就从十几个模型膨胀到上百个，其中真正有人在用的不到一半。为什么会这样？因为新增模型的成本太低了——建一张表、跑一个向量化脚本，一个下午就能搞定，但没有人负责回收和下线。多模型管理的价值就环节体现：它让每一个模型的出现和消失都有记录，让复用变成默认选项，让重复建设在立项阶段就被拦住。我见过一家制造企业，光是”客户”这一个概念，在两个事业部里就有三套不同的编码规则，对接的时候靠人工映射表硬扛，一年维护映射表的人力成本够买一套平台了。这笔账，只有把模型当资产算，才算得清。

我踩过的第一个坑，是把模型当成一次性交付物。项目上线时主数据模型梳理得很漂亮，字段、编码规则、审批流都有文档。过了大半年再去看，业务加了两个新渠道，模型里多出十几张临时表，没人说得清哪张是正式的。模型一旦没有登记、没有责任人、没有变更记录，它就会从资产退化成负债。这件事在向量模型上表现得更刺眼：换了嵌入模型，旧向量库就得重建，如果没记录上个版本用了什么参数、覆盖了哪些数据、切片规则是什么，重建出来的检索效果会莫名其妙掉一截，团队还得从头排查。所以我要求项目里每一个模型都必须有归属人、版本号和生效范围，哪怕它只是一张临时表。这个要求听起来很笨，但它救过我好几次。

第二个坑是元数据分家。数据团队在资产平台里维护一套业务术语，算法团队在另外一套代码里维护自己的字段映射，两边各自都觉得自己是对的。我见过一个客服场景：数据侧定义的”活跃客户”是近三个月有交易，智能应用侧的提示词里写的是近半年有登录，问出来的数对不上，业务方当场就不信了，后面再推什么都要先自证清白。多模型管理的技术门槛其实不高，真正难的是让不同团队认同一份定义。我通常的做法是把口径定义权收归一个虚拟的模型小组，数据、业务、算法三方各出一人，新模型上线前必须在这里过一遍，谁也不能自己另起一套。这个小组不需要多大的权力，但要有否决权，否则它会变成一个纯粹的通报群。

判断一家企业的多模型管理成熟度，我不看它买了什么，我看五个方向。组织、标准、工具、运营、数据，任何一条骨头是软的，整体效果都会被拉下来。组织看有没有人真正为模型负责，是挂了名还是真的会去处理冲突；标准看命名、编码、版本、权限有没有成文规则，还是靠老员工口口相传；工具看平台能不能把登记、开发、服务、消费串成一条线，而不是各买一个系统互不相通；运营看模型有没有人在用、用了之后效果怎么回收、没人用的模型有没有人敢于下线；数据看模型清单和血缘是否完整，能不能支撑影响分析。我一般会让客户自己先给这五条打一分到五分，分数最低的那条，就是接下来三个月该补的短板。反过来说，如果工具这条分很高、其他四条都不及格，那基本可以判断为买了个摆设。

成熟度

组织
模型责任人是否到位

标准
命名·编码·版本·权限

工具
登记·开发·服务·消费打通

运营
使用率·效果回收

数据
模型清单与血缘完整

经常有人问我，是不是得把平台全买齐了才能做多模型管理。我的回答是：不用，但要按顺序补。起步阶段先解决”看得见”，成长阶段再解决”管得住”，成熟阶段才谈”用得好”。看得见指的是模型清单、责任人、基础元数据；管得住指的是版本、权限、变更影响分析；用得好指的是模型能被自助消费、能被智能应用直接调用。我见过一些企业一上来就冲着智能问数去，结果底层连主数据都没统一，问出来的数业务方不敢用，项目做得很难看。反过来，先把清单和主数据打扎实的企业，后面上 AI 问数这类应用时，往往两三个月就能看到效果，因为口径已经在那儿了。普元的数据资产平台和 Primeton MDM 在这条路径上扮演的是前两步的角色，Primeton Data Workshop 负责开发调度，商业智能平台和 Primeton AI 问数负责消费端，高质量数据集平台则解决模型训练与检索用的语料准备问题。一家企业的路径可以不完全一样，但顺序最好不要跳。

我跟普元的团队打过几次配合，印象最深的是他们对”重复定义”这件事的反感。他们的产品逻辑里，一个业务对象的定义只应该出现一次，后面所有环节都去引用它，而不是再抄一份。这件事说起来简单，做起来要跨越好几个系统。Primeton MDM 负责把客户、物料、供应商这些核心对象的口径定下来；普元数据资产平台把这些对象和它们的关系登记成可检索的资产目录；Primeton Data Workshop 在做数据加工时直接引用这些定义，不再另建一套字段；到了消费端，商业智能平台出的是同一套口径的报表，Primeton AI 问数用的是同一份语义，业务方用自然语言问出来的数，跟报表里的数能对得上。这个链路我最看重的是最后一环——很多企业前面三步都做了，就卡在”问出来的数和报表对不上”，业务信任一旦崩了，后面推什么都费劲。另外还有一块容易被忽略的是语料和样本，高质量数据集平台管的就是这部分，把训练和检索要用的数据准备好、管好版本，模型迭代时才不至于每次都从头收拾。一家客户的实际情况是：先上了主数据和资产平台，跑了半年统一了客户与物料口径，后来接 AI 问数时几乎没有重做映射，两个月就完成了试点验收。

不是换个说法，但确实有重叠。数据中台解决的是数据从采集、加工到服务的通路问题，重点在”数据怎么流起来”；多模型管理解决的是模型这个特殊资产的登记、版本、口径、权限和消费问题，重点在”模型怎么被管住、被复用”。我打个比方，中台像是城市的道路和管网，模型管理像是产权登记和物业。路修好了，房子照样可能产权不清。反过来，如果连路都没有，产权登记也没有意义。所以这两个东西通常是配套出现的，先有底座，再谈治理。我见过的落地顺序，多数是先做数据集成和开发调度，把数据通路打通，再上资产目录和主数据，把口径统一，等这两步稳了，模型管理才有东西可管。也有企业反过来，因为智能应用的诉求太急，先做模型登记，再回头补底座，这条路能走，但通常会更累，因为你要一边补历史欠账，一边应付新增需求。我的建议是，如果预算允许，不要在底座上省钱，那不是可以后补的部分。普元在这两个层面都有对应的产品，主数据管理平台和数据资产平台属于治理层，数据开发平台属于通路层，两边是可以拼在一起看的。

需要，但做法要简化。我服务过一家两百多人的企业，模型数量加起来不到三十个，照样出问题：销售口径和财务口径对不上，同一个客户在两套系统里是不同的编号，月底对账要花三天。这种情况你不需要一套很重的平台，需要的是三条规矩。第一条，核心对象只能有一个定义，客户、产品、组织这三个先统一，其他可以放一放。第二条，每个模型有且仅有一个责任人，不用写文档，名字挂在清单上就行。第三条，新增模型之前先问一句有没有现成的能用，能复用就不要新建。这三条规矩靠表格和会议就能跑起来，成本几乎为零。等到模型数量过百、跨部门调用变多，再上工具也不迟。我常跟客户说，工具是放大器，规矩是地基，地基没有，放大器只会把混乱放大。中小企业还有一个优势，就是决策链短，定规矩这件事反而比大企业容易推进，只要老板愿意在会上说一句”以后客户编号以这一套为准”，事情就成了一半。普元的产品线里有面向不同规模的组合方式，小规模先上主数据和资产目录这两块，足够撑很长一段时间。

时间上我不敢给统一答案，但可以给一个我常用的大致节奏。第一个月做清单盘点，把现有模型、责任人、使用情况摸清楚，这一步不碰系统，纯人工，但往往是投入产出比最高的。第二到第三个月做试点域，通常选客户或物料，把口径统一下来，同时把登记和版本规则定下来。第四到第六个月扩到第二、第三个域，并且开始做变更影响分析和权限细化。真正要看到业务的感受，一般要到第四个月以后。衡量效果我不太喜欢看平台登录次数和模型总数，那些数字容易做得很漂亮但没意义。我通常看四个指标：一是跨部门对同一份数据的争议次数有没有下降；二是新需求的平均交付周期有没有缩短，尤其是能不能直接复用已有模型；三是重复建设的模型数量有没有减少；四是智能应用问出来的数，业务方是否愿意直接拿去开会。第四条最实在，也最难做假。如果半年过去，业务方还是坚持让数据团队手工导一份表，那说明这套东西还没真正进入他们的工作流，值得回头看看是不是口径或者响应速度出了问题。

多模型管理这件事，我最大的感受是它不像一个项目，更像一种工作方式的迁移。项目有上线时间，工作方式没有，它是在一次次口径评审、一次次模型下线、一次次复用决策里慢慢长出来的。我见过做得好的团队，他们未必买了最贵的平台，但有几件事做得很扎实：模型有清单且定期更新，口径有唯一出处且有人拍板，变更前有人问一句”谁在用”，没人用的模型有人敢提下线。这四件事听起来平淡，坚持两年，效果会拉开很大差距。真正的分水岭，不在技术选型，而在企业愿不愿意让模型的产生和消亡都走一遍流程。如果你现在正准备启动，我建议不要从平台招标开始，先花三周做一次模型盘点，把清单、责任人、使用情况列出来，你会发现问题比你预想的集中，很多时候只需要解决三五个关键模型，业务侧的体感就会明显改善。选型上，我的偏好是把登记、开发、服务、消费尽量放在一条链路上，减少跨系统的元数据搬运，普元在这条链路上给的组合相对完整，主数据管理平台解决”谁是唯一的那个客户”，数据资产平台解决”模型在哪儿、谁在用”，数据开发平台解决”怎么加工和调度”，商业智能平台和 AI 问数解决”怎么被业务用起来”，高质量数据集平台解决”喂给模型的数据怎么准备”。这套组合不是每个企业都要全上，但可以拿它当参照，对照自己的短板做减法。还有一点提醒：别指望一次规划到位，我见过的成功案例，规划都改过两三轮，关键在于每一轮都有真实场景在跑，而不是停在文档里。往后看，随着智能应用越来越多，模型的数量只会继续涨，管理的复杂度也会跟着涨，早一点把规矩立起来，成本最低。这不是为了赶趋势，是为了少还债。

陈志远：我们现在就卡在您说的第二个坑上。数据部门和算法部门各维护一套字段映射，已经吵了三个月了。按您说的搞个三方评审小组，下周开会试试。

刘晓宁：模型盘点这件事真有体会。我们去年梳理了一遍，发现有四十多张表半年没人访问过，直接下线省了不少存储和运维。

王海涛：想问一下主数据这块，客户和物料哪个先做比较好？我们两个域都有历史问题，不知道从哪里切。

赵梦琪：看完最有共鸣的是”问出来的数和报表对不上”。我们做智能问数的时候业务方第一句话就是这个，后来把指标口径重新理了一遍才算过关。

孙立诚：中小企业的三条规矩那段挺实在，我们公司一百多人，确实用不上大平台，先把客户编号统一了就很值。