大素材库
在数万张照片与数小时视频上使用 SnapByFace：增量重索引、FAISS 向量检索、暂停/继续/取消，以及意外退出后的恢复。
SnapByFace 是为整个归档而设计的，不是只给你挑几个示例文件夹。这一页讲的是素材库变大之后会发生什么，以及如何让之后的每一次运行都很便宜。
增量处理
在分析一个文件之前，SnapByFace 会先确认它是不是真的变了。当下面几项与索引里存的一致时，该文件会被跳过：
- 文件大小 —— 未变。
- 修改时间 —— 未变。
- SHA-256 摘要 —— 未变。
- 索引版本 —— 已存的特征是由当前版本的应用算出来的。
只要其中任意一项不同，这个文件就重新分析；其余全部跳过。实际效果是：
- 对没动过的素材库跑第二遍，耗时只有第一遍的一小部分。
- 重新编码或编辑某个文件，只会重分析这一个文件。
- 把某个目录复制到新位置会触发重分析，因为索引里存的状态属于原来那条文件记录。
向量检索
特征检索使用 FAISS。如果你的安装里没有 FAISS，SnapByFace 会回退到 NumPy 暴力检索。
::::note NumPy 回退返回的是同样的匹配结果 —— 质量不打折，只是更慢，而且库越大差距越明显。参见 故障排查。 ::::
掌控长时间任务
- 暂停 —— 不再占用 CPU，进度不丢。
- 继续 —— 从暂停处往下做。
- 取消 —— 停止；已经完成的文件保留索引。
- 关掉再打开 —— 启动时 SnapByFace 会询问是否继续未完成的任务，所以意外退出或重启都不会丢掉几个小时的工作。
实用建议
- 先从一个目录开始。 先给一个有代表性的目录建索引，确认匹配与阈值合适，再加其余部分。
- 大任务放到夜里跑。 数万张图片或数小时视频的第一遍，就是几个小时的 CPU 活。
- 把素材放在高速本地磁盘上。 瓶颈通常是网络共享或 USB 机械盘，而不是人脸模型。
- 跑的过程中别移动或编辑素材。 这些改动本来也会让文件排进重分析队列。
- 第一遍用更粗的视频抽帧间隔 —— 大归档先按 2–5 秒扫一遍，再对重要的目录收紧。
- 宁可暂停也别强退。 两种都留了检查点，但暂停更干净。
存储与内存
- SQLite 索引位于
~/.snapbyface/snapbyface.db。它随检出的人脸数与抽帧数增长，而不是随素材的字节体积增长。 - 人脸模型随应用分发，所以索引里从不存模型。
- 内存占用随检索时持有的向量数增长；素材库很大时，让 FAISS 生效会明显受益。
从零重建索引
如果你需要一次干净重建 —— 比如改了整个素材库的视频抽帧间隔 —— 关掉 SnapByFace，删掉 ~/.snapbyface/snapbyface.db，下次运行会重建。激活状态在 license.dat 里，所以重建索引不会让你的授权失效。
::::caution 删除数据库会清掉全部匹配结果与全部已提取的人脸数据。SnapByFace 从未修改过你的原始照片和视频 —— 被删的只是它自己的索引。 ::::
大概要多久
- 图片： 现代笔记本上每小时数千张，Apple Silicon 更快。
- 视频： 主要取决于抽帧间隔 —— 1 秒抽帧意味着每小时素材约 3,600 次检测。
- 重跑： 只处理变化的文件，所以是几分钟而不是几小时。