什么是向量数据库

传统数据库存的是数字和文字，向量数据库存的是「语义」。

这句话听起来有点抽象。我们先从一个最熟悉的场景开始：你在电商网站搜索「适合跑步的蓝牙耳机」，传统关系型数据库会用关键词匹配去找标题或描述里包含「跑步」「蓝牙」「耳机」的商品；但向量数据库会先把这句话变成一个高维空间里的点（一个向量），然后去找那些在语义空间里和它距离最近的点——即使那些商品的描述里完全没有「跑步」两个字，只写了「运动防汗、低功耗、通勤」。

这就是向量数据库真正解决的问题：把「相似」「相关」「语义接近」这种模糊的需求，变成一次可计算的几何查询。在 RAG（Retrieval-Augmented Generation）、语义搜索、推荐系统、AI Agent 记忆层这些场景里，它几乎无法被替代。

本文会完整讲清楚：向量数据库到底是什么、怎么工作、和传统数据库有什么本质区别、市面上主流产品怎么选，以及出海 AI 产品在做技术决策时应当避开的坑。

一、向量数据库到底是什么

向量数据库（Vector Database） 是一种专门用来存储、索引和检索高维向量（embedding / vector）的数据库系统。这些向量通常来自 embedding 模型——比如 OpenAI 的 text-embedding-3-small、Cohere 的 embed-english-v3.0、开源的 bge-m3 等——它们把文本、图像、音频、视频等非结构化数据编码成一个固定维度的浮点数数组，例如 768 维、1024 维、3072 维。

一个典型的向量条目长这样：

{
  "id": "doc_0042",
  "vector": [0.0123, -0.0456, 0.0789, ...],  // 768 维
  "metadata": {
    "title": "Getting Started with RAG",
    "source": "docs",
    "language": "en"
  }
}

其中 vector 是核心，metadata 用来做过滤和溯源。向量数据库的职责可以归纳为三件事：

1. 高效写入：批量接收 embedding 模型产生的向量，并持久化。
2. 建立索引：用专门的 ANN（Approximate Nearest Neighbor）算法组织数据，让查询不必遍历全库。
3. 相似度检索：给定一个 query 向量，在毫秒级返回最相似的 Top-K 个结果，通常还要附带距离分数。

如果你做过 RAG，会熟悉这个流程：用户提问 → 把问题用 embedding 模型编码成向量 → 去向量数据库里查最相似的若干条 → 把这几条作为上下文塞进 LLM 的 prompt → 生成回答。向量数据库就是这套链路里的「语义记忆层」。

二、工作原理：从向量到最近邻

向量数据库的工作可以拆成三个阶段来理解。

阶段 1：Embedding 生成（在数据库之外）

向量数据库本身不生成向量。向量由 embedding 模型产出，模型决定了向量的维度、语义质量和多语言能力。数据库只负责「存」和「查」。这一点很关键，因为很多初学者的误解都发生在这里——向量数据库不是 AI 模型，它是模型产出结果的仓库。

阶段 2：向量索引构建

把几百万个 768 维向量直接存进磁盘并不困难，困难的是如何在毫秒内找到「最接近的那几个」。如果每次都做全量距离计算（也叫暴力搜索 / Flat Index），在百万级数据上就要几十到几百毫秒，在十亿级数据上就完全不可用。

因此，向量数据库会使用 ANN 索引算法，核心思路是「牺牲一点点精度，换取几个数量级的速度」。主流算法有三类：

其中 HNSW 是当前工业界最常被使用的算法。它借鉴了跳表（skip list）的思想：把向量组织成多层图，最上层只有少量长边连接，用于快速跳过大片无关区域；最下层包含所有节点，用于精确定位。查询从最高层开始，贪心地往更近的邻居走，逐层下沉，最终在底层得到候选结果。Milvus、Qdrant、Weaviate、pgvector 等都支持 HNSW。

IVF（Inverted File Index） 是另一种常见方案：先用 k-means 把向量空间聚成若干簇（称为 Voronoi cells），查询时先定位 query 落在哪几个簇附近，只在这几个簇里做精确距离计算。IVF 经常和 PQ 量化组合（IVF-PQ），用于十亿级数据的低成本部署。

阶段 3：相似度计算与检索

给定 query 向量 q，数据库需要衡量它和库中向量 v 的「距离」。常用度量有三种：

• 余弦相似度（Cosine Similarity）：衡量方向一致程度，忽略长度。文本语义搜索最常用的默认选项。
• 欧氏距离（L2 Distance）：衡量空间直线距离。图像特征比较常用。
• 内积（Inner Product / Dot Product）：当向量已做归一化时，内积和余弦等价；在未归一化的 learned embedding 上也常用。

数据库根据索引结构快速筛出候选，再用原始向量做精确重排（rerank），最后返回 Top-K。典型延迟在 1–50ms，取决于数据规模、维度、索引和硬件。

下面的流程图展示了一次典型检索的完整链路：

三、向量数据库与传统数据库的区别

把向量数据库和 MySQL、PostgreSQL 这类传统关系型数据库摆在一起对比，差异非常清晰。它们解决的是两类完全不同的问题。

需要注意的一点是：这两类数据库是互补的，不是替代关系。一个完整的 AI 产品，通常还是会用 PostgreSQL 存用户、订单、账单，用向量数据库存 embedding 和语义索引。很多团队甚至会在同一套业务里同时使用两种数据库——例如 PostgreSQL + pgvector 扩展同时承担结构化数据和向量检索的角色，这在小规模 RAG 里非常常见。

四、主流向量数据库横向对比

目前市面上活跃的向量数据库可以分三类：

1. 专用向量数据库：Pinecone、Milvus、Qdrant、Weaviate、Chroma
2. 传统数据库 + 向量扩展：PostgreSQL + pgvector、MongoDB Atlas Vector Search、Redis Stack
3. 内存 / 检索库：FAISS（Facebook 的向量检索库，不是数据库）、Vespa（搜索引擎带向量能力）

下面这张表覆盖五款最常用的专用向量数据库：

几款产品的简单画像

• Pinecone：以「开箱即用」著称。不需要懂索引算法，调几个参数就能跑起来，延迟稳定。代价是不开源、没有私有化部署选项、无法深度调优索引结构。对于早期 MVP 和不想投入基础设施的团队，是最省心的选择。
• Milvus：由 Zilliz 主导，是最成熟的开源向量数据库之一，支持十亿到百亿级向量。索引类型最丰富（HNSW、IVF_FLAT、IVF_PQ、IVF_SQ8、DiskANN 等），适合对性能和成本有精细控制需求的团队。学习曲线相对陡。
• Qdrant：用 Rust 实现，在性能和内存占用上经常跑赢同类。支持丰富的 payload 过滤、多向量、稀疏向量、量化。Cloud 版的免费额度对早期项目非常友好。
• Weaviate：把「混合搜索」做成了核心卖点，原生支持向量 + 关键词 + BM25，同时内置了多种模块化器（text2vec-openai、multi2vec-clip 等）。GraphQL 风格的 API 让它很适合做复杂的多模态检索。
• Chroma：定位是「嵌入式向量数据库」，可以直接在 Python 进程里跑，不需要单独起服务。非常适合做原型、本地实验、Jupyter notebook 里的 POC。数据量大了之后，很多团队会迁移到 Milvus 或 Qdrant。

五、索引算法对比

索引算法决定了向量数据库的性能、成本和召回率。理解这三种主流算法，就能看懂大部分性能报告。

一个经验性的选择路径：

• 数据量 < 100 万：直接用 HNSW，不必纠结。
• 数据量 100 万 – 1000 万，内存够：HNSW；内存紧张：IVF-SQ 或 DiskANN。
• 数据量 > 1000 万：IVF-PQ 或 DiskANN，必要时做分片。

六、如何选择向量数据库：决策矩阵

选择向量数据库，本质上是在「开发效率、运行成本、控制力、规模上限」四个维度之间做取舍。下面这张决策矩阵可以直接用来做第一轮筛选。

七、两个真实场景案例

案例 1：出海 SaaS 的智能客服 RAG

一家做 B2B SaaS 的出海团队，客户遍布欧美和东南亚。他们用 LLM 做智能客服，需要从几千篇多语言帮助文档里检索答案。

架构选择：

• Embedding 模型：bge-m3（多语言、1024 维）
• 向量数据库：Qdrant Cloud（法兰克福 + 新加坡双区）
• 业务数据库：PostgreSQL（用户、工单、订阅）

为什么选 Qdrant：

1. 多语言 RAG 需要混合搜索（向量 + BM25 关键词），Qdrant 原生支持稀疏向量 + 稠密向量并存。
2. 客户数据合规要求高，需要欧洲区域部署，Qdrant Cloud 的 EU 区定价比 Pinecone 低约 30%。
3. Payload 过滤能力强——可以按「客户语言、订阅等级、文档版本」做前置过滤，再在子集上做向量检索。

效果：首答准确率从关键词搜索的 48% 提升到 79%，平均检索延迟 18ms。

案例 2：跨境电商的相似商品推荐

一个面向北美市场的独立站，希望做「看了又看」的相似商品推荐。商品数据包含标题、描述、图片和类目。

架构选择：

• 文本 embedding：OpenAI text-embedding-3-small
• 图像 embedding：CLIP ViT-B/32
• 向量数据库：Milvus（自托管在 AWS EKS）
• 索引：HNSW（文本）、IVF_PQ（图像，量大）

为什么选 Milvus：

1. 商品库有 500 万 SKU，每个 SKU 既有文本向量又有图像向量，需要多向量管理。Milvus 的 collection + partition 模型适合这种结构。
2. 推荐系统对延迟敏感（< 30ms），但对召回率的要求比客服 RAG 低，因此图像向量用 IVF_PQ 节省内存。
3. 自托管可以利用已有的 Kubernetes 集群和 reserved instance，长期成本低于全托管方案。

效果：推荐点击率提升 22%，P95 检索延迟 24ms，每月向量相关基础设施成本约 $800。

八、常见误区与避坑清单

在选型和落地过程中，以下问题几乎每个团队都会踩一次。提前列出来可以节省几周时间。

选型清单（15 项）

1. 不要假设向量数据库可以替代业务数据库——它只负责语义检索，用户、订单、权限还是得用 PostgreSQL / MySQL。
2. 先估算数据规模再选型——10 万、1000 万、10 亿的最优解完全不同。
3. 先确定 embedding 模型，再确定数据库——向量维度、距离类型、是否多语言都由模型决定。
4. 不要一开始就追求十亿级架构——大多数产品前 12 个月的数据量用 HNSW 足够。
5. 考虑延迟 SLA——客服场景 < 50ms，推荐场景 < 30ms，离线分析可以放宽到秒级。
6. 考虑合规和区域部署——出海产品尤其重要，GDPR 要求欧洲区部署，PINECONE / Qdrant Cloud 都有 EU 区。
7. 考虑多租户模型——SaaS 产品要按客户隔离向量集合，不同数据库的多租户能力差异很大。
8. 考虑混合搜索——纯向量搜索在短文本、专有名词、SKU 编号上效果差，需要结合 BM25 或稀疏向量。
9. 考虑元数据过滤——大部分查询会带业务过滤条件（语言、权限、时间），数据库必须支持「先过滤后检索」或「先检索后过滤」。
10. 考虑索引重建成本——HNSW 索引构建非常吃 CPU，批量写入时要控制并发。
11. 考虑内存预算——HNSW 索引大致占用 向量数 × 维度 × 4 字节 × 1.5–2 倍，千万级 768 维需要几十 GB 内存。
12. 考虑运维能力——团队没有 K8s 经验，优先选托管；有基础设施团队，自托管可以省很多钱。
13. 考虑备份和恢复——向量数据库的备份恢复能力差异很大，生产环境必须验证过。
14. 考虑可观测性——是否有 metrics、慢查询、召回率评估工具，对上线后排障至关重要。
15. 不要忽视评测——上线前用真实数据做 recall@K、latency@P95、cost/month 三项评测，不要只看厂商文档。

性能估算速查

• 100 万 × 768 维 × HNSW：内存约 6–8 GB，查询 < 10ms
• 1000 万 × 768 维 × HNSW：内存约 60–80 GB，查询 10–30ms
• 1000 万 × 768 维 × IVF-PQ：内存约 10–15 GB，查询 20–50ms
• 10 亿 × 768 维 × IVF-PQ + 分片：内存 1–2 TB（多节点），查询 50–200ms

这些是经验数字，实际取决于硬件、参数和负载模式。

九、小结

向量数据库不是万能的，但它是 AI 产品技术栈里「语义层」的唯一解。它解决的问题是：把高维 embedding 变成可以毫秒级查询的相似性结果。

选型的核心不是「哪个产品最好」，而是「我的规模、合规、运维能力、成本预算处于什么区间」。

• 小团队、快验证：Pinecone / Qdrant Cloud
• 中等规模、要灵活：Qdrant / Weaviate
• 大规模、要控制：Milvus（自托管）
• 已有 PG、量不大：pgvector
• 本地实验：Chroma / FAISS

记住一条经验法则：embedding 模型决定了语义质量的上限，向量数据库决定了这个上限能被多快地兑现。两者要一起选、一起评测。

检查清单

• 是否明确区分了「向量数据库」和「embedding 模型」的职责边界？
• 是否在选型前估算了数据规模、维度、QPS？
• 是否确认了目标 embedding 模型的维度和距离度量？
• 是否评估了合规区域（GDPR、CCPA）的部署选项？
• 是否测试了混合搜索（向量 + 关键词）的效果？
• 是否验证了元数据过滤的延迟影响？
• 是否估算了 HNSW / IVF 的内存占用？
• 是否考虑了多租户的隔离方式？
• 是否用真实数据做过 recall@K 和 P95 延迟评测？
• 是否准备了备份与恢复方案？
• 是否规划了可观测性（metrics、慢查询、召回率监控）？
• 是否对比了托管 vs 自托管的 12 个月 TCO？

参考资料

1. Wang, M., et al. "Milvus: A Purpose-Built Vector Data Management System." SIGMOD 2021. https://milvus.io/
2. Malkov, Y. A., & Ponomarenko, A. V. "Efficient index construction for approximate nearest neighbor search in high-dimensional spaces." Linguistic and Cultural Research, 2014. (HNSW 原始论文)
3. Pinecone Learning Center. "Vector Databases." https://www.pinecone.io/learn/vector-database/
4. Qdrant Documentation. "Understanding vector search." https://qdrant.tech/documentation/concepts/
5. Weaviate Academy. "What is a vector database?" https://weaviate.io/academy
6. Zilliz. "索引选不对，成本贵十倍！HNSW 与 IVF 如何做选型." https://zilliz.com.cn/blog/Choosing-HNSW-vs-IVF-costs
7. DataAspirant. "Most Popular Vector Databases You Must Know in 2025." https://dataaspirant.com/popular-vector-databases/
8. TensorBlue. "Pinecone vs Weaviate vs Qdrant vs Milvus – Price & Performance." https://tensorblue.com/blog/vector-database-comparison-pinecone-weaviate-qdrant-milvus-2025