sanbuphy
3af119a598
- 新增 Vibe Coding 全栈相关演示组件 (DeveloperSkillShift, FrontendTriad, BackendCore 等) - 新增 RAG 相关组件 (RAGPipeline, ChunkingStrategy, Retrieval 等) - 新增 Embedding & Vector 相关组件 (EmbeddingConcept, VectorSimilarity 等) - 新增 AI Native App 设计组件 (AINativeArch, PromptDesign 等) - 新增 Infrastructure as Code 组件 (IaCConcept, TerraformWorkflow 等) - 新增 DNS & HTTPS 演示组件 (DnsResolution, HttpsHandshake 等) - 新增 Model Finetuning 组件 (FinetuningPipeline 等) - 更新多个章节的 markdown 内容，集成交互式演示
162 lines
9.0 KiB
Markdown
162 lines
9.0 KiB
Markdown
# RAG：检索增强生成
|
||
|
||
::: tip 前言
|
||
**为什么 ChatGPT 有时候会"一本正经地胡说八道"？** 大语言模型的知识来自训练数据，但训练数据有截止日期，也不包含你公司的内部文档。RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的核心技术——让 AI 在回答之前，先去"查资料"。
|
||
:::
|
||
|
||
**这篇文章会带你学什么？**
|
||
|
||
学完这章后，你将获得：
|
||
|
||
- **核心概念理解**：明白 RAG 是什么、为什么需要它，以及它如何解决大模型的"幻觉"问题
|
||
- **完整流程认知**：掌握从文档加载、分块、向量化到检索、生成的端到端流程
|
||
- **技术选型能力**：了解不同分块策略、检索方法的优劣，能根据场景做出选择
|
||
- **架构演进视角**：理解 RAG 从 Naive 到 Advanced 再到 Modular 的演进路线
|
||
- **实践决策能力**：知道什么时候该用 RAG、什么时候该用微调
|
||
|
||
| 章节 | 内容 | 核心概念 |
|
||
|-----|------|---------|
|
||
| **第 1 章** | RAG 基础流程 | 索引、检索、生成三阶段 |
|
||
| **第 2 章** | 文本分块策略 | 固定分块、语义分块、递归分块 |
|
||
| **第 3 章** | 检索技术 | 向量检索、关键词检索、混合检索 |
|
||
| **第 4 章** | 架构演进 | Naive RAG → Advanced RAG → Modular RAG |
|
||
| **第 5 章** | RAG vs 微调 | 两种方案的适用场景对比 |
|
||
|
||
---
|
||
|
||
## 0. 全景图：为什么大模型需要"查资料"？
|
||
|
||
想象你是一个博学的教授，读过无数书籍。但如果有人问你"昨天公司的销售数据是多少"，你肯定答不上来——因为这些信息不在你读过的书里。
|
||
|
||
大语言模型面临的就是同样的困境：
|
||
|
||
- **知识有截止日期**：GPT-4 的训练数据截止到某个时间点，之后发生的事它不知道
|
||
- **缺乏私有知识**：你公司的内部文档、产品手册、客户数据，模型从未见过
|
||
- **容易产生幻觉**：当模型不确定答案时，它倾向于"编造"一个看起来合理的回答
|
||
|
||
::: tip RAG 的核心思想
|
||
RAG 的解决方案非常直觉：**在让模型回答之前，先帮它找到相关的参考资料**。就像开卷考试——你不需要记住所有知识，只需要知道去哪里找、怎么找。
|
||
|
||
RAG = 检索（Retrieval）+ 增强（Augmented）+ 生成（Generation）
|
||
:::
|
||
|
||
---
|
||
|
||
## 1. RAG 基础流程：索引、检索、生成
|
||
|
||
RAG 的工作流程可以分为两个阶段：**离线索引**和**在线查询**。
|
||
|
||
离线阶段就像图书馆的编目工作——把所有书籍分类、编号、上架，方便日后查找。在线阶段则是读者来图书馆查资料的过程——根据问题找到相关书籍，然后综合信息给出回答。
|
||
|
||
<RAGPipelineDemo />
|
||
|
||
::: tip 三个核心阶段
|
||
1. **索引阶段（Indexing）**：将原始文档加载、清洗、分块，然后通过嵌入模型转化为向量，存入向量数据库。这是一次性的准备工作。
|
||
2. **检索阶段（Retrieval）**：用户提问时，将问题也转化为向量，在向量数据库中搜索最相似的文档片段。
|
||
3. **生成阶段（Generation）**：将检索到的文档片段和用户问题一起拼接为 Prompt，交给大模型生成最终回答。
|
||
:::
|
||
|
||
| 阶段 | 输入 | 输出 | 关键技术 |
|
||
|------|------|------|---------|
|
||
| 索引 | 原始文档 | 向量数据库 | 文本分块、嵌入模型 |
|
||
| 检索 | 用户问题 | Top-K 文档片段 | 向量相似度、重排序 |
|
||
| 生成 | 问题 + 上下文 | 最终回答 | Prompt 工程、LLM |
|
||
|
||
---
|
||
|
||
## 2. 文本分块：把大象装进冰箱
|
||
|
||
文本分块是 RAG 中最容易被忽视、却对效果影响最大的环节。为什么需要分块？因为大模型的上下文窗口有限，我们不可能把整本书塞进去。更重要的是，**分块的质量直接决定了检索的质量**。
|
||
|
||
想象你在图书馆找一本书的某个知识点。如果整本书是一个"块"，检索到了也没用——你还是得翻遍全书。但如果按章节甚至段落分块，就能精准定位到你需要的内容。
|
||
|
||
<ChunkingStrategyDemo />
|
||
|
||
::: tip 分块策略的选择
|
||
- **固定大小分块**：按字符数或 token 数切分，简单粗暴但可能切断语义
|
||
- **递归分块**：先按段落分，段落太长再按句子分，保持语义完整性
|
||
- **语义分块**：用嵌入模型判断语义边界，相似度突变处切分
|
||
- **文档结构分块**：利用 Markdown 标题、HTML 标签等结构信息分块
|
||
|
||
没有"最好"的分块策略，只有最适合你数据的策略。一般建议从递归分块开始，chunk 大小 200-500 tokens，overlap 10-20%。
|
||
:::
|
||
|
||
---
|
||
|
||
## 3. 检索技术：如何找到最相关的内容？
|
||
|
||
分块完成后，下一个关键问题是：**用户提了一个问题，怎么从成千上万个文档片段中找到最相关的那几个？**
|
||
|
||
这就像在一个巨大的图书馆里找书。你可以按书名关键词搜索（关键词检索），也可以描述你想要的内容让图书管理员帮你找（语义检索），最好的方式是两者结合（混合检索）。
|
||
|
||
<RetrievalDemo />
|
||
|
||
| 检索方式 | 原理 | 优势 | 劣势 |
|
||
|---------|------|------|------|
|
||
| 关键词检索（BM25） | 基于词频和逆文档频率 | 精确匹配、速度快 | 无法理解语义、同义词失效 |
|
||
| 向量检索 | 基于嵌入向量的余弦相似度 | 理解语义、支持模糊匹配 | 对专有名词不敏感 |
|
||
| 混合检索 | 融合关键词和向量检索结果 | 兼顾精确和语义 | 需要调权重、复杂度高 |
|
||
|
||
::: tip 重排序（Reranking）
|
||
检索到候选文档后，通常还需要一步"重排序"。初始检索追求召回率（尽量不遗漏），重排序追求精确率（把最相关的排到最前面）。常用的重排序模型有 Cohere Rerank、BGE Reranker 等，它们使用交叉编码器对 query-document 对进行精细打分。
|
||
:::
|
||
|
||
---
|
||
|
||
## 4. 架构演进：从简单到智能
|
||
|
||
RAG 技术在短短两年内经历了三代演进，每一代都在解决上一代的痛点。
|
||
|
||
<RAGArchitectureDemo />
|
||
|
||
::: tip 三代 RAG 架构对比
|
||
- **Naive RAG（2023）**：最基础的"索引→检索→生成"流程，实现简单但效果有限。问题包括：检索质量不稳定、无法处理复杂查询、容易引入噪音上下文。
|
||
- **Advanced RAG（2024）**：在 Naive RAG 基础上增加了查询改写、混合检索、重排序、上下文压缩等优化环节，显著提升了检索精度和生成质量。
|
||
- **Modular RAG（2025）**：将 RAG 拆解为可插拔的模块，支持路由判断、自适应检索、自我反思等高级能力。可根据查询类型动态选择最优处理流程。
|
||
:::
|
||
|
||
---
|
||
|
||
## 5. RAG vs 微调：该选哪个？
|
||
|
||
当你想让大模型掌握特定领域的知识时，通常有两条路：RAG 和微调（Fine-tuning）。它们不是互斥的，而是互补的。
|
||
|
||
打个比方：**微调像是让学生上培训班**，把知识内化到大脑里；**RAG 像是给学生发参考书**，考试时可以翻阅。两种方式各有优劣，关键看你的具体需求。
|
||
|
||
<RAGvsFineTuningDemo />
|
||
|
||
| 维度 | RAG | 微调 |
|
||
|------|-----|------|
|
||
| 知识更新 | 实时更新，改文档即可 | 需要重新训练 |
|
||
| 成本 | 低（无需 GPU 训练） | 高（需要训练资源） |
|
||
| 可解释性 | 高（可追溯来源） | 低（知识内化在权重中） |
|
||
| 适用场景 | 知识库问答、文档检索 | 风格迁移、特定任务优化 |
|
||
| 幻觉控制 | 较好（有参考依据） | 一般（仍可能幻觉） |
|
||
|
||
::: tip 实践建议
|
||
大多数场景下，**先试 RAG**。RAG 的优势在于：不需要训练、知识可实时更新、回答可追溯来源。只有当你需要改变模型的"行为模式"（比如输出格式、语言风格、推理方式）时，才考虑微调。最强的方案往往是 **RAG + 微调** 的组合。
|
||
:::
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
RAG 是当前让大模型"落地"最实用的技术之一。它的核心价值在于：让模型的回答有据可查、知识可实时更新、幻觉可有效控制。
|
||
|
||
回顾本章的关键要点：
|
||
|
||
1. **RAG 解决的核心问题**：大模型知识过时、缺乏私有数据、容易幻觉
|
||
2. **三阶段流程**：索引（离线准备）→ 检索（在线查找）→ 生成（综合回答）
|
||
3. **分块是基础**：分块质量直接决定检索质量，选择合适的分块策略至关重要
|
||
4. **检索是关键**：混合检索 + 重排序是目前效果最好的组合
|
||
5. **架构在演进**：从 Naive RAG 到 Modular RAG，系统越来越智能和灵活
|
||
6. **RAG 和微调互补**：大多数场景先试 RAG，需要改变模型行为时再考虑微调
|
||
|
||
## 延伸阅读
|
||
|
||
- [LangChain RAG 教程](https://python.langchain.com/docs/tutorials/rag/) - 最流行的 RAG 框架实战指南
|
||
- [LlamaIndex 文档](https://docs.llamaindex.ai/) - 专注于 RAG 的框架，提供丰富的数据连接器
|
||
- [RAG Survey 论文](https://arxiv.org/abs/2312.10997) - 全面的 RAG 技术综述
|
||
- [Chunking Strategies](https://www.pinecone.io/learn/chunking-strategies/) - Pinecone 的分块策略详解
|
||
- [向量数据库对比](https://superlinked.com/vector-db-comparison) - 主流向量数据库的功能对比
|