向量数据库原理：语义搜索如何实现大规模高效检索

你已经把一百万份文档嵌入成了向量。现在来了一条查询，你需要在几毫秒内找出最接近的几个——逐一检查这一百万条数据太慢了。这就是向量数据库要解决的问题。

向量数据库在 RAG 热潮中从小众走向普及，经常被当作魔法看待。其实不是魔法。下面讲讲它们实际做什么，以及什么时候你真正需要一个。

问题：大规模最近邻搜索

一旦你的内容以嵌入向量（捕捉语义的向量）的形式存在，"找到最相关的文档"就变成了"找到离这个查询向量最近的向量"。原理很简单：计算与每条存储向量的距离，取最小值。

问题在于规模。每次请求都将你的查询与一百万条（甚至十亿条）向量逐一比对、精确计算，这叫暴力搜索或精确最近邻搜索，对于任何需要交互响应的场景都太慢了。你需要现在就拿到最近的向量，而不是扫描完整个数据库之后。

窍门：近似最近邻

向量数据库巧妙地做了一笔交易。它们不去找精确的最近向量，而是找几乎肯定是最近的那些——近似最近邻（ANN）搜索——而且速度要快得多。

背后的洞察是：如果事先把向量组织得当，你不必与所有向量逐一比对。像 HNSW 这样的算法会为向量构建一张可导航的图，这样搜索可以"跳跃"几步就接近正确的邻域，只访问很少一部分数据。你牺牲了一点准确度——偶尔把第 5 接近的当成第 4 接近的——换来数量级的速度提升。对于搜索和检索来说，这笔交易几乎总是值得的。这种"近似但快，胜过精确但用不了"的思路，在我构建的系统中随处可见。

向量数据库除了速度还给你什么

真正的向量数据库不仅仅是 ANN 索引。它还处理：

元数据过滤——"最近的向量，但只来自标注为 2024 年的文档"，将语义搜索与结构化约束结合起来。

更新——随着数据变化添加、删除和重建向量索引，而不需要重建一切。

持久化和扩展——存储远超内存容量的数据，并在增长过程中保持高速。

你真的需要一个吗？

说实话：不一定。

只有几千个向量？内存中的库，甚至用普通数组做精确搜索，就足够了。别添设你不需要的基础设施。

几十万到百万级别，且有实时更新和过滤需求？这时专用的向量数据库才真正发挥作用。

错误在于在原型阶段就上大基础设施。先从简单的来，等你的数据规模和查询量真正需要的时候再引入向量数据库。

向量数据库是一种专用引擎，只做一件事：在大规模场景下快速找到最近的向量。它是语义搜索和 RAG 的检索支柱——但和任何工具一样，只有问题大到确实需要它的时候才值得引入。更多关于我如何做这个判断的内容见 www.divyakush.com。

嵌入向量和语义搜索，从头说起——向量最初是从哪里来的。

分词：为什么 LLM 数不清 strawberry 里的 R——文本如何变成 token，以及这为什么重要。

上下文窗口：LLM 的工作记忆及其局限——模型的工作记忆以及如何管理它。

Divyakush Punjabi · 全栈与 AI 工程师作品集 · GitHub · LinkedIn