从一次知识库回答说起
假设你在维护一个企业内部的知识库问答系统。员工输入“我们公司的年假政策是什么？”，系统从文档库中检索出几段文本，交给大模型生成回答。表面上看，这个流程并不复杂，但一旦回答出错，你很难判断问题出在哪一环：是检索器没有找到包含政策的文档，还是模型忽略了检索到的内容，自行编造了一套规则？
更麻烦的是，你无法靠人工逐条检查所有查询。企业知识库的查询量可能每天上千条，领域覆盖人事、财务、技术规范，人工标注既慢又贵。你需要一种自动化的方式，能够在不依赖人工参考答案的前提下，对 RAG 流水线的每个环节给出可量化的质量分数。
RAGAS（Retrieval Augmented Generation Assessment）正是为解决这个问题提出的评估框架。它由 Shahul Es 等人于 2023 年提出，核心思路是：利用大语言模型本身作为评估器，对 RAG 系统的检索质量和生成质量分别打分，从而定位问题所在。本文将以企业知识库问答为贯穿场景，解释 RAGAS 中三个核心指标——忠实度、答案相关性与上下文相关性——的计算原理、实现细节与适用边界。
为什么需要专门的 RAG 评估指标
传统 NLP 评估指标，如 BLEU、ROUGE，依赖生成文本与参考答案之间的 n-gram 重叠。这类指标在机器翻译、摘要任务中曾广泛使用，但在 RAG 场景下存在明显缺陷。RAG 的答案由检索到的上下文和生成模型共同决定，同一个问题可以有多种正确表述，n-gram 重叠无法捕捉语义等价。例如，员工问“年假可以累计到下一年吗？”，参考答案写“未休年假可结转至次年”，而系统回答“年假余额会在年底清零”，两者在字面上几乎没有重叠，但语义完全相反。BLEU 分数可能给出中等偏上的结果，却无法反映事实错误。
另一方面，RAG 流水线由检索器和生成器两个模块组成，整体指标无法告诉你哪个模块需要改进。如果最终答案质量差，可能是检索器召回了不相关文档，也可能是生成器没有忠实于检索到的内容。因此，评估必须分解到组件级别。
RAGAS 的设计目标正是解决这两个问题：一是提供不依赖人工参考答案的“无参考”评估，二是将评估拆分为多个维度，分别衡量检索质量和生成质量。它的输入包括用户问题、系统生成的答案、检索到的上下文，以及可选的 ground truth（人工标注的标准答案）。其中，只有 ground truth 需要人工提供，且仅在需要计算某些指标（如上下文召回）时才必需。
忠实度：答案是否忠于检索到的上下文
忠实度（Faithfulness）衡量生成答案中的每个陈述是否都能从检索到的上下文中得到支持。这个指标直接对应 RAG 系统的一个核心风险：幻觉。当模型没有使用检索到的知识，而是依赖自身参数记忆生成内容时，就可能产生与上下文矛盾或完全虚构的陈述。
忠实度的计算分为两步。第一步，使用 LLM 将答案拆解为若干独立陈述。例如，对于答案“根据公司政策，员工每年有 15 天年假，未休部分可结转至次年”，LLM 会提取出两个陈述：“员工每年有 15 天年假”和“未休部分可结转至次年”。第二步，再次使用 LLM 判断每个陈述是否被检索到的上下文支持，输出“是”或“否”。最终分数是支持的陈述数除以总陈述数。
这个计算过程有一个值得注意的细节：陈述的提取粒度直接影响分数。如果 LLM 将答案拆成过细的片段，每个片段都容易在上下文中找到对应，分数会偏高；如果拆得过粗，一个混合了正确与错误信息的陈述会被整体判为不支持，分数又会偏低。工程上，RAGAS 通过精心设计的 prompt 来约束 LLM 的拆解行为，但不同 LLM 对 prompt 的遵循程度不同，这会导致同一份数据在不同评估模型下得到不同的忠实度分数。
在企业知识库场景中，忠实度低通常意味着两种可能：一是检索到的上下文本身不包含回答所需的信息，模型只能“硬编”；二是上下文包含信息，但模型在生成时没有遵循。区分这两种情况需要结合其他指标，例如上下文相关性。如果上下文相关性高而忠实度低，问题大概率出在生成模型；如果两者都低，则检索环节可能才是瓶颈。
答案相关性：回答是否切题
答案相关性（Answer Relevancy）衡量生成答案与用户问题之间的相关程度。它不关心答案是否完整或正确，只关心答案是否针对问题本身。例如，员工问“年假可以累计吗？”，如果系统回答“年假政策见 HR 手册”，虽然这句话在语法上正确，但与问题不相关，应该得到低分。
RAGAS 计算答案相关性的方法比较巧妙：它让 LLM 根据答案反向生成若干个人工问题，然后计算这些生成问题与原始问题的语义相似度。具体来说，给定答案，LLM 会生成几个可能的问题；然后使用嵌入模型将所有问题编码为向量，计算每个生成问题与原始问题的余弦相似度；最后取平均值作为答案相关性分数。
这个设计的直觉是：如果答案真正回答了问题，那么根据答案反推出来的问题应当与原始问题高度相似。反之，如果答案是泛泛而谈或答非所问，反向生成的问题就会偏离原始问题。例如，对于答案“年假政策见 HR 手册”，LLM 可能生成“HR 手册在哪里？”，这与原始问题“年假可以累计吗？”的相似度很低，从而得到低分。
答案相关性有一个明显的局限：它依赖嵌入模型的语义理解能力。如果嵌入模型对领域术语不敏感，两个在语义上相关但用词不同的问题可能被计算为低相似度。此外，反向生成问题的数量（默认是 3 个）也会影响分数的稳定性，数量太少可能导致方差过大。
在企业知识库中，答案相关性低往往意味着生成模型没有正确理解用户意图，或者提示词设计不佳，导致模型给出了模板化或偏离主题的回答。这个指标可以帮助你定位生成模块的问题，但它无法告诉你答案是否事实正确——那需要忠实度来补充。
上下文相关性：检索器是否找对了材料
上下文相关性（Context Relevancy）评估检索器返回的上下文与用户问题的相关程度。它直接衡量检索质量，是 RAG 流水线中第一个可能出错的环节。
RAGAS 计算上下文相关性的方法是：使用 LLM 从检索到的上下文中提取出对回答问题至关重要的句子，然后计算这些关键句子占整个上下文的比例。如果检索结果中包含大量无关段落，关键句子的比例就会低，得分也低。
这个指标有一个重要的工程含义：它鼓励检索器返回“精炼”的结果。如果你的检索器总是返回大量文档，即使其中包含正确答案，上下文相关性分数也会因为噪声过多而下降。这会影响下游生成模型的表现，因为过多的无关信息会分散模型的注意力，增加幻觉风险。
然而，上下文相关性只衡量“信噪比”，不衡量“覆盖率”。也就是说，它不关心检索结果是否遗漏了其他重要信息。一个只返回一段相关文本的检索器可能得到很高的上下文相关性分数，但如果这段文本只覆盖了问题的一部分，答案仍然不完整。因此，RAGAS 还提供了上下文召回（Context Recall）指标，用于衡量检索结果对 ground truth 的覆盖程度。
上下文召回需要人工标注的 ground truth 答案。它计算检索到的上下文中包含的 ground truth 陈述的比例。在企业知识库场景中，你可以为每类常见问题准备少量 ground truth 样本，用于评估检索器的召回能力。但请注意，ground truth 的标注成本较高，且不同标注者的判断可能不一致，这会影响指标的可靠性。
指标之间的关系与整体评估流程
在 RAGAS 中，四个核心指标分别从不同角度评估 RAG 流水线。下表总结了它们的输入、输出和主要用途。
| 指标 | 输入 | 衡量内容 | 主要用途 |
|---|---|---|---|
| 忠实度 | 问题、答案、上下文 | 答案中的陈述是否被上下文支持 | 检测幻觉，评估生成模块 |
| 答案相关性 | 问题、答案 | 答案是否切题 | 评估生成模块的响应质量 |
| 上下文相关性 | 问题、上下文 | 检索结果中的相关句子比例 | 评估检索模块的信噪比 |
| 上下文召回 | 问题、上下文、ground truth | 检索结果对标准答案的覆盖程度 | 评估检索模块的召回能力 |
在实际评估中，你可以选择全部或部分指标。如果只关心生成质量，可以只计算忠实度和答案相关性；如果关心检索质量，则需计算上下文相关性和上下文召回。RAGAS 的 evaluate 函数接受一个数据集，其中包含问题、答案、上下文和可选的 ground truth，然后返回每个指标的分数。
评估流程可以用以下流程图表示：
flowchart TD
A[准备评估数据集] --> B{需要 ground truth?}
B -- 是 --> C[标注 ground truth]
B -- 否 --> D[仅使用问题]
C --> E[运行 RAG 流水线生成答案和上下文]
D --> E
E --> F[调用 RAGAS 评估器]
F --> G[计算忠实度]
F --> H[计算答案相关性]
F --> I[计算上下文相关性]
F --> J[计算上下文召回]
G --> K[输出指标报告]
H --> K
I --> K
J --> K
K --> L[定位问题模块]
这个流程的关键在于：你需要先运行 RAG 流水线，收集每个查询的答案和检索到的上下文，然后才能调用 RAGAS 进行评估。RAGAS 本身不参与 RAG 的推理过程，它只负责打分。
与人工评估的对比及适用边界
RAGAS 的一个核心卖点是“无参考”评估，即不需要人工标注的标准答案。这使得评估成本大幅降低，评估周期可以从几天缩短到几小时。然而，无参考评估也带来了一些问题。
首先，LLM 作为评估器可能存在偏见。研究表明，LLM 在判断陈述是否被支持时，可能倾向于给出“是”的答案，导致忠实度分数虚高。这种偏见在模型不确定时尤其明显。其次，LLM 的评估结果可能不稳定，同一份数据在不同运行中可能得到略有不同的分数，这给指标的比较带来噪声。
与人工评估相比，RAGAS 的优势在于可扩展性和一致性。人工评估虽然更准确，但无法扩展到大规模查询，且不同标注者之间的一致性难以保证。RAGAS 提供了一种自动化的替代方案，但它的可靠性高度依赖于所选的评估 LLM 和提示词。
在跨领域场景中，RAGAS 的适用性需要谨慎评估。例如，在医疗或法律领域，术语专业性强，通用 LLM 可能无法准确判断陈述是否被支持。RAGAS 官方文档提到，可以通过调整提示词来适应不同语言和领域，但这需要额外的工程投入。此外，对于低资源语言，嵌入模型和 LLM 的能力可能不足，导致指标失真。
在企业知识库的实际部署中，建议将 RAGAS 作为回归测试工具，而不是唯一的评估手段。你可以在每次更新检索器或生成模型后运行 RAGAS，观察指标变化，快速发现退化。同时，保留一小部分人工评估样本，用于校准 RAGAS 分数的可靠性。
一个贯穿场景的评估实例
让我们回到企业知识库的场景。假设你为 HR 部门构建了一个 RAG 系统，用于回答员工关于年假政策的问题。你收集了 20 个常见问题，并为其中 10 个标注了 ground truth。现在，你使用 RAGAS 评估当前系统的性能。
运行评估后，你得到以下分数：
- 忠实度：0.75
- 答案相关性：0.995
- 上下文相关性：0.60
- 上下文召回：0.85
这些分数告诉你什么？首先，答案相关性很高，说明生成模型基本能够切题回答。其次，忠实度 0.75 意味着答案中有 25% 的陈述无法从上下文中得到支持，这是一个危险的信号，可能意味着模型在部分情况下产生了幻觉。上下文相关性只有 0.60，说明检索结果中混入了不少无关内容，这可能是导致忠实度下降的原因之一——模型被无关信息干扰。上下文召回 0.85 说明检索器基本找全了关键信息，但仍有提升空间。
基于这些指标，你可以采取针对性改进：优化检索器的分块策略或重排序逻辑，以提高上下文相关性；或者修改提示词，要求模型严格基于上下文回答，以提高忠实度。改进后再次运行 RAGAS，对比分数变化，验证改进是否有效。
这个例子展示了 RAGAS 的核心价值：它让你能够量化地定位问题，而不是凭感觉猜测。
生产环境中的注意事项与未解决问题
在将 RAGAS 集成到生产环境时，有几个实际问题需要处理。
第一，评估成本。RAGAS 依赖 LLM 进行多次推理，每个指标都需要多次调用。对于大规模评估数据集，成本可能显著。工程上，你可以通过采样或缓存来降低成本，但必须注意采样偏差。
第二，评估 LLM 的选择。RAGAS 默认使用 OpenAI 模型，但你可以通过配置切换到其他 LLM。不同 LLM 的评估能力差异很大，尤其是在处理长上下文或复杂推理时。建议在固定评估 LLM 的前提下进行指标比较，否则不同 LLM 产生的分数不可直接对比。
第三，指标的可解释性。RAGAS 分数是 0 到 1 之间的数值，但什么分数算“好”并没有统一标准。你需要根据自身业务定义阈值，例如忠实度低于 0.7 就触发告警。这需要积累历史数据，建立基线。
第四，RAGAS 本身也在演进。论文发表于 2023 年，框架后续版本增加了更多指标，如上下文精度、噪声敏感性等。这些新指标可能提供更细粒度的诊断，但也增加了评估的复杂性。
最后，RAGAS 的评估结果仍然无法完全替代人类判断。对于高风险领域，如医疗建议或法律咨询，自动评估只能作为初步筛选，最终仍需人工审核。
RAGAS 提供了一个实用的起点，但它并非万能。理解每个指标的假设和局限，结合具体业务场景调整使用方式，才能真正发挥其价值。