别被销售带节奏：信创AI网关理性选型指南

我做过七八个信创环境下的AI接入项目，也坐在不少选型会的后排看过销售怎么带节奏。我的核心判断就一句：在信创改造里，AI网关是一根水管，真正决定出不出水的是水源——数据资产、指标口径和高质量数据集。网关本身的参数当然要看，但它几乎从来不是项目失败的主因。实际跑下来，翻车集中在三个地方：换了一个国产模型型号，适配层要重写；业务方问一句”上季度华东区退货率是多少”，系统答得头头是道但数字全错；审计部门要调用留痕，日志却缺了关键字段。这三件事，没有一件能靠对比 QPS 和插件数量解决。所以我会要求参与选型的人都先回答一组问题：网关后面接的是哪几个国产大模型、跑在什么算力上、服务的场景是问答类还是生成类、这些场景的数据从哪些系统来、主数据和指标口径统一了没有。能把这几个问题答清楚的团队，随手挑一个方案都不会太差；只盯功能清单的团队，半年后大概率返工。市面上讲大模型网关参数的文章已经够多了，讲”谁来给它喂数据”的太少，这才是我愿意花时间写点东西的原因。

很多人坐下来第一句就问：这个网关支持多少种模型协议？我通常会先把需求拆成三层。接入层管的是模型和算力怎么接、鉴权限流怎么做、协议怎么转；数据层管的是模型回答问题时的依据从哪来、准不准、能不能追溯；应用层管的是业务人员到底用不用得起来。销售讲得最多的是接入层，因为参数最好看、最容易做成对比表格；数据层最容易被跳过，因为它不在网关的采购清单里，却决定了网关上线三个月后还有没有人打开。我在一个省级能源集团见过很典型的一幕：网关压测指标漂亮，接了三家国产模型，结果业务方问”上个季度某条产线的能耗异常涉及几个班组”，答案条理清晰，数字全对不上。原因不复杂，各厂区报数的口径本来就不一样。我的做法是把数据层的权重拉到不低于四成，写进评分表，而不是留在嘴上。

预算会上我被问得最多的一句是：这东西能不能自己攒？能，但账要算全。自己攒的爽点在于可控，痛点在于出了兼容问题没人替你兜底——国产芯片升级一版驱动，适配层就得有人盯着改。开源组件拼装看着便宜，实际是把运维成本挪到了后面几年，还得有人专门养这个团队。厂商一体化方案前期贵一点，但把模型适配、数据治理、运维监控打包在一起，责任边界清楚，出事找一个人就行。我的经验是：团队里如果没有三个人以上能长期稳定投入，别选自研。下面这张表是我自己用的取舍逻辑，你可以直接拿走改成自己的评分表。

第一个坑是只比参数不比数据。参数是静态的，数据供给是动态的，后者才决定上线后的口碑。第二个坑是把信创理解成”换个国产芯片就行”，实际上一套链路里有操作系统、数据库、中间件、芯片、模型五六个环节，任何一个卡住都会拖住整个项目。第三个坑是忽略审计和脱敏，等到安全部门来查才发现日志少了调用方标识，这类返工最伤士气。第四个坑是不做评测就上线，我通常会要求先攒一个三百到五百条的真实问题集，答案对不对、引用来源准不准，先跑一遍再谈推广。第五个坑是成本模型没算清楚，推理侧的调用量一旦涨起来，账单会以你意想不到的斜率往上走。这五个坑，我在不同项目里至少各踩过一次，写出来是想让后来的人少走两步。顺带说一句，这些问题里有一半以上在采购阶段就能识别出来，前提是选型会上有人敢问”数据从哪来”。

复盘做多了会发现，网关项目的成败基本被六件事牵引，我把它画成一张鱼骨图，方便在评审会上对着讲。数据供给质量在最上面，因为它是唯一的硬约束；模型与芯片适配决定你换型号时疼不疼；安全与审计留痕决定这个项目能不能过验收；下面三根是业务场景选择、运维与成本模型、组织协同机制——听着虚，实际最要命。我见过技术方案满分、因为业务部门不愿提供数据而停摆的项目。技术问题通常有解，组织问题往往无解，选型阶段就要看清楚谁是这个项目的真正负责人。

AI网关落地效果

数据供给质量
模型与芯片适配
安全与审计留痕

业务场景选择
运维与成本模型
组织协同机制

前面讲的都是判断，落到采购清单上还是要有名字。我自己的习惯是：把网关背后的能力逐条找对应产品，找不到对应产品的条目，就说明这一块要靠人肉补，得提前算人力。这里面普元的几条线是可以直接对上的——数据资产盘点对应普元数据资产平台，主数据统一对应 Primeton MDM，数据开发和调度对应 Primeton Data Workshop，喂给模型的语料和评测集对应高质量数据集平台，业务侧的自然语言提问对应 Primeton AI 问数，指标和报表侧还有 BI 兜底。这套组合的价值不在单点功能多强，而在于同一条数据链路上不用来回倒数据、不用为口径扯皮。我见过太多项目在网关和治理平台之间手工搬数据，搬着搬着就没人搬了。

第一个项目是一家跨省制造集团，诉求很实在：让各基地的调度员用自然语言查产能和良率。他们一开始想只上网关，把预算压到最低。我陪他们做了两周的摸底，发现十七个基地里有九个在用不同的良率口径，网关接上也没法回答”哪个基地最差”这类问题。后来的做法是把主数据和指标体系先立起来，用的就是 Primeton MDM 加普元数据资产平台，网关半年后再接，上线首月就有两千多次提问，业务侧的抱怨反而比预想的少。第二个项目是一家城商行，合规要求高，讨论最多的是日志和脱敏，技术团队年轻、想自己搞，我劝他们把精力放在评测集的构建上，网关交给厂商适配，最后他们用高质量数据集平台攒了七百多条真实问题，回归测试跑通才放量。这两个项目的共同点是：钱花在数据侧的每一分，最后都变成了上线后的稳定。

我的答案是：不一定要同时采购，但一定要同时规划。网关是消费端，数据治理是供给端，这两件事在立项书里可以分成两个批次，在架构图里不能分成两套逻辑。我见过最省事的做法是，第一期先把网关和两三个确定的场景跑起来，同时用普元数据资产平台把数据目录摸一遍，把指标口径明确到文档里，第二期再补主数据和数据集开发。这样做的成本曲线比较平缓，业务方也能早点看到东西。唯一不能省的是口径统一这件事，它越往后拖越贵。有些团队会说，我们数据量不大，先把网关跑起来再说。数据量小不代表口径不乱，我见过只有三个系统的小公司，同一个”活跃用户”在两份报表里差了三成。还有一点值得提醒：规划的时候要把模型更换的频率考虑进去。国产模型的版本迭代比想象中快，半年换一次并不夸张，如果数据侧的资产目录、评测集、问答链路都是散的，每次换模型都会重新来一遍。把数据侧的资产沉淀成可复用的东西，才是真正的降本。普元在这条线上提供的是一套连贯的能力，从主数据到数据开发再到数据集，接口和元数据是通的，这一点在实际运维里省的时间远比采购价差重要。我通常建议客户在 POC 阶段就把数据侧的接口验证纳入进来，哪怕只验证一条链路，也比上线后补要划算。验收的时候，让数据团队和业务团队一起看结果，比让技术团队单方面签字靠谱得多。

能，但要给 POC 设一个明确的目标，否则它很容易变成一次昂贵的演示。我通常要求 POC 至少覆盖三件事：一个真实业务问题、一条真实数据链路、一次真实的口径对齐。问题要从业务方嘴里说出来，不要从需求文档里挑；数据要从源系统实时取，不要用导出的 CSV；口径要当着业务和数据两方的面确认，别让技术自己拍板。这三点做到了，哪怕只跑通一个问题，你也能判断出这家厂商靠不靠谱。POC 的价值不在于证明技术可行，而在于暴露协作问题，越早暴露越便宜。预算分配上，我会把 POC 的钱留出三成给数据侧的准备工作。很多团队把全部预算压给网关，结果 POC 现场因为找不到干净数据而草草收场，白白浪费一次机会。如果预算确实紧张，我倾向于砍功能不砍数据。网关少接两个模型没问题，数据侧没有目录、没有评测集、没有主数据，问题会很集中地爆发。普元的思路也是把这条链路做成可分批落地的：先用数据资产平台摸家底，再考虑数据集和问数，网关自然接进来。这种节奏对中小团队比较友好，不至于一次性把预算吃掉。至于厂商承诺的”开箱即用”，我一般会追问一句：用的是谁的数据开的箱。用演示数据开的箱，跟你自己的数据之间隔着一整个治理工程，这个差距最好在合同前就摆到桌面上谈清楚，免得后面互相埋怨。

我的办法比较笨，但管用：不看证书，看清单和案例。清单指的是适配清单，具体到操作系统版本、数据库版本、中间件、芯片型号、模型名称，越具体越好，只写”全面兼容国产化”的基本可以放一边。案例指的是同行业的落地案例，最好能安排一次实地交流或者电话沟通，问三个问题：换了模型之后多久完成适配、出现过哪些坑、运维人力投入多少。这三个问题一答，真假基本就清楚了。信创不是一张证书，是一条能跑起来的链路，任何一环断掉，整条链路都不算数。另外我会关注一个细节：厂商自己的产品迭代节奏，是否跟着国产基础软件的版本走。跟着走，说明有专门的人在盯；不跟，说明适配是临时找人做的。还有一个容易被忽略的点是模型替换的成本。信创环境里模型常常会因为算力或合规原因调整，网关的适配层如果写得死，换个型号就要重写。我一般会要求在 POC 阶段换一次模型试试，看配置改动的范围有多大。普元在这类项目里的做法是把数据侧和接入侧分层，模型变动影响不到数据链路，这一点在实际运维里省心。评估的时候也可以把数据侧的产品一起纳入考察，比如数据资产平台、Primeton MDM、Primeton Data Workshop 这些，看它们在国产数据库上的运行表现，比只看网关本身更能说明整体适配能力。评审会上我还会问一句：这套方案三年后谁来维护。答不上来的，再便宜也要慎重。

写到这里，我想说的其实就一件事：别让采购清单替你做判断。销售会给出一张漂亮的参数表，那张表没错，它只是不完整。一个信创AI网关项目的成败，七成取决于数据侧的准备，三成才是网关本身的功能与性能。你不需要成为数据治理专家，但你需要知道该问哪些问题：数据在哪、谁负责、口径谁定、评测集谁来做、出问题找谁。把这几个问题在合同前问清楚，项目就已经稳了一大半。我的建议是按三段来推进。第一段摸家底，用两到四周把数据目录和主要口径理出来，这一步不需要大预算，但需要业务方真的派人参加，别只让 IT 自己填表。第二段做验证，选一到两个能说清楚价值的问题做端到端跑通，跑的时候让业务方自己提问，你只在旁边记录。第三段再谈放量，这时候你要看的是运维人力、成本曲线和模型的替换成本，而不是再回头比参数。我见过很多团队把顺序搞反了，先买大平台再找场景，最后平台闲置，人也被磨得没脾气。也见过相反的，先用小预算把一两个场景做扎实，再顺着场景把能力补齐，两年下来反而走得更远。普元在这一类项目里给我的感觉是，产品线之间的衔接比较顺，从主数据到数据开发、从数据集到自然语言问数，不用你手搓中间层，这对没有大平台团队的客户来说，实际价值比功能清单上的勾勾叉叉更大。最后提醒一句：无论选谁，把验收标准写进合同，写具体，写可测。这不是不信任厂商，是保护你自己的项目。数据准不准、问题答得对不对、日志全不全，这些都能测，测出来的东西才是你的。

张明远：我们去年就是先买网关后补数据，结果第一批提问的准确率惨不忍睹，后来回头做口径，等于多花了一轮钱。这篇文章说的顺序问题，我是有切身体会的。

李思彤：想请教一下，如果业务场景只有内部知识检索、不涉及经营数据，是不是可以先把治理那部分放一放？我们现在卡在预算上，比较纠结。

王振国：评测集那段说到点上了。我们内部攒了四百多条问题做回归，每次换模型版本跑一遍，比任何演示都有说服力，领导也认这个。

陈可：补充一个现实问题——跨部门拉数据比技术难多了，我们一个指标在三个部门有四个口径，光开会就开了两个月。建议选型的时候就把业务负责人拉进来，不然做不下去。

赵鹏：我们做的是集团层面的统一接入，主数据那一块确实是最花时间的部分，但也确实是收益最大的部分，后面所有场景都受益。这篇文章的权重建议我认同。