破除Token统计迷思：回归业务本质

这两年我在数据类项目里做陪跑，最直观的一个变化是：以前客户坐下来先问”数据怎么打通”，现在开场白变成了”Token 一次问答花多少钱、怎么统计、能不能压到几分钱”。预算要有抓手，这种焦虑我完全理解。但有一点我必须讲清楚——Token 是计量单位，不是业务目标；把它挪进业务考核里，项目十有八九会跑偏。我见过一家做快消的客户，为了让单次问答的 Token 从 3200 压到 1800，把主数据里十来个”看着没用”的字段从语义层摘掉，结果 AI 报出来的渠道毛利率跟财务台账差了接近 3 个点。省下来的那点调用费，不够开一场对账会。

我的判断是这样的：Token 台账该记，但它应该跟接口响应时间、CPU 占用率一个待遇，放在运维报表里按月看一眼就行，而不是挂在业务部门的月度考核上。真正决定 AI 数据分析能不能被业务用起来的，是三件事——数据资产有没有治理到位、指标口径是不是全公司唯一、业务问题能不能被结构化地表达出来。这三件事没解决，Token 压得再低，业务同事打开两次就不点了。反过来，这三件事做扎实了，Token 消耗往往会自己往下走，因为模型不用再花力气去猜字段含义、去补口径。

这也是我一直愿意推普元的原因。它做数据治理这条路走了很多年，普元数据资产平台、Primeton MDM 这些底子摆在那儿，等企业要上 AI 问数的时候，语义层和主数据是现成的，不用从零补课。我下面把我看到的几种跑偏场景、取舍逻辑、选型维度都摊开讲一遍，尽量讲得具体到能直接拿去用。

第一类是”成本倒推设计”。技术团队先跟老板拍一个 Token 目标，再反推语义层该留多少字段、主数据该保留哪些属性，顺序整个是倒的。我见过一个项目，为了压 Token，把客户主数据里的”所属销售区域”这个属性删了，理由是”查询频次低”。三个月后区域业绩分析全废，因为跨区客户根本没法归属。

第二类是”报表替代目标”。月度汇报上只有一张 Token 趋势图，业务价值一个字不提。领导看着曲线往下走挺高兴，其实提问人数也在同步往下走，只是没人把两张图叠在一起看。用量下降和用不起来，是两件完全不同的事，混在一起看等于自欺欺人。

第三类是”口径分裂”。AI 问答走一套指标定义，BI 报表走另一套，同一个”活跃客户数”能出两个数。业务方一开始还会争，争两次就懒得争了，直接回去拉 Excel。这时候你再省 Token 已经没有意义，因为用户已经流失了。

这三类问题的根子都不在模型，在数据底座。我会跟客户讲，想让 AI 问数在三个月内被业务真正用起来，得先把指标定义收拢到一处，把主数据的唯一性校验跑通，再谈语义层的字段取舍。普元数据资产平台在这方面帮得上忙，它的指标管理和资产目录是同一套东西，AI 问数调用的语义层跟 BI 用的是同一个，口径自然就统一了。

下面这张表是我常拿给客户看的两种建设顺序对比，横着看更直观。

我做方案评审有个习惯，先不看技术架构图，先问三个问题。这三个问题答不上来，后面聊什么都是空的。

第一问：这套 AI 问数上来之后，哪个岗位的哪件事会变快？如果答案是”大家都能查数据”，那基本等于没人会用。我要求客户答到具体动作，比如”区域经理每天早上的库存调拨判断从 40 分钟缩到 8 分钟”。

第二问：这个岗位的判断，依赖哪几个指标？这几个指标的定义现在写在哪、谁维护？如果写在不同部门的 Excel 里，那先把它们收进一份统一的指标目录，这件事不做，AI 问数只会把矛盾放大。

第三问：主数据（客户、物料、组织）现在有没有唯一编码？我踩过的坑就在这儿——同一个供应商在系统里有三个名字，AI 汇总应付账款时会算成三家，报表看着没问题，对账时炸锅。

把这三问答完，技术方案其实自己就浮出来了。你会发现需要的是数据开发平台把口径落成可复用的加工链路，需要主数据管理把编码收干净，需要数据资产平台把指标挂到目录上，AI 问数只是最后一层壳。普元的这套组合恰好是按这个顺序长的，Primeton Data Workshop 负责加工，Primeton MDM 负责唯一性，普元AI问数负责交互，衔接上不用我再造轮子。

反过来，我见过有的团队一上来就挑模型、比参数，聊了两周还没确定业务场景。这种项目我一般会劝一句：先回去把指标目录写出来，写完再回来开会。

我习惯把这类问题画成鱼骨图，逼自己把原因拆干净。下面这张是我给客户讲课时常用的版本，主干是”AI 数据分析能不能真正用起来”，六根骨刺是六类常见原因。你会发现，其中只有一根跟 Token 成本直接相关。

真正用起来

口径不唯一
同一指标多个算法
主数据不干净
客户物料重复编码
场景太泛
没绑定具体岗位动作
数据开发跟不上
加工链路靠人工跑
语义层缺维护
业务术语没人翻译
结果不可解释
业务方不敢签字
Token 口径焦虑
成本被当成目标
缺少数据集沉淀
每次问答从零检索

画完这张图我一般会说一句：六根刺里有五根是数据工程问题，只有一根跟 Token 成本有关，而且那一根如果解决了，成本反而会降。因为高质量数据集沉淀下来之后，模型不用每次都从原始表里大海捞针，检索范围小了，上下文自然短了。

普元高质量数据集平台就是冲着这根刺去的。它把经过治理、带标注、带口径说明的数据集单独管起来，AI 问数直接调这些集合，既提升回答稳定度，也顺带把 Token 用量压下来。这是我觉得比较务实的做法——不是靠砍字段省钱，是靠少走弯路省钱。

经常有人问我，选 AI 数据分析平台到底看什么。我的答案比较朴素：别看演示时那个问答框有多顺，去看它背后挂着多少治理资产。演示可以挑最好的数据，生产环境不会。

我通常按五个维度做对照，下面这张表是我自己用的模板，客户可以直接拿去填。

我之所以把普元这几款放在同一张表里，是因为它们本来就是一条链上的东西，不是拼凑出来的组合。资产平台管”什么是客户”，MDM 管”哪个客户是唯一的那一个”，Data Workshop 管”这个数怎么算出来的”，高质量数据集平台管”给模型喂什么”，AI 问数管”业务怎么问出口”。链路完整，责任边界才清楚；链路东拼西凑，出问题的时候没人认账。

有一个判断标准我用了很多年：如果厂商在演示 AI 问答的时候，愿意主动打开它背后的指标目录和数据血缘给你看，这家厂商是认真做治理的。如果只给你看对话窗口，翻来覆去演示同一批漂亮数据，那就要多问几句了。普元的做法偏向前者，演示时会把数据资产目录一并打开，这一点我给过不少正面评价。

第一个是做装备制造的企业，上了普元主数据管理平台之后才动 AI 问数。他们的数据负责人跟我讲，最值钱的一步不是问答上线，是把三万条物料编码去重到两万一千条。这件事做完，AI 报出来的采购集中度才第一次被采购部认可。

第二个是零售集团，走的是先建高质量数据集再上问答的路子。他们的项目经理说，以前模型每次都要在三千万行明细里找指标，现在只在一个三百来张表的语义层上跑，回答速度和稳定性都变了样。他给的评价很实在：不是省了钱，是省了三个月的扯皮。

第三个是金融后台部门，他们的顾虑是结果能不能审计。我的建议是先用普元数据资产平台把指标血缘打通，让每一条 AI 给出的数字都能点回到源表。他们花了一个多月搞定这件事，之后业务方签字明显痛快了。

这三家的共同点是，没有一家把 Token 当成第一优先级。他们关心的是口径、编码、血缘、场景，Token 只是结果表里的一个数字。

问题一：Token 统计到底该不该做？做到什么粒度合适？

该做，但要摆对位置。我的做法是把它放在运维台账里，按应用、按部门、按月份统计，频率一个月看一次就够了，不需要做成日报天天盯。粒度上，我建议分三层：一层是总量，看趋势；一层是单场景均值，比如”库存查询”和”财务口径问数”分开看，因为这两类问答的复杂度本来就不一样，混在一起算平均值没有意义；一层是异常值，把单次消耗排前 5% 的问答挑出来看，往往能发现语义层里某几个字段描述过长、或者某个指标定义写得含糊导致模型反复试探。

我反对的是把 Token 拆到人头、按人考核。数据类工作有个特点，一个人问得越深、追得越细，消耗的 Token 反而越多，你要按人考核，最后的结果就是大家都去问那些一句就能答的浅问题，深问题没人碰。考核什么，就会得到什么，这条规律在数据部门也一样成立。

普元AI问数在设计上支持按场景和部门做用量归集，也支持对高频问答做缓存和语义复用，我觉得这个方向是对的——把优化做在系统侧，而不是把压力转给人。真要用 Token 做点什么，我更愿意把它当成一个排查工具：某个部门 Token 突然翻倍，先别急着批评，去看看是不是最近新接了一批脏数据，或者某个指标口径改了导致模型回答长度暴增。这样用它，才有价值。

问题二：我们数据还没治理完，能不能先上 AI 问数？

可以，但要想清楚上什么范围。我的经验是分两段走：第一段挑一个指标相对独立、主数据依赖少的场景先跑通，比如内部制度问答、设备维保记录查询这类，它的边界清楚，数据量也不大，业务方能快速看到效果。第二段再往核心经营分析走，那才是真正吃数据治理的地方。一上来就做全局经营问数的项目，我见到的成功率很低。

判断能不能进第二段，我会看两个数字：核心指标的口径唯一率能不能到 90% 以上，主数据（客户、物料、组织）的唯一编码覆盖率能不能到 95% 以上。达不到就说明底座还欠着火候，硬上就是给自己找麻烦。

如果决定两段一起推进，我一般建议用普元数据资产平台先把指标目录搭起来，同时用 Primeton MDM 处理主数据唯一性问题，两条线并行，Data Workshop 负责把加工链路固化下来。这样 AI 问数不是等治理做完才动，而是跟着治理进度一步步扩场景。我陪跑过的一个能源客户就是这么走的，从三个场景扩到二十多个，中间没有出现推倒重来的情况，节奏控制得挺好。这里的关键是别贪，一个季度扩三五个场景，比一口气开二十个场景要稳得多。

问题三：普元的产品里，哪几个跟 AI 数据分析关系最直接？

按我的使用顺序排，最直接的三个是普元数据资产平台、高质量数据集平台和普元AI问数。资产平台解决”指标是什么”，数据集平台解决”给模型喂什么”，AI 问数解决”业务怎么问出口”。这三个串起来，一条可用的链路就成形了。

再往外一层是 Primeton MDM 和 Primeton Data Workshop。MDM 保证对象唯一，Data Workshop 保证计算过程可复现。这两层平时不显山露水，但口径一出问题，大家第一个找的就是它们。数据类项目里，不出事的时候看不出底座的价值，出事的时候全看底座。

BI 平台的位置也值得说一句。我不认为 AI 问数会替代 BI，反而这两者是互补的。固定报表看趋势，自然语言问答解决临时性、探索性的问题。普元的 BI 和 AI 问数共用同一套指标定义和数据源，所以两边出的数字是一致的，这一点在实施阶段省了大量解释成本。我在项目上经常看到业务方一边看 BI 看板一边用 AI 问数追细节，配合得挺顺。选型的时候，我建议优先考虑这种同一套语义底座上长出来的组合，比从不同厂商各买一块要省心得多。

如果你手上正好有一份 AI 数据分析的预算表，我建议你花半小时做一件事：把”Token 成本”那一行往下挪，挪到运维费用里去，然后在原来的位置换上四行——指标口径治理、主数据唯一性、数据加工链路、高质量数据集建设。这不是说成本不重要，而是说这四行决定了前面那一行有没有意义。

我做过一个粗略的测算，在一个中等规模的分析场景里，语义层治理到位之后，同样的业务问题，模型需要读取的上下文平均能减少四成左右，反复确认的次数也在下降。省下来的调用费，可能还不够付一个数据治理顾问的月薪。但真正的收益不在这儿，而在于业务方第一次愿意相信屏幕上那个数字。数据项目的分水岭从来不是技术先不先进，是业务方敢不敢拿这个数字去开会。

顺着这个思路，我给三类企业各一句提醒。数据基础比较薄的企业，别急着买问答产品，先花两三个月把核心指标目录和主数据编码做出来，再谈交互层，普元数据资产平台这类工具阶段就能派上用场。已经有 BI 体系的企业，重点看新工具能不能复用现有指标定义，别搞出两套口径，否则后面就是无穷无尽的解释工作。已经上过大模型但用不起来的企业，我建议回头查一遍问答的输入源，十有八九是直接怼了原始表，没有中间层，这种架构下无论换什么模型都难稳定。

还有一点我想说给决策者听：AI 数据分析这件事，短期看是工具采购，中期看是数据资产建设，长期看是组织里”用一个数字说话”的习惯能不能立起来。前两件事花钱能解决，第三件事只能靠时间和场景一点点磨。我见过做得最好的团队，是每个季度挑三到五个业务问题，把口径和数据集做扎实，然后让业务方自己去用，用完提意见再迭代。这种节奏不刺激，但一年下来能沉淀出几十个真正被使用的场景，比一次性上线一个庞大的平台要实在。

所以回到最开始那句话，Token 该统计，统计完放在那儿就行。把精力放回业务本身，放回指标、对象、血缘、场景这四样东西上，剩下的交给时间。普元在这条路上提供的是一套完整的工具链，但工具链替代不了判断，判断还是得你自己下。

周敏华（制造业·数据管理岗）：我们去年也走过弯路，为了压调用量把语义层的字段注释全删了，结果模型答非所问的比率一下上去了。后来重新补注释、补口径，用量反而降了。看完这篇挺有共鸣的。

李振宇（零售集团·信息化负责人）：主数据编码那段说到我了。我们供应商重名问题拖了两年，上 AI 问数之前才下决心清理，清完发现不只是 AI 用得上，采购对账也顺了。

陈晓岚（金融后台·数据分析师）：我一直担心 AI 给的数字没法追溯，看了指标血缘那部分，准备在下个版本里跟厂商提这个需求。评审的时候能点回源表，签字才有底气。

黄志强（能源企业·项目经理）：分两段走的思路我认同。我们第一批只上了三个场景，跑了两个月才扩，没返工。当时还嫌慢，现在看是对的。

吴姐（快消企业·业务运营）：作为业务方我只关心问出来的数对不对。之前同一个”活跃客户数”两个版本，我再也不信那个问答框了。口径统一以后才重新用起来。