AI 事实核查：这个说法有原文支持吗？

{
  "source": "The 2023 survey of 1,200 IT leaders found that 38% planned to increase spending on observability tools, while 12% planned cuts.",
  "claim": "According to the survey, most IT leaders planned to increase observability spending."
}

三类 AI 事实核查工具

搜"AI 事实核查"能找到的工具回答的是不同的问题，先弄清你需要哪一种：

本工具属于第三类。它从不联网搜索：你给它说法所引用的那段原文，它只判断这一对。这比联网搜索窄，但对引用来说这才是关键问题——原文真的说了文本声称它说的话吗？而且答案可以核实，因为证据就在 state 里。

这个引用核查检查什么

上面的示例是一个看起来和原文很接近的说法。原文说：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 能回答的问题。

核查 AI 生成的文本

各大学图书馆关于核查 AI 输出的指南给出的建议一致：先确认引用的来源存在，再阅读来源，确认它确实说了 AI 声称的内容。第二步正是本工具的用武之地。

1. 确认来源存在。 语言模型会编造参考文献。先确认每个引用的网址、DOI 或标题都能打开。这是查找而不是判断，用代码或人工完成。
2. 找到那段原文。 打开来源，摘出说法所依据的段落。如果根本找不到支持它的段落，答案已经有了。
3. 对照原文核查说法。 把两者贴到这里，或者用批量页面把草稿里的每一对都跑一遍。unsupported 或 overstated 概率高的，放到审核队列最前面。
4. 处理没有引用的说法。 先找到来源（联网搜索型核查工具或人工搜索都可以），再到这里对照核查。

如果答案出自你自己的检索流水线，RAG 评估会对整个答案做同类核查，还会告诉你问题出在检索还是生成。

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

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 当评判模型讲的是一个是非题在真实评判任务上的表现。