68 lines
5.0 KiB
Markdown
68 lines
5.0 KiB
Markdown
---
|
||
id: ai.vector-db.interview
|
||
title: 向量数据库面试题
|
||
type: interview
|
||
domain: ai
|
||
stack: [vector-db]
|
||
tags: [向量数据库, HNSW, pgvector, 面试]
|
||
level: intermediate
|
||
related: [ai.vector-db.ann-metrics, ai.vector-db.selection-pgvector, ai.rag.interview]
|
||
week: [5, 6, 16]
|
||
---
|
||
|
||
# 向量数据库面试题
|
||
|
||
## 基础
|
||
|
||
### 【基础】向量数据库解决什么问题？和传统数据库有什么区别？
|
||
|
||
**参考答案**：解决“找出和查询向量最相似的 k 个向量”的问题。传统数据库按精确值或范围查询（B+ 树等），向量检索按相似度排序，需要专门的近似最近邻索引（HNSW、IVF）在速度和召回率之间取舍。现在很多传统数据库也通过扩展支持向量（pgvector、ES 的 kNN）。
|
||
|
||
**追问**：数据量只有几万条，需要向量数据库吗？——不需要专门的向量数据库，内存暴力检索或 pgvector 精确检索就够快，而且结果精确。
|
||
|
||
### 【基础】余弦相似度、内积、欧氏距离有什么区别？
|
||
|
||
**参考答案**：余弦只看方向；内积同时受长度影响；欧氏距离是空间中两点的距离。向量归一化后三者的排序结果一致，此时内积计算最快。应该使用嵌入模型推荐的度量。
|
||
|
||
**追问**：pgvector 中 `<#>` 返回什么？——负内积，所以 `ORDER BY embedding <#> q` 是内积从大到小。
|
||
|
||
### 【基础】什么是 ANN？召回率怎么算？
|
||
|
||
**参考答案**：近似最近邻，用索引结构换取速度，结果不保证精确。召回率 = 近似检索的 top-k 和精确检索的 top-k 的重合数 / k。上线前要用自己的数据测试。
|
||
|
||
**追问**：召回率 0.95 够不够？→ 取决于业务：RAG 后面还有重排和生成，0.95 通常足够；关键是要在自己的数据上测出召回率和延迟的关系，再按延迟预算选参数。
|
||
|
||
## 进阶
|
||
|
||
### 【进阶】HNSW 的原理和关键参数？
|
||
|
||
**参考答案**：多层图结构，上层稀疏、下层稠密。查询从最上层的入口点开始，贪心地走向更近的邻居，逐层下降，在最底层用大小为 `ef_search` 的候选队列搜索。参数：`M` 每个节点的连接数（大 → 召回高、内存大），`ef_construction` 建索引时的候选数（大 → 索引质量高、建索引慢），`ef_search` 查询时的候选数（大 → 召回高、延迟高）。
|
||
|
||
**追问**：HNSW 和 IVF 怎么选？——HNSW 查询性能和召回通常更好、支持增量插入，但内存大；IVF 建索引快、省内存（配合 PQ 更省），需要先有数据训练，数据分布变化后要重建。
|
||
|
||
### 【进阶】带过滤条件的向量检索有什么问题？
|
||
|
||
**参考答案**：近似索引先找全局近邻再过滤，满足条件的数据占比很小时，结果可能不足 k 个。解决：数据库的过滤遍历能力（pgvector 0.8 的迭代扫描、Milvus 的标量过滤）、增大候选数、按租户分区、小数据量直接精确检索。
|
||
|
||
**追问**：pgvector 0.8 的迭代扫描是什么？→ 开启 `hnsw.iterative_scan` 后，如果过滤后结果不足，索引会继续往下扫描更多候选，直到凑够结果或达到扫描上限（`hnsw.max_scan_tuples`），参数以官方文档为准。
|
||
|
||
### 【进阶】更换嵌入模型要怎么做？
|
||
|
||
**参考答案**：新旧模型的向量空间不兼容，必须全量重新嵌入。做法：新增列 / 新集合存新向量，后台回填，用评测集对比效果，切换读路径，保留回滚能力，最后清理旧数据。记录每个块使用的模型版本。
|
||
|
||
**追问**：切换期间新文档写入怎么办？→ 双写：切换期间新文档同时生成新旧两种向量，回填只处理存量；切换读路径后再停止写旧向量。
|
||
|
||
## 场景题
|
||
|
||
### 【场景题】SaaS 产品多租户共用向量表，怎么防止数据串租户？
|
||
|
||
**参考答案**：数据访问层统一封装检索函数，`tenant_id` 必填；数据库层启用行级安全（RLS）兜底，应用使用非表所有者的角色连接，每个事务设置租户变量（连接池下必须用事务级）；测试用例覆盖跨租户访问；日志审计。详见[多租户向量索引场景](scenarios/multi-tenant-index.md)。
|
||
|
||
**追问**：大租户和小租户检索性能差别很大怎么办？——分层：大租户单独分区 / 索引，小租户精确检索或开启迭代扫描。
|
||
|
||
### 【场景题】线上向量检索延迟从 50ms 涨到 500ms，怎么排查？
|
||
|
||
**参考答案**：先看是检索本身慢还是嵌入接口慢（分段计时）；检索慢：执行计划是否走了向量索引（运算符类是否匹配）、索引是否能放进内存（`shared_buffers` / 内存不足导致大量磁盘读）、`ef_search` 是否被调大、过滤条件是否导致大量扫描、数据量是否增长、是否有大批量写入在重建索引。对照监控的时间点找变化。
|
||
|
||
**追问**：怎么提前发现这种问题？→ 监控检索 P95/P99 延迟、每次查询扫描的行数、索引大小和内存命中率；给慢查询设置日志阈值；数据量增长到一定程度前做容量评估。
|