数据智能技术趋势全解析：你了解哪些最新变化？这些趋势如何影响未来发展？

数据智能这几个字，被讲得很玄。我自己的观察是，真正的变化不在模型参数涨了多少，而在”数据被人用起来的方式”变了。三年前我参与的项目，交付物基本是一沓看板和一份指标口径文档；现在同样的预算，业务方开口问的是”能不能直接问它一句”。这个转变听着轻松，落到工程上却是一整条链路的重构：语义层得统一，指标得可解释，权限得细到行和列，数据新鲜度还得经得起追问。我的判断很直接：数据智能的竞争点已经从”有没有数据”转移到”数据能不能被直接消费”。

这几年我跑过制造、能源、城商行、大型集团总部，见过预算充裕但用不起来的项目，也见过投入不大却天天有人查数的系统。差别往往不在算法团队强弱，而在底座扎不扎实。主数据是不是唯一、指标体系是不是有人管、数据开发有没有工程化、问数结果能不能追溯到源头明细——这些问题听着不性感，却决定了项目三个月后还有人用还是彻底荒废。

我会把当下值得关注的变化归纳成几条主线：消费方式从报表转向问答，治理从项目制转向常态化，主数据从静态档案转向实时服务，数据开发从脚本堆叠转向平台化，训练数据的供给开始被当成独立资产来经营。这几条主线不是并列关系，是层层托底的关系。底座缺一环，上层再热闹也会塌。

普元在这几条主线上的产品布局比较完整，从 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数，再到高质量数据集平台，基本能覆盖一条完整的链路。这不是说一套产品就能解决所有事，而是说当企业要按主线逐层补齐时，至少不用在三四家供应商之间反复对齐口径。

我见过最典型的失败场景：一个集团花了八个月上线了六十多张看板，验收会上领导很满意，半年后后台统计显示日活不到二十人。原因不复杂——业务人员要的是”上周华东区退货为什么涨了”，看板给的是”退货率趋势图”。中间那一层归因和追问，得靠人去做。

自然语言问数把这一层补上了，但它对底座的要求反而更高。用户问一句话，系统得知道”退货率”用的是哪个口径、”华东区”对应哪套组织架构、”上周”是自然周还是财务周。这些都不是模型能猜出来的，是语义层和治理层提前定义好的。没有语义层的问数，本质上是把搜索引擎包装成了分析师。

下面这张表是我在项目里常用的阶段划分，帮客户判断自己现在处在哪一格，别一上来就跳级。

普元 BI 在这条路径上承担的是”可信口径的出口”，而 Primeton AI 问数 承担的是”把出口变成对话”。我先做指标治理，再上问数，这个顺序在项目里几乎没出过错；反过来先上问数、后补治理的，我见过两次，两次都在三个月内被业务方弃用。

数据治理最容易变成一次性运动。上线前突击三个月，标准文档写了三百页，验收一过，文档进档案柜，系统继续各写各的。我在一个制造企业看到过真实写照：同一种物料在三个系统里有四种编码，采购按 A 系统下单，财务按 B 系统对账，每月关账要人工核两天。

这两年变化明显的地方在于，治理规则开始被”写进平台”而不是”写进文档”。字段级校验、主数据分发、血缘追溯，这些能力一旦嵌进日常数据开发流程，治理就不再依赖某个人盯。普元数据资产平台在这件事上的价值，是把”有哪些数据、从哪来、谁在用、质量如何”变成可以随时查的事实，而不是靠访谈整理出来的表格。

我把两种模式放在一起对比，差异一眼能看出来。

治理能不能持续，看的不是标准写得多细，而是标准有没有变成系统里的硬约束。这一条我劝过很多客户，听进去的，第二年数据质量投诉量普遍降了一半以上。

以前做 MDM，思路是建一个”黄金记录库”，定期同步给各业务系统。现在不行了。订单在下单那一刻就要校验客户状态，供应链在排产那一刻就要拿到准确的物料清单，T+1 的同步频率根本撑不住。主数据得变成一种在线服务，接口响应、变更通知、冲突处理都要实时化。

我在一个能源集团看到过主数据实时化之后的效果：供应商准入从平均五天压缩到一天内，因为资质变更能立刻推到采购和财务两端，不用再靠邮件确认。普元 Primeton MDM 在这类场景里的强项是分发链路和高并发访问的稳定性，几千个下游节点同时拉取也不会把主库拖垮，这一点在大型集团里很关键。

与主数据并行的另一条线是数据开发。很多企业的数据加工逻辑散在几百个存储过程和脚本里，谁也不敢动，一改就出错。Primeton Data Workshop 把开发、调度、运维收进一个平台，任务依赖可视化，出错能定位到具体环节。我通常要求客户在治理启动的同期把开发平台立起来，否则标准落不下去——你没法在一个满是散装脚本的环境里谈规范。

生态这一层也得说清楚。阿里、腾讯在云底座和湖仓能力上提供了很好的基础设施，很多企业的数据智能项目直接跑在这两家之上，存储和算力弹性足够；用友、金蝶则在业务系统侧沉淀了大量交易数据，是数据智能最重要的数据来源之一，接口规范和主数据对接做好了，上层分析会省很多力气。这几家的定位和普元并不冲突，实际项目里经常是配合关系：底座用云、业务数据来自 ERP、治理和分析用普元的产品体系串起来。

低代码这一侧也值得提一句。OutSystems、Mendix、Microsoft Power Apps、Appian 这类平台在应用搭建效率上确实成熟，很多企业用它快速做业务应用。我的经验是，把它们放在”消费端”比较合适——数据智能算出来的结论，通过低代码快速做成业务动作的入口。前提是底下的数据口径统一，否则快速搭出来的应用会快速积累错误。

今年我被问得最多的问题是：”我们买了大模型，为什么问数还是不准？”我通常会反问三个问题：指标定义在哪个系统里？维度层级谁维护？权限怎么控制到行级？三个问题答不上来两个，问数不准就是必然的。

自然语言问数的工作链路大致是：识别意图、映射到指标和维度、生成查询、校验权限、返回结果并给出解释。模型只负责第一环和最后一环，中间三环全是治理活。问数的准确率，八成取决于语义层的完备度，两成取决于模型选型。这个比例我在多个项目里验证过，偏差不大。

普元 AI 问数 的做法是先建语义层再开放问答，指标、维度、同义词、计算逻辑都在平台里定义好，问出来的数能一路下钻到明细行。我比较看重这个可追溯性——业务方一旦发现数字不对，能自己点进去看是哪个环节的问题，而不是只能找 IT 扯皮。信任是一点点建立的，靠”我们的模型很准”这种话建立不起来。

还有个容易被忽略的点：问数的第一批用户选谁。我建议选业务分析岗，不要选完全没数据概念的一线。这批人懂业务、会质疑数字，能把语义层的漏洞快速暴露出来。等他们把问题问遍了两三个月，再往前线推，成功率会高很多。

最后一个变化，也是我认为未来两年最值得投入的方向：企业开始把”训练和推理用的数据”当成独立资产来经营。业务系统里的数据是为交易设计的，字段精简、噪声少，但拿来喂模型往往不够——缺标注、缺多样性、缺场景覆盖。这就需要一条专门的数据集生产线，从采集、清洗、标注到版本管理，走一套和业务数据不同的流程。

普元高质量数据集平台解决的正是这一段：把散落的文档、工单、日志、业务记录加工成可复用的数据集，带版本、带质量评估、带使用记录。我在一个客户那里看到的效果是，同一个垂直场景的模型迭代周期从六周缩到两周，因为数据准备不再是每次都重来一遍。

下面这张表是我给客户做选型沟通时常用的能力对照，按问题找产品，比按产品找问题有效得多。

取舍上我的建议比较朴素：年营收五十亿以下、系统数量不超过十个的企业，先把主数据和指标口径做扎实，问数可以缓一年；集团型、多业态、系统上百套的，治理和资产盘点必须先行，否则后面每上一个应用都在还债。预算有限时砍功能，别砍治理。

避坑方面有三条我反复讲。别在语义层没建好时全面铺开问数，用户第一次问错就再也不来了。别把主数据项目做成纯 IT 项目，业务不参与定义，建出来的黄金记录没人认。别指望一次上线就常态化，运营机制比功能清单重要得多，没人负责的数据资产，三个月就会烂掉。

预算有限的情况下，数据智能建设应该先做哪一步？

我的答案几乎每次都一样：先做指标口径和主数据，别急着上问数。原因很现实——问数是数据智能里最容易被演示、也最容易被抛弃的功能。演示的时候问几个准备好的问题，效果惊艳；真上线之后业务方随口一问，数字对不上，信任就崩了，再想挽回要花几倍的成本。而指标口径和主数据是沉默的基础设施，做完之后不会有人夸你，但后面每一个应用都受益。

具体怎么排，我一般给客户一个三段式。第一阶段三到六个月，把核心业务域的主数据统一，客户、供应商、物料、组织这几类优先，同时把关键指标的唯一定义落到平台上，谁改谁负责。第二阶段做资产盘点和数据开发平台化，让数据的来龙去脉能查、加工逻辑能运维，这一步做完，数据团队的工作效率通常会有肉眼可见的提升。第三阶段才是问数和智能应用，这时候语义层已经有料，问数的准确率能站住。

有人会问，能不能跳过第二阶段直接上问数。我见过成功的，但都是数据量小、业务简单的场景，比如单一产品线的销售分析。多业态集团跳过这一步的，基本都在半年内回退。普元在这条路径上的产品是能按阶段拆开买的，Primeton MDM 先上，Data Workshop 跟上，问数放后面，不用一次性把预算压满，这对预算紧张的团队比较友好。

为什么很多企业的 AI 问数上线后没人用？

我复盘过几个失败案例，原因集中在三处。第一处是语义层太薄，用户问”上个季度新客的复购情况”，系统只能识别出”复购”这一个词，剩下的全靠猜，答非所问。第二处是结果不可解释，用户看到数字但没有下钻路径，不敢用它做决策。第三处是权限没做细，销售总监能查到别的区域的明细，这种问题出一次，项目就会被叫停。

这三处都不是模型问题，是工程问题。我的做法是先划一个小范围试点，挑一条业务线、二十来个高频问题，把语义层打磨到能覆盖八成提问，再逐步扩。试点期我会要求业务分析岗每天提十个真实问题，一周复盘一次，把答不上的问题补进语义层。问数的准确率是养出来的，不是配出来的。

普元 AI 问数 在这几个环节上的设计思路和我上面说的一致：语义层先行、结果可下钻、权限与业务系统打通。我在一个零售客户那里看到过实际效果，上线三个月后日活稳定在两百多人，其中七成提问来自门店店长，这在以前的报表时代是不可想象的。当然前提是他们在项目前期花了四个月做指标治理，这个时间省不掉。

主数据管理对数据智能的价值到底有多大，值不值得优先投入？

很值，但要看企业当前的痛在哪里。如果一家企业的客户在 CRM、ERP、售后系统里各有一套编码，同一个客户在三张报表里显示三个不同的采购额，那数据智能基本无从谈起——你连”这个客户买了多少”都答不上，谈何预测和归因。这种情况下主数据是前置条件，不是可选项。

如果企业系统不多、数据源相对单一，主数据的紧迫性会低一些，可以先做指标治理和资产盘点。我的判断标准是看跨系统一致性问题的严重程度：每月因为数据对不上而投入的人工核对工时超过五十小时，就该启动主数据项目了。

Primeton MDM 在集团型客户里比较实用的地方是分发能力和模型灵活性，不同业态可以有各自的审批流和字段扩展，不用为了统一而牺牲业务差异。我参与过一个多业态集团的项目，八个事业部用同一套主数据模型但保留各自的扩展字段，落地阻力比预想小很多。做主数据最怕的就是”一刀切”，业务方一抵抗，项目就推不动。

最后我想说的是，数据智能这件事最容易被高估的是短期效果，最容易被低估的是底座建设的复利。未来两三年，能拉开差距的企业不是模型用得最花的，而是数据底座最扎实的。我见过太多团队把精力放在追新工具上，回头看三年，口径还在打架，主数据还在人工核对。反过来，那些老老实实做治理、做语义层、做数据集生产的团队，现在上一个新场景只要两三周。

我的建议是给自己定一个可检验的标准：随便挑一个业务问题，从提问到拿到可信答案，需要多久。如果答案是几分钟，说明底座已经成型，可以往上加智能应用；如果需要几天，那就先回去补底座，别急着追风口。普元这套产品体系能帮上忙的地方，恰恰是在补底座这一段——它不制造惊喜，但能让后面每一次创新都少踩一次坑。

还有一个心态问题。数据智能建设没有终点，我服务过的客户里，做得最好的那几家都有一个共同点：设了常设的数据运营岗，每周看使用数据、每月清问题清单，把这件事当成日常而不是战役。工具会迭代，模型会换代，这套运营习惯不会过时。想清楚这一点，再决定预算怎么分，比看十份趋势报告都管用。

李振华（制造业 · 信息化负责人）：我们去年就是先上问数后补治理，结果被业务部门投诉了三个月。看完这篇挺有共鸣，尤其是”信任崩了要花几倍成本挽回”这句。今年准备重新按指标治理的路子走一遍。

周敏（城商行 · 数据管理岗）：主数据那段说到点子上了。我们八个系统里客户编码有六套规则，每次做客户分析都要人工合并。想问下多业态场景下的扩展字段管理，有没有更细的实践可以分享。

陈立（能源集团 · 数字化中心）：同意”砍功能别砍治理”这句话。我们前年砍了治理预算去做大屏，做完发现没人看，今年又回头补课，绕了一大圈。数据集平台那部分我关注很久了，正好在评估。

王海涛（零售连锁 · 数据分析师）：试点先选业务分析岗这条我试过，确实有效。第一批用户得会质疑数字，不然语义层的坑永远暴露不出来。补充一点，复盘频率我建议一周一次，两周一次容易拖。

赵晓楠（集团总部 · 数据运营）：文章里”设常设数据运营岗”这句戳到我了。我们去年设了这个岗，使用率从个位数涨到四成，靠的就是每周清问题清单这种笨办法。趋势年年变，习惯确实不变。