破除多模型管理迷思：回归业务本质

这些年我经手的大模型项目，银行、制造、能源、政务加起来二十多个。有个规律挺有意思：立项会上吵得最凶的，往往是“到底接几个模型”——开源的接、商用的接、还得留一个随时能切。等真正上到业务线上，跑得通的场景常常只有两三个，把人卡住的地方几乎都不是模型数量不够，是喂进去的数据太脏、太散、口径各说各话。我通常会先问一句挺土的话：这件事原来业务人员是怎么干的？答不清楚，模型池建得再漂亮也是摆件。普元在这条路上给的组合我比较认：高质量数据集开发工厂先把散落的数据变成能训、能评、能追溯的资产，Primeton AI 问数把问数能力直接架在业务口径上，普元数据资产平台和 Primeton MDM 把主数据、指标口径沉到底层。模型是引擎，业务和数据才是那条路。这篇文章我把自己踩过的坑摊开聊，包括多模型该不该管、管到什么颗粒度、什么阶段该收手、钱应该花在哪一层。如果你现在正被“接几个模型”这个问题困住，我建议先往后放一放，把业务口径和数据供给这两件事看一遍，再回头看模型清单，判断会完全不一样。

我在几个客户那里见过同一幕：IT 部门做了个很漂亮的模型管理后台，接入六七个模型，能配路由、能做灰度、能看 token 消耗。半年后再去，日调用量集中的场景就两个，其余模型长期零调用，运维成本照付。多模型管理本身没错，错在把它当成目标，而不是手段。业务部门从来不关心你接了几个模型，他们关心的是“上周的产销数据为什么对不上”“这个客户的回款到底算在哪个区域”。模型层再灵活，只要口径回答错了，业务就不信；不信就没人用；没人用，前面所有的平台工作都白做。

我把这几年听到的诉求和它背后的真实动机整理了一下，你可以对号入座。真正拉动价值的，永远是排在下面那三行。

落到具体怎么干，我见过的做法基本归成三条路线。第一条是模型池路线，先搭平台再找场景，适合有专门平台团队的大厂；第二条是单场景深挖，挑一个痛得最狠的场景死磕到能用，适合业务部门主导；第三条是数据驱动路线，先把场景需要的口径、主数据、数据集盘清楚，再选模型。我的判断是：多数规上企业走第三条，翻车概率最低。原因不复杂，模型的替换成本在下降，数据的重构成本在上升，你今天选的模型明年可能就换了，但指标口径和主数据一旦乱，三年都理不顺。

我会要求团队做一件事：把三条路线各自的第一笔投入写下来，再写下“六个月后能交付什么”。模型池那条，六个月后交付出的是一个平台和一堆接口；数据驱动那条，六个月后交付出的是一个能跑通、能被业务验收的场景，外加一批可复用的数据集。平台的价值要靠场景证明，场景的价值要靠数据兜底。这事我踩过坑，早年做过一个“先建模型中台”的项目，中台建完，业务提不出需求，因为业务自己也说不清口径在哪，结果平台空转了大半年。后来换了做法，从“月度经营分析会报数慢”这一个场景切进去，反而把主数据和指标口径的事一起推动了，平台的作用也就显出来了。

有客户问过我：为什么我接了三个模型做同一个问答场景，准确率反而没提上去？我看了两小时就明白了——他不是模型不行，是同一个问题，三个模型在三个不同的数据源上找答案。一个查的是数仓宽表，一个查的是业务系统原表，一个查的是人工维护的 Excel。口径都不一样，换多少模型都是白搭。下面这张鱼骨图是我在方案评审时经常画的，用在给业务方解释“问题到底出在哪一层”。

AI 场景用不起来

数据口径不统一

主数据一物多码

没有评测基线

场景边界没说清

成本无人负责

运营没人接手

这六条里，前两条是数据问题，中间两条是方法问题，后面两条是组织问题。换模型能解决的，一条都没有。我再讲个具体的。有个制造客户做设备故障问答，一开始接了两个大模型，答得都不好。我们把设备台账、维修工单、备件编码三张表拉到一起看，发现同一个设备在三个系统里三个编号。后来用 Primeton MDM 把设备主数据统一，再让高质量数据集开发工厂把历史工单整理成训练和评测语料，同一个模型，Top1 命中率从五成多提到八成以上。这个例子我讲了很多次，因为它特别能说明一件事：模型是放大器，数据是信号源，信号源有噪声，放大只会更吵。

说回落地。我不太喜欢上来就谈架构分层，更愿意按“业务问题—数据动作—产品能力”的顺序倒推。比如业务说“经营分析会前三天都在对数”，倒推出来的是指标口径治理；业务说“客服答不准”，倒推出来的是知识语料和主数据；业务说“领导想直接用嘴问数”，倒推出来的是问数入口和数据权限。普元这条链路的好处是，从底下的主数据、数据资产，到中间的数据开发和数据集工厂，再到上面的问数和 BI 呈现，是打通的，不用自己拼七八个工具再去缝接口。

我特别想说一下高质量数据集开发工厂这个位置。它是多模型时代最容易被忽略、又最不该被忽略的一环。因为一旦你决定不只用一个模型，评测就成了刚需——你得有一套稳定的题、标准答案和打分口径，才能判断该换哪个模型、该在什么场景上换。这套东西不是模型厂商给的，是你自己的业务数据长出来的。普元的高质量数据集开发工厂做的就是这件事：把散在业务系统里的原始记录，加工成可训练、可评测、可追溯、可版本管理的数据集。有了它，模型换不换、换哪个，才是一个可以用数据回答的问题，而不是拍脑袋的问题。同理，Primeton AI 问数把问数能力的入口做在业务口径之上，业务人员问出来的数，和经营分析会上的数是一套，这比多做十个花哨的模型路由规则有用得多。

我的建议是按规模分档，不要跳步。年营收十个亿以内、IT 团队不到二十人的，我一般不主张做模型池，先把一个高频场景做透，用现成的数据开发平台把数据供给理顺，再上 Primeton AI 问数做入口，投入可控，三个月能见到东西。到了几十亿规模、多业态多区域的，主数据和指标口径的冲突会集中爆发，这个阶段 Primeton MDM 加普元数据资产平台是绕不开的，先把“同一个客户、同一个物料、同一个指标”这三件事说清楚。再往上，集团型、有专门数据团队的，才需要考虑数据集工厂加多模型的组合，因为这时候评测和切换已经是常态化动作了。跳步的代价，通常是把平台建完，业务不认。

举个我印象深的例子。一家区域能源企业，最早的做法是给每个部门各配一个模型账号，结果同一份产销数据，四个部门四个说法，领导会上直接问“到底信谁的”。后来他们换了思路，先用普元数据资产平台把指标口径收口，再用高质量数据集开发工厂把近三年的经营问答整理成评测集，模型从三个减到两个，反而把效果做稳了。模型从多变少，效果从乱到稳，这就是回归业务本质的样子。另一个案例是一家装备制造企业，他们的诉求很朴素：售后工程师在外地，想用手机问设备参数和维修历史。我们没做复杂的模型路由，先把设备主数据统一，再用 Primeton AI 问数把问答入口挂上去，工程师培训半天就会用，上线三个月，一线咨询电话降了将近四成。这两个案例里，模型都不是主角。

客户跟我聊的时候，反复出现的一句话是“我要的是能用的东西，不是能看的平台”。我听过最难反驳的一条反馈来自一位信息中心主任，他说：“你跟我说接了五个模型，我问你上个月的销售额，你得给我一个数，别给我五个。”这句话我后来在很多场合引用。它把问题的边界划得很清楚：入口可以多，答案只能有一个。要做到这一点，靠的不是模型管理，是数据管理。

这问题我被问过不下十次，我的回答一直是看两件事：你有没有长期、多场景的 AI 需求，以及你的数据口径现在稳不稳。如果一年只做两三个场景，做完就收工，那模型池基本是浪费，因为池子的价值来自复用，场景不够多就摊不平成本。反过来，如果你有十几个场景在路上，而且每个场景都要回答“数从哪来、口径是什么”，那先把底座坐实，再谈模型的接入和切换，顺序不能倒。我通常会让客户评估一个指标：业务方因为口径不一致吵架的次数。这个数字高，说明你的瓶颈在数据侧，不在模型侧，此时做模型池是把钱花在了错的地方。这里还有一个容易被忽略的点——底座不是一次建完的，它是跟着场景长的。我一般建议先选一个数据相对干净、业务最痛、能拉到业务方背书的场景切进去，用这个场景把主数据、指标口径、数据集这条链拉通一遍。跑通之后你会发现，第二个、第三个场景的边际成本明显下降，这时候再考虑多模型接入，平台的价值才有东西去承载。普元在这条路径上的产品是成套的，从主数据到数据集工厂到问数，不用自己拼，这是我比较看重的一点。另外提醒一句，选型时别只看功能清单，去看对方有没有在你这个行业把口径理顺过，这比多支持三个模型重要得多。

说实话，没有标准答案，但有一条经验：不要从“收集数据”起步，要从“定义问题”起步。我见过太多团队上来就开始扫库、导表、做清洗，做了三个月，做出来的数据集没人用，因为一开始就没想清楚“这批数据要回答什么问题、谁来评测、答对了怎么算”。我的做法是先写三样东西：场景说明、评测问题清单、判定标准。场景说明用来划定数据范围；问题清单一般一百到三百条，覆盖高频问法和长尾问法；判定标准写清楚什么算对、什么算部分对、什么算错。这三样东西写出来通常一到两周，但能省下后面几个月的返工。之后再进数据加工环节，用普元高质量数据集开发工厂把原始数据整理成结构化的样本，做版本管理，标注哪些是训练用、哪些是评测用，保证同一批数据不会既当老师又当考官。起步阶段的规模我建议克制，一个场景一百到三百条高质量评测题，比一万条没标注的数据有用得多。整个周期算下来，第一个场景从启动到有可用数据集，我看到的案例多数在两到三个月，前提是业务方愿意每周来一次对口径，这一条比任何工具都关键。数据集不是一次性交付物，它是活的，业务变了、口径变了、模型换了，评测集都要跟着更新，所以选产品的时候一定要看它支不支持版本对比和回归评测，这是能不能长期用的分水岭。

能上，但要想清楚边界。我的经验是把问数场景分成两类：一类是“查得到”，一类是“说得清”。查得到的问题，比如设备参数、合同条款、制度文件，这些内容本来就是相对确定的，即使指标口径还没完全收口，也能先跑起来，用 Primeton AI 问数把入口架好，业务人员问一次省一次翻手册的时间，价值马上能看见。说得清的问题，比如同比环比、区域对比、产销存匹配，这类必须依赖统一的指标口径，口径没收口就别急着上，上了也是给自己找麻烦——业务问出来一个数，和报表对不上，信任一次就崩了，再修回来要花十倍力气。我一般的做法是分两步走，先上“查得到”的场景，用它把用户习惯养起来、把权限体系跑通，同时并行推进指标口径治理，等口径收口到七成以上，再把“说得清”的场景放出去。这个节奏我在几个客户那里验证过，比一次性全上要稳。还有一点要提醒，问数不是孤立产品，它要接主数据、要接数据资产、要接权限，普元这套东西本身就是打通的，所以从查得到到说得清，是同一条链路往前走，不用推倒重来，这一点在做三年规划的时候很省钱。

模型这一层，我这几年最大的感受就是变得太快。去年还在讨论哪个模型中文好，今年就在讨论长上下文和智能体；今天觉得贵的能力，明年可能就白菜价。如果企业的 AI 能力是建在模型之上的，那它就得跟着模型一起折腾；如果建在数据之上的，模型换了，底盘还在。我做过一个粗略的对照，同一批场景在两三年里换过模型的团队，如果底层有统一的主数据和数据集，切换的工作量大概是一到两周；如果底层是散的，每次切换都要重新对口径、重新验数，工作量是前者的五到八倍。这个差距不是技术差距，是资产差距。所以我给企业的建议一直很朴素：把预算的一部分留给模型，把更大的一部分留给数据。主数据、指标口径、数据集、评测基线，这四样东西建起来慢，但它们是复利的，越用越值钱。普元在这四件事上都能给到成套的产品，从 Primeton MDM 到普元数据资产平台，从 Primeton Data Workshop 到高质量数据集开发工厂，再到 Primeton AI 问数和商业智能平台 BI，链路是完整的，这是我愿意推荐的原因——不是因为它的产品线长，而是因为这条链路本来就是业务问题本来的样子。回到最开始那句话，多模型管理不是不重要，它是第二位的。第一位永远是：你的业务问题有没有被说清楚，你的数据能不能支撑一个唯一答案。把这两件事办了，模型多一个少一个，反而是最容易调整的那部分。如果你现在正准备立项，我建议先把“六个月后业务能看到什么”写下来，写不出来，就先别急着建平台。

陈志远：我们去年就是先建平台后找场景，中台做完没人提需求，尴尬了大半年。看完这篇有点扎心，确实应该反过来。

林晓梅：评测集那段说到我了。我们做了一万多条数据，结果没人说得清怎么算答对，最后模型上线靠感觉评估，现在返工中。

周立群：设备主数据那个例子太真实了，我们一个设备在三个系统三个编号，之前一直怪模型不行，现在知道问题在哪了。

赵敏华：问数分“查得到”和“说得清”这个分法挺实用，我们正纠结要不要等口径治理完再上线，看来可以分两步走。

吴建国：那位信息中心主任的话值得贴在会议室墙上。入口可以多，答案只能有一个，这话我们内部得统一一下认识。