随着RAG（检索增强生成）应用遍地开花，一个核心痛点也随之浮现：如何让模型的回答质量更上一层楼？这个问题的答案，其实是由一系列精雕细琢的优化策略串联而成。接下来，我们将系统梳理当前主流的RAG优化方法，并配合图解，帮助你快速建立起一张清晰的技术攻关地图。

先来看最基础的RAG工作流程，大致是这样：将文档切分为小块，导入向量数据库（例如 Milvus 或 Zilliz Cloud），然后根据用户提出的问题（query）检索出最相关的 Top K 个文档片段。最后，将这些“参考素材”连同原始问题一同馈送给大语言模型（LLM），由模型生成最终回答。

将这个流程图印在脑海中，后续提到的各种优化版本都离不开这个基础架构——你可以随时将其作为对照基准。

主流RAG增强方法布局一览

各种RAG增强方法，按照其在流程中“施展功力”的位置，大致可以归为以下几类：

• 查询增强（Query Enhancement）： 这类方法在输入端对用户的原始问题进行“加工”，使其表达更精准、更易于被检索系统理解。对应基础流程图中的第②步。
• 索引增强（Indexing Enhancement）： 这类方法在数据入库阶段“做文章”，通过优化分块策略、建立多级索引等举措，为后续的精准检索铺设坚实基础。主要对应第①步，有时也会与②、③步产生联动。
• 检索器增强（Retriever Enhancement）： 聚焦于检索过程本身，借助多种策略提升召回内容的相关性和准确度。对应第③步。
• 生成器增强（Generator Enhancement）： 在将检索结果拼装成提示词（prompt）供LLM处理时，通过调整内容编排与顺序等方式，引导模型产出更优质的答案。对应第④、⑤步。
• RAG流程增强（RAG Pipeline Enhancement）： 这类方法走得更远，引入动态流程、智能体（Agent）和工具（Tool）的理念，对整体RAG流程进行灵活编排与深度优化。

下面，我们逐一拆解这些类别下的具体方法。

查询增强（Query Enhancement）

1. 假设性问题

这个思路颇为巧妙：先让LLM为每个文档块生成一个“假设性问题”——即该文档块最有可能回答的典型问题。这样一来，检索任务就从“根据文档找答案”转变为“匹配相似问题”。这种 query-to-query 的匹配，本质上是域内对称搜索任务，相比不对称的 query-to-document 更加直接、易于实现。当然，代价也很明显：需要额外的LLM调用来生成假设问题，且生成的时机与质量都存在一定的不确定性。

2. HyDE（假设文档嵌入）

HyDE 的原理与假设性问题类似，但方向相反：它不是对文档生成问题，而是基于用户的 query 生成一个“假答案”（fake answer）。这个假答案的内容未必准确，但其向量嵌入（embedding）会在语义空间中与真正相关的文档更为“贴近”。最终系统检索的是与该假答案最匹配的真实文档。同样，这种方法缓解了跨域不对称性问题，但也带来了额外的计算开销与不确定性。

3. 子查询

面对一个复杂问题，例如“Milvus 和 Zilliz Cloud 在功能上有哪些区别？”，直接检索很难找到文本直接进行对比。此时，最佳做法是将它拆解为两个子问题：“Milvus 有哪些功能？”和“Zilliz Cloud 有哪些功能？”。这两个子查询并行检索后，再将获得的上下文一并交给LLM，使其综合研判并生成最终答案。这个拆解工作通常可以由 LLM-based Agent 自动完成。

4. 退后一步提示词

有时问题描述得过于具体反而妨碍检索。例如“我有一个100亿条记录的数据集，想存在 Milvus 里查询，行不行？”这个问题情景太过细化，难以直接匹配。不妨让 LLM 将其“提炼”成一个更通用的退后一步问题：“Milvus 能处理的数据集大小上限是多少？”。基于此问题检索，更容易找到能解答原始需求的文档块。在处理具体且复杂的提问时，这种方式效果显著。

索引增强（Indexing Enhancement）

1. 自动合并块

在建立索引时，可以设计一种“嵌套”策略：设置两种粒度的块，一个是细粒度的小块（child chunk），另一个是包含它的父块（parent chunk）。检索时，先搜索那些小块。如果发现 Top K 个命中结果中，有超过 N 个都属于同一个父块，那就表明这个“大段落”信息高度集中。此时，不再使用小块，而是直接将整个父块作为上下文送给 LLM。这样一来，既保有检索精度，又避免了上下文的碎片化问题。

2. 分层索引

为数据构建两层索引：一层是摘要索引，一层是详细文档块的索引。检索分为两步：先借助摘要索引快速定位相关文档，再在被选中的文档内部进行精确匹配。这好比先去图书馆的目录区找到书架号，再前往对应书架取书。这种方法尤其适合数据量庞大、层次结构清晰的场景。

3. 混合检索与重排序

单纯依赖向量召回，有时会“马失前蹄”，遗漏关键内容。混合检索的思路很简单：在向量相似性召回之外，额外增加一路或多路召回手段，例如基于词频的 BM25 或 SPLADE 等稀疏嵌入模型。多路召回的候选结果需要经过一个重排序（Rerank）模块，你可以采用简单的 RRF 算法，也可以使用更精密的 Cross-Encoder 模型进行筛选与排序，最终选出最优质的片段。这种策略能够有效弥补单一召回方式的盲区。

检索器增强（Retriever Enhancement）

1. 句子窗口检索

这个方法的一个精妙之处在于，它将用于检索的块与用于生成的块解耦开来。系统检索到的可能是一个小句子块，但实际提供给 LLM 的，是以该句子块为中心、包含前后文信息的“大窗口”。这样做的好处显而易见：为 LLM 提供更丰富的上下文，降低信息丢失的风险。当然，窗口大小需要根据具体业务场景灵活调整，以在信息丰富度与干扰噪声之间找到平衡点。

2. 元数据过滤

如果数据附带了丰富的元信息（如时间、类别、作者等），那就不要浪费。在检索出候选文档后，可以根据元数据（例如“只保留2023年的财报”）进行二次过滤。这能显著提升最终结果的相关性，尤其适用于那些数据量大、元信息结构清晰的场景。

生成器增强（Generator Enhancement）

1. 提示词压缩

检索回来的文档块中，往往夹杂着一些噪声信息，这些内容不仅无用，还可能干扰 LLM 的回答。同时，LLM 的上下文窗口也存在容量限制。因此，一种有效的策略是在信息送入 LLM 之前，先对上下文进行压缩——突出关键段落，剔除无关内容，甚至可以将长文本提炼为简短的摘要。你可以训练专门的小模型来执行这项任务，其原理类似于上一节提到过的重排序与过滤。

2. 调整知识块顺序

Lost in the Middle 这篇论文揭示了一个现象：LLM 在阅读长文档时，更容易记住开头和结尾的内容，中间部分则容易被“遗忘”。这一发现为我们提供了一个非常具体的操作指南：在将多个检索结果拼接成提示词时，可以将置信度最高的块放在开头和结尾，将置信度稍低或关联性稍弱的块穿插在中间。这种编排方式能最大限度地提升 LLM 对关键参考信息的利用率。

RAG流程增强（RAG Pipeline Enhancement）

1. 自我反馈机制

这里引入了智能体（Agent）中“自我反思”（self-reflection）的思想。当系统初次召回的 Top K 个块中，如果某些块看起来置信度不高或存在歧义，先不要急于使用。可以让系统对这些块执行一次自我验证，确认它们是否真正能够回答当前问题。验证方式多种多样，例如利用一个 NLI（自然语言推理）模型进行判断，或者直接调用网络搜索工具进行交叉验证。这就构成了一个简单的“反思”闭环。

2. 查询路由

并非所有问题都需要经过 RAG 流程。对于一些简单直接的事实性问题（比如“今天星期几？”），强行套用 RAG 不仅耗时，还可能引入不必要的噪声。因此，可以在入口处设置一个路由判断模块。这个路由器（可以是一个 LLM、一个分类模型，甚至一组简单的规则）会判断当前问题是否需要走 RAG 流程。如果不需要，就直接让 LLM 回答；如果需要，再进入后续的完整 RAG 流程。这种做法在实际生产环境中非常实用，既能分流请求、加快响应速度，又能避免干扰信息带来的负面影响。更进一步，查询路由还可以用来判断是否需要调用特定工具（如网络搜索、图片检索），甚至是否需要执行子查询。这是一种灵活的设计思路，具体如何落地，完全取决于业务需求。

总结

基础的RAG流程看似简洁，但在实际业务中，想要取得真正令人满意的效果，离不开一系列高级优化技巧的加持。本文对目前常用的RAG增强方法进行了系统化的归类和梳理，并通过图示辅助理解。希望这份“技术地图”能帮助你更快地掌握这些概念，并将其应用到实际项目中，加速RAG应用的优化落地。