向量库扫盲

这篇笔记的目标，不是把向量库当成一个“AI 时代的新中间件名词”简单过一遍，而是把它拆回工程本质：向量库到底在存什么、查什么、快在哪里、为什么 ANN 索引会成为核心，以及它和关系型数据库、搜索引擎、RAG 系统之间到底是什么关系。

这篇内容重点覆盖四件事：一是向量检索的基本计算模型，二是 HNSW / IVF / PQ 这类常见索引的取舍，三是过滤、混合检索、重排、更新删除这些真实线上问题，四是 pgvector、Milvus、Qdrant、Weaviate、Pinecone 这类方案在架构和运维上的差异。它更偏“整体视图 + 原理拆解 + 工程边界”，不是某个单一产品的使用手册。

参考资料：

论文与基础实现：Faiss: A library for efficient similarity search and clustering of dense vectors 、 Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs

官方文档：Milvus Docs - What is a Vector Database 、 Qdrant Documentation 、 Weaviate Concepts 、 Pinecone Learn - Vector Databases 、 pgvector README 、 Elasticsearch Vector Search

[TOC]

一、先把问题摆正：向量库到底解决什么问题

如果只保留一句核心定义，可以概括为：

它解决的不是“按字段精确查数据”，而是“按语义相似度查近邻”。

传统数据库最擅长的是下面这类查询：

• 主键等值查询
• 范围过滤
• 聚合统计
• 事务更新
• 基于结构化字段的索引访问

搜索引擎最擅长的是：

• 关键词召回
• 倒排索引
• BM25 相关性排序
• 布尔条件过滤

而向量库最擅长的是另一类问题：

• 这段文本和哪些文本“表达的意思接近”
• 这张图片和哪些图片“视觉语义相近”
• 这个用户兴趣向量和哪些商品向量“距离最近”
• 这个问题最可能对应哪几段知识片段

所以它的核心任务不是“存一堆浮点数”，而是：

1. 存储高维向量以及它对应的原始数据和元数据
2. 在高维空间里快速做近邻搜索
3. 在语义检索和过滤约束之间做平衡
4. 在可接受延迟内尽量保持较高召回率

这也是为什么向量库会在 RAG、推荐系统、图像检索、相似内容去重、异常检测这些场景里集中出现。

向量库不是 Embedding 模型

这一点很容易混淆。

• Embedding 模型负责把文本、图片、音频编码成向量
• 向量库负责存储、索引、过滤、检索、排序和返回结果

前者决定“语义空间长什么样”，后者决定“这个语义空间怎么查得快、查得准、查得稳”。

如果 embedding 质量很差，向量库再强也救不了召回质量；但如果 embedding 质量不错，没有合适的向量索引，查询延迟和成本又会失控。两者是上下游关系，不是替代关系。

向量库也不是 RAG 的全部

很多文章会把“RAG = Embedding + 向量库”写成一个简化公式，这能帮助入门，但不够准确。

一个完整的 RAG 系统通常至少包含：

• 文档清洗与切块
• embedding 生成
• 向量索引和元数据存储
• 查询改写
• 检索召回
• 重排
• 上下文压缩
• 提示词组织
• 大模型生成

向量库只负责其中“检索底座”的一部分，而且还不是全部检索逻辑。真正影响最终回答质量的，常常不是只把 top k 查出来，而是：

• chunk 是否切得合理
• 元数据过滤是否正确
• 是否做 hybrid search
• 是否做 rerank
• 是否控制上下文冗余

所以理解向量库，最好把它看成：

RAG 检索阶段的核心基础设施，而不是整个 RAG 本身。

二、向量检索的基本计算模型

什么是向量

向量可以简单理解成一个长度固定的实数数组，例如：

1
[0.12, -0.35, 0.04, ..., 0.91]

这个数组通常有几百到几千维。维度本身未必具备直接可解释性，但整体位置能表达语义信息。

当两段文本表达相近含义时，它们对应的向量在高维空间里通常更接近；当语义差异较大时，距离通常更远。

因此，向量检索的核心操作不是：

• where title = 'Redis'

而是：

• find top k nearest vectors to query_vector

常见相似度度量

向量库的查询结果，本质上由距离函数决定。常见的有三类。

Cosine Similarity

余弦相似度衡量的是两个向量夹角是否接近：

1
cos(A, B) = (A · B) / (|A| * |B|)

它更关注方向而不是长度，所以常见于文本 embedding。

如果 embedding 模型输出向量已经归一化，那么 cosine similarity 和 inner product 在排序上往往会接近。

Euclidean Distance

欧氏距离衡量的是几何空间中的直线距离：

1
L2(A, B) = sqrt(sum((Ai - Bi)^2))

它保留了向量长度信息，在某些图像或特征检索场景更常见。

Inner Product

内积既受方向影响，也受向量长度影响。很多系统会支持最大内积搜索。

这类度量能否使用，不只取决于向量库支持什么，还取决于 embedding 模型训练时默认假设的相似度定义是什么。

为什么“暴力扫描”很快就不行了

假设系统里有 1000 万条文档，每条向量维度是 1536，那么一次查询如果要和每一条向量都做完整距离计算，成本会非常可观。

即便先不考虑 IO，只看计算量，也会遇到几个问题：

• 查询延迟不可接受
• CPU 成本线性增长
• 并发一上来，机器资源会被快速吃满
• 数据量继续增长后几乎无法横向扩展

所以，向量库的核心不只是“存向量”，而是“给向量建索引”，也就是：

用更少的候选访问，尽量找到足够接近真实最近邻的结果。

这就是 ANN，Approximate Nearest Neighbor，近似最近邻搜索。

三、为什么向量检索大多是 ANN，而不是精确搜索

精确搜索的问题不在正确性，而在规模

精确搜索的好处非常明确：

• 一定能找到真正的 top k
• 结果稳定
• 没有近似误差

但一旦规模上来，它的问题也非常明确：

• 复杂度基本随数据量线性增长
• 延迟高
• 成本高
• 很难在在线系统里兼顾大规模和低时延

因此现实工程里通常做的是：

• 离线评估时保留一部分精确搜索作为 ground truth
• 在线服务时使用 ANN 索引做近似召回
• 再通过参数调优、重排、过滤策略，把误差控制在可接受范围内

所以要有一个工程认知：

向量库追求的不是数学上绝对正确，而是“延迟、吞吐、内存、召回率”之间的综合最优。

召回率、延迟、内存经常是三角关系

在向量库里，几乎所有核心参数都在做 trade-off：

• 搜得更深，召回更高，但延迟更大
• 图更密，召回更高，但内存更大
• 压缩更狠，成本更低，但精度可能下降
• 分桶更细，搜索更快，但训练和维护成本更高

所以真正线上调优时，通常不是问：

• 哪个索引算法最好

而是问：

• 在具体数据规模、写入模式、过滤需求、延迟目标下，哪个方案最合适

四、常见索引结构：HNSW、IVF、PQ 到底在解决什么

HNSW：今天最常见的通用型方案

HNSW，Hierarchical Navigable Small World，可以粗略理解成一种“分层导航图”。

它的核心思路不是先把空间切成很多桶，而是：

• 每个向量都是图中的一个节点
• 节点之间维护若干近邻边
• 上层图更稀疏，用于快速跳转到目标区域
• 下层图更密集，用于精细搜索

查询过程可以概括为：

1. 从高层某个入口点开始
2. 不断跳向“离目标更近”的节点
3. 逐层下沉
4. 在底层图里做更细致的近邻扩展

HNSW 的特点通常是：

• 召回率高
• 查询快
• 调参相对直观
• 对在线检索很友好

但它的问题也很明显：

• 内存占用偏大
• 建图成本不低
• 大规模更新和删除需要额外维护策略

很多现代向量库默认主力索引就是 HNSW，例如 Qdrant、Weaviate，pgvector 也支持 HNSW 索引。

IVF：先粗召回，再细搜索

IVF，Inverted File Index，核心思想是先聚类，再查局部。

大致流程是：

1. 对全量向量做聚类，得到多个中心点
2. 每条向量归入最近的簇
3. 查询时先找到最接近 query 的若干簇
4. 只在这些簇里继续搜索

它适合解决的问题是：

• 数据量大
• 全量扫描不现实
• 可以接受先粗筛再细查

IVF 的优点：

• 搜索范围显著缩小
• 结构相对清晰
• 配合量化后压缩效果好

IVF 的缺点：

• 聚类质量会直接影响召回
• 如果 query 落在簇边界附近，容易漏掉候选
• 对动态数据分布变化更敏感

在 PostgreSQL 生态里，pgvector 也支持 IVFFlat。这类索引通常需要先训练中心点，再结合 lists、probes 等参数做调优，因此更适合对查询分布和数据规模已有明确认知的场景。

PQ：降低存储和计算成本

PQ，Product Quantization，不是独立的召回逻辑，而更像一种向量压缩策略。

它会把高维向量切成多个子空间，再分别量化编码，从而把原始 float 向量压缩成更短的编码表示。这样做的收益通常是：

• 占用更少内存
• 缓存命中率更好
• 距离计算成本更低
• 更适合超大规模向量集合

但代价也很直接：

• 有压缩误差
• 召回精度可能下降
• 调参和评估更复杂

因此，PQ 经常与 IVF 组合使用，例如 IVF_PQ。这类设计非常适合超大规模场景，但在数据量尚未到这个级别时，过早引入复杂压缩策略，反而容易把系统复杂度拉高。

一个实用判断：先问规模，再问算法

HNSW 和 IVF 往往不会在真空环境里比较，更合理的判断顺序通常是：

1. 数据规模是几十万、几百万，还是几亿
2. 延迟目标是几十毫秒，还是几毫秒
3. 写入更新频率高不高
4. 是否大量依赖过滤
5. 内存是否足够

对中小规模、读多写少、希望尽快拿到高召回效果的系统，HNSW 往往是自然的起点。

对超大规模、成本敏感、需要压缩存储的系统，IVF + PQ 这一类方案更值得认真评估。

五、向量库不只是“向量索引”，还包含元数据过滤

如果只有相似度检索，很多线上场景其实并不能直接落地。

例如企业知识库问答，通常会带上这样的限制：

• 只查当前租户的数据
• 只查某个知识库集合
• 只查最近 30 天更新的数据
• 只查权限范围内的文档
• 只查 language = zh 的片段

这就意味着，一条真实查询常常是：

1. 先带过滤条件缩小候选范围
2. 在候选集合内做向量近邻搜索
3. 再按相似度、业务分数或时间衰减排序

因此一个成熟向量库往往不只是提供：

• vector index

还要提供：

• payload / metadata 存储
• 标量过滤
• 过滤索引
• 混合排序
• 分片与副本机制

为什么过滤会把问题变复杂

如果查询只是“全库 top k 最近邻”，很多 ANN 结构都能较稳定发挥。

但一旦加上复杂过滤，比如：

• 先过滤出某个租户的一小部分数据
• 再在这部分数据上做 ANN

就会出现几个难点：

• 原始全局索引未必对过滤后子集仍然高效
• 过滤过严时，候选不足，结果质量会抖动
• 先过滤再检索、先检索再过滤，效果和成本都不一样
• payload 索引和 vector 索引之间需要协同

这也是为什么很多向量库的真正差异，不在“支持不支持 HNSW”，而在：

• 过滤性能是否稳定
• 混合查询能力是否成熟
• 写入更新后的索引维护是否平滑

过滤策略：预过滤、后过滤与迭代过滤

当过滤条件进入检索链路后，系统通常会在三种策略之间取舍：

这三种策略没有绝对优劣，核心判断标准通常是：

• 过滤条件是否带有强约束，例如租户、ACL、数据域隔离
• 过滤后候选规模是否仍然足以支撑 ANN 检索
• 查询延迟目标是否允许多轮扩大候选
• 系统更担心“召回不够”还是“误召回越权数据”

六、混合检索：为什么很多系统最后都不是“纯向量”

“纯向量检索”有明显优点：

• 能找到语义接近但字面不同的内容
• 对表达方式更鲁棒

但它也有典型短板：

• 对精确术语、缩写、编号未必敏感
• 对时间、版本号、错误码这种精确 token 可能表现一般
• 某些场景容易被“语义相近但答案不对”的片段干扰

所以很多线上系统会做 hybrid search，也就是：

• 一部分分数来自关键词检索，例如 BM25
• 一部分分数来自向量相似度
• 最终再融合排序

典型适用场景包括：

• API 文档检索
• 运维告警知识库
• 电商搜索
• 法务条款检索
• 包含大量术语和编号的企业内部文档

一个重要认知是：

向量检索并没有淘汰倒排索引，很多时候两者结合反而更强。

混合检索里的分数怎么融合

混合检索并不是简单把两份结果拼在一起，更关键的是如何融合分数。常见做法有两类：

• 加权求和：先把 BM25 分数和向量相似度做归一化，再按权重线性融合
• RRF，Reciprocal Rank Fusion：不过分依赖原始分数，而是更关注候选在各自排序里的名次

其中 RRF 在工程上很常见，原因在于关键词得分和向量相似度的分布通常不在一个量纲上，直接做分数加法并不稳定。RRF 的一个直观优点是：

• 不要求不同检索器的分数严格可比
• 对长尾 query 和分数分布漂移更稳健
• 更适合作为多路召回后的通用融合层

但如果业务已经掌握了较稳定的样本集，也可以用加权融合配合离线评测去微调权重。真正需要比较的不是哪种公式“更先进”，而是哪种融合方式在业务语料上更稳定。

七、把一次 RAG 检索链路拆开：向量库到底处在哪

一个比较典型的链路如下：

graph TB
    A[原始文档] --> B[清洗与切块]
    B --> C[Embedding]
    C --> D[写入向量库]
    D --> E[向量 索引 原文 元数据]
    Q[用户查询] --> R[Query Embedding]
    R --> F[Metadata Filter]
    F --> G[ANN Recall]
    G --> H[Rerank]
    H --> I[组装上下文]
    I --> J[LLM 生成]
    E --> G

最容易被低估的不是索引，而是切块

很多检索质量问题，最后查下来并不是向量库不行，而是 chunk 设计出了问题。

常见表现包括：

• 切得太碎，语义上下文不完整
• 切得太大，主题过于混杂
• 标题和正文没有一起进入 embedding
• 表格、列表、代码块在清洗时丢失结构
• 相邻 chunk 没有 overlap，跨段信息断裂

因此“向量库效果不好”这个判断，往往需要拆开看：

1. 是 embedding 模型不合适
2. 还是 chunk 策略不合理
3. 还是过滤条件限制过强
4. 还是 top k 太小
5. 还是 rerank 缺失

Rerank 常常比“再换一家向量库”更有效

很多团队在召回不稳时第一反应是换数据库，但实践里更常见的情况是：

• ANN 负责从海量候选中快速筛出前几十条
• reranker 再用更贵但更精确的模型重新排序

这一步尤其适合：

• 知识问答
• 法律合同检索
• 医疗文本检索
• 需要细粒度相关性判断的长文档场景

也就是说，向量库负责的是“高效召回”，而不是最终语义判断的全部责任。

一张 RAG 落地最小方案图

如果把一个最小可用的 RAG 系统继续压缩，核心链路可以写成：

1
2
3
4
5
6
7
8
9
10
11
原始文档
  -> 清洗
  -> 切块
  -> embedding
  -> 存储（向量 + 原文 + metadata）
  -> 用户提问
  -> query embedding
  -> 检索
  -> rerank
  -> 组装上下文
  -> LLM 生成答案

如果再把它翻译成更偏工程实现的两条路径，可以拆成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
离线入库链路：
文档/PDF/网页
  -> 清洗与结构化
  -> chunk 切分
  -> embedding
  -> 写入向量库

在线查询链路：
用户问题
  -> query embedding
  -> metadata filter + ANN recall
  -> rerank
  -> 拼接 context
  -> LLM answer

这张图看起来简单，但它至少说明了三件事：

• RAG 不只是“提问 -> 查向量库 -> 出答案”
• 离线入库链路和在线查询链路是两条不同的系统路径
• 真正决定最终效果的，不只有数据库，还包括切块、过滤、rerank 和 context 组织

第一次落地 RAG 时，通常更适合先把这条最小链路跑通，再决定哪些环节值得继续复杂化。

八、写入、更新、删除：真实系统最容易被忽略的一面

如果只是做原型验证，大家通常只关心：

• 能不能 insert
• 能不能 query

但线上系统更棘手的问题往往是：

• 文档更新后旧向量怎么失效
• 删除是否真的从索引里清掉
• 批量导入时索引构建如何控成本
• 实时写入会不会影响查询延迟
• embedding 模型升级后是否需要全量重建

更新不是“改一行数据”那么简单

向量数据的更新通常意味着：

1. 原始文本变了
2. chunk 结果可能变了
3. embedding 需要重算
4. 索引里的向量要替换
5. 某些引用关系、统计信息也可能要同步调整

如果文档被切成多个 chunk，那么一次文档修改，常常不是 update 一条，而是：

• 删除旧 chunk 集合
• 重新生成并写入一组新 chunk

这会直接影响主键设计、幂等写入、版本管理和索引重建策略。

删除、重建、压缩都是运维问题

不同向量库对删除的处理方式可能不同：

• 立即物理删除
• 逻辑删除后延迟清理
• 标记 tombstone，等待后台 compact

如果系统长期高频更新，而没有有效的 compaction 或重建机制，索引质量和查询性能都可能逐步下降。

所以生产环境里，常见配套能力包括：

• bulk load
• segment compaction
• background indexing
• snapshot / backup
• index rebuild

这些能力看起来不像“算法”，却直接决定系统是否可长期维护。

多租户与权限隔离不能只靠业务层补救

向量检索在企业场景里还有一个经常被低估的问题：权限隔离。

如果检索请求天然带着租户、部门、知识库、文档可见范围这些约束，那么权限信息就不只是普通 metadata，而是查询正确性的一部分。一个常见误区是：

• 先按全库做召回
• 再在应用层把越权结果删掉

这种做法的主要问题在于：

• 过滤后可能剩不下足够的结果，导致召回质量不稳定
• 系统会为本不该访问的数据付出计算成本
• 一旦链路存在缓存、日志或中间结果落盘，越权数据就可能在别的环节暴露

因此生产环境里更稳妥的设计通常是把租户、ACL、数据域等约束前置到检索路径里，把“检索到什么”与“允许看什么”统一建模，而不是把权限校验留到最后一层兜底。

九、如何理解主流产品的分工差异

pgvector：最小心智成本的入口方案

pgvector 的核心价值不在于“性能一定最强”，而在于：

• 已经有 PostgreSQL
• 不希望引入新基础设施
• 需要事务、SQL、权限、备份体系复用
• 数据规模还没有大到必须上独立向量引擎

它特别适合：

• 中小规模知识库
• 后台管理系统里的语义搜索
• 需要和现有业务表强关联的场景
• 希望快速验证 AI 检索能力的团队

它的边界通常在于：

• 超大规模场景的扩展性
• 极致低延迟
• 复杂混合检索与分布式能力

所以可以把它理解成：

“先在现有数据库体系里把向量检索跑起来”的工程化折中方案。

Milvus：更偏独立分布式向量引擎

Milvus 更适合强调：

• 独立向量检索能力
• 更大规模数据集
• 分布式部署
• 更明确的数据段、索引构建、查询节点分工

如果团队愿意接受新基础设施和更高运维复杂度，它会提供更完整的专用向量引擎能力。

Qdrant：过滤和工程体验都比较均衡

Qdrant 的讨论度高，很大一部分原因不是“宣传做得好”，而是它在很多真实业务场景里比较均衡：

• HNSW 能力成熟
• payload 过滤体验较好
• API 清晰
• 自托管门槛相对不高

如果重点是“RAG 线上服务 + 元数据过滤 + 自托管可控”，它经常会进入候选名单。

Weaviate：更强调语义应用层能力组合

Weaviate 除了基础向量检索，也常被提到：

• 混合搜索
• 模块化集成
• 多模态场景
• 对上层语义应用更友好的接口设计

它给人的感觉常常不是“一个只负责索引的引擎”，而是更接近“面向 AI 应用的数据层平台”。

Pinecone：托管服务思路更强

Pinecone 的核心价值往往在于：

• 托管化
• 更少自运维负担
• SDK 和云服务体验完整
• 团队能更聚焦业务而不是底层集群维护

如果主要诉求是：

• 更快上线
• SLA
• 更少基础设施维护

那么它的吸引力会很强；如果更强调自托管、成本精控、底层可见性，则往往会更偏开源方案。

一张表先建立整体印象

如果只是为了快速建立整体印象，可以先看下面这张表。大多数选型讨论，本质上都在下面几列里做取舍：

这里的“费用感知”不要只按软件 license 理解，更应该按总拥有成本看，也就是：

• 软件本身是否收费
• 是否需要新机器、新集群、新运维人力
• 查询量、数据量、写入量上来后的弹性成本
• 团队为了接入和维护这套系统要付出多少工程复杂度

复习时怎么快速区分这 5 个方案

如果把这 5 个方案再压缩成更容易记忆的判断，可以直接记成下面 5 句话：

• pgvector：已有 PostgreSQL，优先复用现有基础设施
• Milvus：目标是独立、专业、可分布式扩展的向量引擎
• Qdrant：重点是较强过滤能力与相对可控的自托管成本
• Weaviate：重点是混合检索、多模态和上层 AI 应用整合
• Pinecone：重点是托管化、上线速度和更少运维负担

如果再往前走一步，把它们映射成实际决策问题，可以这样理解：

• 团队几乎没有额外基础设施预算或人力，先看 pgvector
• 团队要做专门的 AI 检索平台，且规模和复杂度都会继续上升，重点看 Milvus
• 团队是典型 RAG 场景，过滤很多，想自己掌控部署，重点看 Qdrant
• 团队不只做文本检索，还希望把 hybrid search、多模态、模块能力一起考虑，重点看 Weaviate
• 团队更像业务产品团队，不想自己维护底层集群，重点看 Pinecone

给一张更实用的选型决策树

如果不想先看一堆横评，而是希望快速缩小范围，可以先走下面这张决策树：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
是否已经稳定使用 PostgreSQL，且向量检索只是现有业务的一部分？
  -> 是：
       数据规模是否仍在中小规模，可接受先用一套库把功能跑起来？
         -> 是：优先看 pgvector
         -> 否：继续往下看专用向量库
  -> 否：继续往下

是否强烈希望“少运维、快上线、有人兜 SLA”？
  -> 是：优先看 Pinecone
  -> 否：继续往下

是否希望系统完全可自托管，并且过滤能力对业务非常关键？
  -> 是：优先看 Qdrant
  -> 否：继续往下

是否不只做基础向量检索，还很看重 hybrid search、多模态、AI 应用层整合？
  -> 是：优先看 Weaviate
  -> 否：继续往下

目标是否是更大规模、更专业、可分布式扩展的独立向量引擎？
  -> 是：优先看 Milvus
  -> 否：默认仍可从 pgvector 或 Qdrant 起步

这张决策树不是“绝对正确”的产品推荐，而是为了先把问题分层：

• 是复用现有数据库，还是引入专用引擎
• 是优先少运维，还是优先可控
• 是偏中小规模快速上线，还是偏长期大规模平台化
• 是只要向量检索，还是还要 hybrid search、多模态、应用层能力

只有先把这些问题问清楚，后面的横向比较才有意义。

十、选型时真正该问的问题

很多“向量库选型”文章最后会变成产品横评，但真正有用的问题通常只有这些：

数据规模多大

• 10 万级和 1 亿级不是一个问题
• 原始向量是 384 维还是 3072 维，成本差很多
• 是否需要多副本、多分片，也会显著改变资源模型

写入模式怎样

• 主要是离线批量导入
• 还是持续实时增量写入
• 更新和删除多不多

读多写少、写后很少变的数据，和高频变更的数据，最适合的索引策略可能完全不同。

过滤需求复杂吗

如果业务对 metadata filter 非常依赖，那么光比较 ANN 算法意义不大，应该重点看：

• payload 索引能力
• 过滤和向量查询的组合性能
• 多租户隔离方式

运维能力强不强

• 团队能不能维护独立集群
• 能不能接受数据迁移和索引重建
• 是否有备份恢复和容量规划经验

这决定了更适合的是：

• 托管服务
• 自托管专用向量库
• 还是先用 pgvector

最终目标是“搜得到”，还是“答得对”

这是最关键的。

如果最终目标是一个 RAG 问答系统，那么要优化的终点不是 ANN benchmark 分数，而是：

• 最终回答正确率
• 幻觉率
• 上下文相关性
• 查询延迟
• 单次请求成本

很多时候，把预算全砸在底层向量库上，不如补上：

• 更合适的 embedding 模型
• 更好的 chunk 策略
• 混合检索
• rerank
• 查询改写

评估体系怎么建

向量检索系统的评估最好分成两层：

1. 检索层评估：看召回是否足够好
2. 任务层评估：看检索结果是否真的改善了最终业务目标

检索层常见指标包括：

• Recall@K：前 K 个结果里找回了多少真实相关文档
• MRR：第一个正确结果出现得有多靠前
• NDCG@K：当相关性有等级差异时，更适合衡量排序质量
• P95 / P99 latency：只看平均延迟会掩盖尾延迟问题

任务层则更应关注：

• RAG 回答正确率
• 幻觉率
• 用户点击率或转化率
• 单次请求成本

如果只看 ANN benchmark，而不看过滤、rerank、权限约束和最终回答质量，线上系统很容易出现“检索指标漂亮，但业务效果一般”的错位。

十一、几个特别常见的追问

为什么不用 Elasticsearch 直接代替向量库

这个问题背后真正要区分的是：

• Elasticsearch 已经能做搜索了
• 它也支持向量检索
• 那为什么还要专门再上一个向量库

答案不是“绝对不能替代”，而是：

要看核心问题，到底是“通用搜索平台顺带做向量检索”，还是“向量检索本身就是系统核心”。

如果需求更偏下面这些：

• 关键词检索本来就很重要
• 倒排索引、过滤、聚合、日志分析本来就是主业务
• 向量检索只是现有搜索体系上的新增能力
• 团队已经非常熟悉 Elasticsearch

那么直接在 Elasticsearch 里做向量检索，是完全合理的工程选择。

但如果系统更偏下面这些：

• RAG 检索是核心路径
• 高维向量召回质量和查询成本非常关键
• 数据规模大，ANN 索引是核心能力
• 元数据过滤要和向量检索深度协同
• 后续会持续调索引、调召回、调 rerank

那么专用向量库通常会更合适。因为这时优化重心已经不再是“通用搜索能力”，而是：

• 向量索引结构
• ANN 查询效率
• 过滤与向量检索的协同
• 写入、压缩、重建、分片、副本这些向量场景特有问题

所以更准确的结论不是：

• Elasticsearch 不行

而是：

• Elasticsearch 更像“通用搜索平台 + 向量能力”
• 专用向量库更像“以向量检索为核心的一等基础设施”

如果主战场是企业站内搜索、日志检索、商品搜索，且本来就重度依赖倒排和 BM25，那么 Elasticsearch 完全可以是一个现实方案。

如果主战场是 AI 检索、知识库问答、推荐召回、长文档语义匹配，专用向量库往往会更顺手。

Elasticsearch / pgvector / 专用向量库，三者到底怎么选

如果把讨论再压缩成一张复习表，可以先看下面这张：

如果只想记一句非常粗的决策规则，可以记成：

• 已有成熟搜索体系，且关键词检索是主轴，优先看 Elasticsearch
• 已有 PostgreSQL，且现在最重要的是低成本验证价值，优先看 pgvector
• 已经确认向量检索是主路径，且后续规模、过滤、性能都会持续升级，优先看专用向量库

为什么很多团队会先用 pgvector

这一节其实在回答：

• 为什么不是先上最“专业”的那套
• 为什么很多团队宁可先做一个不那么极致的方案
• 为什么工程里“先验证价值”经常比“先上最强架构”更重要

原因往往不是“pgvector 一定是最强的”，而是它在很多团队里是最容易启动、最容易证明价值的方案。

第一，它几乎不改变团队的基础设施版图。

• 原来就在用 PostgreSQL
• 现在只是加一个 extension
• 权限、备份、监控、迁移流程很多都能沿用

第二，它很适合“先把功能跑通”。

很多团队刚开始做 RAG 或语义搜索时，真正不确定的不是数据库，而是：

• chunk 怎么切
• embedding 模型选哪个
• 检索效果能不能接受
• 业务到底有没有真实需求

在这个阶段，最怕的是还没验证需求，就先把基础设施搭复杂了。

第三，它特别适合和业务表强关联的场景。

比如：

• 文档表和向量列就在同一库
• 用户权限、租户字段、时间字段本来就在业务表里
• 需要 SQL 联查、事务写入、一致性保障

这时 pgvector 的优势会非常直接。

当然，很多团队“先用 pgvector”，也意味着后面可能会遇到边界：

• 数据规模持续增长
• 查询延迟目标越来越严
• 过滤和检索组合越来越复杂
• 需要更专业的分布式向量能力

于是演进路径常常是：

1. 先用 pgvector 快速验证价值
2. 当规模和复杂度上来后，再评估 Qdrant、Milvus、Weaviate 或托管方案

所以它的真正价值，是：

用最小的组织成本，把“语义检索是否值得做”这件事先验证出来。

什么时候该从 pgvector 升级到专用向量库

这个问题的关键不在于：

• pgvector 行不行

而在于：

• 它是不是已经开始限制系统继续往前走

一个比较实用的判断方法，是看是否已经连续遇到下面这些信号。

数据规模和性能目标开始碰到边界

比如：

• 向量量级已经持续上升，查询延迟越来越难压
• 高峰期并发上来后，数据库负载明显不稳
• 开始频繁纠结索引构建时间、内存占用和查询抖动
• 向量检索已经不再是“顺带做一下”，而是系统的核心路径

这时就要开始认真评估：

• 是否需要更专业的 ANN 能力
• 是否需要把检索压力从主业务库里拆出去

过滤、召回、重排的组合越来越复杂

如果查询越来越像下面这样：

• 多租户过滤
• 权限过滤
• 时间范围过滤
• hybrid search
• rerank
• 去重、聚合、按文档回收结果

那就说明已经不再只是“给 PostgreSQL 多加一列向量”，而是在做一个真正的检索系统。

这个阶段继续把所有复杂度都压在一套通用业务库里，往往会越来越吃力。

运维目标已经从“先跑起来”变成“稳定扩展”

pgvector 很适合验证价值，但当系统进入稳定运营期后，关注点会变成：

• 索引重建能不能更平滑
• 批量导入能不能更快
• 删除和 compact 能不能更可控
• 副本、分片、隔离、扩容能不能更专业

如果这些问题越来越频繁出现，就说明开始需要一套“以向量检索为一等公民”的基础设施。

一个很实用的升级判断

如果满足下面任意两到三条，其实就已经值得把升级提上日程：

• 向量检索是核心请求链路，不再只是附属能力
• 数据规模和并发增长已经开始明显影响主库稳定性
• 查询强依赖复杂过滤、hybrid search 或 rerank 协同
• 团队开始频繁遇到索引重建、导入、删除、扩容方面的运维问题
• 已经知道后面还会继续加规模，而不是一次性的小功能

这时候更合理的做法通常不是“死守 pgvector”，而是：

1. 先保留现有方案继续服务
2. 并行评估 Qdrant、Milvus、Weaviate 或托管方案
3. 用真实业务样本做离线评测和灰度迁移

所以更准确的结论是：

pgvector 适合用来验证价值，专用向量库更适合承接已经被验证过、且会继续扩张的检索系统。

向量库里到底存不存原文

很多人第一次接触向量库时会默认认为：

• 只要存 embedding 就够了

但真实工程里，通常不会只存向量，而是至少还会带上：

• 原始 chunk 文本
• 文档 ID / chunk ID
• 标题、章节、时间、租户、权限等 metadata

原因很简单：

• 检索出来后，还要把可读文本返给上层
• 还要做过滤、权限判断、去重和聚合
• 还要知道这段 chunk 属于哪篇文档、哪个版本

因此更稳妥的理解是：

向量库不是只存一个 vector 列，而是经常要同时存“向量 + 原文片段 + 元数据 + 标识信息”。

当然，也有团队会把原文放对象存储或主库，向量库里只保留引用 ID。这个方案不是不行，但会把查询链路、回表成本和一致性问题都带进来，所以要看系统复杂度是否值得。

是不是所有场景都要 hybrid search

不一定。

如果数据和查询更偏下面这些：

• 自然语言表达很多
• 同义改写很多
• 精确术语不是主矛盾
• 查询更像在“问意思”，不是在“搜关键字”

那么纯向量检索就可能已经够用。

但如果数据里大量包含下面这些元素，hybrid search 通常更值得考虑：

• 专有名词
• API 名称
• 错误码
• 订单号、编号、版本号
• 法条编号、字段名、类名、函数名

因为这类 token 往往具有强精确匹配价值，单靠纯语义相似度未必稳定。

所以更实用的结论是：

• 先别把 hybrid search 当信仰
• 先拿业务样本验证纯向量够不够
• 如果关键字召回明显能补足纯向量短板，再上 hybrid search

十二、几个特别容易踩的坑

混用不同 embedding 模型

如果历史数据和新数据不是用同一个 embedding 模型生成的，甚至维度都不同，那么同库检索通常会出现明显问题。即使维度一样，不同模型的语义空间也可能不一致。

所以要把“embedding 版本”当成一等元数据来管理。

只看 top k，不看上下文冗余

很多系统把 top_k = 10 当成固定参数，但如果前 10 条其实高度重复，真实有效信息量可能很低。检索结果去重、按文档聚合、按章节裁剪，往往能比单纯调大 top k 更有效。

把相似度分数当成绝对真理

不同库、不同度量、不同模型下的分数不可直接横向比较。线上更可靠的做法通常是：

• 基于业务样本做离线评测
• 看 NDCG、Recall@K、MRR 之类指标
• 用 A/B 测试验证最终效果

忽视重建成本

当 embedding 模型升级、chunk 策略变化、索引参数调整时，往往不是改个配置就结束，而是需要：

• 全量重嵌入
• 全量重建索引
• 双写或灰度迁移

如果一开始没有把这件事当成必然会发生的运维动作，后面迁移成本通常会很高。

十三、最后给一个工作中的理解框架

如果要把向量库压缩成一套最值得记住的理解框架，可以先记下面 5 句话：

1. 向量库的核心价值不是存储，而是高维近邻检索
2. Embedding 决定语义表达，索引决定检索效率
3. ANN 追求的是召回率、延迟、内存、成本之间的平衡
4. 线上效果往往取决于 chunk、filter、hybrid、rerank 的整体协作
5. 选型不要只看 benchmark，要看数据规模、写入模式、过滤复杂度和团队运维能力

如果继续往下深挖，最值得延伸的几个主题是：

• HNSW 参数调优，例如 M、ef_construction、ef_search
• pgvector 与专用向量库在生产环境里的边界
• RAG 中 hybrid retrieval 与 rerank 的组合策略
• 文档更新、重嵌入、索引重建的工程治理

• Previous
  RAG 扫盲
• Next
  最小 RAG 项目落地