一个 RAG 系统上线后，真正的挑战不是第一次搭好能跑，而是如何让它持续变好。用户的问题千奇百怪，业务知识也在不断演变，没有任何一套初始配置能一劳永逸。优秀团队与一般团队的区别，往往在于能否建立一套可持续的优化闭环：发现问题、分析根因、调整策略、验证效果，然后进入下一轮。这一节我们就来拆解这个闭环的实际操作方式。
23.4.1 第一步：系统化收集 bad case
优化不能靠“偶尔发现一个问题就改一下”。首先需要建立一条稳定的 bad case 收集渠道，让问题自动浮现出来。
常见的收集来源：
- 用户反馈：在回答下方设置“赞/踩”或“此回答是否有帮助”按钮，被踩的回答自动汇入待分析池。
- 运营抽检：定期（如每日或每周）抽取一定数量的真实对话记录，人工评估回答质量，标记不合格样本。
- 自动化监控：设置基础规则自动拦截明显异常，例如回答为空、检索相关度分数过低、回答中包含“抱歉，我无法”等拒答模版时打上标记。
- 边界案例主动挖掘：用脚本构造一批已知正确答案的测试问题，定期跑一遍，找出回答偏离预期的样本。
不管用哪种方式，每条 bad case 都要记录原始问题、最终回答、检索到的片段、用户反馈（如有）以及发现时间，为后续分析提供完整上下文。
23.4.2 第二步：精确定位根因
拿到一批 bad case 后，最大的误区是凭直觉直接改提示词或换模型。真正高效的做法是先定责：这个糟糕的回答到底是谁的锅？是没找对资料，还是找对了但没用好？
定位方法：顺着流水线逐层排查
- 检查检索结果
看一眼检索召回的内容，问自己：这里面有没有足够回答问题的信息？
- 如果没有，说明是检索问题（索引缺失、切块不当、查询表达不佳、相似度匹配失败）。
- 如果有，但模型仍然答错，说明是生成问题。
- 区分检索子问题
检索环节又可以从几个角度细分：
- 知识库覆盖不全：对应文档根本没入库，自然不可能召回。
- 切分粒度不当：好的信息被切断，导致检索到的片段是不完整的碎片。
- query 改写不足：用户口语化的问题和文档的专业表述在语义上匹配不上。
- 检索策略单一：只靠向量相似度，忽略了关键词精确匹配，导致一些专业术语查询效果差。
- 定位生成问题
如果检索片段明明包含正确答案，模型却答错或答偏：
- 提示词指令不明确：模型未能严格按照给定材料回答，加入了自己的“常识”。
- 上下文过长或信息冲突：检索到的多条片段相互矛盾，模型自行“和稀泥”输出一个错误折衷。
- 模型能力不足：面对复杂的归纳、推理任务，所用模型的理解能力确实跟不上。
在分析时，一个 bad case 不要只归一个原因。比如回答不准可能同时因为检索差了一点，生成又自由发挥了一下，两者叠加才变得不可接受。记录下来每一项贡献因素，为后续调优提供方向。
23.4.3 第三步：制定并执行调优策略
根因定位清楚后，策略调整才有针对性。调优手段大致分为三个层面：知识库层、检索层、生成层。
知识库与索引层优化
- 补全缺失内容：将缺漏的文档或关键信息手动补充入库，并在发布前复核。
- 调整切分策略：对于关键短段落容易被切断的情况，减小 chunk size；对于需要上下文才能理解的条款，增加 overlap 或者采用“父文档+子片段”的层级索引。
- 优化元数据过滤：如果用户提问带有明显的时间、部门、语言等属性，可在检索前利用元数据过滤，缩小召回范围，提高命中率。
检索层优化
- 混合检索：在纯向量检索基础上加入 BM25 等关键词检索，两者结果融合排序，解决专有名词、缩写、编号等向量匹配差的问题。
- 查询改写：在检索前，先用一个轻量级的改写步骤将用户问题补全、规范化为更利于检索的表达。例如将“怎么退”改写为“退货流程”，将“年假几天”改写为“员工年假天数规定”。
- 重排序（rerank）：在初检结果上，用更精准的重排序模型对 top-k 片段再打分，把最相关的片段挤到前面。
- 调整检索参数：尝试增大 top-k 值或调整相似度阈值，避免真正有用的片段被截断。
生成层优化
- 强化提示词约束：在 prompt 中更明确地要求模型“只使用提供的资料回答，资料不足以回答时明确说明”，并加上“禁止编造”等指令。
- 注入引用格式要求：强制要求回答用【来源：xxx】标注，抑制自由发挥。
- 处理信息冲突：在 prompt 中告知模型，如果多条资料存在矛盾，不要自行判断对错，而是如实列出不同说法并请用户核实。
- 模型选型与温度调整：对于需要严格事实性的场景，选择 foundational 能力更强的模型，并将 temperature 调至较低值，减少随机性。
策略调整的实用原则：一次只改一个变量。 如果同时改动切分方式、检索策略和提示词，后面效果变好或变差就无法归因，闭环就断了。
23.4.4 第四步：效果验证与闭环
策略调整后，必须用可量化的方式验证效果，而不是“感觉好像好了一点”。具体做法：
- 回归测试集：维护一份包含历史 bad case 以及典型场景的固定测试集（数量可从几十条逐渐积累到几百条），每次调整后跑一遍，看准确率或通过率的变化。
- 单 case 复测：对于驱动本次优化的具体 bad case，确认问题是否已修复，并检查修复是否引入了新的问题。
- 在线 A/B 测试（有条件时）：对于影响面较大的调整，可以在小流量上先验证新策略，观察用户点赞率、人工抽检通过率等指标对比，再全量上线。
- 记录调优日志：用一张表记录“日期、bad case 编号、根因、采取措施、测试结果、是否上线”，积累下来就是团队的优化知识库，避免反复踩坑。
验证通过后，这个之前的问题就从 bad case 转为已修复 case，加入回归测试集。同时，经过这一轮分析积累的经验也应及时沉淀为优化规则或自动化检查项（例如“新入库文档必须包含某个元数据字段”），让系统的质量防线逐步前移。
23.4.5 让闭环真正转起来
闭环的价值在于持续。建议团队以周为单位进行迭代：
- 每周末汇总本周 bad case，快速分类；
- 选择影响面最大的 1-3 个共性问题深入分析，确定调优方案；
- 工作日实施调整并跑完验证测试；
- 下周初观察在线表现，确认效果稳定。
通过这样一个“发现→分析→调整→验证”的节奏，RAG 系统不会随着时间的推移而老化，反而会随着业务理解的加深和数据的积累，逐渐变得精确、稳定、值得信赖。持续优化闭环，就是让 RAG 从“能用”走向“好用”的核心引擎。