一文读懂:大模型RAG(检索增强生成)
RAG
基于检索机制构建的生成模型(Retrieval Augmented Generation),简称 RAG 或者说是 RAG 模型,在大语言模型领域内已经成为最具影响力的应用方案之一。
相对容易掌握;具体来说,就是要利用自有垂域数据库进行信息搜索,并整合成提示模板集合来帮助大模型系统地构建高质量的问答内容
经历了23年冬季一波 large language model(LLM)浪潮之后,在人工智能领域取得了一系列重要进展的同时,大多数读者可能已经意识到大模型的强大能力。然而,在将大型语言模型应用于实际业务场景时会发现,在某些关键环节上仍存在明显不足的主要原因包括以下几个方面:
- 知识的局限性:模型的知识体系完全建立在训练数据的基础之上。现有的主流大模型(ChatGPT、文心一言、通义千问等)均依赖于网络公开数据集进行训练,在获取实时性、非公开或离线数据方面存在明显限制。这些无法获取的数据类型也相应地缺乏相应的知识储备。
- 幻觉问题:所有AI模型的根本运行机制建立于数学概率基础之上。其输出结果本质上是经过一系列数值运算的结果集合,在缺乏特定领域知识的情况下可能出现不切实际的表现。这种现象的存在使得识别和区分AI系统的"幻想法则"成为一个具有挑战性的课题。
- 数据安全性:从风险管理和合规性的角度来看,在企业运营中确保数据的安全性和完整性至关重要。将私域数据上传至第三方平台进行训练不仅存在较高的风险敞口,在实际应用场景中往往难以平衡数据分析与应用效果之间的关系。
而RAG是解决上述问题的一套有效方案。
简言之,RAG(中文译作检索增强生成模型)由检索技术和LLM提示机制构成。举例而言,在使用过程中,默认情况下我们会向LLM提出一个问题及其回答;借助RAG系统,在多个数据来源中筛选出相关信息,并将其提示信息注入到LLM中;最终通过LLM获得答案。
在2023年期间,RAG被认为是基于LLM系统的最受欢迎架构。目前有许多产品都采用了基于RAG的技术架构,并将其整合到他们的服务中。涵盖从结合搜索引擎与LLM驱动的问答服务到利用私有数据支持的聊天应用程序等多个领域。
虽然在2019年时,Faiss就已经实现了基于嵌入式向量搜索技术的应用,并为该领域奠定了基础。然而,在这一时期之后,RAG(检索增强生成模型)开始推动向量搜索相关领域的进一步发展。目前,在开源社区中涌现出许多创新性向量数据库初创公司如 chroma、weaviate.io 和 pinecone 等(主要基于 Faiss 和 Nmslib 的开源搜索索引引擎),它们近期都引入了对输入文本的额外存储功能和其他辅助工具以提升用户体验。

在这个阶段里包含了两个核心环节:信息检索与响应合成。具体而言,在信息检索阶段系统旨在从海量数据资源中提取与当前问题最为贴合的相关信息源;随后,在响应合成阶段将整合所获取的关键数据构建出全面且具针对性的回答方案
在此过程中首先进行的是信息检索操作这一核心环节通过精确匹配算法系统能够快速定位出与用户查询高度契合的数据资源
以 LangChain 和 LlamaIndex 为代表的两个知名开源工具链,在构建基于大语言模型(LLM)的应用程序和管道方面表现卓越。这些库源自 ChatGPT 的发布,并分别于 2022 年第10季度与第11季度建立,在过去一年中获得了广泛的应用实例。
本文旨在借鉴LlamaIndex的技术框架,并对一系列先进的RAG技术体系进行深入阐述以便帮助研究人员更好地深入理解这些方法的应用场景和技术细节。
问题表现在现有教学材料往往仅聚焦于单一技术细节而未能有效展示不同技术之间的关联与整合。
此外值得指出的是两个具有里程碑意义的开源项目它们的发展节奏极快其官方文档已超越2016年出版的经典机器学习教材在深度和广度。
RAG实现过程
目前已有研究认为RAG融合是一种主要应用于(可能)优化RAG应用检索阶段的技术。在本节中将从以下几个方面进行探讨我的观点。
下图大致呈现了整体工作流程。该图表的核心步骤是通过LLM产出多个相关查询,并旨在使问题的不同方面在上下文中得到体现。随后你可依据这些生成结果执行向量搜索(如前述部分所述),并根据其在结果列表中的呈现位置对其进行重新排列。

可以用下面提示词生成额外问题:
You are a helpful assistant that generates multiple search queries based on a single input query.
Generate multiple search queries related to: {USER_INPUT}
OUTPUT (4 queries):

正如所言,在讨论过程中提到的LLM具备生成能力。它能够生成涵盖原问题的多个维度的查询。这有助于我们获取数据库中包含各个相关方面的信息,并可能提升通过RAG技术所得的结果。
RAG架构
RAG的架构示意如下, 简而言之, RAG就是通过检索获取相关知识并融入Prompt, 使大模型可借助这些知识提供合理的回答。其核心在于'检索+生成', 其中, 前者主要依靠向量数据库的高效存储与检索功能来实现目标知识的召回; 而后者则利用大模型与Prompt工程将召回的知识进行合理运用以生成目标答案。

RAG架构
完整的RAG应用流程主要包含两个阶段:
- 数据预处理环节:采用先进的算法进行数据抽取——>对文本实施切分——>运用嵌入模型将文本转换为数值表示——>完成预处理后存入数据库
- 问答系统运行阶段:接收用户的自然语言输入——>通过搜索引擎实现信息的快速检索——>结合提示信息引导模型输出答案
下面我们详细介绍一下各环节的技术细节和注意事项:
数据准备阶段 :
在大多数情况下,数据准备被视为一个非实时处理的任务,在这一过程中主要目的是将私域资产转化为可量化形式,并建立索引机制;随后将其存储于数据库中以便快速检索。具体包括以下几个步骤:首先进行数据提取;接着对文本进行分词处理;随后将其转化为数值形式;最后完成数据存储工作。

数据准备
数据提取
该过程涉及多种格式的数据加载及来自不同来源的数据获取,并基于数据的具体特征对原始信息进行统一转换为同一规范形式。
数据处理:包括数据过滤、压缩、格式化等。
元数据获取:提取数据中关键信息,例如文件名、Title、时间等 。
主要基于以下两个方面考虑:第一部分是受预训练模型Token限制的影响;第二部分则是关注如何保持各部分语义完整性以提升整体检索效果;常见的几种文本分割方法包括以下几点:例如分段函数优化方法、基于词嵌入的技术等。
遵循"句子"的粒度进行划分,在文本处理中需确保每个句子都能完整传达其意义。常见的标点符号和格式化手段通常包含句号、感叹号、问号以及换行符等。
统一长度划分:受基于embedding模型的token数量限制,在处理文本时将其划分为统一长度的段落(如256或512个tokens)。这样的划分往往会导致大量语义信息的丢失;为此方案通常可在两端增加一定冗余token以弥补这一缺陷。
向量化(embedding) :
向量表示是一种将文本数据转换为高维空间中向量矩阵的方法。该方法对后续检索结果的质量有重要影响。目前主流的embedding技术包括如表所示的具体包括Word2Vec、GloVe等这些embedding模型基本上能满足大部分应用场景的需求但当遇到某些特殊场景(例如涉及一些罕见专有名词或复杂词汇等)或者希望进一步优化检索效果时则需要考虑采用开源Embedding模型的微调版本或者根据自身需求直接训练适合特定场景的自定义Embedding模型。
| 模型名称 | 描述 | 获取地址 |
|---|---|---|
| ChatGPT-Embedding | ChatGPT-Embedding由OpenAI公司提供,以接口形式调用。 | https://platform.openai.com/docs/guides/embeddings/what-are-embeddings |
| ERNIE-Embedding V1 | ERNIE-Embedding V1由百度公司提供,依赖于文心大模型能力,以接口形式调用。 | https://cloud.baidu.com/doc/WENXINWORKSHOP/s/alj562vvu |
| M3E | M3E是一款功能强大的开源Embedding模型,包含m3e-small、m3e-base、m3e-large等多个版本,支持微调和本地部署。 | https://huggingface.co/moka-ai/m3e-base |
| BGE | BGE由北京智源人工智能研究院发布,同样是一款功能强大的开源Embedding模型,包含了支持中文和英文的多个版本,同样支持微调和本地部署。 | https://huggingface.co/BAAI/bge-base-en-v1.5 |
- 数据入库:
在数据向量化之后构建索引并将其存储至数据库的过程中,我们可以将其概括为数据入库流程。在RAG场景中适用的主流数据库类型包括FAISS、Chromadb、ES以及milvus等多种选项。通常情况下,在选择数据库时应综合考虑业务场景特点、硬件配置以及性能需求等因素。
应用阶段:
在应用阶段中,我们基于用户的提问问题,并通过快速的检索机制提取出与之相关的信息内容后进行整合.随后,大模型利用当前提问信息以及相关知识库来生成相应的回答内容.主要涉及以下几个方面:首先是对用户的问题进行高效的数据检索;其次是在检索到的相关知识中进行智能的提示信息注入;最后是基于这些整合的信息内容进行智能的回答生成.

数据检索
- 数据检索
常见数据检索方法主要采用相似性检索和全文检索等技术手段,在实际应用中通常建议综合运用多种检索策略以提高搜索效率
相似性检索亦即通过计算查询向量与所有存储向量之间的相似度分数来筛选出具有较高得分记录的结果集合。常用的相似度计算方法包括余弦相似度、欧氏距离以及曼哈顿距离等。
在数据处理过程中进行的全文检索被视为一种经典的搜索方式。构建阶段主要基于关键词生成倒排索引;而在实际查询阶段,则利用关键词执行全文搜索以获取相关信息。
注入Prompt

LLM生成
在大模型系统中,“Prompt”扮演着关键角色,在Retrieval-Augmented Generation(RAG)场景下,“Prompt”通常涉及三个主要部分:任务描述、检索到的知识背景以及用户指令等基础要素。“根据具体的任务需求以及大模型的实际性能水平”,可以在“Prompt”中加入额外的操作指导以提升其生成效果。“例如,在一个简单的知识问答系统中”,其具体的“Prompt”设计可参考以下内容:
【任务描述】
假如你是一个专业的客服机器人,请参考【背景知识】,回
【背景知识】
{content} // 数据检索得到的相关文本
【问题】
石头扫地机器人P10的续航时间是多久?
Prompt的设计仅凭方法而缺乏明确的语法结构,在实际应用过程中受个人经验的影响较大;通常会根据大模型的实际输出结果来实现针对性地优化和调整。
原始 RAG
本文提出的RAG管道系统基于一个文本文档语料库构建,并省略了如何利用数据加载器从如YouTube等平台获取内容的具体步骤。

标准的 RAG 流程简介:首先对文本进行分段处理;随后通过预训练的 Transformer Encoder 模型对这些段落进行编码映射;接着将所有编码后的向量存储于索引数据库中;最后生成一个提示字符串,并告知模型根据在搜索步骤中获取的相关上下文信息来生成相应的回答内容。
在运行阶段, 我们基于相同的编码器架构将用户的查询转化为向量表示, 然后在预处理好的索引结构中检索与该向量相关的文档, 提取出与查询最相关的top-k个文档片段, 并从预处理的语料库中获取相关文本片段, 将其整合为上下文片段供大语言模型进行提示调用
提示与下边内容类似:
def question_answering(context, query):
prompt = f"""
Give the answer to the user query delimited by triple backticks ```{query}```\
using the information given in context delimited by triple backticks ```{context}```.\
If there is no relevant information in the provided context, try to answer yourself,
but tell user that you did not have any relevant context to base your answer on.
Be concise and output the answer of size less than 80 tokens.
"""
response = get_completion(instruction, prompt, model="gpt-3.5-turbo")
answer = response.choices[0].message["content"]
return answer
提示工程是一种优化RAG流程性能的有效策略。具体参考OpenAI提供的详细提示工程指南。
虽然 OpenAI 是LLM提供商的领军者之一, 但其实在这一领域还有许多其他值得考虑的选择. 比如说, Anthropic 的 Claude 项目就非常突出, 而 Mistral 则以其体积小巧却功能全面的特点受到关注. Microsoft 推出了Phi-2这一款创新产品, 同时Llama2、OpenLLaMA 和 Falcon 也同样值得关注. 这些开源产品都提供了不同特点的选择, 可以帮助你根据具体需求做出最适合的决定, 并最终用于构建RAG管道的大脑.
高级 RAG
目前我们致力于详细阐述高级 RAG 技术方案。该方法将涵盖其中的关键步骤与算法设计,并着重说明其核心原理与实现细节。值得注意的是,在此过程中我们将暂时跳过复杂的循环逻辑以及多级代理机制, 以确保叙述的清晰明了

上图中绿色区域是我们接下来将重点分析的核心RAG技术。单从一张图无法完整呈现所有高阶RAG技术细节,请注意我们目前仅展示基础构建方法
1:分块 (Chunking) & 向量化 (Vectorisation)
第一步我们需要为文档内容构建向量索引接着在运行时阶段中查找与查询向量余弦相似度最高的向量索引通过上述步骤即可检索到与查询内容最为贴近语义意义的相关文档
1.1 分块 (Chunking)
Transformer模型通常被设计为处理具有固定长度输入序列的任务。即使输入数据覆盖了较长的时间跨度或广泛的主题范围,单个或几个句子所生成的向量往往能更准确地反映其深层语义内容。这使得数据处理过程更加高效:将原始文档分成若干个特定大小的部分。有许多文本拆分器实现能够完成此任务。
确定块的大小是需要重点关注的一个问题。
确定块的大小由所使用的嵌入模型以及模型所需的 token 数量共同决定。
例如基于BERT的句子转换器最多支持512个token。
而OpenAI ada-002能够处理更长的序列。
例如基于BERT的句子转换器最多支持512个token。
而OpenAI ada-002能够处理更长的序列,
例如支持8191个token。
不过这中间存在一个权衡:
LLM有足够的上下文来推理,
但并非拥有足够的具体文本嵌入,
从而实现有效的搜索功能。
关于这一研究领域已有诸多探讨,
而在LlamaIndex中,
NodeParser类提供了很好的解决方案,
并包含了多个高级选项,
例如自定义文本分割器、元数据管理以及节点与块之间的关系设置等。
1.2 向量化 (Vectorisation)
下一步将是挑选一个适合进行搜索优化并融入我们系统 的模型。可供选择的对象包括其中一种常见的是bge-large和E5-embedding系列。仅需参考MTEB排行榜即可获取最新的更新信息。
涉及分段与向量化的操作,在 LlamaIndex 中可参考完整的数据采集管道示例。
2. 搜索索引
2.1 向量存储索引

RAG 管道的核心组件是索引系统 ,它整合了我们在上一步中获取的向量化数据。最原始的实现方式基于平面索引 — 直接计算每个查询向量与所有块向量之间的欧氏距离。
为了达成1万元素以上规模下的高效率检索需求,在构建搜索索引时应当选用向量索引方案
此外还有几个第三方服务方案如OpenSearchElasticSearch以及向量数据库它们能够自动执行之前提到的数据收集流程其中包括PineconeWeaviate和Chroma等技术
基于你所选的索引体系、收集的数据以及特定的搜索参数,除了存储元数据之外,在线查询系统还提供了一种专门的元数据过滤工具来筛选依据日期或来源等因素进行检索。
LlamaIndex 覆盖多种类型的向量存储索引,并能与其他简单类型的索引协同工作。其中具体包括列表式结构、层级式架构以及基于关键词的数据表等。关于这些不同的数据组织方式及其应用,请参阅后续章节中的融合检索部分。
2.2 分层索引

面对大型数据库时, 该策略具有显著的效果. 该策略包括建立两个类型的索引结构: 基于摘要构建的一个, 和基于文档块构建的一个. 分为两个阶段执行搜索过程: 首先利用摘要信息筛选出相关文档集合, 然后在此集合中进行精确匹配查询.
2.3 假设性问题和 HyDE
另一种思路是通过 LLM 对每个数据片段生成相关问题并将其编码到特征空间中 ,在运行阶段,在问题相关的位置执行查询以检索与之匹配的信息。之后根据搜索结果返回对应的原始数据片段,并将其提供给LLM用于生成回答所需的上下文信息。
该方法优化了搜索效果;基于与实际块的对比分析表明,查询和假设问题之间的语义关联度更高
另一种称为HyDE的反向逻辑方法——当给定一个查询时,请LLM生成一个假设性回应,并将其与查询一同纳入计算以优化搜索效果。
2.4 内容增强
这部分内容用于将关联的信息整合作为LLM进行推理分析,在较小子块中提取信息以提升搜索效果。
两种主要的选择:一种是在较小区块基础上进行句子在较大语境中的扩展;另一种是通过递归的方式将文档分割为多个较大父块,并确保每个父块内部包含较小子块。
2.4.1 语句窗口检索器
在此方案中,在文档中所有的句子都是独立进行嵌入处理的这一做法,在上下文余弦距离搜索任务中显著提升了查询准确率
以获取最相关且能更精确地支持后续推理分析的一个单独句子为基础,在深入理解该核心信息的基础上,我们将其扩展至包含检索结果前后各k个相关句。随后将这一扩展现有的内容提交给LLM进行处理。

绿色部分指的是在索引搜索过程中识别出来的句子表示,在处理黑色加绿色段落时,则将其发送给LLM以扩展其上下文范围,并基于提供的查询信息进行推理
2.4.2 自动合并检索器(或父文档检索器)
这种思路与基于语句窗口的信息检索机制具有高度相似性——对信息片段进行更加细致的筛选,在LLM中进行推理之前扩大其周围的上下文范围。文档被划分为若干较小的分块,并通过引用关系连接至更大的父分块以形成完整的知识结构。

首先,在信息检索过程中提取较小区块。接着,在前k个检索结果中的多个(共m个)与同一个父节点相关联(且该父节点为较大尺寸),则将该父节点替换为LLM的上下文内容——其原理类似于自动整合多个相关的子块形成一个更大的父块的过程而得名。需要注意的是,在构建过程中信息只在子节点的索引结构中进行。建议参考LlamaIndex官方教程详细了解递归检索器和相关操作步骤。
2.5 融合检索或混合搜索
这种思路旨在将传统基于关键字的搜索(如tf-idf和BM25等成熟方案)与现代语义或向量搜索相结合。
在本研究中所关注的核心问题在于如何整合不同相似度评分的检索结果。该问题通常可采用Reciprocal Rank Fusion算法来进行处理。该算法能够有效地对检索结果进行重新排序,从而生成最终的结果。

在LangChain框架内实现时主要依赖于EnsembleRetriever组件的作用其核心机制在于整合多套自定义检索器以提升整体性能例如采用了一个基于faiss向量索引和另一个基于BM25文本检索器作为基础组件这些组件经过精心配置后能够协同工作不仅实现了高效的搜索能力还通过RRF算法对搜索结果进行了优化排序从而显著提升了系统的性能表现
在 LlamaIndex 中,这一过程也是以类似的方式 实现 的。
混合式/融合式的搜索通常能够显著提升检索效果。这得益于其整合了两种相互补充的搜索算法——不仅考虑到查询与存储文档间的语义相似性,同时也关注于关键词匹配。
3. 重排(reranking)和过滤(filtering)
我们基于所有先前的方法获取了检索结果。目前恰是时候借助过滤筛选、重新排序以及某些转换手段来优化这些结果。在 LlamaIndex 提供了一系列可用的后处理器工具。依据相似性评分、关键术语以及元数据信息筛选出不符合条件的结果。此外还可以采用其他技术比如大语言模型LLM 或者 sentence-transformer 的交叉编码器 同时结合 Cohere 提供的重新排序接口和基于元数据进行再排列的技术来进行进一步优化
这是将检索到的上下文提供给 LLM 以获得结果答案之前的最后一步。
目前,我们致力于探索更高水平的RAG相关技术及其应用模式。这些创新性技术不仅包括查询转换与路由功能,在RAG流程中整合了大语言模型的能力,在实际应用中能够体现出更为复杂的逻辑处理能力。
4. 查询转换
查询转换涉及一系列技术方案。基于LLM构建的推理引擎能够对用户的输入进行优化处理。现有多种解决方案可供采用。

**对于复杂的查询,大语言模型能够将其拆分为多个子查询。**比如,
- 当你问:“在 Github 上,Langchain 和 LlamaIndex 这两个框架哪个更受欢迎?”,
我们无法直接从语料库中找到它们的比较,因此需要将这个问题拆分为更为基础且明确的两个查询
- “Langchain 在 Github 上有多少星?”
- “Llamaindex 在 Github 上有多少星?”
这些子查询将被并行执行,并整合到一个LLM提示词中进行后续处理。两个核心功能将在Langchain框架下采用多查询检索器的形式,在Llamaindex框架下采用分段式问题求解引擎的方式实现。
- Stepback prompting 能够通过LLM生成一个更通用的query来访问更高层次或更具概括性的上下文信息,并在回答问题时同时执行原始query的信息检索过程。随后将这两个不同的上下文信息发送给LLM来生成最终的回答结果。这在LangChain框架中已经提供了相应的实现方案。
- 通过LLM对初始query进行重新表述或重构(rewriting),从而优化检索效果 。目前已有多种技术方案可实现这一目标,在现有技术中个人认为LlamaIndex提供的解决方案更为高效和实用
5. 聊天引擎
关于构建一个可以多次用于单个查询的完美 RAG 系统的下一步主要涉及对话机制 ,类似于LLM时代之前的经典聊天机器人一样充分考虑对话背景及其相关性
它涉及后续问题、代词指代或上一对话中可能关联的各种用户指令。该系统利用压缩查询技术处理信息,将聊天记录和当前查询纳入考量。
类似于过去的方法
更为复杂的情形是CondensePlusContextMode——它在每次交互过程中将聊天记录与最新消息整合进一个新的查询里,并将该查询引入到索引系统中以便检索相关上下文信息。这些检索结果与原始用户输入内容结合后则会作为输入条件用于LLM来生成最终的回答结果。
需要注意的是,在LlamaIndex中还集成了基于OpenAI智能体的聊天引擎,并提供了更为灵活和高效的聊天模式。此外,LangChain系统还支持相关的OpenAI功能API。

此外, 除了ReAct智能体之外的其余聊天引擎类型, 我们将暂时不作深入探讨, 而是直接转向第7节, 全面深入研究智能体本身的特性
6. 查询路由
查询路径是基于LLM的决策流程,在给定用户的特定查询下确定下一步行动;常见做法是总结信息、对相关数据进行索引搜索或尝试多种路径,并将这些结果整合成最终的答案。
路由器不仅用于选择数据存储位置来处理用户的查询;这些数据存储位置包括多种类型:传统向量存储、图形数据库或关系型数据库等;此外,在处理多文档存储时,则常用摘要索引和文档块向量索引这两种不同的索引方法进行管理。
定义查询路由器包括设置它可以做出的选择。
选择特定路由的过程是通过大语言模型触发调用而完成的;其结果按照预先设定的标准格式返回,并用于指定索引的位置进行路由查询。在涉及关联操作的情况下;这些查询也可能会被发送到子链或其他智能体中执行;例如如下的多文档智能体方案所展示的方法。
LlamaIndex和 LangChain都提供了对查询路由器的支持。
7. 智能体(Agent)
该系统(Langchain 和 LlamaIndex 均支持)自其发布以来几乎已-cornerstone般存在——这一思路旨在为具备推理能力的LLM提供一系列功能模块,并承担相应的具体任务。这类工具通常包含一类确定性功能——如各种代码函数或其他外部接口,并可能整合其他系统——这种LLM连接理念正是LangChain命名的基础。
智能体本质上是一项复杂的技术。由于RAG概述篇幅限制无法对此展开深入讨论。因此我可以继续利用agent的多文档检索案例作为研究基础,并简要介绍OpenAI助手这一新兴技术;因为它作为一个新概念将在最近的OpenAI开发者会议上被正式提出并以其卓越能力成为焦点;它将在后续介绍的RAG系统中发挥重要作用。
OpenAI 助手主要整合了相关开源大语言模型(LLM)周边工具集合,并提供了一个完整的生态系统支持实时对话历史记录、领域知识库以及文件上传与管理界面等基础服务功能。其中最为关键的功能模块是基于API的函数调用接口,在这一核心组件中实现了将自然语言处理结果转换为对外部工具和服务资源的API调用指令的能力。
在 LlamaIndex 中,该 OpenAIAgent 类整合了这种复杂的逻辑机制,并将其有机地融合到 ChatEngine 和 QueryEngine 两大组件之中。此组件赋予系统者丰富的知识储备,并通过深入理解上下文来驱动对话交流。该系统还特别支持在一个完整的对话周期内同时调用多个 OpenAI 系列功能模块的能力。这充分体现了智能代理的实际运作。
深入探讨这一多文档智能体设计系统的整体架构——该系统涉及多个复杂组件的集成。其中包含了在每个数据片段中初始化OpenAI代理的过程。该系统具备生成数据摘要和执行传统问答功能的能力。此外,在顶层设计了一个协调层。负责将查询分配到各个子系统,并整合各子系统的响应结果生成最终答案。
每个文档智能体都拥有两个工具:分别是向量存储索引和摘要索引,在处理路由查询时会依据路由查询来决定使用哪一个。在顶级层级上,这些文档智能体都成为其功能模块的组成部分。
该方案采用了高级 RAG 架构系统,在其中每个智能体负责处理多方面的决策。这种方法的优势在于它能够通过分析不同文档及其摘要来比较各种解决方案或实体的表现,并结合传统的单篇文献摘要技术和问答系统功能——这使得在实际应用中这类方法通常能够覆盖大部分基于文档集合的对话场景。

该配置方案的潜在问题可通过图像分析得以识别——因为智能体内部的大语言模型间的交互需经历多次迭代过程,在此过程中整体运行效率较低。值得注意的是,在RAG管道中进行LLM调用通常耗时最长,在搜索功能方面,则是经过设计优化以提高速度。基于以上分析可知,在面对大型多文档存储时我认为该方案可以采用一定程度上的简化处理以便实现更大规模的应用场景扩展。
8. 响应合成
在任何 RAG 管道中作为其最后一个环节使用——通过综合分析所有相关上下文资料以及用户的初始查询信息来输出最终回答内容。
基本方案是通过筛选出相关性高于设定阈值的所有上下文,并将其与查询信息结合后输入到LLM中进行处理。此外,在传统模式的基础上通常会引入更为复杂的策略。这些策略包括调用多个LLM以扩大搜索范围,并通过多轮对话优化最终结果。
响应合成的主要方法有:
采用分批次处理的方式将检索到的上下文输入LLM系统,并通过技术手段优化其输出结果;对检索到的信息进行总结和提炼以满足查询需求;根据不同类型的信息分别生成相应的回答内容,并整合并汇总这些结果为最终的回答内容。
有关更多详细信息,请查看响应合成器模块文档。
RAG 融合
和各类软件世界架构决策类似,在选择RAG融合方案时也需要权衡其得失,并需对此有所了解以便于根据具体情况作出最佳选择然而在深入探讨之前我们先列出RAG融合方案的优势与不足
优点:
- 提供多样化的上下文:通过多维度分析用户的查询请求,在搜索结果中将呈现更加丰富多样的内容片段。相比之下,在单一视角下提供的内容片段往往无法全面覆盖话题的相关方面。
- 额外的控制层面:除了其他机器学习方案外,在RAG融合系统中也引入了额外的控制机制。这些机制允许用户根据自身需求进行微调优化。
- 自动校正:自动校正功能主要通过LLM充当桥梁作用,在识别拼写错误的同时补充相关背景信息并过滤无关内容。
- 成本:这一问题存在争议性地位——既作为RAG融合的优势也被视为其潜在弊端。具体而言:
通常情况下,
向量搜索的成本远低于LLMs技术,
但大部分主流LLMs仍采用基于令牌计费模式,
即使如此,
在实际应用中我们发现:
第一次对模型发出请求时所需处理约100个令牌,
而后续请求则可能达到数千个甚至上万级,
因此前者的成本显著低于后者。
综合来看,
这种策略不仅不会明显增加整体成本,
反而能带来更高的效率优势。
缺点:
- 延迟:正如你可能所知,LLMs需要大量的计算资源,因此它们的运算速度相对较慢(相对于我们应用程序中的其他部分).向LLM发送一次额外的请求可能会让用户体验变得糟糕,因为他们可能需要等待数百毫秒的时间.
- 自动纠错:是的,这是一种优点,但它也可能是一种缺点.这种情况通常发生在你的内容包含专业术语或行业用语,而这些术语或用语没有出现在LLM训练数据中.在这种情况下,LLM可能会感到困惑并生成完全不相关的查询,从而影响最终结果.
- 成本:正如我们之前讨论的,如果RAG融合对你应用程序的整体效益贡献不大,最终可能会增加费用但收益却很有限.
有了之前的介绍,在深入探讨哪些情况下最有可能通过运用RAG融合达到显著的效果时,请注意以下几点:如果你的应用程序的内容是以常见概念为基础的,则很可能能够从中获得显著的好处。

RAG融合n不适用场景
当您的内容中含有过多专业术语或与知名品牌的语言高度相似时,请考虑调整RAG融合提示以优化性能效果;或者最好尽量避免使用此类技术。以下将通过一个具体案例来说明这一观点。目前所有知名的大语言模型(LLMs)都源自于'注意力机制即为所需'这篇论文中首次提出的Transformer架构模型;这是一项衡量在生成下一个词时各个上下文单词重要性的方式;因此,在基于上述论文构建一个支持RAG功能的应用时(绿色字体用于标识那些为该功能做出贡献的语言模型所生成的问题),其运行逻辑可能类似于以下情况:

因为在这个特定情境下解析"注意力"这一概念需要充分考虑上下文信息的存在性要求,在这种情况下LLM出现了误判现象并因此生成了一系列与其实际关联性甚微的相关查询项这些不相关的问题建议不仅无法有效辅助目标应用解决问题反而可能造成不必要的困惑和误导效果这将导致您的应用产生不良结果现在我们来探讨通过修改系统提示指示的方式如何在此类案例中优化模型性能从而避免此类问题的发生

考虑到用户的特殊情况,微调提示未必总是有效。您也可以尝试采用以下技巧后选择放弃。
- 通过语义搜索定位相关查询项:通常适用于较为成熟的使用场景。但如果你拥有庞大的用户群体,则建议建立一个类似主题的数据库以辅助检索相关内容。
- 利用有限数量的示例训练模型来理解上下文:在向模型提供指令之前展示几个相关的示例可能会提高性能。
- 对小型语言模型进行微调优化:如果前面提到的方法对你特定的应用场景效果不佳(而测试这些方法相对较快),那么你可以尝试对自身构建的小型语言模型进行微调优化。这可能显著提升性能(即使该模型规模较小)。请注意这种方法虽然投入更多资源和时间但可能带来最佳效果(代价是增加了复杂性)。
正如您所见,在这种情况下(例如HyDe、TF-IDF、BM25或其他类似方法),我们对这种方法是否能超越特定用例下的基本语义搜索功能持有所谓疑问。然而如同大家所知,“不进行衡量就无法改进”这一真理。因此我的建议是:一旦构建了一个基础的RAG系统就应该立即建立一个评估机制。在这个评估过程中你将面临许多机会去提升提示或搜索功能但每一个改动所带来的潜在影响是不可预知的有时提高一组查询效果的做法可能会导致另一组查询性能下降因此在这种情况下最佳策略通常是将其视为另一种机器学习问题并通过观察数据来寻找答案。
编码器和 LLM 微调
该方法主要通过微调 Transformer 编码器 以及大语言模型(LLM)来进行优化。具体而言,在这一过程中,编码器的质量直接影响到检索结果的准确性。而大型语言模型则利用这些预处理后的上下文信息来生成高质量的回答内容。
如今的一大显著优势是可以利用像 GPT-4 这样的大型语言模型(LLM)来生成高质量的训练数据集。需要注意的是,在微调基础模型时使用小型合成数据集可能会导致基础模型在实际应用中表现出较低的泛化能力。
编码器微调
作者进行了评估实验,在对该模型bge-large-en-v1.5进行了微调训练后发现,在检索性能方面提升幅度较小。这一结果表明由于当前用于搜索优化的Transformer编码器架构已达到高度优化水平。
排序器微调
若完全信任基础编码器,则无需依赖交叉编码器完成结果排序任务。这一过程如下所述:将查询与前 k 个检索到的文本块一同输入至交叉编码器,并对其进行微调训练使其能够识别相关性较高的文本块并给出评价分数1而忽略不相关的文本块给出评价分数0。实验结果表明,在经过交叉编码器微调后成对比分提升了4%。
LLM 微调
最近推出了一款新的工具包——LLM 微调 API。
LlamaIndex 提供了一个实用指南,
指导如何在 RAG 管道中进行 GPT-3.5-turbo 的微调。
通过 RAG 管道评估框架,
实验数据显示,在处理相关任务时的准确性提升了约5%。
该研究机构近期发表的论文RA-DIT展示了更为复杂的解决方案,并基于原始论文中的双编码器框架提出了一种同时优化语言模型LLM以及检索系统的创新方法。这种技术不仅利用了查询、上下文与答案之间的三元组关系作为核心建模单元,并且还成功应用于对OpenAI语言模型进行微调优化的过程。此外,这种方法还成功应用于对开源Llama2模型的微调过程,并比较于采用RAG辅助训练后的65B参数版本,在知识密集型任务上提升约5%,并在常识推理方面也取得了显著提升。
评估
RAG系统的性能评价涉及多个评价体系,在具体实施过程中均包含了若干个独立的评估标准。这些体系的具体表现包括总体回答的相关性、回答的基础性特征、结果的真实准确性以及与检索到的相关上下文之间的关联度等关键指标。
在先前章节中提及 ragas 的基础上,在本节我们将其进一步深化为一种用于生成回答质量评估的方法;具体而言,在实现这一目标时我们主要关注两点:一是生成回答的真实性和准确性之间的关系;二是通过计算经典意义上的上下文准确度和召回率指标来评估rag方案的整体检索性能
近期发布的一套课程体系旨在提升高级 RAG 的性能,并结合了 LlamaIndex 并采用 Truelens 作为评估框架。其创新性地提出了‘RAG 三元组’这一新型评价体系,并针对问题三个关键维度进行考量:首先是检索内容的相关度;其次是答案生成的基础支撑;最后是答案与问题之间的关联程度。
以检索内容的相关性为核心的关键可控制指标为研究重点 — 具体来说,就是指上述高级 RAG 管道的第一至第七阶段以及编码器与排序器经过微调优化的部分;这些环节均旨在提升这一核心指标的表现。相比之下,在第八阶段以及通过大规模语言模型进行微调的地方,则更加关注于提升回答的相关性和准确性。
总结
本文概述 RAG 的核心算法,并举例说明其中的一些方法。
该技术作为一种核心功能具有显著的优势,在提升语义检索效率方面表现出色
还需要考虑的其他事项包括基于网络搜索的 RAG(其中涉及的主要框架包括 LlamaIndex 的 RAG 和 webLangChain 等),以及进一步探索智能体架构并围绕大语言模型长期记忆的相关思路展开思考
除了与答案的相关性和高度一致性的要求之外,在当前主流的大规模语言模型中使用的技术并非传统的科幻元素(赛博朋克风格),而是作为一种优化技术设计用于提升信息处理的速度
基于以下原因,我坚信小参数规模的LLM将展现出显著的发展前景。最近发布的Mixtral和Phi-2正在推动这一领域的进步。
如何学习大模型 AI ?
因为新设立岗位的生产效能高于旧岗的生产效率水平,从而导致整个社会的生产效率得到显著提升.
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在互联网行业的资深从业者职业生涯中培养了许多优秀同行朋友,在过去近二十年的时间里助力许多人实现了自我提升。
我认为自己拥有丰富的宝贵经验和知识资源可供分享。这些能力与经验能够深入挖掘其潜在价值。即使工作繁忙也坚持进行各类整理与分享工作。然而目前部分互联网行业从业者难以获取系统性、高质量的学习资料以实现自身能力提升。因此现提供包括但不限于AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程以及实战应用的学习内容的录播课程,并将其所有资源均免费开放给相关公众进行参考与应用。

第一阶段(10天):初阶应用
该阶段有助于帮助大家深入掌握最新的大模型AI动态。
对于理解程度已经超过95%的人来说,在相关讨论中能够发表既有深度又不过时且通俗易懂的意见。
另外值得注意的是,在日常交流中其他人只会 superficially engage with AI。
而你能够调控人工智能技术,并通过编程实现将大模型与业务有机结合起来。
- AI 大模型能实现什么功能?
- AI 大模型是如何生成智能的?
- 掌握 AI 的核心要诀
- 架构大模型应用体系
- 技术架构解析与实践
- 向 GPT-3.5 输喂新知识的代码示例
- 命令提示工程的核心理念与思想
- prompt 的典型构成方式
- 指令优化的方法论探讨
- 思维链与思维树的应用解析
- prompt 攻击手段及防范策略
…
第二阶段(30天):高阶应用
在这一阶段正式开展大模型AI进阶实战学习活动,在深入研究的基础上掌握构建私有知识库的技术,并有效提升AI整体能力水平。迅速构建一个完整的基础对话型智能代理系统,并深入学习当前最先进的大模型开发技术框架。特别适用于具备Python或JavaScript编程技能的学习者。
- 从RAG的角度切入
- 构建基础ChatPDF系统
- 探讨检索原理基础
- 解析向量表示法概要
- 实现向量数据库及检索方法
- 构建基于向量检索的RAG实现
- 设计RAG扩展知识库系统
- 总结混合检索与RAG-Fusion概述
- 制定本地部署方案
...
第三阶段(30天):模型训练
庆祝你的这一成就!到了这个阶段,基本上就可以找到一份大模型 AI相关的工作,并且完全有能力自行训练GPT系列模型了!通过微调优化的方式专攻某一领域的大模型训练,在实践中能够独立进行开源多模态大模型的开发与应用研究。
到此为止,经过大约两个月的时间。你已然是一名AI从业者。那么你是否还想继续深入探索?
- RAG的作用体现在哪里?
- 模型的概念是什么?
- 模型的基本组成要素有哪些?
- 训练的目标与标准是什么?
- 如何理解求解器的作用?
- 损失函数又是如何定义的?
- 小实验2的目标是什么?它的意义在哪里?
- 训练的基本概念有哪些?它们之间的关系如何?
- 预训练的具体流程是怎样的?它的价值在哪里?
- 微调与轻量化微调有什么不同?这种差异对实际应用有何影响?
- Transformer架构的核心原理是什么?
- 微调与轻量化微调的具体实现步骤有哪些?它们分别适用于什么场景?
- 在完成预训练任务后如何进一步优化模型参数?这种优化对提升模型性能有何帮助?
第四阶段(20天):商业闭环
对全球大模型从性能(运行效率)、处理速度(吞吐量)、资源消耗(成本)等方面的基础认识较为充足,在云端和本地等多种环境下进行部署,并寻找适合的发展机遇。通过AI赋能成为一名被AI赋能的产品经理。
硬件选型
- 带你认识全球大模型
- 采用国产大模型服务
- 基于 OpenAI 开发替代方案
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地运行大型语言模型
- 实现大模型的私有化部署
- 基于 vLLM 开发独立实例部署
- 案例:如何优雅地在阿里云实现开源 LLM 自带安全机制
- 完成一套开源 LLM 的完整部署项目
学习是一种循序渐进的过程,在这个过程中无论你如何努力都会遇到挑战。天道酬勤是一种鼓励人不断努力的智慧法则,在你的持续付出下你会最终成为一个越来越优秀的人。
如果能在15天内完成全部任务,则可被视为完美人才。然而,在仅完成约60%-70%的任务时,则已初步具备大模型AI的关键特质。
保证100%免费
这份涵盖大模型AI的学习资料已发布至平台。如需获取,请扫码关注并获取官方认证资源包,并确保无任何额外费用。

