想象社区图书馆要举办一场“检索大赛”。书架上有几百万本“书”，每本书其实是一串密密麻麻的数字，代表这本书的“味道”；读者递上一张便签，上面也写着一串数字，描述他想读的感觉。管理员的工作，就是根据这串数字，快速把最相近的书找出来。问题是：该选哪位管理员、哪种书架方案？于是图书馆决定办一次大考——用同一批读者、同一批书，记下谁找得准、谁接待得快、谁让读者等得最久。这场大考，就是“向量检索性能评测”。本文会用这场图书馆大考作比喻，带你搞懂召回率@k、QPS、P99 延迟、ANNS 近似检索、HNSW 与 IVF 索引对比，以及如何为业务选型和压测。

岗位关联

学会向量检索性能评测，你就能用数据说话：在 RAG 系统、向量搜索和推荐场景中，为业务选出真正合适的索引，而不是凭感觉拍板。

目录
  1. 可视化演示
  2. 评测核心指标：先给“检索大赛”定规则
  3. 召回率计算：从“推荐袋”里数命中
  4. ANNS 原理：从“翻开每本书”到“走几条捷径”
  5. HNSW 与 IVF：两种不同的“书架方案”
  6. 测试数据集：选择什么样的“考场”
  7. 压测方法论：在“人流高峰”前先演习
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示recall@k召回率计算过程与HNSW/IVF索引性能对比，切换模式查看召回率评测和QPS-延迟权衡曲线。

本节配有交互动效（进入视口后自动加载，约 3KB）。

recall@k召回率计算过程 GT：暴力搜索的Ground Truth近邻集 ANN：近似最近邻检索结果集 HIT：ANN与GT的交集（命中） recall@k = |ANN∩GT| / |GT| recall越高说明索引越准确

评测核心指标：先给“检索大赛”定规则

图书馆大考要发一张成绩单，上面不只写“找到了吗”，还要写每分钟接待了多少位读者、每位读者等了多久、书架额外占了多大面积。对应到向量检索，这四列成绩就是召回率@k、QPS、P99 延迟和内存占用。召回率回答“找得准不准”，QPS 回答“每秒能处理多少查询”，P99 延迟回答“最慢的那 1% 用户等了多久”，内存占用回答“这套索引贵不贵”。

其中 QPS 是最直观的吞吐指标，它的定义简单到像数人头：一段时间内完成了多少次查询，再除以时间。需要注意的是，QPS 高不代表单次就快，它更像是图书馆入口的闸机，一秒钟能放多少人进去，而不是每个人在馆内待了多久。

回到图书馆：一位管理员就算找书再准，如果每分钟只能服务两个人，高峰时读者照样排队到门外。所以评测不能只看“找得准”，还要把吞吐、延迟和成本一起放进成绩单。

QPS=NqueriesTwindow\displaystyle \text{QPS} = \frac{N_{\text{queries}}}{T_{\text{window}}}
QPS 等于统计窗口内完成的查询总数除以窗口时长，反映系统每秒能吞吐多少查询。
  1. 统计窗口内查询数N_queries 表示在评测时间窗口内完成的总查询次数，就像一小时内涌进图书馆的读者人数。
    NqueriesN_{\text{queries}}
  2. 统计窗口时长T_window 表示这次统计持续了多少秒，是评测的时间刻度。
    TwindowT_{\text{window}}
  3. 相除得吞吐用查询总数除以时间，就得到每秒吞吐量，也就是 QPS。
    QPS=NqueriesTwindow\displaystyle \text{QPS} = \frac{N_{\text{queries}}}{T_{\text{window}}}

召回率计算：从“推荐袋”里数命中

考试时，图书馆会先悄悄准备一个“标准答案袋”。袋子里的书，是根据读者的便签在全校范围里逐一比对后，公认最相近的 k 本书，也就是真近邻集合 G_k。管理员交上来的推荐袋是 R_k。召回率要回答的问题很朴素：标准答案袋里的 k 本书，管理员到底捞回了多少本？

这个计数过程写成公式就是 recall@k。它不会惩罚“多找了几本不相干的书”，只关心该中的有没有中。就像考试只统计你答对了多少道必做题，不扣你做错附加题的分。

评测时通常要随机抽几百上千条真实查询，分别算 recall@1、recall@5、recall@10。只看单一 k 值容易失真：k 越大，命中概率天然越高，所以要多 k 看曲线，才能知道这套书架在大范围推荐和小范围精排时分别表现如何。

Recall@k=∣Rk∩Gk∣k\displaystyle \text{Recall@k} = \frac{|R_k \cap G_k|}{k}
recall@k 是检索返回的前 k 个结果中，与真实 k 近邻重合的数量占 k 的比例。
  1. 真近邻集合G_k 是查询向量在全部数据中距离最近的 k 个点，相当于图书馆的标准答案袋。
    GkG_k
  2. 检索返回集合R_k 是索引实际返回的前 k 个结果，相当于管理员交上来的推荐袋。
    RkR_k
  3. 交集计数|R_k ∩ G_k| 统计两个袋子中共有多少本相同的书，也就是命中数。
    ∣Rk∩Gk∣\displaystyle |R_k \cap G_k|
  4. 除以 k 归一化把命中数除以 k，得到 0 到 1 之间的召回率。
    ∣Rk∩Gk∣k\displaystyle \frac{|R_k \cap G_k|}{k}

ANNS 原理：从“翻开每本书”到“走几条捷径”

如果图书馆的查书方式是把每本书都翻开比一遍，那一定能找到最相似的那本，这就是暴力检索。问题是书太多了，每本又是一串几百维的数字，翻一遍的时间随数据量线性增长，线上根本等不起。于是管理员开始走捷径：不保证绝对最优，只保证“足够相似、足够快”。这种思路就是近似最近邻搜索，英文缩写 ANNS。

在评测里，我们不会直接说“快了多少”，而是用两个数字说话：召回率和加速比。召回率衡量捷径有没有偏离正确答案，加速比衡量捷径到底省了多少时间。

图书馆馆长并不要求每次都必须找出世界上唯一最像的那本书，只要推荐袋里的书读者基本满意，同时等待时间从十分钟降到一秒，这场交易就值得做。ANNS 的本质，就是用一点点召回率换巨大的速度提升，而评测就是确保这笔“交易”不亏。

加速比=TbruteTapprox\displaystyle \text{加速比} = \frac{T_{\text{brute}}}{T_{\text{approx}}}
加速比表示暴力检索耗时是近似检索耗时的多少倍，倍数越大，索引带来的速度提升越明显。
  1. 暴力检索耗时T_brute 是线性扫描全部向量找最近邻的时间，准确但昂贵。
    TbruteT_{\text{brute}}
  2. 近似检索耗时T_approx 是使用 ANNS 索引完成同样查询的时间。
    TapproxT_{\text{approx}}
  3. 取比值两者相除，得到近似检索相对暴力检索快了多少倍。
    TbruteTapprox\displaystyle \frac{T_{\text{brute}}}{T_{\text{approx}}}

HNSW 与 IVF：两种不同的“书架方案”

同样是走捷径，管理员们提出了两套方案。HNSW 的思路是给书建一张多层“熟人网络”：每本书都认识几本相邻的书，查询时先从上层的稀疏关系快速定位到大致区域，再往下层细化，有点像先问小区保安，再问楼栋邻居，最后敲开具体房门。IVF 的思路则是把书按内容聚类成若干个分类书架，查询时只选最近的几个书架翻找，像读者直接走进“金融区”或“文学区”，而不是逛遍整座图书馆。

在评测中，HNSW 往往表现出高召回、低延迟，但代价是额外的图结构和内存开销；IVF 内存更省、构建更直接，但需要先训练聚类中心，检索时还会受到候选集大小的限制。IVF 里有一个参数叫 nprobe，意思是选几个最近的书架去翻。nprobe 越大，候选书越多，召回率越高，耗时也越长。

所以不存在绝对“最好的书架”，只存在“最适合这场考试的方案”。如果业务内存紧张、数据量大且相对稳定，IVF 可能更划算；如果追求极致召回和低延迟，HNSW 通常更合适。评测报告要做的，就是把这两种方案的差异量化成一张对比表。

C=∑i∈probes∣celli∣\displaystyle C = \sum_{i \in \text{probes}} |\text{cell}_i|
IVF 的候选集大小等于被选中的 nprobe 个聚类单元中的向量总数，它直接决定召回率和耗时的平衡。
  1. 选中聚类单元probes 是与查询最近的 nprobe 个聚类中心集合，相当于管理员决定去翻哪几个分类书架。
    probes\text{probes}
  2. 单元大小|\text{cell}_i| 表示第 i 个聚类单元里有多少个向量，也就是这个书架上书的数量。
    ∣celli∣\displaystyle |\text{cell}_i|
  3. 候选总量把这些书架的书数加起来，就是最终需要精排的候选集大小。
    C=∑i∈probes∣celli∣\displaystyle C = \sum_{i \in \text{probes}} |\text{cell}_i|

测试数据集：选择什么样的“考场”

考试不能只在图书馆自己的小房间里模拟，还要考虑不同读者群体。公开数据集就像标准化模拟卷，比如 SIFT、GIST、GloVe，它们来自真实图像或文本特征，维度、数据量、查询分布都是公开的，方便不同系统横向比较。但模拟卷考得好，不代表在真实业务里一定表现好，所以最终还要用业务真实数据当“模拟考场”，让查询分布和线上尽量一致。

数据集评测的第一个硬指标是维度和规模。假设你有 N 个向量，每个向量有 d 维，每维用 float32 存储就是 4 字节，裸向量的内存占用可以很快估算出来。这个数字决定了单机能不能装下，也决定了索引需要优化到什么程度。

选考场时不要只看数据集名气，还要看维度是否接近、查询分布是否相似、更新频率是否一致。公开集负责横向对比，业务集负责最终验收，两者配合，评测结果才值得写进选型报告。

M=N×d×4\displaystyle M = N \times d \times 4
裸向量内存约等于向量数量乘维度再乘 4 字节，float32 每维占 4 字节。
  1. 向量数量N 是数据集中向量的总条数，对应图书馆里的藏书量。
    NN
  2. 向量维度d 是每条向量的维度数，对应每本书的特征条目数。
    dd
  3. 单维字节数4 是 float32 类型每个数值占用的字节数。
    44
  4. 连乘估算内存三者相乘得到裸向量占用的总字节数。
    M=N×d×4\displaystyle M = N \times d \times 4

压测方法论：在“人流高峰”前先演习

大考的最后一项，是模拟早高峰。你不能等图书馆真的挤满人再发现问题，而是要先放一批“假读者”进场，反复跑几轮。第一轮往往不算数，因为数据还没加载进内存、缓存还是冷的、索引页也没热起来。所以压测的第一步是加载数据、构建索引、预热若干轮，让系统进入稳定状态。

接下来是并发压力模型。真实世界的流量不是一条直线，而是由很多并发的读者同时涌入门。压测时设置并发数 C，系统达到稳态后，吞吐 QPS 和平均延迟之间满足一个简单关系：QPS 约等于并发数除以平均延迟秒数。反过来说，如果线上目标 QPS 是 Q，平均延迟是 L，需要的并发数就是 Q 乘 L。

压测结束后不要只写一个峰值 QPS，要把并发数、QPS、P50/P99 延迟、recall@k、内存和 CPU 一起记录在案。演习通过，图书馆才敢在真实高峰时开门；向量检索系统也一样，评测报告越完整，上线越安心。

C=Q×Lavg\displaystyle C = Q \times L_{\text{avg}}
在稳态下，并发数约等于目标 QPS 乘平均延迟秒数，这是压测模型的重要估算公式。
  1. 目标吞吐Q 是业务期望的 QPS，比如高峰每秒要处理 5000 次检索。
    QQ
  2. 平均延迟L_avg 是单次查询平均耗时，单位是秒。
    LavgL_{\text{avg}}
  3. 所需并发C 是压测时需要的并发连接数，用它来模拟足够多的同时访问。
    C=Q×Lavg\displaystyle C = Q \times L_{\text{avg}}

AI 应用场景

RAG 系统的索引选型评测

阶段：数据准备与离线评估

解决的问题：RAG 系统需要从海量知识库中检索相关片段喂给大模型。传统方式是凭经验选 HNSW 还是 IVF，上线后才发现延迟超标或召回不足。AI 方式是用业务问答对构造查询集，离线计算 recall@k、P99 和内存占用，提前选出最优索引。

具体案例：某客服机器人在 500 万条知识向量上分别测试 HNSW 和 IVF。HNSW 的 recall@10 达到 0.93，P99 延迟 38ms；IVF 在 nprobe=8 时 recall@10 为 0.88，但内存少了 40%。最终选择 IVF 并调大 nprobe，兼顾成本和体验。

Embedding 模型升级回归

阶段：模型上线与回归评测

解决的问题：替换文本 Embedding 模型后，向量空间彻底变化，旧的索引评测结果可能全部失效。AI 做法是固定测试集和查询集，用同一套评测脚本对比新旧模型在 recall@k、QPS 上的差异，避免“感觉变好了”的主观判断。

具体案例：团队把 Embedding 模型从 768 维降到 384 维后，裸向量内存下降一半，recall@10 从 0.90 微升到 0.91，P99 延迟降低 22%。评测报告成为模型升级决策的直接依据。

大促前的容量压测

阶段：容量规划与性能验收

解决的问题：电商大促或新品发布时，向量检索峰值流量可能翻几倍。传统方式是拍脑袋加机器，AI 方式是用真实查询日志做压测，按并发模型推导所需节点数，再验证不同水位下的 QPS 和 P99。

具体案例：某推荐系统用 2000 条真实查询做冲峰压测，发现 6 个节点扛不住 8000 QPS，P99 会超过 200ms；扩容到 10 个节点后，P99 稳定在 60ms，才被允许发布。

Python 演示

python67 行
import mathimport randomimport time  def vec_distance(a, b):    return math.sqrt(sum((x - y) ** 2 for x, y in zip(a, b)))  def knn_brute(vectors, query, k):    ids = list(range(len(vectors)))    ids.sort(key=lambda i: vec_distance(vectors[i], query))    return ids[:k]  class IVFFlat:    def __init__(self, nlist, seed=42):        self.nlist = nlist        self.seed = seed        self.centroid_list = []        self.cluster_list = [[] for _ in range(nlist)]     def train(self, vectors):        rng = random.Random(self.seed)        selected = rng.sample(range(len(vectors)), self.nlist)        self.centroid_list = [vectors[i][:] for i in selected]        for idx, vec in enumerate(vectors):            c = min(range(self.nlist),                    key=lambda j: vec_distance(vec, self.centroid_list[j]))            self.cluster_list[c].append(idx)     def search(self, vectors, query, k, nprobe=2):        probes = sorted(range(self.nlist),                        key=lambda j: vec_distance(query, self.centroid_list[j]))[:nprobe]        candidates = []        for c in probes:            candidates.extend(self.cluster_list[c])        candidates.sort(key=lambda i: vec_distance(vectors[i], query))        return candidates[:k]  def recall_at_k(true_ids, result_ids, k):    return len(set(true_ids[:k]) & set(result_ids[:k])) / k  def main():    random.seed(7)    vectors = [[random.gauss(0, 1) for _ in range(8)] for _ in range(300)]    queries = [[random.gauss(0, 1) for _ in range(8)] for _ in range(30)]    ivf = IVFFlat(nlist=5, seed=42)    ivf.train(vectors)    total_recall = 0.0    total_latency = 0.0    for q in queries:        truth = knn_brute(vectors, q, 5)        start = time.perf_counter()        approx = ivf.search(vectors, q, 5, nprobe=2)        total_latency += time.perf_counter() - start        total_recall += recall_at_k(truth, approx, 5)    avg_recall = total_recall / len(queries)    avg_latency_ms = total_latency / len(queries) * 1000    print("avg recall@5 = %.2f" % avg_recall)    print("avg search latency = %.3f ms" % avg_latency_ms)  if __name__ == "__main__":    main()
目的：用简单 IVF 近似索引在合成向量上对比暴力检索，输出 recall@5 和平均延迟，演示向量检索评测的核心流程。
  1. ids.sort(key=lambda i: vec_distance(vectors[i], query))暴力法把距离最近的书排到最前，作为真近邻基准。
  2. self.cluster_list[c].append(idx)把每个向量放进最近的聚类书架，模拟 IVF 的聚类分配。
  3. probes = sorted(range(self.nlist), key=lambda j: vec_distance(query, self.centroid_list[j]))[:nprobe]只挑最靠近查询的 nprobe 个书架，减少扫描范围。
  4. candidates.extend(self.cluster_list[c])汇总候选向量，再统一精排。
  5. return len(set(true_ids[:k]) & set(result_ids[:k])) / k用重合数除以 k，得到 recall@k。
  6. approx = ivf.search(vectors, q, 5, nprobe=2)执行近似检索，nprobe 是控制精度和速度的关键参数。

常见误区

误区我一直把 recall@k 调到 0.99，别的指标都不看，越高说明系统越牛。

正解召回率只是精度，不是全部性能。图书馆管理员如果每本书都翻一遍，确实能找得准，但读者等 10 秒也不会用。评测要同时看 QPS、P99 延迟和内存占用，按业务场景做平衡。

为何常见：评测报告里 recall 往往最显眼，初学者容易只盯着这一个数字。

误区压测时 QPS 冲到很高，我以为服务一定很快，根本不用看延迟。

正解QPS 是吞吐，不是单次速度。很多并发请求同时完成时，QPS 可以很高，但单个读者可能已经等了很久。必须看 P50/P99 延迟，P99 才代表最差体验的那批用户。

为何常见：看到总吞吐高就安心，忽略了响应时间分布。

误区大家都在用 SIFT、GIST 公开数据集测，我的业务也直接照抄结论选 HNSW。

正解公开集适合横向对比，但业务向量的维度、分布、更新频率不同，可能出现“这个数据集好用，那个业务不好用”的情况。最好先用公开集筛掉明显不行的方案，再用业务真实数据做最终验证。

为何常见：公开数据集容易获取，业务真实数据需要清洗和构造，成本更高。

误区听说 HNSW 又快召回率又高，所以所有场景都无脑上 HNSW。

正解HNSW 内存开销大、构建复杂；IVF 内存低、可解释性强，适合超大库和成本敏感场景。评测的意义就是量化这些差异，按业务限制选型。

为何常见：对比报告常拿 HNSW 和暴力搜索比，而不是和同类近似索引比。

误区压测就是把并发数拉到最大，看 QPS 最高能到多少，然后写进报告。

正解峰值 QPS 高可能伴随 P99 延迟爆炸。需要预热、分级加压，记录并发数、QPS、P99、recall@k 和资源占用等多维指标，才能判断线上能不能稳定运行。

为何常见：KPI 里 QPS 最直观，容易被单指标带偏。

面试题

Q1. 在向量检索评测中，recall@k 的正确含义是：

单选题 · easy

  • A.返回前 k 个全部相关
  • B.前 k 命中真近邻比例← 正确答案
  • C.全部结果相关项占比
  • D.每秒完成的 k 次查询

答案：B。recall@k 只关心前 k 个结果中有多少是真近邻，相当于管理员推荐袋里有多少本标准答案书。A 太绝对，C 描述的是整体准确率，D 说的是 QPS。

Q2. 暴力检索的复杂度是（N 为向量数，d 为维度）：

单选题 · easy

  • A.常数级 O(1)
  • B.对数级 O(logN)
  • C.线性乘维度 O(Nd)← 正确答案
  • D.线性级 O(N)

答案：C。暴力检索要计算查询向量与每个向量的距离，每次距离计算要遍历 d 维，所以复杂度是 O(Nd)。O(1)、O(logN) 和 O(N) 都没有正确描述“全部遍历且每步算维度”的过程。

Q3. HNSW 索引的核心思想是：

单选题 · mid

  • A.按类别均匀分区
  • B.多层图小世界导航← 正确答案
  • C.对所有向量有损压缩
  • D.把所有向量装进倒排表

答案：B。HNSW 构建多层图，查询从上层稀疏边快速定位，再向底层细化，类似先问小区保安再问邻居。均匀分区是 IVF 的聚类思路，有损压缩是量化思路，倒排表也只是其中一个组件。

Q4. IVF 检索时参数 nprobe 增大会带来：

单选题 · mid

  • A.召回率升，耗时升← 正确答案
  • B.召回率升，耗时降
  • C.召回率降，耗时升
  • D.召回率不变，内存降

答案：A。nprobe 变大意味着管理员翻更多分类书架，候选集更大，召回率上升，但精排耗时也随之上升。这就是精度与延迟的典型交换。

Q5. 做向量检索压测时，通常需要同时关注哪些指标？

多选题 · mid

  • A.召回率@k← 正确答案
  • B.QPS 吞吐← 正确答案
  • C.P99 延迟← 正确答案
  • D.SQL 兼容

答案：ABC。评测既要看准不准，也要看快不快、稳不稳。召回率负责精度，QPS 负责吞吐，P99 负责最差体验；SQL 兼容属于关系型数据库问题，不属于向量检索核心评测指标。

Q6. QPS 指的是：

单选题 · easy

  • A.每秒完成的查询数← 正确答案
  • B.单次查询平均延迟
  • C.每个向量的存储字节
  • D.召回结果中的命中数

答案：A。QPS 是每秒查询数，是吞吐指标。平均延迟属于时延指标，存储字节属于内存指标，命中数属于召回率指标。

Q7. 以下哪项是推荐的数据集选择做法？

单选题 · mid

  • A.只用公开数据集
  • B.只用业务数据集
  • C.公开加业务双验证← 正确答案
  • D.随机生成向量即可

答案：C。公开数据集适合横向对比，业务数据集负责最终验收，双验证最可靠。随机生成向量无法代表真实分布，只用数据集之一则容易失真。

Q8. 关于向量检索压测准备，正确的是：

多选题 · hard

  • A.加载全部数据建索引← 正确答案
  • B.先预热再开始采样← 正确答案
  • C.直接最大并发压测
  • D.记录并发数和延迟分位← 正确答案

答案：ABD。压测前要保证数据完整加载和索引构建完成；预热能减少冷缓存和冷页干扰；报告要记录并发数、QPS、延迟分位。直接最大并发会导致结果不客观，也不是压测的标准做法。

Q9. 100 万个 128 维 float32 向量，仅裸向量占用约：

单选题 · hard

  • A.约 128 MB
  • B.约 256 MB
  • C.约 512 MB← 正确答案
  • D.约 1024 MB

答案：C。内存估算是 N×d×4 = 1,000,000×128×4 = 512,000,000 字节，约 512 MB。这不是索引内存，只是裸向量占用的基础成本，实际索引还要在此基础上增加额外结构。

Q10. 一份可用的压测报告应该包含：

多选题 · mid

  • A.召回率与 P99 延迟← 正确答案
  • B.QPS 与并发数← 正确答案
  • C.数据集与索引参数← 正确答案
  • D.代码注释行数

答案：ABC。压测报告要能回答“在什么数据、什么索引参数、多少并发下，达到了多少 QPS、多少 P99、多少召回率”。代码注释行数与检索性能无关，不应写进评测报告。