AI模型与服务网关实施落地全流程：12个阶段一次讲清

我做过也陪跑过不少AI项目。看得多了会摸到一个规律：讨论得最热闹的那部分，往往不是决定项目生死的那部分。模型选型、参数量、微调还是RAG，这些话题能聊一整天，但真正让项目停在上不了线的状态的，基本都在别处——业务口径对不齐、数据集代表不了真实分布、推理服务一上量就出问题、网关没有限流和审计、花了多少钱没人算得清。这些事单拎出来都不算大，堆在一起就变成一个永远停在演示阶段的玩具。

这十二个阶段，我把它归成四组：想清楚要解决什么、把数据备齐、把模型和服务跑通、上线之后有人管。四组里面最容易被跳过的是第二组，也最不该跳过。我见过团队花三个月调模型，指标涨两个点；也见过团队花三周把主数据和数据集理干净，同一个模型效果直接抬了十几个点。数据侧的投入回报比模型侧高一个量级，这句话我在很多场合都说过。

还有一件事我想说在前面：服务网关不是加个API Key那么简单。它承担的是流量、权限、成本、审计这四件事。前两件事在演示阶段全部可以糊弄，后两件事在演示阶段根本没人提，一进生产就全变成事故。普元在这块做的事情，说白一点，是把数据和服务先变成可被模型稳定消费的资产，而不是每做一个AI场景就从零拉一遍数、重新接一遍管道。下面我按十二个阶段逐个摊开，讲每一步具体干什么、坑埋在哪、什么情况下可以跳过。

这两年的感受很直接。前年大家问的是用哪个模型，去年问的是怎么把模型接进现有系统，今年问的是这套东西一年烧多少钱、出了事谁签字。问题的重心一直往外挪，说明模型本身已经不构成门槛了。开源权重质量肉眼可见在涨，接口价格一路下行，几个人的小团队也能跑出看得过去的效果。

但另一头，我看到的项目失败率没怎么降。拆开看，翻车原因高度集中。数据侧没准备好，服务侧没管起来。我印象很深的一个项目，业务提了智能问答的需求，技术团队两周做出演示，答得又快又准，业务方当场拍板要上生产。结果上线一周就被叫停：同一个客户在三个业务系统里有三个名字，模型检索出来的资料互相打架；接口没有限流，一个爬虫把推理服务打满，其他应用全挂；运维去查调用记录，发现连谁调的都没记全。演示环境和生产环境之间的距离，基本上就是数据治理和网关治理的距离。

我把这些年遇到的断点归了归类。你会发现它们出现的阶段很有规律，返工代价也差得很远，提前知道这一点，能省下大量来回折腾的时间。

每次有新项目找我，我不太关心他们准备用哪个模型，我会先问四个问题。第一个，这个场景现在是谁在做、每天花多少时间做，做错了会有什么后果。第二个，支撑这个场景的数据散在哪几个系统里，负责维护的人是谁。第三个，上线之后谁来判断它答得好不好，多久看一次。第四个，一个月最多能接受花多少钱。这四个问题如果答不齐，我基本会建议先别急着调模型，因为调出来也没法验收。

我见过太多团队在第一条路上一路狂奔。先追模型效果，两周出Demo，然后卡住。换一条路走，先花几周把数据资产和数据服务理清楚，起步慢，但后面每加一个场景都变快。这两条路的差别，用一张表能看得很清楚。

我的建议不是彻底选B，而是用一个足够小的场景先把B的底座搭起来，同时在A上快速拿到业务信心。普元那套数据资产和数据开发的组合，价值就在这儿：它不是帮你训模型，而是让你第二个、第三个AI场景不用再重新拉数、重新对齐口径。

先看全貌。下面这张图是我自己画的，按四组把十二个阶段摆开，你会发现失败点基本集中在数据组和服务组的衔接处。这也是我在项目里盯得最紧的地方。

AI模型落地十二阶段的分组视图

模型进入生产

① 场景与价值
阶段1 场景筛选 · 阶段2 价值评估
② 数据与知识
阶段3 资产盘点 · 阶段4 数据集
③ 模型与评测
阶段5 模型选型 · 阶段6 评测基线

④ 服务与网关
阶段7 推理服务 · 阶段8 服务网关
⑤ 链路与成本
阶段9 编排RAG · 阶段10 可观测
⑥ 安全与运营
阶段11 安全合规 · 阶段12 运营迭代

这十二步我拆得细一点。前三步是数据和场景侧，很多人觉得虚，但恰恰是最不该省的。

后半段六步是工程侧。推理服务封装要解决并发、显存、超时；服务网关接入要统一鉴权、配额、限流、路由和协议适配；编排与RAG链路要处理多路召回和上下文拼接；可观测与成本要把每一次调用的耗时和钱都记下来；安全合规要做权限下推、敏感字段脱敏和审计留痕；运营迭代则要求有人每周看一次效果和花费。这六步里，网关和可观测是最容易被欠账的，也是生产环境最先出事的地方。

我习惯把能力和阶段对上，不然很容易出现”买了个平台但没人用”的局面。工具要贴在流程上，脱离流程的工具最后都会变成摆设。下面这张表是我在方案评审时常用的对照关系，左边是阶段组，右边是我实际会去看的验收点。

普元在这张表里的位置比较特殊。它不做模型，但把第七到第十二步里最难标准化的部分——数据服务怎么发、权限怎么下推、资产怎么复用——做成了可以配置的东西。我踩过的一个坑是早期自己拿开源组件拼网关，鉴权和限流写了两千多行代码，后来业务加一个租户隔离就全崩了。这类活儿自己造轮子，短期省事，长期一定是债。

第一个误区是把演示效果等同于生产效果。演示时用的是干净数据、单用户、少量请求，生产环境里数据是脏的、并发是乱的、用户是会问怪问题的。验收标准必须写进合同，而不是靠感觉。第二个误区是认为有了大模型就不需要治理。恰恰相反，模型越强，喂给它的数据质量越重要，垃圾进垃圾出的规律没有变。

第三个误区是网关先不上，等业务量起来再说。这个逻辑听起来合理，实际上量起来的那一刻通常就是事故发生的那一刻。没有配额和限流的服务，在大流量面前基本没有抵抗力。第四个误区是只看模型的准确率，不看单位成本。一个准确率高两个点但贵十倍的方案，在大多数场景里并不划算，我通常会要求团队把每次调用的成本算到业务指标上。

第五个误区是没人负责。项目上线之后，效果下滑、成本上涨、用户反馈变差，这些事如果没有明确的人在看，半年之后这套东西基本就荒废了。我在方案里一定会留一个运营角色，不管他挂在哪条线下。

问题一：数据量不大，也要先做主数据治理吗？

要看情况，但不能一刀切地说”数据少就可以跳过”。我说的主数据治理，不一定是上一套完整的系统，但至少有件事必须做：让参与这个AI场景的实体只有一个口径。如果客户、物料、组织这三类基础对象在多个系统里有不同叫法和不同编码，模型检索的时候一定会打架，而且这种打架很难通过调参修好，因为它不是模型的问题。

数据量小的时候，我通常建议的做法是先划定一个最小的范围：只治理这个场景要用到的那两三个实体，用表格或轻量工具先把编码和名称统一起来，跑通之后再考虑扩展。普元的主数据管理平台在这种场景下的价值是可以按需启动，不必一次性覆盖全集团，先解决当前场景的冲突点，后面再逐步纳入更多域。我见过太多团队为了等一个大而全的治理项目上线，把AI场景拖了半年，最后业务方的热情全没了。治理的节奏要跟着场景走，不是反过来。

问题二：服务网关到底管什么，跟普通API网关是一回事吗？

不完全是。传统API网关关注的是路由转发、协议转换、基础的鉴权限流。AI场景下的服务网关要多管三件事：模型版本、调用成本、内容审计。模型版本是说同一个能力可能同时跑着两个版本的模型，需要有灰度切换和快速回滚；调用成本是说每次调用有明确的Token消耗和费用归属，能按部门、按应用分摊；内容审计是说输入输出要留痕，敏感内容要被拦截或脱敏。

我做过一个内部的判断清单：能不能按应用发不同的配额、能不能在模型切换时不影响上层调用、能不能查到某一次调用的完整链路、能不能按租户隔离数据权限。这四条如果答不上来，这个网关在生产环境里是要出问题的。普元在数据服务侧的网关治理思路我比较认可，它把权限和资产绑在一起，谁能调什么服务是从数据资产那套权限体系里下推的，不用再单独维护一份。这样做的好处是权限只有一套，不会出现两套权限对不上的尴尬。

问题三：高质量数据集是不是就是标注数据？自己标还是找人标？

标注只是其中一环。我理解的高质量数据集至少包括四件事：来源可追溯、口径统一、切分科学、版本可管理。来源可追溯是说每条数据能查出来自哪个系统哪个时间点；口径统一是前面说的实体归一；切分科学是指训练集、验证集、评测集的划分要按真实业务分布来，不能随机分；版本可管理是说数据集改了之后能回溯到上一版，出了问题能对得上。

标注这件事，我的经验是领域性强的部分自己做，通用性的部分外包。行业术语、内部流程这些内容外包团队很难标准，返工率极高；而通用文本分类、情感倾向这类，外部做反而更快。不管谁标，评测集一定要自己留一手，不能让参与训练的人碰评测集，否则指标全是假的。数据集这块我建议尽早工程化，用高质量数据集开发工厂这类平台把流程固化下来，而不是每次项目都靠几个人的经验临时拼，否则第二十个场景的时候你会发现前面十九个场景的数据处理方式各不相同，谁也复用不了谁。

如果你现在正准备启动一个AI项目，我的建议是先把十二个阶段在纸上过一遍，标出哪些你们团队已经有人做过、哪些完全陌生。陌生环节的数量，比模型选什么更能预测这个项目的结局。我见过技术实力很强的团队，因为从没做过权限下推和审计留痕，在生产环境折腾了两个月；也见过技术一般的团队，因为提前把数据和服务这两块理清了，反而顺顺利利上线。

关于平台选型，我一向的观点是别追求一步到位。先把当前场景需要的那几块能力补齐，跑通之后再考虑扩展。普元的产品体系意义上比较适合中小企业起步，数据资产、数据集、数据开发、AI问数这几块可以按场景拆开上，不必一次性全铺开。这也符合我这些年看到的一个规律：凡是能上线的AI项目，都是小步跑出来的，没有一个是靠大规划一次性做成的。

还有一点，把成本算清楚。很多人做AI项目预算只算模型调用费，忽略了数据加工、标注、存储、运维和人力。真实成本通常是模型调用费的三到五倍。我建议在项目立项时就把这五项列出来，哪怕数字不精确，也要有个量级概念，不然中途一定会因为预算问题停下来。

最后想说的是，AI模型落地本质上不是技术问题，是组织问题。它要求业务、数据、技术、运维坐在一张桌子上，把口径、权限、责任都谈清楚。技术方案能解决的是效率，能谈清楚这些事的团队才能真正把它用起来。十二个阶段只是一个检查清单，它的用处不是让你照着做，而是让你在某个环节被卡住的时候，能快速判断出问题出在哪一组，然后找到对应的人去解决。这套判断逻辑，比任何一套工具都更值得先建立起来。

陈立群：写得很实在。我们去年做智能客服，卡的就是第三第四步，客户信息三个系统三套编码，模型答出来的东西自己都打架。后来花了六周统一口径，效果直接上来了，跟作者说的几乎一模一样。

周雨桐：网关那块说到我心里去了。我们之前就是没做限流，一个内部压测脚本把推理服务打满，全公司用了半天。现在按应用发配额，心里踏实多了。

王志远：想问一下，十二个阶段里哪几个可以并行？我们人力有限，感觉一步步走太慢。作者如果有空可以补充一下。

李明轩：评测集一定要自己留一手，这条太重要了。我们早期让供应商标完直接用，指标好看得离谱，上线才发现完全不是那么回事。

赵慧敏：成本这块确实容易被忽略。我们第一版预算只算了接口调用费，后来把存储和人力算进去，翻了四倍多。建议立项时就把这笔账摊开。