AI 成本核算应看每个合格结果的总开销

模型调用降价，能让团队更便宜地启动实验，却不保证产品运行成本同步下降。作者提出，应该把整条工作流的花费，除以真正通过验收的结果数，而不是只盯着每次请求的价格。

这套思路值得程序员借鉴：重试、工具调用和人工检查，经常藏在 token 账单之外。不过，原文提供的是衡量框架，房产研究案例也只是拟议实验，没有实测数据证明哪种方案更省钱。

一次请求便宜，不代表一个可用结果便宜

作者给出的公式很直接：

Cost per accepted result = total workflow cost ÷ results that pass review

也就是：每个通过验收的结果成本，等于工作流总成本除以通过验收的结果数。

分子不能只填模型账单。模型输入与输出、缓存上下文、工具调用、重试、失败运行、人工审核，以及其他相关费用，都要按一致口径记录。

为什么连失败也算？因为失败同样消耗资源。如果只统计成功那次调用，前面反复尝试的支出就从报表里消失了。一个请求单价更低的模型，如果经常给出错误线索，需要更多重试和人工纠正，最终可能更贵。

分母则要数「不同的合格结果」。同一项任务重试多次，最终得到一个通过验收的输出，只能算一个结果，不能把尝试次数当作产出。

真正要比较的是交付一个合格结果的成本。

还有一个容易处理错的边界：如果没有任何结果通过验收，单位成本就是未定义。应分别报告总支出和零个合格结果，不要写成零，也不要写成无穷大。没有记录到的费用同样不能填零，必须标为未知。

怎样避免算出一个漂亮却没用的指标

计算之前，先固定任务、预期结果的 ID，以及验收规则。这里的 ID 可以理解为每个目标结果的唯一编号，用来确认两套流程处理的是同一批目标，也避免重复计数。

验收规则尤其关键。如果一个方案要求证据完整，另一个方案只要求答案看着合理，后者即使单位成本更低，也不能证明它更划算。

作者还提醒，要同时看精确率、召回率和做出决定所需的时间。精确率关心推荐出来的候选有多少是对的；召回率关心所有应该找到的目标里找回了多少。成本下降，可能伴随着遗漏增加，单看一个数字无法发现这种交换。

原文用房产研究说明如何开展测试：先准备一批有人类标注的房产记录，让系统找出值得进一步调查的候选，并提供支持证据，再由审核者逐条接受或拒绝。随后记录精确率、召回率、总成本和决策耗时。

如果模型把大量错误线索送到审核者面前，省下来的调用费用就可能被审核时间抵消。这是该实验要检验的问题，并非作者已经得到的结论。

作者提到，自己在 Appraiva 从事房产影像分析与房产身份、数据补充和搜索的连接工作。但文中的实验不是 Appraiva 已有功能的介绍，也不是他们团队公布的业务成果。

原文对「accepted result」也划了边界：它只表示通过预先记录的审核规则。历史标题中的「verified result」指向同一套规则，并不代表获得独立认证。

我的判断

我认同作者把人工检查放进成本账。对需要审阅和返工的 AI 工作流，只看 token 支出，很容易低估真实投入。相比按请求价格选模型，这个框架更接近团队要解决的交付问题。

但它能否用于决策，取决于验收规则是否可信。规则太松，单位成本容易变得好看；规则覆盖不到关键错误，通过验收也未必代表结果可靠。作者要求同时看精确率、召回率和决策耗时，正是在限制这个指标的使用范围。

落地还有几个未解决的问题：人工时间如何折算费用，共享工具费用怎样分摊，标注样本是否覆盖真实任务，原文都没有给出具体方法。因此，它更适合作为团队内部的记账与比较框架，不能直接拿来给不同公司的方案排名。

原文没有模型之间或人机流程之间的对照数据，省钱效果仍然需要实验验证。

作者也明确称这是一套编辑整理的衡量方法。文末提到的 Holistic Evaluation of Language Models（2022）等参考资料，不构成对这套流程的背书。

能拿来做什么

• 从已有 AI 流程里挑一个重复任务，先写下当前人工处理步骤和合格条件，再运行实验。不要看到输出之后才调整验收门槛。
• 在 Node 编排层或任务日志中，为目标结果保留唯一 ID，关联每次模型调用、工具调用、重试和审核记录。成本累计到目标结果，通过验收时只计数一次。
• 比较两套流程时，使用相同任务批次、验收规则和币种，同时展示合格结果数、总成本与决策耗时。对于候选筛选任务，再补充精确率和召回率。
• 给成本报表保留「未知」状态；当合格结果为零时，展示总支出、零个合格结果和单位成本未定义，避免用默认零值掩盖实验失败。