当前位置：首页 > news >正文

基于 Faiss 的百万级人脸档案向量检索系统

news 2026/5/16 19:25:41

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

一、背景

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

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

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

本文将以一个实际生产环境的人脸搜索系统为例，深入剖析基于Faiss + MongoDB + Tornado的架构实现，并以此引申不同向量数据库的选型对比。该系统已上线运行，提供人脸匹配、库管理、轨迹检索、归档聚类等完整功能。你可以在 http://faceqianmian.top/static/index.html 体验到实际效果。

二、系统架构概览

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

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

核心设计思想：

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

三、核心技术细节

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

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

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

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

cos_sim = A · B

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

L2² = 2 - 2 * cos_sim

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

D=1-D/2

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

3.2 分数映射函数

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

defget_score(x):ifx<=0.5:score=120*xelifx>=0.616:score=26.041666*x+73.95833else:score=258.62069*x-69.31034returnmax(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…），检索时遍历所有分片并合并结果。这种方式避免了单个索引过大导致的构建耗时和内存分配压力，天然支持水平扩展（可扩展到多机）。

ifindex_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+=1shard_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 加载该时间戳之后新增的数据，增量插入到索引中。

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

faiss.write_index(index_dic[group_id],'index_data/'+str(now)+'/'+group_id)# ...dirs=os.listdir('index_data')dir=dirs[-1]forindex_fileinos.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 做全文检索的团队，能统一技术栈。

选型建议：