自我生成的评估指标：从盲点中进化出的评估器

# 自我演化的评估指标：从盲点中涌现的评估器
来源：https://arxiv.org/html/2608.18744  
崔延伟 王光辉 林志豪 何培阳  
致谢：通讯作者：[email protected]  
单位：[3pt] AWS生成式AI创新中心

###### 摘要

智能体在可靠的自动评估指标下进步迅速，缺乏此类指标则会停滞不前。最需要这些指标的应用——包括报告生成——恰恰是人们尚不知如何评估的领域。评估指标能否自我演化？定义何为“好答案”固然困难，但指出答案中的问题却相对容易。因此，我们演化出的指标是一个小型Python运算符池，每个运算符负责标记特定类型的缺陷候选答案，或选择弃权并参与投票。直接让模型生成运算符效果有限：183个候选运算符仅表现出96种不同行为，仅来自巨大参数空间中的狭窄区域。EvalCEGAR方案借鉴了程序验证中的反例引导抽象精化技术。它将运算符池视为一种抽象表示，搜索“冲突案例”——即两个被运算符评分一致但一正一误的答案。这对反例本身（而非提示词）构成了生成请求，当反例挫败所有生成尝试时，系统会扩展运算符的可读取接口范围，而非简单重新采样。在MBPP+和HumanEval+基准测试中（其隐藏单元测试提供精确的真值标准），该系统生成了一个55行的运算符，在428个未见任务上弥合了15.4%的改进空间（+0.0065，p=0.0010），且仅使用我们最佳手写运算符1/3的标记量。在未曾接触的基准测试上，该运算符在三分之一的标记案例中达到与人工算子完全相同的效果。八次实验中有六次成功生成此类运算符，且所有生成的算子在样本外任务上均有效；而将我们15个手写运算符组合使用反而会降低准确率。使用相同信息的LLM裁判在近似不重叠的候选集上能达到同等效果，但需持续为每个候选支付模型调用成本，而运算符无需额外开销。

## 1 引言

自改进系统需要评估指标优先于策略优化。在可靠自动评估指标的支持下，LLM智能体能快速提升：自精炼、自调试和反思循环都依赖于区分答案优劣的信号。缺乏指标则进展停滞，现有替代方案存在缺陷：参考文本重叠法在语义层面存在局限，LLM裁判则带有属于裁判自身而非答案本身的立场偏好、冗余表达和自我偏好偏差。这对开放式输出（如报告或规划）的影响尤为严重——既无标准答案，也缺乏公认的质量评判标准。

本文探究评估指标能否自动演化。我们演化的并非单一评分，而是一个运算符池：小型Python函数，每个函数读取任务与候选答案，然后标记特定缺陷、标记通过（无缺陷）或弃权。通过投票机制，运算符池形成评估标准：当足够多的成员标记某答案时，该答案即被否决。这种形式基于一种在缺乏参考答案时依然成立的非对称性：评价答案优劣需要标准，而指出错误通常不需要。每个运算符表达一个具体反对意见，可被独立阅读、运行和证伪，池的有效性是可测量的特性而非预设假设——每个成员都必须通过下游决策验证才能加入。

#### 初步实验揭示的问题。

我们首先尝试了直观循环：请求模型生成运算符，若通过验证则保留，如此重复。该循环在两方面陷入停滞，我们将其视为核心问题：*障碍1：运算符空间巨大，模型生成的“评估运算符”仅来自空间中狭窄固定区域。*重新采样无法突破该区域——在狭窄接口上对295个运算符进行评分未能产生任何新发现。*障碍2：生成的运算符行为重复，且大多被拒绝。*五次运行产生183个标记所有内容的运算符，仅实现96种不同标记集合。拒绝信号同样无法提供有效反馈：循环仅知候选失败，不知其未能区分何种差异。

#### 我们的方法。

我们借鉴了程序验证的严谨方法：反例引导抽象精化仅在具体反例证明当前抽象过于粗糙时进行精细化。运算符池即这种抽象，将每个候选答案映射为“签名”——运算符池返回的判定向量。共享相同签名的答案对指标而言不可区分，因此共享签名但真实答案不同的对偶，证明指标无法表达该区分。EvalCEGAR将这对反例作为规范提交模型。每次接纳新运算符都会重新划分签名空间，使下一个规范必然不同：由目标而非采样器提供多样性压力。当反例击败所有生成尝试时，系统扩展运算符可读取的接口范围，而非重新采样——因为接口无法观察的区分无论采样多少次都不可达。运算符被接纳的条件是它提升指标支持的决策质量，而非覆盖更多已知缺陷，且被接纳的运算符参与投票。

#### 为何在代码任务上验证。

研究动机源于缺乏可用指标的领域，但所有数据均来自拥有精确评估标准的领域：MBPP+和HumanEval+的Python编程问题，其隐藏单元测试套件直接判定正确性。无法在未知真相的领域评估生成指标的方法，因此我们在真相已知但被隐藏的场景构建系统。运算符按设计具有领域特异性，新领域将继承循环框架而非该运算符池。可迁移的特性虽狭窄但可验证：运算符永不读取标准答案，四道检查确保其无法重构标准答案，标准答案标签仅在训练集引入，且代价可接受：75个训练任务中仅10个同时包含通过可视检查的正确和错误候选，已足够生成可迁移的运算符。

#### 主要贡献。

- • EvalCEGAR：通过自身盲点演化评估指标的循环系统，生成规范即其发现的反例。
- • 样本外有效的运算符：八次实验中六次生成的运算符在428个未见任务上均有效；最佳运算符仅55行Python代码，在三分之一标记量下达到我们最佳手写运算符的效果，而使用相同信息的LLM裁判在几乎不重叠的候选集上达到同等效果。
- • 各机制价值分析：循环内相同信息下的消融实验：仅接纳问题就将接纳数从0提升至1，狭窄接口在336次尝试中未产生任何接纳。
- • 精确解构组合问题：评估循环可组合的230万子集显示，其使用的组合目标排名低于空间第5百分位数，而未调优的类加权目标可达第91百分位数以上。

## 2 相关工作

#### 开放式输出的自动评估。

两种替代方案都在不改变结构的前提下进行了优化：学习型指标用模型自身相似度判断替代重叠计数，裁判框架向裁判提供明确评判标准，并通过分解粗糙标准和过滤冗余信息进行改进。输出仍是单一标量值，读者无法分离其组成部分。EvalCEGAR生成不同形态的产物：由小型、可执行、可独立证伪的“反对意见”组成的运算符池。运算符池可增删单个成员而无需重训练，这使得该形式的指标具备可演化性。我们与两类方法对比：裁判在终点指标上打平但在候选筛选上存在分歧，因此主张在于可验证指标的生成方式，而非超越标量指标。

#### LLM驱动的程序搜索与CEGAR。

FunSearch针对给定评估器演化程序，自动化智能体设计在给定基准上搜索智能体代码。我们的方法则相反：以评估器本身作为产物，没有固定适应度函数，设计问题从候选变异方式转向候选被保留前必须证明的内容。最接近的是通过LLM生成可执行检查并组合的方法，由紧凑的Python验证器联合满足近似标注目标，或基于模型生成的是否问题进行无权重投票。这些方法搜索预测标签的检查项，而我们搜索证明当前检查项不足的反例，并基于部署决策进行接纳。我们以此作为基线进行实验。CEGAR是验证技术，据我们所知将其迁移至指标合成属创新。

#### 多样性与测试生成。

质量-多样性搜索通过维持显式行为存档防止种群退化；我们的多样性压力来自每次接纳后重新划分目标空间，第6节测量了这种机制的局限性。这也不是测试生成：基于属性的测试需要可供证伪的属性，差异测试需要第二个实现，而我们的场景两者皆无。

## 3 预备知识

#### 任务与数据。

每个任务来自EvalPlus分发的MBPP+或HumanEval+的Python编程问题，其隐藏测试套件作为精确标准答案。它标注循环训练和接纳的样本，除评分脚本外无其他组件读取它。题目也展示少量示例调用及其预期结果，求解器同样可见；我们称其为“可视检查”，不属于保留信息。我们选取150个MBPP+任务，75个用于运行循环，75个保留，另将228个MBPP+剩余任务和164个HumanEval+任务中的125个加入保留集。HumanEval+不打印断言，其可视检查由文档示例合成；我们保留参考解答能通过至少一个此类检查的125个任务。结果报告在428个未见任务上，分为“MBPP+保留集”（75个）、“MBPP+扩展集”（228个）和“HumanEval+”（125个）——唯一来自不同任务分布的组别。

#### 选择准确率。

对每个任务t，我们采样多个模型解答，令V(t)为通过可视检查的解答（含重复）：即部署系统可能接受的候选，因此重要的是通过检查后仍存在的缺陷。指标需从中筛选。它从V(t)中移除标记的候选，留下保留集K(t)；从K(t)均匀抽取一个样本，若标记所有内容则从V(t)抽取。选择准确率是该样本正确的概率在任务间取平均值；Δ始终表示相对于无标记指标的改进值。

#### 可判定性与改进空间。

任务仅在V(t)同时包含正确和错误样本时可判定；在其他任务上，无论指标如何，样本正确性已确定。428个保留任务中仅58个在我们的采样深度下可判定，因此428个任务的选择准确率从无标记的0.7170到完美运算符的0.7593。Δ绝对值较小，故也报告其占可达范围的比例（改进空间）。该终点指标由召回主导：被标记的正确样本仅离开保留集，而被捕获的错误样本会改变剩余可抽样集合。

#### 对比基线。

构建循环前我们手写了15个运算符：十个对候选语法树进行静态检查，五个执行候选代码。它们是循环的初始池，组合使用作为人工基线。我们最强的单个手写算子是贯穿全文的“比较器”，标记行为与任务其他样本多数意见相悖的候选。第二个基线是LLM裁判，在完全模拟一级运算符信息条件下对每个候选提问，在两种模型、两种提示的四种配置下进行测试。

#### 生成运算符的模型。

一个冻结模型（Claude Opus 4.7，未微调且无梯度更新）生成运算符源码，在8轮中每轮调用47-48次（上限60次）。其运算符判定的错误候选来自较弱模型（Llama 3.1 8B Instruct和Claude Haiku 4.5，第6节深度采样中加入Amazon Nova Micro和Mistral 7B Instruct），因此生成错误代码的模型从未编写评判它的运算符。EvalCEGAR输出的运算符池及其投票机制是纯Python实现，无需推理时模型调用。

#### 确保循环诚实性。

四道检查在验证前拒绝生成的运算符，每项阻断一种可能导致标准答案意外重构的方式：仅从语法判断而不运行、按键错误生成器特定常量、根据提示关键词分支、通过文本匹配标记而在其他位置执行候选。这四道检查均未在15个手写运算符上触发，因此不禁止常规检测器。所有Δ均通过尺寸匹配的随机排列零假设检验：对每个任务，运算符自身的标记数从该任务样本中重抽样固定，从而控制标记数量并随机化标记对象。