RAG 系统效果不理想？七个被忽视的优化点

## 为什么你的 RAG 效果不好 RAG（检索增强生成）看起来很简单：文档切块 → 向量化 → 检索 → 拼进 Prompt。但实际项目中，多数团队会遇到同样的问题——检索到的内容与问题不相关，或答案不完整。 根据我们在企业项目中的实践经验，问题通常集中在以下七个环节。 ## 一、文档切分粒度 最常见的错误是按固定字符数切分。正确做法是**按语义结构切分**： - Markdown 文档优先按标题层级切分 - 表格与列表保持完整，不跨块断开 - 代码块不切断 - 单块控制在 300-800 token，并保留 10-15% 重叠 ## 二、元数据过滤 纯向量检索忽略了文档的结构信息。为每个块附加元数据（文档类型、时间、部门、层级路径），可以在检索时先做过滤再算相似度，显著提升相关性。 ## 三、混合检索 向量检索擅长语义匹配，但对专有名词、编号、精确短语不敏感。引入 BM25 关键词检索做混合，并对两路结果做倒数排名融合（RRF），通常能带来 15-30% 的召回提升。 ## 四、重排序（Rerank） 初次召回的数量应该大于最终使用数量。召回 Top 50，用重排序模型（如 BGE-Reranker）重新打分，取 Top 5 送入模型。这一步是投入产出比最高的优化。 ## 五、查询改写 用户的原始提问往往不适合直接检索。可以做三件事： 1. **查询扩展**：生成 2-3 个同义改写，多路检索后合并 2. **HyDE**：先让模型生成一个假设答案，用答案去检索 3. **指代消解**：多轮对话中把「它」「这个」替换为具体名词 ## 六、上下文组织 检索到 5 个块，怎么放进 Prompt？不是简单拼接。建议： - 按相关性排序，最相关的放在最前和最后（利用首尾位置偏好） - 为每个块标注来源，便于模型引用 - 控制总长度，超出时做摘要压缩 ## 七、效果评测 没有评测就没有优化。必须构建评测集： - 准备 100-200 个真实问题 - 标注标准答案与应召回的文档块 - 分别评测**召回率**（是否检索到）与**忠实度**（答案是否基于检索内容） ## 总结 RAG 的优化不是调参玄学，而是系统工程。建议按「切分 → 元数据 → 混合检索 → 重排序 → 查询改写 → 上下文组织 → 评测」的顺序逐步推进，每一步都做 A/B 对比。 启数AI教育 AI 大模型课程第二阶段用 88 课时完整覆盖上述优化链路，学员需在真实企业文档集上完成端到端调优。