RAG核心原理与工程落地详解：从Naive RAG到Agentic RAG

目录

一、什么是RAG，为什么需要RAG？

1.1 核心定义

RAG（Retrieval-Augmented Generation）即“检索增强生成”，核心思想是：

在生成答案前，先从外部知识库检索相关信息，再将检索结果注入Prompt，最后让LLM基于“问题+证据”生成答案。

1.2 为什么需要RAG

仅靠大模型参数记忆，常见问题有：

  • ❌ 知识过期（训练截止后新知识缺失）
  • ❌ 幻觉风险（一本正经地胡说）
  • ❌ 私域知识不可控（企业内部文档不在训练集）

RAG 的价值：

  • ✅ 接入最新知识（文档更新即可生效）
  • ✅ 降低幻觉（要求基于检索证据回答）
  • ✅ 增强可追溯性（可返回引用片段和来源）

1.3 RAG 与微调、Prompt工程的关系

方案 主要作用 优点 缺点 适用场景
Prompt工程 改写指令 成本低、上线快 对新知识无能为力 快速优化表达
Fine-tuning 学习任务模式 风格稳定、任务贴合 训练成本高，更新慢 固定任务范式
RAG 引入外部知识 知识可更新、可追溯 工程链路复杂 知识密集型问答

小结：Prompt解决“怎么问”，微调解决“怎么做”，RAG解决“知道什么”。

二、RAG的核心流程与系统架构

2.1 端到端流程

1
2
3
4
5
离线阶段：
文档采集 -> 清洗 -> Chunk切分 -> Embedding -> 向量索引构建

在线阶段：
用户问题 -> Query改写 -> 检索召回 -> Rerank重排 -> Prompt拼接 -> LLM生成 -> 引用返回

2.2 分层架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
                ┌───────────────────────┐
                │      Application       │
                │  Chat UI / API Gateway │
                └───────────┬───────────┘
                            │
                 ┌──────────▼──────────┐
                 │   Orchestration层    │
                 │ Query改写/路由/策略  │
                 └──────────┬──────────┘
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
┌──────▼──────┐      ┌──────▼──────┐      ┌──────▼──────┐
│ Retrieval层 │      │  Rerank层   │      │ Generation层│
│ BM25/Vector │      │ Cross-Encoder│      │ LLM推理     │
└──────┬──────┘      └──────┬──────┘      └──────┬──────┘
       │                    │                    │
┌──────▼────────────────────▼────────────────────▼──────┐
│               Knowledge Layer (DB / Vector DB)         │
└─────────────────────────────────────────────────────────┘

2.3 三个关键设计点

  1. 召回率优先：先“找得到”再“答得好”。
  2. 证据质量优先：无关上下文越多，答案越容易偏离。
  3. 可观测性优先：必须记录每一步中间结果，才能定位故障。

小结：RAG本质不是一个Prompt技巧，而是一条“检索+生成”的工程流水线。

三、三种RAG范式：Naive、Advanced、Agentic

3.1 Naive RAG（基础版）

标准流程：向量检索 -> 拼接上下文 -> 生成答案。

优点：

  • ✅ 架构简单、上线快

缺点：

  • ❌ 对长文档和复杂问题效果不稳定
  • ❌ 易受检索噪声影响

3.2 Advanced RAG（增强版）

常见增强：

  • Hybrid Retrieval（BM25 + Vector）
  • Rerank（交叉编码器重排）
  • Query Rewrite / HyDE
  • Metadata Filter（按时间、权限、主题过滤）

适合：知识库规模大、领域术语强、问法多变的场景。

3.3 Agentic RAG（智能体版）

关键能力：

  • 任务拆解（先判定子问题）
  • 工具调用（检索、数据库、搜索、API）
  • 多轮反思与修正（Reflection）
1
2
3
4
5
6
7
User Query
   -> Planner
      -> Tool Call 1 (Vector Search)
      -> Tool Call 2 (SQL/Graph)
      -> Tool Call 3 (Web)
   -> Evidence Merge
   -> Final Generation

3.4 三种范式对比

维度 Naive RAG Advanced RAG Agentic RAG
系统复杂度 低 中 高
效果上限 中 高 很高
延迟成本 低 中 高
可控性 中 高 高
适用问题复杂度 简单问答 中高复杂问答 复杂任务型问答

小结：范式演进路径是“能答”->“答准”->“答对复杂任务”。

四、检索优化四件套（Chunk / Hybrid / Rerank / Query优化）

4.1 Chunk策略（切分粒度）

核心问题：切太小会丢语义，切太大又会引入噪声。

实践建议：

  • 文本型知识库：每块 300-700 tokens
  • 技术文档：按标题层级切分（语义边界优先）
  • 推荐 overlap：10%~20%

4.2 Hybrid Retrieval（混合检索）

将关键词检索（BM25）与语义检索（Vector）结合：

  • BM25擅长精确术语
  • Vector擅长语义相似

常见融合方式：

  • 线性加权打分
  • Reciprocal Rank Fusion（RRF）

4.3 Rerank（重排序）

先粗召回 TopN，再用 Cross-Encoder 对候选进行精排，常见流程：

1
Recall Top50 -> Rerank -> Keep Top5 -> Inject Prompt

4.4 Query优化（重写与扩展）

当用户问题模糊时，可以做：

  • Query Rewrite：重写为更标准的问题
  • Query Expansion：补充同义词和上下文
  • HyDE：先生成“假想答案”，再用其向量检索

4.5 优化策略对比（面试高频表）

优化点 主要收益 主要代价 推荐优先级 适用场景
Chunk优化 提升召回相关性 需要离线调参 高 所有RAG
Hybrid检索 减少漏召回 召回链路变复杂 高 术语密集知识库
Rerank 提升TopK质量 增加延迟和算力 中高 高准确性要求
Query优化 提升难问句检索效果 可能引入偏移 中 用户问法多变

小结：RAG调优要遵循“先召回、再排序、后生成”的顺序，不要一上来就调Prompt。

五、Java生态落地：Spring AI 与 LangChain4j

5.1 Java实现最小闭环

1
文档入库 -> 向量化 -> 建索引 -> 用户提问 -> 检索TopK -> 拼接Prompt -> LLM回答 -> 引用返回

5.2 Spring AI 实现思路

  1. 使用 DocumentReader 读取企业文档。
  2. 使用 EmbeddingModel 生成向量并写入向量库（如 PGVector / Milvus）。
  3. 在线请求时通过 VectorStore 做相似度检索。
  4. 将检索结果注入模板化 Prompt，再调用 ChatModel 生成答案。

5.3 LangChain4j 实现思路

  1. 使用 EmbeddingStore 管理向量索引。
  2. 通过 RetrievalAugmentor 将检索逻辑与生成流程解耦。
  3. 引入 ContentRetriever 与 ReRanking 组件实现 Advanced RAG。

5.4 Java伪代码示例（简化）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class RagService {

    private final Retriever retriever;
    private final ChatModel chatModel;

    public RagService(Retriever retriever, ChatModel chatModel) {
        this.retriever = retriever;
        this.chatModel = chatModel;
    }

    public String answer(String query) {
        // 1) 检索证据
        List<String> docs = retriever.search(query, 5);

        // 2) 构造提示词
        String prompt = "请仅根据以下资料回答。\n" +
                "资料：" + String.join("\n", docs) + "\n" +
                "问题：" + query;

        // 3) 生成答案
        return chatModel.chat(prompt);
    }
}

小结：Java做RAG的关键不是框架选择，而是把“检索质量”做成稳定可观测的能力。

六、RAG评估体系：如何判断系统是否真的变好

6.1 检索层指标

  • Recall@K：正确证据是否被召回
  • MRR：正确证据排名是否靠前
  • NDCG：整体排序质量

6.2 生成层指标

  • 准确性（Answer Correctness）
  • 相关性（Answer Relevance）
  • 可追溯性（Faithfulness / Citation Grounding）

6.3 线上评估建议

  1. 构建黄金问答集（含标准证据文档）。
  2. 每次改动后执行离线回归评测。
  3. 线上监控“无答案率、低置信答案率、人工投诉率”。

6.4 评估误区

  • ❌ 只看最终答案，不看检索过程
  • ❌ 只看平均分，不看长尾问题
  • ❌ 没有对照实验就判定优化有效

小结：RAG评估要拆成“找得对”与“说得对”两段，不可混为一谈。

七、常见故障与调试路径（面试高频）

7.1 问题一：答非所问

可能原因：

  • 检索片段不相关
  • Prompt约束不清

排查顺序：

  1. 打印 TopK 召回文档
  2. 检查是否被 metadata 过滤误伤
  3. 检查Prompt是否明确“仅基于证据回答”

7.2 问题二：幻觉严重

可能原因：

  • 无证据也强行回答
  • 检索为空时缺少兜底策略

建议：

  • 设置“无证据拒答”模板
  • 要求返回引用，未引用则降置信度

7.3 问题三：延迟过高

可能原因：

  • 召回过多
  • Rerank模型过重
  • 多轮工具调用无缓存

建议：

  • 召回数量动态化（简单问题少召回）
  • 热点问题做结果缓存
  • 将重排模型改为轻量版本或异步链路

7.4 一条实用调试链路

1
先看Recall@K -> 再看Rerank后TopK质量 -> 再看最终答案与引用一致性 -> 最后再调Prompt

小结：大多数RAG问题不是模型太弱，而是检索链路质量不稳定。

八、面试速答版（60秒+扩展版）

8.1 60秒版（可直接背）

RAG是“检索增强生成”，核心流程是先检索外部知识，再把证据注入Prompt，最后由大模型生成答案。它主要解决大模型知识过期、幻觉和私域知识不可控问题。工程上一般分为检索、重排、生成三层，优化顺序是先提升召回，再做重排，最后调Prompt。若任务复杂到需要多工具协同和任务拆解，就从Advanced RAG升级到Agentic RAG。评估时要分开看检索指标和生成指标，确保系统既“找得对”也“说得对”。

8.2 扩展版（面试加分）

RAG可以看成LLM应用里的“知识中间层”。

在架构上，我通常会把它拆成离线索引构建和在线问答两条链路：离线做清洗、切分、向量化和索引；在线做Query改写、混合检索、重排和生成。

在优化上，我会优先做四件事：Chunk策略、Hybrid Retrieval、Rerank、Query优化。因为这四个点直接影响证据质量。

在工程落地上，Java生态可以用Spring AI或LangChain4j快速搭建闭环。真正的难点不在“能跑起来”，而在“可观测、可评估、可回归”。

在演进策略上，简单问答用Naive RAG，中高复杂问答用Advanced RAG，涉及任务规划和多工具协同时再升级到Agentic RAG，这样可以在效果和成本之间取得平衡。

总结

1
2
3
RAG不是一个Prompt技巧，而是一条知识增强流水线。
要把RAG做好，关键是三句话：
先找对证据（Retrieval） -> 再排好顺序（Rerank） -> 最后再生成答案（Generation）。