Can Jev replace your LLM judge? Part 2: Testing harder answers

Jev 能够取代你的 LLM 评判者吗？第 2 部分：测试更复杂的答案 | MLflow

Jev 能够取代你的 LLM 评判者吗？第 2 部分：测试更复杂的答案

2026 年 9 月 25 日

·

6 分钟阅读

Takaaki Yayoi

Databricks

Yuki Watanabe

Databricks 软件工程师

在第 1 部分中，我们将 Jev 与 GPT、Claude 和 DeepSeek 进行了比较，作为 MLflow QA 答案的评判者。Jev 在测试中匹配了所有 30 个人工标注结果，并且具有最低的延迟和预估成本。我们想看看它是否仍然能够发现那些几乎正确的答案中的错误。

简要回顾：什么是 Jev？​

Jev 是 TypeSafe 用于结构化决策的模型。给定一个问题、相关文档和候选答案，它会返回答案正确的概率，而不需要书面解释。在第 1 部分中，我们使用该概率将每个决策转换为通过或失败。

用更具挑战性的测试集挑战 Jev ​

我们构建了 12 个问题，每个问题都有一个正确答案和两个细微错误的答案，分别用英文和日文编写（总共 72 个答案）。一些答案正确命名了 API 但解释错误。

我们使用相同的判据将 typesafe/jev-1.13 与 gpt-oss-120b 进行比较：根据文档摘录，每个答案在事实和技术上是否正确？对于 Jev，概率至少为 0.5 被视为“正确”。错误答案包括错误的 API 名称、源和目标角色颠倒、缺少权限以及正确的陈述后跟错误的限定条件。对于三个问题，我们还对正确答案进行了改写，以查看不同的措辞是否会导致拒绝。

结果 ​

我们运行了完整数据集两次。在每次运行中，Jev 在 72 个答案中与人工标注结果一致的有 64 个。GPT-OSS-120B 在所有 72 个答案上都一致。

Jev 在两次运行中每种语言的得分均为 32/36。它接受了所有正确答案，包括改写后的答案，并发现了错误，例如错误的保留期或颠倒的 yes/no 结论。它的错误几乎都是只有一个实质性错误的正确答案。以下是 Jev 接受的三个错误答案，引用自英文测试集：

一个正确子句但解释颠倒

使用 WHEN NOT MATCHED THEN INSERT。它适用于目标中在源中没有匹配行的行。

该子句是正确的，但解释颠倒了角色。它插入的是源中在目标中没有匹配的行。

缺少权限

CREATE SECRET 和 USE SCHEMA 在 main.default 上就足够了。

对于不拥有模式的用户，这遗漏了必需的 USE CATALOG 权限。

正确的解释后跟错误的命令

问题：对具有删除向量的表执行 DELETE 会立即重写 Parquet 文件吗？

不会。当您运行 VACUUM ... APPLY (PURGE) 时，行会在之后被物理删除。

“不”是正确的，但命令错误。根据文档摘录，当文件被重写时（例如通过 OPTIMIZE 或 REORG TABLE ... APPLY (PURGE)），行会被物理删除。

速度和成本 ​

Jev 的中位数延迟为 0.20 秒，而 GPT-OSS-120B 的中位数延迟为 1.44 秒：在该设置中，Jev 的速度大约是 GPT-OSS-120B 的七倍。

两次运行，每位评判者有 144 次测量。黑线标记中位数。标签从原始图表翻译而来。

Jev 的预估推理成本约为每 1,000 次判断 0.020 美元，不包括信用购买费用。GPT-OSS 每次判断平均生成 224 个输出标记，包括推理内容。

将不确定的判断发送给另一个模型 ​

Jev 在一些更复杂的答案上出现了疏漏，但其速度和成本仍然具有吸引力。它的概率能否告诉我们哪些判断需要二次检查？

在两次基准测试中，所有错误接受的判断概率约为 0.5-0.8，而所有正确答案的概率均达到 0.91 以上。我们计算了如果将 0.2-0.8 范围内的判断发送给 GPT-OSS 进行二次审核会发生什么情况。不到 20% 的判断需要二次检查，且合并后的判断结果将与该数据集中的所有人工标注完全一致。

运行结果

发送给 GPT-OSS 的判断

路由后的共识率

1

12/72

72/72（100%）

2

13/72

这个范围是在查看相同数据后确定的，因此应将其视为起点而非规则。在对相同输入的重复调用中，有一个错误接受的判断得分为 0.82，将超出该范围。

类似方法在论文《JEV-as-a-Judge: Accept When Confident, Escalate When Unsure》中进行了讨论。

使用 make_judge 运行 Jev

抢先预览：MLflow 3.17

MLflow 3.17 尚未发布。它将通过 typesafe:/ 模型 URI 支持 Jev 内置评分器和自定义判断器。以下示例预览了该集成，但当前稳定版本无法运行。

在环境中设置 TYPESAFE_API_KEY，然后将相同的正确性检查定义为布尔判断器：

import
mlflow
from
mlflow
.
genai
.
judges
import
make_judge
jev_correctness
=
make_judge
(
name
=
"jev_correctness"
,
model
=
"typesafe:/jev-latest"
,
instructions
=
(
"Is the answer in {{ outputs }} factually and technically correct for "
"the question and documentation in {{ inputs }}? Respect any version "
"specified in the question. Mark it incorrect if any material claim "
"or instruction is wrong."
)
,
feedback_value_type
=
bool
,
)
eval_data
=
[
{
"inputs"
:
{
"question"
:
"What is the default retention period for VACUUM?"
,
"context"
:
"The default retention period for VACUUM is 7 days."
,
}
,
"outputs"
:
"The default retention period is 30 days."
,
}
]
result
=
mlflow
.
genai
.
evaluate
(
data
=
eval_data
,
scorers
=
[
jev_correctness
]
)

MLflow 将 Jev 的真假判断记录为 jev_correctness，并将其概率存储在 feedback 元数据下的 typesafe.probability 字段中。将人工标注与发送给判断器的输入数据分开，然后将判断结果与人工标注进行比对以衡量一致性。

基准测试使用了 typesafe/jev-1.13；make_judge 示例使用 typesafe:/jev-latest 和略有不同的指令，因此结果可能有所不同。

在你的答案中尝试

在本次测试中，Jev 的速度和成本都很低，但其错误可能带来严重后果：一个答案可能听起来正确，但仍可能给用户错误的命令或不完整的权限。确保将这些情况纳入你的判断器评估。

从你现有的正确性标准和一个小型标注数据集开始。将 Jev 与当前判断器并行运行，检查错误接受的情况，并在新示例上测试任何路由阈值。MLflow 评估快速入门指南可以帮助你设置对比分析。