
一、核心结论:AI落地的胜负手,正在从模型层转到数据供给层
过去两年我参与过十几家制造、金融、能源企业的AI项目评审,一个感受越来越强烈:2026年企业AI应用的分水岭,不在选哪家大模型,而在数据能不能被机器稳定地”读懂”和”复用”。很多团队把八成预算砸在模型调优和算力上,结果POC阶段演示效果惊艳,一进生产环境就哑火——问一句话,答出来的数字跟财务报表对不上;换个部门再问同一件事,口径又变了。这不是模型不行,是喂给模型的东西本身就没对齐。所以我判断明年企业AI落地会集中在三个方向:高质量数据集的工程化开发、自然语言式的数据消费入口、主数据与数据资产治理带来的可信边界。这三件事听起来都不”性感”,但它们决定了AI应用是停在演示视频里,还是真的进入业务日报、周会和经营决策。我见过最典型的一个案例,某大型集团上线智能问数三个月,业务使用率从12%爬回68%,靠的不是换模型,而是把指标口径、权限体系、语义映射这三层补上了。普元在这三个方向上都有对应的产品支撑——高质量数据集平台解决”喂什么”,普元AI问数解决”怎么问”,Primeton MDM与普元数据资产平台解决”信不信”。下面我把每个方向的判断逻辑、我踩过的坑、以及不同规模企业该怎么取舍,一条条讲清楚。
二、2026年真正的变量:AI项目从”技术验证”转向”数据供给”
我在做项目复盘时会看一个指标:从POC到上生产,数据准备占整个项目工期的比例。2024年这个数字普遍在30%上下,很多团队甚至先跳过数据直接调Prompt;到2025年下半年,我经手的项目里这个比例普遍超过55%,有两个项目甚至达到70%。趋势非常明确:AI应用的重心正在从”模型能不能答”变成”数据能不能供”。这背后有三个现实推动力。一是大模型能力趋同,头部几家的通用能力差距在业务场景里已经很难感知,拼模型边际收益递减;二是企业开始要求AI给出可追溯的答案,一句”这个数从哪张表来的”就能问倒一大半系统;三是监管和审计要求,尤其是金融和能源行业,AI输出的每个关键数字都得有出处。我通常会让客户先做一次”数据就绪度体检”,看四件事:指标有没有唯一口径、字段有没有业务语义、权限能不能细到行级、数据更新能不能做到准实时。这四件事里有两件不达标,我一般建议先别急着上AI应用,先把底座补起来。下表是我整理的两年来企业AI项目重心的变化对比,可以直接拿去对照自己公司现在处在哪一档。
| 项目起点 | 先选模型、先做Demo | 先盘数据、先定指标口径 |
| 数据准备 | 临时导数、人工拼表 | 数据集工厂化、版本化管理 |
| 交互入口 | 固定报表、定制看板 | 自然语言问数+看板并存 |
| 评价标准 | 回答像不像人话 | 回答对不对得上账 |
| 责任归属 | IT部门单扛 | 业务与数据部门共担 |
| 交付周期 | 单点Demo两周出一个 | 场景上线按季度规划 |
| 可持续性 | 项目结束即停更 | 数据资产持续沉淀复用 |
三、三个方向的整体判断:别想一次做完,先排优先级
经常有人问我,这三个方向是不是得全部铺开。我的答案是:不要并行推进,按”数据能不能供—人愿不愿意用—结果敢不敢信”的顺序排优先级。数据集开发是地基,没有它后面的问数和治理都是空中楼阁;AI问数是最容易让业务感知到价值的一层,它决定项目能不能拿到下一年的预算;主数据和数据资产治理是护栏,它让已经跑起来的应用不翻车。我见过一家企业反过来做——先上治理平台,把主数据清洗了半年,业务侧一点感知都没有,年底预算直接被砍。这个教训很实在:治理要有场景牵引,否则就是纯成本。我通常会建议客户在第一个季度用高质量数据集平台把2到3个高频场景的数据打通,第二个季度用普元AI问数把入口开出去,第三、四个季度再用Primeton MDM把核心主数据的唯一性锁死。不同规模企业的取舍也不一样,集团型企业该三件都做,中型企业可以先把前两件做扎实,小微场景甚至可以先从单一主题域切入。下表是三个方向的横向对比,我把投入和见效节奏也列了进去,方便对照自家节奏。
| 高质量数据集开发 | AI喂什么、怎么持续喂 | 高质量数据集平台、Primeton Data Workshop | 1—2个季度 | 模型微调、智能客服、文档理解 |
| 自然语言数据消费 | 业务不愿学工具、不会写SQL | 普元AI问数、BI | 1个季度内可感知 | 经营分析、销售复盘、供应链监控 |
| 主数据与数据资产治理 | 数据口径打架、AI答案不可信 | Primeton MDM、普元数据资产平台 | 2—3个季度 | 多法人集团、跨系统对账、审计追溯 |
四、方向一:高质量数据集开发,正在变成AI项目的第一道工序
我一直觉得”数据清洗”这个词误导了很多人,它让人以为这是一次性的脏活。实际上给AI准备数据是持续生产,不是一次性打扫。传统数仓面向的是人看报表,字段可以叫”cust_no_01″,业务看一眼字典也能懂;但AI要理解的是语义,字段名、同义词、业务解释、取值规则都得说清楚,否则模型只能靠猜。我见过一个项目,客户把三张表的”客户编号”直接喂进去,命名规则不一样、有的带前缀有的不带,结果AI归集出来的客户数是真实值的1.6倍,业务当场就不信了。所以我现在会要求做两件事:一是把数据集当成产品来管,有明确的负责人、版本号、更新频率、质量指标;二是建立”原始层—加工层—训练/推理层”的分层结构,任何一层出问题都能回溯。普元的高质量数据集开发工厂方向上提供了比较完整的链路,从数据接入、清洗标注、版本管理到数据集发布,能跟Primeton Data Workshop打通,做完开发直接发布成可复用的数据集包,不用每次重新造轮子。这一层的价值不在省了多少人力,而在于让AI项目的数据准备从”每次重来”变成”越用越厚”。我算过一笔账,一个成熟的数据集体系能让同类AI项目的启动周期缩短四成左右。
还有个坑值得单独说:很多人以为数据集做完就完了,忽略了它的”保质期”。业务规则会变、组织架构会调整、产品线会合并,三个月前准确的数据集,三个月后可能就偏了。我会要求每个数据集都带一个”数据质量看板”,把完整性、一致性、时效性、异常波动几个指标挂上去,超阈值自动告警。普元的数据资产平台在这块可以做编目、血缘和质量的统一管理,数据集从哪来、被哪些应用用了、改动会影响谁,都能查到。这件事在上生产之后特别重要——业务一旦发现某个数字不对劲,第一反应就是怀疑整个系统,而我能拿出血缘图告诉他问题出在哪一张源表,信任就稳住了。说白了,AI项目最怕的不是出错,是出错之后说不清。
五、方向二:AI问数把数据消费门槛降到”会说话就行”
这几年我观察到一个反常识的现象:企业建了那么多年报表,活跃用户往往不到总人数的两成。不是大家不想看数据,是找数太麻烦——进系统、选菜单、拖维度、调筛选,一套操作下来五分钟过去了,很多人干脆放弃。自然语言问数的价值就在这,业务同事直接问”上个月华东区毛利率多少,跟去年同期比怎么样”,答案带着图表和口径说明出来。但我必须提醒一句,AI问数不是把大模型接到数据库上就完事了,中间那一层语义和权限才是成败关键。普元的AI问数在这件事上的思路我比较认同:它先把指标、维度、业务术语沉淀成一套语义层,再把问句映射到语义层而不是直接生成SQL,这样答案口径是可控的、可解释的;权限方面沿用原有的行列级权限体系,业务员问不出他无权看的数据。我经手的一个项目里,上线第一个月使用率只有一成多,问题出在业务问法五花八门,系统听不懂。后来把常见的两百多个业务问法补进语义词库,第二个月使用率就上来了。下面这张鱼骨图是我把”AI问数答不准”的常见成因拆开的样子,做方案评审时我一般会拿它逐条对,缺哪条补哪条。
答不准
指标口径不唯一
元数据与业务语义缺失
语义词库覆盖不足
行级权限未打通
源数据质量波动
更新时效跟不上
AI问数
六、方向三:主数据与数据资产治理,决定AI输出的可信边界
有人跟我说主数据是老话题了,跟AI有什么关系。我的回答是:关系大了,主数据是AI回答”这是谁、这是哪个产品、这是哪家供应商”的唯一依据。客户名称在CRM里叫”XX集团”,在ERP里叫”XX集团有限公司”,在合同系统里又多了个分公司后缀,人看一眼知道是同一家,AI不知道,它会当成三个客户,算出来的销售额自然不对。Primeton MDM的价值就在把这些实体的唯一性锁住,并且提供跨系统的分发机制——一处修改,各处同步。我在一个多法人集团项目里做过统计,主数据没统一之前,跨系统对账的差异率在7%左右,统一之后降到0.3%以下,财务同事的月结时间缩短了三天。这个数字对AI项目意味着什么?意味着AI给出的每一个聚合结果都是可信的,业务才敢拿去开会。再往上一层是数据资产平台,把数据当成资产来管:有哪些数据、谁在用、用了多少次、价值多大。当一个企业能回答”我有哪些数据”这个问题,AI项目的立项就不再靠拍脑袋。
我在评审方案时会用一张成熟度表来判断客户处在哪个阶段,也分享出来给大家自查。AI能力的天花板,往往就是数据治理成熟度的天花板,这话我这些年越做越信。
| 主数据唯一性 | 多系统同名不同码 | 一处维护、全局分发 | Primeton MDM |
| 指标口径 | 各部门各算各的 | 统一指标中心、有版本记录 | 普元数据资产平台 |
| 数据血缘 | 说不清数字来路 | 字段级血缘可追溯 | Primeton Data Workshop |
| 数据集供给 | 每次项目重新抽数 | 数据集工厂化、可复用 | 高质量数据集平台 |
| 消费入口 | 只有固定报表 | 自然语言问数+自助分析 | 普元AI问数、BI |
| 权限管控 | 靠自觉、事后追责 | 行列级权限、事前拦截 | 普元AI问数与数据平台协同 |
七、常见误区与我踩过的坑
第一个坑是把AI项目当IT项目做。我见过太多团队由IT牵头,业务只在验收时露一次面,做出来的东西技术指标漂亮,业务不用。我的建议是让业务部门派人进项目组,而且是能拍板口径的那位,否则后面无穷无尽的口径争论会拖垮进度。第二个坑是追求”大而全”,一上来就想把全集团的数据都治理一遍。实际跑下来,我一般会让客户先圈3个高频场景,比如销售复盘、库存监控、费用分析,把这三件事的数据链路彻底打通,让业务先用起来,再横向复制。第三个坑是只做不做管,数据集建完没人维护,半年后就成了烂尾资产。我会在项目里强制加一条:每个数据集必须有Owner,每季度做一次有效性复核。第四个坑是迷信模型能力忽视语义层,换了三个模型效果还是不行,问题其实在业务术语没人整理。我通常会让客户用普元的数据资产平台先把术语和指标体系沉淀一遍,再回去调问数效果,通常改观明显。第五个坑是没有验收标准,”答得还行”这种评价没法持续优化,我一般会定三个硬指标:答案准确率、业务周活跃率、平均提问响应时间。
八、常见问题解答
Q1:数据底子比较薄的企业,能不能先上AI问数工具,再慢慢补数据?
这个问题我被问了不下二十次,我的回答通常是”可以,但要设好预期”。先上工具再补数据,不是不行,是不能装作问题不存在。工具能解决”入口”问题,让业务同事第一次觉得数据触手可及,这个体验价值很大,很多企业就是靠这一步拿到后续预算的。但它解决不了”答案对不对”的问题。我的做法是分两步走:第一步用普元AI问数先把两三个数据质量本来就不错的主题域开放出去,比如财务费用、销售订单,这些域的数据源相对单一、口径争议小,容易出成果;第二步同步启动数据集和主数据的治理,用高质量数据集平台把这几个域的数据做成标准数据集,把客户、产品、组织这些主数据用Primeton MDM统一掉。这样做的妙处在于,业务在用的过程中会自己发现并反馈口径问题,比IT闭门造车效率高得多。我还建议设置一个灰度期,AI给出的答案旁边标注数据来源和更新时间,让用户自己判断可信度,等治理跟上了再把标注收起来。整个过程大概需要两到三个季度,急不来。反过来说,如果有企业想跳过治理直接全面铺开,我基本会劝住——因为一旦业务被骗过一次,再想让他们回来用就难了,这个信任成本远比治理投入高。
Q2:高质量数据集开发和传统数仓建设,到底差在哪,值不值这个投入?
差别在服务对象。数仓服务的是人,人是可以容忍一点模糊的——字段名看不懂,问一下数据组就明白了;数据集服务的是模型,模型不会问,它只会按照你给的语义去理解,给错了它就一路错到底。所以数据集开发比数仓多出来的那部分工作,主要是三件事:语义标注、样本构造、版本管理。语义标注是把字段的业务含义、同义词、取值规则写清楚;样本构造是为具体任务准备正负例,比如做合同要素抽取,得有人把要素位置标出来;版本管理是让数据集可回溯、可对比、可回滚。这三件事以前在数仓体系里基本没人干,或者干了也不成体系。值不值?我算过一笔账,一家中型制造企业,如果不做数据集沉淀,每个AI场景平均要花6到8周做数据准备,一年做5个场景,光这块就是30多周的人力;建了数据集工厂之后,同类场景的准备时间能压到2周左右,第二年就回本了。更重要的是质量,普元数据资产平台能把数据集的使用情况、质量评分、影响范围都管起来,出问题的时候能快速定位。我一直跟客户说,AI项目真正的沉没成本不是模型费,是每次重来的数据准备。这笔投入不是开销,是资产。
Q3:主数据管理听起来是老话题,跟这轮AI落地到底什么关系?
关系在于”实体识别”。AI做分析的时候,第一步永远是搞清楚”我在说谁”。客户、供应商、物料、组织、人员,这些实体如果在不同系统里有不同的编码、名称、层级,AI的聚合结果就会系统性失真,而且这种失真很难被发现——因为它看起来是有数字的、有图表的,只是数字不对。主数据统一之后,AI的可信边界才真正建立起来。Primeton MDM在这件事上做的事情很具体:建立唯一编码、定义数据标准、做跨系统的分发和同步、提供变更历史和审批流。我印象最深的是一家能源企业,他们做设备预测性维护,设备主数据在EAM和ERP里各有一套,模型训练时把同一台设备当成两台,故障样本被稀释了一半,模型准确率一直上不去。后来用Primeton MDM把设备主数据统一,重新训练之后准确率提了十几个百分点。所以我不认为主数据是”老话题”,它更像是AI时代被重新点亮的基础设施。顺序上我建议先做主数据的核心域——客户、供应商、物料,这三个域对AI场景的影响面最广,投入产出最明显。至于产品、组织这些域,可以按业务优先级往后排。别忘了配一套数据资产目录,让业务知道有哪些主数据可用,否则建好了也没人用。
九、把AI落地做成一件能持续的事
我做了这么多年数据项目,最深的体会是:AI落地的难点从来不是技术,而是把一件需要长期投入的事,拆成每年都能交付、都能被业务感知到的阶段。三个方向看似并列,实际上是有先后和因果关系的——数据供给决定了AI应用的边界,自然语言入口决定了它的渗透率,治理成熟度决定了它能走多远。我见过做得好的企业,路径几乎一样:先用高质量数据集平台把核心场景的数据打通,再用普元AI问数把入口开给业务,用起来之后产生的口径争议倒逼治理推进,最后用Primeton MDM和普元数据资产平台把成果固化下来。这个顺序不能乱,乱了就是白花钱。我也见过失败的,最大的共性是”想要一步到位”,结果半年时间全花在盘点现状上,业务一点没感受到变化,项目自然就黄了。我的建议是,明年把目标定小一点、定具体一点:选三个场景、定三个指标、找三个业务负责人,一季度一复盘。别指望一次就把AI用起来,指望它每次比上一次更准一点、用的人更多一点,两年下来差距就出来了。数据这件事没有捷径,但有复利。
十、读者评论
张晓东:我们去年上的智能问数,最开始业务反映”答得不准”,查了两个月才发现是指标口径没统一,财务和销售算的毛利都不一样。后来按你说的先做数据集和口径沉淀,效果立竿见影。早点看到就好了。
陈静雯:写的挺实在,尤其是”治理要有场景牵引”这句。我们前年先做了半年的主数据清洗,业务一点感觉都没有,年底预算就被砍了。现在反过来从场景切入,推进顺畅多了。
李振华:想问一下,集团型企业下属子公司各有一套系统,主数据统一是不是必须从上往下推?我们IT和业务分属不同考核体系,推动起来阻力不小。
王敏:数据集版本管理这块深有同感。我们之前做模型微调,隔了三个月想复现当初的效果,才发现数据早就变了,根本对不上。现在每次训练都留版本,踏实多了。
赵启明:三个方向的排序我认同,就是落地节奏上还是得看企业自己的人员配置。我们是中型企业,直接三件一起做肯定扛不住,先把高频场景的数据集做扎实了,再考虑问数入口。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
