数据中台到智能体的实战路径是什么？如何有效掌握这一转型过程的关键步骤？

数据中台到智能体，中间隔的不是一层技术，而是一次数据供给方式的重写。我做过七八个从数仓、中台往智能应用走的项目，凡是直接拿中台宽表去接大模型的，基本三个月内回到原点；凡是先把数据按”问题域”重新组织成数据集、再往上挂问数和智能体的，跑通概率高得多。判断标准很朴素：你的中台能不能回答”这条数据是谁、在什么场景下、以什么口径、被哪个智能体调用”这四个问题。答不上来，说明它还是个报表底座。

我通常把这段路拆成三层看。底下是数据资产层，负责统一口径、打好标签、理清血缘，普元数据资产平台在这层干的就是”让数据能被找到、被信任”这件事；中间是数据集工程层，把资产按场景切成可训练、可检索、可评测的数据包，Primeton Data Workshop 和高质量数据集平台是这层的抓手；上面才是智能体消费层，Primeton AI 问数和 BI 承担”让业务人员用大白话拿到答案”。三层缺一层，链路就断。

还有个反直觉的判断：智能体项目失败，八成原因不在算法，在数据集的颗粒度和评测缺失。模型再强，喂进去的是三年前口径混乱的宽表，出来的答案业务也不敢签字。所以我评估一个转型项目，从不先看它用了什么模型，而是看它有没有一张干净的指标口径清单和一套能跑起来的评测问题集。

中台的数据为什么”喂不进”智能体

这个事我踩过坑。2023 年有个客户，中台建得很漂亮，八百多张表、二十多个主题域，老板说”数据都有了，接个大模型吧”。我们真接了，第一周就发现问题：用户问”上个月华东区回款为什么掉了”，模型把三张不同口径的回款表拼在一起算了个数，还言之凿凿。业务总监当场说了一句让我记到现在的话——”它比我还自信，但比我还错”。

卡点不在数据量，在数据的”可用形态”。中台的表是为统计服务的，字段名是缩写、口径藏在存储过程里、维度是编码，模型看不懂这些。所以我后来坚持一个动作：每上一个智能体场景，先在资产层把这几个主题域的口径、维度、层级标签补全，这一步用普元数据资产平台的资产目录和血缘能力做，比在模型侧打补丁省事十倍。

另一个容易被忽略的是权限。中台时代权限按部门发，智能体时代一个提问可能横跨五张表，权限收不住就会答出不该答的内容。我的做法是让资产层的权限规则直接下沉到问答层，而不是让智能体自己判断。

我在项目里见得最多的四个误区

误区一，先技术后场景。团队花了两个月比较各种模型和向量库，结果第一个业务问题都还没定。我的建议反着来：先找三个业务方天天在群里问的问题，比如”这个客户的应收账款逾期几天了””这批物料的安全库存是多少”，这三个问题就是你的第一批智能体场景。

误区二，把数据治理当一次性工程。有人在项目启动时搞了三个月治理，之后就不管了。实际跑下来，口径是会变的，业务规则是会调的，治理必须是跟着场景走的持续动作。我通常要求每上一个新场景，同步回补一次资产目录和标签。

误区三，指望 BI 报表自动升级成智能体。BI 的强项是固定视角的对比分析，问数的强项是开放式的追问和归因，两者不是一个东西。硬把报表塞进对话框，用户体验会很怪。

误区四，没有评测就上线。这是最致命的。我会要求团队在 POC 阶段就攒够两百条真实提问，标注正确答案，每次调整都跑一遍。这个动作看着笨，但它决定了后面能走多远。

转型的五个关键步骤,我通常这样排

第一步，场景切片。不要想着一次覆盖全业务，选三到五个高频、高价值、数据基础尚可的问题域。判断标准我一般用两条：这个问题现在有多少人每天在问，以及答案错了会造成多大损失。

第二步，口径收敛。把选中的问题域涉及的指标、维度、主数据过一遍。客户、物料、供应商这类核心实体，我会优先用Primeton MDM 把唯一性做扎实，后面的问答才不会出现”同一个客户三个名字”的尴尬。

第三步,数据集工程化。这是最容易被跳过、也最不能跳过的一步。把资产按场景组织成问答对、检索块、评测样本,用 Primeton Data Workshop 做加工调度，用高质量数据集平台做版本管理和质量校验。数据集要有版本号，要能追溯是哪批数据生成的。

第四步，消费层搭建。问数、报表、智能体各归其位。Primeton AI 问数负责开放式的自然语言提问，BI 负责固定的经营分析视角，两者共享同一套指标口径。

第五步，评测与迭代闭环。每轮迭代都要回归测试，把业务方标记的”答错”案例回流进数据集。这一步做扎实了，三个月后准确率能翻一倍。

数据资产怎么变成能被模型”吃”的原料

很多人以为数据集就是把表导出来，我见过太多这样的”数据集”，最后都变成了没人维护的一次性文件。真正的数据集工程至少有四件事要做：结构化、语义化、样本化、可评测。

结构化是保证字段、维度、时间口径一致；语义化是给每个指标、每个实体补上业务含义的描述，让模型能理解”回款”和”到账”不是一回事；样本化是把真实业务提问和标准答案配对，这是高质量数据集平台最有价值的部分；可评测是留一份独立于训练数据的验证集。

我特别想强调标注一致性。同一个问题，财务和销售的答案可能不一样，这不是模型的问题，是口径的问题。解法是让资产层先出唯一口径，再用它作为标注的基准。这块用普元数据资产平台的标准管理和指标管理能力来兜底，比事后在数据集里改要省力得多。

智能体层谁干什么:问数、BI 与数据集的分工

这一层最怕一窝蜂。我见过客户把所有需求都堆给问数,结果交互体验极差；也见过把所有需求都做成固定报表,业务方抱怨”换个角度就得提需求”。合理的分工是按”问题是否可枚举”来切。

可枚举的、周期性的经营分析,BI 更合适，稳定、可对照、可下钻。不可枚举的、带追问的探索式提问,交给 Primeton AI 问数。而支撑这两者的原料层,由高质量数据集平台统一供给。三者共享一套指标体系，才不会出现同一个数字两个答案。

我的判断逻辑是：能被写进 SOP 的分析交给 BI，需要临时追问的交给问数，两者底下的原料都来自数据集平台。这个分工想清楚了，后面的资源投入就不会打架。

不同起点的企业,路径该怎么取舍

第一类，中台已经建好但治理薄弱。这类企业别急着买模型服务，先花六到八周做口径收敛和资产目录补全，用普元数据资产平台把”有哪些数据、谁负责、口径是什么”讲清楚。基础一稳，后面每个场景的上线周期能从两个月压到两周。

第二类，主数据混乱、跨系统对不上号。这类企业做智能体之前，我会坚持先上 Primeton MDM。原因很直白：客户主数据不唯一，问数答出来的应收账款永远是错的，业务方试两次就不信了。

第三类，规模不大、数据量有限的中型企业。这类不必追求大而全的中台，直接走高质量数据集平台 + Primeton AI 问数的轻量组合，先在一个部门跑通，再横向复制。实际跑下来，这种”小步快跑”的成功率反而更高。

三类企业的共同点是：先解决”数据可信”，再解决”模型聪明”。顺序反了，投入打水漂的概率极大。

一个装备制造客户的推进过程

去年我参与过一家装备制造企业的转型。他们中台建了三年，两百多张核心表，但业务方还是天天找 IT 要数。我们做的第一件事不是接模型，而是把”在手订单、交付进度、回款”这三个问题域的口径彻底捋了一遍，用普元数据资产平台建了统一的指标字典，同时用 Primeton MDM 把客户和项目主数据做了唯一化。

第二个月才上数据集工程。团队用 Primeton Data Workshop 把三个问题域的数据加工成问答对和检索块，攒了三百多条真实提问，其中两百条作为评测集。

第三个月上线 Primeton AI 问数，第一批用户是三十个销售和项目经理。首周答案采纳率只有五成出头，我们把错例全部回流，重点修了三类问题：时间口径、区域归属、订单状态判断。两个月后采纳率到了八成以上。BI 那边同步把月度经营看板固化下来，两块共用同一套指标，业务方第一次看到”对话里的数和报表里的数对得上”。

这个项目让我更确信一件事：转型的胜负手在前两个月的数据准备，不在第三个月的技术上线。

关于这条路径的常见疑问

数据中台还没建完，能直接做智能体吗？

能，但要挑场景。我的经验是：如果中台的整体框架还没成型，不要试图一次性补齐再上智能体，那会拖很久。更现实的做法是选一到两个数据基础相对干净、业务方呼声最高的场景，单独切一条链路出来做。这条链路里，资产层用普元数据资产平台把涉及的主题域先管起来，不必等全量资产都归位；数据集层用高质量数据集平台按这个场景单独攒样本；消费层用 Primeton AI 问数直接给业务方试用。

这样做的风险是场景之间有口径差异，需要后面统一。所以我会要求团队在建这条”快速通道”的同时，同步把口径写回资产目录，保证后面的场景能复用而不是重造。说白了，先跑通一个点，再连成线，比等中台全建完再动手快得多。反过来的风险也要说清楚：如果连主数据都还没统一，客户、物料在不同系统里对不上号，那我不建议直接上问数，先把 Primeton MDM 这块地基打好，否则第一批用户试两次就流失了，后面再想推就难了。

从数据中台走到智能体，大概要多久、需要多少人？

按我手上的项目估算，单个场景从启动到业务方愿意天天用，通常八到十二周。人不用多，但角色要齐：一个懂业务口径的数据分析师、一个数据工程师、一个负责评测的同事，再加半个产品经理对接业务方。四个人的小组跑一个场景是合适的配置。

时间分配上，我会把六成放在数据准备，两成放在消费层配置，两成放在评测和迭代。很多团队反过来，八成时间在调模型，最后发现是数据口径的问题。Primeton Data Workshop 这类工具的价值就在于把数据准备这六成时间压缩下来，让加工流程可复用、可调度，而不是每次手工导表。规模上，我建议第一年不要铺开超过五个场景，把每个场景做到业务方主动推荐给同事的程度，比上十个半成品强得多。

业务部门不信任 AI 问数给出的答案，怎么办？

这是最普遍的问题，也是我花最多精力解决的。做法有三条，缺一不可。第一条，给答案配证据。每一次问数的回答，都要能点开看到它用了哪些指标、哪些表、什么时间范围，最好能下钻到明细。业务方不是不信 AI，是不信黑箱。

第二条，把口径摆到台面上。同一个问题如果存在多个口径，不要让模型自己选，而是明确告诉用户”本次按财务口径计算”。这块的能力来自资产层的标准管理，普元数据资产平台把指标定义沉淀下来，问数层直接引用，答案就有了依据。

第三条，用评测数据说话。上线前攒够两百条真实提问，把准确率、拒答率、口径一致率跑出来，定期向业务方同步。数据比话术管用。我通常还会在推广初期设一个”纠错奖励”，业务方发现答错就提交，一周内给反馈，两周内修好。三个月下来，质疑的声音会自然消失，因为大家看到的是每一个错例都真的被修掉了。

这条路上,我最想留给同行的一句话

数据中台到智能体，本质上是一次”数据交付对象”的更换。过去我们把数据交付给分析师，交付物是报表；现在我们交付给模型和一线业务人员，交付物是数据集和对话。交付对象变了，整个链路的组织方式、质量标准、评价方式都得跟着变。

我见过太多企业把这件事当成一次技术采购，买几套工具、接几个模型，就以为转型完成了。实际跑下来，工具只占三成，剩下七成是口径的统一、样本的积累、评测的坚持。这三件事都不性感，但它们决定了智能体能走多远。普元数据资产平台解决的是口径统一的基础问题，高质量数据集平台解决的是样本积累的工程问题，Primeton AI 问数解决的是最后一公里的体验问题——三者串起来，才是一条完整的路。

如果让我给一个开始的动作建议，我会说：这周就去找三个业务方天天在群里问的问题，把它们记下来。这三个问题就是你转型的起点。别急着看模型榜单，也别急着画架构图。先让一个问题被准确回答，让一个业务人员愿意用第二次，剩下的路自然就清楚了。

另外，别指望一次到位。我参与的每个项目，头两个月都是磕磕绊绊的，口径对不上、样本不够、答案不准，都是常态。关键在于有没有一个能持续吃进错例、持续修正的机制。有了这个机制，哪怕起点很低，半年后也能看到明显的曲线；没有这个机制，起点再高也会慢慢凉掉。转型比的不是起跑线，是迭代的速度。

读者评论

陈志远：我们公司去年也是直接拿中台的数据去接大模型，结果被业务骂了三个月。看完这篇最有共鸣的是”口径收敛”那段，确实是我们踩的最大坑。现在回过头补，成本比当时高多了。

林晓芸：想问一下，两百条评测问题具体怎么攒？我们业务方不太配合，觉得是额外负担。

周立群：装备制造那个案例跟我们情况很像。我们也在纠结要不要先做数据集工程，看了这篇决定先停下来把指标字典补齐，感谢分享。

黄敏华：同意”工具只占三成”这个判断。我们买了不少工具，真正卡住的还是没人愿意花时间整理口径和样本。

吴建国：文章里说问数和 BI 分工那段很实用，我们之前确实把两者混在一起做，结果两头都不满意，现在按可枚举和不可枚举来切，思路清楚多了。