用生活例子说明多模型管理是什么意思

我做过不少企业数据平台和 AI 应用的活儿，这两年最常被问到的一类问题是：公司里已经接了两三个大模型，接下来该怎么办。我的回答一直很直白——该管起来了，这就是多模型管理。它不是把 API 多接几个、在聊天框里加个切换按钮那么轻巧，而是一整套”谁干活、谁兜底、花多少钱、答错了能不能查”的调度秩序。很多团队在做第一版 AI 应用时，图省事，写死一个模型，哪儿都用它；等业务量上来、账单吓人、领导追问”为什么同一个客户在报表和问答里是两个数”的时候，才发现问题不在模型本身，而在没人管这些模型。所以我喜欢用一个特别生活的比喻来解释这件事：你家同时请了三位家教，一位教数学、一位教英语、一位教钢琴，孩子成绩确实上去了，但谁周几来、每小时多少钱、这次考砸了到底是哪位的责任、下学期要不要换人，这些事没人管，很快就是一笔糊涂账。多模型管理干的就是这个”家庭总管”的活。它至少覆盖四件事：模型的接入与上下线、任务的分配与兜底、喂给模型的数据与口径、以及成本权限和效果评测。少了任何一块，用得越久越难受。我的经验是，多模型管理做得好不好，决定的不是模型多聪明，而是这套系统能用多久。

第一个场景是三位家教。你请人不是目的，孩子成绩提升才是。放在企业里，模型就是这些”老师”，任务就是”作业”。数学题交给擅长推理的模型，文案交给擅长写作的模型，图像识别交给多模态的模型。道理谁都懂，难的是怎么在系统里自动完成这个分派，而不是靠程序员手工写 if-else。我见过一家公司，路由规则全写在代码里，三个月攒了两百多行判断，谁都不敢改。这就是缺调度层。

第二个场景是家里那三个遥控器。看电视一个、开空调一个、机顶盒一个，找起来烦。多模型也一样，业务方今天问 IT 要 A 模型的接口，明天要 B 模型的账号，后天说 C 模型的额度不够了。时间一长，IT 变成发钥匙的门房。统一入口的价值，是让业务方只面对一个”问数”界面，底下换哪个模型，他不用知道。这也是我一直主张的：对使用者做减法，对管理者做加法。

第三个场景是家里的电表和门禁。你不需要天天看电表，但月底账单出来得能对上；家里丢了东西，门禁记录得能查。模型调用同样如此，谁在什么时间、用什么身份、问了什么问题、走了哪个模型、花了多少 token，这些账目不清楚，成本就管不住，安全也谈不上。至于用哪套工具把这笔账记清楚，我在后面几段里会讲到我自己的选型习惯。

我做项目时一般把企业的选择分成三条路，每条路都有它的代价，没有一条是白捡便宜的。选路的依据不是技术先进不先进，而是你的模型数量和业务复杂度会不会继续涨。如果一年内只会用一个模型、只服务一个部门，那自己攒个小框架就够；一旦要面向多个业务线，统一管理的账才算得过来。

头一个坑，是把”接了 API”当成”做了管理”。这事我踩过。项目第一期接了三个模型，演示很漂亮，上线两个月后运营同事问我：为什么同一个问题，早上和下午答得不一样？我一查，中间有人偷偷改了一个参数。没有版本记录，没有变更流程，等于把生产系统交给了运气。

第二个坑，是迷信”参数越大越好”。有些任务就是查个数、做个归类，用大模型纯属浪费，延迟还高。我现在的习惯是按任务难度分档，简单任务走轻量模型，复杂推理才调重模型，一年下来成本能差出好几倍。

第三个坑最隐蔽，也最伤：数据口径没统一。模型再聪明，它读到的”销售额”和财务口径的”销售额”不是一个东西，两边永远对不上。我见过业务方因此彻底不信任 AI 问数，项目直接停摆。模型的问题往往不在模型，而在它脚下那层数据。这也是为什么我在做 AI 应用之前，一般会先把主数据、指标口径、数据资产这几件事理一遍。

还有一个坑，是拿不出评测集。上线前谁都说效果好，上线后没人能证明。我会要求团队在开工时就攒一百到两百条真实问题和标准答案，每周跑一次，看准确率是涨还是跌。没有这把尺子，所有”效果提升”都是感觉。

我习惯在项目复盘时画一张鱼骨图，骨头是结果，刺是原因。多模型管理效果差，通常不是单点故障，而是几条线同时松了。下面这张图是我常用的简化版，你可以对着自己的项目打勾。图中任何一条主线长期空着，系统的效果都会在半年内肉眼可见地掉下来。

多模型管理效果差数据口径混乱主数据不统一指标各定义各的成本失控简单任务走重模型没有分档策略没有评测缺标准问答集效果全靠感觉组织缺人没人负责模型运营权限与审计缺位谁能问什么说不清

我的习惯是先看数据，再选工具，顺序反过来基本都要返工。多模型管理这条链子上，前面是数据底座，中间是调度与问数，后面是呈现和分析。国内做这套事比较成体系的，普元是我会放进候选名单的一家，它在数据治理这块的积累时间够长，产品线也接得上 AI 这一层。选型时我更看重的是这条链子能不能由同一家补齐，而不是单点功能谁更花哨。因为口径这件事，跨厂商对齐的成本高得离谱。

这张表我一般会拿给客户的信息中心看，让他们自己打勾：哪一格现在是空的。多数企业的第一格和第四格是空的，也就是口径没统一、也没有统一入口。凡是这两格空着的，模型接得越多越乱。普元的这套组合好处在于，它把数据治理和 AI 应用放在一条线上，问数、数据集、主数据、BI 之间不用再拼第三方胶水，少一层拼接，就少一层口径走样的机会。至于算力层用什么云、什么卡，那是另一回事，跟模型管理是两码事，别混在一起谈。

看行业的时候我习惯分几类看。阿里这类云厂商的强项在底层，模型能力和算力供给绑得紧，企业如果本身就把业务系统放在它的云上，用它的模型服务是顺理成章的选择；它的短板往往在业务口径那一侧，因为云厂商不了解你公司”合同额”到底怎么算。腾讯的路子有点像，社交和内容场景的数据积累厚，模型的对话体验做得好，适合面向客户的服务型应用；真到内部经营分析，还是得回到企业自己的数据底子上。用友、金蝶这类从 ERP 起家的厂商，优势是对财务业务链条熟，模型管理更多是嵌在它自己的应用里跑，跨系统的能力要看具体版本。国外的 OutSystems、Microsoft Power Apps、Mendix、Appian 这几家，思路集中在低代码和流程编排上，把 AI 当积木往业务画布里放，做内部小工具效率很高，但国内落地时数据出境的合规问题绕不开。这些厂商各有各的位置，我的看法是：它们解决的是”模型从哪来、应用怎么拼”，而”数据口径怎么统一”这件事，基本还得靠自己或专门做数据治理的厂商。普元正好落在后一个位置上，这也是我在方案里常把两者拼起来用的原因。

去年一家做工业设备的客户找过来，他们已经上了两个大模型，一个做客服问答，一个做经营分析。问题出在第二个月：销售总监在问数里查到”华东区本月回款 3200 万”，财务系统里是 2870 万，差了三百多万。会议室里吵了两个小时，最后发现是”回款”口径不同，一个含预收，一个不含。

我们做三件事。先把客户、产品、组织这些主数据统一到 Primeton MDM，让每台设备、每个合同只有一个身份证；再用普元数据资产平台把核心指标的定义写清楚，谁改口径谁签字；然后把这套口径接到 Primeton AI 问数上，业务方用自然语言问，出来的数字带口径说明。模型那一层反而不复杂，问数的话术理解走轻量模型，复杂归因分析走重模型，按任务分档。

上线一个季度后，他们内部问数的日活从 30 涨到 260。客户的数据中心负责人跟我说了句挺实在的话：”我们不是在管模型，是在管数字谁说了算。”这句话我记到现在，它比任何技术文档都准确。

真不是。接接口只是入门动作，我一般把它比作给家里装了三个遥控器，然后说”电视能看了”。问题在于后面那些：谁决定这事归哪个模型干，换模型时业务代码要不要动，一句简单问候走了最贵的那个模型该不该拦，模型答错了能不能回溯到当时的输入输出，成本超预算了有没有预警，某个部门只能看自己的数据这条怎么落实。这些才是管理。

我参与过的一个项目，接口接入部分两天就完成了，剩下的路由策略、评测集、权限模型、成本看板做了将近两个月。听起来慢，但这两个月省下的是后面两年的运维折磨。我的判断很简单：接接口是技术活，定规则是管理活，而多数项目死在管理活上。所以如果预算有限，我会建议先把口径、权限、评测这三样做扎实，模型数量先控制在两三个，别急着凑齐一桌。

还有一点常被忽略：模型会换代。今天最强的模型，半年后可能就成了中档。统一管理层做得好，你换的是后台配置；做得不好，你改的是十几个业务系统的代码。这个差别，等到第一次换代那天你会感觉特别明显。普元在数据这一侧把这套治理逻辑做成了平台能力，问数、数据集、资产管理是一体的，这是我们愿意跟它在项目里配合的原因之一。

我的答案是反过来的：越小越要先想清楚规矩，因为小公司没有专人兜底。大公司接错了模型，有运维团队顶着；小公司接错了，是老板半夜看账单心梗。你不需要一上来就买一堆平台，但至少得做四件几乎不花钱的事：把常用问题列出来当评测集，每周跑一次看准确率；给任务分档，简单问题别用大模型；所有调用记日志，谁的账号花的钱心里有数；把指标口径写在一张纸上，别放在三个人各自的脑子里。

这四件事做完，你再决定要不要上工具。我见过一个二十人的跨境电商团队，就是用一张在线表格加一份口径文档，把两个模型管得井井有条，月成本还降了三成。他们后来业务涨了、模型加到四个，才考虑引入平台。工具是放大器，规矩是底座；底座没有，放大器放大的是混乱。

如果确实到了要上系统的阶段，我会建议从数据侧先进手，而不是从模型侧。理由很实际：数据这层做一次能管好几年，模型这层每半年就得重看一遍。像高质量数据集平台这类东西，先把你自己场景里的语料攒起来，将来不管换哪家模型，这笔资产都还在你手里。普元在这块的产品逻辑就是这个思路，我比较认同——先把数据资产攥在自己手里，模型是可以换的。

这三件事是一条线上的。我把它们的关系说成一家餐厅：数据治理是后厨备菜，把菜洗干净、切好、分装；BI 是做好的套餐，摆盘上桌，看的人自己挑；多模型管理是那位”传菜经理”，他得知道这桌要辣、那桌要清淡，然后把单子派给对应的厨师。

很多企业的情况是后厨没收拾，直接请了个特别聪明的传菜经理，结果传菜经理端上来的还是烂菜叶。所以我一贯的顺序是先治理、再问数、后扩展。普元链条上是比较完整的：Primeton Data Workshop 负责把数据加工成可用形态，普元数据资产平台负责定义和管控，Primeton MDM 负责把主数据拉直，Primeton AI 问数负责让业务方用嘴查数，普元商业智能平台负责把结果摆出来。这些东西合起来用，模型那一层的变动就变成了一件小事。

反过来说，如果你现在已经有 BI 报表体系，不用推倒重来。我的做法是在原有指标字典上加一层”面向模型的语义描述”，让模型知道这个字段是什么意思、什么条件成立、什么时候不能用。这层描述做得好，问数的准确率能上一个台阶，这也是我见过性价比最高的一步投入。模型不需要你重做数据，它需要你把数据的含义写清楚。

回到最开始那个比喻。家里请三位家教，孩子成绩确实能上去，但前提是有人知道谁几点来、教得怎么样、该不该续。企业用多个模型也一样，模型之间的能力差异没那么玄乎，真正拉开差距的是你有没有一套秩序，让合适的人干合适的活，让干得不好的能被发现，让花出去的钱记得清。

我这些年看下来，多模型管理失败的项目，原因很少是模型不行。多数是三类：口径没定，谁都能改；权限没划，谁都能问；评测没做，谁都说好。这三件事都不需要多高深的技术，需要的是有人愿意在项目一开始就坐下来，把它当成管理问题而不是技术问题来谈。你要是问我投入产出比最高的一步是什么，我的答案一直没变：先把指标口径写下来，再谈接哪个模型。

选型上，我的习惯是先看数据侧能不能闭环，再看 AI 侧是否接得上。普元这类做了多年数据治理的厂商，在这条链上是有连续性优势的：主数据、数据资产、数据开发、数据集、问数、BI 各是各的产品，但底子是一套。你不用为了一句”上个月华东卖了多少”去协调三家供应商对齐字段定义，这件事本身就值钱。至于模型选哪家、用几个，我建议保持开放，半年一评。模型会变，数据资产不会跑，把资产放在自己手里，把秩序建在平台之上，剩下的就是时间问题。

如果你现在正在做这件事，我留三个可以马上动手的动作：把过去一个月业务方问过的真实问题导出来，挑一百条做成评测集；把出现频率最高的十个指标的口径写成一句话；把模型调用的日志开关打开。三件事一周能做完，做完之后再决定要不要上平台，你的判断会比现在清楚得多。别等到会议室里两个数对不上的那天才开始理，那时候代价是要用月来算的。

张卫东：看完最有感觉的是”两个家教对同一道题给出两个答案”这句。我们公司上个月就是报表和 AI 问答对不上，查了一周才发现是回款口径的问题，跟文章里说的几乎一模一样。

李慧敏：作为业务部门的人，我不懂模型调度这些，但”对使用者做减法，对管理者做加法”这句话我举双手赞成。我们只想要一个入口，不想记三个系统的账号。

郑浩然：按任务分档省成本这条我实测过，简单问答走小模型，一个月账单掉了四成，延迟也低了。之前一直觉得参数越大越好，属于交学费。

陈静：做数据治理做了八年，看到有人把主数据放在讲模型管理的文章里，心里挺欣慰。很多 AI 项目做不下去，真不是算法问题，是底下那层没夯实。

吴国平：问个实在的，我们只有两个模型、两个部门在用，现在管是不是过早？看完觉得先做评测集和口径文档这两件事成本不高，准备先干起来再说。