向量数据库

学习目标：理解主流向量数据库和向量检索方案的定位、优劣势、部署方式，并能为 RAG、AI Agent 记忆和企业知识库选择合适的技术底座。

1. 向量数据库解决什么问题

向量数据库用于存储 Embedding 向量，并根据相似度查找最接近的文本、图片、音频、代码或业务对象。在 AI Agent 和 RAG 系统中，它通常负责“从大量资料里找出最相关的一小部分内容”，再交给大模型生成答案。

典型流程如下：

2. 选型时先看哪些能力

3. 主流方案速览

4. 各方案特性、优劣势和部署方式

4.1 Milvus / Zilliz

Milvus 是开源分布式向量数据库，Zilliz 是 Milvus 背后的商业化云服务。它更偏向“专门为大规模向量检索设计的数据库”。

核心特性

• 支持多种向量索引，适合大规模近似最近邻检索。
• 支持标量字段过滤、分区、集合、批量导入和分布式部署。
• 生态成熟，常见 RAG 框架基本都有集成。
• Zilliz Cloud 提供托管版本，降低运维复杂度。

优势

• 适合百万到亿级向量的生产场景。
• 分布式能力强，适合高并发和大数据量。
• 社区和企业案例较多，资料比较丰富。

劣势

• 自建组件较多，生产部署和排障门槛高。
• 对小型项目来说偏重，PoC 阶段可能不够轻便。
• 架构中涉及对象存储、消息队列、协调服务等组件时，运维复杂度会上升。

部署方式

• 本地体验：Docker Compose。
• 生产自建：Kubernetes + Milvus Operator / Helm。
• 托管服务：Zilliz Cloud。

适合选择它的情况

• 向量规模很大，未来明确需要横向扩展。
• 团队有 Kubernetes 和数据库运维能力。
• 希望使用成熟的开源向量数据库，而不是只依赖云厂商。

4.2 Pinecone

Pinecone 是托管型向量数据库，重点是“少运维、快速上线”。用户主要通过 API 使用，不需要自己维护底层集群。

核心特性

• 云端托管，提供向量索引、命名空间、元数据过滤等能力。
• 面向 RAG 和语义检索场景，接入简单。
• 与 LangChain、LlamaIndex 等生态集成成熟。

优势

• 部署和运维成本低，适合快速上线。
• API 使用简单，产品化体验好。
• 对没有数据库运维团队的项目很友好。

劣势

• 主要依赖云服务，数据合规和私有化部署空间有限。
• 成本随数据量、索引规格和查询量增长，需要提前评估预算。
• 底层细节可控性不如自建方案。

部署方式

• 使用 Pinecone Cloud 创建 index，通过 API 写入和查询。
• 应用侧通常只需要配置 API Key、index name 和 namespace。

适合选择它的情况

• 想快速把 RAG 应用上线。
• 不想维护 Milvus、Elasticsearch 这类集群。
• 数据可以放在托管云服务中。

4.3 Weaviate

Weaviate 是开源向量数据库，强调对象模型、schema、模块化和混合检索能力。

核心特性

• 支持向量检索、关键词检索和混合检索。
• 支持 GraphQL、REST API 和多语言客户端。
• 支持 schema 建模，可以把对象属性和向量一起管理。
• 可接入不同向量化模块，也可使用外部 Embedding。

优势

• 对知识对象建模比较自然，适合结构化元数据较多的场景。
• 混合检索能力实用，适合文档问答和企业搜索。
• 自建和云服务都有，部署选择灵活。

劣势

• schema 和模块体系需要学习成本。
• 对只想做简单本地 RAG 的用户来说可能偏重。
• 大规模生产部署仍需要关注集群规划和资源管理。

部署方式

• 本地或测试：Docker Compose。
• 生产自建：Kubernetes / Helm。
• 托管服务：Weaviate Cloud。

适合选择它的情况

• 需要对象 schema、元数据和向量一起管理。
• 需要全文检索与向量检索结合。
• 希望在开源和托管之间灵活切换。

4.4 Qdrant

Qdrant 是 Rust 实现的开源向量数据库，以部署简单、过滤能力强、性能稳定著称。

核心特性

• 支持向量检索、payload 元数据过滤、集合和分片。
• 支持 REST 和 gRPC API。
• 单机部署轻便，也支持集群和云服务。
• 对复杂过滤条件支持较好，适合权限和业务字段过滤。

优势

• 上手简单，单 Docker 容器即可运行。
• 元数据过滤能力强，适合企业知识库的权限控制。
• Rust 实现，资源占用和稳定性表现较好。

劣势

• 超大规模生态和案例数量通常不如 Milvus。
• 如果需要非常复杂的全文搜索能力，通常还要配合搜索引擎。
• 集群运维仍需要规划分片、副本和备份策略。

部署方式

• 本地体验：Docker。
• 生产自建：Docker Compose、Kubernetes。
• 托管服务：Qdrant Cloud。

适合选择它的情况

• 希望部署轻便，但又要比 Chroma 更接近生产。
• 需要强元数据过滤和多租户隔离。
• 中小团队搭建 RAG 系统，希望降低运维复杂度。

4.5 Chroma

Chroma 是面向 AI 应用开发的轻量向量数据库，常见于 LangChain 原型和本地知识库。

核心特性

• Python 生态友好，使用简单。
• 支持本地持久化和基础向量检索。
• 与 LangChain、LlamaIndex 等框架集成方便。

优势

• 非常适合学习、Demo 和 PoC。
• 本地开发体验好，几行代码即可完成写入和查询。
• 不需要复杂运维。

劣势

• 不适合一开始就承载复杂高并发生产场景。
• 分布式、权限、多租户和运维能力不如专用生产型数据库。
• 大规模数据和复杂过滤场景需要谨慎评估。

部署方式

• 本地开发：安装 Python 包并持久化到本地目录。
• 服务化：Docker 或 Chroma Server。

适合选择它的情况

• 做 RAG 原型、课程实验、个人知识库。
• 数据规模小，团队更重视开发速度。
• 后续可以迁移到 Qdrant、Milvus、Weaviate 等生产方案。

4.6 FAISS

FAISS 是 Meta 开源的向量相似度搜索库，不是完整数据库。它适合嵌入应用中做高性能向量索引。

核心特性

• 支持多种向量索引和相似度搜索算法。
• Python / C++ 生态成熟。
• 适合离线构建索引、本地检索和研究实验。

优势

• 检索性能强，算法选择丰富。
• 轻量，适合嵌入式或离线场景。
• 不依赖数据库服务，实验成本低。

劣势

• 不提供完整数据库能力，例如权限、事务、在线更新、分布式、备份、API 服务等。
• 需要自己管理索引文件、元数据映射和服务封装。
• 生产化通常要额外开发很多工程能力。

部署方式

• 作为 Python / C++ 库嵌入应用。
• 索引文件保存到本地磁盘或对象存储，由应用加载。

适合选择它的情况

• 离线检索、算法实验、单机检索。
• 应用团队愿意自己封装服务和元数据管理。
• 不需要完整数据库能力。

4.7 PostgreSQL + pgvector

pgvector 是 PostgreSQL 的向量扩展，可以在现有关系数据库中存储和检索向量。

核心特性

• 在 PostgreSQL 表中新增 vector 类型字段。
• 支持向量距离计算和索引。
• 可与 SQL、事务、权限、备份、业务表关联使用。

优势

• 架构简单，已有 PostgreSQL 的团队接入成本低。
• 业务数据、权限字段、元数据和向量可以放在同一个数据库。
• 适合中小规模 RAG 和企业内部系统。

劣势

• 超大规模和极致检索性能通常不如专用向量数据库。
• 查询性能需要结合索引、表结构和过滤条件调优。
• 大量向量数据可能影响原有业务库资源，需要隔离实例。

部署方式

• 自建 PostgreSQL 安装 pgvector 扩展。
• Docker 运行带 pgvector 的 PostgreSQL 镜像。
• 使用支持 pgvector 的云数据库。

适合选择它的情况

• 已经使用 PostgreSQL，想少引入一个新系统。
• 数据规模中等，更看重事务、SQL 和权限复用。
• RAG 与业务数据强绑定。

4.8 Elasticsearch / OpenSearch

Elasticsearch 和 OpenSearch 原本是搜索引擎，现在也支持向量字段和近似向量检索，适合全文检索与语义检索结合。

核心特性

• 强大的全文检索、过滤、聚合和高亮能力。
• 支持 dense vector / kNN 等向量检索能力。
• 适合 BM25 + 向量的混合检索。

优势

• 如果已有日志或搜索集群，可以复用基础设施。
• 全文检索能力强，适合命令、错误码、产品型号等精确搜索。
• 运维、监控和生态成熟。

劣势

• 作为专用向量数据库使用时，成本和调优复杂度可能较高。
• 向量检索只是其能力之一，API 和索引配置相对复杂。
• 集群资源消耗较大，需要专业运维经验。

部署方式

• 自建 Elasticsearch / OpenSearch 集群。
• Docker / Kubernetes 部署。
• 使用 Elastic Cloud 或 Amazon OpenSearch Service。

适合选择它的情况

• 现有系统已经有 Elasticsearch / OpenSearch。
• 需要关键词搜索、聚合、过滤、日志搜索和向量检索一体化。
• RAG 场景中大量问题包含专有名词、编号、命令和错误码。

4.9 Redis Vector Search

Redis 通过 Redis Stack / RediSearch 提供向量检索能力，适合低延迟检索和缓存型场景。

核心特性

• 支持向量字段、过滤查询和全文索引。
• 内存访问延迟低。
• 可与缓存、会话、实时特征数据结合。

优势

• 低延迟，适合实时推荐、短文本检索、缓存型 RAG。
• Redis 生态成熟，很多团队已有运维经验。
• 小中规模场景接入方便。

劣势

• 内存成本较高，大规模向量存储需要谨慎评估。
• 复杂向量数据库能力不如 Milvus、Weaviate、Qdrant 等专用系统。
• 持久化、备份和大规模集群成本要提前规划。

部署方式

• Redis Stack Docker 镜像。
• Redis Enterprise / Redis Cloud。
• 自建 Redis 集群并启用相关模块。

适合选择它的情况

• 对延迟非常敏感，数据量不是特别大。
• 已经大量使用 Redis。
• 向量检索更像缓存层或实时特征检索层。

4.10 Vespa

Vespa 是面向搜索、推荐和在线排序的平台，适合复杂的生产级检索和排序系统。

核心特性

• 支持文本检索、向量检索、结构化过滤和多阶段排序。
• 支持在线特征计算和复杂 ranking profile。
• 适合大规模搜索推荐系统。

优势

• 检索、排序、推荐一体化能力强。
• 适合复杂线上系统，不只是简单 RAG。
• 支持大规模低延迟在线服务。

劣势

• 学习曲线明显高于轻量向量数据库。
• 对简单知识库问答来说偏重。
• 部署和 schema / ranking 配置需要较强工程经验。

部署方式

• Docker 本地体验。
• Kubernetes / 自建集群生产部署。
• Vespa Cloud。

适合选择它的情况

• 不只是做 RAG，还要做搜索、推荐、排序平台。
• 需要复杂 ranking、特征组合和多阶段召回。
• 团队有搜索工程经验。

4.11 MongoDB Atlas Vector Search

MongoDB Atlas Vector Search 适合把文档数据、元数据和向量检索放在 MongoDB Atlas 中统一管理。

核心特性

• 在 MongoDB 文档中保存向量和业务字段。
• 支持 Atlas Search 与向量检索结合。
• 通过托管 Atlas 服务使用。

优势

• 如果业务数据已经在 MongoDB，架构很简单。
• 文档模型适合存储非结构化和半结构化资料。
• 减少额外引入一套向量数据库的成本。

劣势

• 主要依赖 Atlas 托管服务。
• 如果只看极致向量检索能力，专用向量数据库通常更聚焦。
• 成本和区域合规需要结合 Atlas 方案评估。

部署方式

• 使用 MongoDB Atlas 创建集群和 Vector Search Index。
• 应用通过 MongoDB Driver 或聚合管道查询。

适合选择它的情况

• 已经使用 MongoDB Atlas。
• RAG 文档和业务元数据天然是 JSON 文档。
• 团队希望减少数据库种类。

5. 怎么按场景选

6. 部署建议

6.1 PoC 阶段

• 数据量小于几十万条文本块时，可以优先用 Chroma、Qdrant 单机或 pgvector。
• 重点验证切分策略、Embedding 模型、Top-k、Rerank 和答案引用质量。
• 不要过早追求复杂分布式架构，先证明“检索结果真的有用”。

6.2 生产初期

• 如果已有 PostgreSQL，优先评估 pgvector 是否足够。
• 如果需要独立向量库，Qdrant 和 Weaviate 通常比 Milvus 更容易起步。
• 如果不想自建，优先看 Pinecone、Zilliz Cloud、Weaviate Cloud 或 Qdrant Cloud。
• 必须设计权限过滤、租户隔离、数据删除、重建索引和备份策略。

6.3 大规模生产

• 明确向量规模、写入频率、查询 QPS、延迟目标和召回质量指标。
• 选择 Milvus / Zilliz、Weaviate、Vespa 或成熟搜索集群时，要同步规划监控、扩容、备份和灰度重建索引。
• 将 Embedding 生成、文档解析、切分、入库、检索、Rerank 拆成可观测流水线。
• 建议保留原文、chunk、元数据、向量版本和 embedding model version，方便回滚和重建。

7. 常见坑

• 只看向量库，不看切分策略：Chunk 太大或太小都会影响答案质量。
• 只做向量检索，不做关键词检索：错误码、命令、配置项更适合 BM25 或精确匹配。
• 没有权限过滤：企业知识库必须先按用户权限过滤，再把内容交给模型。
• 忽略数据更新：文档删除、更新、重建索引和版本回滚要提前设计。
• 把 Top-k 调得很大：召回更多不代表答案更好，可能引入噪声并增加上下文成本。
• 没有评估集：至少准备一批真实问题、标准答案和引用资料，用来持续评估召回质量。
• Embedding 模型随意更换：不同模型生成的向量空间不兼容，通常需要重新向量化和重建索引。

8. 推荐结论

• 学习和原型：先用 Chroma 或 FAISS，快速理解流程。
• 中小型企业 RAG：优先看 Qdrant、pgvector、Weaviate。
• 已有数据库优先：PostgreSQL 用 pgvector，MongoDB Atlas 用 Vector Search，已有搜索集群用 Elasticsearch / OpenSearch。
• 大规模专用向量检索：优先看 Milvus / Zilliz、Weaviate、Vespa。
• 低运维云服务：优先看 Pinecone、Zilliz Cloud、Qdrant Cloud、Weaviate Cloud。

真正影响 AI Agent 回答质量的，不只是向量数据库本身，还包括文档清洗、切分、Embedding 模型、混合检索、Rerank、权限过滤和评估体系。选型时应把向量数据库当作 RAG 检索链路的一部分，而不是孤立组件。