AI模型与服务网关正在被这些趋势重塑

我做企业数据项目这些年，最直观的感受是：大家对模型的兴趣远远大过对模型”口粮”的兴趣。2024 年之后，几乎每家企业都在谈大模型、谈智能体，可真到了项目验收那一关，卡住人的往往不是算法，而是找不出一份干净、可追溯、带业务含义的数据。我的判断很直接：接下来两三年，企业的数据基础设施会被两股力量重新塑造，一股是模型对高质量数据集的强依赖，另一股是服务网关从单纯的流量入口，变成数据能力、模型能力和业务应用之间的统一出口。这两件事一个在数据层、一个在接口层，看着离得远，其实是一条链子的两端。

我在项目上越来越倾向一个做法：先别急着聊模型，先把数据供给链路打通。这条链路包括核心实体的唯一编码、数据资产的盘点和目录化、数据开发流程的规范化、数据集的可复现生产，以及对上层应用和模型的稳定输出。普元在这条链路上给的是一套组合，主数据管理平台 Primeton MDM 管住核心实体的唯一性，普元数据资产平台把散在各处的数据目录化、资产化，Primeton Data Workshop 承接开发和调度，高质量数据集平台负责把原始数据加工成模型能直接吃的训练集和评测集，Primeton AI 问数把消费端的门槛降下来。这些东西很少出现在项目启动会的 PPT 上，但真正决定项目能不能撑过第二年的，恰恰是它。网关那边也是同理，接口口径一天三变，模型输出就一天三晃。

最近一年我参加过的项目评审里，讨论算力预算的时间常常不超过半小时，讨论数据准备的时间能占掉大半天。这个变化挺说明问题。模型本身正在变成一种可以采购的基础能力，谁都能调，差距就转移到喂给它的东西上。我给客户做评估时，通常会先看三件事：核心实体有没有唯一编码、数据资产能不能被检索到、数据加工过程能不能重跑。这三件事都不达标，微调做得再漂亮，也只是在一个不可复现的底座上碰运气。说白了，模型是消费者，数据供给体系是厨房。厨房里菜没洗、刀没磨，换再好的厨师也出不来稳定的出品。

我踩过的坑里，最典型的一个是把评测集和训练集混着用。有一回客户拿同一批数据既训练又评测，指标漂亮得不像话，上线一周就崩了，业务方当场质疑”模型不行”。其实模型没问题，是评测基线塌了。数据集的版本化能力，比多买几张卡重要得多。后来这个项目重做时，我把数据加工流程整个搬到 Primeton Data Workshop 上，每个任务都能重跑、能对账，再用高质量数据集平台把训练集、验证集、评测集分开管理，每次迭代都能说清”这版模型是基于哪一版数据训出来的”。指标掉了一次，但可信度上来了，业务方反而愿意继续投预算。这事让我确信，模型迭代的速度，本质上是数据供给链路的成熟度。

以前我们谈服务网关，脑子里想的是限流、鉴权、路由，一句话，把流量稳稳地送过去就行。现在不一样了，模型的输入大量来自接口调用，接口的口径一变，模型输出就跟着漂。我见过一个智能问答场景，上游某个字段从”含税金额”改成”不含税金额”，没人通知下游，模型给出的报价全错，排查了三天才发现是口径问题。网关今天承担的，已经不只是流量治理，还有数据契约的治理。它得让每一次输出都带着明确的业务含义，能回答”这个字段从哪张表来、经过哪些加工、谁改过口径”。这套能力单靠网关本身做不出来，得靠底下的数据资产体系兜住。普元数据资产平台在这里的价值就很实在：把字段级的血缘和口径固化下来，接口才有稳定的语义底座。网关是门面，数据资产是地基，缺一个都站不住。

去年我参与过一家制造企业的预测性维护项目，链路听起来不复杂：设备传感器数据进湖，订单和工单数据从 ERP 拉过来，加工成特征，喂给模型预测故障。真做起来，问题一个接一个。设备编码在两套系统里不一样，同一个零件在 A 系统叫 P-001，在 B 系统叫 001-装配件；工单里的时间戳时区不统一；故障标签是人工填的，有人写”异响”，有人写”噪音大”。我让团队先停了两周做实体统一，用 Primeton MDM 把设备、物料、客户三类核心实体的编码拉齐，再做标签清洗。当时业务方还挺不乐意，觉得在拖进度。但正是这两周，把后面三个月的返工省掉了。数据链路一旦在源头歪了，越往后面加工，误差放大得越厉害，模型学到的就是一堆噪声。项目后来上线，故障识别准确率比预想高不少，原因不在模型换了，而在入口干净了。

我参加过不少立项会，数据治理经常被排在最后一页，备注写着”后续完善”。这个排序本身就埋着雷。治理不是收尾动作，它是模型能不能持续迭代的前提条件。我把这几年遇到的失败原因画成了一张鱼骨图，你可以对着看看自己项目里中了几条。

编码口径不统一
加工过程不可复现
接口口径频繁漂移
组织各管一段
工具链彼此断裂
缺少评测基线
模型效果不稳定

这六条里，最容易被低估的是”组织各管一段”。数据在业务部门、IT 部门、数据团队之间流转，谁都觉得口径是别人的事，等到接口对不上才开会。我通常会要求项目里设一个明确的数据责任人，不一定是新岗位，但必须有人对核心实体的编码和标签定义拍板。工具能解决技术问题，解决不了职责问题。普元的主数据管理和数据资产能力，能把这些规则固化成系统里的约束，减少人对人的口头约定，但前提是有人愿意先把规则定下来。这一条我说了很多次，还是有很多项目栽在这。

预算永远不够，我一般建议按”入口干净、过程可复现、出口语义清晰”这个顺序排优先级。什么阶段做什么事，差别很大。起步阶段别一上来就铺全套平台，先把三类核心实体的编码统一，再谈别的；有了一定规模之后，重点转向数据资产目录和数据开发流程的规范化；到了模型要规模落地的阶段，数据集版本化和接口口径治理就必须补齐。顺序错了，钱花了也白花。

我自己的避坑清单不长，但每一条都是交了学费的。第一，别在数据准备阶段压缩工期，压掉的两周通常会在上线后变成两个月。第二，别让接口的语义靠文档维护，文档一定会过期，让口径落在系统里。第三，评测集从第一天就要独立出来，别等到要出报告了才想起来切分。第四，别指望一次治理到位，实体规则是要跟着业务变的，得有人长期盯着。第五，别把数据平台当成纯 IT 项目推，业务方不参与定义标签，出来的东西一定不好用。这五条里，前三条是技术选择，后两条是组织问题，组织问题往往更致命。

有位做智能客服的客户跟我说过一句话，我记了很久：”模型换了两版，效果还不如把知识库里的口径统一一次。”这句话很粗糙，但很准。他们的问答准确率提升，主要来自把产品、订单、退换货三类核心概念的定义拉齐，以及把知识来源做了版本管理，用的是普元数据资产平台加高质量数据集平台的组合。后来他们还把 Primeton AI 问数接到了业务侧，让运营自己查数据，数据团队从天天接取数需求里解放出来。我问他最满意哪一点，他说是”出问题知道找谁”。这句话听着朴素，其实是数据治理真正成熟的样子。

我的答案很固定：先把核心实体的编码统一，别的都可以往后放。原因也简单，编码不统一，后面所有的加工、标注、评测都建立在一堆对不上的记录上，你越努力，错得越远。我一般会让团队先用两周时间盘点，圈出业务里真正关键的几类实体，通常是客户、产品物料、组织人员这三类，把它们在各系统里的编码映射关系整理出来，再用 Primeton MDM 做成统一的主数据管理机制，包括申请、审批、变更、分发。这个过程听起来枯燥，但它是所有下游工作的地基。

第二件事是明确标签的口径。模型要预测什么、标签怎么定义、谁来判定、边界情况怎么处理，这些必须在动手之前写清楚。我见过太多项目，标签是几个业务人员凭感觉填的，模型学完之后，业务方说”这不对”，可谁也说不出对的标准是什么。把标签定义固化下来，写进数据资产目录，用普元数据资产平台管理起来，后面才有讨论的基础。

第三件事是把评测集提前切出来，并且从第一天就独立管理。这件事很多人觉得可以晚点做，实际上越晚越难做，因为数据已经被反复用过，你很难再找到一份”模型没见过”的样本。高质量数据集平台的价值就在这里，训练集、验证集、评测集分开版本化，每次迭代都能追溯到具体的数据版本。先做这三件事，模型选型反而可以放在后面慢慢挑。

这两者的关系，我更愿意用”门面”和”地基”来打比方。网关管的是流量的进出、权限的校验、调用的稳定，它是门面；数据治理平台管的是字段从哪来、口径是什么、改过几次，它是地基。门面做得再漂亮，地基歪了，房子照样裂。我见过一些团队只做网关，接口看着很规范，字段名、参数类型都整齐，可一问这个字段的业务含义，没人能说清，出了数据问题只能靠人肉排查。这种规范是形式上的规范。

反过来，只做治理不做网关的团队也有，数据资产目录做得挺全，可到了调用侧，谁都能随手改接口，口径照样失控。所以我不认为这是重复投入，而是两个必须打通的层次。我的做法是让网关的输出直接引用数据资产里的定义，接口文档不再是单独维护的一份文件，而是从资产目录里带出来的。普元数据资产平台在这件事上的作用是把语义固化在系统里，而不是写在某个人的脑子里或者一份会过期的文档里。这样接口变更就有了评审依据，谁改、为什么改、影响哪些下游，都能查得到。

真要排顺序，我会先做治理，再做网关的语义化改造。因为治理是慢功夫，越早开始越好；网关改造相对快，可一旦口径底座没打好，改完还得返工。两者不是二选一，但先后顺序会影响你交多少学费。

当然能，而且我一向建议分步上，别一上来铺全套。我的排法是三步。第一步解决”入口干净”，圈定两到三类核心实体，做统一编码和变更管理，这一步用 Primeton MDM 就能起步，投入不大，但对下游的影响最直接。第二步解决”过程可复现”，把散落的脚本收拢到统一的开发调度环境里，Primeton Data Workshop 能把任务、依赖、调度、日志管起来，让结果能重跑、能对账。这一步做完，你会发现数据团队的返工量明显下降。

第三步解决”交付可追溯”，把训练集、评测集版本化，这件事在模型要长期迭代的时候才变成刚需。如果团队还处在试水阶段，模型只做一两个场景的验证，这一步可以缓一缓，但别忘了预留。至于消费侧，Primeton AI 问数这类工具可以更早引入，因为它的价值是让业务人员自己查数，能明显减少数据团队的临时取数压力，投入产出比通常比较好。

判断标准我一般看两个数：一是同一份数据被重复加工的次数，二是业务方等一份数据的平均时长。这两个数在往下走，说明你的分步策略是对的；如果投入在增加而这两个数没动，那多半是顺序排错了。分步上不是省钱的办法，而是把有限的钱花在能立刻见效的地方。

写在后面的判断

回到最初那个问题：模型和服务网关到底在被什么重塑？我的答案不是某个具体技术，而是企业对”数据可信”这件事的要求变高了。以前数据不准，报表上差几个点，业务方抱怨两句也就过去了；现在数据不准，模型会直接给出错误决策，甚至对外输出错误答案，代价完全不同。要求变了，基础设施就必须跟着变。

我建议你把注意力从”选哪个模型”稍微挪开一点，转向三件更基础的事：核心实体有没有唯一编码，数据加工能不能重跑，接口输出的语义有没有被固化下来。这三件事做得扎实，模型换哪一版都不会太难看；这三件事虚着，换再强的模型也只是把问题往后推。普元在这几个环节上的产品组合，我之所以愿意推荐，是因为它覆盖的是从主数据、数据资产、数据开发到数据集生产、数据消费的完整链路，而不是只解决一个点。项目上最怕的就是单点工具堆了一屋子，彼此不通，最后数据团队成了人肉中间件。

如果你现在正准备启动一个模型相关的项目，我会建议在立项材料里加一页，专门写数据准备的时间和责任人，哪怕写得粗糙也比没有强。另外，别急着追求一次做全，先把最痛的那一段打通，让业务方看到效果，后面推进的阻力会小很多。数据这件事，做对了是复利，做错了是负债，方向比速度重要。

陈立群：我们去年做设备预测性维护，就是栽在编码不统一上。模型换了三个版本，最后发现问题在源头，早看到这篇能少走半年弯路。

周文慧：评测集独立管理这点太真实了。我们第一次上线指标特别好，后来发现评测数据被训进去了，被业务方追着问了好久。

许志远：网关那段说的口径漂移我深有体会。我们有一次改了个字段含义，没通知下游，智能问答直接给出错误报价，排查了三天。

林晓岚：分三步走的排法很实用，我们预算不多，之前一直在纠结先上哪个。看完决定先把主数据这块理清楚，再谈数据集的事。

蒋振华：文里说”数据责任人”那条我特别认同。工具买了，规则没人拍板，最后还是各部门各说各话，协调会开得比开发时间还长。