关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集
导读
做 AI 应用的团队，这两年几乎都绕不开 RAG。
知识库接上去不难，向量库跑起来也不难，Demo 更不难。真正进到业务里，问题马上就变了：同一类问题今天答对，明天答偏；文档明明有答案，系统却检不出来；有时候检索已经命中，回答还是会补出文档里没有的话。
RAG 已经是当前最常见的 LLM 应用形态之一，而生成式系统本身又天然带有非确定性。这意味着，传统那套“接口通了、返回对了、状态码没问题就算通过”的测试思路，放到 RAG 上已经不够用了。
很多团队真正卡住的，不是“怎么把知识库接进来”，而是另一件更麻烦的事：
这个系统到底有没有变好，应该怎么测。
目录
一、RAG上线后最先暴露的，不是模型能力，而是测试体系缺位
二、RAG难测的根源，不在LLM，而在它是组合系统
三、真正有效的评估，不是一个准确率，而是四层指标一起看
四、同样是“答错”，背后的工程问题完全不是一回事
五、能落地的团队，都在把RAG测试做成回归工程
六、下一轮差距，不在会不会接知识库，而在能不能持续评估
一、RAG上线后最先暴露的，不是模型能力，而是测试体系缺位
很多团队对 RAG 的第一反应，还是把它当成“问答能力增强”。
这其实只看到了表层。
业务侧真正感受到的，是另外三件事：
第一，答案不稳定。 第二，错误不可解释。 第三，系统改完以后不知道是不是更好了。
OpenAI 把 evals 定义为生成式系统的结构化测试。LangSmith 在 RAG 评估里也明确把问题拆成两层：检索是否拿到了合适证据，回答是否基于证据生成。这个变化本身已经说明，RAG 不是单纯的模型调用问题，而是需要持续测、持续比、持续回归的系统工程。
RAG系统最危险的错，不是答不出来，而是“检索错了还答得像对的”。
这类错误比接口报错更麻烦。 因为它会进入业务流程，会被用户当真，还会在你没有监控的情况下持续发生。
二、RAG难测的根源，不在LLM，而在它是组合系统
传统系统测试，很多时候测的是输入和输出。
RAG 不一样。
它表面上是一个回答动作，底层其实至少包含这几层：
- Query 理解与改写
- 检索召回
- 重排排序
- 上下文组装
- LLM 生成
- 引用与拒答策略
也就是说，用户看到的是一个答案，工程上跑的是一条链路。
这就决定了一个事实：
RAG测试不是测模型聪不聪明，而是测系统有没有把正确证据，稳定送到模型面前。
只要这条链路里有任何一层出问题，最后都会表现成“答案不太对”。 但“答案不太对”这个表象，根本不够你定位问题。
你必须把测试对象从“最终回答”拆回到“中间过程”。
三、真正有效的评估，不是一个准确率，而是四层指标一起看
现在主流的 RAG 评估框架，已经不再只看一个笼统的“回答准确率”。Ragas、LangSmith、NVIDIA 的文档都在强调同一件事：RAG 至少要拆开看检索质量、回答质量、基于证据的一致性，以及线上运行表现。常见指标包括 Context Precision、Context Recall、Faithfulness、Response Relevancy、Answer Accuracy、Context Relevance、Response Groundedness 等。
落到工程里，我更建议按四层来测。
1. 检索层：先看有没有找到
这一层测的是：
- 该命中的文档有没有进 TopK
- 排名靠不靠前
- 是否召回了大量噪声片段
- 多跳问题是否把关键证据都拿到了
如果你有标注好的证据文档，可以看 Recall@K、Precision@K、NDCG 这类检索指标。 如果没有人工标注，也可以用 RAGAs 这类框架做 context recall、context precision 一类的评估。
2. 证据层：再看回答是不是“站得住”
这一层不是问“像不像正确答案”，而是问：
- 回答里的关键结论，能不能被检索上下文支持
- 有没有超出证据范围的补充
- 引用是不是对的
Faithfulness 和 Groundedness 本质上都在解决这个问题：回答是否真正建立在检索证据上，而不是模型自己补全。
3. 答案层：最后才看用户感知质量
这一层才是用户最直观的部分：
- 有没有答到点上
- 是否完整
- 是否遗漏限制条件
- 是否拒答得当
这里可以看 answer accuracy、answer relevancy，也可以使用有参考答案的数据集做对比。LangSmith 的官方建议也很明确：如果你能拿到参考答案，优先使用有参考答案的评估；没有的话，再用 reference-free 的方法补位。RAGAS 和 ARES 这类工作，也是在解决低人工成本下的自动化评估问题。
4. 工程层：真正影响上线的，往往是这一层
很多团队只看回答对不对，却忽略了这些更接近生产的问题：
- 延迟是否可接受
- Token 成本是否失控
- 空检率高不高
- 拒答率是不是异常
- 改了 embedding、chunk、prompt 之后，历史问题有没有回退
这部分不是“模型指标”，但它直接决定系统是否能上线。
没有回归集的RAG优化，本质上不是调优，是碰运气。
四、同样是“答错”，背后的工程问题完全不是一回事
拿一个企业制度问答场景举例。
用户问： “年假没有休完，能不能折现？”
系统 A 的回答错了。 原因是 chunk 切得太碎，制度条款被拆散，召回没拿到完整上下文。
系统 B 的回答也错了。 但它其实已经检索到了正确制度，只是模型在生成时补出了一句“按公司审批流程可折现”，而文档里根本没有这句话。
系统 C 的回答看起来对。 但引用挂错了文档版本，拿的是去年的旧制度。
这三个结果，业务侧看起来都是“答错了”。 但工程处理方式完全不同：
- A 要改切分策略、召回配置、embedding 或 reranker
- B 要改 prompt 约束、引用机制、拒答策略
- C 要改索引更新、版本隔离、元数据过滤
所以，RAG 测试不能只留一个“是否正确”的标签。 至少还要记录：
- 错在检索
- 错在生成
- 错在证据版本
- 错在引用映射
- 错在拒答策略
只有这样，测试结果才能真正指导研发改系统。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
五、能落地的团队，都在把RAG测试做成回归工程
真正能把 RAG 做稳的团队，做法其实很像成熟的软件工程。
不是上线前抽几条问题看看。 而是把评估做成一条固定流程。
这套流程里，最关键的是测试集设计。
一套能用的 RAG 测试集，至少要有这些字段
- 用户问题
- 标准答案或可接受答案
- 关键证据片段
- 是否应该拒答
- 文档版本
- 问题类型标签
问题类型不要只放 FAQ。 一定要覆盖这些高风险场景：
- 同义表达
- 缩写表达
- 多跳问题
- 跨文档聚合
- 文档冲突
- 旧版本干扰
- 无答案问题
- 高相似干扰问题
Ragas 也提供了 RAG 测试数据生成能力，NVIDIA 也在官方材料里讨论了用合成数据扩大评估覆盖面。这条路的价值很明确：人工标注永远不够，自动生成测试样本会成为回归测试的重要补充。
再往前走一步，线上评估也必须补上。 LangSmith 和 OpenAI 的文档都在强调，生成式系统评估不能停留在离线阶段，生产环境中的真实交互同样需要持续监控。
所以，一个像样的 RAG 评估闭环，至少要同时跑两类东西：
离线回归集，负责发现改动有没有把老问题改坏。 线上真实流量，负责发现测试集里没覆盖到的新问题。
六、下一轮差距，不在会不会接知识库，而在能不能持续评估
现在很多团队还停留在“把 RAG 跑起来”。
再往后，差距会越来越集中在另一件事上： 谁能更快判断系统到底变好了没有。
这件事背后，实际比拼的是三种能力：
第一，能不能把业务问题翻译成可测试样本。 第二，能不能把“答错”进一步拆成可归因的问题。 第三，能不能把评估结果真正接回研发迭代。
RAGAS 解决的是低标注成本下的参考无关评估。ARES 解决的是自动化评估和少量人工校准结合的问题。OpenAI、LangSmith 这类平台在强调的，则是把 eval 变成持续工程，而不是一次性动作。行业方向已经很清楚：RAG 的竞争，正在从“谁先接入”走向“谁更会评估、谁更会回归”。
对测试岗位来说，这不是一个边缘变化。
这意味着测试对象，已经从“功能正确性”扩展成了：
- 检索正确性
- 证据一致性
- 拒答合理性
- 线上稳定性
- 数据版本治理
- 评估闭环能力
会不会写接口用例，当然还重要。 但只会这一层，已经不够接住 AI 系统里的核心质量问题了。
你现在在做的系统，评估的是“答案看起来差不多”，还是已经能定位到“到底错在召回、重排、生成，还是版本治理”？
推荐学习
测试智能体与智能化测试平台公开课， 从架构设计到大厂落地，重塑自动化测试力。
扫码进群，报名学习。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
