为什么RAG不是算法问题而是工程问题RAG 进阶10 个优化技巧RAG 的基础流程并不复杂真正困难的是让它在真实业务中同时做到检索准确、上下文完整、生成可信、延迟可控、成本可接受。一、为什么说 RAG 是工程问题一个 RAG 系统的最终效果不由某一个算法单独决定而是由整条链路共同决定用户问题 ↓ 查询理解与改写 ↓ 多路召回关键词 / 向量 / 元数据 ↓ 结果融合、去重与 Rerank ↓ 上下文组织Stuff / Refine / Tree Summarize ↓ LLM 生成答案任意环节出现问题都可能导致最终回答失真。例如文档切分破坏语义、查询表达与知识库不一致、召回结果不完整、相关文档排序靠后或者上下文过长导致重要信息被淹没。二、10 个优化技巧总览阶段优化技巧解决的核心问题检索1. 摘要检索原文太长、主题匹配不准确检索2. 子问题检索复杂问题包含多个意图检索3. 句子窗口检索小块精准但上下文不足检索4. 多路召回单一检索方式容易漏召回检索5. Rerank 重排序候选多但真正相关的内容排位靠后生成6. Refine 迭代精炼多个知识块无法一次性高质量整合生成7. 多文档 Refine跨文档信息需要逐步补充与修正生成8. Tree Summarize超长上下文与串行处理速度慢查询9. 改写提问用户表达模糊、口语化或缺少上下文数据10. 合理利用元数据搜索范围过大、业务条件无法过滤三、检索优化先找得全再排得准1. 摘要检索用摘要定位用原文回答摘要检索属于典型的Small-to-Big思路建库时为原始文档或父文本块生成简洁摘要检索时对摘要进行向量匹配命中摘要后取回其对应的原始文档或完整父文本最终让 LLM 基于原文回答而不是只基于摘要作答。原始文档 → 文本切分 → 生成摘要 → 摘要向量化并建立索引 ↓ 用户问题 → 检索摘要 → 找到映射关系 → 返回原始文本 → LLM这种方式兼顾了小文本的检索精度和大文本的上下文完整性。需要注意摘要质量会直接影响召回摘要遗漏的细节可能永远无法进入候选集。2. 子问题检索先拆解分头找再汇总当用户问题同时包含对比、因果、时间线或多个实体时直接检索往往只能覆盖其中一部分。可以先由 LLM 将复杂问题拆成若干自包含的子问题再分别检索并汇总。复杂问题 ├── 子问题 1 → 检索结果 A ├── 子问题 2 → 检索结果 B └── 子问题 3 → 检索结果 C ↓ 合并后生成答案高质量子问题应满足自包含脱离原问题也能独立理解具体可直接用于事实检索相关所有子问题都服务于原始意图有逻辑顺序便于后续汇总与推理。该方法覆盖面强但会增加 LLM 调用次数、检索次数和整体延迟。3. 句子窗口检索检索中心句返回上下文窗口句子窗口检索同样是 Small-to-Big索引的最小单元是句子命中后返回该句前后若干句组成的窗口。句子 N-2 | 句子 N-1 |【命中的中心句 N】| 句子 N1 | 句子 N2 ↑ 精确检索 └──────── 返回完整窗口 ────────┘优点是检索粒度细、噪声少并能补足代词指向和上下文关系难点是需要维护“中心句—原文窗口”的映射而且窗口大小必须根据数据集调试。4. 多路召回不要把所有鸡蛋放在一个篮子里不同检索方式各有所长关键词检索BM25擅长专有名词、编号、日期和精确词匹配向量检索擅长语义相近但表达不同的内容元数据过滤 / 结构化查询擅长部门、时间、权限、类型等明确条件其他领域检索器可按业务接入知识图谱、SQL 或全文搜索。多路结果的分数尺度不同不能简单相加。视频中给出了基于排名的融合思路RRF(d)∑i1m1kranki(d) RRF(d)\sum_{i1}^{m}\frac{1}{krank_i(d)}RRF(d)i1∑mkranki(d)1其中ranki(d)rank_i(d)ranki(d)表示文档ddd在第iii路检索中的名次kkk是平滑常数。一个文档若在多路结果中都排名靠前其融合分数会更高。融合时只依赖名次不直接比较 BM25 分数、余弦相似度和其他检索器的原始分数因此能够避开不同评分尺度难以统一的问题。工程实现时还需要先按文档 ID 去重再累加每一路的 RRF 得分并按总分降序排列。5. Rerank粗召回之后再精排多路召回负责“尽可能找全”Rerank 负责“把真正相关的文档排到前面”。对比项多路召回Rerank目标提高召回率 Recall提高精确率 Precision阶段生成候选集候选集后处理特点快、范围广、允许少量噪声慢但判断更细致常见实现BM25、向量检索、元数据过滤Cross-Encoder、专用 Reranker结果较大的候选集合Top K 高相关文档典型链路为多路粗召回 → 合并去重 → Rerank 精排 → 截取 Top K → 交给 LLMReranker 会同时读取“问题 候选文档”进行深层交互式相关性判断通常比单独计算向量相似度更准确但计算成本也更高。四、生成优化不是把所有文档直接塞给模型检索到大量参考文档后如果直接拼接Stuff到提示词中常见问题是超出模型上下文窗口文档之间缺少连贯性关键信息被大量噪声淹没Token 成本和响应延迟快速上升。6. Refine让答案逐轮迭代Refine 不一次性处理所有知识块而是先根据第一个知识块生成初始答案再结合后续知识块不断修正和补充。问题 知识块 1 → 答案 1 答案 1 知识块 2 → 答案 2 答案 2 知识块 3 → 答案 3 ↓ 最终答案它适合答案质量优先、知识块存在顺序关系的场景缺点是串行执行较慢而且前序错误可能被带入后续步骤。7. 多文档 Refine跨文档持续补全当参考资料来自多份文档时可以把文档逐个或分批送入模型新文档包含补充信息时扩展答案包含冲突信息时修正答案没有新增价值时保留原答案。工程实现中要特别处理文档优先级与处理顺序重复内容的去重冲突事实的来源与时间中间答案过长时的压缩策略。8. Tree Summarize并行处理分层汇总Tree Summarize 采用“分而治之”的方式先并行总结多个文本块再逐层合并中间结果最终得到答案。Chunk 1 ─┐ Chunk 2 ─┴→ 摘要 A ─┐ ├→ 最终答案 Chunk 3 ─┬→ 摘要 B ─┘ Chunk 4 ─┘模式优点局限Stuff一次调用、速度快、连贯性好容易超过上下文窗口Refine可处理长文档答案可持续修正串行、慢、成本高可能累积错误Tree Summarize可并行适合超长文档层级更复杂底层细节可能在汇总中丢失五、查询与数据优化9. 改写提问把“用户语言”转成“检索语言”用户输入常常口语化、指代不清或缺少关键词。查询改写需要在不改变原始意图的前提下对问题进行补全、规范化或扩展。常见方式包括补全多轮对话中的指代例如把“那里有什么景点”改写为“北京有哪些景点”生成多个语义等价查询提高召回覆盖提取实体、时间、产品名和业务术语将复杂问题拆成可检索的短查询对查询做拼写纠错和同义词扩展。查询改写的风险是“改得太多”导致用户原始意图发生漂移因此应保留原查询并对改写结果设置数量与长度限制。10. 合理利用元数据先过滤再搜索元数据是“描述数据的数据”例如department: finance document_type: policy publish_date: 2026-09-01 version: v3 language: zh-CN permission_level: internal当用户问“财务部 2026 年最新报销制度”时可以先使用部门、时间、文档类型等字段过滤再在较小范围内进行向量检索。这样既提高准确率也能降低延迟与计算成本。元数据还可以用于权限隔离避免召回用户无权访问的内容版本控制优先使用最新有效文档来源追踪让答案可以引用原始资料业务路由将问题发送到对应知识库或检索器。六、推荐的工程化优化顺序不要一次堆叠全部策略建议按问题定位逐步优化建立评估集收集真实问题、标准答案与相关文档确认是否召回正确文档若没有优先调整切分、Embedding、查询改写和多路召回确认正确文档是否排在前面若靠后引入融合排序与 Rerank确认上下文是否完整若片段太碎使用摘要检索、句子窗口或父子文档确认模型是否正确利用上下文若召回正确但回答错误优化 Prompt 与生成策略最后优化性能缓存、并行、批处理、降级与超时控制。一次只修改一个变量并记录 Recall、Precision、答案忠实度、延迟和 Token 成本否则很难判断究竟是哪项改动产生了效果。七、小结RAG 优化不是“更换一个更强的模型”就能解决的问题而是一项贯穿数据、检索、排序、上下文组织和生成的系统工程。Small-to-Big兼顾检索精度与上下文完整性多路召回负责扩大覆盖面Rerank负责提高最终精度Refine 与 Tree Summarize解决多文档和超长上下文的组织问题查询改写与元数据过滤让搜索更贴近真实业务约束。真正有效的方案不是把所有技巧全部打开而是先通过评估定位瓶颈再选择成本与收益最合适的策略组合。
为什么RAG不是算法问题而是工程问题RAG 进阶10 个优化技巧RAG 的基础流程并不复杂真正困难的是让它在真实业务中同时做到检索准确、上下文完整、生成可信、延迟可控、成本可接受。一、为什么说 RAG 是工程问题一个 RAG 系统的最终效果不由某一个算法单独决定而是由整条链路共同决定用户问题 ↓ 查询理解与改写 ↓ 多路召回关键词 / 向量 / 元数据 ↓ 结果融合、去重与 Rerank ↓ 上下文组织Stuff / Refine / Tree Summarize ↓ LLM 生成答案任意环节出现问题都可能导致最终回答失真。例如文档切分破坏语义、查询表达与知识库不一致、召回结果不完整、相关文档排序靠后或者上下文过长导致重要信息被淹没。二、10 个优化技巧总览阶段优化技巧解决的核心问题检索1. 摘要检索原文太长、主题匹配不准确检索2. 子问题检索复杂问题包含多个意图检索3. 句子窗口检索小块精准但上下文不足检索4. 多路召回单一检索方式容易漏召回检索5. Rerank 重排序候选多但真正相关的内容排位靠后生成6. Refine 迭代精炼多个知识块无法一次性高质量整合生成7. 多文档 Refine跨文档信息需要逐步补充与修正生成8. Tree Summarize超长上下文与串行处理速度慢查询9. 改写提问用户表达模糊、口语化或缺少上下文数据10. 合理利用元数据搜索范围过大、业务条件无法过滤三、检索优化先找得全再排得准1. 摘要检索用摘要定位用原文回答摘要检索属于典型的Small-to-Big思路建库时为原始文档或父文本块生成简洁摘要检索时对摘要进行向量匹配命中摘要后取回其对应的原始文档或完整父文本最终让 LLM 基于原文回答而不是只基于摘要作答。原始文档 → 文本切分 → 生成摘要 → 摘要向量化并建立索引 ↓ 用户问题 → 检索摘要 → 找到映射关系 → 返回原始文本 → LLM这种方式兼顾了小文本的检索精度和大文本的上下文完整性。需要注意摘要质量会直接影响召回摘要遗漏的细节可能永远无法进入候选集。2. 子问题检索先拆解分头找再汇总当用户问题同时包含对比、因果、时间线或多个实体时直接检索往往只能覆盖其中一部分。可以先由 LLM 将复杂问题拆成若干自包含的子问题再分别检索并汇总。复杂问题 ├── 子问题 1 → 检索结果 A ├── 子问题 2 → 检索结果 B └── 子问题 3 → 检索结果 C ↓ 合并后生成答案高质量子问题应满足自包含脱离原问题也能独立理解具体可直接用于事实检索相关所有子问题都服务于原始意图有逻辑顺序便于后续汇总与推理。该方法覆盖面强但会增加 LLM 调用次数、检索次数和整体延迟。3. 句子窗口检索检索中心句返回上下文窗口句子窗口检索同样是 Small-to-Big索引的最小单元是句子命中后返回该句前后若干句组成的窗口。句子 N-2 | 句子 N-1 |【命中的中心句 N】| 句子 N1 | 句子 N2 ↑ 精确检索 └──────── 返回完整窗口 ────────┘优点是检索粒度细、噪声少并能补足代词指向和上下文关系难点是需要维护“中心句—原文窗口”的映射而且窗口大小必须根据数据集调试。4. 多路召回不要把所有鸡蛋放在一个篮子里不同检索方式各有所长关键词检索BM25擅长专有名词、编号、日期和精确词匹配向量检索擅长语义相近但表达不同的内容元数据过滤 / 结构化查询擅长部门、时间、权限、类型等明确条件其他领域检索器可按业务接入知识图谱、SQL 或全文搜索。多路结果的分数尺度不同不能简单相加。视频中给出了基于排名的融合思路RRF(d)∑i1m1kranki(d) RRF(d)\sum_{i1}^{m}\frac{1}{krank_i(d)}RRF(d)i1∑mkranki(d)1其中ranki(d)rank_i(d)ranki(d)表示文档ddd在第iii路检索中的名次kkk是平滑常数。一个文档若在多路结果中都排名靠前其融合分数会更高。融合时只依赖名次不直接比较 BM25 分数、余弦相似度和其他检索器的原始分数因此能够避开不同评分尺度难以统一的问题。工程实现时还需要先按文档 ID 去重再累加每一路的 RRF 得分并按总分降序排列。5. Rerank粗召回之后再精排多路召回负责“尽可能找全”Rerank 负责“把真正相关的文档排到前面”。对比项多路召回Rerank目标提高召回率 Recall提高精确率 Precision阶段生成候选集候选集后处理特点快、范围广、允许少量噪声慢但判断更细致常见实现BM25、向量检索、元数据过滤Cross-Encoder、专用 Reranker结果较大的候选集合Top K 高相关文档典型链路为多路粗召回 → 合并去重 → Rerank 精排 → 截取 Top K → 交给 LLMReranker 会同时读取“问题 候选文档”进行深层交互式相关性判断通常比单独计算向量相似度更准确但计算成本也更高。四、生成优化不是把所有文档直接塞给模型检索到大量参考文档后如果直接拼接Stuff到提示词中常见问题是超出模型上下文窗口文档之间缺少连贯性关键信息被大量噪声淹没Token 成本和响应延迟快速上升。6. Refine让答案逐轮迭代Refine 不一次性处理所有知识块而是先根据第一个知识块生成初始答案再结合后续知识块不断修正和补充。问题 知识块 1 → 答案 1 答案 1 知识块 2 → 答案 2 答案 2 知识块 3 → 答案 3 ↓ 最终答案它适合答案质量优先、知识块存在顺序关系的场景缺点是串行执行较慢而且前序错误可能被带入后续步骤。7. 多文档 Refine跨文档持续补全当参考资料来自多份文档时可以把文档逐个或分批送入模型新文档包含补充信息时扩展答案包含冲突信息时修正答案没有新增价值时保留原答案。工程实现中要特别处理文档优先级与处理顺序重复内容的去重冲突事实的来源与时间中间答案过长时的压缩策略。8. Tree Summarize并行处理分层汇总Tree Summarize 采用“分而治之”的方式先并行总结多个文本块再逐层合并中间结果最终得到答案。Chunk 1 ─┐ Chunk 2 ─┴→ 摘要 A ─┐ ├→ 最终答案 Chunk 3 ─┬→ 摘要 B ─┘ Chunk 4 ─┘模式优点局限Stuff一次调用、速度快、连贯性好容易超过上下文窗口Refine可处理长文档答案可持续修正串行、慢、成本高可能累积错误Tree Summarize可并行适合超长文档层级更复杂底层细节可能在汇总中丢失五、查询与数据优化9. 改写提问把“用户语言”转成“检索语言”用户输入常常口语化、指代不清或缺少关键词。查询改写需要在不改变原始意图的前提下对问题进行补全、规范化或扩展。常见方式包括补全多轮对话中的指代例如把“那里有什么景点”改写为“北京有哪些景点”生成多个语义等价查询提高召回覆盖提取实体、时间、产品名和业务术语将复杂问题拆成可检索的短查询对查询做拼写纠错和同义词扩展。查询改写的风险是“改得太多”导致用户原始意图发生漂移因此应保留原查询并对改写结果设置数量与长度限制。10. 合理利用元数据先过滤再搜索元数据是“描述数据的数据”例如department: finance document_type: policy publish_date: 2026-09-01 version: v3 language: zh-CN permission_level: internal当用户问“财务部 2026 年最新报销制度”时可以先使用部门、时间、文档类型等字段过滤再在较小范围内进行向量检索。这样既提高准确率也能降低延迟与计算成本。元数据还可以用于权限隔离避免召回用户无权访问的内容版本控制优先使用最新有效文档来源追踪让答案可以引用原始资料业务路由将问题发送到对应知识库或检索器。六、推荐的工程化优化顺序不要一次堆叠全部策略建议按问题定位逐步优化建立评估集收集真实问题、标准答案与相关文档确认是否召回正确文档若没有优先调整切分、Embedding、查询改写和多路召回确认正确文档是否排在前面若靠后引入融合排序与 Rerank确认上下文是否完整若片段太碎使用摘要检索、句子窗口或父子文档确认模型是否正确利用上下文若召回正确但回答错误优化 Prompt 与生成策略最后优化性能缓存、并行、批处理、降级与超时控制。一次只修改一个变量并记录 Recall、Precision、答案忠实度、延迟和 Token 成本否则很难判断究竟是哪项改动产生了效果。七、小结RAG 优化不是“更换一个更强的模型”就能解决的问题而是一项贯穿数据、检索、排序、上下文组织和生成的系统工程。Small-to-Big兼顾检索精度与上下文完整性多路召回负责扩大覆盖面Rerank负责提高最终精度Refine 与 Tree Summarize解决多文档和超长上下文的组织问题查询改写与元数据过滤让搜索更贴近真实业务约束。真正有效的方案不是把所有技巧全部打开而是先通过评估定位瓶颈再选择成本与收益最合适的策略组合。
