@akshay_pachaar: Jev 与 LLM 作为评判者的清晰对比解析。设想一个客服人员说：“已处理，退款已发放。”追踪记录却显示……

X AI KOLs Timeline 工具
ai-evaluation llm-judges dev-tools structured-evaluation open-source

摘要

本文解析了用于评估 AI 智能体回应的 Jev 与 LLM 作为评判者之间的区别，强调了根据需要开放式推理还是结构化并行判断来选择使用哪种方式。

Jev 与 LLM 作为评判者的清晰对比解析。 设想一个客服人员说：“已处理，退款已发放。” 追踪记录显示，该智能体查询了订单，但从未完成退款操作。现在，评估者需要判断这个回答是否基于事实、是否诚实且是否有用。 LLM 评判者和 Jev 都可以进行这些判断。区别在于它们如何产出结果。 → 两者需要相同的证据 必须包含客户请求、政策、工具结果和智能体的回答。评判者无法评估其未见过的证据。 → LLM 评判者生成评估结果 你在提示词中描述评判标准并指定期望的输出格式。然后，模型会逐个词元地生成一个判定、评分、结构化 JSON 或文字解释。 当评估需要详细推理、解释或答案超出预定义集合时，这种方式效果很好。 → Jev 返回结构化决策 你只需提供一次证据，然后定义独立的问题和预设的答案格式。 对于是非判断标准，Jev 返回陈述为真的概率。对于排序标准，它返回一个评分和一个单独的置信度值。 Jev 将这些格式称为 Noul 和 Score，但其核心思想很简单：可能的答案在评估运行前就已定义好。 Jev 针对共享证据并行评估独立问题。你的代码接收到的值可立即用于阈值设定、路由或审查。 → 工作负载决定了更好的接口选择 当你需要开放式推理或书面理由时，请使用 LLM 评判者。 当你需要重复进行聚焦判断时，请使用 Jev，例如判断一个回答是否基于事实、一个行动主张是否诚实，或一个回应有多大的可操作性。 多次 LLM 评判者调用也可以并发运行。重要的区别不在于调用之间的并发性，而在于逐词元生成与单次请求内并行结构化判断的区别。 这种区别在规模上很重要。当每次智能体运行都需要多项检查时，一个更快且更便宜的评估器可以帮助你检查更多追踪记录、衡量更多维度，并更早地发现问题。 Jev 并非取代所有 LLM 评判者。它为有界的评估工作负载提供了一个更直接的接口。 智能体生成答案。评判者只在判断本身需要时才生成结果。 我还发布了使用 Jev 和 Comet 开源 Opik 平台的完整评估工作流。该仓库包含冻结的智能体追踪记录、结构化评判标准、结果映射以及实验运行器。 你可以在此处浏览和运行代码：http://github.com/patchy631/jev-as-judge… 我撰写了完整分析。文章内容引用如下。
查看原文
查看缓存全文

缓存时间: 2026/09/24 14:25

Jev 对比 LLM 作为评判者，清晰解析

想象一位客服人员说：“已完成。已为您办理退款。”

但追踪记录显示该客服只查询了订单，实际并未完成退款。评估者现在需要判断该回答是否有依据、是否诚实且是否有用。

LLM 评判者和 Jev 都能做出此类判断。关键区别在于他们如何产生判断结果。

→ 两者都需要相同的证据 必须包含客户请求、政策、工具执行结果和客服回答。评判者无法评估未曾看到的证据。

→ LLM 评判者生成评估结果 您在提示词中描述评分标准并指定输出格式。模型随后逐个 token 生成判定结果、分数、结构化 JSON 或文字说明。

当评估需要详细推理、解释性说明或答案超出预设范围时，这种方式效果良好。

→ Jev 返回结构化决策 您只需提供一次证据，然后定义独立问题及预设答案格式。

对于是非判断类标准，Jev 返回该陈述为真的概率；对于排序类标准，Jev 返回评分及独立的置信度值。

Jev 将这些格式称为 Noul 和 Score，但其核心思想很简单：可能的答案在评估执行前就已定义。

Jev 针对相同证据并行评估独立问题。您的代码能立即获得可用于阈值判定、路由分发或人工审核的数值。

→ 工作负载决定最佳接口选择 需要开放式推理或文字说明时，使用 LLM 评判者。 需要反复执行聚焦判断时（如答案是否有依据、操作声明是否诚实、回复可执行性如何），使用 Jev。

多个 LLM 评判者调用也可并发执行。关键区别不在于调用间的并发性，而在于逐 token 生成与单次请求内并行结构化判断的差异。

这种区别在规模化场景中尤为重要。当每次代理运行都需要多项检查时，更快且更经济的评估器能帮助您检查更多追踪记录、衡量更多维度并更早发现问题。

Jev 并非要取代所有 LLM 评判者，而是为有界评估工作负载提供更直接的接口。

代理生成回答。评判者只应在判断本身需要时才生成内容。

我同时发布了使用 Jev 和 Comet 开源 Opik 平台的完整评估工作流。该仓库包含冻结的代理追踪记录、结构化评分标准、结果映射及实验运行器。

您可在此处查看并运行代码：http://github.com/patchy631/jev-as-judge…

我撰写了完整解析，文章引述如下：

patchy631/jev-as-judge

来源：https://github.com/patchy631/jev-as-judge

结合 Comet Opik 的 Jev 评判者

Jev — LLM 作为评判者

使用 Jev 评估退款支持追踪记录的可审计示例，并将结果记录为 Opik 实验。

项目功能

  • 回放十个合成冻结支持追踪记录，包含正确答案、虚构政策、虚假操作声明、模糊表述及评估者注入尝试。
  • 在执行语义评估前进行确定性检查。
  • 单次 Jev 请求中评估三个是非标准及一个排序型有用性评分标准。
  • 保留原始模型回答、解析的模型标识符和评分标准版本以供审计。
  • 通过自定义 BaseMetric 将数值映射到独立的 Opik 指标。
  • 提供完全离线演示、模拟传输测试和真实 SDK 适配器测试。

这是一个评估器教程，并非原生 Jev 插件或生产防护机制。本教程不处理退款操作，仅记录审核结果，未实现自动升级和后台工作进程。

1. 无需账户运行

在当前文件夹中，使用 Python 3.10 或更高版本：

python -m jev_judge.cli --mode demo
python -unittest discover -s tests -v

核心演示无需依赖项和网络调用。可选 Opik 测试在 SDK 缺失时会跳过。演示概率为手工编写，明确标注 DEMO-hand-authored-not-Jev。它们测试的是流程而非模型准确性，请勿将演示时序视为推理延迟。

2. 使用真实 Jev 评估追踪记录

获取 TypeSafe API 密钥并在终端导出：

export TYPESAFE_API_KEY="your-key"
export JEV_MODEL="jev-latest"
python -m jev_judge.cli --mode live --output results/live.jsonl

这将发送合成请求、政策、工具结果和最终答案至 TypeSafe（可能产生 API 费用）。样本包含九个初始评判请求：空答案案例会触发确定性检查失败。重试可能增加费用。该流程不会记录到 Opik。

jev-latest 可能变更，已记录解析的响应模型。如需纵向比较请使用支持的固定模型标识符。切勿将 API 错误转化为质量分数；失败案例会标记为 judge_error，路由至审核环节并产生非零 CLI 退出码。

3. 运行 Opik 实验

python -m venv .venv
source .venv/bin/activate
pip install -e '.[opik]'
opik configure
export TYPESAFE_API_KEY="your-key"
python -m jev_judge.opik_eval --project jev-support-judge

这将再次单独调用 Jev，并在配置的 Opik 工作区中创建新数据集和实验。每次调用使用唯一名称以避免静默混合测试用例修订版本。配置时可选择 Opik Cloud 或自托管方案。构建本项目时未修改外部账户。

适配器测试使用 Opik 2.2.71 和 Python 3.12，采用模拟 Jev 传输。未运行真实 Jev 认证调用和实际 Opik 上传。2026年9月20日已根据官方文档检查公共 API 契约。依赖版本不会冻结服务器行为。

OPIK_TRACK_DISABLE=true 仅在测试中使用，请勿用于真实实验。.env.example 文档记录了相关变量；.env 不会自动加载。

理解评分结果

指标含义
grounded所有事实主张都有所提供依据的估计概率
addresses_request回复解决实际请求的估计概率
action_honest已完成操作声明与成功工具证据匹配的估计概率
helpfulness基于概率加权的评分值，从 0–2 归一化至 0–1
helpfulness_confidence评分答案的提供者不确定性摘要
accepted应用判定为通过（非正确性保证）
needs_review应用判定为不确定

Noul 值 0.98 并非表示“98% 的主张有依据”，而是模型对整体命题回答“是”的概率。Score.confidence 并非评判者正确的概率。教程中 0.2/0.8 的边界值和 0.6 置信度阈值仅为示例说明，未经校准。

使用自定义追踪记录

向任一运行器传递 --data path/to/cases.jsonl。每行需包含：

{
  "id": "case-001",
  "request": "Can I return this order?",
  "policy": "与该请求相关的权威政策。",
  "tool_calls": [{"name": "lookup_order", "result": {"eligible": true}}],
  "final_answer": "待评估的回答。"
}

演示模式还需要手工编写的 demo 字段（如提供的测试用例所示）。实际模式绝不会将这些发送至 Jev。可选的 expected_verdict 字段是教程注解，并非独立收集的人类标签；它们会被排除在评判状态之外。报告准确率前请收集真实标签。

提交前请编辑个人信息。根据需求限制 Opik 的数据保留和访问权限。评分标准中的指令边界可减少歧义，但并非证明能防御提示注入。需单独测试恶意追踪内容。

文件结构

  • article.md：发布草稿，包含源链接和代码片段。
  • jev_judge/rubric.py：原子问题和允许的状态投影。
  • jev_judge/client.py：文档化 HTTP 契约、验证、超时和有界重试。
  • jev_judge/core.py：确定性检查、分数映射、判定策略。
  • jev_judge/cli.py：本地演示/实际运行器和 JSONL 审计结果。
  • jev_judge/opik_eval.py：自定义实际指标和实验入口点。
  • tests/：无网络测试，包含带模拟调用的真实 Opik SDK。
  • scripts/build_figures.py：可复现的架构导出工具。
  • scripts/build_reading_copy.py：独立 HTML 文章构建器。
  • VALIDATION.md：验证范围和发布检查。

重建图形和阅读副本

pip install -e '.[figures]'
python scripts/build_figures.py
npm install --no-save playwright
npx playwright install chromium
node scripts/render_illustrations.cjs
python scripts/build_reading_copy.py

或安装 weasyprint 和 Poppler（pdftoppm），用 python scripts/render_illustrations.py 替代 Playwright 步骤。assets/ 中的四个插图为可编辑 HTML/CSS，其 PNG 导出支撑 Markdown 文章。

发布至 GitHub 前

发布前请审阅文章、选择仓库 URL 并选择许可证。本项目未强制指定许可证。提交源码、数据、测试、文章和图表；请勿提交 .env、凭证、环境配置或私有结果文件。包含的 CI 工作流仅运行离线测试。

资料来源

  • TypeSafe API (https://docs.typesafe.ai/api)
  • TypeSafe Noul (https://docs.typesafe.ai/primitives/noul)
  • TypeSafe Score (https://docs.typesafe.ai/primitives/score)
  • TypeSafe confidence (https://docs.typesafe.ai/confidence)
  • Opik 自定义指标 (https://www.comet.com/docs/opik/evaluation/metrics/custom_metric)
  • Opik 评估 SDK (https://www.comet.com/docs/opik/python-sdk-reference/evaluation/evaluate.html)
  • Comet 评判者指南 (https://www.comet.com/site/blog/llm-as-a-judge/)

相似文章