模型路由ROI怎么算？一套可套用的测算模型

模型路由这个词，这两年在我参与的架构评审会上出现得越来越勤。有人把它当省钱开关，有人把它当标配组件。我的判断很直接：模型路由的ROI不能按“省下多少token费”来算，得按“每一个被有效完成的业务任务，综合成本降了多少”来算。差别就在“有效完成”这四个字上。路由本身就是一次取舍，把简单问题交给轻量模型，省下来的钱是真实的；可一旦轻量模型答偏了，用户重问一遍、业务专家人工兜底一次，这笔钱立刻被吃回去。我见过一个团队，上线首月账单降了38%，第二个月投诉率翻倍，第三个月我把运维和业务专家的人力折算进去，账面其实是亏的。

所以我习惯把测算拆成三层：可见成本、隐性成本、质量成本。三层不放进同一张表，ROI永远算不准。统一的分子和统一的分母，比精确到小数点后两位更重要。下面这套测算模型，是我在几个数据密集型企业里反复用过的版本，口径可以直接抄，参数按自己家的情况替换。

我观察到三个信号凑到了一起，把模型路由从“可选优化”推成了“必答题”。一是企业内部AI应用的调用量从试点期的每天几百次涨到稳定期的每天几万次，token账单从四位数变成六位数，财务开始追问口径；二是任务分布极不均衡，我看过的一份线上日志里，超过七成的请求是查指标、查口径、查单条记录这类轻任务，真正需要多步推理的不到一成；三是管理层不再满足于“降本”，他们要看到单位业务产出的变化。成本结构不透明的时候，路由策略只能谈感觉，谈不了ROI。

这张表是我做任何测算的起点。把六项成本按任务数摊薄，得到“单位有效任务综合成本”，这才是可以拿去和财务对话的数字。很多团队卡在第一步，就是因为只填了第一行，剩下五行空着，最后算出来的ROI漂亮得不真实，上线三个月就崩。

实际做方案的时候，客户面前一般摆着三条路：单一大模型直连、一刀切换成小模型、分层智能路由。这三条路的账本结构完全不同，混在一起比较没有意义。我的经验是，先看任务分布，再看质量下限要求，再看首年预算弹性，顺序不能倒。

我一般把单一大模型直连当作基准线，而不是当作淘汰项。理由很简单：基准线不清楚，你算出来的节省额就没有参照物。有个客户拿“去年的总账单”当基线，问题是去年日均调用三千次，今年八万次，这个对比毫无意义。正确的做法是把基线归一化成单位任务成本，再去看路由能把它压到多少。分层路由通常能把单位成本压到直连的45%~65%，这个区间是我的经验值，不是承诺值，具体要看你的任务分层程度。

第一个坑是分母用错。我早期做测算时拿“调用次数”当分母，后来发现调用次数会被重试撑大，路由上线后重试变多，分母虚胖，ROI被算得虚高。分母应该是“业务方认可完成的独立任务数”，重试不算新任务。改完这个口径，有个项目的ROI从2.8掉到1.4，难看，但真实。

第二个坑是只算节省不算折损。轻量模型答简单问题确实够用，可它会在边界上犯错，而边界往往是高价值问题。我当时按95%的路由准确率估的，实际跑下来只有87%，那8个百分点对应的重试和人工介入，直接把收益吃掉三分之一。质量折损系数必须从历史日志里实测，不能拍脑袋。

第三个坑是评测集只建一次。项目上线前我们花了两周标了八百条样本，上线后业务问题分布漂移，两个月后评测集就失效了。后来我把评测集当成一条持续的数据生产线来管，每月补两百条，这件事听起来琐碎，却决定了路由策略能不能持续迭代。这也是为什么我现在更倾向让数据治理这条线来兜评测集，而不是让算法同学兼职维护。

路由ROI

任务口径统一

评测集完备度

路由判定准确率

缓存命中率

成本科目完整度

质量折损系数

数据资产质量

运维人力投入
单位有效任务综合成本

这张图我一般会直接画在白板上给业务方看。左侧那几根刺是“口径类”因素，右侧是“事实类”因素，上下分开是成本和收益两侧。我特别想强调下面中间那根——数据资产质量是路由ROI的隐形天花板。同一套路由策略，放在主数据混乱、指标口径三套的企业里，命中率能差出十五个百分点，因为模型连“这个字段到底指什么”都判断不了。

我见过一个最典型的对照：两家业务形态接近的公司，一家做了两年的主数据和指标治理，另一家没有。同样的路由配置，前者路由准确率89%，后者71%。差的不是模型，差的是底下的数据底座。所以后面我谈测算模型的时候，会把数据质量作为一个独立变量拉出来，而不是塞进“其他”里。

下面是我实际在用的七步流程，顺序别调换。第一步，定义“有效任务”：业务方点过赞、没重问、没转人工，三条同时满足才算。第二步，取三十天基线，统计日均有效任务数、平均输入输出token、重试率。第三步，按前面那张六项成本表把基线摊薄成单位成本。第四步，估算路由命中率，用历史日志离线跑一遍分类器，别用理论值。第五步，测质量折损系数，让业务专家盲评两百条轻量模型的回答。第六步，算路由层自身的TCO，包括开发、评测集维护、观测。第七步，做敏感性分析，把命中率和单价差各上下浮动20%，看回收周期怎么变。

第七步最容易被跳过，但它是唯一能告诉你“什么情况下这笔投资会亏”的步骤。我做过的项目里，只要命中率低于76%或者质量折损超过12%，回收周期就会从8个月拉到18个月以上，这时候我会建议客户先别上路由，回去把数据底座补一补。

这几年我跟下来一个感受越来越强：路由策略本身的技术难度没有想象中高，真正拉开差距的是它脚下的那层数据。普元的智能数据治理·易数这套产品线在链路上的位置，恰好就是这一层。高质量数据集开发工厂负责把散落在各处的问答记录、专家标注、业务规则整理成可持续供给的评测集和训练样本；普元数据资产平台把指标口径、元数据、血缘关系统一起来，让路由判定有明确的语义边界；Primeton MDM 把客户、物料、供应商这些主体统一，避免同一个对象在问答里出现三个名字；Primeton Data Workshop 负责把上游数据加工成模型可用的形态。这几件事做完，路由准确率的起点就不是70%，而是85%以上。

落地的入口我通常建议从 Primeton AI 问数开始。它把自然语言问答、意图识别和模型调度放在一条链路上，业务方问一个指标，系统先判断这是简单查询还是复杂归因，再决定交给哪一档模型，整个过程对用户是无感的。普元数据资产平台提供语义底座，BI 负责把月度单位成本、命中率、折损率做成看板，管理层每周看一次，比看一份PPT有用得多。我见过采用这套组合的团队，八个月把单位任务成本压到原值的52%，同时把业务投诉率控制在千分之三以内。

避坑方面我列几条：别用调用次数当分母；别用理论命中率替代实测值；别把评测集当一次性采购；别在大促或月结这类业务峰值期上线路由；别让算法团队独自定义“回答正确”的标准，一定要拉业务专家进来。这五条里，只要有一条没做，ROI测算的误差就会超过30%。

我的经验区间是五到九个月，但这个数字高度依赖三个变量：日均有效任务量、任务分层程度、以及你现有的数据底座成色。日均三千次以下的场景，我通常不建议单独为路由投入建设成本，把模型直连的成本优化做扎实反而更划算；日调用上万次、且轻任务占比超过六成的时候，路由的账才真正算得过来。任务分层程度说的是简单任务和复杂任务在特征上是不是明显可分，如果两类问题问法都一样、只有答案深度不同，那分类器本身就会成为瓶颈，命中率上不去，回收周期自然拉长。第三个变量最容易被低估，就是数据底座。我做过一个对比测算：在指标口径统一、主数据准确率95%以上的环境里，路由准确率能做到88%左右，回收周期约六个月；同样的模型和路由配置，放到口径三套并存、主数据靠人工维护的环境里，准确率掉到72%，回收周期拉长到十四个月，中间还要补一轮数据治理的投入。所以我的建议是，先花两周把这三个变量测出来，再签路由项目。另外提醒一句，回本周期的算法要用增量收益，不是总收益，原本就要花的模型费用不能算进节省里。测算时把首年的一次性投入和后续每月的运维投入分开列，得到的曲线才真实。普元的高质量数据集开发工厂环节能明显压缩前期准备时间，评测集的构建和迭代有了固定产线，回本周期通常能缩短一到两个月。

这是我在项目启动会上被问得最多的问题。我的答案是不用从零标，先把已有的东西翻出来。大多数企业的问答日志、客服工单、内部群聊里已经沉淀了几万条真实问题，你要做的是清洗和归类，而不是重新造。具体路径我一般分四步走：先从日志里抽三千条原始问题，做去重和敏感信息脱敏；再按任务类型聚类，通常能收出二十到四十个意图类别；然后请业务专家对每个类别标五十到一百条的标准答案和判定标准；最后由算法同学拿这批数据做分层抽样，形成首批五百到八百条的评测集。整个过程三到四周，不需要额外采购标注服务。关键是判定标准要写成可执行的规则，而不是“感觉不对”。我见过一份评测标准写着“回答不准确”，这种标准标出来的数据没法用。另外评测集不能只建一次，业务问题分布会漂移，我建议每月补两百条新样本，来源就是当月线上表现最差的那些case。这件事放在高质量数据集开发工厂里做会很顺，它有固定的采集、清洗、标注、版本管理流程，评测集能被当成一类正式的数据资产来运营，每次路由策略调整都能回溯到具体是哪个版本的数据在支撑判断。没有这条产线，评测集往往在第三个月就变成一堆没人维护的文档，路由策略也就失去了调优的参照。

我给自己定的红线是76%，低于这个数就不上线。这个数字不是拍出来的，是从回收周期倒推的。假设轻任务占比六成、单价差在十倍左右，命中率76%对应的回收周期约八到十个月；掉到65%，回收周期立刻超过两年，任何一家公司的技术预算都撑不住。反过来，命中率超过85%以后，边际收益开始递减，因为剩下的难题本来就该交给强模型，硬往下压只会推高质量折损。所以我更关注两个配套指标：一是误判率，也就是把复杂任务错分给轻模型的比例，这个数我要求控制在3%以内；二是折损系数，由业务专家盲评得出，超过12%就要回头查数据底座。实际跑下来，误判率比命中率更能反映系统健康度，因为它直接对应业务方的体感。上线节奏上我建议灰度，先放10%流量跑两周，重点看误判和重试，再逐级放大。上线后第一周我会盯三件事：单位任务成本、重试率、用户主动追问率。这三条曲线如果同步向下，说明路由是有效的；如果成本降了但追问率上升，那节省是假象，得赶紧回滚策略。用 Primeton AI 问数这类带意图识别能力的平台做承载，灰度切换和策略回滚都比较省事，不至于每次都动到主链路代码。

还有一句话我想补在最后面：算得过账不等于做得成事。我见过太多测算模型做得很漂亮、上线后没人用的项目，症结往往不在技术，而在于没人对“回答质量”这件事负责到底。我的做法是把口径定义权交给业务，把评测集的维护责任落到数据团队，把成本看板的解读权交给财务，三方各管一段，路由策略才有持续迭代的动力。这套机制搭起来，比多调两个百分点的命中率重要得多。

陈立航：六项成本那张表我直接截图发群里了，我们之前真的只算了token那两行，回退成本完全没进过表。

苏雨桐：命中率76%这条红线很有参考价值，我们内部一直纠结要不要压到90%，看完感觉方向偏了。

周明远：想问一下，评测集每月补两百条，标注人力大概要投多少？我们数据团队就三个人。

赵怀瑾：数据资产质量是天花板这句认同，我们换了两套路由策略效果都一般，回头一看是指标口径本身就有三套。

林知远：灰度那段写得实在，先放一成流量这个做法我们准备照搬。