大模型评测成本应该如何控制？
简化版
控制评测成本不能简单减少样本，而要把不同成本的检查分层：每次提交先跑规则、单测和小型冒烟集；候选版本再跑核心回归和便宜 Judge；发布前才跑完整集、强 Judge 和人工评测。
还可以使用固定输出缓存、只重跑受影响切片、按方差分配样本量、批处理 Judge，以及顺序检验提前停止明显失败或明显胜出的实验。高风险门禁不能因成本被跳过，应单独设最小覆盖。
成本优化的目标是减少低信息量评测，不是减少发现严重回归的概率。
详细版
评测成本可拆为：
C_total = C_generation + C_judge + C_human + C_infra
C_generation ≈ N × (input_tokens·price_in + output_tokens·price_out)例如 5000 条样本，每条平均输入 2000 Token、输出 500 Token；若输入/输出每百万 Token 分别 10 元和 30 元，仅候选生成约为：
5000 × (2000/1e6×10 + 500/1e6×30) = 175 元若每条再由 3 个强 Judge 评审、每个携带长 Rubric，评分成本可能超过生成成本。
| 层级 | 触发时机 | 典型规模 | 失败动作 |
|---|---|---|---|
| L0 静态/单测 | 每次提交 | 全量便宜检查 | 立即阻断 |
| L1 冒烟集 | 每次构建 | 50～200 | 快速反馈 |
| L2 核心回归 | 合并/每日 | 500～2000 | 阻断候选 |
| L3 完整评测 | 发布候选 | 数千以上 | 发布门禁 |
| L4 人评/红队 | 重要发布 | 风险分层抽样 | 专家决策 |
完整版教学
一、先建立评测成本账本
记录候选生成、Judge、Embedding/检索、人工标注、存储和工程运行成本。只看模型 API 账单会漏掉人工审核和失败重跑。
按模型版本、评测套件和样本切片归因，才能发现某个低价值 Judge 或重复样本正在消耗预算。
二、为什么分层评测最有效
绝大多数明显错误应在便宜层被拦截，只有少量候选进入昂贵层。类似测试金字塔：底层快且频繁，顶层慢但覆盖真实体验。
如果每次 Prompt 改一个标点都跑 5000 条三 Judge 人评，反馈慢且成本浪费；若只跑 20 条，又无法支撑发布决策。
三、如何构建高信息量冒烟集
冒烟集应覆盖每个关键能力、接口和高风险类别，而不是随机抽 100 条。优先选择历史上容易回归、能快速暴露配置错误的样本。
它不能替代完整集，但能在几分钟内发现模型不可用、工具 Schema 断裂、拒答全面失效等大问题。
四、只重跑受影响切片是否安全
变更影响可通过依赖图估计：修改检索器优先跑 RAG 与引用，修改工具 Schema 优先跑对应 Agent 任务。但大模型组件耦合强，仍需保留小型全局回归。
targeted slices + global smoke + periodic full suite只跑开发者主观认为受影响的部分，会漏掉意外跨能力回归。
五、缓存应该以什么为 Key
确定性或低随机评测可缓存候选输出，Key 至少包含模型/权重哈希、Prompt 模板、输入、工具版本、解码参数和数据集版本。
缓存命中若忽略任一真实依赖，会把旧输出伪装成新版本结果，比不缓存更危险。
Judge 输出也可缓存，但更换 Rubric 或 Judge 版本必须失效。
六、怎样减少 Judge 成本
先用规则、Schema、代码执行和引用验证处理客观项，只把语义判断交给 LLM。可用小 Judge 初筛，边界样本再路由强 Judge。
| 样本 | 初筛动作 | 升级条件 |
|---|---|---|
| JSON/代码 | 确定性执行 | 无法执行或语义项 |
| 明确通过/失败 | 小 Judge | 低置信或与规则冲突 |
| 高风险 | 强 Judge/人工 | 默认升级 |
| 普通开放回答 | 批处理 Judge | 分数靠近阈值 |
这种 Cascade 需要在人工集上验证漏判率。
七、Batch Judge 有什么取舍
一次 Prompt 评多个样本可摊薄系统指令 Token，但上下文过长会产生位置偏差、样本串扰和解析失败。
应随机样本顺序、限制批大小、使用稳定 ID 和严格输出 Schema，并对单条与批量评分做一致性实验。
例如分别测试每批 1、4、8、16 条，记录单样本成本、解析失败率和相对单评的翻转率。若批量从 8 增至 16 只节省 10% 成本，却使翻转率由 2% 升到 8%，通常不值得采用。
八、样本量如何按方差分配
简单、稳定的切片不需要与高方差切片相同样本量。可通过 Pilot Run 估计方差，把更多预算放在边界和关键指标。
分层抽样后总体指标使用流量权重，高风险指标独立报告。不能因线上占比低就只测两三个严重场景。
九、顺序检验如何提前停止
实验可分批运行并更新置信区间。当候选明显低于发布下限时提前失败；只有接近边界时继续收集更多样本。
batch 1: 200 samples -> 明显回归 8% -> stop fail
batch 2..k: 只有区间跨越门槛时继续必须使用适合重复查看的统计方法或预设停止规则，避免反复偷看造成假阳性。
十、人工评测如何省而不偏
把人工预算用于自动评分器低置信、Judge 分歧、高风险和随机审计样本。不要只标模型最差样本，否则无法估计总体质量。
使用配对比较通常比独立 1～5 分更稳定；复用已标注基准答案也能降低成本，但要检查真值是否过期。
十一、哪些地方不能省
安全严重类别、法律/医疗等高风险任务、关键工具副作用和新领域冷启动必须保证最小样本与专家覆盖。成本压力不能把其稀释到总体平均中。
评测基础设施的可复现日志、数据隔离和失败样本保存也属于必要投入，否则省下运行费却失去事故定位能力。
十二、如何衡量评测 ROI
记录每个套件发现的独立回归数、阻断严重度、平均运行时间和成本。长期不发现问题的套件可能重复或过易，但不能仅因“最近全绿”就删除。
可通过故障注入验证套件敏感性：人为制造引用缺失、工具错误和安全绕过，确认对应评测能报警。
十三、常见误区与追问
- 误区：减少样本数就是控制成本。 随意缩样会扩大不确定性并漏掉低频风险。
- 误区：便宜 Judge 与强 Judge 的分数可直接互换。 需要在人工黄金集上校准路由。
- 误区：缓存只看模型名称。 Prompt、参数、工具和数据版本都必须进入 Key。
- 误区：受影响切片评测可以完全替代全局回归。 组件耦合会产生意外影响，应保留全局冒烟和周期全量。
- 误区：所有样本都值得三 Judge 投票。 客观项应优先用确定性验证，边界项再升级。
- 追问：怎样最快发现坏版本？ 先跑高信息冒烟集，并用顺序检验对明显回归早停。
- 追问：人评预算放在哪里？ 高风险、Judge 分歧、低置信与代表性随机审计。
十四、加强记忆
先算账：生成、Judge、人工、基础设施四类成本；分层运行：提交冒烟、合并回归、发布全量、高风险人评；复用有边界：缓存 Key 必须覆盖全部真实依赖。智能分配：规则优先、Judge 级联、按方差抽样、边界样本升级；红线不省：高风险覆盖、可复现日志和周期全量回归必须保留。
项目实战落地
项目里怎么做的
《AI Agentic RAG高级企业知识库平台》先把一条用例的评测成本算清楚。四个指标不是调一次模型，一条用例要调六次：
1 把标准答案拆成陈述 （用例带来源片段 ID 时省掉这一次和下一次）
2 判断标准答案有没有被召回
3 判断每段资料有没有用
4 把生成的答案拆成陈述
5 判断答案的每句话有没有支撑
6 从答案反推问题加上问答本身的检索和生成，实际更多。每次判断都要把资料一起发过去，五个片段就是两千多字，所以评测的成本主要在输入 Token 上，不在输出上。围绕这一点，项目做了三件事：
- 一次评测最多 20 条。
MAX_CASE_COUNT = 20，20 条 × 每条十几次调用 × 每次两千多字输入，已经是一轮几十万 Token 的量级；评测集超过 20 条时直接拒绝开始，并告诉管理员怎么处置。 - 成本写在按钮下面。 批量评测页的「开始评测」按钮下方写着「一条用例要调六次模型，20 条用例一轮大约几十万输入 token。建议先用 5 条验证方向。」
- 能省的调用都省掉。 判断类的 Prompt 一次判完所有条，不逐条调用；带来源片段 ID 的用例，上下文召回直接做集合运算，不调模型。
为什么这样取舍
- 一次判多条省的是输入。 标准答案拆成 5 句，逐条判断是 5 次调用，每次都要把资料重发一遍，输入 Token 是 5 倍；一次判完只发一遍资料。
- 先 5 条再 20 条。 调一个开关之后，先用 5 条看方向对不对，方向对了再跑完整的 20 条，避免把几十万 Token 花在一个一开始就不对的方向上。
- 成本提示放在点之前。 管理员在点「开始评测」之前就看到一轮大概要花多少，而不是跑完才知道。
面试官还会追问
- 策略对比看板上的「单条耗时」是怎么算出来的？为什么不直接比较每次评测任务的总耗时？
- 评测集超过 20 条时，拒绝提示里给了哪两个处置办法？
学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。