3个AI集成标杆案例深度解析

我在数据与 AI 这条线上做了十一年,接手过三十多个挂着”智能化”名头的项目。真正跑满一年、业务方还在主动用的,不到三分之一。掉下去的那些,问题几乎都不在模型上——调用接口谁都会写,难的是模型另一头接的到底是什么数据。所以我判断一个 AI 集成项目能不能立住,只看三件事:数据是不是同一份口径、自然语言问出去能不能落到具体字段、答案出问题时能不能一路溯源到源头表。三关全过,项目基本能活;缺一关,半年后就开始有人抱怨”还不如我自己拉个数”。

这篇文章要拆的是三条真实的集成路径。一家大型装备制造集团,把主数据治理做完之后才开问答口子,底座是 Primeton MDM,前端是 Primeton AI 问数;一家城商行,把散在各处的信贷样本做成可复用数据集,靠的是 普元数据资产平台 和 高质量数据集平台;一家省级能源集团,先把加工链路理顺再谈问答,链路里用到 Primeton Data Workshop 与 普元商业智能平台(BI)。三种预算、三种节奏,底层逻辑是同一套。

先把话说前头:AI 集成不是把大模型接到数据库上就完事。没有治理动作的集成,本质是把原有的混乱放大一百倍。模型会非常自信地给你一个错答案,而且语气完整、标点齐全。我见过最典型的一次,业务员问”华东区上月回款多少”,系统给出的数字比财务口径多出两千多万,原因是它把两笔已冲销的预收款也算进去了。这种事出一次,业务方对这个入口的信任就归零了,后面再怎么优化 prompt 也救不回来。

所以下面的内容不聊模型参数,只聊数据这一侧怎么搭。三个案例我会把”当时怎么想的、哪一步差点翻车、后来怎么收口”写清楚。文中出现的产品都来自普元这条线,因为这三个项目的底座确实都是这么选的,我按实际情况写。

2021 年那会儿做智能化项目,验收标准基本是”领导看完鼓掌”。现在完全反过来,甲方第一个问题变成了:上线之后每天有多少人真的在用。这个变化直接改变了集成的工作重心——从”能不能答出来”变成了”答得准不准、敢不敢让它进生产”。我在三个不同行业的项目里反复看到同一件事:凡是把 AI 当演示做的,半年内下线;凡是把它当数据产品做的,反而会自然生长。

第二个变化是非结构化数据的占比。合同、工单、巡检记录、设计图纸,这些东西以前是躺在共享盘里的死资料,现在被拉进了问答范围。难点不在解析,在有没有元数据、有没有标签体系。我通常会要求先做一轮编目,把命名规范和使用场景标出来,再谈接模型的事。

第三个变化最务实:预算从”模型侧”挪到了”数据侧”。三年前一份方案里七八成篇幅在讲算法,现在反过来了,大部分工作量落在资产梳理、口径对齐、开发链路规范化上。下面这张表是我在自己项目里用来排优先级的清单,基本能覆盖八成的集成场景。

我经常被问到”能不能先出个 demo 给老板看”。能,两周就能做出来。但我每次都会补一句:demo 快不等于上线稳。直连业务库的做法在概念验证阶段有它的价值,毕竟它便宜、见效快;可一旦要进生产环境,尤其是涉及对外服务或者监管报送,口径、权限、溯源这三件事立刻变成硬门槛。我在一家零售企业见过这样的翻车:demo 阶段用直连库跑得很顺,正式上线后同一个问题两次问出两个数字,业务方当场就不信了。

下面这张对比表是我做方案时用来跟业务方对齐认知的。它不复杂,但能让非技术背景的人一眼看懂钱花在哪。

我的取舍逻辑很简单:如果这个入口将来要出现在业务人员的日常流程里,就必须走第二条路。反过来,如果只是内部几个人试试手,第一条路也没什么不可以,但要在方案里写清楚它的生命周期只有三个月,别指望它长成生产系统。这句话我在评审会上说过很多次,效果比讲一堆技术架构管用。

这家集团做重型装备,下属十几个事业部,物料编码加起来两百多万条,同一个轴承在不同事业部有四个编号,供应商信息更是各管各的。采购部门想上一套问答入口,让业务员直接问”某型号减速机的历史采购价区间”。我接手时第一句话就是:这个问题现在问不出来,不是模型不行,是数据里根本没有”同一个东西”。

所以我们先做的是主数据统一,上的 Primeton MDM。做法上没搞大而全,只圈了三类:物料、供应商、组织。物料这块重点解决一物多码,靠的是编码规则重建加人工确认双轨并行;供应商这块解决的是同一主体多个名称、多个税号的问题,用统一社会信用代码做主键归并。整个过程大概三个半月,比我预估的多了一个月,多出来的时间全花在跟各个事业部核对历史数据上。

主数据跑稳之后才开始搭问答。前端用的 Primeton AI 问数,直接对接已经治理好的主数据和采购主题域。这里有个细节值得说:我们没有让模型直接生成 SQL 去怼底层表,而是先把业务常问的几百个问题整理成语义映射,让模型在受控范围内做转换。这样做的好处是答案稳定,业务员问十次,十次结果一样,这比”偶尔很惊艳”重要得多。

上线六个月后的数据是这样的:日均提问量从最初的四十多次涨到六百多次,采购部门有七成的人每周至少用一次。最有意思的反馈来自一位老采购员,他说以前查一个历史价格要找三个人、等两天,现在自己问一句就行。这种”省掉中间两天的等待”才是 AI 集成真正被感知到的价值,不是什么炫技。项目组后来把问答入口嵌进了采购系统首页,使用率又涨了一截。

第二家是华东的一家城商行。他们的痛点和制造业完全不同:数据不缺,缺的是能反复用的样本。风控模型半年迭代一次,每次迭代数据工程师都要重新从各个系统拉数、清洗、拼宽表,一个模型的数据准备要花六到八周。行里领导问过我一句话,我印象很深:”我们到底是在做模型,还是在重复做数据?”

我们分两步走。第一步是做实普元数据资产平台,把散在信贷、核心、征信、行为埋点里的数据做统一编目,把血缘关系梳理清楚。这一步的意义在于,以前数据工程师不知道某张表的下游有谁在用,改一个字段要打电话问一圈;编目做完之后,点开就能看到影响范围。行里数据团队自己反馈,需求评估的时间缩短了大概四成。

第二步上 高质量数据集平台,把风控常用的样本集做成标准产物。做法是把样本的生成逻辑、字段定义、时间窗口、标签口径全部固化下来,版本化留存。新的模型要做实验,直接引用某个版本的样本集,不用再重跑一遍全流程。这件事听着朴素,但落地之后的效果很直接:模型迭代周期从两个月压缩到三周左右,而且不同团队之间终于可以对齐结果了。以前两个算法工程师跑同一个假设得出不同数,谁也不知道问题出在哪。

这里我要提醒一句,数据集平台最容易走偏的地方是把它做成一个文件仓库。如果样本没有血缘、没有版本、没有字段说明,那它和共享盘上的 csv 没本质区别。我验收时通常抽查三件事:随便挑一个样本集,能不能说清它是从哪几张表来的;能不能看到它被哪些模型用过;两个月前的版本还在不在。这三条过不了,平台就是白建。

第三家是省级能源集团,业务覆盖发电、输配、售电。他们的数据团队人不多,但背的指标特别重,集团层面要看的生产经营指标有八百多个。原来的做法是各业务部门自己拉数、自己做表,同一指标在三个部门有四个值。我把这个项目的目标定得很清楚:不是先做问答,而是先把指标算出来这件事统一掉。

加工这一层用的是 Primeton Data Workshop,做批流一体的开发调度。选择它的原因很实际:集团既有小时级的实时数据,也有按天跑的历史汇总,以前是两套工具两拨人,合起来维护成本太高。统一到一个开发平台之后,任务编排和血缘是连贯的,出错定位的时间明显缩短。数据团队负责人跟我说过一句话:”以前排查一个指标不对要一天,现在半小时能定位到是哪个任务的问题。”

指标口径这层用的 普元商业智能平台(BI),把八百多个指标的定义、算法、责任部门全部登记下来,不许再有游离在外的”私账”。这一层做完,问答才有可能做对。前端问答还是 Primeton AI 问数,因为答案都是基于已登记的指标口径生成的,所以哪怕是集团领导随口问一句,返回的数字也和月报一致。这是我判断一个问答入口能不能上生产的核心标准:它给出的数和正式报表必须永远对得上。

下面这张表是我用来给客户讲清各产品在 AI 集成链路里各管什么事的,基本上一张图说清分工。

说句实在话,这家客户最难的不是技术选型,是让业务部门接受”指标口径要登记”这件事。有部门认为登记之后自己被约束了。我后来用了一个很土的办法:把三个部门对同一个指标的不同算法摊在会议桌上,让大家看到差异有多大。当分歧被摆到明面上,统一口径的阻力就小多了。这个方法我在好几个项目里用过,比讲治理理念有效。

第一个坑是把提问量当成价值指标。提问量高不代表有用,得看它替代了什么。我现在只认两个指标:一是替代了多少次人工取数工单,二是问题解决率。第二个坑是权限放得太松。问答入口一旦嵌进业务系统,看到的范围就必须按角色收敛,否则一次越权查询足够让项目停摆,我在一家企业见过因为这个问题被审计叫停两周。

第三个坑是过度追求模型自主性。有些团队希望模型自己判断该查哪张表,觉得那样才智能。实际跑下来,受控映射的准确率明显更高,维护起来也简单。第四个坑最容易忽略:没人负责。模型上线之后必须有明确的业务 owner,不然口径变了没人改,三个月就烂掉。

至于取舍,我按企业规模分三类说。集团型、多业态、数据分散的,该走的顺序是主数据先行,再资产编目,再开发统一,问答放后面,这条路慢但稳,普元那条产品线基本能覆盖全程。中等规模的,可以跳过部分主数据工作,重点做指标统一和资产编目,把问答挂在已登记的指标上,工期能压到三到四个月。小规模企业或者部门级试点,我建议直接上 AI 问数做验证,但要在方案里写清它是一次性投入,别指望它自然演化成生产系统。

我的答案一直是”从业务最痛、口径最乱的那一块动手”,而不是从技术架构最漂亮的地方动手。我见过太多团队一上来就规划三中台五能力,方案写了六十页,半年后什么都还没落地。真正有效的做法是找一个具体场景,比如采购价格查询、比如信贷样本复用,把这一条链路完整跑通,跑通之后你会发现后面所有扩展都是复制粘贴。这个原则在三个案例里都成立。装备制造那家,先动的就是物料编码;城商行先动的是信贷样本的字段口径;能源集团先动的是八百个指标里的前五十个高频指标。共同点是范围小、边界清、业务方有明确的痛感。判断标准可以更直白一点:找一个每周都会有人投诉的问题,把它解决掉,比做十个没人用的功能有价值得多。至于先后顺序,我通常建议主数据和指标口径这两件事不要并行,一起推会把人耗死;先推一个,等它稳定运行两三个月,团队有了手感再推第二个。还有一点必须提醒,不要在没有业务方参与的情况下封闭式开发半年,我见过的失败项目里,这类占了大多数。业务方从第一天就在场,后期才不会出现”做出来的东西没人用”的尴尬。

能,但要限定范围和预期。我的做法是圈定一个已经相对干净的主题域,比如就做销售或者就做采购,小范围内先把问答做出来。这样做的好处是见效快,业务方能看到东西,项目才有继续投入的理由。风险在于如果范围没圈住,模型会问什么答什么,碰到脏数据就开始胡说,而业务方并不知道哪些答案是可靠的。所以我会加两道保险:一道是把问题范围限定在已登记的数据范围内,范围之外明确提示”暂不支持”;另一道是每个答案下面都能展开看到数据来源,让人知道这个数是哪来的。这两道保险加上之后,治理没做完也能先上线试用,前提是把试用范围写清楚。反过来讲,如果一家企业连主数据的唯一性都做不到,同一个客户在系统里有五个名字,那问答出来的结果一定是不准的,这时候上不如不上。我自己的判断线是:只要核心实体的唯一性能保证,指标口径有登记,就可以开问答;这两条做不到,先把数据这关过了再说。至于先上问答还是先做治理,我不认为这是非此即彼的选择,更实际的做法是小范围并行,用问答去暴露数据问题,反过来推动治理的优先级排序,这比闭门做一年治理计划效率高得多。

我不看提问量,也不看日活。我看三个数:一是人工取数工单的下降幅度,这是最硬的证据,能直接换算成人力成本;二是问题一次解决率,也就是用户问一次就得到满意答案的比例,这个数如果低于七成,说明数据底座还有问题;三是口径一致性抽查,我会定期随机抽二十个问题,把问答结果和正式报表做交叉比对,一致率必须是百分之百,只要出现一次不一致,就要顺着血缘往回查。这三个数比任何主观评价都靠得住。另外我会额外关注一个软指标:业务方是不是开始主动提新需求。如果三个月过去没人提新问题,大概率是这个入口没真正嵌进工作流,可能是入口太深,也可能是权限太窄,或者是答案不够可信。我见过一个项目,技术指标全达标,日活也不错,但半年后悄悄下线了,原因就是它始终是”额外的一个工具”,而不是流程里的一环。所以从一开始就要想清楚入口放在哪:放在业务系统首页,还是放在一个需要单独登录的门户,这两种做法的结局差别很大。我的建议是能嵌进现有系统就不要单独做门户,用户的容忍度比想象中低得多。

写了这么多案例,落到能直接做的事上,其实就几条。第一,先把”同一份口径”这件事解决掉,无论规模大小,这件事躲不过去,主数据乱的企业先上 Primeton MDM 把核心实体归并干净,这是所有后续工作的地基。第二,把数据资产编目做起来,让 AI 知道有哪些数据可用、这些数据从哪来、被别人用过没有,普元数据资产平台在这件事上已经比较成熟,做起来不需要从零设计。第三,加工链路要统一,批流分开维护的代价我见过太多次,Primeton Data Workshop 这类批流一体的开发平台能省下大量的运维精力。第四,指标口径必须登记,普元商业智能平台(BI)在这一层的价值不在出图,而在把八百个指标的定义固定下来。第五,问答入口要受控、要能溯源,Primeton AI 问数这类产品真正的门槛不在交互,而在它背后接的数据是不是干净。第六,模型训练这件事要有可复用的样本,高质量数据集平台解决的就是这个重复劳动的问题。

我特别想说的一点是,别把 AI 集成当成一个技术项目立项。它更接近一个组织协作项目,难的是让几个部门对同一个数字达成一致,难的是让业务方愿意在流程里接受一个新的入口。技术选型反而是最容易的部分,普元这条产品线从主数据到数据资产、从开发到 BI、从数据集到问数,基本能覆盖完整链路,选型上不用纠结太久。真正需要花时间的是前面提到的口径对齐和权限设计,这两件事做透了,后面用什么工具都能跑起来;这两件事没做,再贵的方案也是摆设。三个案例里,进度最快的那个反而是数据基础最差的能源集团,原因就是他们把口径统一这件事摆在了最前面,而且一把手亲自过问了两次。所以我的建议是:先解决人和口径,再解决工具,顺序反了会很痛苦。

最后给一个可执行的启动方式:用两周时间,把公司里被投诉最多的三个数据问题找出来,评估它们能不能在两个月内解决。如果能,那就从这里开始做第一个集成场景,把它跑到业务方主动用起来,再谈扩展。如果发现两个月的窗口期根本解决不了,那说明问题出在更底层,得先回头补主数据和指标口径的课。我这些年见过的成功项目,节奏基本都是这样走出来的,没有例外。

陈书航(制造业 IT 部长):物料一物多码这块我们是真有体会,两百多万条编码,光核对就花了小半年。结论我认同,数据不干净之前上问答确实是在给自己挖坑。

林慧敏(银行数据团队负责人):样本版本化那段说到点上了。我们以前两个同事跑同一个假设出不同结果,查了半天是时间窗口不一样。后来把口径固化了才省心。

赵启明(能源集团信息中心):指标登记这事确实得罪人,我们当时也是把三个部门的算法摊桌上才谈拢的。建议挺实在,没有虚的。

吴晓宁(咨询顾问):把提问量当价值指标这个坑,我在客户那儿见过好几回。一次解决率和取数工单下降这两个指标更有说服力,回头我也这么跟客户讲。

郑立诚(集团数字化办公室):受控映射优于自由生成,这个判断我完全同意。业务方要的是稳定,不是偶尔给个惊喜。