什么是向量数据库？ANN索引、过滤与混合搜索

向量数据库是一种专为存储嵌入向量（表示文本、图像或其他数据含义的数字向量）并快速找到与查询向量最相似向量的系统。它不像传统数据库那样匹配关键词，而是以毫秒级响应“哪些存储项与该项含义最接近？”——即使在数百万向量中也是如此。这种能力使得语义搜索和RAG能够大规模实现。本指南将解释向量数据库的作用、底层工作原理，以及——直白地说——何时需要专用数据库而非轻量方案。

这是概念性说明。当您选择具体产品时，对比内容位于对比页面：最佳自托管向量数据库、Qdrant vs Weaviate 等。

向量数据库解决的问题

一旦你的内容被转换为嵌入向量，按含义搜索在概念上就很简单：为查询生成嵌入，然后找到相似度最高的存储向量。关键在于规模。

将查询与几百个向量逐一比较（“暴力搜索”）是瞬间完成的。但每次搜索都对比一千万个向量，对于实际应用来说就太慢了。朴素搜索每次都必须触及每个向量——这种代价线性增长，很快就变得不可行。

向量数据库的存在就是为了让这种搜索变快。它做了普通数据库不擅长的三件事：

1. 高效存储高维向量及其元数据。
2. 构建专用索引，使相似度搜索无需扫描所有内容。
3. 提供低延迟的近邻查询，并结合过滤、更新和持久化。

工作原理：近似最近邻（ANN）搜索

核心技术是**近似最近邻（ANN）**搜索。关键词是近似。ANN索引并不保证找到数学上绝对完美的最近向量（那需要全部检查），而是通过巧妙跳过绝大多数不可能相关的向量，几乎肯定能找到最近的向量。

这是一种刻意的权衡：你牺牲一点点准确度（称为召回率——你实际检索到的真正近邻的比例）来换取巨大的速度提升。一个调优良好的索引可能只搜索千分之一的数据，就返回98–99%的真正近邻。对于搜索和RAG，这种权衡几乎总是值得的。

你最常遇到的两种索引族：

HNSW (Hierarchical Navigable Small World)

HNSW是现代向量数据库中最流行的ANN索引。它构建了一个分层图，每个向量都与其附近的邻居相连，顶层有稀疏的“快速通道”用于快速跨越空间。搜索从顶层开始，跳跃到查询区域附近，然后下降到更密集的层进行细化——就像放大地图一样。

• 优点： 出色的召回率与速度平衡，适合高吞吐量、低延迟查询。通常作为默认选择。
• 代价： 内存占用更高（图保存在RAM中），且构建/插入速度比简单索引慢。

IVF (Inverted File Index)

IVF首先将所有向量聚类成组（单元）。在查询时，它确定查询附近哪几个聚类，并仅搜索那些，忽略其余部分。它通常与压缩（例如乘积量化）结合使用以减小内存——你会看到像 IVF 和 IVFPQ 这样的名称。

• 优点： 内存占用更低，构建速度快，可扩展到非常大的数据集，尤其是结合量化时。
• 代价： 召回率取决于你探测的聚类数量；调优更为重要，如果数据聚类不清晰，准确率可能会下降。

	HNSW	IVF (+PQ)
结构	分层邻居图	聚类单元
召回率/速度	优秀，默认选择	良好，可调性强
内存	较高（图在RAM中）	较低（尤其是添加量化时）
构建/插入速度	较慢	较快
最佳场景	延迟敏感的搜索	海量数据集，内存受限

你很少自己实现这些——你选择一个数据库并选择（或接受默认）一个索引类型。但了解这些权衡能让你阅读配置文件时理解为什么你的搜索快、慢或消耗内存。

超越相似度：元数据过滤

纯相似度搜索对于实际应用是不够的。你几乎总是需要将“含义最接近”与硬约束结合起来：仅此用户的文档、仅最近30天的文章、仅库存中的商品。这就是元数据过滤。

向量数据库将结构化字段（类别、日期、租户ID、价格）与每个向量一起存储，并允许你在相似度搜索的同一查询中按这些字段进行过滤。难点——也是产品之间的真正区别——在于高效实现：天真的实现要么先过滤，导致可搜索的向量太少，要么先搜索，然后丢弃大部分结果。好的引擎将过滤整合到ANN遍历中，从而保持快速和准确。这也是专用向量数据库在大规模下能够击败额外集成方案的原因之一。

混合搜索：向量加关键词

语义（向量）搜索擅长含义，但可能会遗漏精确字符串——精确的产品SKU、错误代码、人名。关键词搜索（BM25）则相反：字面、精确，对同义词不敏感。混合搜索同时运行两者并融合分数，从而获得语义搜索的召回率和关键词匹配的精确度。

许多向量数据库将混合搜索作为内置的单一查询功能提供，通常使用**倒数排名融合（RRF）**等融合方法来合并两个排名列表。对于大多数生产搜索，混合是默认的最强选择——我们在什么是语义搜索中解释了原因。比较产品时，原生混合支持（相对于在应用代码中手动组装）是一个有意义的指标。

何时真正需要向量数据库

这里实话实说，因为并非每个项目都需要专用向量数据库。根据规模选择工具：

像FAISS这样的库——用于进程内固定数据集

FAISS（以及类似库）是一个ANN库，而非数据库。它提供索引算法（HNSW、IVF等），可在你自己的进程内运行。没有服务器、没有API、没有内置持久化或过滤——所有事情都由你管理。它非常适合研究、批处理作业、notebook，或将快速索引嵌入到数据集基本静态且不需要并发写入、元数据过滤或网络服务的应用程序中。当你的需求超出“进程内快速搜索”时，库就会开始感觉像是你手动重建的基础设施。

pgvector——当你已经在运行Postgres时

pgvector 是一个扩展，为PostgreSQL增加了向量搜索（支持HNSW和IVFFlat索引）。如果你已经在运行Postgres，向量数量适中，并且你希望将向量与关系数据放在一起——同一数据库、同一备份、同一事务，少运维一个系统——pgvector通常是最务实的选择。权衡之处在于：在大规模或对混合搜索和过滤有高要求时，专用引擎通常更具优势，因为向量是pgvector的附加功能，而非其存在的全部理由。

专用向量数据库——大规模和生产环境

当你拥有数百万向量、需要并发负载下的低延迟搜索、想要高效的元数据过滤和原生混合搜索，并且需要真实的运维功能：水平扩展、复制、实时插入和删除以及网络API时，专用引擎（Qdrant、Weaviate、Milvus、Chroma 等）是正确的选择。这是严肃语义搜索和RAG的生产层级。

场景	合理选择
原型/notebook/静态数据集	类似FAISS的库
已在用Postgres，规模适中	pgvector
数百万向量，生产负载，过滤+混合搜索	专用向量数据库

本指南的重点是向量数据库是什么以及你是否需要它。选择哪个专用数据库是一个独立且主观的问题——涵盖在最佳自托管向量数据库、Qdrant vs Weaviate以及从网站搜索角度的Typesense vs Meilisearch比较中。

如何融入自托管栈

对于任何构建私有、自托管AI搜索的人来说，向量数据库是持有索引——即你的数据——的组件。自托管意味着你的嵌入向量（编码了你私有文档的含义）永远不会离开你的基础设施。大多数优秀选项都提供官方Docker镜像，并且对于中小型语料库可以在单台机器上运行，在需要时扩展到集群。掌控这一层，你就掌控了栈中最敏感的部分：你内容的可搜索表示。

常见问题

向量数据库和常规数据库有什么区别？ 常规数据库匹配精确值和关键词。向量数据库存储嵌入向量，并使用ANN索引通过含义相似度查找项。它们解决不同的问题——许多真实系统同时使用两者，或使用pgvector向常规Postgres数据库添加向量搜索。

向量数据库和嵌入向量是同一个东西吗？ 不是。嵌入向量是表示一段内容的单个向量。向量数据库存储许多嵌入向量并高效搜索它们。嵌入是数据；数据库是它存在和被查询的地方。

做RAG需要向量数据库吗？ 你需要某个地方来存储和搜索嵌入向量。对于小型或原型RAG系统，库或pgvector通常就足够了。在生产规模下——数百万向量、并发查询、过滤——专用向量数据库才真正有用武之地。

用一句话概括HNSW是什么？ HNSW是一种基于图的ANN索引，通过导航分层向量网络非常快速地找到近似最近邻；它是现代向量数据库中最常见的默认索引。

难道我不能只用pgvector处理所有事情吗？ 通常可以——特别是如果你已经在运行Postgres且规模适中。pgvector能很好地处理许多实际工作负载。大规模或需要高级混合搜索和高吞吐量过滤查询时，专用引擎会更胜一筹。具体权衡请参见对比页面。

---

向量数据库是基于含义的搜索的核心搜索引擎。向外构建你的理解：从嵌入向量开始，在语义搜索中看它们的实际应用，或在最佳自托管向量数据库中选择自托管选项。Aquila是自有AI搜索的独立家园。掌控你自己的搜索。