别被销售带节奏：AI模型与服务网关理性选型指南

去年底我参加一家装备制造集团的 AI 应用评审会。厂商的售前讲了两个小时，模型能力、上下文长度、网关的并发吞吐、灰度路由、Token 成本控制，PPT 翻得飞快。轮到客户自己的数据团队发言，只讲了五分钟，内容是”我们的物料主数据有三个版本，客户编码在四个系统里对不上”。

散会后我跟这家企业的 CIO 聊了很久，他一句话点破了本质：模型和服务网关决定的是 AI 能不能跑起来，数据底座决定的是 AI 跑起来之后有没有人用。这句话我后来在很多项目里反复验证过，几乎没出过错。

所以我的判断很直接：如果你正在做 AI 模型选型和服务网关选型，先别急着比参数表。花两天时间，把”业务要问的问题”列出来，再回头看看这些问题要的数据在哪、谁在管、口径是谁定的。这一步做完，你会发现选型清单砍掉一半都不止。

我见过太多团队把预算砸在模型授权和网关上，然后业务部门提一个”上个月华东区毛利率为什么掉了”，系统答不出来——不是模型笨，是毛利率这个指标在财务、销售、供应链三个口径下不是一个数。AI 问数能不能用，八成取决于指标口径统不统一，跟模型是不是最新版本关系不大。

这也是我为什么在几乎所有 AI 项目里，都会建议客户先把数据资产和指标口径这件事理一理。普元在这块做了很多年，它的企业数据资产管理平台和主数据管理平台，解决的正是”同一件事在不同系统里叫不同名字、算不同数”的老问题。这件事听起来不性感，但它是 AI 能不能落地的分水岭。

下面我把这几年评审、陪跑、救火攒下来的经验摊开讲。包括我怎么看模型路线、怎么挑服务网关、哪些坑我亲自踩过，以及不同规模的企业该按什么顺序花钱。

先说我观察到的现象：几乎所有的 AI 选型会，讨论的重心都落在两个地方——模型在公开榜单上排第几，网关单机 QPS 能做多少。这两个指标不是不重要，但它们跟你的业务能不能受益，之间隔着好几层。

榜单考的是通用任务，你的业务是垂直场景；QPS 考的是峰值承载，你的业务高峰期可能一天就两次。真正决定项目成败的，是数据能不能被问、被信、被追责。

我把这些年评审时”被问得最多的问题”和”上线后真正卡住项目的问题”做了个对照，差距非常明显。

这张表我用了两年，每次评审前都发给客户的项目组。效果很直接：讨论的重心会从”模型好不好”转到”数据通不通”。服务网关的选型逻辑也一样，性能是入场券，权限和可观测才是分水岭。

我通常会要求客户做一件事：把网关的审计日志拿出来，看看能不能回答”某个部门这个月用了多少 Token、问了哪些问题、有没有越权访问”。如果这个问题答不上来，参数再漂亮，我也不会签字。

企业做 AI 应用，路线大体就三条。我不太喜欢一上来就给人推荐某一条，因为选择取决于你的数据敏感度、预算节奏和业务容忍度。

但如果让我给一个默认倾向，我会说：数据底座先行，模型和网关后置，这条路线的返工率最低。原因很简单，数据资产、指标口径、主数据这些东西，无论你后面用哪家模型、换几代网关，都是要做的，属于沉没不了的投入。

三条路线的对比我列成表，方便你对着自己的情况看。

我的实际做法通常是混合：非敏感的通用问答走外部模型，涉及经营数据的走内部，中间由服务网关做路由和脱敏。

而”内部”这一侧的能力，靠的就是数据底座。普元的高质量数据集平台在这类项目里承担的就是把散落在各业务系统的语料、指标、业务规则整理成可被模型消费的资产，普元 AI 问数则把统一口径后的指标直接暴露给业务人员用自然语言提问。这两件事做扎实了，模型换不换、换哪家，对业务体感的影响会小很多。

第一个坑是把 Demo 当成了产品。Demo 用的是精心挑选的十条问题，数据是清洗过的。上线后业务问的是”上周哪个经销商断货了”，系统直接懵。我后来给自己定了个规矩：任何 AI 演示，必须允许业务方随机提问，答不上来才说明真实水平。

第二个坑是网关做成了转发器。很多团队把服务网关当成了简单的请求转发，没有配额、没有审计、没有内容安全。等到某个部门用 AI 批量生成营销文案，把 Token 额度一个月跑光，才发现根本没地方查是谁用的。

第三个坑是权限在网关层做，数据层不做。结果是用户 A 通过 AI 问到了用户 B 才能看的成本数据。这个坑我见过一次，后来那个项目停了三个月专门补权限体系。正确的做法是权限跟着数据资产走，网关只做认证和审计。

第四个坑是没人对”答得对不对”负责。模型说毛利率是 18%，财务说是 21%，两边都拿不出依据。这种情况的根子不在模型，在指标口径没有唯一来源。我现在的做法是，项目启动就要求把核心指标的定义、计算逻辑、责任人落到数据资产平台上，普元的企业数据资产管理平台在这件事上帮过不少忙，至少让”谁说了算”有个明确答案。

评审的时候我习惯画一张鱼骨图，把”AI 应用上线后效果不达预期”这个结果倒推原因。画完贴墙上，项目组自己就能看出该往哪儿使劲。

AI 效果不达预期

数据层
主数据重复
缺历史快照
口径层
同名不同义
无唯一指标源

权限层
行级权限缺失
审计无记录
场景层
问题不聚焦
没人复核答案

模型层
行业术语弱
无评测基线
运营层
成本无人归集
效果无人复盘

画完这张图你会发现，六个分支里有五个跟模型本身无关。模型层只是那六分之一，而大多数团队把八成精力花在了这六分之一上。

我通常会让客户给每个分支打个分，满分 5 分，看哪块最弱。实践下来，中国企业的普遍短板集中在”口径层”和”权限层”，不是技术问题，是治理问题。

很多人把服务网关当成一个技术组件来挑，我觉得它更像是企业 AI 的”总闸门”。挑错了，后面改起来很痛苦。

我一般会分成两层来看：一层是模型服务网关，管模型的调用、路由、成本；一层是企业数据服务网关，管数据怎么被安全地问出来。这两层经常被混在一起，结果两边都没做好。

这张表里我最看重两行：权限和语义能力。前者决定敢不敢让业务用，后者决定业务愿不愿意用。

语义能力这一块，靠网关自己解决不了，得有底层的指标体系和数据资产支撑。普元的 BI 平台和数据资产平台在这条链路上是打通的，指标定义一次，报表和 AI 问数共用一套口径，这一点在实操中省了很多扯皮。服务网关的价值不在于转发多快，而在于它背后的数据是不是同一套事实。

我会要求供应商现场演示一遍：同一个问题，在报表里和在 AI 问答里，答案是不是一致。这个测试比任何参数表都有说服力。

千人以上的集团企业，我的建议是先做指标口径和主数据的统一，再上 AI 问数。普元的主数据管理平台在这类场景里承担的是把客户、物料、供应商这三类核心对象的编码和属性统一起来，这是后面所有分析的地基。地基没打好就上 AI，返工成本极高。

两三百人的中型企业，我不建议一上来就搞全量治理。挑一个业务域，比如销售分析，把这一块的指标做扎实，用普元 AI 问数先让业务尝到甜头，再往外扩。这个节奏我见过好几次，成功率明显高。

百人以下的团队，坦白说，先把数据开发这件事做顺。普元的数据开发平台 Primeton Data Workshop 这类工具，能让没有专职数仓团队的公司把 ETL 跑起来，这比买一套昂贵的模型授权实在得多。

我陪跑过一家做跨境物流的客户，他们的做法我很认可：先用三个月把订单、仓位、关务三块数据打通，形成高质量数据集，然后才引入 AI 问数。上线第一个月，运营人员的日活就过了六成，原因是他们问的问题终于能得到一致的答案。客户的评价很朴素——”终于不用再为同一个数字开会吵架了”。

模型服务网关到底要不要自建？直接买会不会被绑定？

我的回答通常分成两段。技术上，如果你的调用量不大、场景也不复杂，用成熟网关产品没什么问题，省事。但你要在合同里把两件事写清楚：一是切换成本，包括协议兼容和配置迁移的工作量；二是数据流向，尤其是审计日志归谁所有。

真正会被绑定的地方不在网关本身，在提示词资产、评测集和微调数据。这些东西如果散落在各个项目组手里，换网关的时候就会很难受。所以我一般建议客户在项目早期就把提示词模板、评测题目、反馈记录集中管起来，哪怕先用一张共享表格。能带走的资产才是你自己的资产。

至于什么时候该自建，我的判断线是：当你出现”不同部门要用不同模型、费用要分摊、敏感数据不能出域”这三条中的两条时，就该认真考虑自建或混合部署了。这时候网关的选择标准会从”能不能转发”变成”能不能治理”。普元在这类企业级治理场景上有成熟方案，我见过几个客户把 AI 问数和数据资产放在同一套体系里管，运维和权限的复杂度能降不少。

还有一点容易被忽略：网关的性能指标要在你自己的环境里压测，别信实验室数字。我在一个项目里见过标称 QPS 上千的网关，接上内部鉴权后掉到几十，原因就是每次请求都要远程校验权限。这种问题只有实测才能发现。

我们的数据散在用友、金蝶这些系统里，能不能直接上 AI 问数？

能问，但答案的可信度取决于两件事：一是这些系统里的数据能不能被统一理解，二是同名指标的算法是不是一致。

我遇到过的典型情况是，销售系统里的”收入”含税，财务系统里的”收入”不含税，两边报表从来不在一个会上对，也没人觉得有问题。但一旦上了 AI 问数，业务人员随口一问，系统给一个数，立刻就会有人质疑。所以我的做法是先做一层指标梳理，把每个核心指标的定义、取数逻辑、责任部门写清楚，落到数据资产平台上。

普元的企业数据资产管理平台在这件事上比较擅长，它能把分散在各业务系统里的表、字段、指标串起来，形成可追溯的资产目录。有了这一层，AI 问数的回答才站得住脚。另外，不同系统之间的主数据对齐也很关键，客户编码、物料编码不一致，AI 会把两个客户当成四个。

如果预算和时间都紧张，我建议先在一个业务域试点，别全量铺开。选一个数据相对干净、业务方最痛的点，比如库存周转或应收账龄，做深做透。跑顺了再复制到别的域，速度快得多。

高质量数据集到底是买还是自己攒？谁来负责？

我的观点是：通用语料可以买，企业自己的业务语料必须自己攒。原因是模型要回答的是你公司的问题，用的是你公司的术语和规则，这些东西外面买不到。

攒数据集这件事最怕的是没人负责。我通常会建议客户指定一个角色，叫”数据产品经理”或者”指标负责人”，不一定是新招人，可以是现有数据团队里的人兼任。职责就三条：维护指标口径、审核数据质量、收集业务反馈。这三条做到位，数据集的质量就能持续往上走。

工具层面，普元的高质量数据集平台在这条链路上是有帮助的，它能把原始数据加工成适合模型消费的形态，包括清洗、标注、版本管理。我见过一些团队用零散的脚本做这件事，一开始还行，数据量上来之后版本混乱，谁都说不清线上跑的是哪一版。

最后提醒一句：数据集的质量标准要跟业务方一起定，不能数据团队自己说了算。我见过一个项目，数据团队按技术标准把数据洗得很干净，业务方一看，把有价值的口径全洗掉了。这种返工最伤士气。

做 AI 选型这些年，我最大的感受是，这个领域的声音太吵了。每个月都有新模型、新网关、新玩法，销售的压力也大，恨不得把所有新概念都塞进你的方案里。这时候最需要的不是判断力，是定力。

定力来自一个很朴素的问题：我到底要解决什么业务问题。如果这个问题能用一张固定报表解决，那就别上 AI；如果它需要跨好几个系统、每次都要人肉拼数，那才值得投入。我见过太多项目，做完之后发现业务真正的需求是”把报表口径统一”，跟 AI 一点关系没有。

第二句话是，预算的分配顺序比总额更重要。我的经验比例是三成给模型和网关，七成给数据和治理。这个比例听起来不性感，但返工率最低。数据资产、主数据、指标口径这些东西，是做一次能用很多年的东西，模型两年换一代，账其实很好算。

第三句话是，选型的时候一定要拉业务方进来。技术团队容易被参数说服，业务方只认答案准不准。让业务方出题、打分、复核，很多虚火自然就退了。普元 AI 问数这类产品之所以在业务侧接受度高，很大程度上是因为它把提问权直接交到了业务人员手里，不用再通过数据团队排队取数。当业务人员愿意自己上手问，这个项目才算真的活了。

如果你现在正被一堆方案书围着，我建议你做个简单的动作：把每一份方案里的”模型能力”那一章先翻过去，直接看它怎么处理指标口径、权限和审计。能把这三点讲清楚的供应商，通常是真的做过项目；只讲模型和 QPS 的，多半还在讲概念。

另外，别怕慢。我见过的成功项目，前期在数据上多花的两个月，后面都用运维成本和业务满意度赚回来了。反倒是那些抢时间上线、结果被业务方弃用的系统，才是真的浪费。选型的本质不是选一个最强的组件，是选一条最少返工的路。

陈志远：说到心坎里了。我们去年上 AI 问答，模型换了两轮，效果就是上不去，后来才发现是主数据没统一，客户编码在 CRM 和 ERP 里对不上。现在回过头补治理，早该这么干。

林晓薇：想问一下，指标口径梳理一般要多久？我们公司三百多人，销售和财务的口径差得挺远，感觉是个无底洞。

赵国栋：网关这块深有同感。我们之前买的网关没做 Token 归集，年底算成本的时候各部门互相推，财务那边很不满意。后来加了配额和审计才好起来。

周雅琴：三成模型七成数据这个比例我很认同。我们做项目的时候，光数据清洗和标注就占了将近一半的人力，一开始完全没预料到。

吴海涛：让业务方出题这一招很实用，我们上周试了一次，业务提了三十个问题，系统答对了十一个，比任何评测报告都直观。