模型裁判太贵？用抽样控制评测开销

客服机器人上线后，用更强的模型给每条回答打分，评估费用可能比机器人本身还高。作者按一组假设算出：每天回答 10,000 次，机器人每月花 $132，评估却要 $1,260。

他的建议是：先确定你想把错误率估得多准，再决定每天随机评估多少条。400 条是文中的示例，不是通用标准。对维护 AI 应用的程序员，更有用的是分清两件事：抽样能监测质量，但不能拦住错误回答。

为什么评估一次，能比回答一次贵 9.5 倍

LLM judge 指用另一个模型，按照评分规则检查机器人的回答，例如有没有答非所问、有没有编造退款政策。

它贵在三个地方：要读取机器人收到的上下文、已经生成的回答和额外评分规则；通常选更强、更贵的模型；常见方案还会逐条调用。

作者明确说明，以下是**基于假设的成本测算，不是线上实测。**价格取自其参与开发的 LLM gateway 目录，读取日期为 2026 年 10 月 26 日。

项目	客服机器人	评估模型
模型	GPT-5.6 mini	GPT-5.6
单次输入	1,000 tokens	1,500 tokens
单次输出	200 tokens	100 tokens
每百万输入 tokens 标价	$0.20	$2
每百万输出 tokens 标价	$1.20	$12
单次费用	$0.00044	$0.0042

评估输入中的 1,500 tokens，包括原始输入 1,000、回答 200、评分指令 300。这样算下来，一次评估约是一次回答的 9.5 倍。

这个倍数依赖模型价格、上下文长度和评分输出长度，不能直接套到所有项目。文章也没有给出账单或性能对照实验。

每天评估 400 条，到底能知道多少

如果回答已经发给用户，后台评分无法修复这次体验。它主要回答的是：最近有多少比例的回答出了问题。

随机抽样也能估计这个比例。在真实错误率为 5% 的假设下，作者用下面的公式计算约 95% 置信水平下的误差范围：

1.96 × √(0.05 × 0.95 / n)

这里的 n 是评估条数。按这个近似公式，400 条对应约 ±2.1 个百分点，也就是估计范围约为 2.9%～7.1%；10,000 条对应约 ±0.4 个百分点，范围约为 4.6%～5.4%。

评估量增加到 25 倍，换来的是更窄的区间。一般而言，想把误差减半，需要约四倍样本。

所以，即使流量涨到每天 100 万条，同样的 400 条样本仍对应约 ±2.1 个百分点，评估费用则降到机器人费用的约 0.4%。

但这有前提：样本要随机，评分标准要可靠，数据之间也不能有过强的相关性。这里的 95% 是统计方法在反复抽样中的覆盖水平，不是对某一天结果的保证。

怎样抽样，才能避免只看到白天的问题

作者给出的代码，用昨天的回答量计算今天每条回答被选中的概率：

import math, random

GRADES_PER_DAY = 400

def should_grade(replies_yesterday: int) -> bool:
    """Pick about GRADES_PER_DAY random replies a day, whatever the traffic."""
    return random.random() < min(1.0, GRADES_PER_DAY / max(replies_yesterday, 1))

def margin(failure_rate: float, graded: int) -> float:
    """How far the measured rate can be from the true one, 95% of the time."""
    return 1.96 * math.sqrt(failure_rate * (1 - failure_rate) / graded)

for n in (200, 400, 1600, 10_000):
    print(f"{n:>6} grades a day: 5% ± {margin(0.05, n):.1%}")

关键是 random.random() 那一行：它控制的是抽样概率，并不保证每天恰好选中 400 条。每次回答完成后调用 should_grade，选中的回答再交给后台任务评分，避免用户等待。

也不要直接取当天前 400 条。夜间用户可能提出不同的问题，按时间截取会引入偏差。

如果今天流量翻倍，而概率还按昨天计算，预期评估量会变成 800 条，当天费用从 $1.68 增至 $3.36。若希望提高精度，可以合并一周的 2,800 条样本，误差约为 ±0.8 个百分点，日均费用不变；代价是结果反映一周平均情况。

小流量应用仍要算账。每天只有 2,000 次回答时，评估 400 条的费用仍约为机器人费用的 1.9 倍。降到 200 条，误差则约为 ±3 个百分点。

我的判断

我认可作者把「质量监测」和「发送前拦截」拆开讨论。抽样适合估计整体错误率，逐条检查承担的是拦截责任。

比起全量调用强模型，固定数量抽样更适合控制监测预算；但它对低频问题很迟钝。真实发生率为 0.1% 时，400 条样本约有三分之二概率一次都碰不到。针对邮箱泄漏这类可用代码规则识别的问题，全流量检查更合适。

另一个局限是评估模型也会判错。作者建议先用人工评分的 50 条回答校准，但没有给出评估模型与人工的一致率，也没有证明这 50 条覆盖了哪些问题。因此，文中的建议属于成本测算和工程经验，不能据此认定评分可信。

作者还提醒，其参与开发的 gateway 记录调用状态码，但 HTTP 200 只能说明模型返回了响应，不能证明回答正确。接口成功率和回答质量，需要分别观测。

能拿来做什么

• 给已有客服 AI 增加后台抽样评估时，先写清可接受的误差范围，再确定每日数量，不要直接照抄 400。
• 在 Node 服务中接入时，可以沿用按概率选择回答的思路，把评分放到异步任务里，并同时记录当天实际样本数。
• 把人工评过的 50 条回答作为初步校准集，检查模型是否理解评分规则；不要把这个小样本当作完整验证。
• 对能够明确识别的敏感信息增加全量代码检查；必须在发送前拦截的问题，应单独设计逐条检查流程。