来源信息

  • 文档类型：阅读笔记 · 整理日期 2026-10-07
  • 原文：《Automating eval design and hillclimbing》 · 作者 Lance Martin · 发布于 claude.dev · 发布日期 2026-09-28
  • 原文地址：https://claude.dev/blog/automating-eval-design-and-hillclimbing/
  • 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。

阅读范围

  • 全文，含评估原则、build-eval、爬坡与过拟合、hillclimb、两项案例和起步。

先证明评估可信

任务要代表实际用途，难度有可通过的提升空间，重复运行的噪声低；更强模型或更多思考未改善时，应检查任务和评分器。只挑某模型当前失败的案例，可能测到其弱点指纹；真实流量也可能偏向容易任务。

build-eval 按真实记录、故障报告、手写样例和合成输入构建案例，再让人确认。封闭输出优先程序检查；开放输出可用独立模型按可检查标准评分，比较时随机顺序。先核对评分样本，再跑基线、重复次数与置信区间，保留逐例轨迹。评分一致性、超时、截断与饱和度都需诊断。

优化循环与泄漏

爬坡适合修改便宜、作用可归因且目标清楚的对象。每轮一项变更，只读训练失败；留出集用于检查泛化，退化或仅训练提升则回退。停滞时分类剩余失败，区分真实错误、评分缺陷与噪声，不无限换词。

不能把案例答案或失败原文塞进通用提示，答案须结构性隔离。留出数据即使不供模型阅读，反复用它选版本仍可能产生选择偏差；最终效果宜另做独立检验，这是整理者补充判断。

案例与适用限制

2026-09-28 原文的客服案例为 44 张工单，30 张用于搜索、14 张留出；API 技能案例通过补齐功能、修类型表和排查评分矛盾改善。两者表明应同时审视系统与评估，不是所有任务都能复制其成本或得分增益。部分配图为示意，不能当实测曲线。

起步章节介绍两个技能命令；本文未更新、调用、改提示或运行评估。

游戏开发应用建议

以下为整理者建议，非原文实测，也不表示已经实施。

NPC 决策评估应覆盖日常生产、战斗打断、资源不足与存档恢复，同时包含不应行动的情形。硬规则用状态断言；体验质量用清楚量表和人工审阅，避免单一总分掩盖严重故障。

分离场景与随机种子，清理运行残留，限制优化过程能读哪些案例。一次只改一个可归因因素，记录各类成功率、费用、延迟及未运行项。若系统“变好”只是学会识别固定种子或评分措辞，应视为警报，而不是玩法能力提升。

可先用少量真实失败建立基线，再扩样降低不确定性。预算不够时明确证据不足，不能用更多优化轮次替代可信评估。

小结

先校准任务和评分器，再做可归因改进；留出、证据与噪声判断决定分数是否值得相信。

参考来源

相关笔记