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

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
大数据开发治理平台 DataWorks,不限时长
简介: 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

目录
相关文章
|
4天前
|
消息中间件 监控 数据管理
构建高效微服务架构:从理论到实践
【5月更文挑战第21天】 在现代软件开发的浪潮中,微服务架构已成为企业追求敏捷开发、持续交付和系统弹性的关键解决方案。本文深入探讨了构建一个高效微服务架构的核心原则与实践策略,旨在为开发者提供一个清晰的指南,帮助他们在设计分布式系统时做出明智的决策。我们将从微服务的基本概念出发,逐步展开对关键组件、通信机制和数据管理的讨论,并分享实际案例分析以验证理论的有效性。
|
4天前
|
Kubernetes Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第21天】 随着企业加速其数字化战略,云原生技术已不仅仅是一种趋势,而是推动业务敏捷性、可扩展性和创新的关键因素。本文将深入探讨云原生架构的核心组件,包括容器化、微服务和持续集成/持续部署(CI/CD),以及如何利用这些技术来优化资源使用、提高开发速度并确保系统的弹性。通过分析多个行业案例,我们将阐明云原生实践如何使组织能够快速响应市场变化,降低运营成本,并在高度竞争的环境中保持领先地位。
|
1天前
|
存储 监控 持续交付
构建高效微服务架构:从理论到实践
【5月更文挑战第23天】 在当今的软件开发领域,微服务架构已成为一种流行的设计模式,它承诺通过将大型单体应用拆分为一系列小型、自治的服务来提高可扩展性、灵活性和敏捷性。然而,实现这一理念并非没有挑战,它要求开发者们重新思考如何组织代码库、处理数据一致性以及确保服务之间的有效通信。本文将深入探讨构建微服务的最佳实践,包括关键的设计原则、技术选型、持续集成与部署,以及监控和日志策略,旨在为读者提供一套实用的指南,帮助他们在构建自己的微服务系统时避免常见的陷阱。
|
1天前
|
存储 监控 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第23天】 在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性成为企业技术选型的宠儿。本文将深入探讨如何构建一个高效可靠的微服务系统,涵盖从设计原则到具体实现的各个关键点。我们将分析微服务的优势,探讨其面临的挑战,并提出一系列解决策略。从服务的划分、治理、到持续集成/持续部署(CI/CD)流程的建立,本文旨在为开发者提供一套全面的微服务架构建设指南。
|
2天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的应用
【5月更文挑战第23天】 随着企业加速其数字化转型的步伐,传统的IT基础设施已无法满足市场对于敏捷性、可扩展性和成本效益的需求。云原生架构作为一种新兴的设计理念和模式,以其独特的灵活性和效率,正成为推动企业技术革新的关键力量。本文将探讨云原生的核心组件、实施策略以及面临的挑战,并分析其在帮助企业实现快速迭代与创新中的作用。
|
2天前
|
消息中间件 数据管理 开发者
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第23天】 在当今软件开发的世界中,微服务架构已经成为设计灵活、可扩展且容错系统的首选方法。本文将深入探讨构建高效微服务架构的关键要素,包括服务划分、通信机制、数据管理以及持续集成与部署等。我们将通过实际案例和最佳实践,为后端开发者提供一套行之有效的指南,帮助他们在不断变化的技术环境中保持竞争力。
4 0
|
2天前
|
消息中间件 监控 API
构建高效微服务架构是后端开发的关键
【5月更文挑战第22天】构建高效微服务架构是后端开发的关键,涉及核心原则如服务独立、去中心化、自治和轻量级通信。优势包括可扩展性、独立性、技术灵活性和团队协作。最佳实践包括恰当的服务拆分、选择RESTful API、RPC或消息队列进行通信、处理数据一致性和分布式事务、实施服务治理与监控,以及确保安全性与权限控制。随着技术进步,未来将探索服务网格、容器化和云原生技术,以提升微服务架构的效能和适应性。
12 0
|
3天前
|
Kubernetes Cloud Native API
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第22天】 随着企业加速其数字转型的步伐,云原生架构成为了推动创新、提升敏捷性及优化资源使用效率的核心动力。本文深入探讨了云原生技术如何助力企业实现弹性伸缩、持续集成与持续部署(CI/CD)、微服务架构以及如何借助容器化和编排工具来管理复杂应用。通过分析云原生架构的主要组件,包括容器、服务网格、不可变基础设施和声明式API,揭示了它们如何共同塑造出一个高度自动化、可扩展的云计算环境。此外,文中还讨论了采纳云原生实践所面临的挑战与克服策略,为读者提供了一个关于云原生技术如何赋能业务发展和技术升级的全面视角。
|
3天前
|
设计模式 负载均衡 数据管理
构建高效可扩展的微服务架构:后端开发的新趋势
随着数字化转型的加速,企业对后端系统的要求越来越高。本文探讨了如何构建一个既高效又可扩展的微服务架构,以满足快速变化的市场需求。我们将从微服务的核心概念出发,分析其设计原则,并讨论在实现过程中面临的挑战以及应对策略。文章还将展示通过采用微服务架构,企业如何获得更好的业务敏捷性和技术创新能力。
|
3天前
|
消息中间件 安全 数据管理
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第21天】 在现代软件开发的浪潮中,微服务架构已经成为一种流行且有效的解决方案。它通过将复杂的应用拆分成一组小服务来增强系统的可维护性、扩展性和技术多样性。本文深入探讨了构建高效微服务架构的关键要素,包括服务划分原则、通信机制、数据管理以及安全性考量。通过对这些核心组件的分析,我们将揭示如何优化后端开发流程,以适应快速变化的市场需求和技术演进。