RAG 2.0架构详解:构建端到端检索增强生成系统

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
简介: RAG(检索增强生成)旨在通过提供额外上下文帮助大型语言模型(LLM)生成更精准的回答。现有的RAG系统由独立组件构成,效率不高。RAG 2.0提出了一种预训练、微调和对齐所有组件的集成方法,通过双重反向传播最大化性能。文章探讨了不同的检索策略,如TF-IDF、BM25和密集检索,并介绍了如SPLADE、DRAGON等先进算法。目前的挑战包括创建可训练的检索器和优化检索-生成流程。研究表明,端到端训练的RAG可能提供最佳性能,但资源需求高。未来研究需关注检索器的上下文化和与LLM的协同优化。

关于检索增强生成(RAG)的文章已经有很多了,如果我们能创建出可训练的检索器,或者说整个RAG可以像微调大型语言模型(LLM)那样定制化的话,那肯定能够获得更好的结果。但是当前RAG的问题在于各个子模块之间并没有完全协调,就像一个缝合怪一样,虽然能够工作但各部分并不和谐,所以我们这里介绍RAG 2.0的概念来解决这个问题。

什么是RAG?

简单来说,RAG可以为我们的大型语言模型(LLM)提供额外的上下文,以生成更好、更具体的回应。LLM是在公开可用的数据上训练的,它们本身是非常智能的系统,但它们无法回答具体问题,因为它们缺乏回答这些问题的上下文。

所以RAG可以向LLM插入新知识或能力,尽管这种知识插入并不是永久的。而另一种常用向LLM添加新知识或能力的方法是通过对我们特定数据进行微调LLM。

通过微调添加新知识相当困难,昂贵,但是却是永久性。通过微调添加新能力甚至会影响它以前拥有的知识。在微调过程中,我们无法控制哪些权重将被改变,因此也无法得知哪些能力会增加或减少。

选择微调、RAG还是两者的结合,完全取决于手头的任务。没有一种适合所有情况的方法。

RAG的经典步骤如下:

  • 将文档分成均匀的块。
  • 每个块是一段原始文本。
  • 使用编码器为每个块生成嵌入(例如,OpenAI嵌入,sentence_transformer等),并将其存储在数据库中。
  • 找到最相似的编码块,获取这些块的原始文本,并将其作为上下文与提示一起提供给生成器。

RAG 2.0

当今典型的RAG系统使用现成的冻结模型进行嵌入,使用向量数据库进行检索,以及使用黑盒语言模型进行生成,通过提示或编排框架将它们拼接在一起。各个组件技术上可行,但整体远非最佳。这些系统脆弱,缺乏对其部署领域的任何机器学习或专业化,需要广泛的提示,并且容易发生级联错误。结果是RAG系统很少通过生产标准。

而我们要说的RAG 2.0的概念,通过预训练、微调并对所有组件进行对齐,作为一个整体集成系统,通过语言模型和检索器的双重反向传播来最大化性能:

下面就是我们将上下文语言模型(Contextual Language Models)与冻结模型的 RAG 系统在多个维度进行比较

对于开放域问答:使用标准的自然问题(NQ)和 TriviaQA 数据集来测试每个模型检索相关知识和准确生成答案的能力。还在单步检索设置中使用 HotpotQA(HPQA)数据集对模型进行评估。所有数据集都使用精确匹配(EM)指标。

对于忠实度:使用 HaluEvalQA 和 TruthfulQA 来衡量每个模型在检索证据和幻觉中保持基础的能力。

而新鲜度:我们使用网络搜索索引来衡量每个 RAG 系统概括快速变化的世界知识的能力,并在最新的 FreshQA 基准测试中显示准确性。

这些维度对于构建生产级别的 RAG 系统非常重要。CLM 在多种强大的冻结模型RAG 系统上显著提升性能,这些系统是使用 GPT-4 或最先进的开源模型如 Mixtral 构建的。

RAG如何解决智能问题?

RAG是一种半参数系统,其中参数部分是大型语言模型(LLM),其余部分是非参数的。这样我们就得到了半参数系统。LLM在其权重或参数中存储了所有信息(以编码形式),而系统的其余部分则没有定义这些知识的参数。

但这为什么能解决问题呢?

  • 在LLM中交换索引(特定信息)为我们提供了定制化,这意味着我们不会仅仅获得老旧的知识,同时我们也可以修订索引中的内容。
  • 通过这些索引对LLM进行定位意味着可以减少幻觉,并且通过指向来源进行引用和归属。

所以RAG为的LLM提供了更好的上下文化能力,使其表现良好。但实际上真的这么简单吗?

并不是,因为我们有许多需要解答的问题,才能创建一个现代化的可扩展的RAG管道。

当前的RAG系统并没有那么智能,而且它们非常简单,无法解决需要大量自定义上下文的复杂任务。

我们看到,目前唯一可以训练的参数部分就是LLM。能否增加更多的参数呢?

更好的检索策略

1、稀疏检索

TF-IDF:TF-IDF或词频-逆文档频率,是衡量一个词对一个文档集或语料库中的文档的重要性的指标,同时调整了某些词通常出现得更频繁的事实。[1] 它常被用作信息检索、文本挖掘和用户建模搜索中的权重因子。

BM25:可以视为对TF-IDF的改进。

对于查询“机器学习”,BM25的计算将是BM25Score(机器) + BM25Score(学习)的总和。

公式的第一部分是词项的逆文档频率(IDF)。公式的第二部分代表词频(TF),该词频通过文档长度进行了标准化。

f(q(i), D) 是文档 D 中词 q(i) 的词频。

K 和 b 是可以调整的参数。|D| 表示文档的长度,avgdl 表示数据库中所有文档的平均长度。

这些是稀疏检索的一些早期步骤。

2、密集检索

需要密集检索的原因是因为语言并不那么直白。例如,如果有同义词,稀疏检索就会完全失效。我们不仅仅想基于确切关键词匹配来检索信息,更多的是基于句子的语义。BERT sentence embedding 就是一个密集检索的例子。将句子转换为向量后,使用点积或余弦相似度来检索信息。

密集检索的一个好处是它易于并行处理,借助GPU,它可以轻松地在十亿级别的相似性搜索上运行,这就是Meta开发FAISS的方式,或者我们常说的向量数据库。

密集检索也就是我们常说的向量查询,它通常使用点积来判断响亮的相似程度,这也是一般RAG中常用的步骤。我们如何超越简单的点积呢?

除了简单的点积以外,还有很多文档和查询交互方式,比如说 孪生网络,ColBERT,等等

基于模型的检索算法

ColBERT是一个非常好的检索策略,但这并不是信息检索的SOTA。我们还有其他更先进的算法和策略,如SPLADE、DRAGON和Hybrid搜索。

1、SPLADE:稀疏与密集的结合的查询扩展。

可以看到,通过查询扩展,涵盖了更多的上下文,这有助于更好的检索。

2、DRAGON:通过渐进式数据增强来推广密集检索器。

让我们通过一个例子来理解DRAGON的工作原理:

  • 初始询问:“如何照顾吊兰?”
  • DRAGON的行动:识别出植物护理的主题后,DRAGON制定了一个针对性的检索查询,专门收集有关吊兰的一般护理信息。
  • 初始检索:DRAGON深入其数据库,检索出有关这些绿叶植物的阳光需求、浇水时间表和合适肥料的文档。然后生成回应:“吊兰需要适度的间接阳光,应该每周浇水一次。在生长季节,每月施肥一次对它们有益。”
  • 用户更新:随着用户询问:“如果叶子变成棕色怎么办?”对话发生了转变。
  • DRAGON适应:DRAGON细化检索查询,专注于吊兰叶子变棕的问题。
  • 动态检索行动:DRAGON检索有关叶子变棕的常见原因的信息,如过度浇水或过多直射阳光。
  • 知识传递:通过利用新检索到的数据,DRAGON根据对话的发展定制其回应:“吊兰的棕色叶子可能是过度浇水或阳光直射过多的迹象。尝试减少浇水频率,并将植物移至更阴凉的地方。”

DRAGON根据用户在对话中不断变化的兴趣动态调整其检索查询。用户的每一次输入都会实时更新检索过程,确保提供的信息既相关又详细,符合最新的上下文。

3、混合搜索:我们在密集和稀疏搜索之间进行插值。这就是RAG社区一直在研究的方向,比如采用类似BM25的并将其与SPLADE或DRAGON结合。

但是无论我们使用什么方法,检索器仍然是固定的,或者说无法定制(微调)的

可以提供上下文的检索器

1、RePlug

这是一篇关于检索的非常有趣的论文,对于给定的查询,我们检索出前K个文档,并进行归一化(计算它们的可能性)后得到一个分布,然后我们将每个文档与查询一起单独输入给一个生成器。然后查看语言模型对正确答案的困惑度。这样就有了两个可能性分布,在这些分布上我们计算KL散度损失,以使KL散度最小化,就会得到检索到的文档与正确答案上的困惑度最低的结果。

2、In-Context RALM

它使用冻结模型RAG 和 BM25,然后通过重新排序专门化检索部分。包含一个零样本学习的语言模型和一个训练过的重新排序器。

语言模型是固定的,我们只反向传播或训练重新排序的部分。这不是很先进,但与前面的简单RAG相比,它的性能还不错。

但问题是如果无法访问LLM的参数,如何对检索器的参数进行反向传播或更新呢?

所以它是使用强化风格的损失来训练检索器。检索器的有效性通过其获取的信息如何增强语言模型的输出来评判。对检索器的改进集中在最大化这种增强上。这可能涉及基于从语言模型输出中派生的性能指标调整检索策略(获取信息的内容和方式)。常见的指标可能包括生成文本的连贯性、相关性和事实准确性。

3、组合上下文化检索器和生成器

与其单独优化LLM或retriver,不如一次优化整个流程?

当检索文档时,在每n个令牌或一次检索时,有很多地方可以优化。

在RAG-token模型中,与RAG-Sequence模型的单次检索相比,可以在不同的目标token上检索不同的文档。

使用编码器对所有k个文档进行编码,接着进行协同,然后在将其作为上下文提供给输入提示之前进行解码。

4、k-NN LM

另外一个在RAG系统中有趣的想法是增加包括k-NN LM:

研究人员表明,如果在RAG环境中训练,他们可以创建25倍小的模型

目前SOTA整理

大型语言模型(LLM)的上下文化既复杂又昂贵。因为重新更新整个LLM并不容易,需要更新数十亿甚至数万亿的令牌。

所以Meta的FAIR的发布了ATLAS论文,这篇论文讨论了可以用来训练整个RAG管道,并且针对不同部分使用不同类型的损失函数,并对它们进行了性能比较。

以下是ATLAS论文中所有不同损失的性能比较:

ATLAS是一个经过精心设计和预训练的检索增强型语言模型,能够通过极少的训练示例学习知识密集型任务。ATLAS将这些损失函数整合进一个连贯的训练流程中,可以直接基于其对语言模型性能的影响来微调检索器,而不是依赖于外部注释或预定义的相关性评分。这种整合使系统能够随着时间的推移通过适应其训练任务的具体需求而改进。

  • 使用双编码器框架作为其检索系统,一个编码器专门用于编码查询,另一个用于文档。
  • 然后将检索到的文档与查询一起输入基于T5架构的强大的序列到序列语言模型,该模型在系统中充当解码器,生成最终的文本输出。
  • 采用解码器内融合方法,将检索到的文档的信息直接整合到序列到序列模型的解码器中。这种方法允许语言模型在生成过程中动态利用检索到的信息,增强其输出的相关性和准确性。

总结

RAG(检索增强生成)有三种类型:

  1. 冻结模型RAG:这些在整个行业中随处可见,它们只是概念验证(POC)。
  2. 半冻结模型RAG:应用智能检索器,并试图使它们以某种方式适应。不修改LLM只是操作检索器并将它们与最终输出结合。
  3. 完全可训练的RAG:端到端训练相当困难,但如果做得正确,可以提供最佳性能。但是肯定非常消耗资源。

而我们常用的RAG还仅仅是第一种冻结模型RAG,所以说RAG的技术目前还处于初级阶段,扩展语言模型的参数还是令牌,如何有效地扩展检索器,通过参数还是数据块将记忆与概括分离,将知识检索与生成过程分离等,都是后续需要继续研究的问题。

https://avoid.overfit.cn/post/18853fc6f10e4e23a992880c624ea1dd

作者:Vishal Rajput

目录
相关文章
|
6天前
|
存储 缓存 API
探索后端技术:构建高效、可扩展的系统架构
在当今数字化时代,后端技术是构建任何成功应用程序的关键。它不仅涉及数据存储和处理,还包括确保系统的高效性、可靠性和可扩展性。本文将深入探讨后端开发的核心概念,包括数据库设计、服务器端编程、API 开发以及云服务等。我们将从基础开始,逐步深入到更高级的主题,如微服务架构和容器化技术。通过实际案例分析,本文旨在为读者提供一个全面的后端开发指南,帮助大家构建出既高效又具有高度可扩展性的系统架构。
|
12天前
|
敏捷开发 运维 Prometheus
构建高效运维体系:从基础架构到自动化管理
本文探讨了如何通过优化基础架构、引入自动化工具和流程,以及加强团队协作,构建高效的运维体系。通过案例分析和实践建议,帮助运维人员实现系统的稳定性、可靠性和可维护性。
|
7天前
|
监控 Cloud Native 持续交付
云原生架构:构建弹性与高效的现代应用##
随着云计算技术的不断成熟,云原生架构逐渐成为企业技术转型的重要方向。本文将深入探讨云原生的核心概念、主要技术和典型应用场景,以及如何通过云原生架构实现高可用性、弹性扩展和快速迭代,助力企业在数字化转型中保持竞争优势。 ##
25 6
|
8天前
|
运维 Cloud Native 持续交付
云原生架构:构建未来应用的基石
本文将深入探讨云原生架构的核心概念、主要优势以及实际应用案例,揭示其在现代IT领域的重要性。通过详细解析云原生技术的各个方面,帮助读者更好地理解和应用这一前沿技术。
|
12天前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
|
9天前
|
Cloud Native 持续交付 云计算
探索云原生架构:构建现代应用的新范式
在当今数字化浪潮中,云原生架构以其敏捷性、弹性和可扩展性成为企业技术转型的核心驱动力。本文将引领读者深入理解云原生的概念,剖析其关键技术组件——微服务、容器化、DevOps实践及持续交付/持续部署流程,并揭示这些技术如何相互协作,共同构建高效、可靠且易于管理的现代软件系统。通过对云原生架构的全面解读,我们旨在为开发者、架构师乃至企业决策者提供有价值的见解与指导,助力其在快速变化的市场环境中保持竞争力。
|
9天前
|
Kubernetes Cloud Native 安全
云原生技术:构建高效、灵活的现代应用架构
本文深入探讨了云原生技术的核心概念、主要特点及其在现代应用开发中的重要性。通过分析云原生技术的实际应用案例,揭示了其如何帮助企业实现应用的快速迭代、弹性扩展和高可用性。同时,文章还讨论了采用云原生技术时面临的挑战及相应的解决策略,为读者提供了一套完整的云原生技术实践指南。
|
11天前
|
网络协议 安全 中间件
系统架构设计师【第2章】: 计算机系统基础知识 (核心总结)
本文全面介绍了计算机系统及其相关技术,涵盖计算机系统概述、硬件、软件等内容。计算机系统由硬件(如处理器、存储器、输入输出设备)和软件(系统软件、应用软件)组成,旨在高效处理和管理数据。硬件核心为处理器,历经从4位到64位的发展,软件则分为系统软件和应用软件,满足不同需求。此外,深入探讨了计算机网络、嵌入式系统、多媒体技术、系统工程及性能评估等多个领域,强调了各组件和技术在现代信息技术中的重要作用与应用。
22 3
|
13天前
|
消息中间件 缓存 NoSQL
构建高效后端服务:微服务架构的深度实践
本文旨在探讨如何通过采用微服务架构来构建高效的后端服务。我们将深入分析微服务的基本概念、设计原则以及在实际项目中的应用案例,揭示其在提升系统可维护性、扩展性和灵活性方面的优势。同时,本文还将讨论在实施微服务过程中可能遇到的挑战,如服务治理、分布式事务和数据一致性等问题,并分享相应的解决策略和最佳实践。通过阅读本文,读者将能够理解微服务架构的核心价值,并具备将其应用于实际项目的能力。 ##
|
9天前
|
前端开发 测试技术 API
探索微前端架构:构建现代化的前端应用
在软件开发中,传统单体架构已难以满足快速迭代需求,微前端架构应运而生。它将前端应用拆分成多个小型、独立的服务,每个服务均可独立开发、测试和部署。本文介绍微前端架构的概念与优势,并指导如何实施。微前端架构具备自治性、技术多样性和共享核心的特点,能够加速开发、提高可维护性,并支持灵活部署策略。实施步骤包括定义服务边界、选择架构模式、建立共享核心、配置跨服务通信及实现独立部署。尽管面临服务耦合、状态同步等挑战,合理规划仍可有效应对。
下一篇
无影云桌面