向量数据库技术内核：从存储到检索，拆解其高效运作的秘密向量数据库技术内核：从存储到检索，拆解其高效运作的秘密

向量数据库技术内核：从存储到检索，拆解其高效运作的秘密

我也是“被向量数据库名词轰炸”过的人

说实话，我第一次接触向量数据库的时候，是有点抗拒的。

那会儿各种文章都在说：

向量数据库是 AI 时代的“新型基础设施”
没有向量数据库，大模型就跑不起来
它彻底改变了传统数据库的范式

结果我真正打开文档一看，全是：

embedding
ANN
IVF
HNSW
PQ

名词密度高到让我一度怀疑：

这是不是又一个“包装得很厉害的老技术”？

直到后来我在项目里真的开始用它、调它、踩坑、看源码，才慢慢意识到一件事：

向量数据库真正有价值的地方，不在概念，而在它对「存储 + 检索」这件事做了极其激进的工程优化。

这篇文章，我不打算从“是什么”讲起，而是想换个更工程化的视角：

一个向量，从进数据库到被检索出来，中间到底经历了什么？

一切的起点：为什么“向量”这件事，本身就很麻烦

在传统数据库里，我们处理的是：

int
string
datetime
少量结构化字段

它们的共同特点是：

可比较、可排序、可精确匹配。

而向量完全不是这么回事。

一个 embedding，通常是：

384 / 768 / 1536 维
float32 或 float16
本身没有任何“语义”，只是一个数值数组

你没法说：

这个向量 = 那个向量

你只能说：

这两个向量，有多像

而“有多像”，通常意味着：

余弦相似度
内积
欧式距离

到这里，其实问题已经很清楚了。

向量数据库的本质问题只有一个：

如何在“巨量高维浮点向量”中，快速找到“足够相似”的那几个？

注意我用的是“足够相似”，而不是“最相似”。

这个细节，后面会反复出现。

向量存储：真的只是把 float 存起来吗？

刚开始我也以为，向量数据库的“存储”阶段应该很简单：

不就是一堆 float 数组写到磁盘上吗？

后来才发现，这个想法太天真了。

存储的第一个难题：空间

假设你有：

1000 万条向量
每条 768 维
float32

那光原始数据就是：

1000万 × 768 × 4 bytes ≈ 30GB

这还没算索引、元数据、缓存。

所以第一个现实问题就是：

向量数据库不可能只存“原始向量”。

压缩，是绕不开的第一步

几乎所有成熟的向量数据库，都会在某个阶段引入向量压缩。

但这里有一个经常被忽略的点：

向量压缩不是为了省钱，而是为了“让检索跑得动”。

常见思路包括：

降低精度（float32 → float16 / int8）
Product Quantization（PQ）
Scalar Quantization

它们的共同目标只有一个：

用更少的 bit，保留“相对距离关系”。

这也是为什么你会看到很多向量数据库文档里反复强调一句话：

压缩后，相似度计算仍然“足够准确”。

这里的“足够”，非常工程化。

真正的核心：为什么不能暴力算相似度？

「全量暴力搜索 vs ANN 搜索」复杂度对比图

如果你向量数量很少，事情其实很简单。

比如 1 万条向量，你完全可以：

对 query 向量
和所有向量
全量算一遍相似度
排序取 topK

但问题是，真实世界里几乎没人这么玩。

一旦数据量上来，全量计算就直接不可接受了。

这也是向量数据库真正开始和传统数据库分道扬镳的地方。

ANN：向量数据库绕不开的“不完美选择”

说句实话，如果你追求的是绝对精确，那向量数据库本身就是错的。

因为它几乎都建立在一个前提之上：

我不追求最优解，我追求一个足够好的近似解。

这就是所谓的 ANN（Approximate Nearest Neighbor）。

我当时第一次意识到这一点的时候，其实挺震惊的。

因为这意味着：

向量数据库从设计之初
就放弃了“绝对正确”

换来的，是速度和可扩展性。

从工程角度理解：索引到底在干什么？

“全部向量” → “候选集” → “TopK”

如果你把向量数据库当成一个黑盒，很容易迷失在各种算法名词里。

但如果换个角度想：

索引的核心目的，其实只有一个：

尽可能少地看向量，但还能找到差不多对的那几个。

所有 ANN 索引，本质上都在做这件事。

以 HNSW 为例：为什么“图”这么好用？

HNSW 是我个人觉得最“反直觉但又最工程化”的一种索引结构。

它不是树，也不是 hash，而是一张图。

更准确地说，是多层小世界图。

你可以这样理解它：

每个向量是一个点
相似的向量之间连边
上层图稀疏、下层图密集

搜索的时候：

从上层快速跳跃
慢慢下沉
最后在底层精细搜索

这里面有个很重要的工程思想：

先用很便宜的计算，缩小搜索范围；

再用更贵的计算，做精细判断。

为什么向量检索速度能这么快？

这个问题我后来想了很久，最后得出的结论其实很朴素：

向量数据库快，不是因为算得快，而是因为算得少。

它通过：

索引结构
压缩表示
分层搜索

把原本“必须算 1000 万次”的事情，变成：

只算几千次，甚至几百次。

哪怕每次计算稍微复杂一点，整体还是赚的。

再说一个经常被忽略的点：内存结构

「内存 / 缓存 / 磁盘」分层访问示意图

很多人会以为，向量数据库主要瓶颈在 CPU。

但在真实系统里，内存布局和缓存命中率反而非常关键。

一些非常工程但很少被写进文章的事实：

向量通常会被按块存储，方便 SIMD
热向量和索引节点会尽量常驻内存
IO 只在必要时发生

这也是为什么很多向量数据库会强调：

内存越大，体验越好

不是营销，是事实。

从存储到检索，一次完整请求发生了什么？

我们把流程串起来看一次。

当你发起一次向量检索请求时，大致会发生：

query 被转成 embedding
embedding 被归一化
从索引结构中选出候选集合
对候选向量做精细相似度计算
排序、返回 topK
如果有 metadata filter，再做一次过滤

注意一个细节：

真正算“精确相似度”的向量，数量其实很少。

这就是整个系统能跑起来的关键。

为什么向量数据库和“传统数据库 + 插件”不一样？

我一开始也尝试过：

能不能在 MySQL / PostgreSQL 里直接存向量？

答案是：

能，但体验非常差。

原因并不复杂：

存储层不是为高维 float 优化的
缓存策略不合适
没有针对 ANN 的索引结构

向量数据库并不是“多了个字段类型”，

而是从存储到检索路径全部重新设计过的一套系统。

写到这里，说点更现实的

如果你只是：

数据量不大
QPS 很低
对延迟不敏感

你未必真的需要一套完整的向量数据库。

但一旦你遇到：

向量规模上百万
检索要进主流程
延迟必须稳定

那你会非常清楚地感受到：

这些“看起来很复杂的设计”，

本质上都是被工程现实逼出来的。

最后：我现在怎么看向量数据库

如果让我用一句话总结向量数据库，我会说：

它不是一项“新技术”，而是一堆老思想在 AI 场景下的极限工程化。

高维数据
近似搜索
空间换时间
不追求完美，只追求可用

这些思想其实并不新，但在大模型时代，被推到了一个前所未有的规模。

如果你已经开始在真实项目里用向量数据库，大概率会遇到一个现实问题：

理论都懂了，但怎么把向量、检索、模型训练这几件事真正连起来，反而更麻烦。

尤其是在做 RAG 或大模型应用时，向量数据库往往只是链路中的一环，前后还牵扯到：

embedding 模型选择
数据构建与清洗
检索效果评估
以及后续的模型微调与对齐

在这种情况下，很多团队会选择先用一些已经把训练和工程流程封装好的工具，把整体链路跑顺，再逐步替换成更定制化的方案。

比如像 LLaMA-Factory online这样的工具，已经把模型微调、数据处理、实验配置这些容易出错的工程细节做了封装，对于想快速验证思路、减少重复造轮子的团队来说，会是一个相对省心的起点。

它解决的不是“算法更先进”，而是一个很现实的问题：

让工程师把精力放在真正需要思考的地方，而不是反复踩同样的工程坑。