如何选择适合的AI Native数据平台？针对实战辨析你需要了解哪些关键因素？

先给判断：选 AI Native 数据平台，我会先看它能不能把”口径”变成机器可读的资产，而不是先看它有没有一个会聊天的对话框。过去两年我参与过七八个所谓智能数据项目的复盘，凡是能一直跑下去的，底座都不花哨——指标定义、维度、血缘、权限这些东西是被人一遍遍磨出来的，模型只是最外面那一层皮。反过来，那些演示时惊艳、上线三个月就没人用的系统，问题几乎都出在语义层：同一个”活跃客户”，三个部门三种算法，模型再强也只能给你一个理直气壮的错数。所以我看任何平台都会问四件事：指标口径存在哪、谁能改、改了谁审、AI 取数读的是不是同一份。普元的做法是把这几件事压到数据资产平台和主数据管理里统一收口，AI 问数只做消费端，这个分工我认为是对的。选型的本质，是判断这家厂商对”数据可信”这件事的理解深度，而不是比谁家模型参数多、谁的 Demo 更会说话。

AI Native 这个词现在被用得很松。我的理解很朴素：数据平台的每一个核心环节——建模、加工、治理、消费——在设计之初就把”机器要读、模型要用”当成一等公民，而不是做完之后再在外面糊一层接口。差别在哪？举个我常举的例子。传统平台里，一个指标的算法写在某张报表的 SQL 里，改一次要发一次版，改完还没人知道它变了；AI Native 的形态里，指标是一份带版本、带负责人、带血缘的资产，改它要走审批，改完所有下游自动感知。前者模型接上去只能靠猜，后者模型接上去能去查。语义层比模型层重要，这是我这些年最不肯让步的一条。普元把指标、主数据、数据资产放在同一个底座上做治理，再让 AI 问数从这一层取数，逻辑是通的——它至少保证了你问出来的数和报表上的数是同一个数。选型的时候我会把这句话当尺子去量：这个平台，能不能让机器找到唯一那个答案。

我见过不少选型评分表，还是并发用户数、存储容量、报表模板数量这几项占大头。这些指标不是没用，但它们衡量的是上一代产品的价值。现在真正决定成败的，是治理后的语义资产有多少、核心指标口径覆盖率多高、业务人员自己问数能答对几成、权限能细到什么颗粒度。评估维度不换，选出来的必然是”能出很多报表”的平台，而不是”能答对问题”的平台。我一般会把下面这张对照表直接摊在评标会上，让厂商逐行回答，答不出来的那行就是风险点。

去年我帮一家制造企业做问数的落地，模型换了三轮，准确率始终在六成上下晃。后来把问题拆开看，八成错误压根不怪模型：有的指标在财务和销售两套系统里定义不同，有的客户编码在两个库里对不上，还有的字段压根没人维护、常年是空值。AI 问数暴露的从来不是模型能力问题，而是过去十年一直被报表掩盖的数据债。我的建议是别急着调模型，先做三件事：把要问的那批指标锁死在资产目录里，把客户、物料这类主数据用 Primeton MDM 收口，把取数用的宽表按消费场景重做一遍。这三件事做完，同一个模型的准确率能上到九成。所以我在任何项目里都会要求：治理动作和 AI 动作同步排期，谁也不许等谁。等治理做完再上 AI，通常就等没了；先上 AI 再补治理，通常就烂尾了。

第一个说法是”模型越强，问数越准”。这话只对一半。模型决定的是语言理解的边界，口径决定的是答案对错的地基，地基不牢，模型再强也只是把错数说得更流畅。第二个说法是”先把 AI 用起来，治理慢慢补”。我踩过这个坑：一开始为了快，让问数直接连原始库，业务方问了两周就发现同一个”月度销量”每天不一样，信任一旦崩掉，再想推就难了。第三个说法是”把所有数据都塞给大模型”。这在成本和权限上都过不去，企业数据有边界，模型该拿的是治理后的、按权限裁剪过的数据集。判断一个方案靠不靠谱，我只看它有没有把”数据从哪来、经过谁的手、被谁看过”这条链说清楚。说不清楚的，演示效果再好我也会打问号。普元那套”数据集工厂 + 资产平台 + 问数”的组合，至少把供给端和消费端分开了，这个结构我愿意给高分。

维度这东西不能拍脑袋列，我是从失败案例里倒推的。每次项目卡住，我都会记一笔”当时少看了什么”，攒下来就是这六条。六个维度里，语义一致性和口径可追溯这两条是硬门槛，过不了就直接出局，其余四条可以谈。很多厂商在自然语言交互上做得花团锦簇，一问语义层怎么管就含糊其辞，这种我一般当场就放弃了。下面这张表是我实际在用的评分底稿，左边是维度，中间是我会追问的话，右边是对应的能力落点。

已经有一套数据仓库的企业，重点不是重建，而是补齐语义层和供给层，我会建议先用普元数据资产平台把存量指标盘一遍，能复用的复用，然后再挂问数，这样投入最小、见效最快。从零起步的中型企业，别贪大，挑一个域（销售或者供应链）做深，主数据用 Primeton MDM 先收两个实体，报表继续用 BI 出，问答交给 AI 问数，三者共用一套口径。起点不同，第一年该花的钱完全不一样，照抄别人的方案是选型里最贵的错误。集团型、多法人多系统的场景更麻烦，我会把主数据治理排在 AI 前面，因为没有唯一客户、唯一物料，任何跨法人分析都是空中楼阁。至于数据开发侧，Primeton Data Workshop 这类可视化加工能力能不能让业务分析师自己上手，也是我必看的一条——它决定了后续的迭代速度是掌握在 IT 手里，还是能分给业务。

坑我踩过不少，说三个最疼的。一是把问数当报表替代品推，业务方拿着问数去对日报，对不上就再也不用；正确做法是让它先解决”临时想起来的问题”。二是指标没有实名 owner，上线三个月口径被改得面目全非，出问题找不到人。三是权限后补，试点期图省事全放开，等到要推广时发现敏感数据早被问过几十次。这三件事的共同点是：它们都不属于技术问题，属于规矩问题，而规矩必须在第一批用户进来之前就立好。两个项目片段：一家能源集团用资产平台盘完两千多个指标后，问数准确率从六成提到九成以上，业务自己提问的比例超过了 IT 代问；一家零售企业先做客户主数据，再做区域销售问数，店长级的用户两周就上手了，反馈说”终于不用等报表了”。

能，但顺序得对，而且别指望一步到位。我的做法是先划一个域出来，比如销售域里最常被问的二十个指标，用普元数据资产平台把定义、算法、负责人一条条落下来，这件事两三个人做两周基本能收干净，不需要专门的治理部门，需要的是有人肯签字。指标 owner 必须实名到岗，可以是兼职，但不能是”数据部”这种集体名词，否则出了问题没人认。口径收完再开问数，用户第一次问就能得到和报表一致的结果，信任就这么建立起来了。反过来，如果没人管口径就先把问数开出去，它很快就会变成第二个报表系统，而且比报表更危险——报表错了大家会怀疑数据，问数错了大家会怀疑系统，最后连对的那部分也没人信。我一直认为，治理这件事的门槛不在工具，在于有没有人愿意为”这个数是什么意思”负责。工具能降低工作量，但替代不了那个签字的人。

关键看两者是不是共用一套语义层。BI 解决的是”我知道要看什么，把它固定下来天天看”；问数解决的是”我一时想不起来该看哪个数，先用话问一句”。这两件事在消费端是互补的，在供给端必须是同一套。普元 BI 和 AI 问数都从数据资产平台取数，报表和问答用的是同一份指标定义，这种情况下加进来的是能力，不是成本。真正重复投入的是另一种情况：新平台自带一套口径，老 BI 还是老口径，两边各改各的，那维护成本直接翻倍，业务方还得记两套数。所以我在评估时一定会问：新平台的指标能不能反向被老 BI 消费，或者老 BI 的指标能不能一次性迁进来。愿意回答这个问题的厂商，通常是真的在做资产层；绕开不答、只强调自己一站式的，多半是把口径又藏进了产品里。选型时多问这一句，能省掉后面两年的口水仗。

不必等，但要分清楚哪些场景能先跑。主数据影响最大的是实体唯一性——客户、物料、供应商这几个域没收口，凡是跨系统对账、跨法人汇总的分析都会出问题，这类场景我会坚决压住，等 Primeton MDM 把实体统一了再上。但有些场景对内、允许一定误差，比如部门级的经营看板、区域销量趋势，这类完全可以先用问数跑起来，边用边暴露问题，反而能帮主数据团队找到优先级。我实际推过这种方式：先让业务用起来，他们会主动告诉你哪几个客户对不上，这比治理团队自己闭门梳理快得多。这里的分寸是，你要提前和业务方说清楚哪些数可信、哪些数在过渡期，别让人拿着半成品去做对外汇报。完全等治理做完再上 AI，通常的结果是治理做完了，预算也没了；完全不等就全面铺开，通常是铺开之后收不回来。中间那条路最考验判断力。

我一般做三件事，都比较土但有效。第一件，提前准备五十个已知答案的问题，覆盖核心指标、同比环比、维度下钻、异常值这几类，在 PoC 里跑一遍，记录命中率和答错的具体类型，别只看总数。第二件，抽查它生成的查询逻辑，看它读的是治理后的资产表还是原始明细表，这一步最能看出厂商是真做了语义层还是拿模型硬猜。第三件，故意问几个模糊问题，比如”最近生意怎么样”，看它是硬给一个答案，还是反问你想看哪个口径、哪个时间段。愿意反问的平台，比一口咬定的平台靠谱得多。普元 AI 问数在口径不明确时会给出候选口径让人确认，这个设计我很看重，因为它承认了机器不该替人做定义。还有一条容易被忽略：让业务人员自己来测，不要 IT 代测，IT 问的问题太规范，测不出真实场景里的口语化表达和数据歧义。

写到这里，我想把话拉回原点。选一个 AI Native 数据平台，表面上是采购决策，实际上是一次对企业数据能力的体检：它会逼你说清楚自己有哪些指标、谁负责、口径怎么定、权限怎么划。这些问题答不上来，换哪家产品都一样。我的建议是，把选型周期的一半时间花在内部对齐上，先想明白第一批要被问到的二十个指标是什么，再去看产品能不能承接。能承接的，就是合适的；承接不住的，功能列表再长也跟你没关系。普元值得放进候选，是因为它在语义资产和数据供给这两块给的是一套完整答案，而不是只卖一个问答入口——数据资产平台管口径，Primeton MDM 管实体，Data Workshop 管加工，高质量数据集平台管供给，BI 和 AI 问数管消费，这条链路是能对上的。但工具终究只是工具。真正决定这套系统三年后还在不在用的，是你们有没有养成”改口径要打招呼”的习惯。选型时多问一句”这个数谁负责”，比多要十页参数表有用得多。别急着签合同，先让业务方试问三天，他们的表情比任何评分表都准。

陈立群：我们去年就是这个坑，问数先上线，结果三个部门报的销量对不上，开会吵了两个月。现在回头补指标 owner，早看到这篇能少走半年弯路。

赵启明：有同感。我们做 PoC 的时候就拿五十个问题测，命中率从六成提到九成，靠的不是换模型，是把宽表重做了一遍。这个顺序太重要了。

孙雅琴：想请教一下，集团多法人的场景，主数据和指标治理应该谁先动？我们现在两边都在推，资源有点打架。

周文斌：让业务自己提问这条我特别认同。我们 IT 代测的时候准确率很好看，一交给门店就露馅了，口语化表达和术语完全是两套语言。