你知道RAG？它是如何高效检索向量的？

在历时一个半月的笔试面试后，我又回来分享知识了，后续应该只能一周一更了，要去公司当牛马了，不过好在结果顺利，收获了三个offer，已经打算去鹅厂实习了

好了，言归正传，我们今天来介绍一下RAG

RAG检索增强生成

RAG（Retrieval-Augmented Generation，检索增强生成），其核心模块在于检索与生成，其实其本质还是一个知识库系统，只不过是通过向量聚合手段，提升了检索的高效与正确性：

RAG工作大致流程

RAG通过将收集的多源数据分割为文本块，使用嵌入模型将文本转化为多维向量，用户在进行查询时，实际输入是按照向量来组织，通过向量之间的相似度来查找匹配度最高的知识片段

而这里面要解决的核心问题是，如何从庞大的向量数据库中找到目标文本对应相似向量，这里不仅仅要考虑到搜索速度，还需要考虑内存占用开销：

向量数据库搜索算法

余弦相似度

思想很简单，就是通过依次遍历计算查找文本向量与当前向量的余弦相似度，最大的对应向量即为目标向量：

余弦相似度算法

优点：查询向量肯定为最匹配向量

缺点：需要依次与每个向量比较，时间复杂度太高

K-means聚类算法

按照数据库向量的某种特征，对彼此相近的向量组进行划分，每次要查询某个相似向量时，先查找与之最匹配的一个或者几个聚类中心点，之后查找对应聚类组范围的向量即可：

聚类中心点是指一个聚类组中，与所有节点距离范围最均衡的点

K-meas聚类算法

好处：查询时只需要查询对应聚类组的向量即可

坏处：需要维护聚类中心点与聚类组范围里每个向量的映射表，在多维空间下，映射表内存占用极高

PQ压缩聚类检索算法

针对于聚类算法带来的映射表开销，PQ检索算法优化了这一点，它解决的核心思想在于：

将高维向量分解为低维向量，对每组低维向量进行聚类分析，提炼出每个低维向量的聚类中心点，这样一个高维向量可以由多个聚类中心点所表示

其实这种思想可以类比为，如果我要存储256位数字的值，需要2^256，而如果将256位拆分为8部分，那么总共需要8*2^8，实际上就是将原本的乘法转化为了加法

PQ向量压缩聚类分析手段

好处：通过将高维向量转为低维存储，节省了内存存储空间

坏处：需要额外维护映射表开销

其实我们平时熟知的图片马赛克也是类似的处理手段，每个图片都是由三维像素点RGB组成的，而可以对图片的不同区域进行划分，一个区域只用一个像素点代理，因此就做到了最后的图片内存压缩但原型还在的样子

HNSW压缩算法

在介绍HNSW之前，先来介绍一下NSW算法，在Facebook推出的一项研究中表明，如果你要与一个陌生人联系，通过平均3.57个人的介绍彼此就能互相沟通，而NSW就是借鉴了这种思想

其实庞大数据量对应的文本在数据库中，就是一个个的点，而查询就是通过点之间的路径实现高效查询，因此上面理论的延伸也就启发了我们，可以通过合适的建图策略来提升我们的搜索策略，而NSW就是这种思想

建图流程：依次将所有点放入图中连接边，每次连接距离当前节点最近三个节点的边，以此类推，这样不仅能够保存点与点之间的最近向量，同时也保存了与远处点的直接连接：

NSW建图过程

但是在大数据量情况下，即使查询的某个点与远处某个点已经建立了连接，但可能还是要途径很多边才能建立连接，因此查询效率会大打折扣，而HNSW的诞生就是为了解决这一点：

HNSW分层图结构

如图，HNSW通过对所有点建立分层图机制，越上层图建立的节点数越小，这样上层搜索就能过滤掉很大一部分节点范围，从而大大加快了搜索效率

好处：搜索效率大大加快，类似于Redis的跳表机制(类比迁移)

坏处：由于要存储多个分层图数据，因此维护分层图带来的内存开销比较大

以上介绍了向量数据库检索的几个方法，在大数据量的时代下，通过向量数据库进行相似度查询会比以前的关系型数据库准确匹配更高效，而合适的检索算法也能大大加快查询速率，减少内存开销

附上相关论文，感兴趣的小伙伴可以钻研一下：

https://arxiv.org/pdf/2412.01940

https://www.sciencedirect.com/science/article/pii/S0925231224003035?dgcid=rss_sd_all&#sec2