用 Jev 做 RAG 评估：回答是否有据，流水线错在哪一步

这个 RAG 评估检查什么

上面的示例是一个退款问题。检索到的上下文说：退款在审批通过后 2 个工作日内发出，发卡机构通常还需要 5–10 个工作日入账。回答却说退款是即时的、审批当天就能到账。Jev 一次调用里回答四个问题：

这个示例有用，是因为两个环节的表现不一致。检索器完成了任务——到账时间就写在上下文里——模型却说反了。所以值得看的是：grounded 低到什么程度，context_relevant 是否仍然很高，以及 failure 是偏向 generation 还是 retrieval。只打一个"回答好不好"的分数，能标出这条回答有问题，却说不清该修流水线的哪一半。

短 state 加四个问题是一次标准评估，在 JevStation 上收 1 点。这些问题针对同一份 state 并行作答，同时问两个环节几乎不增加延迟。

怎么写好 RAG 评估问题

把"有据"和"正确"分开。 回答可能完全依据一份过时的文档，对用户来说却是错的；也可能凭常识答对了，却根本没有依据上下文。grounded 只问上下文是否支持。如果你还需要对照参考答案判断正误，另加一个问题——见用 Jev 当评判模型。

单独问上下文本身。 context_relevant 就是检索检查。它偏低时，说明生成环节手里根本没有材料，改 prompt 也没用。给它写上 criteria，让 Jev 知道界线在哪里：

{
  "type": "noul",
  "instructions": "Does `retrieved_context` contain the information needed to answer `question`?",
  "criteria": {
    "true": "A careful reader could answer the question using only the context.",
    "false": "The context is off-topic, incomplete or silent on what the question asks."
  }
}

每个失败选项都要写描述。 failure 这个 Choice 之所以好用，是因为每个选项都有一句描述。Jev 会按字面理解，像"检索不好"这样含糊的选项，等于让它去猜你的边界。

别指望问题之间在数值上自洽。 TypeSafe 说明同一请求里的问题彼此独立、概率不必加总一致——一个 Noul 和等价的 Choice 可能给出不同的数字。把 failure 和 context_relevant 放在一起看，而不是用一个去推算另一个。

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

从一次检查到评估流程里的一步

1. 建一份标注集。 50 到 200 组真实的"问题–上下文–回答"，每组由人标好是否有据，答错的再标明是哪一步失败。
2. 一次跑完。 把这些样本放进 CSV，用批量评估对每一行跑同一组问题，再拿概率和你的标注对比。
3. 定几个区间，而不是一个阈值。 明显有据的直接放行，中间区间重新生成或升级处理，其余拦下。
4. 记录模型版本。 每次响应都带有 model 字段。把它和每条结果一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
5. 从流水线里调用。 同样的评估可以用 API Key 通过 System One API 调用，扣点规则和试验台一样。

信任之前先验证

• 用自己的标注来衡量。 在退款示例上能分开好坏的阈值，不是你语料上的阈值。
• 留意检索文档里被注入的文字。 TypeSafe 的说明指出，专门用来引导模型的内容能左右答案。如果你的语料包含不可信的网页，同时用提示注入检测筛一遍。
• 非英文内容单独测试。 TypeSafe 的文档说明英文是准确率最好的语言。

哪些时候 Jev 不是合适的 RAG 评估工具

• 回答的对错取决于数字或日期。 "7 天内"和"5–10 个工作日"是否一致，是一道算术题，而 TypeSafe 把数学和日期比较列为弱项。把这些值提取出来，在代码里比较。
• 你把整个语料都当作上下文传进去。 TypeSafe 提醒，state 里无关的内容会降低准确率。只传检索器返回的段落；JevStation 的 state 上限是 24,000 字符。
• 你需要知道是哪一句没有依据。 把回答拆成若干说法，逐条对照对应段落跑引用核查。
• 你需要一段书面点评，给审核人看，或者反馈给生成模型。

用一个是非题做评判背后的证据——以及它在哪里失效——整理在用 Jev 当评判模型：一个是非题能抓住什么、会漏掉什么。