我不信看完这篇你还不懂RAG：RAG技术概述

最新推荐文章于 2025-04-11 10:02:30 发布

python_知世

最新推荐文章于 2025-04-11 10:02:30 发布

阅读量940

点赞数 19

文章标签：人工智能深度学习 AI大模型 RAG LLM 大语言模型大模型技术

本文链接：https://blog.youkuaiyun.com/zhishi0000/article/details/146395813

版权

RAG的基本概念

*检索增强生成*（Retrieval Augmented Generation），简称 RAG。它旨在通过在生成回答前主动检索相关信息,将实时、准确的知识作为上下文提供给模型,从而显著提升了回答的质量和可靠性。

RAG能缓解LLM的痛点：

\1. 知识时效性：突破训练数据时空限制。因可借助知识库内容来增强生成。
\2. 领域适应性：快速接入垂直私域知识。
\3. 事实准确性：降低模型幻觉风险

RAG的工作流程

一个经典的RAG（Naive RAG）工作流程宏观地可被分为两部分：索引、检索与生成。

• 索引部分（通常也是离线部分）
1. \1. 加载：根据不同的数据源选择合适的加载器，加载数据得到文档；
2. \2. 切块：使用文本切块器将文档切分成更小的片段，使用小片段一方面可以更好地匹配用户问题，同时也可以适应模型的有限上下文窗口；
3. \3. 存储：存储和索引切片，以便在检索时能够快速找到相关的数据，通常使用 Embeddings 模型和向量数据库（VectorStore）来完成。
• 检索与生成部分（通常是在线部分）
1. \1. 检索：给定用户输入，使用检索器从存储中检索相关的切片；
2. \2. 生成：使用包括用户输入的问题和检索到的文档切片合成的提示调用 LLM 来生成答案。

如下图所示，是一个Naive RAG 的工作流程示意图（流程步骤命名可能不一致）。

RAG核心模块

加载

私域数据可能是以不同形态存在，如：Word、PDF、Excel表格、TXT文档、Markdown、图像等。使用合适的数据加载器加载这些数据是基础（如图像和PDF数据还需利用OCR），在此之上，还有合适的数据预处理工作，如：数据清洗、规范化、元数据获取（数据元信息：文件名、时间、标题等）。

切块

为什么要切块？第一是因为Embedding模型的Token限制。第二是因为语义完整性对检索效果有很直接的影响。通俗理解，把本应该是一部分的文本切成两块，单看其中一块都感觉少一些信息，那经过Embedding模型生成的向量也会如此。

常见切块策略

固定大小分块

按照固定的字数、词数或标记数（token）把文档切成小块。比如，每500字一块。为了避免句子被拦腰截断，通常会在相邻两块之间留点重叠（比如重叠100字）。

优点：

• 操作简单

缺点：

• 可能会破坏语义完整性

适合场景

• 快速验证。性能要求不高。文档内容比较零散、不太讲究上下文。

语义分块

根据语义来切。具体做法是：先把文档分成句子或段落等有意义的单元。为每个单元生成一个向量表示。比较相邻单元（近邻算法获取）的相似度：如果很相似，就合并成一块；如果差异大了，就另起一块。

优点：

• 保留了内容的自然流畅性和完整思路。
• 每块内容更丰富，检索时能抓住更相关的部分，回答更靠谱。

缺点：

• 寻找近邻块和相似度计算引入了计算量。且相似度的阈值，不是通用的，即不同文档都可能不同。

适合场景：

• 当文档有清晰的主题或段落划分时，比较适合它切分原理。

递归分块

先按文档的自然分隔（比如段落或章节）分成大块。如果某块太大（超过预设大小），就再细分，直到每块都合适为止。

优点：

• 既保留了文档的自然结构，又能控制块的大小

缺点：

• 计算量稍微多一些

适合场景：

• 文档有层次结构，又需要控制大小的时

基于文档结构的分块

直接利用文档的天然结构，比如按标题、章节或段落来分块。每块对应一个逻辑单元，比如一个章节或一个小标题下的内容。

优点：

• 保留了文档的原有逻辑布局
• 文本块边界清晰，管理方便

缺点：

• 前提是文档得有明确的结构，适用范围小了
• 分块大小可能不均匀

适合场景：

• 有天然明显的文档结构，如：学术论文、技术文档等结构性强的文档较适用

基于LLM的分块

利用LLM让它根据内容生成独立、有意义的小块。

优点：

• 分得最聪明，语义准确性最高，因为LLM能理解深层含义
• 每块内容质量极佳

缺点：

• 计算量大，成本高
• LLM的处理Token有限

使用场景：

• 对分块效果要求较高且预算充足的情况

通常，语义分块往往是个不错的起点，它在语义完整性和效率之间平衡得很好。不过，没有最好的策略，只有最符合实际需求的策略。

储存

嵌入（Embedding）

Embedding 是机器学习和自然语言处理（NLP）领域中的一个重要概念，它是指将离散的、高维度的数据（如单词、短语或类别标签、图片、视频、音频）映射到一个连续的、低维度的向量空间中。这些向量通常被设计成能够捕捉原始数据之间的语义关系。在机器学习中，我们经常需要处理高维数据，这些数据直接处理起来非常复杂。通过embedding，我们可以将这些数据转换为低维的向量，这些向量在计算上更高效，并且能够保留数据的重要信息。

Embedding单独拎出来都是一个研究领域，这里不做深入和展开了。Embedding在RAG中的功能是要把分块后的文档和用户输入的问题进行向量化，并基于此进行后续的任务，如：通过相似度检索。

使用的Embedding模型对RAG的效果影响也是直接的。Embedding模型的选择也是需要根据实际任务需求去选择的。因为，不同Embedding模型的特性是不一样的，有的支持多种语言，有的针对长文本做了优化，有的针对短文本做了优化，有的针对代码做了优化。

可以借助HuggingFace上的MTEB Leaderboard去挑选适合实际任务且评估靠前的模型。也可以便捷地使用云商提供的API。

可参考实践步骤：

\1. 对实际任务需求进行分析： 明确任务类型、数据领域、语言、硬件条件
1. \1. 任务类型：
2. 1. \1. 问答系统：需要高精度的语义匹配（如 text-embedding-ada-002、bge-large-en）；
  2. \2. 长文档检索：需处理长上下文（如 longformer 或分块策略）；
  3. \3. 跨语言检索：需多语言支持（如 paraphrase-multilingual-mpnet-base-v2）；
  4. \4. 领域特定任务：法律、医疗等领域需领域适配模型（如 LegalBERT、BioBERT）。
3. \2. 数据特性：
4. 1. \1. 文本长度：短文本（如搜索关键词）和长文本（如段落）可能需要不同模型；
  2. \2. 领域特异性：通用模型还是领域微调模型；
  3. \3. 多模态数据：若涉及图片、表格等，需多模态嵌入模型（如 CLIP）。
\2. 候选模型初筛：根据需求从MTEB Leaderboard或社区推荐中选择 2-3 个模型
\3. 本地进行测试并评估：
1. \1. 使用少量样本数据进行测试并评估，如：召回率（recall@k）、命中率（Hit Rate）
2. \2. 测试推理的效率，如：QPS
3. \3. 测试对硬件的压力，如：显存占用
\4. 结合实际任务需求可选是否要对Embedding模型进行微调
\5. 平衡精度、速度、成本选择合适模型或方案

向量数据库

向量化后构建索引，并写入数据库的过程可以概述为数据入库过程。不同的向量数据库也各有所长，同样的，没有最好的只有最合适的。以下是当前常用的向量数据库及其特点，以及选型建议：

以下内容由LLM生成

常用向量数据库及其特点

\1. Milvus

• 特点：
- • 开源专用向量数据库：由Zilliz开发，支持超大规模数据（数十亿向量）。
- • 高性能与分布式：支持多种索引（如IVF、HNSW），可水平扩展，适合高吞吐量场景。
- • 云原生支持：与Kubernetes集成，适合云环境部署。
- • 多语言SDK：Python、Java、Go等接口，易集成。
- • 适用场景：大型生产环境、需要分布式扩展的场景（如电商推荐、知识库检索）。
• 优缺点：
- • 优点：性能强、可扩展性高、社区活跃。
- • 缺点：部署复杂度较高，对资源要求较大。

\2. FAISS

• 特点：
- • 开源库：由Facebook开发，专注于高效向量相似度搜索。
- • 轻量级：适合中小型数据集（百万级向量以内）。
- • GPU加速：支持GPU加速，适合批量查询。
- • 灵活性：提供多种索引算法（如Flat、IVF、HNSW、PQ）。
- • 适用场景：快速原型开发、小规模生产环境。
• 优缺点：
- • 优点：轻量、易用、计算速度快。
- • 缺点：缺乏分布式能力，扩展性有限。

\3. Chroma

• 特点：
- • 轻量级开源工具：适合快速开发和小型项目。
- • 易集成：与Python生态（如LangChain）深度集成。
- • 内存/文件存储：支持内存存储（速度极快）或持久化到文件。
- • 适用场景：研究、教学、小型RAG系统。
• 优缺点：
- • 优点：简单易用、启动快速。
- • 缺点：不支持分布式，数据量大时性能下降。

\4. Pinecone

• 特点：
- • 商用专用数据库：提供托管服务，开箱即用。
- • 高性能：亚秒级延迟，支持实时更新。
- • 扩展性：自动水平扩展，适合大规模数据。
- • API友好：简单易用的RESTful API。
- • 适用场景：实时推荐系统、电商搜索、社交媒体内容过滤。
• 优缺点：
- • 优点：高性能、易维护、支持实时更新。
- • 缺点：需付费，成本较高。

\5. Weaviate

• 特点：
- • 商用专用数据库：支持复杂元数据过滤和混合搜索。
- • 高级功能：内置向量生成（如文本/图像嵌入）、自定义模块扩展。
- • 语义搜索：结合向量搜索与传统文本搜索。
- • 适用场景：需要复杂业务逻辑（如多条件过滤、跨模态检索）的场景。
• 优缺点：
- • 优点：功能丰富、元数据处理能力强。
- • 缺点：成本较高，配置复杂度中等。

\6. Qdrant

• 特点：
- • 开源专用数据库：支持高效向量搜索和过滤。
- • 分布式部署：通过Raft协议实现集群扩展。
- • 过滤支持：灵活的JSON过滤条件（如组合逻辑、数值范围）。
- • 适用场景：需要强过滤能力的场景（如电商商品筛选）。
• 优缺点：
- • 优点：过滤功能强大、分布式支持好。
- • 缺点：社区活跃度略低于Milvus。

\7. PGVector (PostgreSQL插件)

• 特点：
- • 开源支持向量数据库：基于PostgreSQL的向量扩展。
- • SQL集成：结合结构化数据查询（如元数据过滤）。
- • 适用场景：已有PostgreSQL生态、需要混合查询的场景。
• 优缺点：
- • 优点：SQL友好、数据一致性强。
- • 缺点：向量搜索性能低于专用数据库。

\8. Elasticsearch

• 特点：
- • 开源支持向量数据库：结合全文搜索与向量搜索。
- • 实时性：支持实时索引和更新。
- • 适用场景：需要全文搜索和向量搜索结合的场景（如语义搜索+关键词过滤）。
• 优缺点：
- • 优点：功能全面、生态成熟。
- • 缺点：向量索引性能中等，资源消耗较高。

\9. Redis

• 特点：
- • 商用支持向量数据库：通过Redis 7.0+的向量索引功能。
- • 实时性：低延迟、高吞吐，适合实时推荐。
- • 适用场景：需要实时更新和低延迟的场景（如实时聊天机器人）。
• 优缺点：
- • 优点：实时性强、内存存储速度快。
- • 缺点：数据持久化需额外配置，扩展性有限。

选型指南

\1. 核心需求分析

• 数据规模：
- • 小规模（<100万向量）：FAISS、Chroma、PGVector。
- • 中大规模（100万~1亿向量）：Milvus、Qdrant、Elasticsearch。
- • 超大规模（>1亿向量）：Milvus、Pinecone、Weaviate。
• 性能要求：
- • 低延迟（毫秒级）：FAISS（GPU）、Pinecone、Redis。
- • 高吞吐量：Milvus、Elasticsearch。
• 扩展性：
- • 分布式需求：Milvus、Qdrant、Pinecone。
- • 单机部署：FAISS、Chroma、PGVector。

\2. 功能需求

• 元数据过滤：
- • 需要复杂过滤（如组合条件）：Qdrant、Weaviate、PGVector。
- • 需要混合搜索（向量+文本）：Elasticsearch、Weaviate。
• 实时更新：
- • 高频更新：Elasticsearch、Redis、Pinecone。
• 易用性：
- • 快速上手：Chroma、FAISS。
- • 托管服务：Pinecone、Weaviate。

\3. 成本与资源

• 开源免费：Milvus、FAISS、Chroma、Qdrant、PGVector、Elasticsearch。
• 商业付费：Pinecone、Weaviate、Redis（需云服务）。

\4. 典型场景推荐

场景	推荐数据库	理由
小型实验/原型开发	Chroma、FAISS	简单易用，快速启动。
中型生产环境（百万级）	Milvus、Qdrant	性能与扩展性平衡。
大规模生产环境（亿级）	Milvus、Pinecone、Weaviate	分布式能力与低延迟。
需要复杂元数据过滤	Weaviate、Qdrant	灵活的过滤条件支持。
结合结构化数据查询	PGVector、Elasticsearch	SQL与向量搜索结合。
实时推荐系统	Pinecone、Redis	低延迟与实时更新。

检索

检索的过程如下：

\1. 将用户输入的查询进行Embedding（使用的还是在文档块切块时使用的Embedding模型）
\2. 计算查询向量和向量数据库中向量之间的相似度（常用余弦相似度）
\3. 取出TopK相关的块

生成

将用户的查询与检索到的相关数据结合，构建一个增强的prompt。这个prompt将提供给生成模型，确保它能够利用最新、最相关的信息来生成回答。生成模型会根据这个增强的提示，生成最终的响应。

RAG的调优

上面介绍了Naive RAG的工作流程和核心模块，再赘述一次，它的步骤简述为下：

\1. 建立索引：这一过程通常在离线状态下进行，数据清洗并分块，将分块后的知识通过embedding模型产出语义向量，并创建索引。
\2. 检索：用户的query问题，使用相同的embedding模型，计算问题嵌入和文档块嵌入之间的相似度，选择相似度最高的前K个文档块作为当前问题的增强上下文信息。
\3. 生成：将给定的问题和相关文档合并为新的提示，然后由大型语言模型基于提供的信息回答问题。如果有历史对话信息，也可以合并到提示中，用于多轮对话。

但在工程实践时会发现，效果总是差强人意，比如：检索效果不好、生成质量差、增强效果不好。

• 检索质量低：使用长文本做索引，不能很好的突出主题，建立索引时，核心知识湮没在大量无用的信息中，其次，使用用户原始query做检索，不能很好的突出其核心诉求，这就导致用户query和知识索引不能很好的匹配，检索质量比较差。
• 生成质量差：未检索到知识或检索知识质量差时，大模型自主回答私域问题时，容易产生幻觉，或回答内容比较空洞，无法直接使用，知识库失去了本身的意义。
• 增强过程难：将检索到的信息与不同任务整合可能具有挑战性，有时会导致输出不连贯或不一致。此外，还有一个担忧是生成模型可能过度依赖增强信息，导致输出仅仅是复述检索内容而没有添加有洞察力或综合信息。

因此，在Naive RAG面临的这些挑战基础上，衍生出了 Advanced RAG。

Advanced RAG

Advanced RAG 基于Naive RAG范式，围绕着知识检索做优化，新增了检索前、检索中以及检索后的优化策略，用于解决索引、检索和生成的问题。

检索前优化

检索前优化关注于知识切分、索引策略和查询改写。

• 知识切分： 为将长文本依语义分割，确保核心信息不被忽视。
• 索引策略： 通过去除冗余或添加数据来提高匹配精度。
• 查询改写： 旨在理解用户意图，将其问题转化为适合检索的形式，提升搜索准确性。

检索中优化

检索阶段目标是找到最相关的知识。这通常借助向量搜索实现，通过计算查询与数据间的语义相似度来完成。优化工作围绕嵌入模型进行，包括领域特定微调（如BAAI/bge）和上下文适应（例如OpenAI的embeddings-ada-02）。此外，混合搜索结合了向量和关键字搜索，适用于需精确关键词匹配的场景。

检索后优化

检索后处理技术用于改进结果，解决超出限制或噪声干扰的问题。具体方法有提示压缩，即精简内容以聚焦关键信息；以及重新排序，利用机器学习调整检索内容的相关性评分。

Modular RAG

随着 RAG 技术的进一步发展和演变，新的技术突破了Naive RAG的范式，基于此催生了模块化RAG的概念。在结构上它更加自由的和灵活，引入了更多的具体功能模块，例如查询搜索引擎、融合多个回答。技术上将检索与微调、强化学习等技术融合。流程上也对 RAG 模块之间进行设计和编排，出现了多种的 RAG 模式。

除了传统RAG的模块还可能会新增一些模块，如：

• 搜索模块：该模块适用于特定场景和特殊语料的检索，不依赖于相似度搜索。它利用向量、分词、NL2SQL或NL2Cypher等技术进行高效查询。
• 预测模块：此模块通过减少用户问题中的冗余信息和噪声来突出真实意图，并使用大型语言模型（LLM）生成上下文，以获取比直接检索更相关的内容。
• 记忆模块：支持多轮对话的记忆功能，使得系统在后续交互中能记住之前用户的提问内容，增强对话连贯性。
• 融合模块：RAG-Fusion借助LLM将用户查询扩展为多个变体，通过并行向量搜索和智能重排序，确保搜索结果与用户的显式和隐含意图高度匹配，挖掘深层次的相关信息。
• 路由模块：路由机制根据查询内容从多种数据源（如向量数据库、图数据库或关系数据库）中选择最合适的数据库进行查询。开发者需预定义决策逻辑并通过LLM执行，以实现精确查询导向。
• 任务适配器模块：提供基于任务需求定制Adapter的功能，使系统能够灵活适应不同的应用场景。

RAG框架简介

常用RAG框架

框架名称	核心特点	优势	劣势/局限	适用场景
UltraRAG	动态记忆管理、多模态支持、自适应优化（DDR）、端到端训练支持	- 支持多模态数据（文本、图像、空间数据） - 动态更新知识库，响应实时性强 - 性能优化（如DDR策略） - 开源灵活	- 需较高计算资源（GPU） - 配置复杂度较高	复杂问答、多模态分析、企业知识库（如医疗、金融）
LangChain-Chatchat	中文友好、可视化界面、流式输出、支持离线部署	- 中文场景优化 - 开箱即用，易集成 - 支持本地化部署（隐私保护） - 社区活跃	- 复杂任务需自定义模块 - 高级功能依赖外部工具（如向量数据库）	企业内部知识问答、客服系统、教育领域
Spatial-RAG	空间推理、混合检索（SQL+语义）、结构化空间数据库支持	- 精准处理空间数据（如地图、路径） - 混合检索提升召回率 - 开源灵活	- 仅适用于空间推理场景 - 需自定义空间数据库配置	地理推荐、路径规划、物流优化
MedRAG	医疗知识图谱、四层诊断分层（症状-疾病-治疗-预后）	- 医疗领域深度适配 - 知识图谱分层过滤噪声 - 提升诊断准确性	- 仅限医疗领域 - 知识库需专业医疗数据支持	医学诊断、医疗问答、健康咨询
Dify	可视化工作流编排、多模型管理、插件化扩展	- 图形化界面快速搭建系统 - 支持多模型（LLM+检索）协同 - 易于集成第三方工具	- 高级功能需付费 - 复杂场景需自定义插件	快速原型开发、多模型集成、企业级应用（如客服、文档分析）
RAG-Gym	强化学习优化、代理（Agent）驱动、过程监督（Policy-based）	- 通过强化学习优化检索-生成协同 - 适配复杂多步骤任务 - 支持端到端训练	- 训练成本高 - 需较强算法能力	多步骤推理、复杂逻辑任务（如法律咨询、科学计算）
QAnything	无代码配置、轻量级、支持多语言、内置向量数据库（Faiss）	- 无代码部署 - 轻量级适合资源受限场景 - 内置向量存储简化流程	- 功能扩展性有限 - 高级检索策略需自定义	个人项目、小型企业知识库、快速验证
FastGPT	高性能向量检索（Faiss+Milvus）、流式生成、支持本地部署	- 检索速度极快 - 支持流式输出提升交互感 - 企业级部署优化	- 开源部分有限 - 需购买高级功能	电商推荐、实时问答、高并发场景
RAGFlow	模块化设计、支持任意组件组合（检索器/生成器/后处理器）、轻量级	- 极高灵活性，可自定义流程 - 开源且易于扩展 - 适合实验与快速迭代	- 社区支持较少 - 需自行处理性能优化	研究实验、定制化RAG系统开发、教学示例
RAG-Attire	生成器驱动检索、减少冗余信息、支持细粒度控制	- 生成模型主动选择检索内容，减少噪声 - 提升生成连贯性 - 开源灵活	- 对生成模型依赖性强 - 知识库更新需重新对齐	细粒度问答（如法律条款引用）、需要生成可控性的场景