检索增强生成（RAG）策略研究报告

本文整理了一份全面深入的RAG策略研究报告，涵盖其演进历程、核心理念、常见技术方案、各类策略对比（包括表格）、应用场景、存在的瓶颈与挑战、以及实际选择策略的建议。重点聚焦通用问答系统以及多模态大模型实时互动方向下的RAG实现，同时也将涉及企业知识库和编程助手这类RAG的应用场景。

---

检索增强生成（RAG）策略研究报告

大型语言模型（LLM）在知识获取方面存在先天局限：其参数中存储的知识是静态的，无法涵盖所有最新信息，而且在缺乏知识时容易产生虚构的“幻觉”内容 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。检索增强生成（Retrieval-Augmented Generation, RAG）应运而生，通过在生成过程中引入外部检索组件，为LLM提供实时的知识支撑，从而提升模型回答的准确性和时效性 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。RAG方法近年来受到广泛关注，特别是在知识密集型问答和对话系统中，它无需重新训练模型即可让LLM获取最新领域知识 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。本文将围绕RAG的发展演进、技术动机、使用方法、主要策略对比、多模态扩展、应用场景、面临挑战、策略选择指南以及未来趋势等方面展开全面阐述。

1. RAG的演进过程与关键发展阶段

(Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )图1：RAG研究的发展历程概览（根据2023年调研报告绘制），展示了RAG在预训练阶段（绿色）、微调阶段（橙色）和推理阶段（蓝色）的主要技术分支和里程碑 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。底部年份显示了从2020年至2024年，不同阶段出现的代表性方法。

早期阶段（2017-2019）：最初的检索增强方法多用于开放域问答等任务，一般采用BM25等传统稀疏检索获取文本资料，再交由阅读理解模型生成答案。例如Facebook的DrQA系统就使用Wikipedia检索结合机器阅读理解来回答问题。这一阶段的RAG雏形以 “检索器+生成器” 的松散管道为主，检索部分独立于生成模型。虽然BM25简单高效，但在语义匹配上存在局限，常会检索到与查询词表面匹配但语义不相关的段落，导致最终答案不准确。这一阶段的主要进展在于认识到将外部知识库接入生成模型的巨大潜力，但检索质量和生成结合方式都有待改进。

发展阶段（2019-2020）：随着深度学习的进步，研究者开始引入稠密向量检索（Dense Retriever）替代BM25。Facebook提出了Dense Passage Retrieval (DPR)，通过双塔BERT编码器学习查询和文档的向量表示，实现了比BM25更高的召回率。谷歌的REALM模型进一步将检索融入预训练，使语言模型能够在生成时动态查找相关文本。同年，Lewis等人提出了正式命名的RAG模型，将一个可学习的检索器与生成器端到端结合，在开放域问答等知识密集任务上取得了当时的最佳效果 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。此外，Izacard等人提出的Fusion-in-Decoder (FiD)模型探索了“早期融合”的思路：将多个检索到的文档直接拼接输入生成模型的解码器，以让模型在更大上下文中生成答案。这一时期的关键里程碑包括：将检索从非参数的外部工具转变为可训练模块，并探索了多文档融合等不同的信息整合策略，使RAG真正成为一个统一框架而非简单流水线。

成熟阶段（2021-2022）：在这个阶段，RAG方法在更复杂的场景中取得进展。一方面，多跳检索（multi-hop retrieval）受到关注，即回答复杂问题往往需要分步检索多个相关证据。针对HotpotQA等需要多跳推理的数据集，出现了检索-推理交替的流程，例如先检索中间实体信息再基于新线索检索下一步答案。与此同时，重排序（reranking）技术被引入RAG流程：通过训练交叉注意力模型对初始检索结果重新排序，提升检索文本与查询的相关度，从而为生成提供更精炼的上下文。 () ()例如，使用BERT跨编码器对候选段落打分，将最相关的内容放在提示的开头 ()。这一阶段还探索了大模型+检索的新形式：DeepMind的RETRO（2022）使用一个冻结的GPT样式生成模型，在生成每段文本时检索相似片段进行参照，实现了在1.7B参数模型上逼近更大模型性能的效果；Meta的Atlas模型则将T5生成模型与检索紧密结合，通过在微调过程中训练检索器与生成器协同工作，把开放域问答性能推向新的高度。总的来说，这一阶段的RAG研究体现了检索与生成深度融合的趋势，不仅检索模块本身更智能（如语义检索、重排序），而且检索–生成流程出现迭代、多步等更复杂的流程化RAG雏形。

新阶段（2023-至今）：进入LLM和多模态时代，RAG策略进一步丰富并扩展应用边界 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。一方面，RAG被广泛应用于对话系统（如Bing Chat、ChatGPT插件等）以提供实时知识，此类系统需要考虑对话历史和上下文的检索整合，即多轮对话RAG。另一方面，研究者提出了许多增强型检索策略：例如HyDE（Hypothetical Document Embedding）方法先让LLM生成一个假想答案文档，再用该文档去向量检索，从而提高召回的语义相关性 ()；RAG-Fusion策略则通过多重查询扩展来丰富检索覆盖面，即从用户问题生成多样化的查询并行检索，再融合结果，从而发现隐含线索 ()。还有一些工作致力于让检索流程更加自适应：Microsoft提出的Self-RAG可以根据查询判断是否需要检索，避免不必要的开销 ()；FLARE等方法探索了由LLM自我反馈来引导下一步检索的机制，实现检索-阅读-检索-生成的动态循环 () ()。在多模态方向（详见第5节），研究者也开始将RAG用于图像和文本混合的任务。总体而言，RAG发展到现在呈现出三个明显趋势： (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )一是从静态检索走向交互式、多步检索，以应对更复杂的问题；二是从单一模态扩展到多模态；三是从独立模块走向端到端优化和智能调度（如让LLM参与检索决策）。这些演进为RAG开辟了更广阔的应用空间，也形成了丰富多样的RAG策略流派，下文将对比介绍其代表性策略。

2. 为什么使用RAG：背景与优势

纯粹依赖生成模型（LLM）往往面临知识时效性和准确性难题。LLM的训练语料具有时效限制（如ChatGPT的知识截至2022年初）且覆盖面有限，当被问及超出其训练范围的问题时，模型不是拒答就是编造似是而非的回答 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。RAG策略正是为了解决这些问题而提出：通过在推理时引入信息检索，将模型“不知道”的内容及时查找到并提供给它。 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)具体来说，RAG在LLM与用户查询之间插入一个检索器，从外部知识库中提取最新的、相关的信息，并将其与提示一起喂给LLM，从而将LLM的输出锚定在检索到的真实知识上 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。这样一来，即使模型的训练数据过时，它也能通过检索获得最新事实，极大缓解了知识时效性的问题。同时，检索到的精确背景还能抑制模型的幻觉倾向，防止其在知识空白处胡乱猜测 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。

相比于通过持续扩展训练数据或微调模型来更新知识，RAG具有明显实用优势。首先，RAG无需重新训练即可赋予模型新知识，只要更新底层知识库即可。这意味着在企业场景下，可以让模型接入最新的内部文档或数据库回答问题，而不必频繁训练新模型 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。其次，RAG提供了可解释性和可控性：模型的答案源于检索到的文档，用户可以查看这些依据，提高了结果的可信度。在需要精准事实的应用中（如医疗、法律），这种基于检索证据的回答方式比纯生成更可靠。再次，RAG使LLM能够胜任领域专项任务：对于金融、科研等专业领域的问题，只需接入相应领域的文献资料库，LLM就能借助检索获得专业知识，从而给出有依据的解答，而不需要针对每个领域单独训练模型 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。总之，通过在LLM与用户提问之间增加一个检索环节，RAG将LLM原本封闭的参数记忆拓展为开放的外部知识 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。检索证据的加入显著提升了模型回答的准确性、相关性和可控性，从而减少幻觉现象，尤其适用于知识动态演变的场景 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。

3. 如何使用RAG：典型Pipeline介绍

RAG系统通常由索引、检索、后处理、提示构造、生成等模块串联组成，一个典型的工作流程如下 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )：

• 知识索引构建：首先，将待供模型查询的知识库进行处理。一种常见做法是将长文档拆分为较小的段落或文本块（chunk），以提升检索粒度 ()。随后为每个文本块生成向量表示（例如使用预训练模型编码）并存入向量索引库，或对文本建立倒排索引用于关键词检索。如果涉及多模态数据，还需要对图像等进行特征索引（详见第5节）。索引阶段的优化对RAG效果至关重要，例如确定合适的切片粒度、清洗冗余信息、为文档添加元数据（标题、标签）以辅助检索等 ()。良好的索引使后续检索更准确高效。

• 查询检索：当用户提出问题后，RAG系统首先将查询嵌入向量空间，然后在索引库中寻找与之相似的文本块，取Top K个作为候选 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。如果使用BM25等稀疏检索，则直接用查询词匹配文档倒排索引获取候选。现代RAG多采用Dense向量检索，能够基于语义相似度找到隐含相关的信息。例如，当询问“地球大气的主要成分是什么？”时，向量检索能找出包含“大气组成”的段落，即便其中没有精确匹配“主要成分”字样。为了提高召回率，常用策略包括：结合多种检索方法（如稀疏+稠密的混合检索 ()）、进行查询扩展或改写（使查询更适配索引内容）、甚至采用LLM先生成潜在相关查询再检索等。在多轮对话中，检索查询可能还需要结合对话上下文进行改写，以准确反映当前提问。

• 文档后处理：初步检索得到的候选片段可能包含噪音或冗余信息，需要经过后处理提升其对生成的利用价值。一种做法是对候选结果进行重排序，挑选出最相关的几个片段置于前列或过滤掉无关片段 ()。这通常借助一个预训练的交叉编码器来对查询-文档对打分，从而实现比检索器（通常是双塔模型）更精细的相关性判断。另外，可采用内容筛选与压缩技术来减小提示长度：例如只保留候选片段中与问题相关的句子，或用摘要模型压缩长段落 ()。目的在于突出关键信息、减少噪音干扰，因为将过多无关内容送入LLM不仅浪费token，还可能冲淡真正重要的证据。经过这一流程后，我们获得了若干条与查询高度相关且精炼的文本内容。

• Prompt拼接与输入构造：接下来，将处理后的检索信息与原始提问整合，构造成提示（Prompt）供生成模型使用。典型方式是将检索到的文本作为附加上下文，例如：“根据以下资料回答问题：...[检索文本]... 问：...[用户问题]...”这样的格式。对于对话系统，也可在Prompt中包含一定的对话历史，以提供上下文连贯性。需要注意Prompt的设计应避免信息泄露模型之前的知识，使模型尽量基于提供的资料作答。例如，可以明确指示模型：“只参考以上文本回答”。在多文档场景下，有两种主要的拼接策略：早期融合（early fusion）即将所有选中的文档片段串联成一个长上下文一次性提供给LLM；分批融合则是分别与问题组合成多个提示，让LLM针对每个文档单独生成回答，再在输出层面综合（属于“后期融合”范畴，详见第4节）。绝大多数实际应用选择前者，即简明地将所有检索结果附加到一个Prompt中，以便直接调用现有的LLM。

• 生成及后续处理：最后，将构造的提示输入生成模型（如GPT-4、Llama 2等）得到答案。 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )生成模型会将提示中的检索文本与问题一同作为上下文，因而它的输出应“引用”检索内容来回答问题。当模型生成完初步答案后，还可能进行一些后处理。例如，在需要引用来源的场景下，可以对答案中的陈述匹配检索文本以附加引用标注；又或者在多轮对话中，将本轮检索结果缓存以备下文可能的追问。这一步也可以评估答案的可信度：若模型输出与检索证据不一致，可考虑用反馈回路要求模型纠正。整个Pipeline至此完成。

需要强调的是，上述流程有时并非线性一次性完成。例如在复杂问答中，可能出现“检索-阅读-再检索”的循环：模型先根据部分信息生成新的查询再检索补充更多证据，直至能充分回答问题（这属于后述的多跳策略）。但无论流程如何演变，其核心思想都是在生成前或生成过程中引入检索，以外部知识增强LLM (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。实际应用中，这套Pipeline可以结合各种现有工具和框架实现，例如LangChain、Haystack、LlamaIndex等均提供了便捷的RAG组件来构建上述流水线 () (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。

4. 主流RAG策略对比（早期融合、后期融合、多阶段等）

RAG框架下衍生出多种策略流派，其差异主要在于检索信息与生成的集成方式以及检索流程的复杂程度。我们按策略类别将主要方法进行对比，如下表所示：

策略类型	方法思路	优点	缺点	适用场景	系统复杂度	对实时性的影响
早期融合（Early Fusion）	将多个检索到的文档在输入阶段融合，一次性拼接进LLM的上下文来生成答案 ([Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation	by Mexasol	Medium](https://medium.com/@mexasol/exploring-rag-fusion-a-new-approach-to-retrieval-augmented-generation-and-implementation-0bdf3d978752#:~:text=The%20core%20difference%20from%20RAG,context%20at%20the%20generation%20stage))。典型如FiD模型直接将所有证据串联供模型注意。	实现简单、与现有LLM兼容性好；模型可同时考虑多条证据给出连贯答案 ([Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation	by Mexasol	Medium](https://medium.com/@mexasol/exploring-rag-fusion-a-new-approach-to-retrieval-augmented-generation-and-implementation-0bdf3d978752#:~:text=The%20core%20difference%20from%20RAG,context%20at%20the%20generation%20stage))。	上下文长度受限，检索文档过多时难以全部放入；不相关信息混入prompt可能干扰模型；模型可能偏向复述提供内容。	单轮问答，大多数检索结果较短且相关的情况；需要快速构建原型的应用。	低（利用标准LLM接口即可）	较低（一次检索一次生成完成回答）
后期融合（Late Fusion）	分别处理每条检索结果，再在输出阶段或概率空间融合。例如原始RAG模型对每个文档分别生成答案分布再归并 ([Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation	by Mexasol	Medium](https://medium.com/@mexasol/exploring-rag-fusion-a-new-approach-to-retrieval-augmented-generation-and-implementation-0bdf3d978752#:~:text=The%20core%20difference%20from%20RAG,context%20at%20the%20generation%20stage))；或让模型逐个阅读文档回答再综合。	可处理更多证据，每条证据单独评估降低相互干扰；在输出层融合可利用评分机制挑选最可信答案。	实现复杂，需要定制生成过程或结果合并算法；多次调用生成模型（对每文档一次）开销大 ([Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation	by Mexasol	Medium](https://medium.com/@mexasol/exploring-rag-fusion-a-new-approach-to-retrieval-augmented-generation-and-implementation-0bdf3d978752#:~:text=The%20core%20difference%20from%20RAG,context%20at%20the%20generation%20stage))；若答案需要综合多条证据，后期融合可能错失跨文档推理。	需要严格事实核验的场景，可分别基于不同来源作答再比对；以及检索条目非常多、无法一次塞入prompt的情况。	较高（需定制模型推理或增加判决模块）	较高（多轮生成耗时，难以并行则延迟增加）
多阶段检索（Multi-stage Retrieval）	将检索划分为多步流程。包括：1）级联检索：先用高召回但精度低的方法（如BM25）初筛，再用精细方法（如向量检索或交叉重排）精筛，以提高检索质量；2）多跳检索：针对复杂问询，采用“检索-生成新查询-再检索”迭代获取跨越多个证据链的答案 ()。	检索精度和覆盖面兼顾：级联策略提高相关性，避免遗漏答案；多跳策略可应对需要多重关联推理的问题 ()。在复杂问答中表现出色，能逐步挖掘隐含信息。	流程复杂，开发和调试难度大；多阶段累积延迟更高，尤其多跳检索每增加一步都增加等待时间；如果某一步检索出错可能导致后续环节偏离正确方向（误差传播）。	高复杂推理问答（如科研问答、多实体关系问答）；需要高准确率而愿意牺牲一定实时性的系统；多轮对话检索（根据对话进程多次检索）。	很高（涉及多次检索与决策循环，近似Agent系统）	明显降低（多级流水线，每级耗时累积）

表中比较了早期融合、后期融合和多阶段检索三类策略的差异。其中早期融合注重简化流程，将证据一次性交给模型，适合大多数常规场景，但受制于上下文长度；后期融合更复杂，通过在生成端合并结果提高了灵活性，在高精场景下有用；多阶段策略则通过增加检索/推理轮次来处理复杂信息，换取更高答案质量但引入更多延迟和复杂性。需要指出，实际系统中这些策略并非孤立存在，常常是组合使用。例如混合检索就是一种两阶段级联：先用BM25获取初步结果，再用Dense向量检索扩充/重排 ()；又比如有的对话系统在多数提问采用早期融合以保证速度，但一旦检测到复杂追问则切换为多跳检索以确保准确性。总的来说，不同RAG策略各有权衡，应根据任务需求选择合适的融合方式，下文第8节将对此给出指导。

5. 多模态大模型中的RAG应用

随着多模态大模型的发展，将RAG扩展到图像等非文本领域成为新的研究方向。例如，一个多模态RAG系统可以在回答用户文本询问时，不仅检索文本资料，还从图像库中检索相关图片进行展示；或者在用户给出一张图片时，检索与该图片相关的说明文字、知识标签等，辅助回答问题。多模态RAG需要解决跨模态检索和拼接的问题，即如何在图文之间进行相关性匹配，并将不同模态的信息结合提供给模型。 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)

(1) 多模态检索索引：在多模态RAG中，知识库可能包含文本和图像两类数据。最简单的做法是为不同模态建立各自的索引库：例如文本库用句向量索引，图片库用图像特征索引。当收到查询时，分别在两个索引中检索出Top N文本段落和Top N图片，然后再进行融合。这需要应对跨模态排序的问题，可以训练一个多模态相关性模型对所得的文本和图像集合进行重新排序 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。另一种更直接的方法是尝试将不同模态的数据嵌入到同一向量空间。例如OpenAI的CLIP模型可以将图像和文本投影到统一的语义向量空间，用它生成的图像向量和文本向量可以直接进行近邻检索比对 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。这样，一个文本查询可以通过向量相似度直接检索出相关的图片（反之亦然），复用与文本RAG类似的基础设施 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。这种方案的优点是实现统一检索，架构简洁；缺点是在统一空间捕捉细粒度跨模态对应上有难度，尤其是涉及图像中的文字或复杂场景时，CLIP等可能无法涵盖所有细节 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。第三种思路则是模态转换：将一方模态的信息先转换为主要模态。例如如果应用以文本问答为主，但包含图片，那么可在预处理阶段为每张图片生成描述性文本或提取OCR文字，将图像信息“落地”为文本存储 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。检索时就仍然以文本查询匹配这些描述，从而间接找出相关图片，并在最终生成时再将对应图片调取展示 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。这种方法避免了训练复杂的跨模态模型，但图像转文本的过程可能丢失细节，且需要额外预处理成本 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。

(2) 多模态Prompt拼接：一旦检索得到了相关的文本和图像，下一步是将它们组合提供给多模态模型生成答案。如果使用的生成模型是具备视觉输入能力的多模态LLM（如GPT-4V, BLIP-2等），则可以在Prompt中直接包含图像（或图像URL）加上文字说明，一并喂给模型。例如：“用户问题：...。相关资料：[图像]（这是一张...的图片）; 文本说明: ...”。模型会同时参考图像和文本来回答 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。如果生成模型本身是纯文本的，那么可以考虑先由辅助模块对检索到的图片生成描述，再与文本资料一起作为上下文提供给文本LLM。这种做法本质上将图像信息转成文本描述融入Prompt，属于上述模态转换策略的一环。需要注意多模态提示可能触发模型与图像相关的推理能力，例如让模型根据检索图片理解场景，再结合文本给出更丰富的答案。在实时交互场景中，多模态RAG的响应时间往往比单文本稍长，因为检索图像和加载模型处理都会增加开销。但通过提前缓存常用图片向量、优化并行检索等方式，可以将延迟控制在可接受范围。

(3) 多模态应用实例：多模态RAG的一个典型场景是带图文资料的问答系统。设想一个博物馆导览机器人，用户拍摄一张展品照片并提问细节。系统可先根据图像检索内部数据库中相似的展品图片或编号，获取其文字介绍，再将介绍和用户问题一并输入视觉语言模型回答。这实现了图像和文本的双检索与融合，提供准确且有依据的讲解。又比如在电商客服中，用户发送产品截图询问参数，RAG系统可以检索出产品手册中的对应页面（图像）和文字说明，让多模态模型阅读后给出答案。再有，面向社交媒体的智能助手可以结合最新截图（含文本内容）和相关新闻文章一起检索，帮助用户快速获取背景信息进行内容创作。 (GPT-4V with Context: Using Retrieval Augmented Generation with Multimodal Models | DataStax)实际应用表明，将RAG拓展到多模态后，能够显著提升LLM处理视觉相关任务的准确性，减少了仅靠语言描述图片时产生的不确定性 (GPT-4V with Context: Using Retrieval Augmented Generation with Multimodal Models | DataStax) (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)。当然，多模态RAG仍面临不少挑战，例如如何在大规模图像库中高效检索、如何评价多模态答案的准确性等，但随着GPT-4V等模型的出现和相关框架的发展，多模态RAG在实时交互场景中的表现正不断提高，并成为人机多模态互动的重要组成部分。

6. RAG典型使用场景

RAG策略由于其引入外部知识的特性，在诸多应用中展现出优势。下面结合几个重点场景说明RAG的作用：

• 通用问答系统：这是RAG最直接的用武之地，即面向开放领域的知识问答。例如面向互联网的聊天机器人（如New Bing）利用RAG从网页检索答案来源，结合LLM生成简洁回答并附上引用链接，实现了知识全面又有依据的对话问答体验。再如各类百科问答、社区问答辅助工具，RAG让模型可以实时获取最新的公开知识（新闻、百科更新等），回答准确率远高于仅靠训练知识的模型 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow) (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。没有RAG，LLM往往无法回答超出训练集范围的问题，或因不知道而张冠李戴。有了RAG，用户几乎可以询问任何有公开资料的问题，系统都会去检索可靠信息来回答。由此，RAG被视为让LLM保持时效性和扩展知识面的关键，使通用问答真正实用化。

• 企业知识库问答：在企业内部，RAG同样大显身手。许多公司希望构建自己的知识库聊天助手，能够回答有关内部政策、产品文档、客户案例等问题。由于这些内部资料往往保密且不断更新，不可能用来训练开源模型，也无法指望通用模型记住它们。因此，将公司文档建立索引，让LLM通过RAG访问，就成为自然的解决方案。例如某企业的客服机器人接入了产品手册的向量索引，当客户提问技术细节时，机器人检索手册相关段落并据此回答，保证答复专业且符合公司资料。 (Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation | by Mexasol | Medium)又如团队内部的知识问答系统，员工提出问题时，RAG从知识库和历史问答中找出类似问题答案供生成模型参考，从而给出准确解答。相比传统的关键词搜索阅读文档，RAG助手能直接给出凝练答案，大大提高了效率。在这些场景中，RAG的优势还包括易于更新（新文档即时索引即可生效），以及权限控制（检索库可以按需配置哪些内容可供模型访问，防止泄密）。可以说，RAG是企业实现“大模型落地”的重要途径之一，许多面向企业的LLM解决方案（如微软Azure OpenAI的知识连接器等）都内置了RAG功能。

• 多模态交互助手：结合第5节所述，多模态RAG解锁了人机交互的新方式。例如智能家居助理可以让用户拍摄电器的控制面板，系统通过图像识别检索对应的说明书页码和内容，然后指导用户操作。这比起让用户手动翻阅说明书要高效友好得多。再如移动端的生活问答应用，用户拍照提问“这家餐厅评价如何？”，系统将图片中的餐厅名称识别出来后检索大众点评等平台的文字评论数据，最后由LLM生成简短总结回答用户。这种场景下，RAG起到了桥接视觉和语言信息的作用，让助理能够“看图说话”，极大拓展了应用范围。 (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog) (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)此外，在AR眼镜等前沿设备中，嵌入RAG的多模态助手可以做到实时识别视野中的物体并查询相关信息进行播报，创造出“所见即所得”的增强智能体验。

• 编程助手：近年来流行的AI编程助手（如GitHub Copilot等）也开始融合RAG以提供更强大的辅助功能。编程领域的信息高度结构化且知识更新快，仅凭训练模型往往不足以应对各种框架和库的细节问题。通过RAG，编程助手可以即时检索文档和示例代码来增强回答。例如当开发者询问“如何使用Python的requests库设置代理？”，助手可以检索requests官方文档中关于代理设置的段落，结合LLM给出代码示例和解释。 ()研究表明，这种检索增强可以显著提高代码生成的准确度，使AI编程对复杂或冷门问题的解答正确率提升。例如斯坦福的项目通过检索StackOverflow问答来辅助代码生成，使得生成代码通过测试用例的比例相比不检索时提高了约10% ()。除了文档QA，RAG还能用于项目级别的上下文提供：例如让助手检索当前项目代码库中的相关文件，以确保生成的代码与现有代码接口兼容；或在代码评审场景下检索过去的提交历史和讨论，让代码评价更有依据。未来的个性化编程助手甚至可以利用RAG学习个人过往的代码风格和错误模式，提供定制化建议 (Software Development with Augmented Retrieval · GitHub)。总之，RAG为编程助手引入了外部知识源和上下文记忆，弥补了通用大模型在专业领域知识上的不足，使其真正成为开发者高效可靠的搭档。

综上所述，无论是开放网络问答、企业内部助手、多模态交互，还是专业领域助手，RAG都已在实践中证明了其价值。通过检索-生成融合，许多过去困扰语言模型的知识盲区得到解决，各类AI系统的实用性和可靠性有了长足进步。

7. RAG面临的挑战与瓶颈

尽管RAG为增强LLM能力提供了有效手段，但在实际应用和研究中也暴露出一系列挑战和瓶颈，需要持续优化：

• 检索噪声与相关性：检索模块并非完美，有时会返回与查询关系不大的内容（噪声）。当这些无关或错误的片段被送入LLM，可能导致模型产生误导性的回答或偏离主题。因此如何提高检索精度、过滤掉噪音是RAG的首要挑战之一。一方面，可以改进检索模型本身（如更好的向量表征，融合上下文的检索）；另一方面，可以在检索后通过更智能的结果筛选来确保喂给LLM的是高度相关且有用的信息 ()。例如引入对抗检索思路，检测并剔除可能引发模型出错的片段。此外，在多轮对话中还要处理历史遗留的检索结果，如果上下文切换，需要摒弃过时信息避免干扰。这些都对检索的鲁棒性提出了高要求 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。

• 上下文窗口限制：LLM的输入长度（上下文窗口）有限，即使一些新模型扩展到数万token，但面对超大规模的知识库或长文档时，仍无法将所有相关内容一次性放入Prompt。 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )这就需要RAG在召回充分和长度受限之间取得平衡。目前的解决方案包括：更智能地选取最关键的内容（如通过摘要/压缩来缩短文本 ()），或者动态分段、多轮交互获取内容。然而，上下文限制始终意味着RAG提供给LLM的信息是局部的，如果关键点不巧没被检索到，模型就可能回答不全或出错。未来超长上下文模型出现后，此瓶颈或可缓解，但短期内如何在有限窗口内呈现最有用信息仍是RAG系统成败的关键。

• 延迟与实时性：相比纯LLM直接应答，RAG增加了检索和数据处理开销，这会引入额外延迟。尤其在多跳检索或多模态场景，可能需要多个往返才能凑齐答案证据，响应时间会显著变长。如果用户期望即时响应（如实时对话、交互式应用），过高的延迟会损害体验。因此如何加速RAG管道也很重要。例如预先对常见问答进行缓存，优化向量检索的速度，利用并行处理同时获取多个证据等，都可以减少等待时间。此外还有策略层面的改进：如自适应检索（对于简单问题直接回答，复杂问题才启用多跳RAG），以避免每次都走完整的慢流程 ()。总之，性能优化在工程上不可或缺，既要让RAG充分发挥作用，又要尽量保持交互的流畅。

• 非结构化知识表达瓶颈：RAG主要处理的是非结构化文本（以及扩展的图像等），对于那些需要结构化推理或计算的知识，可能存在表达瓶颈。比如一个涉及复杂表格的数据问答，检索可以找到相关表格所在文本，但LLM未必能从中准确提炼出答案，因为表格信息的呈现对LLM来说不直观。同理，代码片段、数学公式等结构化知识在转换成纯文本时可能丢失信息或不易被模型正确理解。这时RAG需要结合工具使用或结构化解析才能解决瓶颈，例如检索到数据表后调用解析函数让LLM读出关键值，再据此回答。如果仅依赖RAG本身，LLM对这类信息的利用效率不高。这也提示我们，RAG有时需要与结构化知识库、计算模块配合，才能弥补非结构化表达的不足。

• 事实一致性与引用：引入检索并不保证LLM输出就万无一失。模型可能误用检索内容，例如张冠李戴地将一个段落的事实嫁接到另一个实体上，造成新的错误。此外，如果检索到的多条证据彼此矛盾，模型可能混淆或偏向错误的信息。这就引出事实一致性的问题：如何让LLM严格遵循检索证据，而不擅自发挥或篡改？当前的做法包括在Prompt中反复强调“基于以上内容作答，不要编造”，以及对输出进行事实核对（fact-check）。有研究让LLM在回答后自己检索核实关键事实，比对是否一致来自我纠正。这种检索增强的自我校验有望提高答案可靠性。另外，在提供答案时如何引注明确的来源也是挑战之一。理想情况下，RAG系统应该像维基百科那样，给出每句话出处。但LLM生成内容往往无法逐句对齐来源，这需要借助算法将输出片段与输入证据匹配，再附上引用 (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)。不当的引用甚至可能暴露模型其实没用相关内容（比如模型胡乱硬塞来源）。因此保持答案与证据的严格一致，并正确引用来源，是RAG在追求可信赖输出过程中必须克服的难题。

• 隐私与安全：RAG系统如果应用于敏感领域，检索的内容可能涉及隐私或受控信息。这带来两个方面的问题：其一，如何确保LLM不会泄露不该给用户看的内部知识。例如对一般用户的问题不应检索出内部机密文档作为依据。如果索引库中混有不同敏感级别的内容，必须有权限控制机制。其二，检索来源本身可能包含不可靠甚至有害的信息，如不良网站或错误数据。如果模型基于这些信息回答，可能输出不当内容或谬误。因此实际应用需谨慎选择和清理知识库，必要时对检索结果进行可信度判别，或限制模型引用外部内容的方式，以确保整体安全。这些安全考量也是RAG在产品化时需要重点关注的。

概括来说，RAG为LLM插上了知识的“翅膀”，但要让这双翅膀稳健有力，还需在相关性、效率、可靠性等方面不断打磨。上述挑战正是当前RAG研究和实践的热点，许多改进工作（如更好的检索模型、更智能的管道调度、更严格的事实校验等）都围绕它们展开 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide ) (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )。

8. 策略选择指南：不同场景下的RAG决策

面对众多RAG策略和实现方案，如何根据具体场景和技术约束做出合理选择？下面从几个关键抉择维度进行指导：

（1）端到端集成 vs. 模块化组合：端到端方案是指训练一个联合模型同时优化检索器和生成器（典型如原始RAG模型，将BERT检索和BART生成一起训练）。模块化方案则是将检索与生成解耦，分别优化，推理时通过接口衔接。选择上，如果追求最高性能且有充足资源数据，端到端方案可能取得更好的协同效果，因为检索器可针对生成需求调整。然而在实际应用中，模块化方案更为常见和实用 ()。原因在于：①目前最强的LLM往往是闭源或难以微调的（如GPT-4），只能作为黑盒调用，无法与自建检索器端到端训练；②模块化使系统更灵活，可随需替换检索后端（例如文本改用知识图谱查询）或切换LLM，而无需重新训练整个模型 ()。因此，大多数场景下推荐采用模块化RAG，用现成的向量数据库+预训练LLM搭建pipeline。在数据规模不大且有能力训练自有模型时，可以尝试端到端优化，以获取一点性能增益。

（2）单轮问答 vs. 多轮对话：如果应用场景是独立的问题解答（每个问题相互独立，没有上下文），可以将每次提问都视作单轮RAG流程，这种情况下策略重点在提高每个问题的检索和回答质量。而在多轮对话场景下，需要考虑对话历史和上下文延续。这涉及两方面：其一，检索时是否需要将历史对话内容作为查询的一部分。如果当前问题是上下文相关的，则应将过去的相关对话串联形成更完整的查询以检索正确资料。其二，如何处理历史检索结果的记忆。例如上轮已经检索出一段内容并被讨论，这轮追问也许不需要重复检索，而可直接利用之前的结果。为此，有些系统实现了对话级的检索缓存和复用，或者采用RAG-flow这样的流程在对话中灵活调度检索模块 ()。简言之，单轮场景可以专注于一次性的检索+生成优化，而多轮场景则需要设计策略来结合对话状态。如果对话主题变化频繁，需确保模型不会错误地引用旧上下文；若对话深入探讨某一主题，则要保持连贯检索。在选择策略时，多轮对话更适合自适应的、多跳的检索方法，以便模型根据需要多次检索并逐步澄清答案。而单轮问答则多采用一次检索融合即可满足需求。

（3）Dense向量 vs. Sparse关键词 vs. 混合检索：选择何种检索技术取决于知识库特点和查询类型。Dense向量检索利用预训练模型的语义表示，擅长处理同义表达和语义模糊的匹配，一般在开放领域问答中效果更好，因为用户问题可能与文章表述有用词差异。 ()但纯向量检索也有短板：对于包含稀有实体名或专业术语的查询，未见过的词向量可能不准确，或者向量检索过于偏重语义近似反而忽略了关键词匹配。这时传统的Sparse检索（BM25）仍有价值，因为它严格依据关键词出现频率，可以保证召回包含那些冷门术语的文档 ()。因此，很多场景采用混合检索策略：同时进行BM25和向量检索，然后合并结果。例如向量检索主导语义相关性，BM25补充确保关键字命中，两者取并集供后续排序 ()。对于资源受限（无法部署向量服务）或文本非常短小（关键词已足以表达需求）的应用，也可只用BM25，这在早期很多FAQ系统中常见。但总体看，Dense检索在RAG中日益占主导，尤其有现成商用向量数据库可用的情况下，应优先考虑Dense或Dense+BM25混合，以兼顾智能和精确。还需注意的是，不同语言和数据类型对检索算法的选择也有关：如中文可能需要结合字词颗粒度的检索策略，多模态需要特殊的嵌入模型等。在策略选择上应根据数据分布和查询特点进行测试对比，选择最适合的一种或组合。

（4）一阶段 vs. 多阶段管道：正如第4节讨论的，检索和生成可以是一个简单直线流程，也可以拆分为多级。如果系统对响应速度要求高，尽量简化为一阶段：例如直接Dense检索Top3文档供LLM，减少中间环节。如果系统对准确率要求极高或问题复杂度高，可以引入多阶段处理以提高质量：如增加一个cross-attention重排序阶段，或对模型生成的初步回答再检索验证（这可视为生成后的第二阶段检索）。多阶段带来的增益是否值得延迟的代价，需要权衡。如果是在交互式场景，每增加100ms都可能影响体验，则应当控制阶段数；但如果是离线批处理的问答生成，牺牲一些时间换正确答案是值得的。因此，可根据实时性要求来决定管道深浅。另外，还可以设计可选的管道：平时走单阶段快速路径，当检测到回答不确定时再触发额外阶段进行补救。例如某些问答系统使用LLM对自己答案的信心评分，低于阈值则自动进行第二轮检索并完善答案。这种自适应机制兼顾了速度和效果，在需要时才进入多阶段流程。

（5）知识库规模与更新频率：如果知识库很大（数百万文档），检索难度增大，可能需要更强的向量索引和高并发支持，策略上倾向于分片检索和并行。比如对百科全书级别的数据，可能按主题分区索引，查询时先分类路由再检索，以减少搜索空间 () ()。反之，如果知识库较小，简单算法就能胜任，不必引入复杂方案。在知识更新频繁的场景，模块化RAG更有优势，因为可以动态插入新数据而无需重训模型。例如电商库存每天变动，向量索引支持实时更新，新商品信息即刻可被检索到。如果采用端到端训练的模型，更新知识就非常不便。还有一种折中是定期将检索得到的新知识用于微调LLM（所谓retrieval-free方法结合RAG），但这实质上又回到了离线更新模型的老路，对于需要时刻最新的系统仍不够灵活。因此，当知识库更新频繁时，应优先选择外部检索为主的方案，将LLM训练保持在较通用状态，把知识更新工作交给检索层完成 () ()。

概言之，RAG策略选择没有放之四海而皆准的答案，需要综合考虑场景需求（速度 vs. 准确）、技术条件（模型和数据）、开发成本等因素。经验法则是：能简单则不复杂，能模块则不耦合。在保证核心功能的前提下，选取尽可能简单可靠的方案，并预留日后改进的空间。例如先实现一个Dense检索+GPT回答的基础版本，如果发现准确率不够再逐步加入重排序或多跳。如果一开始就设计过于繁复，反而增加了出错点和开发难度。通过针对不同应用不断实践，上述指南可以帮助开发者做出合理的策略权衡，搭建出符合需求的RAG系统。

9. 未来趋势展望

展望未来，RAG作为连接知识与大模型的桥梁，将在以下几个方向上继续演进：

• Retrieval-Free方法的融合：随着LLM参数规模的增长和训练技术的进步，一些研究探讨让模型直接拥有更多知识，而减少实时检索的需求。例如超大模型可以在几百页文档的上下文中直接回答问题，或者通过知识蒸馏将检索库中的信息整合进模型权重。这类检索自由的方法某种程度上和RAG是此长彼消的关系。然而，两者并非完全对立：未来很可能出现检索增强+长时记忆的混合架构。一方面模型拥有超长上下文或大量内置知识，另一方面在遇到超出其记忆范围的问题时仍可以调用检索。 () ()比如，一个具备100k字符上下文窗口的模型可以在Prompt中直接塞入一本小型手册作答，无需检索；但如果问的是手册没有的新内容，则模型识别出自己的知识空隙，自动触发检索补充相关资料。这种智能调配使系统既充分利用了模型自身“记忆”，又不放弃外部知识源。当LLM变得更加强大时，部分简单问答可能不再需要检索（提升速度），但RAG仍会是确保最新和特定知识获取的必要手段。未来我们或许会看到检索模块变得更加隐形，高级的LLM能自行决定什么时候需要外部信息，相应地调用检索API完成任务。

• 超长上下文模型 vs. RAG：近期出现了一些上下文长度达到10万甚至百万级的语言模型，它们可以在不拆段的情况下读完一本书。这引发了一个有趣的问题：如果模型能够直接读入整个知识库（或其很大一部分），那RAG是否还有必要？目前来看，长上下文并不能替代检索。原因有二：其一，即使模型能读那么多，逐字提供给它整个知识库依然不现实且效率低下——检索的作用在于筛选出相关部分，这在海量信息时不可或缺。其二，上下文再长也无法涵盖持续更新的动态信息，而RAG随取随用的机制更灵活。因此更可能的趋势是二者结合：利用长上下文模型容纳更多检索到的证据，减少因为窗口限制不得不裁剪信息的情况。例如传统模型也许一次只能放5段证据，但长上下文模型可以放50段，那么答案将更全面。不过依然需要先通过检索挑选这50段，而不是盲目把整库喂进去。所以长上下文技术提升后，RAG的检索颗粒度可能会变粗（一次返回更多内容而模型能吃下），但“检索”这一步并不会消失。相反，它还可能扩展到新的用法：比如检索可以返回一个超长的原始文档（几十页PDF），然后模型在长上下文中自行查找答案。总之，长上下文模型是对RAG的补充而非替代，未来我们将设计更高效的策略，让检索结果最大限度充利用模型的大上下文容量。

• Agent框架与RAG融合：近年来兴起的“大模型Agent”（如ReAct、AutoGPT等）让LLM学会调用工具并分步执行任务。其中最常用的工具正是网络搜索或数据库查询——本质上就是一种带决策的RAG。在Agent框架下，模型可以根据当前需求灵活决定何时检索、检索什么，然后将结果纳入后续推理。这比固定的一次性RAG流程更灵活智能。可以预见，未来RAG将更多地融入Agent架构，使模型具有自我检索、自我反馈的能力。例如一个问答Agent可能先思考“这个问题需要哪些信息”，生成几个子查询分别检索，然后综合结果解答（这与前述的多跳RAG不谋而合）。这种方式已经在一些研究中出现，如Demonstrate-Search-Predict等框架通过让LLM自己生成查询来获取证据 ()。Agent化的RAG有望提升复杂任务的成功率，因为模型不再受限于预定义的检索流程，而是可以根据上下文动态调整。然而，这也对模型的决策可靠性提出更高要求。如果Agent策略不当，可能陷入无效检索循环或遗漏关键步骤。因此，一个可能的趋势是结合Agent的灵活性与传统RAG的稳定性：在大方向上由Agent控制检索策略，但底层仍采用可靠的索引和融合方法，并对Agent的行为进行约束（如限制检索次数、防止不相关搜索）。随着工具使用接口（如OpenAI Functions）的成熟，我们预计RAG将成为LLM代理中标准的“查询工具”，赋能模型自主获取所需知识，解决更开放的问题。

• 检索模块的智能演化：未来的检索模块本身也会更加智能和多样化。一方面，向量检索模型将继续改进，尤其是在特定领域和多语种上的表现 () ()。我们可能看到专为医学、法律等领域训练的检索模型，大幅提升专业文献查询效果。另一方面，检索不再局限于文本匹配，可能融入推理能力。比如Graph Retriever可以基于知识图谱关系找到间接连接的实体；又或者引入小型语言模型来读懂文档后判断相关性，弥补简单向量相似度的不足。此外，Memory-Based RAG也是一大方向：让LLM把交互过程中产生的新信息存入一个长期记忆库，下次需要时通过检索调取。这样Agent能不断积累知识，自我提升。这种记忆检索实际上将RAG用于模型自身的对话历史管理和长期学习，被称为自我RAG ()。它有望缓解长对话遗忘问题，使模型具备持续进化能力。综上，未来的检索模块会更加“智慧”，既包括更强的检索模型，也包括多种新型的数据源（代码库、数据库、图谱等）的接入，甚至具备一定的推理和学习功能，与LLM形成更紧密的互动。

• 评估和可靠性工具：最后值得一提的是，随着RAG应用扩大，如何客观评估其效果将变得越来越重要。未来可能出现标准化的RAG评测基准，既考察回答准确率，也考察引用正确性、上下文利用率等。同时，开发针对RAG的调试工具，例如可视化检索过程、提示诊断等，帮助开发者理解系统行为并改进。 (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )在可靠性方面，或许会引入更多保护措施：比如结合用户反馈对检索结果进行二次筛选，或者通过元学习让模型知道何时该拒绝回答（当检索不到可信资料时）。这些都将帮助RAG系统变得更加健壮可信。

总而言之，RAG作为解决大模型知识局限的成功范式，短期内不会被取代。相反，它将与其它新兴思路相互融合，共同促进下一代智能系统的发展。从让模型学会何时检索、如何检索，到扩展到多模态、长记忆，RAG的概念在不断丰富。但万变不离其宗，其核心仍是“让AI学会利用外部知识”。可以预见，在未来相当长一段时间里，RAG将是构建高效、可信AI应用的关键技术之一，并在实践中迭代出更完善的形态。我们正站在RAG发展的新起点，迎接知识增强型智能体的蓬勃时代。 () (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )

10. 参考文献：

1. Lewis et al. 2020, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)

2. Shuohao Gao et al. 2023, Retrieval-Augmented Generation for Large Language Models: A Survey () ()

3. Stack Overflow Blog 2023, Retrieval augmented generation: Keeping LLMs relevant and current (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow) (Retrieval augmented generation: Keeping LLMs relevant and current - Stack Overflow)

4. Prompt Engineering Guide: RAG for LLMs (dair.ai, 2023) (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide ) (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )

5. NVIDIA Blog 2024, An Easy Introduction to Multimodal Retrieval-Augmented Generation (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog) (An Easy Introduction to Multimodal Retrieval-Augmented Generation | NVIDIA Technical Blog)

6. Stanford CS224N Project 2023, AI Can Look Up StackOverflow too: Retrieval-Augmented Code Generation ()

7. Mexasol 2023, Exploring RAG-Fusion: A New Approach to RAG (Exploring RAG-Fusion: A New Approach to Retrieval-Augmented Generation and Implementation | by Mexasol | Medium)

8. Datastax Blog 2023, GPT-4V with Context: Using RAG with Multimodal Models (GPT-4V with Context: Using Retrieval Augmented Generation with Multimodal Models | DataStax) (GPT-4V with Context: Using Retrieval Augmented Generation with Multimodal Models | DataStax)

9. OpenReview 2025 (under review), FusionMaestro: Early and Late Fusion in Multimodal Retrieval () ()

10. Annie Surla et al. 2024, Challenges & Future of RAG (Retrieval Augmented Generation (RAG) for LLMs | Prompt Engineering Guide )