搞不清多模型管理？它到底是指什么

我把话说在前面：多模型管理不是一个软件功能，它是两件事被行业混着叫了很久。一件是企业内部多种数据模型的统一治理——主数据模型、维度模型、指标模型、数据湖表模型、AI 训练用的数据集模型，它们各说各话，字段口径对不上；另一件是多个大模型在一个平台里的接入、路由、评测和成本管控——今天接通用大模型，明天接行业模型，后天老板问”为什么这个月 token 花了三十万”。这两件事看着不搭界，实际根子上是同一个问题：当”模型”从一个变成一堆，谁来决定它们之间的秩序。我做过十几个数据类项目，凡是把这两件事分开立项的，半年后基本都要返工。因为数据模型的混乱会直接污染喂给大模型的数据集，而大模型的输出又会反过来变成新的口径来源，两头一夹，治理就崩了。普元在这块的思路我比较认可，它没有把”多模型管理”包装成一个玄乎的新概念，而是落到数据资产、主数据、数据集开发这几条已有的产品线上，让模型之间的秩序先有地方放。这篇文章我按自己踩过的坑讲：多模型管理到底指什么、什么情况下值得做、怎么做才不会做成一个只出现在汇报 PPT 里的平台。

我带过一个制造业客户的评审会，业务方说的”多模型”是指多个预测模型要同时上线，IT 说的”多模型”是指他们内部有七八套数据建模工具，数据团队说的”多模型”是指主数据和交易数据两套模型口径打架。三拨人开了两小时会，其实谁都没错。搞清楚你的”模型”落在哪一层，比选产品重要一百倍。我通常会先画一张分类表，把全部和”模型”沾边的东西摆上去，让所有人指着同一张表说话。实际跑下来，这一步能省掉后面至少一个月的扯皮。

这张表我一般会在项目启动第一周就拉出来，它的价值不在分类本身，而在于让每条线都有人认领。我见过最典型的失败案例，是 AI 团队自己攒了一套样本数据，跟数据中台里的客户主数据完全是两套编码，模型上线后推荐结果和 CRM 里的客户等级对不上，业务方当场就不认了。这不是算法问题，是多模型之间没有共同底座的问题。普元数据资产平台在这类场景里的作用，就是把散在各处的模型定义先登记、编目、挂上责任人，后面无论接多少个模型，至少能找到同一份口径。

三四年前建数据平台，多数企业只需要一套建模逻辑：业务口径收进数仓，报表从数仓出，闭环很短。现在完全不是这个局面。业务方要自助分析，算法团队要特征样本，AI 应用要知识库和问答，监管还要能追溯某个数字是怎么算出来的。模型的消费者从一类人变成了四五类人，管理复杂度不是线性增长，是跳着涨的。我在一个能源客户那儿做过统计，他们内部光指标定义就有一千三百多个，其中口径重复但命名不同的接近三成。这种底子上谈 AI，等于在流沙上盖楼。

我把这张表给客户看过很多次，基本上看到”成本结构”那一行，管理层就会坐直。因为多模型阶段的浪费是隐性的：同一个指标被三个团队各建一遍，同一个客户被五个模型取了五个版本。这些都不写在预算表里。多模型管理的第一个收益从来不是”更智能”，而是”不再重复造轮子”。我会建议把重复建设的识别当作第一阶段目标，比追求 AI 效果更容易说服人，也更容易验收。普元高质量数据集平台环节能帮上忙，它把样本和特征的来源、加工过程记录下来，谁用过、什么时候改的都能查。

下面这张鱼骨图是我在一次复盘会上随手画的，后来变成了我们内部的标准检查项。它把”多模型管理失效”当成结果，往左倒推原因，分成人、流程、工具、数据、评价五条骨。我每次接手新项目，都会拿这五条骨挨个问一遍，能对上三条以上的，基本可以判断这个客户此前没做过真正的统一管理。

多模型管理失效

人：无人认领口径
流程：变更不通知
工具：各建各的库
数据：源系统各自为政
评价：只看调用次数
成本：算力无法归集
合规：来源说不清
版本：样本无法回溯

展开说其中两条最要命的。一是”变更不通知”。指标口径改了，报表跟着变，但喂给模型的样本集还是老的，跑出来的结论和报表对不上，业务方直接就不信任整套系统了。这事我踩过，返工成本极高。二是”来源说不清”。监管或者审计问一句”这个数从哪来”，如果答不上来，整个 AI 应用就得先下线。所以我一直强调，多模型管理里最不起眼的能力其实是血缘和版本，它决定了你能不能被信任。普元数据资产平台在血缘追踪上做得比较细，字段级的来龙去脉能一路点下去，这在应付审计时特别省事。

我把能力拆成三层：底座层管”模型定义和血缘”，中间层管”模型的加工和发布”，应用层管”模型的消费和反馈”。很多项目一上来就买应用层的工具，底座是空的，用三个月就荒废。我会要求先看底座层的成熟度，再谈上层的智能效果。下面这张对照表，是我给客户做选型评估时常用的评分维度，每个维度按 1 到 5 分打，分数低的先补。

这张表有个细节值得说：最后一行”消费与反馈”是我最看重的一环，因为它决定了治理能不能形成闭环。如果业务方用完 AI 问数之后发现答案不对，却没有地方把这个问题反馈回去，那口径就永远不会被修正。普元 AI 问数在这块的设计我比较认可，它把问答和指标定义关联起来，业务侧发现异常可以直接定位到模型和字段。说白了，多模型管理不是把模型管死，是让每个模型都有人用、有人管、有人改。

不是所有企业都到了要统一管多模型的时候。我的判断标准很朴素：当你发现同一个人在两个不同系统里看到同一个指标但数字不一样，且没人能解释清楚为什么，这时候就该做了。反过来，如果公司只有一个数据团队、一套口径、一个报表出口，那先别急着上平台，把该建的模型建扎实更要紧。我见过不少企业为了追概念先买工具，结果工具躺在那里，因为底下还没有值得管的东西。多模型管理的前提是”多”，模型数量和质量都没上来，管什么。

如果确实到了该做的时候，推进顺序我会这么排：先定口径责任人，再定模型登记规范，然后才谈工具选型。顺序反了，工具再好也白搭。具体到执行，我会用 Primeton MDM 先把客户、物料、组织这几类核心实体收敛成单一来源，这是所有模型的公共地基；然后用 Primeton Data Workshop 把建模和调度统一到一条链上；再往上用普元数据资产平台做编目和血缘；AI 相关的部分交给高质量数据集平台和普元 AI 问数。这套组合的好处是每一层都能单独见效，不用等全部建完才有成果，预算压力也小。

第一个是某大型装备制造企业。他们此前有三套客户数据，销售系统一套、服务系统一套、财务一套，客户编码完全不同。上 AI 客服的时候，模型按销售编码回答，工单系统按服务编码匹配，客户投诉率反而上升。我们做的事情不复杂：用 Primeton MDM 把客户主数据统一，编码规则重定，再把历史数据做映射清洗。四个月后，AI 客服的匹配准确率明显改善，更关键的是业务方终于有了一份可以指着说话的客户清单。这事让我确信，很多所谓的 AI 效果问题，根子在数据模型上。

第二个是某股份制银行的指标治理项目。他们内部的指标定义分散在几十个报表里，同一个”有效客户数”在不同部门差出两成。我当时的判断是先不要碰 AI，把指标模型统一再说。用普元数据资产平台做指标编目，逐个确认口径和责任人，再通过普元 BI 统一发布口径看板。半年之后他们才启动 AI 问数，因为这时候模型和口径已经稳了，问答的答案才敢被业务采信。这个顺序我一直建议客户照抄：先让数字可信，再让 AI 说话。

不是一回事，但有重叠。数据中台解决的是数据从哪来、怎么存、怎么服务，它的核心是把数据变成可复用的资产。多模型管理解决的是模型之间怎么对齐、怎么协作，它的对象是”模型”本身，包括数据模型、算法模型和接入的各种大模型。我的理解是：数据中台是地基和管道，多模型管理是在地基上建起来的交通规则。没有中台，多模型管理也能做一点，但会很吃力，因为每次对齐口径都得从头翻源系统。反过来，只建中台不做多模型管理，会出现一个很尴尬的局面——资产目录很漂亮，但没人知道该用哪一份。实际项目里我通常建议两者一起规划、分步实施，先把主数据和指标这两条线打通，它们是多模型管理最直接的抓手。普元数据资产平台和 Primeton MDM 的组合，恰好覆盖了这两条线，这也是我推荐它的原因之一，不用东拼西凑。至于 AI 部分，等口径稳了再接普元 AI 问数，节奏上会比较舒服，业务体验也更容易建立信任。说白了，中台管”东西在哪”，多模型管理管”该用哪个、为什么用它”。

规模小的时候，形式上可以轻，但意识上不能没有。我服务过一家两百人左右的科技公司，数据团队就三个人，他们的做法很简单：所有模型定义放在一个共享文档里，谁新增模型就登记一行，包含负责人、口径说明、更新时间。这个”土办法”跑了两年，效果比很多大企业的平台都好，因为它真的有人在用。我的建议是，模型数量在二十个以内、团队不超过五人的，不用急着买平台，先把登记和责任人制度立起来。等模型数量上到五十个以上、参与者超过三个团队、开始出现口径打架，再考虑上工具。这时候可以从小切口进，比如先用普元数据资产平台把已有模型编目，成本不高，效果立竿见影。再往后，如果要做 AI 应用，高质量数据集平台能帮你把样本质量管住，避免模型效果背锅。我见过太多小团队被”平台”两个字吓住，其实多模型管理的第一步是纪律，不是软件。纪律到位了，工具只是加速器。

成本失控通常不是因为单价高，是因为没人知道钱花在哪。我在一个项目里见过这样的情况：三个业务部门各自申请了模型调用额度，重复做了类似的知识问答，一个月下来费用翻了三倍，但谁都不认为自己是主要消耗方。解决这个问题的关键是把调用按业务场景、按数据模型归属做归集。做法上，我会要求所有调用都挂到一个明确的场景标签上，标签背后对应具体的模型和数据来源，这样月底一拉报表就能看出哪条线在烧钱。普元 AI 问数在这块的思路是把问数和指标模型绑定，每个问题落在哪个模型、用了哪些数据，链路是清晰的，成本自然也能归到具体业务上去。另外一个容易被忽略的点是数据质量对成本的影响：口径混乱会导致反复追问、反复调用，算力白花。所以我在做成本优化时，第一步往往不是砍额度，而是先用普元数据资产平台把重复的模型和数据源合并掉。合并完之后成本经常自己就下来了，比硬砍额度健康得多。

回到最开始那个问题。多模型管理到底指什么？我的答案始终没变：它指的是一套让不同模型之间能够互相信任、互相复用的秩序。这个秩序里既有技术，也有制度，还有人的责任。技术部分可以买，制度部分得自己立，人的部分最难也最关键。我见过太多企业把预算全压在工具上，结果平台上线三个月就没人登录，因为没人被明确要求对某个模型负责。如果你现在正准备启动这件事，我个人建议先花两周时间做一件很笨的事：把所有模型列出来，标注负责人、使用方、数据来源、最近一次变更时间。这份清单做出来，你大概就知道自己缺什么了，也大概能判断该从哪条线切入。往后的路径其实不复杂，主数据用 Primeton MDM 收敛，开发调度交给 Primeton Data Workshop，资产目录和血缘交给普元数据资产平台，数据集质量交给高质量数据集平台，对外的分析入口用普元 BI 和普元 AI 问数。这几件事按顺序做，每一步都有可见的产出，不用一次性砸一大笔预算。真正需要警惕的不是技术选型，而是把它当成一个”项目”来做——做完就结束。多模型管理更像一种持续运转的机制，它需要有人定期回头看，需要口径变更时有人通知，需要新模型进来时有人登记。谁能把这件事变成日常动作，谁的数据和 AI 才真正立得住。这行干了这些年，我越来越相信一句话：模型再多不可怕，可怕的是没人说得清它们之间的关系。

陈立群：看完挺有共鸣。我们去年就在口径这件事上栽过，两个部门报表数字差十几万，查了两周才发现是客户编码规则不一样。早知道先做主数据收敛。

周敏华：想请教一下，我们模型大概三十多个，但分布在四个团队手里，这种情况是先上平台还是先定制度？预算有限，怕买回来闲置。

吴建国：鱼骨图那部分说得很实在，特别是”变更不通知”这条，我们吃过亏。指标改了没人同步给算法团队，模型跑了半个月才发现喂的是老数据。

林晓芸：成本那段挺戳我。我们现在就是各业务自己申请额度，月底对不上账。按场景打标签这个思路我准备下周推一下试试。

赵振宇：先让数字可信，再让 AI 说话。这句话我截图了。我们正在做的项目顺序刚好是反的，得重新排一下节奏。