基于 Faiss 的百万级人脸特征向量检索系统

深度实战：基于 Faiss 的百万级人脸特征向量检索系统

一、背景

在人脸识别应用中，最常见的需求就是1:N 人脸搜索 ------给定一张新的人脸照片，在海量已注册的人脸库中找出最相似的人脸。随着业务规模扩大，人脸库可能达到百万甚至千万级别。传统的遍历比对方式在性能上无法接受，必须引入向量近似最近邻（ANN）检索技术。

目前主流的向量检索方案包括：

Faiss（Facebook AI Similarity Search）：元老级单机向量检索库，性能极致。
Milvus：云原生分布式向量数据库，支持持久化与水平扩展。
Pinecone / Weaviate / Qdrant 等：全托管或开源向量数据库。
Elasticsearch + 向量插件：适合已有 ES 技术栈的团队。

本文将以一个实际生产环境的人脸搜索系统为例，深入剖析基于 Faiss + MongoDB + Tornado 的架构实现，并以此引申不同向量数据库的选型对比。该系统已上线运行，提供人脸匹配、库管理、轨迹检索、归档聚类等完整功能。源码：源码

二、系统架构概览

整体架构采用 Python Tornado 提供 HTTP API，MongoDB 存储人脸特征、人员分组、关系信息，Faiss 作为核心向量索引引擎。其简化架构如下：

markdown 复制代码

客户端请求 → Tornado API → Faiss 内存索引
                         ↘ MongoDB (特征/人员/分组)

核心设计思想：

内存索引加速检索：所有活跃的特征向量加载至 Faiss 内存索引，避免每次检索都访问数据库。
持久化与快速恢复：定期将 Faiss 索引 dump 到磁盘，重启时直接加载最近 dump，再增量补充新增数据。
分组与分片 ：按 group_id 划分独立索引，支持多种库类型（轨迹库、普通档案库、重点人员库等）。
多线程并发 ：通过 ThreadPoolExecutor 将聚类等 CPU 密集任务放到线程池执行，避免阻塞 Tornado 主事件循环。

三、核心技术细节

3.1 特征归一化与相似度转换

人脸特征一般由模型输出 128 维或 512 维浮点数向量。系统将特征存储在 MongoDB 中，入库时进行 L2 归一化：

python 复制代码

features = np.array(features).astype('float32')
features = features / np.linalg.norm(features, axis=1, keepdims=True)

这样每个向量的模长为 1，所有向量落在单位超球面上。此时两个向量 A、B 的余弦相似度为：

css 复制代码

cos_sim = A · B

而欧氏距离（L2）的平方满足：

复制代码

L2² = 2 - 2 * cos_sim

因此 cos_sim = 1 - L2²/2。但在实际使用中，Faiss 返回的 D 是 L2 距离（不是平方），直接做平方会有一定开销。本系统使用了一种高效的近似映射：

python 复制代码

D = 1 - D / 2

虽然这并非严格的余弦相似度，但在阈值筛选及分数映射的线性变换中，依然能够保持单调性，满足业务需要。

3.2 分数映射函数

代码中将相似度映射到 0-100 的置信度分数，采用分段线性映射：

python 复制代码

def get_score(x):
    if x <= 0.5:
        score = 120 * x
    elif x >= 0.616:
        score = 26.041666 * x + 73.95833
    else:
        score = 258.62069 * x - 69.31034
    return max(0, min(100, score))

这样可以在前端展示更符合人类直觉的匹配度，同时方便设置阈值。

3.3 Faiss 索引选型与使用

本项目根据场景使用了多种 Faiss 索引：

Flat + IndexIDMap ：用于精确搜索（轨迹库、重点人员库、自定义库）。Flat 索引暴力搜索，保证 100% 召回率，适合数据量不大且对精度要求极高的场景。
HNSW64 + IndexIDMap：用于近似搜索（普通档案库的快速搜索）。HNSW 是一种基于图的高性能 ANN 算法，检索速度快，内存占用适中，适合百万级规模。
分片索引（Shard） ：对于档案库，当单个 HNSW 索引向量数达到 20,000 时，创建新的分片索引（group_id_shard0, group_id_shard1...），检索时遍历所有分片并合并结果。这种方式避免了单个索引过大导致的构建耗时和内存分配压力，天然支持水平扩展（可扩展到多机）。

python 复制代码

if index_dic[shard_group_id].ntotal < 20000:
    index_dic[shard_group_id].add_with_ids(features, np.array([_id]))
else:
    # 创建新分片
    index = faiss.index_factory(128, "HNSW64", faiss.METRIC_L2)
    index = faiss.IndexIDMap(index)
    archive_index_count += 1
    shard_group_id = group_id + "_shard" + str(archive_index_count)
    index_dic[shard_group_id] = index
    index_dic[shard_group_id].add_with_ids(features, np.array([_id]))

IndexIDMap 是 Faiss 的包装索引，允许我们使用自定义的 ID（比如 MongoDB 文档的 _id），在检索时返回 ID 数组，方便回表查询详细数据。

3.4 索引持久化与恢复

为避免服务重启后全量重建索引，系统实现了定期 dump + 增量恢复机制：

定时任务（每 24 小时）将内存中所有索引通过 faiss.write_index 写入磁盘目录，目录名为时间戳。
重启时加载最近一次 dump 的所有索引文件，并记录当时的时间戳 init_index_time。
后续调用初始化函数，从 MongoDB 加载该时间戳之后新增的数据，增量插入到索引中。

这样既保证了索引的持久化，又大大缩短了冷启动时间。

python 复制代码

faiss.write_index(index_dic[group_id], 'index_data/' + str(now) + '/' + group_id)
# ...
dirs = os.listdir('index_data')
dir = dirs[-1]
for index_file in os.listdir('index_data/' + dir):
    index_dic[index_file] = faiss.read_index('index_data/' + dir + '/' + index_file)

3.5 人脸归档与快速聚类

在人脸轨迹应用中，系统需将大量抓拍人脸进行归档聚类 ，将同一个人的不同抓拍关联起来。本系统采用了 Canopy 聚类 算法的一个变种，基于 Faiss 搜索得到的相似矩阵，通过多级阈值（T1=0.6148651, T2=0.4998698）划分强关联和弱关联，生成核心类簇，再经过类簇过滤（最小/最大成员数、质量分数排序）得到最终归档结果。同时通过矩阵运算批量完成相似度计算和聚类，大幅提升效率。

这部分是典型的"以向量检索为基础，辅以轻量图算法"的实践，避免了复杂的深度学习聚类模型，非常适合在线服务。

四、从 Faiss 到向量数据库的思考

上述系统虽然可靠，但也暴露了 Faiss 作为纯内存库的一些局限：

单机内存限制：所有索引必须放进内存，海量向量需要极大内存。
无原生分布式：需自建分片、多机路由、数据一致性等机制。
数据管理弱：增删改查全靠应用层维护，缺少 SQL-like 接口。
持久化非实时：数据可靠性依赖定期 dump 和 MongoDB，存在窗口丢失风险。

因此，在生产环境中更现代化的方案 是引入向量数据库，例如：

Milvus：提供丰富的索引类型（IVF、HNSW、ANNOY 等），支持数据持久化、分区、多副本，原生分布式架构，社区活跃。可以直接取代"Faiss + MongoDB + 自建分片"的复杂组合。
Pinecone：全托管向量数据库，无需运维，但国内使用受网络限制。
Weaviate / Qdrant：开源向量数据库，带过滤、语义搜索等高级功能。
Elasticsearch 8.x + dense_vector：适合已使用 ES 做全文检索的团队，能统一技术栈。

选型建议：

如果数据量在千万以内，且团队对 Faiss 熟悉，可以沿用 Faiss 方案。
需要分布式、多租户、动态扩缩容，强烈推荐 Milvus，其 Go/Java/Python SDK 成熟，且社区版免费。
希望零运维或小团队快速上线，可以用 Zilliz Cloud（Milvus 托管版）或 Pinecone。

五、实战总结

基于 Faiss 构建人脸搜索服务的关键点：

特征归一化 + L2 距离近似余弦相似度，性能与效果平衡。
按业务类型划分独立索引 ，利用 IndexIDMap 维护映射关系。
对大规模库采用 HNSW 分片索引，避免单索引瓶颈。
结合定时 dump 与增量恢复，实现高可用索引管理。
通过聚类算法实现在线归档，提供端到端人脸应用方案。

源码：源码

如果你正在设计类似的向量检索系统，希望这篇实战总结能给你带来启发。

如有任何技术问题，欢迎在评论区交流。我会持续更新向量数据库相关的技术文章，敬请关注。