零成本重跑实验：LLM-as-a-Verifier评分缓存与确定性锦标赛复现的设计哲学

零成本重跑实验LLM-as-a-Verifier评分缓存与确定性锦标赛复现的设计哲学【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifier做智能体Agent评测的人都有过同样的痛一次实验要跑几千次 LLM 验证调用账单吓人想换个参数再验证一遍就得再烧一遍钱。LLM-as-a-Verifier 是一个面向任意智能体的通用验证框架它用评分缓存Score Cache、前缀缓存优化和**确定性锦标赛PPT**三件套把重跑实验这件事的成本压到了接近零——只要分数已经算过整个基准可以离线、零 API 费用复现。本文带你拆解这套设计背后的工程哲学。为什么重跑实验这么贵先看一次验证到底做了什么。框架对每对候选轨迹会在 C 个评分标准criteria× K 次重复验证上各发一次 LLM 请求。以 Terminal-Bench 2.1 为例每条验证提示要携带两条完整轨迹约 8 万 token整个基准动辄上万次调用。问题拆解成两个钱同样的对比重复算一遍就是重复付费结果漂移锦标赛里有个随机环节随机哈密顿环换个随机种子就可能选出不同的赢家实验无法严格复现LLM-as-a-Verifier 的解法分别落在两个模块llm_verifier/fine_grained_reward.py 负责算一次、记一辈子llm_verifier/pivot_tournament.py 负责随机但可复现。评分缓存给每一次对比一个永久门牌号定向比较 精确缓存键框架里每一对比较都是定向的(a, b) 和 (b, a) 是两个不同的缓存条目。缓存键由四元组唯一确定——标准 ID、任务名、候选对、重复序号{crit_id}|{task_name}|{a},{b}|{rep}这个设计看似朴素却是零成本重跑的地基无论锦标赛内部如何流转、参数怎么改只要 (标准, 任务, 候选对, 重复) 没变就直接读磁盘一次 API 都不发。评分主循环 score_directed_pairs 会先加载已有缓存只为缺失的键生成任务每完成 1/20 的任务量就落盘一次——即使中途崩溃已花的钱也不白费。前缀缓存优化命中率从 5.2% 拉到 78.4%光有本地缓存还不够API 侧的前缀缓存才是大头。框架在提示词结构上下了功夫任务描述、两条轨迹、评分量表全部放在前面唯一变化的标准criterion放在提示末尾让不同标准之间共享超长的公共前缀。配合预热波策略——每个不同前缀先发一个请求跑完把服务端缓存焐热剩余请求再扇出并行——在terminal_bench_2.1上把前缀命中率从 5.2% 提升到 78.4%未命中输入 token 直接减少约 3.4 倍。提示词的组装逻辑在 build_prompt 里注释明确要求改提示词时把标准相关文本严格留在末尾。LazyClient缓存跑满后连 API Key 都不需要这是整个设计里最优雅的一笔。评分器客户端是懒加载的LazyClient只有真的需要发请求时才创建。于是当所有比较都命中缓存时脚本会打印 All scores cached 并直接返回——复现一个完全缓存的实验根本不需要配置任何 API Key。验证框架自己就是确定性复现的第一个用户。确定性锦标赛随机但种子说了算固定种子 环路径 可复现的随机选最优候选用的Probabilistic Pivot TournamentPPT包含一步随机打乱的环路径ring pass。但 scripts/run.py 中所有随机性都来自一个显式random.Random(seed)而种子是基准配置的固定字段默认 0可在 llm_verifier/benchmarks.py 的注册表里查到也可用--seed覆盖。这意味着同样的轨迹数据 同样的种子 同样的缓存 逐位相同的锦标赛过程。换种子则是一次廉价的再抽一次签新增的比较照样只算增量。O(Nk) 的比较预算缓存命中率拉满轮赛制要打分全部 N(N-1)/2 对候选PPT 只需 N k(N-k) C(k,2) 次——对 N 线性。以 best-of-5、2 个枢轴计每个摇摆任务约 17 次比较比轮赛制的 10 对×K 重复 ×C 标准省下大量调用。预算花在刀刃上缓存自然更容易填满。每个配置一份独立缓存bo3 与 bo5 互不串味复现 best-of-3 和 best-of-5 的脚本各自维护独立的缓存与结果文件scripts/run_bo3.py 使用config缓存名_bo3.json绝不共用。这保证了报告的 token 消耗是谁花的算谁的也让两个配置可以随时分别重跑、互不污染。每个基准的缓存与结果路径都集中声明在 BENCHMARKS 注册表里一目了然。一键复现从零到结果表的操作指南安装与配置pip install llm-verifier # 在 .env 中配置验证后端DEEPSEEK_API_KEY / VERTEX_API_KEY / OPENAI_BASE_URL 三选一按名字跑基准不带参数运行 scripts/run.py 会列出所有可用基准python scripts/run.py terminal_bench python scripts/run.py swe_bench --pivots 2 --n-evaluations 8 --seed 0 --max-workers 50首次运行付费、落缓存第二次运行同一命令评分阶段零 API 调用直接输出 Pass1 / LLM-as-a-Verifier / Oracle 三行对比表并写入results/。复现自验证实验python scripts/run_bo3.py # Terminal-Bench 2.1 的 best-of-3 python scripts/run_bo5.py # best-of-5复现进度追踪示例python scripts/terminal_bench_progress.py # 重新打分并绘制曲线 python scripts/terminal_bench_progress.py --plot-only # 只重绘零 API 调用注意--plot-only曲线已经存进cache/画图完全离线——连验证框架的示例图都能零成本重生。下图就是pytorch-model-cli任务成功/失败两条轨迹的逐步验证分数让每一分成本都有账可查重跑省下的钱不能靠感觉。框架内置了进程级、线程安全的 token 记账器TokenUsage每次验证调用自动记录输入/输出/缓存命中/推理 token结果表下方直接打印本次运行的成本报告token_usage()还能在库里拿到同样数字。关键点从评分缓存返回的比较不产生任何 token 记账——所以第二遍重跑的成本报告就是零省了多少钱一目了然。小结把可复现当一等公民回到设计哲学LLM-as-a-Verifier 的三个选择都指向同一件事——让实验成为可累积的资产而不是一次性消耗评分缓存比较是最小计价单位算过即永久有效增量永远是零成本前缀缓存 预热把 API 侧的重复 token 也变成一次付费种子化锦标赛 独立配置缓存随机性被框死在可复现的范围内LazyClient token 记账复现无需凭证省钱可被测量这套模式对所有LLM 调用密集的评测项目都有参考价值先定义稳定的缓存键再让随机性显式化最后给成本装个电表。想动手试试从 README.md 的 Quickstart 和 criteria/ 下的标准模板开始把 add_new_benchmark.md 里的任务名替换成你自己的就能接入自己的轨迹数据。【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考