向量检索的延迟问题往往是渐进式恶化的：系统上线时数据量小，暴力检索（Flat索引）几毫秒就能返回结果，运营半年后向量规模涨到千万级，P99延迟却悄悄爬到了几百毫秒，客服工单随之而来。这不是玄学，而是复杂度问题——暴力检索需要对每个查询向量与库内所有向量计算距离，时间复杂度为O(N×D)，其中N是向量数量，D是维度。要根治这个问题，需要两手抓：一手靠近似最近邻（ANN）索引降低单次检索的计算量，一手靠缓存策略消灭重复计算。
一、为什么向量检索会慢：先算清楚复杂度这笔账
在讨论优化之前，必须先理解慢在哪里。假设库中有1亿条768维的向量，使用float32存储，单是原始数据就占约300GB内存。一次暴力检索需要完成1亿次距离计算，每次计算涉及768次乘加运算，即使在现代CPU上做了SIMD优化，单次检索也在秒级，显然无法接受。
慢的根源有三个：第一，计算量大，距离计算次数与库规模线性相关；第二，内存墙问题，随机访问向量数据时缓存命中率极低，CPU大量时间浪费在等内存；第三，维度灾难，维度越高，向量之间的距离区分度越差，剪枝效率下降。理解这三点后就能明白，索引优化的本质是「减少必须参与计算的距离次数」，缓存优化的本质是「让重复的查询根本不走计算」。
先用一个简单的例子感受暴力检索的代价：
import numpy as np
import time
# 模拟100万条768维向量
N, D = 1_000_000, 768
vectors = np.random.rand(N, D).astype("float32")
query = np.random.rand(D).astype("float32")
start = time.time()
# 暴力检索：一次性计算所有距离
distances = np.linalg.norm(vectors - query, axis=1)
top_k = np.argpartition(distances, 10)[:10]
print(f"耗时: {(time.time() - start) * 1000:.1f} ms")
# 单机环境下通常在 20~50ms，规模再涨一个数量级就不可接受
二、索引选型：HNSW、IVF与DiskANN的权衡
ANN索引的核心思想是牺牲少量召回率换取数量级的速度提升。目前工业界最主流的三类方案各有适用场景，选型前需要理解它们的原理差异。
HNSW（分层可导航小世界图）是目前内存充裕场景下的首选。它构建一个多层图结构，上层稀疏用于快速跳转，下层稠密用于精确逼近。查询时从顶层入口点贪心搜索，逐层下沉，最终在底层找到近似最近的邻居。HNSW的优势是查询性能极其稳定、召回率高（通常可达95%以上）、无需训练，缺点是构建慢、内存占用约为原始向量的1.5到2倍（图结构需要额外存储邻居指针）。
IVF（倒排文件索引）的思路是先用K-means把向量空间切分成若干簇（cell），查询时只扫描距离最近的几个簇。它构建快、内存开销小，配合PQ乘积量化可以大幅压缩存储，但需要训练过程，且对数据分布偏斜敏感——如果某个簇特别大，查询落到该簇时性能会明显劣化。IVF适合数据量大但内存预算有限的场景。
DiskANN则面向超大规模数据，把图索引放在SSD上，内存只保留压缩后的向量，单机可支撑十亿级向量。代价是延迟比纯内存方案高，通常在毫秒到十毫秒级。
下面是用Faiss构建HNSW索引的示例，注意关键参数的调优思路：
import faiss
import numpy as np
D = 768
vectors = np.random.rand(1_000_000, D).astype("float32")
# M: 每个节点的连接数，越大召回越高、内存越多，常用 16~48
# efConstruction: 构建时候选队列大小，越大图质量越好、构建越慢
index = faiss.IndexHNSWFlat(D, 32)
index.hnsw.efConstruction = 200
index.add(vectors)
# efSearch: 查询时候选队列大小，是运行时调节召回与速度的核心旋钮
index.hnsw.efSearch = 64
query = np.random.rand(1, D).astype("float32")
distances, ids = index.search(query, 10)
# 同等硬件下，HNSW 检索延迟通常可压到 1ms 以内
这里有个实践要点：efSearch是运行时可调参数，可以按查询流量动态调整——高峰期调低保吞吐，低峰期调高补召回。另一个容易踩的坑是HNSW不支持先加数据再删数据，若业务有频繁删除需求，应选择支持删除的索引类型或定期重建。
三、多级缓存策略：让热查询绕过索引计算
索引解决的是单次查询的速度，缓存解决的是重复查询的浪费。真实业务中查询分布往往高度倾斜：热门商品、爆款内容的embedding查询可能占总流量的30%以上，把这些结果缓存起来收益巨大。
推荐设计三级缓存。第一级是进程内LRU缓存，存放最热的查询向量到结果ID的映射，命中延迟接近零，容量控制在几万到几十万条；第二级是Redis集群，存放次热结果，TTL设置为数分钟到数小时，视数据更新频率而定；第三级才是向量索引本身。查询请求自上而下穿透，任何一级命中即返回。
import hashlib
import redis
import json
from functools import lru_cache
r = redis.Redis(host="127.0.0.1", port=6379)
def cache_key(query_vec, top_k):
# 向量哈希作为缓存键，注意使用原始字节保证一致性
vec_bytes = query_vec.astype("float32").tobytes()
return f"vec:{hashlib.md5(vec_bytes).hexdigest()}:{top_k}"
def search_with_cache(query_vec, top_k=10):
key = cache_key(query_vec, top_k)
# 一级：进程内缓存（示意，生产环境建议用带TTL的本地缓存库）
local = local_cache.get(key)
if local:
return local
# 二级：Redis缓存
cached = r.get(key)
if cached:
result = json.loads(cached)
local_cache.put(key, result)
return result
# 三级：真正的向量索引检索
result = vector_index.search(query_vec, top_k)
pipe = r.pipeline()
pipe.setex(key, 1800, json.dumps(result)) # 半小时过期
pipe.execute()
return result
缓存设计中有三个关键决策点。第一是键的设计：如果业务允许，用查询文本的哈希而不是向量哈希做键，因为同义文本经过embedding模型后向量可能有微小差异导致缓存永远不命中；第二是失效策略：底层数据（如商品信息、向量本身）更新时，必须联动失效相关缓存，否则用户会搜到已下架的内容，常见做法是按业务维度维护失效队列，批量清除；第三是防穿透：对不存在的查询缓存空结果并设短TTL，避免恶意查询把压力全部打到索引层。
四、进阶优化：量化压缩与批处理
除了索引和缓存，还有两个立竿见影的优化手段。一是向量量化：用PQ（乘积量化）把768维float32向量压缩到几十字节，内存占用下降一个数量级，代价是召回率损失几个百分点，通常的做法是「量化索引粗筛+原始向量精排」两级流水线，兼顾内存与精度。二是批处理：把并发到达的查询合并成一个batch送入索引，GPU或SIMD场景下吞吐可以提升数倍，Faiss提供了index.search_batch接口天然支持。
此外别忘了监控体系：持续采集召回率抽样指标、索引内存占用、各级缓存命中率与P99延迟，一旦召回率跌破阈值或缓存命中率异常下滑，往往是数据分布漂移或缓存失效逻辑出问题的信号。综合运用HNSW索引、三级缓存、量化压缩这三板斧，把P99延迟稳定控制在10毫秒以内，对千万到亿级规模的向量库而言是一个完全可以达到的工程目标。