今日学习:LangChain 团队评测Jev(对比GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6)
LangChain 团队最近做了一次对比实验：让 TypeSafe AI 发布的 System One 模型 Jev 来当 Agent 评测的 "裁判"，与 GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6 三个 LLM 裁判，在准确性、稳定性（可重复性）、延迟和成本四个维度上一较高下。
结论：Jev 与传统 LLM 裁判是两种完全不同的东西 —— 它不生成文本，而是直接返回结构化答案；在连续评分上，它的稳定性优势显著（质量分方差比三个 LLM 低 92~913 倍）；同时速度更快、成本更低（平均 0.44 秒 / 次、每次调用约 0.00035 美元）。
该团队也提醒大家：结果虽然乐观，但实验仍处于早期阶段。
一、Agent 评测的两条老路
目前 Agent 评测主要有两种方式：基于代码的评测（code-based）和 LLM 当裁判（LLM-as-a-judge）。两种方式各有局限。
基于代码的评测：便宜、快、可靠，主要短板是能力范围窄。传统函数需要固定的确定性输入，面对 Agent 行为这个 "充满随机性的世界" 就显得力不从心。举个例子：一个传统函数能判断 "Agent 第一次调用是否调用了某个工具"，但如果要判断 "Agent 是否随后用工具返回的结果成功回答了用户的问题"，它就很难做到。在开放式任务里，同一个工具结果可以有多种合理用法，把每种可接受的答案都编码成确定性逻辑，很快就会撞上代码评测 "范围窄" 的天花板。
LLM 裁判：用 LLM 对 Agent 轨迹的非结构化输入进行推理并打分。它能接受问题、轨迹、证据等非结构化输入，再通过提示词判断回复是否满足了用户请求。但正如任何 Agent 工程师都知道的，LLM 裁判并非完美方案 —— 它本质上是非确定性系统，很难作为可信测试装置的地基；而且比传统代码评测更慢、更贵。
什么是 Jev？
Jev 是 TypeSafe AI发布的新模型。严格来说它不是传统意义上的 LLM—— 它不生成文本。TypeSafe AI 团队称其为 "System One" 模型：
System One 模型是一类专为快速、结构化决策而构建的 AI 模型，软件可以直接使用它的输出。System One 模型会评估一个状态（state），并返回带类型的答案和概率。
按 TypeSafe AI 的说法，在分类任务上，Jev 的推理速度可达同类 LLM 的 200 倍，成本低至 400 分之一。
为什么 Jev 可能是个好裁判？
先看一个本质：Agent 评测是一个决策任务—— 给定 Agent 的状态和行为，给出一个能提供反馈的分数。Jev 正是为这种模式设计的：它针对结构化状态回答带类型的问题，返回带类型的答案和概率。而自回归模型则是通过逐 token 生成文本，才得出判断。在本次实验中，"决策优先" 的设计恰好对应了更低的延迟、更低的成本和更低的方差。
Jev 支持三种类型的问题
1. Choice（选择）：从选项中选一个，返回概率和置信度。 例："最终答案是否基于检索到的证据？" → 返回 0.0~1.0 的浮点数，1.0 表示完全基于证据。
2. Score（评分）：按有序量规给答案打分，返回概率和置信度。 例："这个答案有多大帮助？" → 返回 1（没有帮助）到 5（帮助很大）的量规分，外加概率和置信度。
3. Bool（布尔）：返回某个 "是 / 否" 判断为真的概率。 例："本次运行对应哪一种搜索结果？" → 返回 searched_appropriately、searched_unnecessarily 或 failed_to_search 之一，外加概率和置信度。
多个原子问题还可以针对同一个状态并行评估。
怎么测的：同一个 Agent、同一组问题、同一位 "人类裁判"
为了让四个裁判在公平条件下对比，Daniel Shea 和 Seán Roche 做了如下设计：
- 用 Deep Agents（LangChain 的开源 Agent 框架）构建了一个目标 Agent—— 天气查询 Agent；
- 把测试集定义为一个 LangSmith 数据集：5 个天气相关的请求；
- 对每个案例，固定保存天气 Agent 的完整输出，作为 LangSmith 中的固定样例；
- 每位裁判对 5 条固定运行记录给出两个信号：quality（连续分数）和 does_pass（是 / 否通过）；
- 为了把 "准不准" 和 "稳不稳" 分开衡量，人类评审员按同一套量规给每条固定回复打标签，作为 oracle（基准答案）。
核心指标口径：
- 准确度
- 方差Agent 行为完全相同时，裁判是否给出同样的判断。需要说明的是，方差低不等于准确 —— 一个裁判可能稳定地错。但在准确的前提下，低方差能让这份准确在生产环境中更可靠。
对照组为 GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6（通过 LangSmith Gateway 运行），Jev 通过 langchain-typesafe==0.0.1a2 访问。每个案例重复 100 次，计算逐案例方差，并与人类基准对比。
结果：准确、稳定、快、便宜
1. 准确度
以人类评审员的标签为基准，计算二元 "通过与不通过" 决策的准确度：
2. 稳定性（精度）
准确度回答 "是否同意人类基准"，精度则回答 "Agent 行为不变时，是否给出相同的质量分"。作者用各裁判评分的观测方差来衡量：
- Jev的每案例方差观测均值：0.0000149，在四个裁判中处于低位；
- Luna 高出 433 倍，Terra 高出 913 倍，Claude 高出 92 倍。
作者也坦诚指出：实验无法解释为什么 Jev 的分数波动更小。一个可能的假设是两者的优化目标不同 ——Jev 是经过训练、直接返回校准概率和带类型答案的决策模型；而自回归 LLM 裁判是先生成文本，再由评测流程把输出映射成分数。这种差异可能让 Jev 更适合这类边界明确的评测任务。但请注意：这是观测结果，并不能证明是训练目标导致了更低的方差。
3. 成本与延迟
- Jev 平均耗时 0.44 秒 / 次，成本约 0.00035 美元 / 次（本次实验总计 0.34 美元，而 Claude 为 28.17 美元）。
低成本的意义在于：大规模运行 Agent 评测变得现实。当单次裁判调用很贵时，团队不得不在 "覆盖多少" 和 "预算多少" 之间做取舍；而 Jev 的这个价格让取舍不再那么痛苦 —— 团队可以负担更多重复判断、更频繁的回归检查。这对线上评测尤其重要：更低的单次成本意味着可以在更大比例的生产轨迹上跑更多裁判，产生更密集的反馈信号。
作者还给出了一个量化视角：信号价值 = 二元基准一致性 × 二元可重复性。其中 "可重复性" 指对同一条轨迹做两次独立调用、得到相同结论的概率。这个公式会奖励既准确又稳定的裁判，同时惩罚 "稳定地错" 的裁判。
以一个每天产生 10,000 条轨迹的生产 Agent 为例，单次调用成本的差异会转化为显著的运营成本差异。像 Jev 这样高信号、低成本的裁判，有望解锁线上评测更大的价值：在更多生产轨迹上生成反馈、更早发现质量变化、当反馈趋势走偏时及时触发告警。
未来会出现新模式的 Agent 评测
过去，每一次 Agent 评测都伴随取舍：多跑一些 Agent、多评一些维度、多测一些改动，测试成本就会上涨，逼着团队减少评测。而这次实验中，Jev 的一次判断只要 0.00035 美元，同时准确度高、方差低 —— 这意味着构建者可以对每条 Agent 运行记录按多个聚焦标准逐一评测、对每次改动都做度量、在需要置信度的场合放心地重复判断。
这一点很重要，因为构建好的 Agent 离不开大量的测试与监控：评测越频繁，进入开发周期的有效反馈就越多。
该团队同时给出了两句提醒：
- 本次实验结果能否推广到其他 Agent 和生产工作流，还需要进一步验证；
- 低成本也可能放大错误—— 一个稳定地错的裁判，在规模效应下会产生大量坏反馈。工程师仍然需要把人工评审和 "裁判校准"（judge alignment）纳入工作流。
System One 这类新模型，有望让高质量评测变得 "充裕"，从而加速整个 Agent 开发生命周期：更多轨迹转化为反馈、更早发现回归、在构建 — 测试 — 监控 — 部署的循环里走得更快。解锁的不只是更便宜的评测，更是构建可靠 Agent 的更紧的反馈回路。
相关资料
- GitHub 仓库：https://github.com/danielgshea/jev-as-a-judge
- LLM 裁判通过 LangSmith Gateway 运行（GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6）；Jev 通过 langchain-typesafe==0.0.1a2 访问
- 依赖版本：Deep Agents 0.7.15、LangChain OpenAI 1.6.2、LangSmith 0.12.6、Tavily Python 0.8.3
- 未对 LLM 裁判设置 temperature、top-p、seed 或 max tokens，使用各提供方默认值；实验元数据中未记录 Jev 的服务版本
