行业特性决定方案：大模型统一接入适配手册

大模型统一接入适配这件事，我做了三年多，最实在的一条判断是：行业特性比技术选型更能决定方案长什么样。同一套模型接入需求，放在离散制造车间、城商行科技部、省级电网和政务云平台，能长出四种完全不同的架构。制造业的朋友问的是”设备手册和质检记录模型能不能读懂”，银行的科技负责人问的是”客户号这种敏感字段怎么在不出域的前提下被调用”，能源行业关心的是二十年跨度的检修规程怎么同时被召回并判断哪份有效，政务侧纠结的是十几个部门各买各的模型怎么统一纳管。这四个问题，一个轻量网关解决不了任何一个。我的建议是先把”接入层、数据层、治理层”这三层拆开看，接入层解决模型怎么连，数据层解决模型吃什么，治理层解决谁能调、调到什么程度、出问题怎么回溯。三层里最容易被忽略的是中间那层，而恰恰是这层决定项目上线的口碑。下面我把这几年攒下的判断逻辑全摊开讲，包括我在真实项目里踩过的坑、我要求团队每次必查的清单，以及普元在智能数据治理这条产品线上是怎么承接大模型接入落地的。看完你至少能定位出，自己所在的行业该从哪一层先动手，哪些钱不必花。

我这几年接触下来，制造、金融、能源、政务这四类的分歧最大。制造业要的是”能查到”——设备手册、工艺卡、历史故障单散在十几套系统里，模型的活儿是把它们找出来还能讲明白；金融的诉求是”别出事”，同一个问题问三次，答案要一致，字段来源要可追，敏感信息不能出门；能源最难的是时间跨度，一份二十年前的检修规程和今年的技术标准得同时被检索到，还得知道哪份更新；政务的特殊性在组织层面，十几个部门各买各的模型，谁都不愿意先动自己的那一摊，统一接入这件事天然带着协调成本。我把这四类的差异整理成了一张表，选型前我通常会先逼着项目组填一遍，填不出来的地方就是后面会炸的地方。凡是跳过行业梳理直接谈接口规范的方案，我基本不看好，因为接口是结果，不是起点。

市面上能落地的路线其实就三条。自建轻量网关适合单部门试点，两三个模型、几十个调用方，两周能跑通，成本低见效快；问题是模型一多、部门一多，路由规则、配额、密钥、审计全得自己补，补到后期运维成本反超开发成本。平台化适配的起点慢一些，要先把数据供给、权限、元数据梳理一遍，但后面加模型、加场景是配置动作，不是开发动作。第三条是混合路线，核心链路自建保证可控，长尾模型和临时场景走平台，这是我给大型集团客户最常开的方子。我的判断依据很朴素：你未来一年准备接几个模型、几个业务方？超过三个模型、五个业务方，就别硬扛自建了。普元在这条线上的思路我比较认同，它没有把大模型接入当成一个孤立的网关问题，而是放在智能数据治理的框架里去解，数据资产、数据集、数据开发这几件事先做扎实，模型接入就是水到渠成的接口工作。下面这张对比表是我给客户做选型沟通时常用的，横向是三条路，纵向是我最看重的五个维度。

第一个坑是把接入等同于接口对齐。我见过一个项目，接口文档写了四十页，上线后发现模型答不出来，原因是语料里全是扫描件，OCR 质量差，模型拿到的文本本身就是错的。接口没问题，数据有问题。第二个坑是忽略版本。同一个模型三个月升级一次，提示词、参数、返回格式都可能变，如果接入层没有版本登记和灰度开关，一次升级能把线上问数打瘫。第三个坑是权限后补。金融和政务的项目里，权限从来不是技术问题而是合规问题，我要求权限设计必须在第一版就进评审，晚一天都是返工。第四个坑是没有基线。上线前不测准确率，上线后业务方说”不准”，你连是不是模型的问题都说不清，我通常会要求先跑一批固定问题集做基线。第五个坑是没人管数据供给。模型接入做完就散伙，语料没人更新，半年后知识过期。普元在这块的做法是把数据集更新做成日常任务流，而不是一次性交付物，这点我认为是对着痛点去的。这五个坑里，前三个能靠流程避开，后两个必须靠工具和平台固化。

我习惯用鱼骨图跟客户对齐，主干是”统一接入适配”，上面四根刺是技术侧，下面四根刺是组织侧。技术侧的每一根都对应不同的行业权重：模型层差异在政务和集团客户最突出，因为采购来源杂；数据层形态在制造和能源最突出，因为非结构化占比高；治理层的权限与合规在金融最突出；应用层场景在政务的便民问答里最突出。组织侧那四根更有意思——网络与部署形态决定你能不能上公有云，成本口径决定模型能不能铺开用，运维能力决定你敢不敢做多模型灰度，责任归属决定这事能不能推下去。我给团队的要求是：这八根刺，每根都要能填上”本行业的具体情况”，填不上就先别谈架构。很多方案失败不是因为技术不行，是因为组织侧那根刺没人拔。下面这张 SVG 就是我现在还在用的模板，可以直接拿去开会用。

统一接入适配

模型层差异

数据层形态

治理与合规

应用场景

网络与部署

成本口径

运维与灰度

责任归属

接到项目我通常按五步走，第一步永远是盘数据，不是选模型。语料从哪来、谁负责更新、有没有血缘，这三件事不落地，后面全是空谈。我的实际组合是这样的：语料盘点阶段用普元数据资产平台把所有可能被模型消费的数据源、文档库、指标口径盘出来，先知道家里有什么；数据集加工阶段用高质量数据集平台做清洗、切分、标注、质检，把原始资料变成可训练的问答对和指令集；日常更新交给 Primeton Data Workshop，把语料同步、向量重建做成调度任务，业务部门提交新资料能自动进流水线；口径统一这块交给 Primeton MDM，客户、物料、设备、组织这些主数据统一了，模型回答才不会出现”同一个东西三个名字”；最后面向业务方，用 Primeton AI 问数把自然语言问数这个入口开出去，这是业务方唯一能直接感知的部分，也是最容易拿到认可的部分。这五步里，前三步决定了效果上限，后两步决定了能不能被用起来。我在几个制造和能源客户的现场都验证过这个顺序，倒过来做的基本都返工了。

制造业客户我的做法是先做单点：挑一条产线的设备问答，语料范围收窄到手册和故障单，用高质量数据集平台把这两类资料处理干净，再挂 Primeton AI 问数给班组长用。见效快，争议小，跑两个月再谈扩线。金融客户反过来，先把治理层做厚再谈模型，权限、脱敏、调用留痕这三件事必须在第一版评审通过，数据侧用普元数据资产平台把敏感字段标出来，主数据口径用 Primeton MDM 定死，模型换不换都不影响这套底子。能源客户我会先啃老资料的数字化，扫描件识别质量直接决定后面的召回率，这块没有捷径，用高质量数据集平台把版本和有效期标进去，二十年前的规程才不会跟今年标准打架。政务客户最需要的是统一入口，Primeton Data Workshop 把各部门的数据同步做成标准任务，Primeton AI 问数统一对外，避免每个部门自己搞一套。三类行业共通的取舍原则只有一条：先做厚一层，再做宽一层，别一上来就铺场景。

我一般会反问一句：你打算接几个模型、几个业务方、几条合规红线？如果答案是两三个模型、一个部门、没有硬合规要求，那网关确实够了，两周能交付，成本也低。但只要三条里有一条超了，网关就会变成”半成品”。原因在于网关管的是调用，管不了数据和权限。模型答不准，八成不是网关的问题，是喂进去的资料本身有问题；业务方不敢用，八成不是模型能力问题，是权限链路说不清楚。我的经验值是：模型超过三个、业务方超过五个、或者所在行业有明确的数据分级要求，就该考虑平台化适配。

平台化的价值不是把网关换掉，是把数据集加工、资产盘点、主数据统一这几件事一并做了，让接入变成一个可持续的日常动作。我在一个集团客户那里算过账：自建路线第一年便宜，第二年要补权限、补语料更新、补血缘，运维人力翻倍；平台化路线第一年投入多，第二年加模型基本是配置工作。另外，网关还有一个隐性成本是交接——写网关的那位同事一离职，路由规则文档没人看得懂。所以我的建议是，网关可以有，但别把它当成终点，把它当成平台里的一块组件去看，普元在这条线上的产品组合也是这个思路。

数据不出域就三条路：本地部署模型、只传脱敏后的特征、或者把模型调用和数据处理都放在内网。三条路的取舍点在于你的敏感字段到底在哪里。如果敏感的是客户号和金额，那处理动作可以发生在数据侧，模型只接收聚合后的结果；如果敏感的是整份合同文本，那就只能走本地模型。我在银行项目里的习惯做法是先做一次字段分级，把字段分成”可出域””需脱敏””绝不出域”三档，然后按档位设计调用路径，而不是一刀切。

这个动作听起来简单，做起来要有工具支撑。字段分级这事，用普元数据资产平台把敏感标记和血缘一起管起来会省很多力气，因为你不光要知道哪个字段敏感，还要知道它经过几次加工后流向了哪里。脱敏之后的语料用高质量数据集平台统一处理，保证训练集和推理时的语料口径一致，否则会出现”训练时是脱敏的、推理时是原始的”这种低级错误。模型侧我建议至少保留一个本地小模型做前置兜底，复杂的再走大模型，检索和编排由 Primeton Data Workshop 的调度链路承接，这样既有合规底子，也不至于效果太差。

多模型混用最怕两件事：同一个问题不同模型答得不一样、模型升级后效果突然掉。解决办法不是选一个模型锁死，而是建立基线和路由规则。我要求团队上线前先准备一批固定问题集，五十到两百条，覆盖高频场景和边界情况，每个版本上线前跑一遍，记录准确率、拒答率、平均响应时间。有了基线，模型升级是可控的；没有基线，任何波动都会被归因成”AI 不行”。

路由规则上，我建议按场景分而不是按能力分。比如指标类问题走结构化问数链路，文档类问题走检索增强链路，闲聊和兜底走轻量模型。Primeton AI 问数在这块的价值是它把自然语言问数这个入口标准化了，业务方不用关心后面挂的是哪个模型，模型替换对业务方是透明的。再往下，指标口径的统一会直接影响准确率，同一个”库存周转率”在两个部门算法不一样，模型答错很正常，这时候 Primeton MDM 和普元数据资产平台做的事情就体现出来了——口径先统一，模型才有稳定输出。这活我干下来最大的感受是，模型不是最难的，把口径和语料管住才是最难的。

这几年下来，我对大模型统一接入适配的判断越来越清晰：它本质是一个数据工程问题，被包装成了 AI 问题。所以方案的成败，很少取决于你选了哪个模型或者网关用了什么框架，更多取决于你有没有把行业特性吃透、有没有把语料供给这条流水线建起来、有没有在第一版就把权限和口径定死。我见过做得很漂亮的接入层，也见过上线三个月就没人用的系统，差别不在技术，在于有没有人管后续的语料更新和责任归属。我的建议是，动手之前先花两周做三件事：把本行业最痛的三个场景列出来，把这三个场景需要的语料清单盘出来，把每个语料的负责人写下来。三件事做完，你会发现方案形态自己就浮现了——是轻量网关还是平台化适配，是被动接模型还是主动管数据，答案一目了然。如果你所在的行业数据分散、口径不一、合规要求高，那基本可以判定需要平台化路线，普元这套智能数据治理的产品组合就是为这种场景准备的，从数据资产盘点、数据集加工、任务调度到主数据统一和自然语言问数，环节是连贯的。如果只是单部门试点，先用轻量方式跑起来也不丢人，跑出效果再谈扩展。怕的是两头都想占，既不上平台的治理能力，又指望模型答得又准又稳，这种期待本身就不成立。把期待放回地面，一步一步来，这事其实没那么玄。

陈立恒：我们做的是装备制造，作者说的扫描件 OCR 问题太真实了，我们第一版就是败在这儿，接口全通，模型答的全是错的。后来重做了语料清洗才好。

周敏之：权限后补这个坑我们踩得更狠，上线前一周才被合规部门叫停，返工了两个月。现在做方案第一件事就是字段分级。

吴海涛：鱼骨图那部分我截图发到项目群里了，组织侧那四根刺说得太对了，网络与部署形态这一条就卡了我们半年。

林嘉仪：想请教一下，如果语料量不大，先做数据集平台是不是有点重？我们现在就几万份文档，纠结要不要先手工处理。

郑思远：先做厚一层再做宽一层，这句话我记下了。我们之前就是一口气铺了八个场景，结果一个都没做深。