17｜RAG 在测试知识库上怎么应用？

开场先一句话讲清 RAG：检索增强生成——先从知识库里检索相关内容，把检索结果和问题一起给模型，让它基于真实材料回答。

回答思路

第一步：RAG 解决什么

解决「模型不懂你们业务」的根本问题——测试团队最值钱的私有知识（历史 bug、业务规则、用例库）通过 RAG 变成 AI 的上下文。

第二步：测试场景的应用地图（四个场景）

1. 新人的业务问答：「这个模块的历史坑有哪些」——从 bug 库和文档里检索回答
2. 用例生成时的上下文增强：生成前自动检索同类需求的历史用例和 bug，生成的用例带着业务记忆
3. 历史 bug 检索：「这个报错以前出过吗」——语义检索找相似案例
4. 规范查询：团队流程和 checklist 问答

第三步：讲落地的关键环节

环节	要点
知识整理	文档切片、bug 库结构化——垃圾进垃圾出
检索质量	切片粒度、向量化的效果——检索不准，生成再好也白搭
效果验收	建问答评测集，回答的准确率可量化

三个环节里检索质量是命门——能点到这层的说明真做过。

第四步：讲和纯微调的对比选型

知识频繁更新（bug 天天新增）的场景 RAG 优于微调（改知识库即生效，微调要重训），成本也低一个量级——业务知识类首选 RAG。

收尾：讲演进方向

RAG 从「问答」走向「工作流的组件」（生成用例的流程里自动调检索模块）——它从独立产品变成 AI 测试链路里的一个零件。

考察重点

维度	说明
企业动机	RAG 是企业落地 LLM 的最主流形态——停留在「会聊天」的候选人和能聊 RAG 的候选人差一个岗位级别
过线标准	原理一句话 + 测试场景应用 + 检索质量是命门的认知
区分度	讲知识整理的垃圾进垃圾出、讲问答评测集量化的是真落地的
加分项	RAG 和微调的选型逻辑
减分项	把 RAG 讲成「把文档全部贴给 AI」（长上下文硬塞），不懂检索的意义

来源

整理自知识星球帖《面试情报 06｜AI 测试提效 20 题》，返回题库。