向量数据库到底解决了什么问题？从原理到工程实践一次讲清

1. 向量数据库为什么突然火了？

2023 年之前，向量数据库是个小众领域，圈外人基本没听过。

然后 ChatGPT 爆了，大模型成了全民话题。紧接着大家发现一个问题：大模型的知识是训练时固定的，不知道你公司的内部文档，不知道最新的新闻，不知道你私有的数据。

怎么办？把私有数据喂给它。

怎么喂？总不能每次都把几百页文档塞进 prompt 里吧，token 费用先不说，还超长度限制。

于是 RAG（Retrieval-Augmented Generation）火了。思路很简单：先从你的知识库里找到和问题相关的内容，再把这些内容塞给大模型，让它基于这些内容回答。

问题来了：怎么"找到相关内容"？

传统数据库做关键词匹配，搜"苹果手机"只能匹配到包含"苹果手机"这几个字的文档，搜不到写着"iPhone"的文档。

但人知道"苹果手机"和"iPhone"是一回事。怎么让机器也知道？

答案是：把文本转成向量，用向量的相似度来衡量语义的相似度。

这就是向量数据库火起来的根本原因——大模型时代需要语义检索，向量数据库是做语义检索最直接的方案。

2. 什么是向量？Embedding 到底在干什么

向量是什么

向量就是一串数字。

比如 [0.12, -0.34, 0.56, ..., 0.78]，可能有 768 个数，也可能有 1536 个数，取决于用什么模型生成的。

这串数字代表什么？代表这段内容的"语义特征"。

你可以把它理解成一个坐标点。在一个 768 维的空间里，每段文本都有一个位置。语义相近的文本，位置就靠得近；语义不同的，位置就离得远。

Embedding 模型在干什么

Embedding 模型就是负责把文本转成向量的。

输入一段话，输出一串数字。这个过程叫"向量化"或者"Embedding"。

比如：

输入："今天天气真好"
输出：[0.12, -0.34, 0.56, ..., 0.78]  （768维向量）

不同的 Embedding 模型，输出的向量维度不一样，质量也不一样。常见的：

• OpenAI 的 text-embedding-3-small：1536 维
• BGE 系列：768 或 1024 维
• GTE 系列：768 或 1024 维
• M3E：768 维

中文场景下，BGE 和 M3E 效果还不错，而且是开源的，可以本地部署。

怎么衡量两个向量"像不像"

最常用的是余弦相似度。

数学上就是两个向量夹角的余弦值。夹角越小，余弦值越接近 1，表示越相似。

还有欧氏距离、点积等方法，但余弦相似度最常用，因为它对向量的长度不敏感，只看方向。

3. 为什么传统数据库不适合做向量检索

有人会问：向量不就是一堆数字吗？MySQL 也能存啊，为什么非得用专门的向量数据库？

问题一：查询方式不同

传统数据库的查询是"精确匹配"或"范围查询"：

SELECT * FROM users WHERE age = 25;
SELECT * FROM products WHERE price BETWEEN 100 AND 200;

向量检索是"相似度查询"：

找出和这个向量最相似的 Top 10 个向量

这是完全不同的查询模式，传统的 B+ 树索引根本用不上。

问题二：维度灾难

向量动辄 768 维、1536 维。在高维空间里，传统的索引结构会失效。

这叫"维度灾难"——维度越高，数据点之间的距离差异越小，所有点看起来都差不多远。普通索引在这种情况下退化成全表扫描。

问题三：性能要求

实际业务中，向量检索通常要在百万甚至千万级的向量里，毫秒级返回最相似的 Top K。

MySQL 存 100 万个 768 维向量，每次查询都算一遍余弦相似度？服务器会哭的。

所以需要专门的**近似最近邻（ANN）**算法和索引结构。

4. 向量数据库的核心能力拆解

一个向量数据库，核心要解决这几件事：

4.1 高效的 ANN 索引

ANN = Approximate Nearest Neighbor，近似最近邻。

“近似"是关键词。为了速度，我们允许结果不是 100% 精确的最近邻，而是"足够近"的近邻。

常见的 ANN 索引算法：

HNSW（Hierarchical Navigable Small World）

目前最主流的算法。构建一个多层图结构，查询时从顶层开始，一层层往下找，很快就能定位到目标附近。

优点：查询快、召回率高 缺点：内存占用大，索引构建慢

IVF（Inverted File Index）

先用 K-means 把向量聚成若干簇，查询时先定位到最近的几个簇，再在簇内精确查找。

优点：内存占用小，可以配合量化压缩 缺点：召回率比 HNSW 低一些

PQ（Product Quantization）

把向量切成小段，每段用一个码本压缩。查询时用压缩后的表示计算距离。

主要用来省内存，通常和 IVF 配合使用（IVF-PQ）。

4.2 向量 + 元数据混合查询

实际业务中，很少只按向量相似度查。通常还有过滤条件：

找和这个问题最相关的文档，但只要最近 7 天发布的
找最相似的商品，但只要价格在 100-500 之间的

这就需要向量数据库支持混合查询：先按条件过滤，再在过滤后的集合里做向量检索。

有的数据库是先过滤再检索（pre-filter），有的是先检索再过滤（post-filter），性能差异很大，选型时要注意。

4.3 实时增删改

有些场景数据是动态变化的，比如电商商品库、新闻文章库。

需要支持：

• 实时插入新向量
• 删除过期向量
• 更新已有向量

这对索引结构有要求，有些索引（比如纯 IVF）更新代价很高。

4.4 分布式和高可用

数据量大了，单机扛不住，需要分片、副本、故障恢复。

这块各家实现差异很大，有的是天生分布式架构，有的是单机加分布式壳。

5. 向量数据库在真实系统中是怎么用的

场景一：RAG 知识库

最火的场景。

流程：

1. 把文档切成小块（chunk）
2. 每个 chunk 用 Embedding 模型转成向量
3. 向量存入向量数据库
4. 用户提问时，把问题也转成向量
5. 在向量数据库里搜最相似的 chunk
6. 把搜到的 chunk 和问题一起喂给大模型

这套流程，向量数据库是核心组件之一。

场景二：语义搜索

传统搜索是关键词匹配，语义搜索是"理解意图”。

用户搜"便宜又好用的手机"，能搜到标题是"性价比神机推荐"的文章，虽然一个关键词都没匹配上。

很多产品已经在用了，只是你可能没注意到。

场景三：推荐系统

把用户行为、商品特征都转成向量，用向量相似度做召回。

比如：用户看过的商品向量取平均，找和这个平均向量最近的商品推荐给他。

这个场景其实比 RAG 更早用向量检索，只是当时不叫"向量数据库"，叫 Faiss、叫 ANN 服务。

场景四：去重 / 相似检测

判断两张图是不是同一张（抄袭检测、版权检查）。

把图片转成向量，新图进来时搜一下有没有相似的。

文本去重也一样。

6. 工程实践中的常见误区与坑

误区一：以为向量数据库能解决一切检索问题

向量检索是语义相似度检索，不是万能的。

有些场景关键词匹配更合适。比如搜订单号、搜 SKU 编码，这种精确匹配的需求，用向量检索是脱裤子放屁。

好的方案通常是混合检索：关键词检索 + 向量检索，结果做融合排序。

误区二：Embedding 模型随便选一个就行

Embedding 模型的质量直接决定检索效果。

模型不行，向量数据库再牛也白搭。

建议：

• 用 MTEB 榜单看看各模型的评分
• 针对自己的场景做评测，通用榜单不一定准
• 中文场景，BGE、M3E、GTE 都可以试试

误区三：Chunk 切得越小越好 / 越大越好

都不对。

Chunk 太小：上下文丢失，检索到的内容不完整 Chunk 太大：噪音太多，语义被稀释

没有万能的切分策略，要根据内容类型调。一般经验：

• 结构化文档（有标题层级的）：按章节切
• 纯文本：300-500 字一块，可以有重叠
• 代码：按函数 / 类切

误区四：只看召回率，不看排序

召回了 100 条结果，但最相关的排在第 50 名，有什么用？

要关注Top K 的准确率，而不只是"能不能召回"。

这跟 Embedding 模型、索引参数、查询方式都有关。

误区五：忽略元数据过滤的性能

前面说了，混合查询（向量 + 过滤）很常见。

但有些数据库的过滤实现很慢，特别是 post-filter 模式——先召回 10000 条，再过滤，可能最后只剩 10 条，效率很差。

如果你的业务过滤条件很重要，选型时一定要测混合查询的性能。

7. 向量数据库该怎么选（工程视角）

市面上的选择很多，大致分几类：

专用向量数据库

Milvus

• 开源、功能全、社区活跃
• 支持分布式，能扛大规模
• 缺点是部署有点重，依赖 etcd、MinIO 这些组件

适合：正经做向量检索的团队，数据量大，对功能和性能有要求

Pinecone

• 全托管 SaaS，开箱即用
• 不用操心运维
• 缺点是贵，而且数据在别人那

适合：不想运维、预算充足、数据不敏感的团队

Qdrant

• Rust 写的，性能不错
• 支持丰富的过滤条件
• 部署比 Milvus 简单

适合：中等规模，对过滤查询有要求

Weaviate

• 支持多模态（文本、图像）
• 内置一些 Embedding 模型
• GraphQL 接口

适合：想要一站式方案的

传统数据库 + 向量插件

PostgreSQL + pgvector

• 如果你已经在用 PG，加个插件就能用
• 性能一般，但对小规模够用
• 优点是不用引入新组件

适合：数据量小（几十万以内）、想简单搞搞的

Elasticsearch 8.x

• ES 8 开始原生支持向量检索
• 可以和全文检索无缝结合
• 适合已经在用 ES 的团队

纯库（需要自己封装）

Faiss

• Facebook 出品，业界标杆
• 纯索引库，不是数据库，没有持久化、没有 API
• 需要自己包一层

适合：有工程能力，想深度定制的

怎么选？

别被营销忽悠了，先搞清楚自己的需求：

• 数据量多大？
• QPS 要求多少？
• 需不需要混合查询？
• 需不需要实时更新？
• 团队有没有运维能力？

然后再选。

8. 写在最后：向量数据库的边界

向量数据库不是银弹。

它解决的是语义相似度检索这一个问题，而且是"近似"解决。

不要指望它：

• 替代传统数据库的精确查询
• 替代全文搜索引擎的关键词检索
• 自动理解你的业务逻辑

它只是工具链的一环。在 RAG 系统里，Embedding 模型、Chunk 策略、Prompt 设计、大模型本身，每一环都会影响最终效果。向量数据库选得再好，其他环节拉胯也没用。

另外，这个领域还在快速发展。今天的最佳实践，半年后可能就过时了。保持关注，但别盲目追新。

先把基础搞明白，再折腾花活。