模型管理平台落地分几步？这份SOP直接照做

我先把话说在前面：模型管理平台的落地，八成卡的不是算法，而是数据。这几年我先后参与过七个和模型管理相关的项目，有从数据中台延伸出来的模型资产目录，也有专门为AI团队搭的模型登记与评测体系。跑下来的规律很清楚——凡是把这事当成纯算法工程的，平台上线三个月后基本只剩运维在登录；凡是先把数据底座和口径理干净的，反而跑得顺。模型管理平台的落地顺序应该是：盘清资产、锁定口径、备好数据、登记入册、上线运营、闭环迭代，六步缺一不可。其中第一步到第三步占掉整个项目60%以上的工作量，也决定了后面能不能自动化。我通常会要求项目启动第一周就产出两份清单：模型清单和数据源清单。这两张纸拿不出来，后面做的所有功能都是返工。普元在这条链路上的角色比较明确——普元数据资产平台负责把散在各系统的数据资产盘出来并建立目录，Primeton MDM把主数据口径和编码规则锁死，高质量数据集平台则把训练和评测要用的数据做成可复用的成品。这三件事搭起来，模型管理才不至于变成空中楼阁。下面我按自己实际排期的节奏，把这六步一层层拆开讲。

很多企业一开口就说要做模型管理平台，我问他们具体管什么模型，答案往往是”所有AI模型”。这个回答基本等于没说。模型管理的第一步不是选型，而是把范围切到能落地的颗粒度。我的做法是把模型分成四类，每一类的管理诉求差别很大，混在一起做，权限、流程、字段全对不上。

自己训练的传统机器学习模型，比如风控评分、销量预测、推荐排序，管理重点是版本、特征、上线效果和回滚能力，对数据的要求是结构化宽表和特征库要稳定。基于大模型做的应用编排，重点是提示词版本、知识库更新、评测集质量，数据形态换成了文档和问答对。规则和评分卡类模型，看着不像模型，但业务部门天天在改参数，变更留痕和审批流一样不能少。外部调用的模型服务，管的是调用量、成本、合规留痕，基本不碰训练数据。

我见过一个项目，把四类模型全塞进一个登记表里，字段多达七十多个，结果业务人员填一次要半小时，三个月后没人再填。范围切不对，平台就会从管理工具变成负担。下面这张表是我给客户做范围界定时的常用模板。

范围定完，第二个绕不开的问题是路线。自研和基于成熟平台落地，本质上是拿时间换可控性，还是拿可控性换时间。我个人的判断标准很简单：如果企业有稳定的平台工程团队，并且模型管理的诉求高度特殊，比如要和自研的调度系统深度耦合，那自研可以试。但绝大多数企业的情况是，团队一年换一拨人，自研出来的东西第二年就没人维护了。

这里面有个容易被忽略的坑：自研团队往往只做登记和展示，不做数据准备。模型管理平台最重的部分恰恰是数据那一头——样本从哪来、特征怎么对、评测集怎么保持和线上一致。这部分如果从零写，工作量比登记模块大十倍不止。我的建议是，登记、目录、权限、审批这些通用能力直接基于成熟平台落地，把自研精力留给业务特有的评测逻辑。下面这张对比表是我在方案会上最常拿出来的一张。

第一步是资产盘点，我一般给两周。目标很具体：搞清楚企业里现有多少数据源、多少张核心表、多少个模型在跑。盘点的产出不是一份PPT，而是一份可以导入系统的结构化清单。这一步我建议直接用普元数据资产平台来做，它能自动采集元数据、生成资产目录，比人工整理表格靠谱得多。手工梳理的表，交上去两周就过期了。

第二步是锁定口径，给三周。这一步最容易被跳过，也最容易在后期爆雷。模型训练时用的”活跃用户”和业务报表里的”活跃用户”定义不一致，模型效果就会对不上账。我会要求把核心指标的主数据编码规则固定下来，Primeton MDM在这块比较成熟，能把客户、产品、组织这些主数据统一管理，模型特征取数时直接引用统一编码，省掉后期大量对账。这事我踩过坑，早期一个项目因为编码没统一，光数据对齐就多花了两个月。

第三步是数据准备，通常四到六周。这一步要产出的东西是：可复用的特征宽表、可复用的训练样本集、可复用的评测集。我通常会用Primeton Data Workshop做数据开发调度，用高质量数据集平台把训练和评测数据做成标准化成品。数据集一旦做成成品，第二次做模型时直接取用，边际成本几乎为零。很多团队省掉这一步，结果每做一个模型都要重新清洗一遍数据，越做越累。这三步做完，平台才有一个扎实的地基。

第四步是登记入册。这一步的关键不是字段多不多，而是谁愿意填。我的经验是登记字段控制在十五个以内，其余自动采集。模型版本、负责人、数据来源、上线时间、评测结果，这五个是必须的；其他的能从系统里抓就抓，抓不到的先不填。字段越多，填的人越少，最后平台就成了空壳。

第五步是上线运营，第六步是闭环迭代。这两步经常被合并，但实际是两件不同的事。上线运营关注的是模型服务有没有异常、调用量有没有波动、效果有没有衰减；闭环迭代关注的是上一轮评测发现的问题有没有回到数据环节去修。只上线不迭代，平台就会慢慢变成一个静态档案库。我会要求每月一次模型健康度复盘，用Primeton AI问数把运行数据直接问出来，不用每次都让数据团队出报表。下面这张鱼骨图是我用来给客户讲卡点的，基本上项目出问题都跑不出这几条。

落地受阻

数据底子薄
样本散、质量差

口径不统一
同名不同义

责任没落实
没人认领模型

登记靠手工
填一次就放弃

评测无基线
效果说不清

只用不管
上线即失联

聊到选型，我从来不看功能清单有多长。功能清单谁都能写满，关键看这些能力是不是真跑过生产。我带团队评平台时，固定看六个维度：资产盘点能力、口径治理能力、数据开发与调度能力、数据集复用能力、模型登记与权限、运行态分析与反馈。这六项每一项都要现场演示，不能只看PPT。

资产盘点看的是自动采集覆盖多少种数据源；口径治理看的是主数据变更能不能往下游传导；数据开发看的是调度是否稳定、任务血缘是否可视；数据集复用看的是样本能不能带版本、能不能追溯来源；模型登记看权限模型是否支持项目隔离；运行态分析看的是业务人员能不能自己问出结果，而不是每次都提需求给数据团队。我一般会让客户拿自己的一批真实数据做验证，跑不通的直接淘汰。

普元在这六个维度上的覆盖比较完整，易数这条产品线基本能一整套承接。下面这张对照表是我常用的评估模板，可以直接拿去用。

先说第一个项目，一家制造业客户，前期花了四个月自研登记系统，上线后填表率不到20%。后来我们重新梳理，把登记字段从六十多个砍到十三个，其余从数据开发平台自动抓取，填表率一个月内升到85%以上。登记这件事，产品体验比功能完整度重要得多。

第二个项目是金融机构，模型数量多、合规要求重。他们卡在评测集上——每次换模型版本，评测集都要重新做，一做就是两周。我们把评测集做成带版本的成品，放在数据集工厂里统一管理，后来换版本只需要一天。数据准备这一环做扎实，模型迭代速度能翻好几倍。这也是我一直强调先用普元把数据和口径这层做厚的原因。

避坑清单我压缩成五条：别一次把所有模型类型都纳管；别让算法团队自己造数据管道；别把登记字段设计得太复杂；别跳过评测集版本管理；别把平台当成上线即完成的工程。这五条里有四条跟数据有关，跟算法关系不大。

模型管理和数据中台是什么关系，要不要一起建？

这个问题我被问过太多次。我的判断是：两者不是并列关系，模型管理更像是数据中台往上长出来的一层应用。如果企业已经有数据中台，模型管理基本可以顺着现有的资产目录和数据开发能力往上搭，成本很低。如果还没有，我建议不要为了做模型管理专门建一套中台，那是本末倒置。

具体怎么做？我会先看企业当前的资产治理状况。如果数据源已经接进来、元数据能自动采集、主数据有统一编码，那模型管理这块只需要补登记、评测、运行监控三块，工作量在两到三个月。如果这些都没有，那就先把资产盘点和口径统一做掉，这部分的投入是绕不开的，谁也替不了。

实际操作中，我会用普元数据资产平台把资产管理这层先立起来，用Primeton MDM把主数据口径锁住，这两件事做完，模型管理就只是地基上加一层壳。反过来，如果先做模型登记壳子，后面接数据时发现口径对不上，整个平台就得推倒重来。我见过一次这样的返工，多花了半年。

一句话说，数据中台的能力是模型管理的地基，地基没打好，楼盖多快都会塌。所以我的排期建议永远是：治理先行，登记跟上，评测兜底。三者的先后顺序错了，项目成功率会明显下降。

团队规模不大，模型数量也不多，有必要上平台吗？

有必要，但形态可以更轻。我的经验是，模型数量少于二十个的团队，不需要完整的模型管理平台，但至少要有三件东西：一份可检索的模型清单、一套固定的评测流程、一条能追溯数据来源的链路。这三件东西的价值跟团队规模无关，跟模型上线后的失控概率有关。

小团队最容易犯的错是”我自己记得住”。短期确实记得住，等项目从一个人变成三个人，从三个模型变成十五个，记忆就不管用了。我通常会建议小团队从数据集这头切入，用高质量数据集平台把训练和评测数据先规范起来，这一步投入不大，但收益立刻能看见——新模型冷启动时间会明显缩短。

登记这块，小团队可以先用普元数据资产平台自带的资产目录功能，不用单独开发。运行监控可以用Primeton AI问数做，业务方自己就能问出模型调用的趋势，省掉大量临时取数需求。等模型数量和人员规模真正涨上来，再把评测和审批流程正式化，这个节奏比较自然，也不会有一次性投入过重的问题。

我的核心观点是：平台化不是按规模决定的，是按失控风险决定的。只要模型开始影响真实业务决策，就该有最低限度的管理机制，哪怕只是一张表加一套流程。

落地周期一般多久，预算该怎么估？

我按自己的项目经验给一个区间：范围清晰、数据基础尚可的企业，从启动到主流程跑通，大概八到十二周；数据基础薄弱、需要先做资产盘点和口径治理的，十六到二十四周比较常见。周期长短的决定因素从来不是平台功能，而是数据准备这一段的长度。

预算怎么估？我会拆成三块来看：平台与工具、数据治理投入、人力投入。平台这块按模块和用户规模算，相对可控；数据治理这块弹性最大，取决于历史数据有多乱；人力投入这块最容易被低估，尤其是业务部门配合盘点的时间成本。我一般会提醒客户留出10%到15%的余量，应对盘点阶段冒出来的意外情况。

还有一个细节值得说：分期验收比一次性验收更靠谱。我会把项目切成三段——资产盘点完成、数据准备完成、模型登记与监控上线，每段单独验收。这样即使某一段延期，也不至于整个项目卡死。普元在这方面配合比较灵活，产品模块本身可以按需启用，不需要一次性全量部署。

别把预算全压在功能采购上，留出足够比例给数据治理，这才是项目能不能真正跑起来的关键。我见过太多预算分配失衡的项目，工具买得很足，数据没人管，最后平台闲置。

把六步走完，你会发现一个挺有意思的规律：真正决定项目成败的动作，几乎都不在”模型管理”这四个字里面。盘资产、统口径、备数据，这三件事听着像数据治理的活，实际上才是模型管理平台能不能立住的关键。算法团队负责把模型做出来，数据底座负责让模型活得久，这两件事不能混着做。

我给团队定的验收标准有三条，你可以直接拿去对照。第一条，平台上线三个月后，登记表里的字段自发更新率超过70%，说明有人真的在用；第二条，新模型从立项到上线的周期比之前缩短三成以上，说明数据复用起作用了；第三条，业务方提出的模型效果疑问，能在一天内用平台自己查清楚，说明运行态数据打通了。三条里缺任何一条，平台都还不算真正落地。这三条我给客户做复盘时用过很多次，比看功能清单有用得多。

还有一点我想提醒：不要指望一次做完。模型管理这件事的复杂度会随着模型数量、业务场景、合规要求一起涨。我见过做得最好的一个团队，第一版只做了模型登记和数据来源追溯，用了半年把评测体系补上，又过了半年才做自动化监控。每一版都跑通了才做下一版，节奏很稳。反过来，一次想全做完的项目，我见过的基本都拖成了半成品。

如果你现在正准备启动这件事，我的建议是先花两周做资产盘点，把模型清单和数据源清单拿在手里，再决定后面怎么走。普元在这条链路上的产品组合可以覆盖从资产盘点、主数据治理、数据开发、数据集工厂到自助分析的全过程，先从最痛的那一环切入就行，不用一次全上。步子迈小一点，反而走得远。

陈立航：看完最大的感受是”数据准备占60%工作量”这句。我们去年做模型平台就是栽在这，算法团队自己写脚本取数，跑了半年没人维护，现在一堆任务报错没人管。早看到这篇可能会少走点弯路。

周敏：登记字段砍到十五个以内这条太真实了。我们内部系统填一次要二十多分钟，结果就是大家都不填，最后报表里全是空值。准备拿去跟我们产品经理聊一下。

吴晓峰：主数据口径这一段我深有体会。同一个”有效客户”在三个系统里三个定义，模型上线后业务方质疑效果，光对账就对了三周。这块确实得提前做，不能等出问题再补。

林若彤：想请教一下，如果企业规模不大，模型就十几个，是不是可以先不上平台，用文档加流程管着？文章里提到按失控风险决定，这个判断标准挺实用的。

黄振国：分期验收的建议很实在。我们上一次项目就是一次性验收，中间某个环节卡住整个项目停了两个月，后来只能重谈方案。分成三段验收确实灵活很多。