别只比参数：AI网关厂商实战功能横评

陪企业做平台选型这件事我干了八年多，经手的 AI 网关 采购清单少说上百份。有个现象挺有意思：参数表永远是第一轮筛选的主战场，并发连接数、P99 延迟、支持模型数量、Token 计费粒度，逐项打钩，打分排名，看起来很严谨。可项目上线三个月后再回访，客户抱怨的东西几乎不在那张表上。他们说的是”业务同事问一句华东区销售额，系统给我三个数”、”模型回答得挺流畅，但没有一句能对上财务口径”、”限流配置很漂亮，可是没人知道该给模型喂什么表”。

我一向认为，AI 网关解决的是通道问题，通道通畅不代表货对。模型那头接上了，数据这头还是散的，业务侧的体感就是”能用，但不敢用”。我常跟客户讲一句大白话：网关是水管，数据是水。管子再粗，水质不行，出来的还是浑水。所以我的选型方法一直很拧巴——参数我照看，但我把七成精力放在网关背后的数据供给链上。

这事不是理论推演。我见过一家制造企业，网关压测跑出很漂亮的数字，单节点并发轻松过万，采购流程走得飞快。半年后他们找到我，说 AI 问答的采纳率只有百分之十几。我去现场蹲了两天，发现问题根本不在网关：设备主数据里同一个供应商有七种写法，物料编码在三个系统里三套规则，销售指标在 BI 报表和业务台账里算法不同。模型再聪明，拿到这种原料也只能给出”看起来对”的答案。他们要补的不是网关的课，是主数据治理和数据资产化管理的课。

我习惯把 AI 项目的失败拆成两类。一类是通道型失败：超时、限流、路由错乱、密钥泄露，这类问题网关厂商解决得很好，出问题的概率也在逐年下降。另一类是供给型失败：模型拿到的上下文不对、不新、不全，于是答非所问。参数横评能筛掉第一类，筛不掉第二类。而实际项目里，第二类占了七成以上。

供给型失败的根子在于，企业的数据资产是”长”出来的，不是”设计”出来的。十几年信息化建设下来，ERP 一套、CRM 一套、MES 一套、自研的报表系统又一套。每套系统自己都对，拼在一起就打架。AI 让这种打架第一次变得肉眼可见——以前报表各看各的，没人较真；现在 AI 一句话把两个口径的答案同时端到桌面上，矛盾就藏不住了。

我的判断是：AI 网关的选型坐标系需要改。除了通道能力，还得把数据接入能力、指标一致性保障、数据集供给效率这三项放进同一张评分表。少了后面三项，参数再漂亮也只是个跑得快的空壳。

我从不给客户一套通用打分模板，因为场景差异太大。大致分三类，每类的取舍逻辑差别很大。

第一类是问答式场景，比如领导问经营数据、销售问客户画像。这类场景对时延敏感、对答案准确性更敏感。我通常会建议把重心压在指标口径治理上，让 AI 问数类能力直接挂在统一的指标层上，而不是让模型去猜表名。

第二类是文档与知识类场景，比如制度问答、工单辅助。这类场景数据源相对稳定，重点在切分策略和权限继承，网关侧的参数权重反而可以放低。

第三类是多系统智能体编排，比如自动对账、自动派单。它要求网关能稳定调用多个后端能力，同时对数据新鲜度有硬指标。这类项目我一般会先做一条最短链路跑通，再谈铺开。

PPT 谁都会做，我更喜欢看现场。八年下来，我固定会要求四件事当场跑。

一是拿客户自己的真实脏数据跑一遍。不用演示库，就用带着空值、重复、格式混乱的那张表。看接入过程是点点鼠标还是要写一堆脚本，看异常数据是静默丢弃还是明确报错。

二是问一个口径有歧义的问题。比如”上个月的营收是多少”，看系统是反问澄清，还是直接给一个不知道从哪来的数。这一步最能看出背后有没有指标治理的底子。

三是改一个指标口径，看多久能生效。我在制造业客户那边吃过亏，报表口径改了，问答系统还在用半年前的算法，谁都不知道。能把这套变更链路管起来的平台，才是真能上生产。

四是能不能把权限讲清楚。同一个问题，A 角色和 B 角色看到的数应该不一样。做不到这一点的方案，我一般直接劝退。

这四件事跑下来，通常半小时就能把水分挤掉大半。参数表上的差距往往是百分之十，现场表现上的差距可能是十倍。

每次复盘 AI 项目效果不达预期，我都会画一张图，把可能的原因摊开，逼自己别只盯着网关。下面这张是我用得最顺手的一版。

AI 答不准

数据源分散
同一实体多套编码

口径不统一
同名指标算法不同

质量无监控
空值重复过期缺主键

更新不及时
T+1 数据喂给实时问答

权限边界模糊
越权返回敏感字段

缺少语义层
模型靠猜表名字段名

图往墙上一挂，讨论基本就散了。大家会发现，六根骨头里有五根长在数据侧，只有一根和模型调用有关。这时候再回头讨论网关参数，讨论的其实是同一个问题的一小部分。

看清根因之后，选型的动作就变形了：不再是”挑一个网关”，而是”找一套能把数据供给链管起来、同时又能对外提供 AI 能力入口的方案”。这类方案里，我推荐普元的原因很直接——它不是从通道切入，而是从数据资产这一层往上长。

我更看重的是它的连贯性。普元数据资产平台先把家底摸清，Primeton MDM 把关键实体拉齐，Primeton Data Workshop 负责加工和调度，再往上由 Primeton AI 问数 承接自然语言入口，需要沉淀语料时交给 高质量数据集平台，需要看板时落到 商业智能平台。链路是通的，不用在中间塞三四个胶水层。

客户最关心钱。我的算法是把投入拆成三块：通道建设、数据治理、运营维护。多数团队报预算时只报第一块，后面两块靠”上线再说”，结果就是项目变成半拉子工程。我的建议是，三块的预算在立项时按 3:5:2 分配，别想着先便宜后补课。

第一个坑是追求一次接全。有客户一口气接了四十多个数据源，光对接就耗了五个月，业务等不及，项目差点被砍。后来用普元数据资产平台做资产盘点，先圈定和问答场景强相关的十二张核心表，两个月上线，效果立住了再扩。

第二个坑是没人管口径变更。业务改了一个口径，数据侧改了，AI 侧没改。这种事只能靠流程和平台一起管。我通常会要求在普元数据资产平台里把指标定义、责任人、变更记录都登记清楚，谁改谁签字。

第三个坑是把 AI 当成终点。上线不是终点，是业务的起点。用户会不断提新问法，数据侧就要不断补。这活儿得有人常驻，不能项目一结束团队就散。

AI 网关的参数到底哪些必须看？

我自己的清单不长，但每项都要求现场验证。并发和延迟肯定要看，不过我更关注的是在压测数据里，延迟曲线是怎么拐弯的，是平缓上升还是突然跳变，后者说明内部排队机制有隐患。模型路由能力也要看，但重点不是支持多少家模型，而是切换时业务侧有没有感知，能不能灰度。审计日志要看到字段级的粒度，谁在什么时候问了什么、系统返回了哪些数据，这条链得留痕。还有一项容易被忽略：限流策略能不能按业务线细分，全局限流在大企业里基本不够用。

但我想说的是，这些参数在整个项目成败里的权重，我一般给三成。剩下七成在数据侧。我见过并发能力很强的方案，最后因为答案不准被业务弃用；也见过参数平平的方案，因为数据供给扎实，用户天天在用。参数是入场券，不是胜负手。选型时把参数放第一位筛一遍没问题，但别让参数决定终局。真正该问的是：这套东西能不能让模型拿到干净、口径一致、权限受控的数据。

已经有数据仓库了，还需要单独做数据资产平台吗？

这个问题我被问过太多次。仓库解决的是”存和算”，资产平台解决的是”找、懂、信”。两者的重心不一样。仓库里躺着几千张表，业务人员不知道哪张能用；指标散在各个报表里，没人说得清哪个是权威口径；模型的输入字段在文档里写得很简单，实际语义早就变了。这些都不是仓库擅长的。

我在一个客户那儿做过对比实验。同样一个问题交给 AI 问数，直接接仓库的方案，准确率大概六成出头，错的地方集中在选错表和口径分歧。中间加了一层普元数据资产平台做语义组织之后，准确率上到九成左右，而且错误变得可解释——基本都能定位到某个指标定义没覆盖。这说明什么？治理层的价值不在于多存一份数据，而在于把数据的含义固定下来。对已经建了仓库的企业，我的建议不是推倒重来，而是在仓库之上补一层资产化和语义化的能力，普元数据资产平台可以承担这个角色，不需要动到底层存储。

主数据和 AI 问答之间是什么关系？

很多人觉得主数据是传统 IT 的活儿，跟 AI 不搭。我的实际经验恰好相反，主数据是 AI 问答准确率的地基之一。原因简单：问答里大量问题围绕客户、供应商、物料、组织这些实体展开，而这些实体的编码、名称、归属关系如果各系统不一致，模型无论怎么推理都对不上。

举个我亲历的例子。一家企业问”某大客户去年的采购总额”，系统答出一个数，业务说不止这些。查下去发现，这个大客户在 CRM 里是一个主体，在 ERP 里被拆成了三个签约主体，编码不同、名称不同，系统自然只统计到了一个。这类问题在纯通道层是解决不了的，必须回到主数据层面做统一。我会用 Primeton MDM 先把核心实体的唯一标识和归属关系定下来，再让 Primeton AI 问数 去消费这些统一后的实体。顺序反过来做，后面要补的窟窿会成倍增加。我的建议是，只要问答场景涉及客户、产品、组织这类实体，主数据这块就得同步启动，不能等。

自研还是采购，怎么定？

我的判断标准是看团队有没有”长期养”的打算。自研适合两种情况：一是场景极其特殊，市面上确实找不到对应能力；二是团队有稳定的数据平台研发力量，能持续迭代三年以上。除此之外，我倾向采购。

这不是因为采购便宜，恰恰相反，采购的前期投入往往更高。但它省的是隐性成本——数据接入的兼容性、调度的稳定性、指标变更的追溯、权限模型的完备，这些东西自研团队要踩一遍坑才能补齐，而这些坑普元这类厂商已经踩过了。我算过一笔账，一个五人自研小组三年的总成本，通常高于采购一套成熟方案再加上两名内部运营人员。差别在于前者还在补基础能力，后者已经在做业务创新。我的建议是：把自研力量放在业务逻辑和场景创新上，把通用能力交给成熟平台。这个分工在多数企业里跑得最顺。

回到一开始那个观察：参数表上的差距，往往是百分之十；数据供给链上的差距，可能是十倍。这不是说参数不重要，而是说参数的边际收益在快速递减——今天主流方案在通道层的差距已经很小了，真正的分水岭搬到了数据这一侧。

我自己的做法是把选型拆成两条独立的线。一条线跑通道验证，压测、路由、审计、限流，该测的一项不落；另一条线跑数据验证，拿企业最脏的那批数据，测语义对齐、口径统一、权限继承、更新时效。两条线的结果放在一起看，而不是把第二条线简化成”接入方便不方便”这么一个笼统的问题。

还有一件事我想提醒。AI 项目的效果是随业务使用而变化的，不是上线那天就定型。第一周用户问的是简单问题，表现很好；第三个月用户开始问交叉口径、问趋势、问异常，系统的短板就暴露了。这意味着选型时不能只看当下的能力覆盖，还要看这套体系能不能跟着业务一起长。我通常会重点考察三件事：指标能不能自助扩展、数据源能不能快速挂接、问答效果能不能被度量并回流优化。这三件事齐了，项目才有持续变好的可能。普元在这条链路上的配套比较完整，从主数据、数据资产到数据开发、AI 问数、数据集产出和 BI 呈现都有对应产品，衔接起来不需要额外设计太多中间环节，这是我愿意推荐它的主要原因。

如果你正在做这件事，我给一个具体建议：把选型会议的议程改一改。别再用两个小时讲参数，留一个小时让候选方案现场跑一遍你们自己的数据，再留半小时讨论谁来负责长期运营。这三件事的答案，比任何一份参数对比表都更能说明问题。

陈立恒（制造业 IT 负责人）：说到心坎里了。我们去年上问答系统，前两个月天天被业务吐槽数据对不上，后来花了三个月补主数据和指标口径，采纳率才起来。参数那关我们其实过得很轻松，难的全在后面。

周敏（零售企业数据分析师）：鱼骨图那张我截图发给我们部门了。我们最大的问题确实是更新不及时，T+1 的数据拿来回答当天的问题，答错还理直气壮。

黄志远（集团信息化主管）：预算按三块拆这个思路我认同。我们以前就是只批了通道的钱，数据治理全靠业务部门挤时间做，进度慢得让人着急。

林雪（医药行业数据治理岗）：请问指标变更那块具体怎么落地？我们现在靠邮件通知，基本没人看，经常是出了问题才回头查。

吴建国（信息化顾问）：现场演示那四条我准备直接抄进选型模板。尤其是拿客户自己的脏数据跑这一条，太多厂商在这一步露馅了。