前言

在做 RAG Copilot 项目测试时，遇到过一些典型的问题：

系统第一次跑的时候表现很好，但只要做一点小改动，结果就可能发生变化。

例如：

• 调整 chunk 大小

• 更换 embedding 模型

• 修改 prompt

• 新增文档

这些改动看起来都不大，但有时候会导致：

• 原来能回答的问题突然答错

• 检索命中变差

• 模型开始产生幻觉

这类问题在 RAG 系统很常见。

因此在项目测试过程中，需要补充一项QA 机制：

RAG 回归测试集（Regression Set）。

---

一、什么是 RAG 回归测试

简单来说：

回归测试集是一组固定问题，用来在系统修改后验证行为是否发生退化。

RAG 系统中最容易出现的问题不是：

系统不能回答

而是：

系统曾经能回答，但后来变差了

这就是典型的 系统退化问题。

因此需要一组固定问题作为基准。

---

二、RAG系统为什么容易退化

传统系统的逻辑是：

输入 → 业务逻辑 → 输出

RAG 系统是：

问题
↓
向量检索
↓
证据 chunk
↓
LLM 生成回答

如果其中任何一层发生变化，结果就可能改变。

例如：

修改项	可能影响
chunk 切分	证据被拆散
embedding 模型	向量相似度变化
检索参数	TopK 结果不同
prompt	生成策略变化

这就是为什么 RAG 系统须有 回归验证机制。

---

三、设计一组RAG回归测试集

在项目中，我整理了一组 10条核心问题，作为系统回归测试输入。

示例：

ID	问题	类型
R01	XR课程的核心内容是什么	文档事实
R02	XR课程有哪些模块	文档事实
R03	XR课程适合什么人群	文档事实
R04	文档是否提到OpenXR	关键概念
R05	XR系统支持哪些设备	文档事实
R06	XR课程收费多少	文档外问题
R07	系统是否使用向量数据库	技术问题
R08	请总结XR课程结构	总结问题
R09	文档是否包含AI教学内容	判断问题
R10	XR课程难度如何	文档事实

这些问题主要覆盖四种场景：

文档事实问题
技术细节问题
文档外问题（拒答能力）
总结类问题

---

四、回归测试如何执行

每次系统发生修改后，都需要重新跑一遍回归集。

例如：

修改 chunk 大小
更换 embedding 模型
新增文档
修改 prompt

执行流程：

运行10条问题
↓
记录检索结果
↓
记录回答结果
↓
与历史结果对比

测试记录示例：

ID	检索chunk	Score	回答	是否通过
R01	p1-c2	4	正确	✔
R02	p2-c1	3	正确	✔
R06	无	0	正确拒答	✔

如果出现：

正确 → 错误

就说明系统发生退化。

---

五、主观题如何评测（Rubric）

RAG 问答很多属于主观问题，因此需要定义评分规则。

项目中采用简单的三档评分：

分数	含义
2	回答正确
1	部分正确
0	错误
F	严重幻觉

示例：

问题：

XR课程核心内容是什么？

评分规则：

分数	规则
2	包含XR基础、交互设计、项目实践
1	只提到部分内容
0	回答错误
F	编造课程内容

这样就可以统计整体准确率。

---

六、回归测试的工程价值

很多 RAG Demo 能跑通，但没有稳定测试机制。

在项目中，回归测试的价值主要体现在三点：

1 系统修改可验证

任何改动后都可以快速验证结果。

2 行为退化可发现

避免系统悄悄变坏。

3 QA资产可复用

测试集可以长期维护和扩展。

---

七、总结

RAG 系统重要的是：

建立稳定的测试资产。

其中回归测试集是基础的一环。

就是说：

固定问题
固定评测
持续验证

只有这样，RAG 系统的行为才是 可复现、可验证、可迭代的。