使用Claude自动化评测设计与爬山算法（12分钟阅读）

# 使用Claude自动化评估设计与爬山优化 来源：https://claude.dev/blog/automating-eval-design-and-hillclimbing/ 评估能够为你的应用或技能在特定任务上的表现提供量化参考。但设计评估体系，并在不产生自我欺骗的前提下提升其表现，绝非易事。我们已在claude-api技能（https://github.com/anthropics/skills/tree/main/skills/claude-api）中为此提供了完整指引。 通过该技能，你可以运行`/claude-api build-eval`在代码库内构建评估体系，运行`/claude-api hillclimb`对应用进行渐进式优化——每次仅调整一个变量，同时通过留出的样本集来防止过拟合。 本文将首先阐述优秀评估设计与爬山优化的核心原则，随后展示Claude Code如何运用`claude-api`技能实践这些原则，并以具体命令示例作为结语。 ## 评估设计 设计精良的评估体系通常包含以下核心要素（图1）： 1. **评估任务需镜像生产环境**：抽样应选取你所关注的"生产环境"任务——即你所测试的能力或应用的实际应用场景。有时人们会选择易生成或易评分的任务，但关键在于确保任务分布能反映你*真正*关注的内容。 2. **表现应随模型能力与思考强度提升**：更强大的模型与更高的计算投入通常应在评估中取得更好成绩。若未呈现此趋势，往往是模糊任务或评分器校准不当所致。 3. **前沿模型应保有可提升空间**：最强模型在最高算力配置下的得分应明显低于100%，否则将难以可靠评估变更对性能的影响。关键要确保这种差距并非由不可能或模糊的任务导致——常见标志是某个任务在所有评估运行中均失败，无论重复多少次。优质任务应满足：两位领域专家能给出相同结论，且评分器所检查的所有要求都已在任务描述中明确。 4. **低运行方差**：高方差常源于设计欠佳、定义模糊的任务，或是对相同输出产生不同判定的评分器。方差也可能隐藏在配置细节中（例如算力投入不一致），或受环境状态影响（早期试验遗留的文件、git记录可能直接泄露答案）。 针对小、中、大三种模型在低/中/高算力配置下的评估结果示意图。编号标注展示四大要素：表现随模型能力与算力提升，最高分低于满分，误差区间保持狭窄。**图1** 优质评估的四大要素 ### 对抗性抽样 模型能力分布呈参差状。若因当前模型表现不佳而选样，你只是在抽样模型能力曲面的低谷区域（图2）。这可能导致评估最终衡量的是该模型的失败特征，而非任务本身对你的应用的真实难度或价值。 两幅图表分别展示任务空间内的能力分布：当前模型呈锯齿曲线，下一代模型为更平滑的上方曲线。左图中，基于当前模型失败案例的抽样仅触及低谷；右图中，人类标注的困难任务则广泛分布于高低谷，并包含若干应排除的极端案例。**图2** 对抗性抽样 选择困难案例的标准应是人类专家判定其困难：实用的测试标准是在收录任务前能说明其难点所在。同时应纳入源于生产流量、缺陷报告或工单的具体失败案例。但需避免盲目依赖用户流量——用户常尝试预期可行的路径，因此完全基于用户流量的任务分布可能偏于简单。 ## /CLAUDE-API BUILD-EVAL claude-api技能中的`build-eval`命令将这些原则转化为引导式工作流。在Claude Code中运行`/claude-api build-eval`时，Claude将通过访谈构建评估体系，并在关键节点暂停请求确认。 ### 样本设计 Claude将按以下优先级协助你抽样构建评估集： 1. 生产对话记录（首先询问数据保留与敏感信息相关事宜） 2. 缺陷报告与支持工单 3. 你手动编写的5-10个案例 4. 基于代码库合成的案例 该技能优先采用生产流量，但也能基于你提供的少量真实样本生成合成数据。技能会指示Claude生成简洁页面展示所有输入样本，待你确认后方继续。例如下图展示了一个邮件路由应用的样本集供用户审阅（图3）。 技能为收件箱路由评估生成的审阅页面，包含24个输入样本，标注如"计费"、"简单"、"模糊"等标签。Claude在对话中询问这些输入是否具有代表性，用户回复确认。**图3** 由技能生成的输入样本审阅页面 ### 验证评分器 确定输入后，Claude将根据应用输出形式推荐最合适的评分方式： - **程序化验证**：若输出形式受限，采用基于代码的检查（精确匹配、固定标签集、符合模式的JSON、测试用例通过） - **LLM-as-judge**：当输出开放且有多种有效答案但质量标准清晰时默认采用此方式。第二个模型将阅读输入、输出及以可验证断言（非1-5分制）编写的评分标准，返回分数与推理过程。若有基线对比，评分器将随机顺序阅读两个输出（不告知基线身份）并择优选择。评分模型需与被测模型不同。 Claude将对少量案例评分，并询问你是否会对任何案例给出不同评分（图4）。通常而言，在信任评估器前审阅抽样的评分记录至关重要——评分错误是最常见的评估配置失误。 验证评分器后，技能将告知评估集规模（案例数×重复次数×模型数）及预估时长，运行基线测试并输出带置信区间的分数。你将获得：案例集、评分器、执行器、每个案例的JSON行记录与完整日志，以及列出各案例得分与日志链接的简洁页面。如需更多信息（如图表），可直接要求Claude在页面旁生成。默认情况下，这些附加页面为本地静态文件，不加载网络资源。 技能为收件箱路由评估生成的结果页面：基线在24个案例中平均正确率0.681，随后是各案例得分表格与重复运行链接。点击链接可查看该案例的原始JSON追踪记录。**图4** 结果页面示意图，显示各输入的评分建议。 ### 诊断检查 在上述基线运行期间，Claude将执行多项检查： - **评分器一致性**：对同一输出运行两次评分器，验证判定是否一致 - **基础设施稳定性**：检测超时、API错误与截断输出，确保基础设施噪音不被误判为模型方差 - **提升空间评估**：若基线已得分95%以上，技能将提醒用户优化目标应侧重成本或延迟而非质量 ## 爬山优化 获得可靠的评估体系后，即可着手提升应用表现。爬山优化是调整算力投入或提示词等参数的有效方式，可实现成本与性能的平衡。选择优化方向的通用原则： - **快速迭代**：优化目标应易于低成本（时间、资源、人力）调整。许多内部实践和客户将优化重点放在文本层面（如提示词与技能），这些易于修改与回滚。相反，运行时框架的开放式修改可能涉及大量代码变更。 - **结果归因**：评估分数的变化应可直接归因于优化目标。例如，多个成功案例聚焦于技能触发优化，其评估指标（技能触发率）与被调整的技能描述直接相关。 - **目标明确**：常见失败模式是泛泛要求"提升性能"而忽视评估体系的提升空间。接近饱和的评估或定义模糊的优化范围（如开放式更新运行时框架）更易陷入停滞。跨场景的强目标通常是成本优化：即使评估已饱和，也可要求Claude在保持性能的前提下探索降本方案（https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform）。 ### 过拟合问题 即使是精心设计的评估也难以完全匹配生产环境的真实任务分布。因此，评估"过拟合"是常见问题，表现为系统在评估中表现优于实际生产。 评估体系可能通过多种方式"泄漏"到运行时框架（包含提示词、工具与调用循环的代码层）。例如，某评估任务受益于OCR功能，但生产任务很少需要此功能，评估框架可能为此在应用中添加OCR工具，仅提升基准分数而无实际生产效益。更普遍的是，爬山优化可能添加针对特定评估案例边缘情况的框架补丁——这些改进虽提升评估分数，却无法转化为生产效益（图5）。 左侧展示基准测试特征，右侧为对应的框架添加项：需要OCR的任务添加OCR工具，位于/app目录的任务添加"始终执行cd /app，运行pytest"指令，特定表述添加定制提示词，已发现的失败案例各对应一个补丁。虚线箭头标注明显泄漏：公开仓库的答案使框架可直接获取参考解。**图5** 框架过拟合的常见原因 应对措施包括： - **数据分割**：使用训练集（爬山优化可读取）与测试集（不可见）。若训练集分数提升而测试集停滞，即为典型过拟合信号。 - **禁止将失败案例直接粘贴至提示词**：若爬山优化需分析失败日志，切勿将失败内容原样置入提示词。 - **保持答案结构不可及**：模型可能通过直接查找评估答案进行"奖励欺骗"。 如后文所述，claude-api技能已内置这些防护原则。 ## /CLAUDE-API HILLCLIMB claude-api技能的hillclimb命令将这些原则转化为引导式工作流。在Claude Code中运行`/claude-api hillclimb`时，Claude将迭代优化以提升指定评估表现。你可选择允许其调整的范围： - 系统提示词 - 技能或指令文件 - 工具描述 - 模型选择、算力等级等API参数 - 运行时框架代码 启动前，Claude将询问优化目标（如提升性能，或保持性能的前提下降低成本），随后将评估集随机分为测试集与训练集。选择成本目标时，会综合考虑常见成本驱动因素（https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform），包括提示词缓存、提示词与模型的兼容性审核，以及模型与算力配置选择。 首轮运行前，Claude将验证评估噪音（分数随机波动范围）是否小于可采取行动的最小改进阈值；若未达标，会建议增加重复次数或案例数。 每轮优化中，Claude会阅读上一轮训练集日志并提出单个补丁。目标是每轮改进幅度能超越评估噪音：从根本上修复失败行为（如重写问题段落或添加缺失规则），而非简单调整措辞。随后运行补丁版评估。此时Claude会执行检查：若训练集提升但测试集停滞，则怀疑过拟合并回滚补丁；若出现性能回退则回滚；若训练集与测试集同步提升则保留补丁（图6）。 爬山优化循环：被修改对象（如提示词）作用于固定模型与框架，在留出的测试集与训练集上评分。分析器仅读取训练集失败案例，每轮提出一个差异修改；当训练集与测试集均提升时保留修改，仅训练集提升或任一分数下降时回滚。**图6** 爬山优化器的工作流程 当分数连续两轮停滞，Claude会审阅剩余的训练集失败案例并按原因分类。若单次修复预期改进低于评估噪音，也会提前执行此步骤，建议增加重复次数或案例数，避免进行无法测量的微小调整。此步骤可发现模糊评估案例、框架错误或运行方差问题。 仅保留有效失败案例进入后续优化轮次。 优化完成后，Claude将保留测试集上表现最优的代码版本，并输出带置信区间的基线对比测试结果（图7）。若提升在噪音范围内，会明确说明并建议不合并。 爬山优化后的收件箱路由结果页面，对比三个变体在训练集与测试集上的表现。定义各队列并添加平局规则的变体v1以0.875分被标注为最佳；添加两个示例的变体v2因训练集提升而测试集停滞被回滚。**图7** 爬山优化报告示意图 ## 实践案例 ### 降本优化案例 我们在内部客户支持基准测试（https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform）中运行`/claude-api hillclimb`，目标是在保持性能的同时降低成本。该基准包含44个工单，30个用于搜索评估，14个留作测试。初始采用Opus 4.8模型默认（高）算力配置，搜索工单决策准确率74.4%，单票成本4.6美分。 爬山优化首先审核提示词，移除强制工具调用流程、临时笔记步骤及矛盾规则。随后尝试Opus 5.5模型低算力配置，不仅以87.8%准确率超越基线，更将成本降至1.9美分/票，仅为初始成本的43%。 部分成本节约源自Opus 5.5的定价策略（https://claude.dev/blog/getting-the-most-out-of-opus-5-5/）：输入输出token成本较Opus 4.8降低20%，缓存读取成本降低60%。因Opus 5.5已达标，优化重点随即转向...