三种 Grader：代码、模型、人工
静态断言 vs LLM-as-Judge vs 人工校准，每种适合什么场景
本页解决的问题
先给结论「三种 Grader：代码、模型、人工」要解决的关键问题是什么？
静态断言 vs LLM-as-Judge vs 人工校准，每种适合什么场景
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
代码 Grader
| 维度 | 详情 |
|---|---|
| 方法 | 字符串匹配、正则表达式、静态分析（AST）、单元测试 pass/fail、工具调用验证（是否调用了正确的 API 和参数） |
| 优点 | 速度快（毫秒级）、成本几乎为零、结果完全客观可复现、适合 CI/CD 自动化 |
| 缺点 | 对合理变体过于严格（比如变量名不同就判错）、缺乏语义理解、无法评判主观质量 |
| 适用场景 | 有明确正确答案的任务：代码编译是否通过、API 返回值是否正确、文件格式是否合规、数学计算是否准确 |
模型 Grader（LLM-as-Judge）
| 维度 | 详情 |
|---|---|
| 方法 | 将 Agent 的输出和评分 Rubric 一起交给一个评委 LLM，让它按预设标准给出分数和理由 |
| 优点 | 能评判主观质量（文笔、逻辑性、创造力）、能理解意图而超越字面匹配、灵活适应不同任务类型 |
| 缺点 | 成本较高（每次评判都消耗 token）、可能存在评分偏见、需要精心设计评分标准、结果不完全可复现 |
| 适用场景 | 开放式任务：研究报告的质量评判、代码风格评估、对话的自然度、摘要的完整性和准确性 |
0 分 = 完全没有回答问题，或包含严重事实错误
0.3 分 = 回答了问题但遗漏关键信息
0.7 分 = 回答完整准确，但组织混乱或有冗余
1 分 = 完整、准确、简洁、结构清晰
人工 Grader
| 维度 | 详情 |
|---|---|
| 何时用 | 评测初期校准评分标准、LLM 评判出现明显盲点时、需要领域专家判断的高风险场景（医疗、法律、金融） |
| 优点 | 最高质量的反馈、能发现自动化方法的盲区、提供改进方向的深度洞察 |
| 缺点 | 不可扩展（人的时间有限）、速度慢（小时级到天级）、成本高、评判者之间也有分歧 |
| 适用场景 | 定期抽检校准模型 Grader 的准确度、全新场景的评测标准建立、关键产品决策的最终验证 |
- 静态分析（代码 Grader）：检查生成代码是否编译通过、lint 无错误
- 浏览器 Agent 测试（代码 Grader）：自动打开生成的页面，验证 UI 是否符合预期
- LLM Judge（模型 Grader）：评判代码质量、可读性、最佳实践遵循度
「代码 Grader」如何改变一次回答
「静态断言 vs LLM-as-Judge vs 人工校准，每种适合什么场景」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「静态断言 vs LLM-as-Judge vs 人工校准，每种适合什么场景」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 静态分析 （代码 Grader）：检查生成代码是否编译通过、lint 无错误
- 浏览器 Agent 测试 （代码 Grader）：自动打开生成的页面，验证 UI 是否符合预期
- LLM Judge （模型 Grader）：评判代码质量、可读性、最佳实践遵循度
先保留会改变判断的内容
可以用「静态断言 vs LLM-as-Judge vs 人工校准，每种适合什么场景」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「代码 Grader」走到「模型 Grader（LLM-as-Judge）」
「代码 Grader」先把问题落在「用程序逻辑自动判定对错 维度 详情 方法 字符串匹配、正则表达式、静态分析（AST）、单元测试 pass/fail、工具调用验证（是否调用了正确的 API 和参数） 优点 速度快（毫秒级）、成本几乎为零、结果完全客观可复现、适合 CI/CD 自动化 缺点 对合理变体过于严格（比如变量名不同就判错）、缺乏语义理解、无法评判主观质量 适用场景 有明确正确答案的任务：代码编译是否通过、API 返回值是否正确、文件格式是否合…」上；到了「模型 Grader（LLM-as-Judge）」，讨论继续推进到「让另一个 LLM 按评分标准打分 维度 详情 方法 将 Agent 的输出和评分 Rubric 一起交给一个评委 LLM，让它按预设标准给出分数和理由 优点 能评判主观质量（文笔、逻辑性、创造力）、能理解意图而超越字面匹配、灵活适应不同任务类型 缺点 成本较高（每次评判都消耗 token）、可能存在评分偏见、需要精心设计评分标准、结果不完全可复现 适用场景 开放式任务：研究报告的质量评判、代码风格评估、对话的自然度…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「代码 Grader」：用程序逻辑自动判定对错 维度 详情 方法 字符串匹配、正则表达式、静态分析（AST）、单元测试 pass/fail、工具调用验证（是否调用了正确的 API 和参数） 优点 速度快（毫秒级）、成本几乎为零、结果完全客观可复现、适合 CI/CD 自动化 缺点 对合理变体过于严格（比如变量名不同就判错）、缺乏语义理解、无法评判主观质量 适用场景 有明确正确答案的任务：代码编译是否通过、API 返回值是否正确、文件格式是否合…
- 「模型 Grader（LLM-as-Judge）」：让另一个 LLM 按评分标准打分 维度 详情 方法 将 Agent 的输出和评分 Rubric 一起交给一个评委 LLM，让它按预设标准给出分数和理由 优点 能评判主观质量（文笔、逻辑性、创造力）、能理解意图而超越字面匹配、灵活适应不同任务类型 缺点 成本较高（每次评判都消耗 token）、可能存在评分偏见、需要精心设计评分标准、结果不完全可复现 适用场景 开放式任务：研究报告的质量评判、代码风格评估、对话的自然度…
- 「最后的要点」：LLM Judge （模型 Grader）：评判代码质量、可读性、最佳实践遵循度
最后的「最后的要点」把讨论落到「LLM Judge （模型 Grader）：评判代码质量、可读性、最佳实践遵循度」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。