企业官网建设流程全解析

写好评估标准的艺术：LLM-as-a-Verifier的criteria文件模板与5个避免reward hacking的关键要点

【免费下载链接】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

LLM-as-a-Verifier是一个通用的 Agent 验证框架：它无需额外训练，就能为任意智能体（编码、机器人、医疗等）提供细粒度评分反馈。而整个框架评分质量的上限，取决于你写下的那份criteria 文件——也就是本文要讲的"评估标准"。本文将带你拆解官方 criteria 文件模板的结构，并总结 5 个避免 reward hacking（奖励作弊）的关键写法。

先看清 LLM-as-a-Verifier 如何工作

在写标准之前，先花一分钟理解评分机制：框架把"给轨迹打分"分解为四个可放大的维度——不确定性（对分数 token 的 logprob 取期望）、粒度（细粒度打分）、重复（多次评估聚合）、分解（拆成多条独立标准）。你写的每一条 criteria 都会被独立打分、独立缓存，再汇总成 [0,1] 之间的细粒度奖励：

这正是为什么"写好 criteria"如此重要——标准的数量和写法直接决定了反馈的精度。

criteria 文件模板：三段式结构

官方提供了可直接复制的模板 criteria/TEMPLATE.md，一个合法的 criteria 文件只由三部分构成：

几个新手最容易踩的解析细节（实现见 llm_verifier/prompts.py）：

• ###标题名即标准名，其缓存 id 由名称 slug 化生成（如 "Final Answer Correctness" →final_answer_correctness）。想改名又不想失效缓存，用尾部锚点固定 id：### Final Answer Correctness {#correctness}
• HTML 注释（<!-- ... -->）会被整体剥离，验证器永远看不到，因此模板里可以放心写写作提示
• 写完后可以零成本预览验证器实际看到的内容（无需 API key）：

python -m llm_verifier criteria/terminal_bench.md

5个避免reward hacking的关键要点

Reward hacking 指的是 Agent 钻标准漏洞刷分：声称成功却没验证、改对文件却改错位置、输出格式"看似正确"。对照仓库内三份内置标准，可以提炼出 5 条防御写法。

要点1：在 Ground Truth Note 中声明"不信任自我报告"

这是三份内置文件的共同第一句。例如 criteria/terminal_bench.md 写着："以终端输出为 ground truth，不要信任 agent 的自我评估——agent 在终端报错时仍常声称成功"。这句总纲对每一次比较都生效，是防作弊的地基。

要点2：写清楚"去哪里找证据"

模糊的标准会诱导验证器看"叙述"而非"证据"。好的写法是指明具体的命令、字段、文件位置。对比 criteria/medagentbench.md 的写法："只看 GET 请求的 URL 参数——patient=是否与问题中的 MRN 完全一致（逐位数字）、code=是否为合法代码……"。证据位置明确，Agent 就无法靠"讲故事"蒙混过关。

要点3：明确说高分什么样、低分什么样

模板中的标准同时给出两端锚点："仅当答案被轨迹中观察到的输出完全支持时打高分；若答案无证据支撑、与观察输出矛盾、或答非所问，则打低分"。双向锚定能显著压缩验证器的解释空间。

要点4：显式声明"忽略什么"，防止标准互相污染

验证器逐条独立打分，2~4 条窄标准远胜 1 条宽标准。每条标准结尾都该有一句"边界声明"，如 criteria/swe_bench.md 的 Code Quality 项结尾："按技术价值评判 diff，而非篇幅或表面工作量"——这就把"写了多少代码"排除在评分外，避免与正确性标准重复计分或互相干扰。

要点5：只评估轨迹中可观察的行为，杜绝标签泄漏

add_new_benchmark.md 对新基准的硬性要求是：标准必须"仅凭轨迹本身可判定"，且"避免标签泄漏或 reward hacking——应评估轨迹中的可观察行为"。通俗地说：标准里不能写"成功轨迹应该……"这类暗示答案的措辞，只能写"检查 X 命令的输出是否为 Y"。

从内置的3份criteria文件中学到什么

仓库为三个 SOTA 基准各配了一份标准文件，都是要点1~5 的完整示范：

• Terminal-Bench（criteria/terminal_bench.md）：规范符合性、输出逐字符匹配、错误信号检测——专门防"命令没跑通却声称完成"
• SWE-bench Verified（criteria/swe_bench.md）：根因定位、代码质量、实证验证——专门防"修了症状没修病因"
• MedAgentBench（criteria/medagentbench.md）：查询参数准确性、响应-答案对齐、结束格式——专门防"从空数据里编造具体数值"

一个值得注意的细节：MedAgentBench 的总纲特别指出"不要偏向看起来具体的答案，也不要偏向默认值"——连"验证器自己的偏见"也被标准显式约束了。

用criteria驱动细粒度进度追踪

写好的标准不仅能做 Best-of-N 选择，还能逐步给 Agent 打分。下面的曲线来自 scripts/terminal_bench_progress.py 的复现：同一个 pytorch-model-cli 任务，成功轨迹（绿）的验证器分数随步骤稳步爬升到 1.0，失败轨迹（红）因安装错误、编译报错始终低位徘徊——标准写得越准，这条曲线越可信：

上手：3步写出你自己的criteria文件

1. 复制模板：cp criteria/TEMPLATE.md criteria/my_task.md，替换内容但保留标题结构（见 criteria/TEMPLATE.md）
2. 按 5 个要点逐条改写：声明不信任自我报告 → 指明证据位置 → 给出高低分锚点 → 声明忽略项 → 只写可观察行为
3. 预览并跑起来：先用python -m llm_verifier my_task.md确认解析无误（入口见 llm_verifier/main.py），再用llm_verifier.select(..., criteria="my_task")加载评分；完整接入流程可参考 add_new_benchmark.md

评估标准不是给验证器看的"提示词"，而是一份评分合同：写得越窄、越可观察、越明确拒绝不可验证的证据，reward hacking 的漏洞就越少。从 criteria/TEMPLATE.md 复制起步，对着 5 个要点逐条自查，你写出的 criteria 就能像内置基准一样可靠。

【免费下载链接】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