跳转至

P1-13.4 向量搜索(vector search)实现的直觉

Section ID: P1-13.4 Version: v2026.07.20

在 P1-13.1 中，我们看了如何通过嵌入(embedding)把文本(text)表示成向量(vector)。在 P1-13.2 中，我们看了如何通过相似度搜索(similarity search)找到接近的向量。在 P1-13.3 中，我们又看了怎样把这些检索候选接进 LLM 的输入上下文(context)中，形成 RAG(retrieval-augmented generation)。

现在还剩下一个问题：当向量数量变得非常多时，怎样才能快速找到接近的候选？ P1-13.4 不会从深层算法出发，而是从实现直觉来处理这个问题。

向量搜索的实现，是为了在大量向量中快速找到接近候选，而同时设计存储结构、索引与近似搜索方式的过程。

这里最重要的点不是“精确数学公式”，而是“为什么不能每次都把所有向量全部比一遍”。

Part 1 会在这里建立 向量搜索(vector search)实现、索引(index)、近似最近邻(approximate nearest neighbor, ANN)、基于图的搜索(graph-based search)、向量数据库(vector database) 的基本区分。13.1 介绍了嵌入，13.2 介绍了相似度搜索，13.3 介绍了 RAG，而这里要整理的是：这些流程在 真实存储与搜索实现里是怎样被加速的。

这里先固定 当向量非常多时怎样快速找到接近候选 这个问题。HNSW(hierarchical navigable small world)、FAISS、product quantization 等名称会在 Part 5 的 P5-13.1、P5-13.2 中，以服务视角下的搜索存储与索引质量继续出现；这里先只抓住减少全量比较的实现直觉。

等到 Part 2 重新看图(graph)这种数据结构时，本节关于图索引(index)的说明会更自然地接上去。现在先保留一个直觉：把接近的向量用节点(node)与边(edge)连接起来，可以缩短搜索路径。

索引、ANN、基于图的搜索、向量数据库 属于不同层次的实现概念。先把它们的作用区分如下：

术语 极简含义 本节中的作用
索引 为了更快搜索而提前构造的结构 减少全量比较的基本装置
ANN 不追求绝对最近，而是快速找到足够接近的候选 速度与质量折中的核心
基于图的搜索 沿着接近向量之间的连接逐步缩小候选范围 理解 HNSW 直觉的起点
向量数据库 同时处理向量存储、搜索、元数据与运维的系统 理解 RAG 存储层的框架
brute-force search 每次都直接比较所有向量的方法 说明为什么需要索引的基准线

这里先把 全量比较会慢，而索引与 ANN 是为了快速缩小候选范围 作为基准线。

主题 本节要看的问题
全量比较(brute-force search) 为什么不能每次都把所有向量重新比较？
索引(index) 为了加快搜索，系统需要预先准备什么？
近似最近邻(approximate nearest neighbor, ANN) 为什么要用“足够接近”来换取速度？
基于图的搜索(graph-based search) 利用接近向量之间的连接是什么意思？
运维考量 准确率、速度与成本之间要怎样平衡？

阅读向量搜索实现流程的基准

  • 理解向量搜索随着数据变大，会逐渐成为计算问题。
  • 把索引(index)理解为为了加快搜索而预先构造的结构。
  • 把近似最近邻(approximate nearest neighbor, ANN)理解为快速寻找候选的折中方案。
  • 建立对基于图(graph)索引的直觉：它会利用接近向量之间的连接。
  • 理解向量数据库(vector database)不是单一搜索算法，而是连同存储、过滤、元数据与运维一起处理的系统。

三个基准

这里不会深挖向量数据库内部实现，而是专注于整理搜索实现应当怎样被阅读。

基准 为什么重要 本节所需的理解水平
向量搜索是在存储向量并寻找接近候选 这能把嵌入说明连接到真实系统。 只要理解成系统要把向量保存起来，并放入可比较结构即可。
exact 与 approximate 搜索是准确率与速度之间的选择 这能说明为什么资料结构会在实现中变重要。 只要理解成很多时候不是追求绝对最优，而是快速找近似候选即可。
图、树、索引都是为提高搜索速度而设计的结构 这能把数据结构说明与服务实现连接起来。 只要理解成重要的不只是向量本身，还有“怎么找它们”。

每次比较所有向量会越来越慢

最直接的方法是：把问题向量与所有文档向量逐一比较。

问题向量
-> 与文档向量 1 比较
-> 与文档向量 2 比较
-> 与文档向量 3 比较
-> ...
-> 选出最接近的候选

这种方法可以称为全量比较(brute-force search)。当数据量小时，它简单而且准确。

但当文档片段越来越多时，问题就会出现。

文档片段数量 直觉
100 个 全部比较的负担不大
10 万个 每次提问的比较成本开始变高
1 亿个 存储、计算与响应时间都会变成问题

相似度搜索通常要找 top-k 候选。如果每次都重新比较全部向量，虽然结果可能准确，但响应时间会拉长，成本也会提高。

因此，搜索系统会提前做准备，避免每次都从头比较所有向量。这个准备结构就是索引(index)。

索引是为了更快找到候选而提前准备的结构

索引(index)就是为了让搜索更快，而预先构造好的结构。

这里可以先拿书籍索引或图书馆分类来类比理解。

没有索引：
需要把整本书从头翻到尾。

有索引：
可以先看相关词和位置，再跳到需要的地方。

向量搜索里也有类似问题。

没有索引：
把问题向量与所有文档向量都比较一遍。

有索引：
先沿着更可能接近的区域或连接前进。

当然，向量索引并不等同于普通书本的文字索引。向量位于高维空间(high-dimensional space)中，所以向量索引需要额外的数据结构(data structure)与算法，来更快找到接近候选。

近似搜索更快，但一定有折中

近似最近邻(approximate nearest neighbor, ANN)不是承诺每次都找到绝对最近的向量，而是承诺能快速找到“足够接近”的候选。

精确搜索(exact search)：
尽量做足比较，以找到真正最近的向量。

近似搜索(approximate search)：
接受少量遗漏可能性，以换取更快速度。

这里的“近似”并不等于“随便找一找”。更准确地说，它是在搜索速度与搜索质量之间做平衡。

标准 精确搜索(exact search) 近似搜索(approximate search)
目标 精确找到最近候选 快速找到足够接近的候选
优点 结果解释较简单 面对大规模数据时更容易快速运行
缺点 数据越大越容易变慢 可能漏掉一部分接近候选
适合场景 数据较小或准确性优先 大规模检索、实时响应

在 RAG 系统里，近似搜索很常见。因为用户不能一直等待，而文档仓库又会不断增长。

基于图的搜索会沿着接近路径前进

图(graph)是一种用节点(node)与边(edge)表示关系的数据结构。

在向量搜索里，基于图的索引可以直觉地理解成：把每个向量看成一个节点，并提前把彼此接近的向量连接起来。

向量 A -- 接近 -- 向量 B
向量 B -- 接近 -- 向量 C
向量 B -- 接近 -- 向量 D

搜索时，不再需要把所有向量逐个比较，而是可以沿着“看起来更接近”的连接逐步缩小候选范围。

问题向量
-> 选一个起始节点
-> 移动到更接近的邻居
-> 再移动到更接近的邻居
-> 选出足够接近的一组候选

HNSW(hierarchical navigable small world) 就是这种基于图的近似最近邻搜索的代表方法之一。正如名字里的 hierarchical 所示，它会使用多层(layer)图结构，把“快速移动到大致接近区域”和“在局部区域中进一步缩小候选”分开处理。

这里可以先用路径寻找来理解：

宽范围移动的路径：
先快速到达大致接近的区域。

细范围查看的路径：
再在该区域中找到更接近的候选。

这只是算法直觉，不是精确实现。真实的 HNSW 还会涉及图构建、邻居选择、搜索宽度等参数，这里不进入那些细节。

向量数据库不只是一个搜索算法

向量数据库(vector database)是为了存储和搜索向量而设计的系统。但在实际服务里，它不只是“一个寻找接近向量的算法”。

真实系统通常还需要下面这些能力：

要素 作用
向量存储(vector storage) 保存嵌入向量
元数据(metadata) 同时保存文档标题、日期、来源、权限等信息
索引(index) 构造加快搜索的结构
过滤(filtering) 只搜索特定日期、权限或文档类型
更新(update) 反映文档的新增、修改与删除
监控(monitoring) 观察搜索速度、失败与质量变化

例如，在组织内部文档检索中，只找到“接近的向量”还不够。

文档是否接近当前问题？
用户是否有权限查看该文档？
它是不是最新版本？
是否重复检出了同一份文档？
最终回答能否附上来源？

因此，向量数据库只是 RAG 系统中的一个组成部分。RAG 的整体质量不会只由向量数据库决定，还会受到文档准备、嵌入模型、搜索设置、提示词组装与回答审查的共同影响。

速度、质量与成本会一起变化

在向量搜索实现中，通常会同时看三类因素：

标准 问题
速度(latency) 是否能在用户可接受的等待时间内回答？
质量(recall, precision) 是否能找到需要的候选，并减少无关候选？
成本(cost) 存储空间、内存、GPU/CPU 成本是否可承受？

其中 recall 与 precision 会在后面的评估指标中再次出现。这里先抓住下面两个直觉：

recall：
不漏掉本应找到的候选的程度

precision：
找回来的候选中，真正相关内容所占的程度

搜索范围拉得更宽，漏掉重要文档的风险会下降，但无关文档也会更多。搜索范围收得更窄，系统可能更快更简洁，但也可能漏掉重要依据。

因此，向量搜索实现并不是在寻找一个永远固定的唯一答案，而更像是在根据用途寻找合适平衡。

检查清单

  • 能说明全量比较(brute-force search)会随着数据变大而变慢。
  • 能把索引(index)解释为为了加快搜索而预先构造的结构。
  • 能把近似最近邻(approximate nearest neighbor, ANN)解释为快速候选搜索的折中。
  • 能把基于图(graph)的搜索解释为沿着接近向量之间的连接来缩小候选。
  • 能把 HNSW(hierarchical navigable small world)解释为基于图 ANN 的代表性例子。
  • 能说明向量数据库(vector database)会同时处理向量存储、索引、元数据、过滤与更新。
  • 能说明向量搜索实现需要在速度(latency)、质量(recall, precision)、成本(cost)之间做平衡。
  • 能说明为什么真实服务里需要把 全量比较、索引、近似搜索、运维平衡 分开理解。
  • 能把向量数据库(vector database)解释成包含存储、过滤与运维的系统，而不是单一检索算法。

来源与参考资料