RAG 开发 6 个阶段优化策略分析

把 RAG 优化拆成文档加载、文档切割、文档嵌入、相似性检索、上下文处理、生成流程六个阶段。

01. LLM 应用中的 RAG 开发阶段

在 RAG 应用开发中，无论架构多复杂，接入了多少组件，使用了多少优化策略与特性，所有优化的最终目标都是 提升LLM生成内容的准确性，而对于 Transformer架构类型 的大模型来说，要实现这个目标，一般只需要 3 个步骤：

1. 传递更准确的内容：传递和提问准确性更高的内容，会让 LLM 能识别到关联的内容， 生成的内容准确性更高。
2. 让重要的内容更靠前：GPT 模型的注意力机制会让传递 Prompt 中更靠前的内容权重更高，越靠后权重越低。
3. 尽可能不传递不相关内容：缩短每个块的大小，尽可能让每个块只包含关联的内容，缩小不相关内容的比例。

看起来很简单，但是目前针对这 3 个步骤 N 多研究员提出了不少方案，比较遗憾的是，目前也没有一种统一的方案，不同的场合仍然需要考虑不同的方案结合才能实现相对好一点的效果，并不是所有场合都适合配置很复杂的优化策略。

[!IMPORTANT] 在 RAG 应用开发中，使用的优化策略越多，单次响应成本越高，性能越差，需要合理使用。

映射到 RAG 中，其实就是 切割合适的文档块、更准确的搜索语句、正确地排序文档、剔除重复无关的检索内容，所以在 RAG应用开发 中，想进行优化，可以针对 query(提问查询)、TextSplitter(文本分割器)、VectorStore(向量数据库)、Retriever(检索器)、Prompt(基础prompt编写) 这几个组件。

在前面掌握的 LLM 应用开发中，我们构建了一个应用开发流程图，涵盖了 向量数据库、检索器、Prompt、记忆、输出解析器、大语言模型、运行时配置、大模型生成 等阶段，可以优化 RAG 的组件使用红圈覆盖如下：

在完整的 LLM 应用流程中拆解 RAG 开发阶段并进行优化看起来相对繁琐，可以考虑单独将 RAG 开发阶段的流程拎出来，并针对性对每个阶段进行优化与调整，按照不同的功能模块，共可以划分成 6 个阶段：查询转换、路由、查询构建、索引、检索 和 生成。

02. RAG 开发 6 个阶段优化策略

在 RAG 开发的 6 个阶段中，不同的阶段拥有不同的优化策略，需要针对不同的应用进行特定性的优化，目前市面上常见的优化方案有：问题转换、多路召回、混合检索、搜索重排、动态路由、图查询、问题重建、自检索 等数十种优化策略，每种策略所在的阶段并不一致，效果也有差异，并且相互影响。

并且 RAG 优化和 LangChain 并没有关系，无论使用任何框架、任何编程语言，进行 RAG 开发时，掌握优化的思路才是最重要的！

将对应的优化策略整理到 RAG 运行流程中，优化策略与开发阶段对应图如下：

最新版 LangChain 用法提示

新项目要优先确认组件所在包名。核心抽象通常在 langchain_core，文档分割在 langchain_text_splitters，OpenAI 相关集成在 langchain_openai，大量社区组件在 langchain_community 或独立集成包中。

涉及 Retriever、Runnable、LCEL、LangGraph 的链路，建议用 invoke() / ainvoke() 作为统一调用入口，并把检索参数、路由条件、重排参数和降级策略显式配置出来。不要只照搬旧导入路径。

拓展

RAG 开发 6 个阶段优化策略分析 不应该孤立使用。RAG 优化通常要和评测集、召回日志、答案引用、用户反馈、成本统计一起看。只优化某一个环节，可能会让另一个环节退化。

工程上建议把 query、改写后的 query、召回文档、metadata filter、重排得分、最终 Prompt 和模型输出都记录下来。否则问题出现时，很难判断是加载、切分、Embedding、检索、重排、Prompt 还是生成阶段出了问题。

常见问题

什么时候需要使用这个策略？

当普通向量检索已经不能稳定命中关键证据，或者复杂问题经常漏召回、召回重复、上下文不完整时，就需要引入该类优化。

它能替代基础 RAG 链路吗？

不能。优化策略依赖基础链路。文档质量、chunk 设计、Embedding 模型、metadata 规范和 Retriever 配置没有打好，后续策略只能缓解，不能根治。

如何判断优化是否有效？

用固定评测集对比优化前后：召回命中率、答案正确率、引用正确率、拒答准确率、延迟和成本。只看单个 demo 很容易误判。

面试题

RAG 优化应该从哪里开始？

先定位问题阶段：文档是否解析正确、chunk 是否完整、Embedding 是否适合、检索是否命中、上下文是否可用、模型是否按证据回答。定位后再选择对应策略。

为什么复杂 RAG 系统需要可观测性？

因为答案错误可能来自任意环节。没有检索日志、重排分数、Prompt 和输出记录，就只能靠猜。

如何避免优化策略越加越乱？

每个策略都要有触发条件、输入输出、评测指标和降级方案。能用简单策略解决的问题，不要过早引入复杂链路。

生产问题排查

问题	常见原因	处理方式
优化后更慢	多路检索、重排或图分支增加调用次数	增加超时、缓存、并行和候选裁剪
召回更多但更乱	多查询或混合检索没有去重和重排	使用 RRF、rerank、source_id 去重
答案仍然无依据	上下文质量低或 Prompt 没有约束证据	增加引用要求、拒答策略和证据检查
成本上涨明显	过多 LLM 改写、摘要或评估调用	缓存中间结果，限制触发条件
线上效果不稳定	缺少评测集和回归流程	固化 golden set，发布前跑回归