评分方式
eval_752 使用三种评分方式。每种在成本、确定性和灵活性上有不同的权衡。
快速对比
程序化评分
基于规则的评分，在本地运行。不需要 API 调用。
工作原理:
- 精确匹配: 提取答案与参考答案比对（不区分大小写，忽略空白字符）
- 集合匹配 / F1: 多选题——比对答案集合并计算部分得分
- 正则匹配: 需要匹配特定模式的自由文本回答
- 数值容差: 数学题中
3.14和3.141都应该通过
适用场景: 只要「正确答案」可以被精确定义。选择题基准、数学题、事实查找。这是默认且最快的评分路径。
权衡: 无法处理细微差异。如果模型用意外的格式给出了正确答案，程序化评分可能会判为错误。
LLM 裁判
使用另一个 LLM 来评估回答是否满足给定的评判标准。
工作原理:
- eval_752 将问题、模型回答和评判标准发送给裁判 LLM
- 裁判返回二元评分：
1（通过）或0（不通过） - 评判标准可以是参考答案、一组准则，或两者兼有
裁判 prompt 设计为严格模式——只输出 1 或 0，不输出解释。这使结果更易于汇总和比较。
适用场景: 没有单一正确字符串的自由文本任务——摘要、解释、翻译、创意写作。也适用于「正确」意味着「满足这些标准」而非「与答案完全一致」的情况。
权衡:
- 有成本: 每个被评判的题目都会对裁判 Provider 发起一次 API 调用
- 不确定: 同一回答在不同次评测中可能得到不同分数（实际中，写得好的评判标准给出一致结果）
- 裁判偏见: 裁判模型自身存在偏见。换一个裁判模型可能会改变分数
你可以为裁判配置与被评测模型不同的 Provider。例如使用 GPT-4o 做裁判，同时评测其他模型。
Arena——对战比较
将两个模型的回答并排比较。裁判选出更好的或判为平局。
工作原理:
- 两个模型收到相同的 prompt
- 裁判 LLM 看到两个回答（匿名为「回答 A」和「回答 B」）
- 裁判选择
[[A]]、[[B]]或[[TIE]] - 经过多次比较，分数汇总为 Bradley-Terry（Elo 风格）排名
适用场景: 关心相对质量而非绝对正确性的场景。「模型 A 写邮件比模型 B 好吗？」无法用精确匹配回答——但对战比较可以。
权衡:
- 贵: 每次比较需要两个模型的回答加一次裁判调用——正常评测的 3 倍成本
- 需要量: 几次比较没有统计意义。需要足够的题目来收紧置信区间
- 位置偏见: 裁判可能偏向先出现的回答。Bradley-Terry 聚合会在多题目后缓解这个问题
即将推出
Arena 模式正在积极开发中。对战评分管道已存在，但完整的排行榜 UI 尚未可用。
我应该用哪种方式？
- 有单一正确答案？ → 程序化评分
- 正在跨模型比较相同 prompt？ → LLM 裁判
- 需要两个模型正面对决？ → Arena (对战)
对大多数刚上手的用户：程序化评分 + 选择题数据集 是比较 Provider 最快、最便宜、最确定的方式。
关于在启动 Run 时如何配置评分，请参见 运行评测。