用 Harvey 设计法律智能体的高效验证器

LangChain Labs 与 Harvey 联合研究：衡量并设计用于法律智能体的高效验证器。阅读原文在 LangChain 博客。

作者： @Vtrivedy10 (LangChain)、@jakebroekhuizen (LangChain)、@hwchase17 (LangChain)、@nikogrupen (Harvey)、@gabepereyra (Harvey)、@spencerpoff (Harvey)、@ItsJulioPereyra (Harvey)

核心摘要： 验证器可能成为大规模运行智能体评估和强化学习后训练的成本瓶颈。我们发现，通过批量处理验证器并使用开源模型，可以将验证器成本降低一个数量级。调整验证器的提示词可以进一步针对特定行为进行优化。

本月早些时候，Harvey 发布了 LAB，一个用于评估智能体在复杂法律工作中表现的公开基准。初步结果显示，当前智能体在法律领域的表现远未饱和。

我们与 Harvey 合作，共同探讨了以下问题：

如何更高效地验证法律智能体工作结果的正确性？

为什么这很重要？法律工作对智能体来说是一个特别困难的领域，因为它涉及多份文档，需要处理大量上下文，要求具备专业知识，并且有严格的标准来确保输出可被接受。

LAB 基准的验证方式类似于人类复核员。数据集中的每项任务都有一组标准，只有全部通过才算完成。每个标准都由一个独立的 LLM 作为评判者，使用验证器模型进行评估。对于每个标准，验证器会获取智能体输出和需要衡量的匹配标准（match_criteria）。它针对每个标准输出通过/不通过的 verdict。许多任务有超过 50 个独立标准需要验证。每个标准都调用一次 LLM API，如果使用前沿模型大规模运行，成本会非常高昂。

能否实现更高效的验证？

使用前沿验证器的成本给团队带来了一个实际性问题：无论是运行法律智能体评估，还是使用强化学习训练法律智能体。

如何在保持接近前沿性能的同时，最大程度降低验证器成本？

我们研究了两种不同的更高效验证方法：

• 使用更少的 token
• 使用更便宜的 token

我们探索的第一种方法：使用更少的 token。为了使用更少的 token，我们建议批量运行验证器。也就是说，不是为每个标准独立调用一次 LLM，而是让验证器在单次批量调用中一次性评估整个评估表。

• 逐标准评分： 为每个评估要求单独运行一次评判调用。
• 批量评分： 为任务运行一次评判调用，并要求评判者一次性标记所有评估要求。

我们探索的第二种方法：使用更便宜的 token。为了使用更便宜的 token，我们可以在验证过程中测试更便宜的模型。我们以 Opus 4.7 逐标准模式作为参考，并将 GPT-5.5、Sonnet 4.6、DeepSeek v4 Flash 和 Claude Haiku 4.5 分别在逐标准和批量评分模式下进行比较。

不同验证器设计下的效率对比实验

为了运行验证器实验，我们首先需要生成一组供验证器评估的输出。为了创建这些输出，我们让一个智能体（由 Kimi K2.6 驱动）在 40 个公开的 LAB 任务上运行，涉及以下业务领域：企业并购、税务、新兴公司/风险投资，以及信托与遗产。

这 40 个任务共包含 2,348 个独立的评估表标准——每个标准由验证器评分（通过/不通过）。我们首先使用 Opus-4.7 对所有标准进行评分，作为基线。然后以此基线为参照，测试 GPT-5.5、Sonnet 4.6、Haiku 4.5 和 DeepSeek-V4-Flash 作为其他验证器选项时的表现。每次运行验证器都会产生相同的 2,348 个标准评分（通过/不通过），我们可以用这些数据来研究它们之间的差异。

对于每次验证器运行，我们测量了：

• 一致性： 与 Opus 逐标准标签匹配的频率。
• 误通过： 将 Opus 判定为失败的标准判定为通过的次数。
• 误拒绝： 将 Opus 判定为通过的标准判定为失败的次数。
• 成本： 运行 40 个任务验证器所观察到的 token 成本。

我们特别关注误通过。在现实场景中，一个失败的标准可以被升级进行进一步审查。这通常比在本应失败的标准上让其通过要好，尤其是在法律领域。

验证，与大多数智能体系统设计一样，是性能、成本和时间之间的权衡。逐标准验证给评判者提供了更窄的决策窗口，但需要更多的调用次数。批量验证更便宜、更快，但评判者必须一次性跟踪整个评估表。

下图显示了成本与标签漂移之间的关系。x 轴是每 1,000 个评估表标准的验证器成本。y 轴是与 Opus 逐标准标签的不一致率，即 100% - 一致性。越靠左下方越好。

一些要点：

• 总体而言，批量模式下的匹配率低于逐标准模式。但对于相同模型，运行批量的成本低一个数量级，因为它节省了重复的输入 token 成本。
• 即使是 GPT-5.5 和 Opus 这样的前沿模型在标签上也存在分歧——它们的匹配率仅为 95.7%。这意味着某些数据点可能没有充分明确，导致模型无法像专家那样一致地应用它们。
• DeepSeek 作为验证器，无论是逐标准运行还是批量运行，都是 Opus 的一个强近似。它的运行成本低了三个数量级，这使得它成为需要大规模运行验证的大数据和训练领域的理想候选。
• Haiku 比 Opus 和 Sonnet 更便宜，但宽容度高出太多。其误通过率在逐标准模式下为 48.4%，批量模式下为 34.7%，这对于法律验证来说是错误的失败模式。

后训练中的成本节省

验证器不仅用于评估。它们也用于后训练，并且由于每个任务需要多次 rollout，验证成本会进一步放大。LLM 作为评判者的系统将任务评估表转化为奖励信号，而更便宜的奖励信号使得运行更多实验、审查更多 rollout 以及更快迭代变得切实可行。

对成本进行简要推算显示，DeepSeek 在大规模运行时可以比前沿验证器便宜 60-1000 倍。这在那些不容易通过程序验证、需要一定程度的 LLM 作为评判者来产生奖励信号的领域尤其重要。

通过追踪记录调整验证器行为

在之前的实验中，我们对每个模型和每种验证器架构（逐标准 vs 批量）固定了提示词。我们测试的另一个杠杆是有针对性的提示词调整。

为了测试提示词调整的效果，我们基于之前 DeepSeek 与 Opus 的对比结果运行了一个自动研究循环。我们分析了 DeepSeek 出现差异的原因和方式，并在多次运行中调整了提示词。我们告诉它要优化误通过率。

DeepSeek 使用默认提示词时出现一些错误的一个关键原因是：DeepSeek 过于倾向于在答案与要求相关但并未满足所有实质性部分时就将标准判定为通过。最终的提示词让验证器更明确地将每个标准的每个部分分解为清单，并指示它在呈现的信息不完全清晰时要保持谨慎。这使得 DeepSeek 的误通过率在两种评分模式下都降低了：逐标准模式从 10.7% 降至 9.5%，批量模式从 15.6% 降至 14.2%。

从追踪记录中挖掘数据，并通过提示词进行有针对性的行为蒸馏，仍然是改进验证器和智能体的有效策略。

为法律领域构建更好的智能体与更高效的验证系统

验证器是构建世界级法律智能体的拼图之一。开源模型验证器提供了成本与性能的权衡，使得团队能够以低几个数量级的成本运行评估和执行强化学习后训练，并且通常使得尝试本身变得可行。我们还发现，像批量验证这样的简单方法效果相当不错，并能再降低一个数量级的成本。

开源模型还允许公司为其最关键领域微调定制验证器。许多工作默认认为前沿闭源模型是蒸馏的黄金标准，但本研究中 Opus、GPT-5.5 和 Sonnet 在约 4-5% 的标签上存在分歧。我们认为还需要更多工作来进一步挑战这一观念。

我们很高兴能与 Harvey 合作，推动在大规模验证系统方面的研究。在未来的工作中，我们期待研究微调验证器的影响，以及它们对后训练和大规模运行评估的作用。