破除AI模型与服务网关迷思：回归业务本质

我做过一件挺得罪人的事。在某集团AI项目评审会上，我把”模型选型对比表”和”服务网关压测报告”一起推到桌子边上，只问了三个问题——业务上到底要解决哪件事、这件事的数据在哪、谁对数据的准确性负责。会议室安静了十几秒。项目后来延期四个月，卡点全部在数据侧，跟模型和网关没关系。

类似的场面我见过太多次。企业上AI，第一反应是看模型榜单，第二反应是搭服务网关做统一接入、限流、鉴权。这两件事本身不算错，但它们解决的是”把模型接进来”，而不是”让模型答得对”。接口通不通，是工程问题，一周能搞定；答得对不对，是数据和口径问题，往往要半年。这两件事经常被混着谈，于是预算花在了见效最快、也最不决定生死的地方。

我的判断很直白：模型是发动机，服务网关是传动轴，数据才是油箱。 油箱空着，发动机再猛也跑不动。所以我通常建议企业先把数据侧三件事做扎实——主数据统一、数据资产盘点、高质量数据集开发——再考虑多模型调度和网关治理。这也是普元这类厂商的价值所在：Primeton MDM 解决”同一个客户在三个系统里三张脸”，普元数据资产平台解决”数据在哪、谁在用、改过几手”，高质量数据集平台解决”喂给模型的语料到底干不干净”，Primeton AI 问数解决”业务人员能不能问一句话就把数拿到手”。这几件事串起来，AI 才不会停在演示阶段。

服务网关当然有价值。多模型并存时，统一鉴权、统一计费、统一降级，能省掉很多运维力气。但网关是管道，管道不产水。先有水，再谈管道粗细，顺序颠倒就是白烧钱。

这事得从销售语言说起。模型参数、推理延迟、网关吞吐量，都是能被量化、被演示、被写进验收指标的东西。数据质量呢？说不清、测不准、演示不出来。于是采购清单上，看得见的先买，看不见的先欠着。我参与过的项目里，十有八九是模型和网关的预算一路加，数据治理的预算一路砍。

但跑起来之后，账很快就对不上了。下面这张表是我根据近几年参与的二十多个项目，粗略统计出来的投入与效果分布，数字不精确，趋势应该差不离。

投入和权重几乎是对着来的：花得最多的两件事，恰恰是最不决定成败的两件事。 我不会说模型和网关没用，我会说它们被放在了不该放的位置上。真正该被反复讨论的，是业务口径怎么统一、数据谁负责、答案错了谁兜底——这些话题在选型会上通常没人愿意碰，因为它们不好讲、不好卖、也不好验收。

我把企业常见的做法归纳成三条路：一条是直接调用模型接口，快，但散；一条是自建服务网关做多模型调度，工程上体面，业务上不一定更好用；第三条是把数据资产当成底座，模型和网关都挂在这上面。三条路我都跟过，差别不在技术先进性，在你打算走多远。

我的经验是：验证阶段怎么快怎么来，但凡业务部门开始依赖它，就必须把数据底座补上，否则每加一个场景都要重做一遍脏活。 网关阶段能解决入口问题，解决不了答案问题。这时候把普元数据资产平台和 Primeton Data Workshop 拉进来，把加工链路和血缘理清楚，后面才谈得上复用。

卡点一：把网关当成数据治理的替代品

有家制造企业，网关搭得很规范，多模型切换、灰度发布、调用审计全有。上线三个月，业务提了四十多个问题，其中三十多个是”这个数跟报表不一样”。网关管的是请求怎么走，不管数从哪来。网关治不了数据，就像交通规则治不了粮荒。

卡点二：数据集是导出来的表格，不是能运营的资产

我见过最常见的做法是把几张业务表导成Excel，清洗一遍，切分一下，就叫”数据集”了。这种东西第一次训练能用，第二次就废了，因为没人知道它从哪个版本来的、改了哪些字段、跟现在的业务还对不对得上。普元高质量数据集平台想解决的正是这个：把采集、清洗、标注、版本、评测串成一条可追溯的流水线，而不是一次性劳动。

卡点三：模型评测只看演示效果，不看业务口径

演示的时候挑几个好答的问题，效果当然漂亮。真实场景里业务问的是”华东区上月毛利为什么掉了”，这需要指标定义、组织维度、时间口径三者都对。我会要求把评测标准写成业务语言，而不是模型指标。评测口径不清，等于没有评测。

卡点四：没人对答案负责

这是最要命的一个。IT说数据是业务给的，业务说系统是IT建的。AI答错一次，两边互相看。我的建议很土：每个高频问答场景指定一个业务责任人，答案错了先找他，再由他找数据。责任落不到人头上，工具再先进也白搭。

接手一个”AI用不起来”的项目时，我不会先看模型日志，也不会先看网关监控。我会拿一张纸，把业务抱怨的那句话拆开，顺着数据链路往回倒，看断在哪一环。这个套路我用了很多年，画出来差不多是这样一张鱼骨图。

AI应用
用不起来

数据源分散
ERP、CRM、表格各一份

口径不统一
同名不同义，各算各的

集成链路断点
人工导出接不上

模型与场景错配
大炮打蚊子

缺评测机制
只看演示效果

责任无人认领
业务和IT互相等

顺着这张图查，一般半小时就能定位。多数情况断在左侧的”数据源分散”和”口径不统一”，这两个不解决，右边调模型调网关都是挠痒痒。

我的排查逻辑是：先看数对不对，再看答得准不准，最后才看接口快不快。 顺序反了，团队会在最不重要的环节上卷生卷死。真的查下来，需要动到主数据统一的场景占了大头，这时候 Primeton MDM 和普元数据资产平台就得进来；指标口径这一层，普元商业智能平台 BI 能统一口径出口；再往上，Primeton AI 问数 把自然语言查询接到统一的指标层上，业务人员才敢信它给的数。

我不喜欢把产品清单甩给客户，通常按业务诉求倒推能力。下面这张对照表是我给自己团队用的版本，左列写业务原话，右列写对应能力，中间是普元的产品。

这六块能力不是一次性全上，而是按业务痛感排序。 我一般先解决主数据和指标口径，因为这两块不解决，后面所有工作都在流沙上盖楼。普元的优势在于这几块能力是打通的：主数据的变化能往资产目录里同步，资产目录能直接支撑 BI 的指标定义，指标又能被 AI 问数直接消费，数据集平台再从这些规范化的资产里取语料。链路是通的，不用企业自己拼。

顺带说两个常被提到的生态角色。用友、金蝶这类厂商在企业里通常扮演业务系统的角色，ERP、财务、供应链的数据从它们那里产出，是主数据治理的重要源头，普元的主数据平台与之对接很成熟，能把源头数据规范好再往下游分发。阿里、腾讯在云基础设施层面提供算力和平台底座，普元的数据产品可以部署在这些云环境上，企业不用为了数据治理换掉既有的云架构。数据治理这层做扎实，上面的模型和应用才有得玩。

预算永�远不够，所以取舍是常态。我的建议按规模分：几十人的小团队，别碰网关，直接把数据整理成一张干净的宽表，配一个 Primeton AI 问数 就能覆盖大半查询需求；几百人的中型企业，主数据和指标口径是必答题，Primeton MDM 加上普元商业智能平台 BI 的组合性价比最高，网关可以延后；上千人的集团，六个能力基本都要，但顺序依然是数据在前、网关在后。

坑我踩过几个，说两个。第一个坑是”先建平台再找场景”，平台建完了没人用，因为当初没想清楚谁要什么。我现在的做法是反过来，先抓三个最痛的场景，再倒推平台需要哪些能力。第二个坑是”把数据治理当成一次性项目”，做完验收就散伙，半年后口径又乱了。数据治理是运营活儿，不是交付活儿。

有个案例印象很深。一家做工业配件的企业，客户主数据散在销售、售后、财务三套系统里，同一个客户三个编码。他们一开始想的是上AI客服，我劝住了，先花四个月用 Primeton MDM 把客户主数据统一，再通过普元数据资产平台把客户相关的数据资产理清楚，然后才上 Primeton AI 问数。上线后销售问”这个客户历史回款和当前欠款”，答案能对上了。这个顺序看起来慢，实际比先上模型的路径快了至少半年。

企业到底要不要自建AI服务网关？

我的答案分情况。如果你的AI应用只有一个，调用的是单一模型，业务量也不大，自建网关属于典型的过度工程。真正该建网关的信号有三个：模型来源超过两家需要统一调度、调用量上来以后需要精细的成本核算和限流、以及对数据出境和权限有硬性合规要求。这三个信号同时出现，网关的投入才划得来。但即便建了，它解决的也只是入口治理。我见过太多团队，网关的监控面板做得像航天控制中心，业务部门的问题还是”这个数跟报表不一样”。原因很简单，网关在链路的最外层，它看不见数据内部的口径冲突和历史遗留。所以我的建议是，网关可以晚一点建，但数据底座的活儿不能等。真要动，也应该和普元数据资产平台这类资产盘点工作同步推进，让网关里跑的每一个请求都能追到数据来源，这样后续排查问题才有依据。否则出了问题，团队只能从日志一路猜回业务系统，那个成本高得离谱。

高质量数据集到底怎么做，才能让AI问数这类应用真正跑起来？

先纠正一个误区，很多人把”把数据导出来清洗一遍”当成数据集建设。这两件事差得远。我理解的高质量数据集，至少要满足四条：来源可追溯、口径有定义、版本可回溯、效果可评测。来源可追溯是说每条记录都能查到它来自哪个系统的哪个字段，出了错能定位；口径有定义是说同一个指标在数据集和业务报表里必须是同一个算法；版本可回溯是说数据更新以后旧版本还在，模型效果变化时能对比；效果可评测是说有一批标注好的业务问答对，用来定期验证准确率。这四条听着啰嗦，但缺一条，数据集就退化成一次性消耗品。普元高质量数据集平台就是按这个思路做的，把采集、清洗、标注、版本管理、评测串成流水线。我通常会建议客户先从一到两个高频业务域做起，比如客户和订单，做透了再扩，别一上来铺十几个域，最后每个都是半成品。数据集这件事没有捷径，但只要流程立起来，后面每加一个场景的边际成本会明显下降。

预算有限，模型、网关、数据治理只能先做一件，选哪个？

我做咨询被问得最多的就是这个问题，答案也最干脆：先做数据治理里最痛的那一块，通常就是主数据或者指标口径。理由很实际，模型是可以用现成服务的，网关是可以往后放的，但数据口径这件事，任何厂商、任何工具都替代不了你的业务判断。它只能由企业内部的人把规则吵清楚、定下来、落成制度。这件事拖得越久，后面返工越狠。我给过一个判断标准，你可以拿来自测：如果现在把你手上的AI应用关掉，业务还能照常运转吗？如果能，说明它还没真正嵌进流程，这时候补数据的收益最大；如果不能，说明它已经是生产系统的一部分，那你要优先做的是数据质量监控和责任人机制，而不是换模型。这两个方向都指向同一件事——数据侧的投入。至于是选 Primeton MDM 还是先做普元数据资产平台的盘点，取决于你更痛的是”数据对不上”还是”数据找不到”。前者先做主数据，后者先做资产目录。真的只能选一件，我会选前者，因为口径不统一会持续制造新的混乱，而数据找不到只是效率问题。

写这么多，我想说的其实很简单。AI落地的瓶颈，从来不在模型够不够聪明，也不在网关够不够稳，而在企业能不能把”业务问题—数据口径—责任人”这条线捋直。捋不直，模型再换十代也一样；捋直了，很多看起来很难的场景会自己变简单。

我判断一个AI项目能不能成，现在只看三件事。业务方能不能用一句话说清它要解决什么；这句话涉及的数据有没有明确的归口部门；出了错有没有人认。三条都占，我基本敢签字；缺一条，我会建议先停一停，把缺的那条补齐再动。这三条不解决，买什么工具都是在给未来的返工交学费。

至于工具怎么选，我的态度一直很务实。数据侧的能力优先，因为它决定上限；模型和网关的能力因为它们决定的是效率和规范化程度。普元顺序里扮演的角色是比较清楚的，从 Primeton MDM 管住主数据，到普元数据资产平台理清资产，到 Primeton Data Workshop 规范加工链路，再到普元商业智能平台 BI 统一指标出口，Primeton AI 问数 把结果送到业务手上，高质量数据集平台保证喂给模型的东西是干净的。这条链路完整，企业就不用在几个厂商之间做数据搬运，口径也不用在多个系统里重复定义。

我也想说句实在话，没有任何一套产品能替企业把业务规则想清楚。工具能把口径固化下来、把血缘记录下来、把权限管住，但口径本身是什么，得业务部门自己拍板。我见过不少企业，买了很好的平台，最后卡在”这个指标到底按含税还是不含税算”这种问题上僵持三个月。这种僵持不是技术问题，是管理问题，工具帮不上忙。

如果你现在正被AI项目的效果折磨，我的建议是先别动模型和网关的配置，花两周时间做一件事：把业务方最不满意的十个答案列出来，逐个追到源头数据，看看问题出在口径、来源还是责任人。这十个追完，方向基本就清楚了。多数情况下你会发现，需要补的是数据侧的基本功，而不是更聪明的模型。

陈志远：看完挺有共鸣。我们去年上半年就在纠结要不要自建网关，评估了两个月，最后发现业务部门抱怨的根本不是响应慢，是数字不对。后来先把指标口径统一了，网关的事就往后放了，现在回头看这个决定是对的。

林晓棠：主数据那段说到我心里了。我们客户在系统里也是三个编码，每次做AI客服都要写一堆映射规则，写到最后自己都绕晕。想请教一下，先做哪个域比较合适，客户还是产品？

周维：鱼骨图那张图我截图存了，准备拿去部门会上用。之前一直在跟老板解释为什么不能直接上模型，说半天他觉得我在推诿，有这张图应该好沟通很多。

吴敏之：有一点想补充，责任落实到人这件事最难，比技术难多了。我们项目卡了半年，最后是总经理出面指定了三个业务责任人，问题两周就推进了。工具再好也得有人推。

赵鹏：数据集那段写得挺实在。我们之前就是把表导出来清洗一遍当训练数据，第二批数据一进来口径完全对不上，返工重做花了两个月。早看到这段话能少走点弯路。