成本模型也是交付物

语言模型试点几乎不花钱。每天 1000 次请求的费用，还不够批准这个试点的那场会议喝掉的咖啡。同一套系统，每天 6 万次请求，再加上重试、一个检索步骤和一轮校验，就成了财务总监要专门拿出来谈的一笔开支，而到那时，架构已经定死了。

我们把成本模型当作与代码同等地位的交付物。它与基线一起公布，时间在选定任何模型之前；每两周修订一次；并且与影响它的那次改动放在同一个拉取请求里一起评审。

成本模型里包含什么？

按每次请求：输入的 token 数、输出的 token 数、包括重试在内的模型调用次数、检索成本，以及分摊的基础设施费用。按每月：按小时分布的请求量，因为请求量不是平的，服务商的速率限制也不是。按每个决策：调整一个阈值，会让多少请求升级到人工处理，因为人是系统中最昂贵的环节，而模型的任务就是把人用好。

它如何改变架构？

以一个分拣系统为例。单件成本很少是因为换了更便宜的模型而下降。它之所以下降，是因为检索步骤加了缓存，简单的情况被分流给一个更小的分类器，以及一个演示时从未触发过的重试循环被发现并修好了。这些改动之所以会做，都是因为成本模型显示了钱花在哪里。没有它，团队就会去争论选哪个模型，而那往往恰恰是唯一无关紧要的变量。

这就是为什么在每一个 AI 与自动化和数据与分析项目中，成本模型都是一项明确列名的交付物，也是我们如何收费中的一个里程碑。

它放在哪里？

放在您的代码仓库里，和评测集放在一起，既是一张电子表格，也是一套遥测数据。遥测是让它保持诚实的那部分：电子表格说的是我们的预期，每次请求的日志说的是实际发生了什么，而每两周一次的评审，就是把两者对上的地方。我们离开之后，这项评审归平台负责人主持，他也可以自由修改它。这正是关键所在。