16_成本拆成三项之后judge占了91%

16 · 我把成本拆成三项之后发现 judge 占了 91%有一次我看到单次成本从 ¥0.001 涨到 ¥0.005第一反应是生成端出问题了是不是 prompt 变长了拆开一看生成端一分钱没多花。一、三项拆开长什么样我改了记账方式把一次「评测运行」的成本拆成三段分段单次成本占比说明检索¥0.00000%本地向量库暴力全量检索不调 API不花钱生成ask¥0.00059.4%真正回答用户那一次调用评测judge¥0.004890.6%让模型给答案打分合计¥0.0053100%数据data/eval/w3d5_baseline_120_judgefix.json120 条平均九成的钱花在「给答案打分」上而不是「做出答案」上。二、这个拆分救了我一次误判如果不拆我看到的只是一个总数从 ¥0.001 变成 ¥0.005 —— 「变贵了 5 倍」。我会去查prompt 是不是变长了上下文是不是塞多了模型是不是换贵了全查错方向。真实原因是我开了 LLM-as-judge评测开关而 judge 那部分成本跟「服务用户」一点关系都没有。生产环境根本不会跑 judge。用户来问一次问题我的真实成本是 ¥0.0005不是 ¥0.0053。差了 10 倍。如果我拿 ¥0.0053 去做容量规划我会得出「这个服务太贵了做不了」的结论——而真实成本只有它的十分之一。三、它改变了我看 Rerank 的眼光拆开之后我重新看了一遍第 14 篇里那个 Rerank检索成本说明baseline¥0.0000本地检索不花钱rerank¥0.0022重排要调 APIRerank 把检索从「不要钱」变成了「要钱」而且 ¥0.0022 是生成成本¥0.0005的四倍多。这个数字不拆根本看不见——它会混在总数里表现为「整体贵了一点」。知道了这个Rerank 的决策就清楚了它在跨文档题上收益很大20.8pp但它不便宜而且会把 p95 延迟从 1778ms 推到 3016ms所以正确做法不是「全量上线」也不是「砍掉」而是只在跨文档这类题上启用——用最少的多花钱换最大的收益。四、顺带一个反直觉的数字我的检索成本是¥0。不是因为它便宜是因为我用的是本地暴力全量检索——3700 个块余弦相似度全算一遍完全不走 API。我写过一篇第 08 篇讲为什么 3563 条向量我不用 ANN 索引理由之一是这个量级下暴力检索的延迟低到 p50 350ms而且成本为零。对比一下本地暴力检索¥0p50 350msRerank¥0.0022p50 1211ms当一个操作是免费的时候你对「优化」的判断标准会完全不一样。用付费 API 换免费本地计算的一点提升多半不划算。五、三条记账纪律我现在做 LLM 项目成本记账上有三条硬规矩必须分段。检索 / 生成 / 评测分开记。混在一起的总数只能用来吓唬自己。区分「生产成本」和「评测成本」。评测是开发期开销不该算进服务成本里。每次调用都落账。我有个.cost_ledger.jsonl累计到COST_LIMIT_CNY默认 ¥20就抛异常中止。第三条是失业在家逼出来的——我没有公司账单兜底一次跑飞的全量评测就能吃掉一天预算。闸门必须放在代码里不能放在脑子里。脑子里的闸门在凌晨两点会失效。六、一句话不拆开看你连「贵在哪」都不知道更别说优化。而拆开之后最常见的发现是钱没花在你以为的地方。我以为贵在生成实际贵在评测我以为检索要钱实际检索免费我以为 Rerank 只是慢一点实际它是生成成本的四倍。上一篇15 · 我的评测端自己也错了三处下一篇17 · Agent 出错怎么兜底