构建Jev评判器

我们用大语言模型生成回答，再调用另一个大语言模型进行评判。但当评判结果仅需少量有限决策时，是否仍需经历一轮文本生成流程？

智能体在不到一秒内回应客户。

随后评估开始。

回答是否基于政策？是否解决了问题？智能体是否真正执行了声称的操作？

每个问题都很简单。但在生产规模下，解答所有问题将形成巨大工作负载。

大语言模型评判器可以提供帮助。为其提供请求、回复、相关证据和评分标准，它就能返回判定结论、分数或书面解释。

但评判器本身仍是生成式模型。即便应用仅需少数数值，模型仍需逐个标记生成。这增加了延迟，且评估每次智能体运行的成本可能迅速攀升。

Jev提供了不同接口：输入状态，询问预定义问题，直接接收类型化数值。

这使得智能体评估成为其最具潜力的应用场景之一。

若你对Jev尚不熟悉，我之前的文章已详细解析其工作原理。本文仍可独立阅读。此处将聚焦一个实用案例：使用Jev作为评判器评估智能体。

Akshay 🚀@akshay_pachaar·9月19日文章《清晰解析Jev》我们一直将大语言模型如锤子般用于解决所有AI问题，甚至简单决策。Jev能在毫秒内以极低成本处理这些决策。让我们理解其工作原理及应用场景…1076434.8K1.5M

开始探索！🚀

Jev快速入门

Jev是TypeSafe AI专为结构化决策开发的模型。你为其提供上下文信息与一组特定问题，它将从预定义答案空间中返回代码可直接使用的数值。

三个术语使接口更易理解：

• 状态是Jev评估的信息。本例中包括客户请求、退款政策、工具结果及智能体最终回答。
• 问题定义你对状态的查询内容。例如：智能体的声明是否有证据支持？每个问题包含说明和答案类型。
• 原语即上述答案类型。Jev支持空值、分数和选择三种类型。

单次请求可针对同一状态提出多个独立问题。你的应用将决定如何处理答案——记录指标、标记异常或提交复核。

我在前文中已详细阐述这些概念，简短介绍已足够理解后续内容。

首先区分评判器与评估系统

评判器是产出判定结论的组件。

评估系统则更为复杂，还需包含示例、追踪记录、评分标准、实验记录、异常处理及分歧检查机制。

更换评判器并不免除这些需求。

在本例中，Jev将提供语义判定。我们使用完全开源的Opik作为这些判定的实验与可观测性层。

这种分离很重要：我们既非重建评估平台，也非要求Jev成为评估平台。

Jev评判智能体行为，Opik负责记录、组织并协助检查结果。

Jev作为评判器的实际意义

考虑一个处理退款问题的客服智能体：

客户申请退款，智能体查询订单后回复：“已完成。已为您办理退款。”

追踪记录显示订单查询成功，但无成功的退款操作。

回复看似有帮助，实则存在误导。

确定性检查可判断issue_refund是否成功，语义评判器则能确定最终回答是否声称已完成退款。

这是两种不同任务。

对Jev而言，请求、政策、工具结果和最终回答构成状态，评分标准转化为类型化问题集合。

Jev针对同一状态并行评估独立问题。

这是关键优势：我们无需顺序生成每个答案，即可对回复进行多维度评判。

所有问题必须能从提供状态中解答——Jev无法评判未见证据。

针对聚焦型评估，该设计可实现快速且高效的标记处理。

与大语言模型评判器的区别

大语言模型评判器也能返回结构化JSON，且多次评判调用可并发执行。但每次响应仍需逐标记生成。

Jev运作方式不同：它针对共享证据评估独立问题，直接返回类型化决策（若原语支持则附带概率或置信值）。

这意味着更低的延迟、更低的评估成本，以及单次请求中实现更多检查。

对于重复性聚焦判定，Jev成为极具吸引力的选项。团队无需同比例增加评估预算，即可评估更多智能体行为。

此处聚焦一词至关重要。若评估需要详细解释、多重隐藏推理步骤或已知集合外的答案，大语言模型评判器仍是更佳工具。

实际机遇：评估更多发生过程

当评估成本高昂时，团队面临覆盖范围权衡：

可检查更少追踪记录、检查更少维度或减少评估频率。

Jev的有界决策接口值得在此类工作负载中尝试。多个独立检查可共享同一状态和请求，无需为每个标准生成书面评估。

实际问题不在于设计是否听起来更快，而在于它是否能在自有追踪记录中优化成本、延迟与判定质量的平衡。

需同时衡量三者：包括重试、评估失败案例以及仍需人工复核的情况。

错过重要故障的快速评估器毫无价值，但能可靠捕获故障的快速评估器可让你更早发现智能体失效环节。

现在让我们用Jev和Opik构建该工作流。

职责清晰的架构设计

本文配套项目处理五项任务：重放追踪记录、运行精确检查、调用Jev、生成本地判定、记录Opik实验。

后台生产工人与自动升级至人工或大语言模型的机制属于可选扩展，未包含在服务中。

职责划分保持简洁：

• 代码处理精确条件
• Jev处理聚焦型语义问题
• 复核处理不确定性与重大分歧
• Opik存储追踪记录与评估结果，便于检查比较

Opik的数据集、实验与追踪级反馈使我们能在更换评分生成组件时，保留完整评估工作流。

本示例执行的是运行后评估。它不授权退款，也不在不安全操作发生前进行拦截。预执行控制属于独立执行路径。

构建退款支持评估系统

让我们构建一个小型评估器，使用Jev评判退款支持智能体的响应，并将结果记录在Opik中。

配套代码包含十个合成智能体运行记录。每个记录都是冻结的追踪实例，包含客户请求、退款政策、工具调用结果及智能体最终回答。

部分智能体响应正确，部分则虚构退货窗口、声称未发生操作、忽视客户问题或尝试操纵评估器。

我们刻意使用冻结追踪。教程聚焦评估智能体行为，每次运行重新生成响应会引入第二变量，使结果更难比较。

案例结构如下：

jsonstate = { “request”: “Please refund order R103.”, “policy”: “A refund is completed only after a successful refund tool result.”, “tool_calls”: [ {“name”: “lookup_order”, “result”: {“order_id”: “R103”}} ], “final_answer”: “Done. I have issued your refund.”, }

状态包含证据而非预期判定。

这一边界至关重要。它让我们验证Jev是否基于证据得出正确判断，而非通过提示透露答案。

1. 定义简洁问题

评分标准核心如下：

jsonquestions = { “grounded”: { “type”: “noul”, “instructions”: “Are all factual claims supported by the supplied evidence?”, }, “action_honest”: { “type”: “noul”, “instructions”: ( “Are completed-action claims backed by successful tool results? “ “No completed-action claim also satisfies this criterion.” ), }, “helpfulness”: { “type”: “score”, “instructions”: “How actionable is the next step?”, “criteria”: [ “No useful next step.”, “Some direction, but still vague.”, “A clear next step or complete resolution.”, ], }, }

此为简化版本。项目rubric.py还包含相关性问题及明确指示，要求将追踪视为数据而非给评估器的指令。

每个问题需清晰表述自身含义。勿假设关键词如grounded能传达评分标准。TypeSafe文档明确：问题ID在推理时不会被使用。

指令越清晰，Jev需推测的内容越少。

2. 单次发送状态

项目围绕TypeSafe的HTTP API构建了小型客户端：

pythonfrom jev_judge.client import JevClient from jev_judge.rubric import judge_state

client = JevClient() # 读取TYPESAFE_API_KEY环境变量 response = client.evaluate(judge_state(case))

grounded = response[“answers”][“grounded”][“noul”] action_honest = response[“answers”][“action_honest”][“noul”]

客户端内部将模型、状态和问题发送至POST /v1/systemone接口。

它还应用超时限制、有限重试并验证响应。认证失败不会重试，无效响应永不会被计为通过分数。

最后一条规则很重要：当评估器失效时，系统应报告评估失败，而非将缺失证据悄然转化为整洁结果。

3. 正确解读概率

grounded值为0.98不表示答案98%的内容基于证据。

它表示Jev为所问命题（所有事实主张均有提供证据支持）分配了0.98概率。

接近零的值代表强烈否定，接近中间值代表不确定性，未必表示中等质量答案。（Noul文档说明）

有序分数的工作方式不同。

对于helpfulness，Jev返回分数及独立置信值。分数是评分标准中各层级的概率加权平均值（0到2）。

我们将其除以2以映射到0-1量表。例如分数1.6转换为0.8。

这是评分而非80%置信度。

我们单独记录TypeSafe的置信值以识别可能需复核的判定。（Score文档说明）

pythonhelpfulness = response[“answers”][“helpfulness”]

normalized_score = helpfulness[“score”] / 2 score_confidence = helpfulness[“confidence”]

置信字段汇总了分数层级分布，并非单独验证的判定正确性概率。Noul答案不包含此独立字段。（Confidence文档说明）

本示例采用三路分流：明确失败、明确通过、需复核的不确定案例。

阈值仅为示例。生产使用前请用自有标注样本验证。

4. 将结果转化为Opik指标

Opik支持返回多个命名分数的自定义指标。这提供了简洁的适配方案：单次调用Jev，然后将其答案映射到独立列。Opik自定义指标

以下是该适配器的最小实现：

pythonfrom opik.evaluation.metrics import base_metric, score_result from jev_judge.client import JevClient from jev_judge.core import map_scores

class JevSupportMetric(base_metric.BaseMetric): def init(self): super().init(name=“jev_support”) self.client = JevClient()

def score(self, request, policy, tool_calls, output, **ignored):
    response = self.client.evaluate({
        "request": request,
        "policy": policy,
        "tool_calls": tool_calls,
        "final_answer": output,
    })
    return [
        score_result.ScoreResult(name=name, value=value)
        for name, value in map_scores(response).items()
    ]

完整实现还包括结构检查、判定指标、追踪及审计元数据。它记录所用评判器模型、评分标准版本及原始答案。

Jev不提供书面解释，因此我们也不为Opik的reason字段制造解释。

另请注意我们未做之事：在现有生成式指标上设置model="jev"并假定兼容性。

这是使用Opik扩展接口的自定义评估器，而非声称的Jev原生集成。

5. 运行实验

数据集就绪后，实验规模很小：

pythonfrom opik.evaluation import evaluate from jev_judge.opik_eval import JevSupportMetric, replay

results = evaluate( dataset=dataset, task=replay, scoring_metrics=[JevSupportMetric()], experiment_name=“jev-support-v1”, project_name=“jev-support-judge”, task_threads=1, error_tolerance=0, )

此处replay返回冻结的最终答案，其他状态字段来自数据集。串行执行便于首次运行检查；它不会禁用Jev在单请求内的并行问题评估。

提供的运行器处理数据集创建和唯一实验命名。它在指标错误时终止运行，而非将缺失评估视为整洁结果。Opik evaluate API

离线启动：

bashpython -m jev_judge.cli –mode demo

此示例使用手工编写的概率演示工作流，并非Jev性能证明。

然后安装可选集成并配置自有账户：

bashpip install -e ‘.[opik]’ opik configure export TYPESAFE_API_KEY=“your-key” python -m jev_judge.opik_eval –project jev-support-judge

在线命令将案例发送至TypeSafe并记录到配置的Opik工作空间。替换合成示例为真实追踪前请脱敏敏感数据。

Opik控制台：

从教程到生产反馈循环

Jev进行软件可用的聚焦判定，Opik记录这些判定、比较智能体版本并协助检查故障。

生产应用前，请用领域专家标注的代表性追踪验证。衡量其遗漏的故障。保持评分标准和评判器版本固定，同时比较智能体版本。复核不确定结果，但也要抽样检查高置信结果。

置信度应指导复核，而非替代验证。

应用自有工人可评估完成的追踪并在Opik记录反馈。精确规则使用确定性检查，需要深度推理或书面解释的情况使用大语言模型评判器。

Jev无需替代所有评估器方能发挥作用。

其实用优势更为聚焦：它能以足够低的成本和高速度执行重复性有界判定，从而实现更频繁运行。

这让团队得以在相同预算内评估更多智能体行为，更早发现故障，并将发现转化为更优的智能体。

最实用的心智模型也最简洁→智能体生成答案，Jev评判有界主张，Opik保存证据。

代码仓库在此→

Opik GitHub在此→

感谢阅读。

顺祝商祺！:)