RAGAS技术指南-RAG评测从入门到解读
面向企业知识库问答、制度规程助手等 RAG 应用的离线评测方法论整理。
1. RAGAS 是什么：名字、含义与定位
1.1 名字怎么组成
RAGAS 一般理解为：
| 字母 | 英文 | 含义 |
|---|
| R | Retrieval | 检索：从知识库取出与问题相关的文档片段 |
| A | Augmented | 增强：把检索结果注入大模型上下文 |
| G | Generation | 生成：大模型基于上下文产出最终回答 |
| AS | Assessment / Score | 评估 / 打分：对上述 RAG 链路做量化评测 |
合起来：面向 RAG（检索增强生成）管道的自动化评估框架，不是又一个聊天模型，而是一套「指标 + 评判模型/向量模型」的工具链。
1.2 解决什么问题
传统 NLP 指标（BLEU、ROUGE）适合「有标准译文的生成」，但 RAG 场景更关心：
- 回答有没有胡说（是否被检索内容支撑）？
- 检索到的片段对不对、全不全？
- 回答是否扣题（是否真在答用户问的那件事）？
RAGAS 用 LLM-as-Judge（大模型当裁判）+ Embedding 相似度 等方式，把这些维度拆成可计算的 0～1 分数，便于：
- 改 prompt / 改知识库前后对比；
- 回归测试（金标准集 + 批量
evaluate）； - 与 Langfuse 等追踪工具结合，做实验管理。
1.3 官方资源
| 资源 | 链接 |
|---|
| GitHub 仓库 | https://github.com/explodinggradients/ragas |
| 官方文档（稳定版） | https://docs.ragas.io/en/stable/ |
| 指标总览 | https://docs.ragas.io/en/stable/concepts/metrics/ |
| Faithfulness | https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/ |
| Answer Relevancy | https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/answer_relevance/ |
| Context Precision | https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/ |
| Context Recall | https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/ |
| 论文（ESANN 2024） | https://arxiv.org/abs/2309.15217 |
安装示例：
1
| pip install "ragas>=0.2.14" datasets langchain-openai
|
2. RAGAS 在 RAG 链路中的位置
2.1 端到端链路与指标挂载点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| 问题 (question)
│
▼
┌─────────────────┐
│ 检索系统 │
└────────┬────────┘
│
▼
检索结果 (contexts) ◄── context_precision（精确度）
│ context_recall（召回率）
│
▼
┌─────────────────┐
│ 生成模型 │
└────────┬────────┘
│
▼
答案 (answer) ◄── faithfulness（对照 contexts）
│ answer_relevancy（对照 question）
▼
最终用户体验
|
2.2 评测所需额外字段
1
2
3
| 评测时通常还需要：
• ground_truth：人工写的「期望回答要点」（context_recall 等强烈建议）
• ground_truth_contexts：期望被检索命中的关键词/片段描述
|
典型评测数据集字段：
| RAGAS 字段 | 常见来源 |
|---|
question | 金标准测试集 + 线上/离线实际用户问法 |
contexts | 检索模块返回的文档片段列表（或平台 API 返回的引用块） |
answer | RAG 应用最终生成的回答文本 |
ground_truth | 人工标注的参考答案要点 |
ground_truth_contexts | 期望被检索命中的关键词或段落描述 |
示例数据（脱敏，单条样本结构示意）：
示例 1 — 应急类（信息不完整，应先澄清再作答）
1
2
3
4
5
6
7
8
9
10
11
| {
"question": "发生区域停电事故怎么办？",
"contexts": [
"《生产安全事故应急预案》第 3.2 节：II 级事件由应急指挥部启动响应……",
"第 3.1 节：I 级为影响全厂主系统；II 级为单区域；III 级为局部设备……",
"现场人员紧急撤离：警报连续 3 声，按就近路线疏散至集合点……"
],
"answer": "请先说明停电影响区域（A 区/B 区/全厂）及当前负荷百分比。不同等级对应不同响应程序……",
"ground_truth": "应先确认影响区域与关键运行参数；信息不足时提示用户补充，再按 I/II/III 级给出对应处置步骤，不得编造联系方式。",
"ground_truth_contexts": ["响应分级", "II 级", "III 级", "影响区域"]
}
|
示例 2 — 清单类（检索需命中物资/台账片段）
1
2
3
4
5
6
7
8
9
10
| {
"question": "应急物资储备清单包含哪些类别？",
"contexts": [
"应急仓库储备：防护用品类、消防类、医疗类、通讯类……",
"附录 C《应急物资台账》：铁锹 90 把、救生衣 110 件……（节选）"
],
"answer": "储备类别包括防护用品、消防、医疗、通讯等；主要明细见附录台账……",
"ground_truth": "应列出储备类别（防护、消防、医疗等）及主要物资种类与数量，并提示相关附录名称。",
"ground_truth_contexts": ["应急物资", "储备类别", "附录", "台账"]
}
|
示例 3 — 联系类（短事实，易与固定话术混淆）
1
2
3
4
5
6
7
8
9
| {
"question": "应急值班电话是多少？",
"contexts": [
"《应急联系表》节选：本单位值班室 010-XXXX-XXXX；备用线路 021-XXXX-XXXX……"
],
"answer": "本单位应急值班电话：010-XXXX-XXXX；备用：021-XXXX-XXXX。",
"ground_truth": "应如实列出知识库中的值班电话；检索不到则标注未检索到，不得编造号码。",
"ground_truth_contexts": ["值班电话", "应急联系表", "010-XXXX"]
}
|
实际入库多为 JSONL（每行一条）或 CSV；contexts 在文件中常以字符串数组存储，评测前需与 RAGAS Dataset 字段对齐。
3. 指标总览
| 指标 | 中文常称 | 关注维度 | 主要评判对象 | 典型依赖 |
|---|
| faithfulness | 忠实度 / 事实一致性 | 生成（依赖检索片段） | 回答是否被 contexts 支撑 | 评判 LLM |
| answer_relevancy | 答案相关性 | 生成 | 回答是否扣题 | 评判 LLM + Embedding |
| context_precision | 上下文精确度 | 检索 | 检索排序：相关片段是否靠前 | 评判 LLM（+ 参考 answer） |
| context_recall | 上下文召回率 | 检索 | 检索是否覆盖「该检到的内容」 | 评判 LLM + ground_truth |
分数范围一般为 0～1，越高越好（部分版本对 NaN 表示该条评判失败）。
3.1 RAG 评估体系总览（双维度 × 四指标）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| ┌─────────────────────────────────────────────────────────┐
│ RAG 评估体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 检索质量评估 │ │ 生成质量评估 │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Faithfulness │ │
│ │ Precision │ │ (忠实度) │ │
│ │ (上下文精确度) │ │ │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Answer │ │
│ │ Recall │ │ Relevancy │ │
│ │ (上下文召回率) │ │ (答案相关性) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
|
3.2 症状 → 指标诊断指南
| 症状 | 可能原因 | 应关注指标 |
|---|
| 答案包含错误/编造信息 | LLM 幻觉、检索未支撑 | faithfulness |
| 答案不完整、漏要点 | 检索遗漏关键片段 | context_recall |
| 检索结果噪声大、无关片段靠前 | 向量匹配/排序不佳 | context_precision |
| 答案正确但跑题、泛泛而谈 | 生成偏移、未扣题 | answer_relevancy |
3.3 指标选择建议
| 场景 | 推荐指标 | 原因 |
|---|
| 快速验证幻觉 | faithfulness | 可不依赖 ground_truth，直接看是否「有据」 |
| 检索调参/重排序 | context_precision | 反映 Top-K 排序与噪声 |
| 完整离线回归 | 四个全开 | 需准备 ground_truth / ground_truth_contexts |
| 成本敏感的生产抽检 | faithfulness + context_precision | 平衡覆盖面与 LLM 调用成本 |
4. Faithfulness（忠实度）
4.1 评判什么
衡量 模型回答中的陈述，能否从本次检索到的 contexts 中推断出来。
不关心回答是否「比标准答案写得好」，只关心：有没有脱离检索内容的幻觉。
4.2 实现原理：两阶段 LLM 调用
1
2
3
4
5
6
7
8
9
10
11
12
13
| 输入：question, answer, contexts[]
┌──────────────────────────────────────────────────────────┐
│ 阶段一：声明提取（Statement Extraction） │
│ 评判 LLM 将 answer 拆为原子级事实声明（claims） │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 阶段二：支撑验证（Verdict Generation） │
│ 对每条 claim：能否从 contexts 推断？ → 1 支持 / 0 不支持 │
└────────────────────────────┬─────────────────────────────┘
▼
faithfulness = 支持数 / claim 总数 → 0～1
|
流程示意：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| ┌─────────────┐
│ answer │
└──────┬──────┘
│ 阶段一：拆分 claims
▼
[ claim_1, claim_2, claim_3, ... ]
│
│ 阶段二：逐条对照 contexts[]
▼
┌─────────────────────────┐
│ claim_i 可被 context 支撑？ │
└─────────────┬───────────┘
│
┌───────────┴───────────┐
▼ ▼
verdict=1 verdict=0
支持 不支持
│ │
└───────────┬───────────┘
▼
支持数 / 总 claim 数
|
脱敏示例（应急分级）：
1
2
3
4
5
6
7
8
9
10
11
12
13
| Question: 区域停电应按哪一级响应？
Answer: II 级由应急指挥部启动；III 级为局部设备；值班电话 010-XXXX-XXXX。
→ 阶段一 claims：
- II 级由应急指挥部启动
- III 级为局部设备
- 值班电话为 010-XXXX-XXXX
Context 仅含分级条款、未含电话表：
- claim 1、2 → verdict 1
- claim 3 → verdict 0（编造或未检索到）
→ faithfulness = 2/3 ≈ 0.67
|
为什么这样设计？
- 原子化拆分：避免「整体感觉对」的模糊判断，可追溯到具体哪条陈述扣分
- 链式两阶段：推理步骤可控，便于 Langfuse 等工具记录中间结果
- 可解释性强：低分样本可直接列出「unsupported claims」清单
4.3 结果解读
| 分数 | 含义 |
|---|
| 高（≥0.8） | 回答大体有据可查，幻觉风险相对较低 |
| 中（0.5～0.8） | 部分表述缺乏检索支撑，或 claim 拆分过细导致判严 |
| 低（<0.5） | 大量内容无法从 contexts 印证，可能存在编造或检索失败 |
4.4 分低的常见原因与优化
| 原因 | 表现 | 优化策略 |
|---|
| 检索未命中关键片段 | contexts 里没有支撑依据 | 优化分块、同义词、混合检索；表格/附录单独入库 |
| 模型「发挥」过多 | 回答超出 context 的概括/推断 | 收紧 system prompt：「仅依据知识库，不得编造」 |
| 应先澄清参数却直接作答 | 如缺时间/地点仍罗列全部等级说明 | 与金标准策略对齐，改提示词自检清单 |
| 评测时 context 裁剪过狠 | 仅保留少量 top 片段参与评判 | 适当增加参与评测的 context 条数或长度上限 |
| 评判 LLM 输出被截断 | faithfulness 报 max_tokens | 增大评判模型 max_tokens、缩短参与评测的 answer/context |
5. Answer Relevancy（答案相关性）
5.1 评判什么
衡量 最终回答与用户原始问题在语义上是否一致——答的是不是用户问的那件事。
与 faithfulness 正交：可以「很忠实但跑题」，也可以「很扣题但幻觉」。
5.2 实现原理：反向生成 + 语义相似度
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 输入：question, answer（不需要 contexts）
┌──────────────────────────────────────────────────────────┐
│ 阶段一：反向生成问题 │
│ 给定 answer，评判 LLM 生成「可由该答案回答的问题」 │
│ 默认 strictness=3 → 一次请求 n=3，得 Q1', Q2', Q3' │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 阶段二：Embedding 余弦相似度 │
│ sim(Qi', user_question)，再取均值 │
└────────────────────────────┬─────────────────────────────┘
▼
answer_relevancy ∈ [0, 1]
|
流程示意：
1
2
3
4
5
6
7
8
9
10
11
12
13
| user_question ─────────────────────────────┐
│ │
│ cosine similarity
│ (Embedding)
▼ ▼
┌─────────┐ 阶段一：反向生成 ┌──────────────────────────┐
│ answer │ ──────────────────► │ Q1', Q2', Q3' (n=3) │
└─────────┘ 评判 LLM └────────────┬─────────────┘
│
strictness=1 时仅 Q1'（n=1）
│
▼
mean(sim(Qi', question))
|
脱敏示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 原始问题：应急物资储备应包含哪些类别？
Answer: 储备包括防护用品、消防、医疗、通讯等；明细见附录台账……
→ 反向生成：
Q1': 应急物资有哪些储备类别？
Q2': 台账附录在哪里查？
Q3': 防护用品包括什么？
cosine(原始, Q1') ≈ 0.91 → 扣题
cosine(原始, Q2') ≈ 0.62 → 偏子问题
cosine(原始, Q3') ≈ 0.55
→ answer_relevancy ≈ mean([0.91, 0.62, 0.55])
|
跑题反例：
1
2
3
4
5
| 原始问题：应急值班电话是多少？
Answer: 请先说明停电影响区域及负荷百分比……（未答电话）
→ 反向问题偏向「如何分级响应」「影响区域」等
→ 与原始问题语义差异大 → answer_relevancy 偏低
|
为什么这样设计？
- 避免直接比 Q-A：问句与答案形式差异大，直接相似度不可靠
- 捕捉语义偏移：答非所问时，反推问题与原始问题距离变远
- 多次取平均：strictness=3 降低单次 LLM 随机性（不支持 n>1 时用 strictness=1）
5.3 strictness 与 API 的 n
| 配置含义 | 说明 |
|---|
| strictness = 3（默认） | 一次要 3 条反向问句，需 OpenAI 兼容网关支持 n=3 |
| strictness = 1 | n=1 模式：只生成 1 条，适配仅支持 n=1 的评判 API |
在 RAGAS 中通过 AnswerRelevancy(strictness=1|3) 实例化指标即可切换。
注意：answer_relevancy 必须配置 Embedding 模型，与评判 LLM 可共用同一 OpenAI 兼容 base_url。
5.4 结果解读
| 分数 | 含义 |
|---|
| 高 | 回答在语义上紧扣用户问题 |
| 低 | 答非所问、泛泛而谈、或只答了子问题 |
5.5 分低的常见原因与优化
| 原因 | 优化策略 |
|---|
| 回答冗长偏题 | 提示词要求「先直接回答问题」 |
| 多意图只答其一 | 拆解复合问题或引导用户澄清 |
| strictness=1 方差大 | 可接受；或换支持 n=3 的 API 求稳 |
| 未配置 embedding | 为 RAGAS 单独指定 embedding 模型与密钥 |
| 与 faithfulness 混淆 | 扣题但不忠实 → 升 relevancy、降 faithfulness，应修检索/防编造 |
6. Context Precision（上下文精确度）
6.1 评判什么
衡量 检索结果排序质量：与问题/答案相关的 chunk 是否排在前面，无关内容是否靠后。
强调 Precision@K 与排序，不是「有没有检到」而是「排在前面的是否够准」。
6.2 实现原理：逐文档判断 + 位置加权
1
2
3
4
5
6
7
8
9
10
11
12
13
| 输入：question, contexts[]（按检索分数排序）
┌──────────────────────────────────────────────────────────┐
│ 第一步：逐条 context 相关性判定（LLM） │
│ 每条 → verdict: 1 有用 / 0 无用 │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 第二步：位置加权的 Precision@k 汇总 │
│ 相关片段越靠前，贡献越大；前排噪声会显著拉低分数 │
└────────────────────────────┬─────────────────────────────┘
▼
context_precision ∈ [0, 1]
|
流程示意：
1
2
3
4
5
6
7
8
| contexts 排序: [ C1, C2, C3, C4, C5 ]
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
LLM 判定: 1 0 1 0 0 (verdicts)
│
▼
Precision@k 仅对「相关位置」加权计入
无关项靠前 → 拉低整体分
|
脱敏计算示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Question: 如何优化制度规程类知识库的检索效果？
C1: 分块建议按条款/附录单元…… → verdict 1
C2: 无关：通用 LLM 框架介绍…… → verdict 0
C3: 可提高相似度阈值、减少 top-K 噪声 → verdict 1
verdicts = [1, 0, 1]
Precision@1 = 1/1 = 1.00
Precision@2 = 1/2 = 0.50
Precision@3 = 2/3 ≈ 0.67
context_precision = (1.00×1 + 0.50×0 + 0.67×1) / 2 ≈ 0.835
（公式：Σ Precision@k × is_relevant@k）/ 相关文档数
|
为什么这样设计？
- 位置敏感：相关片段排第 1 位比排第 5 位得分更高
- 惩罚噪声：大量无关 chunk 进入 Top-K 会明显降分
- 贴近产品：用户与模型主要消费前几条检索结果
6.3 结果解读
| 分数 | 含义 |
|---|
| 高 | Top-K 检索结果干净，噪声少 |
| 低 / 0 | 前排大量无关片段，或评判与金标准关键词不对齐 |
6.4 分低的常见原因与优化
| 原因 | 优化策略 |
|---|
| Embedding 与领域语料不匹配 | 换领域模型或微调向量模型 |
| 分块过大/过小 | 按段落、条款、附录单元重新 chunk |
| 相似度阈值过低 | 提高检索相似度阈值、减少 top-K 中的噪声 |
金标准 ground_truth_contexts 过粗 | 评测用关键词改为真实文档中的表述 |
| 评测样本与线上检索条数不一致 | 对齐线上 top_k 与离线参与评测的 context 数量 |
7. Context Recall（上下文召回率）
7.1 评判什么
衡量 检索是否覆盖了解答所需的全部信息（相对 ground_truth 或 ground_truth_contexts）。
回答「该检到的有没有都检到」，偏 Recall。
7.2 实现原理：句子级分解 + 归因验证
1
2
3
4
5
6
7
8
9
10
11
12
13
| 输入：question, contexts[], ground_truth
┌──────────────────────────────────────────────────────────┐
│ 第一步：标准答案分解 │
│ 将 ground_truth 拆为独立信息单元（常为句子/要点） │
└────────────────────────────┬─────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ 第二步：逐条归因 │
│ 每条 Ti 能否在 contexts 中找到依据？ → 1 / 0 │
└────────────────────────────┬─────────────────────────────┘
▼
context_recall = 可归因条数 / ground_truth 要点总数
|
流程示意：
1
2
3
4
5
6
7
8
9
10
11
12
13
| ground_truth 要点: [ T1, T2, T3, T4 ]
│
▼
每条 Ti 能否归因到 contexts[]？
│
┌────────────┴────────────┐
▼ ▼
verdict=1 verdict=0
能覆盖 未覆盖
│ │
└────────────┬────────────┘
▼
覆盖数 / 要点总数
|
脱敏示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
| ground_truth: 应列出储备类别（防护、消防、医疗等）及主要物资种类；
并提示附录台账名称；信息不足时应引导用户补充参数。
→ 分解要点：
T1: 储备类别（防护、消防、医疗等）
T2: 主要物资种类与数量
T3: 附录台账名称
T4: 信息不足时引导补充
contexts 仅命中制度总则、未命中附录台账：
T1→1, T2→0, T3→0, T4→0
→ context_recall = 1/4 = 0.25
|
注意：依赖 ground_truth，更适合离线金标准回归；线上实时监控可优先 faithfulness + context_precision。
为什么这样设计？
- 面向结果：直接回答「答题所需知识是否都被检到」
- 粒度适中：句子/要点级比词级更有语义，比整段更细
- 可指导检索：低分往往指向缺文档、分块不当或 top-K 过小
7.3 结果解读
| 分数 | 含义 |
|---|
| 高 | 检索覆盖了答题所需知识 |
| 低 / 0 | 关键文档未进 Top-K，或要点与 chunk 语义对不上 |
7.4 分低的常见原因与优化
| 原因 | 优化策略 |
|---|
| 知识库缺文档 | 补录制度正文、附录、联系表等源文档 |
| 关键词与正文表述不一致 | 建 QA 对、增加同义词索引 |
| 检索 top-K 过小 | 适当增加检索条数（注意成本与噪声） |
| 多跳/附录未二次检索 | 工作流增加「先定位附录再拉全文」等步骤 |
| 金标准过细 | ground_truth_contexts 用知识库中真实可检索表述 |
8. 指标之间如何一起看
8.1 检索 × 生成 四象限
1
2
3
4
5
6
7
8
| 检索差 检索好
┌─────────────────┬─────────────────┐
生成差 │ recall/prec 低 │ faithfulness 低 │
│ 先修知识库/检索 │ 先修 prompt/防编造│
├─────────────────┼─────────────────┤
生成好 │ 整体不可用 │ answer_relevancy│
│ │ 可再抠交互策略 │
└─────────────────┴─────────────────┘
|
一种常见的解读模式（示意，非特定系统实测）：
| 指标 | 若 faithfulness 高、context_* 低 | 说明 |
|---|
| faithfulness | 偏高（如 0.8+） | 生成内容多能在已检索片段中找到依据 |
| context_precision / recall | 偏低（如 0.4 左右） | 检索排序或召回与金标准对齐不足 |
典型结论：生成侧相对可控，检索链路往往是首要优化点；清单类查询、联系类查询、需先补全参数再作答类查询，常是低分高发场景。
9. 如何实施离线 RAGAS 评测（通用步骤）
9.1 离线评测流水线
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| ┌─────────────────────────────────────────────────────────────┐
│ 离线 RAGAS 评测流水线 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Step 1 金标准集（JSONL/CSV） │
│ question + ground_truth [+ ground_truth_contexts] │
│ │ │
│ ▼ │
│ Step 2 批量调用 RAG API（detail=true 等） │
│ 采集 answer、contexts[] │
│ │ │
│ ▼ │
│ Step 3 组装 RAGAS Dataset │
│ │ │
│ ▼ │
│ Step 4 配置评判 LLM + Embedding（answer_relevancy 必需） │
│ │ │
│ ▼ │
│ Step 5 ragas.evaluate(metrics=[...]) │
│ │ │
│ ▼ │
│ Step 6 导出 CSV/JSON + Langfuse Scores（批次对比） │
│ │
└─────────────────────────────────────────────────────────────┘
|
9.2 与 Langfuse 的配合（可选）
1
2
3
4
5
6
7
8
9
10
11
12
| ┌─────────────────────────────────────────────────────────┐
│ LangFuse 在评测侧的典型角色 │
├─────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Tracing │ │ Scores │ │ Datasets │ │
│ │ 单次评测链路 │ │ RAGAS 分数 │ │ 金标准版本 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ └────────────────┴────────────────┘ │
│ ▼ │
│ 统一存储：对比 prompt/检索 调参前后 │
└─────────────────────────────────────────────────────────┘
|
业务 RAG（如 FastGPT）不必先嵌入 Langfuse SDK；在 eval/ 脚本侧对每条样本上报 trace + score 即可实现离线可观测。
环境配置注意点：
| 项 | 建议 |
|---|
| answer_relevancy + DeepSeek 等 | strictness=1（仅支持 n=1） |
| answer_relevancy / context_* | 必须配置 embedding 模型 |
| faithfulness 超长回答 | 限制参与评测的 context/answer 长度、提高 max_tokens |
10. 延伸阅读
- 金标准质量决定评测上限：宜按业务场景（清单类、联系类、需澄清参数类）持续迭代测试集。
- 离线 RAGAS 看分布与回归，在线 Tracing 看单条请求，二者互补。
RAGAS API 与指标细节以 官方文档 为准。
