What is a vector database

1️⃣ 考察意图

面试官想确认你是否真正理解向量数据库的本质，而非只会背概念。这道题看似基础，但刁钻点在于：很多人会把“向量数据库”等同于“用 embedding 做搜索”，却说不清它和“用 PostgreSQL + pgvector”或“用 FAISS 做内存索引”的本质区别。答好了能展示你对系统设计的硬实力：理解索引结构（HNSW/IVF）的 trade-off、知道何时该用向量数据库而非传统方案、以及能讲清楚 ANN 搜索的工程落地细节。

2️⃣ 标准答

向量数据库是一种专门为高维向量数据设计的数据库系统，核心能力是近似最近邻（ANN）搜索。它不是为了替代传统数据库，而是解决传统数据库无法高效处理的“语义相似性搜索”问题。

核心组件与工作流

嵌入模型：将非结构化数据（文本、图片、音频）转为固定维度的浮点数向量。例如，用 text-embedding-3-small 将句子转为 1536 维向量。关键取舍：嵌入模型的选择直接影响搜索质量，但高维向量（>1024 维）会显著增加索引构建和搜索延迟，实际中常降维到 256-512 维。
索引结构：这是向量数据库的引擎。常见索引：
HNSW（Hierarchical Navigable Small World）：基于图结构，搜索速度快（延迟 <10ms），但内存占用高（每个向量约 200-300 字节额外开销），适合高并发在线场景。
IVF（Inverted File Index）：基于聚类，先粗粒度搜索再细粒度精排，内存效率高，但召回率略低。工程取舍：HNSW 是“空间换时间”，IVF 是“精度换速度”。实际中常混合使用：IVF 做第一级过滤，HNSW 做第二级精排。
度量函数：余弦相似度（常用于文本）、欧氏距离（常用于图像）、内积（常用于推荐）。坑：很多人默认用余弦相似度，但若 embedding 已归一化，余弦等价于内积，用内积计算更快（避免除法）。

典型流程

入库：文档 → 嵌入模型 → 向量 + 元数据 → 构建索引（如 HNSW 的 ef_construction=200，M=16）。
查询：用户 query → 同一嵌入模型 → 向量 → 索引搜索（如 ef_search=40）→ 返回 Top-K 相似向量及元数据。

应用场景

RAG 知识库检索：LangChain + ChromaDB 或 Pinecone，召回率@10 通常 >90%。
推荐系统：用户 embedding 与物品 embedding 做内积排序，延迟 <5ms。
去重/聚类：用向量距离判断相似度，替代传统哈希。

与传统数据库对比

关系数据库：擅长精确匹配（WHERE id=123）、范围查询（BETWEEN）、事务（ACID）。向量数据库不保证精确结果，只返回近似 Top-K。
pgvector：PostgreSQL 的扩展，支持 IVFFlat 和 HNSW 索引。坑：pgvector 的 HNSW 实现不如专用库（如 FAISS）优化，百万级数据量下延迟可能翻倍。取舍：若已有 PostgreSQL 生态，用 pgvector 省运维成本；若追求极致性能（如毫秒级延迟），用专用向量数据库（Milvus、Qdrant）。

实际落地的坑 + 解法

坑 1：数据量增长后索引重建耗时。解法：用增量索引（如 Milvus 的“流式写入+批量合并”），或设置分段策略（每 100 万条数据自动合并）。
坑 2：高维向量（>1024 维）导致“维度灾难”，所有向量距离趋近。解法：用 PCA 降维到 256 维，或改用 Product Quantization（PQ）压缩，牺牲 5% 召回率换取 10 倍内存节省。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，定义上，向量数据库是专门做高维向量 ANN 搜索的数据库，核心组件是嵌入模型、索引结构（HNSW/IVF）和度量函数。第二，它和传统数据库的差异在于：传统库做精确匹配，向量库做近似搜索，且不保证 ACID。第三，实际落地要注意索引选择（HNSW 快但吃内存，IVF 省内存但召回略低）和维度灾难（降维或 PQ 压缩）。总结一句：向量数据库是语义搜索的引擎，但不是万能的，需要根据数据量和延迟要求选型。”

4️⃣ 高频追问 & 应对

追问 1：向量数据库和 FAISS 有什么区别？

应对策略：FAISS 是索引库，不是数据库。向量数据库在 FAISS 基础上加了持久化、分布式、CRUD 操作、元数据过滤、高可用等。例如，FAISS 不支持删除单条向量（需重建索引），而 Milvus 支持。取舍：若只需离线批量搜索，用 FAISS 更轻量；若需在线服务，用向量数据库省去自建运维。

追问 2：如何评估向量数据库的召回率？你期望达到多少？

应对策略：用“召回率@K”衡量：在 100 万数据集中，用暴力搜索（精确 Top-K）作为 ground truth，对比 ANN 结果。通常期望召回率@10 > 95%。坑：召回率不是越高越好，HNSW 的 ef_search 参数调高可提升召回但增加延迟。实际中在 95% 召回率下，延迟控制在 10ms 内是可接受的 trade-off。

追问 3：向量数据库能支持事务吗？为什么？

应对策略：不能，至少不是传统 ACID 事务。因为 ANN 搜索本质是近似计算，插入一条数据后索引不会立即更新（需异步合并），导致“读未提交”现象。解法：若需要强一致性，用“双写”策略：先写传统数据库（如 PostgreSQL），再异步同步到向量数据库，查询时以传统库为准。

5️⃣ 避坑 · 常见错误答法

❌ “向量数据库就是存向量的数据库，和 MySQL 差不多，只是字段类型是向量。” → ✅ 正确切入：强调核心差异是 ANN 搜索而非精确匹配，以及索引结构（HNSW/IVF）和度量函数。
❌ “向量数据库能替代传统数据库，以后所有搜索都用向量。” → ✅ 正确切入：说明适用边界——语义搜索、推荐、RAG；不适合精确匹配、事务、范围查询。
❌ “向量数据库的索引用 KNN 就行，不用 ANN。” → ✅ 正确切入：KNN 是精确搜索，数据量 >10 万时延迟不可接受（O(n)），必须用 ANN（如 HNSW 的 O(log n)）。

6️⃣ 简历呼应

如果你有 RAG 项目：从“向量数据库在 RAG 中的选型”切入，对比 ChromaDB 和 Pinecone 的索引策略，强调召回率@10 和延迟的 trade-off。
如果你只做过传统 NLP：用“语义搜索 vs 关键词搜索”类比，说明向量数据库如何解决传统 TF-IDF/BM25 无法处理的同义词和语义问题。
如果你是校招无项目：聚焦“HNSW 论文复现 demo”，用 Python 实现一个简化版 HNSW（1000 条数据），对比暴力搜索的召回率和延迟，展示对索引原理的理解。
《Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs》（HNSW 原论文）
《Billion-scale similarity search with GPUs》（FAISS 论文）
《Product Quantization for Nearest Neighbor Search》（PQ 压缩技术）
Milvus 官方文档：索引类型选择指南（IVF_FLAT vs HNSW vs DiskANN）
《What is a Vector Database?》by Pinecone（入门博客，含对比表）

—— 本场面试完 ——