Wiki Notes

Appearance

01. 向量数据库详解 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在做 RAG、企业知识库、语义检索、多模态检索、Agent 检索工具、推荐与召回系统，以及需要回答“为什么搜不准、为什么查得慢、为什么一扩租户就串数据”的产品、研发、架构、平台与运维同学

很多团队第一次接触向量数据库时，最容易形成一个过于简单的印象：

  • 把文本做成 embedding
  • 存进去
  • 查询时做相似度搜索

这当然没错，但如果你只停在这一步，后面几乎一定会在生产里踩到这些坑：

  • 为什么召回结果“语义很像，但业务上是错的”
  • 为什么 metadata filter 一加，性能突然掉得很厉害
  • 为什么同一个问题离线评测还行，线上一上多租户就开始串数
  • 为什么数据明明写进去了，却总是检索不到最新内容
  • 为什么换了 embedding 模型后，整个索引像是“集体失忆”
  • 为什么数据库本身没报错，但最终答案质量明显退化

这页的目标不是只讲“什么是向量数据库”，而是帮你建立一套更接近生产的心智模型：

  • 向量数据库不是“存 embedding 的地方”
  • 它更像 检索基础设施

1. 什么是向量数据库 ​

最实用的理解通常是：

  • 为高维向量存储、索引、过滤和近邻搜索优化的数据系统

它和普通关系数据库最大的差别不在“能不能存数据”，而在：

  • 能不能从海量高维向量里高效找出最相近的候选

根据 pgvector 当前官方 README：

  • pgvector 为 Postgres 提供 vector similarity search
  • 支持 exact search 和 approximate nearest neighbor search

根据 Weaviate 当前官方文档：

  • 向量索引用于组织 embedding，以支持高效相似度搜索

根据 Pinecone 当前官方文档：

  • 一条记录通常由 id、vector 和 metadata 组成

所以更准确地说：

  • 向量数据库的核心不是“存”，而是“找”

2. 为什么它对 AI 系统重要 ​

在 LLM 应用里，尤其是 RAG、企业知识库、推荐和 Agent 检索工具中，系统常常要做下面这件事：

  1. 把原始内容切块
  2. 给每个 chunk 生成 embedding
  3. 在查询时从海量候选里找到最相关的一小批
  4. 再交给重排、生成或下游决策

如果没有合适的检索基础设施，系统会很快遇到：

  • 召回慢
  • 成本高
  • 结果不稳
  • 数据规模上来后不可扩展

所以在 AI 系统里，向量数据库本质上是：

  • 语义召回层

而不是：

  • 最终答案层

这点非常重要，因为它解释了一个常见误区：

  • 向量数据库负责的是把候选找出来，不是直接保证最终回答一定正确

3. 向量数据库和普通数据库有什么不同 ​

普通数据库更擅长：

  • 精确匹配
  • 条件过滤
  • 事务
  • 结构化查询
  • 聚合与 join

向量数据库更擅长：

  • 近邻搜索
  • 语义相似检索
  • 高维空间索引
  • 混合稠密 / 稀疏召回

但真实生产里，两者通常不是替代关系，而是组合关系。

典型形态包括：

  • Postgres + pgvector
  • OpenSearch / Elasticsearch + vector + lexical
  • 向量检索 + metadata filter + 外部业务库

更实用的理解通常是：

  • 普通数据库负责“精确事实”
  • 向量数据库负责“语义候选”

4. 一条向量记录到底由什么组成 ​

很多团队一开始只盯着：

  • vector 本身

但真实系统里，一条记录至少会涉及下面几部分。

4.1 向量 ​

向量通常来自 embedding 模型，例如：

  • 文本 embedding
  • 图片 embedding
  • 多模态 embedding

它代表的是：

  • 模型把内容映射到高维空间后的数值表示

4.2 稳定 ID ​

每条向量记录都应该有稳定 ID。

这个 ID 的作用不只是“主键”，还关系到：

  • 更新覆盖
  • 去重
  • 版本追踪
  • 父子关系
  • 数据回放

4.3 原始内容或引用 ​

很多系统不会把所有原始正文都塞进向量库，但至少应能通过记录拿到：

  • chunk 文本
  • 原文引用
  • document id
  • source uri

4.4 元数据 ​

这是生产里最容易被低估的部分。

常见 metadata 包括：

  • 文档来源
  • 标题
  • 时间
  • 标签
  • 文档版本
  • 租户 ID
  • 权限范围
  • chunk 序号
  • 语言
  • 产品线

Pinecone 当前官方文档明确把 metadata 作为记录模型的重要组成。

真实业务里你几乎很少只做：

  • 纯向量相似搜索

更常见的是：

  • 向量相似度 + metadata 过滤 + 排序策略

4.5 索引结构 ​

索引决定的是：

  • 查得多快
  • 近似到什么程度
  • 更新代价有多大

4.6 查询接口 ​

查询层至少要处理：

  • 相似度搜索
  • top-k 返回
  • metadata filter
  • hybrid search
  • namespace / collection / tenant scope

5. 向量数据库最核心的，不是“相似”，而是“相似度怎么定义” ​

向量检索不是魔法，它必须依赖某种距离或相似度度量。

常见度量包括：

  • cosine similarity
  • dot product
  • Euclidean / L2 distance

这不是数学细节，而是会直接影响：

  • 排序结果
  • embedding 兼容性
  • 模型迁移成本

5.1 cosine similarity 常见于文本语义任务 ​

很多文本 embedding 场景会优先使用 cosine，相对更适合看“方向相似性”。

5.2 dot product 往往和模型训练方式有关 ​

一些 embedding 模型更适合 dot product。

工程上最关键的一点是：

  • 你的索引距离度量最好和 embedding 模型官方推荐保持一致

5.3 L2 不是落后方案，而是另一种空间假设 ​

某些场景下，L2 依然是合理选择，关键不是“哪种永远最好”，而是：

  • 训练空间与检索度量是否匹配

6. 什么是近邻搜索 ​

近邻搜索解决的问题是：

  • 给定一个查询向量，找到向量空间里最接近它的若干记录

如果数据量很小，完全可以做：

  • 全量扫描

但当数据规模上去后，全量比较会变得：

  • 太慢
  • 太贵
  • 无法承受高并发

所以生产系统真正关心的是：

  • 如何在可接受延迟下，尽量找对那些候选

这也解释了为什么向量检索里常常出现一个核心权衡：

  • 精确性 vs 性能

7. 精确检索和近似检索，不是谁替代谁 ​

很多团队第一次看到 ANN 时，会误以为：

  • 近似检索是不是“不准确”

更准确的理解应该是：

  • exact search：更直接、更朴素、通常更慢
  • ANN search：更可扩展、通常更快、可能存在召回损失

pgvector 当前官方 README 就明确区分：

  • exact nearest neighbor search
  • approximate nearest neighbor search

7.1 exact search 适合什么场景 ​

更常见于：

  • 数据量不大
  • 验证阶段
  • 评测基线
  • 对召回完整性非常敏感的场景

7.2 ANN 适合什么场景 ​

更常见于：

  • 大规模在线检索
  • 高并发服务
  • 低延迟要求
  • 多租户共享检索面

7.3 生产里很有价值的做法：保留 exact baseline ​

很多团队只上 ANN，不留 exact baseline，最后就很难回答：

  • 召回退化到底是 embedding 问题
  • 还是索引参数问题

更稳的做法通常是：

  • 在评测环境保留 exact baseline
  • 在线面跑 ANN
  • 用样本回放比对召回差异

8. 向量索引到底在做什么 ​

如果用一句话描述索引的作用，就是：

  • 减少你为每次查询要比较的候选范围

否则你每次都需要拿查询向量与海量数据逐条比较。

向量索引的价值主要体现在：

  • 加速召回
  • 降低资源消耗
  • 让大规模在线检索可行

但代价通常也包括：

  • 参数调优复杂
  • 更新代价上升
  • 存储占用增加
  • 可能带来召回损失

9. 最常见的 ANN 索引思路为什么值得懂 ​

大多数团队不需要自己实现索引，但最好知道常见家族差异。

9.1 HNSW ​

HNSW 是当前很多向量系统广泛使用的 ANN 路线之一。

你会在多个主流产品或文档里看到它，因为它常常在：

  • 查询速度
  • 召回率
  • 实用性

之间取得较好平衡。

但它也通常意味着：

  • 建索引和内存成本不低
  • 参数调优值得认真做

9.2 IVF / IVFFlat ​

IVF 路线的核心思路更接近：

  • 先做粗粒度分桶
  • 再在部分桶里精查

这类路线的好处通常是：

  • 更好理解“查询范围收缩”

但它往往要求：

  • 更关注聚类质量
  • 更关注 probe 范围

9.3 Flat ​

Flat 往往更接近：

  • 不做复杂近似结构，直接或近直接比较

它更适合：

  • 小规模
  • 基线评测
  • 精确验证

9.4 真正该记住的不是索引名，而是权衡项 ​

你最终要权衡的通常是：

  • 查询速度
  • 召回率
  • 内存
  • 建索引速度
  • 更新友好度
  • 多租户下的稳定性

10. metadata 为什么不是“附属字段”，而是业务正确性的核心 ​

生产里最常见的向量检索错误之一就是：

  • 语义上很像
  • 业务上不对

这往往不是向量本身错，而是因为少了正确的 metadata 约束。

10.1 生产里最常见的 metadata 字段 ​

更常见的字段包括：

  • tenant_id
  • org_id
  • user_group
  • product_line
  • doc_type
  • updated_at
  • document_version
  • source
  • language
  • region
  • compliance_scope

10.2 结构化 ID 和父子关系很重要 ​

如果没有这些关系，你常常会遇到：

  • 检索到了 chunk，但不知道属于哪篇文档
  • 同一篇文档多个 chunk 重复上屏
  • 无法按父文档做去重或聚合

10.3 新鲜度和版本治理不能最后再想 ​

如果 metadata 没有版本和时间维度，最常见的线上问题是：

  • 总能搜到旧版本
  • 新内容写进来了，但旧内容还在抢前排

11. 过滤为什么会改变检索系统的性质 ​

很多新手会把 filter 理解成：

  • 只是“再加一个 where 条件”

在向量检索里，这远不止如此。

因为一旦你开始大量依赖 filter，系统就不再只是：

  • 向量最近邻搜索

而是：

  • 高维相似度搜索 + 结构化约束求交

这会直接影响：

  • 查询性能
  • 索引设计
  • namespace / collection 规划
  • 多租户隔离方案

11.1 没有 filter 的“语义最相近”不等于业务最正确 ​

例如：

  • 用户问某租户的知识
  • 结果召回了别的租户相似内容

语义可能相近，但业务上是灾难。

11.2 filter 太重时，性能和召回都会受影响 ​

如果过滤维度过多、表达式复杂或租户分布不均，很容易出现：

  • 查得变慢
  • 候选过少
  • 召回不稳定

所以 filter 设计本身就是架构题。

12. Hybrid Search 为什么越来越重要 ​

只做 dense vector search 很多时候不够。

原因很简单：

  • 纯语义相似不一定能保住关键词精度
  • 数字、型号、SKU、专有名词、缩写常常需要 lexical 信号

所以 Hybrid Search 越来越重要。

12.1 dense 检索擅长什么 ​

  • 语义相近
  • 同义改写
  • 模糊表达

12.2 sparse / lexical 检索擅长什么 ​

  • 关键词
  • 精确术语
  • 编号、代码、产品名

12.3 hybrid 的真实价值 ​

真实价值通常不是“技术更复杂”，而是：

  • 让检索同时保住语义泛化和关键词精度

12.4 不要把 hybrid 理解成“简单加权求和” ​

真正做得稳，通常还要处理：

  • dense 与 sparse 的归一化
  • 重排
  • 去重
  • 不同 query 类型的权重差异

13. 向量数据库和 RAG 的关系：它是召回层，不是答案层 ​

很多团队做 RAG 时最容易把责任归错层。

向量数据库通常负责的是：

  1. 找候选
  2. 控相关性
  3. 控速度
  4. 控过滤边界

它通常不直接负责：

  • 最终答案组织
  • 证据引用格式
  • 幻觉控制
  • 回答语气

所以如果最终答案效果不好，可能的问题来自：

  • embedding 质量
  • chunk 设计
  • 检索过滤
  • 重排缺失
  • 生成层 prompt
  • 引用策略

不能把所有锅都甩给向量数据库。

14. Dense、Sparse、多向量和重排，最好分层理解 ​

检索系统成熟后，常见链路通常不是单层：

  1. dense / sparse 召回
  2. filter 约束
  3. 去重与聚合
  4. rerank
  5. 上下文拼装

14.1 dense 负责“广义相关” ​

14.2 sparse 负责“关键词精度” ​

14.3 rerank 负责“最终排序更贴近任务” ​

14.4 多向量 / named vector 适合更复杂对象 ​

一些系统会为同一对象维护多个向量表示，例如：

  • 标题向量
  • 正文向量
  • 图片向量
  • 摘要向量

这不是炫技，而是因为：

  • 单一向量未必足够表达复杂对象的不同检索意图

15. 写路径为什么同样重要 ​

很多团队做向量数据库时只盯查询，忽略写路径。

但线上经常出问题的恰恰是：

  • 数据写入后什么时候可查
  • 更新时旧版本何时失效
  • 删除是否真的生效
  • 大规模重嵌入如何切换

15.1 写进去不等于马上可信 ​

从“写入成功”到“检索可用”之间，现实里常常还有：

  • 索引构建
  • 异步刷新
  • 副本同步
  • filter 可见性

15.2 更新最容易出的问题不是失败，而是“半更新” ​

例如：

  • vector 更新了，metadata 还没更新
  • 新版本写进去了，旧版本没及时下线
  • document 级别的删除没有同步到 chunk 级别

15.3 删除与失效一定要有策略 ​

如果没有失效策略，最常见的线上体验就是：

  • 已废弃内容仍频繁被召回

16. 多租户与权限隔离，为什么不能只靠 prompt ​

多租户检索里，一个最危险的误区是：

  • 在 prompt 里告诉模型“只看本租户”

这远远不够。

真正的隔离应该尽量落在检索层，而不是只落在生成层。

16.1 namespace 适合什么场景 ​

namespace 更像：

  • 第一层硬隔离

更适合：

  • 租户边界强
  • 数据混用风险高
  • 合规要求高

16.2 metadata filter 适合什么场景 ​

metadata filter 更像：

  • 租户内细粒度约束

更适合：

  • 同租户内再分业务线、文档类型、区域、时间等

16.3 一个常见反模式 ​

把所有租户都塞进一个大检索面，然后只靠：

  • 应用侧逻辑
  • prompt 提示
  • 后置过滤

这在规模上来后非常容易变成：

  • 偶发串租
  • 排查困难
  • 性能不可预测

17. 主流方案到底怎么选：别只看“谁支持向量” ​

很多产品都支持向量检索，但它们的工程定位不一样。

17.1 pgvector ​

pgvector 的核心价值往往在于：

  • 你已经有 Postgres
  • 想把结构化数据和向量数据尽量放近
  • 想先以较低心智成本起步

它常见于：

  • 中小规模产品
  • 强事务业务旁路检索
  • 原型到生产的渐进演进

17.2 Pinecone ​

Pinecone 的心智更偏：

  • 专门化向量检索服务
  • 更直接地围绕 records、indexes、namespaces、filters 做工程

适合：

  • 想更专注做检索面治理
  • 不想自己深管底层基础设施

17.3 Weaviate ​

Weaviate 的特征通常更偏：

  • 向量检索 + schema / class / filter / hybrid 的完整能力面

适合：

  • 想把对象建模、搜索和多样能力放在统一系统里

17.4 Qdrant ​

Qdrant 常被团队看重的点包括：

  • filter 能力
  • 多向量 / payload 建模
  • 对检索控制面的强调

17.5 Milvus ​

Milvus 更常出现在：

  • 大规模向量检索
  • 专门检索基础设施场景

17.6 OpenSearch / Elasticsearch ​

如果你们原本就很依赖：

  • 关键词检索
  • 复杂过滤
  • 日志 / 文档搜索栈

那向量能力和 lexical 能力结合起来，常常会更自然。

17.7 不要按“功能列表”选，要按系统边界选 ​

真正该问的问题通常是：

  • 你们是从数据库出发，还是从检索平台出发
  • 多租户是否强隔离
  • metadata filter 有多重
  • hybrid search 占多大比重
  • 更新频率高不高
  • 团队是否愿意维护底层索引运营

18. 怎么判断检索质量到底好不好 ​

向量数据库本身不会告诉你“业务是否搜对了”。

你需要自己建立评测口径。

18.1 召回层指标 ​

常见包括：

  • recall@k
  • hit@k
  • MRR

18.2 排序层指标 ​

如果有 rerank，可看：

  • NDCG
  • precision@k

18.3 业务层指标 ​

真实业务更应该关心：

  • 最终回答引用正确率
  • 命中正确文档率
  • 串租率
  • 过期文档命中率

18.4 运行层指标 ​

还应同时看：

  • P95 延迟
  • filter 失败率
  • 更新后可见时延
  • 索引重建时稳定性

19. 检索效果差时，排查顺序比“盲调参数”更重要 ​

一个更实用的排查顺序通常是：

  1. 先看 query 是否表达清楚
  2. 再看 embedding 是否合适
  3. 再看 chunk 是否合理
  4. 再看 filter 是否过宽或过窄
  5. 再看 ANN 参数与索引配置
  6. 再看是否需要 hybrid 和 rerank

很多团队一出问题就直接调：

  • top-k
  • HNSW 参数
  • probe 数

但如果根因其实在：

  • chunk 太差
  • metadata 缺失
  • 旧版本没下线

那你调再多索引参数也很难根治。

20. 典型故障信号与排查顺序 ​

20.1 命中了语义相近但业务错误的内容 ​

优先看：

  • filter 是否缺失
  • metadata 是否不够
  • 是否缺少关键词或 rerank

20.2 总能搜到旧版本 ​

优先看：

  • 版本字段
  • 删除策略
  • 更新可见性
  • 新旧索引切换方式

20.3 多租户偶发串数 ​

优先看：

  • namespace / collection 规划
  • tenant filter 是否强制
  • 缓存 key 是否带 tenant 信息

20.4 速度还行，但最终答案效果不好 ​

优先看：

  • 召回候选是否本来就错
  • rerank 是否缺失
  • 证据拼装是否太噪

20.5 新数据写进来却搜不到 ​

优先看：

  • 写入路径是否真正完成
  • 索引刷新 / build 状态
  • filter 字段是否填错

21. 上线前最值得确认的检查项 ​

如果你们准备把向量检索放进生产，至少建议确认：

  1. embedding 模型与距离度量是否匹配
  2. 是否保留 exact baseline 做回放
  3. chunk、ID、metadata 设计是否可回放
  4. 多租户边界是否在检索层落地
  5. 新鲜度、版本、删除策略是否明确
  6. 是否支持 hybrid 或 rerank 的升级空间
  7. 任务级评测指标是否建立
  8. 索引重建与回滚策略是否明确

22. 一句话总结 ​

向量数据库不是“把 embedding 存起来”的组件，它更像：

  • 一个负责语义召回、结构化过滤、租户边界、更新新鲜度和检索评测的基础设施层

23. 推荐阅读 ​

24. 重点官方资源 ​