给大模型装上“外挂大脑”：一文读懂 RAG 技术的来龙去脉-优快云博客

大模型虽强，但并非全知全能。作为弥补 LLM 时效性与私有数据短板的关键技术，RAG (检索增强生成) 已成为 AI 应用落地的“必修课”。

第一讲：RAG 的本质、核心价值与基础架构

1. 什么是 RAG？(Retrieval-Augmented Generation)

RAG，全称是 Retrieval-Augmented Generation（检索增强生成）。

如果用最通俗的语言来解释：

纯 LLM (大模型) 生成：就像是一个参加“闭卷考试”的学生。他只能凭自己脑子里的记忆（预训练数据）来回答问题。如果他记错了，或者这道题无论是课本里没有（私有数据），还是因为课本太老了（知识截止日期），他都可能会一本正经地胡说八道（产生幻觉，Hallucination）。
RAG 生成：就像是允许这位学生参加“开卷考试”。当遇到问题时，他先去翻阅手边的参考书（外部知识库），找到相关的段落，然后再结合这些段落来回答问题。

2. 为什么我们需要 RAG？

大语言模型（LLM）虽然强大，但存在三个致命的短板，而 RAG 就是为了解决这些问题而生的：

知识时效性 (Cut-off Date)： GPT-4 或 Llama 3 训练完的那一刻，它的知识就定格了。它不知道昨天发生了什么新闻。RAG 可以通过外挂最新的数据库，让模型“实时”知晓天下事。
私有数据 (Private Data)：企业内部的合同、代码、HR文档，OpenAI 是没有见过的。通过 RAG，我们可以让模型基于企业私有数据回答问题，而不需要把数据上传给模型厂商去训练。
幻觉问题 (Hallucinations)：模型在不知道答案时倾向于编造。RAG 强制模型“基于检索到的事实”说话，极大地降低了胡编乱造的概率，提高了可解释性。

3. RAG 的标准工作流程 (The Pipeline)

一个标准的 RAG 系统，其运行流程可以概括为三个核心步骤：索引 (Indexing)、检索 (Retrieval) 和生成 (Generation)。

A. 准备阶段：索引 (Indexing)

在用户提问之前，我们需要先把“参考书”准备好。

文档加载：读取 PDF, Word, HTML 等原始文件。
切分 (Chunking)：把长文章切成小段（Chunk），因为模型上下文有限，且切分越细，检索越精准。
向量化 (Embedding)：这是关键一步。利用 Embedding 模型将文字变成高维向量（一串数字），存入向量数据库 (Vector Database)。

B. 运行阶段：检索 (Retrieval)

当用户提出问题（Query）时：

Query 向量化：把用户的问题也变成向量。
相似度匹配：在向量数据库中，寻找与“问题向量”距离最近的“文档块向量”。这就像是在图书馆里根据索引号找书。
Top-K 提取：取出相关度最高的 K 个片段（Context）。

C. 运行阶段：生成 (Generation)

Prompt 组装：我们将用户的问题 + 检索到的 K 个片段，填入一个精心设计的 Prompt 模板中。

模板示例：“你是一个助手。请基于以下【已知信息】回答用户的【问题】。如果信息不足，请说不知道。/n【已知信息】：... /n【问题】：...”
LLM 回答：大模型阅读这个组装好的 Prompt，生成最终答案。

4. 关键辨析：RAG vs Fine-tuning (微调)

这是面试或技术选型中最常被问到的问题：我该微调模型，还是用 RAG？

维度	RAG (检索增强)	Fine-tuning (微调)
本质比喻	给模型一本教科书 (开卷考试)	让模型把知识背下来 (内化知识)
知识更新	极快 (更新数据库即可)	慢 (需要重新训练模型)
数据隐私	数据在本地数据库，控制权高	数据融入模型参数，难以剥离
主要用途	扩展知识库、实时信息查询	调整模型语气、指令跟随能力、特定格式输出
幻觉风险	低 (基于证据回答)	仍存在，且难以溯源

在 90% 的企业级知识问答场景中，RAG 是首选。通常只有当你需要改变模型的“说话方式”或“特定领域的逻辑推理能力”时，才考虑 Fine-tuning。现在的趋势是 RAG + Fine-tuning 结合使用。

RAG 是一种通过外挂知识库来弥补大模型时效性差、不懂私有数据、爱瞎编这三大缺陷的技术架构。它的核心在于“先检索，后生成”。

第二讲：数据索引与向量化——RAG 的“记忆”构建

这一讲我们解决两个核心问题：

切分 (Chunking)：长文章怎么切才合理？
向量化 (Embedding)：机器怎么理解文字的含义？

如果说 RAG 是一个大脑，那么今天我们要讲的，就是如何把知识“吃”进去，并转化成大脑能记住的“记忆”。很多 RAG 系统效果不好，不是模型不行，而是因为这一步做得太粗糙，导致“吃坏了肚子”（Garbage In, Garbage Out）。

一、数据的切分策略 (Chunking Strategies)

很多初学者直接把整本书或者整篇 PDF 丢给 Embedding 模型，这是错误的。Embedding 模型通常有 token 限制（比如 512 或 8192 token），而且片段越长，语义越稀释，检索越不精准。

我们需要把长文本切成小的文本块 (Chunks)。但这不仅是简单的“切一刀”，这是一门艺术。

1. 为什么要切分？

模拟人类阅读：你背书时也不会整本背，而是一段一段地理解。
检索精度：如果用户问“公司的迟到扣款规则是什么？”，你希望检索出来的只有“考勤制度”那一段，而不是把整本 500 页的《员工手册》都丢给大模型，那样模型会“迷失”在无关信息中（Lost in the Middle 现象）。

2. 常见的切分方式

固定大小切分 (Fixed-size Chunking)：最简单粗暴。比如每 500 个字符切一段。
- 缺点：容易把完整的句子或逻辑切断。比如“我喜欢吃……（切断）……苹果”，语义就丢了。
基于字符/分隔符切分 (Character/Recursive Splitting)：这是最常用的。优先按照段落 (\n\n) 切，段落太大就按句子 (., 。) 切，还不行就按词切。
- 工具：LangChain 的 RecursiveCharacterTextSplitter 就是做这个的。
语义切分 (Semantic Chunking)：这是进阶玩法。不按字数切，而是判断“话题”是否变了。如果前后两句话讨论的是完全不同的东西，就在这里切开。这需要先用小模型计算句子间的相似度。

3. 关键技巧：重叠 (Overlap)

这是重点！ 在切分时，相邻的两个块之间必须保留一部分重叠内容 (Chunk Overlap)。

举例：假设设定块大小为 100，重叠为 20。

Chunk 1: [字符 0 - 100]

Chunk 2: [字符 80 - 180] （注意这里重复了 20 个字符）

为什么要重叠？ 为了防止上下文在切分点丢失。如果用户的问题恰好跨越了两个块的边界，没有重叠的话，两个块单独拿出来都回答不了问题。重叠就像是“接力棒”，保证语义的连贯性。

二、向量化 (Embedding)——赋予文字坐标

切分好文本块后，计算机依然不认识字。我们需要用到 Embedding 模型。

1. 什么是 Embedding？

Embedding 是将文字转换为一组浮点数向量（例如 [0.12, -0.98, 0.45, ...]）。

它的神奇之处在于：语义相似的文本，在向量空间中的距离更近。

直观理解：在向量空间里：

“苹果”和“香蕉”离得很近（都是水果）。

“苹果”和“乔布斯”离得也比较近（科技关联）。

“苹果”和“卡车”离得很远。

传统的关键词搜索（Keyword Search）只能匹配字面（比如搜“小狗”搜不到“汪星人”），而 Embedding 能够实现语义搜索（搜“小狗”能匹配到“汪星人”，因为它们语义向量很近）。

2. 如何选择 Embedding 模型？

Embedding 模型是 RAG 效果的基石。选错了模型，后面再强的 LLM 也没用。

闭源模型 (API)：
- OpenAI text-embedding-3-small/large：目前也是工业界的主流，不仅性能好，而且支持降维，性价比高。
开源模型 (Self-hosted)：
- MTEB 排行榜：Hugging Face 上有一个 MTEB 榜单，专门给 Embedding 模型排名。
- BGE (BAAI General Embedding)：北京智源推出的模型，中文效果极佳，是目前中文 RAG 的首选之一。
- Jina AI / Cohere：也提供了非常优秀的多语言 Embedding 模型。

如果你做中文 RAG，推荐试用 BGE-M3 或 OpenAI text-embedding-3。

三、向量数据库 (Vector Database)

算出了成千上万个向量，存哪里呢？MySQL 存这些高维数组效率太低了，我们需要向量数据库。

1. 核心功能

它的核心能力不是“存”，而是“算”。当你给它一个新向量时，它能在大海捞针般地，在毫秒级时间内找到和它最像的那几个向量（Approximate Nearest Neighbor, ANN 算法）。

2. 相似度计算公式

余弦相似度 (Cosine Similarity)：最常用。主要看向量的方向是否一致。
欧氏距离 (Euclidean Distance)：看两点间的物理距离。

3. 常见选型

轻量级/本地开发：Chroma, FAISS (Facebook开源，是所有向量库的老祖宗), LanceDB。适合在你的笔记本上跑 Demo。
生产级/云原生：Pinecone (SaaS，不用运维), Milvus (国产开源，高性能), Elasticsearch (老牌搜索也加入了向量功能)。

总结

同学，这一讲我们完成了 RAG 的“记忆构建”。请记住三个核心点：

切分 (Chunking) 必须要有 Overlap (重叠)，防止语义断裂。
Embedding 是把文字变成“意思”，让机器能进行语义检索。
中文场景下，选对 Embedding 模型（如 BGE）比选对大模型更重要。

现在我们的数据库里已经存好了切好的知识片段。当用户提问时，我们该如何精准地把答案捞出来？

第三讲：检索策略与生成——如何找到最准确的答案

检索（Retrieval）不仅仅是计算相似度，它其实是一个漏斗筛选的过程。

一、为什么单纯的向量检索不够用？

我们在第二讲说了 Embedding 很厉害，能懂语义。但是，它也有“短板”：

精确匹配能力弱：如果你搜一个特定的产品型号“XJ-9000”或者一个人名，向量模型可能只觉得它是“某种机械”或“名字”，反而不如传统的关键词搜索（比如 SQL 的 LIKE 或搜索引擎的 BM25 算法）精准。
语义漂移：有时候“很像”的话，意思完全相反。比如“我爱吃苹果”和“我不爱吃苹果”，在向量空间里距离可能极近（因为词重叠度高），但逻辑相反。

为了解决这个问题，工业界有三个办法：混合检索、重排序、查询转换。

二、混合检索 (Hybrid Search)

这是目前生产环境的标配。既然向量检索（语义）和关键词检索（字面）各有优劣，那就把它们结合起来。

做法：
1. 路数 A (Vector Search)：找出语义相关的文档（比如搜“苹果”找到“水果”）。
2. 路数 B (Keyword Search / BM25)：找出字面精确匹配的文档（比如搜“iPhone 15”精准命中）。
3. 加权融合 (Reciprocal Rank Fusion, RRF)：将两路结果打分合并。

比喻：这就像找对象。向量检索是看“三观合不合”（语义），关键词检索是看“硬性条件符不符合”（身高、收入）。混合检索就是既看三观又看条件，往往能找到最合适的人。

三、重排序 (Re-ranking) —— RAG 的“提分神器”

如果让我只推荐一个能瞬间提升 RAG 效果的手段，那一定是 Re-ranking。

1. 两阶段检索模式

因为向量数据库（Vector DB）为了快，使用的是一种“模糊搜索”算法（ANN），它追求速度但损失了精度。

第一阶段（粗排）：先从海量数据库中，快速捞出 Top 50 个“大概相关”的片段。这一步要快。
第二阶段（精排 - Re-ranking）：使用一个专门的Re-rank 模型（Cross-Encoder），把这 50 个片段，每一个都和用户的问题放在一起精细比对，重新打分，选出 Top 5。这一步要准。

2. 为什么 Re-rank 准？

Bi-Encoder (向量检索用)：分别计算问题和文档的向量，不仅丢失了部分交互信息，而且如同“由于距离远，只能大概看看”。
Cross-Encoder (重排序用)：把“问题”和“文档”像三明治一样夹在一起输入模型，模型能逐字逐句分析它们的相关性。

工业界经验：加入 Re-ranking 模块后，检索准确率（Hit Rate）通常能提升 10% - 20%。常用的 Re-rank 模型有 BGE-Reranker, Cohere Rerank 等。

四、查询转换 (Query Transformation)

很多时候，检索不到不是系统的问题，而是用户的问题写得烂。

问题指代不明：
- 用户问：“它多少钱？”（RAG 系统懵了：它是谁？）
- 解决：利用 LLM 结合历史聊天记录，把问题改写为：“iPhone 15 Pro Max 多少钱？” —— Query Rewriting (查询重写)。
问题太复杂：
- 用户问：“对比一下 A 公司和 B 公司的财报。”
- 解决：把这个问题拆解成两个子问题：“A 公司财报如何？”和“B 公司财报如何？”，分别去检索，最后汇总。 —— Sub-query Decomposition (子问题拆解)。

五、最后的临门一脚：生成 (Generation)

当通过上述手段，我们要到了最精准的 Top 5 片段（Context）后，就到了最后一步：让 LLM 回答。

这里的关键是 Prompt 工程。你需要给 LLM 戴上“紧箍咒”：

经典的 RAG Prompt 结构：

你是一个诚实的助手。请务必只根据下方的【参考信息】回答问题。 如果【参考信息】中没有答案，请直接说“我不知道”，不要编造。

【参考信息】： 1. ... 2. ...

【用户问题】：...

注意：

来源标注：可以要求 LLM 在回答时标注引用来源（如：根据[1]...），增加可信度。
上下文窗口：虽然现在 LLM 支持 128k 甚至 1M 上下文，但塞入过多无关信息（Noise）会降低 LLM 的推理能力（Lost in the Middle 再次出现）。所以，检索越准，给 LLM 的越少越好。

总结

同学，这一讲全是干货。如果要打造一个工业级可用的 RAG，你不能只靠简单的向量相似度。请记住 RAG 进阶三板斧：

混合检索：语义 + 关键词，两手都要抓。
重排序 (Re-ranking)：先海选，再精选，这是提升准确率性价比最高的手段。
查询转换：帮用户把问题问对，答案自然就来了。

经过前三讲的学习，你已经掌握了 RAG 的核心“三板斧”：切分、向量化、混合检索+重排序。对于 80% 的常规问答（比如“公司几点上班？”），这套打法已经足够好了。

但是，当你面对复杂的真实世界数据时——比如全是表格的财报、逻辑复杂的法律文书，或者用户问了一个需要拐好几个弯才能回答的问题——基础 RAG 就会“虽然努力但依然翻车”。

第四讲：进阶 RAG —— 复杂场景与模块化优化

这一讲我们解决三个让无数开发者头秃的难题：

上下文碎片化：切得太细，模型看不懂；切得太粗，检索不准。
表格与结构化数据：文档里的表格，一转成文字就乱套。
复杂逻辑推理：简单的一步检索回答不了多步推理的问题。

一、破解“切分两难”：父文档检索 (Parent Document Retriever)

我们在第二讲提到，为了检索精准，我们倾向于把文本切得很小（比如 200 字一段）。但是，把这 200 字丢给大模型时，往往因为缺乏前言后语，模型看了一脸懵。

矛盾点：

检索 (Retrieval) 喜欢小片段（特征明显，杂音少）。
生成 (Generation) 喜欢大片段（上下文完整，逻辑通顺）。

解决方案：父文档检索 (Parent Document Retriever) / 小索引，大内容 (Small-to-Big)

这是一个非常聪明的策略：“搜的时候搜儿子，给的时候给爸爸”。

索引阶段：我们将文档切成小块（Child Chunk），比如 100 字，进行向量化存入数据库。同时，记录下它属于哪个大块（Parent Chunk）（比如 1000 字）。
检索阶段：我们用“小块”去匹配用户的问题（保证精准度）。
生成阶段：一旦匹配中某个“小块”，我们不直接用它，而是把它背后的“父文档（大块）”取出来，喂给 LLM。

老师的比喻：这就像你在视频网站搜电影。你搜索的是短短几秒的“高光片段”（小块），但当你点击播放时，系统给你看的是包含这几秒的前后完整 5 分钟的片段（父文档），这样你才能看懂剧情。

二、攻克“RAG 杀手”：表格处理 (Handling Tables)

PDF 里的表格是 RAG 的噩梦。如果你直接把 PDF 里的表格转成纯文本，通常会变成一堆乱码，列与列对不齐，语义完全丢失。LLM 根本读不懂。

解决方案：摘要索引法 (Summary Indexing)

不要试图强行切割表格。

提取：单独把表格提取出来。
总结：用 LLM 给这个表格写一段文字摘要（Summary）。
- 例如：“这是一个关于 2023 年 Q3 各部门营收的表格，销售部营收 500 万，增长 10%...”
索引：我们把这段**“文字摘要”**向量化，存入数据库。
检索：当用户问“2023 Q3 哪个部门最赚钱？”时，会匹配到这段摘要。
生成：将原始表格数据（而不是摘要）作为上下文喂给 LLM 回答。

这叫“用摘要去检索，用原数据去回答”。

三、拒绝“傻瓜式检索”：路由与模块化 (Routing & Modular RAG)

基础 RAG 不管用户问什么，都一头扎进数据库里找。但有时候用户只是问“你好”，或者问“今天的股价是多少（这是公网信息）”。

我们需要一个**“大脑”**来指挥 RAG，这就是 Router (路由器)。

在检索之前，先加一个分类器（通常也是 LLM）：

如果是寒暄 -> 直接回答。
如果是问内部知识 -> 走 RAG 向量检索。
如果是问实时新闻 -> 调用 Google/Bing 搜索 API（Web Search）。
如果是数学计算 -> 调用代码解释器 (Code Interpreter)。

这就是 Agentic RAG (代理式 RAG) 的雏形。系统不再是一根筋的流水线，而是一个能根据情况选择工具的智能体。

四、终极武器：知识图谱 RAG (GraphRAG)

这是目前最前沿的方向。向量检索只能找到“字面”或“语义”相似的东西，但很难发现**“隐性关系”**。

场景：文档 A 说：“张三是 A 公司的控股人。” 文档 B 说：“A 公司实际上控制了 B 公司。”

用户问：“张三和 B 公司有什么关系？”

向量检索：可能这就瞎了。因为它找不到直接把“张三”和“B 公司”写在一起的句子。
GraphRAG：通过构建知识图谱 (Knowledge Graph)，将实体（张三、A公司、B公司）和关系（控股、控制）连接成网。它能顺藤摸瓜，推理出“张三 -> A公司 -> B公司”的路径。

微软最近大力推崇 GraphRAG，它在处理全局性问题（如“总结全书的主题”）和多跳推理时，效果完爆传统 RAG。