RAG 到底是怎么工作的？一文彻底搞懂 RAG 原理与完整流程
RAG 到底是怎么工作的？一文彻底搞懂 RAG 原理与完整流程
在学习 LangChain4j、Spring AI、Milvus、Embedding 等 AI 技术时，RAG 是一个绕不开的核心概念。
很多人第一次接触 RAG，会看到大量陌生的概念：
Document
Chunk
Embedding
Vector
Vector Database
Retriever
Prompt
LLM
RAG
然后很容易产生一个疑问：
RAG 到底是什么？
其实 RAG 的核心思想并不复杂。
一句话理解：
RAG = 先从自己的知识库中找到与用户问题相关的资料，再把这些资料交给大模型，让大模型结合这些资料生成答案。
也就是说：
用户问题
↓
搜索知识库
↓
找到相关资料
↓
把资料放进 Prompt
↓
交给大模型
↓
生成答案
这就是 RAG 最核心的工作原理。
一、为什么需要 RAG？
在理解 RAG 之前，我们首先要理解：
为什么不能直接问大模型？
例如我们开发了一家公司内部的 AI 知识库助手。
公司内部有大量资料：
公司员工手册.pdf
技术架构文档.pdf
Java开发规范.pdf
项目部署文档.pdf
产品需求文档.pdf
数据库设计文档.pdf
接口文档.pdf
现在用户问：
公司的年假制度是什么？
如果直接调用大模型：
用户
↓
LLM
↓
答案
大模型并不知道公司内部的年假制度。
因为这些资料并没有存在模型训练数据中。
于是模型可能：
不知道
甚至：
根据自己的知识猜一个答案
这就是大模型非常重要的一个问题：
大模型并不天然知道你的私有数据。
二、RAG 解决的是什么问题？
RAG 的目的就是：
让大模型在回答问题之前，先去查询外部知识。
例如：
用户：
公司的年假制度是什么？
RAG 系统不会马上问大模型。
而是：
用户问题
↓
检索知识库
↓
找到《员工手册》中关于年假的内容
↓
把相关内容交给大模型
↓
大模型根据资料回答
最终变成：
用户问题
↓
Retriever
↓
知识库搜索
↓
相关知识片段
↓
Prompt
↓
LLM
↓
最终答案
所以：
RAG 本质上是一种“检索 + 生成”的架构。
RAG 的全称是：
Retrieval-Augmented Generation
拆开来看：
Retrieval
检索
Augmented
增强
Generation
生成
也就是：
检索增强生成。
三、先记住 RAG 的一张总图
如果只记住一张图，我建议记住下面这张。
┌─────────────────┐
│ 用户问题 │
└────────┬────────┘
↓
┌─────────────────┐
│ Query 处理 │
│ 问题理解/改写 │
└────────┬────────┘
↓
┌─────────────────┐
│ Embedding │
│ 问题向量化 │
└────────┬────────┘
↓
┌─────────────────┐
│ Vector Search │
│ 向量检索 │
└────────┬────────┘
↓
┌─────────────────┐
│ Top-K 相关内容 │
└────────┬────────┘
↓
┌─────────────────┐
│ Prompt │
│ 问题 + 检索内容 │
└────────┬────────┘
↓
┌─────────────────┐
│ LLM │
│ 大语言模型 │
└────────┬────────┘
↓
┌─────────────────┐
│ 答案 │
└─────────────────┘
但是，这张图只描述了：
用户提问之后发生什么。
真正完整的 RAG 还包括：
知识库是怎么建立起来的。
所以完整 RAG 应该拆成两条链路：
RAG 系统
│
┌────────┴────────┐
↓ ↓
数据入库链路 用户查询链路
│ │
↓ ↓
文档加载 用户问题
↓ ↓
文本解析 Query处理
↓ ↓
文本切分 Embedding
↓ ↓
Embedding 向量检索
↓ ↓
向量数据库 Top-K
↓
Prompt组装
↓
LLM
↓
答案
这就是完整 RAG。
四、RAG 第一条链路：知识库构建
首先来看：
数据到底是怎么进入 RAG 系统的？
假设我们有一个 PDF：
Java开发规范.pdf
里面有：
第一章 Java编码规范
1. 类名必须使用 UpperCamelCase
2. 方法名必须使用 lowerCamelCase
3. 常量名称必须全部大写
4. 禁止使用魔法数字
...
RAG 首先要把这些内容处理成机器可以检索的数据。
完整流程：
PDF
↓
Document Loader
↓
Document
↓
Text Splitter
↓
Chunk
↓
Embedding
↓
Vector
↓
Vector Database
下面一步一步理解。
五、第一步：加载文档
首先需要把各种文件读取出来。
例如：
PDF
Word
TXT
Markdown
HTML
数据库
网页
通过对应的 Loader 读取。
例如：
PDF
↓
PDF Loader
↓
Document
最终得到类似：
Document {
content: "Java编码规范......",
metadata: {
source: "Java开发规范.pdf",
page: 10
}
}
这里最重要的是：
Document 不只是文本，还可以包含 Metadata。
例如：
content:
Java编码规范......
metadata:
source = Java开发规范.pdf
page = 10
category = Java
Metadata 在后面的检索、过滤、引用来源时非常重要。
六、第二步：文本切分 Chunk
这是 RAG 中非常重要的一步。
假设一本 PDF 有：
500 页
不能直接把整个 PDF 一次性丢给 Embedding 模型。
通常需要先进行：
Chunking：文本切分。
例如：
原始文档
Java开发规范
------------------
第一章
Java命名规范
......
第二章
异常处理规范
......
第三章
数据库规范
......
第四章
日志规范
......
切分之后：
Chunk 1
Java命名规范......
Chunk 2
异常处理规范......
Chunk 3
数据库规范......
Chunk 4
日志规范......
每个 Chunk 都是一个可以独立检索的知识单元。
七、为什么一定要 Chunk？
因为如果 Chunk 太大：
Chunk = 10000 字
可能包含大量无关信息。
用户问：
Java异常应该怎么处理？
但是整个 Chunk 里面可能包含：
Java命名规范
异常处理
数据库
日志
Git
部署
测试
......
检索出来以后：
相关信息太少，无关信息太多。
反过来，如果 Chunk 太小：
Chunk = 20 字
又可能导致：
上下文不完整
例如：
Chunk 1：
异常必须......
Chunk 2：
统一处理......
Chunk 3：
并记录日志......
单独检索某个 Chunk 时，语义可能已经不完整。
所以：
Chunk 的大小会直接影响 RAG 的检索效果。
八、Chunk 并不是简单地“每 N 个字符切一刀”
初学者非常容易误解：
Chunk = 每1000个字符切一次
实际上优秀的 RAG 系统通常会考虑：
段落
标题
章节
语义
代码结构
Markdown结构
HTML结构
例如：
# Java异常处理
## 1. 异常分类
...
## 2. 异常处理原则
...
## 3. 日志规范
...
比较合理的切分方式是：
Chunk 1
Java异常处理
异常分类......
Chunk 2
异常处理原则......
Chunk 3
日志规范......
而不是机械地：
每1000字符切一次
九、Chunk Overlap 是什么？
实际 RAG 中经常还会出现：
Chunk Size
Chunk Overlap
例如：
Chunk Size = 500
Overlap = 100
原文：
AAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDDDD
切分可能变成：
Chunk 1
AAAAAAAA
BBBBBBBB
Chunk 2
BBBBBBBB
CCCCCCCC
Chunk 3
CCCCCCCC
DDDDDDDD
这里：
BBBBBBBB
就是重叠部分。
为什么需要 Overlap？
因为避免重要信息刚好被切断。
例如一句话：
Spring AI 可以通过 VectorStore
实现向量数据的存储和检索。
如果刚好切成：
Chunk 1:
Spring AI 可以通过 VectorStore
Chunk 2:
实现向量数据的存储和检索。
上下文就被拆开了。
使用 Overlap 可以降低这种问题。
十、第三步：Embedding——把文字变成向量
Chunk 切完以后，下一个核心步骤：
Embedding。
这是 RAG 最重要的基础技术之一。
假设：
Chunk：
Java中HashMap的底层结构是什么？
Embedding 模型会把它转换成一组数字：
[0.0123,
-0.2841,
0.8912,
0.3321,
...]
这组数字就是：
向量 Vector。
例如：
文本
↓
Embedding Model
↓
Vector
十一、为什么要把文字转换成向量？
因为计算机很难直接理解：
Java异常处理规范
和：
系统应该如何处理Java异常？
是不是表达了相似的意思。
但是通过 Embedding，可以把文本映射到一个高维向量空间。
例如：
Java异常处理
↓
[0.12, 0.87, -0.31, ...]
Java异常规范
↓
[0.14, 0.83, -0.29, ...]
两个向量比较接近。
而：
深圳天气
可能变成：
[-0.82, 0.12, 0.74, ...]
距离就比较远。
于是我们可以通过：
向量相似度
找到语义相似的文本。
十二、Embedding 的核心思想
可以简单理解成：
语义相近
↓
向量空间中距离较近
语义不相关
↓
向量空间中距离较远
例如：
"Java异常处理"
"Java异常机制"
"Java Exception处理"
它们虽然文字不同，但是语义相近。
Embedding 的目标就是让：
Vector(Java异常处理)
≈
Vector(Java异常机制)
≈
Vector(Java Exception处理)
十三、第四步：把向量存进向量数据库
得到向量之后，还需要存起来。
这时候就出现了：
Vector Database：向量数据库。
常见的向量数据库包括：
Milvus
Qdrant
Weaviate
Pinecone
pgvector
Elasticsearch
OpenSearch
在 Java 项目中，也经常会通过 Spring AI 或 LangChain4j 对 VectorStore 进行统一封装。
十四、向量数据库里面到底存什么？
不是只存：
Vector
通常还会保存：
Vector
+
原始文本
+
Metadata
例如：
ID:
10001
Vector:
[0.123, -0.345, 0.891...]
Text:
Java异常应该统一进行处理......
Metadata:
source = java-guide.pdf
page = 32
category = java
可以理解成：
┌─────────────────────────────┐
│ Vector Database │
├─────────────────────────────┤
│ ID │
│ Vector │
│ Text │
│ Metadata │
└─────────────────────────────┘
十五、到这里，知识库就建立好了
整个知识入库流程：
PDF / Word / Markdown / Web
↓
文档解析
↓
Document
↓
Text Split
↓
Chunk
↓
Embedding
↓
Vector
↓
Vector Database
到这里：
RAG 的知识库已经准备好了。
接下来就是最关键的：
用户到底是怎么问问题的？
十六、RAG 第二条链路：用户查询
假设用户输入：
Java中的HashMap为什么线程不安全？
RAG 系统接收到问题之后，并不是：
问题
↓
LLM
而是：
问题
↓
Query处理
↓
Embedding
↓
Vector Search
↓
找到相关Chunk
↓
Prompt
↓
LLM
↓
答案
下面逐步分析。
十七、第一步：接收用户问题
用户输入：
Java中的HashMap为什么线程不安全？
系统把它称为：
Query
也就是：
查询问题。
十八、第二步：Query Embedding
用户问题也需要进行 Embedding。
例如：
Java中的HashMap为什么线程不安全？
转换成：
[0.123,
-0.823,
0.341,
0.921,
...]
注意：
这里使用的 Embedding 模型通常需要与知识库构建阶段保持兼容。
因为：
文档向量
和：
Query向量
最终需要在同一个向量空间中进行相似度比较。
十九、第三步：向量检索
现在系统有：
Query Vector
然后去向量数据库查询：
哪些 Chunk 和这个问题最相似？
例如知识库中有：
Chunk 1
Java HashMap底层结构......
Chunk 2
ConcurrentHashMap线程安全......
Chunk 3
Java ArrayList实现......
Chunk 4
Java线程池......
Chunk 5
Redis缓存......
用户问题：
HashMap为什么线程不安全？
经过向量相似度计算：
Chunk 1 → 0.91
Chunk 2 → 0.84
Chunk 3 → 0.32
Chunk 4 → 0.28
Chunk 5 → 0.11
系统就会优先选择：
Chunk 1
Chunk 2
这就是：
Retrieval：检索。
二十、什么是 Top-K？
实际系统不会把所有知识都返回。
例如：
100万条 Chunk
不可能全部交给大模型。
通常会选择：
Top-K
例如：
Top-K = 5
也就是：
找出最相关的 5 个知识片段。
例如：
用户问题
↓
Vector Search
↓
Top 5
↓
Chunk 12
Chunk 893
Chunk 1024
Chunk 2048
Chunk 9999
二十一、但是 Top-K 并不意味着一定正确
这是理解 RAG 非常重要的一点：
向量检索不是“答案检索”，而是“相似内容检索”。
例如：
用户：
HashMap为什么线程不安全？
检索出来：
HashMap底层结构
只能说明：
这个内容和问题比较相关。
不能说明：
这个内容一定包含完整答案。
所以成熟 RAG 往往还会继续做：
召回
↓
重排序
↓
过滤
↓
Prompt
二十二、Rerank：为什么需要重排序？
假设第一次向量检索得到：
Chunk A → 0.91
Chunk B → 0.89
Chunk C → 0.87
Chunk D → 0.86
Chunk E → 0.85
但是向量相似度只是第一阶段筛选。
可以再使用 Reranker：
Query
+
Chunk A
↓
Reranker
↓
相关性评分
重新排序：
Chunk C → 0.98
Chunk A → 0.95
Chunk D → 0.91
Chunk B → 0.75
Chunk E → 0.43
最终只把：
Chunk C
Chunk A
Chunk D
交给大模型。
所以企业级 RAG 常见流程：
Vector Search
↓
初步召回
↓
Rerank
↓
精准筛选
↓
LLM
二十三、第四步：把检索结果放进 Prompt
这是 RAG 最关键的一步。
假设我们找到：
Chunk 1：
HashMap在并发环境下可能出现数据覆盖、数据结构异常等问题，
因此HashMap本身不是线程安全的数据结构。
用户的问题是：
HashMap为什么线程不安全？
系统会构建一个 Prompt：
你是一个Java技术专家。
请根据下面的知识库内容回答用户问题。
【知识库内容】
HashMap在并发环境下可能出现数据覆盖、数据结构异常等问题，
因此HashMap本身不是线程安全的数据结构。
【用户问题】
HashMap为什么线程不安全？
然后：
Prompt
↓
LLM
二十四、这就是 RAG 最核心的秘密
很多人以为：
RAG 是让大模型“学会”了公司的知识。
其实不是。
RAG 并没有重新训练大模型。
而是：
用户问题
↓
搜索外部知识
↓
找到相关知识
↓
塞进 Prompt
↓
让大模型参考这些知识回答
所以：
RAG 的知识并没有真正进入模型参数，而是在推理时作为上下文提供给模型。
这是 RAG 和 Fine-tuning 非常重要的区别。
二十五、第五步：LLM 生成答案
现在大模型看到的是：
System Prompt
+
知识库内容
+
用户问题
例如：
System：
你是Java专家。
请严格根据知识库内容回答。
如果知识库中没有答案，请明确说明。
Context：
HashMap本身不是线程安全的数据结构。
并发环境下可能出现数据覆盖等问题。
Question：
HashMap为什么线程不安全？
大模型最终生成：
HashMap不是线程安全的，主要原因是其内部数据结构和操作没有提供并发控制。
在多个线程同时执行put、resize等操作时，
可能出现数据覆盖、结构异常等问题。
如果需要在并发环境中使用Map，
通常应该考虑ConcurrentHashMap。
最终：
LLM
↓
Answer
二十六、到这里，完整 RAG 流程就跑完了
把整个流程连起来：
【知识库构建阶段】
PDF / Word / Markdown / DB
↓
文档解析
↓
Document
↓
文本切分
↓
Chunk
↓
Embedding
↓
Vector
↓
Vector Database
│
│
│
↓
【用户查询阶段】
用户问题
↓
Query处理/改写
↓
Embedding
↓
Vector Search
↓
Top-K召回
↓
Rerank重排序
↓
Context上下文
↓
Prompt Template
↓
LLM
↓
最终答案
这就是一个完整的 RAG Pipeline。
二十七、用一个真实项目理解 RAG
假设我们正在开发：
AI 企业知识库助手
技术栈：
Spring Boot
Spring AI
MySQL
Milvus
Embedding Model
LLM
公司有：
1000份PDF
500份Word
2000份Markdown
1. 文档上传
管理员上传：
Java开发规范.pdf
系统：
PDF
↓
解析
↓
Text
2. 文本切分
例如：
100页PDF
切成：
500个Chunk
3. Embedding
每个 Chunk：
Chunk
↓
Embedding Model
↓
1024维向量
4. 写入 Milvus
保存：
id
vector
content
metadata
例如：
id = 10001
content =
"HashMap在并发环境下不是线程安全的..."
metadata =
{
fileName: "Java开发规范.pdf",
page: 32,
category: "Java"
}
二十八、用户开始提问
用户：
HashMap为什么线程不安全？
系统：
Query
↓
Embedding
↓
Vector Search
↓
Milvus
Milvus 找到：
Chunk 10001
Chunk 10008
Chunk 10013
二十九、构建上下文
系统把这些 Chunk 拼成：
Context：
Chunk 10001:
HashMap在并发环境下不是线程安全的......
Chunk 10008:
多个线程同时执行put操作时......
Chunk 10013:
ConcurrentHashMap提供了并发安全能力......
然后：
Context
+
Question
进入 Prompt。
三十、调用大模型
最终请求：
LLM(
question,
context
)
大模型根据：
用户问题
+
检索到的知识
生成答案。
三十一、最终返回
用户看到：
HashMap本身不是线程安全的。
在多线程环境下，如果多个线程同时修改HashMap，
可能出现数据覆盖、结构异常等问题。
如果需要在并发环境中使用Map，
可以考虑ConcurrentHashMap。
如果系统还保存了 Metadata：
source = Java开发规范.pdf
page = 32
还可以返回：
参考来源：
Java开发规范.pdf
第32页
这就是企业知识库最常见的 RAG 场景。
三十二、RAG 本质上可以抽象成两个阶段
如果要用一句非常清晰的话总结：
RAG
=
知识准备
+
问题回答
知识准备：
文档
↓
切分
↓
Embedding
↓
向量数据库
问题回答：
问题
↓
Embedding
↓
检索
↓
相关知识
↓
Prompt
↓
LLM
↓
答案
三十三、RAG 中几个核心组件到底是什么？
到这里，可以把所有概念对应起来。
| 概念 | 作用 |
|---|---|
| Document | 原始文档 |
| Chunk | 文档切分后的知识片段 |
| Embedding | 把文本转换成向量 |
| Vector | 文本的向量表示 |
| Vector Database | 保存和检索向量 |
| Retriever | 从知识库检索相关内容 |
| Top-K | 取最相关的K个结果 |
| Reranker | 对召回结果再次排序 |
| Context | 提供给LLM的知识上下文 |
| Prompt | 告诉LLM应该如何回答 |
| LLM | 根据问题和上下文生成答案 |
把这些东西串起来：
Document
↓
Chunk
↓
Embedding
↓
Vector
↓
Vector DB
↓
Retriever
↓
Top-K
↓
Reranker
↓
Context
↓
Prompt
↓
LLM
三十四、RAG 最容易理解错的地方
误区一：RAG 等于训练大模型
错误。
RAG：
不修改模型参数
而是：
推理时提供外部知识
误区二：向量数据库里面存的是答案
不准确。
向量数据库主要保存：
向量
+
文本
+
Metadata
它负责：
找到相关知识。
最终答案还是：
LLM
生成的。
误区三：Embedding 就是大模型
不是。
Embedding Model：
文本
↓
向量
LLM：
问题 + 上下文
↓
答案
两者职责完全不同。
三十五、RAG 和传统搜索有什么区别？
传统搜索：
关键词
↓
倒排索引
↓
关键词匹配
例如搜索：
HashMap 线程安全
主要依赖：
HashMap
线程安全
这些关键词。
而 RAG 的向量搜索更加关注：
语义相似度。
例如：
为什么HashMap不能在多线程环境下直接使用？
即使知识库里面写的是：
HashMap本身不具备并发安全能力。
关键词可能不完全一致。
但是 Embedding 可以识别：
语义相关
所以：
传统搜索
关键词匹配
RAG
语义检索
当然，现代企业级 RAG 往往会把：
关键词搜索
+
向量搜索
+
Rerank
结合起来，也就是常见的：
Hybrid Search（混合检索）。
三十六、RAG 为什么有时候效果不好？
理解这个问题非常重要。
因为：
RAG 并不是“接上向量数据库就一定准确”。
RAG 的效果取决于整个链路。
可以抽象成：
RAG效果
=
文档质量
×
切分质量
×
Embedding质量
×
检索质量
×
Rerank质量
×
Prompt质量
×
LLM能力
任何一个环节出现问题，都可能导致最终答案不好。
三十七、例如 Chunk 切错了
原文：
Spring AI支持Tool Calling。
Tool可以让大模型调用外部系统。
例如：
查询数据库
调用天气API
查询订单
如果错误切分：
Chunk 1：
Spring AI支持Tool Calling。
Chunk 2：
Tool可以让大模型调用外部系统。
可能导致：
Tool到底是什么？
只能找到部分上下文。
三十八、例如检索错了
用户问：
如何查询订单？
结果召回：
订单创建流程
订单取消流程
订单支付流程
但是没有召回：
订单查询接口
这时候：
不是 LLM 不聪明，而是 RAG 根本没有把正确资料找出来。
所以 RAG 中一个非常重要的原则：
Garbage In, Garbage Out。
检索错了：
Retrieval错
后面的 LLM 再强，也很难得到正确答案。
三十九、因此企业级 RAG 通常不是简单的：
Question
↓
Embedding
↓
Vector Search
↓
LLM
而是：
用户问题
↓
Query Rewrite
↓
Query Embedding
↓
┌───────────┴───────────┐
↓ ↓
Vector Search Keyword Search
↓ ↓
└───────────┬───────────┘
↓
Hybrid Search
↓
Top-K
↓
Rerank
↓
Context
↓
Prompt Template
↓
LLM
↓
Answer
这才是更加接近企业实际项目的 RAG 架构。
四十、进一步理解：RAG 其实就是给 LLM 加了一双“搜索眼睛”
可以用一个非常形象的比喻理解。
普通 LLM：
┌─────────────┐
用户问题 ───→│ LLM │
└─────────────┘
↓
答案
它只能依赖：
模型参数
+
当前上下文
而 RAG：
┌──────────────┐
│ 知识库 │
└──────┬───────┘
↑
│
用户问题 ──→ 检索系统 ─────────┘
│
↓
找资料
│
↓
LLM
│
↓
答案
所以可以把 RAG 理解成：
给大模型增加了一个外部知识库。
四十一、RAG 最核心的一句话
如果面试官问：
你能不能简单讲一下 RAG？
可以这样回答：
RAG，也就是 Retrieval-Augmented Generation，核心思想是在大模型生成答案之前，先从外部知识库中检索与用户问题相关的知识片段，然后将这些知识作为上下文注入 Prompt，再交给大模型生成最终答案。
整个过程可以分为知识库构建和在线问答两个阶段。知识库构建阶段主要包括文档解析、文本切分、Embedding 向量化以及向量数据库存储；在线问答阶段主要包括 Query 处理、向量检索、Top-K 召回、Rerank、上下文组装、Prompt 构建以及 LLM 生成答案。
RAG 最大的价值是不需要重新训练大模型，就可以让大模型基于企业自己的私有知识回答问题，同时还可以通过 Metadata 返回答案来源。
这就是一个非常标准的企业级 RAG 面试回答。
四十二、最后用一张图彻底记住 RAG
RAG
│
┌────────────┴────────────┐
│ │
↓ ↓
【知识库构建】 【用户问答】
│ │
↓ ↓
PDF/Word 用户问题
↓ ↓
文档解析 Query处理
↓ ↓
Document Embedding
↓ ↓
Chunking Vector Search
↓ ↓
Embedding Top-K
↓ ↓
Vector Reranker
↓ ↓
Vector Database Context
│ │
│ ↓
│ Prompt Template
│ │
└─────────────────────────┤
↓
LLM
↓
Answer
↓
引用/来源
把它压缩成一句话就是：
文档
↓
切分
↓
Embedding
↓
向量数据库
↓
用户提问
↓
Query Embedding
↓
检索
↓
Rerank
↓
Context
↓
Prompt
↓
LLM
↓
答案
这就是：
RAG 的完整生命周期。
四十三、下一步应该继续学习什么？
如果按照企业级 Java + AI 工程师的路线学习 RAG，建议按照下面顺序继续深入：
第1阶段：RAG基础
│
├── 1. RAG原理
├── 2. Embedding
├── 3. Chunk
├── 4. Vector Database
└── 5. Retriever
第2阶段：RAG核心技术
│
├── 6. 相似度搜索
├── 7. Top-K
├── 8. Metadata Filter
├── 9. Rerank
├── 10. Hybrid Search
└── 11. Query Rewrite
第3阶段：高级RAG
│
├── 12. Parent-Child Retrieval
├── 13. Multi-Query Retrieval
├── 14. Contextual Retrieval
├── 15. Self Query
├── 16. HyDE
├── 17. Graph RAG
└── 18. Agentic RAG
第4阶段：企业级RAG
│
├── 19. 权限控制
├── 20. 多租户
├── 21. 文档更新
├── 22. 增量Embedding
├── 23. 删除与重建索引
├── 24. RAG评估
├── 25. Recall / Precision
├── 26. RAGAS
└── 27. 生产环境性能优化
第5阶段：Java企业级实现
│
├── Spring Boot
├── Spring AI
├── LangChain4j
├── Milvus
├── Elasticsearch
├── MySQL
└── Redis
如果你接下来准备做 Spring AI + Java 的企业级 RAG 项目，最值得继续深入的是：
文档上传
↓
PDF解析
↓
智能Chunk
↓
Embedding
↓
Milvus
↓
Hybrid Search
↓
Rerank
↓
Prompt
↓
DeepSeek / Qwen / GPT
↓
流式回答
↓
引用来源
↓
权限控制
↓
RAG评估
这条链路真正走通之后，你基本就不只是“知道 RAG 是什么”，而是已经具备了企业级 RAG 开发的完整技术认知。
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
4
0- 0
已为社区贡献2条内容
所有评论(0)