RAG是什么RAG 是 Retrieval-Augmented Generation，中文通常叫做检索增强生成。你可

RAG 是 Retrieval-Augmented Generation，中文通常叫做 检索增强生成。

RAG架构图.png

你可以把它理解成一句话：

先查资料，再让大模型回答。

它的核心目标，是解决大模型仅靠参数记忆回答问题时常见的几个问题：

容易产生幻觉，胡编乱造
不知道企业私有知识
知识可能过时
回答缺少依据和来源

一、RAG 到底是什么

传统大模型在回答问题时，主要依赖训练阶段学到的参数知识。

比如你问：

公司的报销规则是什么？
这个产品最新版本支持什么功能？
这份合同里第 8 条写了什么？

如果模型没有见过这些内容，或者知识已经过时，就可能答错，甚至一本正经地胡说。

而 RAG 的基本流程是：

用户提出问题
系统先去知识库中检索相关资料
将检索结果和问题一起发送给大模型
大模型基于这些资料生成答案

所以，RAG 不是让模型“凭空回答”，而是让模型进行：

开卷考试

二、RAG 这个名字怎么理解

1. Retrieval（检索）

从外部知识库中查找与问题相关的信息。

知识库的来源可以包括：

PDF
Word
Excel
数据库
企业文档
FAQ
网页
API 返回数据
向量库

2. Augmented（增强）

把检索到的信息补充到提示词中，增强模型上下文。

也就是把“相关资料”喂给模型。

3. Generation（生成）

模型根据：

用户问题
检索结果
提示规则

生成最终答案。

三、为什么需要 RAG

1. 解决幻觉问题

模型有时会“一本正经地胡说八道”。
RAG 给模型提供外部依据后，回答通常会更稳。

2. 接入私有知识

大模型并不知道你公司的内部制度、业务数据、知识文档。
RAG 可以把这些私有数据接进来。

3. 降低训练成本

很多场景并不需要重新微调模型，只需要把文档做成知识库即可。

4. 方便知识更新

当制度、产品文档、流程规则变化时，只需要更新知识库，不需要重新训练模型。

四、RAG 的标准流程

一个典型的 RAG 系统，通常可以拆成以下几个步骤。

第一步：准备知识

先把文档、数据库内容、网页内容等收集起来，例如：

产品说明书
接口文档
售后问答
公司制度
合同模板

第二步：切块（Chunking）

由于大模型无法一次处理无限长文本，所以需要把文档切成较小的片段。

常见切法：

每段 300～800 字
按标题切分
按段落切分
按语义切分

这一环节非常关键。

切得太大：

检索不精准

切得太小：

上下文容易丢失

第三步：向量化（Embedding）

把每个文本块转换为向量。

你可以把向量理解成“文本语义坐标”。
这样即使两句话字面不同，只要语义相近，向量也会比较接近。

例如：

“怎么退款”
“退款流程是什么”

虽然字不同，但语义接近，所以向量距离也接近。

第四步：存储到向量库

把文本块及其向量存储起来。

常见向量库包括：

Milvus
pgvector
Elasticsearch
Weaviate
Pinecone
Chroma

第五步：用户提问并向量化

用户输入问题后，也会把问题转换成向量。

第六步：相似度检索

拿“问题向量”去向量库中检索最相近的文本块。

常见做法是返回：

Top 3
Top 5
Top 10

第七步：重排序（可选）

初步检索到的结果不一定最优，因此通常会再用 Reranker 做一次更精细的排序。

第八步：拼装 Prompt

把以下内容拼成提示词：

用户问题
检索出的知识片段
回答规则

第九步：模型生成答案

大模型基于这些外部资料，生成最终回答。

五、RAG 的核心组成

一个完整的 RAG 系统，通常包含以下模块：

1. 数据源

知识内容的来源。

2. 文档解析

把 PDF、Word、网页等解析成可处理文本。

3. 文本切块

将长文拆成适合检索的片段。

4. Embedding 模型

负责把文本转换成向量。

5. 向量数据库

负责存储向量并执行相似度检索。

6. 检索器（Retriever）

根据问题找到相关片段。

7. 重排器（Reranker）

对召回结果做更精准排序。

8. 大语言模型（LLM）

负责最终生成自然语言答案。

9. Prompt 模板

约束模型如何使用检索内容进行回答。

六、RAG 和微调的区别

很多人容易把 RAG 和 Fine-tuning（微调） 混淆。

RAG

RAG 是把知识放在 模型外部。

特点：

更新快
成本低
适合知识问答
易接入私有文档
可以给出引用依据

微调

微调是把知识或行为“写进模型参数”中。

特点：

更适合固定风格、固定任务
训练成本更高
更新知识不灵活
不适合频繁变化的知识库

一句话区分

RAG：让模型查资料
微调：让模型改脑子

实际项目中常见的分工是：

RAG 负责知识
微调负责风格、格式和任务能力

七、RAG 的常见类型

1. Naive RAG（基础版）

最简单的做法：

切块
向量检索
拼 Prompt
模型生成

优点：

简单
上手快

缺点：

效果一般
容易检索不准

2. Advanced RAG（增强版）

在基础版上增加优化能力，例如：

更合理的切块
混合检索
重排序
查询改写
多路召回
去重与过滤

3. Agentic RAG（智能体式 RAG）

不仅仅检索一次，而是让系统自己判断：

要不要检索
检索什么
是否继续检索
是否调用数据库或 API
是否进行多步推理

这类系统能力更强，但工程复杂度也更高。

八、RAG 中最关键的几个点

1. 切块质量

切块不合理，后面基本都白做。

例如，一条完整规则被切成两半，模型拿到不完整内容，就容易回答错误。

2. 检索质量

如果检索不到正确资料，模型再强也没用。

因此通常需要做：

关键词检索 + 向量检索混合
Query 改写
同义词扩展
Metadata 过滤

3. 上下文拼接质量

不是把所有结果一股脑塞进去就好。
要注意：

去重
控制长度
保留最相关内容
给模型明确使用规则

4. 提示词约束

例如明确要求模型：

只能基于提供的资料回答
如果资料不足，要明确说不知道
优先引用原文
不要编造

这能显著降低幻觉。

九、RAG 的常见优化手段

1. Hybrid Search（混合检索）

把以下两种方式结合起来：

向量检索
关键词检索

原因是：

向量检索擅长找语义相近内容
关键词检索擅长找精确术语

两者结合，通常效果更好。

2. Rerank（重排序）

先粗召回 20 条，再从中选出最相关的 3～5 条交给模型。

3. Query Rewrite（问题改写）

当用户问题很口语化时，先改写成更适合检索的形式。

例如：

原问题：

这个能退吗？

改写后：

该商品订单在什么条件下支持退款？

4. Metadata Filter（元数据过滤）

可以基于元数据做筛选，例如：

文档类型
时间范围
部门
产品线
租户 ID

5. Parent-Child Chunk

子块负责检索精度
父块负责提供更完整上下文

这样既能检得准，又能保留完整语境。

6. 多路召回

从多个知识源同时检索，例如：

FAQ
产品文档
数据库
工单历史

然后再进行融合。

十、RAG 的典型应用场景

企业知识库问答

例如：

报销制度
人事政策
技术文档查询

客服机器人

例如：

退款规则
物流问题
商品使用说明

法务 / 合同问答

例如：

合同某条款内容
违约责任说明

医疗 / 金融辅助问答

这类场景通常需要更强的审计和合规控制。

开发助手

例如：

查询接口文档
查询代码规范
查询系统设计说明

数据问答

结合数据库、BI、SQL 生成能力，做智能分析问答。

十一、RAG 的优点

1. 知识可更新

文档更新即可，不必重训模型。

2. 更适合私域场景

尤其适合企业内部知识库。

3. 成本更低

相比微调，整体更轻量。

4. 可解释性更强

可以给出“答案依据了哪些文档片段”。

5. 上线速度快

知识库准备完成后，就可以快速验证效果。

十二、RAG 的缺点和难点

1. 检索不到就答不好

典型问题就是：

Garbage in, garbage out

2. 文档解析复杂

PDF、扫描件、表格、图片等都会影响效果。

3. 切块非常考验经验

目前并没有一套对所有场景都适用的万能方案。

4. 长文档容易丢上下文

尤其是跨段落、跨章节的问题。

5. 不能天然保证 100% 正确

RAG 只是降低幻觉，并不能彻底消灭错误。

6. 工程链路更复杂

不仅仅有模型，还需要：

文档处理
向量化
检索
排序
缓存
监控

十三、一个简单的 RAG 例子

假设你在做一个公司制度问答机器人。

用户提问：

年假最多可以连续请几天？

系统内部流程如下：

去员工手册中检索“年假、连续请假、假期规定”等相关内容
找到相关片段，例如：

“员工年假原则上可连续申请，连续休假超过 5 个工作日需部门负责人审批……”
把这个片段和问题一起发给模型
模型生成答案：

“根据提供的制度，年假可以连续申请；若连续休假超过 5 个工作日，需要部门负责人审批。”

这就是一个典型的 RAG 场景。

十四、RAG 和普通搜索的区别

普通搜索通常只是返回一组文档列表。

而 RAG 不一样，它是：

先搜索资料
再结合资料直接生成答案

所以它更像是：

带参考资料的智能回答

十五、RAG 和数据库查询的区别

数据库查询更适合返回 结构化数据。

RAG 更适合处理：

非结构化文档
自然语言问答
多文档综合归纳

很多企业系统会把两者结合起来：

结构化数据 走 SQL / API
非结构化知识 走 RAG

这通常才是更完整的企业智能问答方案。

十六、做 RAG 时的常见误区

1. 以为只要上向量库就行

不是。真正困难的地方通常在于：

数据清洗
切块
召回
Prompt 设计

2. 以为模型越大效果一定越好

如果检索错了，再大的模型也会答偏。

3. 以为 RAG 可以替代所有微调

不能。
行为控制、格式稳定输出、特定任务能力等方面，微调依然很重要。

4. 以为知识库越大越好

知识越杂，噪音越多，检索效果反而可能变差。

十七、RAG 的本质

RAG 的本质，就是给大模型外挂一个“可检索的外部知识系统”，让它回答时不是只靠记忆，而是边查边答。

从系统层面看，一个完整的 RAG 通常分成两大部分：

十八、离线建库链路

这一部分负责把知识“准备好”。

流程

数据源 → 文档采集 → 文本解析清洗 → 切块 → 元数据抽取 → 向量化 → 入库

这里最重要的 4 个点

1. 文档解析

把 PDF、Word、网页、数据库内容转成可处理的文本。
如果是扫描件，还可能需要 OCR。

2. 切块

把长文本拆成适合检索的小块。

常见做法包括：

固定字数切块
按标题 / 段落切块
Parent-Child 切块
滑动窗口切块

3. 元数据

每个 Chunk 最好附带元信息，例如：

文档名
来源
时间
部门
产品线
权限范围

这样检索时可以进行精确过滤。

4. 向量化与索引

同一份内容，通常会同时进入：

向量库：负责语义检索
关键词索引：负责 BM25 / 精准术语命中
元数据库：负责业务属性和权限控制

十九、在线问答链路

这一部分负责真正回答用户问题。

流程

用户提问 → Query 预处理 → 检索路由 → 混合召回 → 重排序 → 上下文构建 → Prompt 组装 → LLM 生成 → 后处理 → 返回答案

二十、真正影响效果的关键点

完整架构有了，并不代表效果一定好。
RAG 最容易出问题的地方，通常集中在以下几个方面。

1. 切块不合理

切太碎，语义断裂
切太大，检索不准

2. 检索策略过于单一

如果只用向量检索，很容易漏掉专业术语。
因此很多项目会加入 BM25 混合召回。

3. 没有重排序

粗召回回来的内容中常常有很多噪音，若不做 rerank，效果通常会明显下降。

4. 上下文拼接太乱

不是把 Top5 全塞进去就结束了。
还需要：

控制长度
去重
提取关键片段
保留上下文完整性

5. 没有权限隔离

在企业知识库中，这是非常关键的问题。
不同用户必须只能看到自己有权限访问的内容。

6. 没有评估体系

如果没有监控：

召回是否正确
答案是否有依据
哪个环节出了问题

那么后续就很难持续优化。

二十一、一句话总结

RAG = 检索系统 + 外部知识 + 大模型生成。

它不是让模型“更会背”，而是让模型“更会查”。

所以，RAG 最核心的价值并不只是“接一个向量库”，而是：

让大模型在回答时拥有可用、可控、可更新、可追溯的外部知识能力。