一、RAG 解决了什么问题？
在 RAG 出现之前，依赖纯大模型的应用常常面临以下问题：
1. 知识过时（无法实时更新）
大模型的知识完全来源于其训练数据集。一旦训练完成，模型的知识库就固化了。这意味着它不知道最新的新闻事件（例如今天刚发生的科技突破），不了解你公司内部的规章制度、产品文档或项目报告，也无法获取刚刚更新的 API 接口文档或软件版本说明。
解决：为模型接入一个可实时更新的外部知识库。RAG 正是实现这一目标的桥梁。
2. 幻觉问题（Hallucination）
大模型有时会"自信地"编造出看似合理但完全错误或不存在的事实、引用或数据。这在需要高准确性的场景（如客服、医疗、法律咨询）中是致命的。
解决：强制模型在生成答案前，先"查阅"权威的外部资料，并基于这些资料进行回答，从而将"凭空编造"转变为"有据可依"。
3. 无法使用私有/专有数据
每个企业、团队乃至个人都拥有大量未公开的私有数据，例如企业内部的知识库和Wiki、客户通信记录和合同，以及个人的笔记、邮件和收藏。传统的大模型无法直接访问这些数据，因为它们不在训练集中。微调（Fine-tuning）虽然是一种方法，但成本高、流程复杂，且难以频繁更新。
解决：通过 RAG，可以安全、灵活地将这些私有数据作为检索源，让大模型在需要时从中获取信息，而无需改变模型本身。
4. 上下文窗口（Context Window）有限
即使是最先进的长上下文模型，其能处理的 Token 数量也有上限。试图将整个数据库或长篇文档全部塞进提示（Prompt）中是不现实的，不仅会触及长度限制，还会带来极高的计算成本和响应延迟。
解决：RAG只检索与当前问题最相关的信息片段，将其作为上下文提供给模型。
总结： RAG 本质上是为大模型外挂了一个动态、可扩展、可控制的外部记忆系统，增强了大模型的表现。就像运动员穿更好的装备，可以发挥出更高的运动水平。
二、RAG 是什么？
RAG = Retrieval（检索） + Augmented（增强） + Generation（生成）
Retrieval（检索） ：当用户提出一个问题时，系统会从一个庞大的知识库（通常是向量数据库）中寻找与问题语义最相关的文档片段。
Augmented（增强） ：将检索到的相关文档片段作为额外的"上下文"，与用户的原始问题一起构造成一个新的、信息更丰富的提示词。
Generation（生成） ：大模型接收这个被"增强"后的提示词，基于其中提供的上下文信息生成准确、相关且有针对性的答案。
核心思想
先查询外部知识库获取相关事实，再基于这些事实组织语言生成答案。
与纯 LLM 的对比：
| 模式 | 工作机制 | 优点 | 缺点 |
|---|---|---|---|
| 纯大模型 | 完全依赖训练时记忆的参数化知识。 | 响应速度快，通用性强。 | 知识陈旧，易产生幻觉，无法访问私有数据。 |
| RAG | "检索" + "生成"。先查找资料，再基于资料回答。 | 信息实时、准确、可溯源，支持私有数据。 | 流程稍复杂，结果依赖检索质量。 |
三、RAG 基本流程详解
RAG 的完整流程可以分为两个主要阶段：离线准备阶段和在线查询阶段。
【离线阶段】文档 → 分片 → 向量化 → 建索引 (存入向量数据库)
【在线阶段】问题 → 向量化 → 召回 → 重排 → 构造提示 → 生成答案
阶段一：离线准备（数据索引）
这个阶段的目标是将原始知识（文档）处理成易于快速检索的格式。通常只需在数据更新时执行一次。本质上就是把文本处理为向量，之后存入向量数据库。
1. 文档加载与预处理
从各种来源（PDF、Word、网页、数据库）加载文档，并进行基础清洗（去除无关字符、格式化等）。
2. 文档分片（Chunking）
常见的分片策略包括：固定大小分片，即按固定Token数或字符数切割，这种方法简单但可能割裂语义完整的段落；基于分隔符分片，按段落、标题、句子等自然分隔符切割，能更好地保持语义完整性；滑动窗口分片，在固定大小分片的基础上让相邻分片有一定重叠，避免关键信息恰好被切在分片边缘；以及语义分片，使用模型判断语义边界进行切割，更智能但计算成本更高。
3. 向量化（Embedding）
使用 Embedding 模型（如 OpenAI 的 text-embedding-ada-002，或开源的 BGE、Sentence Transformers）将每个文本分片转换为一个高维向量（例如，1536 维）。这个向量在数学空间中代表了该文本的语义。
核心作用：将文本间的"语义相似度"比较，转化为向量间的距离计算（如余弦相似度、欧氏距离）。语义越相近的文本，其向量在空间中的距离就越近。
4. 存储与索引
将生成的向量及其对应的原始文本片段（以及元数据，如来源、标题、页码等）存储到向量数据库中。数据库会为这些向量建立高效的索引，以实现快速的近似最近邻搜索。常用的工具包括FAISS（Facebook）、Milvus、Pinecone（云服务）、Weaviate、Chroma（轻量级）等。
一个简化的向量数据库表示如下，其中每行左边是原始文本片段，右边是其对应的向量（此处为示意，实际向量维度很高）：
| 原始文本片段 | 对应向量（简化表示） |
|---|---|
| “RAG 通过检索外部知识来增强大模型的生成能力。” | [0.23, -0.41, 0.89, -0.12, 0.05, ...] |
| “向量化（Embedding）将文本转换为高维空间中的点。” | [-0.31, 0.77, 0.02, 0.45, -0.88, ...] |
| “检索时，系统计算查询向量与库中向量的相似度。” | [0.12, -0.65, 0.33, 0.91, -0.27, ...] |
| “分片（Chunking）是将长文档切分为较小片段的过程。” | [0.44, 0.18, -0.52, 0.07, 0.63, ...] |
至此，知识库已经准备就绪，静待查询。
阶段二：在线查询（检索与生成）
这个阶段在用户每次提问时实时发生，目标是从已索引的知识中快速找到答案并生成回复。
1. 查询向量化
将用户的自然语言问题（Query）使用与离线阶段相同的 Embedding 模型转换为一个查询向量。
2. 召回（Retrieval）
在向量数据库中进行相似性搜索。系统计算查询向量与数据库中所有存储向量之间的距离，返回距离最近（即语义最相似）的 Top-K 个文本分片。这就是初步的"候选集"。
3. 重排（Reranking）
初步召回基于向量相似度，这有时被称为"粗召回"。它可能因为语义匹配不够精确而引入一些相关性稍差的片段。 重排使用一个更精细的模型（通常是 Cross-Encoder，它能同时处理两个文本并直接输出相关性分数），对 Top-K 个候选片段进行重新打分和排序，筛选出最精准的 Top-N 个片段（通常 N < K）。可以理解为对召回的结果进行进一步筛选，找到最相关的片段。
4. 上下文构造与提示工程（Augment）
将重排后得到的最相关文本片段，与用户的原始问题结合起来，构造成一个给大模型的指令性提示（Prompt）。这是"增强"的具体体现。
一个经典的 Prompt 模板示例：
你是一个专业的助手，请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答，请直接说明"根据已有信息无法回答该问题"。
上下文信息：
{片段1的文本内容}
{片段2的文本内容}
...
{片段N的文本内容}
用户问题：{用户原始问题}
请基于上述上下文信息回答：
5. 生成（Generation）
将构造好的提示发送给大模型（如 DeepSeek、GPT、Claude、本地部署的 Llama 等）。模型会基于你提供的上下文来生成答案，并在答案中引用或溯源这些上下文信息，从而极大地减少幻觉，提高可信度。
四、进阶方向与应用
RAG 本身是一个强大的范式，与其他技术结合可以产生更强大的应用：
混合搜索（Hybrid Search），结合稀疏检索（如基于关键词的BM25）和密集检索（向量检索），兼顾精确关键词匹配和深层语义匹配以提高召回率
多跳检索（Multi-hop Retrieval），对于复杂问题可能需要连续检索多个相关文档，像"侦探破案"一样逐步推理出最终答案
RAG与智能体（Agent）结合，让智能体主动使用RAG作为其"记忆"或"知识查询"工具，完成更复杂的任务规划与执行
多模态RAG，检索源不仅限于文本，还可以是图像、音频、视频的嵌入向量，实现跨模态的知识问答
递归检索与摘要，先检索大型分片定位范围，再在更细粒度上检索，或对检索到的内容进行摘要后再喂给模型
权限感知的RAG，在企业场景下根据用户身份动态过滤检索内容，实现数据安全
五、技术方案与实现选型
在构建一个完整的 RAG 系统时，每个环节都有多种技术选项。下面我们将按照 RAG 的标准流程，逐一介绍每个部分可以使用的具体技术、工具以及依赖的模型从哪里获取。
1. 文档加载（Document Loading）
目标：从各种格式和来源（PDF、Word、Excel、PPT、HTML、Markdown、数据库、API 等）中提取文本内容。
常用工具：
- LangChain：提供了丰富的
Document Loaders，支持上百种文件格式和外部服务（如 Google Drive、Notion、GitHub 等）。 - LlamaIndex：内置了多种数据连接器（
Data Connectors），可以轻松接入本地文件、云存储、知识库等。 - Apache Tika：一个强大的内容分析工具包，特别适合解析复杂的办公文档格式。
- Unstructured：专注于从非结构化文档（如 PDF、图片中的文字）中提取文本和元数据。
此阶段通常不涉及深度学习模型，主要依赖解析库。如需 OCR（光学字符识别），可选用 Tesseract、PaddleOCR 或云服务（如百度 OCR、腾讯 OCR）。
2. 文本分割（Text Chunking）
目标：将长文档切分成语义连贯、大小适中的片段（Chunks），以便后续向量化和检索。
常用工具：
- LangChain Text Splitters：支持按字符、Token、句子、段落分割，并提供递归分割、重叠窗口等高级功能。
- LlamaIndex Node Parsers：除了基本分割，还能保留文档的层次结构（如标题、段落关系）。
- 语义分割库：如
semantic-text-splitter，利用句子嵌入的相似度变化来寻找自然边界。
分割策略：
- 固定大小分片：简单，但可能割裂语义。
- 基于分隔符分片：按段落、标题等自然分隔符切割。
- 滑动窗口分片：保留相邻分片的重叠，避免边缘信息丢失。
- 语义分片：使用轻量级模型判断语义边界，效果最佳但计算开销稍大。
模型依赖：语义分割可能需要一个小型的句子嵌入模型（例如 sentence-transformers/all-MiniLM-L6-v2）来计算句子间的相似度。这类模型可从 Hugging Face Hub 直接下载。
3. 向量化（Embedding）
目标：将文本片段转换为高维向量（嵌入），使得语义相似的文本在向量空间中距离相近。
常用模型与服务：
- OpenAI Embedding API：
text-embedding-3-small、text-embedding-3-large等，性能稳定，但需调用 API 并付费。 - 开源 Sentence Transformers 模型：
- BGE (BAAI/bge-large-zh)：中文社区表现优异的模型。
- all-MiniLM-L6-v2：轻量级，英文通用场景。
- multilingual-e5：支持多语言。
- GTE (General Text Embeddings)：在检索任务上表现突出。
- Cohere Embed API：提供多语言嵌入服务。
- 云端厂商的嵌入服务：阿里云、腾讯云、百度文心等均提供了嵌入模型 API。
如何获取：
- 开源模型可通过 Hugging Face Hub 直接下载并使用
sentence-transformers库加载。 - API 服务需注册相应平台并获取 API Key。
4. 向量存储（Vector Storage）
目标：存储向量和对应的原始文本及元数据，并提供高效的相似性搜索（近似最近邻，ANN）能力。
常用数据库：
- 本地/自托管：
- FAISS（Facebook）：高性能向量检索库，适合单机或小规模部署。
- Chroma：轻量级，易于使用，内置简单的持久化和查询接口。
- Qdrant：支持丰富的数据类型和过滤条件，性能优秀。
- Milvus：专为大规模向量搜索设计，支持分布式部署和丰富的索引算法。
- Weaviate：兼具向量搜索和图数据库能力，支持模块化扩展。
- 云托管服务：
- Pinecone：全托管向量数据库，无需运维，弹性伸缩。
- Zilliz Cloud（基于 Milvus）：提供云原生的 Milvus 服务。
- 阿里云 OpenSearch、腾讯云 VectorDB：国内云厂商的向量检索服务。
选择建议：根据数据规模、性能要求、运维能力和预算进行选择。
5. 检索（Retrieval）
目标：给定查询向量，从向量数据库中快速找出最相似的 Top-K 个文本片段。
技术实现：
- 相似度度量：余弦相似度（最常用）、内积、欧氏距离。
- 索引算法：HNSW（Hierarchical Navigable Small World）、IVF（Inverted File Index）、PQ（Product Quantization）等，这些已在向量数据库内部实现。
- 混合检索（Hybrid Search）：结合密集检索（向量相似度）和稀疏检索（如 BM25 关键词匹配），可显著提升召回率。工具如
rank_bm25、Elasticsearch。
工具集成：大多数向量数据库已内置高效的 ANN 检索接口。LangChain 和 LlamaIndex 也提供了统一的检索器抽象，方便切换后端。
6. 重排（Reranking）
目标：对初步召回的 Top-K 个结果进行精细化排序，筛选出最相关的 Top-N 个片段（N<K），提升最终答案的准确性。
常用模型：
- Cross-Encoder：一种能够同时编码两个文本并直接输出相关性分数的模型，比双塔式 Embedding 模型更精准。
- MS-MARCO 系列：如
cross-encoder/ms-marco-MiniLM-L-6-v2，在英文检索数据集上训练。 - BGE Reranker：BAAI 发布的专门用于重排的模型，支持中英文。
- Cohere Rerank API：云服务，简单易用。
- MS-MARCO 系列：如
- 其他方法：也可使用更强大的 LLM（如 GPT）对候选片段进行相关性评估，但成本较高。
如何获取：Cross-Encoder 模型同样可从 Hugging Face Hub 下载，并使用 sentence-transformers 库加载。
7. 生成（Generation）
目标：基于检索和重排得到的上下文，生成自然、准确、符合要求的答案。
常用模型：
- 云端大模型 API：
- OpenAI GPT 系列
- DeepSeek API（DeepSeek-V4-pro）
- Claude API（Claude Sonnet，Claude Opus）
- 百度文心一言、阿里通义千问、腾讯混元等国内大模型
- 开源大模型（本地部署）：
- Llama 系列（Llama 4等）
- ChatGLM（智谱 AI）
- Qwen（通义千问开源版）
- Yi（零一万物）
- Mistral 系列
提示词工程：构造清晰的 Prompt 模板，指示模型严格依据上下文回答，并注明引用来源。这是 RAG 生成质量的关键。
8. 模型来源与依赖汇总
| 组件 | 主要模型/工具 | 来源/获取方式 |
|---|---|---|
| 文档加载 | LangChain, LlamaIndex, Apache Tika | GitHub, 官方文档，包管理器（pip, npm） |
| 文本分割 | LangChain Text Splitters, 语义分割器 | 同上，Hugging Face Hub（用于语义分割模型） |
| 向量化 | OpenAI Embedding, Sentence Transformers (BGE, all-MiniLM) | Hugging Face Hub, OpenAI API, 各云平台 |
| 向量存储 | FAISS, Chroma, Milvus, Pinecone | GitHub, 官方文档，云控制台 |
| 检索 | 向量数据库内置索引，BM25 | 同上 |
| 重排 | Cross-Encoder, BGE Reranker | Hugging Face Hub, Cohere API |
| 生成 | GPT-4, Claude, Llama, DeepSeek | 各大模型平台 API，Hugging Face Hub（开源模型） |
部署建议：
- 快速原型：使用 LangChain/LlamaIndex + OpenAI API + Chroma，几行代码即可搭建。
- 生产级、注重成本与数据安全：采用开源模型（如 BGE + Llama）本地部署，搭配 Milvus 或 Qdrant 作为向量数据库。
- 企业级、需要高可用与弹性：选择云托管服务（Pinecone、Zilliz Cloud）结合云厂商的大模型 API。
