向量数据库存储高维向量（通常为384到3072个浮点数，具体取决于嵌入模型），并支持在数百万或数十亿个向量中进行快速最近邻搜索。其基本操作是：给定一个查询向量，找到数据库中与之最接近的k个向量，通过余弦相似度、点积或欧几里得距离进行衡量。暴力搜索（将查询与所有存储的向量逐一比较）虽然精确，但规模扩大时速度过慢。因此，向量数据库使用近似最近邻（ANN）算法，以牺牲极小的精度换取巨大的速度提升——通常在搜索索引的一小部分时，仍能找到95–99%的真实最近邻。
最常见的ANN算法是HNSW（分层可导航小世界），被Qdrant、Weaviate、pgvector等广泛使用。HNSW构建一个多层图，其中每个向量是一个节点，连接到其最近邻。搜索从顶层（稀疏、长距离连接）开始，逐步深入到底层（密集、短距离连接），就像在地图上放大一样。它速度快、精度高，适用于数亿个向量的数据集。权衡是内存：HNSW将图存储在RAM中，因此需要足够的内存来容纳向量和图的开销。对于一百万个1536维向量（OpenAI的ada-002输出），大约需要6–8 GB内存。IVF（倒排索引）和ScaNN等替代方案内存占用更少，但需要更多调优。Pinecone和部分Qdrant配置使用量化——将向量从float32压缩为int8或二进制——以在相同内存中容纳更多向量，但会略微损失精度。
在主要向量数据库之间选择取决于你的约束条件。Qdrant和Weaviate是开源且可自托管的，这对数据隐私和成本控制很重要——你可以在自己的基础设施上运行它们，仅支付计算费用。Pinecone是全托管（无需操作基础设施），但存在供应商锁定问题，按向量计费，在大规模时成本高昂。ChromaDB轻量且嵌入式（在进程中运行，存储到磁盘），适合原型设计和小数据集，但不适合处理数百万向量的生产环境工作负载。如果你已经在运行PostgreSQL，使用pgvector扩展的PostgreSQL很有吸引力，因为它避免了添加新数据库到技术栈，但其查询性能在更大规模时落后于专用向量数据库。对于大多数生产RAG系统，Qdrant或Weaviate在性能、功能和操作控制之间提供了最佳平衡。
元数据过滤是区分严肃向量数据库与玩具实现的特征。实际上，你几乎从不希望搜索整个集合——你希望搜索“此用户上传的所有文档”或“仅过去30天的文档”或“特定PDF中的块”。向量数据库允许你将元数据与每个向量一起存储，并在相似性搜索前或期间应用过滤。这称为预过滤（先过滤，再搜索缩减后的集合）或后过滤（搜索所有内容，再丢弃不匹配的结果）。预过滤更高效，但需要索引支持；大多数生产数据库现在都支持。在索引时正确设计元数据模式可以避免后续巨大痛苦——在未设计过滤的集合上添加过滤通常意味着重新索引所有内容。
向量数据库在当前AI浪潮之前就已存在——Spotify多年前就使用近似最近邻搜索进行音乐推荐，Facebook的Faiss库自2017年以来一直存在。但2023–2024年嵌入模型和RAG的爆发使其从利基技术转变为关键基础设施。该领域仍在快速成熟：多租户（在共享部署中高效隔离客户数据）、混合搜索（在单个查询中结合向量和关键字搜索）以及磁盘索引（处理超出内存的数据集）都是产品差异显著且快速改进的领域。如果你今天开始一个项目，请选择一个能处理当前规模、支持元数据过滤和混合搜索且有活跃维护轨迹的数据库。你以后可以迁移——嵌入向量是可移植的。