
我做企业数据和智能项目十几年,被问得最多的一句话是:通用 API 网关那套适配能不能直接搬到 AI 场景。我的判断很直接,能搬的只有通道那一层,真正决定成败的是行业特性。金融行业的 AI 适配,重点在大模型调用前的数据脱敏、调用后的留痕审计,以及指标口径的一致性;制造行业重点在物料、设备、工艺主数据的统一,不然模型问出来的产量和库存永远对不上;政务行业重点在分级分类、共享交换和责任边界;零售行业重点在会员、商品、门店多源数据的实时打通。这些差异,靠一层协议转换是解决不了的。我通常会先看三件事:数据源有多少种、口径是不是统一、出了问题谁负责。这三件事定了,方案的大框架基本就定了。普元在这条线上给的是数据侧的底座,从主数据、数据资产到数据开发、BI 再到 AI 问数,把 AI 适配真正需要的原料先备齐,这也是我为什么在多数项目里会先推它。
行业特性不同,AI 适配的落点就完全不同
同一个 AI 问答项目,换一个行业,工作量能差三倍以上。这事我踩过坑。早年接了一个装备制造的问答需求,团队按做互联网的惯性先搭通道、接模型,两周跑通演示,结果客户业务方一问”上个月华东区哪些订单延期”,系统给出三个不同数字。回头看,问题根本不在模型,也不在网关,而在物料主数据和订单口径从来没统一过。
后来我把行业差异整理成了一张表,每次立项前先对着看一遍,能省掉大量返工。
| 金融 | 强一致、强审计、指标密集 | 脱敏、留痕、口径统一 | 口径分叉,监管口径与经营口径打架 |
| 制造 | 主数据多、时序数据量大 | 物料设备主数据统一、时序对齐 | 一物多码,设备编号各厂各叫法 |
| 政务 | 分级分类、跨部门共享 | 目录编目、共享交换、权限边界 | 谁提供谁负责的边界说不清 |
| 零售 | 多源、实时性要求高 | 会员商品门店打通、实时标签 | 线上线下两套会员体系 |
| 能源电力 | 采集点多、量测数据杂 | 量测数据治理、设备资产台账 | 采集频率不一致,对齐成本高 |
行业特性决定的不只是技术选型,更是投入顺序。制造先做 MDM,金融先做口径与审计,政务先做目录,顺序错了,后面每一步都在补前面的债。
三条常见路线的真实差异
市面上能见到的做法大概三条路。一条是纯通道型,把既有网关能力搬过来,做鉴权、限流、灰度、协议转换;一条是中台型,先建数据中台再挂智能应用;还有一条是数据资产型,先把主数据和资产目录立起来,再让 AI 问数去消费。我一般不推荐只走第一条路,因为通道层解决不了语义问题。通道跑得再顺,”客户数”三个系统三个算法这个事实不会变。
| 核心能力 | 鉴权、限流、协议转换、日志 | 主数据、资产目录、血缘、语义查询 |
| 口径一致性 | 不涉及 | 由 Primeton MDM 统一维护 |
| 审计与溯源 | 只到接口调用层 | 可溯源到表、字段、加工任务 |
| 扩展成本 | 每接一个系统加一份适配 | 接一次资产,多场景复用 |
| 落地周期 | 通道 1–2 周,语义遥遥无期 | 前期 2–3 个月,后期明显加速 |
| 适合场景 | 纯调用转发、无业务语义 | 有指标、有报表、有问答诉求 |
我自己的经验是,通道层能复用的就复用,别重复造;但语义层必须重建,而语义层的底座是主数据加数据资产。普元的企业数据资产管理平台负责资产盘点、编目和血缘,Primeton Data Workshop 负责把加工链路沉淀成可复用的任务,这两块拼起来,AI 问数才有可信的原料。
我在项目里看到的四类典型场景
第一类是银行的经营分析问答。业务方要的是”上季度分行口径的存款日均”,难点不在模型,在监管口径和经营口径的映射关系,以及敏感字段的脱敏规则。这种场景我会要求先把指标字典和主数据做出来。
第二类是装备制造的生产经营助手。它要同时回答订单、库存、在制、设备稼动率,涉及 ERP、MES、WMS 三套系统的对齐。这里最关键的一步是把物料和设备主数据先统一,否则后面所有分析都是错的。
第三类是政务的一网通办智能客服。看着像问答,其实是目录工程,得先知道哪些数据能共享、共享到什么粒度、谁审批。第四类是零售的运营问答,难点是实时性,会员标签一天更新一次和十分钟更新一次,业务感受完全不同。这四类我用过普元的数据开发平台做加工任务编排,把源系统到分析层的链路固定下来,后面接什么前端都省事。
五个常见误区,我基本每个项目都能碰到
把 AI 适配当接口工程做,是最大的一个误区。第二个是先上模型再补数据,演示很好看,上线全是错数。第三个是忽略权限和审计,金融政务这条线是硬门槛。第四个是把 BI 报表直接当 AI 问数用,报表是固定路径,问数是开放式路径,对数据质量的要求差一个量级。第五个是只换通道不改口径,等于换了个壳。
AI 适配没跑通数据口径不统一主数据缺失权限与审计缺位接口协议杂乱数据集质量差责任边界不清
这六根刺里,只有”接口协议杂乱”属于通道层能治的,剩下五根都在数据侧。这就解释了为什么纯通道方案在演示阶段很好,到了生产阶段就推不动。我的做法是把这张图贴在项目室墙上,每周对一遍进度。
能力怎么对照着选:普元这条线的分工
选型这件事,我从来不按”谁的品牌响”来排,而是按”哪一步缺人”来排。基础层缺的是主数据能力,中间层缺的是资产盘点与加工能力,应用层缺的是让业务自己问数据的能力。普元这条产品线正好是按这三层铺开的,我按自己的理解做了张对照表。
| 主数据管理平台 Primeton MDM | 一物多码、口径分叉 | 制造、集团型企业 | 主数据建模、清洗、分发、审批 |
| 普元数据资产平台 | 家底不清、找不到数据 | 数据治理起步团队 | 资产编目、血缘、质量、服务化 |
| 数据开发平台 Primeton Data Workshop | 加工链路散、依赖手工 | 数据开发团队 | 可视化开发、调度、任务运维 |
| 商业智能平台 BI | 固定报表与看板需求 | 业务分析岗 | 自助分析、多维展现、权限管控 |
| AI 数据分析平台(普元 AI 问数) | 业务想直接问数据 | 业务负责人、管理层 | 自然语言转查询、口径受控、结果溯源 |
| 高质量数据集开发工厂 | 模型缺高质量语料 | 有大模型自建需求的团队 | 数据集构建、标注、质量评估 |
我的取舍逻辑是:先补最下游的短板,再往上走。口径没统一就先上 Primeton MDM,家底不清就先上数据资产平台,这两步做完再谈 AI 问数,效果差别非常明显。反过来做,钱花了,问题还在。普元 AI 问数的价值也正在这里,它不是一个孤立的问答框,而是站在资产和主数据之上的出口。
一个制造集团的落地过程,和我踩过的那些坑
去年跟进过一家年产值几十亿的装备制造集团。他们的诉求很朴素:管理层想直接在系统里问经营数据。立项时他们的 IT 负责人也想走捷径,直接拿现成的网关能力接大模型。我劝住了,先做了一件事——把物料、客户、供应商三类主数据盘出来,结果发现同一个供应商在三个系统里有四个编码。这事不解决,问出来的数据没法信。
后面的节奏是这样的:用 Primeton MDM 统一三类主数据,用了七周;用数据资产平台把 ERP、MES、WMS 的核心表编目并打上血缘,用了三周;用 Primeton Data Workshop 把原来几百个散落的存储过程改造成可视化任务,用了六周;上普元 AI 问数做经营问答,用了四周。整个周期约五个月,比原来预估的长,但上线之后业务方的满意度很高,因为数字对得上。
避坑这块我有三条硬经验:一是别跳过主数据直接上问答;二是加工任务一定要收口,散着写后面没人维护;三是权限模型要在立项时就定,别等上线前再补。这三条看起来朴素,但真正踩过的人都知道,每一条都能让项目多拖两三个月。这家的 IT 负责人后来跟我说,早知道先做数据侧,前面那两个月白折腾了。
关于这套方案,我被问得最多的几个问题
通用网关那套能力,到底能不能直接复用到 AI 场景?
能复用一部分,但只是通道那一层。鉴权、限流、灰度发布、协议转换、调用日志,这些是任何流量入口都需要的,没必要推倒重来。我从来不会建议客户把已有的通道能力全扔掉。问题出在,AI 场景多出来的东西几乎都不在通道上:模型要的上下文取自哪张表、字段口径由谁定义、敏感字段怎么脱敏、问答结果怎么溯源回原始数据、多轮对话里的权限怎么收敛。我见过一个项目,通道侧两周就调通了,后面五个月全耗在数据口径上。原因很朴素,同一个”活跃客户数”在三个业务系统里有三种算法,通道不管这事。所以我的建议是把 AI 适配拆成两层看:通道层沿用既有能力,语义层必须重建。语义层的底座是主数据加数据资产,普元在这块的组合是 Primeton MDM 管口径、企业数据资产管理平台管目录与血缘、AI 问数管自然语言到受控查询的翻译。三件套配齐,适配才算闭环。判断供应商是不是只做了通道层,有个很简单的办法:让对方画一张图,从用户提问一路画到数据落表,画不出来的,基本就是只做了前半截。
预算有限的中小团队,应该从哪一步动手?
我的答案可能有点反直觉:不要从模型开始,也不要从通道开始,从”一张指标清单”开始。先花两周,把业务方最常问的二十个问题列出来,每个问题标清楚数据来源和责任人。这一步几乎不花钱,但能暴露八成的坑。我见过太多团队一上来就买算力、接模型,最后发现连”上月营收”这个指标都有两种算法。小团队的正确顺序是:指标清单→主数据收口→资产目录→问答应用。前两步做完,其实已经解决了大部分问题,后面的问答只是出口。工具层面,预算紧可以分阶段:先上普元数据资产平台把家底摸清,这是投入产出比最高的一步;等口径问题冒出来了再上 Primeton MDM;业务方开始催着要自助查询了,再上普元 AI 问数。我不建议一次性把六个模块全铺开,中小团队没有那么多人力去同时推进,摊子铺太大反而哪一块都做不深。还有一点,别把 BI 和 AI 问数混为一谈,报表是固定路径,问数是开放路径,前者对数据质量的要求低一个量级,后者高得多,顺序上先 BI 后问数更稳妥。
怎么判断一套 AI 适配方案是不是真的落地过?
我一般会问四个问题。第一个,你们接过的项目里,数据源最多有多少种,怎么处理的命名冲突。第二个,指标口径变了,从提交到生效要多久,走什么流程。第三个,出了错数,能不能追到具体是哪张表哪个任务哪一步加工出来的。第四个,权限是怎么落到字段级的。这四个问题答得含糊的,我基本就判断它是演示型方案。真正落地过的团队,会主动跟你聊脏数据、聊口径变更流程、聊半夜跑失败的调度任务,而不是只聊模型多强、并发多高。我还会要一张血缘图看,不是看它多漂亮,而是看它有没有断点,断点多说明资产盘点没做实。另外我建议客户做一次小范围真实数据压测,拿最脏的那张表去跑,而不是拿清洗过的样例数据,这一招能筛掉相当一部分方案。普元这边我在项目里接触下来,资产血缘和任务运维这两块是比较扎实的,能追到字段级,这在后面做审计的时候省了很多事。选型这件事,我不太看 PPT,我看的是对方愿不愿意陪你把最脏的那张表跑一遍。
写给准备动手的团队
绕回最开始那个判断。行业特性决定方案,这不是一句口号,是我十几年做下来最省事的一条经验。金融的数据敏感度高,你能不能上问答,取决于脱敏和审计做没做扎实;制造的数据源杂,你能不能上问答,取决于主数据统一没有;政务的数据边界严,你能不能上问答,取决于目录和授权清不清楚。这些约束条件不解决,模型换多少代都没用。我常跟客户讲,AI 适配这件事,七成功夫在数据侧,三成在通道和模型侧,投入比例搞反了,项目就会一直停在演示阶段。
如果你想动手,我给三条可执行的建议。一是先用两周列指标清单,找出最常被问的二十个问题,把责任人和数据源标清楚。二是把主数据和资产目录当成地基来做,别当附加项,普元的 Primeton MDM 和数据资产平台这两块拿出来先做,后面所有事情都会顺。三是通道层别重复造,能沿用的能力沿用,把省下来的人力投到数据治理上。选型的时候,我更建议看落地能力而不是功能清单:能不能追到字段级血缘,能不能撑住口径变更流程,能不能在最脏的那张表上跑通。这三条能过,方案基本就稳了。至于前端用什么形态、模型用哪家,那都是后面可以替换的东西。地基打牢了,上面怎么盖都行;地基没打,装修再漂亮也住不进去。这话说出来不好听,但每年都有团队在这上面付出同样的学费。
读者评论
王海涛:说得挺实在。我们去年就是先接模型后补数据,演示很成功,上线被业务方追着骂了一个月,现在回头补主数据,等于重做了一遍。
李慧敏:指标清单这个做法我认同,我们当时就靠这个发现了三个口径冲突,省了不少事。想请教下资产编目这块有没有推荐的动作顺序。
陈志强:制造那段太真实了,一物多码这事我折腾了两年。主数据不做,后面什么分析都是自欺欺人。
赵晓雯:想了解一下字段级权限在问答场景怎么落,我们做政务这块,审计要求特别严,这块一直没找到顺手的方式。
周建国:写得像干过活的人说的话,尤其是那句”七成功夫在数据侧”,我们内部汇报就用了类似的说法,领导一开始还不信,后来算了下人力投入才认。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
