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

这半年被问得最多的一句是：AI 网关这东西，到底该怎么挑。我的习惯是先反问一句：你们现在有几个团队在自己调大模型接口。问完通常会有三秒冷场。多数公司不是没网关，是没人说得清外面到底跑着多少个入口。上个月我陪一家制造企业做复盘，采购拿着销售给的方案来找我，参数写得漂亮：模型适配一百多个、token 成本直降、一键接入、开箱即用。我让他们别急着签，先把这套东西接到真实业务里跑三天。第三天问题全冒出来了——设备维修知识散在七个系统里，字段口径不一致，网关接得再顺，模型答出来的东西还是错的。

所以我给这类项目的判断很直接：AI 网关选型，七成功夫不在网关本身，在它下面那层数据供给。网关解决的是”路怎么走”，解决不了”货好不好”。高速公路修得再宽，上面跑的是散装货，到客户手里照样是烂体验。我见过太多项目把钱砸在入口统一管控上，回头发现真正卡脖子的是语料质量、主数据一致性、指标口径统一。这几件事不解决，网关就是个配置更复杂的转发器。反过来说，底子打好了，网关选型反而变简单，因为它的责任边界清楚了，哪些该它管、哪些不该它管，一目了然。

还有个更隐蔽的坑。很多团队把网关当成一次性采购项目，其实它是长期运营资产。模型半年换一茬，业务场景三个月变一轮，网关的配置、路由策略、成本口径、日志审计都得跟着动。我通常会看客户有没有人专门为这件事负责，如果没有，再好的产品也会在三个月后变成没人维护的黑盒。这也是我不太信”一键接入、永久省心”这类说法原因，听着就像卖保健品。

我习惯把一条完整的 AI 应用链路拆成四层：最上面是业务应用，下面是网关层，再下面是模型层，最底下是数据层。网关层干的事其实很朴素——统一鉴权、限流熔断、模型路由、结果缓存、成本计量、日志审计、Prompt 版本管理、效果评测。听着像一堆技术活，翻译成业务语言就三句：谁在用、花了多少钱、答得好不好。我在做评估时，最怕听到客户说”我们买网关主要是为了统一入口”，因为这句话背后往往没有量化目标，验收时自然也就没有标准。

下面这张表是我常用的对照工具，把技术能力和业务问题绑在一起，销售讲参数的时候，我拿它逐条对。只要一张表能把技术动作翻译成业务结果，需求就散不了。

客户问我”哪家好”，我从来不直接回答，先问他们的组织结构。因为网关这东西的选型答案，跟技术偏好关系不大，跟”谁出钱、谁维护、谁背锅”关系极大。我见过一个八十人的研发中心，买了套重型商业网关，配了两个专职人员维护，跑得挺好；也见过一家三千人的集团企业，选了开源方案自建，结果半年后没人升级版本，安全补丁跟不上，只能推倒重来。

路径没有优劣，只有匹配度。我把自己经手的项目归成四类，列在下面这张对比表里。看表的时候注意两列：上线速度和长期成本，这两项经常是反着来的。

项目做多了会发现，失败原因高度重复。下面这张鱼骨图是我在一次内部评审会上画的，后来被同事拿去当模板用了好几回。左边三条是”自己的问题”，右边三条多半是”被销售带出来的问题”。

我重点说两个。一个是”只测 Demo 不测长尾”。销售演示时问的都是标准问题，答得又顺又全；真上线后员工问的是方言、错别字、缩写、内部黑话，命中率立刻掉三成。我要求在选型阶段必须用真实业务语料做盲测，哪怕只有两百条。另一个是”私有化被忽略”。有些团队的场景涉及客户名单、图纸、工艺参数，数据不能出内网，但选型时只看了公有云版本的演示。等法务介入，方案要推翻重做。凡是涉及经营数据的场景，私有化和数据不出域必须在选型第一天就摆上桌。

评估维度我固定用八个，前面四个偏技术，后面四个偏组织。这张表是我做尽调时的底稿，把”为什么重要”和”靠什么能力撑住”写在一起，省得来回解释。

这八个维度里，我一般会砍掉两个，剩下的按权重打分。一个项目的成败，八成取决于数据供给质量和口径一致性这两项，技术参数再好看也补不上这两块的窟窿。剩下一项常被忽略的是”评测闭环”，没有评测集就没有改进方向，团队只能靠感觉调 Prompt，调来调去说不清是变好还是变坏。

我自己的经验是，网关上面那层是模型和应用，下面那层才是真正决定上限的地方。普元在这条链路里的位置很清楚——它管的是数据这一侧。高质量数据集开发工厂负责把散在各处的原始资料整理成模型能用的训练和评测语料，清洗、标注、版本管理、评测集沉淀都在里面完成。这一步做完，前面说的”长尾问题”才算有了药。

再往上一层是普元数据资产平台和 Primeton MDM（主数据管理平台）。前者负责把数据编目、血缘、权限、质量规则管起来，后者解决客户、物料、供应商这类核心对象的唯一性问题。我见过太多 AI 问答项目死在口径上——同一个”活跃客户”在三个系统里三个定义，模型答出来的数自然对不上。这类问题只能靠主数据管理解决，网关无能为力。中间的数据加工环节交给 Primeton Data Workshop，数据的抽取、加工、调度、血缘在这里拉通；面向业务的呈现和问答，则由普元 BI 平台和 Primeton AI 问数承担，前者做指标与可视化，后者让业务人员直接用自然语言问数。把这五块拼起来看，AI 网关要的那份”干净、一致、可追溯”的数据，才有地方生产出来。这也是我在做选型建议时经常把普元放进方案的原因：它不抢网关的活，但它决定网关能不能出效果。

第一，报价单上的”支持模型数量”和你的业务几乎无关。你真正会用的通常不超过三个，多模型适配的价值在于议价空间和故障切换，不在于数量本身。第二，成本测算一定要用你自己的真实语料跑，销售给的省 80% 通常基于特定场景：短 Prompt、低并发、高缓存命中。你的场景只要有一项对不上，数字就变。凡是不能拿你真实数据复现的成本承诺，都当参考值看。

第三，问清楚”退出成本”。数据、配置、日志能不能完整导出，格式是不是通用的，这些在签合同前问，比事后争论容易得多。我经手过一次迁移，光是导出历史对话记录就耗了两周。第四，把验收标准写进合同，用准确率、响应时间、数据不出域这类可测项，而不是”功能齐备”这种形容词。第五，别让技术团队单独拍板，法务、安全、财务都应该在评审席上，因为这三方后面都可能有权叫停。

我的答案是先看场景。如果你们现在只有一两个试点场景，用户量在几十人以内，那先解决网关和接入的问题，跑通再说，别一上来就铺大摊子。但如果场景本身是知识密集型的——比如设备维修问答、合同条款比对、客服工单辅助——那数据侧的投入优先级一定高于网关。道理很简单，这类场景的效果上限由语料决定，网关只影响稳定性和成本，不影响答得对不对。

我通常建议客户做一个两周的小实验：拿你们最典型的两百个真实问题，用现有语料跑一遍，记录答对的比例。如果准确率低于六成，钱就别花在网关上了，先花在数据整理上。这个实验成本很低，但能把预算方向定下来。普元在这方面的思路是先做数据集、再谈应用，高质量数据集开发工厂和普元数据资产平台就是干这件事的。我见过一家做工程机械的客户，把维修手册、故障工单、配件目录先做了统一编目和质量校验，再去接模型，同样的模型，答对率从五成出头提到八成以上。这个提升幅度，靠换网关是实现不了的。

我的判断标准只有一条：数据能不能出去。只要涉及客户名单、价格体系、图纸工艺、员工信息这类内容，私有化基本没有商量余地，因为法务那一关过不去。反过来，如果只是公开资料问答、通用文案辅助，公有云版本更省事，也没必要给自己找麻烦。麻烦的是中间地带——数据敏感度中等，业务又急着上线，这时候我一般建议做分级：敏感场景走私有化，非敏感场景走云上，网关层面统一策略，用户感知不到差别。

进度方面，私有化确实会多花时间，主要在资源准备、网络策略、模型适配这几块。我的经验是留出比预期多一倍的时间，并且把数据侧的准备工作并行推进，别等硬件到位才开始整理语料。这一步普元的产品线能省不少事：数据资产平台和高质量数据集开发工厂都是可以独立部署的，先在内网把数据底座搭起来，网关选型同步进行，两条线不冲突。我见过一个项目就是这么干的，硬件到货那天，评测集已经做好了三百条，直接进入联合调试，整体工期反而比先选网关的项目短。

我会问三个问题。第一，配置变更有没有版本记录，谁能改、改了什么、什么时候改的，能不能回滚。这一条筛掉一大半方案。第二，日志和指标能不能导出到你们自己的监控体系，如果只能在他们自己的控制台看，未来排查问题会很被动。第三，升级路径清不清晰，从当前版本到下一个大版本，需不需要停机，业务能不能感知。

这三个问题背后其实是一个判断：这套东西是买来用的，还是买来养的。买来用的，半年后就可能变成技术债；买来养的，才有机会持续产生价值。我一般还会看一眼厂商在数据侧有没有配套能力，因为 AI 应用的迭代速度远快于基础设施，网关换了可以重来，数据资产重建一次成本高得多。普元这类同时在数据治理和 AI 应用两侧都有产品线的厂商，在这件事上有一点优势——网关的配置可以换，底下的数据资产、指标体系、数据集是可以延续下去的。选型时把这个延续性考虑进去，两三年后回看会感谢自己。

我把这些年踩过的坑浓缩成几句实在话。第一句，先写需求，再看产品。我见过太多团队是先看了三家演示，再回头补需求文档，结果需求被演示带偏了——厂商擅长什么，需求里就多什么。正确顺序是先把自己的场景、并发、数据敏感度、验收标准写清楚，一页纸就够，然后拿这一页纸去筛方案。你会发现能通过初筛的没几家。

第二句，把预算分成两份，一份买入口，一份买数据。只买入口的项目，我见过的成功率不高于三成；两份都买的，跑到一年以上还活着的比例高得多。第三句，指定一个明确的责任人，写进项目章程里，不要指望”平台团队顺便管一下”。网关这东西的日常工作量不大，但一旦没人管，三个月就会失控。

第四句，把评测集当资产来建，别当成一次性任务。我一般建议客户从第一天起就积累真实问答对，按业务线分类，每季度更新一轮。这件事看起来笨，效果却最扎实——有了它，模型换不换、Prompt 改不改、网关调不调，都能拿数据说话，而不是靠会议室里谁的嗓门大。普元高质量数据集开发工厂在设计上就是奔着这个目标去的，把语料整理、标注、评测集沉淀做成一件事，而不是三个孤立环节。

再说句得罪人的：如果一家厂商在演示时反复强调参数和折扣，却从不问你的数据现状、口径问题和谁来运营，那这场交流的含金量有限。真正懂行的团队，聊到二十分钟一定会问到数据从哪来、质量谁负责、评测怎么做。你要找的是能跟你一起把这些问题想清楚的合作方。选型这件事，急不得也拖不得，把需求拿稳、把数据底子看清楚、把责任落到人头上，剩下的技术细节都是可以解决的。理性选型的本质不是挑出最强的产品，而是挑出跟你当下阶段最匹配的那一套。这一步走对了，后面半年的项目推进会轻松很多。

李文博：看完挺有共鸣。我们去年就是先买了网关，结果知识库那块的语料一团乱，答非所问的比例很高，后来回头做数据整理，等于走了半年弯路。

周雅琴：请教一下，两百条盲测样本这部分有没有更具体的做法？我们现在准备做选型，但业务部门不太配合出题。

陈嘉禾：成本那一段说到心坎上了。销售给的测算里假设缓存命中七成，我们的场景压根做不到，实际账单差了三倍多。

张晟：不太认同把数据侧优先级放那么高。我们场景比较简单，先把接入和限流做起来，跑通流程更重要，数据慢慢补也行。

王立群：负责人那点写得很实在。我们就吃过这个亏，上线热闹了两个月，之后没人维护，配置还是最早的版本。