❝当你的 RAG 系统上线后，如何回答"效果好不好"这个问题？本文将介绍如何使用 RAGAS 框架进行自动化评估，并通过 LangFuse 实现评估过程的可观测性。❞
一、为什么需要 RAG 评估？
RAG（Retrieval-Augmented Generation）已成为 LLM 应用的标配架构。但在实际项目中，我们经常面临这些问题：
- 「检索质量如何衡量？」 召回的文档是否真的相关？
- 「生成质量如何评判？」 LLM 的回答是否忠于检索内容？
- 「端到端效果怎么追踪？」 调整参数后效果是变好还是变差了？
仅凭人工抽检，既不可扩展，也难以量化。我们需要一套「自动化、可量化、可追溯」的评估体系。
二、RAGAS：专为 RAG 设计的评估框架
RAGAS（Retrieval Augmented Generation Assessment）是目前最流行的 RAG 评估框架，它的核心思想是：「用 LLM 来评估 LLM」。
2.1 核心评估维度
RAGAS 从两个维度、四个指标来评估 RAG 系统：
┌─────────────────────────────────────────────────────────┐
│ RAG 评估体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 检索质量评估 │ │ 生成质量评估 │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Faithfulness │ │
│ │ Precision │ │ (忠实度) │ │
│ │ (上下文精确度) │ │ │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Answer │ │
│ │ Recall │ │ Relevancy │ │
│ │ (上下文召回率) │ │ (答案相关性) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘2.2 四大核心指标详解
Faithfulness（忠实度）
「定义」：生成的答案是否忠实于检索到的上下文？
「实现原理」：
RAGAS 的 Faithfulness 评估是一个「两阶段 LLM 调用」过程：
「第一阶段：声明提取（Statement Extraction）」
首先，RAGAS 使用 LLM 将答案拆解为原子级的事实声明（Atomic Facts）：
Prompt（简化版）：
Given a question and answer, create statements from the answer.
Question: RAG 技术是什么？
Answer: RAG 是 2020 年由 Facebook AI 提出的检索增强生成技术，
它通过检索外部知识库来增强大模型的回答能力。
→ LLM 输出：
statements:
- RAG 是 2020 年提出的
- RAG 由 Facebook AI 提出
- RAG 是检索增强生成技术
- RAG 通过检索外部知识库来增强回答能力「第二阶段：支撑验证（Verdict Generation）」
然后，针对每个声明，让 LLM 判断是否能从上下文中找到证据支撑：
Prompt（简化版）：
For each statement, determine if it can be inferred from the context.
Return 1 if supported, 0 if not supported.
Context: "RAG（Retrieval-Augmented Generation）是一种检索增强生成技术，
由 Facebook AI Research 在 2020 年提出..."
Statement: "RAG 由 Facebook AI 提出"
→ Verdict: 1 (supported)
Statement: "RAG 是目前最流行的技术"
→ Verdict: 0 (not supported, 上下文未提及"最流行")「最终计算」：
Faithfulness = 被支撑的声明数 / 总声明数
= 3 / 4 = 0.75「为什么这样设计？」
- 「原子化拆分」：避免整体判断时的模糊性，每个声明独立验证
- 「链式推理」：两阶段设计让 LLM 的推理过程更可控
- 「可解释性强」：可以追溯到具体哪个声明导致扣分
「示例」：
上下文：RAG 是 2020 年由 Facebook AI 提出的技术
答案：RAG 是 2020 年由 OpenAI 提出的技术
→ Faithfulness 较低（"OpenAI" 这个声明没有上下文支撑）Context Precision（上下文精确度）
「定义」：检索到的文档中，有多少是真正相关的？相关文档是否排在前面？
「实现原理」：
Context Precision 使用「逐文档判断 + 加权平均」的方式：
「第一步：逐文档相关性判断」
对于检索到的每个 context，让 LLM 判断是否与问题相关：
Prompt（简化版）：
Given a question and context, verify if the context is useful
to answer the question. Return 1 (useful) or 0 (not useful).
Question: "如何优化 RAG 的检索效果？"
Context_1: "RAG 检索优化包括：调整 chunk 大小、使用重排序..."
→ Verdict: 1 (relevant)
Context_2: "LangChain 是一个流行的 LLM 应用框架..."
→ Verdict: 0 (not relevant)
Context_3: "向量检索可以使用 HNSW 算法提高召回率..."
→ Verdict: 1 (relevant)「第二步：计算加权精确度」
采用「位置加权」的方式，排在前面的文档权重更高：
假设检索返回 [相关, 不相关, 相关]，即 verdicts = [1, 0, 1]
Precision@1 = 1/1 = 1.0 (第1个相关)
Precision@2 = 1/2 = 0.5 (前2个中有1个相关)
Precision@3 = 2/3 = 0.67 (前3个中有2个相关)
Context Precision = (1.0×1 + 0.5×0 + 0.67×1) / 2
= (1.0 + 0 + 0.67) / 2
= 0.835「公式本质」：
Context Precision = Σ(Precision@k × is_relevant@k) / 相关文档总数只有相关文档位置的 Precision@k 会被计入，不相关位置的贡献为 0。
「为什么这样设计？」
- 「位置敏感」：相关文档排在第 1 位比排在第 5 位得分更高
- 「惩罚噪声」：检索到大量不相关文档会显著降低分数
- 「符合实际」：用户通常只看前几个结果，排序质量很重要
「为什么重要」：如果召回了 5 个文档，但只有 1 个相关且排在最后，说明检索策略需要优化。
Context Recall（上下文召回率）
「定义」：回答问题所需的信息，是否都被检索到了？
「实现原理」：
Context Recall 需要「标准答案（ground_truth）「作为参照，采用」句子级分解 + 归因验证」：
「第一步：标准答案分解」
将 ground_truth 拆分为独立的信息单元（通常按句子）：
Ground Truth: "RAG 优化方法包括：1.调整 chunk 大小 2.使用重排序
3.优化 embedding 模型 4.引入 HyDE 技术"
→ 分解为：
- "调整 chunk 大小"
- "使用重排序"
- "优化 embedding 模型"
- "引入 HyDE 技术"「第二步：逐句归因验证」
对于每个信息单元，判断是否能从检索结果中找到支撑：
Prompt（简化版）：
Given a context and statement, determine if the statement
can be attributed to the context. Return 1 or 0.
Contexts: ["chunk 大小影响检索效果，建议 512-1024 tokens...",
"重排序可以使用 cross-encoder 模型提升精度..."]
Statement: "调整 chunk 大小"
→ Verdict: 1 (能在 context 中找到)
Statement: "引入 HyDE 技术"
→ Verdict: 0 (contexts 中未提及 HyDE)「最终计算」：
Context Recall = 能归因到 context 的句子数 / ground_truth 总句子数
= 3 / 4 = 0.75「为什么这样设计？」
- 「面向结果」：直接衡量"该有的信息是否都检索到了"
- 「粒度适中」：句子级比词级更有语义意义，比段落级更精确
- 「可指导优化」：低召回率直接说明检索环节有问题
「为什么重要」：召回率低意味着遗漏了关键信息，即使生成模型再强也无法给出完整答案。
「注意」：此指标需要提供 ground_truth（标准答案），因此更适合离线评估而非实时监控。
Answer Relevancy（答案相关性）
「定义」：生成的答案与原始问题的相关程度。
「实现原理」：
Answer Relevancy 采用了一个巧妙的「反向生成 + 语义相似度」方法：
「第一步：反向生成问题」
给定答案，让 LLM 反向生成可能的问题（通常生成 3 个）：
Prompt（简化版）：
Generate a question for the given answer.
Answer: "RAG 通过检索外部知识库来增强大模型的回答能力，
主要优势是减少幻觉、支持最新数据、来源可追溯。"
→ Generated Questions:
Q1: "RAG 技术有什么作用？"
Q2: "RAG 的主要优势是什么？"
Q3: "如何使用外部知识增强大模型？"「第二步：计算语义相似度」
使用 Embedding 模型计算原始问题与每个生成问题的余弦相似度：
Original Question: "RAG 技术的优点有哪些？"
cosine_similarity(Original, Q1) = 0.75
cosine_similarity(Original, Q2) = 0.92
cosine_similarity(Original, Q3) = 0.68「最终计算」：
Answer Relevancy = mean([0.75, 0.92, 0.68]) = 0.783「为什么这样设计？」
核心思想是：「如果答案高度相关，那么从答案反推出的问题应该与原始问题语义相近」。
- 「避免直接比较」：问题和答案的形式差异大，直接比较不可靠
- 「捕捉语义偏移」：答非所问的情况会导致生成的问题与原始问题差异大
- 「鲁棒性」：多次生成取平均，减少单次 LLM 输出的随机性
「示例」：
原始问题：RAG 技术的优点有哪些？
答案：RAG 是 2020 年由 Facebook AI 提出的。
→ 生成的问题可能是 "RAG 是什么时候提出的？" "谁发明了 RAG？"
→ 与原始问题语义差异大，Answer Relevancy 得分低「为什么重要」：防止"答非所问"——答案本身可能正确，但没有回答用户真正的问题。
2.3 四个指标的关系
理解这四个指标之间的关系，有助于定位问题：
问题 (Question)
│
▼
┌─────────────────┐
│ 检索系统 │
└────────┬────────┘
│
▼
检索结果 (Contexts) ←── Context Precision（精确度）
│ Context Recall（召回率）
│
▼
┌─────────────────┐
│ 生成模型 │
└────────┬────────┘
│
▼
答案 (Answer) ←── Faithfulness（基于 Context）
│ Answer Relevancy（基于 Question）
▼
用户满意度「诊断指南」：
症状可能原因应关注指标答案包含错误信息LLM 幻觉Faithfulness答案不完整检索遗漏Context Recall检索结果噪声大向量匹配不准Context Precision答案正确但跑题生成偏移Answer Relevancy
2.3 指标选择建议
场景推荐指标原因快速验证Faithfulness无需标注数据，直接评估幻觉程度检索优化Context Precision评估向量检索和重排序效果完整评估全部四个需要准备 ground_truth生产监控Faithfulness + Context Precision平衡评估全面性和成本
三、LangFuse：LLM 应用的可观测性平台
评估不是一次性的工作，而是持续的过程。我们需要：
- 追踪每次评估的结果
- 对比不同版本的效果
- 深入分析评估过程中 LLM 的调用
- 「统一管理评估用例集」
LangFuse 正是为此而生的开源可观测性平台。
3.1 LangFuse 核心能力
┌─────────────────────────────────────────────────────────┐
│ LangFuse 功能架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Tracing │ │ Scores │ │ Datasets │ │
│ │ 调用追踪 │ │ 评分管理 │ │ 用例管理 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 统一数据存储与可视化 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘「Tracing（调用追踪）」：记录每次 LLM 调用的完整链路，包括 prompt、response、耗时、token 消耗等。
「Scores（评分管理）」：存储和管理各类评估指标，支持自定义评分维度。
「Datasets（用例管理）」：管理评估数据集，支持版本控制、Schema 验证、从生产数据创建用例。
3.2 业务 LLM 接入 LangFuse
要实现"生产数据 → 测试用例"的闭环，首先需要将业务系统的 LLM 调用接入 LangFuse。
「接入方式一：LangChain Callback（推荐）」
如果你的 RAG 系统基于 LangChain，只需添加一行代码：
from langfuse.langchain import CallbackHandler
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
# 创建 LangFuse callback
langfuse_handler = CallbackHandler()
# 你的 RAG 链
llm = ChatOpenAI(model="gpt-4o-mini")
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
# 调用时传入 callback，自动记录到 LangFuse
response = qa_chain.invoke(
{"query": "什么是 RAG？"},
config={"callbacks": [langfuse_handler]}
)「接入方式二：OpenAI SDK 包装」
LangFuse 提供了 OpenAI SDK 的包装，零侵入接入：
# 只需改一行 import
from langfuse.openai import openai # 替换 import openai
# 后续代码完全不变
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "什么是 RAG？"}]
)
# 自动记录到 LangFuse「接入方式三：手动 Trace（完全控制）」
对于自定义 RAG 流程，可以手动创建 Trace：
from langfuse import Langfuse
client = Langfuse()
# 创建 trace（一次完整的用户请求）
trace = client.trace(
name="rag-query",
user_id="user-123",
metadata={"source": "web"},
input={"question": user_question}
)
# 记录检索步骤
retrieval_span = trace.span(
name="retrieval",
input={"query": user_question, "top_k": 5}
)
contexts = retriever.search(user_question) # 你的检索逻辑
retrieval_span.end(output={"contexts": contexts, "count": len(contexts)})
# 记录生成步骤
generation = trace.generation(
name="llm-generation",
model="gpt-4o-mini",
input={"question": user_question, "contexts": contexts}
)
answer = llm.generate(user_question, contexts) # 你的生成逻辑
generation.end(output={"answer": answer})
# 结束 trace
trace.update(output={"answer": answer})接入后，所有 LLM 调用都会出现在 LangFuse 的 「Traces」 页面。
3.3 从 Trace 生成用例集：生产数据闭环
这是 LangFuse 最强大的功能之一：「将线上真实请求转化为测试用例」。
「工作流程」：
┌─────────────────────────────────────────────────────────────┐
│ 生产数据 → 用例集 闭环流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户请求 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ RAG 系统 │ ← 接入 LangFuse（Callback/SDK） │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ LangFuse │ ← 自动记录：question, contexts, answer │
│ │ Traces │ ← 包含完整调用链路和耗时 │
│ └──────┬───────┘ │
│ │ │
│ ▼ 筛选 & 标注 │
│ ┌──────────────┐ │
│ │ 问题用例 │ ← 用户反馈差评 / 人工抽检发现问题 │
│ │ 典型用例 │ ← 高频问题 / 边界 Case │
│ │ 回归用例 │ ← 修复后的 Bug Case │
│ └──────┬───────┘ │
│ │ │
│ ▼ 一键添加 │
│ ┌──────────────┐ │
│ │ LangFuse │ ← 自动填充 input（question, contexts） │
│ │ Dataset │ ← 人工补充 ground_truth │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ RAGAS │ ← 持续评估、版本对比 │
│ │ 评估 │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘「操作方式一：UI 手动添加」
- 进入 LangFuse → Traces 页面
- 筛选目标 Trace（按时间、用户、标签等）
- 点击某条 Trace → 查看详情
- 点击 「"Add to dataset"」 按钮
- 选择目标 Dataset，确认 input/expected_output 映射
「操作方式二：批量添加」
在 Observations 表中勾选多条记录 → Actions → Add to dataset
「操作方式三：SDK 自动化」
结合用户反馈，自动将差评 Case 加入用例集：
from langfuse import Langfuse
client = Langfuse()
def on_user_feedback(trace_id: str, feedback: str, rating: int):
"""用户反馈回调"""
# 记录用户评分
client.create_score(
trace_id=trace_id,
name="user_rating",
value=rating,
comment=feedback
)
# 差评自动加入待审核用例集
if rating <= 2:
trace = client.get_trace(trace_id)
# 提取 trace 中的关键数据
question = trace.input.get("question")
contexts = extract_contexts_from_trace(trace) # 从 span 提取
answer = trace.output.get("answer")
# 加入待审核 Dataset
client.create_dataset_item(
dataset_name="rag-eval/pending-review",
input={
"question": question,
"contexts": contexts,
"answer": answer, # 原始答案，供对比
},
metadata={
"source_trace_id": trace_id,
"user_feedback": feedback,
"user_rating": rating,
"status": "pending_review"
}
)
print(f"差评 Case 已加入待审核: {trace_id}")「用例积累策略建议」：
用例来源优先级说明用户差评高真实痛点，必须覆盖人工抽检问题高质量问题的直接证据高频问题中覆盖核心场景边界 Case中长问题、特殊字符、多语言等修复后 Bug高防止回归随机采样低保持用例多样性
「这种闭环的价值」：
- 「零成本获取真实用例」：不需要人工编造，直接来自生产
- 「问题驱动」：差评 Case 优先，聚焦真实痛点
- 「持续积累」：用例集随业务运行自动增长
- 「可追溯」：每个用例都能追溯到原始 Trace
3.4 Dataset：统一管理评估用例集
LangFuse 的 Dataset 功能可以作为评估用例的「单一数据源」，解决以下痛点：
- 用例散落在各处（JSON 文件、Excel、代码里）
- 多人协作时用例版本混乱
- 无法追溯用例变更历史
- 生产问题难以快速转化为测试用例
「创建数据集」：
from langfuse import Langfuse
client = Langfuse()
# 创建数据集（支持文件夹组织）
client.create_dataset(
name="rag-eval/qa-dataset", # 使用 / 创建文件夹
description="RAG 系统评估用例集",
metadata={"version": "v1.0", "owner": "qa-team"}
)「上传用例」：
# 逐条创建用例
client.create_dataset_item(
dataset_name="rag-eval/qa-dataset",
input={
"question": "什么是 RAG？",
"contexts": ["RAG（Retrieval-Augmented Generation）是一种结合检索和生成的技术..."]
},
expected_output={
"answer": "RAG 是检索增强生成技术",
"ground_truth": "RAG 是检索增强生成技术，通过检索外部知识来增强 LLM 回答"
},
metadata={"category": "基础概念", "difficulty": "easy"}
)
# 批量创建
test_cases = [
{"question": "RAG 有什么优点？", "ground_truth": "减少幻觉、支持最新数据、来源可追溯"},
{"question": "如何优化 RAG 检索？", "ground_truth": "调整 chunk 大小、使用重排序、优化 embedding"},
]
for case in test_cases:
client.create_dataset_item(
dataset_name="rag-eval/qa-dataset",
input={"question": case["question"]},
expected_output={"ground_truth": case["ground_truth"]}
)「从生产数据创建用例」：
LangFuse 支持将线上 Trace 直接转化为测试用例，这是其最强大的功能之一：
生产流程：
用户提问 → RAG 系统回答 → 记录到 LangFuse Trace
↓
发现问题用例
↓
一键添加到 Dataset（带上 contexts、answer）
↓
持续积累用例3.5 从 Dataset 读取用例运行 RAGAS 评估
核心思路：从 LangFuse Dataset 获取用例 → 转换为 RAGAS 格式 → 执行评估 → 结果回写 LangFuse。
from langfuse import Langfuse
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, context_precision, context_recall
def run_ragas_from_langfuse(dataset_name: str, run_name: str):
"""从 LangFuse Dataset 读取用例并运行 RAGAS 评估"""
client = Langfuse()
# 1. 获取数据集
dataset = client.get_dataset(dataset_name)
# 2. 提取用例数据
questions, answers, contexts, ground_truths = [], [], [], []
for item in dataset.items:
questions.append(item.input["question"])
# contexts 可能在 input 或需要实时检索
if"contexts"in item.input:
contexts.append(item.input["contexts"])
# answer 可能在 expected_output 或需要实时生成
if"answer"in (item.expected_output or {}):
answers.append(item.expected_output["answer"])
if"ground_truth"in (item.expected_output or {}):
ground_truths.append(item.expected_output["ground_truth"])
# 3. 如果没有预存 answer/contexts，需要实时调用 RAG 系统
ifnot answers ornot contexts:
answers, contexts = run_rag_system(questions) # 你的 RAG 系统
# 4. 构建 RAGAS Dataset
ragas_dataset = Dataset.from_dict({
"question": questions,
"answer": answers,
"contexts": contexts,
"ground_truth": ground_truths if ground_truths elseNone
})
# 5. 执行评估
metrics = [faithfulness, context_precision]
if ground_truths:
metrics.append(context_recall)
result = evaluate(ragas_dataset, metrics=metrics)
# 6. 将评估结果关联回 Dataset Run
for idx, item in enumerate(dataset.items):
# 创建 dataset run item
run_item = item.link(
trace_or_observation=None, # 可关联到 trace
run_name=run_name
)
# 记录各指标分数
for metric_name in result.to_pandas().columns:
if metric_name notin ["question", "answer", "contexts", "ground_truth"]:
client.create_score(
name=f"ragas_{metric_name}",
value=float(result.to_pandas()[metric_name].iloc[idx]),
dataset_run_item_id=run_item.id
)
return result
# 使用示例
result = run_ragas_from_langfuse(
dataset_name="rag-eval/qa-dataset",
run_name="ragas-eval-v1.2"
)「完整工作流」：
┌─────────────────────────────────────────────────────────┐
│ LangFuse + RAGAS 评估流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ LangFuse │ │
│ │ Dataset │ ← 团队协作管理用例 │
│ │ (用例集) │ ← 从生产 Trace 添加 │
│ └──────┬───────┘ ← 版本控制 & Schema 验证 │
│ │ │
│ ▼ get_dataset() │
│ ┌──────────────┐ │
│ │ Python 脚本 │ → 提取 question/ground_truth │
│ │ │ → 调用 RAG 获取 answer/contexts │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ RAGAS │ → 执行评估 │
│ │ evaluate │ → 计算四大指标 │
│ └──────┬───────┘ │
│ │ │
│ ▼ create_score() │
│ ┌──────────────┐ │
│ │ LangFuse │ → 存储评估分数 │
│ │ Scores │ → 关联到 Dataset Run │
│ │ + Runs │ → 可视化对比不同版本 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘「这种方案的优势」：
优势说明用例集中管理所有用例在 LangFuse 统一维护，告别散落的 JSON 文件版本追溯每次用例变更自动记录，可回溯历史版本生产联动线上问题可一键转化为测试用例结果可视化评估分数自动关联到 Dataset Run，支持多版本对比团队协作多人可同时维护用例集，有权限控制
3.6 与 RAGAS 的其他集成方式
LangFuse 提供两种与 RAGAS 的集成方式：
「方式一：Callback 集成」
通过 LangChain 的 Callback 机制，自动追踪 RAGAS 评估过程中所有的 LLM 调用：
from langfuse.langchain import CallbackHandler
callback = CallbackHandler()
result = evaluate(dataset, metrics=metrics, callbacks=[callback])「方式二：Score API 集成」
将评估结果作为 Score 记录到 LangFuse：
from langfuse import Langfuse
client = Langfuse()
client.create_score(
trace_id=trace_id,
name="ragas_faithfulness",
value=0.95,
)四、生产环境最佳实践
4.1 评估数据集构建
「标注数据来源」：
- 用户真实提问日志
- 产品经理整理的 FAQ
- 领域专家标注的测试集
「数据集格式建议」：
{
"samples": [
{
"question": "如何申请退款？",
"ground_truth": "登录账户 → 订单中心 → 选择订单 → 申请退款",
"category": "售后服务",
"difficulty": "easy"
}
]
}「数据集规模建议」：
- 开发验证：20-50 条
- 版本发布：100-200 条
- 全面评估：500+ 条
4.2 评估策略
「开发阶段」：
# 快速验证，只用 faithfulness
config = RAGASConfig(
use_faithfulness=True,
use_answer_relevancy=False,
use_context_precision=False,
use_context_recall=False,
)「发布前评估」：
# 完整评估
config = RAGASConfig(
use_faithfulness=True,
use_answer_relevancy=True,
use_context_precision=True,
use_context_recall=True,
)「生产监控」：
- 定期抽样评估（每天/每周）
- 设置指标阈值告警
- 对比不同版本的评估趋势
4.3 成本优化
RAGAS 评估需要调用 LLM，成本可能较高。优化建议：
- 「使用小模型评估」：评估不一定需要最强的模型，gpt-4o-mini 通常足够
- 「按需选择指标」：不需要每次都跑全部指标
- 「采样评估」：大规模数据集可以随机采样
- 「缓存机制」：相同输入可以复用评估结果
4.4 CI/CD 流水线集成：质量门禁
将 RAGAS 评估集成到 CI/CD 流水线，作为「提测和发布前的必检项」，从根本上保障 RAG 系统质量。
「整体架构」：
┌─────────────────────────────────────────────────────────────────┐
│ CI/CD + RAGAS 质量门禁流程 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 开发提交代码 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ CI 触发 │ ← Git Push / PR / Tag │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 构建 & 测试 │ ← 单元测试、代码检查 │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ RAGAS 评估阶段 │ │
│ │ ┌────────────────────────────────────┐ │ │
│ │ │ 1. 从 LangFuse 拉取用例集 │ │ │
│ │ │ 2. 部署临时 RAG 服务 │ │ │
│ │ │ 3. 执行 RAGAS 评估 │ │ │
│ │ │ 4. 对比基线，判断是否通过 │ │ │
│ │ └────────────────────────────────────┘ │ │
│ └──────┬───────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 通过门禁？ │─ No →│ 阻断流水线 │→ 通知开发修复 │
│ └──────┬───────┘ └──────────────┘ │
│ │ Yes │
│ ▼ │
│ ┌──────────────┐ │
│ │ 部署到环境 │ ← 测试环境 / 生产环境 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘「分环境门禁策略」：
环境触发条件用例集阈值指标提测PR 到 developci-dataset (50条)0.70faithfulness + precision预发PR 到 mainfull-dataset (200条)0.75全部 4 个指标生产Tag 发布full-dataset (200条)0.80全部 + 回归用例必须 100%
「门禁失败处理流程」：
门禁失败
│
▼
┌──────────────────────────────────────────────────┐
│ 1. 查看 CI 日志，定位低分用例 │
│ 2. 在 LangFuse Dataset Run 中查看详细对比 │
│ 3. 分析原因： │
│ - faithfulness 低 → 检查 Prompt / 上下文长度 │
│ - precision 低 → 检查检索策略 / embedding │
│ - relevancy 低 → 检查问题理解 / 生成偏移 │
│ 4. 修复后重新提交，触发新一轮评估 │
└──────────────────────────────────────────────────┘「与 LangFuse 联动的价值」：
- 「结果可追溯」：每次 CI 评估结果都关联到 LangFuse Dataset Run，可查看历史趋势
- 「版本对比」：直观对比不同 commit 的评估分数变化
- 「问题定位」：点击低分用例直接跳转到详情，快速定位问题
- 「用例演进」：CI 发现的新问题可一键加入用例集，持续加固
4.5 常见问题排查
「Q: Faithfulness 分数很低怎么办？」
A: 检查以下几点：
- LLM 是否出现幻觉，编造了上下文中不存在的内容
- Prompt 是否强调了"根据给定内容回答"
- 上下文长度是否过短，信息不足
「Q: Context Recall 很低怎么办？」
A: 检索环节可能有问题：
- 向量检索的 top_k 是否太小
- embedding 模型是否适合你的领域
- 是否需要引入重排序（rerank）
「Q: 评估结果不稳定怎么办？」
A: 这是 LLM 评估的固有问题：
- 设置 temperature=0 提高确定性
- 多次评估取平均值
- 使用更大的测试集
五、总结
本文介绍了如何使用 RAGAS + LangFuse 构建 RAG 评估系统：
- 「RAGAS」 提供了四个核心指标：Faithfulness、Context Precision、Context Recall、Answer Relevancy，覆盖检索和生成两个维度。每个指标都有明确的 LLM 评估实现逻辑，可解释性强。
- 「LangFuse」 不仅提供可观测性能力，还能通过 「Dataset」 功能统一管理评估用例集，支持版本控制、生产数据联动、团队协作。
- 「集成方案」：
- 用 LangFuse Dataset 管理评估用例
- 用 RAGAS 执行自动化评估
- 用 Callback 追踪评估过程中的 LLM 调用
- 用 Score API 将结果回写并可视化
- 「CI/CD 质量门禁」：将 RAGAS 评估集成到流水线，作为提测和发布前的必检项，自动阻断低于阈值的版本发布。
RAG 系统的优化是一个持续迭代的过程。有了自动化评估体系，我们才能：
- 量化每次改动的效果
- 快速定位问题环节
- 建立效果基线和目标
- 「确保每次发布都经过质量验证」
- 让生产问题快速转化为测试用例
「参考资料」：
- RAGAS 官方文档：https://docs.ragas.io/
- LangFuse 官方文档：https://langfuse.com/docs
- LangFuse Dataset：https://langfuse.com/docs/datasets/overview