Wiki Notes

Appearance

向量数据库专题索引 ​

版本：v1.13

最后更新：2026-07-09

这一组文档主要解释：向量数据库到底解决什么问题、为什么 RAG 系统离不开它，以及索引、过滤、混合检索、更新、租户隔离和运维该怎么理解。

很多团队第一次做 RAG，会把“向量数据库”理解成一个黑盒组件：

  • 文档切片
  • 算 embedding
  • 存进去
  • 查 top-k

Demo 阶段这样想勉强够用，但一进企业场景就会马上遇到这些问题：

  • 为什么编号、错误码、产品名经常搜不到
  • 为什么租户隔离一开始没设计，后面补起来很痛
  • 为什么文档更新以后老 chunk 还在污染结果
  • 为什么同一个问题换一种问法，命中完全不一样
  • 为什么召回看着有结果，最终答案却仍然不可信

OpenAI Retrieval / File search、Pinecone Data modeling / Production checklist / Implement multitenancy、Azure AI Search Hybrid search / Vector relevance and ranking、Weaviate Hybrid search / Multi-tenancy 的当前官方资料都在反复说明同一件事：

向量数据库不是完整 RAG，它解决的是“索引、召回、过滤、隔离、可追溯性”这一段基础设施。

1. 先建立一个不容易跑偏的心智模型 ​

你可以把向量数据库放在下面这条链路里理解：

  1. 原始文档进入清洗与切片流水线。
  2. 每个 chunk 生成向量，并附带 metadata。
  3. 向量库或检索引擎建立索引。
  4. 查询进入向量检索、关键词检索、metadata 过滤和重排。
  5. 结果回到上层做证据组装、引用、答案生成与评测。

也就是说，向量数据库真正负责的是：

  • 把知识对象变成可检索索引
  • 支持基于相似度的召回
  • 配合 metadata 做过滤、租户隔离和追溯
  • 为上层重排、引用和生成提供候选证据

而它不直接负责：

  • 业务问题是否定义清楚
  • 文档是否切得合理
  • 检索证据是否足够可信
  • 最终答案是否正确
  • 错误能否回溯到具体环节

这也是为什么很多“RAG 不准”问题，根因并不在向量库本身。

2. 官方资料现在更强调什么 ​

根据 2026-07-09 可访问的官方资料，几个关键信号很值得注意：

  • OpenAI Retrieval 把向量存储明确当成你的数据索引层，语义搜索返回的是相关 chunk、相似度分数和来源文件。
  • OpenAI File search 明确说明它是托管式工具，并且会同时利用 semantic + keyword search 来找知识，而不是只做纯向量召回。
  • Azure AI Search 把 hybrid search 定义成同一请求里并行跑全文检索与向量检索，再用 RRF 合并结果；同时把 hybrid + semantic reranker 当成提高相关性的核心路径。
  • Pinecone 当前把 structured IDs、metadata、traceability、namespaces、data freshness 都放在数据建模与生产清单里，这说明生产问题常常出在数据结构和租户隔离，不只是 ANN 算法。
  • Weaviate 当前除了 hybrid search，还很强调 named vectors、multi-target vector search、multi-tenancy 与 tenant states，适合需要多表示空间和分层资源治理的场景。
  • Qdrant 当前把 payload filtering、hybrid queries、multitenancy、snapshots 和 edge 形态一起展开，说明它更强调“检索底座 + 可控部署 + 恢复路径”。
  • Milvus 当前把 filtered search、partition key、consistency、multi-vector hybrid search 放在核心用户路径里，说明它更偏大规模向量基础设施，而不是只讲 ANN 算法。
  • pgvector 和 FAISS 的官方资料则提醒了另一个现实：向量能力不一定要落在独立数据库里，也可能分别落在现有 PostgreSQL 体系和本地 ANN 库里。
  • Elasticsearch / OpenSearch / Vespa、MongoDB Vector Search、Redis、Neo4j、LanceDB 的当前官方资料则进一步提醒：向量能力还可能落在搜索平台、文档数据库、缓存层、图数据库和本地湖仓工作流里，而不是一定要单独新建一套“专门向量库”。
  • Chroma、Astra DB、ClickHouse、SingleStore、TiDB、Couchbase、Supabase 的当前官方资料则把另一层现实讲得更清楚了：向量能力正在快速进入 local-first 工具链、API 原生 serverless 数据平台、SQL / HTAP 引擎、文档数据库搜索服务，以及托管 Postgres 应用平台。
  • AlloyDB AI、Azure Database for PostgreSQL、Neon 的当前官方资料把另一层现实讲得更清楚了：向量能力正在快速进入托管 PostgreSQL / 兼容 Postgres 的 AI 数据库路线，而不是只停留在“裸 pgvector 扩展”。
  • Databricks AI Search、Snowflake Cortex Search、Cloudflare Vectorize、Turbopuffer、Oracle AI Vector Search、Typesense、Meilisearch、Apache Solr、Vald、KDB.AI 的当前官方资料又补上了另一组生态位：湖仓 / 数据平台内检索、数据云内搜索服务、边缘向量数据库、对象存储原生 serverless 检索、企业数据库内置向量能力、开发者友好的搜索 API、经典企业搜索平台、云原生向量引擎，以及实时 / 时序向量路线。

这几个方向放在一起看，结论很清楚：

企业检索系统比起“向量库选哪家”，更应该先想清楚索引对象、元数据、混合检索、权限边界、新鲜度，以及自己到底需要哪一种架构形态。

3. 推荐阅读顺序 ​

3.1 想先理解向量检索为什么存在 ​

  1. 01-向量数据库详解
  2. 02-ANN 索引与召回权衡
  3. LLM专题 / 01-RAG详解
  4. LLM专题 / 02-Embeddings详解

3.2 想把它接进企业知识系统 ​

  1. 知识库与检索
  2. 05-主流方案、架构形态与选型清单
  3. 06-部署形态、容量规划与成本治理
  4. 01-向量数据库详解
  5. 03-多租户、过滤与版本治理
  6. 平台工程

3.3 想补检索治理和评测 ​

  1. 知识库与检索
  2. 04-混合检索、重排与评测
  3. 评测运营与案例
  4. LLM 与生产化总目录

3.4 想看多租户和权限边界 ​

  1. 03-多租户、过滤与版本治理
  2. 知识权限继承专题
  3. 企业权限模型专题
  4. 多租户架构专题

3.5 想补部署、容量和成本运营 ​

  1. 06-部署形态、容量规划与成本治理
  2. 05-主流方案、架构形态与选型清单
  3. 03-多租户、过滤与版本治理
  4. 平台工程
  5. AI成本治理案例专题

3.6 这组专题现在包含什么 ​

  1. 01-向量数据库详解：负责建立向量数据库在 RAG 里的职责边界、metadata、hybrid、版本与运维心智模型。
  2. 02-ANN 索引与召回权衡：负责解释 exact / approximate、HNSW / IVF / Flat、过滤交互、量化压缩、参数调优与 exact baseline 之间的工程权衡。
  3. 03-多租户、过滤与版本治理：负责讲 namespace、collection、payload / metadata、权限边界、filter 前后置、tenant states、删除验收、snapshot / rollback 和版本谱系。
  4. 04-混合检索、重排与评测：负责讲 hybrid search、RRF、rerank、候选池、query rewrite 和分层评测。
  5. 05-主流方案、架构形态与选型清单：负责把 Pinecone、Weaviate、Qdrant、Milvus、Azure AI Search、pgvector、FAISS，以及 Elasticsearch / OpenSearch / Apache Solr / MongoDB Atlas / Redis / Neo4j / Vespa / LanceDB / Chroma / Astra DB / ClickHouse / SingleStore / TiDB / Couchbase / Supabase / AlloyDB AI / Azure Database for PostgreSQL / Neon / Databricks AI Search / Snowflake Cortex Search / Cloudflare Vectorize / Turbopuffer / Oracle AI Vector Search / Typesense / Meilisearch / Vald / KDB.AI / Zilliz Cloud / Gemini Enterprise Agent Platform Vector Search / Azure Cosmos DB / ScyllaDB / Turso / Tiger Data 放回各自正确的架构生态位里比较。
  6. 06-部署形态、容量规划与成本治理：负责把 namespace、partition、冷热分层、重嵌入、snapshot / restore、成本拆账和容量看板放回真实运维语境里理解。

4. 这组内容最值得先建立的几个共识 ​

4.1 向量数据库解决的是“召回基础设施”，不是完整 RAG ​

真正的 RAG 还要包含切片、查询改写、过滤、重排、引用设计、失败复盘和知识治理。

4.2 metadata 设计通常和 embedding 模型同样重要 ​

Pinecone 当前官方资料把 structured IDs、metadata、traceability、filtering 放在一起讲；Azure AI Search 和 Weaviate 也都把向量、全文、过滤和重排放在同一条检索链路里。换句话说，很多“检索不准”问题并不是 embedding 差，而是字段设计、过滤条件和索引对象设计不对。

4.3 混合检索比纯向量更接近企业现实 ​

Azure AI Search 当前把 hybrid search 描述为并行执行全文检索和向量检索，再用 RRF 融合结果；OpenAI File search 也说明它结合语义与关键词信号。对企业知识来说，编号、错误码、合同号、角色名、日期和产品名都很难只靠语义相似度解决。

4.4 租户隔离和更新策略往往比索引名字更影响上线成败 ​

Pinecone 当前把 namespace per tenant、avoid filtering by high-cardinality IDs、data freshness 单独展开。Weaviate 也把 multi-tenancy 做成显式能力。企业里最容易出问题的，往往不是 HNSW 还是 IVF，而是：

  • 权限边界是不是在检索层就生效
  • 文档更新后旧 chunk 会不会残留
  • 父文档、chunk、版本之间是不是能追溯
  • 下线租户或不活跃租户怎么做资源治理

4.5 同一个 embedding 模型空间要保持一致 ​

Azure AI Search 当前官方资料明确提到，查询向量应处在和索引向量相同的 embedding space。实际工程里这意味着：

  • 建库和查询不要混用不兼容的 embedding 模型
  • 模型切换通常意味着重建索引或至少重嵌入
  • 多语言、多模态、多字段场景要明确每个向量空间服务什么检索目标

4.6 “向量数据库”正在扩成一整片能力地带 ​

从 2026-07-09 复核到的官方资料看，团队已经不该把“向量数据库”只理解成几个独立新厂商：

  • local-first 工具链里有 Chroma
  • API 原生 serverless 数据平台里有 Astra DB
  • SQL / HTAP 体系里有 ClickHouse、SingleStore、TiDB
  • 文档数据库搜索服务里有 Couchbase
  • 托管 Postgres 应用平台里有 Supabase + pgvector
  • 托管 PostgreSQL / 兼容 Postgres AI 数据库里有 AlloyDB AI、Azure Database for PostgreSQL、Neon
  • 湖仓 / 数据平台内检索里有 Databricks AI Search
  • 数据云内搜索服务里有 Snowflake Cortex Search
  • 边缘向量数据库里有 Cloudflare Vectorize
  • 对象存储原生 serverless 检索里有 Turbopuffer
  • 企业数据库内置向量能力里有 Oracle AI Vector Search
  • 开发者友好的搜索 API 路线里有 Typesense

这带来的工程启发很直接：

  • 选型时先看你现有系统长什么样
  • 再看向量能力该长在搜索层、数据库层、应用平台层，还是独立检索底座层

5. 企业场景最常见的七个设计决定 ​

5.1 chunk 粒度怎么定 ​

太大，召回证据会脏；太小，证据上下文会碎。向量库表现好坏，经常先取决于 chunk 设计，而不是索引算法。

建议至少明确：

  • 是按段落、标题块、页面还是语义块切片
  • 是否保留父文档标题、章节路径、页码
  • 是否需要 overlap
  • 是否要对表格、代码块、FAQ、制度条文单独切

5.2 _id 和父子关系怎么设计 ​

Pinecone 当前生产清单建议使用 structured IDs，这背后很有工程价值。一个可追溯的 ID 设计，通常会包含：

  • 文档 ID
  • 版本号
  • chunk 序号
  • 语言或租户维度

这样做的意义是：

  • 更新整篇文档时更容易批量替换
  • 删除旧版本时更容易定位
  • 回答出错时更容易回放到原始 chunk

5.3 metadata 到底要带哪些字段 ​

至少要提前想清楚这些字段：

  • tenant / namespace
  • 文档类型
  • 来源系统
  • owner
  • 权限组
  • 生效时间与失效时间
  • 版本号
  • 父文档 ID
  • 语言
  • 更新时间

很多“查不准”和“串数”问题，根源都在 metadata 不够。

5.4 一开始要不要上 hybrid search ​

如果业务里有这些强关键词信号，通常就不该只做纯向量检索：

  • 编号
  • 产品名
  • 报错码
  • 接口名
  • 工单号
  • 人名 / 组织名
  • 日期与版本

这类场景里，pure vector 往往会召回“语义相近但不是你要的那一条”。

5.5 namespace、filter、权限组该怎么取舍 ​

Pinecone 当前明确建议多租户强隔离优先考虑 namespace，而不是对海量高基数个人 ID 直接过滤。更稳的做法通常是：

  • 强租户隔离：tenant -> namespace
  • 组级权限：metadata filter
  • 个人级细粒度授权：尽量转成 access group 或后置精筛，而不是把超大 user ID 列表直接塞进检索过滤

5.6 要不要做多向量或多索引 ​

Weaviate 当前的 named vectors、multi-target vector search 很适合这些场景：

  • 标题和正文希望用不同向量表示
  • 中英文或多语种需要不同向量配置
  • 图文、多模态知识对象需要多个表示空间
  • 一个对象既要服务 FAQ 召回，也要服务长文 grounding

如果你的知识对象天然有多种检索目标，就不要默认“一条文本一个向量”永远够用。

5.7 更新和删除怎么做 ​

如果不先想清楚整文重建、旧版本删除和新鲜度策略，检索系统很容易长期带着脏数据运行。

至少要先回答：

  1. 文档更新是整文重嵌入，还是增量重嵌入。
  2. 历史版本保留多久。
  3. 同一个父文档是否允许多版本共存。
  4. 结果里怎么判断“过期但仍可追溯”。
  5. 答案错误后能否快速查到对应 chunk 来撤回。

6. 第一版 RAG 和企业级检索，关注点有什么不同 ​

阶段最关心什么常见误区更合理的做法
Demo / POC先跑通召回和答案生成只看“能不能答出来”先留 query、top-k、chunk 命中和原文引用
第一版业务上线证据稳定性和失败复盘只看平均命中率开始按 query 类型分桶评测
企业知识系统权限、版本、新鲜度、租户隔离所有数据混一个索引设计 namespace、metadata、版本链路
平台化阶段成本、吞吐、回放、治理只盯延迟同时看召回质量、更新效率、资源隔离

7. 出问题时该怎么排查 ​

推荐按下面顺序排，而不是一上来就怪模型：

7.1 先看数据有没有进来 ​

  • 原始文档是否入库
  • 是否切片成功
  • 是否被错误过滤
  • 更新时间是否落后

7.2 再看向量和索引是否一致 ​

  • embedding 模型是否一致
  • 查询向量和索引向量是否处在同一空间
  • 向量维度是否匹配
  • 重建索引后旧数据是否仍残留

7.3 再看过滤和租户边界 ​

  • namespace 是否打对
  • metadata filter 是否过严或过松
  • 权限组是否覆盖正确
  • 是否出现租户串数

7.4 再看召回和融合 ​

  • top-k 是否过小
  • 是否只做 pure vector
  • 是否缺少关键词召回
  • 是否缺少 rerank 或证据打分

7.5 最后再看生成层 ​

  • 引用片段是否被错误拼接
  • prompt 是否要求必须基于证据回答
  • 冲突证据是否有显式处理规则

8. 上线前最值得先确认什么 ​

  1. 是否已经能稳定记录 query / namespace / filter / top-k / parent_doc_id / chunk_id / source，方便排障。
  2. 是否已经验证过“旧版本残留”“租户串数”“编号搜不到”“同义问法失配”“过期制度仍被引用”这几类高频问题。
  3. 是否已经区分向量检索问题、重排问题和生成问题，而不是把所有效果问题都归给模型。
  4. 是否已经按 query 类型做分桶评测，而不是只看平均效果。
  5. 是否已经预留删除、重建、冷启动和租户下线机制，而不是只关心新增写入。

9. 常见误区 ​

  • 把向量数据库当作“自动变聪明”的黑盒。
  • 不做 metadata 建模，后面再想补权限和过滤。
  • 所有租户共用一套索引，只靠应用层兜底隔离。
  • 只做纯向量检索，不做关键词、过滤、重排和混合检索。
  • 用同一份索引同时服务完全不同的检索目标，却没有多向量或多索引设计。
  • 只看召回速度，不看证据质量、过期率和最终答案效果。

10. 不同角色更适合怎么读 ​

10.1 应用工程师 ​

先看 01-向量数据库详解，重点理解 chunk、metadata、hybrid search 和最终答案效果的关系。

10.2 平台或架构负责人 ​

重点看 05-主流方案、架构形态与选型清单、租户隔离、更新策略、索引治理、日志字段和运行指标，再配合 平台工程 一起看。

10.3 检索评测和知识治理同学 ​

重点看召回失败类型、证据质量、版本新鲜度、引用链路和 知识库与检索 中的治理专题。

10.4 安全与合规同学 ​

重点关注权限继承、租户隔离、知识版本、过期下线和审计回放链路，不要只把检索当成“相关性问题”。

11. 建议搭配阅读 ​

12. 重点官方资源 ​

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