如何评估 RAG 系统：指标、黄金数据集与回归测试
如果你无法衡量你的 RAG 系统，你就无法改进它。关键指标以及如何自行运行这些指标。
评估 RAG 系统意味着分别衡量两件事：检索找到正确上下文的效果如何，以及生成使用它的效果如何。可靠的方法是构建一个由问题/预期答案对组成的黄金评估集，用 recall@k、MRR 和 nDCG 等指标给检索打分，用忠实度和答案相关性（采用 RAGAS 风格或 LLM-as-judge 方法）给生成打分，并在每次做出改动时重新执行整个过程作为回归测试。本指南将详细介绍每个部分以及如何在自己的基础设施上运行。
这是自托管 RAG 完整指南的深入探讨。“演示看起来不错”不是评估——评估的存在正是为了取代它。
为什么必须将检索与生成分开
RAG 回答出错可能有两个完全不同的原因，它们有不同的修复方法：
- 检索失败。 从未获取正确的块，因此 LLM 没有机会。修复：分块、嵌入模型、k、混合搜索、重排序。
- 生成失败。 正确的块确实被检索到了，但 LLM 忽略了它、与它矛盾，或者用编造的细节填充回答。修复：提示词、模型、指令。
如果你只衡量最终答案，你就无法判断哪个环节出了问题，并且你会花一周时间调错地方。总是先分别给检索和生成打分，然后再看端到端的回答质量。这一项纪律就区分了那些能切实改进 RAG 的团队和那些盲目猜测的团队。
构建黄金/评估集
下游的一切都依赖于这个。黄金集是一组固定的测试用例，你会反复对照它评分。在接触指标之前先构建它。
每个用例需要：
- 一个问题，真实用户会实际提出的问题，使用他们真实的措辞（包括那些杂乱、缩写、充满错别字的问题）。
- 预期来源 — 应该检索哪个文档或块来回答它。这支撑你的检索指标。
- 参考答案 — 正确的答案，最好附带支持事实。这支撑生成指标。
目标一开始是 30–100 个用例。偏向覆盖率而非数量：包括简单查询、多文档问题、答案确实不在你的知识库中的问题（系统应回答“我不知道”——测试它是否如此），以及已知的边缘情况。从支持日志、用户访谈或你自己的使用中提取真实问题，而不是编造整洁的问题。由真实查询构建的黄金集价值是想象的黄金集的十倍。
将其以纯 JSON 或 CSV 格式保存在版本控制中。它是一个活的资产——每当你在生产中发现一个失败，就添加一个用例。
检索指标
这些指标仅评估检索器：给定查询，正确的块是否被召回，以及排名有多高？它们只需要你的预期来源标签，不需要 LLM，而且成本低且确定性高——随时运行它们。
- Recall@k — 在所有相关块中，有多大比例出现在前 k 个结果中？核心检索数字。如果 recall@k 很低，生成也无法挽救你；上下文根本不存在。
- Precision@k — 返回的前 k 个结果中，有多大比例是实际相关的？低精确率意味着你向提示中注入了大量噪声，这可能会混淆 LLM 并浪费上下文预算。
- MRR (Mean Reciprocal Rank) — 对第一个相关结果的排名取倒数的平均值。奖励将正确块放在靠近顶部的位置。当每个问题只有一个明确正确的来源时非常有效。
- nDCG (normalized Discounted Cumulative Gain) — 奖励相关结果，并且根据相关程度对它们排序，对较低位置进行折损。当相关性是分等级而非二元时，这是最完整的检索指标。
- Hit rate — 简单的“是否有任何相关块进入前 k 名，是/否”——一个有用、直观的完整性检查。
从 recall@k 和 MRR 开始。它们易于计算且能捕捉大多数检索问题。当你拥有分级相关性并且关心排序时，再使用 nDCG。
生成指标
这些指标对给定检索上下文后的答案进行评分。它们更模糊——很少有一个完全正确的字符串——这就是为什么 LLM-as-judge 方法在这里发挥价值。
- Faithfulness / groundedness — 答案中的每一个断言是否都得到检索上下文的支持？这是反幻觉指标，可以说是 RAG 中最重要的一个。一个答案可以相关且流畅，但仍然自信地编造上下文从未提及的事实。
- Answer relevance — 答案是否针对实际提出的问题，没有填充或回避？
- Context precision / context recall — RAGAS 风格的指标，判断检索到的上下文是否既相关（精确率）又充分（召回率）来回答问题，桥接了两个部分。
- Answer correctness — 答案是否与你的参考答案匹配？需要黄金集的参考答案。
Faithfulness 和 answer relevance 是首先要关注的两个指标。它们共同捕捉到两个最可怕的失败模式：编造事实和不回答问题。
指标一览
| 指标 | 衡量内容 | 需要 | 从这里开始？ |
|---|---|---|---|
| Recall@k | 相关块是否到达前 k | 预期来源标签 | 是 |
| Precision@k | 前 k 中有多少是相关的 | 预期来源标签 | 可选 |
| MRR | 第一个相关结果的排名 | 预期来源标签 | 是 |
| nDCG | 分级相关性 + 排序 | 分级标签 | 当排序重要时 |
| Faithfulness | 答案基于上下文 | 上下文 + 答案 (+ 评判者) | 是 |
| Answer relevance | 答案回答所问问题 | 问题 + 答案 (+ 评判者) | 是 |
| Context precision/recall | 上下文是否相关且充分 | 上下文 + 参考 | 可选 |
| Answer correctness | 答案匹配参考 | 参考答案 (+ 评判者) | 当你有参考时 |
RAGAS 风格与 LLM-as-judge 评估
你无法通过字符串匹配来评判忠实度——“API 密钥每 90 天轮换一次”和“密钥每季度轮换”是相同事实的不同表述。现代的答案是使用 LLM 作为评判者。
LLM-as-judge 向一个能力强的模型提供问题、检索到的上下文和答案，并附上评估标准：“答案中的每个断言是否都有上下文支持？打分 0–1，并指出不支持的断言。”评判模型以人类审核者的方式评估语义正确性，但在机器规模上。这是 2026 年忠实度和答案相关性评分背后的标准技术。
RAGAS 是最著名的开源框架，它封装了这一点。它提供了基于 LLM-as-judge 模式的开箱即用的忠实度、答案相关性和上下文精确率/召回率指标，因此你无需自己编写评判提示。其他框架（DeepEval、TruLens、promptfoo）覆盖了相似的领域；概念是相通的。
关于 LLM-as-judge 的两点注意事项：
- 评判者存在偏见——它可能偏爱较长的答案、自己的措辞风格或首先列出的内容。在盲目信任其分数之前，先用一组人工标注的样本验证评判者。
- 评判者消耗 tokens——如果你将上下文和答案发送到云评判者，你重新引入了自托管本应解决的数据出口问题。
自托管运行评估
如果你的栈的要点是数据永不离开你的基础设施，那么你的评估也必须尊重这一点。将每个块和答案发送到云评判者来评分“隐私”会适得其反。
好消息是：LLM-as-judge 并不需要前沿模型。一个通过 Ollama 运行的强大本地模型——一个能力较强的 8B–14B 指令模型，或者更大的模型（如果你的 VRAM 允许）——对于忠实度和相关性评分来说是一个完全适用的评判者，尤其是配合严格的评估标准和少样本示例。RAGAS 和 DeepEval 都允许你将它们的评判器指向本地的 Ollama 或 vLLM 端点，而不是 OpenAI。你的检索指标（recall@k、MRR、nDCG）完全不需要 LLM，可以在任何地方运行。
一个完全自托管的评估循环：
- 本地嵌入模型（与你的 RAG 使用相同的模型）和向量存储，用于检索评分。
- 一个通过 Ollama 或 vLLM 运行的本地评判模型，用于生成指标。
- 配置 RAGAS 或 DeepEval 调用这些本地端点。
没有任何数据离开你的机器。这与在 VPS 上构建私有 RAG 栈直接配对——将评估器指向同一个 Ollama 实例。
回归测试：真正的回报
评估不是一次性的成绩单。它的真正价值在于回归测试：一个在你每次改变时重新运行的数字，这样改进得到证明，回退在用户发现之前被捕获。
将它集成到你的工作流中：
- 在每一次有意义的变更时——新的分块策略、不同的嵌入模型、提示词调整、模型升级、添加重排序器——重新运行完整的黄金集并与上次基线比较。修复一个查询的更改通常会破坏其他五个；只有评估集能捕捉到这一点。
- 在 CI 中，理想情况下——如果 recall@k 或 faithfulness 低于你设定的阈值，则构建失败。这使“我们认为它更好了”变成了一道门。
- 跟踪趋势——记录每次运行的评分。观察 recall 在十次实验间从 0.6 攀升到 0.9，这样你才知道工作是真的有效，而不是凭感觉。
这闭合了与本集群中其他杠杆的循环：更改你的分块策略或嵌入模型，重新运行集，保留胜出的。没有评估集，每次变更都是掷硬币。有了它，每次变更都是测量。
常见问题
检索指标和生成指标之间有什么区别？ 检索指标（recall@k、MRR、nDCG）使用预期来源标签且无需 LLM，对是否获取了正确的上下文进行评分。生成指标（忠实度、答案相关性）通常通过 LLM 评判者来评估答案是否正确使用了上下文。分别衡量它们，这样你就知道该修复哪一部分。
我的 RAG 评估集应该多大？ 从 30–100 个用例开始，然后增长。覆盖率比原始数量更重要——包括简单查找、多文档问题，以及故意缺失答案的问题，这样你可以测试系统是否回答“我不知道”。每次遇到真实失败时追加一个用例。
什么是 RAGAS？ RAGAS 是一个流行的开源 RAG 评估框架，它基于 LLM-as-judge 模式提供了现成的指标——忠实度、答案相关性、上下文精确率和召回率。你可以将其评判模型指向本地的 Ollama 或 vLLM 端点，以保持评估完全自托管。
我能否在不将数据发送到 OpenAI 的情况下评估 RAG？ 可以。检索指标不需要 LLM。对于生成指标，通过 Ollama 或 vLLM 使用一个强大的本地模型作为评判者，并配置 RAGAS 或 DeepEval 调用它。没有任何数据离开你的基础设施，如果你自托管的理由是隐私，这点很重要。
LLM-as-judge 可靠吗？ 它足以驱动迭代，并且远远优于字符串匹配来解决模糊语义正确性问题——但评判者存在偏见（偏爱较长或首先列出的答案）。在信任之前，先用一组人工标注的样本验证评判者，并保持评估标准严格。
Aquila 是关于 私有、自托管 AI 搜索 的独立指南——基于你应该拥有自己的索引而不是租借它的信念。一个你无法衡量的 RAG 系统是一个你无法信任的 RAG 系统，而且你可以在不将数据交给任何人的情况下衡量它。探索更多指南或订阅新闻通讯以获取诚实、供应商中立的文章。掌控你自己的搜索。