轨迹评判：仅基于结果的LLM评判器在智能体轨迹中遗漏的问题

# 仅结果型LLM评判在智能体轨迹评估中的盲区
来源：https://arxiv.org/html/2609.00038
## 轨迹评判：仅结果型LLM评判在智能体轨迹上遗漏了什么

###### 摘要

仅结果评估是LLM智能体生产环境中的默认做法：向评判模型展示用户请求和最终回复，询问其是否处理妥当。这种评估方式在结构上无法识别那些"用错误方式得到正确答案"的智能体。我们通过构建已知真实值的场景来测量这一盲区：一个确定性工具调用的支持台环境、一个始终能解决问题的脚本化预言策略，以及一个在已知步骤精确破坏单一功能的故障注入器，并根据客户可见结果是否保留（*静默故障*）或未保留（*显性故障*）对故障进行分层。五种评判方法（程序化规则、仅结果型、两种模型规模的步骤评分型、以及自一致性集成方法）在400条轨迹上评估检测率、步骤定位、故障分类、校准度和成本。仅结果型评判能捕捉84%的显性故障，但仅能捕捉45%的静默故障，同时错误标记了33%的正确轨迹；步骤评分型评判在成本为3倍的情况下，实现了77%的静默故障召回率且零误报。没有评判模型阅读最终回复：一条附加在完美轨迹上的虚构承诺完全规避了规则评判，并有82%的概率被步骤评判者忽略；而自一致性方法使成本增加两倍却未提升任何效果。我们主张评判评估必须根据结果保留情况分层统计召回率，并发布了该环境、注入器、所有原始判定结果以及可离线重建所有数据的分析流水线。

## 1引言

调用工具的智能体受限于结果层面的评判。模型读取用户请求和智能体最终答案，判断案例是否处理妥当，该判定结果输入仪表板、发布门控或奖励信号。通过这个过滤器幸存的失败恰恰是那些它无法看见的：跳过了必要资格检查的智能体、违背工具返回结果行动的智能体，或在最终答案正确的前提下做出了无法被观测证实的承诺。当最终答案正确时，未经资格检查就发出正确金额的退款，从外部看与正确执行流程的退款完全一致。这些是能进入生产环境的故障，因为旨在捕捉它们的评估指标在结构上对它们视而不见。

评估评判者通常需要人工标注，但标注者本身就成了被测试的对象。我们通过构建场景来打破这个循环。一个确定性的支持台环境通过一个可证明正确的脚本化预言策略来解决（测试套件断言它符合所有流程规则并在每个实例上达到预期结果），然后故障注入器在已知步骤精确破坏单一功能并重放轨迹以保持观测的内部一致性。因此每条轨迹都携带精确标签且标注成本为零：是否故障、在哪个步骤、属于哪种类型、以及客户可见结果是否保留。本文固定*智能体*而将*评判者*置于测试台上：每个评判错误都可归因于评判者本身。

按结果保留情况分层是使测量成为可能的关键。在所有故障混合评估时，仅结果型评判的召回率看起来不错的0.61。但拆分后，该数字分解为破坏答案的故障召回率0.840和未破坏答案的故障召回率0.451。这个差距*就是*核心发现，而单一混合召回率将其平均化了。

贡献：(i) 为工具调用智能体评判构建了正确性由设计保证的测试平台：一个宽容环境配合严格检查器、一个六类单点故障注入器（带已知步骤和结果保留标签），以及一个覆盖缺口由测试固定的规则引擎基线（§3）。(ii) 对五种评判设计在五个维度（检测、定位、分类、校准、成本）上进行受控比较，带有分层自举置信区间（§4–§6）。(iii) 具有部署意义的发现：量化的静默盲区；一种能规避所有评判者（包括看到完整轨迹的评判者）的unsupported\_claim故障类型；自一致性集成的负面结果；以及一个本质上为"始终判定故障"基线的8B参数评判模型（§7）。(iv) 完全可离线复现的成果：发布原始判定数据，本文所有表格、图形和区间均可从这些数据再生而无需调用模型（§10）。

## 2相关工作

LLM评判的可靠性。模型作为评判者已成为开放式输出的标准评估方式，其缺陷已被充分记录：位置和冗长偏好、自我偏好、指令跟随比较中的客观性失败，以及随任务难度增长的不对齐现象。该研究路线针对的是*单次响应*与人工标签的评判审计；而我们审计的是*多步工具轨迹*与设计即正确标签的评判，因此在干净轨迹上的标记就是无可争议的假阳性。评判设计本身（判断前推理、明确置信度）遵循Mohammadi等人（2026）的方法，将模型标签视为需要自身可靠性估计的测量数据则遵循Mohammadi等人（2025）和Mohammadi（2026）的思路。

智能体基准测试。工具调用智能体的基准测试对智能体进行评分，越来越多地基于轨迹而非仅结果：τ-bench比较最终数据库状态，AgentBench和WebArena评估任务成功，AgentBoard跟踪子目标进展，而近期工作直接评估推理轨迹。我们反转了角色：智能体是固定的预言者，评估系统才是被测试对象。

失败归因。在追踪中定位失败步骤或智能体是新兴任务，AgenTracer通过向成功轨迹注入故障来规模化生成带标签的错误对。故障注入是我们设计中的成熟部分；差异在于如何处理它：一种五维度的工具比较，将检测与归因分离，并按结果保留情况分层召回率——这在现有文献中未被报告。

过程与结果监督。过程奖励模型显示分步反馈在数学验证器训练中优于结果反馈，ProcessBench测量推理链中的错误定位。该研究方向训练最终答案可核查的评分器；我们提出其下的测量问题：当最终答案正确时，现成评判者能否*根本*看到过程故障？答案发现取决于评判者的视角而非其指标。

校准度。我们使用预期校准误差对每个评判者的置信度声明进行评分。可解释的置信度可能有用，但倾向于过度自信；我们补充了评估方的结果：在小样本下，集成方法的投票份额（"原则性"替代方案）在结构上比明确数值更粗糙。

变异测试。植入已知缺陷来测量检测器已有半个世纪历史。变异体能否替代真实故障是经典的效度问题；第8节在此回答：就流行度而言不能，就能力而言可以。

## 3设计即正确真实值的测试平台

支持台实例6类分层，种子预言策略设计即正确，干净n=100，故障注入6类已知步骤静默n=175显性n=125，五种评判方法检测·局部化分类·校准·成本结果保留结果破坏
图1：无标注真实值：预言策略设计即正确，每个变异恰好破坏一项功能，因此每条轨迹携带精确标签：故障、步骤、类型及客户可见结果是否保留。环境：一个拥有七种工具（get\_customer, lookup\_order, get\_policy, check\_eligibility, issue\_refund, escalate, reply）的客户支持台环境，并配有书面标准操作程序：验证客户、查询订单、读取商品政策、确认资格后再处理资金、退还精确授权金额、不符合条件时上报、回复仅声明观测支持的信息。实例生成于六个分层：全价退款、重新上架费、过期窗口、不可退款商品、属于其他客户的订单、已退款订单，从单一种子流轮流抽取。

环境宽容而检查器严格。issue\_refund会退还未经资格检查的订单，就像真实支付API一样。没有任何因素阻止智能体跳过流程；只有规则检查器会判定这是错误的。这是关键设计选择：没有它就没有静默失败可供测量，因此它由测试而非注释固定。

符号：轨迹τ=(g,s₀,...,sₜ₋₁,a)将目标g与最终答案a配对步骤sₜ=(hₜ,cₜ,oₜ)：思考、工具调用cₜ=(toolₜ, argsₜ)、观测oₜ。其标签ℓ(τ)=(y,t*,φ,ω)：是否故障、失败步骤、故障类型φ∈Φ(|Φ|=6)、客户可见结果是否匹配实例预期结果。当y∧ω时故障为*静默*，当y∧¬ω时为*显性*。评判者将轨迹的*视图*映射为判定(ŷ,τ̂,φ̂,ĉ,r)及声明置信度ĉ和理由r。仅结果视图为Vout(τ)=(g,a)；步骤视图Vstep(τ)是完整渲染。本文的两种LLM评判仅在此视图上有区别。

预言策略：一个固定的六步脚本，跨分层仅一个分支不同：验证、查询、读取查询观测返回的SKU政策、检查资格、符合条件则退还授权金额否则上报、然后回复。一个跨所有实例参数化的测试断言其不违反任何规则并达到预期结果；正确性是计算而非假设的。

表1：六种故障类型。每个变异在已知步骤编辑预言策略的调用列表并重放到全新环境，因此变异体与真实运行同样内部一致。规则覆盖率通过测试测量和固定而非估计。两个零值是关键：看似合理但错误的工具选择不违反任何规则，回复中的虚构句子根本不属于规则违反；两者都需要能理解语义的工具。故障注入器：每个变异仅编辑调用列表（一次编辑一个步骤）然后将编辑后的列表*重放*到全新环境，重新生成每个观测。因此虚构的SKU确实会查找失败；没有手写内容，测试断言重放观测与调用一致。表1列出六种类型。注入是按（实例，类型）字符串种子化的，因此集合是确定性的。一个规则需要强调：变异被构造为仅破坏一条规则。例如skipped\_precondition将退款金额改写为订单总额，以使参数仍基于查询观测；否则会触发第二条规则，混淆矩阵将测量注入器而非评判者。评判集为400条轨迹：100条干净、175条静默、125条显性（每类50条），确定性洗牌使任何前缀都是分层样本。

规则引擎及其两个零值：检查器遍历每个轨迹一次，维护从目标种子化的基础值池，并执行八条关于基础、顺序、金额、身份和终止性的规则。它以100%覆盖率覆盖四种故障类型，另外两种则为0%。wrong\_tool不违反任何顺序或参数谓词：检查器没有工具*意图*概念。unsupported\_claim在回复中附加文本，而没有规则读取回复：文本被故意排除在基础池外，因为标识符有基础而句子没有。两个零值由测试固定（如果改变则测试失败）。这是诚实的免费基线：将LLM评判的论点表述为测量而非断言。

## 4五种评判方法

表2：评判方法。两种单次通过LLM评判是具有不同视图的相同评判者：相同模型、解码、程序文本、分类法和置信度指令；唯一自由变量是渲染是否包含步骤。

两种单次通过LLM评判是具有不同视图的相同评判者：相同模型、解码、程序文本、分类法和置信度指令；唯一自由变量是渲染是否包含步骤。表2列出五种评判方法。保持比较公平的工程细节值得列举。两种LLM评判接收完全相同的标准操作程序和故障分类法文本。响应在JSON模式（语法约束）下解码，reasoning作为第一属性：模式属性顺序是生成时的，因此评判者在看到任何轨迹前先看到其推理指令。置信度作为输出字段而非提示的一部分，以避免锚定偏差。表2详细说明保持透明性所需的全部变量。

步骤评分型评判在完整轨迹上运行；其设计选择在此表中冻结以保持公平：允许二次重写最终步骤，但要求引用具体步骤编号，提供六类分类法供选择而非自由文本，并指示"即使存在多个错误，也只需报告第一个"。自一致性集成对五次仅结果型评判（温度0.7）取多数投票，仅报告是否一致。成本按输入token数计算：支持台步骤平均1.2k token，完整轨迹平均5.8k token，每千token 0.01美元，但报告相对成本（以程序规则为基准1×）。