❝当你的 RAG 系统上线后,如何回答"效果好不好"这个问题?本文将介绍如何使用 RAGAS 框架进行自动化评估,并通过 LangFuse 实现评估过程的可观测性。❞
RAG(Retrieval-Augmented Generation)已成为 LLM 应用的标配架构。但在实际项目中,我们经常面临这些问题:
仅凭人工抽检,既不可扩展,也难以量化。我们需要一套「自动化、可量化、可追溯」的评估体系。
RAGAS(Retrieval Augmented Generation Assessment)是目前最流行的 RAG 评估框架,它的核心思想是:「用 LLM 来评估 LLM」。
RAGAS 从两个维度、四个指标来评估 RAG 系统:
┌─────────────────────────────────────────────────────────┐
│ RAG 评估体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 检索质量评估 │ │ 生成质量评估 │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Faithfulness │ │
│ │ Precision │ │ (忠实度) │ │
│ │ (上下文精确度) │ │ │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Context │ │ Answer │ │
│ │ Recall │ │ Relevancy │ │
│ │ (上下文召回率) │ │ (答案相关性) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
「定义」:生成的答案是否忠实于检索到的上下文?
「实现原理」:
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
「为什么这样设计?」
「示例」:
上下文:RAG 是 2020 年由 Facebook AI 提出的技术
答案:RAG 是 2020 年由 OpenAI 提出的技术
→ Faithfulness 较低("OpenAI" 这个声明没有上下文支撑)
「定义」:检索到的文档中,有多少是真正相关的?相关文档是否排在前面?
「实现原理」:
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。
「为什么这样设计?」
「为什么重要」:如果召回了 5 个文档,但只有 1 个相关且排在最后,说明检索策略需要优化。
「定义」:回答问题所需的信息,是否都被检索到了?
「实现原理」:
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 采用了一个巧妙的「反向生成 + 语义相似度」方法:
「第一步:反向生成问题」
给定答案,让 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
「为什么这样设计?」
核心思想是:「如果答案高度相关,那么从答案反推出的问题应该与原始问题语义相近」。
「示例」:
原始问题:RAG 技术的优点有哪些?
答案:RAG 是 2020 年由 Facebook AI 提出的。
→ 生成的问题可能是 "RAG 是什么时候提出的?" "谁发明了 RAG?"
→ 与原始问题语义差异大,Answer Relevancy 得分低
「为什么重要」:防止"答非所问"——答案本身可能正确,但没有回答用户真正的问题。
理解这四个指标之间的关系,有助于定位问题:
问题 (Question)
│
▼
┌─────────────────┐
│ 检索系统 │
└────────┬────────┘
│
▼
检索结果 (Contexts) ←── Context Precision(精确度)
│ Context Recall(召回率)
│
▼
┌─────────────────┐
│ 生成模型 │
└────────┬────────┘
│
▼
答案 (Answer) ←── Faithfulness(基于 Context)
│ Answer Relevancy(基于 Question)
▼
用户满意度
「诊断指南」:
症状 | 可能原因 | 应关注指标 |
|---|---|---|
答案包含错误信息 | LLM 幻觉 | Faithfulness |
答案不完整 | 检索遗漏 | Context Recall |
检索结果噪声大 | 向量匹配不准 | Context Precision |
答案正确但跑题 | 生成偏移 | Answer Relevancy |
场景 | 推荐指标 | 原因 |
|---|---|---|
快速验证 | Faithfulness | 无需标注数据,直接评估幻觉程度 |
检索优化 | Context Precision | 评估向量检索和重排序效果 |
完整评估 | 全部四个 | 需要准备 ground_truth |
生产监控 | Faithfulness + Context Precision | 平衡评估全面性和成本 |
评估不是一次性的工作,而是持续的过程。我们需要:
LangFuse 正是为此而生的开源可观测性平台。
┌─────────────────────────────────────────────────────────┐
│ LangFuse 功能架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Tracing │ │ Scores │ │ Datasets │ │
│ │ 调用追踪 │ │ 评分管理 │ │ 用例管理 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 统一数据存储与可视化 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
「Tracing(调用追踪)」:记录每次 LLM 调用的完整链路,包括 prompt、response、耗时、token 消耗等。
「Scores(评分管理)」:存储和管理各类评估指标,支持自定义评分维度。
「Datasets(用例管理)」:管理评估数据集,支持版本控制、Schema 验证、从生产数据创建用例。
要实现"生产数据 → 测试用例"的闭环,首先需要将业务系统的 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」 页面。
这是 LangFuse 最强大的功能之一:「将线上真实请求转化为测试用例」。
「工作流程」:
┌─────────────────────────────────────────────────────────────┐
│ 生产数据 → 用例集 闭环流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户请求 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ RAG 系统 │ ← 接入 LangFuse(Callback/SDK) │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ LangFuse │ ← 自动记录:question, contexts, answer │
│ │ Traces │ ← 包含完整调用链路和耗时 │
│ └──────┬───────┘ │
│ │ │
│ ▼ 筛选 & 标注 │
│ ┌──────────────┐ │
│ │ 问题用例 │ ← 用户反馈差评 / 人工抽检发现问题 │
│ │ 典型用例 │ ← 高频问题 / 边界 Case │
│ │ 回归用例 │ ← 修复后的 Bug Case │
│ └──────┬───────┘ │
│ │ │
│ ▼ 一键添加 │
│ ┌──────────────┐ │
│ │ LangFuse │ ← 自动填充 input(question, contexts) │
│ │ Dataset │ ← 人工补充 ground_truth │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ RAGAS │ ← 持续评估、版本对比 │
│ │ 评估 │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
「操作方式一:UI 手动添加」
「操作方式二:批量添加」
在 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 | 高 | 防止回归 |
随机采样 | 低 | 保持用例多样性 |
「这种闭环的价值」:
LangFuse 的 Dataset 功能可以作为评估用例的「单一数据源」,解决以下痛点:
「创建数据集」:
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)
↓
持续积累用例
核心思路:从 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,支持多版本对比 |
团队协作 | 多人可同时维护用例集,有权限控制 |
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,
)
「标注数据来源」:
「数据集格式建议」:
{
"samples": [
{
"question": "如何申请退款?",
"ground_truth": "登录账户 → 订单中心 → 选择订单 → 申请退款",
"category": "售后服务",
"difficulty": "easy"
}
]
}
「数据集规模建议」:
「开发阶段」:
# 快速验证,只用 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,
)
「生产监控」:
RAGAS 评估需要调用 LLM,成本可能较高。优化建议:
将 RAGAS 评估集成到 CI/CD 流水线,作为「提测和发布前的必检项」,从根本上保障 RAG 系统质量。
「整体架构」:
┌─────────────────────────────────────────────────────────────────┐
│ CI/CD + RAGAS 质量门禁流程 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 开发提交代码 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ CI 触发 │ ← Git Push / PR / Tag │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 构建 & 测试 │ ← 单元测试、代码检查 │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ RAGAS 评估阶段 │ │
│ │ ┌────────────────────────────────────┐ │ │
│ │ │ 1. 从 LangFuse 拉取用例集 │ │ │
│ │ │ 2. 部署临时 RAG 服务 │ │ │
│ │ │ 3. 执行 RAGAS 评估 │ │ │
│ │ │ 4. 对比基线,判断是否通过 │ │ │
│ │ └────────────────────────────────────┘ │ │
│ └──────┬───────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 通过门禁? │─ No →│ 阻断流水线 │→ 通知开发修复 │
│ └──────┬───────┘ └──────────────┘ │
│ │ Yes │
│ ▼ │
│ ┌──────────────┐ │
│ │ 部署到环境 │ ← 测试环境 / 生产环境 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
「分环境门禁策略」:
环境 | 触发条件 | 用例集 | 阈值 | 指标 |
|---|---|---|---|---|
提测 | PR 到 develop | ci-dataset (50条) | 0.70 | faithfulness + precision |
预发 | PR 到 main | full-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 联动的价值」:
「Q: Faithfulness 分数很低怎么办?」
A: 检查以下几点:
「Q: Context Recall 很低怎么办?」
A: 检索环节可能有问题:
「Q: 评估结果不稳定怎么办?」
A: 这是 LLM 评估的固有问题:
本文介绍了如何使用 RAGAS + LangFuse 构建 RAG 评估系统:
RAG 系统的优化是一个持续迭代的过程。有了自动化评估体系,我们才能:
「参考资料」: