如何用 A/B 测试评估 RAG：别只看“回答像不像”，要看“是否真的更好用”

RAG 系统上线后，常见情况是：你换了一个 Embedding 模型、加入重排模型，或者调整了分块策略，主观感觉答案似乎更好了。

但“感觉更好”不等于真的更好。要判断某个 RAG 方案是否值得上线，A/B 测试是最可靠的方法之一。

简单说，A/B 测试就是让一部分用户使用旧方案 A，另一部分用户使用新方案 B，在相同条件下比较结果，最后用数据决定是否切换。

一、先明确：A/B 测试到底测什么？

RAG 的回答质量由多个环节共同决定：

用户问题
→ 检索召回
→ 重排筛选
→ 拼接上下文
→ 大模型生成答案
→ 用户反馈

因此，A/B 测试不只是比较“两个模型谁回答得更流畅”，而是比较某个改动是否让整个链路更有效。

例如：

A：仅用向量检索；
B：向量检索 + 关键词检索 + 重排模型。

或者：

A：每段文档按 500 字切分；
B：按标题和语义段落切分。

又或者：

A：直接让模型回答；
B：要求模型必须引用检索来源，资料不足时明确拒答。

一次测试最好只改一个核心变量。否则 B 比 A 好，你也很难判断到底是分块、Embedding、重排，还是提示词起了作用。

二、RAG 的 A/B 测试，应同时看四类指标

1. 检索指标：找没找对资料？

这是 RAG 的基础。如果检索错了，模型写得再漂亮也可能是“有依据地胡说”。

常用指标包括：

Recall@K：正确资料是否出现在前 K 条检索结果中；
MRR：正确资料排得是否足够靠前；
命中率：用户问题对应的标准资料是否被召回；
无关文档比例：检索结果中有多少是噪声。

例如，某个问题的正确答案在第 1 篇制度文件中，但系统只检索到了第 20 篇不相关文档。即使最终模型答对了，也不代表系统稳定可靠。

2. 回答指标：答得对不对、全不全？

回答层面可以人工标注，也可以让专家或评审模型辅助打分。常见维度是：

指标	要解决的问题
正确性	回答是否符合事实
相关性	是否真正回答了用户的问题
完整性	是否遗漏关键条件或步骤
忠实性	是否严格基于检索资料，而非编造
可读性	用户是否容易理解和执行
引用准确性	引用的资料是否真的支持结论

其中最重要的是忠实性。RAG 不是普通聊天机器人，它的价值在于“有据可查”。如果系统引用了资料，却得出了资料中没有的结论，就存在幻觉风险。

3. 用户指标：用户觉得有没有用？

离线数据看起来更优，不代表真实用户更满意。上线后可以观察：

点赞率、采纳率；
用户是否继续追问；
同一问题是否反复重问；
人工客服或人工检索的转接率；
用户完成任务的时间；
用户对“答案是否解决问题”的评分。

例如，B 方案回答更长、更全面，但用户获取关键信息的时间更久，满意度反而下降。此时 B 未必真的更好。

4. 安全指标：有没有答出不该答的内容？

对于企业 RAG，这一项必须单独测试。

重点关注：

是否检索到无权限文档；
是否泄露个人信息、合同金额、薪资等敏感字段；
是否能被提示词注入诱导；
是否在资料不足时硬编答案；
是否错误引用过期制度、已废弃流程。

一个回答“更详细”，不一定更好；如果它把不该出现的信息说出来，整体就是失败。

三、一个最实用的 A/B 测试设计

假设你准备验证：加入重排模型后，RAG 是否更好。

可以这样设计：

A 组：向量检索 → 前 5 条文档 → 大模型回答
B 组：向量检索 → 取前 20 条 → 重排 → 前 5 条文档 → 大模型回答

然后把真实用户随机分成两组：

50% 用户进入 A；
50% 用户进入 B；
用户身份、权限范围、问题类型尽量保持可比；
同一用户在同一轮会话中固定使用同一方案，避免体验混乱。

测试时，至少记录：

问题文本
用户权限
实验分组
检索文档及排序
最终答案
用户是否点赞/追问/转人工
响应耗时
安全拦截结果

经过一段时间后，再比较 A、B 两组的整体表现。

四、不要只做在线测试，最好先做离线评测

直接把不成熟的 B 方案推给真实用户，风险较高。更稳妥的流程是：

历史问题集
→ 离线评测
→ 小流量灰度 A/B 测试
→ 扩大流量
→ 正式上线

离线评测时，可以整理一批有标准答案的问题，例如：

常见制度问答；
多文档综合问题；
需要精确引用的问题；
故意设计的模糊问题；
无答案问题；
越权和敏感信息问题。

这批数据不能只包含简单问题，否则系统会出现“考试成绩很高、真实使用很差”的情况。

五、RAG 测试里最容易犯的五个错误

第一，只看模型回答，不看检索结果。 模型偶然答对，不代表知识库检索正确。必须把“召回质量”和“生成质量”分开看。

第二，一次修改太多东西。 分块、Embedding、重排、提示词一起改，最后无法判断改进来自哪里。

第三，只看平均分。 平均分提高，可能是简单问题变好了，但复杂问题、敏感问题反而变差。应按问题类型分组分析。

第四，忽略响应时间和成本。 B 的准确率高 1%，但响应时间从 2 秒变成 10 秒，调用成本翻三倍，未必值得上线。

第五，没有安全对照集。 RAG 不仅要回答“知道的问题”，还要正确拒答“无权限、无资料或不该回答的问题”。

六、最后怎么判断 B 是否胜出？

B 方案不是只要某一个分数高就上线，而是要同时满足：

回答正确率提高
检索命中率不下降
幻觉和错误引用不增加
敏感信息泄露风险不增加
响应时间和成本在可接受范围内
用户满意度或任务完成率提升

如果 B 只是“语言更漂亮”，但检索更慢、幻觉更多、用户更容易追问，它就不是真正的优化。

一句话总结：

RAG 的 A/B 测试，不是在比较哪套系统更会“说话”，而是在比较哪套系统能更安全、更准确、更高效地帮助用户完成任务。