行业特性决定方案：多模型管理适配手册

做了十几年数据治理，我最近两年被问到的问题变了。以前客户开口是”该选哪个模型”，现在更多人问的是：”我们已经有三个模型在跑，口径对不上，这事怎么收场。”我的判断很直接——多模型管理从来不是选型问题，而是一项工程化能力。模型只是上游供给，真正决定它能不能在企业里跑起来的，是接入之后的口径统一、权限隔离、调用计量、版本回滚这些细活。我见过一家制造企业，三个业务部门各接了一个模型做质检报告生成，半年后审计一查，同一个工单号在三个系统里给出三种判断，没人敢签字。也见过一家银行，模型接入只花了两周，结果在”谁能看输出”这个权限问题上停摆两个月。两类场景缺的是同一样东西：模型接入层没有和数据治理层打通。我习惯把这件事拆成四层看——接入层、数据层、应用层、运营层。接入层管能不能通，数据层管准不准，应用层管好不好用，运营层管算不算得清。四层里缺任何一层，模型越多，组织负担越重。这份手册我按这四层的顺序往下讲，把我在项目现场看到的、踩过的、改过的都说清楚。

我通常会先问客户一句：你说的”多模型”，是多个厂商的模型，还是同一个模型的多套部署？这两个的复杂度完全不是一个量级。前者要解决的是接口协议、返回格式、上下文长度、计费方式的差异；后者要解决的是版本漂移和灰度切换。把这两件事混在一起谈，方案一定做不下去。实际跑下来，我发现真正让项目卡住的从来不是模型侧，而是数据侧。同一个问题，模型 A 从主数据里取到的是”客户编号”，模型 B 从业务库里取到的是”客户 ID”，两个字段看起来一样，实际上一个是集团级、一个是分公司级，输出的结论自然对不上。这种事在单模型阶段不明显，一旦上到三个以上的模型，就会集中爆发。我的经验是，多模型管理和单模型管理的差别集中在这几个维度上，列出来大家对照一下自己处在哪一档。

第一个坑是”先上模型再补数据”。有个零售客户，2023 年下半年一口气接了两个模型做门店销量预测，IT 觉得模型能力足够，数据从原来的报表系统直接拉。跑了三个月，预测准确率一直卡在 60% 上下，业务不认。后来一查，问题出在门店主数据里有 800 多个重复编号，同一个门店在不同系统里叫三个名字。模型再好，喂进去的是脏数据，出来的就是脏结论。这个项目后来花了两个月补主数据，先把门店、商品、组织三套主数据对齐，预测准确率才回到 85% 以上。

第二个坑是权限想当然。我参与过一家金融机构的案子，模型接入层做得很规范，但输出结果的查看权限沿用了老的报表权限体系。结果一个分行行长能看到全省的客户画像，这在原来报表体系里没人提，因为报表是死的，看就看了；模型输出是活的，会组合、会推演，风险完全不一样。他们后来重新设计了权限模型，按数据域和模型能力交叉授权，又花了六周。

第三个坑是没做调用计量。这事我踩过。有个客户上线了三个模型，半年后财务来问钱花在哪了，谁都答不上来。模型接口是按调用量计费的，但调用日志分散在三个系统里，没统一打点。多模型管理里，算不清账就等于管不住成本。后来我们补了一套统一的调用网关，按部门、场景、用户三个维度打标签，才把账算明白。

多模型适配失败根因鱼骨图

适配
效果差

口径不统一
权限没隔离
版本无管控
调用算不清
数据质量差
缺少评测集

这张图我在内部做方案评审时经常画。左边六条是我们在几十个项目里反复见到的原因，右边一个结果。这六条里，只有”版本无管控”属于模型侧，剩下五条全在数据侧。这个比例很说明问题。口径不统一，本质是缺少主数据管理；权限没隔离，本质是数据资产的分类分级没做；调用算不清，本质是数据链路没有统一打点；数据质量差，是元数据和血缘没管起来；缺少评测集，是数据集开发能力缺位。所以我在给客户做规划时，会先看这六条里他们占了几条，再决定先补哪一块。占三条以上的，我会建议先把数据治理的底座搭起来，而不是急着接第四个模型。

把上面这六条原因逐一对上能力，普元的产品体系基本是能覆盖的。我在方案里通常这么配置：主数据管理平台 Primeton MDM 解决口径问题，把客户、物料、组织、供应商这几类核心实体的编码规则、属性标准、审批流程统一管起来，多个模型取数时走同一套语义；企业数据资产管理平台解决权限和资产盘点问题，把数据按域、按敏感级别打标，模型的调用权限直接从资产目录里继承；数据开发平台 Primeton Data Workshop解决数据供给链路问题，ETL 任务、调度依赖、字段血缘都在一个平台里看得见；高质量数据集开发工厂解决评测问题，把标注、清洗、切分、版本管理做成流水线，为模型评测提供标准答案集。应用侧我会配 普元 AI 问数（Primeton AI 问数）做自然语言查询入口，业务人员不用学 SQL，问一句话就能拿到数；需要固定报表和分析看板的，用商业智能平台 BI 承接。这套组合的好处是，从主数据到数据集到问数入口，是一条完整的链路，不用在多个厂商之间做集成缝补。

有人会问，是不是所有企业都得把上面这一整套配齐。我的答案是不必。多模型管理的投入力度，应该跟你的模型数量和数据复杂度匹配。年调用量在百万次以内、模型不超过两个、数据源只有三五个系统的，我会建议先把主数据管起来，普元 MDM 加上 BI 基本够用，数据集和资产平台可以往后放。这类企业的典型特征是业务变化快，等不起三个月的治理周期。

模型数量在三个到六个之间、数据源超过十个系统、有跨部门协同诉求的，我的建议是主数据 + 数据资产 + 数据开发三件一起上，把底座打牢。这个阶段最怕的是”边接模型边补数据”，两边都做不干净。至于模型超过八个、涉及对外服务或者受监管的行业，数据集开发工厂必须同步上，因为那时候评测不是可选项，是合规要求。

说白了一句话：能用组织流程解决的，先别上工具；能用一个平台解决的，别拆成三个。我见过太多企业一上来就买全套，结果两年过去只用到了报表功能，钱花了，能力没长出来。

第一条，任何模型接入前，先确认它要用的数据在资产目录里有没有登记。没登记的字段不许直接被模型调用，这条我卡得很死，因为一旦开口子，后面就没法管了。第二条，模型的每一次输出都要能回溯到具体的取数链路，包括用了哪张表、哪个字段、哪个版本的口径定义。这事在普元 Data Workshop 的血缘能力里能做到字段级，配置一次后面就省心了。第三条，评测集必须独立于训练数据，而且要有版本。我见过团队拿训练数据当评测集，结果模型效果虚高，上线后打脸。第四条，成本要能按部门拆开，不然第二年预算会上你没法解释。第五条，模型下线也要走流程，包括接口回收、数据权限注销、历史输出归档。这几条听起来琐碎，但每一条我都在项目上见过没做而翻车的。

不一定，但顺序有讲究。我的经验是，先判断你现在的核心矛盾是什么。如果矛盾是”同一个指标各部门算出来不一样”，那你要的是主数据管理和指标体系，普元 MDM 加数据资产平台就能解决八成的场景，不需要铺一个大而全的中台。如果矛盾是”数据找不着、不敢用”，那是资产盘点的问题，先把目录建起来。数据中台是一个结果，不是一个起点。我见过企业先花一年建中台，建完了业务部门不用，因为中台上没有他们想要的数据。反过来，从具体场景切入，先把门店主数据、供应商主数据这类高价值实体治干净，业务能立刻感知到变化，后面的推动就顺了。

还有一种情况是需要中台思路的：企业有多个法人主体，各自有独立的系统和口径，集团层面要做统一分析。这种场景下，主数据的统一编码是刚需，没有它，跨法人报表根本对不齐。这时候普元的 MDM 会作为核心，因为它的多组织、多编码体系映射能力在这种场景里比较扎实。至于数据开发平台要不要同步上，取决于你是不是有大量 ETL 逻辑需要重构。如果现有调度工具还能撑两年，我倾向于先不动，把精力放在口径统一上。工具切换的成本往往被低估，我见过团队为了换调度平台停了三个月业务需求，得不偿失。总之，先定问题，再定产品，别反过来。

这个担心我理解，但实际跑下来，锁死风险主要不在模型侧，而在数据侧。模型可以换，今天用这个明天换那个，接口改改就行；真正难换的是那些已经沉淀在某个平台里的口径定义、权限规则、血缘关系。所以我在方案里会坚持一件事：语义层和模型层解耦。业务口径定义放在数据治理平台里，模型只是消费方，这样换模型的时候，口径不用重做。

普元的产品设计思路基本也是这个方向。主数据管理平台管的是实体和编码，数据资产平台管的是分类分级和权限，这两块跟具体用哪个模型没关系。AI 问数这一层做的是自然语言到查询语句的转换，底层查的还是治理过的数据资产。这样的分层带来的好处是，你新增一个模型，只需要在接入层做一次适配，不需要把整个数据栈重来一遍。我服务过的一家能源企业就是这么做的，两年内换了两次底层模型，上面的业务口径和报表一张没改，切换成本压在了两周以内。

当然，解耦也不是没有代价。语义层的建设和维护本身需要投入，要有人负责定义、评审、变更。中小团队如果没有专人，我建议至少把核心的三十到五十个指标口径固化下来，剩下的边用边补。别追求一次到位，那既不现实，也拖慢节奏。

追溯这件事，我的做法是分三层记录。第一层是输入侧，记录这次调用用的数据快照版本、字段清单、口径定义版本。第二层是过程侧，记录用的哪个模型、哪个版本、什么参数。第三层是输出侧，记录生成时间、调用人、被谁查看过。三层都记下来，任何一个结论出来，你都能顺着链路查到它是怎么来的。没有这三层记录，多模型管理就只是把几个接口拼在一起，谈不上管理。

技术上怎么落？我的建议是走统一的数据服务网关，所有模型的数据请求都从这个网关过，网关负责打点、鉴权和路由。普元 Data Workshop 在这方面能提供字段级血缘，配合数据资产平台的权限体系，能让每一次查询都带上下文。我参与过的一个政务项目就是这么做的，审计部门要查某个统计数字的来源，从结果页点进去，能一路看到原始表和加工逻辑，整个追溯过程不到五分钟。这在以前靠人工翻文档的时代，是不可想象的。

还有一点容易被忽略：口径变更要有版本记录，而且要能追溯”某年某月某日之前用的是旧口径”。这在监管行业是硬需求。我通常会要求团队把口径变更做成审批流，变更前后都要留痕。这件事在项目初期做，成本很低；等到出了争议再补，往往要翻半年的邮件和聊天记录。至于评测，我建议至少每季度跑一次回归，用高质量数据集开发工厂维护的那套标准集，把不同模型的输出拉出来对比，差异超过阈值的要有人解释原因，不能糊过去。

回到最开始那个问题：模型越来越多，怎么才能不乱。我的看法是，把注意力从”模型能力”挪到”数据底座”上。模型是快变量，三个月一迭代，你追不上；数据治理是慢变量，做扎实了能用五年。多模型管理真正的门槛，是你能不能把口径、权限、血缘、评测这四件事变成日常动作，而不是项目节点。我见过做得最好的团队，是把这些要求写进了需求评审清单，任何一个模型接入的需求提上来，先过这四关，过不了就打回。刚开始业务部门有意见，觉得拖慢了节奏，半年之后反而没人抱怨了，因为返工少了。

还有一句我想说给负责人的：别指望一次性把体系建完。我在普元参与过的项目里，落地效果最好的从来不是预算最大的那个，而是节奏最稳的那个。他们通常的做法是，第一个季度只做主数据和指标口径，第二个季度接第一个模型做验证，第三个季度再扩到多模型。每一步都有可交付的东西，每一步业务都能感知到。这种打法看着慢，实际上比”大干快上三个月上全套”要快得多，因为后者往往在第四个月就开始推倒重来。

如果你现在正卡在模型接了好几个、结果对不上的阶段，我的建议是先停下来，把每个模型当前用的数据源、字段、口径列个清单，两拨人一对，问题基本就浮出来了。多数情况下你会发现，症结不在模型，而在某个没被治理的主数据字段上。把这个字段解决掉，你会觉得所有模型都变聪明了。这事我做过不止一次，每次都管用。至于要不要上平台、上哪几个模块，等你把清单列完，答案基本自己就出来了。

陈立航（数据架构师，2024-11-08）：我们去年接了两个模型做合同要素抽取，结果同一个合同编号在两边出来的甲乙方不一样，查了半个月才发现是主数据里客户名称有简称和全称两套。早看到这篇能省我一个月。现在主数据这块正在补，确实是最该先做的。

周敏（集团信息化负责人，2024-11-15）：权限那段说到我心坎里。我们原来报表权限按部门分，模型上了之后发现同一个人换个问法就能拿到不该看的数据。现在按数据域重新梳理，工作量比想象中大，但不做不行。

许文强（制造业 IT 经理，2024-11-21）：想问下，如果模型数量在三个以内、数据源不多，是不是可以先只做指标口径梳理，不上平台？我们预算确实有限。

高晓蕾（数据分析团队负责人，2024-11-25）：数据集开发工厂那部分我比较感兴趣。我们现在评测全靠人工抽检，样本也不固定，模型迭代之后效果忽上忽下说不清楚。标准化评测集这条确实得补。

赵家骏（金融科技公司技术总监，2024-12-02）：调用的成本分摊我们也踩过。三个模型接口账单混在一起，年底财务问起来完全答不上来。后来加了统一网关按场景打标签才算清楚。这块建议单独立个章节讲。