用 Jev 做引用核查：这个说法有原文支持吗？

这个引用核查检查什么

上面的示例是一个看起来和原文很接近的说法。原文说：2023 年一项针对 1,200 名 IT 负责人的调查发现，38% 计划增加可观测性工具的投入，12% 计划削减。说法却是：根据该调查，大多数 IT 负责人计划增加可观测性投入。Jev 一次调用里回答两个问题：

这个说法方向没错——计划增加的人比计划削减的多——但"大多数"比 38% 能支撑的程度更强。这正是研究综述和各类总结里最常见的问题：不是凭空捏造，而是在转述中把结论稍微拉大了一点。所以值得看的是 supported 的概率在 partially 和 unsupported 之间怎么分配，以及 overstated 有多高。只给"支持 / 不支持"两个答案，会把这种差别藏起来。

短 state 加两个问题是一次标准评估：在 JevStation 上收 1 点。

怎么写好核查问题

一个 state 只放一个说法。 如果 claim 字段里有三句话，一个概率就得同时覆盖三句。在代码里拆开复合说法，每一条对照它引用的段落单独检查。

传段落，不传整篇论文。 只传引用指向的那一段。TypeSafe 提醒，state 里无关的内容会降低准确率，所以裁剪原文本身就是核查的一部分。

把每一级支持程度写清楚。 supported 这个 Choice 把 partially 定义为"原文只支持说法的一部分"。Jev 会按字面理解，如果你的编辑标准把带限定词的说法也算作有支持，就在 criteria 里写明。

给"夸大"单独写 criteria。 用 true 和 false 各一句描述，把界线说清楚：

{
  "type": "noul",
  "instructions": "Does `claim` overstate what `source` says?",
  "criteria": {
    "true": "The claim uses stronger wording, a larger scope or more certainty than the source.",
    "false": "The claim says the same as the source, or less."
  }
}

更多关于问法的内容，见设计 Jev 能回答的问题。

从一个说法到审核流程里的一步

1. 抽出"说法–原文"对。 对稿件里的每一处引用，把那句话和它引用的段落配成一对。配对是普通代码的工作，不需要问 Jev。
2. 一起跑。 把这些配对放进 CSV，用批量评估对每一行跑同样的两个问题。
3. 排序，而不是自动驳回。 明显有支持且没有夸大的直接放行，其余连同概率一起交给编辑，最可疑的排在最前面先看。
4. 记录模型版本。 每次响应都带有 model 字段。把它和每条结果一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
5. 从你的工具里调用。 同样的评估可以用 API Key 通过 System One API 调用，扣点规则和试验台一样。

信任之前先验证

• 用自己核查过的说法。 收集 50 到 200 条已经由人核查过的说法，看 Jev 的概率在哪里把它们分开。
• 测试问法。 TypeSafe 的说明显示，一个 Noul 和等价的 Choice 可能给出不一致的结果。在 overstated 上调好的阈值，不要直接搬到问同一件事的 Choice 上。
• 最终判断留给人。 校准是在一组答案上衡量的，不保证每一个答案都对，所以把每条结果当作复核的优先级，而不是定论。

哪些时候 Jev 不是合适的核查工具

• 说法的对错取决于算术。 "大多数"能不能形容 38%，是措辞问题；38% 乘以 1,200 是否"超过 450"，是算术题，而 TypeSafe 把算术列为弱项。把数字提取出来在代码里比较，再把结果放进 state。
• 说法涉及日期比较。 拿"在政策变更之前"去对照一份带日期的原文，是日期比较，同样是文档列出的弱项。
• 原文非常长。 JevStation 的 state 上限是 24,000 字符。面对完整报告，先找到相关段落。
• 你要端到端检查一条 RAG 回答。 用 RAG 评估，它还会判断是检索还是生成出了错。
• 你需要一段书面解释，给作者或读者看。

这些局限背后的证据整理在设计 Jev 能回答的问题，而用 Jev 当评判模型讲的是一个是非题在真实评判任务上的表现。