摘要：在下文中，我将尝试经过Faiss源码中各类类结构的设计来梳理Faiss中的各类概念以及它们之间的关系。
本文分享自华为云社区《Faiss源码剖析（一）:类结构分析》，原文做者：HW007。算法
Faiss是由Facebook AI Research研发的为稠密向量提供高效类似度搜索和聚类的框架。经过其官方给出的新手指南，咱们能够快速地体验Faiss的基本功能。可是，相信大多数人看完官方的新手指南后，对Faiss不少的概念仍是有点模糊、没法清晰的明确这些概念之间的边界。好比说在Faiss中，Quantizer是个什么概念、其与Index之间的联系是什么；还有各类Index之间的关系又是什么等等。为此，在下文中，我将尝试经过Faiss源码中各类类结构的设计来梳理Faiss中的各类概念以及它们之间的关系。数据库
首先奉上Faiss源码的类图全家福以下，详细的EA类图文件见附件：数组
图一：Faiss的类图全家福框架
首先，咱们来看一下Faiss最主要的功能：类似度搜索。以下图所示，以图片搜索为例，所谓类似度搜索，即是在给定的一堆图片（下图中左上角的图集）中，寻找出我指定的目标（下图中左下角的巴士图片）最像的K张图片，也简称为KNN（K近邻）问题。函数
接下来咱们看一下为了解决KNN问题，在工程上咱们至少须要作哪些事情。显然，有两件事是必需要作的，第一，咱们要把上面例子中的那个图库存储起来；第二，当用户指定一种图片后，咱们须要知道怎么从存储的图库中找到最近类似的K张图片。由此，咱们肯定了Faiss在其应用场景中至少应该具有的两个功能：添加功能和搜索功能。工具
对于熟悉数据库的同窗来讲，应该能在这里嗅到点“CRUD”的味道。的确，当咱们对“图集”有添加存储这样的动做后，修改和删除等功能也便接踵而来了。由此Faiss本质上就是一个向量数据库。对于数据库来讲，时空优化是两个永恒的主题，即在存储上如何以更少的空间来存储更多的信息，在搜索上如何以更快的速度来搜索出更准确的信息。如何减小搜索所需的时间？在数据库中很最多见的操做即是加各类索引，把各类加速搜索算法的功能或空间换时间的策略都封装成各类各样的索引，以知足各类不一样的引用场景。优化
由此，咱们便不难理解为何Faiss中为何会有那么多的Index了，由于Index这个概念自己就与加速搜索是绑在一块儿的。由此也能够看出在Faiss中，如何又快又准地找到类似向量是第一要务。下图中给出的是Faiss中最重要的两个基类：Index和IndexBinary。编码
在上图中，用白色的箭头标出了这两个基类中最重要的三个函数，其中add()和search() 函数便对应了我上文中所提到的Faiss至少应该实现的两个基本功能：存储和搜索。在此顺带提一下，与传统的数据库相比，Faiss的Index还包含了数据存储的功能，若是你一开始就从字面上按照传统数据库中索引的概念来理解地话，就会感受有点怪怪的。接下来，咱们重点聊聊Index中的train()函数，咱们都知道天上是不会白白掉馅饼的，对于Faiss来讲，无论其为了减小存储空间仍是加速搜索，都须要提早作好一些准备工做，这即是train()函数发挥做用的时候了。url
以减小存储为例子，咱们都知道在图片处理中经过PCA能够将图片从高维空间（p维）转换到低维空间（q维, 其中 p > q ），其具体操做即是是将高维空间中的图片向量（n*p）乘以一个转换矩阵（p*q），获得一个低维空间中的向量（n*q）。为了使得在整个降维的过程当中信息丢失最少，咱们须要对待转换图片进行分析计算获得相应的转换矩阵（p*q）。也就是说这个降维中乘以的转换矩阵是与待转换图片息息相关的。.net
回到咱们的Faiss中来，假设我指望使用PCA预处理来减小Index中的存储空间，那在整个处理流程中，除了输入搜索图库外，我必须多输入一个转换矩阵，可是这个转换矩阵是与图库息息相关的，是能够由图库数据计算出来的。若是把这个转换矩阵当作一个参数的话，咱们能够发现，在Faiss的一些预处理中，咱们会引入一些参数，这些参数又没法一开始由人工来指定，只能经过喂样原本训练出来，因此Index中须要有这样的一个train() 函数来为这种参数的训练提供输入训练样本的接口。由此，咱们也能够发现，这些喂给train()函数的样本数据最好与以后要添加存储的图集以及搜索目标一致比较好，好比说，你先给Index喂一个猪脸数据集训练出PCA中的转换矩阵，再给这个Index添加人脸数据集，最后再在这个索引上作人脸识别，这样确定比不上一开始就喂人脸数据集获得PCA转换矩阵的效果好。
由上，咱们已经能够从train()、add()和search()三大函数大概地了解到Faiss中的Index是个什么东西了，接下来咱们看一下Faiss中有哪些不一样的Index。从图一中的类图中能够看到，在Faiss中，大多数类基本都继承或使用了Index接口，他们要么对Index接口中定义的train、add和search函数进行了本身个性化的实现（如图一中被淡橙色标注的类），要么就是对已经实现的三大函数的类进行包装，提供一些三大函数以外的流程上的加工处理（如图一中被淡蓝色标注的类）。
从图一中咱们能够看到这些被淡蓝色标注的偏包装的Index子类，他们与Index基类之间既有“is a”又有“hold a”关系，在类结构上出现这种关系的时候，设计者要么是在设计一个树或链表的节点，要么是在设计一个包装类。显然在Faiss中更偏向于后者。一方面，淡蓝色的Index子类借助其所“hold”的Index来提供基本的train、add和search功能，使其自身符合Index接口的定义标准，成为一种Index，为以后的层层嵌套包装提供支持。另外一方面，他又对其所“hold”的Index类进行了一些通用的功能扩展。以下图的IndexPreTransform类所示，Faiss将对待存储图集的预处理，如归一化、PCA降维等功能抽象成一个VectorTransform接口，让IndexPreTransform使用它来为其所“hold”的Index添加预处理功能，这种预处理功能是与其所“hold”的是什么Index没有任何关系，所以我更偏向于将这种功能归结为Index以外的流程上的包装功能。如IndexPreTransform类提供了数据预处理功能、IndexIDMap类提供了自定义ID功能、IndexShards类为Index的并行计算提供了相关的支持等。
接下来咱们来看一下图一中被淡橙色标注的Index子类，如IndexLSH、IndexPQ、IndexIVFPQ等，从名字中咱们能够大概了解到这些类都是基于一些不一样的算法实现的不一样索引，他们的train、add和search方法各有差别。但在总体上仍是能找到一些其余结构上的共性。在上文中，咱们知道Index具备存储的功能，这些被淡橙色标注的Index子类在数据存储方式上基本能够划分为两大类，一类是统一存到一个容器中，如在IndexLSH、IndexPQ等中咱们均可以看到一个命名为codes的vector容器。另外一类是分桶储存到多个容器中，这主要为索引后续的非精确分桶局部搜索提供支持，为此，Faiss特意抽象出InvertedLists接口，须要支持分桶局部搜索的Index子类均会有hold一个实现了InvertedLists接口（淡紫色标注）的实例来存储其数据。以下图所示，Faiss为InvertedLists接口提供了数组、链表和磁盘文件等三种不一样的实现。
在图一中还有两个被标记为淡绿色的类ProductQuantizer和ScalarQuantizer值得你们关注下，在结构上，这两个类均没有派生的子类，而且全部其余的类与他们的关系均为“hold a”关系，很纯粹的工具类。从其命名中的Quantizer（量化器）后缀可知，这两个工具类的做用是将“连续或稠密”的数据进行“离散或稀疏化”，简单来讲就是进行聚类的操做，就像咱们把18岁如下的称为少年，18~50岁的称为中年同样，咱们把具体年龄量化成年龄段的过程就是一个聚类的过程。从图一中还能够看到，带有Quantizer后缀的类还有四个：MultiIndexQuantizer、MultiIndexQuantizer二、IndexScalarQuantizer和Level1Quantizer。其中前三个均是经过对ProductQuantizer或ScalarQuantizer的包装来实现Quantizer的功能，没什么稀奇的地方，但最后一个Level1Quantizer类居然是包装了两个Index类，并且其中一个Index类的属性名仍是quantizer，以下图所示。
难道Index也是一种Quantizer？的确，对于Index来讲，咱们更熟悉的是其将数据集存储起来，再寻找某个数据在该数据集中的K个最近邻点的功能。但若是Index中存储的是数据分类后各个类的中心点呢，那么对于某个数据，咱们即可以在该Index上经过KNN来求得其K（此时K=1）个最近邻点，这些求出来的中心点所表明的类即是该数据在聚类中该归属的类。由此咱们能够看到Index是可用来聚类，将数据量化成类的中心点的。所以，Index能够被包装成一个Quantizer也便不足为奇了。其实Index的这种聚类功能在Faiss的设计中是很常见的，除了上面所说的用来作Quantizer外，还能够用来辅助实现K-means算法，这也是为何Level1Quantizer类中除quantizer外还存在一个名为clustering_index的Index类型属性的缘由。经过上面的分析，咱们还能够知道，在Faiss的Quantizer类中，或明或暗都应该有个地方来存储用来辅助量化的“centroids”，即类中心点，它们在大多数场景中都是通过数据训练出来的（如对数据进行K-means聚类），在少数场景中也能够直接人为设定。
让咱们最后来关注下IndexIVF类（上图中被圈出来的淡紫色类）。也许在上文介绍淡紫色的InvertedLists类簇时，有人会有疑问，InvertedLists类及其派生子类在Faiss中主要为Index提供非精确的分桶局部搜索功能，这种功能与Index的种类毫无关系，按上文对Index派生的子类的分类标准来看，IndexIVF类应该是一个偏包装的Index子类，应该被标注为淡蓝色才对。的确，如上图所示，虽然IndexIVF类没有直接“hold a”Index类，但其经过继承Level1Quantizer类间接“hold a”Index类，确实也是一个偏包装的Index派生子类。图一的颜色标注只是为了突出拥有IVF功能的Index类，经过颜色来辅助各个功能类簇在视觉上的区分度而已，没必要深究。
经过上文，咱们能够发现，Faiss的整个类结构设计是很是清晰简洁的，其首先将KNN问题的解决过程切分红train、add和search三个步骤并抽象出Index基类。接着从这些基类派生出各类偏功能实现或者偏流程包装的Index子类。此外还为Index提供了两种的存储方式：集中和分桶（IVF）。最后还提供了SQ和PQ两种量化编码工具以及将这些编码工具或其余的Index包装成Quantizer的类。