前几篇我们一直用“超级毕业生”来比喻LLM。这个毕业生脑子里装的是训练时灌进去的知识——可能是两年前的数据，而且绝对没有你公司内部的HR文档、产品手册和项目Wiki。你问他“我们公司2026年的年假政策是什么”，他只能硬着头皮编，或者老实说不知道。

这时候你就需要RAG了。

RAG，全称Retrieval-Augmented Generation，中文叫检索增强生成。核心思路很简单：让模型回答之前，先从你自己的知识库里检索相关片段，把这些片段和问题一起塞进Context，再让模型基于这些资料生成答案。相当于毕业生在答题前，先去图书馆翻了几页相关资料，复印下来摊在桌上，然后照着资料回答你。

这样一来，答案就不再依赖模型那可能过时的“记忆”，而是基于你给的最新、最相关的文档。RAG适合私有知识、专业文档、频繁更新的内容，和Tool Calling刚好互补——Tool偏向“办事”（下单、发邮件、查天气），RAG偏向“查资料”。

下面我把RAG流水线里绕不开的几个概念拆开讲，这些都是实际搭建RAG系统时会直接接触的东西。

Chunk：把书拆成一页一页的

Chunk，翻译过来就是文本块或文档切片。在把文档（PDF、Wiki、代码说明）入库之前，你得先把它们切成一段段大小适中的片段，而不是整本书一条塞进数据库。

为什么要切？因为上下文窗口有限，检索的时候通常只塞进最相关的几条片段，而不是整本手册。切太大，一个片段里糅了多个主题，和问题只有半句话相关，相似度就被稀释了；切太小，语义不完整，模型看不到前后文，容易断章取义。

常见做法是按固定字数或Token数切，也可以按标题、段落、代码函数边界来切，相邻块之间最好重叠几行，避免一句话被拦腰截断。我自己做的时候，一般会根据文档类型调chunk大小：技术文档偏短（256-512 tokens），政策文件可以稍长（512-1024 tokens），但都得实测看看检索效果。这活不复杂，就是费耐心。

Embedding：给每段文字打个“语义指纹”

Embedding，也叫向量嵌入。它是用一个专门的Embedding模型，把一段文字变成一串固定长度的数字向量。重点是：语义相近的文本，向量在空间里会更靠近。

在RAG里，Embedding干两件事：

1. 入库时，每个Chunk算一个向量，和原文一起存进向量库。
2. 提问时，把用户问题也算一个向量，用来和库里的向量比谁更“像”。

注意，Embedding模型和聊天用的LLM通常是两个不同的模型。Embedding模型更小、更便宜，专门训练来捕捉语义相似度。你可以把它想象成给每页书贴一张“主题指纹卡”，你问问题时也给你的问题打一张指纹，然后去卡片柜里找指纹最像的几张。

Vector：那个具体的数字串

Vector就是Embedding算出来的那串数字，比如[0.12, -0.34, 0.78, ...]，维度常见384、768、1536，看你用的模型。在代码和数据库里，一条Chunk通常存三样东西：原文、metadata（来源、页码等）和vector。

专门存这些向量的数据库叫向量数据库，比如pgvector、Pinecone、Milvus。它们针对大量向量做“找邻居”优化，速度远超传统关系型数据库的WHERE title LIKE '%年假%'。

Similarity Search：在语义地图上找邻居

Similarity Search，也叫向量相似度检索。就是拿问题的向量，和库里所有Chunk的向量比相似程度，取出最像的前K条。

常用的度量有余弦相似度（Cosine）和欧氏距离（L2），不过实际用的时候，向量库都帮你封装好了，你不需要手算。RAG里最常见的是余弦相似度，它看的是两个向量的夹角，值越接近1越相似。

和关键词搜索最大的不同在于：用户问“带薪休息几天”，文档里写的是“年假额度”，字面不完全重合，但向量可能很近。这就是语义搜索的威力。当然，纯向量搜索也有盲区，比如专有名词、编号这些，语义不一定能对上，所以后面会提到混合检索。

Retrieval：检索阶段总称

Retrieval就是RAG的检索阶段总称：根据用户问题，从知识库里捞出候选片段，再交给LLM。Similarity Search是最常用的手段，但生产环境往往会组合多种策略：

• 混合检索：向量相似度+关键词（比如BM25）一起打分，避免专有名词、编号只靠语义对不上。
• 元数据过滤：先限定department=HR、year=2025，再在子集里做相似度搜索，缩小范围。

检索质量直接决定RAG的上限。捞错了，模型再聪明也会对着错误段落一本正经地编。所以做RAG开发，很大一部分精力是花在调优检索策略上——Chunk策略、Embedding模型选型、Top-K设多大、要不要重排，这些都得根据实际数据反复测。

Re-ranking：精挑细选最后几步

Re-ranking，重排序。Similarity Search先粗捞一批候选（比如Top 20），再用一个更精准但更慢的模型或规则，对“问题-片段”逐对打分，重新排序后只把前几名塞进Context。

为什么需要这一步？向量检索快，但有时会把“长得像但答非所问”的段落排前面。重排模型（比如Cross-encoder）专门训练“这段是否真的回答这个问题”，精度更高，适合在Top-K较大时收窄到Top 3-5。

比喻一下：图书馆先按主题指纹找出20本书，再由资深馆员翻一遍目录，挑出真正该复印的那3页。很多生产系统都遵循这个模式：向量检索负责召回，Re-ranking负责精度。

RAG不是训练模型

这一点特别容易误解。RAG没有改LLM的权重，也不是用你的PDF再跑一遍预训练或微调。它只是：检索→把结果贴进Context→调用现成的LLM生成答案。

	训练/微调模型	RAG
改什么	模型参数	不改模型，改每次提问时桌上多摆什么资料
新知识	要学进参数，成本高、周期长	更新文档库、重新切块嵌入即可，分钟级生效
过时	难追实时政策	换文档、重建索引就行
可追溯	难说答案来自哪条训练数据	可附带引用检索到的原文片段
风险	数据混进训练集难清洗	私有文档不必上传给模型厂商训练

所以RAG = 外挂知识检索 + 原有大脑阅读，不是把图书馆搬进毕业生脑子里重造一个人。微调适合固定话术、风格；RAG适合常变、可引用、要控数据出境的企业知识。两者可以并存，但千万别搞混。

Embedding为什么能“理解”文本？

最后聊一个很多人困惑的问题：Embedding怎么就能把意思相近的句子映射到相近的向量呢？严格说，Embedding并不理解文本，也没有人类意义上的“懂”。它只是把文字映射到高维空间里的一个点，使得训练数据里经常一起出现、或标注为相近的句子，点与点更近；语义差远的，点更远。

之所以能“搜得像理解了”，是因为：

1. Embedding模型用海量文本（或“问题-答案对”“相似句对”）学过：怎样把文本压成向量，才能让“意思相关”的两段距离近。这是统计规律，不是读心术。
2. 问题和文档块用同一套Embedding模型编码，才能在同一个语义地图上比距离。
3. 它也有局限：谐音梗、极冷门的内部缩写、最新网络梗，可能离得很远；专有名词有时要靠混合检索或Re-ranking补救。

回到那个比喻：毕业生不会背下图书馆每一本书，但有一张训练过的“主题地图”——你问“休假”，地图上“年假”“带薪假”“调休”会在邻近区域，按距离找书页往往比按书名首字母靠谱。这和LLM那篇里说的“本质是模式与统计”一致；Embedding是为相似度检索优化的压缩表示，不是意识。

---

整个RAG流水线串起来就是这样一条路：

文档 → Chunk → Embedding → 存入向量库
用户提问 → 问题Embedding → Similarity Search（Retrieval）→ 可选Re-ranking → 片段+问题进Context → LLM生成答案

把这条线在自己项目里跑通，你对RAG的理解就落地了。下一篇我们会继续往下，聊Agent和Agent Loop——怎么让模型不光会查资料，还能自己判断、规划、调用工具，一步步完成任务。