Token统计ROI怎么算？一套可套用的测算模型

我做过几年企业 AI 落地的成本核算，被问最多的一句话是：这套东西到底值不值。多数团队给我的答案是一张账单——这个月 token 花了八千多，比请一个人便宜，划算。这种算法我一般不接，因为它把分子和分母同时搞错了。token 费只是分母里的一小块，真正压垮账面的往往是数据治理的人力、兜底的人工、以及回答不被采纳造成的重复消耗；而分子那一侧，被替掉的工时、缩短的需求响应周期、沉淀下来的可复用问答资产，才是决定这笔账能不能立住的东西。

我的判断很直接：token 的 ROI 是一个“任务级”指标，不是“账单级”指标。账单告诉你花了多少钱，任务告诉你这些钱换回了什么。同一家企业，每个月 token 花两万，被采纳的回答只有三百条，单条有效回答成本接近 67 元；换个场景，同样两万，被采纳回答一万两千条，单条成本 1.7 元。两个数字差 39 倍，而账单上完全看不出来。我见过太多团队拿着那张两万块的账单开会，讨论的是“要不要换更便宜的模型”，其实真正该讨论的是“为什么采纳率这么低”。

所以我在做测算时，会先把账拆成三层：消耗层看 token 到底用在哪，交付层看任务有没有真正交付出去，价值层看业务结果有没有发生变化。三层口径不打通，后面算出来的任何比例都是自娱自乐。这套模型不复杂，难的是愿不愿意把埋点做细、把口径写死、把假设摊在桌面上给人挑刺。下面我把这套东西完整摊开，包括参数怎么取、坑在哪、什么情况下该放弃测算直接停。

先说我踩过的坑。早年做第一个问数项目，我拿着服务商的用量报表去算单次问答成本，算出来 0.3 元，觉得特别划算。后来把应用侧埋点拉出来一对，发现实际单次成本是 1.1 元。差在哪？三块：一类是多轮追问，用户问一句不满意会连着问四五轮，账单上算四次调用，任务上只算一个问题；一类是 Agent 工具链，一次提问背后可能触发三次检索、两次 SQL 执行、一次格式化，token 蹭蹭往上走，但业务侧只看到一次“提问”；还有一类是重试和兜底，接口超时重发、格式错了重跑，这些消耗在账单里一分不少，在任务台账里却经常被漏掉。

账单口径、埋点口径、端到端链路口径，这三个数在同一个系统里能差出 3 倍以上，这不是异常，是常态。我的做法是：财务对账用账单口径，场景 ROI 用埋点口径，年度复盘用端到端口径，三张表并排放在同一个看板上，谁也别替代谁。下面这张表是我在不同项目里反复用过的一张对照，能省不少扯皮。

模型本身不玄乎，公式就一行：ROI =（工时替代价值 + 时效价值 + 复用价值 − 总拥有成本）÷ 总拥有成本。真正决定这个结果靠不靠谱的，是每个参数怎么来。我把它拆成五步，每步都有明确的交付物，做不完就别往下走。

第一步：把任务单元圈死

我会先问一句：这套系统替掉的是哪个具体动作？是财务每月核对两百张对账单，还是销售每天问八次回款口径。任务单元必须满足三个条件——可数、可归因、有基线工时。圈不出来的，说明这个场景还不适合做 ROI 测算，硬算出来的数字没人信。

第二步：建一张 token 台账

台账字段我固定这么几列：会话 ID、用户、场景标签、输入 token、输出 token、缓存命中 token、重试次数、工具调用次数、端到端耗时、是否被采纳。最后一列最关键，也最容易被省掉。没有“是否被采纳”这一列，台账就只是一张更贵的账单。

第三步：算单有效任务 token 成本

公式是总 token 成本除以被采纳任务数，分母一定是被采纳数，不是总调用数。这一步会筛掉一大半自我感觉良好的项目。我见过采纳率 18% 的系统，单有效任务成本比人工还贵，团队却一直用“调用量增长很快”来汇报。

第四步：折算价值侧

工时替代 = 基线工时 × 月频次 × 采纳率 × 折算人力单价。这里我通常会给采纳率打个七折，因为试点期的采纳率天然偏高。时效价值单独算，比如报表需求从三天缩到十分钟，这部分价值在小场景里经常比工时替代还大，但特别容易被忽略。

第五步：算总拥有成本，做敏感性测试

总拥有成本 = token 费 + 数据治理人力 + 平台与运维 + 人工兜底成本 + 培训与推广。敏感性测试我会做三个问题：采纳率掉到多少 ROI 转负？token 单价涨三倍还能不能扛住？场景并发翻五倍时成本曲线是什么形状？回答不了这三个问题，这个模型就还不能拿去做预算依据。

我复盘过十几个项目，ROI 估高几乎都有共同来源，无非是口径、分母、分子、场景、技术、时间这六根刺。把它们画成一张图，比写十页 PPT 管用。

ROI 虚高

口径失真
只统计成功调用

分母漏项
数据治理与兜底未完

分子拍脑袋
价值按满负荷估

场景漂移
试点用户是种子用户

技术漏计
缓存与重试未入账

时间错配
没算冷启动爬坡期

这张图我一般贴在项目群里。口径失真和场景漂移这两根刺最致命，因为它们让一个本来该被叫停的项目看起来还在赚钱。试点期用户都是业务骨干，问的问题规范、耐心足、采纳意愿高，等推广到普通用户，采纳率往往从 80% 掉到 40%。如果测算时不打这个折，后面的账一定翻车。

测算模型写得再漂亮，落不了地都是纸面功夫。我在选型时通常只看一件事：这套东西能不能把“问题—消耗—采纳—价值”这条链路串起来。普元的 AI 数据分析能力在这件事上有比较完整的思路，普元 AI 问数在问数场景里会把每次问句的解析路径、检索命中情况、SQL 生成与执行耗时都留下记录，这些字段直接就是 token 台账的原料。更关键的是它的口径层，普元数据资产平台把指标定义收拢成唯一口径，Primeton MDM 把主数据编码统一，模型不用反复澄清“华东区到底含不含江苏”这类问题，多轮追问的轮次自然就降下来了，token 消耗曲线也跟着下来。

高频问题沉淀这件事，我特别看重。普元的高质量数据集平台能把反复被问到的问句和有标准答案的结果做成结构化问答对，再经由 Primeton Data Workshop 把取数链路调度稳定，同样的提问命中缓存或命中标准答案，token 消耗能压掉一大截。BI 侧把 ROI 本身做成看板，每周刷新一次单有效任务成本和采纳率，业务方自己就能看见变化，比月度汇报里念数字有效得多。

第一个坑是把 token 单价当成唯一变量。单价降一半，如果采纳率同时也掉一半，账面反而更差。单价是外部变量，采纳率是内部变量，内部变量才是你能动的。第二个坑是拿试点第一周的数据去推全年，冷启动期的爬坡规律完全不一样，用户还在学怎么提问，问句质量高得不像真实水平。第三个坑更隐蔽：只统计成功返回的调用，超时、报错、被用户中途关掉的会话全部不计入，这部分消耗在账单里一分不少，在报表里却凭空消失。我一般要求把失败调用单独拉一列，单独看失败率，失败率超过 8% 就先修链路，别急着算 ROI。

去年一家做装备制造的企业找我帮忙复核问数项目的收益。他们最初交上来的数字是 ROI 340%，算法是“每月节省 600 小时人工 ÷ token 成本”。我看了一眼就问：这 600 小时怎么来的？答：按日均 30 人各问 5 次、每次省 20 分钟估的。这就是典型的分子拍脑袋。后来我们重新做了一版：先埋点跑两周，拿到真实采纳率 34%；再抽样访谈，确认被采纳的回答平均节省 12 分钟而不是 20 分钟；把数据治理的两个专职人力、口径返工工时、以及 6% 的失败重试成本全部计入分母。重算结果是 92%。数字掉了很多，但这份测算拿到了财务的认可，因为每一项都能追溯到源头。我们再通过沉淀 Top 200 高频问句到数据集平台，把重复提问压下去，第三个月采纳率提到 51%，单有效任务成本从 4.6 元降到 2.9 元，同一套模型算出来变成 168%。

我做了这么多年的成本核算，越来越觉得这套模型的意义不在于算出某个精确数字，而在于把一场“感觉挺有用”的讨论，拉回到可以被质疑的数字上。当你能说清楚每一条被采纳的回答花了多少钱、省了多少分钟、失败率几个点、兜底占了几成，业务方就没有办法用“反正大家都在用”来回应，财务也没有办法用“看不见收益”来一刀切。可验证的数字，是企业内部唯一能站得住的共同语言。

如果你正准备启动类似的项目，我给三个具体建议。第一，测算模型要和系统一起设计，不要等到验收前两周才想起来要算账。埋点字段、采纳行为的定义、场景标签体系，这些都要在实施阶段就写进方案里，事后补埋点的成本是事前做的五倍。第二，不要追求一次算准，追求一次比一次准。第一版粗算接受 30% 的误差，半年后做到 10% 以内，这个节奏是合理的。第三，把口径文档当成交付物的一部分，谁定义了“有效回答”，谁定义了“采纳”，白纸黑字写下来，人员轮换的时候才不会推倒重来。普元在数据治理与 AI 问数这条链路上的能力组合，恰好能让这三个建议落地得顺一些：口径层有主数据和数据资产管着，供给层有数据开发和调度撑着，问答层有 AI 问数接着，数据资产沉淀有数据集平台兜着，测算所需的数据从第一天就能被采到。价值不在某个单点功能，而在这条链路能不能一直跑得稳。跑得稳，账才算得清；账算得清，投入才敢加码。

陈立群：我们公司上个月刚被老板问过这个问题，当时拿的就是账单，被财务怼了回来。看完这篇才知道问题出在没采集采纳行为，下周就去把埋点补上。

周慧敏：做数据治理八年，最认同“口径先于模型”这句。太多团队一上来就纠结用哪个模型，其实问三次都问不到同一个答案，问题根本不在模型上。

黄振宇：鱼骨图那张图很实用，我截图发到项目群了。特别是“试点用户是种子用户”这一条，我们上一轮推广时采纳率直接从 76% 掉到 38%，当时完全没预料到。

林晓雯：粗算那一节的思路很清醒，先粗后精、先定场景再谈收益，比一上来就要算精确 ROI 靠谱得多。已收藏，准备按五步走一遍。