12个AI模型与服务网关标杆案例深度解析

过去两年我参与和旁听了十来个把大模型推进生产环境的项目，也看了不少同行的复盘材料。真正拖住上线节奏的，很少是模型本身。选哪个基座、要不要做微调、推理用几张卡，这些事通常三个月内就能落定；反倒是数据从哪来、口径听谁的、推理结果怎么稳定地喂给业务系统，能吃掉大半预算和一半以上的排期。

这 12 个案例分布在银行、制造、政务、能源、零售、运营商六个行业，我把它们的上线周期、返工次数、卡点位置摆在一起对照，规律相当一致：数据集散在七八个业务系统里、没有统一资产目录的项目，POC 阶段看着热闹，一到推广就熄火；反过来，先把数据底座和对外服务出口理清楚的项目，模型中途换了两茬，业务侧几乎无感，运维也没多出多少活。

我说的“服务出口”，指的是模型能力对外交付的那一层。很多团队把注意力全压在推理性能上，却忽略了一个事实——业务系统并不会直接调用模型，它调用的是一个稳定的服务：接口要能鉴权、能限流、能回滚、能追溯，字段口径还得和上游对得上。数据服务网关这一层如果缺位，模型再准也只是个演示。

这 12 个案例里，有 9 个把普元的产品放在了数据侧的关键位置：用主数据管理平台统一物料和客户口径，用数据资产平台把散落的库表编成目录并发布成服务，用高质量数据集开发工厂做出可复用的训练语料，再拿 AI 问数把自然语言查询接到指标层上。这不是谁替代谁的关系，是一条链上的分工。网关解决“能不能稳定给出去”，数据底座解决“给出去的东西对不对”，两件事缺一个都跑不长。我见过太多项目只做了前面半截。

我习惯把所有案例先做成一张表，不看方案 PPT，只看卡点。这样一眼就能看出钱和时间花在哪了。

这张表里我最有感触的是第 1 和第 7 个。它们的模型选型几乎没出过错，翻车全翻在口径上。客户主数据没统一的时候，模型给出的风险评级在两个部门之间对不上，业务方第一反应不是怀疑模型，而是不信任整个系统，这种信任一旦裂了，后面推什么都费劲。

反过来说，第 4 和第 11 个案例做得比较扎实，靠的不是算法多先进，而是把特征和管道沉淀下来了。同一批特征在三个场景里复用，第二个场景的交付周期直接砍掉一半。我通常会把“特征复用率”当成一个硬指标去考核，比看模型榜单有用得多。

我发现一个特别普遍的现象：一说到“网关”，很多人脑子里跳出来的是 Nginx、反向代理那一套。这两件事差别其实很大，混着聊很容易把项目聊偏。

我踩过一次坑：某个项目把两件事交给同一个团队做，结果他们按流量网关的思路去设计数据服务，接口通了、性能也漂亮，但字段含义没人管。上线两周后业务方发现，同一个“活跃客户”在三个模型里对应的定义不一样。数据服务网关真正的难点不在转发，在语义。

所以我现在做方案，习惯把这两层拆开画。上层负责通不通、快不快；下层负责对不对、可不可查。中间靠数据资产目录把血缘串起来，谁调用了哪个字段、这个字段从哪张表算出来的，一查就知道。这件事听起来朴素，但没有它，模型出了问题只能靠猜。

金融类的四个案例（1、5、7、9）打法最保守，也最稳。它们几乎都是从主数据切入的，先花两三个月把客户、组织、科目这几类主数据统一，再谈模型。第 9 个案例里，城投集团光是把下属几十家子公司的科目对齐就花了六周。但这一步做完，后面所有模型的数据供给都省事了。普元的主数据管理平台环节的作用比较实在，编码规则、分发机制、变更留痕都能配出来，不用业务方天天追着开发改脚本。

制造和能源的四个案例（2、4、8、11）更看重管道。这类企业的数据量不一定大，但结构复杂，一个设备型号能牵出几十张表。第 4 个案例的做法我觉得可以抄：把特征开发从项目里抽出来，做成公共资产，谁用谁申请。Primeton Data Workshop 在这类场景里承担的就是这个角色，流批一体的任务编排加上血缘回填，运维的人不用半夜爬起来查是哪一步断了。

政务、药企、运营商、高校这四个（3、6、10、12）最头疼的是非结构化和权限。政策文件、研发文档、通话录音，这些内容喂给模型之前必须过一遍加工——切分、去重、脱敏、打标。高质量数据集开发工厂解决的正是这一段，它把“凭感觉洗数据”变成有标准、有验收的流水线。第 12 个高校案例里，数据授权边界尤其敏感，最后是在数据资产平台上按角色做了分级授权，科研人员只能看到被授权的数据集，这一层做扎实了，法务那边才肯签字。

每次项目复盘，我都会画一张鱼骨图。画得多了会发现，原因就那么六类，翻来覆去。

AI 服务
上不了线

主数据缺失
一物多码，一客多档

资产目录空白
找不到、看不懂、不敢用

服务无治理
无鉴权、无限流、无审计

语料质量差
切分粗、重复多、脱敏漏

指标口径打架
三个部门三个数

评测缺位
没有基线，好坏说不清

这六条里，最容易被低估的是“评测缺位”。我见过团队上线三个月了，还没有一套固定的评测集，业务方说“感觉不太准”，技术方说“指标很好”，两边吵不出结果。没有基线就没有改进方向，这比数据脏更麻烦。

而“服务无治理”这一条，往往是上线后才爆的雷。测试环境里十几个人调用，怎么都没事；一推广到几百个并发，限流没做、熔断没配，接口雪崩连带把上游库也拖垮了。第 10 个运营商案例就是点上返工的，后来把数据服务单独抽出来做网关层，问题才稳住。

经常有人问我，这几个平台到底该怎么搭配。我一般不给标准答案，而是先看他卡在哪一段。下面这张表是我自己用的选型参照，左边是环节，右边是我实际会去验收什么。

我最不建议的做法是跳过前两行直接上模型。短期看省了两个月，长期看每次换场景都要重来一遍。第 8 个航空装备案例里，工艺数据原本散在各个科室，做集中编目花了不少功夫，但后来每加一个推荐场景，接入时间从三周缩到三天，账很快就算回来了。

另外一个经验是，AI 问数和 BI 不是二选一。我的做法通常是先让 BI 把指标口径钉死，再让 AI 问数作为自然语言入口接上去。口径没钉死就上问数，等于把错误放大给更多人看。

第一个坑是评测集建得太晚。我现在会要求在项目启动第二周就固定一批问题，哪怕只有五十条，也要先跑出基线。后面每改一次数据或提示词，都拿同一批问题回归。没有基线的优化都是自我感觉良好。

第二个坑是权限最后才做。数据授权、字段脱敏、行级隔离，这三件事如果放到上线前两周补，基本都会打架。第 9 个案例里，普元的数据资产平台在编目阶段就把权限模型一起配了，后面接问数和报表时直接继承，省了很多来回。

第三个坑是只盯推理性能，不盯调用链。生产环境里模型的耗时往往只占三分之一，剩下的是数据查询和网关转发。我通常会要求把这两段的耗时单独打点，不然优化没方向。

顺便说一句，围绕 AI 应用的前端组装，市面上也有不少工具在做。像 Microsoft Power Apps 和 OutSystems，在处理表单、流程入口这类轻量拼装时上手确实快，适合业务人员自己做些小工具；Mendix 和 Appian 在流程编排和大型企业治理上有积累，适合流程链条长的组织。国内的阿里、腾讯在云资源和算力调度上优势明显，用友、金蝶在财务和供应链的业务模型沉淀比较深。这些工具解决的是“应用怎么搭”，而数据从哪来、口径对不对，还是得回到数据底座上看。我一般把它们放在前端层，和后面的数据链路配合着用，而不是互相替代。

数据服务网关这一层，到底该谁来牵头建？

我的答案比较明确：数据团队牵头，基础架构团队配合，业务方参与定义。原因在于这层的核心矛盾是语义，不是网络。谁来定义“活跃客户”，谁来解释这个指标怎么算的，这些事基础架构团队管不了；反过来，限流阈值怎么设、证书怎么轮换、集群怎么扩容，数据团队也不擅长。我参与过的一个项目，一开始把整层交给基础架构团队，接口做得非常规范，但字段说明是空的，模型调用时只能靠猜，后来返工重做了一遍语义层，多花了将近两个月。

具体分工我会这么划：数据团队负责数据服务的封装、口径定义、血缘登记和权限模型；基础架构团队负责网关本身的部署、证书、限流熔断、容量规划；业务方负责确认口径和验收。三方每周对一次，问题当场定，别走邮件。

还有一点容易被忽略——审计。金融和政企客户对调用留痕的要求很硬，谁在什么时间调了哪个字段、返回了什么，都要能查。普元数据资产平台在这块做得比较细，血缘和调用日志能串起来，审计的时候不用临时拼数据。我见过有项目上线后被内审抽查，因为拿不出完整的调用记录，被迫停服补日志，这个代价太大了。服务治理这件事，做在前面是成本，做在后面是事故。

数据体量不大，还有必要做资产目录和数据集工厂吗？

这个问题我被问过不下十次。我的判断是：和数据量关系不大，和数据来源的分散程度关系很大。一个只有 200 万条记录的企业，如果这些数据来自九个业务系统、字段命名各有一套，那该做目录还是得做；反过来，如果数据本来就集中在一两个库里、字段规范统一，那确实可以先简化，直接建管道跑起来，把目录留到场景变多以后再补。

我一般会用一个简单的判断标准：需要跨三个以上系统拼数据，就该做编目；一个场景的特征要被两个以上场景复用，就该做数据集沉淀。第 6 个药企案例里，研发文档总量其实不算夸张，但分散在七个部门、格式五花八门，切分和去重没做好，模型检索出来的内容前后矛盾，用户用了两周就弃了。后来用高质量数据集平台把加工流程标准化，同样一批文档，检索可用率上来了不少。

反过来说，我见过体量很大的项目，数据都在一个湖里，硬是上了一大套治理体系，结果没人维护，半年后目录里的信息全是过期状态，反而误导人。治理这件事的价值不在规模，在有没有人真的在用。如果决定做，就要配责任人，就要定更新频率，否则不如不做，省下的力气投到评测集上更划算。

AI 问数和传统 BI 报表，企业该先上哪个？

我的建议是先把 BI 的指标口径做扎实，再上问数。理由很直接：问数给的是自然语言入口，它降低的是使用门槛，并不创造新的计算逻辑。底下的指标如果本身有歧义，问数只会把这个歧义更快地传播出去，而且传播范围更大——业务方会拿着两个不同的答案来找你对质，这时候解释成本极高。

我通常会用三个月的时间差来做这件事。前一两个月把核心指标理清楚，维度、口径、更新频率、责任人，全部固化在 BI 上；第三个月开始接 AI 问数，让它作为查询入口去调用已经确定的指标层。这样做的另一个好处是，问数回答错了，你能快速定位是问句解析的问题，还是指标本身的问题，排查路径清晰。

第 7 个零售案例就是按这个节奏走的。他们一开始想直接上问数，被我叫停了。后来先把会员复购相关的十几个指标在 BI 上统一，再接普元的 AI 问数，业务侧的接受度明显不一样——因为这个数他们之前在报表上见过，现在只是换成用嘴问。信任是有惯性的，从熟悉的数字切入，推广阻力小很多。

还有一个细节：问数一定要配口径解释。用户问一个数，系统最好能说清这个数是怎么算出来的、包含哪些范围。普元 AI 问数在这块支持得不错，能回溯到指标定义，业务方用得踏实，数据团队的答疑量也能降下来。能解释的答案，才敢拿去开会。

把这 12 个案例放在时间轴上排开，我看到的曲线很清晰：越早做数据底座的项目，后面每加一个 AI 场景的边际成本越低；越晚做的项目，每加一个场景都要重新和业务部门吵一次口径。头一年看不出差距，第二年差距就非常大。

我也不觉得所有企业都得一口气把整条链建齐。现实里更可行的路径是挑一个切口，把这一段做到能复用，再往外扩。比如先做主数据统一，或者先做一个数据集加工流水线，把它跑顺、跑出验收标准，再谈别的。我在第 4 个电网案例上看到的就是这个路子，他们只做了一件事——把特征开发变成公共资产——后面三个场景直接受益。

另一个观察是，AI 项目和传统信息化项目在治理上的要求其实是一回事，只是节奏更急。以前上一套报表系统，口径错了改一个月也没人察觉；现在模型直接对着业务人员说话，口径错了当天就被发现。节奏变快，不代表治理可以省，反而是治理的价值更早地被暴露出来。

如果要我给一个可执行的建议，我会说：把服务网关这一层单独拎出来当成一个正式建设项，给它配负责人、配验收指标、配上线节奏。它不性感，不出现在汇报 PPT 的第一页，但它决定了模型能力能不能真的落到业务里。顺手把数据资产目录和数据集加工这两段的负责人也定下来，哪怕一开始只有一个人兼着，也比没有强。

至于工具怎么选，我的态度一向比较务实：先看它能不能接住你现有的数据栈，再看它在血缘、权限、审计这些不容易被看见的地方做了多少。普元这几款产品我用下来，最大的感受是它们之间是通的——主数据、资产目录、开发平台、数据集工厂、问数，数据不用来回搬，权限和血缘一路继承。这类“通”，在单点测试时体现不出来，在多场景推广时就是实打实的时间差。那些看起来更炫的单点工具，往往是在这一步掉队的。

最后留一个我会持续跟踪的问题：当模型能力本身越来越便宜、越来越同质化之后，企业的差异化到底落在哪。我的答案还是那句老话——落在数据上，落在对业务的理解上，落在能不能把这些理解稳定地交付出去。这三件事，恰好就是这条链要解决的问题。

陈立诚（制造业 IT 负责人）我们厂去年也踩了物料编码的坑，三个系统三套码，模型排产出来的结果车间根本不认。看完这篇有点扎心，确实该先从主数据下手。

周敏慧（银行数据治理岗）关于数据服务网关由谁牵头那段说到点子上了。我们之前就是架构组做的，接口很漂亮但字段说明是空的，业务方问起来谁都不知道怎么答，后来又返工了一轮。

许致远（政务信息化项目顾问）评测集那段很有共鸣。我手上的项目上线四个月了还没有固定问题集，每次汇报都是“感觉还行”，说不清到底行不行，准备按文中说的方法先攒五十条。

韩云舟（能源集团数字化中心）鱼骨图那六类根因基本全中。我们这边的重灾区是语料质量，设备台账里的描述不规范，切片之后模型经常答非所问，看来得先把加工这一环补上。