Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview

Retrieval-Augmented Generation for Large Language Models: A Survey——(1)Overview

1. Introduction&Abstract

1. LLM面临的问题

• 幻觉(表现为不适合领域知识密集型任务)
• 知识过时(预训练)
• 推理过程不可知

2. RAG核心三要素

• 检索(Retrieval): 给定用户输入(query), 如何在数据库中检索需要的内容, 如果检索出来候选, 如何挑选候选检索, 选择怎样的检索方法(关键词/嵌入相似度)
• 生成(Generating): 大模型通过prompt生成推理(或者是训练/微调)
• 增强(Augmentation): 在大模型的哪个阶段(pre-training, fine-tuning, inference)增强大模型性能, 如何组合query和检索内容为prompt(或者是如何设计训练/微调)来增强大模型能力

3. RAG taxonomy

Naive RAG

Advanced RAG

Modular RAG

RAG技术在推理阶段, 预训练阶段, 微调阶段都可以增强

2. Overview: RAG的概念和范式(paradigm)

1. Naive RAG

(1) Indexing

人话: 建立索引

• 把各种来源各种格式(pdf, HTML, md)的文本转换成统一的文本格式
• 为了遵从LLM对上下文长度的限制, 把统一格式的文本切片成chunk
• 计算每个chunk的向量表示(用嵌入模型), 存入向量数据库

(2) Retrieval

人话: 检索数据库

• 用户输入query(可以认为是用户输入的prompt, 但是不是最终输入给LLM的prompt)
• 把query向量化, 通过向量相似度来索引数据库, 获取最相似的chunks
• 把获取到的chunks作为对用户query的补充, 组合成最终输入到大模型的prompt

(3) Generation

人话: 组成prompt输入到大模型让他生成

历史聊天记录也可以部分选取到新一轮的prompt中, 提升交互性

(4) 面临的挑战

• 检索阶段一般缺乏准确性, 会导致检索到无关的文本
• 生成阶段检索的上下文可能不能很好的支持生成的内容
• 增强阶段, 相似的信息可能在不同的文本源被重复检索, 会生成重复的回答
• 生成模型可能过于依赖增强的信息, 可能导致输出只是检索文本的复制品, 而没有增加新的见解

2. Advanceed RAG

简单来说就是在NaiveRAG基础上, 在检索前后(pre-retrieval+post-retrieval)都进行一些处理

• 主要集中在增强检索质量上
• 对索引也有增强, 不是简单的切片, 而是用滑动窗口/更细粒度的切片/增加元数据(比如文本的来源, 创建时间等附加信息)

(1) Pre-retrieval

目标是增强检索质量和优化索引(index)

方法:

• 减小粒度

• 优化索引结构(indexing structure)(如滑动窗口)

• 增加元数据(metadata)(如文本来源和创建时间)

• 对齐(alignment)优化(对齐query和数据库, 比如query可能更口语, 而数据库更正式), 所以训练一个适配器或者对比学习, 使得相似的查询/文档更加接近
  比如在 代码检索 场景中，优化查询，使其更贴近代码片段的表示方式

• 混合检索(mixed retrieval): 结合多种方法

  稀疏检索(Sparse Retriveal): 基于关键词匹配如BM25, TF-IDF

  稠密检索(Dense Retrieval): 使用嵌入向量进行相似度计算

(2) Post-retrieval

简单的把检索出来的相关文本喂给LLM可能导致大模型无法集中在关键信息而过度注意检索的文本而忘记query, 问题是如何把检索出来的文本和query有效的组合

核心目标:

​ 通过选择关键信息/强调关键部分/简短上下文来 让大模型注意到增强后prompt的关键部分, 而不是过度依赖检索文本

方法:

• rerank: 仅仅通过相关性排名筛选出候选文档, 但是初次筛选不够精确, 这样不能反映最终的相关性, 还是要通过更强大的模型来二次排序(rerank)后进行筛选
• 上下文压缩(context compressing)

工具:

• LangChain(听过)
• LlamaIndex
• HayStack

3. Modular RAG

模块化RAG

这部分综述介绍了 Modular RAG（模块化 RAG）框架中的多个 模块（Modules），相比于 Naïve RAG 和 Advanced RAG，Modular RAG 允许灵活地调整、替换和新增模块，从而提高检索的质量和适用性。以下是各个模块的介绍：

📌 Modular RAG 中的核心模块**

📌 模块解释

1. Search 模块（搜索模块）

​ • 作用：

​ • 适用于不同的检索场景，支持直接从搜索引擎、数据库、知识图谱中获取信息。

​ • LLM 生成查询语句（SQL、SPARQL、API 调用等），适配不同数据源。

​ • 技术：

​ • 支持 向量检索、关键词检索、混合检索（Hybrid Retrieval）。

​ • 能够使用 LLM 解析查询意图，自动生成 SQL、SPARQL 或 API 调用代码，实现跨数据源检索。

2. RAGFusion 模块

​ • 作用：

​ • 解决传统检索的局限性，采用 多查询策略（Multi-query strategy），扩展用户查询，提高信息的多样性。

​ • 通过 并行向量检索 + 智能重排序（Re-rank） 发现显性与隐性知识。

​ • 技术：

​ • Parallel Vector Search（并行向量搜索）：对同一查询生成多个变体，并行检索多个数据库。

​ • Intelligent Re-ranking（智能重排序）：使用 LLM 或 BERT-based Re-ranker 重新排序候选检索结果，保证最优答案排前面。

3. Memory 模块（记忆模块）

​ • 作用：

​ • 让 RAG 具备 “长期记忆”，通过 LLM 记忆机制指导检索，使上下文信息更加精准。

​ • 形成 无界记忆池（Unbounded Memory Pool），对文本进行 自增强（Iterative Self-enhancement），逐步优化存储的知识。

​ • 技术：

​ • RAG + Retrieval-augmented Memory（RAM），即结合检索和记忆的增强存储方案。

​ • 适用于 会话式 AI、个性化问答、长期任务跟踪等 需要记忆的场景。

方法人话: 增量训练或者是把之前的对话记录在知识库中, 保证多次对话的一致性

4. Routing 模块（路由模块）

人话: 选择合适的检索方法, 或是不检索…

​ • 作用：

​ • 决定查询的最佳路径，智能选择是直接生成答案、检索数据库，还是从多个来源融合信息。

​ • 适用于 跨模态、多数据源 的 RAG 应用。

​ • 技术：

​ • LLM 充当 路由决策代理（Routing Agent），分析查询意图，决定最佳检索或推理方式。

​ • 混合信息流（Hybrid Information Flow）：支持不同数据源的信息合并（如文本+图像+知识图谱）。

5. Predict 模块（预测模块）

​ • 作用：

​ • 直接用 LLM 预测最相关的内容，减少无效检索，提高效率。

​ • 适用于 低检索成本、高生成精度 的任务，如 FAQ 生成、知识填空等。

​ • 技术：

​ • 上下文预测（Context Prediction）：让 LLM 直接 生成可能的检索结果，然后再进行搜索。

​ • 融合生成（Fusion-based Generation）：结合 LLM 预测和检索结果，提高最终答案的可信度。

6. Task Adapter 模块

​ • 作用：

​ • 让 RAG 自适应不同任务，提升零样本（Zero-shot）和小样本（Few-shot）任务的检索表现。

​ • 自动 调整 Prompt、检索策略、答案格式 以适应特定应用。

​ • 技术：

​ • Few-shot Query Generation：基于 LLM 生成适合任务的检索查询。

​ • 自动 Prompt 检索（Automated Prompt Retrieval），动态调整提示词，使 LLM 输出符合预期。

📌 额外提到的 RAG 变种

除了模块化 RAG，还提到了几种 不同模式的 RAG 变体：

🔎 结论

• Modular RAG 的模块化设计提升了检索质量和灵活性，可以根据不同任务动态调整结构。

• Search、RAGFusion、Memory、Routing、Predict、Task Adapter 这 6 大核心模块增强了信息获取的精准度。

• 不同的 RAG 变体（如 Rewrite-Retrieve-Read、Self-RAG） 进一步优化了 RAG 的能力，使其适应不同应用场景。

4. 补充: 漏洞代码检索可能的方法

在漏洞代码检索场景下，RAG 需要精准、高效地检索代码片段，同时支持语义查询，并能结合上下文理解代码的安全性。基于你的需求，以下模块的优化和组合会最适合你：

🔍 适用于漏洞代码检索的 Modular RAG 组合

📌 重点模块优化

1️⃣ Search（搜索模块）

​ • 传统的向量检索（如 FAISS、Milvus）可能无法完全捕捉代码漏洞的结构特征，建议采用：

​ • AST（抽象语法树）索引：基于代码结构进行检索，而非仅靠文本相似度

​ • API 调用图（Call Graph）检索：分析函数调用关系，发现潜在漏洞

​ • 混合检索（Hybrid Retrieval）：

​ • 语义向量检索（Transformer-based code embedding，如 CodeBERT、GraphCodeBERT）

​ • 符号分析（静态分析工具结合 RAG）

​ • 关键词匹配（CVSS 评分、CWE ID）

2️⃣ RAGFusion（多查询策略）

​ • 代码漏洞的查询往往需要不同的表达方式，例如：

​ • 代码等价转换（Semantic Code Equivalence）：变换不同代码风格、不同变量命名

​ • 补丁差异分析（Patch-based Retrieval）：利用 CVE 补丁信息进行反向检索

​ • Exploit 生成启发查询：基于已知攻击手法生成更有针对性的查询

3️⃣ Memory（长期记忆）

​ • 场景：

​ • 记录用户常搜索的漏洞模式，提高未来检索的相关性

​ • 存储历史检索上下文，避免重复查询

​ • 结合漏洞数据库（如 NVD、ExploitDB）进行知识增强

​ • 优化方法：

​ • 漏洞模式缓存（Vulnerability Pattern Cache）

​ • 漏洞传播路径学习（记住哪些代码片段往往与漏洞相关）

4️⃣ Routing（智能路由）

​ • 基于代码特征选择最佳检索方式：

​ • 静态分析（SAST）适用于结构化漏洞（如内存泄露）

​ • 动态分析（DAST）适用于行为相关漏洞（如命令注入）

​ • 混合方法（如 LLM 先生成可能的漏洞代码，再进行匹配）

5️⃣ Task Adapter（任务自适应）

​ • 代码漏洞类别多样，不同类型可能需要不同检索方式：

​ • 缓冲区溢出 → 结构化数据流分析

​ • SQL 注入 → 语义模式匹配

​ • 远程命令执行（RCE） → API 调用序列分析

​ • 权限提升（Privilege Escalation） → 依赖分析（Dependency Analysis）

​ • 通过自动任务适配，动态调整 RAG 结构，例如：

​ • 适配不同编程语言（C/C++、Python、Go）

​ • 适配不同漏洞检测工具（CodeQL、Joern）

6️⃣ Predict（漏洞预测 & 生成）

​ • 让 LLM 直接预测可能的漏洞代码

​ • 漏洞补全（Vulnerability Completion）：

​ • 仅有部分代码片段时，生成完整的漏洞示例

​ • Exploit 预测（Exploit Prediction）：

​ • 预测某段代码是否可能被利用

​ • 结合 PoC（Proof of Concept）数据库，提高 Exploit 生成能力

📌 适合你的向量数据库

为了高效支持漏洞代码检索，你需要一个能够处理 代码结构化检索 + 语义搜索 的向量数据库。以下是几个适合的方案：

数据库 优点 适用于

FAISS 高效向量搜索，支持 GPU 加速 大规模漏洞数据库的快速检索

Milvus 支持多种索引（HNSW、IVF），可扩展性强 混合代码/漏洞模式检索

Weaviate 自带文本+图结构检索，支持 GraphQL 查询 代码调用图 & 知识图谱增强 RAG

Pinecone 易用性高，适合云端部署 远程漏洞分析（如 Web 漏洞）

Qdrant Rust 实现，性能优越，支持过滤器 基于 CVE/CWE 分类的高效索引

推荐选择：

如果你的漏洞代码量很大，FAISS + Milvus 结合使用会是最优解：

​ • FAISS：适合大规模语义向量搜索（快速查找相似代码）

​ • Milvus：适合混合索引，能支持符号+语义混合检索

如果想结合 代码调用关系，Weaviate 会是不错的选择。

综合来看，漏洞代码检索 RAG 可能会采用 以下结构：

用户查询 --> 预处理（Query Expansion + Rewrite）

​ --> Routing（选择适合的检索方式）

​ --> Search（Milvus + FAISS 混合搜索）

​ --> Memory（存储漏洞模式，提高精准度）

​ --> Re-rank（BERT/LLM 重新排序，提高结果相关性）

​ --> 结果生成（Predict + LLM Summarization）

5. 重点: RAG, FT, ICL的对比

文章对RAG和FT的类比:

• RAG就像带笔记本参加开卷考试, 用高超的检索能力(翻书能力)和全面的知识库(带很多资料甚至上网查)来增强LLM的能力
• FT就像花长时间准备闭卷考试, LLM内化微调过程中的知识, 真正的理解, 泛化性更好, 遇到没见过但是相关的知识也能不出现幻觉(RAG方法中遇到没见过的知识可能出现幻觉), 对定制的任务性能也更好(比如限定输出格式等)

各项指标对比

1. External Knowledge Req

就是模型对专业领域知识的需求有多大, 对知识的实时性需求有多大
能力排名: RAG > FT >> ICL

​

2. Model Adaptation Req

就是模型需不需要调整参数, 泛化性如何(遇到没见过的知识会不会出现幻觉), 对特定任务的性能(比如限定输出格式等)

能力排名: FT >> RAG > ICL

3. 相应速度

能力排名: ICL $\approx$ FT > RAG(涉及检索和排序)

4. 计算资源需求

资源需求量大小: FT > RAG > ICL

5. 数据需求量

FT > RAG >> ICL

6. 推理能力 vs. 记忆能力

• Prompt Engineering 强调推理能力（基于预训练知识推理）

• RAG 强调信息检索能力（从外部知识库获取答案）

• Fine-tuning 强调记忆能力（将知识固化到模型中）

7. 动态性

也就模型能不能更新最新的知识

RAG > ICL(few-shot) > FT(静态)

3. 检索

1. 检索源

其他的都是NLP的源, 不讨论

特殊点的: LLM生成内容

在传统 RAG（Retrieval-Augmented Generation）框架中，模型通常从向量数据库、知识库或搜索引擎中检索相关文档，并将其提供给 LLM 进行总结或生成。但 LLM-Generated Content 试图利用 LLM 自身的知识，通过自回归生成、自适应检索、甚至存储和迭代优化自身记忆来增强 RAG 的效果。

LLM 生成的内容。为了解决 RAG 中外部辅助信息的局限性，一些研究集中在利用 LLM 的内部知识上。SKR [58] 将问题分类为已知或未知，选择性地应用检索增强。GenRead [13] 用 LLM 生成器替换了检索器，发现 LLM 生成的上下文通常包含更准确的答案，因为它与因果语言建模的预训练目标更加一致。Selfmem [17] 使用检索增强生成器迭代创建一个无界内存池，使用内存选择器选择作为原始问题的对偶问题的输出，从而自我增强生成模型。这些方法强调了 RAG 中创新数据源利用的广度，努力提高模型性能和任务效率。

核心思想：

既然 LLM 经过大规模预训练，已经包含了大量知识，为什么不让它自己生成信息，而非总是依赖外部检索？

就是LLM包含知识, 但是要显式的生成出来

LLM-Generated Content 的几种实现方式

1. SKR（Selective Knowledge Retrieval） - 选择性检索

方法：

• 先用 LLM 判断问题是否为“已知”或“未知”

• 已知问题：直接用 LLM 生成答案

• 未知问题：调用检索模块（RAG）

2. GenRead（Generate-Read） - 生成替代检索

方法

• 完全不使用检索器，让 LLM 生成背景知识，并基于该内容回答问题

• 依赖 LLM 强大的 内在知识（Pre-trained Knowledge）

重点: 为什么可行？

• LLM 预训练目标（Causal LM / Masked LM）天然适应从上下文预测知识

• 许多事实知识已经固化在 LLM 权重中

• LLM 生成的内容往往能更符合其内部知识结构

适用场景：

• 少量训练数据的任务（避免 Retriever 需要大规模索引）

• 格式化任务（如 SQL 生成、代码补全）

局限性：

• LLM 生成内容可能产生幻觉（hallucination）

• 无法适应实时更新的数据（如最新安全漏洞）

3. Selfmem（Self-Memory Augmentation） - 自增强记忆

方法：

• 让 LLM 自己创建“记忆池”，存储回答和相关背景知识
• 使用 Memory Selector 选择最有价值的记忆，提升后续回答质量
• 让 LLM 自我迭代训练，提升自身推理能力

关键技术：

• Retrieval-Enhanced Generator：模型自己检索、自己生成

• Memory Pool：存储生成的背景知识，提高上下文连贯性

• Dual Problem Creation：让 LLM 生成“相关问题”以自我训练

适用场景：

​ • 需要长期记忆的任务（如对话历史、代码修复）

​ • 需要持续增强的任务（如漏洞分类、日志分析）

🔹 LLM-Generated Content 在漏洞代码检索的应用

​ 你目前的应用场景是 漏洞代码检索，可以结合 LLM-Generated Content 进行优化：

1️⃣ 提高检索准确性（减少无关代码段）

​ • 结合 SKR，让 LLM 先判断漏洞是否常见

​ • 已知漏洞 → 直接用 LLM 生成解释

​ • 未知漏洞 → 触发代码库检索，提供真实代码

2️⃣ 让 LLM 生成补充信息

​ • 传统 RAG 检索出的代码可能缺乏上下文

​ • 结合 GenRead，让 LLM 生成 漏洞影响分析、修复建议

​ • 适用于 CVE 漏洞数据库、代码安全分析

3️⃣ 让 LLM 记住漏洞模式（Selfmem）

​ • 让 LLM 存储常见漏洞类型（Memory Pool）

​ • 未来查询时，不必总是从头检索，提高效率

​ • 适用于 重复性高的漏洞分析（如 SQL 注入、缓冲区溢出）

2. 检索粒度

1. 检索开销
   细粒度 > 粗粒度

2. 语义完整性(semantic integrity)
   粒度大可能提供更多相关信息也可能提供冗余信息
   提供信息量: 粗粒度 > 细粒度