RAGAS教程2026：30分钟搭好LLM驱动的RAG评估。改完分块、换了嵌入模型、加了重排，然后呢？

📜 目录

• 一、它算的到底是什么
• 二、准备三样东西
• 三、最小可运行代码
• 四、分数怎么读
• 五、接进日常工作流
• 六、指标之外还要看的东西
• 七、成本与坑
• 常见问题
• 相关文章

RAGAS教程2026：30分钟搭好LLM驱动的RAG评估

改完分块、换了嵌入模型、加了重排，然后呢？多数团队到这里就靠肉眼挑几个问题看看，觉得"好像好点了"就上线。RAGAS 解决的正是这件事：用裁判 LLM 给每条回答打分，把"感觉"变成可以对比的数字。

一、它算的到底是什么

RAGAS 的核心思路是拆解：一条 RAG 回答好不好，可以拆成几个互相独立的指标，每个指标让 LLM 当裁判，输出 0 到 1 的分数。

忠实度是最有价值的一个：它测的是幻觉。做法是把回答拆成若干断言，逐条判断能否从上下文推出，能推出的比例就是分数。上下文里没有依据却说得斩钉截铁，分数会立刻掉下来。

二、准备三样东西

1. 测试集：50 到 200 条真实问题。50 条能看到趋势，200 条能比较接近的方案差异。问题要从真实用户提问里抽，不要自己编
2. 裁判 LLM：任意够强的模型。可以用云端 API，也可以用本地大模型。裁判模型越强，打分越稳
3. 待评估的 RAG 链路：能批量跑问题，输出问题、回答、检索到的上下文

标准答案（ground truth）只有部分指标需要。只想看幻觉和切题程度，没标注也能开跑，这是 RAGAS 相比传统评估最实用的地方。

三、最小可运行代码

先收集数据：

import json

results = []
for q in questions:
    answer, contexts = my_rag(q)
    results.append({
        "question": q,
        "answer": answer,
        "contexts": contexts,          # list[str]，检索回来的片段
        "ground_truth": gt_map.get(q, ""),
    })

json.dump(results, open("rag_outputs.json", "w"), ensure_ascii=False)

再跑评估：

import json
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)

data = json.load(open("rag_outputs.json"))
dataset = Dataset.from_list(data)

result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)

print(result)
df = result.to_pandas()
df.to_csv("ragas_scores.csv", index=False)

裁判模型和嵌入模型的配置方式随版本变化较大（有通过 LangchainLLMWrapper 包装的，也有用 llm_factory 直接传 OpenAI 客户端的），按你装的版本查官方文档，别照抄一年前的写法。本地 Ollama 也能当裁判，配好 base_url 和模型名即可。

四、分数怎么读

分数不是越高越好，要看哪一项在拖后腿：

关键动作是看逐题分数，别看平均值。90 条 0.95 加 10 条 0.2，平均下来很漂亮，但那 10 条往往就是用户会投诉的场景。

五、接进日常工作流

一次评估只有参考意义，持续跑才有价值：

• 改一次测一次：任何影响检索或提示词的改动，跑同一套黄金集，分数掉了立刻回滚
• 进 CI：把评估脚本挂到流水线，核心指标低于基线就拦住合并
• 线上抽样：每天抽一部分真实请求跑评估，抓数据漂移。新文档进来、用户问法变了，分数会慢慢滑
• 固定裁判模型：换裁判等于换尺子，前后分数不可比。升级裁判模型时，用旧数据重跑一遍做校准

六、指标之外还要看的东西

数字能说明趋势，但有几件事指标测不出来，上线前仍要人工过一遍：

• 语气与合规：客服场景里，一个准确的答案配上生硬的措辞同样会引发投诉
• 引用是否可点：指标只看上下文相关性，不看引用链接是否指向正确段落
• 拒答是否得体：该拒答时拒了，但话术像机器报错，用户体感很差
• 多轮退化：单轮指标好看，聊到第五轮开始丢失上下文，这类问题要专门造多轮测试

建议在评估集里固定放十条"最不能出错"的问题，每次改动都看这十条的逐题结果。它们不能反映整体水平，但能防住灾难性回归。

七、成本与坑

• 裁判调用是按 token 计费的，指标数乘题目数乘长度就是总消耗。100 条题、4 个指标，一次几百次调用，先把测试集压到 50 条跑通再加
• 裁判模型和被测模型不要同族。同一个模型评自己，容易给自己打高分
• 上下文要传原始片段，不要传截断后的版本，否则忠实度会误判
• 中文场景下裁判模型的中文能力直接影响打分稳定性，选中文强的模型
• 分数是相对指标，不同测试集之间的分数不能横向比较，只能自己跟自己比

常见问题

Q：没有标准答案能评估吗？

A：能，忠实度和答案相关性不需要标准答案。上下文精确度和召回率需要，答案正确性也需要。

Q：为什么我的忠实度一直是 1.0？

A：回答很短、只复述上下文时容易满分。也可能是检索到的上下文和回答高度重合。这种情况看答案相关性和上下文召回率，别只看一项。

Q：本地模型当裁判靠谱吗？

A：7B 级别的模型打分波动较大，同一批数据跑两次结果可能差不少。要本地跑，选参数更大的模型，并且固定随机性。

Q：和 RAGAS 类似的还有哪些？

A：DeepEval、Arize Phoenix 都提供类似能力，侧重点不同：DeepEval 更接近单元测试风格，Phoenix 强在可观测和追踪。选一个能接进现有流程的就够。

相关文章

• RAG评估指标2026：忠实度、相关性、上下文精确度
• Python LLM 评估指标完整指南 2026：RAGAS 与 DeepEval 实战
• Arize Phoenix 2026：开源LLM可观测性与评估