启动微调前先搭评测工具链：用黄金集、逐失败模式评分器和校准…

在开始微调、把 traces 转成评测集或校准 judge 时，先建好 eval/ harness，让它同时充当训练数据来源和 checkpoint 晋级门禁。

适用场景

解决思路

1. 把评测工具链（eval harness）当作 Phase 0 门禁：在写训练配置前先建立它；没有评测工具链就不开始微调。
2. 不要把评测工具链当作训练结束后的附带产物；把它当作数据整理引擎：构建黄金集（goldens）的已标注轨迹（traces）也用于训练数据，但必须保留显式留出集（holdout）。
3. 收集轨迹：有生产/agent spans 就用它们；如果还没有，就用合成任务。
4. 做错误分析：对 ≥100 条轨迹做开放式编码（open coding），先阅读并用自己的话标记失败，不要预先设固定分类法。
5. 做主轴编码（axial coding）：把开放式编码标签收敛成 4–8 个命名的失败桶（failure buckets）；少于 4 个说明编码太浅，多于 8 个需要合并。
6. 对单一失败面任务（例如 strict-schema extraction）允许落到 1–2 个失败桶，但要在同一个评分器内放置逐字段子指标（per-field sub-metrics）；不要无证据地人为拆分。
7. 如果还没有轨迹，使用基于维度的合成生成：枚举重要轴（任务类型、难度、边界情况、人物设定等），对交叉乘积采样；不要依赖自由生成提示词，因为它会聚集在最容易写的样本上。
8. 把黄金集像代码一样版本化：提交 eval/goldens.jsonl，在评审中 diff，按发布打标签；它同时作为 CI 回归套件。
9. 按频率 × 严重度 × 价值（frequency × severity × value）给失败桶排优先级。
10. 让已标注轨迹进入数据集整理（dataset curation），但保留显式留出集；eval/goldens.jsonl 中每个 ID 都必须按 ID 排除在训练数据之外。
11. 训练。
12. 在 checkpoint 上重新运行同一套评测工具链，不要换成不同且更宽松的评测工具链。
13. 用漂移检测（drift detection）把新的生产失败模式反馈到错误分析：回到第 2 步重新打开错误分析。
14. 为错误分析得到的每个失败桶建一个评分器（grader），而不是为整个评测集建一个总分评分器；单一混合分数（blended score）会掩盖哪个桶退化。
15. 优先用确定性评分器：regex、schema validation 或 execution checks，成本更低、可复现且无需校准。
16. 只对真正主观的标准使用 LLM 裁判（LLM-judge），例如语气、忠实度、哪个回答更好，这些无法用确定性检查表达。
17. 使用二值通过/失败（binary pass/fail），而不是李克特量表（Likert）：1–5 或 1–10 更难校准且更难一致应用；折叠为通过/失败。
18. 对漂移套件（drift-suite）的 MMLU 式评分，优先用对数概率（logprob）而不是生成再抽取（generate-and-extract）；紧 token budget 下，生成再抽取对会先输出前言（preamble）的模型解析脆弱，会把格式遵从与所测知识混淆。四种评分器形态的模板和该评分说明见 references/grader-templates.md。
19. 任何路由到 LLM 裁判的桶，在其判定能超出探索用途之前都必须校准；这是硬性前置条件，不是可选项。
20. 如果没有桶路由到裁判，显式声明 N/A：全确定性评测工具链没有可校准对象，不要留空不处理。
21. 标注 ≥100 条 items，并拆成 train/dev/sealed test；sealed test 只报告一次，之后不得再触碰。
22. 报告 TPR 和 TNR，而不是单一混合准确率；在偏斜集合上，裁判可能靠总说 pass 达到 90%。
23. 把裁判固定到固定模型快照（model snapshot）；裁判模型变化时重新校准，并且无论是否变化都每季度校准一次。
24. 确保裁判来自与被测模型不同的模型家族（model family）。
25. 如果裁判未达到约定的 TPR/TNR 门槛，就以 advisory-only 方式发布：只向人工评审发 flags，绝不能 gate promotion。完整协议、偏差校正和重新校准清单见 references/judge-calibration.md。
26. 在 Phase 1（方法选择）开始前，用完整评测工具链（黄金集加能力漂移套件）跑未修改的基座模型（base model）；这是后续每个 checkpoint 的比较基准。
27. 把 eval/baseline-<model>.json 作为 gate token；没有 baseline 文件，checkpoint-promotion 就没有比较基础，“看起来更好”不是发现。
28. 遵守目录契约：eval/ 下放 goldens.jsonl（带标签轨迹 + 合成黄金集，版本化）；graders/ 下每个失败桶一个模块，例如 schema_compliance.py、exact_match.py、rubric_judge.py；drift-suite.yaml（冻结 benchmarks + 200-500 条领域相邻 items）；baseline-<model>.json（gate token：评测工具链 + 漂移套件 vs 基座模型）。
29. 把每次运行的评测工具链输出写到 runs/<run-id>/results.json，每个 checkpoint 一份。
30. 让 eval/ 跨运行持久化并位于 runs/ 之外，作为固定测量标尺，而不是运行产物；runs/ 可丢弃，eval/ 不可丢弃。绝不要让运行脚本写入 eval/。
31. 所有逐轨迹 results.json（包括 Phase 0 baseline）都放在 runs/<run-id>/results.json，绝不放在 eval/runs/...；要求放到后者的指令是错的，以本契约为准。
32. Phase 0 退出前，在 finetuning-method-selection 前确认：≥100 条轨迹已开放式编码；4–8 个失败桶（合成黄金集且单失败面任务时有 N/A 下限；之后失败桶数量来自 post-baseline 错误分析）。
33. 确认 eval/goldens.jsonl 已提交并版本化。
34. 确认每个桶一个评分器，确定性优先。
35. 确认裁判已校准：TPR/TNR、快照固定、不同家族（没有桶路由到 LLM 裁判时 N/A，并显式说明）。
36. 确认 eval/drift-suite.yaml 已冻结。
37. 确认 eval/baseline-<model>.json 已写入。
38. 如果六项（或已声明的 N/A）缺任何一项，不算 Phase 0 完成；/finetune 会在运行前检查 baseline 文件。
39. 与相关技能衔接：finetuning-method-selection 先路由到这里；dataset-curation 把这些轨迹格式化成训练行；trace-to-training-data 把已评分轨迹转成训练样本；checkpoint-promotion 消费 baseline-<model>.json，并在每个候选 checkpoint 上重跑本评测工具链。
40. 通用评测指导（仪表盘、A/B 测试、非微调评测工具链）使用 llm-application-dev 插件的 llm-evaluation 技能；本技能只覆盖微调耦合：黄金集兼作训练数据，baseline gate checkpoint。

适用边界 · 注意事项

• 不适用于非微调的通用评测场景：仪表盘、A/B 测试、非微调评测工具链应使用 llm-application-dev 插件的 llm-evaluation 技能。
• 当所有桶都走确定性评分器、没有任何桶路由到 LLM 裁判时，跳过裁判校准，但必须显式声明 N/A。
• 没有微调计划，或没有愿意标注 ≥100 条示例的标注者/可标注数据时，不能把该评测工具链当作 Phase 0 完成门禁。