向量数据库解决了什么问题？

向量数据库解决了什么问题：为什么不能用MySQL作向量检索、ANN索引原理

你做了一个RAG系统，有100万给个文档chunk，每个chunk都经过Embedding变成了一个768维向量

现在用户提了一个问题，你把这个问题也向量化了，接下来要做的事情就是：找到100万个向量里，和这个Query向量最相似的top-5个

最直接的方法就是"暴力搜索"：把Query向量和全部100万个向量逐一计算余弦相似度，排序，取top-5，在一台普通服务器上，这个操作大概需要几百毫秒到几秒---对于实时场景来说完全不可以接收

而且，当向量数量增长到1000万、1亿时，暴力搜索的耗时增长，根本无法用于生产

这就是向量数据库要解决的核心问题：在海量高维向量中，如何在毫秒级内找到最相似的结果

传统关系型数据库的查询本质上是精确度匹配或者范围扫描，比如WHERE age > 25 AND city = '北京'，通过B-Tree索引可以快速定位到符合条件的行

向量相似度搜索完全不同，你不是在问"那些向量等于某个值"，而是在问"那些向量和我的查询向量最接近"---这是一个在高维连续空间里的几何问题

传统数据库的索引结构对这类问题完全无效，因为他们设计之初没有考虑"高维几何相似度"这个维度，即便PostgreSQL的pgverctor扩展支持向量存储，在大规模场景下的性能仍然远不如专门的向量数据库

要在百万级向量中做毫秒级检索，关键是向量索引，向量数据库不做暴力全量计算，而是预先构建一个特殊的索引结构，让检索时只需要访问一小部分向量就能找到近似的最近邻---这就是ANN

近似，这两个字需要注意，ANN不保证找绝对最近邻，但在实践中找到的结果精确度足够高，而速度提升是数量级的

目前最主流的两类向量索引算法是：

HNSW

HNSW构建了一个层级结构的图：最顶层是少量节点，形成高速公路，底层是所有节点，形成"街道网络"。检索时从顶层入口进入，沿图中的邻居边快速导航，逐层下降，想GPS导航一样越来越精细，最终定位到目标附近的最近邻

HNSW的优势时查询速度极快、精度高，是Milvus,Qdrant,Weaviate等主流向量数据库的默认索引，代价是构建索引时内存占用较大

IVF

IVF先对所有向量做K-means聚类，把相似的向量分组到同一个货架，检索时先找到Query向量最近的几个货架，只在这些货架里面做精细查找，而不是全量扫描

IVF的优势是内存占用较低，适合超大规模数据集，缺点是如果Query向量恰好落在两个货架的边界，可能会漏掉一些相关结果（边界效应）

向量数据库不只是"存向量、搜向量"这么简单，他还有几个在RAG工程里面非常重要的能力：

元数据过滤

每个向量可以附带结构化的元数据，比如文档来源、创建时间、部门归属、文档类型等。检索时可以在向量相似度搜索的同时附加元数据条件---比如"只在最近三个月的文档里面搜索"、"只搜索产品部门的文档"。这让RAG系统可以做到语义相关+业务过滤的组合查询

混合检索

主流向量数据库，支持同时运行向量搜索和关键词搜索，然后用融合算法，合并两路结果。这对中文专业术语场景尤其有用，因为有些专有名词的语义表示很弱，必须依赖关键词精确匹配

向量更新和删除

知识库需要持续更新---文档修改了、删除了，向量索引也需要对应更新，不同数据库对这个操作的支持成本差异很大，选型时需要考虑业务更新频率

目前常见的向量数据库选项可以分为几类：

专用向量数据库，这类系统从设计之初就以向量检索为核心，功能最完善，性能最优，适合大规模生产场景

传统数据库的向量扩展，如果已经有这些基础设施，小规模场景下也可以用，但在百万量级向量时性能明显不如专用方案

轻量级本地库，适合嵌入到应用内做原型或者小规模部署

选型的核心考量是规模和功能需求：如果是几十万向量以内的场景，Chroma或者pgvector足够，规模到百万以上、需要元数据过滤和混合检索，Milvus或者Qdrant是更好的选择

误区一：向量数据库的结果不精确，所以不可靠

ANN近似指的是找到的不一定是数学意义上的绝对最近邻，但实践过程中召回精度通常在95%-99%，对于RAG应用来说，这个精度完全够用，而速度收益是数量级的

误区二：向量数据库越大越好，键索引时参数越高越好

HNSW等索引有超参数（如M---每个节点的最大连接数，efConstruction---建图时的搜索深度），这些参数越大精度越高，但占用内存和构建时间也成比例增加。根据实际场景找到精度、内存的平衡点，不是越大越好

误区三：向量相似度高就代表语义相关

向量相似度是Embedding模型学出来的相似度，取决于模型的训练质量和领域覆盖。如果Embedding模型对某个专业领域支持不足，即便向量相似度高，语义也可能并不相关，向量数据库只是工具，底层模型的质量仍然是决定因素

误区四：用FAISS就是用了向量数据库

FAISS是一个向量索引库，不是完整的数据库系统。他没有持久化、没有元数据管理、没有CRUD接口，只负责索引构建和搜索计算。在生产环境里面，通常需要在FAISS基础上自己封装持久化和业务逻辑，或者直接用封装好的这些能力的向量数据库