说说向量数据库：从 Embedding 到 ANN，我的一些复盘

一篇关于向量数据库的独立观察。不写通稿，只说真话。
阅读时间：约 7 分钟 | 标签：#向量数据库 #Embedding #技术选型

这一年，总有人来问我向量数据库的事。问法五花八门，但核心就那么几个：它到底是个啥？我该怎么选？要不要现在就上？

我琢磨了几次，索性把反复讲的那几点整理成一篇文章，算是我自己的复盘。尽量说人话，不讲花活。

一、先把词说清楚：向量数据库存的是「意思」

向量数据库，存的是「向量」——一串表示意义的数字，做的是一件事：语义相似度检索。

传统数据库存的是结构化数据，一行一列，用 SQL 精确查。它擅长回答「金额大于 100 的订单有哪些」，但回答不了「找一找和这条投诉最像的 10 条记录」。

原因很简单：传统库的匹配是字面相等，要么相等、要么不相等、要么命中关键词；而「意思相近」是另一套逻辑。

维度	传统数据库	向量数据库
数据形态	行列式的结构化数据	高维向量
匹配方式	精确匹配 / 关键词	语义相似度
擅长回答	「等于多少」「包含什么」	「和什么最像」

一句话：传统库问「字面上像不像」，向量库问「意思上近不近」。

它跟着大模型火起来，是因为 RAG——让大模型先检索真实资料再回答，而不是凭空编。Menlo Ventures 的调研显示，RAG 在 2024 年已占企业 AI 部署的 51%。

二、三个概念，我一般这么讲

理解向量数据库，就三个概念：Embedding、相似度、索引。

Embedding：把意思变成数字。 拿个模型，把文本、图片转成一串固定长度的数字。关键是——语义相近的内容，转出来的向量在空间里也靠得近。「苹果手机」和「iPhone」字面毫无重合，但好模型生成的向量会很接近。

这里有个被很多人忽略的点：向量数据库的上限在 Embedding 模型，不在它自己。 模型选得不对，后面全是垃圾进、垃圾出。中文场景要挑中文友好的模型（BGE 系列这类），别拿只对英文敏感的模型硬上。

相似度：在比距离。 常用三种度量：余弦相似度（比方向，文本最常用）、欧氏距离（比直线距离）、内积（方向和长度都看）。不用背公式，记住一句：相似度检索就是「拿查询向量，去库里找离它最近的那批向量」。

索引：为什么不能全量比。 最朴素的作法是暴力扫描，和每个向量都算一遍距离，100% 准。但几十万、上亿条就太慢了。于是有了近似最近邻（ANN）——用「近似」换「速度」，允许偶尔漏几个，换毫秒级响应。

三、ANN 索引，我打比方讲三种

ANN 是一场三角权衡：要精度就得牺牲速度和内存，要速度就得接受精度损失。三种主流算法就是三种取舍姿势：

算法	一句话原理	精度	查询速度	内存
HNSW	分层图，像「六度分隔」一样从粗到细跳近目标	高	快	大
IVF	先聚类分桶，只搜最近的几个桶	中	中	较小
PQ	向量切段量化，用「压缩」换内存	较低	快	最小

HNSW 我一般比作社交网络：从人脉广的节点出发，上层粗跳几下落到目标附近，再底层精搜。精度高、查询快，代价是吃内存、建索引慢。

IVF 像图书馆分区：先聚类把书分到不同区，查询只搜最近的几个区。内存省、构建快，但精度略逊，分多少个簇（nlist）调得好不好很关键。

PQ 是有损压缩：把高维向量切成小段，每段用最接近的代表值近似。内存压到极小，精度损失明显，常和 IVF 组合。

衡量好坏看三个指标：召回率（Recall@K，准不准）、延迟（P99，快不快）、吞吐（QPS，扛不扛得住）。一个常见的坑：厂商爱拿「99% 召回」说事，但从 90% 提到 99%，往往要付出几倍的内存或延迟代价。

四、选型上的几点复盘

向量数据库的产品其实分三条路线，很多人以为只能选专用库，这是个误区。

专用向量库：Milvus、Qdrant、Pinecone、Zilliz、Weaviate。性能调教得最好，但它是套独立存储系统，等于又养一座数据孤岛。

传统库的向量扩展：pgvector 是代表。国产库里金仓 KingbaseES 等也在关系库上提供了向量扩展能力，企业不必另起炉灶。好处是一站式，业务数据和向量数据在同一套库里。

云托管：省心，代价是接受一定生态绑定。

我的几点判断，说几句可能得罪人的话：

1. 绝大多数公司现阶段根本不需要专用向量库。 数据没到千万级、延迟没到毫秒级苛求，pgvector 就够用。
2. 专用库最大的风险不是性能，是孤岛。 图灵奖得主 Stonebraker 在 2024 年论文里判断：专用数据库市场终将被关系型数据库吸收。我不认为会这么快，但方向值得信。
3. 别被「选 Milvus 还是 Pinecone」困住。 先问三个问题：数据量级、延迟要求、数据现在在哪。答案往往已经替你选好了。

照抄清单：数据在 PostgreSQL 且百万级以内 → pgvector；追求极致性能且上亿 → Milvus/Qdrant；不想运维 → Pinecone/Zilliz；深度绑定某朵云 → 云托管；国产化/信创 → 国产库的向量扩展。

五、几个我见人踩过的坑

1. Embedding 决定上限，不是索引。 先验证模型在你的语料上「近邻」是否靠谱，再谈选库。
2. 生产要的是混合检索。 真实查询往往要「关键词命中 + 标签过滤 + 语义相似」一起，向量检索和全文检索融合（RRF 之类）才是常态。
3. 更新删除比想象中麻烦。 向量进了索引，删一条或改一条，索引一致性怎么保证、会不会污染召回，很多方案没讲清。
4. 维度灾难是真的。 维度越高，点与点距离越趋于相似，区分度反而下降。
5. 什么场景不要用。 精确匹配、范围查询、强一致事务 → 关系库；关键词搜索 → Elasticsearch 这类全文引擎。向量库补的是「语义」这块空白。

结语

这些是我这一年的复盘。向量数据库不神秘，拆成三个概念、三种索引、三条路线，心里就有底了。

一句话收尾：想清楚你的业务里有多少问题是「字面匹配」解决不了的，就知道自己到底需不需要它了。

---

本文基于公开信息与个人从业经验独立撰写，不代表任何厂商立场。
李白客，信创行业独立观察者。关注数据库、AI基础设施与国产化替代。

数据来源：RAG 企业部署占比引自 Menlo Ventures 调研；专用库市场判断引自 Michael Stonebraker 2024 年论文观点。