Vector Database (向量数据库)

核心 · Key Idea

一句话：向量数据库 = 一个专门存向量 + 极快查近邻的数据库。它解决的核心问题是：在百万、上亿条向量中毫秒级找出和某个向量最像的 K 条。

是什么#

普通 SQL 库做不了 —— 「找 1536 维向量里余弦相似度最高的 5 条」算下来要扫全表，百万级就崩了。向量库用近邻索引 (HNSW / IVF / DiskANN) 把它降到 O(log N)：

-- pgvector 的写法
SELECT id, content
FROM docs
ORDER BY embedding <=> $query_vector
LIMIT 5;

<=> 是 cosine 距离 —— 由索引加速，毫秒返回。

打个比方 · Analogy

普通 DB 像电话簿 —— 按名字（key）找记录。
向量 DB 像地图 + 雷达 —— 给一个坐标，雷达扫一扫附近最近的几个点。

ANN Index近似近邻索引

HNSW / IVF / DiskANN 等。牺牲一点点准确率换巨大速度。

Metric距离度量

Cosine / Euclidean / Dot product —— 必须和 Embedding 模型训练时一致。

Filter元数据过滤

向量检索时同时按字段过滤（user_id / 时间 / 类别）。

Hybrid Search混合检索

向量 + 关键词 (BM25) 一起，再 rerank。

索引把高维空间「分区 + 邻接图」存起来 —— 查询时只扫局部就够了。

先 pgvector 试试：万级到千万级 pgvector 完全够用，别一上来上 Milvus 集群。
Metric 必须对齐：Embedding 模型训练用 cosine 就用 cosine。错了召回掉一大截。
元数据 + 向量一起存：每条向量绑定 {doc_id, chunk_idx, user_id, source, time}。查询时按需过滤。
批量写入：一次写 1 条 vs 一次写 1000 条，建索引速度差几十倍。
监控召回：定期跑「黄金问题集」测召回率，升级 embedding / 调 chunk 大小后立刻看效果。

向量 DB

**按语义找**。
懂同义、懂模糊。

搜索引擎 (ES)

**按字面找** (BM25)。
精确实体强。

混合检索 = 二者都做 → 最稳的 RAG 召回。