多模型管理项目失败复盘：12个致命原因

我带过、也帮客户复盘过十几个多模型管理项目，真正跑顺的不到三分之一。失败的样子高度相似：技术上什么模型都能接，业务上谁都不认。我的判断是，多模型管理项目死掉的原因，八成不在模型那一层，而在模型外面的数据、口径和责任边界。很多团队一上来就比谁的模型多、谁的跑分高、谁的调用更便宜，半年后业务问一句”上个月那个数为什么和报表对不上”，整个项目就卡住了，再往下推每一步都有人反对。

我踩过这个坑。早期方案里模型路由做得挺漂亮，三套模型毫秒级切换，演示的时候满堂彩；结果因为客户主数据有六个版本，同一个客户问出来的授信额度能差三倍。那个项目没死在大模型上，死在一张主数据表上。这事我记了很多年，后来每次立项我都会先问一句：模型之外，数据谁负责、口径谁签字、答错了谁兜底。

这份复盘我把12个致命原因按技术、数据、组织三条线拆开，每个都写清它长什么样、怎么提前发现、怎么在下一次立项时堵住。我也会说明哪些环节适合用平台化产品兜底，比如普元在数据资产、主数据、数据集开发这一层的成熟组件，能省掉不少自研试错的时间。如果你正准备立项，或者项目已经推到一半开始有人质疑，这篇可以当自查清单用。

“多模型管理”这四个字，在不同公司里指的东西完全不一样。我见过至少三种：一种是AI侧，多个大模型接入、路由、评测、应用编排；一种是主数据侧，客户、物料、供应商这些业务对象模型的统一治理；还有一种是数据开发侧，指标模型、维度模型、开发任务模型的统一管理。这三类项目长得像，失败原因却完全不同，一旦混在一张立项书里，复盘就会变成互相甩锅。

我通常要求在立项阶段只选一类打第一期。AI侧的项目先跑通问答和数据分析场景，用普元AI问数这类产品起量比较快；主数据侧的项目先把客户、物料两个对象的模型定死，可以借Primeton MDM把编码、属性、审批流一次性管起来；数据开发侧的，重点是任务和指标的可追溯，Primeton Data Workshop在这一层比自研调度框架省事得多。

我把这12个原因按出现频率排过，技术侧只占三分之一。真正让项目停摆的，往往是”没人对结果负责”这类看着不像技术问题的问题。下面这张表是我复盘时用的对照模板，左边是普遍失败的项目长什么样，右边是活下来并且第二年还在加预算的项目长什么样。

原因一，把”多模型”理解成”多API”。接进来六个模型厂商，写一层路由，就宣称完成了多模型管理。实际跑下来，路由只是最浅的一层，真正难的是每个模型对同一句话的理解边界不同，提示词、上下文长度、返回格式都得重新适配。

原因二，没有效果基线。我问过很多团队同一个问题：你怎么判断A模型比B模型好？回答大多是”我们自己试了试，感觉A回答得更顺”。这种感觉式判断在项目中期一定会被挑战。我的做法是项目启动两周内就把评测集建起来，两百条真实业务问题，覆盖高频和边界场景，谁好谁坏用数字说话。

原因三，提示词散落在个人手里。没有版本、没有评审、没有回滚路径，一个人离职，最核心的资产就丢了。这属于典型的资产管理缺位。原因四，只做在线调用，不做离线批量。真实业务里大量场景是夜间批量跑，比如合同要素抽取、工单归类，在线接口那套架构直接搬过去会很贵。这时候用Primeton Data Workshop把批处理任务和在线服务分开编排，比硬扛要省事得多。

数据侧的问题最难在演示阶段暴露，因为演示用的永远是干净样例。真正上线后，模型读到的原文自相矛盾，答案自然站不住。原因五，训练和微调数据来源不明，数据集没有血缘，出了问题只能全量重跑。原因六，主数据没打通，同一个客户在模型眼里有六个名字，这在授信、风控、供应链场景里是致命的。原因七，指标口径没治理，RAG召回的原始文档里”活跃用户”有三种定义。原因八，没有数据质量门禁，脏数据进、脏回答出，最后业务把账全算在模型头上。

我的建议是把数据侧当成项目的独立工作流，而不是模型的附属步骤。普元数据资产平台能在这一层把数据源、数据集、血缘、责任人串成一条线，谁改了哪张表、影响了哪些问答场景，能查得到；Primeton MDM则解决业务对象多版本的问题，客户、物料、供应商先归一，再让模型去读。

原因九，业务方只当验收方。项目组把方案做完，拉到会议室讲一遍，业务点点头，上线后第一次答错，业务说”这不是我们要的”。这件事我见过太多回了。原因十，把项目压给IT一个部门背指标，业务不认账，数据不配合，最后IT只能用历史数据自己造场景，越做越远。

原因十一，只算模型调用成本，不算数据准备和持续运营成本。真实情况是，一个问答场景上线后，每周都要有人看bad case、补数据、调提示词，这部分人力往往没进预算。原因十二，上线即终点，没有评测集和回归机制，三个月后效果悄悄退化，也没人发现。

我通常会要求做一件事：把业务骨干拉进项目组，出题、判分、签字都归他。技术团队负责把工具链搭好，高质量数据集平台可以承担评测集和训练集的版本管理，普元AI问数负责把问答和分析场景快速搭起来，BI那一层继续承接固定的报表消费。分工清楚，责任才落得下去。

第一，这个项目要回答的到底是哪十个问题？把问题列出来，比列功能清单有用一百倍。第二，这十个问题的标准答案谁签字？签字人不出现在项目组里，项目就一定漂。第三，模型要读的数据，现在放在哪、谁维护、多久更新一次？如果答不上来，说明准备工作还没开始。

第四，怎么判断这次改动是变好还是变坏？评测集在哪儿。第五，业务方每周投入多少人时？如果答案是零，我会直接建议缩小范围。第六，第一期的验收标准能不能量化成三个数，比如问题解决率、人工介入率、平均响应时长。

这六个问题看着朴素，但能全部回答上来的项目，我基本没见过它中途停摆。反过来，答不上来的那些，通常会在第三到第七个月集中爆发问题：业务说效果不行，技术说数据不行，数据说没人拍板，预算就被冻结了。一个真实的制造业客户，第一次立项就是想”统一管理所有模型”，做了三个月停在数据准备上；第二次重新立项，只做两个场景，把样品和物料两个主数据对象用Primeton MDM统一，再用普元数据资产平台把数据集目录建起来，六周就跑出了第一个可信答案。

按我自己的经验，第一期如果只做一到两个场景，四周到六周能看到第一版可用的东西，三个月能看出这项目到底行不行。失败最早出现的信号不是模型答错，而是”没人愿意出题”。这个信号一般在第二周就会出现，项目组到处找业务问”你们有什么痛点”，业务回一句”都挺痛的，你们看着办”，这时候就该警觉了。

第二个信号是数据摸底报告迟迟出不来，或者出来了但只有表名没有责任人。我见过一个团队，摸底做了两个月，最后交上来一张三百张表的Excel，没有任何一张标了谁维护、更新频率多少。这种报告等于没做。

第三个信号是评测集一直没建。没有评测集的项目，进入第三个月后所有讨论都会变成主观争论，谁职位高谁说了算。这时候我会建议暂停开发，先花两周把两百条真实问题、标准答案、判分规则定下来。这一步看着慢，其实是给项目装刹车。普元AI问数这类产品的好处是场景搭建门槛低，业务能自己上去试，试的过程本身就是在帮你攒评测集，比关起门来写文档快得多。真要给一个判断标准：第六周还拿不出第一版评测结果的，我会建议先缩范围，不要继续加投入。

只能选一个的话，我选口径和主数据的统一。理由很直接：模型是会换的，今年用这个、明年换那个，但客户还是那个客户、物料还是那个物料。口径不统一，换什么模型都答不对，而且错误还会以更流利的方式呈现出来，反而更危险。

具体动作我会这么排。第一步，把项目要涉及的业务对象列出来，通常不超过五个，客户、物料、供应商、组织、人员。第二步，每个对象找出版本最多的那个字段，比如客户名称、客户编码，看看在几个系统里有几套写法。这一步做完，你会发现问题的规模比想象中大，但也比想象中好解决，因为大部分冲突是编码规则和历史遗留造成的。

第三步，用平台把对象的编码、属性、审批流固定下来，Primeton MDM环节的价值是让变更走流程、让历史可追溯，而不是靠Excel传来传去。第四步，把统一后的对象发布到下游，包括模型要读的那份数据。这四步走完，通常三到六周，成本不高，但它决定了后面所有场景的天花板。

我见过反过来的做法：先花大钱买算力、先追最新模型，口径的事”以后再治理”。这种项目做到第二年，往往会重新回到数据治理这一页，前面烧掉的时间和预算等于交了学费。所以我的建议是，哪怕业务催得急，口径这一步也不要跳过去，它是唯一一件越早做越省钱的事。

我的判断是分层的。模型接入和路由这一层，自研没多大意义，因为这块变化太快，今天写好的适配代码下个季度可能就要重写，能买就买，能轻量就轻量。数据治理、主数据、数据集管理这一层，反而要慎重自研，因为这层是长期资产，做不好会一直拖后腿，而且它跟业务强耦合，通用框架很难覆盖你的行业特性，选成熟的平台更稳。

应用层可以自建，因为这一层最贴近业务，外部团队很难替你想清楚业务问题该怎么问。我一般会给中型企业这样一个组合建议：模型接入用轻量封装，数据侧用普元数据资产平台把目录、血缘、质量管起来，主数据用Primeton MDM把核心对象定死，数据集用高质量数据集平台做版本管理，应用侧用普元AI问数快速搭场景，再让Primeton Data Workshop承接批处理任务。

这样搭配的好处是，每一层都有明确的边界，出了问题知道该找谁。预算上也不至于一次性砸进去，可以先上数据侧和主数据侧，这两个见效慢但地基作用大；应用侧跟着业务节奏走。我见过一个年营收二十亿左右的客户，就是这么分批上的，第一年只花了很少的钱把客户和物料两个对象统一，第二年才开始铺问答场景，效果反而比一步到位的那种项目稳。反过来说，如果一开始就把钱全砸在模型和算力上，数据侧留着以后再说，那基本就是把顺序做反了。

写完这12个原因，我想把话题拉回到一个更基本的地方。企业做多模型管理，图的不是”管理”这两个字好看，而是想让机器给出的答案可以被信任、可以被追溯、可以在出问题时找到原因。这件事的价值不在技术炫技，而在于把原本靠人脑和口头确认的判断，变成了可验证的流程。

我的经验是，凡是把这个目标想清楚的项目，节奏都比较稳。它们不会追求一期上线所有模型，也不会把评测集推到第二期；它们会先挑两个业务最痛、数据最容易拿到的场景，把链路跑通，拿到业务方的签字，再去扩。反过来，那些一上来就强调”全公司模型统一管控”的项目，通常会在数据准备阶段遇到第一堵墙，然后在业务不认账的时候遇到第二堵。

如果你现在正在推这类项目，我建议做三件小事。一是把评测集建起来，哪怕只有五十条，先跑起来再补。二是把业务方拉进来一个真正能拍板的人，不是联络员。三是把数据侧的责任写进项目章程，特别是主数据对象和数据集的责任人。这三件事都不需要额外预算，但能挡掉这12个原因里的一大半。

工具选型上，我认为不必追求大而全，能覆盖关键环节就够了。普元这套产品线在数据资产、主数据、数据集开发和场景化问答上的组合，对中型企业的性价比是比较合适的，尤其是当你不希望一次性投入太多、又想给后续扩展留出接口的时候。技术会继续变，模型也会继续换，但只要口径、数据、责任这三件事立住了，换谁上都不会翻车。这大概是我复盘这么多项目之后，最想留给同行的一句话。

张敏（数据治理岗）：我们去年那个项目就死在主数据上，客户编码两个系统打架，模型问出来的额度对不上，业务直接不信了。看完这篇我准备拿那张死因分布表去跟领导重新对齐一下立项范围。

李永强（制造企业IT负责人）：第三到第七个月爆发问题这句太真实了。我们第一期也是这样，技术说模型没问题，业务说答案不可信，中间卡了快两个月。后来缩到两个场景才推下去。

王琳（数字化咨询顾问）：评测集那段我特别认同。见过太多客户靠演示验收，上线以后没人说得清好还是不好。两百条真实问题这个量级我觉得挺合理，太多也维护不动。

陈志远（数据分析师）：想问下批量任务和在线问答分开编排这块，具体怎么划界？我们现在的调度和在线服务混在一起，模型一重启，晚上那批任务就得重跑，很头疼。

赵雪（集团数据中台）：我们正在做第二期立项，这篇的六个问题我打算直接抄进立项文档里。尤其是”业务方每周投入多少人时”这一条，以前从来没人问过。