别人的学费别白交：AI模型与服务网关复盘集

我做企业数字化项目十几年，最近三年几乎全部精力都压在同一个问题上：怎么让大模型真正长在业务系统里，而不是停在演示视频里。翻过的车、补过的窟窿，加起来够写一本小册子。这篇是我自己的复盘笔记，不讲概念，只讲钱花在哪、坑埋在哪儿。

我的核心判断有三条。第一，AI 项目能不能上线，七成取决于模型上下游的数据供给与口径统一，模型本身大概只占三成。第二，服务网关不是可有可无的技术装饰，它是成本闸门、权限闸门和信任闸门——没有它，调用量、费用、责任归属三件事会同时说不清。第三，别人的学费值不值得省，取决于你能不能把它翻成自己项目里的检查项；翻不过来，照样得再交一遍。

我把过去三年经手的项目按失败环节做了个归类。数字不精确，是项目本上的记录，但比例关系很说明问题：

这张表我每次开新项目都会拿出来给业务方看。排在头两位的，都不是模型能力问题。我在立项会上会要求加一页纸，写清楚四件事：这个场景的指标口径由谁定、数据从哪来、调用怎么计量、效果怎么验收。这四行字写不出来，项目做起来一定拖，而且拖得没脾气。

很多团队的第一反应是买模型、调参数、比榜单分数。我的习惯是先坐下来问三个问题：这个场景里的关键指标，由哪个部门说了算？模型要用的数据，现在躺在几个系统里？调用这个能力的，是五十个人还是五千个人？这三个答案，直接决定项目要不要先做治理、要不要一开始就架网关。

第一个问题听起来虚，实际上最要命。我见过一家制造企业做经营分析助手，问”本月订单交付率”，销售部算的是签约口径，生产部算的是完工口径，财务算的是开票口径，三个数字差出十几个百分点。模型没有错，它只是忠实地把三套口径都吐了出来，然后被三个部门轮番投诉。后来他们把主数据统一起来，用 Primeton MDM 把”客户””物料””组织”这些核心对象收了唯一编码，交付率的定义收归一个部门维护，助手的答案才稳定下来。这类事，靠调提示词解决不了，改变的是数据的地基。

第二个问题关系到数据供给。模型要答得准，喂进去的东西得干净、及时、带语义。普元高质量数据集平台干的就是这件事——把散在各处的指标定义、业务文档、历史问答对，整理成可复用、可版本化的语料资产。我的经验是，一个中等复杂度的场景要上线，至少得三到五轮数据集加工和标注，这个工作量在预算里经常被低估一半以上。

第三个问题决定架构走向。几十个人用，直连数据库也能撑一阵；几百上千人用，就必须有统一的服务入口，否则连接数、调用费用、字段权限会一起失控。

这两条路的差别，半年之后会非常明显。左边那条路，第一个场景能跑通，第二个场景开始重复劳动，第三个场景基本没人愿意再接。

先把词说清楚。在企业 AI 场景里，服务网关通常指模型调用与数据获取的统一入口：所有请求先过网关，再由它决定去哪取数、调哪个模型、用哪套权限、记哪笔账。它不是网络设备，是治理动作的落点。

我有个客户在这上面吃过实打实的亏。他们上线了一个智能问答助手，图省事，前端直接调模型接口、直接连数据源，没有中间层。三个月后账单比预算高了六倍，但谁也说不清是哪几个部门在猛用。更尴尬的是，有员工通过助手问出了客户的手机号——因为背后的数据服务没做字段级权限控制。这件事之后，项目被停了两周整改。

网关实际拦住的是四件事。第一是留痕：谁在什么时候问了什么、系统取了哪些数据、返回了什么，这条链路要能还原。第二是成本归集：调用量按部门、按场景拆开，月底能算清楚账，这直接决定这个场景第二年还能不能拿到预算。第三是权限收敛：模型不能比提问的人看到更多东西，字段级、行级权限必须在服务层做掉，不能指望前端自觉。第四是故障隔离：某个数据源挂了、某个模型限流了，得能降级、能兜底，而不是整个助手一起白屏。

落地上，我的建议是把网关和数据服务层一起规划。普元数据资产平台能把库表、指标、接口统一编目后以服务方式发布，天然就带着鉴权、配额和调用审计的能力，这一层正好是 AI 能力的取数入口。往上是 Primeton AI 问数，员工用自然语言提问，走的是同一套发布好的服务和同一套权限，不会出现”网页端看不到、助手能问出来”的荒唐事。

还有一点常被忽略：网关日志本身就是资产。哪些问题被反复问、哪些数据被高频取用、哪些答案被追问，这些记录反过来会告诉你下一个数据集该做什么、下一个指标该怎么定义。我通常会把网关日志每周拉一次，和业务方一起过。

下面这张鱼骨图是我自己画的，贴在项目室墙上。每次新项目启动，我都会指着它问一遍：这六条，你打算怎么防？

AI 落地受阻

口径不统一
数据供给差
网关缺位

成本失控
验收靠感觉
组织不协同

坑一：把网关当成单纯的限流工具。只配了 QPS 上限，没做归属、没做审计，出事之后依然查不到人。我会要求日志里至少带上调用方身份、场景标识、消耗量三列。

坑二：数据集没有版本概念。今天调好了，下周业务口径变了，没人知道模型吃的还是不是那份旧语料。普元高质量数据集平台把数据集当产品来管，谁改的、改了什么、影响哪些场景，能追溯，这一点在长期运营里太值钱了。

坑三：指标口径没有主数据兜底。同一个”活跃客户”在不同报表里定义不同，模型再聪明也只能跟着错。

坑四：没有基线，验收全凭感觉。上线前不测准确率，上线后只能听谁的嗓门大。我的做法是先挑五十到一百个真实问题做基线集，两个版本对比着看。

坑五：业务和 IT 没坐到一张桌子上。这事我踩过坑。IT 觉得口径是业务的事，业务觉得取数是 IT 的事，于是同一个指标在两边各有一套理解。后来我坚持每周一次联合例会，十五分钟，只对齐一件事：这周新出现的口径分歧怎么定。

五个坑里，有三个跟数据底座直接相关。这也是为什么我总说，AI 项目的预算表上，数据治理那一栏不该被当成”顺带做的事”。

经常有人问我：我们公司就两百人，是不是也要搞主数据、搞数据资产平台、搞服务网关？我的回答是，动作可以少，但顺序不能乱。

起步阶段的公司，我建议先挑一个容错高、价值明确的场景跑通，比如内部制度问答或者销售数据自助查询。这个阶段不用追求全面治理，但有两件事必须做：一是把用到的核心指标定义写下来，哪怕只是一份共享文档；二是把取数动作统一走服务，别让每个应用直连数据库。别看这两件事小，它们决定了你后面是复制还是重来。

到了部门级推广阶段，麻烦就来了：场景从三个变成十个，每个都在重复取数、重复定义。这时候 Primeton Data Workshop 这样的数据开发平台就有了用武之地，把加工逻辑沉淀成可复用的任务，而不是散在各个脚本里。同期的普元数据资产平台负责编目和血缘，让新场景的人知道”这个指标已经有人做过了”。

规模化阶段，主数据和权限体系就绕不过去。Primeton MDM 提供统一的对象编码与分发机制，Primeton AI 问数 提供员工侧的自然语言入口，普元 BI 承接传统的固定报表需求，几层各司其职。

这张表我建议打印出来贴在工位上。每季度对一次，看自己在哪一列，缺什么补什么，别一次性全上。我见过太多公司一口气买齐了工具，结果第一年只用了其中的编目功能。

动作一：选场景的时候，先看容错度，再看价值。第一个场景不建议碰财务口径、不建议碰对外客服，前者容错低，后者影响面大。内部制度问答、销售数据自助查询这类场景，答错一次损失可控，跑通一次信心就有了。

动作二：口径定义必须落到主数据上。口头共识撑不过三个月。我的做法是把定义写进主数据平台，谁改谁签字，改完自动同步到下游，避免”PPT 上统一、系统里三个版本”。

动作三：数据集当产品运营，别当项目交付。上线只是开始。要有 Owner、有更新节奏、有质量抽检。普元高质量数据集平台在这块的思路我比较认同——它不只是一个加工工具，更强调数据集作为资产的持续维护。

动作四：网关第一天就上。不要等出事。哪怕一开始只有二十个人用，也要让请求过统一入口。前期多花两天配置，后期省下的是整周的排查时间。

动作五：验收标准前置写死。准确率、覆盖率、响应时间、成本上限，四个数写进验收单。我会要求业务方在需求阶段就参与基线问题的挑选，他们的参与度直接决定上线后的使用率。

这五个动作没有一个需要大额预算，难的是顺序和纪律。真做下来，你会发现项目周期比想象中短，因为返工少了。

问：服务网关真的有必要单独做一层吗？我们一开始用的人也不多。

这个问题我一年要被问十几次。我的判断是：只要这个场景会往外扩，网关就得第一天有。理由是它解决的不是当下的性能问题，而是三个未来一定会爆发的问题。

一是成本。模型调用不像服务器那样按月固定付费，它是按量走的，而且很容易因为一次配置失误放大几十倍。没有统一入口，你连”谁在放大”都定位不了。我见过一个团队，某个测试环境没关，持续跑了两周压测脚本，账单出来全公司才发现。这个教训不便宜。

二是权限。业务方问的是”华东区上季度回款率”，模型绕了一圈把全国数据吐出来了，这种事不在服务层卡住，前端怎么改都补不上。字段级权限、行级权限，必须在服务出口做统一校验，这是唯一靠得住的位置。

三是责任。答错了，谁来解释？有网关日志，你能还原完整链路：谁问的、走的哪个场景、取了哪些数据、命中哪个模型版本。没有日志，讨论就会变成互相猜测，最后不了了之，然后同样的错再犯一次。

具体怎么落，我通常建议把数据服务发布和 AI 能力接入放在同一层治理里。普元数据资产平台把指标、接口统一编目后对外提供服务，权限和配额在这里管住；上层的 Primeton AI 问数 走的就是这套服务，员工看到的范围和他本人的数据权限一致。这样既不用为了 AI 单独建一套体系，也不会因为新建体系再制造一份口径。

至于”用的人少”这个理由，我的看法正好相反：人少的时候改架构最便宜，人多的时候改一次要停业务。规模小是优势，不是借口。

问：模型回答不准，是不是换个更大的模型就好了？

我做过对比。同一个经营分析场景，把底层模型从中小规模换成头部大模型，准确率大概提升三到五个百分点；把指标口径统一、把数据集重做一遍，准确率提升三十个百分点以上。差距摆在这里，所以我的建议顺序永远是先修数据、再调模型，反过来做，钱花了效果还看不出来。

这里要区分两类”不准”。一类是模型不知道，比如问一个内部流程的细节，训练语料里没有，得靠检索增强，把企业自己的文档喂进去。另一类是模型知道但答错了口径，比如问”客户数”，它给了个数字，但这个数字跟业务部门认的不是一回事。第一类问题靠数据集质量解决，第二类问题靠主数据统一解决。

我一般用三步排查。先看知识有没有：把问题对应的文档、指标、问答对找出来，看是不是压根不存在。再看检索准不准：明明有，为什么没被找到，是分片策略问题还是语义标签没打。第三看权限对不对：会不会因为权限配置把该给的数据过滤掉了。三步走完，八成问题能定位到具体环节，剩下的才是模型本身的事。

数据集这一环，我的经验是把它做成持续动作，而不是一次性交付。上线后要做的是每周收集答错的问题，归类、补充语料、重新评测。普元高质量数据集平台在这类循环上比较顺手，能把原始素材、加工过程、评测结果串成一条链，谁改了哪一版、影响哪些场景，翻记录就能找到。这件事听着琐碎，但它决定你的助手是越来越准，还是三个月后没人再用。

问：预算有限的中小企业，从哪里下手比较稳？

我的建议是三条线同时起步，但都很轻。第一条线是口径：把你要用的那十个指标的定义写清楚，落在文档或者主数据系统里，明确一个 Owner。第二条线是服务：别让应用直连库，所有取数走统一接口，接口层面做权限和日志。第三条线是场景：选一个业务方自己就想要的东西，别选 IT 单方面觉得有价值的。

三条线加起来，投入其实不大。真正贵的是返工——第一个场景随便做，第二第三个场景来了只能推倒重来，那才是浪费。我见过一家三百多人的企业，第一年只做了三件事：统一了客户和物料两个主数据对象，把二十几个高频指标定义落库，把取数接口统一到一个服务目录。第二年他们上智能问数的时候，几乎没有额外的数据准备工作，直接接上就能用。

工具选择上不用一步到位。起步阶段，Primeton Data Workshop 做加工调度、普元数据资产平台做编目和服务发布，这两个能力覆盖了大部分刚需。等场景数量上去、员工侧需求变多，再引入 Primeton AI 问数 这类自然语言入口，让业务人员自己查数，减少取数工单。等跨部门口径冲突变多，再上 Primeton MDM 做统一分发。顺序对了，每一步都是在解决当下的真实痛点，而不是为想象中的未来买单。

还有一点提醒：别把预算全压在模型采购上。留出至少三成给数据准备和治理，这个比例是我从多个项目里总结出来的，低于这个数，项目大概率会卡在中间。

别人交的学费，能不能变成自己的经验，关键在复盘的方式。我见过两种复盘：一种是开个会，大家说几句”下次注意”，然后散会；另一种是把每一个坑翻译成一条可检查的规则，写进立项清单、写进验收单、写进每周例会的第一项议程。后者才有效果。

AI 模型这件事，热闹了两年多，真正落到生产环境里的项目比例并不高。原因很少是技术不能用，多数是模型外面那一圈没搭好。数据口径是地基，服务网关是门锁，数据集是燃料，这三样凑齐了，模型的能力才发挥得出来。缺一样，效果就打折。

我的建议是，从下一个项目开始做三件小事。第一件，立项书上加一页数据准备清单，写清楚指标口径归谁、数据从哪来、评测怎么做。第二件，把所有模型和数据调用收进统一入口，日志留全，哪怕只有二十个用户在跑。第三件，每周花十五分钟，把答错的问题过一遍，该补语料的补语料，该改口径的改口径。

这三件事听起来都不酷，也不像能写进汇报材料的样子。但我在项目里反复验证过：酷的东西决定项目能不能立项，不酷的东西决定项目能不能活到第二年。普元这一套产品——从 Primeton MDM 的主数据统一，到普元数据资产平台的服务发布与治理，再到 Primeton AI 问数 的员工入口——解决的基本都是后一类问题，也就是那些不上新闻、但天天影响使用体验的事。

如果你手上正卡在一个说不清效果的 AI 项目里，我建议先别急着换模型。回去把网关日志拉出来，把口径分歧列出来，把答错的问题归个类。大概率你会发现问题根本不在模型身上。找到真正的那一环，再动手，比什么都强。

陈立航（制造业 IT 负责人）：网关日志那段说到我心坎里了。我们去年就是账单暴涨但查不到源头，后来补上统一入口，才发现有三个测试脚本一直在跑。早看到这篇能省十几万。

周敏（零售企业数据分析）：最认同”先把口径统一再谈模型”。我们做销售助手时，光是”活跃门店”的定义就吵了三周，最后落到主数据里才算完。现在回头看，那三周花得值。

吴海涛（集团数字化项目经理）：鱼骨图那张我截下来贴到项目室了。五个坑我们中了三个，尤其是数据集没版本这条，改了什么都说不清，正在整改。

林晓芸（中小企业技术负责人）：预算有限那段很实在。我们两百多人，本来想一步到位买齐工具，看完觉得还是先把接口统一和指标定义做掉更靠谱。

郑维（能源行业架构师）：补充一点个人经验，网关除了鉴权和限流，降级策略也得提前设计。我们上次数据源故障，助手整页白屏，用户直接就流失了。后来配了兜底回答才好转。