大模型+检索增强（RAG、Atlas 和 REPLUG）

Yuezero_

已于 2024-03-31 02:46:33 修改

阅读量9.1k

点赞数 15

文章标签：自然语言处理人工智能

于 2023-09-19 15:46:40 首次发布

本文链接：https://blog.csdn.net/weixin_54338498/article/details/133024348

版权

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

https://github.com/ninehills/blog/issues/97

1. 检索增强生成 RAG

在问答和对话的场景下，通常可以通过检索和生成两种方式得到一个回复。检索式回复是在外部知识库中检索出满意的回复，较为可靠和可控，但回复缺乏多样性；而生成式回复则依赖于强大的语言模型中储存的内部知识，不可控，解释性差，但能生成更丰富的回复。把检索和生成结合起来，Facebook AI research 联合 UCL 和纽约大学于 2020 年提出：外部知识检索加持下的生成模型，Retrieval-Augmented Generation (RAG) 检索增强生成。

检索：这是指系统搜索庞大的数据库或存储库以查找相关信息的过程。
生成：检索后，系统生成类似人类的文本，整合获取的数据。

检索增强方法来克服大型语言模型(Large Language Models, llm)的局限性，比如幻觉问题(胡言乱语)和知识有限问题(常用于补充最新知识、公司内部知识)。检索增强方法背后的思想是维护一个外部知识库，在提问时检索外部数据，并将其提供给LLM，以增强其生成准确和相关答案的能力。

在这里插入图片描述

原理

RAG 由两部分组成：

第一部分负责在知识库中，根据 $query_x$ 检索出 top-k 个匹配的文档 $z _i$ ；
第二部分将 query 和k个文档拼接起来作为QA的prompt，送入 seq2seq 模型，生成回复 $y$ 。

第一部分：Retriever

在第一部分 Retriver 中，RAG 通过两个不同的 BERT 把外部知识和 query 嵌入为稠密向量，做内积得到内积最大的 k 个文档。将 query 和 k个文档拼接起来组成 k 个输入，作为第二部分的输入。

第二部分：Generator

Generator 中有两种使用文档的方式。

第一种称为 RAG-Sequence model：使用同一个文档生成每个词，先确定一个文档 $z_i$ ，然后计算 $p(y|x,z_i)$ ；
第二种称为 RAG-Token model：使用不同的文档生成每个词，对于第 i 个位置，候选词的概率等于所有文档的条件概率之和，即计算候选词对文档的边际概率。

BART 是一个基于完整的 transformer 预训练模型，使用去噪作为预训练任务。作者选用 BART-large 作为 RAG 的生成器。

在训练过程中，只有负责嵌入 query 的 BERT 和负责生成的 BART 参与微调更新参数，负责嵌入外部知识的 BERT 不用更新参数。在测试过程中，RAG-Token model 在计算当前词的概率时，前面位置候选词的概率已经完成计算了。因此，RAG-Token model 如同朴素的生成模型一样使用 beam search 解码。而 RAG-Sequence model 要遍历完所有文档才能得到每个位置候选词的概率。因此需要对每个文档使用 beam search 解码，然后再整合。

在这里插入图片描述

8大挑战

数据源加载与处理

各种数据加载、解析过程中，如何尽可能保留原始数据的逻辑和语义关系是一个需要注意的问题。可以多尝试不同的加载与解析方式，对比不同的py库。也可预定于好prompt便于LLM理解。

在这里插入图片描述

一个好的prompt可以通过补充相关材料实现：背景知识、互联网检索结果、RAG检索结果、in-context QA实例。

在这里插入图片描述

数据切分难

chunk_size: 对输入文本序列进行切分的最大长度。大语言模型一般会限制最大输入序列长度,比如GPT-3的最大输入长度是2048个token。为了处理更长的文本,需要切分成多个chunk,chunk_size控制每个chunk的最大长度。
chunk_overlap: 相邻两个chunk之间的重叠token数量。为了保证文本语义的连贯性,相邻chunk会有一定的重叠。chunk_overlap控制这个重叠区域的大小。

举例来说,如果chunk_size设为1024,chunk_overlap设为128,则对一个长度为2560的文本序列,会切分成3个chunk:
chunk 1: 第1-1024个token
chunk 2: 第897-1920个token (与chunk 1重叠128个)
chunk 3: 第1793-2560个token (与chunk 2重叠128个)
这样的切分方式既满足了最大长度限制,也保证了相邻chunk间语义的衔接。适当的chunk大小和重叠可以提升大语言模型处理长文本的流畅性和连贯性。

在这里插入图片描述

如何对原始文本进行切分(如何选择 chunk size)，影响很大，需要根据业务具体需求判断：

实验改超参数，不断测试
解耦 index 时和 generation时的 chunk size，这里也有两种方式：

在这里插入图片描述

在检索时，文档如果可以构建为文档树结构，比如段1段2，则可以先让 LMM 分别进行摘要，在搜索时首先根据摘要定位段落（也是使用相似度 ann 的方式），然后在段落内部 ann 检索。
将文档分的很小很小，这样每一个 chunk 内部的语义已经很清晰了，然后检索到 chunk k 之后，我们取 chunk k-1, k, k+1 ，即相邻的 chunk 作为上下文。

检索效果不好

在这里插入图片描述
无法检索到有效的chunk (模型问题，切分问题) ； chunk 内部有无效信息 (先进行摘要，相关性过滤)。

提升方法：

可以使用混合搜索 Hybrid Search ，即混合其他相似度评价指标，比如 Bm25，Keyword，Vector
混合其他的搜索字段，比如元数据 meta-data，同时也可以考虑让 LLM 去抽取chunk 的大义，关键词；也可以结合上下文摘要

检索结果过多或过长

在这里插入图片描述
检索结果的过滤：后处理，其实就是一个重排的过程

在这里插入图片描述

告诉模型原始query 和 metadata 中类型的集合，让模型帮助我们得到子集合，从而进行筛选。

Re-rank 的问题：需要真实业务 domain 的数据来微调；这里可以尝试使用 LLM 来 rerank （给LLM写好prompt）。

在这里插入图片描述

答案合成策略：
在这里插入图片描述

Default 版本：
在这里插入图片描述

迭代式 refine 版本：一条一条 chunk 输入，不断让模型修改更新原答案
在这里插入图片描述

可解释性与鲁棒性

在这里插入图片描述

复杂query的处理

Prompt → Sub-query , 不断拆分成子问题 → 直到可以回复
在这里插入图片描述

2. Vector DB

在这里插入图片描述

第一阶段，Vector DB以文件形式存储vector数据，没有索引和查询功能；
第二阶段，Vector DB使用KD-tree等索引结构，可以实现一定查询功能，但高维向量的查询效率不高；
第三阶段，Vector DB通过复杂的Index索引算法，实现高效的索引和查询功能，可以高效的处理高维向量。

向量数据库和传统数据库的区别：

传统数据库存储的是文本，基于文本精确匹配(关键字搜索BM25)的精确查找，查询结果是符合条件的文本/None。缺点是不支持语义检索。
向量数据库存储的是embedding vector，基于embedding相似度的近似查找，查询结果是TOP-K个最相似的向量；

在这里插入图片描述

向量数据库Vector DB：向量数据库为vector数据提供Embedding存储、Index索引、Search查询三个功能。

Embedding作为Vector的表示形式：因为在深度学习模型中，所有的数据都是Tensor（高维Vector）形式，所以需要训练一个Embedding Model，将文本、图像、视频等各种模态的非结构化数据压缩为Embedding这种结构化的数据，同时保证真实世界中的语义相似度和在Embedding Space中的语义相似度一致。
Index索引功能使用tree、graph、hash等索引方式，对Vector数据进行分区/分片，通过缩小搜索空间，使得Vector DB更加高效的进行向量相似度查询，提高高维向量embedding数据处理效率。（K-means、Faiss、Inverted File Index(IVF)、Hierarchical Navigable Small World graphs(HNSW)）
Search功能是通过向量相似度算法实现的，最常用的2个算法是点积和余弦相似度。

相似性搜索

在这里插入图片描述
相似性搜索算法有很多，可以按索引Index使用的数据结构（tree/graph/hash/IVF） 分类（加快索引检索），也可以按照减少向量的大小(量化降维向量数值长度) 分类（加快相似度运算）。

按照索引Index使用的数据结构（tree/graph/hash/IVF） 分类：
在这里插入图片描述

基于hash的索引结构：将高维向量映射为低维向量。如LSH。
基于tree的索引结构：将高维空间划分为多个子空间，用树结构来存储和检索。如KD-Tree、Annoy。
基于graph的索引结构（主流）：用图节点表示向量数据，图边表示向量相似性。如NSW、HNSW。
基于IVF的索引结构（主流）：将向量空间划分为不同的Voronoi单元，进行单元聚类，构建倒排索引。如IVF。

按照减少向量的大小(量化降维向量长度) 分类：
在这里插入图片描述

Flat indexing 扁平化索引：使用索引算法（ANN、IVF、HNSW等），直接计算query embedding与DB中所有embedding的距离（什么都不做）。为了将其与Quantized 区分开，使用这种方法时通常称为IVF-Flat、HNSW-Flat等。
Quantized indexing 量化索引：将索引算法（IVF、HNSW等）与量化方法结合，减少内存占用并加快索引速度，量化方法分为标量量化（Scalar Quantization，SQ）或乘积量化（Product Quantization，PQ）

相似性搜索算法分类与汇总：
在这里插入图片描述

当前流行的向量数据库使用的相似性搜索算法汇总：

在这里插入图片描述

ANN

在这里插入图片描述
ANN暴力搜索中比较经典的是K-means算法：

ANN暴力搜索之Faiss算法：
在这里插入图片描述

Inverted File Index(IVF)

文档的倒排索引：构建单词表，再构建单词_id到文档_id的映射。
在这里插入图片描述

向量的倒排索引：构建Voronoi单元(区域)集合，再构建点到Voronoi单元的映射。

在这里插入图片描述

Hierarchical Navigable Small World graphs(HNSW)

在这里插入图片描述

相似性度量

在这里插入图片描述

3. Atlas

Atlas： Few-shot Learning with Retrieval Augmented Language Models
Atlas ：用检索增强的语言模型进行few-shot学习

Atlas 拥有两个子模型，一个检索器与一个语言模型。当面对一个任务时，Atlas 依据输入的问题使用检索器从大量语料中生成出最相关的 top-k 个文档，之后将这些文档与问题 query 一同放入语言模型之中，进而产生出所需的输出。
在这里插入图片描述

2.1 模型架构 Architecture

Atlas 模型的基本训练策略在于，将检索器与语言模型使用同一损失函数共同训练。检索器与语言模型都基于预训练的 Transformer 网络，其中：

检索器基于 Contriever 设计，Contriever 通过无监督数据进行预训练，使用两层编码器，query 与 document 被独立的编码入编码器中，并通过相应输出的点乘获得 query 与 document 的相似度。这种设计使得 Atlas 可以在没有文档标注的情况下，使用对比学习预训练检索器，从而显著降低内存需求。
语言模型基于 T5 (encoder-decoder架构) 进行训练，将检索回来的每个passage都与question拼接为<question, passage>，通过encoder分别编码，然后concat在一起输入decoder进行 Cross-Attention，生成最终的回复。这种 Fusion-in-Decoder 的方法有利于 Atlas 有效的适应文档数量的扩展。

2.2 训练目标 Training objectives

利用语言模型提供监督信号来训练检索器，联合训练 检索器retriever 和 语言模型LM：如果语言模型在生成输出时发现有用的文档，则检索器目标应鼓励检索者对所述文档进行更高的排名。基于这种想法，论文设计了以下四种不同的损失函数：

Attention Distillation (ADist)：在decoder的cross attention模块中计算的文档跟输出之间的得分可以被用来充当每个文档的重要性，对于每个文档，计算它的每个token在语言模型decoder的每层网络，每个attention的head的注意力得分的平均值作为该文档的重要性得分，进而得到多个文档的注意力得分分布 $P_{ATTN}(d_k)$ ，通过最小化检索器返回TOP-K的概率分布 $P_{RETR}(d_k)$ 跟语言模型的注意力得分分布 $P_{ATTN}(d_k)$ 之间的KL散度来优化模型。也就是希望检索返回的得分分布 $P_{RETR}(d_k)$ 尽可能的接近 $P_{ATTN}(d_k)$ 。这个loss仅用于优化检索器的参数，而不是语言模型。
End-to-end training of Multi-Document Reader and Retriever(EMDR2)：这种loss的设计将检索返回的文档作为隐变量，q 是给定的query，a 是最终的生成结果，对应的检索器的loss由语言模型得分跟检索得分的乘积的对数组成，但是通过固定语言模型的参数，实现只优化检索器的参数。之前提及的FiD，RAG等检索增强模型的联合训练使用的基本都是这种类型的损失函数。
Perplexity Distillation(PDist)：上述1)的改进版，将ADist中的目标分布，由pATTN，改成语言模型的得分经过softmax操作后的概率分布，然后训练目标是最小化pATTN跟改进版的概率分布，进而去优化检索器的参数。
Leave-one-out Perplexity Distillation(LOOP)：上述3)的改进版，将对应的语言模型的概率得分改成移除了特定文档后的语言模型得分的负数，训练目标同样是最小化pATTN跟新版语言模型概率分布的KL散度。这种损失函数的计算成本明显高于前面几种。

2.3 代理任务 Pretext task

基于 pretext task 的无监督学习用于联合预训练 retriever 和 language
model，关于预训练的任务涉及，论文也尝试了一下几种不同的方式。

a) Prefix language modeling

以N个字符为单位将文本分块，将每个块(chunk)的文本切分为长度为N/2的2段子序列，用第一段子序列作为query，通过检索模块召回相关的文档，然后去生成结果，生成的目标target是对应的第二段子序列。

b) Masked language modeling

以N个字符为单位将文本分块，对于每一个分块(chunk)，随机抽样若干个平均长度为3的子片段进行mask，直到被mask的长度占文本总长度15%，将被mask后的每个分块作为query输入，通过检索模块去召回相关文档，然后利用语言模型去生成被mask掉的片段。

c) Title to section generation

利用Wikipeida的文章信息，将文章和章节的title作为query输入，通过检索模块去召回相关文档，然后利用语言模型去生成对应章节的详细内容。

2.4 高效的检索器 Fine-tuning

Retriever中的语料通过文档编码器，被编码成向量被存储到索引中，在联合训练retriever跟语言模型LM时，retriever的文档编码器更新后，相应的索引就需要被更新，全量更新索引会耗费非常多的计算资源跟时间。尤其是在finetune阶段，训练样本的数量会远小于文档的索引数，更新索引的时间会增加整体的训练时间。

a) Full index update

训练每经过一定步数后更新全部索引，这种方式的好处在于全量更新索引能保证retriever中的文档编码器跟索引之间的相关性，同时可以根据实际需要来设置更新的频率。在论文中索引总数是3700万，训练batch size是64，每次召回20个文档，每经过1000步后更新全部索引，更新索引的计算量占模型训练的30%左右。

b) Re-ranking

在训练的每一步，检索模块会召回top-L个文档，返回其中top-K个文档给语言模型，并且更新这个L个文档的索引，L会大于K，也就是每次更新的索引数量会大于语言模型用到的文档数量。在论文中，每次更新的索引数量是语言模型接受文档数量的10倍，更新索引的计算量占模型训练的10%。

c) Query-side fine-tuning

训练过程retriever模块只更新query的编码器，不更新文档document的编码器，那样就不需要更新索引了，所以更新索引的计算量占模型训练0%。固定文档编码器的影响在不同任务下不尽相同，在大多数few shot场景下，这种方式不会带来较大的性能影响，有时甚至能提高模型表现。

总结

检索增强的优势

可解释性：大模型的黑箱属性，使得研究者很难以利用大模型对模型运行机理进行分析，而检索增强模型可以直接提取其检索到的文档，从而通过分析检索器所检索出的文章，可以获得对 Atlas 工作更好的理解。
可控性：我们往往会认为大模型存在训练数据“泄露”的风险，即有时大模型针对测试问题的回答并非基于模型的学习能力而是基于大模型的记忆能力，也就是说在大模型学习的大量语料中泄露了测试问题的答案，而在这篇论文中，作者通过人为剔除可能会发生泄露的语料信息后，模型正确率从56.4%下降到了55.8%，仅仅下降0.6%，可以看出检索增强的方法可以有效的规避模型作弊的风险。
可更新性：检索增强模型可以无需重新训练而只需更新或替换其依托的语料库实现模型的时时更新。

https://www.51cto.com/article/717069.html

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

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