OpenAI《Graders》官方指南解读
本文基于 OpenAI Developers 官方页面《Graders》进行中文解读。重点不在逐段复述文档，而在于把不同 grader 类型的适用边界、优先级和组合关系讲清楚，方便实际落地。
- 原文标题：
Graders - 发布方：OpenAI Developers
- 页面链接：developers.openai.com/api/docs/guides/graders
这份指南解决什么问题
Section titled “这份指南解决什么问题”做 evals 时，很多团队很快会遇到同一个问题：到底应该用哪一种 grader 来判分。看起来最简单的是字符串匹配，但一旦任务开始开放化，它马上变脆；上来就用模型判分又容易成本高、不稳定、难校准。
OpenAI 这页文档的作用，就是把 grader 先当成“判分原语”来介绍。不同 grader 不是彼此替代的一个按钮，而是一组各有适用边界的判断工具，适合在不同任务里组合使用。
OpenAI 的 grader 体系本质上是在提供一个由确定性检查、语义近似检查、模型评审和自定义代码验证组成的判分谱系。真正有效的做法，通常不是只选一种，而是先用最确定、最便宜的 grader 兜底，再在需要语义判断或复杂逻辑时逐步升级。
核心概念拆解
Section titled “核心概念拆解”Overview：grader 不是只给 0 或 1（对应原文：Overview）
Section titled “Overview：grader 不是只给 0 或 1（对应原文：Overview）”OpenAI 开头先给出 grader 的总定义：grader 用来把参考答案和模型输出进行比较，并返回一个 0 到 1 之间的分数。这里最重要的点，是它并不把所有评估都压成二元通过或失败。
官方文档明确提到 "partial credit" 这种思路。也就是说，对很多开放式任务来说，给部分分数比简单判 0 或 1 更符合实际情况。尤其在长文本、开放回答或多步任务里，这种连续分值比绝对通过更能反映真实质量。
OpenAI 把 grader 主要分为四类：string_check、text_similarity、score_model 和 python。这四类基本上就覆盖了从最刚性的规则，到最灵活的自定义逻辑之间的主要梯度。
String check：最适合兜底的确定性判分（对应原文：String check grader）
Section titled “String check：最适合兜底的确定性判分（对应原文：String check grader）”string_check 的定位很清楚，就是做简单直接的通过/失败判断。适合答案本来就高度确定的场景，比如城市名、是非题、固定格式字段、输出中是否包含某个短语等。
它的优点是快、便宜、稳定，也最容易调试。你知道 grader 在做什么，也知道为什么一条样本过了或没过。对很多需要回归保护的任务来说，先有这种确定性检查往往是最务实的起点。
但它的问题也同样明显：非常脆。大小写、措辞变化、等价表达、浮点格式差异，都会让本来“语义上差不多”的答案被误判失败。所以 string_check 更适合做硬约束检查，而不是承担开放任务的全部评分工作。
Text similarity：当答案允许多种表达时（对应原文：Text similarity grader）
Section titled “Text similarity：当答案允许多种表达时（对应原文：Text similarity grader）”text_similarity 的位置，正好位于纯字符串匹配和模型判分之间。它适合参考答案本身是开放文本，但你仍然希望通过相似度来估计“像不像”的场景，例如专家写的一段标准回答，或一段需要覆盖核心意思的说明文。
OpenAI 文档列出了多种相似度方法，例如 fuzzy_match、BLEU、GLEU、METEOR、ROUGE，以及只在 evals 中可用的 embedding cosine。这说明它并不是一个单一算法，而是一类评分方式。
它的优势是比 string_check 更能容忍表达变化，但仍然属于结构化、可重复的确定性评分近似。缺点是它只能告诉你“接近程度”，不一定能判断答案是否真的满足任务要求。所以它很适合中间层，而不是所有任务的终点。
Score model：让模型来当 grader，但要控制边界（对应原文：Score model graders）
Section titled “Score model：让模型来当 grader，但要控制边界（对应原文：Score model graders）”当任务开始需要判断语义完整性、风格、质量、多维标准，或者输出存在很多合理表达时，score_model 才真正体现价值。它的核心思路，是用一个单独的模型来读取输入并输出一个数值分数。
这里最重要的不是“模型判分更高级”，而是它能把自然语言 rubric 直接写进 grader。你可以把“是否清晰解释原因”“是否 grounded 在给定上下文”“是否覆盖必要点”这类标准，显式交给模型评分。
但这也意味着 score_model 天生更贵、更不稳定，也更需要人工校准。它适合作为处理开放式质量判断的主力工具，但不应替代所有硬性检查。更稳妥的做法通常是：先用确定性规则兜底，再让模型 grader 评估剩余更细腻的维度。
Python grader：最后的逃生舱与高自由度扩展（对应原文：Python graders）
Section titled “Python grader：最后的逃生舱与高自由度扩展（对应原文：Python graders）”当现成 grader 类型都不够时，OpenAI 提供了 python grader。它允许你用自定义 Python 逻辑读取 sample 和 item，并返回一个浮点分数。对需要复杂规则、外部逻辑组合、或对结构化输出做细粒度分析的团队来说，这个能力非常重要。
它的本质是给评估体系留一个通用扩展点。你不再被固定模板限制，而可以把自己的业务判断逻辑写进 grader。代价当然也很明显：灵活性越高，维护成本越高，调试和复用也更依赖工程纪律。
因此，python grader 不适合一上来就滥用。更合理的顺序通常是：先确认简单 grader 是否足够；只有在标准类型无法准确表达业务规则时，再使用代码扩展。
推荐使用顺序 / 实战工作流
Section titled “推荐使用顺序 / 实战工作流”按 OpenAI 这页文档的实际用途，可以把 grader 选择顺序理解成一条从简单到复杂的路线：
- 先问任务是否可以被
string_check可靠覆盖。 - 如果答案允许多样表达，但仍有明确参考文本，再尝试
text_similarity。 - 如果需要语义判断、风格判断或多维 rubric，再上
score_model。 - 如果业务逻辑过于特殊，标准 grader 无法表达，再用
pythongrader 补齐。
这个顺序的关键，是尽量把最贵、最不稳定的判断后置。不是因为模型 grader 不好，而是因为很多任务根本没必要一开始就动用它。
适合什么团队、什么阶段
Section titled “适合什么团队、什么阶段”这页文档特别适合两类人。第一类是刚开始系统做 evals 的团队，他们往往缺的不是更多样本，而是一个清楚的“判分方法选择框架”。第二类是已经有 grader，但经常遇到误判、过度宽松或维护困难的团队，这时重新按 OpenAI 的类型边界梳理一遍，通常会更清楚哪些任务该用哪类 grader。
对 agent 团队来说，这页最重要的价值是帮助你把“打分”从模糊直觉变成一套可组合的原语。只有判分原语清楚了，后面的 datasets、eval runs、回归保护才会更稳。
原文链接与出处说明
Section titled “原文链接与出处说明”原始文档由 OpenAI Developers 提供：
本文为官方指南解读与结构整理。如需查看最新字段定义、示例 JSON 和接口说明，请直接阅读官方页面。