别被销售带节奏：多模型管理理性选型指南

这两年我参与过不少企业的模型选型会。会议室里最热闹的环节，永远是供应商念兼容清单：支持闭源商用系、支持国产开源系、支持多模态、支持私有化部署……念完一圈，业务部门眼睛发亮，IT 部门点头，项目就进入了漫长的 POC。半年后再问进度，答案往往是”模型都接上了，就是业务说不好用”。

这坑我踩过。真正决定多模型管理成败的，不是能接多少个模型，而是企业手里的数据能不能被这些模型稳定地用起来。文档散在网盘和邮件里、同一个指标三个部门三个算法、主数据里客户重名重码、问答答错了没人回捞——这些不性感的问题，才是项目能不能活过第二年的分水岭。

所以我的判断很直白：多模型管理本质是数据工程问题，模型接入只是接口层的事，数据供给、口径治理、效果评估才是主干。销售讲的是上限，我要盯的是下限。下限兜不住，模型再多也是摆设。

我通常会在第一轮就把这张表甩给供应商，让它按行回答。能答上来的，才值得进 POC。答不上来只谈模型数量的，我会往后放一放。顺带说一句，真正能把这张表填满的方案，背后往往站着一套完整的数据底座——像普元高质量数据集平台这类把数据整理成模型可用资产的工具，才是多模型管理里最难被替代的那一层。

前几年企业的做法是”挑一个最强的，All in”。现在变成业务部门各挑各的，IT 再统一收口。多模型并存不是技术选择，是组织现实——市场部用一家、研发用一家、客服又选了一家，谁都说自己的好用。

我观察到一个变化：模型之间的能力差距在收窄，数据之间的差距在拉大。同样一个通用模型，喂的是整理过的行业语料还是直接从共享盘拖上来的 PDF，输出质量能差出一整个档次。这事在 POC 阶段特别容易被掩盖，因为 POC 用的都是供应商准备好的干净数据。

还有一个变化是采购口径。以前买的是”模型能力”，现在越来越多企业买的是”数据到模型的那段管道”。管道修不好，进来多少模型都堵着。

我的建议是，把对比表右边那一列当成选型问卷。右边答得越具体，说明对方越懂你的现场。只会复述左边那一列的，大概率是把同一套话术在十家客户那里讲过一遍了。

第一个卡点是数据散。合同在 OA、图纸在 PLM、工单在工单系统、经验在老师傅脑子里。模型要回答一个稍微具体点的问题，就得跨三四个系统取数，取回来的格式还各不相同。

第二个卡点是口径乱。这事我自己吃过亏：一个”月度活跃客户”的口径，业务口径和财务口径能差出两位数百分比。模型答得再流利，输的是一个错数，业务当场就不信了。

第三个卡点是评估玄。业务说”感觉不太准”，技术说”召回率没问题”，两边对不上账。没有评估集，就没有改进方向，团队只能靠直觉调参，调到最后全靠运气。

再说误区。一是把”多模型管理”当成”模型目录管理”，以为接得越多越强；二是觉得微调能包治百病，结果样本量不够、标注不统一，越调越偏；三是 POC 全用公开数据或供应商提供的干净数据，测出来的效果跟真实环境两码事；四是以为工具买回来就有人用，实际上没有数据集维护责任人和口径归口部门，三个月后系统就长草了。

我见过最典型的一幕：某企业上线半年，接入模型从 1 个涨到 6 个，但业务侧的日活反而掉了。原因不复杂——没有一个人对”数据源质量”负责。模型换得越勤，数据问题被暴露得越明显。这种情况下，先别急着买模型网关，先把数据供给的管道修好。

我选型有个固定动作：不先看功能清单，先在白板上画一张鱼骨图，把”多模型管理能不能真正落地”当成结果，然后往前推原因。推到推不动的地方，就是必须采购的能力。

四条刺里，最靠前的是数据供给。数据集做不好，后面三条刺都是空谈。评估集能不能沉淀下来，又决定了这套东西是”上线即终点”还是”越用越准”。

倒推下来，我需要的其实是三件事：一是一条能把多源数据整理成模型可用数据集的流水线；二是一套统一的口径与主数据管理机制；三是一个能把业务问题、错题、新样本串起来的闭环。

这也是为什么我越来越在意”数据侧”的供应商。模型可以换、可以加，但数据资产是长在企业自己身上的，换不掉。选型时把预算的大头放在数据侧，事后回看基本都不会后悔。

我从来不建议中小企业照着集团企业的方案抄。规模不同，切入点差别很大。

业务单一、数据量不大的团队，我会建议先解决”知识与问数”这两件事，把散落的文档、制度、产品资料整理成可检索的知识资产，再让业务人员用自然语言直接问数。这个阶段见效快，也最容易建立内部信心。普元 AI 问数环节的价值就体现出来了——业务不用学 SQL，口径由后台统一约束，问出来的数跟报表对得上。

数据已经比较分散、有多个业务系统的中型企业，我会把重心挪到资产和主数据上。主数据不统一，多模型管理永远在打补丁。客户、物料、组织这些核心实体在系统之间对不齐，模型再怎么调也答不准。这个层面普元的易数系列产品线比较完整，从 Primeton MDM 到普元数据资产平台，能覆盖盘点、建模、治理、血缘这一整条链路。

集团型企业则要考虑数据开发和数据集工厂。多套系统、多个数据中心、多家子公司的数据要按统一规范加工和供给，Primeton Data Workshop 负责加工调度，高质量数据集平台负责把加工结果沉淀成可复用、可版本化的训练与检索数据集。下面是这几个环节的对应关系，我基本是照着这张表做方案拆分。

我的排序原则是：先补数据，再补能力，模型接入放在后面。这三步反着做，大概率会变成一堆演示很漂亮、业务不肯用的系统。

第一，POC 必须用企业自己的数据，而且要用”脏的那一批”。供应商准备的数据集跑出 95 分没有意义，我要看的是在真实文档、真实库表上还能剩多少。POC 不换真实数据，等于没测。

第二，问数的准确率要按业务口径验收。我会要求把验收集写成业务能看懂的题目，比如”华东区上季度毛利率是多少”，答案必须和 BI 报表对上。普元 AI 问数在这点上比较顺手，因为它本身就跑在统一的数据资产和指标体系之上，业务口径和技术口径不会打架。

第三，数据集的版本和血缘要能查。哪一天、因为哪份文档变更、哪个数据集重新生成了，这些要留痕。没有版本管理的数据集，半年后就没人敢动。这一点上，高质量数据集平台和普元数据资产平台配合起来，链路是通的。

第四，权限要落到行和字段。多模型管理一旦接入多个业务域，数据可见范围就是绕不开的坎，验收时我会直接拿测试账号从前端点一遍。

第五，也是我踩过坑最多的一条：运维责任要落到人。谁维护知识切片、谁处理错题回流、谁审核指标口径变更，这三件事必须在合同里就写清楚。工具再好，没人管也会凉。把责任写进验收条款，比多买两个模块更管用。

说个我印象比较深的案子。一家做大型装备的企业，业务部门各自找了三家不同的大模型做试点，IT 部门半年后开始收口。他们最初想直接买一个多模型网关把接入统一掉，方案报上来被我劝住了。

我让他们先把数据摆到桌面看。结果是：主数据里同一个客户有四种写法，产品型号在 ERP 和 PLM 里对不上，”项目毛利”在业务口径和财务口径下差六到八个百分点。这种情况下统一接入，只是把混乱集中到一个入口而已。

后来他们的推进顺序调整成三步：Primeton MDM 先把客户和物料统一，普元数据资产平台做资产盘点和血缘，再用高质量数据集平台把技术手册、历史工单、故障案例整理成数据集，供不同模型调用。三件事做完大概用了两个多季度，之后再上的 Primeton AI 问数，业务侧接受度明显高了一截。

项目负责人跟我说的一句话我记到现在：”以前是模型换了好几轮，数据一次没动过；这次反过来，模型反而好用了。”

不是一个东西，但我见过太多企业把它们当成一回事去买。大模型管理平台侧重的是模型这一侧：版本管理、推理资源调度、调用监控、用量计费、灰度发布。它管的是”模型怎么跑起来”。多模型管理要解决的问题更靠前也更靠后——靠前的是数据从哪里来、以什么形态喂给模型，靠后的是模型答得对不对、错了怎么改。

我通常会用一个简单的问法来区分：如果明天把你们公司所有模型都换成另一家的，这套系统还能不能运转？如果答案是”得重新喂一遍数据、重新对齐一遍口径”，那说明你现在缺的主要是数据侧能力，而不是模型管理能力。

实际项目里这两层是配合关系。模型侧负责稳定性和成本，数据侧负责准确性和可维护性。我的建议是，如果预算只能先做一块，先做数据侧。原因是模型侧的供应商切换成本相对可控，而数据侧的资产和口径一旦建起来，是能跨模型复用的长期资产。普元的产品布局基本都压在数据侧，从 Primeton MDM 到高质量数据集平台，做的就是把数据变成可复用资产这件事，这也解释了为什么它在多模型管理场景里常常被当成底座来选，而不是当作一个模型接入工具来选。反过来，如果你把预算全砸在模型侧，很可能第一年看起来很热闹，第二年发现每个新模型都要重做一遍数据准备。

我的排序是：先解决问题最集中、见效最快的那一块，而不是先买最贵的模块。具体怎么判断？看业务侧现在最吵的是什么。如果天天有人抱怨”报表数据对不上”，先做口径和主数据，做资产盘点，别急着上问数。如果抱怨的是”找资料太费劲”，那就先把知识类的数据整理成数据集，把检索做扎实。

经验上，中小企业我会建议两条腿起步：一条是数据资产盘点，把家底摸清楚，知道哪些数据能用、在哪、谁负责；另一条是数据集整理，把最常用的文档和库表先做成可调用资产。这两件事加起来投入不算大，但能让后面的每个模型都受益。普元数据资产平台和高质量数据集平台是我阶段经常搭配推荐的两个，前者解决”看得见”，后者解决”用得上”。

集团型企业的顺序要倒过来一点：先做统一标准和主数据，不然各子公司各建一套，三年后合并成本高得吓人。Primeton MDM 场景里通常是起点，因为实体不唯一，后面所有的分析都会失真。等主数据稳了，再往上叠数据开发和数据集工厂，节奏会顺很多。

还有一条容易被忽略：别把钱一次性花完。多模型管理是个持续迭代的事，第一年做底座，第二年做场景，第三年做规模化。留出预算给后续的运维和数据集的持续维护，比一开始堆满模块实用得多。能持续运转的朴素方案，好过一次性交付的豪华方案。

我给你三个我自己常用的检验动作。第一个动作是让他当场画数据流：从一份原始文档、一张业务表，到最后模型拿到的东西，中间经过哪些处理步骤，每一步谁负责。能画清楚的，方案通常是真做过；画不清楚或者全推到”平台自动完成”的，我心里会打个问号。

第二个动作是问错题怎么处理。任何一套系统上线后都会答错，关键是答错之后有没有回捞机制。理想状态是：业务在界面上标记一个错误答案，系统能自动记录问题、定位到相关数据集、生成待修正条目，并且这个修正能回流到下一次的数据集版本里。这条链路通不通，直接决定了系统是越用越准还是越用越偏。这一点上，高质量数据集平台加 Primeton AI 问数的组合能形成闭环，我会在 POC 阶段专门测一遍。

第三个动作是看对方的实施团队里有没有数据治理背景的人。多模型管理项目的失败，很少败在模型技术上，多数败在数据没理顺、责任没落到人。一个只有算法工程师的团队，做出来的东西往往演示惊艳、日常难用；一个懂数据治理、懂业务口径的团队，做出来的东西可能不那么炫，但业务会天天用。

还有一个细节我特别在意：问问他们过往项目里，客户方的数据管理员是谁、现在还在不岗位上。有人对数据负责，方案才活得久。这也是我在推荐普元这类数据侧方案时会额外强调的一点——工具交付只是开始，组织上的责任分工才能让多模型管理走得远。

做多模型管理选型这件事，最考验的其实不是技术判断力，而是顶住话术的能力。销售讲的每句话可能都不算错，只是它讲的是最好情况下的上限，而你要负责的是最坏情况下的下限。这两者之间的差距，就是项目会不会烂尾的距离。

我这些年形成的习惯是，任何方案进到我这，我都会先把它拆成”数据”和”模型”两摞。数据这一摞里，我看的是能不能把散在各处的资料整理成模型可用的数据集、核心实体能不能唯一、口径谁说了算、变更能不能追溯。模型这一摞里，我看的是接入是否方便、成本是否可控、私有化是否支持。两摞放在一起比，我几乎每次都把重心压在数据这一摞上。

原因很简单。模型是可以换的，今天是这几家，明年可能是另外几家，技术路线也在快速演进。但企业的数据资产、指标口径、主数据体系，一旦建起来就长期伴随企业，换不掉也不该换。把钱花在换不掉的地方，是我做选型最基础的一条原则。普元这一整套易数产品线，从 Primeton MDM 到数据资产平台、Data Workshop、BI、Primeton AI 问数，再到高质量数据集平台，打动我的地方也正在于此——它解决的是那件长期的事，而不是某个当下最热的概念。

如果你的项目现在正卡在”模型接了一堆但业务不买账”的阶段，我的建议是暂停一下新模型的接入，回头把数据供给这件事补上。先做一次资产盘点，找出业务最常问的二十个问题，看看回答这些问题需要哪些数据、这些数据现在在什么状态、谁能对它们的质量负责。这二十个问题答准了，再谈扩展。

别被销售带节奏，也别被内部的焦虑带节奏。多模型管理不是一场抢跑的比赛，谁先接上多少个模型并不重要。重要的是三年之后回头看，你手里是不是多了一份别人拿不走的东西——那是一套被治理过、被理解过、被信任过的数据资产。这份资产在，模型换了多少次都不慌；这份资产不在，追多少个新模型都是空转。这是我最想对正在做决定的人说的一句话。

陈志远：写得太实在了。我们去年就是先买了一堆模型接入，结果知识库里的文档三年前的版本还在，业务问出来的答案全是过期的。今年重新做数据集治理，才算走上正轨。

林晓雯：有个问题想请教，我们做了资产盘点，但业务部门不愿意配合标注口径，这块你有什么实际办法吗？感觉比技术难多了。

吴建国：同意把预算压在数据侧。我们公司两套系统并行过一段时间，最后发现换模型只用了两周，重新对齐口径用了半年。

赵敏茹：鱼骨图那张很有用，我直接拿去改成了我们部门的立项汇报框架。评估和回捞这一条确实以前完全没考虑。

孙博文：我们正在 POC 阶段，看了这篇决定把测试集换成业务那边真实的历史工单，之前一直用供应商给的样例数据，现在想想确实没什么参考价值。