向量数据库

它是什么

向量数据库是面向高维向量做存储、索引与相似度查询的数据系统。它把向量和它的元数据（原文、来源、部门、生效时间）绑在一起，并提供近似最近邻搜索。

它是一个底座，不是一条检索链路：它不会帮你把问题改成好查的查询，不会帮你判断哪些候选真的相关，也不会替你决定该取几块。它的职责边界很窄——存得住、查得快、过滤得对。

为什么需要它

因为逐个比较太慢。要在一个向量集合里找最相近的几个，朴素做法是把查询向量和每一条都比一遍——数据量一大，这个成本按线性增长，撑不住线上延迟。

专用索引的价值就在这里：它在速度、内存和召回质量三者之间做取舍，让「从大规模知识集合里快速拿到语义相近的候选」变得可行。注意这句话里有取舍——近似索引会漏，这是它的工作方式，不是 bug。

它如何工作

链路是：文档切片经嵌入模型转成向量 → 写入索引 → 查询用同一个（兼容的）模型编码 → 在向量空间里做相似度搜索 → 按元数据过滤 → 返回候选。

四个机制点值得记住：

• 索引是近似的。 为了快，多数索引只找「很可能是最近的那几个」，而不是数学上严格的最近邻。所以召回率是一个需要单独测量、单独调参的指标。
• 元数据过滤与向量搜索要一起生效。 「只看他可访问的部门」这种约束必须作用在召回阶段，而不是取回来再筛——否则你会先拿到一批无权内容再丢掉，既浪费又危险。
• 查询与文档必须同源编码。 两边用不同嵌入模型，向量空间不对齐，算出来的距离没有意义。这是最难从结果上看出来的一类错误。
• 向量只是字段之一。 权限、时效、版本这些仍然是普通数据，需要普通的过滤与索引能力。所以「向量库能不能做元数据过滤」和「它向量查得快不快」是同等重要的选型问题。

必须澄清的误会

向量数据库 ≠ 嵌入模型。 两者常被当成一回事，因为产品介绍里总是一起出现。分工是清楚的：一个是把内容变成向量的表示方法，一个是把这些向量存起来并查得快的基础设施。一个决定『像不像』，一个决定『找得快不快』。 症状也因此不同——嵌入选错，结果会系统性跑偏（领域术语分不开）；库选错，结果通常是对的，只是慢或者贵。

向量数据库 ≠ 检索。 向量库是检索链路里的一个零件，不是整条链路。完整的检索还可以包含查询改写、关键词召回、混合排序、重排。所以「检索效果不好」这件事，只盯着向量库看往往找不到根因——先看切片，再看有没有关键词路，最后才轮到库。

它不是「什么数据都往里塞」。 精确交易、唯一约束、复杂聚合、事务一致性，这些是关系型数据库的地盘。把订单数据搬进向量库去做「相似订单推荐」可以，但让它承担订单状态的真值，会立刻踩到一致性问题上。

它也解决不了权限。 权限是查询阶段的过滤条件，需要你自己定义规则并确保它在召回时生效；向量库只是执行你的过滤，不会替你判断谁该看到什么。

真实例子

一个企业知识库为每条制度片段存下：向量、文档 ID、所属部门、生效日期、版本号。

员工提问时，查询流程是先过滤再搜索：先把范围收窄到「他有权访问的部门」且「当前生效的版本」，再在这个子集里找语义相近的片段。

这个顺序不能反。反过来（先搜全库、再过滤结果）会带来两个后果：一是召回阶段被大量无权内容占满，真正该看到的那一条可能因为名额被挤掉而漏掉；二是无权内容已经进入了处理流程，多了一次不该发生的暴露。

这就是「权限要在召回阶段生效」这句话的具体含义。

什么时候适合与不适合

适合：非结构化内容的语义召回与相似项搜索——文档问答、相似案例推荐、去重、聚类。判断标志是「查询靠意思匹配，而不是靠字段相等」。

不适合：需要精确匹配、强一致或复杂聚合的场景。规模很小时也别急着上——几千条以内，一个简单的向量索引或直接内存计算往往就够了，先验证价值再谈架构。引入一个独立系统是有运维成本的：备份、权限、版本升级、监控，一样都少不了。

选型时要看的顺序建议是：过滤能力 → 召回质量 → 延迟与成本 → 运维复杂度。把它当「向量搜索」单独选型，是常见的踩坑方式。

亲自试一下

用 100 个真实片段建一个最小索引，然后写三组查询，每组 5 条：

1. 语义提问——「怎么退掉买错的」这类，靠意思匹配。
2. 编号查询——订单号、条款号这类，必须逐字命中。
3. 带权限的查询——同一个问题，用两个不同权限的账号各问一次。

全程约 20 分钟。观察点是第三组：两个账号拿到的片段是否真的不同。如果一样，说明权限过滤没有在召回阶段生效——这是最该在演示阶段就发现、却最常在演示阶段被跳过的一类问题。

顺带记下第一组的延迟和第二组的召回情况：第一组通常表现好，第二组通常表现差。第二组的失败，就是「该上混合检索」的信号。

接下来学什么

向量数据库是第 3 站 给知识 · 怎么让它知道你家的资料 的存储底座，位置在切片与检索之间。

顺着这条链路走：上游是 文档切片（决定什么内容成为一个向量）与 嵌入（决定这个向量怎么算出来）；下游是 检索（完整的候选召回过程）与 重排（候选怎么排序）、Top-K（取几块）。

如果你的第二组「编号查询」失败了，直接读 混合检索——那是标准解法；如果权限过滤不生效，去看 RAG 词条里「权限贯穿两段」那段。

来源与修订

系统定义、能力范围与选型维度参考 AWS 的 Overview of vector databases 指南；切片 → 嵌入 → 索引 → 查询这条链路，以及「元数据过滤与租户隔离在查询阶段共同生效」的做法，参考同一家的 Custom retrievers for RAG 指南（均访问于 2026-09-19）。

一处需要点明的：本文不评估任何具体产品。 这类系统迭代很快，把某个产品的特性写进概念词条，会迅速变成过期信息；真正稳定的是「过滤能力 / 召回质量 / 延迟成本 / 运维复杂度」这四项评判维度。

修订日期 2026-09-19：本条由生成模板改为决策页——补「必须澄清的误会」一节（对嵌入、对检索），把「权限必须在召回阶段生效」写成可操作的顺序约束，去掉生成期的引用标记，补 boundaries 与 minAction。