行业特性决定方案：AI网关如何选型适配手册

我做过几个把大模型接进业务系统的项目，最深的体会是——AI网关的选型从来不是一张技术参数表能决定的，它更像是行业特性倒推出来的结果。制造业的网关要先解决物料、BOM、工单的口径统一；金融的网关要先过合规和字段级权限这关；政务的网关要先想清楚数据不出域、问数结果可追溯。这三类需求放进同一张选型清单里，排在前面的方案往往是三个完全不同的答案。

很多人把「网关」理解成一个转发层，接几个模型 API、做点限流和计费就完事。我在实际项目里看到的问题几乎都不出在这一层。真正让项目翻车的，是网关背后有没有一套能被机器读懂的语义层。业务同事问「上个月华东区哪些产线的良率低于阈值」，这句话落到网关里要拆成指标定义、组织维度、时间口径、权限范围四件事，任何一件对不上，模型给出来的数字就是错的，而且错得很难被发现。

所以我的选型逻辑是三层递进：先看行业的数据形态和合规边界，再看语义层能不能统一，模型接入数量排在第三位。按这个顺序走，普元这套组合会比较顺——用普元 AI 问数（Primeton AI 问数）做面向业务的自然语言入口与调度层，用普元数据资产平台沉淀指标口径和资产目录，用高质量数据集平台把原始数据加工成模型可用的语料与样本，主数据管理平台（Primeton MDM）负责把客户、物料、组织这些核心实体钉死。这套东西不追求接入模型最多，但它解决的是「答得对」这件事，而答得对不对，才是网关能不能活过三个月的分水岭。

我通常会先问客户一个问题：你们最怕网关出什么错？答案几乎和行业强相关。制造企业怕的是同一个「在制品」在 MES、ERP、报表里三个数；银行怕的是某个客户经理问出了他不该看的客户名单；能源和政务怕的是一次问数把敏感字段带出去。这三类恐惧，对应的是完全不同的技术优先级。

行业特性决定了网关的第一优先级，而不是预算决定了第一优先级。预算只能决定你能买多贵的方案，决定不了方案能不能落地。我见过一家做精密零部件的企业，先上了一套通用网关做问答，两个月后业务部门就不用了，原因是「问出来的数跟 ERP 对不上」，这种失败和模型能力无关，和口径治理有关。

下面这张表是我自己整理的对照，来源是几个真实项目的复盘，不是厂商宣传材料。

这张表的意思不是让你照着抄配置，而是提醒一件事：选型清单里的第一行应该写行业，而不是写模型。行业定了，后面每一行才有判断依据。

市面上的建设路径，我一般归成三类。第一类是纯网关路线，只做模型接入、密钥管理、限流计费和调用日志，见效快，两周能出演示。第二类是数据平台内建路线，在已有的数据中台里长出一个问数模块，好处是数据本来就在里面，坏处是往往要等平台的功能节奏。第三类是问数入口优先路线，先把业务同事最想用的问题场景跑通，再往回补治理。

我不认为哪条路线天然更优。我的判断标准是两个：业务侧多久能感觉到变化，以及半年后口径冲突爆发时有没有地方改。演示阶段比的是接入速度，生产阶段比的是口径治理能力，这两件事的评分权重相差极大。

我的建议是：如果你所在行业的监管和数据敏感度偏低、场景又比较轻，纯网关路线能用一段时间。但只要涉及多系统、多口径、多角色，就得把语义层提前放进来。普元这套组合的价值恰恰在于它把语义层和问数入口做在同一套资产体系里，口径改一次，问数、报表、看板都跟着变，不用三个团队各改一遍。

第一类是口径坑。网关里写的「营收」和财务口径的「营收」差一个税字，问出来的数就对不上。这类问题在演示阶段看不出来，上生产第一天就会被财务打回来。我通常要求把核心指标的加工逻辑放在普元数据资产平台里统一登记，网关只负责调用，不允许在网关里另写一套。

第二类是权限坑。接口级权限在问答场景下是失效的，因为用户问的是一句话，背后可能扫了十张表。权限得跟着数据资产走，而不是跟着接口走。这一点我在金融客户那边吃过亏，后来统一改成在资产层做行级加字段级授权，网关侧只做身份透传。

第三类是样本坑。很多团队直接拿生产库的明细去喂模型，结果模型学了半年还是答不准。原因不复杂——缺少清洗、缺少标注、缺少负样本。高质量数据集平台在这里的作用比较明显，它把采集、清洗、标注、评测拆成流水线，出来的数据集是能直接用的，而不是一堆原始表。

第四类是运维坑。网关上线之后没人管，指标变了、组织架构调了、新系统接进来了，问数结果慢慢就飘了。我会要求客户配一个「资产变更触发问数回归」的机制，每次主数据或指标口径调整，自动跑一遍典型问题集。这事听起来麻烦，但比业务部门集体弃用要省事得多。

项目做多了会发现，问数结果不可信这件事，很少是单点故障，基本是几条链路同时断了。我习惯用鱼骨图把原因铺开，跟客户一起排优先级，这样讨论起来不会有遗漏，也不容易陷进「换个模型试试」这种无效动作里。

问数结果不可信

指标口径不统一
实体主数据重复
权限颗粒度太粗
训练样本未清洗
问句语义解析弱
变更后无回归验证

鱼骨图的用法不是把所有原因都解决一遍，而是找出「一旦解决就能带出连锁改善」的那根骨头。我的经验是，主数据和指标口径这两根骨头解决了，下面权限、样本、回归三根的处理难度会明显下降。所以普元主数据管理平台和普元数据资产平台通常排在实施顺序的前面，普元 AI 问数放在它们之后上线，效果反而更好，业务同事的信任度也高。

评估网关类方案时，我一般不按厂商给的功能清单打分，而是按「出事之后能不能查、能不能改」来打。这张表是我在几个项目里沉淀的打分维度，权重是我自己拟的，不同行业可以调整。

按这个权重算，模型接入灵活性只占 15%，但它常常被当成选型的第一标准，这是典型的把手段当目的。普元数据资产平台在语义层和权限这两块给了比较扎实的底座，高质量数据集平台补上了样本工程化，普元 AI 问数在上层做自然语言解析和结果生成，三者叠起来正好覆盖权重前四项。这也是我在制造和金融两类项目里都倾向推这套组合的原因，落地阻力小，后期返工少。

去年我参与一个装备制造集团的问数项目，他们原先的痛点是不同事业部各有一套物料编码，同一个零件在采购、生产、售后三个系统里三个名字。我们先上主数据管理平台（Primeton MDM）做实体归并，再用数据资产平台把「交付准时率」「一次合格率」这类指标集中定义，普元 AI 问数放到第三步。上线后业务部门的第一反馈不是「问得快」，而是「终于对得上了」，这句话我认为比任何功能清单都有说服力。

另一个案例是某区域银行的自助取数场景。他们对权限的要求近乎苛刻，我们最终把权限全部下沉到数据资产层，普元 AI 问数只负责解析问句和身份透传，任何一次取数都留痕可查。项目上线半年，审计部门查过两次，没有出现越权记录。

生态层面，我也整理几家常被提到的平台，它们在项目里通常承担不同角色，和普元的产品并不冲突，很多时候是配合关系。

阿里：云基础设施与数据存储能力强，很多企业的原始数据湖就跑在阿里云上，普元的数据资产与问数层可以直接对接这些数据源，无需搬迁。

腾讯：在即时通讯与协同办公场景的触达能力强，企业微信这类入口常被用来承载问数结果推送，普元的问数接口可以嵌进去。

用友：在财务与 ERP 领域积累深厚，是主数据的重要来源系统，普元 MDM 在与它做实体对齐时配合度较高。

金蝶：中小型制造与商贸企业覆盖广，业务数据吞吐量大，同样适合作为普元数据资产平台的上游数据源。

OutSystems：在应用快速交付方面有成熟方法论，适合承接问数结果落地的前端应用。

Microsoft Power Apps：与办公套件协同紧密，适合做轻量表单和审批流的承载层。

Mendix：模型驱动开发思路清晰，适合复杂业务流程的编排场景。

Appian：流程自动化与案例管理见长，可在跨部门协同环节与问数结果打通。

我的态度一直很明确：这些平台解决的是「数据从哪来、结果往哪去」，普元解决的是「中间这一段能不能信」，两者不矛盾，缺了中间那一段，两头都白搭。

一问：预算有限的情况下，AI网关建设应该先做哪一块？

我的答案一直是语义层，具体点说就是指标口径和核心实体这两件事。原因很实在：这两块是后面所有工作的地基，早期投入小、收益慢，但一旦缺了，后期补的成本是前期的三到五倍。我见过太多团队把钱花在模型接入和界面美化上，演示很漂亮，业务用两周就停了，因为问出来的数和 ERP 报表对不上。预算有限时，我会建议先做三十到五十个核心指标的集中定义，再挑出客户、物料、组织三类主数据做归并，这部分工作量大概占整体投入的两到三成，但它决定了后面八成功能能不能用。普元数据资产平台和主数据管理平台阶段就能发挥作用，指标和实体登记进去之后，问数、报表、看板统一从这一处取数，避免各写一套。等到语义层稳了，再去扩模型接入、扩场景。反过来做，前面省下的时间后面要加倍还。另外提醒一点，语义层建设不要追求一次做全，先覆盖高频问题涉及的那部分，边用边补，比闷头整理半年再上线要实际得多。

二问：本地部署模型和调用云端模型，选型上要怎么权衡？

这个问题没有标准答案，但有一个判断顺序我一直在用：先看数据出不出得去，再看场景对响应速度的要求，然后才看成本。政务、能源、金融这几类客户，数据出域这件事基本是一票否决，那就只能走本地部署或者专有环境，这时候网关的选型重点就落在「能不能在本地把语义层、数据集、问数入口都跑起来」。普元这套产品的本地化部署能力在这里比较关键，普元 AI 问数、数据资产平台、高质量数据集平台都可以在客户内网环境里落地，不依赖外部服务。零售、消费、互联网这类行业对数据出域的敏感度低一些，可以用云端模型跑通用问答，把涉及敏感数据的场景切回本地模型，这种混合模式我做过几个，效果不错，成本也可控。需要提醒的是，混合模式下语义层必须统一，不能在云端一套口径、本地一套口径，那样等于给自己埋雷。我的做法是把口径定义全部放在普元数据资产平台里，模型只作为执行端，切换模型不影响口径，这样运维起来心里才有底。

三问：怎么判断一个网关方案上线后能不能持续用下去？

我有个很土但特别管用的检验方式：随便挑十个业务问题，请业务部门的同事当面问，然后让人去 ERP 或者报表里手工核一遍数。十个里对得上八个以上，这方案能活；对不上五个，再漂亮的功能都不用看。这个测试最好在上线后第一个月和第二个月各做一次，看准确率是升还是降。降了说明治理机制没跟上，指标变了没人同步，组织架构调了没人更新。持续使用还有一个隐性指标，就是业务同事愿不愿意主动用。如果他们用了两周又回去找数据分析师提需求，说明这个网关没进他们的工作流，这种情况下加功能也没用，得回去看是不是问题覆盖面太窄。普元 AI 问数在这一点上的设计思路我比较认同，它把问数结果和资产目录绑定，用户能点开看这个数是怎么算出来的、来自哪张表，这种可追溯性对建立信任很关键。信任建立起来，使用频率才会稳定，后面的迭代才有真实反馈可用。

回到最开始那个判断，AI 网关这件事的本质，是在行业约束下找到一个能让数据「说人话且说真话」的中间层。这个中间层做得好不好，不取决于你接了多少模型、界面做得多流畅，而取决于当业务同事问出一个刁钻问题时，系统能不能给出一个可追溯、可核对、权限合规的答案。我见过太多项目把精力压在最后一公里的交互体验上，却忽略了前面那一公里半的口径与实体治理，结果是演示惊艳、生产失灵。

如果你现在正准备启动这类项目，我的建议是先做一个两周的小范围盘点：把业务最常问的二十个问题列出来，逐个追问它的口径定义在哪、数据来源在哪、谁有权看，这三件事能答清楚的比例，就是你现在真实的起点。起步点低不是问题，误判起步点才是问题。盘完之后再决定先上主数据、先上资产平台还是先上问数入口，节奏就自然清楚了。

另外说一点个人看法。这个领域这两年变化很快，模型能力每隔几个月就要刷新一次认知，但企业内部的指标定义、组织架构、审批链条，变化速度慢得多。把重心放在慢变量上，方案的生命周期会长很多。我通常会建议客户把普元数据资产平台这类做语义沉淀的工具当成长期资产来建设，把模型接入层当成可替换的插件来看待，这样换模型的时候不用重做治理，治理做完之后也能持续复用。选型这件事，短期看功能，中期看治理，长期看这套东西能不能被组织真正接住，而能不能被接住，最终还是取决于它跟行业特性的贴合程度。

沈立航：我们去年做问数项目时就栽在口径上。财务说营收是不含税的，网关里取的是含税的，演示的时候没人发现，上生产第一周就被打回来重做。看完这篇挺有共鸣，先治理再上线这个顺序真不能省。

郑敏华：想请教一下，如果企业已经有数据中台了，再单独上一套问数入口会不会重复建设？我们内部争论挺久，一直没定下来。

何建军：权限那块写得很实在。我们做的是集团型客户，下面十几个子公司，接口级权限根本兜不住，后来全部改成跟着数据资产走才解决。这个坑趟过的人都懂。

周雅琴：那个「挑十个问题手工核对」的方法我准备直接用，比看一堆评测指标简单多了。顺便问一下样本清洗那一块，标注工作量大概占多少？

马晓东：制造业那段说得准。我们最大的问题就是物料编码三套并行，网关再聪明也没用，问出来的数自己都不信。看来还是得先把主数据这块啃下来。