8. 什么是向量数据库？有没有做过向量数据库的对比选型？

👔面试官：来说说什么是向量数据库？你有没有做过向量数据库的对比选型？

🙋‍♂️我：向量数据库我知道，就是在 MySQL 里加个向量字段，然后用 LIKE 语句做模糊匹配检索，差不多就是存向量的数据库吧。

👔面试官：MySQL 加个向量字段？那是存向量，不是向量数据库。你用 LIKE 做语义检索？LIKE 是字符串模糊匹配，跟向量相似度搜索完全是两码事。你对向量数据库的理解就停留在「存了个向量字段」？

🙋‍♂️我：那应该是用 Elasticsearch 吧？ES 不是也能做向量检索吗，加个 dense_vector 字段类型就行了，没必要专门引入一个新的数据库吧。

👔面试官：ES 的向量检索能力是后来加的补丁，不是原生设计，数据量一大性能根本扛不住。而且你连专门的向量数据库和传统数据库的本质区别都说不清楚，还怎么做选型？选型的时候你考虑哪些因素？索引算法了解吗？HNSW 和 IVF 听说过吗？

🙋‍♂️我：选型嘛，就看哪个 Star 多用哪个呗，Chroma Star 挺多的，生产环境直接上 Chroma 就行了吧？

👔面试官：Chroma 是本地嵌入式数据库，连分布式都不支持，你拿它上生产？百万级数据你怎么扛？面试前连基本的选型标准都没搞清楚，Star 数量能当技术选型依据？回去好好了解一下各家的适用场景再来吧。

好吧，这段面试属实是把向量数据库的雷踩了个遍。下面我来从头捋清楚向量数据库到底是什么、为什么需要它、以及怎么做选型。

💡 简要回答

向量数据库是专门用来存储和检索高维向量的数据库，核心能力是近似最近邻搜索，也叫 ANN，能在百万甚至亿级的向量里快速找出最相似的几条。普通关系型数据库的索引结构对高维向量基本上是失效的，所以需要专门的数据库来处理这个场景。我自己做过一些选型，本地开发阶段我用 Chroma，零配置上手极快；生产环境的中小规模我推荐 Qdrant，性能不错、API 也比较简洁；如果到了超大规模就要考虑 Milvus 了，字节和小米都在用；不想自己运维的话 Pinecone 是一个云托管的选项；如果项目里已经有 PostgreSQL，也可以直接用 pgvector 插件，不用引入新组件。

📝 详细解析

什么是向量数据库？

向量数据库就是专门用来存储和检索「向量」的数据库。

这里的向量，指的是嵌入模型（Embedding Model）把文本、图片、音频这些内容转换成的一串浮点数，比如一句话可能被转换成 [0.12, -0.87, 0.34, ... ] 这样一个 768 维或 1024 维的数组。每一个向量代表了这段内容的「语义含义」，语义越相近的内容，它们的向量在高维空间里的距离就越近。

向量数据库支持的核心操作叫做 近似最近邻搜索（ANN，Approximate Nearest Neighbor）：给你一个查询向量，在库里找出和它最相似的 K 个向量，返回对应的原始内容。这正是 RAG 里「检索」那一步的底层支撑——用户问了一个问题，先把问题转成向量，再去向量数据库里找最相关的文档片段，最后喂给大模型生成回答。

很多人会把向量数据库和「MySQL 加个向量字段」混为一谈，其实这两者有本质区别。用一句话概括就是：MySQL 擅长精确匹配（WHERE id = 123），向量数据库擅长语义相似（「找和这个意思最接近的内容」）。两者解决的是完全不同的问题，不是互相替代的关系。

为什么需要专门的向量数据库？

理解了向量数据库是干什么的，接下来自然会问：为什么不直接在 MySQL 或者 ES 里存向量，非要引入一个新的数据库？

普通的关系型数据库（MySQL、PostgreSQL）在存储结构化数据时靠 B-tree 索引，查询 WHERE id = 123 这种精确匹配效率极高。但向量检索要做的事完全不同——不是找「等于」的，而是找「最相近」的，没有精确匹配，只有相似度排序。

高维向量（比如 1024 维）的相似度搜索如果暴力遍历，把查询向量和库里每一条向量都算一遍余弦相似度，百万条数据就要算一百万次，延迟完全不可接受。那为什么不用 B-tree 加速？因为 B-tree 只能处理一维的有序索引，对高维向量这种「多个维度同时要考虑距离」的场景基本是失效的。你不可能对一个 1024 维的向量建一个 B-tree，然后说「帮我找和它最近的」，因为「近」本身是一个高维空间的综合判断，不是某一个维度上的排序。

向量数据库的价值就在于用专门的索引结构把这个搜索加速，在可接受的精度损失下把延迟降到毫秒级。理解了这个核心价值，接下来我们看它是怎么做到的。

核心索引算法：HNSW 和 IVF

向量数据库之所以能做到毫秒级检索，秘密全在索引算法上。目前主流的索引算法有两种：

先说 HNSW（Hierarchical Navigable Small World），这是目前精度最高的 ANN 算法之一。它构建的是一个多层图结构，查询时从最上层的稀疏图开始导航，逐层收窄范围，最终在底层找到最近邻。你可以把它想象成在地图上找最近的餐厅：不是把全国所有餐厅都遍历一遍，而是先在全国层面找到大致方向，再锁定到省、市、区，一层一层缩小，效率极高。HNSW 的优点是召回率高（通常能达到 95%+ 的精度）、查询速度快；缺点是建索引时内存消耗大，不适合内存极度受限的场景。Qdrant、Milvus、Chroma 默认都用 HNSW。

IVF（Inverted File Index） 是另一种思路，它先对向量做聚类，把相似的向量分进同一个「桶」里，查询时只搜最相关的几个桶，而不是全量遍历。这就像图书馆的分类体系：找一本编程书，不需要把整个图书馆翻一遍，先找到「计算机科学」那个区域，再在里面找，范围大幅缩小。IVF 的优点是内存占用小、适合超大规模；缺点是精度比 HNSW 略低，需要调参（聚类数量 nlist、搜索桶数量 nprobe）。Milvus 在超大规模场景下会用 IVF 系列索引。

你可能会问，HNSW 精度高、速度快，为什么还需要 IVF？原因很简单：HNSW 的内存消耗和向量数量成正比，到了亿级规模内存可能扛不住。IVF 用聚类换内存，牺牲一点精度就能处理超大规模数据，两者各有适用场景。

向量数据库的核心能力

搞清楚了索引算法这个底层核心，再来看向量数据库在工程层面需要具备哪些能力。光有 ANN 搜索还不够，生产级系统还要支持几个关键特性：

第一个是 Metadata 过滤，也叫混合检索。实际业务里，知识库往往有多个部门、多个产品线的文档，用户查的时候只想搜「技术部的文档」或者「2024 年更新的内容」。向量数据库支持给每个向量挂上 metadata 字段，检索时加过滤条件，只在符合条件的子集里做 ANN 搜索。你可能会想，为什么不先 ANN 搜完再过滤？因为那样可能搜出来的 Top-K 结果大部分都不满足条件，白白浪费了检索名额。先过滤再 ANN 搜索，能保证召回的每一条都是真正想要的。

第二个是实时更新。RAG 的知识库经常需要新增、修改、删除文档，向量数据库需要支持增量更新。很多人以为向量索引建好就不能动了，其实主流的向量数据库都支持在线写入，新数据进来后增量构建索引，不需要停服重建。

第三个是与关键词检索融合。纯向量检索对一些精确词语（比如产品型号「GPT-4o」、专有名词）的效果不好，有些向量数据库同时支持向量检索 + BM25 关键词检索，做混合召回效果更好。

选型建议

了解了向量数据库的核心原理和能力之后，最后来看一个很实际的问题：到底选哪个？

选向量数据库主要看三个维度：数据规模、部署方式、是否需要混合检索。

数据规模在百万以内、团队小、快速上线，首选 Qdrant，性能好、API 设计简洁、文档完善，Docker 一条命令就能部署，Rust 写的性能很稳。很多团队一开始用 Chroma 做原型，后来上生产就切到 Qdrant，这个路径很常见。

说到 Chroma，它确实是上手最快的选项，Python 直接 pip install，本地内存运行，零配置，配合 LangChain/LlamaIndex 原生集成非常方便。但一定要注意，Chroma 是本地嵌入式数据库，很多人在开发阶段用 Chroma 觉得一切都好，直接就拿去上生产，结果数据量一上去、并发一上来就各种问题。Chroma 的定位就是开发测试用的，千万别拿它当生产数据库。

数据规模在千万到亿级，需要分布式，选 Milvus，国内大厂用得最多，支持多种索引类型，有完整的集群方案，但部署运维复杂度也高，团队需要有足够的人力来维护。

不想运维，数据在云上，用 Pinecone，全托管 SaaS，按用量付费，适合快速验证商业化产品。不过要注意数据出境的问题，如果业务数据有合规要求，Pinecone 就不合适了。

已经在用 PostgreSQL，数据量不是特别大，可以直接用 pgvector 插件，不用引入新组件，查询可以和业务数据做 SQL JOIN，运维成本为零。

把几个常用的选项对比一下，方便选型时做决策：

数据库	部署方式	适合规模	混合检索	主要优势	主要劣势
Chroma	本地/嵌入式	小规模（开发测试）	否	零配置，上手极快	不适合生产
Qdrant	自托管/云	中小规模（百万级）	是	性能好，API 简洁	超大规模需调优
Milvus	自托管（分布式）	大规模（亿级）	是	可水平扩展	部署运维复杂
Pinecone	全托管云服务	中大规模	是	无需运维	费用高，数据出境
pgvector	PostgreSQL 插件	中小规模	是（配合全文检索）	无需新组件，可 JOIN 业务数据	性能弱于专用向量库

🎯 面试总结

回到开头那段面试，面试官问「什么是向量数据库」，你不能把它理解成「普通数据库加个向量字段」，这完全搞反了。向量数据库是专门为高维向量的相似度搜索设计的，核心能力是 ANN（近似最近邻搜索），普通关系型数据库的 B-tree 索引对高维向量检索基本是失效的，这不是加个字段就能解决的问题。

面试官追问选型标准的时候，你要从数据规模、部署方式、是否需要混合检索三个维度来回答。开发阶段用 Chroma 快速验证，中小规模生产环境推荐 Qdrant，超大规模选 Milvus 做分布式，不想运维就上 Pinecone，已有 PostgreSQL 的项目直接用 pgvector 插件就够了。每个选项的适用场景和优劣势都要说清楚，千万别拿 GitHub Star 数量当选型依据。另外，索引算法至少要能讲清楚 HNSW 和 IVF 的区别和适用场景，这是向量数据库的核心技术，面试官一定会问。