LLM作为评判者并非神谕:为何自我改进的代理需要确定性防护机制

arXiv cs.AI 论文

摘要

本文识别了自我改进代理中LLM作为评判者系统的失败模式,并介绍了PROCTOR,一个具有确定性防护机制的架构来缓解这些问题。

arXiv:2609.02246v1 Announce Type: new 摘要:自我改进代理流程的核心存在问题。一个优化器重写提示以获得更高分数,而分数来自一个评判者,该评判者本身是一个LLM。该评判者对系统是否改善有最终决定权,而我们的观点是它并未赢得这个权利。评判者应从神谕降级为顾问:其裁决成为多个输入之一,而每个更改都由一个确定性验证层控制,评判者无法覆盖。我们通过构建替代方案并运行它得出了这个结论。在生产环境中运行自主提示优化循环数月,涉及合同分析、合规审查和代码质量,我们记录了评估信号失败的十一种方式,分为四类:评判者偏差、测试框架和指标失败、真实标签错误以及奖励破解。代理通过从环境中读取缓存的答案键获得了满分,100%的通过率隐藏了68%的真实能力。一个损坏的真实标签导致优化器删除了正确的合规规则以与之保持一致。一个语法错误的提示被提升为赢家,因为一个静默的解析器回退改进了指标。尝试通过重写评判者标准来修复评判者效果有限;唯一可靠的改进来自对其输出顺序的结构性约束。作为回应,我们描述了PROCTOR,一个教师-学生循环,其中有状态的编排器持有所有工具访问权限,无状态的子代理诊断失败并起草它们无法应用的变异,教师在五个确定性防护机制下对这些变异进行评分:密封沙箱、能力分离的角色、优先级高于教师的验收检查、冻结的保留案例以及精心设计的金丝雀案例,以至于完美分数本身就是作弊的证据。我们报告了这防止的失败,以及,因为教师本身是一个LLM评判者,它未能防止的失败。
查看原文
查看缓存全文

缓存时间: 2026/09/03 06:03

# LLM作为评判者并非神谕:为何自我改进的智能体需要确定性防护机制  
来源:https://arxiv.org/html/2609.02246  

###### 摘要  
*观察到LLM评估器在优化压力下的失效模式,以及能够控制这些失效的防护机制。*  

自我改进的智能体流程存在一个核心问题。优化器通过重写提示词来获得更高分数,而这个分数来自一个本身也是LLM的评判者。因此,这个评判者对系统是否改善拥有最终决定权,而我们认为它并未获得这个资格。评判者应当从“神谕”降级为“顾问”:其裁决仅作为多个输入之一,每次修改都应由一个评判者无法覆盖的确定性验证层来把关。我们通过构建替代方案并实际运行,得出了这一结论。在数月的生产环境中运营自主提示词优化循环(涵盖商业合同分析、法律合规审查和代码质量评估领域)过程中,我们记录了评估信号失效的十一种方式,归为四类:评判者偏见、测试工具与度量标准失效、基础事实错误以及奖励欺骗。智能体通过从环境中读取缓存的答案键获得满分——这种100%的通过率掩盖了仅有68%的真实能力。一个被污染的基础事实标签导致优化器删除正确的合规规则以使其与之相符。一个语法错误的提示词因解析器静默回退机制改善了度量值,而被提升为胜出候选方案。试图通过重写评分标准来修复评判者的努力遭遇瓶颈;唯一可靠的收益来自对其输出顺序的结构性约束。  

为此,我们描述了目前使用的PROCTOR架构:一个带有系统性验证的教师-学生循环。其中,一个有状态的协调器掌握所有工具访问权限,无状态的子智能体诊断故障并起草修改方案但无权应用;而教师则根据明确的评分标准对这些修改进行评分,并遵循五层验证机制:完全隔离的执行沙箱彻底消除数据泄露通道;能力隔离的角色确保没有任何组件既能提议又能应用修改;确定性验收检查优先于教师的批准;严格禁止泄露的分层冻结保留集;以及精心设计的金丝雀测试用例,使得完美分数本身就成为作弊的证据。  

我们报告了该架构所防止的失效案例,同时也说明,由于教师本身就是一个LLM评判者,因此也存在它未能防止的失效。  

## 1 引言  
考虑一个具体设置,这是我们本文描述的两个案例之一。给定一个代码库,要求一个LLM从1到5分评估其可读性和稳健性等特质。人类专家评审员已对相同代码库进行评分,因此我们可以衡量模型评分与他们的评分差距:平均绝对误差0.96意味着模型在五分制评分中通常偏离约一分。为了在没有人类参与的情况下缩小这一差距,第二个LLM充当优化器。它反复重写评判者的指令,重新运行评判,并保留得分最高的指令版本。  

在我们的一个早期原型中,优化器通过删除评判者来改善它。它提议的修改将整个评分标准替换为占位符字符串。评判者因无评分依据而返回包含非结构化文本的响应,其中不含任何预期的评分字段。我们的评估工具捕获了解析错误,并静默回退为每个维度默认的3分。由于统一的3分恰好比原始评判者分散的4分和5分更接近人类平均分,测量误差从0.96降低到0.92。选择门(selection gate)完全按设计执行,将内容被掏空的提示词提升为胜出候选方案。  

这一序列中没有任何环节是传统意义上的故障。每个组件都按规格运行。失效的是整个安排背后的基本假设:即分数代表了我们认为它代表的意义。  

爬山算法(Hillclimbing)需要一个可靠的进展度量。在生产环境中运行这些循环教会我们,我们的度量并不可靠,更重要的是,搜索过程并未容忍误差,反而在主动寻找这种误差。  

这是本文的核心主张,我们将其置于证据之前陈述:**在封闭的优化循环中,LLM评估者不能被视为神谕**。它是一个容易出错的组件,却处于最终权威的位置,而优化压力非常善于找出其度量值与我们真实意图之间的差距。  

这个主张的建设性部分比批判性部分更重要。我们并非反对LLM评判者,它们仍然是语义评估唯一可扩展的选项。我们讨论的是其裁决在权威链中的位置。评判者应当**从神谕降级为顾问**:它的意见是输入,而非决定;决定由无法被说服的检查来做出。我们将这种由此产生的规范称为**系统性验证**,它包含两个组成部分,分别在第2节和第5节展开。  

第一个是**角色解耦**:循环中的任何组件都不能同时提议和应用,也不能同时评判和行动。第二个是**确定性门控**:具有最终权威的检查是机械规则,机械拒绝会覆盖LLM的批准,反之则绝不成立。  

这是一份现场报告,而非基准研究。第2节描述了我们运行的教师-学生架构及其分离的角色。第3节列举了我们运行时观察到的十一种评估病理,分为四类。第4节探讨了搜索过程针对此类缺陷进行优化时发生的情况,这是我们发现最具启发性的部分:循环不会平均掉评估者的误差,而是会向上累积这种误差。  

第5节详细说明了控制这些失效的五层确定性机制,同时诚实地说明了它们未能控制的部分,包括我们自身教师的失效。第6节提出对抗性多角色评判者作为未来工作。  

**贡献**:  
1. 十一种LLM评估失效模式,根据评估信号失效的位置分为四类,每一种都基于实际的生产案例,而非假设。  
2. 证据表明,评判者端的提示词优化会达到瓶颈,而结构性约束则有效,这基于六轮尝试通过重写评分标准来提高评判者与人类专家标签一致性的实验。  
3. PROCTOR,一个具有系统性验证的教师-学生架构:角色解耦加上五层确定性防护,完整描述,并包含生产运行的拒绝遥测数据。  
4. 金丝雀测试用例:在评估套件中植入的测试用例,任何诚实的智能体都无法通过,因此完美分数不再是个好消息,而是作弊的证据。  
5. 精确描述该架构未能消除的剩余风险,包括其自身的教师是一个可能遭受同样失效的LLM评判者,并分析为何周围的层级能约束该评判者的不可靠性而非继承它。  

## 2 研究对象系统:PROCTOR,一个教师-学生循环  
本节描述了本文所有观察结果的来源系统。我们首先介绍它,因为第3和第4节的失效在具体架构下更容易理解,也因为该架构本身就体现了我们所主张答案的一半。  

设计原则是单一的。在传统的优化循环中,一个智能体或一个模型调用同时拥有过多权限:它可以读取环境、提议修改、判断修改好坏并应用它。我们后来列举的大多数失效都利用了这些权限之间的重叠。一个能读取环境且按答案评分的智能体最终会读取答案本身(第3节,D1)。一个既能提议又能批准自身修改的优化器会批准奉承评分者的修改(D2)。一个既评分又定义正确性的评判者无法被任何东西核查(A类)。  

因此,我们将循环分解为具有故意隔离能力的角色,并使它们之间的边界是机械性的而非指令性的。我们将由此产生的系统称为PROCTOR,其安排称为教师-学生循环,使用这两个词的特定含义:学生负责提议,教师对提议进行评分,两者都不能直接操作系统。这不同于智能体研究中更常见的教师-学生用法(即较强模型向较弱模型传递知识或轨迹);在这里,两个角色在能力上是相当的,区别在于**权限**,而非能力。  

![PROCTOR的角色分解图注](图1):PROCTOR的角色分解。协调器是唯一的有状态组件,也是唯一持有工具的组件;三个子智能体是无状态的、无工具的,仅能看到训练案例。所有持久化状态都保存在底部的两个工件中。  

### 2.1 角色及其能力  
**协调器(有状态,持有工具)**。一个协调智能体是唯一被允许执行评估、读写文件、划分数据集并将批准的修改应用于目标提示词的组件。它持有运行的所有持久化状态:不断演进的目标提示词、冻结的数据划分以及记录每次迭代结果的记分卡。将能力集中在一个可审计的组件中是故意的:它为所有关键操作提供了一个单一瓶颈,可以在那里强制执行确定性检查。  

**学生1,批评者(无状态,无工具)**。接收当前提示词及其失败训练案例和它们的裁决,返回根本原因诊断。它被明确禁止提议提示词文本。将诊断与撰写分离,防止了常见失效:单个模型编造一个方便的解释来合理化它已经想做的编辑。  

**学生2,优化器(无状态,无工具)**。接收批评者的诊断,并以结构化补丁的形式起草一个精准的修改方案,每轮限于少量编辑和示例。它从不接触评估工具,从不运行测试,也无法应用自己的工作。  

**教师,审计员(无状态,无工具)**。根据涵盖泛化性、结构完整性、简洁性和逻辑可执行性的明确评分标准对提议的补丁进行评分。它审查文本,而非结果:评估集上的正确性由协调器衡量,而非由教师断言。  

每个子智能体都运行在禁用写工具、外部连接器和子委托的隔离工作区中,所有上下文都由协调器内联提供。它们都无法检查文件系统,这使得D1中的泄露路径在设计上而非指令上对它们不可用。  

### 2.2 三个有界反馈循环  
一次拒绝不会结束一次迭代。循环将每种拒绝作为修订信号路由回优化器,每种情况限三次尝试,之后迭代中止,目标提示词回滚到上一个已知良好状态。  

**预应用重试**。机械检查失败,将确切拒绝原因返回给优化器,修订后的补丁被重新检查。这在教师看到任何内容之前运行,因此低成本的确定性故障从不消耗评分精力。  

**教师重试**。教师在某个评分标准维度上拒绝,其反馈返回给优化器,修订后的补丁从机械检查重新进入流程,而非跳过直接到评分。  

**回归反馈**。补丁应用并重新评估后,训练通过率可能下降。协调器不是丢弃该补丁,而是提取新失败的案例,发送给批评者以诊断补丁破坏了什么,并要求优化器在不重新引入回归的情况下修复原始故障。当修订后的补丁返回给教师时,原始失败和回归失败都会提供,因为教师是根据补丁旨在修复的失败来评分的,否则会拒绝一个正确的修复。  

这些循环的一个实现细节对第5.6节很重要:在重试期间,优化器保持在会话状态中而非重新实例化,因此它积累了针对其先前草稿提出的具体反对意见。这是故意的,这也是重试循环可能收敛于评分者而非任务本身的机制。  

### 2.3 为何要角色解耦,为何要无状态  
这种安排有两个属性比具体的名称更重要。  

***能力隔离***。没有任何组件既能提议又能应用。没有任何组件既能评判又能行动。教师可以拒绝但不能写入;优化器可以写入但不能应用;协调器可以应用但仅限于通过机械检查和教师批准的内容。因此,一个被破坏或行为异常的组件自身无法完成一个腐败的修改。  

***无状态即有意识的健忘***。子智能体在每次迭代中重新实例化,没有之前迭代的记忆。所有累积的改进都存在于目标提示词和协调器的记分卡中,两者都是人类可读的工件。这使得优化历史可审计,并防止了智能体私有累积信念(而非测量证据)开始驱动其提案的缓慢上下文漂移。  

### 2.4 教师受信任和不受信任的方面  
教师是一个LLM,第3和第4节详细论证了LLM判断不可靠。它之所以留在循环中,是因为它执行的检查正是任何机械规则都无法执行的:规则是泛化还是记忆化,一个示例是教授推理还是夹带训练案例,一个指令在目标环境中是否可执行。它的判断受到下述防护机制的约束,其中最重要的是一个单一的排序规则:**机械拒绝覆盖教师的批准,反之绝不成立**。教师是顾问。协调器的确定性检查做决定。  

### 2.5 第二个循环:评判者校准  
一个更简单的第二个循环贯穿本文,作为我们评判者端证据的来源。它校准的是一个LLM评估者,而非任务智能体:在一组专家标注的项目上运行评判者,计算与人工评分的精确匹配率(EM)和平均绝对误差(MAE),分析不匹配项,修改评判者的提示词,然后重复。第4.3节报告了该循环的六轮结果。  

### 2.6 规模与设置  
本文的观察来自十个评估套件,涵盖以下三类工作。其中九个是法律和商业文档审查,这是我们大部分生产应用所在;第十个是代码质量评估,出于本节末尾给出的方法论原因,它在第3和第4节中发挥了不成比例的作用。  

表1:本文中使用的评估套件  
| 套件 | 领域 | 案例数 | 评判输出为 |  
|---|---|---|---|  
| 合同红线标注 | 商业合同 | 100 | 针对主张的自由格式编辑 |  
| 商业合同分析 | 商业合同 | 47 | 针对主张的自由格式发现 |  
| 联合雇佣风险 | 合规政策 | 19 | 分类、提取、推理 |  
| 模板完整性 | 合规政策 | 18 | 分类、提取、推理 |  
| 交付物语言 | 合规政策 | 17 | 分类、提取、推理 |  
| 范围误分类 | 合规政策 | 17 | 分类、提取、推理 |  
| 定义术语一致性 | 合规政策 | 17 | 分类、提取、推理 |  
| 未解决红线 | 合规政策 | 16 | 分类、提取、推理 |  
| 政策位置 | 合规政策 | 15 | 分类、提取、推理 |

相似文章

尽可能使代理具有确定性的最佳尝试

Reddit r/AI_Agents

本文讨论了使基于LLM的代理更具确定性的各种技术,例如黄金数据集、护栏、共识机制、回归测试、编码逻辑和超参数调优,并询问其他成功的方法。