检索增强生成（RAG）的完整工作流程，从宏观上看似乎只是“检索+生成”的简单组合，但深入实践后会发现，其中涉及的环节与决策点极为丰富。面对众多可选模块与技术，一个现实的问题随之而来：如何将它们有效整合，构建一套真正高效可靠的RAG系统？
下面，我们将这一问题逐一拆解。先从典型的RAG流程入手，再依次梳理每个模块中经过验证的“最佳实践”，最后探讨如何对整条系统进行端到端的评估。
RAG工作流程概览
先看一张典型的RAG流程图，以便对整个链条形成直观认知。
图 1：检索-增强生成工作流程
从用户提问到最终生成回复，中间包含了若干关键中间环节：
查询分类：首先判断用户问题是否需要检索外部知识。并非所有问题都需要联网查询，许多简单问题模型自身即可作答。
检索：若确需检索，则从知识库中提取最相关的文档。
重新排序：检索出的文档未必完全精确，需依据相关性重新排序，确保最可靠的排在最前。
重新打包：将筛选排序后的文档整理为结构化形式，便于后续处理。
总结：最后一步，从文档中提炼关键信息，去冗取精，生成最终答案。
此外，该图还揭示了一连串需要决策的问题：文档如何切分？选用哪种语义嵌入模型？向量数据库如何选择？模型怎样微调？每一步都有讲究。
查询分类
为何要先进行“查询分类”？道理很简单：并非所有用户提问都需要大动干戈地执行检索。模型自身已具备一定知识储备，强行检索不仅增加响应时间，有时还会引入不必要的噪声。
因此，合理的思路是：只有当问题超出模型参数中存储的知识范围时，才启动检索。实践中，可根据用户任务是否提供足够信息，将其划分为15种类型。那些完全依赖用户提供信息即可回答的任务，标记为“sufficient”，无需检索；而需模型动用外部知识才能回答的任务，则标记为“insufficient”，需要及时启动检索。
图 2：不同任务的检索要求分类
该分类过程通过训练一个分类器即可自动完成。
图 3：查询分类器的结果
分块
文档切分（Chunking）是整个RAG流程的基础。将长文档切分成小块，既能提高检索精度，又能避免将过长的内容直接塞给模型。
分块通常有三种层级可选：
标记级分块：最简单直接，但容易将一个完整句子从中切断，破坏语义，影响检索质量。
语义级分块：直接利用LLM判断句子在何处断开最合理，保留完整语义上下文，但计算时间较长。
句子级分块：一种折中方案，在保留语义与简洁高效之间取得了较好平衡。
实际应用中，句子级分块往往是更务实的选择。不过，即便采用句子级，仍有几个参数需仔细斟酌。
- Chunk Size 分块尺寸：块的大小直接影响性能。块越大，提供的语境越丰富，有助于模型理解，但处理速度会变慢；块越小，检索效率越高，但可能因缺乏上下文而答非所问。
衡量分块效果，主要关注两个指标：忠实度和相关性。忠实度指生成的回复是否脱离检索到的文本，相关性指检索到的文本与最终回复是否真正与用户问题相关。
- Chunk 组织形式：最终选型时，较小的块可设为175个字节，较大的块设为512个字节，块与块之间可保留20个字节的重叠。
嵌入模型的选择：实验数据显示，LLM-Embedder模型能达到与BAAI/bge-large-en相近的效果，但模型体积仅为后者的三分之一。因此，在性能与大小之间权衡，LLM-Embedder是非常划算的选择。
向量数据库
存储和检索这些高维向量自然离不开向量数据库。我们对五个主流的开源向量数据库进行了详细的横向对比：Weaviate、Faiss、Chroma、Qdrant 和 Milvus。
从对比结果来看，Milvus 在各项基本标准上表现全面，综合性能在开源选项中最为突出。
检索
检索模块的核心任务是根据用户查询，从已建库中找出最相关的top-k个文档。几种主流技术及其组合方式值得深入探讨。
查询重写：用户输入的查询可能不够精确，因此先用LLM对查询进行“清洗”，使其更好地匹配文档。
查询分解：用户问题可能较为复杂，可将其拆解为多个更简单的子问题，分别进行检索。
伪文档生成：例如广为人知的HyDE方法，它根据查询先生成一个“假设答案”，再将该假设答案的嵌入向量用于库中相似文档的检索。
不同检索方法的结果
上图的结果很有说服力：有监督方法的表现明显优于无监督方法。最终得分冠军是结合了HyDE与混合搜索的LLM-Embedder。因此，将HyDE + 混合检索作为默认检索方案是稳妥的选择。所谓混合检索，即把稀疏检索（如BM25）与密集检索（基于向量）相结合，既能保证效果，又能将延迟控制在较低水平。
重新排序
第一轮检索出的文档排序可能并不完美。此时需要“重新排序”模块上场，将最相关的信息精准地排到最前面。通常有两种主流方法：
DLM 重新排序：利用深度语言模型（DLM）对文档与查询的相关性进行“真”或“假”的二分类判断。推理时，按模型预测为“真”的概率进行排序。
TILDE 重新排序：该方法更巧妙，通过预测模型词表中每个词的概率，独立计算每个查询词出现的可能性。它能预计算文档得分，推理速度非常快。TILDEv2版本进一步优化，仅对文档中实际存在的词建立索引，进一步提升效率。
综合来看，monoT5 在性能与效率之间取得了最佳平衡，是首选的通用方案。若追求极致效果，RankLLaMA 值得尝试。而仅在固定数据集上快速实验时，TILDEv2 则是最合适的选择。
重新打包
文档的顺序也会影响LLM的最终表现。为解决“中间位置信息易被忽略”这一现象（即著名的“迷失在中间”问题），可在重新排序后增加一个“重新打包”模块。这里有三种不同策略：
前向方法：按照重新排序后的相关性得分，从高到低排列。
反向方法：反过来，从低到高排列。
侧向方法：该思路源于“迷失在中间”论文的发现——模型对输入内容的开头和结尾部分注意力最强。因此，将最相关信息放置在这些位置效果更佳。
这些打包方法的具体表现将由后续的LLM模块体现，我们将在下一节的综合评估中看到它们的实际效果。
总结
检索回来的文档中往往含有不少冗余信息。这些杂质不仅会干扰LLM生成准确回复，还会使输入提示词变长，拖慢推理速度。因此，对检索到的文档进行有效的“总结”或“压缩”，成为RAG流程中至关重要的一环。
实现总结的方式可分为两类：
- 提取式压缩器：将文本拆分为句子，对每个句子打分排序，选出最重要的句子。
- 生成式压缩器：更为高级，它综合多篇文档的信息，重新组织语言，生成连贯的摘要。
两种方式均可选择基于查询或不基于查询。我们重点评估了三种方法：
- Recomp：同时集成了提取式与生成式压缩器，功能全面。
- LongLLMLingua：在LLMLingua基础上改进，能更聚焦于与查询相关的关键信息。
- Selective Context：通过识别并删除输入上下文中的冗余信息，提高LLM效率。
三种方法的对比如下：
从图中可见，Recomp 表现最为出色，是首选的推荐方案。LongLLMLingua虽然在榜单上表现不佳，但它有一个可贵优点：未在这些测试数据集上训练过，展现出更强泛化能力。因此，当遇到新的、未见过的领域时，将LongLLMLingua作为替代方案是很有价值的。
结论
梳理完这一切，有几个关键点值得再次强调：
系统组件的重要性：RAG系统的每一个环节，从查询分类到最终生成，都不可或缺。任何一个环节的短板都可能成为整个系统的瓶颈。这提醒我们，在设计复杂系统时，对每个组件性能的优化都至关重要。
模块化设计的重要性：独立优化和测试每个组件，是模块化设计带来的最大红利。它允许你无需影响其他模块，即可轻松对某一环节进行技术升级，或在不同的应用中复用该模块。
系统的实验方法：最后，整个研究建立在公认的数据集和详尽的测试之上，使得结论具有很强的说服力和可推广性。这种系统的实验设计思路本身便值得借鉴。