向量数据库选型

上文聊完Embedding模型，将文本内容转换为了向量，并了解两个向量之间，如何判断相似度，是正相关还是负相关。
但是我们的chunk如果有几百万个，我们这时候来一个语句，通过embedding生成向量后，怎么跟几百万个向量匹配呢？

正常数据库该怎么做

假设我们使用正常的mysql，拿一个text字段去存储chunk对应的向量。

那我们进行匹配的时候，因为不是精确匹配，也无法模糊匹配，不可能在数据库层进行匹配出来的，所以我们只能将向量的数据在数据库中查询出来，然后在内存中进行匹配，最简单粗暴的办法。

但是得考虑到数据量太大，每次读取数据都会走磁盘io的操作，以及未来并发一大，很容易就会将数据库打崩。

所以我们如果要在生产环境上使用的话尽量不用这种方式。

核心索引算法

在具体介绍向量数据库前，先介绍下向量索引的核心算法。因为我们在之前的文章里也讲过，可以使用余弦相似度的方式计算两个向量之间的相似度。但是我们应该如何从百万个向量里找到最匹配我们目标向量的向量呢，大概有以下几种方式。

暴力法

最简单粗暴的办法，就是一个个匹配，弄个循环，每个都去算一下和目标向量的匹配度，然后统计所有匹配度里最高的n个向量。
优点是极致的简单，代码量小
缺点是效率堪忧，需要对几百万个向量进行余弦相似度的计算。

那有没有可以不用全局搜，而是只比较其中一部分向量，就找到大概率最相似的向量呢？有的，这就是 ANN（Approximate Nearest Neighbor，近似最近邻搜索）的核心思想。比如以下几种索引算法。

IVF（倒排文件索引）

INV的宗旨是先分区再搜索。

怎么个理解呢，可以想象把所有的向量都平摊在一个数学坐标内，也就是一张图里，通常先使用K-Means等算法将所有向量聚类成多个“单元”(cell)，搜索时先找到距离目标向量最近的几个中心点（即最可能的几个簇），然后只在这些簇内进行精确计算。最后得到最高匹配度的top-n个向量。

优点是一次可以过滤掉90%的向量，只处理最终10%的向量

缺点是数据如果分布不均匀，效果可能一般，以及还是需要处理剩下的10%

HNSW（分层可导航小世界图）

这是最主流的索引算法，它的实现有点像redis的zset，跳表的形式，跳表的特色就是有多层节点，下层节点最多，上层节点最少，然后从上到下一层一层寻找最匹配的节点，直到找到符合目标的节点返回。

HNSW也是差不多的原理，可以看作是多层图，最上层拥有最少的向量，第二层向量变多，最底层有所有的向量，当目标向量进行匹配时，先在第一层匹配最相似的向量，匹配后从第二层找到周围最匹配的向量，直到最后一层，找到最相似的向量为止。
相对于其他的索引算法，这种算法的效率已经算做很高了。

优点就是搜索的效率最高。
缺点就是多层的向量很占用内存。

HNSW通常适用于百万到千万级的数据量，这主要受限于内存容量。对于亿级甚至更大规模的数据，需要将索引存储在磁盘上以容纳数据，此时可采用像DiskANN这样的算法，但通常会以牺牲部分搜索速度为代价

主流向量数据库

有些专门为向量检索而设计的数据库，比如Milvus、Pinecone、Chroma等。

Milvus适用的向量数据量在百万到十亿级别之间，支持多种索引算法，比如HNSW、DISKANN等，并且是开源的，支持java的技术栈，提供官方的Java SDK、丰富的Java示例。

其中索引算法的选择可以按上述说的，根据数据量来决定具体适用什么索引算法。