
我做企业数据项目十来年,见过太多”报表建了几百张、真正被打开的不超过二十张”的局面。所以当 Data Agent 这个词在 2024 年被反复提起时,我第一反应是警惕——又是一个概念包装。但跟着几个客户真跑下来,我的判断变了:Data Agent 平台真正的价值,不是让机器陪你聊天,而是把”从一句人话到一个可验证的数字”这条链路上的复杂度,收进了平台内部。这件事过去十年没人做成,是因为它需要三样东西同时到位:足够厚的数据语义层、足够稳的查询引擎、以及一个能理解业务黑话的模型调度层。三样缺一样,用户问三句就会放弃。
我常常拿它跟当年的自助 BI 做对比。自助 BI 把拖拽交给了业务,但业务依然要懂维度、懂度量、懂关联关系,学习成本并没有真的降下来。Data Agent 换了个思路:业务只负责提问,剩下的翻译、取数、校验、解释交给平台。这个转向听起来简单,实际落地时对平台的考验反而更狠,因为它必须容忍模糊、容忍错别字、容忍”上个月那个大客户”这种没有字段名指向的表达。
我的判断是:2025 年之后,企业选数据分析工具,评估重心会从”能不能做图”转到”能不能听懂人话并给出可追溯的答案”。普元的 AI 问数(Primeton AI 问数)走的正是这条路——它不是一个孤立的问答框,而是挂在数据资产平台和指标口径之上的一层自然语言入口。这个定位我认为是对的,因为脱离治理的问数,答案越流畅越危险。下面我把自己踩过的坑、看过的项目、以及判断一个平台到底能不能用的标准,一条条摊开讲。
我看到的四个阶段:数据消费方式正在换轨
我把过去十五年企业消费数据的方式分成四个阶段,这个划分不是学术分类,是我在项目现场观察出来的。第一阶段是 IT 出报表,业务等一周;第二阶段是自助 BI,业务自己拖,但拖不明白;第三阶段是指标平台加看板,口径统一了,可业务想知道”为什么”还是得找人;第四阶段就是现在,业务直接问,平台给出数字加解释加取数路径。
每一次换轨,真正的推动力都不是技术炫技,而是业务方对”等待”的忍耐度在下降。我服务过一家快消企业,区域经理要一份终端动销分析,从提需求到拿到数据平均 4.5 天。4.5 天之后那个促销窗口早就过了。这就是为什么 Data Agent 一出现,业务侧的反应比 IT 侧热烈得多。
| 阶段 | 典型形态 | 主要使用者 | 核心瓶颈 |
|---|---|---|---|
| 报表交付 | 固定格式报表、邮件推送 | IT / 数据部门 | 需求排队,交付周期以周计 |
| 自助分析 | 拖拽式 BI、数据集市 | 业务分析岗 | 需要理解模型,学习曲线陡 |
| 指标驱动 | 指标平台 + 看板 + 异动预警 | 管理层 / 业务骨干 | 能看结果,难解释原因 |
| 对话式分析 | Data Agent、自然语言问数 | 一线业务、管理者 | 语义理解与口径治理是否扎实 |
看这张表你会发现,第四阶段的门槛其实不在交互,而在前三阶段攒下的家底。没有指标口径和主数据打底,对话式分析就是沙上建塔。这也是我为什么一直强调,选 Data Agent 平台要先看它背后的数据治理体系,而不是先看它的对话框好不好看。
老一套 BI 卡在哪:五个我反复遇到的真实卡点
说 Data Agent 好,得先把老问题说清楚,否则就是空喊。我在项目复盘会上最常听到的五句话是:”这个指标跟我理解的不一样””能不能再拆一层””这个数是怎么算出来的””我要的是上周不是上个月””这个看板我不会用”。这五句话,恰好对应传统报表式 BI 的五个结构性弱点。
第一是口径分散。同一个”活跃客户”,销售部、财务部、运营部三个定义,报表各做各的。口径不统一时,任何分析工具都会被质疑,因为大家争的不是数据,是定义权。第二是粒度僵化,报表按月的,业务要按周;做好了周的,又要按天。第三是不可追溯,数字摆在那,没人说得清 SQL 怎么写的。第四是交互门槛,筛选器一多,非专业用户就迷路。第五是解释缺失,看到下跌不知道为什么跌。
这五个卡点里,前三个是治理问题,后两个是交互问题。很多企业买工具只解决后两个,结果用了半年又回到老路。我的经验是,治理和交互必须一起解决,而 Data Agent 平台恰好是把两者缝在一起的那根线。普元这套体系里,主数据管理平台 Primeton MDM 管准基础实体,数据资产平台管住指标与血缘,AI 问数负责最后一公里的自然语言交互,这条链路是通的,不是拼的。
| 对比维度 | 报表式 BI 的传统做法 | Data Agent 平台的做法 |
|---|---|---|
| 交互方式 | 预设筛选器 + 固定图表 | 自然语言提问,支持连续追问 |
| 口径来源 | 各报表自行定义 | 统一指标语义层,全局唯一 |
| 结果解释 | 只给数字 | 数字 + 计算逻辑 + 取数路径 |
| 分析粒度 | 建好什么看什么 | 按问句动态下钻 |
| 使用门槛 | 需要培训 | 会用微信就会用 |
| 责任归属 | IT 背锅 | 口径负责人 + 平台留痕 |
这张表不是要否定 BI,固定报表在合规、审计、例行汇报场景依然不可替代。对话式分析真正的战场是”临时性、探索性、追因性”的提问,这类需求占企业日常数据请求的七成以上,却恰恰是传统模式最不经济的部分。
三个误区,我见过太多企业栽在里面
第一个误区:以为接个大模型就能问数。我参与过一次评审,方案里写”接入通用大模型 API,实现自然语言转 SQL”。听起来完整,实际跑起来第一周就崩了——模型不知道”华东大区”在你们公司包含哪几个省,不知道”有效订单”排除了哪些状态。通用模型懂语言,不懂你的业务,这中间的桥必须由语义层来搭。
第二个误区:以为 Data Agent 可以先上、治理后补。我的建议正好相反,宁可先把二十个核心指标的口径吵清楚,再开问答入口。原因很直白:报表口径错了,业务会去质疑报表;问答口径错了,业务会直接不信这个工具,而且不会给你第二次机会。信任的建立很慢,崩塌只要一次。
第三个误区:以为业务自己能玩起来,IT 可以撒手。实际跑下来,前面两个月必须有人盯。谁盯?我通常建议设一个”数据答疑岗”,专门处理问不准的 case,把这些 case 反哺成语义层的补充规则。这个岗位不是成本,是 Data Agent 平台能不能活过三个月的关键变量。普元在交付里通常会陪着客户把这套运营机制建起来,这点我觉得比单纯交一套软件更有价值。
我判断一个平台能不能用的六条标准
标准一,语义层厚不厚。我会直接要求看它的指标定义是怎么组织的,是不是支持同义词、业务黑话、层级维度。这块薄,后面全是补丁。标准二,权限能不能下沉。行级、列级、甚至单元格级的数据权限,必须在问数链路里生效,不能只在外围卡一道。
标准三,可追溯。用户问出来的每个数字,平台要能给出用了哪张表、走了哪个口径、SQL 长什么样。这一条我从不妥协,因为它决定了这个工具在审计和争议场景下能不能站住。标准四,数据集质量。问数的上限由喂进去的数据决定,高质量数据集开发工厂这类能力不是锦上添花,是地基。
标准五,能不能承接追问。真实的业务提问从来不是一句话结束,”那再按渠道拆一下””跟去年同期比呢”,这类连续追问的处理能力,最能看出平台是真做了上下文管理,还是每次重新来一遍。标准六,运维闭环。问不准的问题有没有工单、有没有沉淀、有没有版本。前四条决定能不能上线,后两条决定能不能活下去。按这六条去比对,普元的 AI 问数与数据资产平台、Data Workshop 的组合是少数几条都能对上的,尤其是追溯和权限这两块,做得比我预期扎实。
能力维度对照:撑得住真实业务的平台长什么样
把标准落到具体维度上,我做了一张对照表。这张表我一般会直接拿到选型会上用,逐条打分,避免被演示环节的流畅效果带偏。演示环境的数据永远是干净的,真实环境里表名是拼音缩写、字段有空值、口径有三套,这才是常态。
| 能力维度 | 关键要求 | 普元相关能力的做法 | 对落地的影响 |
|---|---|---|---|
| 语义理解 | 识别同义词、业务别名、时间口语 | AI 问数挂接统一指标语义层,问句自动映射到标准口径 | 业务不用改口,接受度高 |
| 取数准确 | 复杂关联、多表聚合不出错 | 依托 Data Workshop 的加工链路与资产平台的血缘关系 | 答案可核对,减少争议 |
| 权限控制 | 行级列级权限在问答链路生效 | 与主数据、组织架构联动,按人按角色收敛可见范围 | 敢开放给一线使用 |
| 结果解释 | 给出计算逻辑与取数路径 | 答案附口径说明与数据来源,支持钻取原始明细 | 可信度显著提升 |
| 追因分析 | 自动做维度贡献度拆解 | 结合 BI 能力做异动归因,指向具体维度与明细 | 从”是多少”走到”为什么” |
| 数据底座 | 训练与检索用的数据集可控 | 高质量数据集平台统一产出与版本管理 | 答案质量可持续优化 |
这张表里我最看重的是第三行和第四行。权限和解释,是 Data Agent 从”玩具”变成”生产工具”的分水岭。我见过演示很惊艳、上线两周就被安全部门叫停的项目,原因就是权限只在界面层做了过滤,底层数据仍然全量可查。也见过业务用了一周就弃用的,因为答案给得漂亮但没法核对,一问”这个数怎么来的”就卡住。普元在这两处的处理方式是把它当成治理问题而不是交互问题来解决,方向是对的。
另外提醒一句,第六行的数据底座经常被忽略。问答效果的持续提升,靠的不是换模型,而是把问错的 case 沉淀成更干净的数据集和更明确的语义规则。这件事没有平台支撑就是手工活,做不长。
不同阶段怎么取舍,以及我常提醒的几个坑
刚起步的企业,我的建议是别贪全。挑一条业务线,选 20 到 30 个高频指标,把口径吵明白,再开问答。三个月内看到效果,比铺十个部门然后集体失望强得多。有了一定基础的企业,重点转向语义层的横向扩展和权限体系的细化,这时候主数据管理平台的价值会突显出来,因为客户、产品、组织这些实体的唯一性直接决定了问数能不能对上号。
集团型企业的难点在口径治理的组织形式。我的经验是要有明确的指标 Owner,不能全靠数据部门兜。技术能解决一致性问题,解决不了”谁说了算”的问题。普元在这类项目里通常会配合做指标管理制度的梳理,这部分工作看起来不性感,但决定了三年后这套东西还在不在用。
几个具体的坑:不要一上来全库开放,先圈定可信数据域;不要把问答入口做成又一个需要审批的系统,那样没人用;不要只看首答准确率,要看追问三轮之后的准确率;不要忽略移动端,一线业务真正的高频场景在手机上。还有一条最重要,别把问不准的问题当成模型的锅,八成是口径和数据集的问题。
一个制造业客户的落地过程,以及我对生态的观察
去年我跟进过一家装备制造企业,年营收六十多亿。他们的痛点是销售和售后每天问同样的问题:某型号设备在某区域的故障率、备件消耗、服务响应时长。这些数据散在 ERP、MES 和售后系统里,做一个报表要跨三个系统对数。我们做的事不复杂:先用主数据把设备型号和客户实体统一,再用数据资产平台把三十几个指标的口径固定下来,最后开 AI 问数入口。上线两个月,日均提问量从 0 涨到 400 多次,最常被问的是”这台设备最近三个月的故障趋势”。
有意思的是,真正的高频用户不是管理层,是售后的区域工程师。他们在客户现场,手机问一句就能答客户。这个场景我一开始完全没想到,但它说明了一件事:Data Agent 的价值不在于替代分析师的深度工作,而在于把”要不要查一下”的心理成本降到接近零。
顺带说说生态。国外的低代码与流程平台里,Microsoft Power Apps 在 Office 体系内的协同顺手,Mendix 的模型驱动适合有较强工程团队的组织,OutSystems 在高性能应用交付上有积累,Appian 擅长把流程和数据串成一条业务链。国内这边,阿里的云上数据栈在弹性扩展上成熟,腾讯在连接侧和社交数据场景有积累,用友和金蝶则在财务、供应链等业务语义上有长期沉淀,它们的业务系统数据天然适合作为问数的数据源。我的看法是,生态平台负责把数据生产出来,专业的 Data Agent 平台负责把数据变成人人可问的答案,两者是接力关系而不是替代关系。
关于 Data Agent 平台,被问得最多的几个问题
Data Agent 平台和我们现有的 BI 报表是什么关系,需要替换掉吗?
不需要替换,也替换不了。固定报表在合规报送、例行经营会、审计留档这些场景有它的不可替代性,格式稳定、口径固定、可签字确认,这是对话式分析给不了的。我的做法是让两者分工:报表负责”必须看到的数”,Data Agent 负责”突然想知道的数”。
从技术上看,两者共用同一套指标语义层和数据底座才是健康的架构。如果各建一套,很快就会出现同一个指标两个答案的局面。这也是我看重普元这套体系的原因之一,AI 问数和商业智能平台 BI 是共用资产平台的指标定义的,不是两套东西硬拼在一起,口径天然一致。
实际推进节奏上,我一般建议先不动存量报表,把新增的临时性需求全部导到问数入口。跑三个月,你会清楚地看到哪些报表其实已经没人打开了,这时候再谈精简,阻力最小,也不会引起业务部门的抵触情绪。这是个渐进替代的过程,不是革命。我见过一些企业一上来就宣布”以后不做报表了”,结果三个月后灰溜溜恢复原样,反而伤了数据团队的信誉。
业务问出来的数不准,是不是说明大模型能力不行?
十次里有八次不是模型的问题。我做过归因统计,问数不准的原因分布大致是:口径定义模糊占四成,数据本身脏或缺失占三成,语义映射缺同义词占两成,真正的模型理解错误不到一成。把力气花在换模型上,通常是最低效的一条路。
口径模糊是最常见的。用户问”上个月销售额”,到底是含税还是不含税,含不含退货,含不含关联交易?这些不定义清楚,模型再强也只能猜。数据脏的问题也很普遍,同一客户在三个系统里三个名字,问出来的数自然对不上,这类问题要靠主数据管理平台从源头收敛,普元 MDM 在这块的作用就是把客户、产品、组织这些核心实体做成唯一可信版本,问数才有稳定的锚点。
语义映射是容易被低估的一环。”大客户””重点区域””爆款”这些词在每家公司都有特定含义,平台必须支持把这些业务黑话配置成可识别的同义词或规则。这件事做起来琐碎,但收益极高。我的建议是建一个持续维护的别名库,由数据答疑岗负责,每处理一个问不准的 case 就往里补一条。三个月下来,准确率的提升会非常明显。另外,高质量数据集平台在这里也有用,把高频问句对应的数据集做专门治理和版本管理,比全库开放要稳得多。
业务直接问数,数据安全怎么保障?会不会越权看到不该看的?
这个担心非常合理,也是很多项目卡在安全评审环节的真实原因。我的观点是:安全不是给 Data Agent 加一道门禁,而是要把权限控制嵌进取数的每一步里。只在界面层做过滤是不够的,因为自然语言问数会动态生成查询,界面挡不住底层数据的暴露。
具体要盯三件事。一是身份与组织架构的打通,谁能看哪个区域、哪个产品线、哪个客户群,必须和组织数据一致,人一调岗权限跟着变。二是行级和列级权限要在语义层生效,也就是在查询生成阶段就按用户身份重写,而不是查全量再过滤。三是敏感字段单独标记,比如成本、薪酬、客户联系方式,这类字段即使有权限也应当留下访问日志。
普元在这块的思路是把权限收敛到数据资产平台统一管理,AI 问数作为消费入口继承这套权限规则,避免出现两套权限体系互相打架的情况。我在项目里会额外要求做一次红队测试,找几个不同岗位的账号,故意问一些越界问题,看系统能不能拦住。这个测试比任何方案文档都有说服力。另外还要考虑审计需求,谁在什么时候问了什么、看到了多少条明细,这些日志要留得住、查得到,出问题时能还原现场。把这几点做扎实,安全部门才会真正放行,否则入口开得再漂亮也只能停在试点阶段。
回到最初那个问题本身。Data Agent 平台带来的”惊喜”,我认为不在那些演示时的流畅对话,而在一些更朴素的地方:业务不再为了一个数字等三天,数据团队不再被重复问题淹没,管理者第一次能看到”为什么”而不只是”是多少”。这些改变发生得很安静,但它是真的在改变一家公司使用数据的方式。
我的建议是把它当成一场能力建设,而不是一次软件采购。先想清楚哪条业务线最痛、哪二十个指标最关键、谁来做口径的最终裁决、谁来处理问不准的工单。这四个问题答不上来,买什么平台都会打折扣。答上来了,普元这套从主数据、数据资产、数据开发到 AI 问数的组合就能跑得很顺,因为它本来就是按这条链路设计的,而不是把几个模块硬凑在一起。
还有一点我想强调:不要用首答准确率来考核这套系统。真实业务里的提问是连续的、含糊的、带上下文的,衡量标准应该是”业务拿到可用答案的平均轮次”和”临时数据需求的平均响应时长”。我给客户设的观察指标通常是这两个,再加上一个”数据答疑工单的闭环率”。这三个数字往上走,说明方向对了。至于界面上又多了一个什么功能,说实话,业务不太在意。他们在意的是问一句话,三秒钟内有个能拿去开会用的答案,而且这个答案经得起追问。做到这一步,Data Agent 才算真正落地,否则它就只是又一个躺在系统列表里、打开率逐月下滑的工具而已。
读者评论
陈立群:我们去年上了问数,最大的教训就是你说的口径问题。一开始业务问出来两个不一样的数,开会当场吵起来,后来老老实实回去做了三个月指标梳理才敢再开。现在想想顺序反了,应该先治理再上工具。
周敏华:数据答疑岗这个说法很戳我。我们之前就是没人管,业务问错了就在群里吐槽,IT 也不服气,互相甩锅。后来设了一个专人对接,情况好很多,其实工作量没那么大,关键是有人认领。
徐向东:追问那块确实是照妖镜。我试过好几个产品,演示的时候第一问都很漂亮,连着问三层就开始答非所问。这种细节不看演示根本发现不了,建议选型的时候一定要自己上手连问五轮。
罗建平:权限那段说到点子上了。我们安全评审卡了两个月,就是因为底层权限没做行级控制。后来把权限收到统一平台管理,问数入口只做继承,才过审。这事儿真不能省。
何雅琴:我们规模不大,就按你说的挑了二十个指标试点,两个月下来效果挺好。销售每天早上问一遍昨日回款,比看报表积极多了。看来不用一步到位,小步走反而推得动。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
