Initial commit
This commit is contained in:
@@ -0,0 +1,137 @@
|
||||
# 第一节 评估介绍
|
||||
|
||||
> 构建RAG系统后，下一个关键问题是：如何科学地评估其表现？
|
||||
|
||||
评估之所以关键，是因为它回答了RAG开发与应用中的一系列核心问题：
|
||||
|
||||
- **对于开发者：** 如何量化地追踪、迭代并提升RAG应用的性能？当系统出现“幻觉”或答非所问时，如何快速定位问题根源？
|
||||
- **对于用户或决策者：** 面对两个不同的RAG应用，如何客观地评判孰优孰劣？
|
||||
|
||||
|
||||
本节将探讨RAG评估的理念与方法，并围绕 **“RAG三元组（RAG Triad）”** 展开。
|
||||
|
||||
|
||||
|
||||
## 一、RAG评估三元组
|
||||
|
||||
该架构包含以下三个维度，并在 **TruLens** [^1]等工具中有深入的应用：
|
||||
|
||||
（1）**上下文相关性 (Context Relevance)**
|
||||
- **评估目标：** 检索器（Retriever）的性能。
|
||||
- **核心问题：** 检索到的上下文内容，是否与用户的查询（Query）高度相关？
|
||||
- **重要性：** 检索是RAG应用在响应用户查询时的第一步。如果检索回来的上下文充满了噪声或无关信息，那么无论后续的生成模型多么强大，都没法做出正确答案。
|
||||
|
||||
（2）**忠实度 / 可信度 (Faithfulness / Groundedness)**
|
||||
- **评估目标：** 生成器的可靠性。
|
||||
- **核心问题：** 生成的答案是否完全基于所提供的上下文信息？
|
||||
- **重要性：** 这个维度主要在于量化LLM的“幻觉”程度。一个高忠实度的回答意味着模型严格遵守了上下文，没有捏造或歪曲事实。如果忠实度得分低，说明LLM在回答时“自由发挥”过度，引入了外部知识或不实信息。
|
||||
|
||||
（3）**答案相关性 (Answer Relevance)**
|
||||
- **评估目标：** 系统的端到端（End-to-End）表现。
|
||||
- **核心问题：** 最终生成的答案是否直接、完整且有效地回答了用户的原始问题？
|
||||
- **重要性：** 这是用户最直观的感受。一个答案可能完全基于上下文（高忠实度），但如果它答非所问，或者只回答了问题的一部分，那么这个答案的相关性就很低。例如，当用户问“法国在哪里，首都是哪里？”，如果答案只是“法国在西欧”，那么虽然忠实度高，但答案相关性很低。
|
||||
|
||||
> 你可能觉得忠实度和答案相关性很相似，但它们的侧重点是不同的。忠实度更关注模型是否严格遵循了上下文，而答案相关性则更关注模型是否直接、完整且有效地回答了问题。
|
||||
|
||||
通过对这三个维度进行评估，可以对RAG系统的表现有一个全面而细致的了解，并能准确定位问题所在：是检索出了问题，还是生成环节有待改进。
|
||||
|
||||
## 二、评估工作流
|
||||
|
||||
虽然上面把评估分成了三个部分，但实际上可以把评估过程拆解为两个主要环节：**检索评估**和**响应评估**。
|
||||
|
||||
### 2.1 检索评估
|
||||
|
||||
检索评估聚焦于RAG三元组中的 **上下文相关性 (Context Relevance)**，本质上是一次**白盒测试** [^2]。此阶段的评估需要一个标注数据集，其中包含一系列查询以及每个查询对应的真实相关文档。
|
||||
|
||||
这项评估借鉴了信息检索领域的多个经典指标：
|
||||
- **上下文精确率 (Context Precision):** 衡量检索结果的准确性。计算在检索到的前 **k** 个文档中相关文档所占的比例，其中 **k** 是一个预设的数字（例如，k=3或k=5），代表评估的范围。高精确率意味着检索结果的噪声较少。
|
||||
|
||||
$$\text{Precision}@k = \frac{\text{检索到的}k\text{个结果中的相关文档数}}{k}$$
|
||||
|
||||
- **上下文召回率 (Context Recall):** 衡量检索结果的完整性。计算在检索到的前 **k** 个文档中，找到的相关文档占所有真实相关文档总数的比例。高召回率意味着系统能够成功找回大部分关键信息。
|
||||
|
||||
$$\text{Recall}@k = \frac{\text{检索到的}k\text{个结果中的相关文档数}}{\text{数据集中所有相关的文档总数}}$$
|
||||
|
||||
- **F1分数 (F1-Score):** F1分数是精确率和召回率的调和平均数，它同时兼顾了这两个指标，在它们之间寻求平衡。当精确率和召回率都高时，F1分数也高。
|
||||
|
||||
$$F_1 = 2 \cdot \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}$$
|
||||
|
||||
- **平均倒数排名 (MRR - Mean Reciprocal Rank):** 评估系统将第一个相关文档排在靠前位置的能力。对于一个查询，倒数排名是第一个相关文档排名的倒数。MRR是所有查询的倒数排名的平均值。该指标适用于用户通常只关心第一个正确答案的场景。
|
||||
|
||||
$$\text{MRR} = \frac{1}{|Q|} \sum_{q=1}^{|Q|} \frac{1}{\text{rank}_q}$$
|
||||
|
||||
其中 `|Q|` 是查询总数，`rank_q` 是第 `q` 个查询的第一个相关文档的排名。
|
||||
|
||||
- **平均准确率均值 (MAP - Mean Average Precision):** MAP是一个综合性指标，同时评估了检索结果的精确率和相关文档的排名。它先计算每个查询的平均精确率（AP），然后对所有查询的AP取平均值。AP本身是基于每个相关文档被检索到时的精确率计算的。
|
||||
|
||||
$$\text{MAP} = \frac{1}{|Q|} \sum_{q=1}^{|Q|} \text{AP}(q)$$
|
||||
|
||||
其中 `|Q|` 是查询总数，`AP(q)` 是第 `q` 个查询的平均精确率（Average Precision）。
|
||||
|
||||
要计算上述所有指标，前提是拥有一个高质量的标注数据集，其中包含了查询和每个查询对应的“真实”相关文档。
|
||||
|
||||
### 2.2 响应评估
|
||||
|
||||
响应评估覆盖了RAG三元组中的 **忠实度** 和 **答案相关性**。此环节通常采用 **端到端** 的评估范式，因为它直接衡量用户感知的最终输出质量。无论采用何种评估方法，都主要围绕以下两个核心维度展开。
|
||||
|
||||
#### 2.2.1 评估维度
|
||||
|
||||
（1）**忠实度 / 可信度**：衡量生成的答案在多大程度上可以由给定的上下文所证实。一个完全忠实的答案，其所有内容都必须能在上下文中找到依据，以此避免模型产生“幻觉”。
|
||||
|
||||
（2）**答案相关性**：衡量生成的答案与用户原始查询的对齐程度。一个高相关性的答案必须是直接的、切题的，并且不包含与问题无关的冗余信息。
|
||||
|
||||
#### 2.2.2 主要评估方法
|
||||
|
||||
针对上述维度，目前主要有两类评估方法：
|
||||
|
||||
（1）**基于大语言模型的评估**
|
||||
|
||||
这是一种强大的评估方法，能够提供更深度的语义评估，正逐渐成为主流选择。利用一个高性能、中立的llm作为“评估者”，对上述维度进行深度的语义理解和打分。
|
||||
|
||||
- **忠实度评估：** 首先，将生成的答案分解为一系列独立的声明或断言（Claims）。然后，对于每一个断言，在提供的上下文中进行验证，判断其真伪。最终的忠实度分数是所有被上下文证实的断言所占的比例。
|
||||
- **答案相关性评估：** 评估者需要同时分析用户查询和生成的答案。评分时会惩罚那些答非所问、信息不完整或包含过多无关细节的答案。
|
||||
|
||||
（2）**基于词汇重叠的经典指标**
|
||||
|
||||
这类指标需要在数据集中包含一个或多个“标准答案”。它们通过计算生成答案与标准答案之间 n-gram（连续的n个词）的重叠程度来评估质量。
|
||||
|
||||
- **ROUGE (Recall-Oriented Understudy for Gisting Evaluation):** ROUGE关注的重点是 **召回率**，即标准答案中的词语有多少被生成答案所覆盖，因此常用于评估内容的 **完整性**。其常用变体包括计算n-gram的 `ROUGE-N` 和计算最长公共子序列的 `ROUGE-L`。
|
||||
|
||||
$$\text{ROUGE-N} = \frac{\text{匹配的 } n\text{-gram 数量}}{\text{参考答案中 } n\text{-gram 的总数}}$$
|
||||
|
||||
- **BLEU (Bilingual Evalu ation Understudy):** BLEU侧重于评估 **精确率**，衡量生成的答案中有多少词是有效的（即在标准答案中出现过）。它还引入了长度惩罚机制，避免模型生成过短的句子，因此更适合评估答案的 **流畅度和准确性**。
|
||||
|
||||
$$\text{BLEU} = \text{BP} \times \exp\left(\sum_{n=1}^{N} w_n \log p_n\right)$$
|
||||
|
||||
其中，`BP` 是长度惩罚因子，`p_n` 是修正后的n-gram精确率。
|
||||
|
||||
- **METEOR (Metric for Evaluation of Translation with Explicit ORdering):** 作为BLEU的改进版，METEOR同时考量 **精确率和召回率** 的调和平均，并通过词干和同义词匹配（如将'boat'和'ship'视为相关）来更好地捕捉语义相似性。其评估结果通常被认为与人类判断的相关性更高。
|
||||
|
||||
$$F_{\text{mean}} = \frac{P \times R}{\alpha P + (1-\alpha)R}$$
|
||||
|
||||
$$\text{METEOR} = F_{\text{mean}} \times (1 - \text{Penalty})$$
|
||||
|
||||
其中 `P` 是精确率，`R` 是召回率，`Penalty` 是基于语序的惩罚项。
|
||||
|
||||
> 为了更直观地理解三者的区别，来看一个简单的例子。
|
||||
>
|
||||
> **假设：**
|
||||
> - **参考答案：** `狗 在 床 上面` (共5个词)
|
||||
> - **生成答案：** `狗 在 床 上` (共4个词)
|
||||
>
|
||||
> **评估分析：**
|
||||
> - **ROUGE (召回率导向):** 从召回率的角度出发：“参考答案里的5个词，生成答案覆盖了多少？”——覆盖了4个。因此，它的召回率很高（ROUGE-1 为 4/5），得分会不错。ROUGE更关心“说全了没”。
|
||||
>
|
||||
> - **BLEU (精确率导向):** 从精确率的角度进行评判：“生成答案里的4个词，有多少是有效的（在参考答案里）？”——全部有效，精确率很高。但它会发现生成答案比参考答案短，于是通过 **长度惩罚(Brevity Penalty)** 进行扣分。BLEU更关心“说对了没，以及长度是否合适”。
|
||||
>
|
||||
> - **METEOR (综合平衡):** 同时计算精确率和召回率，并取一个调和平均。在这个例子里，词序是完全正确的，惩罚项为0。METEOR会在“说全”和“说对”之间找到一个最佳平衡点。
|
||||
|
||||
#### 2.2.3 方法对比和总结
|
||||
|
||||
基于LLM的评估更注重**语义和逻辑**，评估质量高，但成本也更高且存在评估者偏见。基于词汇重叠的指标**客观、计算快、成本低**，但无法理解语义，可能误判同义词或释义。在实践中，可以将两者结合，使用经典指标进行快速、大规模的初步筛选，再利用LLM进行更精细的评估。
|
||||
|
||||
## 参考文献
|
||||
|
||||
[^1]: [*The RAG Triad of Metrics*](https://www.trulens.org/getting_started/core_concepts/rag_triad/).
|
||||
|
||||
[^2]：[*如何评估 RAG 应用？*](https://zilliz.com.cn/blog/how-to-evaluate-rag-zilliz)
|
||||
@@ -0,0 +1,154 @@
|
||||
# 第二节 评估常用工具
|
||||
|
||||
了解了评估的基本原理之后，来介绍几个RAG评估工具，它们各自代表了不同的设计哲学和应用场景。
|
||||
|
||||
## 一、LlamaIndex Evaluation
|
||||
|
||||
`LlamaIndex Evaluation` 是**深度集成于LlamaIndex框架内的评估模块**，专为使用该框架构建的RAG应用提供无缝的评估能力。作为RAG开发框架的原生组件，其核心定位是**为开发者在开发、调试和迭代周期中提供快速、灵活的嵌入式评估解决方案**。它强调与开发流程的紧密结合，允许开发者在构建过程中即时验证和对比不同RAG策略的性能[^1]。
|
||||
|
||||
> **适用场景**：对于深度使用 `LlamaIndex` 框架构建RAG应用的开发者而言，其内置评估模块是无缝集成的首选，提供了一站式的开发与评估体验。
|
||||
|
||||
### 1.1 核心理念与工作流
|
||||
|
||||
`LlamaIndex` 的评估理念是利用LLM作为“裁判”，以自动化的方式对RAG系统的各个环节进行打分。这种方法在很多场景下无需预先准备“标准答案”，大大降低了评估门槛。其典型工作流如下：
|
||||
|
||||
1. **准备评估数据集**：通过 `DatasetGenerator` 从文档中自动生成问题-答案对（`QueryResponseDataset`），或加载一个已有的数据集。为了效率，通常会将生成的数据集保存到本地，避免重复生成。
|
||||
2. **构建查询引擎**：搭建一个或多个需要被评估的RAG查询引擎（`QueryEngine`）。这是进行对比实验的基础。
|
||||
3. **初始化评估器**：根据评估维度，选择并初始化一个或多个评估器，如 `FaithfulnessEvaluator`（忠实度）和 `RelevancyEvaluator`（相关性）。
|
||||
4. **执行批量评估**：使用 `BatchEvalRunner` 来管理整个评估过程。它能够高效地（可并行）将查询引擎应用于数据集中的所有问题，并调用所有评估器进行打分。
|
||||
5. **分析结果**：从评估运行器返回的结果中，计算各项指标的平均分，从而量化地对比不同RAG策略的优劣。
|
||||
|
||||
### 1.2 应用实例：对比不同检索策略
|
||||
|
||||
下面示例基于我们在第三章学习的“句子窗口检索”技术，通过评估，对比它与“常规分块检索”在响应质量上的差异。
|
||||
|
||||
**代码示例：**
|
||||
|
||||
|
||||
```python
|
||||
# ... (省略数据加载、文档解析、查询引擎构建等步骤)
|
||||
|
||||
# 1. 初始化评估器
|
||||
# 定义需要评估的指标：忠实度和相关性
|
||||
faithfulness_evaluator = FaithfulnessEvaluator(llm=Settings.llm)
|
||||
relevancy_evaluator = RelevancyEvaluator(llm=Settings.llm)
|
||||
evaluators = {"faithfulness": faithfulness_evaluator, "relevancy": relevancy_evaluator}
|
||||
|
||||
# 2. 使用BatchEvalRunner执行批量评估
|
||||
# 从数据集中获取查询列表
|
||||
queries = response_eval_dataset.queries
|
||||
|
||||
# 评估“句子窗口检索”引擎
|
||||
print("\n=== 评估句子窗口检索 ===")
|
||||
sentence_runner = BatchEvalRunner(evaluators, workers=2, show_progress=True)
|
||||
sentence_response_results = await sentence_runner.aevaluate_queries(
|
||||
queries=queries, query_engine=sentence_query_engine
|
||||
)
|
||||
|
||||
# 评估“常规分块检索”引擎
|
||||
print("\n=== 评估常规分块检索 ===")
|
||||
base_runner = BatchEvalRunner(evaluators, workers=2, show_progress=True)
|
||||
base_response_results = await base_runner.aevaluate_queries(
|
||||
queries=queries, query_engine=base_query_engine
|
||||
)
|
||||
|
||||
# 3. 分析并打印结果
|
||||
# ... (省略结果计算与打印的辅助函数)
|
||||
print(f"句子窗口检索: 忠实度={sentence_faith:.1%}, 相关性={sentence_rel:.1%}")
|
||||
print(f"常规分块检索: 忠实度={base_faith:.1%}, 相关性={base_rel:.1%}")
|
||||
```
|
||||
|
||||
**输出如下：**
|
||||
|
||||
```bash
|
||||
============================================================
|
||||
响应评估结果对比
|
||||
============================================================
|
||||
|
||||
句子窗口检索:
|
||||
忠实度: 53.3%
|
||||
相关性: 66.7%
|
||||
|
||||
常规分块检索:
|
||||
忠实度: 0.0%
|
||||
相关性: 6.7%
|
||||
```
|
||||
|
||||
通过这个结果可以看出，在本次实验中“句子窗口检索”的忠实度和相关性上均显著优于“常规分块检索”。
|
||||
|
||||
### 1.3 核心评估维度
|
||||
|
||||
LlamaIndex提供了丰富的评估器，覆盖了从检索到响应的各个环节。上述示例中主要使用了**响应评估**维度：
|
||||
|
||||
- `Faithfulness` (忠实度): 评估生成的答案是否完全基于检索到的上下文，是检测“幻觉”现象的关键指标。分数越高，说明答案越可靠。
|
||||
- `Relevancy` (相关性): 评估生成的答案与用户提出的原始问题是否直接相关，确保答案切题。
|
||||
|
||||
此外，它还支持专门的**检索评估**维度，如：
|
||||
|
||||
- `Hit Rate` (命中率): 评估检索到的上下文中是否包含了正确的答案。
|
||||
- `MRR` (平均倒数排名): 衡量找到正确答案的效率，排名越靠前得分越高。
|
||||
|
||||
## 二、RAGAS
|
||||
|
||||
RAGAS（RAG Assessment）是一个**独立的、专注于RAG的开源评估框架**。提供了一套全面的指标来量化RAG管道的检索和生成两大核心环节的性能。其最显著的特色是支持**无参考评估**，即在许多场景下无需人工标注的“标准答案”即可进行评估，极大地降低了评估成本。现对RAG管道的持续监控和改进。如果你需要一个轻量级、与具体RAG实现解耦、能够快速对核心指标进行量化评估的工具时，`RAGAS` 是一个理想的选择。
|
||||
|
||||
### 2.1 设计理念
|
||||
|
||||
`RAGAS` 的核心思想是通过分析问题（`question`）、生成的答案（`answer`）和检索到的上下文（`context`）三者之间的关系，来综合评估RAG系统的性能。它将复杂的评估问题分解为几个简单、可量化的维度。
|
||||
|
||||
### 2.2 工作流程与核心指标
|
||||
|
||||
RAGAS的评估流程非常简洁，通常遵循以下步骤：
|
||||
|
||||
（1）**准备数据集**：根据官方文档，一个标准的评估数据集应包含 `question`（问题）、`answer`（RAG系统生成的答案）、`contexts`（检索到的上下文）以及 `ground_truth`（标准参考答案）这四列。不过，`ground_truth` 对于计算 `context_recall` 等指标是必需的，但对于 `faithfulness` 等指标则是可选的。
|
||||
|
||||
（2）**运行评估**：调用 `ragas.evaluate()` 函数，传入准备好的数据集和需要评估的指标列表。
|
||||
|
||||
（3）**分析结果**：获取一个包含各项指标量化分数的评估报告。
|
||||
|
||||
其核心评估指标包括：
|
||||
|
||||
- `faithfulness`: 衡量生成的答案中有多少比例的信息是可以由检索到的上下文所支持的。
|
||||
- `context_recall`: 衡量检索到的上下文与标准答案（`ground_truth`）的对齐程度，即标准答案中的信息是否被上下文完全“召回”。
|
||||
- `context_precision`: 衡量检索到的上下文中，信噪比如何，即有多少是真正与回答问题相关的。
|
||||
- `answer_relevancy`: 评估答案与问题的相关程度。此指标不评估事实准确性，只关注答案是否切题。
|
||||
|
||||
## 三、Phoenix (Arize Phoenix)
|
||||
|
||||
Phoenix (现由Arize维护) 是一个**开源的LLM可观测性与评估平台**。在RAG评估生态中，它主要扮演**生产环境中的可视化分析与故障诊断引擎**的角色。它通过捕获LLM应用的轨迹（Traces），提供强大的可视化、切片和聚类分析能力，帮助开发者理解线上真实数据的表现。Phoenix 的核心价值在于**从海量生产数据中发现问题、监控性能漂移并进行深度诊断**，是连接线下评估与线上运维的关键桥梁。它不仅提供评估指标，更强调对LLM应用进行追踪（Tracing）和可视化分析，从而快速定位问题[^3]。
|
||||
|
||||
|
||||
|
||||
### 3.1 核心理念
|
||||
|
||||
`Phoenix` 的核心是“AI可观测性”，它通过追踪RAG系统内部的每一步调用（如检索、生成等），将整个流程可视化。这使得开发者可以直观地看到每个环节的输入、输出和耗时，并在此基础上进行深入的评估和调试。
|
||||
|
||||
### 3.2 工作原理
|
||||
|
||||
`Phoenix` 的工作流程是先通过基于开放标准 **OpenTelemetry** 的**代码插桩（`Instrumentation`）**，在 RAG 应用中集成追踪功能，自动捕获 LLM 调用、函数执行等事件；随后在应用运行过程中持续生成**追踪数据（`Traces`）**，记录完整的执行链路；接着在本地启动 `Phoenix` 的 Web 界面，加载并可视化这些追踪数据；最后在 UI 中对失败案例或表现不佳的查询进行筛选、钻取，并借助内置的**评估器（`Evals`）**完成深入的评估与调试。
|
||||
|
||||
特色功能：
|
||||
|
||||
- **可视化追踪**: 将RAG的执行流程、数据和评估结果进行可视化展示，极大地方便了问题定位。
|
||||
- **根本原因分析**: 通过可视化的界面，可以轻松地对表现不佳的查询进行切片和钻取。
|
||||
- **安全护栏 (`Guardrails`)**: 允许为应用添加保护层，防止恶意或错误的输入输出，保障生产环境安全。
|
||||
- **数据探索与标注**: 提供数据探索、清洗和标注工具，帮助开发者利用生产数据反哺模型和系统优化。
|
||||
- **与Arize平台集成**: `Phoenix` 可以与Arize的商业平台无缝对接，实现生产环境中对RAG系统的持续监控。
|
||||
|
||||
## 四、对比建议
|
||||
|
||||
| **工具** | **核心机制** | **独特技术** | **典型应用场景** |
|
||||
| ---------- | -------- | ----------------------- | --- |
|
||||
| RAGAS | LLM驱动评估 | 合成数据生成、无参考评估架构 | 对比不同RAG策略、版本迭代后的性能回归测试 |
|
||||
| LlamaIndex | 嵌入式评估 | 异步评估引擎、模块化BaseEvaluator | 开发过程中快速验证单个组件或完整管道的效果 |
|
||||
| Phoenix | 追踪分析型 | 分布式追踪、向量聚类分析算法 | 生产环境监控、Bad Case分析、数据漂移检测 |
|
||||
|
||||
> 在实践中，这些工具并非互斥，可以结合使用，以获得对RAG系统更全面、多维度的洞察。
|
||||
|
||||
## 参考文献
|
||||
|
||||
[^1]: [*LlamaIndex Evaluating*](https://docs.llamaindex.ai/en/stable/module_guides/evaluating/)
|
||||
|
||||
[^2]: [*Ragas Docs*](https://docs.ragas.io/en/stable/)
|
||||
|
||||
[^3]: [*Arize AI Phoenix*](https://arize.com/docs/phoenix)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 302 KiB |
Reference in New Issue
Block a user