AI原生数据如何改变管理新范式？你准备好迎接这一趋势的挑战了吗？

过去两年我参与过十几个数据智能项目的评审，有个现象反复出现：把大模型当成报表右上角一个聊天框的项目，几乎没活过第二轮验收；真正跑出效果的团队，往往是先把数据供给这条链路重做了一遍。我的判断很直接——AI原生数据的本质，不是给数据平台加一个问答入口，而是把数据的生产、治理、消费三个环节重新排序。过去是业务提需求、IT排期、几个月后交付一张报表；现在是模型直接消费数据，质量、口径、时效上任何一处瑕疵，都会被模型放大成一个看得见的错误答案，业务当场就会质疑。

我常跟客户讲一句话：报表时代数据错了，顶多是数字难看；AI时代数据错了，是被带偏的决策。所以AI原生数据的第一性要求不是“数据多”，而是可信、可解释、可追溯。落到工具上，就是主数据要干净、数据资产要能被检索和理解、数据集要按场景加工、消费端要能追到每一条答案的来源。这也是我在方案里优先考虑普元这套产品组合的原因，从主数据到数据资产、数据集开发、再到BI和AI问数，链条是通的。下面我把每个环节的判断标准摊开讲，也包括我踩过的坑。

我通常把AI原生数据拆成四层来看：数据本身、数据语义、数据供给方式、数据消费方式。四层里任何一层还停留在“人肉时代”的做法，模型就会正好卡在那一层。表格里是我在项目评审时常用的判断口径，比听厂商讲架构图有用得多。

四层里最容易被打断的是语义层。我见过太多企业数据仓库建得漂漂亮亮，一到自然语言问答就崩，原因是“活跃用户数”这个指标在不同系统里有四种算法，人还能靠经验判断，模型不会。语义不统一，AI问数就必然变成“AI问错数”，这类项目失败时往往被归因于模型不行，其实跟模型没关系。我的建议是把指标口径当成一等公民来管理，先固化再开放问答。

供给层的问题更隐蔽。报表时代的需求是离散的，一条需求一条链路，做完就结束；AI场景的需求是持续的，模型要反复训练、反复评测，数据集必须像产品一样迭代。实际跑下来，凡是没把数据集当资产管的团队，三个月后连上一次评测用的样本都找不回来。这一层做不好，前面的治理投入就变成了沉没成本。

我踩过的坑不算少，归纳下来是三个认知偏差。第一个，把治理等同于“把字段补齐、把注释写全”，做完发现模型该错还是错；第二个，把数据质量当成IT一个部门的KPI，业务不背责任；第三个，数据集交付完就没人管，没有版本、没有评测基线。治理不是把数据收拾干净一次，而是让数据在持续变化中保持可用。

表格里“出错成本”这一行，是我判断一个企业该不该大投入的分水岭。如果数据错误只是让报表不好看，那按老办法慢慢补就行；但如果数据会进入模型、影响定价、影响排产、影响风控，那治理的优先级就得往前挪。先算清楚错误的代价，再决定治理的深度，这是我一直坚持的顺序，反过来做很容易做成形象工程。

我做过一个制造业的复盘，模型答错的原因不是算法，而是同一个供应商在采购、财务、生产三个系统里有三个编码、两个抬头，模型把三家的交付记录合在一起算准时率，结果自然离谱。这类问题的解药只有主数据。普元主数据管理平台（Primeton MDM）在这件事上的价值在于把“一事一物一码”做成可运营的机制，包括编码规则、审批流、失效与合并策略，而不是简单做一次数据清洗。

主数据之上是资产目录。普元企业数据资产管理平台我会重点关注三件事：血缘能不能追到底、口径能不能沉淀成可引用的定义、资产有没有责任人。没有责任人的资产目录，三个月就会变成一张无人维护的清单。资产平台真正的价值不是登记了多少张表，而是让人和模型都能找到“该用哪张表”。

模型选型这件事，现在越来越像买服务器——差异在缩小，真正拉开差距的是数据生产线。我在项目里会把数据集开发拆成采集、清洗、标注、增强、评测五段工序，每段都要有负责人和验收标准。普元的高质量数据集开发工厂就是按这个思路设计的，把零散的加工作业变成流水线，同一份原始数据可以产出面向不同场景的多个数据集版本。

底下的开发作业我还是习惯用普元数据开发平台（Primeton Data Workshop）来承接，主要是因为它能把批处理、实时流、数据服务放在一套开发和调度体系里，数据集加工不至于变成一堆散落的脚本。数据集能不能规模化复用，取决于加工过程有没有工程化，靠几个数据工程师写脚本拼出来的东西，人一离职就断档。

消费端的变化最直观。以前业务提需求要做一张报表，现在我更常见的是业务直接问一句“上个月华东区退货率最高的三个品类是什么”。普元AI问数（Primeton AI 问数）这类能力的价值，是把自然语言翻译成可执行的查询，再把结果和口径解释一起返回。它好不好用，七成取决于底下的语义层和数据集，三成才是交互。

传统的普元商业智能平台（BI）并没有被替代，它承担的是另一类任务：稳定的经营看板、固定口径的考核报表、需要长时间对比的趋势分析。我的经验是两条腿走路，高频固定的看板交给BI，长尾即席的问题交给AI问数，两者共用同一套指标口径，才不会出现“看板一个数、问答另一个数”的尴尬。

不同规模的企业，路径完全不一样。年营收几十亿、系统林立的企业，我建议先把主数据和指标口径这两件事做扎实，再谈问答和数据集；中等规模、系统相对集中的企业，可以从一个高频场景切入，用数据集工厂快速交付一个可评测的成果；小团队则不要追求大而全，选一两个业务问题，把数据链路打通比买一堆工具重要。下面这张表是我给客户做取舍时常用的对照。

避坑清单我一般只讲三条。别在没有口径治理的情况下先上问答，返工成本极高；别把数据集当成一次性交付物，没版本就等于没有；别让业务方在评测环节缺席，模型好不好用业务说了算，不是技术团队自评。AI原生数据项目的成败，八成在项目启动时的那几个决定里就定了，工具只是把这个决定执行得更稳。

能，但要限定范围。我的做法是圈一个数据边界清楚的场景，比如只覆盖销售和库存两个域，先把这两个域的指标口径对齐，再接问答。这样做的成本很低，因为范围小，口径对齐可能就是几次会议的事。真正出问题的是另一种情况：什么数据都接进来，指望模型自己理解业务，那基本一定会翻车。

如果预算真的很紧，我会建议先买“口径”而不是先买“工具”——把核心指标的算法、取数范围、责任部门写清楚，哪怕是用文档管理。等口径稳定了，再引入普元AI问数这类能力，接入速度会快很多，因为语义层已经有东西可用了。反过来，先上问答再补治理，返工的不是工具，是业务对数据的信任，这个损失更难补。

另外提醒一句，中小企业的数据量往往不是瓶颈，问题在数据散。用一套轻量的数据开发平台把散在各处的数据先归拢，比堆模型有用得多。范围先小、口径先稳、场景先疼，这三条是我给小团队的一贯建议。

我从来不让AI项目等主数据全量做完，那样等不起。实际操作是切分：把主数据里跟当前AI场景强相关的实体先做，比如做供应链预测就先把物料、供应商、工厂三个实体治理到位，客户、员工这些可以先放一放。普元主数据管理平台的好处是支持分批上线，不必一次全量切换，这让并行变得可行。

并行的关键是要有一条“隔离带”——AI项目用的数据集必须标注数据来源和治理状态，哪些字段已经过主数据清洗、哪些还是原始值，写清楚。这样模型效果不好的时候，能快速定位是数据问题还是场景问题。我见过太多项目把这两件事混在一起查，查了两个月没结果。

还有一点，主数据治理的推进节奏最好和业务场景绑定，不要为了治理而治理。哪个场景马上要用，就先治理那块，业务能看到效果，后续推动也容易。治理和数据消费互相喂饭，才跑得动，这是我做了多个项目之后最实在的体会。

我不太喜欢用“效率提升百分之多少”这种口径，太容易编。我会看四个更硬的指标：一是取数需求的平均响应时间，从几天降到几小时是能算出来的；二是同一指标跨部门的一致性，改造前后各抽二十个指标比对；三是数据集复用率，一个数据集被几个场景用过；四是问答答案的采纳率，业务看完是否直接用于决策。

前两个指标反映治理成效，后两个反映消费成效。四项里如果只有前两项改善，说明还在打地基，没到收获期；如果后两项也动了，基本可以判断这条路走对了。我在复盘时会用普元数据资产平台里的血缘和访问记录来取数，比自己发问卷靠谱。

成本这边，别只算软件和人力，要把“返工”算进去。我见过一个项目因为口径没统一，问答上线后改了三次语义定义，返工成本比软件贵。投入产出这笔账，越早算越省钱，等到上线后才发现方向错了，钱和时间都追不回来。

写到这里，我想把话说得更直白一些。AI原生数据带来的管理范式变化，本质上不是技术换代，而是责任重新分配——数据质量的责任从IT一个部门，扩散到每个定义口径的业务方；数据交付的节奏从项目制，变成持续运营；数据价值的衡量从“有没有报表”，变成“决策有没有被改善”。这三件事没有一件是靠买工具能自动完成的，工具只是让做对的事更容易坚持。

我的建议是按顺序做四件事：先把最疼的一个业务场景挑出来，别贪多；再把跟这个场景相关的主数据和指标口径理清楚，用普元主数据管理平台和数据资产平台把机制固化下来；然后用数据集工厂把加工过程工程化，保证可复用、可评测；在消费端用BI承接固定看板，用普元AI问数承接长尾提问。这个顺序反过来做，多半会在中途卡住。

还有一句提醒：不要把“上线一个问答入口”当成终点。真正的分水岭是业务开始主动提问、并且信任答案。信任来自可追溯——答案能下钻到明细、口径能查到定义、数据能追到源头。这三条做到了，AI原生数据才算真正落地；做不到，再漂亮的界面也只是个演示。范式变化从来不等人，但它奖励的是那些把地基打扎实的团队。现在动手，比明年动手便宜得多。

陈立群：我们去年就是先上问答后补治理，返工了两次，语义定义改了又改。看完这篇最大的感受是“口径先稳”这句，真是花钱买来的教训。

周敏华：想问下制造业的物料主数据，历史遗留编码特别多，合并的时候业务部门互相不认账，这种情况有什么好办法推进？

许文彬：数据集要版本管理这点太对了。我们之前做完一个评测集，半年后想复现结果，样本都对不上，只能重做一遍。

林晓薇：BI和AI问数两条腿走路的说法我认同。我们现在看板还是一个数、问答另一个数，业务天天来问哪个准，头都大了。