jevals：用类型化判定代替 LLM 评委的智能体评测库

jevals 的 README 说了什么

jevals 是 openlayer-ai 这个 GitHub 组织下的开源 Python 库。README 把它定位为“给智能体用的评测与护栏”，并强调它使用 Jev 类决策模型，而不是 LLM 评委。核心主张落在成本和速度上：一条智能体轨迹的全部评测会合并成一次请求发出去。README 称这次请求只花千分之几美分，几百毫秒就能返回，因此可以对每一条轨迹都跑一遍，甚至放进智能体的运行循环里。

本文只依据 README 撰写。我们没有安装，也没有运行这个工具。下文所有数字都是作者自己的说法，凡是 README 自己标明“估算”或“示意”的地方，我们都会指出来。

README 中的关键事实

模型思路。 README 说，Jev 不生成文本。你给它一份状态和一组带类型的问题：是非题、多选一，或者按评分标准打分。它在一次前向计算里，为每个问题返回一个经过校准的概率。各个问题彼此独立、并行求值，所以问 40 个问题的延迟和问 1 个差不多。README 给出的价格是每百万输入 token 0.042 美元，没有输出 token 的费用；经由 Vercel 网关测得每次请求 p50 为 244 毫秒，p95 为 371 毫秒。 快速上手。 调用一次 `evaluate()`，传入消息列表和工具的 schema，再加上一组评测对象，例如 `ToolChoice`、`UsedToolResult`、`Grounded`、`StayedInScope`、`AnswerRelevancy`、`Completeness`、`IndirectInjection` 和 `PHI`。README 报告说，八项评测只用了一次 HTTP 请求：1,388 个 token，0.00006 美元，0.33 秒。 后端。 库会根据环境变量选择后端。可选项包括：通过 `TYPESAFE_API_KEY` 直连 Jev（README 说目前需要候补名单资格）、通过 Vercel AI Gateway 使用 Jev、自托管的 Kev、在 Apple Silicon 上进程内运行的 Laya，以及经由 OpenRouter 的普通聊天 LLM，后者靠提示词模拟“输出概率”。README 提醒：换后端之后要重新运行 `jevals calibrate`，因为不同模型的概率并不对齐。 评测目录。 README 列出了智能体类评测（如 `ToolChoice`、`Grounded`、`StayedInScope`、`LoopDetection`、`GoalCompletion`、`ToolCallRisk`）、安全类评测（`PromptInjection`、`IndirectInjection`、`Jailbreak`、`PII`、`PHI`、`SecretsExposure` 等），以及 Ragas 风格的质量指标（`Faithfulness`、`AnswerRelevancy`、`ContextPrecision`、`ContextRecall` 等）。README 称一共有 37 项评测。

基准对比表。 README 用同一个小型 RAG 数据集的 20 行数据，把 jevals 和 Ragas 做了对比，测量日期是 2026-09-20。使用 gpt-4.1-mini 的 Ragas，每个样本要 6.0 次 LLM 请求外加向量嵌入，每千个样本约 2.60 美元，20 个样本耗时 22 到 35 秒。使用 Jev 的 jevals，每个样本 1.0 次请求，每千个样本约 0.03 美元，耗时 0.8 秒。用 gpt-4.1-mini 模拟 Jev 的 jevals，1.0 次请求，每千个样本 0.46 美元，耗时 4 秒。Kev-4B 与 Laya 两行被标注为估算值。三行实测结果里，faithfulness 都在 0.90 到 0.92 之间，context precision 和 recall 都是 1.0。

评测与闸门如何工作

一个评测就是带三个方法的类。`state()` 挑出模型该看的内容，`questions()` 说明要问什么，`reduce()` 把返回的概率变成分数。向 `evaluate()` 传入多个评测时，README 说它们的状态会被合并，问题会被打包进同一次请求。由于评测只依赖样本本身，同一个类既能当离线指标，也能监控线上轨迹，还能在智能体内部当闸门。

闸门是“一个评测加一条策略”，策略把答案映射为放行、升级或拦截。README 展示了一个工具调用风险的 YAML 闸门：当 `action.approve >= 0.85` 且 `grounded >= 0.7` 时放行，当 `action.block >= 0.6` 时拦截，其余情况升级处理。README 还给出了接入 OpenAI Agents SDK、普通异步循环、LangGraph，以及 Claude Agent SDK 的 `PreToolUse` 钩子的写法。如果后端在重试之后仍然不可用，闸门默认放行；对不可逆操作，可以传入 `on_error="block"` 反过来处理。

对于 PII 和 PHI，README 描述了两步做法：先做实体检测，再向模型问一个问题——这是关于可识别个人的健康信息，还是一个客服邮箱地址？README 说，单靠实体检测分不清这两者，而这正是多数 PII 误报的来源。

背景与我们的解读

*这一节是我们的分析，不是 README 的内容。* 所谓 LLM 评委，就是让通用聊天模型给输出打分，通常通过提示词要求它给出推理过程和一段 JSON。README 的论点是：评委要做的判断大多能归入三种问题类型，而且你最终留下来的本来就是一个标签。如果一个小模型能在一次计算里给出带概率的标签，你就负担得起高得多的运行频率。这改变了评测的用途：每晚抽样一次，可以变成对每条轨迹的检查；对每条轨迹的检查，又可以挪进请求路径。

README 还谈到了方差。它引用 LangChain 的一次对比：在相同轨迹上，GPT 和 Claude 评委的分数方差是 Jev 的 92 倍到 913 倍。我们没有读过那篇文章。另外，概率和一大段文字不同，可以设阈值，所以能按动作来权衡。README 里的 `jevals calibrate` 示例列出了各阈值对应的“错误放行”和“漏放行”比例，并建议按动作而不是按模型设阈值，因为退款和查询不该共用一个阈值。

README 自己的例子说明了为什么要同时跑多项指标。工具只返回了今天的预报，智能体却说“整周都会晴”。`grounded` 评测给这句话的 p 值只有 0.05，而 `answer_relevancy` 仍是 0.84。README 的结论是：单靠 RAG 式指标，这条轨迹会被判为通过。

局限与未解问题

README 对自身局限相当坦率。它说项目是 alpha 版本，只有一周大，底层模型同样只有一周大。TypeSafe 直连后端是按文档中的通信格式写的，只对着模拟后端测试过，还没有真实运行。各框架适配器按 SDK 文档编写，只对着假对象测试。表中 Kev 与 Laya 两行是估算，由这两个模型作者公布的数字推算而来。多处输出块被标为“Illustrative output”，即示意输出。README 还说，它不生成测试集，没有仪表盘，遇到需要多步推理或书面点评的工作，也不会取代 LLM 评委。

关于准确率，README 引用了独立基准 JevBench：在分类任务上，Jev 的准确率大致相当于最小的那批 LLM（Banking77 和 CLINC150 上为 83% 到 87%），并且不同任务的校准表现不一。README 还提到，LangChain 的结果是 500 次重复中与人工判断 100% 一致，而 Claude 为 80%，但那只基于五条轨迹。它同时报告说，某次运行中网关在部分连接上卡住，导致那次运行的 p95 达到一分钟，不过客户端重试后运行完成了。 我们还发现 README 里有几处小的不一致。开头示例是八项评测、1,388 个 token、0.33 秒，较长的示例却是九项、1,423 个 token、0.50 秒。文中说“百分之六美分”，对应的却是打印出来的 0.00006 美元，那其实是千分之六美分。这些看起来是不同运行造成的措辞疏忽，不是深层问题，但它们提醒你：数字要自己重新测。 我们的解读：能省多少，取决于你的问题是否落在这三种类型里，也取决于你的数据是否接近表中那个小样本。README 自己给出了最尖锐的提醒：别让分类器变成授权者。一次退款该不该执行，取决于账户状态和权限，而这些模型看不到。

给读者的实用建议

1. 如果你已经在对一部分流量跑 LLM 评委，README 提供的 LLM 模拟后端是试用这套 API 阻力最小的方式。README 说它现在就能用，但返回的概率只会是 0.00 或 1.00，而不是校准后的值。2. 先给自己的一批轨迹打上标签，再运行 `jevals calibrate`，然后才信任某个阈值。README 说，校准数据是最能帮到项目的贡献。

3. 不可逆操作要留一个人在回路里，并给挡在它们前面的闸门设置 `on_error="block"`。4. 照 README 的写法建议来：一个问题只问一件事；描述选项，而不是只给选项起名；状态要精简；当状态里可能没有答案时，加一个“证据不足”的选项。5. 在有人真实跑通之前，把框架适配器当作毛边较多的部分；把成本表当作作者的自述。规划之前，先在自己的轨迹上重复一遍对比。