Evals：为 Skill 建立回归集与评分规则（Judge/Rubric）

为什么没有 Evals 的 Skill 迟早失控

你一旦开始优化提示词、换模型、加工具调用，就会发生两件事：

• 某些 case 变好了
• 某些 case 变坏了（你不知道）

Evals 的价值是把这件事显式化：每次变更都跑回归，知道哪里变好/变坏。

最小评测集（Golden Set）怎么做

不要一上来就做 1000 条。建议从 10 条开始：

• 5 条常见场景（happy path）
• 3 条边界场景（极短输入、极长输入、空字段）
• 2 条失败场景（工具超时、权限不足）

每条 case 至少包含：

• input（调用参数）
• context（必要的工具输出或引用数据）
• expected（你期望的结构或要点）

一个 JSONL 格式示例：

{"id":"case_001","input":{"repo":"org/repo","pull_number":1},"expected":{"must_have":["summary","risks"],"risk_severity":"medium"}}

Rubric（评分规则）要写成“可执行的检查点”

Rubric 不要写“更清晰、更有用”。要写成可检查项：

• 格式正确：是否满足输出 schema
• 覆盖完整：是否包含必须字段/小节
• 事实一致：是否与工具输出冲突
• 风险识别：是否指出关键风险点
• 简洁性：是否在字数预算内

可以用一个简单的分数模型：

• 0 分：缺失必需字段或严重事实错误
• 1 分：格式对，但遗漏关键信息
• 2 分：满足要求且无明显错误

Judge 模型：用于“辅助评分”，不是代替标准

Judge 的正确用法是：

• 先做硬校验：schema/字段/顺序/字数
• 再做软评分：可读性、覆盖度、风险点质量

如果你完全依赖 Judge，评测会随 Judge 变化而漂移。

动手做：最小自动评测流水线（框架无关）

你可以用任何语言/脚本实现，流程建议固定为：

1. 对每个 case 生成输出
2. 运行硬校验（schema/regex/必填字段）
3. 运行软评分（rubric + judge）
4. 输出报告：通过率、失败 case 列表、差异对比

输出报告建议结构化，便于 CI 展示：

{
  "pass_rate": 0.9,
  "failed": ["case_007","case_009"],
  "metrics": { "schema_ok": 0.95, "fact_conflict": 0.02 }
}

工程化清单

• Golden set 从小做起，覆盖 happy + edge + failure
• Rubric 可检查、可量化
• 硬校验先行（schema/字段），软评分后置
• 每次变更都跑回归，输出结构化报告

常见坑

• 评测集太大起步：做不动就会废弃
• Rubric 太主观：评测不稳定
• 只测“回答像不像”：不测格式与事实一致

下一篇：可观测性：Tracing/日志/指标。