1、向量数据库是什么：从传统数据库到向量数据库的演进

说实话，我第一次接触向量数据库时，心里也犯嘀咕：这不就是个搞相似度搜索的东西吗？跟 Elasticsearch 有什么区别？后来踩了几个坑才明白——向量数据库不是传统数据库的替代品，而是 AI 时代的全新基础设施。

1.1 传统数据库的边界：为什么不够用了？

我们先用一个场景来感受一下。假设你有一张用户表，存了 1000 万条记录。你想找「年龄在 25-30 岁之间、住在北京、最近一周登录过的用户」。这在 MySQL 里加几个索引就能搞定，毫秒级返回。

但换个需求：「找一张跟这张图片最像的图片」。传统数据库怎么搞？

• 用标签？你得先给每张图片打上「猫」「狗」「风景」之类的标签。但「像」这个感觉，很难用几个标签描述清楚。
• 用 SQL 的 LIKE 模糊匹配？图片又不是文本，没法比。
• 用精确匹配？两张图片哪怕只有 1 个像素不同，在数据库眼里就是完全不同的两条记录。

你看，传统数据库擅长的是精确匹配和结构化查询。但 AI 时代的需求变了——我们想要的是语义相似，不是字段相等。

1.2 向量检索的核心概念：从「等于」到「像」

要理解向量数据库，先得搞明白三个核心概念：向量化、距离度量、近似最近邻搜索。

1.2.1 向量化：把万物变成数字

任何非结构化数据——文本、图片、音频、视频——都可以通过深度学习模型转换成一组浮点数。比如一张 224x224 的图片，经过 ResNet-50 模型，会变成一个 2048 维的向量。

# 伪代码示例：文本向量化
text = "今天天气真好"
embedding_model = SentenceTransformer('all-MiniLM-L6-v2')
vector = embedding_model.encode(text)  # 输出一个 384 维的向量
print(vector.shape)  # (384,)
print(vector[:5])    # [0.0234, -0.1567, 0.0891, 0.3124, -0.0456]

这个向量的每个维度，可以理解为模型从数据中提取的某个「特征」。两个向量越接近，原始数据在语义上就越相似。

1.2.2 距离度量：怎么才算「像」？

有了向量，接下来就是算距离。常用的度量方式有几种：

度量方式	公式	适用场景	特点
欧氏距离 (L2)	√Σ(ai - bi)²	图像检索、聚类	对向量长度敏感，适合数据分布均匀的场景
余弦相似度	cos(θ) = A·B / (|A|·|B|)	文本搜索、推荐系统	只关注方向，忽略长度；文本场景首选
内积 (IP)	Σ(ai × bi)	语义搜索、排序	与余弦相似度正相关，但计算更快

嗯，这里要注意：选错度量方式，召回率可能直接腰斩。我记得有个项目，团队用欧氏距离做文本检索，结果「苹果手机」和「苹果水果」的距离反而比「苹果手机」和「华为手机」更近——因为文本向量的长度差异太大，欧氏距离被带偏了。换成余弦相似度后，效果立竿见影。

1.2.3 近似最近邻搜索：暴力搜索不可行

假设你有 1000 万个 512 维的向量。暴力搜索——把每个向量跟查询向量算一遍距离——需要做 1000 万次浮点运算。一次查询几十毫秒，看起来还行？但如果是每秒 1000 次查询呢？服务器直接冒烟。

所以业界搞出了近似最近邻搜索（ANN）。核心思路很简单：不找最近的，只找「足够近」的。牺牲一点点精度，换来几十上百倍的速度提升。

常见的 ANN 算法包括：

• HNSW（分层可导航小世界图）：目前最流行的算法。构建一个多层图结构，上层粗搜，下层精搜。召回率高，但内存占用大。
• IVF（倒排文件索引）：先聚类，再在最近的几个簇里搜索。速度快，内存友好，但召回率不如 HNSW。
• PQ（乘积量化）：把向量压缩成短码，大幅降低内存。适合超大规模场景，但精度损失明显。

1.3 为什么需要专门的向量数据库？

你可能会问：用 Redis 存向量，自己写 ANN 搜索不行吗？ 当然可以。但现实往往比想象中复杂得多。

我列几个真实场景，你看看自己实现要花多少功夫：

1. 数据持久化与恢复：内存里的 HNSW 图结构怎么落盘？服务重启后怎么重建索引？
2. 动态增删改：用户上传了新图片，向量要插入索引；用户删除了图片，向量要从索引里移除。HNSW 的删除操作非常麻烦。
3. 混合查询：既要按向量相似度排序，又要加过滤条件（比如「只查 2024 年之后的记录」）。传统 ANN 不支持这种过滤。
4. 分布式与高可用：单机存不下 10 亿向量怎么办？节点挂了怎么自动切换？
5. 多租户隔离：不同客户的数据要物理隔离，但又要共享集群资源。

专门的向量数据库，就是把这些能力打包成一个开箱即用的产品。你不需要自己写 ANN 算法、不用操心索引持久化、不用手撸分布式一致性——像用 MySQL 一样用向量数据库。

1.4 从传统到向量：一张图看懂演进

下面这张图展示了从传统数据库到向量数据库的演进路径，以及各自的核心能力边界：

从图上可以清楚看到：传统数据库、搜索引擎、向量数据库，各有各的领地。没有谁取代谁，而是各司其职。你想想看，一个典型的 AI 应用，往往是三者的组合——MySQL 管用户信息，ES 管日志搜索，向量数据库管语义检索。

1.5 什么时候该用向量数据库？

我个人的判断标准很简单：如果你的查询条件里出现了「相似」「推荐」「匹配」「搜索」这些词，而且数据是非结构化的，那大概率需要向量数据库。

几个典型场景：

• RAG（检索增强生成）：把文档切块、向量化，用户提问时先检索最相关的几个片段，再喂给大模型生成答案。
• 以图搜图：电商平台上传一张衣服图片，找出所有相似款。
• 推荐系统：把用户行为序列编码成向量，找兴趣相似的其他用户或物品。
• 异常检测：把正常行为模式向量化，偏离太远的标记为异常。