做 RAG 不懂向量数据库，就像做后端不懂 MySQL

本文是「RAG 面试通关」系列的第 4 篇。 上一篇：第 3 篇《RAG 语义匹配：Embedding 模型到底怎么选？》下一篇预告：第 5 篇《为什么你的 RAG 搜不出答案？面试官让我重写检索逻辑》

“你们 RAG 项目为什么要用向量数据库？直接用 MySQL 存向量不行吗？”

“因为向量数据库更快。”

“快在哪里？它用了什么索引？HNSW、IVF、PQ 分别解决什么问题？FAISS 算不算数据库？”

卡住了。

这就是很多 RAG 面试里的真实情况。

大家会用 LangChain，会连向量库，会写 similarity_search。

但一问到底层原理和选型，就说不清。

做 RAG 不懂向量数据库，就像做后端不懂 MySQL。

不是说你每天都要手写索引算法，而是你至少要知道系统为什么这样设计，出了问题该往哪里排查。

今天这篇，我们就把向量数据库面试高频问题讲透。

01 向量库不是存数组

一、面试官问：向量数据库是什么？

新手回答

向量数据库就是专门存向量的数据库，可以做相似度搜索，RAG 系统里用它来查相关文档。

高手回答

向量数据库是为高维向量数据设计的存储和检索系统。

它不只是把向量存起来，更重要的是通过近似最近邻索引，在大规模向量集合中快速找到和 Query 最相似的 TopK 结果。

一个完整的向量数据库，通常要具备四类能力。

第一，向量存储。

能存储 Embedding 向量，以及对应的文本 ID、元数据和业务字段。

第二，向量索引。

通过 HNSW、IVF、PQ 等算法加速检索。

第三，相似度检索。

支持余弦相似度、点积、欧氏距离等计算方式。

第四，数据库工程能力。

比如增删改查、分区、过滤、多租户、权限、备份、扩容和监控。

所以向量数据库不是“一个能存数组的表”。

它的核心价值是：在可接受的召回损失下，用更低延迟完成大规模相似度检索。

二、为什么不能直接用普通数据库？

严格说，不是不能。

如果你的知识库只有几千条 Chunk，用 PostgreSQL 加 pgvector，甚至用本地 FAISS，都可以跑起来。

问题出现在数据规模和并发上。

假设你有 100 万条文档向量，每条 768 维。

用户每问一个问题，如果暴力计算相似度，就要把 Query 向量和 100 万条向量逐个比较。

一次还能忍，多人并发就很难扛。

普通数据库擅长的是结构化查询，比如：

按用户 ID 查订单。

按时间范围查日志。

按状态筛选记录。

但向量检索的问题是：

给我一个 768 维的向量，在海量向量中找语义最接近的前 10 个。

这类问题需要专门的向量索引。

所以面试时可以这样答：

小规模场景可以用普通数据库加向量扩展，但当数据量、并发和延迟要求上来后，需要专门的向量索引和检索引擎。向量数据库的价值不只是存储，而是高效相似度检索和工程化管理。

三、向量数据库和 Elasticsearch 有什么区别？

这个问题不能简单答成：ES 做关键词，向量数据库做向量。

因为现在 Elasticsearch、OpenSearch 也支持向量检索，并且可以做混合搜索。

更准确的区别是定位不同。

Elasticsearch 的核心优势是全文检索、倒排索引、关键词匹配、日志搜索和复杂过滤。

向量数据库的核心优势是高维向量检索、向量索引优化、向量数据管理和语义召回。

如果你的业务是关键词检索为主，顺带做语义检索，ES 或 OpenSearch 可能就够了。

如果你的业务是大规模 RAG，主要依赖向量召回，并且需要高并发、低延迟、多集合、多租户和向量索引调优，专业向量数据库会更合适。

面试里不要把二者绝对对立。

更好的回答是：

ES 和向量数据库不是谁替代谁，而是擅长的问题不同。生产级 RAG 经常会把 BM25 和向量检索结合起来，用 ES 做关键词召回，用向量数据库做语义召回，最后做结果融合和 Rerank。

02 索引算法别只背名词

四、ANN 是什么？

ANN 是 Approximate Nearest Neighbor，近似最近邻搜索。

它的目标是：不一定找到绝对最相似的结果，但要用更快速度找到足够相似的结果。

为什么需要近似？

因为精确最近邻搜索太慢。

如果每次查询都和全库所有向量算一遍相似度，数据一大，延迟就会爆炸。

ANN 的思想是牺牲一点点精度，换取数量级的速度提升。

RAG 场景里，这个取舍是合理的。

因为后面还有 Rerank 和 LLM 生成，不一定要求向量检索阶段百分百精确。

但要注意，ANN 不是越快越好。

速度、召回率、内存、索引构建时间之间永远有权衡。

五、HNSW 怎么理解？

HNSW 是现在非常常见的向量索引算法。

不用背公式，可以用一个生活化比喻理解。

你要在一个陌生城市找一家店。

如果你从每条小巷开始挨个找，肯定慢。

更聪明的方式是：

先走高速路到目标区域，再走主干道，再走小路，最后找到具体门牌。

HNSW 也是类似。

它构建了一个分层图结构。

上层节点少，连接远，负责快速跳到大概区域。

下层节点多，连接近，负责精细查找。

查询时从高层开始，一层层往下找，最终在底层找到相似向量。

HNSW 的优点是查询快，召回率高，工业界使用广。

缺点是内存占用较大，索引构建相对慢，写入和删除也有维护成本。

面试高频参数有两个。

M：每个节点连接多少邻居。

ef_construction：建索引时搜索候选范围，越大索引质量越好，但构建越慢。

ef_search：查询时搜索候选范围，越大召回率越高，但查询越慢。

你不需要把参数背得很细，但一定要知道它们都在调速度和召回率之间的平衡。

六、IVF 和 PQ 是什么？

IVF：先分桶，再查桶

IVF 可以理解成先给向量空间做聚类。

比如把所有向量分成 1000 个桶。

查询时，不再全库搜索，而是先判断 Query 最接近哪几个桶，再只在这些桶里查。

这样速度会快很多。

IVF 的关键参数是 nprobe，也就是查询时搜索多少个桶。

nprobe 越大，召回率越高，但速度越慢。

IVF 的优点是内存相对友好，适合大规模数据。

缺点是如果分桶不好，或者 Query 落在边界附近，可能漏掉真正相关的向量。

PQ：把向量压缩

PQ 是 Product Quantization，乘积量化。

它的核心作用是压缩向量，减少存储和内存占用。

比如原来一个向量需要用很多 float 存储，PQ 会把它拆成多个子空间，再用码本表示，从而大幅压缩。

代价是会损失一部分精度。

所以 PQ 常用于超大规模向量库，或者内存成本特别敏感的场景。

面试时可以这样说：

HNSW 更适合追求高召回和低延迟但内存充足的场景。IVF 更适合大规模分桶检索。PQ 主要解决存储和内存压缩问题，通常会和 IVF 等方法组合使用。

七、TopK 应该怎么设置？

TopK 是向量检索返回的候选数量。

很多新手会直接设成 3 或 5。

这在 Demo 里可以，但生产里经常不够。

因为向量检索是粗召回阶段。

粗召回的目标不是一步到位给大模型答案，而是尽量把可能相关的候选找回来。

如果 TopK 太小，正确 Chunk 一开始就没进来，后面 Rerank 再强也救不了。

如果 TopK 太大，会带来更多延迟、更多重排成本、更多上下文筛选压力。

常见做法是：

召回阶段 TopK 取 20 到 100 之间。

Rerank 后再选 TopN，比如 3 到 8 个，送给大模型。

具体值要看知识库规模、Chunk 大小、问题复杂度、延迟要求和模型上下文窗口。

面试时可以记住一句话：

TopK 不是越大越好，也不是越小越好。它是召回率、延迟、成本和上下文质量之间的平衡。

八、相似度计算怎么选？

常见有三种。

Cosine Similarity

余弦相似度，看两个向量方向是否接近。

它不太关心向量长度，更关注语义方向。

文本语义检索里非常常用。

Dot Product

点积，把两个向量对应位置相乘后求和。

如果向量已经做了归一化，点积和余弦相似度的排序结果通常一致。

如果没归一化，点积会受到向量长度影响。

Euclidean Distance

欧氏距离，看两个点在空间中的直线距离。

距离越小越相似。

更常见于一些特征空间距离有明确意义的场景。

面试里最重要的一句话是：

相似度计算方式要和 Embedding 模型训练方式、向量是否归一化、向量数据库索引配置保持一致。

不要随便换。

03 权限过滤才是企业级

九、Metadata Filter 怎么做？

企业级 RAG 里，向量检索很少是“全库随便搜”。

经常要加过滤条件。

比如：

只查某个部门的文档。

只查用户有权限的文档。

只查最近一年更新的文档。

只查某个产品线的知识库。

这就是 Metadata Filter。

难点在于，过滤和向量检索的顺序会影响效果。

先过滤再检索

优点是结果一定满足权限和业务条件。

缺点是过滤后数据太少时，向量索引优势可能下降。

先检索再过滤

优点是向量检索流程简单。

缺点是可能 TopK 里大部分被过滤掉，最后结果不够。

检索中融合过滤

更好的系统会在向量索引搜索过程中结合过滤条件。

这对向量数据库实现要求更高，也是专业向量库的重要能力。

面试时可以这样答：

Metadata Filter 不是简单加 where 条件。要考虑过滤选择性、权限安全、召回数量和索引执行方式。企业级 RAG 里，权限过滤必须在返回给模型前严格生效，不能只靠 Prompt 约束。

十、Milvus、Qdrant、Weaviate、Pinecone、FAISS 怎么选？

重点提醒：

FAISS 不是完整向量数据库。

它更像一个高性能向量索引库。

如果面试时把 FAISS 和 Milvus、Qdrant 完全并列成同类数据库，会显得不够准确。

十一、多租户和权限怎么做？

企业级 RAG 面试里，这个问题非常加分。

多租户常见有三种方式。

第一，一个租户一个 Collection。

隔离性好，但租户多了管理成本高。

第二，多个租户共用 Collection，通过 tenant_id 做过滤。

资源利用率高，但权限过滤必须非常严谨。

第三，大租户独立，小租户共享。

这是比较折中的方案。

权限控制要注意一点：

不能把用户无权访问的 Chunk 检索出来，再指望大模型不说。

正确做法是在检索阶段就加权限过滤，确保进入上下文的内容都是用户有权看的。

如果权限非常复杂，可以把权限系统放在业务层，向量库只负责存文档 ID 和必要元数据，最终由业务服务做权限校验。

04 项目落地和追问

十二、项目里怎么落地向量数据库？

可以按这个流程回答。

第一步，评估数据规模。

几万条、百万条、千万条，对架构选择完全不同。

第二步，确定检索模式。

只做向量召回，还是向量加 BM25 混合召回。

第三步，选择索引。

内存充足、追求低延迟，可以优先考虑 HNSW。

超大规模或内存敏感，可以评估 IVF、PQ 或量化方案。

第四步，设计元数据。

包括 document_id、chunk_id、source、title_path、tenant_id、permission、updated_at 等。

第五步，做灰度和评估。

看 Recall@K、查询延迟、P95、P99、索引构建时间、内存占用。

第六步，做可观测性。

记录每次查询的 Query、TopK、相似度分数、过滤条件、最终回答和用户反馈，方便排查 bad case。

十三、面试官追问清单

1. 向量数据库和普通数据库的区别是什么？
2. 小规模 RAG 是否一定要用专业向量数据库？
3. Elasticsearch 能不能做向量检索？
4. ANN 为什么是近似而不是精确？
5. HNSW 的基本原理是什么？
6. HNSW 的 ef_search 调大有什么影响？
7. IVF 和 HNSW 怎么选？
8. PQ 解决什么问题？
9. TopK 怎么设置？
10. 余弦相似度和点积有什么区别？
11. Metadata Filter 有哪些实现方式？
12. FAISS 为什么不算完整数据库？
13. 多租户和权限过滤怎么设计？
14. 向量库查询慢，你怎么排查？

总结

最后总结一下。

向量数据库不是 RAG 里的“存储插件”，而是语义检索的核心基础设施。

面试时记住五句话。

第一，向量数据库的核心价值是大规模相似度检索，不只是存向量。

第二，ANN 用一点精度损失换取查询速度，常见算法包括 HNSW、IVF、PQ。

第三，HNSW 查询快、召回高，但更吃内存；IVF 适合分桶检索；PQ 主要解决压缩问题。

第四，ES、向量数据库、FAISS 定位不同，不能简单混为一谈。

第五，企业级 RAG 必须考虑 Metadata Filter、多租户、权限和可观测性。

下一篇我们讲 RAG 面经系列第 5 篇：召回策略。

因为向量数据库只解决“怎么查得快”，但真正的 RAG 检索效果，还取决于你怎么设计召回策略。

本文是「RAG 面试通关」系列的第 4 篇。下一篇预告：为什么你的 RAG 搜不出答案？面试官让我重写检索逻辑，记得星标不走丢。

最近我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF，我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。