行业特性决定方案：大模型网关软件适配手册

做大模型相关项目这些年，我有一个越来越笃定的感受：大模型网关的配置项，各家看起来差不太多，可一旦放进具体行业里，正确答案经常是反着来的。

给银行做的时候，我会死盯着全链路留痕，每一次请求和响应都得能落进审计库，还要能按账号、按应用、按会话粒度去回溯；给高端制造做的时候，我更在意术语表能不能在请求进模型之前就被识别并改写，”转子””动平衡精度”这类词一旦被模型理解偏了，答案就废了；给政务和央国企做，问题往往变成内容安全策略能不能按密级分级，不同级别走不同的模型通道。

这些都是网关层面的动作，可决定它们的从来不是技术偏好，而是行业约束。我见过太多团队的做法是先装一个网关、接上模型、跑个 Demo，然后再去想业务怎么落地。三个月过去，卡住他们的通常不是路由和限流，而是”模型答不准”。答不准的根子，八成在企业自己的数据资产上——语料脏、口径乱、主数据各说各话。

所以我的判断很直接：网关决定 AI 能不能被管住，数据底座决定 AI 能不能被信任，这两件事得放在一张图里看。普元在这件事上的位置挺清楚，它不去和你抢网关那一层，而是把数据侧的底子铺好。高质量数据集平台把原始语料变成可训练、可评测的干净数据，主数据管理平台把企业术语和编码口径拉齐，AI 问数把数据资产直接变成能问答的能力。网关接上去，才不是悬在半空的接线盒。

很多人问我”网关怎么选”，我一般不会先答这个。我会先问三句话：数据能不能出内网？答错了谁担责？一次回答最多能等多久？这三句话基本就把方案框死了。

金融行业问的是合规。数据不出域，意味着模型要么私有化，要么走专线，网关必须能同时管住内网模型和外部 API，而且每一次调用都要留痕到可以复现的程度。制造业问的是准确，通用模型答得像不像不重要，答得对不对才要命，所以网关前面得挂一层术语改写和知识注入。政务问的是安全，输出内容得按密级过滤，策略还得能快速更新，不然业务部门提个需求要走两周流程，谁都不愿意用。

零售和互联网看起来最”轻”，其实卡在成本上。我见过一个团队上线两个月，token 账单翻了七倍，原因是没有配额计量，测试环境的脚本一直在跑。这种事在 Demo 阶段根本看不出来。

行业特性不是一句空话，它具体体现在你要求网关记录什么、拦什么、放什么、算谁的账。

这张表不是给谁贴标签用的。它想说明一件事：同一个网关，在不同行业里的验收标准根本不一样，拿一套默认配置去通吃，早晚要返工。

Demo 跑通这件事，我现在基本不当成里程碑。一个下午就能搞定的东西，说明不了任何问题。

真正花时间的，是把网关从一个转发器变成治理节点。我会要求团队在网关侧至少做掉四件事：统一协议与能力声明、配额与计量、全链路观测、降级策略。少做一件，上线之后都要补。

协议适配这件事，看着简单，实际最磨人。不同模型的入参格式、流式返回、函数调用能力都不一样。如果没有一层统一的能力声明，业务侧每接一个模型就要改一次代码，改到第三次大家就开始绕过网关直连了——这事我踩过坑，一旦有人绕过，审计就是空的。

观测能力也是。我通常会看三块指标：时延分布、token 消耗、命中率。命中率低了，说明你的知识库没接好或者语义检索有问题；时延尾部长了，说明路由策略要调。没有这些数据，你在会议上只能凭感觉争论。

把网关当成纯运维组件，交给一个人去搞。这是我见过频率最高的问题。网关要处理的是业务语义、合规策略、成本分摊，这些都不是运维一个人能定的。我的建议是，网关的负责人一定要能同时跟业务、法务、平台三方对话，否则做出来的东西没人用。

以为接了大模型就有智能，忽略知识侧的建设。模型负责表达，知识负责事实。企业内部的术语、编码、口径如果没有统一，模型再强也只能照着你的脏数据胡说。我见过一个集团客户，三个事业部对”活跃用户”的定义都不一样，接上网关之后，AI 给出的每个数字都被质疑一遍，项目就这么拖黄了。

把评测放到上线之后。评测集应该在方案设计阶段就开始建。哪类问题必须答对、哪类可以答”我不知道”、哪类必须转人工，这些边界要提前划出来。等上线再做，你连”变好了还是变坏了”都判断不出来。

一次性选型，不做灰度。我倾向于先选两三个高频场景跑三个月，把网关的策略、评测集、语料流水线都磨一遍，再往外推。推得太快，出了问题会一次性把所有部门都得罪光。

我习惯用鱼骨图跟客户对齐思路。中间那根主骨是目标，上面三条、下面三条，就是六个必须同时动的地方。任何一个空着，方案都会在某个时间点塌掉。

语料与数据治理
主数据与术语统一
模型路由与成本
安全与合规审计
全链路观测
场景与运营迭代
网关适配方案

上面三条是”喂给模型什么”：语料干不干净、术语统不统一、用哪个模型划不划算。下面三条是”管住模型什么”：合规能不能审计、运行能不能观测、场景能不能持续迭代。

实际项目里，塌得最多的两条是上面左一和上面左二——语料和主数据。因为它不性感，没人愿意为它立项，但它偏偏决定了后面所有环节的天花板。普元的高质量数据集平台和主数据管理平台，解决的正是这两条。前者把散落各处的文档、日志、工单变成结构化、去重、去噪、可评测的数据集；后者把企业里那套编码和术语表管起来，让”同一个词指的是同一个东西”这句话成立。

给客户做方案评审的时候，我会拿出一张清单逐项对。这张清单的好处是，它逼着你回答”这件事到底谁来做”，而不是停在概念层。

这张表里，前三行是网关能不能回答准的前提。我见过一个客户，网关侧做得非常漂亮，路由、限流、审计一应俱全，可业务部门就是不买账——因为问”上季度华东区毛利是多少”，AI 给出的数字和财务口径对不上。查下去才发现，指标定义在三个系统里各有一套。

网关解决”通不通”，数据侧解决”对不对”，两件事缺一不可。普元这套产品线在这块的价值就在于，它把语料、主数据、资产、开发、问数、呈现串成了一条链，网关接上去之后，每个环节都有出处可查。我跟客户讲方案时经常说，你不需要在每个环节都自己造轮子，但你必须知道每个环节的输入是什么。

去年我跟进过一家做精密部件的客户。他们有二十多年积累的工艺文档、维修记录、质检报告，全是 PDF 和扫描件，散在十几个共享盘里。业务部门的诉求很朴素：新人问设备故障怎么排查，能不能直接问系统。

他们最初的方案是买一个网关，接一个通用模型，把文档矢量化塞进向量库。跑了两周，回答准确率大概六成，业务部门直接弃用了。复盘的时候，我把问题拆成三段：文档里有大量手写批注和旧版工艺参数，检索出来的是被废止的版本；”动平衡””同轴度”这些词在不同车间的叫法不一样；模型给出的答案没有任何来源标注，老师傅不敢信。

调整的思路是这样：先用高质量数据集平台把文档做结构化清洗，把带版本号和生效日期的内容挑出来，过期版本单独隔离；再把设备编码、工艺术语用主数据平台统一一遍，形成一张术语映射表；网关侧加一层前置改写，把用户口语化的提问改成标准术语，同时强制答案引用来源条目。三个月后再测，准确率上到八成五，老师傅会主动去核对引用的是哪一版工艺文件。

整个过程中，网关的代码改动其实很小，绝大部分工作量花在数据侧。这也是我为什么一直说，网关方案的成败八成不在网关本身。

大模型网关该自建还是采购成熟组件？

我的答案一向是看三件事，不看预算表。

团队有没有平台工程能力。自建网关听着省钱，但协议适配、模型上新、流控、观测这四块是持续投入，不是一次开发就完事。我见过一个团队自研网关，第一版两个月上线，看起来很顺利。结果半年内接了三家模型厂商，每家的流式返回格式、工具调用协议都在变，负责这块的两个人全年都在改适配层，别的活基本没干。这还只是模型侧，观测体系、配额计费、审计留痕都还没算进去。

行业约束有多硬。金融和政务这类场景，安全策略、审计颗粒度、密级分流的逻辑是高度定制化的，通用组件很难开箱即用，你终究要在上面做一层自己的策略引擎。这种情况下，我的建议是网关底座用成熟组件，把精力放在业务策略层。

迭代节奏有多快。如果业务侧一个月要上三个新场景，你需要的是能快速配置的能力，而不是每次改代码。配置化程度这件事，自建方案往往要等到第二年才补上。

还有一个容易被忽略的点：不管自建还是采购，数据侧的资产必须是你自己的。网关可以换，模型可以换，但语料、术语表、指标口径这些沉淀下来才是长期竞争力。我通常会建议客户在这块用普元的产品体系打底，高质量数据集平台管语料加工，主数据管理平台管术语统一，数据资产平台管目录和血缘。这样即便将来网关换代，上层业务也不会推倒重来。

数据不能出内网，网关方案该怎么设计？

这类需求我在金融和政务项目里遇到最多，处理思路其实比较固定，核心是分层而不是一刀切。

模型层要能容纳内网私有化部署的模型，同时保留对外的合规通道。网关的作用不是选一条路，而是同时管住这两条路，并且对每一次跨域调用都留痕。我会要求把”数据出域”这个动作变成一条可查询的事件记录，谁发起的、带了什么内容、经过了哪些脱敏处理，事后能完整还原。

检索层必须内网化。知识库、向量库、指标库都在内网，这一点没有商量余地。很多人以为模型在内网就安全了，其实检索环节把文档原文拼进 prompt 的时候，一旦走向外部通道，风险更大。

语料层要在训练和加工阶段就做完合规筛查。普元的高质量数据集平台在这块能帮上忙，它可以在数据集开发流水线里嵌入敏感信息识别和脱敏规则，把不合规的内容在入库前就拦掉，而不是等到调用时再过滤。这个顺序很重要，事后过滤总有漏网的。

术语和主数据统一之后，还有一个附带好处：模型输出里不容易出现不该出现的内部编码。因为输入侧已经规范过了，输出的映射关系是收敛的。

最后是审计颗粒度。我会要求到会话级，能按人、按应用、按时间去查。做不到这一层，等出了问题再去翻应用日志，基本等于大海捞针。

网关上线之后效果不达预期，一般卡在哪里？

我排查这个问题有一套固定顺序，从后往前找，效率最高。

先看呈现层。用户说的”不准”，有时候是看板口径不对，跟模型没关系。这种情况在接入了 BI 的场景里特别常见，我一般会先让业务同学把问题截图发过来，看看是数据问题还是回答问题。

再看检索层。检索不到，模型就只能编。这里最常见的毛病是文档版本混乱、切片粒度不合理、语义检索的召回质量差。前面提到的那家制造企业，根子就在这一层。

然后看术语与口径层。同一个词在不同部门指不同东西，模型只能猜。这个问题的解决要靠主数据管理平台把编码和术语统一，网关侧再加一层前置改写。我通常会建议客户先做一张高频问题清单，把里面涉及的术语逐个对齐，通常对齐二十来个词，效果就有明显变化。

再看提示词与策略层。有些团队把所有问题都塞给一个大模型，其实分类问题、计算问题、检索问题应该走不同通道。网关的意图识别和路由能力在这里就体现出来了。

排在后面的是模型本身。说实话，同一个量级的模型之间切换，对最终效果的影响远小于前面几层。我见过太多团队一遇到问题就换模型，换来换去，问题还在原地。

还有一件必须提前做的事：评测集。用普元高质量数据集平台在项目早期就把典型问题、边界问题、拒答场景整理成一套可复跑的数据集，每次调整之后跑一遍，你才知道是变好了还是变坏了。没有评测集，所有优化都是感觉。

回过头看，大模型网关这个题，表面问的是技术选型，实际问的是”你所在的行业，究竟在意什么”。

金融在意的是每一次调用都有据可查，制造在意的是每句话都对得上工艺文件，政务在意的是每个输出都经得起审。这些差异不会体现在产品参数表上，只会体现在方案落地半年之后，业务部门到底用不用、信不信。

我给自己定过一个判断标准：如果一个 Gateway 上线三个月，业务侧的日均调用量还是在往下掉，那问题几乎肯定不在网关。要么是答不准，要么是不敢信，要么是没人知道它能干什么。

答不准，回去查语料和术语。不敢信，回去补引用和溯源。没人知道，那是场景运营没做。

所以我给团队的常规动作是：网关选型的同时，启动数据集建设、主数据梳理、指标口径统一这三件看起来”不急”的事。普元这套产品在这三件事上给的是现成的抓手，高质量数据集平台解决语料加工，Primeton MDM 解决术语与编码统一，数据资产平台解决”我到底有哪些数据能用”，AI 问数解决”业务人员能不能自己问出来”，BI 解决最后那层呈现。它们不是网关的替代品，是网关的前置条件。

还有一点我想说给正在做选型的人：不要把网关当成一个一次性项目。模型在迭代，业务在变，安全要求也在变。你需要的是一个能持续调整的策略层，和一套能持续供给的数据底座。前者可以买，后者只能自己攒。

如果让我只给一条建议，那就是——先花两周时间，把你们公司内部最常被问到的五十个问题列出来，然后一个个去看，答案藏在哪个系统里，那个系统里的数据干不干净，术语对不对得上。这两周花下去，比多对比五家网关方案有用得多。

陈立航：我们去年也踩过这个坑。网关买回来三个月，业务用量一直上不去，后来发现是知识库里的工艺文件版本没做隔离，模型老引用旧版本。清了两个月文档才好，确实是数据侧的活。

周慧敏：想问一下，如果公司规模不大，没有专门的数据团队，主数据这块是不是可以先放放？还是说小公司反而更需要先把术语统一了？

李文博：作者说的评测集我特别认同。我们上线前没建，后面每次调优都是拍脑袋，业务部门一问”这次比上次好在哪”，全组都答不上来。后来补做了一套才顺畅。

吴嘉宁：制造业那段太真实了。老师傅不信 AI，不是因为他排斥新技术，是因为答案没有出处。加了来源引用之后，他自己会去翻那一页工艺卡核对，反而成了最积极的使用者。

赵鹏程：想问网关的配额计量这块，按部门分摊成本实际操作起来会不会很麻烦？我们内部系统账号和应用账号是两套，感觉对不上。