---
title: "00-向量数据库概览"
created: 2026-08-30
tags:
  - 项目筑基
---

# 向量数据库概览

> 🤖 数据库家族里最年轻的一类，AI 时代的新物种。

## 为什么 AI 需要一种新数据库？

传统数据库的查询都是**精确匹配**：`WHERE name = "张三"`，要么等于要么不等于。但 AI 处理的世界不是这样的：

- 一句话有 N 种说法："我想退货" / "这东西用着不行，帮我处理一下" —— 意思一样，字面完全不同
- 一张猫的图片和另一张猫的图片，像素级完全不同，语义上是同一回事

解决方案是 **embedding（嵌入）**：把文本、图片、音频统统交给模型，压成一个高维数字向量（比如 1536 个小数）。神奇的地方在于——**语义相近的东西，向量在空间里的距离也近**。"我想退货"和"帮我处理一下"转出来的向量，真的会挨在一起。

于是"查找相似内容"就变成了一个数学问题：**找离我最近的 K 个向量**（KNN / 近似最近邻检索 ANN）。

传统数据库干不了这事：B+ 树索引擅长精确匹配和范围查询，但"1536 维空间里找最近邻"它算不动——暴力算的话，每条查询都要和全表几百万条向量算一遍余弦距离。

## 向量数据库干了什么

一句话：**专门存向量 + 专门加速"最近邻检索"**。

```
写入：文档 → 切块 → embedding 模型 → 向量 → 存入向量库
查询：用户问题 → 同一个模型转向量 → ANN 检索 → 返回最相似的 K 条
```

支撑它快的核心是**专门设计的索引结构**（如 HNSW 图索引、IVF 倒排、PQ 量化），用"近似"换速度——不保证 100% 找到最近的，但 99% 够用且快几个数量级。

> 💡 顺带说清一个词：**RAG**（检索增强生成）。让大模型回答问题前，先用向量库检索出相关资料塞进 prompt——这是 2025 年以来 AI 应用最常见的架构，也是向量数据库最大的应用场景。

## 主流产品对比

| 产品 | 形态 | 特点 | 适合 |
| --- | --- | --- | --- |
| **Milvus** | 独立分布式服务 | 功能全、性能强、支持亿级向量，部署重 | 生产级大规模检索 |
| **Chroma** | 嵌入式/轻服务 | Python 几行代码上手，开发体验好 | 原型、小项目、学习 |
| **pgvector** | PostgreSQL 插件 | **不用引入新组件**，SQL 直接查向量 | 已有 PG 的项目，数据量不大 |
| **FAISS** | 库（不是数据库） | Meta 出品，算法最全，纯内存，无服务/持久化 | 研究、离线批量检索 |
| Elasticsearch | 搜索引擎加向量能力 | 已有 ES 的团队顺手用 | 已有 ES 技术栈 |

选型直觉（书上看的，未验证）：**已有 PostgreSQL → 先试 pgvector；写 demo 学习 → Chroma；真上了规模 → Milvus**。

## 和关系型的关系：搭配，不是替代

典型的 AI 应用架构是**两个库一起用**：

- 业务数据（用户、订单、权限）→ MySQL：要事务、要强一致
- 语义检索（文档、图片、对话记忆的向量）→ 向量库：要相似度
- 中间的桥梁是 embedding 模型——两边存同一个 `document_id`，检索时先查向量库拿 id，再回 MySQL 取完整业务数据

so——向量数据库解决的是"**按语义找**"这一种新需求，它补的不是关系型的短板，而是关系型根本没有的能力。等我真的在项目里用上（大概率是 RAG 场景），再来补一篇实操。

---
⬅️ [[06-MongoDB 数据建模与实战模式|06-MongoDB 数据建模与实战模式]] 🏠 [[00-数据库|00-数据库]] ➡️ [[01-相似度与向量索引|01-相似度与向量索引]]