向量 (vector)搜索操作，尤其是在大型数据集上的近似最近邻（ANN）搜索，通常受内存容量和带宽的限制。优化性能需要降低计算负担和数据传输量，例如可以采用量化 (quantization)和过滤等技术。有效的内存管理和缓存策略同样是这个优化过程的重要组成部分，直接影响延迟、吞吐量 (throughput)和成本，尤其是在处理跨越千兆字节甚至兆兆字节的索引时。
了解内存占用
管理内存的首要步骤是弄清楚内存消耗在哪里。向量 (vector)搜索系统的总内存占用包括几个部分：
- 原始向量： 存储原始高维向量。这通常在近似搜索后需要精确重新排序时使用，或者在其他操作需要完整精度时使用。内存通常是 N×D×sizeof(float)，其中 N 是向量数量，D 是维度。
- 索引结构： ANN 索引本身的开销。
- HNSW： 存储图连接性（每层每个节点的邻居）以及可能在每个节点上的向量或向量 ID。内存使用量很大程度上取决于
M（每个节点的最大连接数）和 efConstruction 等参数 (parameter)。更高的 M 会带来更好的召回率，但会增加索引大小。
- IVF： 存储粗略质心和将质心映射到向量 ID 或量化 (quantization)编码的倒排列表。内存取决于质心数量（k）和倒排列表的长度。
- PQ/SQ 编码： 如果使用量化，存储压缩编码而非完整向量会显著减少内存。对于 PQ，内存大约是 N×M×sizeof(uint8)（假设 M 个子量化器和每个子量化器 8 位编码）加上码本存储。
- 元数据： 存储用于过滤的相关元数据。这可以是小标志到大文本字段，如果管理不当，会显著影响内存。高效的序列化和选择性加载很重要。
- 运行时缓冲区： 查询期间用于距离计算、维护候选列表（如 HNSW 搜索中的堆）和存储中间结果的内存。
减少这种占用通常需要权衡。例如，积极的量化（如使用更少比特的 PQ）会显著减少内存，但可能降低召回率。同样，减少连接性（HNSW 中的 M）节省内存，但可能影响搜索质量。
大型索引的内存映射
当你精心构建的 ANN 索引过大以至于无法完全放入可用 RAM 时会发生什么？加载整个索引可能不可能或成本过高。这就是内存映射（mmap）成为一种有价值的技术的地方。
mmap 是一个系统调用，它将文件或设备映射到内存中。与使用标准 I/O 操作（read、write）读取文件不同，mmap 允许你直接访问文件内容，就像它在内存中是一个数组一样。操作系统负责按需将页面（连续的内存块）从磁盘加载到 RAM 中，当你的应用程序访问映射区域的特定部分时。它还管理将修改过的页面写回磁盘（尽管许多向量 (vector)索引在构建后是只读的）。
优点：
- 处理大型索引： 允许进程处理远大于可用物理 RAM 的索引。
- 操作系统级别缓存： 使用操作系统页面缓存，这通常经过高度优化。索引中经常访问的部分（如 HNSW 的上层或热门的 IVF 单元）倾向于留在页面缓存中，从而减少磁盘 I/O。
- 简化代码： 访问索引可以感觉像访问内存中的数组，相较于手动文件 I/O 和缓冲，简化了应用程序逻辑。
缺点：
- 性能波动性： 访问索引中当前不在页面缓存中的部分会触发页面错误，需要进行磁盘读取。这会引入显著且有时不可预测的延迟峰值，与完全在 RAM 中的索引相比。性能在很大程度上取决于访问模式和操作系统页面缓存的效率。
- 磁盘 I/O 瓶颈： 整体吞吐量 (throughput)可能受限于底层存储的速度（HDD、SSD 或 NVMe）。
- 更新的复杂性： 修改内存映射索引可能更复杂，尤其是在并发环境中。
mmap 对于磁盘上的 ANN 实现特别有用，在这些实现中，只有部分索引结构（例如，图节点、倒排列表）需要在搜索遍历期间动态加载。像 Faiss 这样的库明确支持某些索引类型的内存映射。
缓存策略
仅依靠通过 mmap 的操作系统页面缓存，实施应用程序级缓存可以进一步优化性能，通过减少冗余计算和 I/O。目标是将经常访问的数据或计算成本高的结果随时在快速内存（RAM）中可用。
缓存什么？
考虑在你的向量 (vector)搜索管道中缓存各种组件：
- 索引节点/结构：
- 在 HNSW 中，缓存上层节点和连接信息非常有效，因为这些节点在几乎每个查询的入口点搜索期间都会被访问。
- 在 IVF 索引中，缓存粗略质心（用于确定要扫描哪些倒排列表）以及可能最常访问的倒排列表可以加快查询速度。
- 向量数据：
- 缓存与经常访问的索引节点相关的完整或量化 (quantization)向量可以节省查找时间，尤其当向量单独存储或需要解压/解码时。
- 距离计算： 虽然通常过于细粒度，但在特定场景下（例如，在复杂的重新排序步骤中）缓存成对距离可能可行。
- 查询结果： 缓存相同或非常相似查询的最终结果可以为热门搜索提供显著的延迟改善。这需要一种机制来定义查询相似性。
- 元数据： 缓存与经常检索的向量 ID 相关的元数据可以加快后过滤或结果丰富。
缓存级别与实施
缓存可以存在于多个级别：
- 内部库缓存： 一些向量 (vector)搜索库（如 Faiss）有内部机制，有时在使用
mmap 时通过操作系统缓存隐式实现，或者为特定结构（例如，倒排列表长度）提供可配置的缓存。
- 应用程序级缓存： 在你的搜索服务应用程序中实施缓存。这能让你获得最大的控制权。常见策略包括：
- 最近最少使用（LRU）： 当缓存满时，它会驱逐最近最少访问的项。简单且通常对时间局部性有效（最近访问的项很可能再次被访问）。
- 最不常用（LFU）： 驱逐最不常用访问的项。更适合具有稳定热度的数据，但需要更多开销来跟踪频率。
- 自适应替换缓存（ARC）： 尝试平衡 LRU 和 LFU 的特性，适应变化的访问模式。
- 像
cachetools 这样的 Python 库提供了这些策略的高效实现。
- 分布式缓存： 在横向扩展架构（第四章）中，使用 Redis 或 Memcached 等外部缓存系统可以提供一个可供多个搜索节点访问的共享缓存。这通常用于缓存查询结果或经常访问的元数据。
典型向量搜索应用程序中的缓存层次。请求检查应用程序缓存，可能利用操作系统页面缓存（尤其在使用 mmap 时），并且在访问底层存储之前可能与分布式缓存进行交互。
缓存失效
缓存的一个重要挑战，尤其对应用程序级缓存而言，是失效问题。如果底层向量 (vector)索引或元数据被更新，对应的缓存条目必须被移除或更新，以避免提供过时数据。
- 生存时间（TTL）： 简单方法，缓存条目在设定时长后过期。如果可以接受一定程度的过时，则适用。
- 写通/写失效： 当索引更新时，立即更新或使缓存中对应的条目失效。要求更新机制与缓存之间更紧密的结合。
- 基于事件： 使用消息系统或回调来通知缓存实例更新。
最佳策略取决于索引更新的频率和对过时结果的容忍度。对于接近实时索引，高效的失效是必不可少的。
实际考量与调优
- 缓存大小设置： 为缓存分配足够的内存以实现良好的命中率，但要与系统整体内存限制进行权衡。监控命中/未命中率以指导调优。
- 驱逐策略： 选择与你预期的数据访问模式匹配的驱逐策略（LRU、LFU、ARC）。如果性能要求高，则对不同策略进行性能分析。
- 缓存粒度： 决定什么要缓存。缓存大型、粗粒度对象可能更简单但效率较低，比起缓存更小、频繁重复使用的组件。
- 量化 (quantization)与缓存： 如果使用量化，决定是缓存压缩编码（节省缓存内存）还是重建（解压）后的向量 (vector)（命中缓存时节省计算）。
有效管理内存和实施智能缓存不是事后考虑的事情；它们是构建高性能、可扩展向量搜索系统不可或缺的部分。通过分析内存使用情况，借助 mmap 等技术处理大型索引，并策略性地实施应用程序级缓存，你可以显著减少延迟并提高依赖向量搜索的 LLM 应用程序的整体效率。
