RAG 评估工具:回答是否有据,流水线错在哪一步
贴上用户问题、检索器返回的上下文和模型写出的回答。Jev 会告诉你:回答是否以上下文为依据、上下文里有没有需要的信息、问题回答得怎么样,以及——如果出了错——该怪检索还是该怪生成。
用你自己的文本试试
修改示例后,免费注册即可运行:送 50 点,无需信用卡。
场景
检查 RAG 回答是否有检索内容支撑,并判断问题出在检索还是生成。
可以随意修改,所选模型会针对这里的内容回答该场景的问题。
Jev 实际返回了什么
下面是上方示例未经修改的输出,采集自线上 API。
{
"question": "How long do refunds take to reach my card?",
"retrieved_context": "Refunds are issued within 2 business days of approval. Card issuers usually post them within 5–10 business days after that.",
"answer": "Refunds are instant — you will see the money back on your card the same day we approve it."
}grounded
noulIs every claim in the answer supported by the retrieved context?
context relevant
noulDoes the retrieved context contain the information needed to answer the question?
answer quality
scoreHow well does the answer address the question?
- 0 · Wrong99%
- 1 · Poor1%
- 2 · Partial0%
- 3 · Good0%
- 4 · Complete0%
置信度 99%
failure
choiceIf the answer is wrong, where did the pipeline fail?
generation
- generation100%
- none0%
- retrieval0%
置信度 100%
采集于 2026-10-09 · 0.21 秒 · jev-1.13.0
这个 RAG 评估检查什么
上面的示例是一个退款问题。检索到的上下文说:退款在审批通过后 2 个工作日内发出,发卡机构通常还需要 5–10 个工作日入账。回答却说退款是即时的、审批当天就能到账。Jev 一次调用里回答四个问题:
| 问题 | 类型 | 返回什么 |
|---|---|---|
grounded | Noul | 回答中每个说法都有 retrieved_context 支持的概率 |
context_relevant | Noul | 上下文包含回答所需信息的概率 |
answer_quality | Score | 在 Wrong → Poor → Partial → Good → Complete 上的位置和置信度 |
failure | Choice | none、retrieval、generation 各自的概率,以及置信度 |
这个示例有用,是因为两个环节的表现不一致。检索器完成了任务——到账时间就写在上下文里——模型却说反了。所以值得看的是: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 能回答的问题。
从一次检查到评估流程里的一步
- 建一份标注集。 50 到 200 组真实的"问题–上下文–回答",每组由人标好是否有据,答错的再标明是哪一步失败。
- 一次跑完。 把这些样本放进 CSV,用批量评估对每一行跑同一组问题,再拿概率和你的标注对比。
- 定几个区间,而不是一个阈值。 明显有据的直接放行,中间区间重新生成或升级处理,其余拦下。
- 记录模型版本。 每次响应都带有
model字段。把它和每条结果一起记下,版本变化时重新校验阈值——JevStation 在部署层固定模型,不需要你在请求里指定。 - 从流水线里调用。 同样的评估可以用 API Key 通过 System One API 调用,扣点规则和试验台一样。
信任之前先验证
- 用自己的标注来衡量。 在退款示例上能分开好坏的阈值,不是你语料上的阈值。
- 留意检索文档里被注入的文字。 TypeSafe 的说明指出,专门用来引导模型的内容能左右答案。如果你的语料包含不可信的网页,同时用提示注入检测筛一遍。
- 非英文内容单独测试。 TypeSafe 的文档说明英文是准确率最好的语言。
哪些时候 Jev 不是合适的 RAG 评估工具
- 回答的对错取决于数字或日期。 "7 天内"和"5–10 个工作日"是否一致,是一道算术题,而 TypeSafe 把数学和日期比较列为弱项。把这些值提取出来,在代码里比较。
- 你把整个语料都当作上下文传进去。 TypeSafe 提醒,state 里无关的内容会降低准确率。只传检索器返回的段落;JevStation 的 state 上限是 24,000 字符。
- 你需要知道是哪一句没有依据。 把回答拆成若干说法,逐条对照对应段落跑引用核查。
- 你需要一段书面点评,给审核人看,或者反馈给生成模型。
用一个是非题做评判背后的证据——以及它在哪里失效——整理在用 Jev 当评判模型:一个是非题能抓住什么、会漏掉什么。
常见问题
- 怎么用 Jev 评估 RAG 回答是否有据?
- 把问题、检索到的上下文和回答放进同一个 state,问一个 Noul,比如"回答里的每个说法是否都有检索上下文支持?"。Jev 返回成立的概率,你可以对每条回答设阈值。
- Jev 怎么区分检索失败和生成失败?
- 直接问它。示例里用了一个 Choice,有 none、retrieval、generation 三个选项,每个都有一句描述;另外再用一个 Noul 问上下文是否包含所需信息。两个结果都记下来,哪一步有问题就修哪一步。
- 一次 RAG 检查多少钱?
- 在 JevStation 上,state 不超过 8,000 字符、问题不超过 5 个,就是一次标准评估,收 1 点,所以示例里的 4 个问题收 1 点。上下文更长或问题超过 5 个收 3 点。评估失败会自动退还。
- Jev 能分别检查长回答里的每个说法吗?
- 一个 Noul 只给整条回答一个概率。如果你需要知道是哪一句没有依据,就在代码里把回答拆成若干说法,逐条对照对应的段落检查——这正是引用核查工具做的事。
- Jev 会解释回答为什么没有依据吗?
- 不会。Jev 返回的是带类型的答案——概率和置信度——而不是文字理由。需要给审核人解释的场景,保留一个生成式模型。
相关页面
把它接进你的流程
注册即送 50 点,保存自己的问题集,并通过 API 调用同样的评估。