上一篇文章，我们完成了本地大模型系列中非常重要的一步：

让本地大模型提供 API。

从此以后，你的模型不再只是一个可以聊天的软件，而可以被 Python、VS Code、Web 应用以及各种 AI 工具调用。

但是很快，你会发现一个新的问题：

本地大模型虽然已经运行在自己的电脑上，但它并不知道你的文件。

你的电脑里可能有：

• 几百份 PDF
• Word 文档
• Markdown 笔记
• 学习资料
• 公司内部文档
• 项目代码
• 产品说明书
• 个人知识库

你问模型：

“根据我电脑里的这些资料，帮我总结一下。”

它很可能会回答：

“请提供相关资料。”

这时候，很多人第一次听到一个词：

RAG

那么，RAG到底是什么？

为什么现在很多 AI 知识库都在使用 RAG？

本地大模型又是如何通过 RAG“读取”你的私人资料的？

今天，我们把这些问题一次讲清楚。

一、先理解一个最简单的问题

假设你电脑里有一本：

《公司产品技术手册.pdf》

里面有几百页内容。

你打开本地大模型，然后问：

“这个产品支持哪些部署方式？”

模型为什么不知道？

因为：

模型的知识和你的文件是两回事。

模型本身拥有训练阶段形成的知识。

而你的 PDF 是后来才出现在电脑里的。

所以：

大模型↓知道训练数据中的知识你的PDF↓属于外部数据

两者之间没有天然连接。

我们需要建立一条通道：

你的文件↓知识库↓检索↓本地大模型↓回答

这就是 RAG 的核心思想。

二、RAG到底是什么？

RAG 是：

Retrieval-Augmented Generation

中文通常翻译为：

检索增强生成。

这个名字看起来很专业，但实际上可以拆成两个动作：

Retrieval：检索

Generation：生成

也就是说：

先从你的资料中找到相关内容，再让大模型根据这些内容生成答案。

因此，RAG并不是重新训练一个模型。

而是在模型回答问题之前：

先给它找资料。

三、用一个例子理解RAG

假设你的电脑里有：

资料/├── 产品手册.pdf├── 用户指南.pdf├── 技术文档.pdf├── 常见问题.docx└── 项目说明.md

现在你问：

“这个产品如何部署到 Linux？”

RAG系统会做什么？

第一步：

理解你的问题。

第二步：

去知识库里搜索。

第三步：

找到与“Linux部署”相关的内容。

第四步：

把这些内容交给大模型。

第五步：

大模型根据这些内容回答。

最终：

用户问题↓检索知识库↓找到相关资料↓发送给大模型↓生成答案

这就是最基本的 RAG。

四、RAG和“把PDF上传给AI”有什么区别？

很多人会问：

“我直接把PDF上传给AI不就行了吗？”

对于单个文件、短期任务来说，当然可以。

但如果你有：

100份PDF

500份Word

几千篇Markdown

甚至几十万份文档，

每次都把所有文件上传给模型显然不现实。

RAG解决的是：

长期、批量、自动化地从大量资料中检索信息。

因此：

上传文件更像是：

临时给AI一本书。

RAG更像是：

给AI建立一个图书馆，并且配一个检索系统。

五、RAG最核心的工作流程

一个完整的 RAG 系统通常可以分成两个阶段。

第一阶段：建立知识库

PDF / Word / Markdown        ↓     文档解析        ↓      文本切分        ↓      向量化        ↓    存入向量数据库

第二阶段：用户提问

用户问题   ↓问题向量化   ↓搜索相关内容   ↓找到相关文档片段   ↓组合Prompt   ↓本地大模型   ↓生成答案

这两个阶段一定要分开理解。

六、第一步：读取文档

RAG首先要解决的问题非常简单：

怎么把PDF、Word等文件变成文本？

例如：

产品说明书.pdf        ↓PDF解析器        ↓纯文本

Word：

技术文档.docx        ↓DOCX解析器        ↓纯文本

Markdown：

README.md        ↓直接读取        ↓文本

所以RAG并不是直接“理解PDF”。

它首先需要：

把PDF里的内容提取出来。

七、为什么不能直接把整本PDF塞给模型？

因为模型存在：

上下文窗口限制。

假设一本PDF有：

500页。

里面可能有几十万甚至更多 Token。

如果每次提问都把整个PDF发送给模型：

PDF↓全部文本↓大模型

不仅浪费资源，而且成本和速度都会变得非常不理想。

所以RAG通常不会把整个文档都交给模型。

而是：

只找到最相关的一小部分。

这就引出了RAG最重要的技术之一：

文本切分。

八、什么是文本切分？

假设一本书有10万字。

我们不能把它作为一个整体存储。

通常会把它切成很多小片段：

文档↓Chunk 1Chunk 2Chunk 3Chunk 4……Chunk 500

每一个 Chunk 都是一个独立的文本片段。

例如：

Chunk 1：第一章 产品介绍……Chunk 2：第二章 安装要求……Chunk 3：第三章 Linux部署……Chunk 4：第四章 Windows部署……

当用户问：

“Linux怎么部署？”

系统就可以优先找到：

Chunk 3。

而不是把整个文档交给模型。

九、Chunk为什么不能切得太大？

如果一个 Chunk 太大：

Chunk↓包含大量无关内容

检索时容易把很多无关信息一起带回来。

模型需要处理更多内容。

效率会下降。

十、Chunk也不能切得太小

如果切得太碎：

一句话↓一个Chunk

那么上下文可能不完整。

例如：

Chunk 1：安装系统后，Chunk 2：需要配置环境变量。Chunk 3：然后重新启动服务。

单独检索 Chunk 2：

“需要配置环境变量。”

模型可能不知道：

配置什么？为什么配置？

所以：

RAG的文本切分并不是越大越好，也不是越小越好。

而是要尽量保持：

语义完整。

十一、什么是Embedding？

这是RAG中最关键的概念之一。

Embedding中文一般称为：

嵌入 / 向量表示。

听起来很复杂。

其实可以简单理解：

把文字转换成一组数字。

例如：

“苹果手机如何充电”

经过Embedding模型处理以后，可以变成类似：

[0.12, -0.31, 0.87, ...]

当然，实际向量通常拥有更多维度。

它的真正意义不是：

把文字变成数字这么简单。

而是：

让语义相近的文本，在向量空间中更加接近。

十二、为什么需要Embedding？

假设知识库中有：

“设备支持USB-C快速充电。”

用户问：

“这个设备能不能快充？”

虽然两个句子的字面完全不同：

USB-C快速充电

和：

能不能快充

但它们表达的意思非常接近。

Embedding可以帮助系统发现这种：

语义相似性。

于是：

用户问题↓Embedding↓向量↓搜索相似向量↓找到相关文档

这就是向量检索。

十三、什么是向量数据库？

既然我们已经把所有文本转换成向量：

Chunk 1 → 向量Chunk 2 → 向量Chunk 3 → 向量……

那么这些向量需要存在哪里？

这时候就需要：

向量数据库。

常见的向量数据库或相关方案包括：

Chroma

FAISS

Milvus

Qdrant

pgvector

等等。

它们的核心工作之一就是：

帮助我们快速找到与用户问题最相似的文本。

十四、RAG完整架构终于出现了

现在把前面的内容全部连接起来：

PDF / Word / Markdown          ↓       文档解析          ↓        文本切分          ↓       Embedding          ↓      向量数据库          ↓       用户提问          ↓       问题Embedding          ↓       相似度检索          ↓     找到相关文本          ↓      组合上下文          ↓      本地大模型          ↓        最终答案

这就是一个典型的 RAG 系统。

十五、RAG并没有“教会”模型新知识

这是非常重要的一点。

很多人会误以为：

“我把公司的资料放进RAG以后，大模型就学会这些资料了。”

其实不是。

RAG和训练、微调是不同概念。

RAG更接近：

考试时给模型发了一份参考资料。

模型本身没有永久记住。

而是：

回答问题的时候查资料。

十六、RAG和微调有什么区别？

可以这样理解：

RAG：

让模型“查资料”。

微调：

让模型“改变行为”。

例如：

你希望模型知道公司内部最新产品参数。

优先考虑：

RAG。

因为产品参数未来还会变化。

而如果你希望模型：

始终采用某种语气

按照固定格式输出

学习某种特定任务模式

那么：

微调可能更合适。

所以：

知识更新问题，通常优先考虑RAG；行为和能力适配问题，才考虑微调。

当然，实际项目中也可以把两者结合起来。

十七、为什么RAG特别适合本地大模型？

这正是本地AI非常有价值的地方。

假设你有一批：

私人资料

项目文档

学习资料

公司内部文件

个人笔记

如果全部发送到云端AI：

可能涉及：

隐私

安全

数据合规

网络

成本

等问题。

而本地RAG可以设计成：

文件↓本地解析↓本地Embedding↓本地向量数据库↓本地大模型

整个流程：

可以全部运行在自己的电脑上。

这就是：

私有知识库。

十八、本地RAG到底能干什么？

应用场景非常多。

例如：

个人知识库

把自己的：

Markdown

PDF

笔记

电子书

资料

全部建立成知识库。

然后直接问：

“我之前记录过关于Linux双系统的哪些内容？”

学习助手

把：

教材

讲义

试卷

笔记

全部导入。

然后：

“根据这些资料给我整理知识点。”

企业知识库

把：

产品文档

技术手册

员工手册

制度文件

接入RAG。

员工可以直接询问：

“报销流程是什么？”

程序员知识库

把：

README

项目文档

API文档

代码说明

接入。

然后：

“这个项目的认证流程在哪里？”

十九、RAG甚至可以读取你的代码

这也是程序员非常喜欢RAG的原因。

例如一个项目：

project/├── src/├── docs/├── README.md├── package.json└── config/

经过处理后：

代码↓切分↓Embedding↓向量数据库

然后你问：

“用户登录之后Token在哪里生成？”

系统可以先检索相关代码，再让模型解释。

这就是：

代码知识库。

二十、但是RAG并不是万能的

这一点必须说明。

RAG最核心的问题是：

检索质量。

如果系统没有找到正确的资料：

错误检索↓错误上下文↓大模型↓错误答案

即使模型本身非常强，也可能回答错误。

所以：

RAG系统的上限，不仅取决于大模型，也取决于检索系统。

这也是为什么真正成熟的RAG系统，需要研究：

文档解析

Chunk切分

Embedding模型

向量数据库

检索策略

Reranker

Prompt

上下文管理

等等。

二十一、什么是Reranker？

假设你搜索：

“如何在Linux部署？”

系统第一次搜索可能找到20个相关片段。

但其中：

真正最相关的可能只有5个。

这时候可以使用：

Reranker（重排序模型）。

简单来说：

第一次检索↓找到20个候选↓Reranker重新排序↓选出最相关的5个↓交给大模型

这样可以提高最终回答质量。

所以更完整的RAG架构可能是：

问题↓Embedding↓向量检索↓候选文档↓Reranker↓Top-K↓大模型

二十二、为什么现在很多RAG系统采用“混合检索”？

单纯依靠向量检索并不一定最好。

例如用户搜索：

“RTX 5090”

这是一个非常具体的关键词。

这时候传统关键词搜索可能非常有效。

而用户问：

“有没有一种方法可以让显卡承担部分模型推理任务？”

这种语义问题：

向量检索可能更加有优势。

因此很多成熟系统会采用：

关键词检索 + 向量检索

也就是：

Hybrid Search

两种方法互相补充。

二十三、从RAG走向Agent

现在再回到上一篇文章。

我们之前讲：

模型↓API↓Python↓VS Code↓Agent

现在加入RAG：

Agent↓RAG↓知识库↓本地模型

于是Agent就可以：

读取自己的知识。

如果再加入工具：

Agent├── 知识库├── 文件系统├── Shell├── Git├── 浏览器└── 本地模型

那么一个真正意义上的本地AI Agent就开始出现了。

二十四、最终的本地AI架构

到这里，我们前面几篇文章终于可以完全串起来：

用户                     │                     ▼                  AI Agent                     │       ┌─────────────┼─────────────┐       ▼             ▼             ▼     RAG           Tools         API       │             │             │       ▼             ▼             ▼   知识库          文件/Git       模型服务       │                           │       ▼                           ▼  Embedding                   本地大模型       │       ▼  向量数据库

这已经不再是：

“在电脑上装一个AI聊天软件。”

而是一套真正属于自己的：

本地AI系统。

二十五、如果你现在就想动手，应该怎么开始？

不要一开始就研究复杂的企业级RAG。

最简单的路线是：

第一步

准备一个本地大模型。

例如通过 Ollama 运行。

第二步

准备一个Embedding模型。

第三步

准备几份PDF或Markdown。

第四步

解析文本。

第五步

切分Chunk。

第六步

生成Embedding。

第七步

保存到向量数据库。

第八步

输入问题。

第九步

检索相关内容。

第十步

把检索结果交给本地大模型。

这样，你就完成了人生中的第一个：

本地RAG系统。

二十六、这也是为什么我们前面的文章必须一步一步来

如果你直接告诉一个新手：

“搭建一个RAG Agent。”

他可能会看到：

Embedding

Vector Database

Retriever

Reranker

LLM

Prompt

Tool Calling

MCP

Agent

然后直接放弃。

但如果按照我们这个系列：

第一篇本地部署大模型↓第二篇理解模型参数与量化↓第三篇本地模型API↓第四篇Python / VS Code / Agent↓第五篇RAG知识库

整个过程就会非常清晰。

因为每一步都是上一层的自然延伸。

二十七、写在最后

本地大模型真正有价值的地方，从来不是：

“我电脑里有一个AI。”

而是：

“这个AI能够使用我自己的数据。”

当你把：

模型

API

知识库

文件

程序

工具

连接起来以后，

AI就开始从一个：

聊天机器人

逐渐变成：

属于你的智能助手。

而RAG，就是其中非常重要的一座桥梁。

它解决了一个关键问题：

如何让大模型在不重新训练的情况下，使用外部知识。

这也是为什么RAG成为现代AI应用中非常重要的一项技术。