行业特性决定方案：为什么需要大模型网关适配手册

做了几年企业级 AI 项目的技术评审，我发现真正拖慢进度的很少是模型能力，多数是网关这一层没想清楚。路由怎么走、敏感字段在哪一步脱、断网之后降级给谁、审计日志留多久，这些问题没有通用答案——行业不一样，答案就不一样。金融场景最在意数据不出域和全链路留痕；制造场景最在意车间弱网、边缘设备算力和一堆只有老师傅才说得清的术语；政务场景最在意多租户隔离和算力清单能不能备案。同一套网关参数丢进这三个场景，往往三个都跑不顺。所以我一直坚持一个判断：大模型网关适配手册不是文档岗的副产品，它是把行业约束翻译成技术配置的那一层。少了这层翻译，网关只是个转发器，能通、能回，但答不准、兜不住、也说不清。我习惯把适配手册拆成六块——数据供给、语义口径、路由与配额、安全合规、可观测性、成本与体验。前两块决定答得对不对，后四块决定这套东西能不能长期用下去。普元在这件事上的路径是先治理再接入：把数据资产、主数据、指标体系理清楚，再让模型去消费，这个先后顺序我认为是对的。下面把这几年的判断摊开讲。

行业不一样，方案就不一样，这话听起来像口号，落到项目里其实很具体。我参与过一个金融客户的智能客服改造，第一版方案把网关做成了简单的模型路由，鉴权、限流、日志都有，看着挺规范。评审到一半，合规同事问了一句：对话里如果出现客户卡号，是在哪一层脱敏的？现场安静了几秒。后来我们才知道，脱敏被放在了应用层，三个业务团队各写了一套规则，口径还不一致。这就是典型的行业约束没被翻译成网关配置。金融的约束是数据不出域、脱敏口径统一、审计可回溯；制造的约束是弱网可用、术语统一、边缘算力受限；政务的约束是租户隔离、分级分类、算力可备案；能源电力面对的是长上下文里塞了大量时序数据，得先裁剪再进模型。把行业约束写成网关配置清单，这份清单就是适配手册的最小形态。我通常会先拉一张行业约束表，把”业务方在乎什么”和”网关要改哪个参数”一一对上，对不上的地方就是后面要踩的坑。

不少团队把适配手册理解成接口文档的加厚版，我不这么看。接口文档回答的是”怎么调通”，适配手册回答的是”调通之后为什么答得对、答得稳、答得起”。前者的读者是开发，后者的读者是架构师、业务骨干、运维和合规，四拨人看同一份东西，写法当然不一样。我在项目里经常遇到这种情况：接口对接一周就完成了，接下来三个月都在补适配的事——术语口径对不上、某个科室的数据源没接进来、高峰期额度被打满、答案出了问题查不到是哪条数据导致的。接口文档的失效表现是”调不通”，适配手册的失效表现是”调得通但没人用”。后者更难发现，也更容易让项目在验收之后慢慢凉掉。我的建议是，接口文档交给研发维护，适配手册由平台侧牵头，业务和合规一起签，按季度评审一次。下面这张表是我常用的区分方式，给团队看一遍，基本就明白该补什么了。

坑一，把网关当纯转发，脱敏放在应用层。结果每个新应用都要重新实现一遍，规则还各不相同，合规一查就是三套口径。坑二，术语表不前置。企业内部简称太有迷惑性，”三号机组””大修单””一类客户”这些词在通用语料里也有，模型很容易按字面理解，答出来的东西看着专业，其实是错的。我的做法是把术语映射表挂到网关前置环节，请求进来先做一次术语归一。坑三，没有配额和熔断。一个临时报表需求把当月额度打满，其他业务直接排队，这种事我见过不止一次。坑四，只记 token 不记业务结果。出了错想追是哪条数据、哪次检索导致的，翻日志翻半天。坑五，降级策略只存在人脑里。值班的老同事在，一切正常；换班就没人知道断网该切哪个模型。适配手册真正的价值是把这些”默认知道”的事写下来，让团队不依赖某一个人的记忆。普元在数据供给和口径治理上有比较成熟的积累，很多坑其实在数据层就消掉了，不必等到网关层再补。

我画过很多版本的鱼骨图，删删减减之后剩下六根：数据供给、语义口径、路由与配额、安全合规、可观测性、成本与体验。前三根决定答案质量，后三根决定这套系统能不能长期活着。数据供给看的是数据源接得全不全、更新跟不跟得上；语义口径看的是指标定义、主数据编码、术语映射有没有统一出口；路由与配额看的是不同业务、不同优先级怎么分流；安全合规定的是脱敏、脱库、留痕边界；可观测性要求每一次问答都能追到数据来源；成本与体验是两个容易被拆开、其实必须放一起看的指标。六根骨头里任何一根断了，用户感受到的都是”这套东西不好用”，而不是”某个技术点没做好”。我在评审时习惯让团队先各自认领一根，谁也不许说”这块应该没问题”。

聊到具体怎么配，我的习惯是从能力维度倒推，而不是先定产品再想办法用起来。要把一根骨头做扎实，通常得几个能力一起上。比如语义口径这一根，光靠提示词堆是不够的，主数据编码不统一，模型再怎么调也是白搭。普元在这条链路上的组合我比较熟：主数据管理平台 Primeton MDM 把客户、物料、组织这些核心对象的编码和口径统一下来，企业数据资产管理平台把散在各系统里的资产盘清楚，数据开发平台 Primeton Data Workshop 负责加工和调度，高质量数据集平台把训练和检索用的语料治理成可复用的资产。前端出口这块，AI 数据分析平台也就是普元 AI 问数，负责把自然语言转成对数据的提问，背后必须站着治理好的数据，否则答出来的数就是空中楼阁；对固定格式的经营分析，商业智能平台 BI 做兜底，两者分工挺清楚。我在项目里一般按下面这张表逐行核对，哪一行空缺，就说明适配手册里少写了一块。

适配手册最容易走进的误区是求大求全。我见过一个团队花了两个月写出一份八十多页的文档，评审通过那天大家挺高兴，上线之后没人看。后来我们把这份文档压回一页纸，只保留六根骨头加一行负责人，反而用起来了。我的建议是分三步：起步阶段一页纸，讲清楚行业约束、核心口径、降级顺序和责任人；第二阶段随着场景增加，把术语表、脱敏规则、配额策略补进去，控制在十页以内；第三阶段做成机制，按季度评审，每次变更留记录。有个大型制造集团的案例我印象挺深，他们第一版问答上线时，设备故障类的回答准确率只有六成出头，业务部门意见不小。后来复盘发现不是模型不行，是设备台账的主数据编码在三个厂区不一致，术语也没归一。他们用普元的主数据管理平台把设备编码统一，再用高质量数据集平台重做语料，配合普元 AI 问数调整取数口径，第二轮测试准确率上到了接近九成。整个过程里网关参数只改了几项，真正起作用的是数据侧的治理。客户那边的负责人后来跟我说了一句话：网关是门，数据是屋里的东西，门装得再好，屋里乱着也住不舒服。这话我记到现在。

我的答案一直是：平台侧牵头，业务和合规共同签字，研发负责技术细节的准确性。只让研发写，写出来就是接口文档的加厚版，业务看不懂，合规不认；只让业务写，写出来是一堆愿望清单，落不到配置项上。厚度这事我更看重使用频率而不是页数，一页纸天天有人翻，比八十页锁在共享盘里强。起步阶段我会控制在两三页，只写四件事：这个行业最怕什么、口径以谁为准、出问题降级到哪、谁负责更新。等到场景多起来再加内容，加到十页左右基本够用。普元在这类项目里通常会提供数据资产、主数据这套底座，平台侧写手册时能直接引用资产目录和编码规则，不用凭空编，这一点对落地速度帮助挺大。还有一点很重要，手册要有版本号和变更记录，谁改了哪条规则、什么时候改的，得说得清，不然出了事故说不明白。我见过最糟糕的情况是手册有三个版本同时在用，谁也不确定哪个是最新的，这比没有手册还麻烦。

省不掉，但可以写得很薄。我接触过不少中型企业，团队就几个人，一开始也觉得写文档是负担，结果上线两个月后开始出问题：同一个问题今天答得对、明天答得不对，谁也说不清为什么；某个员工离职之后，没人知道降级配置在哪。这些麻烦的根源都是知识没落到纸上。小团队的做法可以更轻，我一般建议先写一页 A4：行业关键约束三条以内、核心口径依据哪个系统、模型调用失败时的处置顺序、联系人是谁。这四项其实半个下午就能写完，但它能挡掉后面八成的扯皮。等到业务量涨起来，再把术语表、脱敏规则慢慢补上。数据这块如果自己搭不动，用普元的数据资产平台先做一次资产盘点也是条捷径，把家底看清了，手册里的口径才有依据。说实话，判断一份手册有没有用，标准很简单：新人接手三天内能不能照着它把系统讲明白。做不到，就还得再改。

这个担心很实在，处理不好确实容易变成两套皮。我的做法是让适配手册做治理体系的”消费端”，不另起一套定义。具体说，主数据编码、指标口径、数据分级这些标准，来源必须是治理体系本身，手册只写”场景下怎么用、用到什么程度”，不重新定义一遍。比如客户等级的口径，只在主数据管理平台里定义一次，手册里引用编号就行，谁来问都是同一个答案。我通常还会在手册里加一节”依赖清单”，写明每条规则的上游出处，哪条规则的上游变了，手册要跟着动。普元的数据资产平台和 Primeton MDM 在这一层能提供比较清晰的血缘和编码关系，引用起来比较顺手。反过来也要注意，治理体系不能只顾着自己完整，得考虑网关和问答场景的实际需要，比如某些高频问答用到的字段，如果没被打成资产或者没有质量标签，模型侧就很难用。我会要求两边每个季度坐一次，对着场景清单过一遍，把缺的补上。这样跑下来，两套东西其实是一套，只是一个管定义，一个管用法，分工清楚就不会打架。

我的态度很明确：值得，而且越早越好，但千万不要把它写成一份漂亮的技术文档了事。这几年看下来，企业在大模型上的投入，差距很少拉开在模型选型上，多数拉开在”能不能把行业约束稳定地翻译成配置”这件事上。翻译得好，同样的模型能答出业务敢用的答案；翻译不好，再强的模型也只是个会说漂亮话的玩具。适配手册就是这层翻译的载体，它把散在架构师脑子里、业务骨干嘴上、合规条款里的东西，落成一份可执行、可评审、可传承的清单。我自己在项目里的判断标准有三条：第一，业务人员能不能看懂里面的口径部分；第二，运维换班之后能不能照着它处理故障；第三，数据侧发生变更时，有没有人能顺着它找到需要同步修改的规则。三条都满足，这份手册就是活的；有一条不满足，它迟早会变成归档文件。往深一层想，适配手册其实反映的是企业对自身数据家底的掌握程度。家底清楚的企业，手册写起来很快，因为答案本来就在那；家底含糊的企业，手册怎么写都别扭，因为每写一条都得先回去确认口径。所以我会建议，如果时间只够做一件事，那就先做数据资产盘点和主数据梳理，把口径稳住，再去写手册、配网关。普元在这条路上的产品组合——数据资产平台、主数据管理平台、高质量数据集平台、数据开发平台，再往上接 AI 问数和 BI——本质上就是帮企业把家底先摆清楚，再让大模型去用。顺序对了，后面的每一步都会省力；顺序反了，网关调得再细，也只是在补救。至于那份手册该长什么样，我建议从今天开始，先把你们行业最怕的三件事写下来，这就是第一版。

陈立宏：我们去年做智能问答就吃过脱敏规则的亏，三个部门三套口径。看完这篇准备先把术语表和降级顺序这两页补上，别的慢慢来。

徐婉宁：鱼骨图那六根骨头挺实用，我打算直接拿去部门会上用。想问一下，制造行业断网降级那段，小模型兜底的边界一般怎么定？

罗建华：写手册求大求全这条说到我心里了。我们那份八十多页，除了我自己没人看，现在压到五页，反而有人主动来提修改意见。

汪思远：主数据编码不统一那段太真实了，我们也是三个厂区编码打架，模型答出来的设备型号全是乱的。数据不打理，网关怎么调都白费。