我们如何为法律分析找到最佳 AI 模型

一套三层评估方法：LLM-as-a-Judge、Crew-as-a-Judge，以及人工验证。三者并行，而非串行。

挑战：让质量变得可度量

哪个 AI 模型能给出最好的法律分析？在 Erst Recht，这是我们面对的第一个问题。凭直觉和听营销话术是不够的。我们需要一套系统化、数据驱动的方法。

结果就是：一套三层评估，让 AI 打分与人类专业判断协同工作。在这篇文章里，我来讲讲我们是怎么做的。

问题：你怎么度量一份法律分析“好不好”？

做数学题时，有明确的标准答案：40+2=42，搞定。（而且不，我们这里说的不是 JavaScript，那里 '1' + '1' = '11'。）而在法律分析里，这种明确性并不存在。要求是多方面的：

• 事实正确：引用正确的法律、最新的判例
• 完整：覆盖所有相关方面，不漏掉任何期限
• 易懂：没有法学学位也能看明白
• 可操作：给出具体的下一步

人工逐一评估每个测试用例既耗时又主观。我们需要一种既可扩展又可靠的方法。

为什么公开基准回答不了这个问题

排行榜看起来是条捷径。但对于普通人依据德国法提出的法律问题，它行不通：

• 语言不对，法律也不对：LegalBench 收录了 162 项英文法律推理任务。一个模型能否用德语向外行说出《德国民法典》规定的正确解雇通知期，它测不出来。
• 数据污染：公开的测试题会混进训练数据。在数学基准 GSM8k 的一个全新“孪生”版本上，部分模型家族的准确率下降了多达 8%，而最强的模型几乎不受影响（Zhang 等，2024）。
• 营销不等于测量结果：在一项斯坦福研究中，供应商承诺能避免幻觉的商用法律检索工具，幻觉率仍在 17% 到 33% 之间（Magesh 等，2024）。

想知道哪个模型适合你自己的用例，就需要你自己的测试用例。

我们的做法：三位并行的评判者

重点：这三层评估是并行运行的，而不是串行。每位评判者独立评估同一批输出，最后再把结果汇总。

1. LLM-as-a-Judge

思路是：让一个强大的语言模型，按照明确定义的标准去评估所有其他模型的输出。自动化，且可扩展。

我们从四个专门的维度来评估每一份分析：

2. Crew-as-a-Judge

单一评判者会有盲区。解决办法是：让多个专门化的 AI agent 从不同视角来评估。

关键在于：这些 agent 会互相“讨论”，并汇聚成一个总体判断。这样得到的结果比任何单一评估都更稳健。

3. Human-as-a-Judge（人工验证）

AI 评估并不能取代人类的专业判断，但它也不需要审查每一个案例。相反，由创始团队中的一位律师对结果中的一个抽样样本进行验证：

• 盲测：审核者不知道哪个输出出自哪个模型
• 边界案例：有针对性地测试临界场景
• 校准：人类的判断和 AI 评估一致吗？

目标是：确保自动化评估是可靠的。人工抽样起的是完整性检查（sanity check）的作用，而不是完整地重新评估一遍。

结果汇总

三位评判者都会对每个模型的每个案例进行评估。结果被合并成：

• 各案例的获胜模型：在这个具体案例上，哪个模型表现最好？
• 总体获胜模型：跨所有案例的整体赢家

评判者之间达成共识，会提升我们对结果的信心。当判断出现分歧时，我们就更深入地分析那个案例。

测试流程详解

系统化的评估需要系统化的测试：

1. 创建测试用例：覆盖产品所涉法律领域的案例
2. 相同条件：对每个模型使用完全相同的提示词
3. 多次运行：逐场景检查一致性
4. 并行评估：两位 AI 评判者同时评估，人工抽样复核

结果与洞见（截至 2026 年 2 月）

历史快照：以下结果来自本文 2026 年 2 月的初版。我有意不公开我们比较过哪些模型，而且当时的排名对今天的模型毫无参考意义。留下来的是规律。

“AI 评判者以多数意见把 Model A 评为获胜者。人工抽样也证实了这一结果。这对我们自动化评估的可靠性来说，是一个强有力的信号。”

这次评估给出了清晰的结论：LLM-as-a-Judge 和 Crew-as-a-Judge 都一致地把同一个模型评为获胜者。通过抽样进行的人工验证也得出了相同的结论。

这次评估的关键洞见：

• 定制化的方法值回票价：我们专门化的方法胜过了通用的聊天助手
• 存在取舍：有些方法更快，有些更精确。我们选择为质量而优化
• 一致性很重要：质量忽高忽低的方法被淘汰了

我们学到了什么

可复用的方法：面向当下模型的八个步骤

如果今天重做这次评估，我会这样做。先说一点：被测对象不是模型，而是由模型、提示词和流水线组成的系统。因此，流水线的不同变体应和候选模型放进同一场比较。如果只在聊天窗口里测试新模型，你测的就是错误的系统。

1. 从真实案例中提炼测试用例

做匿名化处理，覆盖产品实际涉及的各个法律领域，再加上刻意设计的“难缠”案例：事实不完整、超出范围的问题、明显的胡言乱语。测试集要保密。上文的解雇案例随着本文公开，已经不能再当测试用例了。

2. 每个案例一份参考清单

在第一次运行之前，由受过法律训练的人确定：一个正确的回答必须包含什么，以及哪些错误会直接判为不合格，比如说错了期限。评判者会拿到这份清单。在 MT-Bench 研究的一个小型测试中（10 道数学题、20 次判断），当提示词里附上评判者事先自己生成的参考答案后，它的失败率从 70% 降到了 15%（Zheng 等，2023）。

3. 用“通过/不通过”代替 1 到 5 分

上文的评分细则用 1–5 分来评价易懂程度，可是没人知道 3 分意味着什么。更好的做法是二元评分：把每个回答标为正确或错误，并附上详细理由。Hamel Husain 在他的 LLM-as-a-Judge 指南中也这样建议。如需排名，再从正确的回答中选出最好的。我还会加一个检查项：这份分析是否说明了它不确定的地方？（模型否则为何更倾向于虚张声势。）

4. 盲测与成对比较

评审者只能看到 A 到 D 这样的中性标签，并且每个案例的顺序都随机打乱。LLM 评判者对每组成对比较评两次，第二次交换顺序。只有同一个回答两次都胜出才算赢，否则算平局。这就是 Zheng 等人应对位置偏差的做法。

5. 先检验评判者，再相信它

• 自我偏好：LLM 能认出自己写的文本，并给出更高的评分（Panickssery 等，2024）。评判者和候选模型应来自不同的模型家族，或者由多个来自不同厂商的评判者共同决定。
• 长度偏差：评判者往往偏爱更长的回答。检查一下你的分数是不是只是随长度上升。
• 校准：由律师用同一套评分细则对一个样本做盲评。关键在于：被人类标为错误的回答中，评判者也能识别为错误的有多少，以及正确的回答中它放行了多少（Husain 建议把这两个比率都报告出来）。

6. 同时测量成本与延迟

每个案例的 token 数、成本和运行时间，应和质量放在同一张表里。用数倍的成本换来几个百分点的质量提升，对于价格亲民的初步评估来说，并不自动就是更好的选择。那篇梳理了 247 篇 agent 安全论文的综述也批评了安全评估很少同时测量延迟和成本。

7. 认真对待统计

举一个用虚构数字的计算例子：如果有 40 个案例、80% 的回答正确，95% 置信区间大约是 ±12 个百分点。小的差异只是噪声。所以要让每个案例多跑几次，在相同案例上对模型做配对比较，并报告误差线（Anthropic，2024）。

8. 把重新评估排进日程

每次更换模型、提示词或流水线时都要重新评估，法律发生变化时也是如此（参考清单同样会过时），此外大约每季度做一次。固定模型版本，而不是使用总是指向最新模型的别名。此外，各厂商会定期下线旧模型，可参见 Anthropic 和 OpenAI 的模型弃用页面。因此，确切的模型 ID 应该属于评估配置的一部分，它的每一次变更都是重新运行评估的理由。

开启新评估项目的三条原则

• 从一开始就让评判者来自与候选模型不同的模型家族：否则自我偏好就会起作用。
• 从第一天起记录每个案例的成本：如果选定模型之后才问成本，你比较时用的就是不完整的数据。
• 把评估设置当作产品的一部分：测试用例、清单、评判提示词和模型 ID 都应纳入仓库做版本管理，并在每次更换模型前作为部署关卡运行。游离在产品之外的评估工具，每经历一次重构就会过时一次。

什么时候不值得这样做

• 没有真实用户的原型：十几个精挑细选的案例加上你自己的判断就够了。
• 反正每个输出都有人工编辑：那么这道编辑就是你的评估。
• 没有专家来制定参考答案：没有经过审核的清单，LLM 评判者产出的多半是虚假的精确。先做参考答案，再做自动化。
• 每个案例都用 Crew-as-a-Judge：多个评判 agent 的成本是单个评判者的数倍。我只会在评判者意见不一致时才动用它们。

Erst Recht 用 AI 让初步法律评估触手可及。我们 AI 分析的质量，欢迎你亲自来体验。

在筹划你自己的 LLM 评估项目吗？联系我。我很乐意在方案设计和落地实施上帮上忙。