Wiki Notes

Appearance

向量数据库专题 ​

版本：v1.8

最后更新：2026-07-09

适用对象：正在做 RAG、知识检索、企业搜索、File Search 对照方案、多租户知识平台，以及需要决定“什么时候该上专门向量数据库、怎么设计索引、怎么做权限和成本权衡”的工程团队

很多人学习 RAG 时，会把“embedding + 向量库”看成一个固定配方。

但真实工程里更重要的问题其实是：

  • 向量到底存在哪里
  • 检索时除了相似度还要不要做过滤
  • 什么时候该用专门向量数据库，什么时候不需要
  • 向量库和文档流水线、权限、版本、缓存是什么关系
  • 多租户、混合检索、重排、回滚、删除这些问题，应该在什么层解决

这篇专题不是把向量数据库写成算法入门，而是从生产工程视角解释：

  • 向量数据库究竟在 RAG 系统里承担什么职责

1. 先摆正位置：向量数据库不是 RAG 本身，只是检索底座之一 ​

一个完整的 RAG 链路通常更接近：

text
Source Documents
 -> Parsing / Structuring
 -> Chunking
 -> Embeddings
 -> Index / Vector Store
 -> Filtering / Hybrid Search / Rerank
 -> Prompt Assembly
 -> Generation
 -> Citation / Evaluation / Feedback

向量数据库主要负责的是：

  • 存储向量表示
  • 组织检索索引
  • 支持相似度查询
  • 结合 metadata 过滤
  • 承载更新、删除、多租户和性能优化

它非常重要，但它绝不是：

  • 文档治理本身
  • 权限模型本身
  • 回答质量本身

2. 什么情况下需要专门向量数据库 ​

如果只是下面这些场景，你未必需要单独上向量数据库：

  • 小规模 Demo
  • 单租户内部试验
  • 文档量很小
  • 离线分析
  • 批处理脚本

这类场景先用：

  • OpenAI 托管 vector stores
  • 带向量能力的现有数据库
  • 本地索引

通常更简单。

2.1 什么时候“明显需要” ​

一旦出现这些特征，专门向量数据库的价值就会迅速放大：

  • chunk 总量很大
  • 查询量和并发上升
  • 需要 metadata filtering
  • 需要租户隔离
  • 需要增量更新、批量删除、回滚
  • 需要 hybrid search
  • 需要成本、延迟、召回率的细致调优

3. 向量数据库最核心的四个职责 ​

3.1 相似度检索 ​

根据查询向量找最相近的候选结果。

3.2 元数据过滤 ​

在向量检索前后结合业务字段做过滤，例如：

  • 只查某租户
  • 只查某部门
  • 只查生效中的文档
  • 只查某种文档类型

3.3 更新与删除 ​

支持：

  • upsert
  • delete
  • metadata 更新
  • 重建索引

3.4 多租户与资源隔离 ​

支持：

  • namespace / collection / tenant 级隔离
  • 资源和成本可控
  • 按租户治理生命周期

4. 向量数据库里真正需要建模的不是“向量”，而是“记录” ​

一个生产级向量记录通常不只是向量本身，而是：

  • id
  • vector
  • metadata
  • namespace / tenant
  • version_id
  • document_id
  • chunk_id

Pinecone 当前官方文档在 2026-07-08 反复强调：

  • 记录至少包含 ID 和向量
  • metadata 用于存储附加上下文
  • 查询时可以通过 metadata filter 缩小搜索范围

这意味着工程上真正要设计的是：

  • “一条可检索记录如何映射到知识对象”

而不是只想“向量怎么存”。

5. 为什么 metadata 往往比算法名更值得先设计 ​

很多团队刚接触向量库时会先问：

  • HNSW 还是别的
  • ANN 还是精确检索

但在企业知识系统里，更早应该回答的问题通常是：

  • document_id 怎么定义
  • chunk_id 怎么定义
  • version_id 怎么定义
  • 哪些字段参与过滤
  • 哪些字段用于追踪
  • 哪些字段用于权限和租户隔离

如果 metadata 没设计好，后续会非常难做：

  • 权限继承
  • 精细过滤
  • 版本清理
  • 删除传播
  • 回答回溯

6. 记录 ID 应该怎么设计 ​

Pinecone 当前 production checklist 与 data modeling 文档都明确强调：

  • 使用结构化 ID 更利于高效运维，例如 document_id#chunk_number

这条建议非常实用，因为它会直接影响：

  • 批量 upsert
  • 批量删除
  • 版本清理
  • 问题排查

一个常见的可用模式：

text
tenant_id/document_id/version_id/chunk_id

或者：

text
document_id#version_id#chunk_000123

核心不是格式统一好看，而是要支持：

  • 能快速定位一批兄弟块
  • 能按文档或版本批量处理
  • 出事时人能读懂

7. 向量库选型时最容易忽视的，是“过滤”和“租户”不是附属能力 ​

很多 Demo 只验证：

  • query 向量进去，top-k 出来

但企业环境里更关键的是：

  • 先过滤，再检索还是检索后过滤
  • namespace 和 metadata filter 怎么配合
  • 不同租户数据是否天然隔离
  • 复杂权限是不是会把查询成本拖垮

7.1 Pinecone 给出的启发 ​

Pinecone 当前官方文档在 2026-07-08 的要点非常明确：

  • 多租户最有效的方式通常是用 namespaces
  • 如果只是把所有数据塞进一个空间，再靠 metadata 过滤租户，会带来性能和成本权衡

这说明对多租户知识平台来说，租户建模不能拖到后面再补。

7.2 Azure AI Search 给出的启发 ​

Azure AI Search 当前官方文档强调：

  • hybrid search 是在单个请求里并行跑全文和向量查询
  • 可同时使用过滤、排序、facet、语义重排

这对工程的启发是：

  • 企业检索往往不是“只做向量最近邻”就结束，而是和文本、过滤、重排一起组成完整查询计划

8. 为什么纯向量检索往往不够 ​

根据 OpenAI 当前 File search 文档以及 Azure AI Search 当前 hybrid search 文档的说明：

  • OpenAI File Search 会同时用 semantic + keyword search
  • Azure hybrid search 会并行跑全文检索和向量检索，再用 RRF 合并

这说明一件很重要的事：

  • 生产检索并不迷信“纯向量”

原因很现实：

  • 产品型号
  • 人名
  • 编号
  • 规则编号
  • 错误码
  • 日期

这些内容常常需要关键词精确匹配。

更实用的结论通常是：

  • 语义负责“概念相近”
  • 关键词负责“字面精确”
  • 过滤负责“范围正确”
  • rerank 负责“排序更稳”

9. 向量索引类型到底怎么理解 ​

很多人第一次接触会被各种索引名吓住。

更实用的理解是把它们看成一组权衡：

  • 召回率
  • 查询延迟
  • 写入成本
  • 内存占用
  • 更新便利性

9.1 Weaviate 当前文档给出的一个非常实用的视角 ​

Weaviate 当前官方文档说明：

  • 支持 hnsw、flat、dynamic 等索引类型
  • dynamic 会从 flat 起步，在达到阈值后切换到 HNSW
  • 多租户场景常适合动态索引，因为不同租户规模差异很大

这说明选型时不要只问：

  • “哪个算法最好”

更应该问：

  • “我们的数据规模和租户形态，更适合什么资源模型”

9.2 一个实用的经验判断 ​

  • 小集合、小租户：简单索引可能已经够用
  • 中大规模：更需要 ANN 索引
  • 多租户差异极大：更要考虑动态索引或分层策略

10. 命名向量、多向量和多索引什么时候有价值 ​

Weaviate 当前文档还提到：

  • 一个对象可以有多个 named vectors
  • 每个向量空间可以使用不同配置、不同向量器、不同距离度量

这对复杂知识系统很有价值，因为很多对象天然有多种表示：

  • 标题语义向量
  • 正文语义向量
  • 表格语义向量
  • 图片描述向量
  • 多语言向量

多向量不是必须，但当你遇到这些问题时通常值得考虑：

  • 标题和正文检索意图差异很大
  • 文本和结构化字段要分别建模
  • 多语言、多模态检索需求明显

11. 多租户该用 namespace、metadata 还是独立索引 ​

这是企业最常问的问题之一。

11.1 namespace 方案 ​

更适合：

  • 强租户隔离
  • 每次查询只查单租户或少量租户
  • 希望更低查询噪音和更清晰生命周期边界

Pinecone 当前文档明确推荐多租户优先考虑 namespace。

11.2 metadata 过滤方案 ​

更适合：

  • 需要跨租户分析
  • 隔离要求没那么严格
  • 租户只是查询条件的一部分

但要认识到它的代价：

  • 查询开销可能更高
  • 大过滤条件会带来复杂度
  • 生命周期和成本边界不如 namespace 清晰

11.3 独立索引方案 ​

适合：

  • 超大客户单独隔离
  • 合规要求极强
  • 资源和容量模型完全不同

但运维复杂度也明显更高。

12. 删除、更新、回滚为什么是向量库设计的关键部分 ​

很多团队在选型时只测查询，不测：

  • 批量 upsert
  • 批量 metadata 更新
  • 批量删除
  • 旧版本清理
  • 索引重建窗口

但这些才是生产系统最常见的真实操作。

12.1 你至少要确认这些问题 ​

  • 更新是整文重建还是 chunk 增量
  • 删除是按 ID、按文档、按 metadata 还是按 namespace
  • 旧版本怎样快速退出检索
  • 回滚时能否恢复上一版本索引

12.2 Pinecone 的一个重要工程提醒 ​

Pinecone 当前文档说明：

  • 可以按 metadata 更新记录
  • metadata filter 的能力很强，但超大过滤条件也会有明确限制和成本边界

这意味着：

  • 不要把“权限控制”和“大规模运营动作”完全寄托在超重 metadata 过滤表达式上

13. 向量数据库如何和文档流水线配合 ​

更稳的职责切分通常是：

文档流水线负责 ​

  • 来源同步
  • 结构解析
  • chunking
  • metadata 生产
  • 权限继承
  • 生命周期状态

向量数据库负责 ​

  • 向量 / 索引存储
  • 检索执行
  • 过滤能力
  • 更新 / 删除执行面
  • 性能与成本优化

如果让向量库承担“整个知识治理”，通常会越来越乱。

14. 选型时除了召回率，还应该比较什么 ​

建议至少比较下面这些维度：

14.1 数据模型 ​

  • 是否支持结构化 metadata
  • metadata 过滤能力是否够用
  • 是否方便表示文档版本、租户、状态

14.2 检索能力 ​

  • 纯向量
  • hybrid
  • rerank 集成
  • 多向量 / named vectors

14.3 多租户与权限 ​

  • namespace / tenant 模型是否清晰
  • 是否支持按租户建索引边界
  • 跨租户查询如何处理

14.4 运维能力 ​

  • 备份
  • 恢复
  • 迁移
  • 重建
  • 监控
  • 扩缩容

14.5 成本模型 ​

  • 存储成本
  • 写入成本
  • 查询成本
  • 冷热分层能力

如果只比 top-k 样例，看不出生产差异。

14.6 架构形态与生态位 ​

“向量数据库”这个词很容易把不同东西混在一起讲，但从当前官方资料看，至少要区分十几种形态：

  • 托管型向量数据库，例如 Pinecone
  • 托管 Milvus 路线，例如 Zilliz Cloud
  • 向量 + 搜索一体化引擎，例如 Azure AI Search、Weaviate
  • 云厂商托管向量检索服务，例如 Gemini Enterprise Agent Platform Vector Search
  • 搜索平台内置向量能力，例如 Elasticsearch、OpenSearch、Vespa、Apache Solr
  • 分布式向量基础设施，例如 Milvus、Qdrant
  • 宽列数据库内置向量能力，例如 ScyllaDB
  • 云原生 / Kubernetes 原生向量引擎，例如 Vald
  • 开发者友好 / local-first 向量存储，例如 Chroma
  • 开发者友好搜索 API / 轻量搜索引擎，例如 Meilisearch、Typesense
  • API 原生 / 宽列系 serverless 向量数据库，例如 Astra DB
  • 文档数据库内置向量能力，例如 MongoDB Atlas Vector Search
  • JSON 文档数据库内置向量能力，例如 Azure Cosmos DB
  • 文档数据库 + 搜索服务一体，例如 Couchbase
  • 内存型实时向量能力，例如 Redis
  • 图数据库内置向量能力，例如 Neo4j
  • 关系数据库扩展，例如 pgvector
  • 托管 PostgreSQL / 兼容 Postgres AI 数据库，例如 AlloyDB AI、Azure Database for PostgreSQL、Neon
  • 托管 Postgres AI 平台，例如 Supabase（底层仍是 pgvector）
  • SQLite / edge 原生向量数据库，例如 Turso / libSQL
  • Postgres + 实时分析 + 向量一体化路线，例如 Tiger Data
  • 分析型 / HTAP SQL 引擎，例如 ClickHouse、SingleStore、TiDB
  • 湖仓 / 数据平台内检索，例如 Databricks AI Search
  • 数据云 / 云数仓内搜索服务，例如 Snowflake Cortex Search
  • 实时 / 时序向量数据库，例如 KDB.AI
  • 边缘向量数据库，例如 Cloudflare Vectorize
  • 对象存储原生 serverless 检索，例如 Turbopuffer
  • 企业数据库内置向量能力，例如 Oracle AI Vector Search
  • 搜索 API / 产品化检索引擎，例如 Typesense
  • 本地 / 湖仓型嵌入式检索，例如 LanceDB
  • 本地 ANN 库，例如 FAISS

如果只把这些名字平铺出来，还是很难选。更实用的办法是先按“系统边界”分层：

14.6.1 Postgres 路线：优先复用事务边界和现有数据模型 ​

这一路最典型的是：

  • pgvector
  • Supabase
  • Neon
  • AlloyDB AI
  • Azure Database for PostgreSQL 上的 pgvector / DiskANN
  • Tiger Data

这条路线更适合：

  • 业务主数据本来就在 Postgres
  • 你希望向量和业务记录共用同一套表、事务、迁移和备份体系
  • 初期更重视工程一致性，而不是独立检索集群能力

pgvector 当前官方 README 仍把 HNSW 和 IVFFlat 作为核心索引类型来讲，这类方案的优势不是“功能最花”，而是：

  • 开发团队学习成本低
  • 权限、审计、备份、运维链路复用现有数据库体系
  • 适合中小规模、强业务一致性、少一层基础设施的团队

但这条路线也要提前接受它的边界：

  • 大规模 ANN 调优通常没有专用检索底座那么细
  • 混合检索、重排、多租户隔离往往要靠你自己补更多工程设计

14.6.2 搜索引擎路线：把全文、过滤、聚合、向量放进同一个查询平面 ​

这一类更像：

  • Azure AI Search
  • Elasticsearch
  • OpenSearch
  • Vespa
  • Apache Solr
  • Meilisearch
  • Typesense

这类系统的价值，不只是“也能存向量”，而是天然把下面这些能力放在一起：

  • 倒排全文检索
  • 过滤、facet、聚合
  • hybrid search
  • rerank / rank fusion
  • 更成熟的企业搜索查询平面

Azure AI Search 当前官方文档明确把 hybrid search 定义成：

  • 在单个请求里并行执行全文与向量查询
  • 通过 RRF 合并结果

Elasticsearch、OpenSearch、Vespa 的当前官方资料也都强调：

  • 向量检索应和原生 query/filter/aggregation 一起设计

所以如果你的核心问题是：

  • 企业搜索
  • 电商 / 内容搜索
  • 需要 facet、过滤、运营检索配置
  • 需要把关键词精确命中和语义召回同时做好

那“搜索引擎路线”通常会比“只找一个专用向量库”更自然。

14.6.3 专用向量基础设施路线：优先考虑检索底座能力和独立扩展 ​

这一类更接近：

  • Pinecone
  • Qdrant
  • Milvus
  • Weaviate
  • Vald

这些系统更强调：

  • ANN 检索本身
  • collection / namespace / shard / replica 等检索底座能力
  • 向量字段、多向量、压缩、索引类型
  • 独立于事务数据库之外扩容

Pinecone 当前官方文档持续强调：

  • namespace 对多租户的性能和成本意义很大

Qdrant 当前官方文档则把多租户拆得更细：

  • 单 collection + payload 分区
  • tiered multitenancy
  • 大租户独立 shard，小租户共享 shard

Milvus 当前官方文档则更突出：

  • 多向量字段
  • hybrid search
  • 面向更大规模检索基础设施的能力

如果你的团队是在做：

  • 独立知识平台
  • AI 检索中台
  • 多业务线共享的向量底座
  • 明显需要单独扩缩容的高吞吐检索集群

这条路线会更合适。

14.6.4 本地 / 嵌入式 / data-lake 路线：优先开发体验、可移植性和数据就近 ​

这类典型代表包括：

  • Chroma
  • LanceDB
  • FAISS

它们并不一定适合直接承担大型生产多租户平台，但非常适合：

  • 本地原型
  • 单机评测
  • notebook / pipeline 场景
  • 数据科学和多模态实验

LanceDB 当前官方资料强调 hybrid search 与多模态检索，说明它更像：

  • 面向开发者和数据工作流的“检索构件”

而不是所有团队都该拿来替代完整企业搜索平台。

14.6.5 数据平台 / 实时系统路线：当检索必须贴着现有数据基础设施 ​

还有一类经常被漏掉，但在企业里非常常见：

  • MongoDB Atlas Vector Search
  • Couchbase Vector Search
  • Redis Vector Search
  • ClickHouse
  • SingleStore
  • TiDB
  • Databricks AI Search
  • Snowflake Cortex Search
  • Cloudflare Vectorize
  • Turbopuffer
  • Oracle AI Vector Search
  • KDB.AI

这些方案的共同点不是“都一样”，而是：

  • 你本来就已经站在某个数据或实时平台上
  • 你更在意数据就近、运维复用、现有团队技能和治理边界

例如：

  • MongoDB / Couchbase 适合文档数据和业务对象本来就在那里
  • Redis 更适合高实时、低延迟、缓存和在线特征贴近的场景
  • ClickHouse / SingleStore / TiDB 更像把向量能力带进分析型或 HTAP 引擎
  • Snowflake / Databricks 更适合把检索接进现有数据云与治理体系

这几类方案并不在同一层竞争。更实用的做法通常不是问“谁最好”，而是先问：

  1. 你需要的是独立检索底座，还是企业搜索引擎。
  2. 你要不要把向量和业务记录放在同一个事务边界里。
  3. 团队是否有能力长期承接集群、快照、恢复和容量治理。

这也是为什么现在很多团队第一步并不是新建一个“独立向量库品牌池”，而是先看自己究竟更适合沿 Postgres、数据云、搜索平台，还是 独立检索底座 这条路继续演进。

如果你正在做具体产品选型，可以直接配合阅读：

15. 企业最值得观察的向量检索指标 ​

15.1 质量类 ​

  • 检索命中率
  • 引用可用率
  • 混合检索胜率
  • rerank 提升幅度

15.2 稳定性类 ​

  • P95 / P99 查询延迟
  • 查询超时率
  • 批量 upsert 失败率
  • 删除完成时长

15.3 治理类 ​

  • 旧版本残留召回率
  • 权限误召回率
  • 无 metadata 记录比例
  • namespace / tenant 配置异常数

16. 最常见的误区 ​

  • 把所有问题都归因于向量库
  • 没有 metadata 设计就开始堆向量
  • 只做语义检索，不做关键词、过滤、重排
  • embedding 模型换了却不重建索引
  • 所有租户混放，再用复杂过滤兜底
  • 不测试删除、更新、回滚
  • 不记录版本和文档映射
  • 用单次 Demo 查询代替生产评测

17. 建议的学习与落地顺序 ​

  1. 先理解 RAG 详解 和 Embeddings 详解。
  2. 再理解文档流水线、chunking、metadata 和生命周期。
  3. 然后再看向量数据库的数据模型、过滤、租户和索引类型。
  4. 最后再做 hybrid、rerank、多向量和成本优化。

这个顺序很重要，因为：

  • 大量所谓“向量库问题”，本质上其实是前置数据建模问题

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：