JEV 场景方案
让一个大模型去评判另一个大模型,慢、贵,而且它报的「置信度」基本都挤在 95% 上下,分不出流。评判本身是个判断题,不是写作题——这正是 Jev 这类 System One 模型的形状。
文中所有数字来自我们自己跑的 2,390 题实测,方法和局限见 实测报告。
一次调用同时判断:有没有依据、答没答全、啰不啰嗦。
import { experimental_evaluate as evaluate } from 'ai';
const { answers } = await evaluate({
model: 'typesafe-ai/jev',
state, // 把用户问题、参考材料和 AI 回答粘进来
questions: {
grounded: { type: 'boolean', instructions: '回答里的所有事实性说法,是否都能在参考材料中找到依据?' },
complete: { type: 'boolean', instructions: '回答是否完整覆盖了用户问题?' },
concise: { type: 'score', instructions: '这个回答的表达效率如何?',
criteria: ['大量废话', '偏啰嗦', '长度合适', '精炼有力'] },
},
});检查回答有没有超出检索到的材料,并直接给出放行 / 重写 / 拦截的处置。
把 supported 的概率配一个阈值(比如 0.8)做自动放行,剩下的交给人——Jev 标为「没把握」的那一档正好是该转人工的题。
import { experimental_evaluate as evaluate } from 'ai';
const { answers } = await evaluate({
model: 'typesafe-ai/jev',
state, // 把检索到的材料和生成的回答粘进来
questions: {
supported: { type: 'boolean', instructions: '回答中的每一处具体信息,是否都由材料支持?' },
contradicts: { type: 'boolean', instructions: '回答中是否存在与材料直接矛盾的说法?' },
action: { type: 'choice', instructions: '基于材料的支持程度,应当如何处置这个回答?',
criteria: { accept: '可以直接放行给用户', revise: '需要补充或修正后再发', reject: '严重偏离材料,应当拦截重生成' } },
},
});A/B 对比两版输出,给出胜者和差距大小,用来做离线评测或线上灰度。
import { experimental_evaluate as evaluate } from 'ai';
const { answers } = await evaluate({
model: 'typesafe-ai/jev',
state, // 把同一个问题的两版回答粘进来
questions: {
winner: { type: 'choice', instructions: '哪一版回答对提问者更有用?',
criteria: { a: '回答 A 更好', b: '回答 B 更好', tie: '两版质量相当' } },
margin: { type: 'score', instructions: '两版之间的质量差距有多大?',
criteria: ['几乎没差别', '略有差距', '差距明显', '一版明显不合格'] },
},
});Jev 不写字,它只在你预先定义的答案空间里选,并返回概率。我们实测同一批 2,390 题:是/否判断准确率和 GPT-5.6 Sol 打平,但快 3 倍、便宜 88 倍,而且「自信地答错」的次数只有它的六分之一。
很多。实测一次塞 50 道题的耗时和问 1 道差不多,50 道里只有 2 道的判断和单独问时不一样。一次塞 100 道就开始不稳定了(全程耗时 1.0 秒到 8.2 秒都有)。
是/否题的期望校准误差(ECE)是 0.048,和 GPT-5.6 Sol 同级。多选题会过度自信:平均报 89% 的把握,实际只对 77%,用阈值时要留余量。
Jev 给不了理由,它只给类型化的答案和概率。常见做法是让 Jev 先判,只有被判为不合格或没把握的那一小部分再交给大模型写理由——省下的是绝大多数调用。
这些项目的源码里都能找到真正调用 Jev 的那一行。更多项目见 awesome-jev-verified。
上面的问题是固定的。想写自己的判据、自己的选项、自己的打分档位,去 试验场 里随便改。
打开试验场