向量数据库选型：三个关键决策

向量数据库是三个决策，不是一个产品

1. 索引。Flat（精确、暴力搜索）、IVF（先聚类再搜索若干聚类）或 HNSW（可导航的小世界图）。这是唯一会影响结果的决策，因为除 Flat 外的所有方式都是近似的——而近似意味着一个召回率数字，你选择是否去测量它。

2. 度量。Cosine、dot product 或 L2。不可互换：如果你的 embedding 已归一化，cosine 和 dot product 排序结果完全相同，L2 也一样——直到单调变换。如果未归一化，dot product 偏好长向量，这通常意味着它偏好长文档。

3. 存哪里。进程内（FAISS、Chroma）、服务器（Qdrant、Weaviate、Milvus）或你现有的数据库（pgvector）。Arc Rector 默认使用 Qdrant，Apache-2.0 许可，因为它作为单个容器运行，且其过滤功能不是事后补救。

没人会刻意调整的那个数字

每个 ANN 索引都有一个在召回率和延迟之间权衡的旋钮——IVF 中的 nprobe，HNSW 中的 ef_search。默认值由库选择，它决定了你实际看到多少个真正的最近邻。

ef_search=16    recall@10 = 0.71    fast
ef_search=64    recall@10 = 0.94
ef_search=256   recall@10 = 0.995   slow

在自己的数据上用 flat 索引测量。一次对几千个向量的穷举搜索只需几分钟，但这就是"检索没问题"和"检索悄悄丢失了四分之一的正确块"之间的区别。

这个测量还能告诉你 RAG 问题究竟是检索问题还是生成问题——没有它，团队会花几周时间调整 prompt 来修复一个召回率 bug。

过滤是抽象泄漏的地方

"查找相似的块，但只从这个租户"是最常见的真实查询，也是最容易击穿 naive 方案的那个。搜索后过滤：文档少的租户什么都返回不了，因为 top-k 结果完全来自别人的数据。搜索前过滤：你就在对过滤后的子集做暴力扫描。

好的引擎将过滤集成到图遍历中。值得知道你的引擎是哪种，因为故障模式是静默的、以租户为中心的。

这个层级解决不了什么

向量数据库返回的是"近的"内容。近不等于相关，而 embedding 决定了"近"意味着什么——这对应 Level 5，是比这个层级杠杆更大的那层。如果你的检索很差，换数据库是清单上最不可能的解决方案。

Level 5 是 embedding 和重排序，问题变成"相似"本来到底应该意味着什么。

整个堆栈，九个层级，全部可免费自托管：https://dev48.infy.uk/arcrector.php