为什么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】| 句子 N+1 | 句子 N+2 ↑ 精确检索 └──────── 返回完整窗口 ────────┘优点是检索粒度细、噪声少，并能补足代词指向和上下文关系；难点是需要维护“中心句—原文窗口”的映射，而且窗口大小必须根据数据集调试。
4. 多路召回：不要把所有鸡蛋放在一个篮子里
不同检索方式各有所长：
- 关键词检索（BM25）：擅长专有名词、编号、日期和精确词匹配；
- 向量检索：擅长语义相近但表达不同的内容；
- 元数据过滤 / 结构化查询：擅长部门、时间、权限、类型等明确条件；
- 其他领域检索器：可按业务接入知识图谱、SQL 或全文搜索。
多路结果的分数尺度不同，不能简单相加。视频中给出了基于排名的融合思路：
RRF(d)=∑i=1m1k+ranki(d) RRF(d)=\sum_{i=1}^{m}\frac{1}{k+rank_i(d)}RRF(d)=i=1∑mk+ranki(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解决多文档和超长上下文的组织问题；
- 查询改写与元数据过滤让搜索更贴近真实业务约束。
真正有效的方案不是把所有技巧全部打开，而是先通过评估定位瓶颈，再选择成本与收益最合适的策略组合。
