向量数据库和 Embedding 的原理是什么？

2026年阅读约 8 分钟面试指南 · AI面试

AI 面试向量数据库

AI开发面试题：Embedding语义表示与向量数据库，距离度量、HNSW近似检索、混合查询与标量过滤、量化压缩、Milvus/pgvector/ES选型对比，分三层讲解。

一句话总结

Embedding 把文本映射成高维向量（语义相近 → 向量距离近），向量数据库用 HNSW 等近似最近邻（ANN）算法在亿级向量里毫秒级找出"语义最近"的 K 条。核心权衡是召回率 vs 速度/内存。选型一句话：轻量用 pgvector（复用 PostgreSQL），大规模高并发用 Milvus，已有 ES 且要求关键词+向量混合则用 Elasticsearch。

初级理解

Embedding 是什么：把一段文字编码成一个固定长度的向量（如 768/1536 维），训练目标是"意思相近的文本，向量距离近"。它让"语义"变成可计算的几何问题：

"如何退款" → [0.12, -0.4, ...] "退货流程" → [0.11, -0.38, ...] ← 距离很近（语义近） "今天天气不错" → [0.9, 0.2, ...] ← 距离很远

为什么需要专门的向量数据库：暴力比较 1 亿条向量的距离是 O(N×D)，扛不住在线请求。向量库用 ANN 索引（牺牲一点点召回率换百倍千倍速度），同时提供增删改、标量过滤、分布式副本这些"数据库的基本修养"。

常见产品：Milvus（分布式、大规模）、Qdrant（Rust、性能好）、pgvector（PostgreSQL 插件，复用现有设施）、FAISS（库不是数据库，单机研究用）、Elasticsearch/OpenSearch（关键词+向量混合）、云厂商托管版。

中级深入

三种距离度量（要能说清区别）：

度量	含义	适用
余弦相似度	向量夹角，与长度无关	文本语义（最常用）
内积（IP）	夹角×模长	Embedding 模型声明用 IP 时
L2 欧氏距离	空间直线距离	图像特征等

注意：度量方式必须与 Embedding 模型的训练方式一致——模型用什么度量训练就用什么查询，混用召回质量会明显掉。文本场景常做归一化后用内积（等价余弦且算得快）。

HNSW 原理直觉（面试常问）：多层跳表式图结构——顶层稀疏长边负责"快速跳跃"，底层稠密短边负责"精细查找"。查询从顶层贪心走最近邻逐层下降，复杂度约 O(logN)。代价：内存占用高（图结构+全量向量）、构建慢、是近似算法（参数 ef/M 调召回率）。

混合查询：真实业务几乎都要"向量 + 标量条件"——"在部门=电商的文档里语义检索"。实现方式：预过滤（先标量筛再向量搜，过滤率高时快）vs 后过滤（先向量搜再筛，可能不够 K 条）。选型时验证向量库对过滤场景的性能表现。

高级拓展

内存与压缩（大规模必谈）：HNSW 全量浮点向量很吃内存——1 亿条 768 维 float32 ≈ 300GB。压缩手段：PQ 乘积量化（向量切段聚类用质心编号表示，压缩 10~30 倍，召回略降）、SQ 标量量化（float32→int8）、磁盘索引（DiskANN，向量放盘热数据进内存）。

召回率怎么权衡：ANN 不是精确解——用"ground truth 召回率@K"衡量（如 Recall@10 = 98%）。调参三件套：HNSW 的 ef_search（查询时候选队列长度，越大越准越慢）、M（每节点边数）、构建参数。上线标准：压测"目标 P99 延迟下能达到的召回率"，别只看单次查询。

选型决策树：

数据量 < 500 万、团队已有 PG → pgvector（少维护一个组件，事务/备份白嫖）
亿级向量、多租户、高 QPS → Milvus/Qdrant（专用分布式向量库）
强需求是"关键词+向量混合+复杂过滤" → Elasticsearch 8.x+（kNN + BM25 一体）
纯算法实验 → FAISS/HNSWLIB（进程内库，无服务化能力）

Embedding 模型更新是隐蔽大坑：换了 Embedding 模型，全库向量必须全量重算重建——新旧向量不在同一语义空间，混用等于检索失效。所以要给向量集合带"模型版本"，灰度重建后再切流量。

实战场景

场景一：RAG 知识库的向量层选型（设计题）

规模：50 万文档块，QPS 峰值 100，需按部门/时间过滤选型：pgvector（HNSW 索引 + 标量过滤）理由：数据量不大、团队有 PG 运维经验、事务一致性好若未来到亿级 → 迁 Milvus，接口层做好抽象隔离

场景二：加了过滤条件后查询特别慢

// 常见原因：后过滤——先搜 TopK 再过滤，过滤率高时有效结果不足，引擎反复重搜 // 方案： // 1. 改预过滤（带分区的库按分区裁剪：partition key = 部门） // 2. 高过滤率场景用"标量检索 + 向量重排"替代纯向量搜索 // 3. 过滤字段建标量索引，过滤率超过 90% 时效果立竿见影

场景三：升级 Embedding 模型

// 新模型召回评测：抽 200 个真实 query，新旧模型各检索，对比 Hit Rate // 灰度迁移：新集合双写 → 全量重建 → 评测达标 → 切读流量 → 下线旧集合 // 全程两个集合共存，出问题秒回切

面试模拟

Q：HNSW 为什么快？牺牲了什么？

A：多层图 + 贪心搜索，查询从顶层"高速公路"跳到目标邻域再底层精查，复杂度 O(logN)，避免了全量 O(N) 距离计算。牺牲三点：① 内存（图边额外开销 + 常驻向量）；② 近似性（可能错过真实最近邻，用 ef 参数换召回率）；③ 增删有成本（删除节点在图里是标记失效）。数据规模到亿级还要叠加 PQ 量化压内存。

Q：pgvector 和 Milvus 怎么选？

A：看规模与运维预算。pgvector：数据千万级以内、QPS 不高、需要与业务数据同库事务一致（如文档权限表 join）——"少一个组件"就是最大优势。Milvus：亿级向量、高 QPS、多副本、需要 GPU 索引/磁盘索引这些重能力——代价是一套独立分布式系统的运维。我的原则：先 pgvector 起步，把向量层接口抽象好，到瓶颈再迁，迁移成本可控。

Q：Embedding 模型的维度越高越好吗？

A：不是。高维表达力更强，但存储与计算成本线性上涨（1536 维是 768 维的两倍），且维度过高可能出现"维度灾难"——距离区分度反而被稀释。选型看 MTEB/C-MTEB 榜单在目标语言与任务上的实际表现，结合成本选"够用"的模型；检索质量瓶颈常常不在模型维度，而在分块与查询改写。