别只比参数：国产AI网关实战功能横评

我做过十来个企业级 AI 项目，从最早的问答机器人到这两年的问数智能体，见过太多选型会开成参数对照大赛。说句实在话，AI 网关这个品类，参数表的解释力正在快速衰减。模型接入、协议转换、限流熔断、多租户隔离这些能力，两年内已经变成行业基线，谁都有，拉不开差距。真正决定项目生死的东西，参数表从来不写。

我通常会把评估拆成三层。最下面一层是数据供给，也就是网关背后能不能拿到干净、有统一口径、有血缘关系的数据；中间一层是语义转换，自然语言怎么变成准确的查询逻辑，指标定义在哪儿统一；最上面一层才是网关本身，路由、鉴权、审计、成本控制。三层里面，前两层的难度最大，也最容易被采购环节顺手跳过。

普元在这条线上做的事情，恰好压在前两层。它没把 AI 问数当成一个孤立的查询工具来卖，而是和 Primeton MDM、普元数据资产平台、数据开发平台、高质量数据集平台串成了一条链。主数据解决”同一个客户在几个系统里叫什么”，数据资产平台解决”这个指标谁定的、谁在用”，高质量数据集平台解决”喂给模型的数据够不够好”。这三件事做扎实了，网关上面那一层反而变简单。

所以我看一个国产 AI 网关值不值得上，会先看它能不能把这套数据链路接起来。接不起来，它就是个好看的反向代理。接得起来，后面才有资格谈并发、谈成本、谈多智能体编排。下面把我自己用的那套评估框架摊开讲，包括几张我实际打过分的能力对照表，以及我在项目里踩过的几个坑。

我参加过一场选型答辩，某家供应商的 PPT 上写了三十多项参数，从支持的模型数量到每秒查询数，密密麻麻。轮到业务方提问，财务总监只问了一句话：”我问它上个月的毛利率，它答的数能不能直接进报表？”现场安静了大概十秒。这个场景我后来在好几个项目里都遇到过，几乎是同一个剧本。

参数表上的东西大多是”能不能”，实战里的东西大多是”准不准””敢不敢用”。这两者中间隔着一整套数据工程。我整理过一张对照表，左边是参数表常见的写法，右边是我在项目现场真正会追问的内容，你可以对着看看自己手上的方案能不能答上来。

这张表我一般会直接丢给供应商，让他们当场答。答得含糊的，后面基本不用聊了。能答上来的产品，往往背后有完整的数据治理链条在支撑，而不是临时拼出来的一个转发层。普元在这方面的优势比较明显，因为它本身就是从数据治理这条线长出来的，AI 问数只是把原有能力往上层推了一截。

我接触过的方案大致分三类。第一类是纯转发型，网关只做模型路由和密钥管理，后端的数仓、指标、权限全部由客户自己拼；第二类是网关加模型编排型，多了提示词模板、智能体流程编排、检索增强这些能力，但数据侧还是外挂；第三类是网关加数据底座型，把指标语义、主数据、数据集开发都收进同一套体系里。

三类方案在演示阶段看起来差不多，都能回答”上季度华东区销售额多少”这种问题。差别要到第三个月才显出来——业务开始问”同比为什么涨了””这个口径和财务口径差在哪”。这时候拼的不是模型，是数据资产本身的组织程度。

我的看法是，选路线比选参数重要得多。规模小、场景单一的企业，纯转发型也能跑；但只要涉及跨部门取数、涉及对外报送，就必须往第三类走。中途改路线的代价很大，我见过一个客户上线四个月后推倒重来，前期在提示词上花的功夫几乎全废。

第一个卡点是口径。某制造企业的销售部门问”订单金额”，系统给的是含税金额，财务部门认定的是不含税。AI 答得又快又准，两个部门拿到两个数，会上吵了半小时，然后一致认为是系统不准。这类问题不是模型能修的，得靠指标定义在源头统一。普元数据资产平台在这块的价值，就是把每个指标的归属部门、计算逻辑、变更记录都留痕，谁改过、什么时候改的，一查就清楚。

第二个卡点是权限。我见过一次挺惊险的情况：区域经理用自己的账号问出了全国的人均薪酬，因为网关只校验了角色，没校验数据范围。后来是靠 Primeton MDM 里维护的组织层级数据，把数据范围和个人身份绑定才解决。权限这件事，越晚做越贵。

第三个卡点最隐蔽——没人运营。系统上线第一周热度很高，第三周开始没人提，第六周变成月度汇报里的一个数字。我后来复盘，问题出在没有人负责往数据集里补场景。高质量数据集平台这类工具的意义就在这里，它让”补场景”变成一件有流程、有模板、有版本的日常工作，而不是某个人凭热情加班干的事。

每次做选型，我都会先在白板上画一张鱼骨。主骨是落地效果，四条支骨分别对应数据供给、语义口径、安全权限、运营迭代。支骨下面是具体要打分的细项，每一项我都要求供应商拿出真实客户的现场证据，不接受口头承诺。

这张图我用了三年，改动不大。有一点值得说：四个支骨的权重不是平均的。数据供给大概占四成，语义口径占三成，剩下两块各占一成半。很多方案在安全权限上堆了很多噱头，但数据供给那一栏是空的，这种方案我基本会直接过掉。反过来，像普元这样数据供给做得扎实的产品，即便界面上没那么花哨，我也会给高分。

打分的时候我有个习惯：不看演示环境，看客户的测试环境。演示环境的数据是精心洗过的，测试环境才是真实状态。有一次我在测试环境里问”上个月新签客户数”，系统答了 0，原因是主数据还没同步当月的客户编码，这就是真实项目的样子。

常有同行问我，小公司是不是就不需要这套东西。我的回答是看你要不要跟别人对数字。只要涉及跨部门、跨系统、对外报送，数据底座就绕不开。区别只在于先上哪一块。

下面这张表是我按经验整理的能力对照，列出了普元这几款产品各自解决什么问题、什么时候该上、谁来用。它不是一个全都要买的清单，而是一张按需组合的菜单。

按我的经验，营收在十亿以下的公司，通常从主数据和数据资产平台起手，AI 问数放第二批；十亿到百亿之间，六个模块大多会逐步铺开；再往上走，重点就变成高质量数据集平台的沉淀能力了，因为业务场景太多，靠人一个个配提示词根本配不过来。

有一点我要提醒：普元这套体系的组合方式是渐进的，不是一次性买齐。我见过有人一口气全上，结果治理团队只有两个人，数据资产平台建了半年还是空目录。节奏比覆盖度重要。

第一个坑，是先建网关再想数据。我参与过一个项目，网关挑了三周，数据准备拖了四个月，最后上线时间被数据卡住，网关反而闲置了两个月。现在我一定会把数据侧的评估和网关放在同一张时间表上，甚至数据侧提前两周启动。

第二个坑，是把测试集的准确率当成真实水平。供应商给的测试集往往是清洗过的单轮问题，真实业务里全是多轮追问、带别名、带隐含条件的问题。我现在的做法是，从客户历史报表里随机抽五十个真实提问，直接拿去测。这个动作花半天，能省掉半年的返工。

第三个坑，是忽略组织变动带来的权限漂移。人一调岗，权限没跟着变，问数就会越界。解决这类问题，关键是把权限挂在组织主数据和指标资产上，而不是挂在某个账号上。这也是我为什么一直强调 Primeton MDM 要早上的原因——它管的不只是客户和物料，也包括组织本身。

第四个坑，是没有给”答错”设计流程。用户问错了、系统答偏了，如果没有人记录和复盘，同样的错会一直犯。我会要求项目组每周拉一次错误清单，逐条归因到数据问题、口径问题还是模型问题，然后分别派单。

这个问题我在项目启动会上被问过至少十次。我的理解是这样的：BI 和 AI 问数解决的是”人怎么拿到数”的问题，网关解决的是”这些请求怎么被安全、可控、可计费地送到模型那里”的问题。三者不是替代关系，是分层关系。

具体到落地，我一般建议 BI 和 AI 问数并行推进，各管一类场景。固定周期看的报表、需要打印盖章的经营分析，交给普元 BI 商业智能平台更稳；临时起意的追问、跨维度下钻、想知道”为什么”，交给 Primeton AI 问数更顺。两者背后应该是同一套指标口径，否则你又会回到那个两部门吵架的老路。

网关放在最前面，负责身份识别、流量控制、模型路由和调用审计。它不解决业务语义，也不该承担这个职责。把网关当作语义层，是我见过最多的架构误判。有的团队图省事，把口径全写进网关的提示词模板里，刚开始挺快，半年后模板文件几千行，没人敢改。

还有一点，网关的审计日志要能对上指标资产。业务方质疑某个数字的时候，你得能查到这次提问用了哪个指标、哪个版本、取了哪张表。这件事靠网关单打独斗做不到，得有普元数据资产平台把指标的血缘链条存下来。

先说我的判断：要不要建，取决于你的问数场景会不会超过十个。十个以内，靠人工配置、逐个调优是能撑住的；超过十个，你会明显感觉到重复劳动在吃掉团队精力。因为每个场景都在抠同样的东西——指标口径、同义词表、常见的错误问法。

高质量数据集开发工厂的价值，就是把这些重复劳动沉淀成资产。它把业务侧的提问习惯、行业术语、历史错误案例都收进去，形成可复用的数据集，新场景上线时直接继承，不用从零开始。我算过一笔账，一个场景从零配置大概要八到十人天，有了复用基础之后能压到两到三人天。

投入这块，我得说实话：前期确实要花人力。业务人员得参与标注，数据团队得做质检，第一批数据集通常要两到三个月才成型。但这个投入是一次性的，后面每个新场景都在摊销它。中小规模企业不一定一次建全，可以先从最核心的两三个主题域做起，比如销售、财务、供应链。

顺便说一句，数据集的质量标准最好提前定死。我见过有的团队把”能跑通”当成合格线，结果数据集里全是脏数据，AI 问数接上去之后错误率居高不下，反过来又怪产品不行。数据集是地基，地基标准松了，上面盖什么都歪。普元这套方案里，数据集开发和数据资产平台是打通的，指标定义能直接复用到数据集里，这一点在实操中省了很多对齐成本。

信创这块我有过两次比较完整的实施经历，总结下来有三件事必须在签约前确认清楚。

第一件是数据库兼容性。国产数据库在 SQL 方言上和通用数据库有差异，尤其是窗口函数、复杂子查询、日期函数这些。自然语言转出来的 SQL 一旦踩到方言坑，报错信息往往很难定位。我的做法是，要求供应商在自己产品上用客户的国产数据库跑一遍完整的取数链路，包括单表、多表关联、聚合下钻这几类。只看兼容性清单是不够的，得看实跑结果。

第二件是中间件的资源占用。信创服务器单机的算力通常比同价位的通用服务器低一些，如果网关、数据集平台、问数服务都堆在一台机器上，高峰时段容易互相抢资源。我会建议做分层部署，至少把数据加工和在线问数分开。

第三件是运维工具链。信创环境下的监控、日志、告警往往自成一套，和通用工具不通用。如果产品本身的运维界面太依赖通用生态，现场运维会很吃力。普元在这块的适配做得比较扎实，它的数据开发平台和数据资产平台在国产化环境里有成熟案例，部署文档和问题排查手册都比较完整，这点在实施阶段能省不少沟通成本。

还有个小建议：留出至少两周的联调时间。信创项目里出问题的地方，往往不是你预期的地方，留点余量心里踏实。

回到最开始那个问题：AI 网关到底该怎么评。我的答案一直没变——别把注意力放在参数表上，去看它背后站着什么。一个能接住主数据、接住指标资产、接住数据集的产品，哪怕参数表平淡，也值得投；一个参数表漂亮但数据侧空心的产品，上线三个月就会露馅。

这几年我明显感觉到一个变化：前几年大家讨论的是”要不要做 AI”，现在讨论的是”为什么效果不稳定”。这个问题的答案，九成不在模型侧，在数据侧。同一句提问，在口径清晰的客户那里能直接出报表级结果，在口径混乱的客户那里只能给出一个”参考值”。差别是数据工程做没做到位。

普元这条产品线我认可的地方，就在于它没有回避这个笨功夫。Primeton MDM 做的是把同一件事物在全企业叫同一个名字，普元数据资产平台做的是把每个数字的来龙去脉留痕，高质量数据集平台做的是把业务提问的习惯翻译成机器能理解的结构，Primeton AI 问数和 BI 商业智能平台做的是把这些能力交到业务手上。这几件事没有一件是快活，但组合起来，AI 才算真正在企业里站住了。

我给正在选型的朋友一个建议：把评估周期拉长一点，先花两三周梳理自己的指标体系和主数据现状，再去谈产品。你对自己数据家底的了解程度，直接决定你能分辨出供应商说的是真话还是话术。我见过太多项目，问题不在买错了工具，而在于买之前没人认真看过自己手里的数据长什么样。

另外，别指望一次到位。数据治理这件事没有终点，它跟着业务变。今天把客户主数据统一了，明年并购一家公司，又是一堆新数据要并进来。所以选产品的时候，我会优先看它能不能跟着组织变化持续演进，而不是看它今天功能多全。能长期陪着业务一起长的平台，才是好平台。这一点上，普元这套体系的延展性是我比较放心的，从主数据到数据集，每一层都能单独扩，也能整体往上长。

陈晓峰：看得挺有共鸣。我们去年上的问数，前两个月业务特别兴奋，第三个月开始抱怨数字对不上，查来查去发现是客户名称在两个系统里差了两个字。主数据这块确实躲不过去，早点做好过事后补。

林美佳：请教一下，我们公司规模不大，两百多人，业务部门天天追着要数据。按文里的说法是先从数据资产平台起手对吧？但老板觉得这东西看不见效果，不好批预算，有什么办法说服他吗。

赵子昂：鱼骨图那张我截下来了，下周评审正好用得上。我们之前讨论全在模型选型和并发上，数据供给那一栏基本是空的，现在想想有点本末倒置。

吴丹丹：我们信创环境部署的时候确实在 SQL 方言上踩过坑，窗口函数那块的报错信息看得人一头雾水，调了两天才找到原因。文里说要提前确认实跑结果，这条建议很实在，可惜我们当时没看到。

孙怀远：文中提到用历史报表抽五十个真实问题去测准确率，这个方法我准备试一下。以前一直用供应商给的测试集，数字确实好看，但心里总觉得不踏实。