前言：

RAG 项目如果不做回归集，
“越改越烂”只是时间问题。

本篇做了三件事：

1. 为 RAG Copilot 构建 20 条黄金回归用例

2. 区分 ANSWER / REFUSE 两种行为

3. 用脚本自动统计准确率

第一轮结果：

• Overall：85%

• ANSWER：100%

• REFUSE：70%

这个结果有瑕疵，但它是“工程可控”的开始。

一、为什么 RAG 项目必须做回归集？

传统接口测试可以：

• 输入固定

• 输出固定

• 用例覆盖

但 RAG 不一样：

• chunk_size 改了 → 检索结果变

• top_k 改了 → 命中不同

• prompt 改了 → 表达方式变

• min_score 改了 → 拒答比例变

如果没有固定测试集，你根本不知道：

这次优化到底是提升，还是破坏？

RAG 会“悄悄变坏”。

二、我的回归集怎么设计？

目标很简单：

覆盖“应该回答”和“应该拒答”两类行为。

结构：10 答 + 10 拒

ANSWER 类型（10条）

• 项目目标是什么？

• 最小验收标准是什么？

• 核心用户是谁？

• 为什么不能直接用大模型对话？

• MVP 关注什么？

这些问题：

• 文档中有明确内容

• 可以引用 chunk

• 应该正常回答

---

REFUSE 类型（10条）

这些问题文档中根本没有：

• 什么是函数调用？

• 什么是向量数据库？

• 如何使用 Transformer？

• temperature 怎么设置？

• LangChain 怎么用？

这些问题：

• 应该稳定拒答

• 不允许“带引用胡编”

三、如何实现自动回归？

新增两个文件：

tests/
├── regression_cases.jsonl
├── run_regression.py
└── output/latest.json

regression_cases.jsonl

每条用例结构：

{
"id": 1,
"pdf_path": "demo.pdf",
"question": "什么是工程可接受？给出定义",
"expected": "ANSWER"
}

---

run_regression.py 做三件事：

1. 逐条调用 ask(pdf, question)

2. 读取 decision（ANSWER / REFUSE）

3. 统计准确率并保存结果

四、第一轮测试结果

Overall: 85% (17/20)
ANSWER: 100% (10/10)
REFUSE: 70% (7/10)

失败的 3 条

• temperature 参数怎么设置？

• RAG 如何使用 embedding？

• 如何使用 Transformer？

原因：

• 文档中出现“大模型”“RAG”“模型”等词

• 关键词检索命中

• 但文档并未回答“如何实现”

这就是经典问题：

retrieval ≠ answerability

五、当前系统的能力边界

目前系统已经具备：

• no_hit 拒答

• 可观测日志（Top chunks + score）

• decision 打印（ANSWER / REFUSE）

• 引用可追溯

但还缺：

• 方法型问题的“证据门槛”

• 更严格的 answerability 判断

这会在下一轮优化中补上。

六、收获

这次不是在优化模型。

而是在构建：

RAG 的质量防线。

从“能跑”
到“能回归”
是 RAG 项目从 Demo 到工程的分水岭。

七、下一步计划

下一轮优化目标：

• 提升 REFUSE 准确率

• 针对“命中但不该答”加规则门槛

• 对比优化前后指标变化

总结

RAG 项目真正的难点，不是生成。

而是：

如何证明它不会乱答。

回归集，就是第一层安全网。

🔗 代码版本记录

当前文章对应版本：

v0.2-regression-baseline

• 回归集：20 条（10答 / 10拒）

• Overall：85%

• REFUSE：70%

• 已实现 decision 日志与拒答机制

GitHub Release：

👉 https://github.com/test202005/project2_mvp/releases/tag/v0.2-regression-baseline

后续优化将基于此版本继续迭代。

Testing & Regression

回归测试策略

本项目采用最小可行断言（MVP Assert）策略：

• 不比较自然语言答案文本

• 仅断言系统决策类型：ANSWER / REFUSE

原因：

RAG 输出文本具有波动性，但“该不该回答”必须稳定。

---

用例结构

回归集包含 20 条黄金用例：

• 10 条应答（ANSWER）

• 10 条应拒（REFUSE）

示例：

{
"id": 1,
"pdf_path": "demo.pdf",
"question": "什么是工程可接受？给出定义",
"expected": "ANSWER"
}

---

断言机制

在 tests/run_regression.py 中：

result = ask(case['pdf_path'], case['question'])
expected = case['expected']
actual = result['decision']
passed = (expected == actual)

判定逻辑：

• expected == actual → PASS

• 否则 → FAIL

---

指标统计

回归结果分为三类指标：

• Overall Accuracy

• ANSWER Accuracy

• REFUSE Accuracy

当前版本：

Overall: 85%
ANSWER: 100%
REFUSE: 70%

---

回归 Gate 规则

默认规则：

overall_acc == 1.0 才算全部通过

未达标的用例将作为下一轮优化目标。

---

设计原则

• 决策稳定性优先于文本一致性

• 允许模型表达差异

• 不允许“错误决策”