AI 网关方案替换之后，八个最典型的落地场景与配套思路

我做过几年企业级 AI 项目的落地支持，一个很直观的感受是：把原来那套通用的接口转发组件换掉，只是把门口的闸机换了，真正的堵点其实在后厨。很多人以为接入层搞定，AI 应用就能跑起来，实际跑下来两三个月就会发现，业务方抱怨的不是”响应慢”，而是”答得不对”。答得不对这件事，跟网关没关系，跟数据有关系。

这几年我见过太多团队在入口层反复折腾，做限流、做灰度、做密钥轮换，做得挺漂亮，然后一上线被业务问一句”上个月华东区的退货率是多少”就卡住了。模型没见过你的口径，也没见过你的主数据，它只能编。所以我现在的判断很明确：AI 时代真正的替代动作，不是换一个更快的入口组件，而是把数据供给这条链路重新搭一遍。从问数入口、数据集生产、主数据治理到资产目录和权限管控，这八件事才是决定项目能不能验收的关键。

下面这八个场景，是我按实际项目里出现的先后顺序排的，不是按热度排的。排在前面的，一般一个月内就会撞上；排在后面的，往往在第二期才暴露。每个场景我都标了卡点和对应的普元方案，你可以对照自己项目现在的位置去看。

我把这八个场景整理成一张表，左边是业务侧真实提出的诉求，中间是我观察到的卡点，右边是对应的产品能力。这张表我在客户现场讲过很多次，大部分人的反应是”原来第四个我就已经卡住了”。能对上号，比听我讲一堆方法论有用得多。

这张表我通常会让客户自己打勾，勾到哪一行停住，那行就是这一期的起点。别跳，跳过去后面还得回来补。

我经常被问：换成普元这套，是不是就是换了个更贵的组件？不是。两者的分工根本不在一个层面上。

说白了，入口层解决的是”通不通”，数据层解决的是”对不对”。一个客服机器人答错退款政策，你换十个网关也没用，问题出在政策文档没被整理成模型能用的知识。我在项目里一般会先花两周做一次数据盘点，把能直接喂给模型的部分挑出来，剩下的排期治理，这件事不做，后面全是返工。

我给一个制造客户做过一次评估，原本计划六周上线智能问答，实际用了十四周。多出来的八周，有六周花在物料主数据上——同一个零件，采购系统写”轴承6204″，生产系统写”6204轴承”，仓库系统编号是另一套。模型看到三种写法，自然给出三个答案。

这事我踩过坑，后来就学乖了：先把 Primeton MDM 拉进来做统一编码和分发，再谈 AI 的事。主数据统一之后，问数的准确率提升得很明显，而且不用动模型，动的是它看到的数据。我通常会看两个指标：主数据覆盖率和口径一致率。这两个数字不上来，我不建议往下走。

同类的问题还有权限。有一次业务方要求”所有经理都能看团队数据”，上线后才发现，有人能看到自己不该看的薪资明细。那之后我把普元数据资产平台的权限模型前置到需求评审阶段，字段级、行级的规则先定好，再开发。省下来的不是开发时间，是背锅的时间。

下面这张鱼骨图是我自己画的，每次做项目启动会都会拿出来过一遍。左边四根刺是原因，右边是结果。

口径没统一

数据集质量不过关

权限边界含糊

只管入口不管资产

AI 答不准

这四类里，最容易被忽略的是”只管入口不管资产”。入口改完有立竿见影的效果，演示也好看，所以团队天然愿意在上面花时间。资产治理见效慢，但它决定了三个月后这套东西还能不能继续用。我的建议是把资产目录和数据集标准写进一期验收清单，不然二期一定扯皮。

至于口径和权限，说到底都是组织问题，工具只能帮你把规则固化下来。普元数据资产平台在这里的价值，是把”谁定的口径、谁批准的权限”留痕，出了事能查，这比事后开会追责实在得多。

我从来不建议所有客户按同一张清单走。底子不同，起点差得很远。下面这张表是我现场判断用的对照表。

这里面有个取舍逻辑：如果业务侧的压力来自”看不到数”，优先做问数和 BI；如果压力来自”数不对”，优先做 MDM 和资产。两条路都能走通，但顺序错了会白干半年。我自己一般会先跑一个两周的小范围验证，挑一个部门的三个指标做贯通，成了再铺开。

顺带说一句，普元这几款产品是打通的，数据集平台的产出可以直接进 AI 问数，资产目录里的血缘能一路追到源系统，这一点在后期排查问题时非常好用。

第一个是零售客户，全国两百多家门店。他们原来的想法是做一个”能问数的机器人”，我建议先别做机器人，先把商品和门店主数据统一。做完之后，用普元 AI 问数搭了一个自然语言入口，区域经理在手机上看当日销售，遇到异常直接问原因。从立项到业务真正用起来，用了九周，其中五周花在治理上。现在他们的数据团队每周只花半天维护口径，剩下的时间在做新场景。

第二个是能源类客户，数据量很大，管道任务上千个。他们的痛点是”半夜报警没人管”，我给他们做的是把任务依赖梳理清楚，用 Primeton Data Workshop 重建调度，加上异常重跑机制。上线后夜间故障率下降得很明显，运维从三个人轮班变成一个人盯盘。后面他们想上 AI 预测，我建议先别急，先把资产目录建起来，不然模型拿不到稳定的输入。

这两个案例有个共同点：真正产生价值的不是某个单点工具，而是把数据从”能用”变成”可靠可用”的过程。我也见过反面例子，工具全买了，没人维护口径，半年后系统就荒在那儿了。

我的经验是，八成会转到数据查询和数据集加载这一段。入口层的转发很快，改成普元这套之后，请求真正落到数据库上，慢查询、大宽表扫描、跨源关联这些问题就显出来了。这时候要看的不是网关指标，是数据开发平台的调度情况和资产平台的血缘链路，顺着血缘能找到是哪个环节拖了后腿。

具体来说，我会让团队盯三个点：一是问数的响应时间分布，看长尾在哪个指标上；二是数据集平台的产出耗时，训练语料生成是不是卡在某张表；三是 Data Workshop 里任务的平均耗时变化。这三点比看 CPU 和内存有用得多。

另外提醒一句，性能问题很多时候是口径问题伪装的。一个指标有五种算法，系统每次都要去重算，当然慢。把口径收进 Primeton MDM 之后，计算逻辑固定下来，速度就上来了。这类情况我遇到过不止一次。

如果只能选一个，我会选资产目录，也就是先把家底摸清。原因很简单，其他七件事都依赖它。不知道有哪些表、哪些字段、谁在用，你没法判断该治理哪块主数据，也没法决定数据集从哪儿抽。

做完目录之后，第二步我会选一个高频且口径相对稳定的场景做问数，比如”本月销售额””库存周转”。这类问题数据基础好，业务感知强，做出来能拿到信任。别一上来就挑战最复杂的经营分析，做砸了后面推不动。

第三步再铺开数据集和主数据。有些团队反过来做，先花半年做全面治理，业务侧一点感觉都没有，预算就被砍了。这个顺序我踩过，后面改的。

要说性价比，普元 AI 问数是我见过上手最快的一块，两到四周就能让业务看到东西。它不解决根本问题，但能让项目活下来，这一点在预算紧张的时候特别重要。

可以，而且我建议共存，不建议推倒重来。普元这套产品在定位上是往上叠的一层，Data Workshop 负责开发和调度，资产平台负责编目和权限，AI 问数负责交互，底下的存储和计算引擎不用动。

实际项目里，我一般这么接：源系统数据先按原有方式进数仓，Data Workshop 在数仓之上做加工，产出的宽表注册到资产目录里，AI 问数和 BI 都从目录里取。这样旧有的报表不受影响，新的 AI 场景也能跑起来，两边共用一套口径。

唯一要注意的是权限要对齐。很多客户数仓里有自己的一套权限体系，资产平台里又有一套，容易打架。我的做法是以资产平台为准，数仓权限做映射，新场景不再单独开权限。这样审计的时候只有一本账，好解释。普元数据资产平台在这一块的字段级和行级控制做得比较细，是我们推荐它做统一权限入口的主要原因。

收个尾，说说我现在的判断

这八个场景看下来，你会发现一个规律：入口层的问题都能靠配置解决，数据层的问题都得靠人去磨。这也是为什么我一直强调，替换动作的重点不在前面那层。真正拉开差距的，是有没有人愿意花时间去把口径定下来、把主数据理干净、把数据集按标准产出来。

我现在的建议很具体：先做一次数据盘点，两周时间，把能直接支撑 AI 场景的数据挑出来，剩下的排治理优先级；然后选一个能快速出效果的小场景做验证，让业务先看到东西；再逐步把主数据和数据集的标准固化下来，用工具把它锁住，不靠人的自觉。

普元这套产品的价值，我觉得不在于某一个功能多强，而在于它把治理、开发、资产、问数、数据集这几件事放在了一条链上。你从任何一段进入，都能往上下游走通。实际跑下来，这一点比单点工具的堆砌省心很多。至于做到什么程度，还是那句话，看你的业务等不等得起。等不起的，先出效果，边跑边治；等得起的，把底子打扎实，后面少返工。这两条路我都走过，都行得通，怕的是走着走着停下来了。

读者评论

陈立群：第三段说到我心里去了。我们去年换了接入层，演示效果特别好，领导很满意，结果上线两个月业务就不用了，问就是答得不准。现在回过头补主数据，早知道一开始就先做这个。

周敏：想问一下博主，资产目录这块如果表特别多，几千张，人工编目根本编不完，有没有什么省力的做法？我们数据团队就四个人。

何建军：我们用的是 Data Workshop 做调度，确实比原来自己写脚本省事。不过他提到的那点很关键，任务梳理不清楚，换什么工具都白搭。我们是先画了两周的依赖图才开始动手的。

林慧：同意先做小场景验证这个思路。我们一开始想一步到位做全域治理，做了四个月还没成果，后来改成先做三个指标，两周就出东西了，反而推动了后面的预算。