⭐️AI 应用开发面试和 AI Coding 实战相关的内容目前正在持续更新中：https://javaguide.cn/ai/ 。
前段时间面某大厂的时候，面试官问我：“你们 RAG 系统的向量检索怎么做的？”，我说：“用 MySQL 存 Embedding，查询时遍历计算相似度。”
空气突然安静了五秒。我看到面试官的嘴角抽了一下，才意识到问题大了——当时我们知识库有 50 多万条 Chunk，每次查询都要全表扫描，平均响应时间 3 秒+，用户早就跑光了。
面试被挂后才懂：这叫“暴力搜索”，而生产级方案应该是向量数据库 + ANN 索引。
段子归段子，向量数据库确实是当下 RAG 应用的基础设施，也是 AI 应用开发面试的高频考点。今天 Guide 分享几道向量数据库相关的面试题，希望对大家有帮助：
RAG（Retrieval-Augmented Generation）的核心是“语义检索”——把文档和用户问题都转成高维向量（Embedding），然后找最相似的 Top-K 片段作为 LLM 上下文。传统关系型数据库（MySQL、PostgreSQL 原生）或全文搜索引擎（ES 的 BM25）无法高效完成这件事，所以必须引入向量数据库（或带向量扩展的数据库）。
Embedding 通常是 768~3072 维的稠密向量，传统数据库只能用 = 或 LIKE 做精确匹配，无法计算“余弦相似度 / 内积 / 欧氏距离”。
暴力搜索：如果强行用 SQL 遍历全表计算相似度，复杂度是 O(n)。以 100 万条 1024 维向量为例：
秒级延迟——对于需要实时响应的问答系统完全不可接受。
ANN 近似检索：向量数据库专为最近邻搜索（ANN, Approximate Nearest Neighbor）设计，通过图导航或空间划分大幅减少距离计算次数，将检索延迟降至毫秒级。
| 指标 | 暴力搜索 | ANN 索引检索 |
|---|---|---|
| 时间复杂度 | O(n) | 图索引 ≈ O(log n)，聚类索引 ≈ O(nprobe × n/nlist) |
| 100 万向量延迟 | 秒级 | 毫秒级 |
| 召回率 | 100% | 95-99% |
| 速度提升 | 基准 | 100-200 倍 |
注：上表延迟为数量级描述，实际性能因硬件规格、并发负载、索引参数（如
ef_search、nprobe）而异，建议参考 ann-benchmarks.com 在目标环境验证。
用不到 5% 的召回率损失，换来 100 倍以上的速度提升——这就是索引的价值。
RAG 知识库动辄几十万 ~ 亿级 Chunk，向量数据库支持亿级向量持久化 + 增量更新 + 分片，而传统 DB 存向量后基本无法扩展。
| 检索方式 | 原理 | 局限性 |
|---|---|---|
| BM25 关键词 | 字面匹配，基于词频统计 | 遇到同义词/改写就失效（“退货” vs “退款流程”） |
| 向量语义搜索 | Embedding 捕获语义相似性 | 理解同义词、上下文、隐含意图 |
文档的 Chunking 策略（切分规则与重叠度）与 Embedding 模型共同决定了语义召回的理论上限，而向量数据库负责在可接受的延迟内把这个上限兑现出来。
生产级必备能力：
WHERE category='Java' AND version>='v2'）+ 向量相似度联合查询REINDEX 或 vacuuming 机制清理，并监控实际召回率向量索引算法是向量数据库的核心，它的核心任务是解决一个数学难题：如何在海量的高维向量中，极速地找到和给定查询向量最相似的那几个。
它的本质，是一种空间划分和数据组织的艺术。如果没有索引，我们要找一个相似向量，就必须把数据库里所有的向量都比较一遍，这叫暴力搜索。在百万、亿级的数据量下，这种方法的延迟是灾难性的。
向量索引的目标，就是通过预先组织好数据，让我们在查询时能够智能地跳过绝大部分不相关的向量，只在一个很小的候选集里进行精确比较。
用生活化的比喻来说：
在实践中，向量索引算法主要分为两大类：
当我们谈论向量索引时，绝大多数时候谈论的都是 ANN 算法。
选择并调优一个合适的 ANN 索引，是决定 RAG 或向量搜索系统最终性能和成本的关键，带来的性能提升可以达到百倍甚至千倍以上。
在向量数据库与 RAG（检索增强生成）应用中，索引算法直接决定了系统的召回率、响应延迟和资源消耗。
这里需要区分两个层级概念：
| 层级 | 示例 | 说明 |
|---|---|---|
| 向量数据库 | Milvus、Qdrant、pgvector | 负责向量存储、检索和管理的完整系统 |
| 其支持的索引算法 | HNSW、IVF-PQ、IVFFLAT、Flat | 决定检索性能与召回率的内部实现 |
主流索引算法一览：
| 算法名称 | 原理机制 | 核心优势 | 主要劣势 | 适用数据规模 |
|---|---|---|---|---|
| Flat（暴力搜索） | 遍历所有向量计算距离 | 100% 准确无损 | O(n) 复杂度，查询极慢 | < 10 万 |
| HNSW（图索引） | 分层导航的小世界图 | 查询极快，召回率极高 | 内存消耗巨大，构建耗时 | 10 万 - 1000 万 |
| IVFFLAT（倒排聚类） | 聚类 + 倒排索引桶 | 内存效率高，构建快 | 需前置训练，召回率略低 | 1000 万 - 1 亿 |
| IVF-PQ（乘积量化） | 聚类 + 向量极致压缩 | 支持海量数据，开销极低 | 精度损失较大 | > 1 亿 |
| IVF_RABITQ | 聚类 + 随机旋转比特量化 | 内存占用极低，召回率优于 PQ | 较新算法，生态支持有限 | > 1 亿 |
关于 IVF_RABITQ：这是 2024 年提出的新一代量化算法，核心创新是 Random Rotation（随机旋转）+ Bit Quantization（比特量化）。相比传统 PQ 将向量切成子向量再分别聚类，RABITQ 先对向量做随机旋转使各维度分布更均匀，再将每个维度量化为 1 bit（仅保留符号位）。这种设计在保持高召回率的同时，将内存占用压缩到原始向量的 1/32，且距离计算可高效使用位运算加速。在 Milvus 2.5+ 中已作为
IVF_RABITQ索引类型提供。
这里以 《SpringAI 智能面试平台+RAG 知识库》项目为例。
在我们的项目中，使用的是 PostgreSQL 的 pgvector 扩展，并配置了 HNSW 索引。
为什么选择 HNSW？ 因为在百万级数据规模下，HNSW 在检索速度、召回率和内存占用之间取得了最佳平衡。
我们可以把 HNSW 理解成一个多层高速公路网络：
核心机制：
level = floor(-ln(random()) * mL) 决定，其中 mL 是层级乘数。这使得越高的层级节点数指数级递减，形成“金字塔”结构。这种“由粗到精”的查找方式，能够极快地定位到最近邻向量，而不需要像暴力搜索那样比较每一个点。
HNSW 的本质是近似最近邻（ANN）算法，意味着它为了追求极致速度，无法保证 100% 的召回率。但在实践中，通过调整参数，召回率可以达到 99% 以上，对于 RAG 应用完全足够。
调优参数：
m 值越大，图越密集，召回率越高，但会增加构建时间和内存消耗。扩展性考虑：
HNSW 是非常耗内存的索引。如果未来数据规模增长到千万甚至亿级，或者对写入吞吐量有更高要求，HNSW 的内存占用和构建成本可能成为瓶颈。
届时可以考虑切换到 IVFFLAT 索引。IVFFLAT 基于倒排索引思想，通过将向量空间聚类成多个桶来缩小搜索范围。或者引入 Milvus 等专业向量数据库，它们在分布式、大规模场景下提供更专业的解决方案。
过滤行为注意：
pgvector 0.5+ 的 HNSW 索引在执行元数据过滤时，采用混合过滤策略：过滤条件在索引扫描期间并行评估，而非纯后过滤。但若过滤条件较严格，仍可能导致最终结果远少于 Top-K 预期。
例如，查询“返回 10 条相似文档中 category='Java' 的记录”，若候选集中只有 3 条满足条件，则仅返回 3 条。解决方案包括：
ef_search 或 LIMIT，让更多候选进入过滤阶段CREATE INDEX ... WHERE category = 'Java'，但需为每个常见过滤条件创建独立索引这两者的核心区别在于：一个是利用“图”的连通性寻找邻居，一个是利用“聚类”缩小搜索范围。
HNSW（图索引）
IVFFLAT（倒排聚类）
nlist 参数和硬件）| 特性 | HNSW（图索引） | IVFFLAT（倒排聚类） |
|---|---|---|
| 底层原理 | 层次化小世界图结构 | 聚类 + 倒排桶结构 |
| 查询速度 | 极快 | 中等 |
| 内存消耗 | 极高（原始向量 + 图连接指针） | 中等（原始向量 + 质心），低于 HNSW |
| 构建速度 | 慢（需逐个节点插入） | 快 4-32 倍（依赖 K-Means 训练） |
| 数据动态性 | 增量添加方便，但删除需定期 REINDEX | 建议全量训练，否则精度下降 |
| 适用规模 | 10 万 - 1000 万 | 1000 万 - 1 亿 |
如何选择？
对于向量数据库的选型，适合项目的才是最好的，没有银弹！
第一类：传统数据库扩展
第二类：搜索引擎演进
第三类：原生专业向量数据库
第四类：云托管的向量数据库服务
这里以 《SpringAI 智能面试平台+RAG 知识库》项目为例。本项目需要同时存储结构化数据（简历、面试记录）和向量数据（文档 Embedding）。
方案对比：
| 方案 | 优点 | 缺点 | 适用规模 |
|---|---|---|---|
| PostgreSQL + pgvector | 一套数据库搞定，运维简单 | 百万级以上性能下降明显 | < 100 万向量 |
| PostgreSQL + Milvus | 向量检索性能更好 | 多一个组件，运维复杂度增加 | 100 万 - 10 亿 |
| Pinecone / Zilliz Cloud | 全托管，低运维 | 成本高，数据在第三方 | 任意规模 |
选择 pgvector 的理由：
-- pgvector 余弦相似度搜索示例
-- <=> 是余弦距离运算符（0 = 完全相同，2 = 完全相反）
-- 余弦相似度 = 1 - 余弦距离
SELECT content, 1 - (embedding <=> $1) as cosine_similarity
FROM vector_store
WHERE metadata->>'category' = 'Java'
ORDER BY embedding <=> $1 -- 按距离升序，越小越相似
LIMIT 5;
-- ⚠️ 关键前提：查询时使用的距离运算符必须与创建 HNSW 索引时指定的
-- operator class（例如 vector_cosine_ops）严格保持一致，否则查询将
-- 无法命中索引，直接退化为全表扫描。
-- 验证方式：EXPLAIN ANALYZE 检查执行计划是否包含 Index Scan。
PostgreSQL 最大的优势，也是它在 AI 时代甩开对手的“王牌”，就是其强大的可扩展性。开发者可以在不修改内核的情况下，为数据库安装各种功能插件：
tsvector（基础需求），或 pg_bm25 扩展（高级需求）这种“一站式”解决能力意味着许多项目不再需要依赖 Elasticsearch、Milvus 等外部中间件，仅凭一个 PostgreSQL 即可满足多样化需求，从而简化技术栈。
注意：MySQL 8.x 系列（包括 8.4 LTS）无官方向量支持。MySQL 9.0（2024 年 7 月发布）才正式引入 VECTOR 数据类型及 STRING_TO_VECTOR、VECTOR_TO_STRING 等向量函数，但目前尚不支持向量索引（ANN），仅能做暴力计算。生态成熟度和生产验证案例远少于 pgvector。如果项目已深度绑定 MySQL 生态，可考虑 MySQL 9.0+ 基础方案（小规模）或 MySQL + 外部向量库的组合。
关于 MySQL 和 PostgreSQL 的详细对比，可以参考我写的这篇文章：MySQL vs PostgreSQL，如何选择？。
上面的内容摘自我的星球实战项目教程： 《SpringAI 智能面试平台+RAG 知识库》。内容安排如下（已经更完，一共 13w+ 字）
Spring AI 和 RAG 面试题两篇加起来就接近 60 道题目，主打一个全面！
项目地址 （欢迎 Star 鼓励）：
完整代码完全免费开源，没有 Pro 版本或者付费版！
向量数据库是 RAG 系统的核心基础设施，选择合适的向量索引算法和数据库方案，直接决定了系统的性能和成本。通过本文，我们系统梳理了向量数据库的核心知识：
核心要点回顾：
面试高频问题：
学习建议：
向量数据库选型和索引调优，直接决定 RAG 系统能不能在生产环境站稳脚跟——选错了就是”检索慢、召回差、成本炸”三连。
AI Agent 知识体系：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。