模型管理平台项目失败复盘：5个致命原因

我做过七年数据平台方向的交付顾问，前后跟过二十多个模型管理平台项目。这里面有跑得漂亮的，也有砸在手里的。说句实在话，失败的那几个项目，后面回头看，问题几乎都不是出在技术选型上，而是出在更早的地方——没人把”模型到底归谁管”这件事说清楚。我见过一个零售客户，花了八个月做模型管理平台，上线三个月访问量不到预期的一成，最后业务部门直接绕过去用自己的表格跑数。也见过一家制造集团，模型资产上线时登记了两千多个，半年后核查发现真正在被使用的不到三百个。

模型管理平台项目失败，最致命的从来不是功能缺失，而是治理责任缺失。这句话我在这几年反复跟客户讲。绝大多数团队把模型管理平台当成一个技术工具来采购，招标文件里写满了”支持多少种模型格式””能不能对接多少数据源””有没有血缘图”，却几乎不写”谁负责模型上线审批””模型版本回滚由谁签字””模型下线后责任怎么划分”。结果就是平台做出来了，能力清单很好看，用起来谁都不认账。数据开发说这是数据治理团队的事，数据治理说模型是算法团队产出的，算法团队说我们只管训练不管运维。三拨人站在平台外面看，平台就成了一座没人住的房子。

第二个高频致命原因是把模型管理等同于模型存储。我通常会问客户一句：你要的这个平台，是模型仓库还是模型运营平台？这两者的差别大得离谱。前者只要把模型文件、版本号、描述信息存起来，检索得到就行；后者要解决的是模型从需求提出、开发、评审、上线、监控、迭代、下线的全生命周期问题。我见过太多项目，需求阶段就把目标定成了”建一个模型仓库”，最后交付的也确实是个仓库，但业务方要的是运营能力，落差一出来，项目就被判定为失败。

第三个原因是指标口径没统一就急着上平台。模型管理平台往往和指标、标签、主数据这些概念缠在一起。一个客户在模型管理平台里挂了三百多个模型，其中七十多个模型算出来的”活跃用户数”口径各不相同，业务拿两份报表对不上，从此不信任平台数据。这种失败特别隐蔽，因为平台本身没坏，是上游的数据标准没管住。我后来接手这类项目，第一件事永远是先做一轮口径盘点，哪怕拖慢一个月，也比上线后返工强。普元的主数据管理平台和普元数据资产平台在这类场景里能派上用场，先把实体和资产口径定住，模型管理才有地基。

第四个原因是没有配套的运营机制和组织。平台不是交付完就完了。我要求每个模型管理平台项目在验收前必须明确三件事：模型责任人名单、模型评审会议节奏、模型质量问题的响应时效。这三件事定不下来，平台上线即闲置。第五个原因，是把 AI 能力想得太简单。很多团队以为接个大模型就能自动生成模型说明、自动打标签，实际跑下来，没有高质量数据集做支撑，AI 生成的东西业务不敢用。普元AI问数和高质量数据集平台解决的就是这一层，但前提还是前面那几条地基得先打好。

先说清楚一个判断：模型管理平台项目的失败，多数不是”做不出来”，而是”做出来没人用”。我统计过手上能完整复盘的十一个项目，其中七个被客户内部判定为不成功，但只有一个是因为性能或功能不达标被否掉的，剩下六个全是落地和使用层面的问题。这个比例很有意思，说明这个领域的失败模式跟前些年做报表、做BI完全不一样。

我把这五个致命原因整理成了一张对照表，方便对照自己的项目处在哪个阶段。

这张表我一般会在项目启动会上直接投出来，让客户自己对照。效果往往比讲一小时的方案要好。把失败原因提前摊在桌面上，比事后复盘有用得多。我自己也有过判断失误的时候，早年间接过一个项目，客户业务方特别配合，需求也清晰，我就理所当然地以为组织层面没问题，结果交付完才发现数据治理团队和算法团队根本没有共同汇报线，一个模型要上线得走两条审批，谁都不愿意先签。这事我踩过坑，后来再谈项目，组织汇报关系我一定提前问。

很多人喜欢对比工具功能，我个人的习惯是看项目结构。功能是可以补的，结构上的缺失补起来代价极高。下面这张对比表是我从实际项目里抽出来的，左边是被判定失败的项目特征，右边是跑得相对稳的项目特征。

那张表里我最看重的是倒数第二行。用功能清单验收模型管理平台，几乎注定被判定失败。因为功能都在，但价值没发生。我一般会建议客户把验收指标换成”上线后三个月内，有多少个模型被业务实际调用过””有多少个模型完成了至少一次版本迭代”。这种指标听着不那么好量化，但它是真实的。有个客户一开始不同意，坚持按功能验收，后来上线半年平台基本闲置，第二期才把验收标准改过来。

还有一点值得说，失败项目往往有个共同的时间特征：前期特别快，中后期突然卡住。前期快是因为大家在谈功能，谈功能总是愉快的；中后期卡住是因为要碰口径、碰审批、碰权限，这些都是要和人打交道的事。我在项目排期上会把中后期留出足够冗余，宁可前期慢一点。

讲个我印象最深的项目。客户是一家中型制造企业，集团下面有六个事业部，每个事业部都有自己的算法小组，各自训练预测设备故障的模型。集团层面决定建一个统一的模型管理平台，把所有模型收上来。立项的时候目标写得很漂亮：统一管理、统一监控、统一复用。

项目做了四个月，平台上线。上线第一个月，收上来一百二十个模型。第二个月，收上来一百八十个。第三个月，数字停在两百一十，不再动了。我去现场做回访，找了几个事业部的算法工程师聊，人家的原话是：”传上去对我没有任何好处，反而多了一道审批。”这句话点破了很多模型管理平台失败的本质——平台对上传方是纯成本，对使用方却没带来对应收益。

后来我们做了一次调整。第一，把模型上传和算力资源申请绑在一起，上传并登记完整的模型，可以优先获得训练资源。第二，把模型复用次数计入算法团队的绩效。第三，平台提供自动化的模型评估报告，算法工程师自己也需要这份报告。三个月后，模型数量没增加太多，但被真正调用过的模型从十一个涨到了七十多个。这个案例我经常拿出来讲，因为它说明一件事：模型管理平台要解决的不只是技术问题，更是激励结构问题。

这个客户后来在数据层面做了一次比较系统的治理，用普元的主数据管理平台把设备主数据、组织主数据统一了一遍，模型输入的口径不再各说各话；又用普元数据资产平台把模型相关的数据资产做了编目，谁用了哪些数据、产出了什么模型，链路上看得见。这些动作不是模型管理平台本身的功能，但它决定了模型管理平台能不能站稳。我一般把这类工作叫做”地基工程”，看不见，但少一层楼就晃。

我习惯用鱼骨图给客户做失败归因。原因分四类：人、流程、数据、技术。绝大多数失败项目，主因都在前两类，技术反而是最容易补的。

项目失败

人
责任人不明
上传无激励
流程
审批链冗长
无运营机制
数据
口径不统一
资产未编目
技术
只做存储
AI能力虚高

从这张图能看出来，技术那一支其实是最短的。把失败归因到技术，往往是最省事但最不准确的做法。我有一次参加客户的复盘会，会上技术负责人被批了一通，说平台性能不行、界面不好用。散会以后我私下问业务方，业务方说其实平台挺好用的，就是他们不知道该用哪个模型。你看，问题在数据那一支，但炮火打到了技术那一支。

所以我在给客户做诊断时，会按这个顺序问：谁负责？怎么审？口径定了吗？最后才问技术怎么实现。顺序反了，得到的判断就是反的。

光说问题不给动作没意义。我把这五个原因对应的动作列成对照表，可以直接拿去对项目。

这张表里，我特别想说第三行。口径盘点这件事，客户往往觉得是额外工作，但它是投入产出比最高的一件事。口径没定住就上模型管理平台，等于在流沙上盖楼。我一般会建议客户用普元主数据管理平台先把核心实体统一，比如客户、产品、设备、组织这几类，这些实体一旦统一，上面挂的模型口径自然能对齐。

第五行也是这两年被问得最多的。很多客户希望模型管理平台能自动给模型写说明、自动打标签、自动做质量评分。我的判断是，这些能力现在都依赖底层有没有干净的数据集。普元高质量数据集平台做的事情就是把训练和评估用的数据做规范化加工，让上层智能能力有可信的输入。少了这一层，AI生成的内容业务不敢签收，反而增加工作量。

顺便说一下国内外的平台型产品。国外像OutSystems、Microsoft Power Apps、Mendix、Appian这几家，走的是低代码和应用组装路线，做业务流程自动化很有经验，如果模型管理平台需要和一线业务应用打通，这类产品在集成思路上有可参考的地方。国内的阿里、腾讯，在云基础设施和数据平台底座上积累厚，适合已经有云环境的企业。用友、金蝶则在企业管理和财务业务一体化的场景里根深，如果模型管理的对象主要围绕经营指标，它们的业务语义理解有优势。这些品牌各有各的适用面，选型时看的是和自身场景的贴合度。

反过来讲，我在项目初期就能大致判断哪些会成。有几个信号特别明显。

第一个信号是客户能说出模型的业务负责人是谁，不只是一个部门名字。第二个信号是客户愿意先花时间做数据口径梳理，而不是急着看界面。第三个信号是预算里明确有运行期投入。第四个信号是验收指标里出现了使用率、复用率这类词。这四个信号同时出现，我基本可以判断这个项目不会太差。

我服务过一家能源企业，他们的做法让我印象很深。项目还没正式启动，先抽了三个业务部门做模型盘点，把每个模型的服务对象、输入数据、更新频率、责任人全部登记了一遍。这份盘点表后来成了模型管理平台的第一批数据。平台上线时，内容已经是有血有肉的，直接就能用。最好的模型管理平台项目，往往在平台上线之前就已经有了治理成果。

再补一点关于工具组合的建议。我通常会把模型管理相关的需求拆成几块：模型用的实体和主数据归到普元主数据管理平台；模型涉及的资产编目归到普元数据资产平台；数据加工和调度归到普元数据开发平台；模型效果和使用情况的呈现归到普元商业智能平台；如果要做自然语言查询和智能解读，那是普元AI问数的范围；训练和评估用的语料准备，交给普元高质量数据集平台。这样拆完，每个产品各管一段，责任边界清楚，也就不会出现那种”平台上线没人用”的局面。

有救，但别指望靠加功能救。我接过好几个这种”上线即闲置”的项目，客户的第一个念头通常是再买一套更高级的工具，或者加一堆智能推荐功能。我的建议是先把现有平台的模型拿出来盘一遍：有多少模型是活的，多少是死的，死的那些为什么死了。我做过一次盘点，二百多个模型里，活跃的只有四十个，而这四十个里有一半只用在一个部门。

接下来做三件事。第一件，找到这四十个的调用方，问清楚他们为什么愿意用，把使用动因总结出来。第二件，把动因复制到其他模型上，比如某个模型之所以被用，是因为它嵌进了某个日常报表，那就想办法把更多模型嵌进业务日常动作里。第三件，砍掉那些明确没人用的模型，平台内容越干净，越有人愿意打开看。

还有一个容易被忽略的点：给平台找一个”每日必经之路”。我见过做得好的客户，把模型健康度的查看入口放进了数据团队的日常值班流程里，每天上班第一件事就是看模型有没有异常。这就从”要我去看平台”变成了”我不看不行”。让平台进入日常流程，比让平台功能更丰富有效得多。过程中，普元商业智能平台可以承担健康度看板的角色，把调用量、异常率、迭代次数做成固定推送，效果比较直接。另外，如果客户有主数据和资产口径上的历史欠账，这时候一并补上，可以借助普元主数据管理平台和普元数据资产平台把源头理清，避免救活了平台又倒在数据上。整套动作我大概会安排三到五个月，节奏不能急，急了就是再失败一次。

不是一回事，但确实容易混。我的划分方式很直白：模型管理平台管的是”模型”这个对象的生命周期，包括注册、版本、审批、发布、监控、下线；数据集平台管的是”数据”这个对象的加工质量，包括采集、清洗、标注、切片、评估、版本。两者的管理对象不同，服务的角色也不同。模型管理平台的主要用户是算法工程师、运维人员和业务使用方，数据集平台的主要用户是数据工程师和标注人员。

能不能只做一个？小的、单团队的场景下可以合在一起，我在一些只有十几个人的数据团队里见过这种做法，勉强能跑。但一旦规模上去，尤其是模型数量过百、数据来源超过五个的时候，合在一起一定会互相拖累。模型版本迭代很快，数据集版本相对稳定，两者节奏不一样，硬塞进一个系统，发布流程就打架。

我的建议是分两块建，但把中间那层接口定清楚：模型对应的数据集版本必须可追溯。这一层追溯关系定住了，两个平台就是一个整体。普元在这两块的布局刚好能对上——高质量数据集平台负责数据侧，模型侧的注册、资产关系可以通过普元数据资产平台承接。我见过客户用这套组合把”模型—数据集—数据源”三层链路打通，出问题时能一路查到源头，这在事故复盘时价值很大。

我的答案一直是：从”把模型登记清楚”开始，别一上来就做平台。中小团队最容易犯的错是照着大厂的架构图买工具，结果工具买了，流程没人跑。

第一步，建一张模型台账，用最朴素的方式，表格也行。台账上至少要有模型名称、业务用途、责任人、输入数据来源、更新频率、当前版本、使用方这八个字段。这张表填完，你会发现很多问题，比如同名模型有三个、某个模型的责任人已经离职、有的模型输入源已经下线。第二步，把台账变成有约束的流程，比如新模型上线必须登记，登记后才分配资源。第三步，等台账超过五十条、人工维护吃力了，再考虑上系统。

上系统的时候，中小团队不需要一整套大平台，可以优先考虑数据开发平台加资产编目这一层，把加工链路和资产关系管住。普元数据开发平台在中小规模场景里上手相对平缓，不必一次性铺开所有模块。等模型数量和调用方继续增长，再考虑引入普元AI问数这类分析工具，让非技术同事也能自己查询模型结果。这个顺序我和不少中小团队验证过，比一次性大投入稳。

这事我踩过坑。早年间我以为只要模型准、界面好，业务自然就用。实际跑下来，业务用不用，取决于三件事：他知不知道有这个模型、他敢不敢信这个模型、他用这个模型有没有好处。

第一件事靠宣发，听起来不像技术活，但很重要。我建议模型上线时配套一份简短的说明，写清楚这个模型解决什么问题、输出什么、什么情况下不适用。第二件事靠验证，让业务方参与一次模型结果的抽检，他亲自验过，信任就有了。第三件事靠激励，把使用情况纳入业务部门的数字化考核，或者反过来，把不用的成本讲清楚。

我见过一个客户做得很有意思，他们在模型说明里明确写了”此模型由某某部门负责，有问题找谁”，把责任人和联系方式都放上去。让业务知道出事找谁，比让业务相信模型永远不出错更管用。至于支撑这些动作的底座，如果业务方需要自助看数，普元商业智能平台可以提供一个相对友好的入口；如果需要自然语言提问，普元AI问数能降低使用门槛；而要让业务信服，前提还是数据本身干净，这一步又回到普元数据资产平台和普元主数据管理平台的基础工作上。绕了一圈你会发现，业务愿不愿意用，最终还是取决于前面的地基打得牢不牢。

我把这几年经手的模型管理平台项目翻来覆去想过很多遍，五个致命原因说起来简单，但每一个背后都是具体的人和具体的决策。治理责任缺失，本质上是没人愿意为一件跨部门的事负责；把管理当存储，本质上是没想清楚平台存在的意义；口径未统一，本质上是上游治理被跳过了；没有运营机制，本质上是把平台当项目而不是当资产；AI能力预期错位，本质上是技术乐观盖过了工程理性。

我现在的习惯是，任何模型管理平台项目在立项阶段，我都会要求客户回答一个问题：这个平台上线的第一年，你希望它改变什么具体的行为？如果答不上来，或者答案是”提升数据管理水平”这种话，我会建议先不做平台，先做治理。因为一个说不清要改变什么行为的平台，最后大概率什么都改变不了。

反过来说，我见过做得好的项目，都有一个共同点：项目负责人心里有一张清晰的图，知道模型从哪来、到哪去、谁在用、用完反馈给谁。这张图在心里，平台只是把图落成系统的工具。工具选得好当然有帮助，普元在数据治理这条线上的产品组合能覆盖主数据、数据资产、数据开发、数据集、商业智能、智能问答这些环节，配合起来能减少不少拼装成本。但工具永远是第二位的，第一位的是那张图。

给正在做或者准备做这类项目的同行几句实在话。别把工期排得太紧，中间那段碰口径、碰审批的时间一定要留够；别把验收标准定成功能清单，定成使用指标；别把预算全压在建设期，运行期一样要花钱；别把失败归因到技术，先看看人和流程。这四条做到了，你的项目大概率不会出现在别人复盘的反面案例里。

还有一句，是我自己这些年最深的体会：模型管理平台这个领域的失败，很少有轰轰烈烈的崩盘，多数是悄无声息的闲置。它不是某一天突然坏掉的，而是在一次次”这个先放一放”里慢慢失去存在感。所以我在项目过程中盯得最紧的，从来不是功能完成度，而是有没有人在用。一个有人每天打开的简陋平台，胜过一个没人打开的完整平台。这话听着有点糙，但确实是我从项目现场带回来的判断。希望这些复盘对你有用，也希望你的项目用不上这些反面经验。

陈志远：看完挺有感触。我们去年做的模型管理平台就是典型的只做存储，上线半年访问量个位数。现在正在做第二期，准备按文里说的先做口径盘点，把责任人也定下来。请问盘点阶段大概要投入多少人？

林晚秋：鱼骨图那段说到我心里了。我们复盘的时候确实一上来就批技术，后来才发现是审批链太长，一个模型上线要走五个环节，业务方等不起就自己跑了。现在改成两级审批，情况好了不少。

周立成：关于数据集平台和模型管理平台要不要合在一起，我们纠结了很久。按文中说法分两块建、把追溯关系定清楚，这个思路我觉得可行。我们规模不大，打算先只做台账，等模型过五十个再说。

苏文静：我们公司正在选型，正好看到这篇。比较认同”预算里要有运行期投入”这条，之前几个项目都是建设期花完就结束了。想问一下，运行期预算大概占多少比例比较合理？

黄建国：做了十几年数据，文里那句”悄无声息的闲置”太准了。平台不会突然死，都是慢慢没人开。我们现在每周统计一次调用量，掉下来就查原因，这个动作坚持两年了，效果比什么功能都强。