RAG全系列之《向量化与向量召回》

Wait 5 sec.

在知识检索领域,向量化与重排序正成为解决海量数据精准检索的关键技术组合。本文深入剖析向量化与重排序技术,从文档拆分的多种优化方法,到向量化模型选择、相似度计算的技巧,为你提供一套全面的知识检索指南,供大家参考。向量化与 重排序(rerank)放到一起, 因为他们两个搭配起来,解决知识检索的问题,两个是搭配着使用的,今天先介绍一下向量检索。向量召回的核心:在海量数据中,检索与跟查询内容相近的内容。一般称为内容召回。例如一次性召回 50 条内容。rerank的核心:基于召回的内容,再做更加精准的排序。例如将上面 50 条内容,做一次更加精准重排序,获取到 top10 内容;向量化听着这个名字感觉很复杂,其实思想很简单,简单理解:就是通过一种向量化技术,将内容映射到空间上,在空间中距离越近就代表含义越相近。解决系统不理解语义的问题。实际会更复杂一点,下面给大家详细介绍一下流程。文档拆分(可选)我们提供给 RAG 的内容,如果是长文档的话,就是在知识检索的时候,能够检索到具体的相关的部分。那么这个时候,就需要我们先把文档拆分为一个个小块(chunk),然后针对每个小块进行后续处理。如何将块拆分得合理,也是个很头疼的问题。比如公司的规章制度的手册,厚厚的一本。如果让 AI 自动切的时候,他可能会把前后有关联关系的两个段落甚至一个句子,拆分到两个片段里面了。 后面检索到其中一个片段,你人单看这一个片段,压根看不懂是什么意思,大模型生成那就是一塌糊涂了。给大家介绍几个目前比较通用的优化的切分方法:人工拆分为小块我目前采取的就是这个方案,因为我们是企业级的 RAG,对于准确性要求更高,所以人工拆分的是最准确的。但是这里也有前提,首先有人力配合做这个事情(人工重新其实是个非常痛苦的事情),因为要保证每个知识点的知识都要是完备的,不能有遗失。然后知识变更不要太频繁,不然人工刚维护完,然后多段时间又要更新,还必须等人工拆分完才能上线,效率就非常低。但是针对企业各种规章制度、平台操作手册各种,还是建议大家上人工,先保障效果。剩下的几个方法,我只是有了解,还没有 实战过,如果介绍有偏差,欢迎大家指出。添加 buffer在文档切分的时候,把切割点前后的内容,也冗余到这个文档中,这样就可以避免句子等被切断,导致语义不全的问题。但是这种 buffer 一般都不会设置的很大,主要解决句子等被切断的问题。前后段落语义有关联性的,这种方案就不是很好了。多维度切分因为切一次,可能导致一个句子被切断。那么就设置不同的切分长度,这样一个内容就会存在多个片段中,后续检索的时候,大概率能够检索到对应的相对完整的内容。但是这种切割之后,会导致重复内容都被检索出来,候选内容变得更多,后续的重排序压力就比较大了。先切大块,再切小块先切分为大块(例如按照章节拆分),先大块级别做向量检索,快速找到相关章节。找到对应的章节后,再这个章节内切分好的小块找内容(可以添加 buffer 方式拆分为小块)。这个适用于大块与大块内容的确不同的情况,例如公司的规章制度,有明确的章节的概念。如果知识本身就是稀碎,每个知识点都是单独的,那么拆分大块就没有意义了。向量化就是将拆分好的 知识点,转换为空间坐标。这里其实就有模型的事情,就是大家长听说的embedding模型。不同的embedding转换出来的空间向量差异是非常大的。这里需要特别注意的就是需要基于语言选择,我们是中文,就建议选择针对中文优化过的embedding模型。我自己试过火山的embedding模型、OpenAI 的text-embedding-3-large模型,针对中文效果都还可以。检索准备工作都完成了,这个时候来了一个查询之后,我们把需要查询的内容也进行向量化,用于后续检索。相似度计算一般我们计算的都是余弦相似度,大家不理解也不太重要,知道怎么用就行,毕竟这里大家也改不了啥。但是这里就有个坑了,就是稀疏与稠密的关系了,这个是向量检索效果最复杂的地方。给大家举个例子,需要检索美食攻略,标题【深圳福田区有哪些日式料理,排队人不多的】。因为向量化是按照整句话转化为了空间坐标,他就缺少了关键信息例如福田区、日式。 做向量检索的时候,【深圳福田韩国料理人过多】、【北京日式料理,人不多又好吃】这样的稠密矩阵相似度就很高,但是显然他不是我们要的内容。比较简单的方式,是提升稀疏名词的权重,例如日式、福田区,在整个知识库中出现是比较低频的,能否适当在用户检索这些内容的时候,给这些名词加上更高的权重? 这个就是稀疏矩阵的意义。我们可以综合稀疏与稠密矩阵的检索结果,然后综合权衡,获得最终排序的结果。进阶的知识检索刚才那个例子,用了稀疏+稠密之后,其实检索效果也不太好,对于高准确率场景的话,还是不够用的。给大家介绍两个热门的的进阶做法标量过滤我们提前给知识点打标,然后基于用户的查询也抽取标签,这样就可以更加准确了。例如对于知识点打标上所处位置、菜系两个标签。用户查询【深圳福田区有哪些日式料理,排队人不多的】的时候,系统自动识别【深圳】、【日式料理】两个标签,然后基于这两个标签过滤知识,针对过滤后的知识,进行向量检索。我目前用的这个方法,针对这种特点标签的,效果会很好。但是这个会比较考验知识点打标准确性、用户提问抽取标签的能力,这个不同行业不同,大家自己探索下自己的玩法。知识图谱知识图谱解决的各个实体有关系的,简单举个例子。三国演义中,刘备、关羽、张飞这三个人的关系是什么,然后用户问刘备的三弟用的是什么武器,如果只是做内容检索,很难检索到这个类似的表达。我们建立刘备、关羽、张飞就作为三个实体(角色),然后把他们兄弟关系作为图与图之间关系维护起来。才能解决这个问题。但是人工建立图谱是一个非常非常非常大的工作量,现在基本都是让 AI 大模型自动抽取实体与关系,但是各家抽取的准确性都还没有办法实际使用。我自己用了阿里的 KAG、light RAG,都无法直接应用到生成环境,所以需要再优化一下,才能做到开箱即用。当前用起来,都需要自己再进行个性化的调优。本文由 @寻走 原创发布于人人都是产品经理。未经作者许可,禁止转载题图来自Unsplash,基于CC0协议