RAG:我不只是一个检索器!

2024-06-22 22:25:22 浏览数 (2)

年初在我独到的技术见解:LLM的演进与发展文章中和大家分享了LLM的应用和发展,其中有简单介绍过RAG技术,也提到我个人建议在大模型的应用中,能用prompt搞定就别碰RAG,能利用好RAG技术实现需求就别去训练模型,非要训练模型能sft就别pretrain,以上三个大招都用上都实现不了你的需求,非要训自己的垂域大模型,那就快点准备数据,真正应用的时候,估计还是躲不掉三面三步。(不针对算法人员,我说应用呢~)

RAG通常被大家认为就是一个检索器,或者就是一个大模型的辅助,但是目前的RAG技术已经越来越强大了。反过来看,我们可以认为,LLM只是RAG技术的一个模块而已。

本文就详细介绍第二个大招,RAG(Retrieval-Augmented Generation)检索增强技术。

同样从以下几个方面进行梳理:

1. RAG介绍

主要介绍RAG是什么,以及它的技术发展

2. RAG技术优势和应用

主要介绍RAG能干什么?它的技术优势有哪些?我们在什么场景和应用上使用它?

3. RAG技术框架

详细介绍RAG的技术框架和各个模块的作用和相互关系

4. RAG行业案例

基于Baichuan的行业案例来介绍RAG的具体流程

1. RAG介绍

Retrieval-Agumented Generation--检索增强生成 aka RAG。一般说RAG技术,我更偏向认为它是一个系统,主要包含三个核心部分:"R“ and ”A“ and “G”,“检索”,“增强”,“生成”。

RAG 通过在语言模型生成答案之前,先从广泛且权威的文档数据库中检索相关信息,然后利用这些信息来引导和增强大模型的生成,极大地提升了生成内容的实时性,准确性,相关性和可信性。

之前我们介绍过,大模型能够直接回复用户的问题是因为,大模型把海量知识库压缩到它的模型参数中,然后再通过问答对微调模型让它具有指令遵循能力,具有人类推理总结等能力,最后通过强化学习让模型和人类价值观对齐。所以用户和大模型进行对话的时候,模型是基于它的压缩知识库参数和算法去推理生成答案。如果是涉及到知识盲区了,只能通过再次学习微调那个压缩知识库参数。大家也都知道学习是需要成本的。大家也都知道学习是需要成本的,不管是人力还是算力。

RAG表示:我有一妙招,用户的需求可能很简单,对于一个小问题去微调改变千辛万苦训练出来的大模型没有必要,我可以提前将用户相关的知识准备好后作为输入,大模型发挥推理和文本润色能力就好。

其实从广泛意义上说,我们小学时候查词典也是一个RAG技术

我们长大了使用浏览器解决问题也是一种RAG技术

在大模型之前的客服问答系统中通过文本匹配问答对也是RAG技术

只是LLM的发展促进了RAG技术的发展,让RAG这颗技术树枝繁叶茂。

Lewis 在 2020 年提出的 RAG 概念,近几年快速演变,经历了研究旅程中的几个不同阶段。起初,研究旨在通过在预训练阶段注入额外知识,来强化语言模型。ChatGPT 的推出让生成这个模块性能大幅提升,极大地促进了对大模型进行深入上下文理解能力的兴趣,并加速了 RAG 在推理阶段的发展。随着研究人员对大语言模型(LLMs)能力的深入挖掘,焦点转向了提升它们的可控性和推理技巧,以满足日益增长的需求。GPT-4 的问世是一个重要里程碑,它采用了一种将 RAG 与微调技术结合的新方法,同时继续优化预训练策略。

2. RAG技术优势和应用

通过上面介绍,RAG检索增强生成能干的事情无非就是:检索,检索增强,检索增强生成。

然而,随着大模型本身的持续进步,一些人开始质疑RAG技术未来的地位。他们认为,如果大模型能够消化足够多的信息(支持长上下文)以及提高内部处理复杂性(大模型推理能能力),那么外部检索可能就不再必要。表面上看这种观点有其合理之处,但它忽视了一个关键因素:知识的动态性。世界在不断变化,信息也在持续更新。RAG技术通过实时检索最新信息保持了模型的时效性和准确性,这是单纯依靠预训练大模型难以实现的。

2.1 RAG的优势和劣势

2.1.1 RAG和传统语义检索

与传统检索相比,当前 RAG 系统最显著的不同之处在于其组件的灵活性和模块化设计。人们正不断以新颖和创造性的方式将大语言模型与检索结合起来,从数据中挖掘出更深层次的洞见。

现在RAG的方向也是和大模型技术共同进步,向Agent框架和思路发展。

RAG的语义检索重点通常放在向量化,也就是通过embedding模型将语句转换为高维向量。它的优势是:

(1)语义理解能力:句子(词)向量化后包含了语义信息,能够捕捉到词汇之间的语义联系,而基于关键词的检索需要分词后去匹配到关键词,忽略了词语之间的语义联系。

(2)容错性:关键词检索需要完全匹配,而embedding能够理解词之间的潜在含义,所以具有一定的鲁棒性。

(3)领域数据泛化性:对于专业领域词汇,RAG可以通过微调模型的方式让模型理解如何将问题映射到专业词汇;而关键词检索需要不断的增加匹配对数据或者添加规则解决,泛化能力不强。

当然传统的匹配方法在有些情况下是有效率和性能优势的,在实际项目应用中,我们应该灵活结合两者优缺点配合使用。

2.1.2 RAG和LLM微调

对于RAG和LLM技术的选取,可能被问到的问题是:

现在大模型这么厉害,我直接用大模型不行吗?

不行,大模型容易产生幻觉,大模型不能回答实时更新的问题,大模型不能回答专业领域的问题,大模型无法获取个人和公司私密性文档数据。

那我用业务数据训练大模型或者微调大模型,在本地部署保护数据资产,不行吗?

可以,业务提供足够多样性的训练数据,可以基于大模型进行微调。但是比RAG成本高,无论是资金成本还是人力成本,我们可以结合finetune和RAG的优缺点进行选择。

什么时候用微调,什么时候需要训练生成大模型,其实在LLM的分享中已经聊过。

RAG 和 FT技术,在实际项目应用中并不是相互排斥的,它们应该是互补的。

2.1.3 RAG和支持长文本LLM

我不在乎数据保密,我直接用支持长文本的大模型不行吗?

如果去年我们考虑的LLM对于领域知识问题解决方案是:使用RAG还是使用模型微调?

今年我们的疑问可能就是:随着LLM的发展,是否还需要RAG和finetune?

LLM一直在进步,长文本支持一直是他发展的方向之一,最近层出不穷的支持长上下文的技术论文和开源框架,闭源API出现。我也调研了主流的技术方案。那RAG会因为LLM对长文本的支持而消失么?通过调研得出的结论是:不会。至少现阶段不会。

(1)安全和隐私

kimi是目前提供的支持长文本最大的模型,但是只能提供API形式,通常企业和个人不会提供核心数据。

如果要基于开源支持框架/自研框架进行私有化部署,则需要研发以及全方位对比测评,而目前测评的支持长上下文的开源LLM,对于业务数据的理解能力无法满足业务需求。

(2)性能

从模型算法角度,输入token越多会带来耗时问题,当然推理速度提升也是算法和工程发展的一个重要方向。

kimi的API对于150W字的文档,一个问题大概等1分钟。这个级别的耗时对于问答任务几乎是不可接受的。这些支持长上下文的LLM技术更适合做对整篇文章的理解以及简单推理,比如摘要和速读;而检索任务目前还是RAG更有优势。

我们再从一些实验结果来具体了解下目前支持长上下文的LLM的现状:

来源:https://www.bilibili.com/video/BV1eM4m1D7gM/?spm_id_from=333.337.search-card.all.click&vd_source=75bd9e8ff9ebcb04832827d49a8cb2fb

实验的一些结论:

针(有效片段)越多,难度越大;

上下文开始部分的针要比结尾部分的针更难;

推理要比检索更难(检索到后进行再一次的推理,难度更大)。

个人建议不要被一些公众号文章误导就认为这些技术能够很好的应用到实际需求中,在海底捞针任务中,能高质量的检索到内容需要保持存疑,很多测试表明目前的支持超长文本模型对于单针检索的效果并没有很好,除非检索片段位置在后半段。

当然这个问题一定是在慢慢改善的

上面讲了这么多,RAG这么厉害,那数据都给RAG,让RAG去检索生成?选择一个最好的底座大模型一劳永逸?

不行,RAG只是弥补LLM的短板,它本身也有自己的短板,比如对多轮对话的理解,问题的指代消除,关联文档和片段的检索,召回和重排的性能等等。

再次强调,大模型应用最大的形式应该是RAG和LLM互补,联合使用让性能最佳。

2.2 RAG的应用

文章开头就说过,广义上的RAG技术是在大模型之前就出现的,它的应用场景是很广泛的,大方向上:搜索引擎,智能客服,智能问答。小方向上语义匹配,文本匹配等,比如之前写过的一篇文章:是谁~还不会优雅的构建fewshot!就是RAG的一个应用方向。

所有大模型的应用方向,只要你需要外部知识库的支援,或者严谨场景需要问题答案出处,或者不能容忍大模型出现幻觉问题,都可以搭配使用RAG技术。

3. RAG技术框架

RAG 研究范式不断发展,RAG 被分为三个阶段:初级 RAG、高级 RAG 和模块化 RAG。尽管 RAG 方法的提出能够解决原生 LLM 的幻觉和时效等问题,但它也展示了一些局限性。高级 RAG 和模块化 RAG 的开发是为了克服初级 RAG 中的这些特定缺点的创新。

看过同济大学的RAG综述论文的应该对下面的图不陌生。

3.1 初级 RAG

初级RAG范式是早期的方法论,只是chatGPT的广泛使用让RAG技术获得了更多人关注。初级RAG主要包括索引,检索,生成,也被称为"检索-阅读"框架。

索引 - 将文档分割成短小的片段,并利用编码器建立一个向量索引。

检索 - 根据问题与这些片段之间的相似度来寻找相关的文档片段。

生成 - 结合检索到的信息,生成回答问题的内容。

然而,初级 RAG 遇到了显著的缺点:

检索挑战:检索阶段经常在精确度和召回率上挣扎,导致选择不对齐或不相关的块并丢失关键信息。其中的除了embedding和rerank算法本身的挑战外,对于文档排版分析,文本切片,切片的chunking_size的粗放策略(切片太大,影响检索准确性,切片太小,丢失连贯上下文以及完整语义信息)等等。

生成困难:在生成响应时,模型可能面临幻觉问题,产生与检索上下文不支持的内容。

增强障碍:将检索到的信息与不同任务整合可能具有挑战性,有时会导致输出不连贯或不一致。此外,还有一个担忧是生成模型可能过度依赖增强信息,导致输出仅仅是复述检索内容而没有添加有洞察力或综合信息。

3.2 高级 RAG

初级 RAG 在信息检索、内容生成和信息增强方面存在挑战。为此,高级 RAG 应运而生,它在检索前后加入了额外的处理步骤。在检索前,可以采用查询重写、路径选择和扩展等方法来缩小问题与文档片段之间的语义差异。检索后,对文档进行重新排序,以避免在信息处理中出现信息丢失或上下文信息过于冗长的问题。

高级 RAG 引入了特定的改进,以克服初级 RAG 的限制。它专注于提高检索质量,采用了预检索和后检索策略。为了解决索引问题,高级 RAG 通过滑动窗口方法、细粒度分割和元数据的整合,改进了其索引技术。此外,它还采用了几种优化方法来简化检索过程。预检索过程:在这个阶段,主要关注是优化索引结构和原始查询。优化索引旨在提高被索引内容的质量。这涉及到策略:提高数据粒度、优化索引结构、添加元数据、对齐优化和混合检索。查询优化的目标是使用户的原始问题更清晰、更适合检索。常见方法包括查询重写、查询转换、查询扩展和其他技术。

Naive RAG 在检索质量、响应生成质量以及增强过程中存在多个挑战。Advanced RAG 范式随后被提出,并在数据索引、检索前和检索后都进行了额外处理。通过更精细的数据清洗、设计文档结构和添加元数据等方法提升文本的一致性、准确性和检索效率。在检索前阶段则可以使用问题的重写、路由和扩充等方式对齐问题和文档块之间的语义差异。在检索后阶段则可以通过将检索出来的文档库进行重排序避免 “Lost in the Middle ” 现象的发生。或是通过上下文筛选与压缩的方式缩短窗口长度。

高级RAG的检索增强优化方案:

检索增强的阶段:在预训练、微调和推理三个阶段中都可以进行检索增强,这决定了外部知识参数化程度的高低,对应所需要的计算资源也不同。

检索增强的数据源:增强可以采用多种形式的数据,包括非结构化的文本数据,如文本段落、短语或单个词汇。此外,也可以利用结构化数据,比如带有索引的文档、三元组数据或子图。另一种途径是充分发挥 LLMs 的能力,从模型自身生成的内容中检索。

检索增强的过程:最初的检索是一次性过程,在 RAG 发展过程中逐渐出现了迭代检索、递归检索以及交由 LLMs 自行判断检索时刻的自适应检索方法。

3.3 模块化 RAG

随着 RAG 技术的进一步发展和演变,新的技术突破了传统的 Naive RAG 检索 — 生成框架,基于此我们提出模块化 RAG 的概念。在结构上它更加自由的和灵活,引入了更多的具体功能模块,例如查询搜索引擎、融合多个回答。技术上将检索与微调、强化学习等技术融合。流程上也对 RAG 模块之间进行设计和编排,出现了多种的 RAG 模式。然而,模块化 RAG 并不是突然出现的,三个范式之间是继承与发展的关系。Advanced RAG 是 Modular RAG 的一种特例形式,而 Naive RAG 则是 Advanced RAG 的一种特例。

模块化 RAG 架构超越了前两个 RAG 范式,提供了增强的适应性和多样性。它整合了多种策略来改进其组件,例如添加搜索模块进行相似性搜索和通过微调来精炼检索器。为了应对特定挑战,引入了重构的 RAG 模块和重新排列的 RAG 流程的创新。向模块化 RAG 方法的转变正在变得普遍,支持顺序处理和跨其组件的集成端到端训练。尽管具有独特性,模块化 RAG 仍然建立在高级和初级 RAG 的基本原则之上,展示了 RAG 家族内的进步和精炼。

新模块:模块化 RAG 框架引入了额外的专门组件,以增强检索和处理能力。

搜索模块适应特定场景,使得可以直接跨各种数据源(如搜索引擎、数据库和知识图谱)进行搜索,使用 LLM 生成的代码和查询语言。RAG-Fusion 通过采用多查询策略,将用户查询扩展到不同视角,利用并行向量搜索和智能重新排序来揭示显式和变革性知识,解决了传统搜索的限制。

记忆模块利用 LLM 的记忆来指导检索,通过迭代自我增强创建一个与数据分布更紧密对齐的无界记忆池。RAG 系统中的路由通过多样化的数据源导航,为查询选择最佳路径,无论是涉及摘要、特定数据库搜索还是合并不同信息流。

预测模块旨在通过直接通过 LLM 生成上下文来减少冗余和噪声,确保相关性和准确性。

最后,任务适配器模块通过为zero-shot自动化提示检索和通过少次射查询生成创建特定于任务的检索器,将 RAG 定制到各种下游任务。

新模式:模块化 RAG 通过允许模块替换或重新配置以应对特定挑战,提供了显著的适应性。这超越了初级和高级 RAG 的固定结构,后者以简单的“检索”和“阅读”机制为特征。此外,模块化 RAG 通过整合新模块或调整现有模块之间的交互流程,扩展了这种灵活性,增强了其在不同任务中的适用性。

Modular RAG的好处是显⽽易⻅的,将当前RAG的技术整合到⼀个范式中,提供了更加全⾯且更⾼维度的视⻆,可以让研究⼈员快速把握当前研究发展的全貌和趋势,构建⼀个RAG的思维地图。通过模块之间编排,相关的技术和⽅法被清晰的汇总,RAG系统的设计和构建变得更加便利,更容易定位到问题环节。

对于研究⼈员。研究⼈员可以在全⾯了解RAG当前的发展的基础上,更好地识别当前RAG各个模块中的缺陷,聚焦研究内容,提出新的模块类型、模块和算⼦。

对于开发⼈员。⼀⽅⾯开发研究⼈员可以借鉴当前经过验证的RAG Flow Pattern,快速上⼿。另⼀⽅⾯开发⼈员可以根据特定的数据情况、使⽤场景、下游任务以及其他需要去定制化地编排不同的RAG模块和算⼦,定义新的Flow和 Flow Pattern。

3.4 RAG技术框架

同济大学RAG-Survey已经总结出了7个RAG Flow模式以及3个典型的应用场景。

针对自己的业务需求去找最适合场景的RAG-Flow,而Flow中每个步骤就是模块化RAG中的一个模块。

论文也提到了RAG的生态系统:

4. RAG最佳行业案例

基于百川的宣传资料整理(查看原⽂)。针对⽤户⽇益复杂的问题,百川借鉴了Meta的CoVe技术,将复杂Prompt拆分为多个独⽴且可并⾏检索的搜索友好型查询。利⽤⾃研的TSF(Think-Step Further)技术来推断和挖掘⽤户输⼊背后更深层的问题,以更精准、全⾯地理解⽤户意图。在检索步骤中,百川智能⾃研了Baichuan-TextEmbedding向量模型。同时引⼊稀疏检索rerank 模型(未披露),形成向量检索与稀疏检索并⾏的混合检索⽅式,⼤幅提升了⽬标⽂档的召回率。此外还引⼊了self-Critique让⼤模型基于 Prompt、从相关性和可⽤性等⻆度对检索回来的内容⾃省,进⾏⼆次查看,从中筛选出与 Prompt 最匹配、最优质的候选内容。

最后我们借助Baichuan的RAG案例,来分析RAG应用中的难点和解决方案。

Baichuan的RAG的主要流程:

1. 用户问题的扩写和改写:主要用于将复杂的Prompt拆分为多个独⽴且可并⾏检索的问题去查询,有点我们写prompt时候的思维链,思维树的概念。百川是采用了自研的Think-Step Futher技术去挖掘用户的真实问题,能更深入和更精准的了解用户意图。

2. 判别:有了多并发的一系列子问题后,他还有一个Judge过程,来判断问题如果模型能回答,就直接生产;如果不能回答就需要进行检索。

3. 检索和重排:对于检索它使用了稀疏检索和密集检索的混合检索形式,再结合生产的结果,多路召回问题相关知识,再通过rerank技术获取有用信息。

4. 自省:获取到问题相关信息后,百川使用self-Critique技术,让⼤模型对检索回来的内容再次进行思考,判断召回片段是否有用是否相关等,再次从中筛选出与 问题最匹配的候选内容。

5. 生产:最后利用LLM结合检索到的信息生成答案。

可以看出,最终表现形式虽然就是简单的问答,但是整个流程中处处是难点。但是大家也要注意结合自己的业务需求和成本区考虑,去选择最适合自己的流程~

我正在参与2024腾讯技术创作特训营最新征文,快来和我瓜分大奖!

参考:

https://arxiv.org/pdf/2312.10997.pdf

https://blog.csdn.net/TgqDT3gGaMdkHasLZv/article/details/135985279

https://blog.csdn.net/TgqDT3gGaMdkHasLZv/article/details/135985279

https://zhuanlan.zhihu.com/p/670432927

https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2650901201&idx=1&sn=3a9bd61403fb4b024ec5d8c128990495&scene=21#wechat_redirect

0 人点赞