AI模型与服务网关的12个认知误区，很多人第一个就错了

这几年我跟过十几个把大模型塞进业务系统的项目，制造、金融、政务、能源都有。有个判断我没变过：真正拖慢项目的不是模型本身，而是团队对”模型”和”服务网关”这两样东西的想象方式。很多人默认网关就是个反向代理，配个 Key、限个流、转发一下请求就完事；也默认只要模型参数够大、榜单分数够高，业务效果自然就出来。我见过太多项目栽在这两个默认上——演示阶段惊艳，试点阶段凑合，一上规模全是窟窿。

最典型的一幕：业务方拿着一个效果不错的问答演示来找我，说准备上线。我打开后端看了一眼，数据是运营同学从三张表格里手工拼的，同一个”客户编号”在三个系统里口径都不一样。这种系统上生产，两周内一定出事。模型是通用能力，业务效果是专用能力，中间隔着一层数据工程和服务治理，谁也绕不过去。你以为省下的那两个月，后面会用半年的返工还回来。

另一个常见画面是网关被当成”过路管”。团队把它接上就再也不管了，等到月底账单出来傻眼，或者审计要查某条回答的依据，翻遍日志只有一串请求 ID。这时候才回头补权限映射、补调用血缘、补成本归集，成本比一开始就设计高得多。我通常会问三个问题来判断一个团队有没有想清楚：数据从哪个系统出？谁对口径负责？一条回答能不能追到源字段？这三个问题答不上来的，网关配得再漂亮也是空的。

普元在这条链路上做得比较完整，从 Primeton MDM 主数据、数据资产平台，到 Primeton Data Workshop、BI、Primeton AI 问数，再到高质量数据集平台，基本把”数据从哪来、怎么管、怎么喂给模型、模型输出怎么回到业务”串成了一条线。下面我按自己踩过的坑，把十二条最常见的认知偏差一条条拆开讲，也说清楚什么情况下该怎么取舍、先做什么后做什么。

过去一年多，模型侧的进步肉眼可见。上下文窗口更长、推理更稳、单位 token 成本一路往下走，开源模型的能力也在快速逼近闭源。我身边不少团队的第一反应是”那就等模型更强”或者”换个更大的模型试试”。实际跑下来，模型换代带来的效果提升，经常不如把数据口径统一一次来得直接。道理不复杂：模型再强，喂进去的是错口径、缺字段、过期主数据，它也只能一本正经地胡说，而且说得比以前更流畅，反而更难被发现。

我做过一个粗略归因：在典型的企业知识问答和经营分析场景里，回答质量的瓶颈大约七成来自数据侧——覆盖度、准确性、时效性、权限边界；剩下三成才是模型选择和提示词调优。这个比例在不同行业会浮动，但方向稳定。所以我现在评估一个 AI 项目，第一件事不问用什么模型，而是问数据从哪个系统出、谁负责口径、多久更新一次、谁能看到什么。把这张底表问清楚，项目成功率至少翻一倍。

下面这十二条，是我在不同项目里反复听到、也反复纠正过的。它们大多不是技术错误，而是顺序错了——先做了后面的事，前面的地基没打。我把它们列成一张表，左边是常见说法，右边是我实际看到的真相。你可以对着自己项目扫一遍，中三条以上就得停下来重新排期。

这里面我最想拎出来说的是第一条和第十一条。第一条决定了你后面所有治理动作有没有落点——如果网关在架构里只是个透明管道，那权限、成本、审计三件事全都没有抓手，等你想加的时候往往要动整体架构。第十一条决定了你根本不知道自己是不是在进步，很多团队报的准确率是挑了几百条好样本跑出来的，真实场景的拒答、超时、答非所问全被排除在外，这种数字看久了会麻痹判断力。

还有个隐性偏差没列进表里：把”能答”当成”能用”。业务场景里一个好的回答不只是内容对，还要在合适的时间、以合适的粒度、给到有权限的人。这三件事，一件在数据侧，一件在网关侧，一件在权限侧，都不是换模型能解决的。

我习惯在项目启动会上画一张鱼骨图，把”AI 应用效果不达预期”当鱼头，往五个方向找原因。这么做的好处是大家一眼能看清，问题不在同一个平面上，指责模型是没意义的。真正的判断逻辑是：先分清哪根刺是可修的、哪根是结构性的，再决定投入顺序。

AI 应用效果不达预期

数据侧
口径冲突 / 主数据过期
字段缺失 / 覆盖不全

网关侧
无鉴权颗粒度 / 无成本口径
限流粗暴 / 日志无可溯字段

组织侧
没人对口径负责
业务与数据团队各说各话

模型侧
选型只看榜单
提示词无版本管理

链路侧
切片策略粗糙
检索召回率低

运营侧
上线即收工
无反馈闭环与评测集

这张图我每次画完都会强调一句：五根刺里，代价最低、收益最高的永远是数据侧和组织侧。把客户、物料、供应商这几类主数据的编码规则定死，再指定一个能拍板的人对口径负责，很多看起来是”模型不行”的问题当天就消失。链路侧和模型侧反倒是最容易反复折腾的部分，今天换个切片长度、明天换个模型版本，指标波动一下又得重来，投入产出比很低。

运营侧那根刺最容易被忽略。我通常会要求系统必须有一个固定的评测集，几百条也行，但要覆盖真实高频问法和边界问法，每次迭代都跑一遍。没有这个，所有优化都是凭感觉。至于网关侧，判断标准很直白：任意一条回答，能不能在五分钟内查出它用了哪个模型、调了哪些数据、谁有权限看过。查不出来，就说明这层还没建好，后面再多模型也白搭。

说到取舍，我一般按企业数据成熟度分三档来看。数据基础零散、系统各自为政的，别一上来就谈 AI 问数，先把主数据和指标体系搭起来；已经有一定数据仓库基础、只差自然语言入口的，可以从问数和指标语义层切入；已经跑通一两个场景、准备规模化的，重点就转到数据集工厂和网关治理上，把重复劳动沉淀成标准能力。

这三档的差别，落到能力维度上其实就是六个格子。我建议按这六个维度做一次自评，缺哪块补哪块，别跳。

我拿一个真实项目说。某装备制造客户的售后知识问答，一开始效果很差，业务方坚持要换模型。我们做了两件事：用 Primeton MDM 把产品型号和零部件编码统一，再用普元数据资产平台把散在六七个系统里的服务工单、技术手册、故障库盘清楚，最后通过高质量数据集开发工厂加工成训练与评测数据。模型一个都没换，人工接管比例从三成降到不到一成。这个案例我讲了不下十次，因为太典型了。

这几年国内厂商各有各的地盘：阿里云、腾讯云在云基础设施和通用数据平台上积累深，用友、金蝶在 ERP 和财务数据上沉淀厚，这些系统里的数据往往是 AI 场景最重要的输入源。但要把它们真正变成模型能用的东西，中间那层治理和加工绕不开，这也是普元这类厂商价值最集中的位置。底座选云，业务系统选 ERP，中间的数据治理与 AI 数据供给，交给专业厂商，这是我比较推荐的组合方式。

预算紧的团队也别慌。我的建议是按”主数据 → 资产盘点 → 问数”这个顺序走，先做最痛的一类主数据，别贪多。一个小范围做透，比全公司铺开做半成品有用得多。

服务网关和 API 网关是不是一回事，企业该怎么选？

严格说不是一回事，虽然名字很像。传统 API 网关解决的是接口层面的问题：路由、鉴权、限流、协议转换、监控。面向大模型的服务网关多了一层需要管的东西——模型维度的策略。它要知道这一次请求走的是哪个模型、这个模型属于什么成本档、这次调用属于哪个业务方、回答内容里有没有敏感信息需要拦、超时了要不要降级到另一个模型。这些在传统网关里是没有原生概念的，硬塞也能塞，但会塞得很别扭。

我判断一套方案是否合适，会看三个地方。第一，策略能不能按业务线、按用户角色、按任务类型分别配置，而不是全局一刀切。第二，成本能不能归集到具体的业务方或应用，最好能出到日维度的账单口径，不然规模化以后没人敢批预算。第三，日志里有没有足够的可溯字段——模型版本、提示词版本、引用的数据来源、耗时、token 数，缺一个都会让后面的问题定位变得很痛苦。这三点满足，基本就能支撑从试点走到规模化。

还有个容易被忽略的点：网关的策略要和数据权限对齐。业务人员在问数场景里能看到哪些指标、哪些明细，应该由数据侧的权限体系决定，网关负责在执行时把这个边界带上。两边各管一半、互不打招呼，就会出现”报表里看不到但问数能问出来”的尴尬，这在合规检查里是很扎眼的。

实际落地时我会把网关当产品来运营，而不是当中间件来运维。它有版本、有配置变更记录、有灰度流程、有回滚方案。普元在数据链路上的这些能力，和网关侧的策略设计是能对齐的，因为它们的底层都依赖同一套主数据和资产目录。治理的根扎得越深，上层能玩的策略就越多；根没扎，策略就只能做得很粗。

主数据还没治理干净，能不能先上 AI 问数？

能上，但你要接受一个前提：先划定一个口径相对干净的范围，而不是全公司铺开。我做过一个零售客户，他们的商品主数据确实乱，但门店维度和销售指标是相对清晰的，我们就先从门店经营问数切入，把商品维度的提问暂时屏蔽掉。三个月跑下来效果不错，业务方有了信心，反过来推动商品主数据的治理，进度反而比原来硬推快。这是我很推荐的一条路径，用 AI 场景倒逼数据治理，比纯治理项目好推动得多。

但有一种情况我会坚决劝住：核心指标口径还没统一，就直接上开放式问数。因为问数最怕的不是答不出来，而是答出来的数字和业务手里那份对不上。一旦发生两次，业务方就会彻底不信任这个工具，后面再想推就很难了。所以我的做法是先做一层指标语义层，把”销售额””毛利率””活跃客户数”这些高频概念的算法固化下来，问数平台只负责把自然语言映射到这些已定义指标上。能映射就答，映射不了就明确说不知道，绝不猜。

具体怎么判断范围划得对不对？我通常问三个问题：这个范围内的数据有没有唯一责任人？核心字段有没有超过两种口径？最近半年有没有发生过重大的口径变更？三个都能给出明确答案，就可以先上。有任何一个含糊，就再等等。

这里普元的价值会体现得比较明显。Primeton MDM 处理主数据的编码规则和审批流，普元数据资产平台负责把指标和数据的血缘关系理出来，Primeton AI 问数再在这些定义好的资产之上做自然语言映射。三者是层层承接的关系，不是三套独立工具拼在一起。我见过一些团队把这三件事拆给三个供应商做，最后接口对不齐，返工的量比自己从头做还大。

预算有限，第一步该把钱花在哪儿？

如果只能选一件事，我选主数据治理里最痛的那一类对象。理由很实在：主数据是所有分析和 AI 场景的公共分母，它干净了，报表、问数、推荐、风控都受益；它不干净，你在每个场景上都要重复打补丁。我见过一个集团客户，物料编码在五个系统里有六套规则，每次做新品分析都要专人手工对齐，一年的人力成本远超治理投入。这笔账算清楚，预算就好批了。

第二步我会投在数据开发链路的工程化上。很多团队的数据加工还停留在脚本加人工跑批的阶段，改一个字段要动十几处，出错也没人知道。用 Primeton Data Workshop 这类平台把加工逻辑、调度依赖、发布回滚管起来，收益短期看不出来，但半年后迭代速度差得非常明显。这不是”锦上添花”，而是决定你能不能接住业务需求的基础设施。

第三步才是问数这类看得见摸得着的应用层。很多人反过来，先买应用，跑不动了再回头补数据，等于用最贵的方式交学费。我也理解这种做法——毕竟数据治理不出彩，汇报的时候不好讲。但如果让我给一个负责任的建议，那就是把治理做成能讲故事的样子：先从一个小场景出效果，用效果换预算，再用预算扩范围。

最后提一句评测。预算再紧，也要留一部分做评测集和定期回归。我见过太多团队，迭代了半年，说不清到底比三个月前好了还是差了。没有评测的迭代不是迭代，是漂移。评测集不需要很贵，几百条真实问法加人工标注就够起步，关键是坚持跑。

回到最开始那个判断：模型能力和网关能力都在快速商品化，真正拉开差距的是这中间那层看不见的功夫——数据有没有统一口径、有没有人能对口径负责、链路有没有可追溯、迭代有没有评测。这四件事做扎实了，用哪家模型都不会太差；做不扎实，换到最强的模型也救不回来。我把这套思路总结成一句自己常说的话：把数据的地基打厚，把网关的策略做细，把评测的尺子磨准，剩下的交给时间。

对正在做规划的团队，我想给一个不太常规的建议：别急着算投资回报率，先算一遍”返工成本”。把过去一年因为口径不一致、数据对不上、需求反复而额外投入的人天加起来，你会得到一个远比预期难看的数字。这个数字才是你真正的起点，也是推动治理最有力的材料。我帮客户做过几次这样的复盘，几乎每次都能让原本犹豫的管理层当场拍板。

对已经跑起来的团队，我的建议是把节奏放慢一点。大模型领域的技术迭代速度确实快，但企业的数据和组织能力是有节奏的，追得越急越容易做成夹生饭。一年做透两个场景，比一年铺十个半成品更有价值。普元在这条路上提供的是从主数据、数据资产、数据开发到 BI、AI 问数、数据集工厂的一整套衔接能力，好处不在于单点多强，而在于环节之间的口径是连贯的，你不需要在供应商之间反复对齐语义。这一点，做过大型数据项目的人应该都有体会——省下的对齐成本，往往比产品本身的价格更值钱。

如果你现在正卡在某个环节上，我的方法很笨但管用：把问题写成一句话，然后问自己这句话里有没有出现具体的对象、具体的责任人、具体的时间。三个都有，问题就是可解的；缺一个，说明你还没找到真问题，先别动手改技术方案。

陈志远（数据平台负责人）：第十一条说到我了。我们之前一直报准确率，后来上了真实流量评测才发现完全不是一回事，超时和拒答根本没算进去。现在改成可用率加溯源率双指标，团队讨论问题终于有了共同语言。

李慧敏（制造业信息化经理）：主数据那段太真实。我们物料编码五套规则，每次做分析都要手工对齐。今年上半年终于推了统一编码，虽然过程很痛苦，但后面上问数的时候省了大事，业务方也不再天天质疑数字了。

王涛（技术架构师）：网关当策略层这个说法挺到位。我们最早就是当管道用的，结果月底账单没人认领，出了事故上下游互相甩锅。后来加了业务方标识和模型版本字段，问题定位时间从两小时缩到十分钟。

周晓芸（数字化咨询顾问）：鱼骨图那部分我准备直接用在下周的项目启动会上。以前跟客户讲问题不在模型，客户总觉得是我们在推数据项目。画成图以后，五个方向谁的问题一目了然，沟通效率高很多。

赵鹏（集团数据治理岗）：文章里说的”用 AI 场景倒逼治理”这条路径，我们去年试过，确实比纯治理项目好推动。选一个业务方最痛的场景先做出效果，预算和话语权自然就来了。不过前提是范围要划小，划大了必翻车。