最近换工作，面了几家做AI和大模型的公司，向量数据库相关的问题被问了很多。

随着RAG、语义搜索、推荐系统的普及，向量数据库成了后端开发的必备技能。面试中，面试官不仅会问基础概念，还会问工程实践和性能优化。这篇文章，我整理了面试中被问到的向量数据库相关问题，以及我的回答思路，希望能帮到正在准备面试的朋友。

问题一：什么是向量数据库，和传统数据库有什么区别

这是最基础的问题，几乎每场面试都会问。

我的回答思路是：

向量数据库是专门用来存储和检索向量的数据库。向量就是高维数组，比如一个1024维的浮点数数组，用来表示文本、图片、音频等非结构化数据的语义特征。

向量数据库和传统数据库的区别主要在几个方面：

第一，存储的数据不同。传统数据库存储的是结构化数据（行、列），向量数据库存储的是高维向量。

第二，查询方式不同。传统数据库是精确匹配（等于、大于、小于），向量数据库是相似度查询（找最相似的前K个向量）。

第三，索引结构不同。传统数据库用B-Tree、Hash等索引，向量数据库用ANN（近似最近邻）索引，比如HNSW、IVF、PQ等。

第四，评价指标不同。传统数据库关注查询的精确性和ACID，向量数据库关注召回率和查询延迟的平衡，因为ANN是近似查询，不保证100%准确。

第五，应用场景不同。传统数据库用于事务处理、业务数据存储，向量数据库用于RAG、语义搜索、推荐系统、图像检索等AI场景。

当然，现在的向量数据库也在向多模态发展，支持同时存储向量和结构化数据，支持过滤查询。传统数据库也在增加向量功能，比如PostgreSQL的pgvector、MySQL的向量类型。两者的边界在逐渐模糊。

问题二：向量数据库的相似度计算方法有哪些

这个问题考察对向量相似度的理解。

我的回答是：

常用的相似度计算方法有几种：

第一个是，欧氏距离（L2距离）。计算两个向量之间的直线距离，距离越小越相似。公式是各维度差的平方和开根号。欧氏距离适合对距离敏感的场景，比如图像检索。

第二个是，余弦相似度。计算两个向量夹角的余弦值，值越大越相似（范围是-1到1）。余弦相似度只关心方向，不关心长度，适合文本向量，因为文本向量的长度通常归一化了。

第三个是，点积（内积）。两个向量对应维度相乘再求和。如果向量都做了归一化，点积和余弦相似度是等价的。点积计算简单，性能好。

第四个是，曼哈顿距离（L1距离）。各维度差的绝对值之和。对异常值不如欧氏距离敏感。

第五个是，汉明距离。两个向量对应位置不同的数量，适合二进制向量。

选择哪种相似度，取决于向量的类型和应用场景。文本向量通常用余弦相似度或点积，图像向量常用欧氏距离，二进制向量用汉明距离。

问题三：常用的向量索引算法有哪些，原理是什么

这个问题是重点，考察对ANN索引的理解。

我的回答是：

向量检索的暴力方法是计算查询向量和所有向量的距离，取最近的K个。但当向量数量很大（比如百万、千万级），暴力检索太慢了，所以需要ANN（近似最近邻）索引。

常用的ANN索引算法有几种：

第一个是，HNSW（Hierarchical Navigable Small World）。这是目前最流行的索引算法。

HNSW的原理是构建一个多层的图结构。最底层包含所有向量，上层是下层的子集，越往上节点越少。查询的时候，从最上层开始，找到当前层最接近查询的节点，然后进入下一层继续找，直到最底层。这样可以快速跳过大部分不相关的向量，只检查少量候选。

HNSW的优点是查询速度快、召回率高、支持动态增删。缺点是内存占用大（因为要存图的边），构建索引比较慢。

第二个是，IVF（Inverted File）。

IVF的原理是先用K-Means把向量聚成N个簇，每个簇有一个中心。查询的时候，先找最接近查询的几个簇中心，然后只在这几个簇里做精确搜索。这样不需要搜索所有向量，只搜索部分簇。

IVF的优点是构建快、内存占用小。缺点是查询速度和召回率不如HNSW，而且需要训练（聚类），不适合频繁更新的场景。

IVF通常和PQ（乘积量化）结合使用，叫IVF-PQ，用PQ压缩向量，进一步减少内存和加速计算。

第三个是，PQ（Product Quantization，乘积量化）。

PQ的原理是把高维向量切分成若干段，每段单独做K-Means聚类，每段用一个聚类中心的ID来表示。这样，一个高维浮点数向量就被压缩成了几个字节的ID，大大减少了内存占用。查询的时候，用预计算的距离表快速估算距离。

PQ的优点是内存占用极小，适合大规模向量。缺点是有精度损失，召回率不如未压缩的索引。

第四个是，LSH（Locality Sensitive Hashing，局部敏感哈希）。

LSH的原理是设计哈希函数，让相似的向量有更高的概率哈希到同一个桶里。查询的时候，只需要搜索同一个桶里的向量。

LSH的优点是理论优雅，适合高维向量。缺点是实际效果不如HNSW和IVF-PQ，现在用得不多了。

第五个是，ScaNN（Scalable Nearest Neighbors）。

Google提出的算法，通过各向异性的向量量化和学习到的评分函数，在相同召回率下比HNSW更快。但实现复杂，主要用在Google的系统里。

实际应用中，HNSW是最常用的，因为它综合性能最好。如果内存紧张，可以用IVF-PQ。如果向量量特别大（十亿级），可能需要用更复杂的方案，比如磁盘索引、分布式索引。

问题四：HNSW的参数有哪些，怎么调优

这个问题考察工程实践能力。

我的回答是：

HNSW主要有几个参数：

第一个是，M（每个节点的最大连接数）。M越大，图的连接越多，查询越快，但内存占用越大，构建越慢。M越小，内存占用越小，但查询可能需要遍历更多节点。一般M取16到64，常用的是16或32。

第二个是，efconstruction（构建时的搜索宽度）。构建索引时，每个节点插入时搜索的候选数量。efconstruction越大，构建的图质量越高，查询召回率越高，但构建越慢。一般取100到500，常用的是200。

第三个是，efsearch（查询时的搜索宽度）。查询时搜索的候选数量。efsearch越大，召回率越高，但查询越慢。这个参数可以在查询时动态调整，根据对召回率和延迟的要求来设置。一般取100到1000。

调优的思路是：

  • 如果追求高召回率，增大M、efconstruction、efsearch。
  • 如果追求低延迟，减小这些参数，但要保证召回率达标。
  • 如果内存紧张，减小M，或者用PQ压缩。
  • 先固定M和efconstruction构建索引，然后通过调整efsearch来平衡召回率和延迟。

实际中，通常先做一个基准测试，在测试集上测试不同参数下的召回率和延迟，选择一个满足业务要求的配置。

问题五：向量数据库的分布式架构是怎样的

这个问题考察对分布式系统的理解。

我的回答是：

向量数据库的分布式架构，通常包括几个组件：

第一个是，数据分片（Sharding）。把向量数据分成多个分片，每个分片存储在不同的节点上。分片的方式可以是范围分片、哈希分片，或者基于聚类的分片。查询的时候，查询请求会发到所有分片，每个分片返回Top K，然后在协调节点合并，返回全局的Top K。

第二个是，副本（Replication）。每个分片有多个副本，保证高可用和读扩展。写请求发到主副本，同步到从副本。读请求可以负载均衡到多个副本。

第三个是，元数据管理。管理集群的拓扑、分片分布、索引状态等。通常用etcd、ZooKeeper等协调服务。

第四个是，查询路由。客户端的请求先到协调节点（或者客户端自己路由），协调节点把请求发到相关的分片，收集结果，合并返回。

以Milvus为例，它的架构包括：

  • 接入层：Proxy，负责接收请求、鉴权、限流、查询路由。
  • 协调层：RootCoord、DataCoord、QueryCoord，分别管理元数据、数据、查询。
  • 执行层：DataNode（写数据）、QueryNode（查询）、IndexNode（构建索引）。
  • 存储层：对象存储（存数据和索引）、元数据存储（etcd）、消息队列（Pulsar/Kafka）。

分布式向量数据库的挑战包括：

  • 分布式Top K查询的准确性和性能。
  • 索引构建的分布式调度。
  • 数据一致性和故障恢复。
  • 弹性扩缩容。

问题六：向量数据库怎么和传统数据库结合使用（RAG场景）

这个问题考察实际应用能力。

我的回答是：

在RAG（检索增强生成）场景中，向量数据库通常和传统数据库结合使用。

典型的架构是：

  1. 文档处理：把文档切成小块（chunk），每个小块用embedding模型生成向量。
  2. 存储：向量存在向量数据库里，同时把文档的原始内容、元数据（标题、作者、时间、来源等）存在传统数据库（比如PostgreSQL、MySQL）里。向量和原始数据通过一个ID关联。
  3. 检索：用户提问时，把问题也生成向量，在向量数据库里检索最相似的K个文档块，得到ID列表。
  4. 取详情：用ID列表去传统数据库里查文档的原始内容和元数据。
  5. 生成：把检索到的内容和用户的问题一起传给大模型，生成回答。

为什么不把所有内容都存在向量数据库里？因为：

  • 向量数据库擅长相似度检索，但不擅长复杂的结构化查询（比如按时间范围过滤、按作者统计）。
  • 传统数据库擅长事务和复杂查询，存原始数据更合适。
  • 两者结合，各取所长。

当然，现在很多向量数据库也支持标量过滤（metadata filtering），可以在向量检索的同时按元数据过滤。但复杂的关联查询、事务，还是传统数据库更强。

另外，也可以用PostgreSQL + pgvector的方案，把向量和结构化数据存在同一个数据库里，简化架构。但如果向量量特别大（千万级以上），专用的向量数据库性能更好。

问题七：向量数据库的性能优化手段有哪些

这个问题考察性能优化经验。

我的回答是：

向量数据库的性能优化，可以从几个层面入手：

第一个层面是，索引优化。选择合适的索引类型和参数。比如用HNSW，调整M、efconstruction、efsearch。根据召回率和延迟的要求，找到最优的参数组合。

第二个层面是，向量优化。降低向量的维度（比如用PCA降维），或者用量化压缩（PQ、SQ）减少内存占用，加速距离计算。还可以对向量做归一化，用点积代替余弦相似度，计算更快。

第三个层面是，查询优化。用标量过滤减少候选集，先按元数据过滤再做向量检索。用批量查询，减少网络开销。设置合理的Top K，不要取太多结果。

第四个层面是，硬件优化。用更大的内存，把索引和向量都放内存里。用SSD甚至NVMe，加速磁盘IO。用SIMD指令加速距离计算。用GPU做大规模的向量计算。

第五个层面是，架构优化。读写分离，读请求走副本。数据分片，分散压力。冷热分离，热数据放内存，冷数据放磁盘。用缓存缓存热门查询的结果。

第六个层面是，数据优化。定期清理无效数据，减少数据量。对数据做去重，避免重复向量。合理设置chunk大小，平衡检索精度和性能。

问题八：向量数据库的召回率怎么评估

这个问题考察对评估方法的理解。

我的回答是：

向量数据库的召回率（Recall），是指ANN查询返回的Top K结果中，有多少是暴力检索（精确检索）的Top K结果。公式是：

召回率 = ANN返回的Top K和精确Top K的交集数量 / K

比如，精确检索的Top 10是向量A1到A10，ANN返回的Top 10是A1到A9和B1，那么召回率就是9/10=90%。

评估召回率的步骤是：

  1. 准备一个测试集，包含一定数量的查询向量。
  2. 对每个查询向量，用暴力检索得到精确的Top K，作为ground truth。
  3. 用ANN索引查询，得到近似的Top K。
  4. 计算每个查询的召回率，然后取平均值。

除了召回率，还要关注查询延迟（QPS、P99延迟）和内存占用。这三个指标是互相制约的，需要根据业务要求找到平衡点。

实际应用中，召回率不是越高越好。召回率越高，查询越慢、内存越大。要根据业务场景确定可接受的召回率下限，然后在这个基础上优化性能。比如，RAG场景可能90%的召回率就够了，因为大模型有一定的容错能力；但人脸识别场景可能需要99%以上的召回率。

问题九：向量数据库怎么处理数据更新和删除

这个问题考察对动态数据的处理能力。

我的回答是：

向量数据库的数据更新和删除，比传统数据库复杂，因为涉及到索引的维护。

插入新向量：HNSW支持动态插入，新向量会被插入到图结构中。但插入太多之后，图的质量可能下降，需要定期重建索引。IVF类的索引，新向量可能暂时存在缓冲区，定期合并到索引中。

更新向量：通常是先删除旧向量，再插入新向量。因为向量变了，它在索引中的位置也可能变。有些数据库支持原地更新，但本质上也是删除+插入。

删除向量：HNSW的删除是软删除，标记为已删除，查询时跳过。软删除的向量不会立即从内存中移除，需要定期清理（类似PostgreSQL的VACUUM）。如果删除太多，索引质量下降，需要重建。

大规模数据更新的最佳实践是：

  • 批量写入，而不是单条写入，减少索引更新的开销。
  • 定期重建索引，保证索引质量。
  • 用蓝绿部署，新索引用新数据构建，构建完成后切换流量，避免重建期间影响查询。
  • 对于频繁更新的场景，考虑用支持实时更新的索引，或者用Lambda架构（实时层+批处理层）。

问题十：常用的向量数据库有哪些，怎么选型

这个问题考察对行业的了解。

我的回答是：

常用的向量数据库有几种：

第一个是，Milvus。开源的分布式向量数据库，功能强大，支持多种索引，适合大规模生产环境。但架构比较重，运维成本高。

第二个是，Qdrant。开源的向量数据库，Rust写的，性能好，API友好，支持标量过滤。单机和分布式都支持，比较轻量。

第三个是，Weaviate。开源的向量数据库，支持多模态，有内置的embedding模块，生态好。

第四个是，Pinecone。闭源的SaaS向量数据库，开箱即用，不用自己运维，性能好。但费用高，数据存在第三方。

第五个是，Chroma。轻量级的向量数据库，适合原型开发和小规模应用。Python接口友好，但不适合大规模生产。

第六个是，FAISS。Facebook开源的向量检索库，不是完整的数据库，需要自己实现持久化、分布式等。但性能非常好，适合做底层引擎。

第七个是，pgvector。PostgreSQL的向量扩展，把向量存在PostgreSQL里，适合已经用PostgreSQL、向量量不大的场景。

选型的考虑因素：

  • 数据规模：百万级以下，pgvector、Chroma就够了；千万到亿级，Milvus、Qdrant、Pinecone；十亿级以上，需要更专业的方案。
  • 运维能力：有运维团队可以选Milvus，不想运维选Pinecone。
  • 功能需求：需要标量过滤、多模态、分布式等，选功能全的。
  • 成本：开源的免费但要自己运维，SaaS的付费但省心。
  • 性能要求：对延迟和吞吐量要求高的，做基准测试对比。

一些面试建议

最后，分享一些向量数据库面试的建议。

第一，基础要扎实。向量的基本概念、相似度计算、ANN索引的原理，这些是必问的，一定要搞懂。尤其是HNSW的原理，几乎每场面试都会问。

第二，要有实践经验。光懂理论不够，最好实际用过一两个向量数据库，做过RAG或者语义搜索的项目。面试的时候，能讲出自己在项目中怎么用的、遇到了什么问题、怎么解决的，比单纯背理论有说服力得多。

第三，了解行业动态。向量数据库发展很快，新的产品、新的算法、新的应用场景不断出现。关注行业动态，了解主流产品的特点和区别，面试的时候能体现你的视野。

第四，能结合大模型聊。向量数据库现在最大的应用场景是RAG，面试中经常会和大模型、embedding、RAG一起问。要能把向量数据库放在整个AI应用的架构里去聊，而不是孤立地谈向量数据库。

写在最后

向量数据库是AI时代的基础设施，随着大模型的普及，它的重要性会越来越高。掌握向量数据库的原理和实践，对后端开发来说是一个很有价值的技能。

这篇文章整理的面试题，覆盖了从基础概念到工程实践的主要知识点。希望能帮到正在准备面试的朋友。

当然，面试题只是一个参考，最重要的还是真正理解和实践。把向量数据库用起来，在项目中积累经验，面试的时候自然能游刃有余。

祝大家都能拿到心仪的offer。