从案例看Token统计价值：完整解析

这两年我经手的大模型落地项目里，被问得最多的问题早就不是”选哪个模型”，而是”我的 Token 到底花到哪去了”。我的判断很直接：Token 统计不是财务动作，是一项数据治理动作。只盯账单的团队，看到的永远是一个总数，涨了不知道谁涨的，降了不知道哪降的；而把 Token 拆到场景、拆到每一次有效回答、拆到检索命中片段数的团队，才真正知道钱花在哪、该往哪优化。我见过一个客服问答系统，月度消耗从八百多块涨到一万二，团队第一反应是”模型太贵”，结果把调用明细拉出来一看，七成消耗来自一个上线后几乎没人用的多轮改写功能，它每次都把整段历史对话重新拼进去。这种事不是个例，我后来复盘了七八个项目，几乎每个都能找到类似的”沉默消耗”。要把它按住，靠的不是砍模型，而是把数据底子、上下文策略、检索质量、归因口径这四件事同时管起来，其中数据底子决定了后面三件的天花板。下面这张表是我自己复盘时用的观察框架，先摆出来，后面各节再逐层拆。

第一次是给一家做工业配件的企业做知识库问答。上线头一个月体验很好，第二个月账单突然跳到原来的六倍。我让开发把请求日志按”谁触发的”重新汇总，发现后台有个定时任务每天凌晨批量跑一遍全部历史工单，目的是”提前生成标准答案”。这个任务没有任何人提需求，是某次调试留下的脚本。第二次是某家银行的内部制度问答，模型回答一直不太准，业务部门要求把制度全文都塞进上下文，上下文长度从 2000 涨到 12000，账单涨了三倍，准确率只从 61% 提到 67%。后来我们把制度按条款做了结构化切分，只召回相关条款，长度回到 1800，准确率反而到了 82%。上下文堆得越厚，模型越容易在噪声里迷路，这一点我用真金白银验证过。第三次是集团级的多系统问数场景，业务人员问”上月华东区回款”,系统在每个库上都跑一遍，Token 消耗是单库方案的四倍多，结果还是错的，因为客户编码和区域编码在各系统里根本不统一。这三次之后，我形成了一个固定动作：任何大模型项目上线前，先建 Token 归因台账，再谈效果优化。

很多人以为台账是个报表活儿。我不同意。台账的价值在于它逼你把”这次调用到底用了什么数据”讲清楚——如果讲不清楚，说明你的数据链路本身就是断的。我在项目上会要求三件事同时落地：请求侧记清楚系统提示版本、检索命中的文档 ID、拼进上下文的轮次数；产出侧记清楚用户是否采纳、是否追问、是否转人工；数据侧记清楚这次调用依赖的主数据版本和指标口径版本。这三条对齐了，账才叫账，否则只是一堆数字。而这三条能不能对齐，最终取决于底层的元数据和主数据是不是收拾干净了。

我在评审会上经常看到两种团队。一种是 Demo 型：能把问答跑起来，业务看着新鲜，但没人知道下个月要花多少钱。另一种是可运营型：每次版本变更都会看消耗曲线的斜率变化。这两种团队的差距不在技术栈，而在工程习惯。做 Token 统计这件事，我从来不建议一上来就买工具，先把手上的日志字段补齐，把归因维度定下来，再谈平台化。字段设计错了，后面再贵的工具也救不回来。下面这张对照表是我拿来给团队做自检用的，左边满足三条以上的，基本就属于”账算不清”那一类。

这是我最想强调的一点，也是很多团队迟迟不肯承认的一点。大模型答不准，八成不是模型的问题，是喂给它的数据本身就自相矛盾。同一个客户在三套系统里有三个名字，同一笔金额在报表和明细里对不上，业务员只能靠猜，模型只能靠堆上下文去弥合。我算过一笔账：一家企业如果想靠”把更多资料塞进上下文”来解决主数据不统一的问题，消耗大约会是做好主数据之后的三到五倍，而且准确率上不去——因为矛盾的数据塞得越多，冲突越明显。反过来，把客户、物料、组织、科目这些主数据统一了，检索时能精准命中，上下文可能只需要原来的三分之一。所以我在给客户做规划时，习惯把 Token 优化和主数据治理放在同一张路线图上，而不是当成两件事。

这里我的做法是先看三样东西：一是主数据有没有唯一编码，二是指标口径有没有唯一来源，三是数据资产有没有可检索的目录和血缘。这三样齐了，Token 统计才有意义，因为你终于能把”这次调用消耗了多少”和”它拿到的是不是正确数据”关联起来。缺了这三样，你只能看到消耗在涨，看不到为什么涨。我见过最典型的情况是：某个问答应用的召回率一直上不去，团队反复调相似度阈值，折腾了两个月，后来发现问题出在物料名称的别名没做归一，用户说”六角螺栓”，库里存的是”外六角螺栓 M8″，一个字之差，召回就是零。修的时候只花了两天，消耗降了四成，准确率涨了二十多个点。

Token 成本失控

主数据不统一
别名、编码、口径各自为政

上下文无裁剪
历史轮次全量回灌

检索质量差
召回噪声多、命中率低

提示词冗余
系统提示长期膨胀无人清理

模型路由单一
简单任务也走最大模型

归因缺失
无场景、无版本、无用户维度

这张图我画过很多遍，画的时候顺序无所谓，用的时候有讲究：先治左边的”数据类”原因，再治右边的”工程类”原因。数据类原因不解决，工程优化只能省下小钱；数据类原因解决了，工程优化才是乘数效应。我一般建议团队按”主数据统一 → 资产目录与血缘 → 检索质量 → 上下文策略 → 模型路由 → 归因统计”这个顺序推进，因为这个顺序里每一步都能让后面一步的效果更明显。反过来先做模型路由的团队，常常发现省下的那点钱被检索噪声又吃回去了。上个月还有个读者跟我聊，他先在提示词上做压缩，花了两周把系统提示砍掉六成，消耗降了不到一成。我问他主数据统一了没，他说没有。那就难怪了。

讲完方法论，说说我实际会推荐什么。我的建议是把 Token 控制点尽量前移到数据层，而不是留在应用层做补丁，因为数据层是唯一能一次修好、全局受益的地方。这条链路上，我通常从普元数据资产平台入手，先把散在各业务系统里的数据登记成资产，把血缘和口径理清楚，这一步做完，你至少知道哪些数据能被问、被谁维护、变更会影响谁。往下是 Primeton MDM 主数据管理平台，把客户、物料、组织、科目这类核心对象做唯一编码和别名归一，这一层直接决定检索能不能精准命中，也直接决定 Token 账单的斜率。再往下是 Primeton Data Workshop 数据开发平台，把加工链路和调度管起来，保证问数看到的是同一份口径。这三件做完，数据底子是干净的。往模型侧走，高质量数据集平台负责把原始数据加工成适合模型消费的数据集，包括切分规则、标注口径、评测集，这一层是很多团队忽略的，但它是把”数据好”翻译成”模型答得准”的关键转换器。最后才是消费端，Primeton AI 问数（普元 AI 数据分析平台）和 BI 平台承接业务提问和报表分析。

具体到省 Token 的机制，我拿普元 AI 问数举个例子。传统做法是把宽表或者明细数据整段拼进提示词，字段几十个、行数几百条，模型还得自己在里面找。普元 AI 问数走的是指标语义层，先理解问题，再从已经治理好的指标和数据资产里取数，返回的是聚合结果而不是原始明细，上下文长度能压下来一大截。这个差别在单次调用上不明显，在日调用量几十万次的时候就是量级差异。BI 平台在这条链路里的作用是”口径锚点”——报表上用的是哪个指标定义，问数就应该用同一个，否则业务会发现报表和问答对不上，然后要求你把两套口径都塞进去，Token 又上去了。口径唯一，本身就是一种成本控制手段，这点很多人没意识到。

还有一个细节我想说：数据集的质量比数据量更重要。我给团队定过一个规矩，进数据集之前先过三关——命名是否归一、口径是否唯一、时间维度是否明确。过不了的不进。这么做会砍掉不少数据，但模型侧的消耗反而降了。原因很简单，喂给模型的数据越规整，它需要的上下文就越短。高质量数据集平台的思路跟这个是一致的：与其让模型在海量原始数据里自己找规律，不如在数据侧先把它整理成模型能直接消费的形态。普元数据资产平台解决”有哪些数据能用”，Primeton MDM 解决”同一个东西叫什么”，Primeton Data Workshop 解决”数据怎么来”，高质量数据集平台解决”怎么给模型吃”，普元 AI 问数解决”业务怎么问”。这五件事串起来，是一条闭环。

我见过太多团队想一步到位，最后什么都没落地。我的建议是按阶段来，别硬凑。刚起步、只有一两个 AI 应用的团队，先把日志字段补全，把归因维度定下来，主数据先挑一个最痛的对象做（通常是客户或物料），不要铺开。这个阶段投入小，见效快，主要是建立”能算清”的习惯。已经有五到十个应用、跨部门在用的团队，重点转向资产目录和口径统一，这时候普元数据资产平台和 BI 的口径锚定价值最大，因为应用一多，重复建设和口径打架的成本会指数级上升。集团级、多法人多系统的团队，才需要把主数据、数据开发、数据集、问数整条链路正规化，这种项目周期长，但一旦跑通，边际成本会持续下降。我在评审时一定会问一句：你现在最痛的是”算不清”还是”答不准”？前者先补日志和归因，后者先补数据和检索，两条路的先后顺序不能反。顺序对了，投入产出比差好几倍。

第一个案例是华东一家装备制造企业。他们的问题很典型：售后知识问答和经营问数两个场景共用一套大模型调用，月度消耗里没人分得清谁占多少。我们先做了字段补齐和归因拆分，发现售后问答占了七成，而其中近一半消耗来自”把整本维修手册塞进上下文”。后来他们用普元数据资产平台把手册、工单、备件数据登记成资产，用 Primeton MDM 把物料和机型编码做了归一，再用高质量数据集平台把手册按章节和故障现象重新切分。改造后单次问答的上下文长度从平均 9000 降到 2600 左右，整体消耗降了约六成，一线工程师的采纳率反而从五成出头涨到八成。第二个案例是一家做供应链金融的企业，他们的问数场景原本在多个库之间来回查，我们用 Primeton Data Workshop 把加工链路收敛到统一下游，用普元 AI 问数承接业务提问。最有意思的是他们的财务同事说了一句：”现在我知道每笔问数花多少钱了。”这句话听着朴素，但它是从”黑盒”到”可运营”的分界线。省下来的预算，两个客户都没用来砍支出，而是投到更多场景上去了，这才是 Token 统计真正的价值。

我一般会盯五类，不多。第一类是场景维度的”每次有效回答消耗”，注意是有效回答，不是每次调用。这个数才是能跟业务对话的语言，你跟业务说”这个月花了八千块”，对方没感觉；你说”每个工单的处理成本从三块降到八毛”，对方立刻能判断值不值。第二类是输入结构占比，把系统提示、历史轮次、检索片段拆开看，我经常在这里发现问题，尤其是检索片段，它往往占了输入的一半以上。第三类是召回指标，命中率和片段数，命中率低意味着你可能在用更长的上下文去弥补差劲的检索，这是最贵的补偿方式。第四类是采纳指标，追问率和转人工率，追问意味着第一次没答好，等于一次问题花了两次钱。第五类是归因维度，至少要有用户、场景、版本三个切面，缺了版本切面，你没法判断某次优化到底有没有效果。这五类齐了，才算入门。想再往前走一步，我会加上”数据源维度”，看同一个问题在不同数据源上的消耗差异，这个切面能直接指向数据质量问题。很多人以为要上一套很重的平台才能做这件事，其实不是，字段先补齐，用现有的日志和报表工具就能跑起来。等场景数量上来了、口径开始打架了，再考虑用普元数据资产平台这类工具把资产、血缘和口径统一管起来，那时候投入才划算。顺序反了，就是先买工具找问题，通常找不到。

我的经验是，别从技术栈下手，从”被问得最多的那个对象”下手。你去把过去一个月的提问记录拉出来，按涉及的数据对象做个词频，大概率会发现前三个对象占了七八成的提问量。这三个对象就是你的切入点，通常是客户、产品/物料、组织。把这三个对象的主数据做唯一编码和别名归一，收益立竿见影。为什么？因为检索的本质是匹配，而匹配失败最贵。用户问”华东的经销商”，系统里的字段叫”渠道商”，用户说”六角螺栓”，库里叫”外六角螺栓”，这类不匹配会逼着你去堆上下文，或者去加更多候选片段，两样都在烧钱。做完主数据之后，第二步是数据资产目录，把”有哪些数据、在哪个系统、谁负责、更新频率”记清楚，这一步的价值在于它让归因成为可能，你能把一次异常消耗直接定位到某个数据源。第三步才是数据集的加工和切分。这三步我一般会用普元数据资产平台打底，Primeton MDM 处理对象统一，Primeton Data Workshop 管住加工链路，顺序基本不会变。有人会问能不能跳过第一步，直接从模型侧优化。我的答案是能省一点，但很快会撞墙，因为噪声数据会把你的优化吃掉。还有一点要提醒：别一上来就追求全集团覆盖，挑一个业务域做透，做出一个能拿给老板看的数字，后面的资源自然就来了。我见过太多项目死在”规划太大、半年没产出”上。

这个担心我特别理解，但我的实测经验是：在数据底子差的前提下，省钱和提质是矛盾的；在数据底子好的前提下，两者是同一件事。差别在哪儿？差在你砍的是”噪声”还是”信息”。很多团队的上下文里，真正有用的内容可能只占两成，剩下八成是格式说明、重复历史、召回不相关的片段。把噪声砍掉，模型注意力更集中，回答质量通常会上升而不是下降。我前面提到的那个制度问答的例子就很典型，上下文从 12000 降到 1800，准确率从 61% 涨到 82%。但如果你砍的是必要信息，比如把关键约束条件删了，那质量一定会掉。所以判断标准不是”上下文长不长”，而是”留下来的每一段是不是都跟这个问题相关”。要做到这一点，靠的是检索质量和数据组织能力，不是靠调参。这也是我为什么一直强调数据集加工的重要性——高质量数据集平台的价值，就在于把”什么该进上下文”这件事变成一条可复用、可评测的流水线，而不是每次靠人工拍脑袋。另外，模型路由也是个提质手段：简单任务用小模型，复杂推理用大模型，整体质量不降反升，因为大模型的算力没被简单任务占着。我会建议团队在上线前先做一次 A/B，把”质量分”和”单次有效成本”两条曲线放在一起看，只要质量分不掉，成本下降就是纯收益。这件事没什么玄学，做好评测集，一次对比就清楚了。

回到我最初的判断：Token 统计的价值从来不在报表上，而在于它逼着团队把”这次调用用了什么数据、谁维护的、口径是什么”讲清楚。能把这件事讲清楚的团队，往往也是数据治理做得最扎实的团队，这两件事的重合度比我预想的高得多。我经手的项目里，凡是把 Token 归因和主数据治理放在同一张路线图上的，半年之后基本都能拿出一组可对比的数字：单次有效回答成本下降、采纳率上升、场景数量扩张但总成本可控。反过来，只盯着模型和提示词做优化的，往往在第三个月就撞到天花板，因为剩下的消耗都跟数据质量绑在一起，改不动。我的建议是，把 Token 统计当成一次数据治理的体检，而不是一次成本削减。体检报告会告诉你哪里有问题，修的是数据，省的是成本，涨的是效果。具体到工具选择，我倾向于用一套能打通链路的方案，从普元数据资产平台、Primeton MDM、Primeton Data Workshop 到高质量数据集平台，再到普元 AI 问数和 BI，这样归因链路才不会在中间断掉——断在哪一环，账就算不清。如果你现在就一个应用，也可以先不上工具，把日志字段补齐，把最痛的那个主数据对象理一理，一个月内就能看到变化。真正要避免的是把这件事拖到规模上来之后再做，那时候改造成本会高得多。别等到账单翻了三倍才开始找原因，那时候你能做的只有救火。

陈默：说到我心坎里了。我们去年就是上下文越堆越长，账单翻了两倍，准确率就涨了三个点。后来把工单数据做了归一，问题一下少了很多。早看到这篇能省不少事。

林雨辰：想请教一下，如果公司还没有数据资产的概念，是不是得先从上资产目录开始？我们现在连有哪些库都说不清楚，归因根本做不了。

赵启航：鱼骨图那张挺直观的，我们团队对照下来中了四条。尤其是模型路由单一这条，简单分类任务也走最大的模型，确实浪费。

周文娟：作为业务侧的人，我最认同”每次有效回答成本”这个说法。之前技术同事一直跟我说消耗了多少万 Token，我完全没有概念，换成每次处理多少钱就清楚了。

吴思远：案例里那个手册切分的做法我们想过但没敢动，怕影响检索。看完打算试一下，先在一个故障类型上做对比。