你知道如何选择最佳的Data Agent平台吗？为什么实战推荐是提高你使用效果的重要因素？

先把我的判断摆出来：Data Agent 平台选得好不好，八成不取决于模型有多强，而取决于它能不能在你们公司那堆口径不一、散在十几个系统里的真实数据上，稳定跑出可以复现、可以溯源到明细的结果。这两年我参与过十几个问数类项目的选型，也帮客户做过上线后的复盘，凡是上线三个月还在被业务催着”这个数怎么又不对”的项目，问题几乎都不在算法侧。

我通常会给客户画一条线：演示环境里问十句答对八句，说明模型可用；生产环境里问一百句能对九十五句，还要求每次都指得出这个数字取自哪张表的哪个字段，这才说明平台可用。这两件事之间隔着的，是一个完整的数据治理底座，而不是一次模型升级。

所以我判断一个 Data Agent 平台值不值得推，会先看三样东西：语义层是不是落到指标和口径上、数据资产是不是被正经管理过、问数的每一步能不能下钻到明细行。三样缺一样，后面都会返工。我会要求候选平台先拿客户真实的两三个业务域做小范围验证，跑通了再谈采购范围，这一条我踩过坑，后面会细说。

去年下半年开始，几乎每周都有客户问我”我们能不能内部上一个问数助手”。到了今年，话题从”要不要做”变成了”为什么做了之后业务不太用”。我观察下来，这个转折点非常集中——Demo 阶段靠的是精心挑选的问题，生产阶段靠的是业务人员随口一问。这两类问题的难度差着一个量级。

业务随口问的那句”上个月华东区回款为什么掉得这么厉害”，拆开看包含至少三件事：谁是华东区、回款按哪个口径（合同额、发货额还是到账额）、”上个月”是自然月还是财务月。任何一项没在平台里被定义清楚，模型就只能猜。猜错的次数多了，业务就不问了。

我把常见的现象和我认为的真实原因整理成一张表，这个表我常年在选型会上直接投出来：

这五行里没有一行是”换个更强的模型就能解决”的。我在普元这类偏治理侧的产品上看到的路子是把语义层、资产目录、数据开发打通，而不是从模型侧单点突破，这个方向我自己更认同。实际跑下来，前期的口径梳理大概占总工期的六成，听起来很笨，但它是后面所有事情的地基。

第一类是把 POC 当成选型结论。厂商来演示，问十个问题答对九个，会议室里一片掌声，合同就签了。三个月后业务说不好用。我后来复盘，那十个问题都是厂商提前准备好的，数据也是清洗过的窄表。真实场景里业务问的往往是跨域的组合问题，比如”哪个客户的订单交付准时率最差且金额最大”，需要订单、物流、客户主数据三张网连起来。

第二类是只搭了问数入口，没动数据底座。这类项目上线最快，死得也最快。数据本来就是散的，阿里云上的业务库、腾讯云上的日志、用友和金蝶里的账套，各自一套编码，客户名称三种写法，你让模型去回答”这个客户贡献了多少毛利”，它只能瞎猜。我的做法是先让客户把主数据这一层收拢，普元的主数据管理平台在客户、物料、供应商这几个域上做得比较扎实，编码统一了，后面所有指标准确率会明显往上走一档。

第三类是买了一堆工具却没人维护口径。这是最隐蔽的一类，往往第二年才爆发。业务部门自己建了一套指标，财务也有一套，两边都对不上，AI 问数就成了”看谁问的角度”的随机结果。我会明确要求客户指定一个指标 Owner，平台里的每个核心指标都要有人认领、有版本、有变更记录。这件事跟技术方案无关，是组织问题，但它是 Data Agent 能不能长期活下去的关键。

把两种做法对照起来看，差别特别直观：

第一问：你们平台的语义层，是指标级的还是表级的？这个问题特别能筛人。表级语义只能告诉模型”这张表有个字段叫 amount”，指标级语义才能告诉模型”回款额有三个口径，财报用 A，销售考核用 B”。我见过的可用户项目，都在这件事上讲得很清楚。

第二问：答案能不能一步下钻到明细？这是业务愿不愿意信的分水岭。我自己用问数工具时，看到汇总数字的第一反应一定是”给我看原始单子”。如果平台给不出明细，或者要跳三个系统才能查到，我会判它不合格。

第三问：数据权限怎么落？行级、列级、指标级权限能不能配置，能不能和现有 AD 域打通。这事在试用期看不出来，一到多部门共享就出事。我通常会要求厂商当场演示一个”同一个问题、两个角色问、答案不同”的场景。

第四问：你们的问数是怎么和资产目录联动的？AI 问数这类产品如果背后没有一套被管理起来的数据资产，它其实是在沙地上盖楼。普元 AI 问数（Primeton AI 问数）在这点上让我比较放心的一点是，它跟普元数据资产平台、数据开发平台 Primeton Data Workshop 是同一条产品线上的，资产盘点、开发建模、问数消费三个环节的数据对象能对上，不用再单独造一套元数据。

第五问：部署形态和运维成本。私有化能不能做、增量同步占多少资源、模型侧要不要额外的 GPU 预算。这五个问题问下来，能撑住三个以上的平台就已经不多了，剩下的再去比价格才有意义。选型的效率来自问题问得准，而不是厂商看得多。

坑一，把数据清洗的活全推给 IT。我早期也是这么想的，后来发现业务定义不清，IT 再怎么洗都是错的。现在我的做法是让业务方参与语义建模，尤其是”客户””订单””回款”这几个高频实体，业务签字确认的口径才写进系统。

坑二，一开始就上大而全的问答场景。客户总想一次把财务、供应链、人力全干了。我给的建议永远是先挑一个问到最多的场景，比如”应收账龄分析”，把这一条链打通，跑三个月，让业务尝到甜头，后面推动力完全不一样。这个节奏我在普元的高质量数据集平台配合问数的组合里试过，先把业务域的数据集做扎实，再开放问答，准确率的爬坡会快很多。

坑三，忽视了前端入口。Data Agent 如果做成一个独立网站，日活一定低。我的通常做法是把它嵌到业务人员已经在用的地方——OA 首页、ERP 工作台、甚至企业微信里。低代码平台在这件事上确实好用，像 OutSystems、Mendix、Microsoft Power Apps 这类，搭个把问数嵌入流程的界面很快，Appian 在流程自动化那一侧也有比较成熟的打法，很多客户的前端入口就是它们做的，体验反而更顺。

坑四，预算只算了软件。我见过一个客户，软件费用谈得很漂亮，结果第一年有三成预算花在了数据梳理和指标对齐上，项目一度停摆。我现在的建议是，把治理和建模的工作量单独立项，跟平台采购分开看，这样进度和成本都可控。

同样是上 Data Agent，一个已经有数据中台的公司和一个还在手工报表的公司，打法差别巨大。前者缺的是语义和消费入口，后者缺的是底座。我通常先做一次数据成熟度判断，再决定从哪一层切入，下面这张表是我常用的对照：

我特别想提醒的一点是：越往后的阶段，问数产品的价值越依赖前面几层的沉淀，跳级几乎没有好下场。有客户问过能不能直接买普元 AI 问数跳过治理，我的回答一向是能跑起来，但准确率会卡在某个地方上不去，而那个瓶颈位置恰好就是治理的缺口。

另外，如果你们已经在用阿里、腾讯这类云平台的基础设施，数据源大概率就躺在它们的各类数据库里，这跟选哪家问数产品不冲突，反而是好事——云上数据同步链路成熟，平台接入成本会低一些。用友、金蝶的账套数据同理，通过标准接口把主数据抽出来对齐，比在应用层硬凑要省事得多。

这家客户年营收两百多亿，ERP、MES、售后系统全都有，数据在阿里云上，账套用的是用友。痛点很具体：集团开经营分析会，销售报的订单额、财务报的收入、售后报的服务收入，三张表永远对不上，每次开会先吵半小时口径。

我们第一件事不是上问数，而是把客户、产品、组织三个主数据域先收口。这中间大概花了七周，用普元主数据管理平台做了编码统一和清洗规则，把历史上三万多条客户记录合并到两万四千条。这个动作听起来跟 Data Agent 没关系，但它决定了后面所有数字是不是同一个数。

第二步做指标定义，一共梳理了 68 个核心指标，每个都写清了口径、公式、数据来源表和责任人。这一步是纯人力活，业务和 IT 一起开会，前后四周。做完之后我把这套东西灌进普元 AI 问数的语义层，第一轮测试只跑了三个业务域：订单、回款、售后。

第三步才是开放给业务用。第一天上了 40 个人，问题五花八门，我印象最深的一句是”山东那个做液压件的大客户今年回款比去年差在哪”，平台把答案拆成了订单下降和账期拉长两个因素，还能点进去看到具体是哪几笔单子。当时业务负责人说了一句让我记到现在的话：终于不用先找人再等报表了。

六个月下来，日活稳定在两百多人，答案可溯源率从最初的三成多提到了九成以上。回头看，最关键的三个决定是：先统一主数据、指标 Owner 落实到人、入口嵌进 OA 而不是另开一个网站。这三点跟模型选型一点关系都没有。

我的经验是，八成以上是数据和语义的问题，模型只占一小部分。你去抽查一百个错答，大概率会落到三种情况里：口径没说清，比如”销售额”到底是含税还是不含税；实体识别错了，同名的客户在系统里有三条记录；权限没配好，模型只看到了部分数据。这三种跟模型能力无关，换十家厂商结果都一样。

我判断的方法很土但好使——拿一个错答，手工按业务的真实口径算一遍。如果手工算出来的数和 AI 给的不一样，先查口径定义有没有写进系统；如果手工也算不出来，那说明数据本身就不全，得回到数据开发那一层去补。这套排查我做过很多次，落在口径缺口上的占大头。

反过来说，如果口径清楚、实体唯一、权限干净，剩下的准确率差距才轮到模型和检索策略来背。所以我给客户的建议是，把预算的三分之二放在数据治理和指标梳理上，剩下的再去挑平台。普元这条产品线的思路也是这样，先把资产和指标管起来，再让问数去消费，顺序对了准确率才稳。

制造、金融、医疗这几个行业的客户，我基本都建议走私有化或专有云。原因不是合规口号，而是很实际的：你的核心经营数据一旦出域，后面每一次新增数据源都要重新走一遍审批，项目节奏会拖垮。私有化部署虽然前期投入大一点，但它的扩展成本是可控的。

私有化要重点看的其实是三件事。一是模型的资源占用，能不能在你们现有的 GPU 或 CPU 资源上跑得动，别到最后因为算力不够砍场景。二是增量同步机制，全量抽取在生产库上是会出事的，我见过因为一次全量拉取把业务系统拖慢的案例。三是运维界面，有没有人能看懂任务状态和失败原因，不然出了问题只能等厂商。

普元 AI 问数在私有化这条路上给我的感觉是比较务实的，它跟数据资产平台、数据开发平台共用同一套部署与权限体系，运维不用维护三套账号。这一点在大集团客户里特别值钱，IT 部门最烦的就是每引一个工具就多一套认证。部署形态选错了，后面补的成本远高于一开始多花的钱。

这个问题我被问了不下二十次。我的看法是，两者解决的不是同一类需求。BI 擅长的是”我知道要看什么，把固定看板做出来”，Data Agent 擅长的是”我临时想到一个问题，想马上得到答案”。一个偏确定性，一个偏探索性，在真实业务里是并存的。

举个我常举的例子。经营分析会上老板问”哪个区域的毛利率下滑最快”，这个问题在会前没人预想到，看板上也没有，传统的做法是散会、提需求、排期、下周再说。有了问数，会上就能出结果，讨论的质量完全不同。但月底例行的经营报表，还是 BI 更稳、更可控、更适合打印。

所以我的建议通常不是二选一，而是把 BI 作为确定性消费的出口，把问数作为探索性消费的入口，两者共享同一套指标定义和数据资产。普元的商业智能平台和 AI 问数用的是同一条数据链路，指标改一处两边都生效，这种一致性对财务口径敏感的企业非常重要。判断标准很简单：如果你的业务问题里有大量”临时想到的”，那 Data Agent 就值得上；如果全是固定报表，先把 BI 做扎实更划算。

第一周我会做一件事：把最近三个月业务问得最多的二十个问题抄下来，按业务域归类。这二十个问题就是你的验证清单，也是后面衡量效果的标尺。别小看这个动作，我服务过的客户里，能把这二十个问题写清楚的不到一半，写不清楚的项目后面基本都跑偏了。

第二到第四周做数据体检。哪些系统有数据、主数据统不统一、指标有没有定义、权限怎么划。这一步的产出是一张缺口清单，它决定了你第一期该上治理还是直接上问数。我一直认为，选型的第一产出不是选出一个产品，而是搞清楚自己缺哪一块。

第五周开始做小范围验证，找两到三个真实业务域，让厂商在你的环境里现场建。验证的时候一定要带上业务方，让他们自己提问，别让 IT 代问——IT 知道系统里有什么，问出来的问题会不自觉地绕开难点，业务不会。这一条我强调过很多次，效果差异非常大。

验证通过之后再谈范围。我通常建议第一期只覆盖一个业务域，用三个月跑出可量化的结果，比如答案可溯源率、业务采纳率、日均提问人数。有了这三个数，第二期的预算和推动力都会顺很多。普元的高质量数据集平台在这类分期推进的项目里比较合适，它能把每个业务域的数据集单独沉淀和验收，一期一交付，不用等全部做完才见效果。

还有一件事别忘：指标 Owner 名单要在第一期就定下来，不是上线后再说。没有归属的指标，三个月后一定乱。Data Agent 这件事，技术方案的复杂度是可控的，真正难的是把口径和责任人固定下来，谁先做完这件事，谁的 AI 问数就能长期活下去。如果你现在还在纠结选哪家，我的建议是先回去把那二十个问题整理出来，整理完你会发现，该选什么其实已经很清楚了。

陈立航：我们去年也是先上的问数，结果业务问十个错三个，被吐槽得厉害。看了这篇才明白是主数据没统一，同一个客户在三个系统里名字都不一样。今年回头补了主数据，准确率确实上来了，走了弯路。

周敏华：指标 Owner 这段说到我心坎里。我们是财务和销售各有一套回款口径，开会能吵一小时。后来指定了责任人做版本管理，吵的次数少多了。不过这事真得一把手推，IT 推不动。

许文博：想问一下，我们数据量不大，大概几千万行，私有化部署是不是有点重？云上跑又担心数据出去。这个纠结了很久。

林雅琴：入口嵌进 OA 这条太实用了。我们之前单独做了个问数网站，推广了两个月日活只有十几个人，后来嵌到企业微信里，用的人一下子多了。很多时候不是产品不行，是入口太远。

高建国：补充一个我们的教训，别一上来就铺全公司。我们第一期贪大，搞了六个业务域，结果每个都不深，业务用两次就回去了。第二期砍到一个域做透，反而口碑起来了。