关于本笔记

本笔记用于介绍 RAG（检索增强生成）的核心原理、两大工作阶段（离线建库与在线检索生成），以及语义搜索与关键词搜索的本质区别。

目录

• 一、大模型为什么「看不到」你的数据？
• 二、暴力解法为什么行不通？
• 三、RAG 的核心思路：先检索，再回答
• 四、RAG 的两大阶段
  • 离线阶段
  • 在线阶段
• 五、关键概念再讲透：语义搜索和关键词搜索的差别
• 六、完整流程图
• 七、RAG 在 Agent 里处于什么位置？
• 八、一张表看懂：没有 RAG vs 有 RAG
• 总结

一、大模型为什么「看不到」你的数据？

咱们先把问题说清楚，有三类「看不到」，每一类的原因都不同。


第一类：知识截止日期

大模型是用历史数据训练的，训练完之后它的知识就冻结了。比如 Claude 的训练数据截止到 2025 年某个时间点，之后发生的事情它一概不知。你去问它「我们系统今天凌晨发生了什么故障」，它根本没有这份信息，只能瞎猜。

第二类：私有数据

你们公司的内部文档、产品设计方案、运维手册、客服问答库，这些都是保密的，不可能出现在大模型的训练数据里。模型从没见过这些内容，自然没法基于它们来回答问题。

第三类：实时数据

今天刚写完的技术方案、刚产生的 bug 日志、刚更新的配置文件，这些是动态变化的，即便大模型更新了训练数据也追不上。你的 Agent 需要访问的，往往就是这类「最新鲜」的数据。

三类问题的共同点： 大模型的知识是静态的、封闭的，但你的业务数据是动态的、私有的 。

二、暴力解法为什么行不通？

遇到这个问题，很多同学第一反应是： 直接把数据塞进 Prompt 里不就行了？

听起来很直接，但这个方案有三个致命问题。

问题一：Context Window 有上限

大模型一次能处理的文本是有限的，这个限制叫做 Context Window（上下文窗口）。就算是目前最大的模型，一次也只能处理几十万 token，换算成中文大概是几十万个字。

你们公司的内部文档可能有几百个文件，光是运维手册就几十万字，根本塞不进去。更别提那些有几千个历史工单的故障数据库了。

问题二：费钱又慢

Token 是要花钱的。你塞进去 10 万 token 的背景资料，每次提问都要花那 10 万 token 的钱。一天问几百次，成本直接爆炸。而且 token 越多，模型推理越慢，用户等待时间越长。

问题三：注意力稀释

这是最容易被忽视的问题。大模型处理很长的上下文时，注意力会被稀释，相关内容埋在几万字的堆料里，模型很可能找不到重点，反而表现变差。你塞进去越多，有时候回答质量越低。

三、RAG 的核心思路：先检索，再回答

直接塞数据行不通，那 RAG 到底怎么解决这个问题？

核心思路其实非常简单，一句话就能说明白：

不把所有数据都塞进 Prompt，而是在每次回答之前，先去找到最相关的那几段，再把这几段塞进 Prompt。


这就是 RAG 名字的含义：

• Retrieval（检索） ：从知识库里找出和当前问题最相关的内容

• Augmented（增强） ：把检索到的内容加进 Prompt，增强大模型的上下文

• Generation（生成） ：大模型基于增强后的上下文生成回答

打个考试时查字典的比方：你考试的时候不需要把整本字典背下来，你只需要知道去字典里查哪个词，查到了那一页，看完再写答案。

RAG 就是这个思路，大模型不需要「记住」所有知识，它只需要在需要的时候，从知识库里检索到相关内容，然后基于这些内容来回答。

四、RAG 的两大阶段

RAG 的整个工作流程分两个阶段： 离线建库 和 在线检索生成 。


离线建库是一次性的准备工作（数据更新时重做），在线检索是每次用户提问时触发的实时流程。

离线阶段

这个阶段的目标是把你的私有数据，处理成大模型能快速检索的格式，存进向量数据库。一共四步：


Step 1：加载文档

把你的数据源统一接入进来，PDF 文档、Word 文件、Markdown 笔记、网页内容、数据库记录、代码文件……各种格式的数据，统一解析成纯文本。

Step 2：文本切块（Chunking）

拿到文本之后，不能直接整篇存起来，要先切成小块。为什么要切？

原因有两个：一是一篇文档几千字，里面涉及多个主题，检索的时候很可能只需要其中一个主题的内容，不需要整篇都召回；二是每个 chunk 要转化成向量存起来，chunk 太长，向量就无法精确代表那段文字的核心含义，检索准确率会变差。

切块就像是图书馆整理书籍：不是把整本书放一个标签，而是按章节、按小节分别标注，这样读者想找某个具体知识点，能直接找到那几页，而不用翻整本书。

Step 3：向量化（Embedding）

这是 RAG 里最难理解的一步，咱们重点讲。

切好的每个 chunk，要通过一个「Embedding 模型」转化成一串数字，这串数字就叫做 向量（Vector） 。

这串数字有什么神奇之处？它编码了这段文字的 语义含义 。意思相近的文字，转化出来的向量在数学空间里距离也相近。

用城市坐标来类比：每个城市都有经度和纬度，北京大约是北纬 40°、东经 116°；天津大约是北纬 39°、东经 117°，两组坐标数字很接近，在地图上两座城市确实挨着。广州是北纬 23°、东经 113°，坐标差别大，在地图上和北京也确实很远。

向量就是文字的「语义坐标」，「数据库响应慢」和「查询性能问题」虽然词语不同，但意思相近，它们转化出来的向量在空间里也是挨着的；而「数据库响应慢」和「今天天气不错」意思毫不相关，向量距离就很远。

Step 4：存入向量数据库

转化好的向量，连同对应的原文，一起存进向量数据库（比如 Milvus、Pinecone、Weaviate 等）。向量数据库专门优化了「在海量向量里找最近邻」这个操作，能在几毫秒内从百万级向量里找出最相似的几条。

在线阶段

每次用户提问，实时触发以下四步：


Step 1：问题向量化

用同一个 Embedding 模型，把用户的问题也转化成向量。

Step 2：语义搜索

拿着问题的向量，去向量数据库里找「最相似的几个 chunk 的向量」，这就是语义搜索。找到之后，把对应的原文 chunk 取出来，通常取 3-5 个最相关的片段。

注意，这里找的不是「包含相同关键词」的内容，而是「语义最相近」的内容。这是语义搜索和传统关键词搜索的本质区别。

Step 3：构造增强 Prompt

把检索回来的几段原文，加上用户的原始问题，拼成一个增强后的 Prompt：

Step 4：大模型生成回答

把这个 Prompt 发给大模型，大模型基于提供的背景资料生成有据可查的精准回答。

五、关键概念再讲透：语义搜索和关键词搜索的差别

这里展开说一下语义搜索，因为这是 RAG 能工作的核心，也是最容易搞混的地方。

传统关键词搜索（比如 SQL 的 LIKE 查询） ：逐字匹配，你搜「数据库慢」，它就找包含「数据库慢」这几个字的文档，找不到就返回空。如果文档里写的是「query performance degradation」或者「查询响应时间过长」，关键词搜索就找不到，哪怕说的是同一件事。

语义搜索 ：找意思相近的，不要求字面相同。你搜「数据库慢」，语义搜索能找到「查询性能问题」「SQL 响应延迟」「慢查询优化」这些片段，因为它们的向量距离近，语义上是相关的。

再举一个对比例子：

语义搜索让 RAG 能真正「理解」问题，而不只是机械地找字符串。这也是为什么 RAG 系统的检索准确率通常比普通关键词搜索高得多。

六、完整流程图

把整个 RAG 的两阶段用图串起来：


七、RAG 在 Agent 里处于什么位置？

学完 RAG 的原理，你可能会问：它和我们之前学的 Agent、MCP、Function Calling 是什么关系？

其实非常简单： RAG 本质上就是一个特殊的工具 。

还记得 Agent 章节讲的吗？Agent = 大模型（大脑）+ 工具（双手）+ 执行循环。「查询知识库」这个动作，被封装成了 Agent 里的一个 Tool。

当 Agent 接到一个需要私有知识的任务，大模型通过 Function Calling 下达「调用知识库检索工具，查询：XXX」的指令，Agent 执行这个工具调用，触发 RAG 的在线流程，检索结果回传给大模型，大模型基于检索结果继续推理。

这就是 mcp 和 agent 里预告 RAG 时说的： 「把知识库检索封装成工具」 。

八、一张表看懂：没有 RAG vs 有 RAG

总结

整理一下这一章的核心认知：

• RAG 是什么 ：Retrieval-Augmented Generation，检索增强生成。先从知识库里找到相关内容，再把这些内容加进 Prompt，让大模型基于私有数据生成有据可查的回答。

• 为什么需要它 ：大模型的知识是静态的、封闭的，而业务数据是动态的、私有的。把数据全量塞进 Prompt 行不通，超 token 限制、费钱、注意力稀释。RAG 用「按需检索 + 动态注入」绕开了这个死局。

• 两大阶段 ：离线阶段建知识库（加载→切块→向量化→存库），在线阶段查询生成（问题向量化→语义搜索→构造增强 Prompt→大模型生成回答）。

• 向量化和语义搜索 ：文字转化为代表语义的数字坐标（向量），语义相近的内容向量距离近。语义搜索不靠关键词匹配，靠语义相似度，能找到「意思相关但词语不同」的内容。

• 在 Agent 里的位置 ：RAG 就是一个特殊的工具，「检索知识库」被封装成一次 Function Call，是 Agent 能力体系的重要组成部分。