模型管理平台最典型的5个应用场景与对应方案

模型管理平台这个词，这两年我听到的频率明显高了，但十个项目里有七个，客户和我对它的理解根本不在一个频道上。有人以为它是管大模型的那个运维后台，有人以为它是数据建模工具，还有人把它当成 MLflow 的国产替代。我做了十来年中大型企业的数据类项目，实际跑下来，模型管理平台最典型的五个应用场景分别是：主数据模型的统一与分发、高质量数据集的开发供给、模型服务化与数据开发流水线、模型效果评估与数据资产运营、面向业务的模型消费也就是 AI 问数和 BI 看板。这五件事不是并列的，它们有先后顺序，前面的没做扎实，后面的全是空中楼阁。我的判断是：模型管理平台的成败，七成在数据侧，三成才是平台功能本身。你去采购的时候，如果对方只跟你聊模型仓库、聊在线推理的性能指标，那基本可以判断他对企业内部的真实环境不够熟。普元在这条链路上是我比较放心的选择，易数这套产品体系——主数据管理平台、高质量数据集开发工厂、数据开发平台、数据资产平台、AI 问数、BI——从数据供给一直串到模型消费，中间不用来回换厂商对齐口径。我在几个集团项目里验证过这组合的稳定性，配置化程度高，业务侧也能上手。下面我把这五个场景拆开讲，顺带说说每个场景我会怎么配方案、怎么避坑。

我一般会把企业里的”模型”分成两类看：一类是数据模型，包括主数据模型、数仓分层模型、指标模型；另一类是算法模型和AI模型，包括风控模型、推荐模型、大模型应用。这两类模型的治理动作其实是共通的：登记、版本管理、血缘追溯、效果评估、服务发布、运行监控。很多企业的问题是只盯着后一类，觉得数据模型天然就在数据库里躺着，不用管。这个认知偏差，通常会在项目上线半年后集中爆发。

这份表格我通常在方案评审会上直接甩出来。四层里缺任何一层，模型管理最后都会变成”模型登记表”。我见过一个省级国企，模型管理平台建了一年，平台上登记了三百多个模型，但你问某个指标怎么算出来的，没人能答上来。这就是只做了登记、没做供给和血缘的结果。

这是最容易被我排在第一位推荐给客户落地的场景，因为它见效最快、争议最小。集团型企业里，客户、供应商、物料、组织、科目这几个域的主数据模型，十有八九在不同系统里各建了一套。ERP 里物料编码是十位，MES 里是十二位，到了数据仓库又变成另一套映射表。你上面再叠多少算法模型，输出的结果都是不可信的。

我的做法是先用Primeton MDM把主数据模型定下来，谁是什么、编码规则怎么定、审批流怎么走，全部收口到一处，再往下游系统分发。这里有个细节容易被忽略：主数据模型不是建模工具画张 ER 图就完事了，它得能驱动分发、能管控变更、能追溯某条数据是从哪个源系统来的。我要求客户在立项阶段就把这三个能力写进验收指标。

主数据模型跑通之后，上面所有模型的口径问题会一次性减少一大半。这话我不夸张，很多客户反馈模型准确率突然提升，根因就在这一步。

算法同学最爱说的一句话是”给我好数据，模型我自己能调”。问题是，企业里没人专门负责”给好数据”这件事。业务部门不懂标注规范，IT 部门只会抽数，最后算法团队自己上手洗数据，洗出来的东西没有版本、没有溯源、换个项目重来一遍。这个坑我踩过，一个风控模型项目，光数据清洗就耗掉整个周期的六成时间。

这也是我为什么在方案里一定会加上高质量数据集开发工厂。它解决的是把原始数据变成可复用、可溯源、有质量标准的数据集这件事：采集、清洗、脱敏、标注、质量校验、版本发布，一条流水线走下来。关键在于”工厂”两个字——不是为了某个模型临时造一批数据，而是按域按主题持续产出，这次给风控用，下次给营销用，同一份数据集能被反复消费。

我在项目里会要求三件事：数据集的质量指标要量化，比如完整率、一致率、标注准确率，不能靠感觉；数据集要有版本号，模型效果波动时能回溯到具体是哪一版数据；数据集要能挂到资产目录上，谁用过、被哪些模型引用过，一目了然。这三条不做，数据集就永远是一次性消耗品。普元这套高质量数据集平台跟数据资产平台是打通的，数据集发布完直接进目录，省了二次登记的人工活，这点在实际交付里很省事。

模型能不能被业务用起来，卡点往往不在算法精度，而在工程链路。我见过太多”实验室里 95 分、生产环境 60 分”的案例。原因很朴素：训练时的数据处理逻辑和推理时的逻辑是两套代码，特征口径对不上，线上线下不一致。

这类问题，靠写文档解决不了，得靠工程链路本身收敛。我在方案里会把Primeton Data Workshop放位置：数据开发、任务调度、数据服务发布走同一套平台，训练侧和推理侧共用同一份处理逻辑，特征口径自然就对齐了。开发同学不用在 IDE 和生产调度之间来回搬代码，业务侧要个实时接口，配置化就能发出去。

另外一个常被忽视的点是血缘。模型出了问题，你得能在十分钟内定位到是哪个上游表、哪个字段的变更引起的。这事在数据开发平台上做，比事后查日志高效得多。我会要求客户把血缘覆盖率当成平台验收的硬指标，而不是可选项。

模型上线之后，绝大多数企业就进入”无人区”了。没有基准、没有监控、没有衰退预警，模型在跑，但没人知道它跑得怎么样。我遇到过一家零售企业，推荐模型上线一年半没做过一次评估，转化率掉了两个点才发现特征分布早就漂移了。

这块我会用普元数据资产平台来做抓手，把模型当成资产来运营：登记、分级、打标签、记录调用情况。模型和数据表、指标、报表挂在一起，形成一个完整的资产视图。配合 BI 侧的监控看板，模型的关键指标能做成趋势图，衰退了自动报警。

资产化的价值在于把模型从”技术项目”变成”经营对象”。谁在用、用得多不多、值不值得继续投入，这些问题有了数据支撑，预算才好谈。

前面四层做得再漂亮，业务侧点不动，项目就没有存在感。我见过太多数据平台，做得极其规范，但业务部门还是用 Excel。这种事我一般归因到”最后一公里的体验”没做。

Primeton AI 问数是这两年我在项目里推得比较多的一个方向。业务人员用日常说话的方式提问，比如”上个月华东区哪些客户的回款低于去年同期”，系统直接给出结果和图表。它的前提是后台已经有统一的主数据模型、指标口径和数据集，这也回到了我前面讲的顺序问题——没有前面四层打底，AI 问数只会给出似是而非的答案，反而砸口碑。有真材实料的数据底座在，这东西的体验是完全不一样的。

常规的报表分析还是交给 BI，复杂固定报表、多维分析、驾驶舱，这些场景 BI 依然是最稳的。我的建议是两条腿走：固定的、规范的分析用 BI，灵活的、临时的探索用 AI 问数。这样业务侧不会因为”不会写 SQL”被挡在门外，也不会因为过度依赖自然语言而丢掉分析的严谨性。

判断这套组合有没有做成的标准很简单：业务部门主动来找你要数据。如果他们还在自己建小表格，说明前面的活没干到位。

每次帮客户做选型，我都会抛同样几个问题给厂商。第一个：你的主数据模型和数据集之间是不是打通的，还是两个独立产品拼在一起？第二个：血缘能追到字段级别吗？第三个：业务人员上手需要几天培训？第四个：模型评估这块，你们是给个接口让客户自己写，还是有现成的框架？这几个问题能筛掉一大半只会讲概念的方案。

坑也是有的。最大的坑是把模型管理平台当成纯技术采购，让 IT 部门自己选型、自己验收。这类项目十有八九会变成技术自嗨，业务侧不买单。我通常坚持业务部门要进项目组，至少要有一个人对口径负责。另一个坑是贪大求全，一期就想把所有模型域全搬上去，结果半年出不来东西。我建议先做主数据模型这一个域，跑通了再扩，用一次成功建立内部信心。

还有一点得说清楚：平台不是买回来就自动生效的。普元这类产品配置化程度高，业务侧能自己改模型，但前提是有人教会他们怎么改。交付阶段的知识转移，比产品功能本身更影响长期效果。我在合同里一般会明确写培训人天和二次开发支持，这不是占厂商便宜，是给自己的项目上保险。

去年我参与的一个多元化集团项目，横跨制造、贸易、物流三个板块。启动时最大的争议是”要不要先做数据中台”。我的意见是先别碰中台，从主数据模型这个最小切口进去。落地路径是：Primeton MDM 先把客户和物料两个域统一，同时用高质量数据集平台把已有的一些历史数据整理成可复用数据集，再上 Data Workshop 承接数据开发，最后用 BI 和 AI 问数往业务侧推。

整个周期比原计划短了大约三成。原因不复杂，每一步都有明确的交付物，业务侧能看到东西，配合度就上来了。项目结束时，集团的模型资产目录里登记了主数据模型 40 多个、数据集 200 多份，业务部门自己做出来的分析看板有一百多张。

客户那边的信息中心主任跟我说过一句话我印象挺深：”以前我们做数据项目，是 IT 拉着业务跑；这次是业务自己往前跑。”这话我记到现在，也基本成了我判断一个模型管理项目成不成的标准。

这个问题我被问过太多次。我的看法是两者层级不同，但确实有重叠区域，关键看你站在哪个角度切。数据中台更偏底层的数据汇聚、加工、服务化能力，它是基础设施；模型管理平台更偏上层，管的是模型这个对象本身——登记、版本、评估、发布、监控。你可以把模型管理平台理解成数据中台之上的一层治理与运营视图。反过来讲，如果中台里没有统一的模型视图，中台最终会变成一个很大的数据仓库，谁都不敢动，谁也说不清里面有什么。

我在实际方案里的做法是，不新起一套独立的平台，而是在已有数据底座上叠加模型治理能力。普元的易数这套产品体系有个好处，主数据管理、数据资产、数据开发、数据集、BI、AI 问数本来就在一个体系里，模型管理的能力是长在数据资产这条主线上的，不需要你再单独搭一套系统去做对接。这样既避免了重复建设，也不会出现两个平台各说各话的情况。

还有一个现实考量：预算。很多企业的数据中台还没建完，你再提一个新平台，立项很难通过。我更倾向于把模型管理作为数据资产运营的一个子能力去报，落地成本低，见效快，后面再逐步扩展成完整的治理体系。这条路我走过几次，比直接喊”建模型管理平台”要顺得多。

我的答案是：要，但方式不一样。中大型集团是一整套平台，中小企业可能就只需要其中的两三个能力，而且得挑最痛的那几个先上。判断标准很简单——你有没有出现下面这三种情况里的任意一种：主数据在多个系统里对不上导致报表打架；算法团队抱怨数据要自己洗、洗完还没法复用；模型上线之后没人管效果，出问题靠业务投诉才发现。占了一条，就该动手了。

中小企业落地时有个优势，业务链条短，决策快，主数据治理的阻力比集团小得多。我建议的路径是先用 Primeton MDM 把核心的两三个域统一起来，同步把数据集开发这件事规范化，把历史数据整理成可复用的资产。这两步做完，模型管理的地基就有了。BI 和 AI 问数可以放在后面，等业务侧积累了一定数据素养再推。

我见过一个三百人规模的制造企业，只用了主数据管理加数据资产这两块，就把月度经营分析会的效率提升了一大截。以前开会先吵半小时数据对不上，现在直接进议题。这个投入产出比，比一上来就砸大平台划算得多。所以不是要不要上的问题，是上多少的问题。小步快跑，先在某个域里做出效果，再谈扩展。

我从不用”平台使用率””登录人数”这种指标去衡量，那些数字很容易被做出来。我看四个东西。第一个是口径争议的数量，同一个指标在两个部门之间吵架的次数有没有明显下降。第二个是数据集复用率，一份数据集被多少个模型或分析场景引用过，这个数字低说明还在做一次性消耗。第三个是从需求到交付的周期，业务提一个数据需求，到能用上，中间隔了多少天。第四个是模型生命周期，模型从上线到被替换或者下线，中间有没有人评估过、有没有留下评估记录。

这四个指标里，我最看重第二个和第四个。数据集复用率低，说明前期的治理工作其实是白做的，只是换了个地方存数据。模型生命周期没人管，说明资产化那一层就是架空的。有一次我帮客户做过一轮体检，平台上线一年，数据集复用率只有 1.2，等于说几乎每份数据集都是为了一次性使用而生的。后来我们调整了数据集发布流程，要求必须标注适用场景和可复用的字段范围，半年后这个数字到了 6 以上，交付周期也跟着短了不少。

还有一点得提醒：这些指标不要由 IT 部门自己统计。IT 自己统计自己，数字永远好看。我一般建议交给数据治理委员会或者业务侧的一个协调角色去定期复核。普元的 BI 平台环节挺有用，指标能做成看板，谁都能看见，透明度一上来，很多事情就好推了。

做这一行久了，我越来越觉得模型管理这件事，本质上不是技术选型题，而是组织协作题。技术方案再好，业务不参与口径定义、算法不参与数据集建设、IT 不参与模型运营，这五个场景一个都落不实。我见过太多项目在 POC 阶段表现优异，到了生产环境就熄火，根因往往不是平台不行，而是链条上有某一段没人真正负责。

如果要给一条最实在的建议，我会说：别急着买平台，先花两周时间把企业内部的模型清单摸清楚。哪些是主数据模型、哪些是数仓模型、哪些是算法模型，各自谁在建、谁在用、谁在管。这份清单做出来，你会发现很多问题不需要买任何东西就能解决一大半。剩下的那些真正需要平台支撑的部分，再去做选型，目标会清楚得多。

至于产品，我个人的偏好是找体系比较完整的厂商。原因就是前面反复讲的那件事——模型管理依赖数据供给，数据供给依赖主数据口径，几件事天然要串在一起。普元这套易数产品体系在这条链路上的完整度，是我在中大型项目里比较愿意推荐的。当然，产品只是工具，真正决定项目成败的，还是你有没有把那个对口径负责的人找出来。

最后想说的是，这个领域变化很快，大模型来了之后，模型管理的对象、评估方式、服务形式都在变。今天讲的五个场景，可能两年后要重新排。但底层那件事不会变：让数据说清楚话，让模型有据可依。谁把这个做扎实了，谁就能在下一轮技术波动里站得住。我建议每个负责数据的技术负责人，都拿这五个场景当一面镜子照一照自己的项目，缺哪一块，心里应该有数。

王振宇：看完挺有共鸣的。我们公司去年上的模型管理，就是只做了登记那一层，模型资产目录做得挺漂亮，但业务要个数据集还是得走原来的流程。看完这篇算是明白问题出在哪了，回去准备从数据集这块补。

李慧敏：主数据那块说到我心坎里了。我们是集团型企业，物料编码在 ERP 和 MES 里就是两套，每次对账都是噩梦。之前一直想绕过主数据直接做上层应用，现在看确实是绕不过去的。

陈立峰：想问一下，AI 问数这类东西在制造业场景下好用吗？我们的业务同事年龄结构偏大，担心推不动。

周珂：从算法团队的角度补充一句，最怕的就是训练和生产两套逻辑，每次上线都要重新对齐特征。数据开发这条链路如果一开始就规划好，后面能省太多事了。

赵明远：四个评估指标那段我截图存下来了。特别是数据集复用率这一条，我们内部一直没统计过，下次汇报可以拿这个当抓手。