从零搭建向量数据库：实现文本语义检索实战

写在最前面：我一开始真没打算“自己搭一个”

说句实话，我第一次接触向量数据库的时候，根本没想过要自己搭一套。

原因也很现实：

• 市面上已经有不少成熟产品
• 文档、SDK、Demo 一应俱全
• 看起来直接用现成的就好

所以一开始我的想法非常简单：

我只需要一个“能做语义检索的东西”，
至于它内部怎么跑的，说实话并不关心。

直到后来在项目里遇到几个非常具体的问题：

• 检索结果为什么会抖
• 为什么同样的数据，换个参数效果差这么多
• 数据量一上来，延迟突然失控

那时候我才意识到一个问题：

如果你完全不了解向量数据库是怎么“拼”起来的，
那你其实很难用好它。

这篇文章，就是在这种背景下写的。
不是为了造一个“能对外卖钱的数据库”，而是为了搞清楚：

一套最小可用的向量数据库，从工程角度到底需要哪些东西？

从目标说起：我们到底要做一个什么东西

在开始写代码之前，我建议先把目标说清楚。

这篇文章里，我们要做的事情其实很克制：

• 输入是一段文本
• 系统能返回语义上相近的文本
• 支持一定规模的数据
• 结构清楚、可扩展

换句话说，我们要实现的是：

一个最小但完整的文本语义检索系统

它不追求极限性能，但每一层都是真实向量数据库会有的结构。

第一步：把“文本”变成“向量”（很多问题从这里开始）

所有向量数据库的起点，其实都非常一致：

你得先有向量。

这一步通常叫 embedding。

选模型之前，我先踩过一个坑

一开始我也犯过一个很常见的错误：

embedding 模型，越大越好吧？

后来发现，完全不是这么回事。

在真实工程里，你要考虑的其实是：

• 向量维度
• 生成速度
• 稳定性
• 是否和你的任务匹配

对“文本语义检索”这个任务来说，一个稳定、维度适中、输出一致的模型，往往比一个“看起来更强”的模型更重要。

一个很现实的工程判断

如果你是第一次搭：

• 不要追求最强 embedding
• 不要一上来就换模型
• 先选一个“大家都用过、坑被踩过的”

因为后面你会发现，问题往往不出在 embedding 上。

第二步：向量要不要“原样存”？

当你已经能把文本变成向量，接下来一个非常自然的问题就来了：

向量该怎么存？

很多人第一反应是：

直接存成 list / numpy array 不就行了？

在数据量很小的时候，这个想法完全没问题。
但一旦你认真算一下空间和性能，就会开始犹豫。

一个简单但很打击人的计算

假设：

• 100 万条文本
• 每条 768 维
• float32

那你光原始向量就已经是几十 GB。

这时候你就会意识到：

“原样存”这条路，迟早会走不下去。

压缩不是锦上添花，而是你迟早要面对的事

我当时的第一反应其实是抗拒的：

我只是想做个语义检索，
怎么突然就要研究压缩了？

但后来你会发现，压缩在向量数据库里承担的角色非常特殊：

• 它不只是为了省空间
• 更是为了让后面的检索“跑得动”

哪怕你第一版系统里不真的做复杂压缩，
你也要在结构上给它留位置。

原始向量 vs 压缩向量 概念图

第三步：最朴素的检索方式（以及它为什么注定不行）

在正式引入索引之前，我强烈建议你先实现一版最朴素的检索。

也就是：

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

为什么？

因为这是你理解后面一切优化的“对照组”。

当你真正跑起来的时候，会发生什么

在数据量小时，你会觉得：

好像也没那么慢？

但只要你把数据量放大一个数量级，
延迟和资源占用就会立刻告诉你现实有多残酷。

这一步非常重要，因为它会让你发自内心地接受：

必须引入近似搜索。

第四步：接受现实，引入 ANN

我第一次认真看 ANN 相关资料的时候，内心其实是有点抗拒的。

因为这意味着一个非常不工程师直觉的事实：

我主动放弃“最优解”。

但后来你会发现，这不是退步，而是妥协。

一个重要但常被忽略的认知

在语义检索里：

• 你几乎不可能定义“绝对最相似”
• 人类对结果的容忍度其实很高
• 稳定、可控，远比“极致准确”重要

所以 ANN 的存在，本质上是：

把“精确性”换成“可用性”。

第五步：我们到底要不要“自己写索引”

这是很多人会卡住的地方。

我的建议非常直接：

第一版，千万别自己实现复杂索引算法。

不是因为你写不出来，而是因为：

• 实现成本极高
• debug 成本更高
• 非常容易在细节上出错

更好的方式是：

• 先理解索引在干什么
• 再决定是否替换、优化

你要清楚的是：

向量数据库真正的难点，不是“有没有索引”，
而是索引和系统其他部分怎么配合。

第六步：一次完整查询到底发生了什么

当你把系统各个模块拼起来，一次语义检索请求，通常会经历：

• 文本 → embedding
• embedding → 索引搜索
• 得到候选向量
• 精排
• 返回结果

一个很重要的工程细节是：

真正参与精确相似度计算的向量，数量应该很少。

如果不是这样，那你的系统迟早会顶不住。

向量检索完整请求路径图

第七步：别忽略元数据和过滤条件

很多“从零搭建”的教程，都会下意识忽略 metadata。

但在真实系统里，没有 metadata 的向量数据库几乎没法用。

比如：

• 时间过滤
• 类型过滤
• 权限控制

工程上的现实是：

向量检索只是第一步，
真正能不能用，取决于你怎么把它和结构化条件结合。

第八步：性能问题通常不是你一开始想的那样

很多人会下意识把性能问题归结为：

• 向量算得慢
• 索引不够高级

但我在实践中遇到的瓶颈，更多来自：

• 内存布局不友好
• cache miss
• 数据结构不连续

这也是为什么你会发现：

同样的算法，不同实现，性能差距巨大。

写到这里，说点非常现实的感受

如果你真的按这条路从零搭一遍，你会明显感觉到：

• 向量数据库并不“神秘”
• 它是很多工程选择堆出来的结果
• 每一步看起来都不复杂，但组合起来很重

这也是为什么，大多数团队最终都会选择：

• 用成熟方案
• 但前提是你理解它在干什么

写在最后：什么时候你应该自己搭，什么时候不该

我现在对“自己搭向量数据库”的看法是这样的：

• 为了学习，非常值得
• 为了上线产品，大多数时候不值得
• 为了理解系统边界，极其有价值

你不一定要永远自己维护一套，
但你最好至少亲手搭过一次。

尾声：一点关于工程效率的补充

在真实项目中，你往往不仅要处理向量检索，还要同时面对：

• 数据构建
• 模型训练
• 实验对比
• 版本管理

如果你把所有东西都从零写一遍，成本会非常高。

这也是为什么我后来会在一些项目里，先借助像 LLaMA-Factory online 这样的工具，把模型微调、数据处理、实验流程这些容易反复踩坑的部分先跑顺，再把精力放在真正需要定制的系统设计上。

它解决的不是“算法多高级”，而是一个很现实的问题：

让工程师少在重复的工程细节里消耗精力。