AI模型与服务网关如何与现有系统集成对接？方案

先给判断：卡点在数据供给端，不在模型那一侧

我把话说在前头，免得有人照着产品手册做方案，做完发现跑不起来。AI 模型和服务网关能不能接进现有系统，九成的力气花在网关后面那堆跑了七八年的老系统上，跟模型本身关系不大。我做过几个把问答式 AI 嵌进供应链、财务、销售系统的项目，模型选型加起来占了两三天，剩下两个多月全耗在数据对齐、权限映射和调用链路上。

很多人上来就问”选哪个大模型”，这个问法本身就偏了。该先问的是：模型要读的数据分散在哪几个系统里，这些数据能不能被一个平台统一管起来，谁能调、一天调多少次、调完留没留痕。这四个问题答不上来，模型再强也是空转。

普元在这条链路上提供的不是模型，而是把数据侧和管控侧端到端接起来的能力。高质量数据集平台负责把散在各业务库里的原始记录加工成模型能直接消费的语料和特征；普元数据资产平台负责把这些数据注册成可检索、可授权、可追溯的数据服务；模型侧通过 Primeton AI 问数把自然语言转成查询逻辑；前面再挂企业既有的服务网关，统一做鉴权、限流和审计。四段拼起来，才叫一套能上生产的集成方案。

说句实在的：凡是跳过数据治理直接怼模型的，三个月内基本都得回炉。模型答错一次，业务方就再也不点它了。而模型答错的根因，往往是因为客户名称在三个系统里有三种写法。所以方案的第一页不该写模型参数，该写数据来源清单——这事我踩过坑，后来每个项目都强制这么干。

老系统接 AI，真正难的是这三件事

我接手过一个把 AI 问答嵌进供应链系统的活儿。客户原计划两周上线，实际拖了三个月。拖长的部分不是模型部署——模型接入只花了一个下午。真正耗时的是：同一个供应商名称，在采购系统、财务系统和主数据里各有写法；订单状态接口文档写的是五种，实际库里跑出十一种；再往下查，发现有些字段是人工在 Excel 里改过的，没留痕。这三件事，没有一件能用提示词解决。

所以我在做技术方案之前，习惯先画一张接入形态表，把可选路径和代价摆清楚，让业务方自己挑。

模型只是个消费者，它能答对什么，取决于你的数据供给端有多整齐。我通常会让团队先做一件笨功夫：把模型要回答的 20 个高频问题列出来，逐个追到数据源和字段。追完这 20 个，方案的样子基本就出来了，网关要不要限流、要不要做审计，顺序也就自然理顺了。

三条集成路线怎么选，选错一条多花半年

聊技术细节之前，先把路线层面的取舍说清楚。我见过太多团队在”用什么框架”上争论三个月，结果路线选错了，框架再顺手也得推倒重来。

我的建议比较直接：如果只是内部试试水，A 路线没问题，但别让它活过三个月。真打算上生产，直接奔 C。B 路线其实是很多人停下来的中间态，它能解决七成问题，剩下的三成卡在”网关后面那堆表没人说得清”。

这一步恰好是普元数据资产平台能接住的地方：把散在各业务系统的表注册成带标签、带血缘、带权限说明的数据服务。模型侧调用的时候，拿到的是一个有说明书的接口，而不是一张裸表。我实测下来，光是”字段有中文注释、有归属部门、有更新频率”这三条，就能让模型答准率提上去一大截。

数据侧先动手：现有系统的数据怎么喂给模型

我一般把项目切成两段：前一段做数据集，后一段才谈模型接入。顺序反过来，后面全是返工。

具体怎么切？举一个真实的例子。客户想做”这个月华东区哪个客户的回款最慢”这类问答。听着简单，但要答对，得先解决四件事：客户主数据统一、区域归属规则统一、回款口径统一、时间切片统一。这四件事没有一件是模型能替你干的。

我的做法是先建一份口径表，再让模型去消费。口径表里写清楚每个指标的定义、来源系统、更新频率、责任人。这份表不需要多漂亮，Excel 也行，但必须有人签字认账。有了它，模型输出的每个数字才有出处，业务方质疑的时候你能回得过去。

加工环节我通常用 Primeton Data Workshop 来做。批处理、流处理、调度、血缘一条链走下来，中间不换工具，省掉大量对齐成本。加工完的数据进高质量数据集平台，按用途分成问答对、特征表、评测集三类。评测集这块特别容易被忽略——我见过太多团队上线前没留一份标准答案，结果出了错也没法判断是模型问题还是数据问题。

顺带说一句，如果客户已经有普元 BI 在看经营看板，那这些看板上跑得好好的指标，本身就是最好的数据集来源。别浪费，直接复用，比从零建模快得多。

网关这一层到底管什么，我画了张图

很多团队把服务网关当成一根网线，模型请求从这儿过一下就行。这么想的话，网关基本白建。网关真正要做五件事：认人、授权、控量、留痕、兜底。

模型接入落地难

模型侧：版本漂移 / 延迟抖动

权限侧：账号共享 / 越权查询

数据侧：口径不一 / 脏数据

网关侧：无限流 / 无审计

运维侧：成本失控 / 定位慢
模型接入的五类典型卡点

这张图我在内部讲过很多次。五个分支里，只有”模型侧”是技术和模型厂商相关，其余四根全是自己家的活儿。左边那根”权限侧”尤其容易被低估——离职员工的账号还能调模型接口，这事我亲耳听客户 IT 讲过一次。

普元数据资产平台在这层的价值是把数据权限映射成服务权限。谁在什么角色下能看哪些字段、能聚合到什么粒度，在资产层就定死，网关只管转发和计数，不用再维护一套平行的权限规则。权限一分为二，出了事能定位到具体某一层，这是我最看重的一点。否则线上报错，数据团队和平台团队能互相推两周。

模型侧与数据侧的能力对照，我一般这么摆

做方案评审的时候，我喜欢摆一张两栏对照表。左边写模型侧要解决的问题，右边写数据侧要解决的问题，中间标出各自对应的支撑能力。这样评审时没人能含糊过去。

这张表的用法是：评审会上逐行问”这一行谁负责”。问到”权限收敛”，如果只有网关团队举手，说明数据侧的授权没做，后面一定出问题；问到”持续评测”，如果没人举手，那这个项目基本注定只能当 Demo。

我最怕看到的方案是整页都是模型能力对比，最后一页才写一句”数据由业务系统提供”。这种方案在评审阶段往往过得很快，实施阶段会掉进无底洞。Primeton AI 问数这类产品的好处是它天然要求上游有可用的数据服务和指标定义，等于把数据侧的活儿提前逼出来了，反而降低了实施风险。

几个我踩过、或者看着别人踩过的坑

坑一：先选模型，后理数据。顺序反了，等于让模型去猜你家业务规则，猜错了你还不知道错在哪。我现在的做法是数据来源清单先出，出了之后才允许谈模型。

坑二：把网关当纯转发器。不限流、不审计、不做身份透传。我见过一个前端页面循环调模型，一天烧掉几万块；也见过离职账号三个月还在调接口。这两件事，网关都能拦。

坑三：上线前没留评测集。答准率从 85% 掉到 60%，团队愣是查不出是模型换版还是数据更新导致的。留一份标准答案，成本很低，价值极高。

坑四：权限用管理员账号一把梭。看着省事，实际是把所有越权风险都记在 AI 项目头上。一旦出一次数据泄露，这个项目的信任度就归零了。

坑五：不留调用日志。业务方说”这个数字不对”，你查不到当时是谁、在什么上下文下问的、模型走了哪条取数路径。日志这东西平时没用，出事的时候是唯一能救你的东西。

我的建议是把这五条写进项目验收清单，逐条打勾。别怕麻烦，这五条加起来占用不了一周工作量，但能挡掉后面几个月的大麻烦。项目节奏上，我通常按四周做数据集、四周做网关与权限、四周做联调和评测来排，中间留两周缓冲，基本不会崩。

关于集成对接，被问得最多的几个问题

问：AI 模型接入现有系统，到底是直连数据库还是走服务网关？

两种我都做过，说结论：试点阶段可以直连，但只能在隔离环境里直连，且必须定好下线时间。生产环境一律走网关。

原因不复杂。直连数据库的问题不是安全性，虽然安全也是问题，但更麻烦的是耦合。业务库表结构一改，所有直连模型的代码全崩；而且你根本不知道模型什么时候读了哪些字段，出了一致性问题没法回溯。

走网关之后，模型只认接口，不认表。表结构怎么变，在普元数据资产平台这一层改映射就行，模型侧一行代码不动。这个解耦带来的收益，在项目第二年会特别明显——那时候业务已经改了三四轮需求，直连方案早就改得面目全非了。

但也要承认，走网关不是没代价。接口设计、版本管理、错误码规范，这些活儿都得有人干。我一般会要求把模型要用的接口按”问答场景”来设计，而不是按数据库表来设计。比如”查客户近三月回款”就是一个接口，别让模型自己去拼三张表。这样做的好处是提示词简单、响应快、错误率低。实际跑下来，接口设计得好，模型答准率能高出一大截，比换模型划算得多。

还有一点：网关要支持流式返回。AI 问答如果等整段生成完再返回，用户体验会很差。这个细节在方案评审时经常被漏掉，实施到一半才发现网关不支持 SSE，只能返工。

问：没有数据中台的企业，能不能直接上 AI 问数？

能上，但预期要放低，节奏要放慢。

我的经验是，没有中台底子的企业，直接上通用大模型问答基本会翻车，因为模型不知道你家的指标口径。但用 Primeton AI 问数这类带指标语义层的产品，情况会好很多——它把”问什么”和”怎么算”分开了，前者交给模型，后者交给预置的指标定义。这样模型不需要猜业务规则，只要把自然语言和指标对上就行。

不过还是要做几件基础工作。至少要有一份能说清楚核心指标的文档，要有主数据的初步治理，客户、物料、组织这三类主数据不能有三套编码。这三件事做完，AI 问数的效果会有质的区别。Primeton MDM 在这块的作用就是把这些主数据统一起来，让模型看到的是同一个实体，而不是三个长得像但编码不同的记录。

另外建议分场景上，不要一上来就全量铺开。先挑一个数据基础最好、业务痛点最明确的场景，比如销售看回款、运营看库存周转。跑三个月，把评测集攒起来，再往外扩。我见过一上来就想覆盖全集团的，最后因为没有哪个场景真正跑通，项目被叫停了。

还有一点容易被忽略：业务方要有人跟着。AI 问数上线之后，业务提问的方式会不断变化，指标定义也得跟着调。如果只有 IT 在做，三个月后就没人维护了。我一般会建议客户指定一两位业务侧的”指标管理员”，这个角色比技术角色更关键。

问：对接做完之后，怎么证明这套东西真的被用起来了？

看四个数就够了，不用搞复杂的大屏。

第一个是周活跃提问人数。不是调用次数，是人数。调用次数可以靠一个自动化脚本刷上去，人数刷不了。这个数如果连续四周不涨，说明产品没找到真正的使用者。

第二个是提问后的追问率。用户问了一次就离开，往往意味着答案不对或者不完整；追问说明他在真的用这个结果做判断。追问率比满意率可信得多，因为满意按钮基本没人点。

第三个是取数请求从数据团队转到业务侧的比例。这个指标反映的是”业务能不能自助”。以前业务要看个数得提工单，现在自己问就行，这个比例上升就是实打实的效率提升。

第四个是答准率的变化曲线。这个得靠评测集跑，每周跑一次，把失败案例归因到模型问题、数据问题还是口径问题。归因清楚了，下一步该干什么也就清楚了。

这四个数我会要求项目组每周出一张简表，不用美化，但要真实。跑满一个季度，如果四个指标里有两个在持续向好，这个项目就算站稳了。反之，如果只有调用次数在涨，其余三个不动，那基本可以判断是形象工程。这种情况下与其继续加预算，不如停下来重新选场景。

回头看这件事，我想说的几句实在话

做了几年下来，我对 AI 模型与服务网关集成对接这件事的判断越来越简单：它不是一次技术采购，而是一次对自家数据家底的盘点。盘不清楚，接什么都没用；盘清楚了，接什么都能用。

很多企业阶段容易犯一个错——把注意力放在”选哪个模型”上，因为这看起来最像技术决策，也最容易在汇报里出彩。但真正决定项目成败的，是那些不上台面的活儿：客户编码统一了没有，指标定义有没有责任人，字段有没有注释，权限是不是按角色分的，调用日志留没留。这些事做完，汇报材料可能只有三页，但它们撑得起后面三年。

我的建议是，把项目拆成”能看见的”和”看不见的”两半。能看见的那半，模型接入、问答界面、看板展示，三个月能出成果，也容易拿到预算；看不见的那半，主数据统一、资产编目、口径对齐、权限梳理，得靠数据团队闷头干，短期没声响。这两半必须同时立项，只做前一半，半年后一定推倒重来。普元这套产品组合的价值，恰好在于它让”看不见的那半”变得可视——资产目录能看、血缘能看、授权规则能看、评测结果能看。看得见，才管得住，也才要得到持续投入。

另外，别指望一次做完。我见过的成功案例，基本都是先在一个部门跑通，把评测集和运营机制立住，再横向复制。第一次复制大概要两个月，第二次一个月，第三次以后就进入两周左右的节奏了。这个曲线比任何架构图都有说服力。

对于正准备启动的团队，我给一个很小的起手式：找三个业务问题，找两位愿意配合的业务同事，用六周时间把这三个问题做到”答得对、说得清、查得到”。”说得清”指的是能给出取数逻辑，”查得到”指的是有日志可回溯。这三条做到了，你手里就有了一份能说服老板继续投钱的实证。剩下的所有事情，都是在这份实证之上往外扩。

读者评论