均分相近不代表判决一样：Jev 与九家语言模型的 ContractNLI 对照
做 agent 或 harness 选型时，最常见的一句话是：「这几家均分差不多，挑便宜的就行。」同一份预印本——Same Scores, Different Decisions: Evaluating JEV and Language Models for Legal Document Understanding——用 ContractNLI 把这句话拆开了：均分相近，单个判决可以完全不同；平均正确率接近，跨请求配置仍保持正确的目标数可以差一截。[1]
站内已经写过 Jev 怎么接到 Claude Code：它不是聊天模型，而是结构化决策层——提交 state 与一组带类型的 questions，返回带概率的结构化答案，不生成自然语言助手消息。[2] 本篇换一个切口：当决策对象是合同上的多条假设时，评测该怎么读，选型清单该长什么样。 一句话边界：本文不教法律实务，也不把「小面板上的 All-12」写成「Jev 全面更稳」；论文自己写明，小样本不足以建立一般稳定性优势。[1]
为什么值得单独写一篇？因为 agent 回路里大量失败，并不是「离线榜单低了两个点」，而是：同一条业务判断，换了可见上下文、输出个数或字段顺序之后，标签翻了；或者模型反复给出同一个错答案，监控却只看「一致性很高」。ContractNLI 上的对照，正好把这两种失败模式钉成可复现的数字。
任务长什么样：一份合同，多条判决
ContractNLI（Koreeda & Manning, 2021）把合同理解收成文档级自然语言推理：给定一份合同与一组假设，模型对每条假设给出 E / C / N（entailment / contradiction / not mentioned）。官方测试集是 123 份合同、2091 条判决（968 蕴含、220 矛盾、903 未提及）。[1][3] 证据跨度抽取不在本评测范围内；每条预测都对照已有标注，没有新的人工标注，也没有用模型当裁判。
为什么这件事对 agent 有用？因为真实回路里很少只问一次：同一份文档上，你会并行问「是否保密」「能否拷贝」「终止后义务还剩什么」。这些判决可以一起请求，也可以拆开请求；金标准不变，请求包装变了。若你只看一次联合请求的 accuracy，就看不见「包装一变，哪几条翻了」。论文开篇也点了同一困难：聚合准确率会掩盖哪些判决变了；反复同意也不足以证明正确——模型可以每次都返回错误标签。[1]
论文对照的是 Jev 1.13.0 与九家语言模型：Qwen3.5-4B / 9B、Gemini 3.5 Flash-Lite、Gemini 3.1 Pro Preview、GPT-5.6 Luna / Terra、GPT-6 Astra、Claude Sonnet 5、Claude Haiku 4.5。[1] Jev 把合同放进共享 state，每条假设做成原生 Choice；生成式模型走语义对齐的分类指令，返回 JSON 标签图。基线一次请求 17 条标签；无效响应计入分母并算错——这不是「剔掉失败再报高分」的评测习惯，也更接近 agent 里「本轮没产出合法决策」的真实体验。
三个研究问题贯穿全文，读博客时可以对着记：
- RQ1：成本、时延与准确率之间，Jev 与对照模型的权衡是什么？
- RQ2：更高的准确率，是否意味着更多判决在重复请求条件下仍然正确？
- RQ3：可见假设、请求输出或输出顺序变化时，哪些单个判决会翻？
可复现的评测设计：条件 A–D 在拆什么
若你只想抄一套能在自己业务上复用的评测骨架，这一节比「谁分最高」更重要。
基线怎么跑
基线对每份合同一次联合请求全部 17 条标签。有效响应必须恰好包含所请求的 ID，且每条是三个允许标签之一。Accuracy 覆盖所有意图判决；无效算错。同时报告 Macro-F1 与有效响应覆盖率。生成额度耗尽、没产出最终标签的，仍算该配置失败。[1]
成本与时延和质量共用同一批请求，包括失败尝试。托管 API 按公开单价或供应商账单计；本地 Qwen 用「每 GPU 小时 2 美元」的租金等价把墙钟换算成每合同成本——这是对观测推理时间的估值，不是实测账单，也不声称云端吞吐。[1] 时延是客户端端到端中位数（含准备、建连、网络、服务侧处理、校验），同一客户机、每模型单飞、无自动重试。
稳定性面板：30 锚点 × 4 条件 × 3 重复
稳定性面板从测试集里预选 30 个锚点（每份合同一条目标假设），种子 20260922，与标签和模型预测无关。每个锚点跑 4 种条件 × 3 次重复，共 12 次回答；全员各跑 360 次稳定性请求。面板是准确率评测的子集，因此是对重叠合同的互补分析，而不是另一套无关数据。[1]
四个条件保持合同与金标准不变，只改「看得见什么」和「要输出什么」：
| 条件 | 可见假设 | 请求输出 | 主要在测什么 |
|---|---|---|---|
| A | 只有锚点 | 只要锚点标签 | 单目标、最小上下文 |
| B | 全部 17 条 | 只要锚点标签 | 可见目录变了，输出集合不变 |
| C | 全部 17 条 | 17 条标签，锚点排第一 | 输出工作量/结构变了 |
| D | 全部 17 条 | 17 条标签，锚点排最后 | 请求输出顺序变了 |
拆法很干净：A→B 改可见目录；B→C 改输出工作量与结构；C→D 改请求输出顺序。主评分只看锚点；C/D 里多出来的标签不膨胀主目标数。B/C/D 的目录顺序固定。[1]
这一设计直接对应生产里三类常见改动：
- 为了省 token，从「把相关条款都塞进 prompt」改成「只问当前门禁」——类似 A↔B；
- 为了少打几次 API，从「逐条请求」改成「一次吐整张标签图」——类似 B↔C；
- schema 序列化、字段排序或「把重要字段放最后」的日志习惯——类似 C↔D。
All-12、稳定错、配对变化
「All-12 correct」的定义要钉死：四个条件、三次重复里，每一次都给出正确标签，才算这个锚点持续正确。其余互斥类别包括：十二次都有效但标成同一个错标签（稳定错 / same wrong）、十二次有效但标签在变、或集合里至少有一次无效。无效优先于其他归类。每个选中的锚点都留在分母里。[1]
另外还有两个容易混的量：
- Mean correct：同一 30 个锚点上 360 次回答的平均正确率（无效算错）。它和 All-12 用同一批目标，但一个按次计、一个按「目标是否全程扛住」计。
- 配对变化率 F(b,c)：在两个条件都有效的锚点–重复对上，标签是否不同。变化还可以拆成 正确→错误（回归）、错误→正确（纠正）、错误→另一个错误。均分差由「纠正减回归」决定，不是由变化总数决定——所以会出现「准确率一样、判决翻了很多」的情况。[1]
未改条件的重复分歧，用来当「自然抖动量」的参照；把它从跨条件变化里简单减掉，得不到因果效应估计。论文把这一点写得很清楚。[1]
基线：准确率高的，往往更贵、更慢
官方测试基线：每模型 123 合同、2091 判决；失败请求仍算错；成本与中位时延计入全部 123 次尝试。[1]
| 模型 | Accuracy (%) | Macro-F1 | 成本 (USD/合同) | 中位时延 (s) | 有效调用 |
|---|---|---|---|---|---|
| Jev 1.13.0 | 77.38 | 72.23 | 0.000228 | 1.24 | 123/123 |
| Gemini 3.1 Pro Preview | 83.21 | 77.71 | 0.008474 | 3.73 | 123/123 |
| Gemini 3.5 Flash-Lite | 82.54 | 76.96 | 0.001353 | 1.60 | 123/123 |
| GPT-5.6 Terra | 82.59 | 77.23 | 0.011839 | 11.61 | 123/123 |
| Claude Sonnet 5 | 82.40 | 76.38 | 0.011352 | 3.27 | 123/123 |
| GPT-6 Astra | 81.83 | 76.55 | 0.091890 | 20.94 | 123/123 |
| Claude Haiku 4.5 | 79.44 | 74.46 | 0.005396 | 5.65 | 123/123 |
| GPT-5.6 Luna | 78.96 | 73.77 | 0.000931 | 1.74 | 123/123 |
| Qwen3.5-9B | 79.15 | 74.57 | 0.077361 | 134.64 | 122/123 |
| Qwen3.5-4B | 74.22 | 71.67 | 0.053653 | 86.87 | 117/123 |
读表时先分三层，不要合成一句口号：
- 成本与时延。 Jev 最低：约 $0.000228/合同、中位 1.24s（P95 约 1.59s）。Flash-Lite 约六倍成本、准确率高约 5.16 个百分点；Luna 与 Jev 的准确率差在配对区间上并不稳（约 −0.05–3.11 点）。[1]
- 基线准确率。 七家托管模型的点估计都高于 Jev；Gemini Pro 最高 83.21%。前沿点估计不等于「每个对照都显著更好」。沿观测前沿往上加钱也不均匀：Gemini Pro 相对 Flash-Lite 贵约 6.26 倍，只多约 0.67 个百分点，配对区间跨过零。[1]
- 本地 Qwen。 生成额度耗尽导致部分请求无效（4B 117/123、9B 122/123）。即便乐观地把缺失标签全补成正确答案，两者基线仍分别最多到约 79.10% / 79.96%，仍低于 Flash-Lite 的 82.54%——差异不全是「截断惩罚」。[1]
工作量也会改速度排名。固定可见 17 条假设时，从「只要一个标签」（B）改成「要 17 个」（C），Jev 中位时延从约 1.15s 到 1.22s，Flash-Lite 从约 0.99s 到 1.86s，Luna 从约 1.10s 到 1.78s。[1] 比「谁更快」更有用的问题是：在你真实的输出工作量下，谁更快。
对 harness 选型：若决策点在热路径上每轮都要跑，成本 × 调用次数和 P50/P95 时延会先于「再高两个点的 accuracy」成为硬约束。Jev 占的是低成本–低时延端；托管大模型占的是更高基线准确率端。这是配置与计价假设下的观测前沿，不是永恒排名。[1]
All-12：均分相近，持续正确可以差很远
稳定性面板把同一批 30 个锚点在四条件 × 三重复下打分。[1]
| 模型 | Mean correct (%) | All-12 correct | 稳定错 | 有效但在变 | 任一无效 |
|---|---|---|---|---|---|
| Claude Sonnet 5 | 86.67 | 24/30 | 1 | 5 | 0 |
| Jev 1.13.0 | 79.44 | 23/30 | 5 | 2 | 0 |
| Gemini 3.1 Pro Preview | 85.28 | 22/30 | 2 | 5 | 1 |
| GPT-5.6 Luna | 81.94 | 22/30 | 3 | 5 | 0 |
| GPT-6 Astra | 76.39 | 22/30 | 6 | 2 | 0 |
| Gemini 3.5 Flash-Lite | 82.50 | 21/30 | 4 | 5 | 0 |
| GPT-5.6 Terra | 80.56 | 20/30 | 2 | 8 | 0 |
| Claude Haiku 4.5 | 81.94 | 19/30 | 2 | 9 | 0 |
| Qwen3.5-9B | 79.17 | 18/30 | 2 | 8 | 2 |
| Qwen3.5-4B | 77.50 | 17/30 | 2 | 8 | 3 |
最该记住的对照是 Jev 与 Qwen9B：Mean correct 几乎一样（79.44% vs 79.17%），All-12 却是 23/30 vs 18/30。[1] 错误怎么分布决定了「平均」能不能代表「这条目标在生产配置漂移后还对不对」。Jev 有五条锚点从头错到尾、两条在变；Qwen9B 则是两条稳定错、八条有效标签在变、两条碰到无效——总数对得差不多，能扛住全部条件的目标数却少一截。
基线 accuracy 与 All-12 的观测排名也不同：Gemini Pro 基线最高，Sonnet 的 All-12 点估计最高，Jev 在 All-12 上排第二。两套指标的目标集合本就不完全相同；即使把 Mean 与 All-12 都钉在同一批锚点上，仍可见「均分相近、持续正确不同」。[1]
再钉一句论文自己的限定：Sonnet 24/30、Jev 23/30，只差一个目标；配对 95% 区间约 −10.00–16.67 个百分点，跨过零——小面板不能宣称 Jev 相对 Sonnet 有一般稳定性优势。[1] 可以说「在这套条件与样本上，Jev 的 All-12 有竞争力」；不能说「Jev 全面更稳」。Jev 相对 Haiku / Qwen4B 的 All-12 差距更大（点估计差 4–6 个目标），部分配对区间不含零，但仍属探索性、未做多重比较校正。[1]
同意也容易骗人：Jev 与 Astra 各自在 28/30 个目标上重复同一标签，但其中 Jev 有 5 个、Astra 有 6 个是稳定错；Sonnet 的一致性目标里只有 1 个稳定错。[1] 把「反复给出同一答案」当成成功稳定性，会把错误当成可靠。
请求配置会改单个判决：均分可以不动，判决在翻
RQ3 的核心画面：条件级 accuracy 可以持平，配对判决却在换标签。
- Qwen4B 条件 A 与 B 准确率相同，但 90 对里有 9 个变了：4 次回归、4 次纠正、1 次错→错。[1]
- Terra 条件 B 与 C 准确率相同，却有 7 个变化：3 回归、3 纠正、1 错→错。[1]
- Haiku 从 C 到 D（只改输出顺序）：14/90 变化，其中 12 次回归；准确率掉约 11.11 个百分点（描述性配对区间约 −23.33 到 −1.11）。[1]
纠正与回归在均分里会互相抵消。你看到的是「还是那个准确率」；生产里看到的是「这条门禁今天过了、明天不过」——尤其当你为了省 token 改成「只请求锚点」、为了批处理改成「一次要 17 个」、或为了日志习惯把目标标签挪到 JSON 末尾时。
Jev 在该面板上 C→D 零变化；论文同时提醒：Jev 的 question-key 顺序干预不等于自回归模型的输出位置干预，有限样本零变化也不等于证明不变性。[1] 读评测时，把「干预语义」写进笔记，比只抄变化率更重要。
未改条件的重复也会抖。Qwen9B 在 A→B 有 15/90 配对变化的同时，A 条件内部重复也有 12/90 在变；C→D 有 12/88 变化时，D 内部重复仍有 11/86 在变。[1] 跨条件变化率必须和「同请求重复」对照着看。
开发集上的诊断把同一现象放大过：Qwen4B 在联合请求与单假设请求之间改了 510 条里的 87 条标签，正确条数却只差 4；在另一组锚点上 A/B 准确率相同，却有 24/90 配对变化（12 纠正 + 12 回归）。[1] 这些样本与测试集分开，不能直接并进主表，但足以说明：「均分差不多」作为工程口号，风险很大。
类别召回：总分相近时，错在哪一类
总体 accuracy 还会被类别支持度加权。测试集上矛盾类只有 220 条，蕴含 968、未提及 903。论文报告：Jev 在矛盾召回上点估计最高（170/220，约 77.27%），Gemini Pro 矛盾召回更低（135/220），却在蕴含与未提及上拿回更多正确判决，净多约 122 条正确——于是总体准确率更高。[1] Astra 的蕴含召回点估计最高，Sonnet 的未提及召回点估计最高。这些是描述性对照，类别支持不等，不能直接当成「谁适合哪类合同条款」的定论；但对 harness 很有用：如果你的业务损失主要来自某一类假阴性（例如漏掉矛盾），总体榜第一未必是你该上的模型。
同一逻辑可以搬到 agent 门禁：路由错误、安全拒绝、是否需要人工接管，往往不是对称损失。评测报告里除了 macro 指标，至少要留一列「你真正在乎的那一类」的召回或代价加权错误。
开发集诊断为什么还要提一句
正式结论以官方测试为准；开发集用另一批合同，用来解释评测为什么要拆条件。几条与工程直觉对齐的发现：[1]
- 聚合正确可以掩盖大量单个判决变化。 本地与托管生成式模型上，纠正与回归会在 accuracy 里部分抵消；分开计数才能看见「改好了多少、新砸了多少」。
- 敏感度要和同请求重复一起读。 有限次重复上的同意，描述的是观测行为，不能证明确定性。
- 分组会在类别与假设之间重分配错误。 某个模型总体 accuracy 微降，Macro-F1 却升——因为它在矛盾类上补回了召回，却在其他类上丢分。
对选题和站内 Jev 线来说，这些诊断的价值是方法论，而不是另一张可引用的排行榜：它们解释了为什么博客要坚持 All-12、稳定错、配对变化方向，而不是只贴一张均分表。
对 agent / harness 选型：一份可执行清单
把论文读成工程清单，比读成「Jev 赢了」更有用。站内 Jev 文已经强调：它适合回路里必须快、必须结构化的判断。[2] 这份评测补充的是——怎么验收那些判断。
报告什么
- 不要只用均分 / accuracy 选型。 至少并列报告：基线 accuracy（或 Macro-F1）、All-k / persistent correctness、成本/调用、中位与尾部时延、有效响应覆盖率。
- 把稳定错单列。 反复同意但反复错，比「偶尔抖一下」更危险——监控若只看一致性，会漏掉系统性偏差。
- 无效响应算失败，不要默默丢掉。 生成额度耗尽、JSON 缺键、标签非法——在 agent 里通常就是本轮决策失败或 fail-open。评测若剔掉它们，会系统性高估你上线后的体验。
怎么搭一个最小「跨条件」面板
不必一上来就 30×4×3。可以按论文骨架缩一版：
- 从真实业务里固定 N 个锚点判决（与模型输出无关地抽样；记下种子）。
- 定义至少三种请求包装，对应你线上真会改的旋钮：单问 / 多问可见、单标签 / 批量标签、字段顺序。
- 每个包装重复 R 次（R≥3 更稳）。
- 主指标用「锚点在全部包装×重复上是否全对」；辅指标用条件级准确率、配对变化方向、无效率。
- 同时记录成本与端到端时延，且失败尝试留在分母与成本里。
这样你验收的是「同一目标在配置漂移后是否仍对」，而不是「某次 prompt 的幸运均分」。
怎么把模型放进回路
- 成本路径与准确率路径可以拆开。 热路径路由 / 门禁 / 压缩可以用低成本决策层；需要更高基线准确率的复核再上托管大模型。论文观测到的成本–准确率前沿大致落在 Jev、Luna、Flash-Lite、Gemini Pro 一类配置附近；Sonnet / Terra 等准确率接近 Flash-Lite，但更贵，未必扩展这条二维前沿。[1]
- 决策点要像评测一样盯 persistent correctness。 生产里常见的条件漂移：多问题可见 vs 单问题；一次只吐一个标签 vs 批量吐图；字段顺序因 schema 序列化改变。为关键门禁准备锚点面板，比只盯离线 accuracy 更接近真实失败模式。
- 写清计价与部署假设。 本地 GPU 用租金等价、API 用公开单价、时延含网络与排队——换价、换推理预算、换并发，前沿会动。把假设写进选型文档，避免半年后「我们当时测过」却对不上账。
- 接口差异写进对照表。 Jev 的 C/D 是 question-key 顺序；自回归模型是生成答案顺序。两者都叫「顺序敏感」，机制不同，不能直接宣称「谁对位置免疫」。
边界与不该外推的地方
论文 Limitations 写得很直，博客也不该比它更大胆：[1]
- 测试集 123 合同、稳定性 30 锚点，全是同一套 17 类假设；外推到其他法律问题或领域证据不足。
- 基线 accuracy 与 All-12 的目标集合不同；名次差异可能同时来自目标构成与条件敏感。
- 三次重复对可能响应空间的信息有限；小面板上几个目标就能拉动排名；区间描述性、未做多重比较校正。
- Sonnet / Haiku / Terra 是在较早结果审视后加入的；任务与计分规则固定，但模型选择本身带探索性。
- 托管模型在固定标识符背后可能更新；接口、推理设置、供应商路径不完全对齐；Jev 与自回归输出顺序干预不等价。
- 小面板上的 All-12 差距，不能写成「Jev 普遍比 Sonnet 稳」。
伦理侧也清楚：这是研究场景下的模型行为评测，不能当成专业法律或财务决定。[1] ContractNLI 按 CC BY 4.0 使用，应保留对数据集作者的署名。
结语：分数相同，决策可以不同
回到标题。Same scores, different decisions 不是文案，而是评测发现：均分可以掩盖翻盘；同意可以掩盖稳定错；成本与时延把「能不能放进热路径」和「离线排行榜第几」拆开。
对做 agent / harness 的人，可带走的操作结论是：
- 选型报告里同时放 cost、latency、accuracy、persistent correctness；
- 对关键判决做条件 A–D 一类的小面板，而不是只跑一次联合 prompt；
- Jev 在本评测的成本/时延上占优，托管大模型基线准确率更高；稳定性上 Jev 有竞争力，但不要把小样本写成全面优势；
- 请求配置（可见假设、输出个数、顺序）会改单个判决——这正是 harness 该管的层，也是「均分相近就差不多」这句话最该被纠偏的地方。
完整数字与条件定义以论文为准：arXiv:2609.27678。[1] 若你还在接 Jev 的落地路径，可先读站内 Jev × Claude Code。[2]
参考
[1] Fan Zhang et al. Same Scores, Different Decisions: Evaluating JEV and Language Models for Legal Document Understanding. arXiv:2609.27678, 2026. https://arxiv.org/abs/2609.27678
[2] Remy. Jev × Claude Code：别当聊天模型用，先搞清四条落地路径和 25 行最小实现. https://redreamality.com/cn/blog/jev-claude-code-10x-and-25-lines/
[3] Yuta Koreeda and Christopher D. Manning. ContractNLI: A Dataset for Document-Level Natural Language Inference for Contracts. Findings of EMNLP 2021.