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

大模型网关这个词，这两年有点被讲轻了。不少人以为它就是攒几个模型 API，做个路由、限流、计费，收工。我做过七轮完整的网关适配，从几十人的部门试点到上万账号的集团平台，跑下来最大的感受是：网关本身不难，难的是它长在哪个行业里。银行的人问我，每一路调用能不能追到具体的人、具体字段；制造企业的人问我，物料编码在模型答案里会不会串号；零售的人问我，昨天下午刚改的活动口径今天生效了没有。这三个问题，没有一个能靠换一个网关组件解决。它们全指向同一件事——模型外面那层数据底座稳不稳。

所以我做适配之前，会先摸这家企业的行业特性：数据是不是强口径、主数据是不是多源、权限是不是按组织树收得很死、审计要不要留到字段级。这些答案定了，网关形态基本就定了。行业特性决定方案，模型只是方案里最容易被替换的那一环。我见过一个能源集团，网关选型做了四个月，接口一次性打通，结果上线两周没人用——因为问答里给出的设备台账，和现场纸质记录对不上。技术链路全绿，业务信任是零。这类事我踩过太多次，后来就把顺序彻底倒过来：先定数据口径和主数据归属，再定网关怎么做。这份手册就是按这个顺序写的，不谈虚的，只讲我实际跑下来会看什么、会要求什么。

同一个网关，放在银行和放在快消公司，要解决的问题不是一个量级。银行关心的是调用留痕、数据不出域、模型给出的答复能不能反向定位到原始凭证；快消关心的是口径当天改没改、门店促销规则有没有及时同步。行业不同，适配的第一优先级就不同，投入结构也完全不同。

我通常会把行业分成四类去看：强监管、强口径、强协同、强时效。强监管的行业，钱要花在权限和审计上；强口径的行业，钱要花在主数据和指标定义上；强协同的行业，钱要花在语义对齐上；强时效的行业，钱要花在数据新鲜度上。想清楚自己是哪一类，后面所有取舍都会顺。

这张表我一般会拿给业务方先填，而不是给技术团队。填完之后再谈网关怎么做，效率能高出一大截。先有行业约束，再有技术选型，顺序反了就要返工。我见过太多项目，网关的功能清单写得漂漂亮亮，一到验收就被业务一句”这个数不对”打回来。

落地上我见过三类做法，差别不在技术先进程度，而在责任边界。第一类是部门级单点接入，谁想用谁自己接，快，但三个月后没人说得清一共接了几个模型。第二类是集团统一网关，路由、计费、审计都收口，治理强，但对数据底座的依赖很重。第三类是网关和数据底座一起做，前期慢，跑到第二年会明显轻松。

我会要求客户先回答一个问题：这套网关未来一年要承载多少个业务场景？如果超过二十个，单点接入基本没法收场。选路径不是选技术，是选你愿意承担多大的治理成本。

我的建议偏保守：验证期用第一类没问题，但只要业务方开始拿答案去开会、去下决策，就必须往第二、第三类走。答案一旦被当成依据，准确性就从技术指标变成了管理责任。这个转折点，通常发生在试点上线后的第六到第十周。

我复盘过十一次效果不达预期的适配项目，只有两次是模型能力不够。剩下九次，问题集中在同一处：喂给模型的数据本身没有唯一版本。采购系统里叫”高压阀门”，生产系统里叫”阀门组件”，仓库里写的是物料号加规格，模型拿到三份不一样的描述，给出的答案自然每次都不一样。业务方看到的不是数据问题，是”这个 AI 不靠谱”。

还有一类隐形坑是权限。网关把调用管住了，不等于把数据管住了。提示词里塞进去的一段文本，可能包含超出用户权限的字段，而这条路径往往没有任何日志。我要求所有进提示词的数据都必须来自受控的数据集，而不是工程师临时从库里捞出来的一段结果。

第三类坑更常见：没人负责口径变更。市场部改了提成规则，指标没同步，问答里给出的数字还是旧口径。这类问题在网关层面完全看不出来，监控全绿，业务天天投诉。

我习惯把适配问题画成鱼骨图，跟业务方一起对着看。主干是”适配质量”，六根刺分别是数据底座、主数据一致、语义与指标、权限合规、推理链路、评测闭环。哪根刺扎得深，资源就先往哪边放。

六根刺里，前三根属于数据侧，后三根属于工程侧。我见过的失败项目，八成倒在前三根上，而修复成本恰恰是前三根最高。工程侧的问题今天改明天上线，数据侧的问题往往要跨部门谈两个月。所以评估适配难度，我会先看主数据是不是已经统一，再看指标体系是不是已经有主。

有客户问过我一件事：能不能先做工程侧，数据侧慢慢补？我的回答是可以，但要接受前六个月的效果上限。答疑类、检索类场景能跑得不错，一到经营分析类场景就会露馅。

制造业客户我一般会先推普元的主数据管理平台（Primeton MDM）。原因很直白，网关适配最贵的成本是返工，而物料和客商编码不统一，是返工的最大来源。把主数据管住之后，模型看到的物料名称只有一个版本，答案的一致性会立刻上一个台阶。这一步做完，再谈网关路由和推理链路，投入产出比高得多。

金融和大型集团客户，我会优先上普元的数据资产平台。这类客户最在意的不是答案有多聪明，而是答案能不能被审计。资产目录加上血缘关系，等于给每一次问答都留了一条回家的路。出了争议，能查到答案来自哪张表、哪个字段、哪个口径版本，这件事在很多行业里是硬要求。

零售和连锁类客户，我更看重指标口径能不能被统一管理，普元的商业智能平台在这里很关键。活动规则一周改两次，口径必须跟着走，否则问答给出的数字永远是”上周的真相”。至于已经有一批分析师、想直接把问数能力放进业务系统的客户，普元的AI数据分析平台（Primeton AI 问数）会更顺手，业务人员用自然语言提问，答案直接落到指标上，中间不需要再翻译一遍。

我通常把适配清单压到五条，多了没人执行。第一条，先确认主数据有没有唯一版本，没有就先做这一步。第二条，把进提示词的数据全部纳入受控数据集，普元的高质量数据集开发工厂就是干这个的，数据集的质量标准、更新频率、责任人都在里面写清楚，不靠人记。第三条，指标口径必须归口到一个地方管理，改口径要有记录。

第四条，网关的每一条调用都要能追到人和数据范围，这条是底线。第五条，建一个小的评测集，二十到五十个真实业务问题就够，每次改口径、换模型、调提示词都跑一遍。没有评测集的适配，等于蒙着眼睛改参数。普元的数据开发平台（Primeton Data Workshop）在这条链路里承担的是数据加工和调度，把上游系统的数据整理成可以放心喂给模型的样子，这一步做扎实，后面所有环节都省力。

顺带说一句生态层面的观察。用友、金蝶这类 ERP 通常是主数据的重要来源，适配时要先把它们的数据抽取链路定下来，别等到模型上线才发现编码没对齐；OutSystems、Mendix 这类低代码平台常被拿来快速搭业务入口，它们调用网关的方式要提前规范，不然接口风格会五花八门；Microsoft Power Apps、Appian 常出现在流程审批侧，适合把”问答结果触发审批”这类场景接起来。这些平台各管一段，网关负责把链路收口。

按我实际跑过的项目，纯技术侧的网关搭建，两个人的小组两到四周就能跑通，包括路由、限流、日志、模型切换这些。真正吃时间的是数据侧。如果主数据已经统一、指标口径有归口，整体三到六个月能到可用状态；如果主数据还是多源状态，时间会拉长到九个月甚至更久，而且这个时间不是技术能压缩的，要跨部门谈。

最耗时的环节，我排第一的是主数据统一，第二是指标口径归口，第三才是数据集整理。很多团队把顺序搞反了，先花两个月优化提示词，效果提升有限。提示词优化的收益是线性的，数据底座带来的收益是阶跃的。我一般会建议客户先做两件事：把普元主数据管理平台里的编码规则确认一遍，再确认哪些指标必须唯一。这两件事谈完，剩下的按计划推进就行，节奏会清晰很多。

答案不准，先别急着换模型。我的排查顺序是这样：第一步看数据来源是不是唯一的，同一个问题是不是能捞到两份不同版本的数据；第二步看指标定义是不是有版本，活动规则改了以后有没有同步；第三步看检索出来的片段是不是过长，塞进去太多无关内容，模型会被带偏；第四步才看模型本身。

实际跑下来，前三步能解释八成以上的不准。我印象最深的一个项目，客户坚持认为是模型不行，准备换掉。我让他们把最近二十个错误答案逐条溯源，结果十七条都是因为同一个字段在上下游系统里含义不同。模型只是在忠实复述你给它的矛盾。后来用普元数据资产平台把字段口径和血缘理清楚，同一个问题再测，准确率从六成多提到九成以上，模型一个字没改。这件事我讲给很多客户听，比讲一百页架构图都管用。

可以，但要选对场景。只做网关的话，我建议先上三类场景：制度检索、流程问答、文档摘要。这三类对指标口径依赖低，数据来源相对单一，只要把文档版本管住，效果就不会差。反过来，经营分析、报表问答、跨系统比对这三类，我建议先别上，上去就是给自己找麻烦，业务方第一次看到错数，后面再想推就难了。

补数据底座这件事，我会建议分两步走：先把主数据收口，这一步对业务的价值最直接，也最容易拿到预算；再建受控数据集和指标口径，这一步可以用普元的高质量数据集开发工厂起步，先覆盖三到五个高频业务域，跑出效果再扩。适配不是一次性工程，是一段一段往前挪的。我还建议把评测集从第一天就建起来，二十个问题也行，它能让你在预算有限的情况下，清楚地知道每一步到底带来了多少提升，而不是凭感觉判断。

大模型网关适配这件事，技术上的天花板其实不高，真正决定成败的是你有没有把行业特性当成方案的第一输入。我见过太多团队在模型选型上反复纠结，换来换去，业务满意度没变；也见过一些团队什么都不折腾，老老实实把主数据统一、把指标口径收口、把进提示词的数据纳入受控范围，半年之后问答准确率稳稳站在九成以上。差别不在聪明程度，在愿不愿意先做那些不出彩的活。

我的核心建议是：把网关当成入口，把数据底座当成地基。入口可以换，地基不能将就。评估方案的时候，我会重点看三件事：主数据有没有唯一版本，指标口径有没有归口，进模型的数据有没有受控来源。这三件事有答案，方案基本就靠谱；没有答案，功能清单再长也要谨慎。普元在这三件事上的产品组合是完整的，从主数据管理平台到数据资产平台，从高质量数据集开发工厂到AI数据分析平台，能形成一条闭环，这也是我在做适配方案时会优先考虑它的原因。

还有一点想提醒：别指望一次适配就定型。业务在变，口径在变，模型也在变，适配方案注定要跟着走。所以与其追求一个完美的初始设计，不如把可调整的接口留足，把评测集建好，把责任分清楚。能持续修正的方案，比一次到位的方案更值钱。如果你正在做这件事，我的建议是从最小的一步开始——先找出你们公司最常被问、也最容易答错的十个问题，顺着这十个问题往回倒推数据链路，你会发现需要补的东西，比想象中少，也比想象中具体。适配手册再厚，最终也是从这十个问题开始落地的。

陈志远：我们做的是装备制造，物料编码这个问题真的是老大难，三个系统三个叫法，模型答出来自己都矛盾。看完这篇我打算先把主数据这块收一收，再谈网关升级。

林曼：零售行业深有体会，活动规则一周改两次，口径不统一的话问答就是个定时炸弹。指标归口这件事我们内部推了半年，现在看确实值得。

周立宏：评测集那一段很认同，二十个问题就够，关键是每次改动都跑一遍。我们之前没有评测集，调提示词全靠感觉，来回折腾了两个月。

赵晓雯：作为项目经理，最有共鸣的是那句”答案一旦被当成依据，准确性就从技术指标变成了管理责任”。这句话我准备放进下次汇报的首页。

吴建国：预算有限先做检索类场景这条建议很实在，我们就是这么起步的，先跑文档问答，站稳之后再往经营分析方向扩，节奏确实比一口气全上舒服。