157 lines
7.6 KiB
Markdown
157 lines
7.6 KiB
Markdown
|
这是一份标准的 **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"}
|
|||
|
|
```
|