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

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

文章目录

[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. Introduction&Abstract)
- - [1. LLM面临的问题](#1. LLM面临的问题)
  - [2. RAG核心三要素](#2. RAG核心三要素)
  - [3. RAG taxonomy](#3. RAG taxonomy)
- [2. Overview: RAG的概念和范式(paradigm)](#2. Overview: RAG的概念和范式(paradigm))
- - [1. Naive RAG](#1. Naive RAG)
  - - [(1) Indexing](#(1) Indexing)
    - [(2) Retrieval](#(2) Retrieval)
    - [(3) Generation](#(3) Generation)
    - [(4) 面临的挑战](#(4) 面临的挑战)
  - [2. Advanceed RAG](#2. Advanceed RAG)
  - - [(1) Pre-retrieval](#(1) Pre-retrieval)
    - [(2) Post-retrieval](#(2) Post-retrieval)
  - [3. Modular RAG](#3. Modular RAG)
  - - [📌 Modular RAG 中的核心模块**](#📌 Modular RAG 中的核心模块**)
    - [**📌 模块解释**](#📌 模块解释)
    - - [1. Search 模块（搜索模块）](#1. Search 模块（搜索模块）)
      - [2. RAGFusion 模块](#2. RAGFusion 模块)
      - [3. Memory 模块（记忆模块）](#3. Memory 模块（记忆模块）)
      - [4. Routing 模块（路由模块）](#4. Routing 模块（路由模块）)
      - [5. Predict 模块（预测模块）](#5. Predict 模块（预测模块）)
      - [6. Task Adapter 模块](#6. Task Adapter 模块)
    - [**📌 额外提到的 RAG 变种**](#📌 额外提到的 RAG 变种)
    - - [**🔎 结论**](#🔎 结论)
  - [4. 补充: 漏洞代码检索可能的方法](#4. 补充: 漏洞代码检索可能的方法)
  - [5. 重点: RAG, FT, ICL的对比](#5. 重点: RAG, FT, ICL的对比)
  - - 文章对RAG和FT的类比:
    - 各项指标对比
    - - [1. External Knowledge Req](#1. External Knowledge Req)
      - [2. Model Adaptation Req](#2. Model Adaptation Req)
      - [3. 相应速度](#3. 相应速度)
      - [4. 计算资源需求](#4. 计算资源需求)
      - [5. 数据需求量](#5. 数据需求量)
      - [6. 推理能力 vs. 记忆能力](#6. 推理能力 vs. 记忆能力)
      - [7. 动态性](#7. 动态性)
- [3. 检索](#3. 检索)
- - [1. 检索源](#1. 检索源)
  - [LLM-Generated Content 的几种实现方式](#LLM-Generated Content 的几种实现方式)
  - - [1. SKR（Selective Knowledge Retrieval） - 选择性检索](#1. SKR（Selective Knowledge Retrieval） - 选择性检索)
    - [2. GenRead（Generate-Read） - 生成替代检索](#2. GenRead（Generate-Read） - 生成替代检索)
    - [3. Selfmem（Self-Memory Augmentation） - 自增强记忆](#3. Selfmem（Self-Memory Augmentation） - 自增强记忆)
  - [2. 检索粒度](#2. 检索粒度)

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 中的核心模块**

模块名称	作用	关键技术
🔍 Search 模块	适应不同场景，支持跨数据源的搜索	直接查询搜索引擎、数据库、知识图谱，利用 LLM 生成代码或查询语句
🌀 RAGFusion 模块	解决传统搜索的局限性，增强检索的广度	多查询策略（将用户查询扩展为多个角度）、并行向量搜索、智能重排序（Re-rank）
🧠 Memory 模块	让 RAG 具备"记忆"能力，使检索更贴合数据分布	LLM 记忆机制、自增强（Iterative Self-enhancement）
🚦 Routing 模块	智能路由查询，选择最佳信息路径	根据查询类型决定是否检索数据库、搜索引擎、知识图谱，或进行 LLM 直接推理
🎯 Predict 模块	减少冗余和噪声，直接生成高相关的上下文	LLM 直接预测最相关的内容，无需冗余检索
🔧 Task Adapter 模块	针对不同任务调整 RAG，提高零样本/小样本适配性	自动化 Prompt 生成，任务特定的检索器（few-shot query generation）

📌 模块解释

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 变体：

方法	核心思路
Rewrite-Retrieve-Read	先用 LLM 重写查询，再检索，提高任务适配性
Generate-Read	直接用 LLM 生成内容，而非传统检索
ReciteRead	让 LLM 从自身权重中召回知识，提高知识密集型任务能力
Demonstrate-Search-Predict（DSP）	结合示例学习（Demonstrate）、搜索（Search）和预测（Predict），提升检索质量。
ITERRETGEN	Retrieve-Read-Retrieve-Read 迭代流程，增强检索优化能力
FLARE & Self-RAG	让 RAG 动态决定是否需要检索，减少不必要的搜索

🔎 结论

Modular RAG 的模块化设计提升了检索质量和灵活性，可以根据不同任务动态调整结构。
Search、RAGFusion、Memory、Routing、Predict、Task Adapter 这 6 大核心模块增强了信息获取的精准度。
不同的 RAG 变体（如 Rewrite-Retrieve-Read、Self-RAG） 进一步优化了 RAG 的能力，使其适应不同应用场景。

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

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

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

模块	作用	适配漏洞代码检索的关键优化
🔍 Search（搜索模块）	在代码数据库、GitHub、NVD、CVE 等数据源中检索漏洞代码	语义 + 结构化混合检索，结合 AST、API 调用图
🌀 RAGFusion（多查询增强检索）	生成多个不同角度的查询，覆盖更全面的漏洞模式	漏洞语义变体扩展（代码重构、等价转换）
🧠 Memory（记忆模块）	记住用户的检索习惯，提高上下文一致性	漏洞模式缓存（存储漏洞模式和修复建议）
🚦 Routing（智能路由）	选择最佳检索方式（代码相似性、API 调用、补丁分析）	基于代码特征的动态检索策略
🔧 Task Adapter（任务自适应）	适配不同漏洞类别（缓冲区溢出、SQL 注入、RCE）	按漏洞类型自动调整检索策略
🎯 Predict（生成预测）	直接基于 LLM 生成潜在漏洞代码	漏洞填充与预测（补全漏洞代码，生成 Exploit）

📌 重点模块优化

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. 检索粒度

检索开销

细粒度 > 粗粒度
语义完整性(semantic integrity)

粒度大可能提供更多相关信息也可能提供冗余信息

提供信息量: 粗粒度 > 细粒度