wiki_crawler/docs/RAGtest.md

这是一份标准的 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 完全一致。 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 模板

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

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

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

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

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