第 2 篇：RAG 核心原理拆解——全流程、核心组件与基础逻辑

本文为「从零到落地：RAG 检索增强生成实战系列」第 2 篇，完整系列持续更新中。

前言

本篇拆解 RAG 的完整运行逻辑，用流程图和类比讲透每个核心组件的作用，不堆砌晦涩术语，看完你就能画出 RAG 的完整数据流。

你用过 ChatGPT、Kimi 这类大模型对话工具，大概率遇到过这些情况：问它一个公司内部的产品细节，它一本正经地胡说八道；问它最新的政策变化，它还在用去年的信息回答；问它你的私有文档内容，它直接告诉你”我没有这方面的信息”。

这三个问题的本质是一样的——大模型的知识是训练时固定的，它不知道你公司内部的事，也不知道训练截止日期之后发生的事。

RAG（Retrieval-Augmented Generation，检索增强生成）就是为了解决这些问题而生的。核心思路很直接：先帮你去知识库里查到相关内容，再把这些内容喂给大模型，让它基于真实资料来回答。

本篇学完你将掌握：

  • 传统大模型的三大核心痛点及其根因
  • RAG 的两大核心流程：索引阶段和推理阶段的完整数据流
  • 六大核心组件的作用：文档解析器、分块器、Embedding 模型、向量数据库、LLM、Prompt
  • 基础 RAG 的优势和现存问题（为后续增强篇埋伏笔）

一、传统大模型的痛点

在讲 RAG 之前，先搞清楚我们到底要解决什么问题。大模型有三个在落地场景中绕不开的硬伤。

1.1 幻觉问题

大模型会编造看起来合理但完全错误的内容。这不是 bug，而是大模型的生成机制决定的——它本质上是在做”下一个词的概率预测”，当它没有足够信息时，依然会按照语言规律”编”出一个通顺的回答。

举个例子：你问”你们公司的 A 产品支持哪些协议？”，大模型可能回答”支持 TCP、UDP 和 HTTP”——听起来很专业，但如果你的产品实际上只支持 Modbus 和 OPC UA，这个回答就完全是幻觉。

面试模板：大模型幻觉（Hallucination）是指模型生成看似合理但事实错误的内容。根因是模型基于统计概率生成文本，而非基于事实检索。RAG 通过引入外部知识源，让模型的回答有据可查，是目前缓解幻觉最主流的工程方案。

1.2 知识滞后

大模型的知识截止于训练数据的时间点。GPT-4o 的训练数据截止到 2023 年 10 月，你问它 2024 年的事，它要么不知道，要么瞎编。

对于企业场景这个问题更严重：你的产品手册上周刚更新、你的公司制度今天才发布——大模型不可能知道这些。

1.3 无法使用私有数据

大模型是在公开互联网数据上训练的，你公司的内部文档、产品手册、客户资料、会议纪要，它一概不知。而且你不可能把这些敏感数据拿去训练一个模型——成本高、周期长、数据泄露风险大。

1.4 三种传统应对方案的局限

面对这些问题，在 RAG 之前常见的做法有三种：

方案 做法 问题
微调（Fine-tuning） 用私有数据继续训练模型 成本高、周期长，知识更新要重新训练
长上下文（Long Context） 把所有资料塞进 Prompt Token 有限，成本高，信息太多反而”迷路”
提示工程（Prompt Engineering） 在 Prompt 里手动贴资料 手动操作不可扩展，适合一次性任务

这三种方案各有适用场景，但对于**”让大模型基于大量私有数据准确回答问题”**这个需求，都不够好。RAG 就是目前最优的工程解法。

二、RAG 整体架构

RAG 的全流程分为两大阶段：索引阶段（提前把知识准备好）和推理阶段（用户提问时去查资料、生成回答）。

用一个类比来理解：想象你开了一家咨询公司，索引阶段就是建档案室——把各种资料整理好、分类、编号、放进文件柜；推理阶段就是接到客户问题后，先去档案室查相关资料，再基于资料给客户写回复。

1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────────────────────────┐
│                     索引阶段（离线）                       │
│                                                         │
│  文档加载 → 文本分块 → 向量化（Embedding） → 存入向量数据库  │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                     推理阶段（在线）                       │
│                                                         │
│  用户提问 → Query 向量化 → 相似检索 → 拼接上下文 → LLM 生成  │
└─────────────────────────────────────────────────────────┘

💡 提示：索引阶段是一次性的离线操作（文档更新时重新执行），推理阶段是每次用户提问都会触发的在线操作。

下面逐个拆解每个环节和核心组件。

三、索引阶段：把知识”存”进向量数据库

索引阶段的任务是：把你的文档变成向量，存进向量数据库，等待被检索。整个流程分四步。

3.1 文档加载

做什么：把各种格式的原始文档读进来，提取出纯文本内容。

你的知识可能散落在不同格式里：PDF 产品手册、Word 合同、Markdown 技术文档、网页 FAQ、Excel 表格……文档加载器的作用就是把这些格式统一转换成纯文本。

文档格式 常用加载工具 说明
PDF PyPDF、Unstructured、MinerU PDF 最复杂，可能包含表格、图片、多栏排版
Word（.docx） python-docx、Unstructured 相对规范，提取正文和表格
Markdown 直接读取 最简单，纯文本格式
HTML BeautifulSoup、Trafilatura 需要去除 HTML 标签，提取正文
Excel pandas、openpyxl 通常按行转成文本记录

💡 提示：PDF 解析是 RAG 领域公认的难点。扫描件（图片型 PDF）需要 OCR，排版复杂的 PDF（多栏、表格、公式）需要布局分析模型。这也是 RAGFlow 等一体化套件重点优化的方向。

3.2 文本分块（Chunking）

做什么：把长文档切成一段一段的小块（Chunk），每块几百到上千个 Token。

为什么要分块？两个原因：

  1. Embedding 模型有输入长度限制——大多数 Embedding 模型最多处理 512 或 1024 个 Token，超长文本必须切开
  2. 检索精度需要——如果整篇文档作为一个整体，检索时只能判断”这篇文档大概相关”；切成小块后，可以精准定位到”这段内容最相关”

常见的分块策略：

分块策略 做法 适用场景
固定长度分块 每 500 Token 切一刀，相邻块之间留 50-100 Token 重叠 通用场景，实现最简单
语义分块 根据语义边界（段落、句子）切分 文档结构清晰时效果更好
递归分块 先按大标题切，再按小标题切，层层递进 有清晰层级结构的文档
文档结构分块 按 Markdown 标题、HTML 标签等文档结构切分 结构化文档（技术文档、Wiki）

💡 提示：分块策略对 RAG 的检索效果影响极大——块太大，检索精度下降；块太小，上下文不完整。这是后续第 9 篇优化进阶会重点展开的话题。基础 RAG 一般用固定长度分块 + 重叠（Overlap）就够了。

3.3 向量化（Embedding）

做什么：把每个文本块转成一个高维向量（一串浮点数），这个向量就是这段文本的”语义指纹”。

这是 RAG 里最关键的一步。Embedding 模型的作用是把人类语言”翻译”成计算机能理解的数字表示。核心特性是：语义相近的文本，向量在空间中的距离近；语义无关的文本，向量距离远。

举个例子：

1
2
3
文本 A："公司年假制度是入职满一年后 5 天"
文本 B："员工入职满 12 个月后可享受 5 天带薪年假"
文本 C："公司的服务器部署在阿里云华东区"

A 和 B 说的是同一件事（虽然措辞不同），它们的向量距离很近；C 是完全不相关的话题，向量距离很远。这就是为什么向量检索能比关键词搜索更”懂”语义——关键词搜索看到”年假”和”带薪年假”会认为是不同的词，但向量检索知道它们是一回事。

Embedding 模型 来源 维度 中文支持 说明
bge-large-zh-v1.5 智源 BAAI 1024 优秀 中文开源首选，性价比高
text-embedding-3-small OpenAI 1536 良好 API 调用，开箱即用
m3e-base Moka AI 768 优秀 轻量级中文模型
jina-embeddings-v3 Jina AI 1024 良好 支持多语言，可本地部署

💡 建议：中文场景优先选 bge-large-zh-v1.5，开源免费、效果优秀、可本地部署。如果对精度要求不高且想省事，用 OpenAI 的 text-embedding-3-small API 最方便。

3.4 存入向量数据库

做什么：把所有文本块的向量和原文一起存进向量数据库，建立索引。

向量数据库就是专门为存储和检索高维向量设计的数据库。它和传统数据库的区别在于：传统数据库擅长精确匹配（WHERE name = '张三'），向量数据库擅长相似性搜索（找到和查询向量最接近的 Top-K 个向量）。

向量数据库 类型 适用场景 特点
Chroma 轻量嵌入式 学习、原型开发 纯 Python，零配置启动
FAISS 本地库 学习、中小规模 Meta 开源，速度极快，不支持分布式
Milvus 独立服务 生产环境、大规模 支持分布式，亿级向量
Qdrant 独立服务 生产环境 Rust 编写，性能好，支持丰富的过滤条件
Elasticsearch 搜索引擎 混合检索场景 同时支持向量检索和全文检索

💡 提示：入门学习用 Chroma 或 FAISS（本地跑、不需要额外部署），生产环境用 Milvus 或 Qdrant（支持大规模数据和并发）。

存储时每个向量通常会附带元数据（Metadata），比如来源文件名、页码、章节标题等，方便后续过滤和溯源。

四、推理阶段：用户提问时的完整流程

索引阶段完成后，向量数据库里已经存好了所有文档的”语义指纹”。当用户提问时，进入推理阶段——整个流程分五步。

4.1 用户提问与 Query 向量化

做什么：把用户的问题转成向量，用于后续检索。

用户输入的是一个自然语言问题，比如：”公司的年假制度是什么？”。和文档分块一样，这个问题也需要通过同一个 Embedding 模型转成向量——只有用同一个模型，查询向量和文档向量才在同一个语义空间里，距离才有意义。

⚠️ 注意：Query 和文档必须使用同一个 Embedding 模型。如果文档用 bge-large-zh 向量化，查询时用 text-embedding-3-small，两个向量空间不一致，检索结果会完全失效。

4.2 相似性检索（Retrieval）

做什么：在向量数据库中，找到和用户问题最相似的 Top-K 个文本块。

向量数据库会计算查询向量和所有文档向量之间的距离（通常用余弦相似度），返回最接近的 K 个结果。

1
2
3
4
5
6
7
8
9
10
11
用户问题："公司年假几天？"
    ↓ Embedding
查询向量: [0.12, -0.34, 0.56, ...] (1024维)
    ↓ 向量检索（余弦相似度）

Top-3 检索结果：
┌────────────────────────────────────────────────────────┐
│ [相似度 0.92] "入职满一年后享受5天带薪年假，满三年后8天"   │
│ [相似度 0.85] "年假需提前3天在OA系统提交申请"            │
│ [相似度 0.71] "实习生不享受年假，转正后按入职时间计算"     │
└────────────────────────────────────────────────────────┘

Top-K 的值一般设为 3~10。K 太小可能漏掉关键信息，K 太大会引入不相关内容、浪费 Token。

4.3 拼接上下文（Context Assembly）

做什么：把检索到的文本块拼接成一段完整的上下文，和用户的原始问题一起组装成 Prompt。

这一步看起来简单，但它是 RAG 的核心——把”外部知识”注入到大模型的输入中。

典型的 Prompt 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
你是一个专业的企业知识库助手。请根据以下参考资料回答用户的问题。
如果参考资料中没有相关信息，请明确告知用户你不确定，不要编造答案。

## 参考资料
{检索到的文本块1}
{检索到的文本块2}
{检索到的文本块3}

## 用户问题
{用户的原始问题}

## 回答要求
1. 基于参考资料回答，不要编造
2. 如果资料不足，告知用户需要补充信息
3. 回答简洁、准确

💡 提示：Prompt 里的约束指令（如”不要编造””资料不足时告知用户”）是缓解幻觉的关键手段。基础 RAG 通常用上述模板，后续第 9 篇会讲更高级的 Prompt 策略。

4.4 大模型生成回答（Generation）

做什么：把组装好的 Prompt 发给 LLM，获取最终回答。

LLM 收到 Prompt 后，会基于参考资料中的信息来生成回答。因为参考资料已经限定了范围，大模型的回答就有了事实依据——这就是”检索增强生成”的”增强”所在。

LLM 的选型分两大类：

方式 代表 优势 劣势
API 调用 DeepSeek、GPT-4o、Qwen-Max 开箱即用，效果好 数据经过第三方，按量计费
本地部署 Ollama + Qwen2.5、vLLM + Llama 数据不出网，无持续费用 需要 GPU 服务器，运维成本

💡 建议：对数据隐私无特殊要求的场景，API 调用最省事，DeepSeek 性价比最高；涉密场景用 Ollama + Qwen2.5 本地部署，后续第 4 篇会手把手演示。

五、六大核心组件速查

回顾整个流程，RAG 系统由六个核心组件构成。每个组件的质量都直接影响最终效果：

组件 作用 影响什么 基础 RAG 常用选择
文档解析器 把各种格式文档转成纯文本 数据质量（解析错了后面全错） PyPDF、Unstructured
分块器 把长文本切成小块 检索精度和上下文完整性 固定长度 + 重叠
Embedding 模型 把文本转成语义向量 检索的语义理解能力 bge-large-zh-v1.5
向量数据库 存储和检索向量 检索速度和规模 Chroma（入门）/ Milvus（生产）
LLM 基于上下文生成回答 回答质量、速度、成本 DeepSeek API / Ollama + Qwen2.5
Prompt 模板 组装查询、约束生成行为 幻觉率、回答格式 带约束指令的标准模板

核心价值：理解这六个组件的关系，后面不管用 Dify、LangGraph、LlamaIndex 还是 RAGFlow，你都知道每个配置项在调什么、为什么这么调。

六、基础 RAG 的完整数据流

把上面的全流程串起来，一张完整的数据流图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
┌─── 索引阶段（离线，一次性） ───┐
│                                │
│  PDF/Word/MD    ┌──────────┐    │
│  ──────────→   │ 文档解析器 │    │
│                └────┬─────┘    │
│                     ↓          │
│              ┌──────────┐      │
│              │  分块器   │      │
│              └────┬─────┘      │
│                   ↓            │
│            ┌──────────────┐    │
│            │ Embedding 模型 │    │
│            └──────┬───────┘    │
│                   ↓            │
│           ┌──────────────┐     │
│           │  向量数据库    │     │
│           └──────────────┘     │
└────────────────────────────────┘

┌─── 推理阶段（在线，每次提问） ───┐
│                                 │
│  用户提问                        │
│    ↓                            │
│  Embedding 模型（同一个）         │
│    ↓                            │
│  向量数据库检索 Top-K             │
│    ↓                            │
│  拼接 Prompt（上下文 + 问题）     │
│    ↓                            │
│  LLM 生成回答                    │
│    ↓                            │
│  返回给用户                      │
└─────────────────────────────────┘

七、基础 RAG 的优势与现存问题

7.1 核心优势

优势 说明
缓解幻觉 回答基于检索到的真实资料，不是凭空编造
知识实时更新 只需更新向量数据库中的文档，不用重新训练模型
私有数据可用 企业内部文档直接入库，数据不出网
成本可控 比微调便宜得多，更新知识只需重新索引
可溯源 能追溯回答来自哪个文档的哪个段落

7.2 现存问题（后续优化方向）

基础 RAG 能跑通流程，但在实际使用中会暴露不少问题。这些问题在第 9 篇「全链路增强技术」中会逐个解决，这里先列出来让你有个全局认知：

问题 表现 根因 后续增强方向
检索不准 查到的内容和提问关系不大 分块不合理、Embedding 模型能力有限、无重排 Query 改写、Rerank、分块优化
上下文不完整 关键信息被切到相邻块里，检索到的内容断章取义 固定分块破坏语义完整性 语义分块、窗口扩展
回答有冗余 LLM 把不相关的检索内容也写进回答 检索结果未过滤，Top-K 中混入噪声 上下文压缩、摘要过滤
多轮对话混乱 连续追问时上下文丢失、回答前后矛盾 无对话记忆管理 记忆管理、多轮对话策略
长文档效果差 答案分散在文档多处，单次检索凑不齐 Top-K 检索的覆盖范围有限 多路检索、Map-Reduce 策略

💡 提示：基础 RAG 就像一个”能用但不完美”的初版产品。跑通流程是第一步，后面 5 篇实战文章会基于不同框架实现基础 RAG，第 9 篇再集中解决这些优化问题。

踩坑记录：Embedding 模型不一致导致检索完全失效

现象：

用 text-embedding-3-small 索引文档，查询时用 bge-large-zh-v1.5 生成查询向量，检索结果完全随机，相似度分数极低（0.1 以下），回答全是”抱歉，没有找到相关信息”。

原因：

不同 Embedding 模型的向量维度不同（1536 vs 1024），向量空间也完全不同。即使维度相同，两个模型训练出来的向量空间也不互通。查询向量和文档向量不在同一个语义空间里，距离计算没有意义。

解决方案：

确保索引和查询使用完全相同的 Embedding 模型。在代码中统一配置：

1
2
3
4
5
6
7
8
# ✅ 正确做法：统一使用同一个 Embedding 模型
EMBEDDING_MODEL = "BAAI/bge-large-zh-v1.5"

# 索引阶段
doc_embeddings = embed(documents, model=EMBEDDING_MODEL)

# 推理阶段
query_embedding = embed(user_query, model=EMBEDDING_MODEL)

避坑建议：

在项目初期就确定 Embedding 模型，中途更换模型需要对所有文档重新索引。建议用一个配置文件或常量统一管理模型名称，避免在代码不同位置写死不同的模型。

总结与回顾

知识点 关键要点
大模型三大痛点 幻觉、知识滞后、无法使用私有数据
RAG 核心思路 先检索相关资料，再让 LLM 基于资料回答
索引阶段 文档加载 → 文本分块 → 向量化 → 存入向量数据库
推理阶段 提问 → Query 向量化 → 相似检索 → 拼接 Prompt → LLM 生成
六大核心组件 文档解析器、分块器、Embedding 模型、向量数据库、LLM、Prompt 模板
基础 RAG 优势 缓解幻觉、知识实时更新、私有数据可用、成本低、可溯源
基础 RAG 问题 检索不准、上下文不完整、回答冗余、多轮混乱（后续优化篇解决）

下篇预告

第 3 篇：RAG 主流搭建方案与技术选型 —— 深度对比四大搭建模式（低代码平台 / 代码框架自研 / 云端 SaaS / 私有化套件），给出按场景推荐的选型决策表，帮你确定“我该用什么方案来做 RAG”。

本文为「从零到落地：RAG 检索增强生成实战系列」第 2 篇，完整系列持续更新中。