> 原始仓库：harveyai/harvey-labs > 上榜数据：+87 stars today | 语言：Python | 分类：AI 法律基准
基准测试的盲区
AI 基准测试多如牛毛。MMLU 测知识广度，SWE-bench 测代码能力，MATH 测数学推理。但有一个领域长期缺乏靠谱的基准：法律工作。
原因很简单。法律工作不是”回答问题”或”写代码”，而是在一堆真实文档里找问题、做交叉引用、按规则产出结构化文件。这种任务的复杂性不在知识本身，而在流程和环境。
Harvey AI 刚刚开源了 Legal Agent Benchmark（LAB），专门测量 LLM 代理在真实法律工作上的能力。
LAB 是什么
LAB 由两部分组成：
1. 任务数据集：包含代理指令、相关文档、评分标准（rubrics） 2. 执行框架：运行代理、评估结果、生成报告的工具
示例任务是一个 M&A（并购）数据室作业。这个任务的设计很真实：
– 代理拿到一个数据室（一堆并购相关文档） – 代理需要按指令完成特定任务（比如审查合同条款、识别风险、生成报告） – 代理可以使用工具（检索、计算、文件操作） – 评估按 rubric 打分，不是简单的对错
为什么法律工作难测
法律工作和编程工作有三个根本差异，导致 SWE-bench 那套方法不适用：
第一，输入不是代码，是文档。 编程任务的输入是函数签名和测试用例，结构化程度高。法律任务的输入是几十页的合同、尽调报告、监管文件，结构化程度低。代理需要先理解文档，才能开始工作。
第二，输出不是对错，是质量光谱。 编程任务有测试套件，通过就是通过。法律任务的输出是一份报告或一份文件，质量是连续光谱。LAB 用 rubric（评分细则）来量化，每个 rubric 项是”通过/不通过”，但整体质量是多个 rubric 项的加权。
第三，过程不是线性的。 编程任务通常是”读题→写代码→跑测试”。法律任务可能需要反复检索文档、交叉引用、修改之前的判断。代理的轨迹（trajectory）比代码任务复杂得多。
LAB 的评估方法
LAB 用的是 all-pass rubric scoring：一个任务有 N 个 rubric 项，代理必须全部通过才算完成。这比”按比例打分”更严格——90% 通过率在法律语境下可能意味着 10% 的条款没审查到，这是不可接受的。
另外，LAB 用 LLM 作为裁判（LLM judge）来评估代理输出。这带来一个问题：LLM judge 本身的可靠性如何？LAB 的文档里专门讨论了 LLM judge 的行为分析，包括它在不同 rubric 项上的一致性和偏差。
执行框架的设计
LAB 的执行框架（harness）支持：
– 多模型适配器：可以接入不同的 LLM（GPT-4、Claude、Gemini 等） – 工具调用：代理可以检索文档、操作文件、做计算 – 报告生成：每次运行生成详细报告，包括每个 rubric 项的通过情况 – 批量扫描（sweep）：可以一次跑多个任务、多个模型，生成对比报告
这个设计让 LAB 不只是一个测试集，而是一个评估平台。你可以用它做模型对比、能力追踪、回归测试。
对 AI 法律应用的启示
LAB 的开源有几个重要信号：
第一，法律 AI 从”能不能用”进入”好不好用”阶段。 2023 年大家问的是”AI 能做法律工作吗”，2025 年问的是”AI 做得有多好”。LAB 给了”多好”一个可量化的答案。
第二，代理能力比模型能力更重要。 LAB 测的不是单个 LLM 的法律知识，而是 LLM 代理在法律工作流中的表现。代理架构（工具调用、文档检索、多步推理）的差距可能比模型本身的差距更大。
第三，真实环境是关键。 LAB 的任务设计基于真实法律场景（M&A 数据室），不是人造的法律考试题。这意味着基准结果更接近实际应用效果，而不是学术测试分数。
一个值得思考的问题
LAB 的 rubric 是由 Harvey 的法律专家设计的。这意味着：基准测试的质量取决于设计者的领域知识。
如果另一个团队想扩展 LAB（比如增加诉讼任务、合规任务），他们需要相应的法律专家。这和 SWE-bench 不同——SWE-bench 的测试用例来自真实的 GitHub PR，任何程序员都能贡献。
法律基准的门槛天然更高。这会不会限制它的社区贡献速度？还是说，法律领域的特殊性恰恰需要这种高门槛来保证质量？
Harvey 的选择是：开源框架和任务集，但保持专家审核。这是一个平衡开放和质量的设计。
—
项目地址：github.com/harveyai/harvey-labs 公告：harvey.ai/blog/introducing-harveys-legal-agent-benchmark