这是一份标准的 **RAG 系统测试与验证设计文档**。你可以将其作为项目文档的一部分，用于指导开发团队进行自动化测试框架的搭建、QA 团队进行测试用例的编写，以及算法工程师进行模型选型。

---

# RAG 知识库检索与生成系统测试设计规范
**RAG System Test Design Specification**

**版本**: 1.0
**状态**: 拟定中

---

## 1. 测试背景与目标 (Background & Objectives)

RAG（检索增强生成）系统涉及“检索器（Retriever）”与“生成器（Generator）”的复杂交互。传统的软件测试（单元测试、集成测试）无法有效评估其回答质量。本设计文档旨在建立一套**端到端（End-to-End）**与**分段式（Component-wise）**结合的测试框架，以达成以下目标：

1.  **量化评估**：将模糊的“回答好坏”转化为可度量的指标（如召回率、忠实度得分）。
2.  **归因分析**：当系统表现不佳时，能快速定位是“检索没找对”还是“LLM 没答好”。
3.  **选型决策**：通过横向对比（Benchmark），为检索算法（BM25/Vector/Hybrid）和模型选择提供数据支撑。
4.  **短板识别**：自动识别系统在特定场景（如多语言、数值推理、负向测试）下的薄弱环节。

---

## 2. 测试架构原理 (Test Architecture)

测试框架基于 **RAG 三元组 (RAG Triad)** 理论进行设计，分别针对链路中的三个关键节点进行评估：

### 2.1 评估对象
*   **Query (用户提问)**: 测试的输入。
*   **Context (检索上下文)**: 检索器从知识库召回的 Top-K 文档片段。
*   **Response (系统回答)**: LLM 基于 Query 和 Context 生成的最终文本。

### 2.2 测试流向
1.  **检索层评估 (Retrieval Evaluation)**: `Query` $\leftrightarrow$ `Context`
    *   *核心问题*: 检索到的内容是否包含回答问题所需的全部信息？
2.  **生成层评估 (Generation Evaluation)**:
    *   `Context` $\leftrightarrow$ `Response`: **忠实度 (Faithfulness)**。回答是否完全基于上下文？有无幻觉？
    *   `Query` $\leftrightarrow$ `Response`: **相关度 (Relevance)**。回答是否解决了用户的问题？

---

## 3. 测试数据集设计 (Dataset Design)

为了全面评估系统能力，构建“黄金数据集”是测试的基础。数据集需包含以下维度的字段：

### 3.1 数据字段定义
| 字段名 | 说明 | 用途 |
| :--- | :--- | :--- |
| **ID** | 唯一标识符 | 用于追踪 Case |
| **Type** | 问题分类 | 用于计算 "Weakest Category" (见 3.2) |
| **Query** | 用户模拟问题 | 输入 |
| **Ground Truth Answer** | 标准答案 | 用于生成层对比评分 |
| **Keywords/Key Information** | 关键信息点/术语 | 用于计算检索层的 Recall |
| **Ground Truth Context IDs** | (可选) 预期命中的文档ID | 用于计算 Hit Rate |

### 3.2 场景分类体系 (Category Taxonomy)
测试集必须覆盖以下场景，以防止模型“偏科”：

1.  **Core Function (核心功能)**: 基础的概念解释和流程指引。
2.  **Detail/Numeric (细节与数值)**: 涉及具体参数、价格、限制阈值等精确信息（考察向量检索的弱点）。
3.  **Inference (推理集成)**: 需要综合多段文档才能回答的复杂问题（考察 Context Window 和推理能力）。
4.  **Multilingual (跨语言)**: 中文问英文文档，或反之（考察 Embedding 对齐能力）。
5.  **Negative Test (负向/拒答)**: 知识库中不存在的问题（考察系统抗幻觉能力，预期输出为“未找到信息”）。
6.  **Safety/Injection (安全)**: Prompt 注入攻击防御测试。

---

## 4. 控制变量与横向对比设计 (Experimental Design)

为选出最佳技术方案，需设计控制变量矩阵（Control Matrix），进行 A/B 测试或横向评测。

### 4.1 实验组配置 (Configuration Matrix)

| 实验组 | 检索机制 (Retrieval) | 权重策略 | 重排序 (Rerank) | 测试目的 |
| :--- | :--- | :--- | :--- | :--- |
| **Group A (Baseline)** | **Keyword (BM25)** | Vector=0, Keyword=1 | OFF | 模拟传统全文检索，设立基准线。 |
| **Group B (Semantic)** | **Dense Vector** | Vector=1, Keyword=0 | OFF | 验证语义理解能力，检测对专有名词的丢失情况。 |
| **Group C (Hybrid)** | **Hybrid Search** | Vector=0.7, Keyword=0.3 | OFF | 验证双路召回的互补性（当前主流方案）。 |
| **Group D (High Acc)** | **Hybrid Search** | Vector=0.7, Keyword=0.3 | **ON (Top N)** | 验证引入 Rerank 模型对长尾、复杂问题的提升效果及延迟代价。 |

### 4.2 性能监控
在运行上述配置时，同步记录以下工程指标：
*   **Latency**: 端到端耗时（P50, P95）。
*   **Token Usage**: 消耗的 Token 数量（计算成本 ROI）。

---

## 5. 核心评估指标 (Key Metrics)

采用 **规则计算 + LLM裁判 (LLM-as-a-Judge)** 相结合的方式。

### 5.1 检索层指标 (Retrieval Metrics)

| 指标 | 定义 | 计算方法 | 优劣判断 |
| :--- | :--- | :--- | :--- |
| **Keyword Recall** | 关键词召回率 | $\frac{\text{检索内容中命中的关键词数}}{\text{标准答案中的关键词总数}}$ | 低于 50% 说明切片策略或检索算法严重失效。 |
| **Hit Rate** | 命中率 | 检索结果 Top-K 中是否包含至少一个相关文档片段。 | 二分类指标 (0/1)。 |

### 5.2 生成层指标 (Generation Metrics)

使用高智能模型（如 GPT-4o / Qwen-Max）作为裁判，进行 1-5 分打分。

| 指标 | 定义 | 评分标准 (Rubric) |
| :--- | :--- | :--- |
| **Correctness** | 正确性 | **5分**: 含义与 Ground Truth 完全一致。<br>**1分**: 完全错误或包含严重幻觉。 |
| **Completeness** | 完整性 | 答案是否涵盖了问题询问的所有方面？(主要针对列表类问题)。 |
| **Honesty** | 诚实度 | (针对负向测试) 当无相关信息时，是否诚实回答“不知道”而非编造。 |

### 5.3 诊断性指标 (Diagnostic Metrics)

*   **Weakest Category (最弱类别)**:
    *   计算逻辑：按 `Type` 分组，计算各组的平均分，取最低者。
    *   作用：直接指出系统短板（例如：“多语言能力最差”或“数值细节最差”），指导后续优化方向。

---

## 6. 自动化测试流程 (Workflow)

1.  **Setup Phase**:
    *   加载 `dataset.json`。
    *   初始化所有待测的 RAG Pipeline 配置。

2.  **Execution Phase (Loop)**:
    *   遍历测试集中的每个 Query。
    *   **Step 1 Retrieve**: 调用检索接口，获取 Context。
    *   **Step 2 Generate**: 将 Context + Query 送入 LLM 生成 Answer。
    *   **Step 3 Measure**: 记录 Latency。

3.  **Evaluation Phase**:
    *   **Rule Check**: 计算 Keyword Recall。
    *   **AI Judge**: 将 (Query, Answer, Ground Truth) 组装 Prompt 发送给裁判 LLM 打分。

4.  **Reporting Phase**:
    *   输出汇总报表，包含：各配置的平均分、平均召回率、延迟、最弱类别。
    *   输出 Bad Case 列表（得分 < 3 的用例）。

---

## 7. 附录：LLM 裁判 Prompt 模板

```markdown
你是一名 RAG 系统测试裁判。请评估【系统回答】相对于【标准答案】的质量。

【问题类型】: {type}
【用户问题】: {query}
【标准答案】: {ground_truth}
【系统回答】: {prediction}

请打分 (1-5)：
- 5分: 完美。逻辑正确，无幻觉，细节精准。
- 3分: 及格。包含核心信息，但有遗漏或啰嗦。
- 1分: 错误。答非所问，或在负向测试中产生幻觉。

特别规则：对于 "Negative Test"，如果标准答案是“不支持/未提及”，而系统回答了“未找到相关信息”，请给 5 分。

输出 JSON: {"score": int, "reason": "string"}
```