✏检索技术

doc/数据技术/检索技术.md

@@ -305,3 +305,53 @@ RAG 将传统的语言生成模型与大规模的外部知识库相结合，使
 1. 检索：对于给定的输入（问题），模型首先使用检索系统从大型文档集合中查找相关的文档或段落。这个检索系统通常基于密集向量搜索，例如 ChromaDB、Faiss 这样的向量数据库
 2. 上下文编码：找到相关的文档或段落后，模型将它们与原始输入（问题）一起编码
 3. 生成：使用编码的上下文信息，模型生成输出（答案）。这通常当然是通过大模型完成的
+
+## 基于 Faiss 实现实时人像追踪
+
+```mermaid
+sequenceDiagram
+   前端摄像头 ->> 网关: 人脸数据
+   网关 ->> Kafka: （人脸数据，位置，时间，身份）
+   Kafka ->> FaceConsumer: 
+   FaceConsumer -->> FaceConsumer: 将人脸转为向量
+   FaceConsumer ->> Storage: 存储向量，<br>生成唯一ID
+   FaceConsumer ->> Storage: 存储唯一ID与位置、时间、身份
+   FaceService ->> Storage: 获取向量
+   FaceService -->> FaceService: Faiss 构建索引
+   使用者 -->> FaceService: 提供一个人脸向量
+   FaceService ->> FaceService: 返回最相关的k个向量ID
+   FaceService ->> FaceService: 根据K个向量ID构建行踪轨迹
+```
+
+### 索引类型与空间占用
+
+使用 Faiss 的 IndexFlatL2，这个方法是精确搜索。128 维的人脸向量，一千万的索引，约占 5G 内存空间。
+
+### 数据量
+
+某二线城市，一个区县约有 3 万台人像识别设备，一天越能产生一千万的人像数据，整座城市一天算下来越可以产生 7 千万到 1.2 亿的人像数据。
+
+大约 50 个进程就能支撑起一座城市 7 天的实时人像数据检索需求。
+
+三台 128G 内存的机器，就能支撑起上面这个需求。
+
+### 性能与问题
+
+效果：k = 500 时，单进程一秒内返回结果
+
+遇到的一些问题：
+
+1. 大量人脸小文件造成 inode 耗尽，导致无法写入文件。只能扩容磁盘或重写格式化，增加 inode 数量
+2. 对于历史数据，单进程人脸转向量时，速度较慢，启用多进程
+
+### 水平扩展
+
+```mermaid
+stateDiagram-v2
+   master --> process1(1,10000000)
+   master --> process2(10000001,20000000)
+   master --> process3(20000001,30000000)
+   master --> ...
+```
+
+通过不同的进程各负责一部分的向量处理以及识别，再由 master 聚合结果。实现水平扩展