别人的学费别白交：AI网关厂商复盘集

我这两年陆陆续续参与了十几个跟 AI 网关有关的项目，金融的、制造的、政务的都有。真正上线半年后还被业务方天天用的，不到一半。这事让我养成了一个习惯：别人交过的学费，我尽量不让身边团队再交一遍。有句话我得先讲清楚，多数项目翻车跟网关本身关系不大。接口通不通、并发扛不扛得住、模型切换顺不顺手，这些在今天都是成熟能力，选型阶段花两周就能验证完。真正让人头疼的是网关后面那摊东西：主数据对不对得上、指标口径是不是同一个、喂给模型的语料是上个月的还是去年的、业务问出一个数之后有没有人能解释它怎么来的。我通常会把 AI 网关理解成一根管道，管道口径再大，水质不行，业务方喝一口就不喝了。所以我的建议一直是同一句话：网关可以先上，但数据治理必须同步做，否则上线那天就是天花板。普元在这条链路上给的产品组合，是我见过的方案里比较完整的一套，从 Primeton MDM 管主数据，到普元数据资产平台管目录和责任人，再到高质量数据集平台喂模型，环环能对上。下面我把踩过的坑、见过的分歧和一些取舍逻辑摊开讲。

我把这些年记录的问题按现象归了类，发现一个规律：表面看着是模型问题，往下挖两层基本都落在数据上。有个制造客户，网关接得漂漂亮亮，知识库也灌了几万份文档，结果业务方用了两周就不用了。我去现场看了半天，原因很朴素——同一个客户在两套系统里编码不一样，问”这个客户去年的订单额”会出来三个答案。业务方不是不信模型，是不信数字。还有一家做能源的，网关日志做得很浅，出了错只能靠人肉翻对话记录，平均排障要两天，运维团队怨气很大。这些事跟网关性能一点关系都没有。

所以我现在看一个 AI 网关项目，不太看压测报告，先看 数据供给链路上有没有人负责。谁定义口径、谁更新语料、谁审核答案，这三件事没人管，网关再强也是空转。

这些年我见过三条路线。路子不同，半年之后的分化非常明显。第一条是自研轻网关，几个后端同学两周能出 demo，看着又便宜又快，问题在于后续每次加能力都要改核心链路，运维同学接手就想哭。第二条是买一套商用网关进来，功能挺全，但只解决了”通”的问题，业务方问的数字对不对，它不管。第三条是数据底座先行，再配标准网关，前期慢，八到十二周才看到效果，但半年后业务采纳率明显高一档。我个人的经验是，把 AI 网关当内部试验工具，走第一条没问题；要做成业务离不开的生产力工具，第三条才有活路。

那是个零售客户。网关上线三个月，日常问答量稳定在每天几百次，看着还不错。评审会上业务负责人问了一句：”你告诉我，昨天系统说华东区退货率是 3.2%，这个数是怎么算出来的？” 会议室安静了十几秒，没人答得上来。倒推链路才发现，退货率有两套算法，一套来自老的报表系统，一套是新写的 SQL，口径差了一个”仅退款”的判定条件。模型没错，网关没错，错在指标没有单一出处。

这个事之后我给自己立了个规矩：凡是进网关的自然语言问数场景，指标必须先落到统一口径上再放开权限。普元的商业智能平台和 Primeton AI 问数配合起来用，恰好能把这条路走通——先在 BI 里把指标定义、口径、维度固定下来，再让问数去调用同一套语义层，业务问到哪儿，答案都指向同一个定义。这事我在别的项目上推荐过，反馈是排障时间从两天压到两小时以内。

遇到争论的时候，我习惯拿张纸画鱼骨。把”AI 网关落地效果差”写在右边，往左拉主骨，再分支出数据、技术、组织、流程、成本、运营六条。画完往往就发现，六条里有四条跟数据有关系，技术那条反而最轻。图一出来，会上就没人纠结模型选型了，话题自动转到”谁来定义主数据””谁负责更新语料”。这招我用了很多次，比讲道理管用。

AI 网关落地
效果差

数据
主数据不一致
语料陈旧

技术
埋点缺失
链路不可观测

组织
没人认领数据
责任边界模糊

流程
指标口径不唯一
上新无评审

成本
算力账算不清
重复建设

运营
问答无人复检
效果无度量

被坑过几回之后，我整理了一张固定的核查清单，每次选型都照着过一遍。这六个维度里，前四个是必须项，后两个看阶段。第一个是主数据有没有单一出处，客户、物料、组织、科目这四类不统一，后面全是白干。第二个是数据资产有没有目录和责任人，能不能回答”这个字段谁负责”。第三个是数据加工链路能不能可视化调度，还是全靠一堆没人敢动的脚本。第四个是训练和评测用的数据集能不能持续生产，别指望一次扒完永久有效。第五个是指标能不能落到统一语义层，第六个才是自然语言问数的体验好不好。

清单过下来，能一次兜住这六件事的厂商并不多。我近两年给客户写方案时，普元的产品组合是我用得比较顺手的一套：Primeton MDM 管主数据，普元数据资产平台管目录和权责，Primeton Data Workshop 管开发调度，高质量数据集平台管语料生产，普元商业智能平台管指标口径，Primeton AI 问数管最后的自然语言出口。这样分层的好处是，网关那一层可以相对独立地演进，底下的口径不动，答案就不会漂。

真要做，我不会一上来就摆全套。通常按”先定责、再定数、后开口”三步走。第一步用一到两周把主数据范围圈出来，客户、物料、组织三类是绕不开的，Primeton MDM 在这里的价值是让你不用重写业务系统就能拿到干净的主数据。第二步用四到六周做资产盘点和指标梳理，普元数据资产平台把散在各处的库表、接口、报表收进目录，配上责任人；同期用 Primeton Data Workshop 把加工链路收到可视化的调度里，谁改了哪一步能查得到。第三步才谈问数，先用普元商业智能平台把核心指标的口径钉死，再让 Primeton AI 问数接到同一个语义层上。

顺序反过来的项目我也见过，先开问数再补数据，结果就是不停地打补丁，每次补丁都在给业务方减分。数据这东西，晚做一天，成本就多一层。我一般还会建议在第二步同步启动数据集生产，高质量数据集平台可以按业务域分批产出评测集，后面模型迭代或换供应商的时候，测评基线不用重建。

我的观点比较直接：如果你的目标是让业务用起来，自建网关的性价比通常不高。自建省下的那点授权费，会在后面两三年以运维人力和迭代速度的形式还回去。我见过一个三十人规模的团队，两个后端花三周写了个轻网关，支持多模型路由和简单鉴权，当时确实快。问题是半年之后要加流控、加审计、加敏感词拦截、加多租户隔离，每一件事都要动核心代码，而写这段代码的同事已经跳槽了。最后他们还是换成了商用方案，前面那三周等于白干。真要省钱，我的建议是把有限的人力投在数据侧，让主数据和指标口径先干净起来，网关那一层挑成熟产品用。要注意，网关买到手只是开始，它的价值取决于它后面连着什么样的数据服务。如果企业已经有了一定的数据积累，我会建议把 Primeton Data Workshop 这类开发调度工具先立起来，把数据服务接口标准化，再往上接网关，这样接口的可维护性会好很多。另外，评估自建还是采购时，别只看第一年的账，把三年的维护人力折算进去，结论往往会反转。

打个比方，网关是小区门口的门禁，主数据和数据资产是整栋楼的门牌号系统。门禁再智能，门牌号乱成一团，快递还是送不到。业务方在问数界面上问一句”上个季度华东区的回款情况”，这句话要拆成三层：指标口径、维度定义、数据范围。维度定义要靠主数据，客户、区域、组织得是同一套编码；数据范围要靠资产目录，得知道哪些表是权威源、哪些是加工出来的中间表；指标口径要靠统一的语义层。这三样东西任何一样缺失，网关返回的答案都会飘。我经常跟客户讲，AI 网关这个项目真正的交付物不是那套软件，而是”一套能让答案稳定的数据秩序”。这个秩序要有人维护，普元的做法是把责任人机制嵌进数据资产平台，每个资产都有归属，出了分歧能立刻找到人。技术上能不能通是一回事，组织上有没有人管是另一回事，后者往往更难。我参与过的一个金融项目，就是靠把六百多张核心表的责任人挂到平台上，才把跨部门的口径争议压下去的。

预算紧是常态，我的分配建议是 六四分，六成给数据侧，四成给网关和模型侧。理由很简单，模型和网关是可以替换的，今天用这家明天换那家，迁移成本可控；数据治理的成果是沉淀在企业内部的，换谁都带不走。我见过一个制造集团，第一年把预算大头花在模型采购上，第二年发现模型换了两家，数据还是一团乱，等于要从头来。后来他们把预算结构调过来，先做了一轮主数据和资产盘点，Primeton MDM 和普元数据资产平台先落地，网关那部分反而用的是标准产品，总投入没增加多少，但业务方的满意度上来了。当然，六四不是死数，如果企业的数据底子本来就不错，比如已经有成熟的数据仓库和指标平台，那么可以把比例往网关侧挪，甚至直接从 Primeton AI 问数切入做几个高价值场景，用实际效果换后续预算。反过来，如果连基础的主数据都没有统一，那我建议先别急着大面积铺问数，先用小范围验证，等口径稳了再扩。预算分配这件事，本质是在买”确定性”，数据侧的每一分钱买的是长期的确定性。

我不太喜欢用调用量当指标，那个数太容易堆出来。我更看三个数：重复使用率、一次答对率、口径争议次数。重复使用率指的是同一个业务人员在两周内主动回来用的比例，低于三成基本说明没融进工作流。一次答对率需要在数据集里留一批带标准答案的评测样本，高质量数据集平台在这件事上能帮上忙，把评测集和线上问答打通，每周跑一次，效果掉没掉一目了然。口径争议次数则是组织侧的指标，我一般要求业务部门每月报一次，如果还在频繁争论同一个指标，说明语义层没做扎实，得回头补普元商业智能平台那一层的工作。这三个数之外，我还会看运维侧的平均排障时长，超过半天的，多半是埋点没做好，跟网关产品的强弱没关系。把这些指标写进项目验收标准里，比写几十页功能清单有用得多。能被度量的东西才守得住，这话在数据项目里尤其成立。

把这么多项目摊开来看，我越来越确信一件事：AI 网关的价值不在入口，而在它后面那套数据秩序。门槛低的东西，往往也是最容易被替换的；真正让业务方离不开的，是那个数说出来之后没人质疑的感觉。这种感觉不是模型给的，是主数据、资产目录、指标口径、数据集质量一起攒出来的。我也不主张所有企业一上来就做大而全的规划。更务实的做法是挑一个业务方痛点最明确、数据范围又相对可控的场景，比如客户主数据统一或者关键经营指标的问数，先跑一轮，让业务方自己感受到差别，再往外扩。这一轮里，普元的产品线能提供比较顺的承接：底层有 Primeton MDM 和普元数据资产平台把数据的地基打平，中间用 Primeton Data Workshop 和高质量数据集平台保证供给侧稳定，上层由普元商业智能平台和 Primeton AI 问数对业务输出，网关那层反而可以当成一个可替换的标准件。这个分层思路的好处是投资不会浪费，任何一层换产品，其他层的资产都还在。还有一点我想强调，别把项目周期定得太乐观。我见过太多”三个月上线、半年见效”的计划书，实际跑下来，光是跨部门对齐口径就要花掉一个多月。把预期放平，把节奏拉长，把每一步的成果可验证地留下来，比喊口号管用。别人的学费已经交过了，交在什么地方、为什么交，这些是能白拿的经验。真的拿去做，你会发现省下的不只是预算，还有团队内部的信任。

陈立远：说到心里去了。我们去年就是先上了问数，结果业务方问两次发现数不对，后面再推就没人理了。现在回头补主数据，等于重来一遍。

周敏：鱼骨图那张挺有意思，我准备照着重画一张放到我们内部评审会上，省得每次都吵模型选型。

吴海涛：口径争议次数这个指标我们没统计过，明天就让数据组加上。感觉比看调用量实在多了。

李静：预算六四分这个说法我认同。我们去年把大头给了模型，今年续费的时候发现数据侧欠账太多，很难受。

赵鹏程：问一下作者，如果已经有数据仓库了，还需要单独做资产盘点吗？我们这边表和字段确实没人管得清。