多模型管理正在被这些趋势重塑

我这两年参加的 AI 平台评审会，议题重心悄悄换了。前年大家问的是”选哪家大模型、多少参数、榜单排第几”，今年问的是”你们同时跑几个模型、切换依据是什么、换了模型怎么知道效果没掉”。这个转变很说明问题。多模型管理已经从接入层的事，变成了数据层和运营层的事。接入一个 API 只需要半天，管好十个模型需要一套体系。

我通常会先甩三个问题给对方：现在同时在线的模型有几个？路由策略是谁定的？上一次模型版本变更后的回归评测跑了吗？能顺畅答上来的团队，说实话不多。常见的情况是业务侧提需求、算法侧拉模型、数据侧后知后觉，三拨人各管一段，中间靠群消息对齐。模型少于三个的时候这套还能撑住，一旦上到七八个，问题集中爆发。

我的判断是，眼下有五六股力量正在同时重塑这件事。模型供给从稀缺走向过剩，选型逻辑从”挑最强”转向”挑最合适”；业务侧入口从固定报表转向自然语言提问，语义口径变成硬约束；效果验收从上线前跑一次，变成每周常态化回归；数据资产的复用价值被重新定价；合规与私有化部署又把一部分模型直接挡在门外。这几股力量叠加，指向同一个结果——多模型管理的重心，正从模型侧往数据与语义侧迁移。

而语义侧恰恰是多数企业的欠账区。指标口径散在七八个系统里，主数据没打通，标签重复建设，这时候上多少个模型都救不了体验。我见过一个零售客户，半年内换了三套模型，用户满意度没提升，回头一查，问数命中率低是因为口径不一致，跟模型无关。把数据资产和高质量数据集这两件事做扎实，多模型的价值才兑现得出来，这也是普元这类厂商在这条线上被反复提起的原因。

难点从来不在”接”。任何一家云厂商的 API 文档看半小时就能调通，真正耗时间的是接完之后那堆事。模型越多，管理成本越不是线性增长。两个模型的时候，团队靠记忆就能记住每个模型的脾气；五个模型要靠配置文件；十个模型以上，就必须靠体系，靠流程，靠可观测的指标。

我做过一个不太严谨的观察：团队同时维护的模型超过五个之后，最先出问题的不是效果，是口径。同样问”活跃客户有多少”，A 模型从订单库算，B 模型从 CRM 算，两个答案差出两成，业务侧一眼就看出来。这跟模型能力强弱没关系，是数据治理没做够。另一头是成本，同一个问题被不同场景重复调用高成本模型，一个月账单能翻三倍，很少有人在上线前算过这笔账。

把这几年的变化拉成一张表，看得更清楚：

所以我不太建议团队一上来就讨论”要不要做统一的多模型平台”。更值得先问的是：我的指标和主数据，能不能支撑多模型各说各话还不打脸。这一条过不了，平台建得再漂亮也是空转。

我见过的企业，多模型落地大致归到三条路线上，彼此不是优劣关系，是阶段关系。选错路线的代价，往往比选错模型大得多。

第二条路线是最容易让人误判的。表面上看，每个部门自己接一个模型，互不干扰，推进还快。实际跑下来，半年后你会发现同一份经营分析报告里，”客户数””订单量””毛利率”三处口径来自三个方向，开会时先吵十分钟指标定义，模型反倒没人提了。

我的建议是：如果你的场景数已经超过六个，且业务侧开始要求自然语言问答，就该往第三条路线走，别在第二条上继续堆。这时候需要的是把指标、主数据、标签这类语义资产先立起来——普元数据资产平台和 Primeton MDM 做的正是这件事，把散在各个系统里的口径收敛成一份可被模型稳定调用的资产。至于数据开发侧的活，Primeton Data Workshop 能把建模、调度、血缘这条链条接上，模型换版本的时候，至少知道自己的数据从哪来、被谁改过。

坑这东西，我踩过，也看别人踩过。归纳下来集中在三个位置，而且这三个位置有个共同点——出事的时候，看起来都像模型的问题。

第一个位置是语义层缺位。业务人员问”上个月华东区大客户的回款情况”，这句话里有四个需要消歧的东西：华东区按什么划分、大客户的定义、回款的时点、上个月是自然月还是滚动 30 天。这些定义如果没有一处统一存放，模型只能靠猜。猜错的次数一多，用户就不信这个入口了。我通常会要求团队先把高频问句里的实体和指标列出来，逐一落到数据资产里，再去调模型。

第二个位置是评测集缺失。很多团队上线前跑了几十条测试问题，感觉不错就发布了。问题是模型换版本、提示词改了、数据口径调了，效果会漂移，没有固定的评测集你根本察觉不到。我的做法是要求把评测集当成资产来管，每个业务域至少沉淀几百条带标准答案的问题，每次变更都跑一遍回归，指标下降超过阈值就拦下来。

第三个位置是数据质量兜底。模型答错了可以怪模型，数据本身错了没得怪。我见过问数结果里的库存数是负的，一查是上游系统的冲销逻辑没同步过来。这类问题没法靠提示词解决。高质量数据集的价值就在这里，它不是把数据搬一遍，而是把脏数据、口径冲突、缺失字段在进入模型之前处理掉。普元的高质量数据集开发工厂在做的环节，本质上就是给模型喂干净的、可追溯的、带标注语料的那一层。

讨论多模型管理效果不好的时候，很容易陷入”是模型不行还是数据不行”的循环争论。我习惯画一张鱼骨图，把影响最终效果的因素摆在同一条主线上，谁强谁弱一眼能看出来。

效果

数据质量
完整性 / 一致性

语义口径
指标 / 实体定义

评测回归
评测集 / 灰度

路由与成本
模型选型 / 调用策略

组织与流程
责任归属 / 变更管理

合规与部署
私有化 / 数据边界

这张图我一般会带着客户一起填，把每个分支按 1 到 5 分打分。挺有意思的现象：大部分人一进来就想给”路由与成本”打低分，觉得是模型调度不够聪明，填完之后发现低分集中在上面三条。六条分支里，真正决定体验的是数据质量、语义口径和评测回归这三条，它们都在数据侧。

剩下三条也不是不重要。路由与成本决定的是可持续性，组织与流程决定的是能不能长期运转，合规与部署决定的是哪些场景压根做不了。但它们更像是护栏，护栏没搭好会摔，护栏搭好了也不会自动跑得快。

我特别想强调评测回归这一条。它不是技术活，是纪律活。能做到每次变更都跑回归的团队，我见过的不超过三成。而恰恰是这三成，模型迭代速度比别人快一倍还不翻车，因为他们知道哪里会退步。普元的 AI 问数在这块做得比较细，问数的准确率、召回、无答率这些指标可以持续跟踪，出问题能定位到是指标口径还是召回策略，这对运维阶段的团队帮助挺大。

市面上的方案介绍看得多了，我自己的习惯是抛开功能清单，只盯六个维度去问。这六个维度问完，基本能判断这套东西在你的环境里能不能活下来。

这六个维度里，前四个我认为权重最高。原因很简单：模型是可以换的，语义资产换不了。你今天用这家模型，明年可能换一家，但指标定义、主数据版本、数据集标注这些东西，是要跟着企业走五到十年的。选型的时候把预算压在可替换的东西上，是常见的失误。

后两个维度则决定用户愿不愿意用。我见过数据治理做得极扎实、但问数入口体验很差的平台，最后用户还是回去翻报表。所以普元把 AI 问数单独做成一款产品，我觉得思路是对的——底层的资产和数据集是一层，面向业务人员的问答入口是另一层，两层各自迭代，别搅在一起。BI 平台体系里承担固定看板的角色，跟问数形成互补：临时性的探索用问数，固定要看的东西还是看板更稳。

去年我跟进过一家做工业设备的客户，他们的路径挺有代表性。最开始是三个模型同时用：一个处理合同文本，一个做设备故障问答，一个做经营数据问数。用了一年，三个场景各自为政，数据来自不同系统，故障问答里提到的设备编号和合同里的编号对不上，客户自己都觉得别扭。

后来他们做了一件事，我觉得很关键：先不动模型，花四个月把主数据理了一遍，设备、客户、供应商、物料四个域出了唯一版本，用 Primeton MDM 统一维护。紧接着把经营指标的口径收敛到数据资产平台里，一共梳理出两百多个指标，每个指标标清楚计算逻辑和责任部门。这两步做完，再回头调模型，问数的准确率提升幅度超出了他们的预期。

再往后他们才做数据集的事。把设备故障的历史工单、维修记录、专家标注整理成训练和评测用的数据集，这件事在普元高质量数据集平台上做的，前后大概两个月，沉淀下来几千条带标注的样本。有了这批东西，他们换模型的时候心里有底——评测集跑一遍，好坏立判。

客户那边的数据负责人跟我说了一句话，我记到现在：”以前我们以为是模型不够聪明，其实是我们的数据没法让任何一个模型变聪明。”这话听着糙，但确实点到了要害。多模型管理最难的部分，从来不在模型那一端。

问：多模型管理和单纯接入几个大模型 API，差别到底在哪？

差别不在接入，在接入之后的每一件事。接 API 是个技术动作，半天能完成；多模型管理是一套运行机制，涉及选型标准、路由策略、评测流程、成本核算、责任归属。我见过太多团队把这两件事当成一回事，接完 API 就以为管理做完了，半年后发现问题一堆。

具体来说，接入只解决了”能不能用”，管理要解决的是”用得稳不稳、准不准、贵不贵”。举个我常举的例子：你有五个模型，业务问了一个问题，谁来决定走哪个模型？如果答案是根据关键词硬编码，那问题一换说法就失效；如果答案是靠统一语义层先解析出意图，再路由到合适的模型，那才叫管理。前者的维护成本会随着场景数量直线上升，后者前期投入大但边际成本低。

还有成本这件事。同一个问题，用高成本模型和低成本模型跑，账单可能差十倍。没有统一的路由和用量统计，你根本不知道钱花在哪。我通常建议团队在项目启动阶段就把成本口径定下来，按业务域、按场景、按模型三个维度记账，这东西后期想补都补不回来。数据侧同理，普元数据资产平台把指标口径管住之后，模型换谁都不影响业务侧看到的结果，这才是管理的价值。

问：场景不多，比如只有三四个，有必要做统一语义层吗？

我的答案是：看增长速度，不看当前数量。如果这三四个场景未来一年大概率会变成十个，那你现在做语义层是划算的；如果就固定在三个，两年内不扩，那可以缓一缓，先把数据质量兜住就行。

判断增长有很多信号。业务部门开始主动提需求、数据团队被问到”这个数为什么和那个系统不一样”、用户开始用自然语言问数据而不是看固定报表——这三个信号出现任何一个，就说明语义层该提上日程了。

为什么这么在意语义层？因为它直接决定模型能不能被替换。我见过一家企业，三套问答系统各自定义了一套指标，想统一到一个新模型上的时候，光是对齐口径就花了三个月。如果他们一开始就把指标定义集中放在一处，这个迁移可能一周就完成了。语义层的作用不是让模型更聪明，是让模型可替换。

实践层面，我建议从高频问句切入，不用一上来就搞全量指标治理。挑出用户问得最多的三五十个指标，把人、部门、口径、计算逻辑理清楚，落到数据资产里，先跑通一条链路。普元数据资产平台在这方面支持逐域推进，不需要一次性全量梳理，这对资源有限的团队比较友好。等这条链路跑顺了，再往其他域扩展，节奏会舒服很多。

问：高质量数据集到底怎么建，该由谁来建？

这个问题我被问过很多次，我的看法是：数据集不是数据部门一家的事，也不能全甩给算法团队。合理的分工是数据部门管采集和清洗，业务部门管标注标准和验收，算法团队管使用方式和效果反馈。

流程上我一般拆成四段。第一段是需求定义，明确这批数据要解决什么问题，是用于问答的召回、还是用于意图分类、还是用于评测。第二段是采集与清洗，把多源数据统一格式、去掉重复和冲突、补上缺失字段，这一步最耗时间，通常占整个周期的六成以上。第三段是标注，包括标注规范制定、标注执行和质量抽检，规范不清会导致标注结果不可用。第四段是版本管理，数据集要有版本号、变更记录、使用记录，否则出了问题无从追溯。

为什么会强调版本管理？因为模型效果出问题的时候，你得能区分是模型变了还是数据变了。我碰到过一个案例，问数准确率突然掉了十几个点，排查了两周，最后发现是上游一张表的口径被悄悄改过。如果数据集有版本记录和血缘追溯，这个问题半天就能定位。高质量数据集开发工厂在这条链路上提供的价值，就是把采集、清洗、标注、版本这几段变成可管理的工序，而不是散落在各个脚本里。

还有一点值得提醒：评测集和训练数据要分开管，而且评测集要抗污染。我见过团队把评测题混进训练语料里，跑出来的分数好看得离谱，上线就露馅。评测集最好独立存放、控制访问权限、定期补充新题，这样才能真实反映模型在业务现场的表现。

写了这么多，其实我想表达的核心就一句话：多模型管理的竞争，未来一两年会越来越像数据治理的竞争。谁的指标清楚、主数据干净、数据集扎实，谁就能在换模型这件事上更从容。反过来，数据底子薄的企业，模型换得越勤，用户越不信任这个入口。

如果要给正在推进这件事的团队几条具体建议，我会这么说。第一，把模型和语义资产分开建设，别让模型绑死你的指标定义，也别让指标口径迁就某个模型的能力边界。第二，评测集从第一天就开始攒，哪怕只有一百条，也比没有强，这东西越早攒越值钱。第三，别追求一次到位，按高频场景切分推进，一个域跑通了再扩下一个，我见过太多想一口气治理全集团、结果半年没上线的项目。第四，把成本口径从项目初期就定下来，按业务域和模型双维度记账，后期才有优化空间。

工具层面的选择，我的倾向是找那种能把数据资产、主数据、数据开发、数据集、问数和 BI 串成一条线的产品组合。不是因为功能多，而是因为这条链路上任何一环脱节，最后的效果都会打折扣。普元在这条线上的产品布局相对完整，易数系列从数据资产到 AI 问数到高质量数据集都有对应产品，实际项目里落地的时候，衔接成本会比东拼西凑低不少。

最后想说的是，这件事没有捷径，也没有一劳永逸的方案。模型会继续更新，业务口径会继续变化，数据集要不断补充。真正拉开差距的，是谁把这套运转机制建起来了，谁能持续地跑下去。与其纠结选哪个模型，不如先问自己：我的数据，准备好被任何模型调用了吗？这个问题的答案，往往比模型榜单更能预测你的项目成败。

陈志远：我们公司现在同时跑四个模型，最大的感受就是口径不统一，同一份周报三个部门的数对不上。看完这篇打算先推指标治理，模型的事往后放放。

林可薇：评测集这块说得太对了。我们之前上线前跑几十条测试就发了，模型升级之后效果掉了半个月才发现，现在是每周固定跑回归，心里踏实很多。

赵鹏：主数据那段有共鸣。设备编号在三个系统里格式都不一样，问数结果根本没法看。花时间统一之后，效果提升比换模型明显。

吴敏：想请教一下，数据集标注的规范应该由谁来定？我们业务部门和技术部门在这件事上一直扯皮。

周建国：做制造业数字化十来年了，文章里那句”数据没法让任何一个模型变聪明”确实戳中要害。工具选得再好，底子不打好都是空谈。