Vector Database向量数据库

向量数据库是为一件事优化的存储系统:给定一个查询向量,从上亿条向量里快速找出最相似的 K 条。传统数据库擅长精确匹配和范围查询,面对"找最接近的"这种需求只能全表扫描,数据量一大就跑不动。

它凭什么快

关键在于放弃精确。全量比对的复杂度随数据量线性增长,不可接受。向量数据库用的是近似最近邻(ANN)算法——HNSW、IVF、PQ 这些——通过预先建好的图或聚类结构,只搜索空间中很小一部分区域。

代价是结果可能不是最优的那几条,而是"几乎肯定包含最优的那几条"。这个近似程度可以调:调高召回率就慢一点、占内存多一点,调低就快但可能漏。绝大多数应用场景里,这个取舍非常划算。

挑选时真正该看的

• 过滤能力。真实场景几乎总是"在这个租户 / 这个时间段 / 这个权限范围内找最相似的"。向量检索和条件过滤怎么结合,是各家差异最大的地方,也是性能塌方最常见的原因。先过滤再检索、还是先检索再过滤,结果和速度差别很大。
• 更新代价。有些索引结构增删改很贵。如果数据每天大量变动,这一项比查询速度更关键。
• 规模与成本。向量吃内存。上千万条向量的内存账要提前算,量化压缩能省不少但会掉精度。
• 要不要独立部署。很多团队一开始就上了重型向量库,其实规模远没到。
• 混合检索。能不能同时跑向量和关键词(BM25)并融合排序。纯向量检索在专有名词、编号、精确短语上表现很差,混合检索通常是效果提升最明显的一步。

一个常被忽略的现实

十万条以内的数据,可能根本不需要向量数据库。 PostgreSQL 的 pgvector、SQLite 的向量扩展,甚至内存里直接算,都能满足。引入一个独立组件带来的运维、一致性、成本负担,在小规模下往往超过收益。

判断标准很简单:先用最简单的方案跑起来,量到了、慢了,再换。

常见误解

"向量数据库能替代传统数据库"——不能。它只解决相似度检索,事务、复杂关联、精确查询还是要靠原来的库。绝大多数系统是两者并存,原文和元信息在传统库,向量在向量库,靠 ID 关联。

"存进去就能搜准"——检索质量主要由 Embedding 模型和切块策略决定,数据库只负责快。库选得再好,前面两步没做对一样搜不准。