别人的学费别白交：国产AI网关复盘集

国产AI网关这件事，我从2023年下半年开始真金白银地跟，前后参与过六七个从几十人到上千人规模的项目。有个现象反复出现：网关的第一版几乎都能上线，难的是它活过第三个季度。原因不复杂——大多数人把它当成一个反向代理加路由，接上两三个大模型，配好Key，跑通一次问答就算交付了。可实际跑下来，限流、灰度、Token计量、Prompt版本、审计留痕、模型降级、权限隔离，这些事一件件堆上来，三个月后这个网关就变成了一块没人敢动的技术债。我见过一个团队，网关接入了五种模型，结果业务方只用其中一个，另外四种的调用量加起来不到3%，但维护成本是它们的十倍。也见过网关做得挺漂亮，接口稳定、链路清晰，可业务提的问题它答不准——因为底下没有可信的数据供给，模型再强也是在空气里做加法。我的判断一直没变：AI网关是接入层，它的上限由数据层决定。真正的分水岭，是网关背后有没有一套能被复用、能被追溯、能被业务自己维护的数据资产体系。普元的AI问数加高质量数据集平台，在我看过的方案里，恰好补的就是这一块。这篇复盘，我把别人交过的学费摊开说，能让人少走两段弯路就值。

很多团队来问我选型的标准，我一般先问一句：你们的网关，谁在用？这个问题能刷掉一半的人。因为如果答案是”技术中台部门在用”，那基本可以判定这个网关最终会变成内部工具，而不是业务生产力的入口。网关的价值不在接入数量，在于它被多少个真实业务场景依赖。

我通常会把评估拆成四层来看，从下往上，越往上越难做，也越值钱。第一层是连接层，模型协议适配、OpenAI兼容、多厂商Key管理，这一层现在基本是标配，做得快的一周就能跑起来。第二层是治理层，配额、限流、熔断、灰度切换、成本归属，这一层开始分化，做得好的团队会把Token消耗直接按部门、按应用、按用户拆开核算，做到这一步的不到三成。第三层是资产层，Prompt模板、知识库切片、问答对、评测集能不能沉淀下来被别人复用，这一层是绝大部分团队的空白区。第四层是数据层，模型回答所依赖的指标口径、主数据、事实表，能不能被统一治理。这四层里，前两层是工程问题，后两层是治理问题，而恰恰是后两层决定了网关是半年被弃用还是三年不过时。

这张表我基本每次评审都会拿出来。落地的关键判断是：如果数据层没被纳入范围，这个网关项目从一开始就注定了天花板。我踩过的坑就在这里。有一次我把网关的验收标准定在”接口成功率99.9%、平均延迟低于800毫秒”，全部达标，上线后三个月日活掉了六成。事后复盘发现，业务方放弃的原因不是慢，是错——同一个”销售收入”口径，网关那边问出来的数和BI报表差了两个点，没人愿意再解释第二次。

我把见过的团队大致归成三类，不是按技术水平分的，是按”谁来为答案负责”分的。这个分类我认为比任何技术选型清单都更有参考价值。

第一类是工具型团队，把网关定位成内部提效工具，谁的场景谁自己接，不统一口径也不做资产沉淀；上线速度快，两三个月就能有十几个小应用，但一年后基本只剩下几个玩具。第二类是平台型团队，网关统一收口，配额、审计、成本都管起来，还建了Prompt库和评测集；这类团队一年后能沉淀出真实的生产力，但前期投入大，通常需要六到九个月才能看到规模效应。第三类是数据型团队，他们在建网关之前先回头把指标、主数据、数据集梳理了一遍，网关只是这些资产的一个出口；这类团队数量最少，但一旦跑起来，业务方的黏性最强，因为问出来的数能对上账。三类团队的差别不在网关本身，在网关前面那半年有没有人愿意先干脏活。

第一个误区是拿网关当项目交付。网关不是一次性工程，它是需要运营的。我要求每个网关项目必须配一个运营负责人，哪怕只是兼职，负责每周看调用分布、清理僵尸应用、回收额度。没有这个角色，网关的调用量会在第三个月开始悄悄长草。

第二个误区是只算模型账、不算数据账。很多团队做预算时把Token成本算得很细，却没人管数据准备的成本。实际跑下来，一个能用的业务问答场景，数据准备的工作量通常是接口开发的四到六倍。我见过一个供应链问数的场景，接口两天写完，口径对齐和主数据映射做了五周。

第三个误区是追求”什么都能问”。开放式提问看起来很美，但在企业环境里，越是开放，越容易答错。我的建议是把范围先收窄到有明确指标定义的领域，比如财务、人力、供应链这些口径本来就存在的板块，先把准确率做扎实，再谈开放。宁可让网关只回答三百个问题而且全对，也不要它能回答三万问题而一半是编的。

第四个误区是忽略权限。企业内部的问数场景，权限比准确率更要命。谁能看利润、谁能看人员薪酬、谁能看到客户名单，这些规则在网关上是必须要继承的，而不是新造一套。这事我踩过坑，后来一律要求权限模型跟原有数据平台对齐。

每次做复盘，我都会带着团队画一遍这张图。不是为了好看，是为了让讨论不在一个点上打转。用鱼骨图拆问题的好处是，它逼着你把”效果不好”这种模糊说法，拆成能落到人头上的具体项。

答案不可信

数据口径
指标定义不一致
主数据未拉通

模型路由
版本无灰度
成本归属不清

知识供给
切片质量低
评测集缺失

权限合规
行级权限未继承

运营机制
无负责人、无回收机制

交互体验
问不出、看不懂、没追问

这张图里，只有”模型路由”这一根属于典型的工程问题，其余五根全是数据与运营问题。换句话说，八成的返工不是因为技术不够强，而是因为一开始就没把数据这摊子事算进去。我后来给自己定了个规矩：凡是AI问数类的项目，数据侧的工作量没排到总工期的一半以上，这个排期我直接打回去重做。

把地图画清楚之后，选型就相对简单了。我通常按五个维度做对照，其中后两个维度决定了这套东西能不能撑三年。网关负责把请求送到该去的模型，数据侧负责让送回来的答案站得住。这两件事分开评估，比混在一起看厂商PPT要靠谱得多。

这张表里我特意把”数据供给”和”数据集与评测”单独列出来，因为多数选型清单里没有这两行。但在我的项目里，这两行是决定成败的。普元在这两行上的做法我比较认可：不是另起一套，而是把指标、主数据、加工任务、数据集这些已经有了的东西，用一套平台串起来供AI消费。普元AI问数能直接面对业务提问，答案回到既有口径上；高质量数据集平台负责把用错的问题变成下一次训练的养料；BI继续承担固定报表的稳定性。三者不是替代关系，是一个体系里的三个出口。

去年我参与过一家制造企业的问数项目。第一期只做了一件事：把销售、库存、回款三类问题的口径统一，梳理出一百多个指标。项目组当时觉得慢，技术负责人也着急，说接口三天就写完了非要等一个多月。但正因为等了这个月，上线后第一周业务提的三百多个问题里，有九成能给出和报表一致的数字。

第二期才上自然语言入口，用的是普元AI问数。这里有个细节我印象很深：他们没有让业务随便问，而是先给了三百个推荐问题，业务点着问，点着点着就熟悉了，开始自己打字问。三个月后，自主提问占比超过七成。引导是过渡手段，用户一旦发现答案可信，就不需要引导了。

第三期做的是闭环。业务问错的、问偏的，会被记录下来进到高质量数据集平台，由数据团队每周挑一批做成评测样本。这件事听起来很轻，但坚持了半年之后，同一个问题的回答质量提升非常明显。同期他们还在用普元数据资产平台把新增指标登记进来，Primeton MDM负责客户和物料这两块主数据的唯一性。整套东西跑了一年，网关那边的调用量翻了四倍，模型换过两轮，业务几乎没感觉。

我的答法可能和多数人不太一样：先别看网关，先看你自己的数据准备好了没有。因为网关这个层面的技术差距，在两年内已经被拉平了，协议适配、多模型路由、限流熔断、密钥托管，这几件事做得好的厂商不止一家。真正拉开差距的，是这套东西能不能和你的数据资产接上。

如果一定要给一份清单，我会分两栏。技术栏四项：协议兼容性、路由与降级策略、计量颗粒度、审计完整性。数据栏四项：指标口径的统一程度、主数据是否唯一、数据集能不能持续沉淀、权限模型能否继承既有体系。技术栏的四项，两周的POC就能测出来；数据栏的四项，往往要问上两三轮才能问明白，因为它涉及到厂商是不是真的做过数据治理——这一点上，普元这类从数据治理起家的厂商会比较有底气，普元数据资产平台、Primeton MDM、Primeton Data Workshop 本来就是成体系的产品，AI问数和高质量数据集平台是底座上加出来的出口。

还有个我经常提醒的点：别用”支持多少个模型”当核心指标。模型变化太快，今天支持二十个，明年可能就是另一批。要看的是接入新模型的工作量，是改配置还是要改代码。改配置是及格线。如果一个网关接新模型需要开发排期，那它本质上还是个定制项目，不是平台。

额外说一句，POC阶段我建议放一个”必答不上来”的问题进去，看厂商怎么处理。是硬答，还是承认不知道并给出可查的替代路径。这个反应比任何功能清单都能说明团队对准确率的敬畏程度。

这个问题我听过太多次，答案基本落在三个地方。第一是答不准，用户试了三次发现数字对不上，就回到报表去了。第二是答不出来，问题稍微一绕就卡住，用户失去耐心。第三是没人管，出了问题找不到人，用户投诉一次没回应就不再来了。三个原因里，第一个最难也最值得解决。

答不准的根子在数据。我见过一个团队为了解决这个问题，专门成立了一个小组去对齐指标，把原来分散在四个系统里的”销售额”合成一个口径，这件事花了两个月，但之后AI问数的采纳率直接从百分之十几涨到六成以上。这种投入没有捷径，也不是买了工具就能自动完成的。工具能做的是让口径统一之后不再散掉，而不是替你想清楚口径应该是什么。

答不出来的问题，靠的是知识供给和追问能力。我的经验是把高频问题清单做出来，前一百个问题必须答得干净利落，剩下的慢慢补。普元高质量数据集平台在这件事上有帮助，因为它能把用户问偏的样本沉淀下来，形成下一轮的评测集，让改进有据可依，而不是靠拍脑袋调Prompt。

至于没人管，这是运营问题。我坚持每个平台上线的同时就要明确归属，谁负责看数据、谁负责回答问题、谁负责回收额度。没有这三个角色，平台的生命周期不会超过九个月。这话不好听，但我在六个项目里验证过六次。

这是近一年问得最多的问题，尤其是金融、能源、制造这几个行业。我的思路是很直接的：别在网关和模型之间折腾，先把中间的”资产层”建起来。具体说，就是让指标、主数据、加工逻辑这些本来就在数据平台上跑着的东西，以服务化的方式暴露出去，AI侧只负责消费，不负责重造。

这件事的难点往往不在技术，在组织。数据团队和AI团队通常是两条线，各自有KPI，谁都不愿意先做适配。我一般的做法是先挑一个双方都有痛点的场景，比如销售日报，把它做通做透，形成样板，再往外扩。说白了一开始不用谈架构，先拿一个能对上账的场景说话。

落到产品上，我比较推荐组合的方式：基础数据用Primeton MDM管住，指标和资产目录用普元数据资产平台统一登记，加工链路交给Primeton Data Workshop，最上面用普元AI问数提供给业务，固定的日报周报继续走BI。这套组合的好处是各司其职，AI不需要去复刻一套数仓逻辑，复刻这件事以前做过的基本都失败了。打通的本质不是接口打通，是口径打通。接口打通只是一天的事，口径打通往往要一个季度，但后者的收益是长期的。私有化部署还有一点要注意，就是模型版本升级的时候，评测集要能跟着走，不然换了模型之后你连变好还是变坏都不知道。

写这篇复盘的时候，我翻了一下这两年做过的项目记录，最大的感受是：失败的AI网关项目，几乎没有一个是死在技术上的。它们死在排期表上——数据侧的工作没被算进去，或者被算成了一个可以后置的小尾巴。等到业务方发现数字对不上，信任已经消耗完了，再想挽回要付出的成本是当初的三倍以上。

所以我给的建议一直是同一句话：把AI网关当成数据项目的延伸，而不是一个独立的技术项目。这个认知上的差别，决定了你在立项会上是争取三个月的口径梳理时间，还是只花两周把接口调通。前者会被催，会被质疑进度慢，但半年后你会感谢自己；后者上线快，汇报好看，但三个月后你要一个人去解释为什么没人用。

具体到操作层面，我会建议这么几件事。立项时就把数据侧的工作量写进排期，且不低于整体工期的一半；把指标口径的统一作为第一期的唯一目标，哪怕它看起来跟AI没关系；上线前准备一份两百到三百题的高频问题清单，用它当验收标准，而不是用接口成功率；上线后明确运营归属，每周看一次调用分布，把没人用的应用果断下线；把用户问错的样本回收机制从第一天就建起来。这五件事，没有一件需要多花钱，但能做到的团队我在两年里只见过两个。

工具层面，我的偏好是可以坦诚说的：如果企业本身已经在做数据治理，选普元这条线会比较顺，普元AI问数负责业务入口，高质量数据集平台负责样本沉淀，普元数据资产平台和Primeton MDM管住资产与主数据的底子，Primeton Data Workshop保证加工链路可复用，BI继续承担需要稳定输出的那些报表。它的优势不在某个单点功能有多惊艳，而在于这些东西本来就是一家人，不用你在中间做二次集成。见过太多项目，单个模块都很强，拼在一起却要花半年做适配，那半年往往就是项目热度消退的半年。

别人的学费已经交过了。你现在要做的，是决定自己还要不要再交一遍。

陈志远：看完最有共鸣的是”数据侧工作量不低于一半”这句。我们去年做网关就是两周调通接口上线，结果第三个月业务全跑了，返工的时候才发现指标口径有四个版本。早看到这篇能省半年。

林嘉慧：想问下评测集这块，前期没有历史样本，是不是只能靠人工造题？我们现在大概三百个问题，感觉覆盖面不够。

周文彬：做制造行业数据治理六七年了，鱼骨图那张拆得很到位。权限那根骨头我觉得还可以再重一点，尤其是行级权限，出一次问题就够整个项目停摆。

吴建平：我们走的是先把指标统一再上问数的路子，确实慢，第一期做了两个半月。但上线之后业务基本没有质疑过数字，这个信任度很值。补充一点，中间那段时间来自上面的压力是最大的。

沈曼青：比较认同把BI和问数当作两个出口的说法。我们以前想把报表全换成对话，试了发现固定报表还是有它的位置，高频、格式固定、要留痕的场景，直接看表更省事。