RAG详解：人工智能系统如何按需获取最新知识
了解检索增强生成的工作原理，从分块与嵌入到向量搜索，从而让人工智能模型无需重新训练即可回答问题。
想象一个很久以前就完成训练的AI助手。
你向它提问：
“我刚刚上传的这份文档里有什么内容？”
该模型在训练过程中从未接触过那个文件。
那它怎么可能回答呢？
一种解决方案是被称为检索增强生成的技术，通常简写为RAG。
RAG能让AI系统从外部来源获取相关资料，并将这些资料融入它生成的答案中。
有趣的是：
每当有新信息出现时，无需重新训练模型。
让我们来看看其工作原理。
问题所在：AI无法知晓一切
大型语言模型会从其训练所使用的数据中学习。
该过程的简化示意图如下：
Training Data
↓
Model Training
↓
Model Parameters
↓
AI Model
↓
Generate Answers
训练完成后，模型无法自动获取之后出现的新文档、网站、公司报告或私人文件。
假设你今天完成了模型的训练。
那么明天，有人创建了：
new_report.pdf
在模型训练时根本不存在那个PDF文件。
那么模型要如何回答以下问题呢：
“这份报告的三个主要发现是什么？”
这正是RAG旨在填补的空白。
什么是RAG？
RAG = 检索增强生成
其名称本身就解释了工作原理：
- 检索 → 定位相关信息
而非简单的流程：
Question
↓
LLM
↓
Answer
你可以构建如下管道：
Question
↓
Retrieve relevant information
↓
Add information to context
↓
LLM
↓
Answer
这一架构上的转变可能会产生重大影响。
RAG与传统AI
没有RAG时，流程是直接的：
┌──────────────┐
Question ───→│ LLM │
└──────┬───────┘
↓
Answer
加入RAG后：
┌─────────────────┐
│ External Data │
│ PDFs / Docs │
│ Database / Web │
└────────┬────────┘
↓
Question → Retrieval → Relevant Context
↓
LLM
↓
Answer
模型不再需要提前记住所有内容。
相反，它能够按需获取相关事实。
RAG究竟是如何工作的？
标准的RAG架构要经过几个不同的阶段：
Documents
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
← User Question
↓
Query Embedding
↓
Similarity Search
↓
Relevant Chunks
↓
LLM
↓
Final Answer
让我们逐一了解它们。
收集数据
起点是收集原始资料。这些资料可能包括：
- PDF格式的文件
- 用Word制作的文档
- 从网站获取的页面
- 学术或研究论文
- 公司内部记录
- 产品说明手册
- 纯文本文件
- 存储在数据库中的记录
- 知识库中的条目
举个例子，想象有一个文件夹包含：
company_policy.pdf
research_paper.pdf
employee_handbook.pdf
product_manual.pdf
RAG流程能够处理所有这些类型的内容。
将文档拆分为块
由于大小限制，通常无法一次性将整份文档输入模型。
因此，文档会被分解为更小的单元，即块。
以下是一个简单的示例：
Document
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
├── Chunk 5
└── ...
想象一份有100页、包含数千句话的文档。
无需在每次查询时都扫描全部内容，可以将其拆分成更易处理的部分：
Chunk 1 → Introduction
Chunk 2 → Architecture
Chunk 3 → Security
Chunk 4 → Performance
Chunk 5 → Limitations
分割方式取决于内容的性质以及正在构建的系统。
将文本转换为嵌入向量
这才是真正有趣的部分。
计算机至少无法像人类那样直接理解文本含义。
为了解决这个问题，文本会被转换成称为嵌入向量的数值向量。
来看这个例子：
"Machine learning is a branch of AI"
↓
Embedding Model
↓
[0.21, -0.14, 0.73, ...]
还有第二句话：
"Artificial intelligence includes machine learning"
↓
[0.19, -0.11, 0.70, ...]
由于这两句话含义相近，它们对应的嵌入向量通常会位于嵌入空间中的相近位置。
大致可视化如下：
AI
●
/ \
/ \
ML ● ● Robotics
\
\
Cooking ●
重点并非寻找字面意义上的重复内容。
相反，其目标是捕捉语义相似性——即含义上的接近程度。
什么是语义搜索？
传统的关键词搜索引擎会处理如下查询：
"car"
然后寻找那些字面包含car这个词的文档。
而语义搜索则试图理解查询的实际含义。
例如，像这样的查询：
"电动汽车如何储存能量？"
可能会找到解释电动汽车依靠锂离子电池来储存电能的段落。
这两者的用词几乎没有重叠，但匹配结果依然合理。
这是因为嵌入模型编码的是含义上的关系，而不仅仅是拼写。
将嵌入存储在向量数据库中
一旦生成了嵌入向量，就需要一个存储它们的地方。
这就是向量数据库的作用，它用于存储：
Chunk
+
Embedding
+
Metadata
大致结构如下：
Vector Database
ID Vector Text
-------------------------------------
1 [0.21,...] Chunk A
2 [0.78,...] Chunk B
3 [0.34,...] Chunk C
4 [0.91,...] Chunk D
当有人提交问题时，系统会扫描这些存储的向量以找到匹配的上下文。
用于此类向量搜索的一些常用工具包括：
- FAISS
- pgvector
- Pinecone
- Weaviate
- Milvus
- Chroma
选择哪种具体的数据库并非关键所在。
重要的是：
将信息以支持快速、基于语义检索的形式存储。
用户提出问题
假设用户输入：
“该系统使用了哪些安全机制？”
该问题随后会被转换为其自身的嵌入向量。
User Question
↓
Embedding Model
↓
Query Vector
此时，系统会持有该问题的数值指纹。
搜索相关信息
该查询向量随后会与数据库中已有的所有向量进行比对。
简而言之：
Query
●
/ \
/ \
● ●
Relevant Relevant
Chunk Chunk
●
Unrelated
匹配度最高的片段会被提取出来。
例如，给定：
Question:
"What security mechanisms does the system use?"
系统可能会返回：
Retrieved:Chunk 17 → Authentication
Chunk 42 → Encryption
Chunk 51 → Access control
这样，模型就有了有意义且相关的上下文可供使用。
将获取的信息添加到提示词中
一旦找到相关片段，它们就会作为上下文与原始问题一起传递给大语言模型。
从概念上讲，提示词的结构如下：
System Instructions
+
User Question
+
Retrieved Context
↓
LLM
↓
Answer
例如：
Context:
"The system uses AES-GCM encryption
for protecting stored data..."Question:"What encryption method does the
system use?"
在这样的设置下，模型可能会给出类似如下的回复：
“系统使用AES-GCM加密来保护存储的数据。”
该回复基于检索到的信息，而非完全依赖于模型在初始训练过程中吸收的内容。
这就是核心思想
模型本身未必从这次交互中学习到任何永久性的内容。
其内部参数保持不变。
实际上，流程如下：
New Information
↓
External Knowledge Store
↓
Retrieve When Needed
↓
LLM Uses Context
↓
Answer
模型固有的知识与可更换的外部知识源之间的这种分离，正是RAG具备优势的关键所在。
RAG并不意味着人工智能已经掌握了这些信息
这一区别非常重要，也很容易被误解。
假设你上传了一个这样的文件：
Project_Report.pdf
然后助手开始根据它来回答问题。
但这并不意味着模型已经将该报告的内容永久地融入到其权重中。
实际上，该文档：
Stored externally
↓
Retrieved when relevant
↓
Provided as context
↓
Used to generate response
一个恰当的类比是学生在考试时查阅教科书。
学生并不会提前记住书中的每一页内容。
实际操作流程如下：
先提出问题，再找到相关页面，然后阅读，最后作答
RAG的工作方式大致也是如此。
RAG与微调
这种对比经常被提及，因此有必要清晰地说明。
微调
微调实际上是通过在特定的示例集上继续训练来调整模型的参数。
从概念上讲：
Base Model
↓
Training Data
↓
Fine-Tuning
↓
Modified Model
RAG
RAG几乎不会改变模型本身的结构，而是在收到问题时提供外部信息。
Base Model
+
External Knowledge
↓
Retrieval
↓
Context
↓
Answer
以下是简化的并列对比：
| 功能特性 | RAG | 微调 |
|---|---|---|
| 是否改变模型参数 | 通常不改变 | 会改变 |
| 外部知识整合能力 | 非常出色 | 相对较弱 |
| 知识更新方式 | 更新文档或索引 | 可能需要重新训练 |
| 私有文档处理 | 十分有用 | 可行，但需权衡其他因素 |
| 风格或行为控制 | 能力有限 | 适用场景更广泛 |
| 信息来源追溯性 | 潜力巨大 | 无法天然保证 |
这两种技术并非互斥的，团队可以将它们结合起来使用。
RAG能访问互联网吗？
可以。
外部知识库不必存储在私有的文档存储系统中。
系统可以从以下来源获取信息：
Internet
↓
Search Engine
↓
Relevant Pages
↓
LLM
↓
Answer
当问题需要基于最新事实时，这种方法就显得非常有用。
例如：
“该软件的最新版本有哪些变化？”
在这种情况下，系统可以先获取当前的文档，并以此作为回答的依据。
不过，仅靠信息检索仍无法保证准确性。
所获取的信息来源仍需可靠，且确实与问题相关。
用于自有文档的RAG
这种模式最实用的功能之一就是让你能够直接与自己的文件进行交互。
想象一个包含以下内容的文件夹：
Research/
│
├── paper1.pdf
├── paper2.pdf
├── dataset_notes.pdf
├── experiment_results.pdf
└── thesis.pdf
基于RAG的架构可以让你提出这样的问题：
“实验中发现了哪些主要限制？”
相应的处理流程如下：
Your Documents
↓
Extract Text
↓
Chunk Documents
↓
Create Embeddings
↓
Vector Database
↓
Question
↓
Semantic Search
↓
Relevant Sections
↓
LLM
↓
Answer
这正是RAG为何对研究工作流及企业级知识系统如此重要的原因。
实际应用中的RAG
这种模式广泛应用于各种系统中。
客户支持
Customer Question
↓
Product Documentation
↓
Retrieve Relevant Section
↓
AI
↓
Response
教育领域
Student Question
↓
Course Materials
↓
Relevant Concepts
↓
AI Tutor
↓
Explanation
研究工作
Research Question
↓
Research Papers
↓
Relevant Sections
↓
AI
↓
Summary
企业知识管理
Employee Question
↓
Internal Documents
↓
Retrieve Policy
↓
AI
↓
Answer
RAG无法完全消除幻觉现象
这一点值得重点强调。
你可能会认为：
“如果我使用RAG，AI就永远不会产生幻觉。”
这并不完全正确。
RAG可以减少某些缺乏依据的回答，但并不能彻底解决这个问题。
例如：
Bad Retrieval
↓
Wrong Context
↓
LLM
↓
Wrong Answer
还有其他几种可能出现问题的情况：
- 被分割后失去原有含义的文本片段
- 源材料中根本不存在的相关事实
- 检索到的内容实际上与问题无关
- 已经过时或不准确的文档
- 从一开始就存在错误或不匹配的源文件
- 在提示词中一次性塞入过多上下文
- 尽管输入数据良好，模型本身的推理仍出错
正因如此，一个完善的RAG系统需要的不仅仅是背后的向量数据库。
评估RAG系统
可以从多个不同层面来评估RAG流程。
检索质量
系统是否获取到了正确的信息？
Question
↓
Retrieved chunks
↓
Are they relevant?
生成质量
模型是否真正充分利用了检索到的信息？
Retrieved Context
↓
Generated Answer
↓
Is the answer supported?
端到端质量
整个流程综合起来能否正确回答用户的问题？
Question
↓
Retrieval
↓
Context
↓
Generation
↓
Final Answer
即便底层的大语言模型非常出色，系统也有可能出现故障。
例如：
如果检索到的文档有误，即使是非常强大的模型也可能会给出错误答案。
嵌入背后的数学原理
嵌入技术使得可以利用数学方法来比较各种信息。
一种广泛使用的相似度度量方法是余弦相似度。
对于两个向量A和B，余弦相似度的计算方式为A与B的点积除以它们模长的乘积。
所得数值可以表明这两个向量的方向有多接近。
简单来说：
High similarity
↓
Vectors point in similar directions
↓
Likely related meaning
这为RAG提供了一种具体的数学方法，用于查找与查询在语义上相关的信息。
RAG就像为AI提供图书馆
这或许是理解这一概念最清晰的方式。
把AI想象成一个能力很强的学生。
在没有RAG的情况下：
Student
↓
Uses what they already remember
↓
Answer
有了RAG之后：
Student
↓
Goes to library
↓
Finds relevant book
↓
Reads relevant pages
↓
Answers question
这个学生的基础知识与推理能力并没有改变。
发生变化的是该学生当时能够获取的信息。
本质上，这就是RAG背后的核心理念。
RAG 的发展前景
RAG 系统正日益变得更为复杂精密。
未来的实现方案可能会结合以下功能：
User Question
↓
Query Understanding
↓
Multiple Retrieval Sources
↓
Document Ranking
↓
Reasoning
↓
Tool Use
↓
Verification
↓
Answer + Evidence
系统不再仅从单一文档中获取信息，而是可以搜索多个来源：
PDFs
+
Database
+
Website
+
API
+
Company Knowledge Base
随后将这些相关内容整合在一起。
这使 RAG 朝着成为人工智能代理更广泛的知识与推理架构的方向发展，而不仅仅是一种检索技巧。
更宏观的视角
RAG 代表了我们在理解人工智能知识方式上的重要转变。
旧有的模式是：
Train AI
↓
Put knowledge into model
↓
Ask questions
新的方法则更类似于：
Train AI
↓
Keep knowledge externally
↓
Retrieve relevant information
↓
Reason over it
↓
Generate answer
以这种方式将模型智能与外部知识分离，被证明具有极强的效力。
模型不再需要将所有事实都存储在内部。
相反，它只需掌握如何在获取信息后有效利用这些信息即可。
最后的思考
也许人工智能的未来并不在于构建一个能记住所有已知知识的模型。
相反，它或许在于打造一种能够判断自己需要查询什么、找到合适的信息来源、有效利用这些资料，并验证答案是否正确的模型。
这正是RAG值得关注的原因。
AI Model
+
External Knowledge
+
Retrieval
+
Reasoning
+
Verification
↓
More Useful AI
这引出了一个更重要的观点：最聪明的人工智能未必是那个无所不知的，而是那些懂得如何找到所需信息的。
相关阅读
- Agentic AI Explained: From Language Models to Autonomous Agents — 详细介绍了大型语言模型如何通过工具、记忆机制、规划能力、多智能体架构以及MCP集成，逐步演变为具备自主能力的系统。