RAG 核心知识十讲：从入门到企业级实践
建议阅读人群： AI 应用开发者 / 大模型面试备战者 / 对 RAG 技术感兴趣的同学
原文作者： 陈宇锋（飞行社），本文是对其飞书社区分享的整理
原文链接： 飞书社区 - RAG 核心知识十讲
为什么你需要读懂 RAG？
但很多同学一聊到 RAG，就只会说「就是给大模型外挂一个知识库嘛」，再深入问几句：RAG 的完整流程是什么？文档怎么切分？向量数据库怎么选？什么是 Re-rank？什么是多路召回？怎么评估 RAG 的效果？
一连串的问题，就卡壳了。
这篇文章用最通俗易懂的方式，把 RAG 相关的核心知识一次性讲透。搞懂了不仅能应付面试，更能帮你真正理解企业级 RAG 系统的设计思路。
十大核心问题一览：
- 🌟 什么是 RAG？
- 🌟 RAG 整体工作流程是怎样的？
- 🌟 微调和 RAG 各自区别是什么？
- 🌟 RAG 中的文档切割策略有哪些？
- 🌟 Re-rank 是什么？
- 🌟 Embedding 有哪几种算法你了解过吗？
- 🌟 什么是向量数据库？有没有做过向量数据库的对比选型？
- 🌟 什么是多路召回？具体怎么做？
- 🌟 怎么量化你的 RAG 效果？
- 🌟 什么是大模型幻觉？怎么降低幻觉？
第一讲：什么是 RAG？
聊 RAG 之前，咱们得先搞清楚一个问题：大模型为什么需要「外挂」？
大模型的「知识困局」
你有没有遇到过这样的情况：问 ChatGPT 一个你们公司内部的问题，比如「我们公司今年的年假政策是什么」，它要么告诉你「我无法获取你们公司的内部信息」，要么就开始一本正经地编答案，说得头头是道，但全是错的。
这就是大模型面临的三大困境：
- 知识有截止日期：大模型的知识来自于训练数据，而训练数据是有时间窗口的。比如某个版本的 ChatGPT 训练数据截止到 2023 年 4 月，之后发生的任何事情它都不知道。
- 不知道私有数据：你公司的产品文档、内部规章制度、客户信息、项目资料……这些数据从来没有出现在大模型的训练集中。
- 会「幻觉」：大模型会非常自信地说出一些听起来很专业但完全是编造的内容。你问它一个不存在的研究论文，它能给你编出标题、作者、摘要、甚至 DOI 号，看起来像模像样，但全是假的。
那怎么办？给大模型「开卷考试」
打个比方。大模型就像一个参加了「闭卷考试」的学生，所有知识都得靠脑子记。但这个考试有个问题：题目会问到最新的知识（知识截止日期）、会问到课本上没有的内部资料（私有数据），而且这个学生还会「编答案」（幻觉）。
那怎么解决？最直觉的办法就是给他开卷考试，允许他翻参考书。
RAG 就是这个思路。 RAG 的全称是 Retrieval-Augmented Generation（检索增强生成），核心思想非常简单：
- 先从外部知识库中**检索（Retrieval）**出和用户问题相关的资料
- 把检索到的资料作为**增强（Augmented）**上下文，和用户的问题一起给到大模型
- 大模型基于这些真实的资料来**生成（Generation）**回答
这样一来，大模型的回答就有了「依据」，不再是凭空编造，而是基于真实文档生成的。知识可以随时更新（更新知识库就行），私有数据也能用了（把公司文档放进知识库），幻觉问题也大幅减少了（有真实资料做参考）。
RAG 这个概念是怎么来的？
RAG 最早由 Facebook（现 Meta）的研究团队在 2020 年提出。2020 年那会儿大模型还没那么火，RAG 这个概念也只是学术圈在讨论。真正让 RAG 火起来的，是 2023 年 ChatGPT 爆红之后，大家发现大模型在实际应用中有那么多局限性，而 RAG 恰好能很好地解决这些问题。
到了现在，RAG 已经成为企业落地 AI 应用的标配技术。不管是大厂还是创业公司，只要做大模型应用，几乎都绕不开 RAG。
RAG 不是万能的
它解决的是「大模型缺乏特定知识」的问题，但它不能：
- 改变大模型的推理能力（如果模型本身推理不行，给再多资料也没用）
- 改变大模型的输出风格（如果你希望模型用特定风格回答，这需要微调）
- 保证 100% 的准确性（检索可能召回错误的文档，模型也可能曲解文档内容）
所以 RAG 更准确的定位是：一种让大模型基于真实、可更新的知识来回答问题的技术方案。它和微调、Prompt Engineering 等技术是互补的，而不是替代关系。
第二讲：RAG 整体工作流程是怎样的？
一个完整的 RAG 系统其实分为两个大阶段：索引阶段（离线） 和 查询阶段（在线）。
索引阶段：把知识「整理好」
第一步：文档加载 — 把各种格式（PDF、Word、Excel、PPT、HTML、Markdown……）的文档加载进来，统一转成纯文本。比如包含表格、图片、多栏排版的 PDF 解析起来就很费劲。
第二步：文档切割（Chunking） — 把长文档切成一个个小的文本块（Chunk），每个大概几百到几千个字符。因为大模型的上下文窗口有限，不可能把整本 100 页的文档直接扔给它。
第三步：向量化（Embedding） — 把每个文本块转换成一个数学向量（一串数字）。Embedding 模型把一段文本「翻译」成了高维空间中的坐标点，语义相近的文本在这个空间中的距离也相近。比如「今天天气很好」和「今天阳光明媚」在向量空间中的距离会很近。
第四步：存入向量数据库 — 把所有文本块的向量和原始文本一起存入向量数据库，构建索引结构，以便后续快速检索。
查询阶段：让大模型「翻书找答案」
第一步：用户提问向量化 — 用同样的 Embedding 模型，把用户的问题也转换成一个向量。比如「公司年假政策是什么」。
第二步：相似度检索 — 拿着问题的向量，去向量数据库中进行相似度搜索，找到和这个问题语义最相近的 Top-K 个文本块。比如：
- 「公司全职员工入职满一年后享有 10 天带薪年假」
- 「年假可以拆分使用，每次不少于半天」
- 「未使用的年假可以累积到下一年，但最多累积 5 天」
第三步：构造增强 Prompt — 把检索出来的文本块和用户的原始问题拼在一起：
「请根据以下参考资料回答用户的问题。参考资料：[检索出的文本块]。用户问题：公司年假政策是什么？」
第四步：大模型生成回答 — 把增强版的 Prompt 发给大模型，大模型基于这些真实的参考资料来生成回答。
完整流程一览
- 索引阶段（离线）：文档加载 → 文档切割 → 文本向量化 → 存入向量数据库
- 查询阶段（在线）：用户提问 → 问题向量化 → 向量检索 → 构造增强 Prompt → 大模型生成回答
这是最基础的 RAG 流程，也被称为 Naive RAG（朴素 RAG）。在实际生产中，为了提升效果，还会加入查询改写、多路召回、重排序（Re-rank）等高级技术。
第三讲：微调和 RAG 各自区别是什么？
先搞清楚什么是微调
微调（Fine-tuning）就是拿一个已经预训练好的大模型，用自己的数据对它进行进一步的训练，让它在特定领域或特定任务上表现更好。微调的级别有：
- 全量微调：更新模型的所有参数，效果最好但成本极高，需要大量 GPU。
- 参数高效微调（如 LoRA）：只训练一个很小的「低秩适配器」，不动模型主体，一张消费级显卡就能跑。
- 指令微调：用「指令-回答」格式的数据来微调，让模型学会听懂指令。
核心维度的对比
| 维度 | 微调 | RAG |
|---|---|---|
| 知识更新方式 | 重新训练，成本高 | 更新知识库即可，成本低 |
| 准确性 | 靠「记忆」回答，可能记错 | 基于真实文档，可追溯可验证 |
| 语言风格控制 | 强项，能学会特定风格 | 弱，取决于模型本身 |
| 成本 | 初始成本高，推理成本低 | 初始成本低，每次查询有检索开销 |
什么时候用微调，什么时候用 RAG？
大多数场景下，优先选 RAG。 尤其是需要回答内容严格基于特定文档（法律条款、产品手册）、知识更新频繁（新闻问答、股票分析）、涉及大量私有数据、需要回答可追溯有出处的场景。
微调更适合：需要模型输出特定风格或格式（客服话术、法律文书格式）、需要学会某种「能力」而非「知识」（特定编程语法）、数据量不大且不常更新且对推理速度有很高要求。
最成熟的做法是微调 + RAG 结合：先用微调让模型适应你的领域和风格，再用 RAG 来提供实时、准确的知识支撑。就好比先送员工去培训（微调），让他学会行业的专业知识和做事方式；再给他配一个可随时查询的资料库（RAG），让他能随时查到最新的信息。
第四讲：RAG 中的文档切割策略有哪些？
为什么文档切割这么重要？
切割有个两难：
- 切得太小：每个文本块信息太少，可能丢失上下文。比如把「公司全职员工入职满一年后享有 10 天带薪年假」切成两半，第一块根本不知道在说什么。
- 切得太大：每个文本块信息太多，检索精度下降，而且浪费大模型的上下文窗口。
五大切割策略
策略一：固定大小切割 — 按固定字符数或 token 数机械切割。最简单但最粗暴，可能把一句话切成两半。通常配合「重叠（Overlap）」来缓解，让相邻块之间共享一部分文本。
策略二：递归字符切割 — 先用段落分隔符切，切不动再用换行符，再切不动用句号、空格。LangChain 的 RecursiveCharacterTextSplitter 就是这个思路。它尽量在自然的语义边界处切割，是最推荐的起步方案。
策略三：基于文档结构的切割 — 根据 Markdown 标题、HTML 标签等文档自身的结构来切。如果一个文档有清晰的章节结构，按章节切通常比按固定长度切效果好得多。
策略四：语义切割 — 基于内容的语义相似度来决定在哪切。把语义相似的句子放在一起，语义发生转折的地方就是切割点。切割质量最高，但计算成本也最大。
策略五：Agent 驱动的智能切割 — 用 LLM 来判断应该怎么切，充当「智能编辑」的角色。理论上效果最好，但成本最高。
实战建议
- 起步阶段：直接用递归字符切割，块大小 256-512 tokens，重叠 10%-20%。
- 优化阶段：如果文档有清晰的结构（Markdown、HTML），切换到基于文档结构的切割。
- 进阶阶段：尝试语义切割或「父子块」策略（存储小块用于精准检索，返回给大模型的是包含上下文的父块）。
第五讲：Re-rank 是什么？
先理解一个核心问题
在 RAG 系统中，检索阶段用的是 Bi-Encoder（双编码器），也就是 Embedding 模型。它把查询和文档分别编码成向量，然后计算余弦相似度来判断相关性。
这有两个先天不足：
- 信息压缩损失：一段几百字的文本被压缩成一串数字，细微但关键的信息可能丢了。
- 缺乏查询意图感知：文档的向量是在索引阶段预先计算好的，同一篇文档的向量不管用户问什么都是一样的。
Cross-Encoder：让查询和文档「面对面交流」
Re-rank 使用 Cross-Encoder（交叉编码器），它把查询和文档拼在一起，让模型同时看到两者，进行深度的交互分析。这就好比从「分别给两篇文章写摘要再比对」变成了「把两篇文章放在一起仔细对比」。
为什么不直接用 Cross-Encoder？
因为 Cross-Encoder 太慢了。Bi-Encoder 可以预先计算好文档向量，查询时只需要一次向量运算；而 Cross-Encoder 需要把查询和每个候选文档都拼起来过一遍模型，计算量是 N 倍。
所以实际方案是：先用 Bi-Encoder 快速召回 Top-50 到 Top-100 个候选，再用 Cross-Encoder 对这些候选做精排，选出最相关的 Top-5 或 Top-10。
主流的 Re-rank 模型
- Cohere Rerank：商业 API，效果稳定
- bge-reranker：智源开源，中文效果好
- Jina Reranker：支持多语言
- bce-reranker：网易有道开源，中英文混合场景效果好
Re-rank 带来了多大的提升？
- 复杂查询（多跳推理）：准确率提升 40%-50%
- 简单事实查询：提升约 18%
- 模糊查询：提升约 30%-40%
- Databricks 测试还表明，重排序后的检索结果能让大模型幻觉率降低约 35%
实战建议
- 先检索 50-100 个候选，再重排到 Top-5 或 Top-10，性价比最高。
- 不需要所有查询都做 Re-rank。可以设置条件触发机制，只在初排 Top-1 的分数低于阈值时才启动。
第六讲：Embedding 有哪几种算法你了解过吗？
Embedding 的核心思想：把文本转换成高维空间中的数值向量，让语义相近的文本在向量空间中的距离也相近。
四代演进
第一代：静态词向量时代（2013 年） — Word2Vec 由 Google 在 2013 年提出。核心思想来自「上下文相似的词，语义也相似」。有 CBOW 和 Skip-Gram 两种训练方式。能做词语类比：「国王 - 男人 + 女人 ≈ 女王」。但根本缺陷是给每个词只生成一个固定的向量，无法处理多义词（「苹果」是水果还是公司？）。
第二代：上下文嵌入时代（2018 年） — BERT 由 Google 在 2018 年提出。最大的突破是：同一个词在不同的上下文中会得到不同的向量。在 RAG 场景中通常取 [CLS] token 的向量作为整段文本的表示。但局限是上下文窗口只有 512 tokens，且不是专门为检索设计的。
第三代：融合与优化时代（2023 年至今） — 代表作 BGE-M3（智源研究院），「M3」代表三个多：
- Multi-Granularity（多粒度）：最大支持 8192 tokens
- Multi-Functionality（多功能）：一站式集成稠密检索、稀疏检索和多向量检索
- Multi-Language（多语言）：支持 100 多种语言
OpenAI 的 text-embedding-3-large 维度高达 3072，在 MTEB 榜单上表现优异。
第四代：基于大模型的 Embedding（2025 年） — 核心思路是直接用大模型（LLM）来做 Embedding。代表工作包括 LLM2Vec、Qwen3-Embedding、字节跳动的 Seed1.5-Embedding（MTEB 中英文 SOTA）。
怎么选 Embedding 模型？
- 看榜单：参考 MTEB 排行榜，最权威的 Embedding 模型评测榜单
- 中文场景优先选国产模型：BGE 系列、M3E 系列、ACGE 系列通常优于 OpenAI
- 关注上下文窗口：长文档（法律合同、学术论文）一定要选支持长上下文的模型（如 BGE-M3 的 8192 tokens）
- 考虑部署方式：数据安全要求高选开源模型私有化部署；追求简单用 API 服务
第七讲：什么是向量数据库？有没有做过向量数据库的对比选型？
向量数据库解决什么问题？
假设你有 100 万个文本块，每个被转换成 1536 维的向量。暴力搜索每次查询都要和 100 万个向量逐一计算相似度，完全不可接受。
向量数据库使用特殊的索引结构（HNSW、IVF、PQ 等），能够在海量向量中实现毫秒级的近似最近邻搜索（ANN）。
主流向量数据库对比
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| Milvus | 开源，支持十亿级向量，索引类型丰富（HNSW/IVF/PQ），GPU 加速 | 大规模企业级应用，数据量上亿 |
| Pinecone | 全托管 SaaS，零运维，自动扩缩容 | 预算充足、不想折腾基础设施 |
| Weaviate | 原生支持混合检索（向量+BM25），内置 Embedding 集成 | 中小规模、需要混合检索 |
| Chroma | 轻量极简，pip 安装即用 | 原型验证、个人项目、教学演示 |
| Qdrant | Rust 编写，单机性能极强，QPS 和延迟最优 | 对性能有极致要求，自建但不想用 Milvus |
选型建议
- 快速 POC → Chroma
- 中小规模生产，预算充足 → Pinecone
- 中小规模，需私有化 → Weaviate
- 大规模企业级（上亿） → Milvus
- 极致性能，自建 → Qdrant
另外，PostgreSQL 的 pgvector 插件、Elasticsearch 的向量搜索功能也是务实的选择——如果项目已经在用这些数据库，运维成本几乎为零。
第八讲：什么是多路召回？具体怎么做？
单路召回的局限性
向量检索擅长捕捉「语义相似性」，但在「精确匹配」方面有短板。比如用户搜索「iPhone 15 Pro Max 256GB」，向量检索可能把「iPhone 14 Pro Max 512GB」也搜出来。再比如搜索公司内部产品编号「PRD-2024-089」，纯靠语义相似度匹配不上。
多路召回的核心思想
既然一条路不保险，那就多走几条路，每条路各有侧重，最后把各路结果合并。
第一路：向量检索（Dense Retrieval） — 用 Embedding 模型做稠密向量相似度搜索。擅长语义匹配，是 RAG 系统的主力。
第二路：关键词检索（Sparse Retrieval / BM25） — 传统的全文检索方式，基于词频和文档频率计算相关性。擅长精确关键词匹配，对专有名词、产品编号、人名有天然优势。
第三路：知识图谱检索（可选） — 如果有结构化的知识图谱，可以用图查询做第三路召回。擅长实体关系推理，比如「A 公司的 CEO 是谁」。
混合检索的具体实现
多路召回的关键不只是「多走几条路」，还在于如何合并各路的结果。主流的合并方式有：
- 分数融合（Score Fusion）：将各路的分数归一化后加权求和。RRF（Reciprocal Rank Fusion）是最常用的方法。
- 重排序融合：把各路召回的结果合并后，统一用 Re-rank 模型做一次精排。
主流框架都有现成的混合检索支持：LangChain 的 EnsembleRetriever、LlamaIndex 的 QueryFusionRetriever、Weaviate 的混合搜索功能等。
高级召回策略
- 查询改写（Query Rewriting）：先用 LLM 把用户的问题改写成更适合检索的形式。比如「你们公司加班多吗」改写成「公司加班制度」「加班时间规定」「加班补贴政策」等多个查询。
- HyDE（Hypothetical Document Embedding）：先让 LLM 根据用户问题生成一个「假设性的答案文档」，再用这个假设文档的向量去检索。因为假设文档在表述上更接近真实的答案文档，检索效果通常更好。
- 多查询扩展（Multi-Query）：把一个问题用 LLM 改写成多个不同角度的子问题，分别检索后合并。
第九讲：怎么量化你的 RAG 效果？
为什么评估 RAG 比评估普通 LLM 更复杂？
因为 RAG 有两个环节都可能出问题：检索环节（找的文档对不对）和生成环节（模型有没有正确理解文档）。就像评价一道菜好不好，你得分别评估「食材新不新鲜」和「厨师的烹饪水平」，才能定位到问题。
检索质量的评估指标
召回率（Recall@K）：找全了没有？在所有相关的文档中，Top-K 结果里包含了多少。比如知识库中有 5 篇和问题相关的文档，Top-10 结果中包含了 4 篇，那 Recall@10 = 4/5 = 0.8。
精确率（Precision@K）：找对了没有？在 Top-K 结果中，有多少是真正相关的。比如 Top-10 结果中有 8 篇相关，那 Precision@10 = 8/10 = 0.8。
生成质量的评估指标
- Faithfulness（忠实度）：最重要的指标。模型生成的回答是否忠实于检索到的文档？有没有编造文档中不存在的信息？RAGAS 的评估方式是把回答拆分成独立陈述，逐个检查是否能从文档中找到支撑。10 个陈述中 8 个有支撑，忠实度就是 0.8。
- Answer Relevance（答案相关性）：回答是否真正回答了用户的问题？有没有跑题？
- Context Relevance（上下文相关性）：检索到的文档是否和用户的问题相关？
RAGAS：RAG 评估的事实标准
RAGAS 是目前 RAG 评估领域最流行的开源框架。核心思路是用一个更强大的 LLM（如 GPT-4）作为「裁判」，自动化评估 RAG 系统的输出质量。准备包含 question、contexts、answer、ground_truth 的数据集，调用 evaluate 函数即可。
其他评估工具：
- DeepEval：把 RAG 评估融入单元测试框架
- TruLens：提供深度可观测性和诊断能力
- ARES：用 LLM 生成合成评估数据
评估最佳实践
- 先建基线，再做优化 — 用一组测试数据建立性能基线，之后每次改动对比基线
- 测试数据要有代表性 — 包含简单事实查询、复杂推理、多跳问题、模糊问题等
- 定期评估，持续监控 — RAG 效果会随知识库更新和模型版本变化而波动
- 把评估自动化 — 融入 CI/CD 流程，每次更新自动跑评估
第十讲：什么是大模型幻觉？怎么降低幻觉？
什么是大模型幻觉？
幻觉（Hallucination）就是大模型自信地说出一些听起来很专业但实际上是编造的内容。幻觉不等于「错误」——如果模型说「我不知道」，那不叫幻觉。幻觉是不知道但假装知道，用流畅自信的语言编造错误信息。
OpenAI 科学家 Andrej Karpathy 有一段精彩观点：
「在某种意义上，幻觉正是大模型所做的一切。它是造梦机，我们通过提示词引导它的梦境。只有当梦境进入事实上不正确的领域时，我们才将其标记为『幻觉』。这不是 bug，而是大模型一直在做的事情。」
幻觉的类型
事实性幻觉（Factuality Hallucination）：生成内容与客观事实不符。分为内在幻觉（与输入上下文矛盾）和外在幻觉（无法从任何已知知识中验证）。
忠实性幻觉（Faithfulness Hallucination）：在 RAG 场景中更常见。模型虽然拿到了正确的检索文档，但生成回答时偏离了文档内容。
幻觉是怎么产生的？
- 数据层面：训练数据包含错误信息、偏见或过时知识。「垃圾进，垃圾出」。
- 训练层面：大模型的训练目标是「预测下一个 token」，追求生成流畅文本而非确保每句话正确。主流评估方式（多选题评测）鼓励模型「蒙答案」而非「承认不知道」。
- 推理层面：用户的提示词可能诱导幻觉。如果问题包含错误前提（「请介绍一下林黛玉的妹妹」），模型往往顺着错误前提编造。
RAG 是怎么降低幻觉的？
RAG 把大模型从「闭卷考试」变成了「开卷考试」：
- 注入真实知识：检索到的文档是真实资料，减少凭空编造。研究表明 RAG 能将事实性幻觉降低 20%-40%。
- 注意力机制偏向：当 Prompt 包含检索文档时，大模型约 70-80% 的注意力集中在检索片段上。
- 可追溯可验证：回答可追溯到具体文档来源。
但 RAG 不能完全消除幻觉。如果检索到错误文档、模型曲解了文档内容、或做了越界推断，幻觉依然会发生。
除了 RAG，还有哪些降低幻觉的方法？
方法一：Prompt 工程约束 — 成本最低、见效最快。
- 限制知识范围：「请仅基于以下参考资料回答，如果资料中没有相关信息，请直接回答『根据现有资料无法回答』」
- 要求标注来源：每个关键陈述后标注出处
- 鼓励承认不确定
方法二：输出验证（独立校验） — 用另一个 LLM 来检查回答是否忠实于检索文档。也叫 LLM-as-Judge。
方法三：领域微调 — 用领域数据做有监督微调（SFT），建立更可靠的知识体系。或用 RLHF 引导「诚实」——奖励模型「说真话」或「坦率承认不知道」。
方法四：不确定性量化（UQ） — 让模型对每个输出给出置信度分数。基于 token 概率、多次采样一致性、或模型内部状态（熵值）来估计。置信度低时触发人工审核或拒答。
方法五：GraphRAG 和 LightRAG — 2025 年的新方向。GraphRAG（微软提出）先从文档中提取实体和关系构建知识图谱，再基于图谱检索回答，适合需要全局理解的问题。LightRAG 是轻量版，解决了 GraphRAG 的 token 开销大、动态更新成本高的问题。
实际项目中的组合策略
核心原则是分层设防、按需组合：
| 防线 | 方法 | 成本 | 适用场景 |
|---|---|---|---|
| 第一道 | Prompt 工程约束 | 零成本 | 所有场景都应该做 |
| 第二道 | RAG 检索增强 | 中等成本 | 需要准确知识的场景标配 |
| 第三道 | 输出验证 | 额外延迟和成本 | 高风险场景（医疗、法律、金融） |
| 第四道 | 领域微调 + UQ | 成本最高 | 对准确性要求极高的场景 |
按风险等级分层管控
- 高风险（医疗诊断、法律建议、金融决策）：必须 RAG + 人工审核 + 明确免责声明 + 输出验证
- 中风险（客户服务、内容生产、代码辅助）：Prompt 约束 + RAG + 输出验证 + 置信度阈值
- 低风险（头脑风暴、草稿起草、创意生成）：基础 Prompt 优化即可
企业落地的核心原则只有一条：把幻觉当作工程问题而非模型缺陷，用系统设计来约束 AI 的行为边界。
总结
| # | 问题 | 核心要点 |
|---|---|---|
| 1 | RAG 是什么 | 检索增强生成，给大模型「开卷考试」，回答基于真实文档 |
| 2 | 工作流程 | 分索引阶段（离线建库）和查询阶段（在线检索+生成） |
| 3 | 微调 vs RAG | 微调是「内化知识」，RAG 是「外挂参考书」，两者互补 |
| 4 | 文档切割 | 从固定大小到语义切割，推荐先用递归字符切割起步 |
| 5 | Re-rank | 用 Cross-Encoder 对检索结果做精排，准确率提升 30-50% |
| 6 | Embedding | 从 Word2Vec 到 BERT 再到 BGE-M3，技术不断演进 |
| 7 | 向量数据库 | Milvus、Pinecone、Weaviate 等各有侧重，按需选型 |
| 8 | 多路召回 | 向量检索 + BM25 混合检索，效果比单路好 10-30% |
| 9 | 效果量化 | 用 RAGAS 等框架评估 Faithfulness、Relevance 等核心指标 |
| 10 | 大模型幻觉 | RAG 是降低幻觉的核心手段，但不能完全消除，需要组合策略 |
RAG 技术这一两年发展非常快，从最基础的 Naive RAG 到结合 GraphRAG、Agentic RAG 等高级架构，技术栈在不断演进。但万变不离其宗，本文讲的这些核心概念是所有 RAG 系统的基石，把基础打牢了，后面的进阶技术学起来就会事半功倍。