向量数据库：一个故事，而非说明书

前几天读到一句话，对我启发很大：你只有在试图向别人解释时，才真正学会一个东西。 教是最好的学。所以今天，不重读旧笔记，而是把向量数据库写成一段故事——像跟朋友喝咖啡时聊出来的那种，不是教科书式的罗列。

如果你曾困惑“我们把数据存成embedding”或“AI应用用向量数据库”到底什么意思，这篇文章就是为你写的。没有术语墙，只有一段旅程。

一切从一个问题开始：计算机怎么理解“意思”？

计算机擅长精确比较。“apple”等于“apple”？当然。但“apple”和“fruit”相似吗？或者“king”和“queen”的关系，是否跟“man”和“woman”的关系一样？传统计算机毫无概念，它只看到一串字母。

这就是 embedding 被发明出来的原因。

Embedding 到底是什么？

向量空间示意图

想象你要把每个词、每张图、每段声音都描述成一组数字——更准确地说，是空间中的一组坐标。不是随便列数字，而是让相似的东西在空间里彼此靠近，不相关的东西离得远远的。

这就是 embedding：一段数据的数值表示（称为向量），被放进一个高维空间，在这个空间里，距离和方向都承载着语义。

举个简单的例子。在二维地图上，巴黎和伦敦距离近，因为都在欧洲；东京则很远。现在假设这张地图不是二维（经度、纬度），而是成百上千维——每一维都捕捉某个细微的语义侧面，比如语气、主题、情感、风格。这就是 embedding 模型做的事，只不过它处理的是词、句子甚至整篇文章。

所以当有人说“词‘狗’的embedding”时，意思是一串数字（可能是384个，也可能是1536个），它编码了“狗”相对于模型所学一切事物的含义。

这些数字从哪来？Embedding 模型

数字来自一个专门训练的模型，叫做 embedding 模型。它跟普通人熟悉的聊天模型不太一样，唯一任务就是输入数据，输出向量。

一些常见的 embedding 模型：

OpenAI text-embedding 系列：广泛用于将文本转成向量做搜索和检索。
Sentence-BERT（SBERT）：开源模型，专为生成有意义的句子级 embedding 而设计。
Cohere embed 模型：另一个商用选项，常用于企业搜索。
CLIP：不仅能嵌入文本，还能同时嵌入图片和文本到同一个空间，所以可以用文字描述搜图片，反过来也行。

关键要记住：一个 embedding 只在其对应模型的上下文中才有意义。 你不能把两个不同模型的向量混在一起，因为它们本质上是不同世界的地图。

向量数据库跟普通数据库有什么不同？

传统数据库（比如经典的SQL表）用来回答精确匹配或范围问题：

“给我所有年龄>30的用户”“找到id=42的行”。

精准、结构化、可预测。

向量数据库回答的完全是另一类问题：“给我和这个最相似的东西。”没有精确匹配，没有相等判断，只有高维空间里的距离。

底层上，向量数据库存储那些长长的数字列表（embedding），同时保留原始数据。它专门针对快速搜索数百万甚至数十亿向量做了优化——不用把查询和每个向量逐一比较（那样太慢了）。

这就是思维转变的核心：传统数据库靠“精确匹配”检索，向量数据库靠“语义”检索。

示意图

每种数据类型都有自己的模型

有件事我花了一阵子才完全理解：不存在一个万能的 embedding 模型（虽然有些多模态模型，但先忽略）。文本、图片、音频、行为数据，各自都需要专门的模型来生成能捕捉语义相似性的向量。

文本用语言模型（OpenAI embeddings, SBERT, Cohere）。
图片用视觉模型（如CLIP，兼顾图文）。
音频有自己的 embedding 模型，基于声谱图或波形训练。
推荐系统也用 embedding，把用户或产品基于行为表示为向量，从而可以找到“相似用户”或“相似产品”。

数据库本身不关心向量代表什么，它只负责存数字、找邻近数字。这些数字含义的魔法完全在于你选的 embedding 模型。所以有时间的话，花功夫选好这个模型。

示意图

退一步：端到端怎么运作？

在讲“搜索”部分之前，我发现自己跳过了重要环节：数据到底怎么进向量数据库？你点“搜索”时又发生了什么？这是两条独立的旅程，当我把它们并排放着看时，整个系统才终于像系统一样清晰起来。

旅程一：数据入库（Ingestion）

想象一位图书管理员收到一卡车新书。她不是只看书名就开始上架——她会先浏览每本书，形成对内容的印象，然后把它放到感觉相近的书旁边。这个浏览-理解的过程就是 embedding 模型做的事。

一步步来：你手里有原始数据（文档、商品描述、照片等）。把它喂给 embedding 模型（比如 SBERT、OpenAI embeddings、CLIP）。模型读完后输出一个向量——就是你熟悉的那些表达语义的数字列表。最后，这个向量被存入数据库，同时保留原始数据，这样当你找到向量时也能取回背后的原始内容。

这个过程通常一次性批量完成，称为 索引（indexing）。你不是让用户等着即时处理，而是提前预处理整个数据集，为后续秒级搜索做好准备。

旅程二：你搜索那一刻发生了什么（查询时间）

这里是我最难理解但最终想通的一点：查询的本质过程和入库完全一样，只是反过来而且实时执行。

你输入一个查询文本。这个文本不会直接跟存储的文档比较。它首先必须经过和入库时一模一样的 embedding 模型。这个匹配不可妥协——如果查询用一个不同的模型嵌入，它就会落进完全不同、不兼容的语义空间。查询变成向量后，数据库利用相似性搜索技术，把它和所有已存向量比较，按相似度从高到低返回最接近的结果。

所以整个系统就两条镜像旅程：数据通过 embedding 模型一次性入库；每次查询都通过同一扇门后才有资格搜索。一旦这样理解，相似性搜索就不再是黑盒子，而变成了简单的几何问题：“哪个已存点离我的新点最近？”

现在来点好玩的：相似性搜索

一切向量化之后，向量数据库的核心操作就是 相似性搜索：找到离查询向量最近的向量。这种“靠语义而不是靠精确词”的搜索方式，就是大家说的 向量搜索。你找的不是匹配的字符串，而是语义空间里最近的点。

但“最近”需要明确定义，常见度量方法：

余弦相似度：测量向量间的夹角，而不是原始距离。文本场景常用，因为它关注方向（语义）而非幅度。
欧几里得距离（L2）：两点间的直线距离，像用尺子量。图片和通用 embedding 常用。
点积：计算更简单，向量已归一化时速度很快。

搜索方式也有区别：

精确K近邻（kNN）：跟每个向量比较，保证找到真正最近的那几个。准确但大规模时慢。
近似最近邻（ANN）：用巧妙的索引结构（如HNSW：层级可导航小世界图）找到非常接近的匹配，几乎跟精确搜索一样好，但快得多。这是让向量数据库能在现实世界处理数百万条记录的关键。

不过，纯向量搜索虽神奇，并非完美。

“仅靠语义”的问题

假设你运营一家网店，有人搜“防水徒步夹克”。好的 embedding 模型会漂亮地理解意图：它甚至能找到那些描述为“防雨户外外套”的商品，即便这些词从未出现。这正是向量搜索的意义：它读出言外之意。

但现在另一个顾客搜精确的货号“WPJ-2024-BLK”。向量搜索可能就晕了。货号、序列号、精确名称对 embedding 模型来说没有“语义”，模型不知道“WPJ-2024-BLK”是什么，无法可靠地把它放在正确商品附近。这种查询正是 关键词搜索 的用武之地——它是传统技术，扫描精确或近似词匹配，不关心语义，速度极快。

所以两种优势完全不同：向量搜索擅长理解，关键词搜索擅长精确。单靠任何一方都不够应付真实产品。这种张力正是 混合搜索（hybrid search） 要解决的问题。

混合搜索如何实际运作

混合搜索并不是把两种技术混合成一个新算法。更简单、更优雅：它同时独立运行两个搜索，然后合并结果。

好比让两位风格迥异的专家评审同一场比赛。一位只看语义（向量搜索），他仔细阅读每份作品并按符合意图的程度排序；另一位只看精确（关键词搜索），他扫描关键词语、拼写、代码、名称。两位互不沟通，各自交回一个独立的排名列表。

难题是：如何把两个完全不同的排名合并成一个最终列表？尤其当底层分数不在同一尺度上时——向量搜索的余弦相似度 0.87 和关键词搜索的 BM25 相关性分数 14.2 根本无法直接相加。

这时候用到 Reciprocal Rank Fusion（RRF），一个极其聪明的技巧。它不看原始分数，只看每个结果在各自列表中的位置。一个在向量排名第1、关键词排名第3的结果，跟一个排名第20和第1的合并方式不同。在两个法官中都排名靠前的结果自然升到最终列表顶部——即使单边打分不是最高。这是一种公平、尺度无关的融合方式。

美妙之处在于这一切发生在一次请求中。你发送一个查询，系统在后端并行运行向量搜索和关键词搜索，应用RRF，然后返回一个统一的排名列表。所以从外面看，就是一个非常智能的搜索。

混合搜索流程图