第四节 RAG的核心 - 结果召回和重排序原创

大家好，欢迎来到我们腾讯云开发者社区，腾讯云向量数据库团队，安顿团队共同打造的IG7天入门训练系列课程的第4期，今天呢，我们要讲解的是IG的核心，也就是咱们的这个知识检索哈，那我是来自腾讯云的赵九洲，主要是负责我们整个IG这一块的一些算法，这一块的一些研发，OK,那在之前的课程内容呢，我们已经为大家详细介绍了，如何把我们的文档切分成我们的窗口定义。啊，采用我们的这个向量数据库提供的这样的一个em be模型，转换成这个be，并且存储到我们的这个向量数据库，那这节课呢啊，我们准备好数据之后呢，接下来就要来看一下啊，当用户的问题来了之后，我们该如何使用我们的向量数据库去进行一些相应的知识的一个检索啊。

好，我们先来看一下我们的这个啊主流程，主流程是实际上是包含了三个比较重要的部分啊，第一部分是我们的这个query的这个预处理啊，实际上大家在使用我们这样的一个啊，基于大模型的这样的一个。IG的这些产品的时候，大家可能会发现一个问题啊，初期用户可能更多会基于这样的一个啊，类似于检索的一个思路来使用我们这样的一个产品，这时候他有时候实际上可能就是输入一些关键词，它并不会说把这个问题描述的一个很详细，或者说像一个问题，所以这个时候我们通常会对我们的query去做一些预处理，包括我们的一些query的一些标准化啊，或者是对我们的query去做一些啊增强啊，具体的话我们待会儿会详细说，那que预处理这一块做完之后呢，我们接下来就要去我们的这个。啊，知识库，也就是我们的这个向量数据库当中去找到我们所有啊相关的这些和这个用户输入的query相关相关的一些知识，那这个过程呢，我们就称为这个召回，那召回完之后呢，可能我们召回了N条相关的一个数据，那再下一步呢，就进入到了我们的这个排序的阶段啊，那排序这个阶段呢，实际上就是把我们的这个N条的数据的一个范围啊，尽可能的一个缩小。

那为什么要去做这样的一个事情呢？大家可以考虑一下啊，那如果啊，我现在召回了100条数据，我们把这100条数据都给到模型，那对于模型来说，它实际上压力是非常大的，对吧？你文本越多，那它模型需要去处理的这个文本数据就越多，那模型的效果可能就会啊有一点点这个下降，其次啊，模型它能输入的，或者说它可以支持的这个文本程度是有一定的这个限制的，虽然现在目前有一些模型已经提供了非常长的这样的一个支持的一个输入长度，但实际上你越长的话，整体效果可能确实会有一些折扣啊，所以呢，我们就需要在召回的一个结果当中，尽可能去保留一些和我们用户输入的这个query语义最接近的这些文本，把它保留下来，再最终注入给我们的这个模型。

经过经过模型之后呢，再得到我们最终的这个答案。啊，举个简单的例子啊，假设我们刚才召回了100条，那经过排序之后呢，可能我们就只会保留个5条，最后我们再把这5条给到我们，这就是我们排序的一个作用啊OK，那接下来呢，我们就针对于这三个模块为大家详细介绍一下啊。啊，首先是我们的这个啊，Query的这个预处理的一个阶段啊，那预处理这一块呢，实际上我们要做的第一个事情呢，实际上就是咱们这个意图识别，也就是说当用户的问题来了之后呢，我们会去判断一下用户的这个query它到底是什么样的一个类型的，从而决定我们到底应该走这个是否应该走这样的一个IG的这个链路，啊我们下面有有一些事例啊，例如第一个例子啊，这个用户问了一个深圳有什么好玩的，那对于这样的一个问题的话，实际上我们是没有必要去我们的这个数据库里面去检索。

因为它其实就是简单来看，它实际上就是一个闲聊的一个问题，对吧，那这样的一个问题，那我们只需要交给我们的这个大模型自身去进行一个回答就好了。那假如用户他问的是一个比较偏云计算相关的，或者说偏我们腾讯云产品相关的一些问题，例如他说啊VDB支持哪些检索算法，那对于这样的一个问题，它实际上就是一个垂直领域的一个问题，对吧？那如果你直接让我们大模型去回答，它，实际上就可能会产生一些幻觉，导致回答的一个结果是错的。这个时候因为我们有了这样的意图识别，那我们就可以把我们这个问题引导到我们的这个IG链路，让他去走这个IG的一个流程。

从而保证我们得到一个比较正确的一个答案啊。然后我们再来看一个事例啊，下面还是一个啊，有这样的一个问题啊。为什么某个芒果DB实例内存占用过高，那对于这样的一个问题呢，实际上就是需要去做一些其他的一些处理，例如我们需要去查询一些工具，对吧？那这个链路呢，又和我们的这个IG这个链路是不太一样的，它可能更多涉及到的是一些数据库的一些诊断，那这个时候呢，我们就需要去调用一些工具，那这有。又让我们去走了另外一条链啊，这就是意图识别这个模型啊，他要做的一些事情啊，就是帮助我们判断一下用户输入的这个query，他接下来到底要走哪一条链路啊。好，这是我们的这个预处理当中的意图识别，那我们再来看一下第二啊，第二块呢，是叫做同义句的一个生成。也就是说，当用户输入了这样的一个query之后呢，我们会针对这个RY去生成一些同义句，他为什么要去生成这样的一个同义句呢？因为其实就像刚刚说的啊，一开始用户去使用这样的一个产品的时候，他可能会把它当成一个啊检索引擎去使用，就输入一些关键词啊之类的，那这个时候实际上。

它并不是一个完整的问题，所以我们希望采用这样的一个同义句生成的一个方法来让我们的这个问题。有更多的一些问法，从而尽可能去提高我们整个知识检索的一个召回率啊，举个例子啊，我们这里有一个问题是VDB支持哪些检索算法，那这个时候呢，我们就可以基于这样的一个问题去生成一些新的一些问题，例如VDB有哪些可用的检索算法，列举一下VDB所支持的一检索算法，那我们把这些生成的这些同一问呢，再去经过我们整个这样的一个IG的一个链路，这个时候我们实际上就可以尽可能的避免我们这些知识的一个漏召回。当我们把这些知识全部召回之后呢，我们再做一个这样的一个合并，合并。

啊，我们也可以从右边这个图可以看到啊，但这个时候可能啊，大家就会有一个疑问啊，那你这里这个合并岂不是把我们的这个。召回的这个数据量变多了，对吧，举个例子啊，刚才我们一个句子，它是召回100条，那我们这里生成了两个统一问，包括我们的原问题，那最终我们实际上就找回了啊300条对吧，那这300条我们最后。怎么去用呢？实际上我们在合并的时候也是考虑直接给了我们的这个排序模型，那我们这个排序模型从这300条当中再选择出最终需要的可能5条，就以这样的一个形式来减少我们召回的一个数量啊。好，这是我们的这个同义句。啊，生成我们再看一下我们的第三块啊，这一块是我们的这个query的一个标准化，标准化那这一块要做的事情呢，实际上是就是针对于我们用户输入的这样的一个query，我们会把其中的一些专有名词啊，一些简写或者说一些啊英文去做一些标准化的一些处理，举个例子啊，还是我们刚才这个问题，这个VB支持哪些解锁算法，那么这个时候呢啊，我们会基于一些实体识别的一个方式，把这个VDB给提取出来，然后转换成我们这样的一个比较标准的一个产品，也就是咱们的这个腾讯云向量数据库支持哪些检索，那为什么要做这样的一个事情呢？

首先啊，如果我们使用一些这个开源的通用的一个运营模型，那对于这些模型来说，他因为没有学习过这种。我们云领域相关的一些产品的一些信息，因为对于VDB来说，它实际上是腾讯云领域它专有的一个名词，对吧，它这些开源的模型，开源的模型它不一定会了解这个VDB到底是什么，那对于我们数据库存储的一些知识呢，可能更多存储的会是这样的一个向量数据库，这样的一个名词，就导致我们再去检索的时候啊，模型可能没有办法知道VDB，它就是这样的一个向量数据库。

所以呢。为了解决这个问题呢，我们就有两种方案啊，第一种方案呢，就是咱们这里提到的，我们去做这样的一个query的一个标准化，把我们直接检索啊，变成一个比较专有的这样的一个名词，那还有一种思路就是可以采用我们提供的啊，针对于垂类领域单独去进行微调过的这样的一个背模型。好，这就是我们query处理的啊，第三块啊，咱们的这个query的一个标准化。我们再来看一下啊，我们的第2块啊，刚才提到了。我们这个改到了我们的这个啊。加强数据库，那接下来的话就要把相关的这个文档给检索出来，对吧。好，我们看一下这个流程啊，其实都到了这一步呢，我们要做的一个事情，实际上就是首先我们要把用户的这个输入的这个query啊，也转换成这个bed。

那有了这个embing之后呢，我们就去我们的向量数据库去计算当前输入的这个query embing和向量当中其他所有文档的一个，它的一个啊距离。那其实我们刚刚在之前的课程当中啊，我们介绍过它有一个性质，就是说如果我这个文本它的一个语义是比较接近的话，那在空间当中它的距离是相对来说会更近一些，对吧？那我们这里的检索实际上就是要去利用invading它这样的一个性质啊。只要我们找到了当前的这个。用户输入的query in.它距离它最近的N个文本的一个EMB点，那我们就认为这N条文本就是我们需要检索出来，或者说和我们query语义比较相近的这样的一些文本，这就是我们与add检索它的一个思路，那当然哈，大家可以考虑一下，假设我们的这个知识文档特别多，到了啊3000万条或者说上亿条，那这个时候大家可以考虑一下，如果我们把我们用户输入的query和我们这个知识库当中所有的文本都去算一遍这个相似度的话，那实际上它的时间复杂度是非常高的，对吧？

所以呢，我们的这个销量数据库也是提供了非常多的一些检索的一些优化的一些方式啊，那啊，对于不同的这样的一个使用场景，我们采用了不同的这样的一个。啊，检索的一些优化的一些算法，那这些算法的话，我们可以基于不同的一些数据规模去进行一个选择。那使用了不同的一个检索算法呢，我们在检索这一块啊，效率我们也会得到一定的一个提升啊，这就是我们整个。啊，VDB这一块的一些检索方面的一些算法，大家在使用的过程中呢，我们也可以去基于我们自己的一个业务场景去选择不同的一个算法，当然这些算法也会可能也会涉及到一些参数方面的一些啊微调，那这个时候呢，大家建议大家可以优先去使用我们这个默认的一些参数，那如果你想把这个效果进行进一步的提升，那这个可能就需要去大概了解一下当前这个算法其中的一些。

小细节，然后再来去调整我们这个算法当中的一些参数，从而提升我们整个算法的一个召回率。好，那到这里之后呢，实际上我们已经召回了这个啊top n的和query相关的一些文本了，对吧，那。接下来其实我们就会遇到一些问题嘛。那召回了这么多一些数据，那我们是不是应该把我们与尽可能相关的内容往前排呢？其次呢，我们刚才也提到一点啊，啊，我们在这个预处理当中会生成很多的一个统一的一个query，我们是不是也要把这个统一的query生成的一个结果进行一个合并。

最后呢？我们在这个召回阶段，实际上是希望只把这个最优质的内容给到我们的这个am，对吧，去减少，减少一些无关数据的一些干扰，那这个时候呢，实际上就是我们要做的事情，就是刚才提到的啊，我们要去做这样的一个。啊排序啊排序。哎，那这个时候可能大家又会有一点疑问啊，那我这个in bed不就是根据它的一个相似度，或者是说文本之间它的一个距离进行一个排序的嘛，那为什么我这里还要再重新去做这样的一个排序呢？啊，这里大家就需要注意一点啊，首先对于我们的这个in bedding模型来说，它实际上啊，它是存在于一定的一个局限性的，它没有办法完全保证说我们的这个文本就是基于这样的一个语义的相似度。完全排好序的。因为其实对于白领模型来说，它。

可以简单的理解为它类似于它并不是一个完全的一个监督学习的一个模型，对吧，它可能也会有一些所谓的一些bad case,所以我们没有办法完全依赖说它的相似性就一定能完全反映出我们语义的一个相关性啊，所以这个时候呢，我们就希望说，既然如此，我们是不是能训练一个模型，让这个模型专门去做这样的一个排序的一个事情，把我们召回的这个文档语义最相近的放到最前面，最后呢？我们在取这个排完序之后的啊，前K个文档，然后再把这K个文档返回给用户对吧。例如我们这里这个例子啊，用户输入carry，那我们召回了啊50条数据，那经过排序之后呢，我们再把排序前10条数据。最终再返回出来，给到我们的大模型进行一个回答，好，那接下来呢，我们就来详细看一下这个排序这一块啊，到底应该怎么做啊。

好，我们先来看一下上面这个图啊，啊，从上面这个图呢，我们可以得出一个结论啊，当然我们提供给模型的这个上下文越长，那对于模型来说，实际上它的这个压力是越大的，那在于准确率这一块，实际上就是可能会有一定的一个降低。当然了啊，由于目前啊，大模型这一块发展的也比较快啊，可能嗯，大家对这个大模型的这个支持的一个上下文长度也越来越长了，那对于比较典型的这种大海捞针的一个任务上面来说，效果也是越来越好了，但实际上呢啊，如果你的文本提供的特别长，肯定还是会有造成一定的这个负面影响，所以我们还是要尽可能保证啊，提供给模型的内容，它是一个高质量的，并且它是一个有效的能解决用户问题的这样的一个知识，OK.那既然如此，好，那我们就来去做这样的一个排序模型啊，排序模型，那我们的排序实际上关键是想基于这样语义的一个思去排比，就说语义越相关，那我希望越排在前面，那既然它是一个排序的一个模型，那我们就应该考虑应该基于这样learning to的一个思想去做我们的这样的一个排序模型，那说到这个learning to,实际上目前主要就是三类方法嘛，对吧？

咱们第一类方法，也就是咱们的这个point wise,那这一类的方法呢，大家就可以简单的理解为啊，我把我输入用户的这个query，然后输入这样的一个相关的一个文档，我就判断一下我们的这个文档和我们输入的这个query它是不是相关的，就是非常简单的，那我们再来看一下这个PI啊PI的思路就是说啊，我输入了。两篇文档，还有用户的这个query，我需要判断一下啊，我的这个A文档和B文档，到底是A文档和query的相关性。更高呢，还是说我们的第一文档和那个query的相关性更高，它实际上就会有一个两个文档，它经中间做了这样的一个对比啊，这是一个的一个思路，最后呢，就是咱们的这个list啊。

那前面的一些实际上更多的是基于啊，单条数据，或者说两条数据去做一个对比，那它的一个思就不一样了，它的一个想法就是说我希望把我要排序的数据直接去进行一个排序。啊，我们举个例子啊，假设我们这里这个图一共有C3条这样的一个数据，对吧，那我们可以把这ABC这三条数据去做一个排序，那排完序之后实际上就有6种情况对吧。也就是ABCACB。也就是一直到我们的CBA啊，一共有6种情况，那我们只需要判断一下哪种情况它是在第一个位置，哪种情况在第二个位置，就说白了啊，我们需要判断一下6种情况，哪种情况的一个效果最好，也就是选出我们效果最好的那种排序方式。

说白了就是简单的去做一个六分类啊，分类这是一种比较简单的啊，它的一个思路，但是大家可以考虑一个问题啊。这样的一个方法，它实际上也是有它的一个弊端的啊，比如我们现在。要排序的文本有N条，那它的排序结果实际上就是N的接重中，那这个时候大家可以看一下它实验，实验复杂度是非常高的，对吧？那我们要排序的越多，那你这个实验成本就越高，所以。对于list这一块呢，我们就考虑采用了这样的一个NDCG这样的一个优化方式，说白了就是我们对我们的function啊去做了更好的一个优化，那NDCG它其实呢，就是排序当中的一个。啊，指标我们可以简单看一下。这个NDCG，它的一个计算公式呢，就是咱们的这个啊第一部分了。

这个图当中的这个第一部分，但是对于NDCG这个指标来说，因为它其中包含了一个实函数，导致我们的这个NDCG它实际上是没有办法去求导的。那你没有办法求导，也就是咱们P都传不过来，我们没有办法做BP，所以呢，我们希望做一个事情啊，就是把我们的这个试函数去进行一个近似，把它采用这样的一个啊logistic function去做一个近似，那近似完之后呢，当我们这个logistic function当中的这个超参数，也就是咱们的阿尔法取100的时候，可以看到它的一个最终的一个输出结果和我们这个式函数的一个输出结果是非常接近的，那这个时候呢，我们就可以以这样的一个近似的方式来得到我们的这个loss function,并且它是一个。啊，可导的一个结果啊。最后呢，我们就基于这样的一个loss function来训练我们的一个啊的一个排序模型，最后我们也可以对比一下啊。

啊，这里呢，我们对在我们自己的这个垂类领域啊，去对比了目前这个市面上BG开源的一个排序模型，和我们自己的这个排序模型的一个效果，那对于这个市面上开源的这些排序模型来说呢，更多它实际上是基于这样的一个point的一个思来做的，但是对于我们的这种排序模型来说，因为基于的是list这个思，List它本身就是朝着这个排序去做的，所以最终呢，会得到一个相对来说会更优质的这样的一个结果啊。到这里为止呢，我们就把我们的这个啊。检索这一块啊，就全部讲完了，OK,那在下一个章节呢，我们就会为大家再介绍一下，当我们检索到相关的内容之后呢，我们是不是要把我们的这个相关的内容提跟提供给我们的一个模型，要我们的模型来输出啊，正确的一个答案对吧？好，那这就是我们下节课要给大家带来的一个内容。

好，这节课就到这里了。