这是一份关于向量数据库、相似性搜索的实用指南，解释了为什么传统SQL无法处理驱动ChatGPT、Pinecone与现代推荐系统背后的语义查询，而这正是AI应用的核心能力。

关系型数据库与向量数据库：每个开发者都应该了解的差距。

你从未与这家银行有过线下接触，可当你在从未到访过的国家使用银行卡时，银行系统却能在毫秒级时间内标记该笔交易。同样，你手机银行 APP 也能瞬间调出上月所有单笔超过500美元的交易记录。但这两种功能的底层逻辑是完全不同的，厘清其中的差异，正是理解现代人工智能系统工作原理的关键。

事实上，这正是Airbnb在搭建搜索系统时所遇到的架构难题：用户想要的是符合需求、体验匹配的房源，而不仅仅与关键词完全一致的结果，这是传统关系型数据库从设计上就无法解决的问题。Airbnb没有替换原有数据库，而是新增了专用数据库，专门处理关系型数据库做不到的事。

以SQL为代表的关系型数据库数十年来一直支撑着互联网的运转，但它回答不了AI所依赖的核心问题。

这篇文章最精彩的部分就在这里。

此前我所在的团队开发过一个实时欺诈检测系统原型，最终在项目中同时使用关系型数据库与向量数据库。因为它们各自具备对方无法替代的核心能力。本文正是基于这段实战经验展开。

只要你了解传统数据库的工作原理，包括数据检索方式以及其在结构上存在的局限，你就会明白：为什么我们必须为AI创造一种全新的数据库。

一、什么是数据库？

数据库通常被视为数据的存储载体，但这种认知忽略了其核心本质：它是内置查询能力的数据存储形式，不仅能保存数据，更能在任意规模下即时对各类数据进行查询与响应。

最常见的数据库类型是关系型数据库。它将数据组织成表，其中每一行代表一条记录，每一列代表该记录的一个属性。之所以称之为“关系型”，是因为这些表之间可以相互引用：某一行可以关联到用户表中的对应条目，并且数据库会对这种关联关系进行约束。正是这种结构，让关系型数据库在互联网领域广泛应用，并成为商业数据处理中极为可靠的选择。

与关系型数据库对话的语言称为SQL（结构化查询语言）。所有关系型数据库均针对一项核心操作做了优化：查找指定列与指定值相匹配的数据行。

WHERE  email  =  'priya@uni.edu'

你的银行账单、订单记录、登录校验全部依赖于这类基础查询。当你更新电子邮箱时，只需修改单个单元格的数据，而数据库会严格按照指令执行操作。

如果一张包含百万行数据的表，查找一条记录却需要遍历全部数据，那它也毫无意义。为此，数据库通过构建索引解决了这一问题。索引是一种预先构建的独立结构，可充当快速检索的捷径。就像教科书末尾的索引，只标注知识点对应的页码，而非呈现全文内容。

但教科书的索引是静态的，一经定稿印刷，便不会再更新。生产环境中的数据库却并非如此。每一秒都有新用户注册，数百万设备上的现有数据记录同时被新增、修改或删除。这就要求数据库索引始终保持有序、可检索，且无需从头重建。

要理解数据库如何解决这一问题，就需要了解数据结构，这正是不同数据库性能存在差异的核心原因。

采用合适的数据结构，如同将所有文件按字母顺序归入带标签的文件夹，而非杂乱堆放在同一抽屉中。

关系型数据库在构建索引时，采用一种名为B树的专用数据结构。技术细节不必深究，关键在于理解它的核心思路：

不妨设想一座永不闭馆、持续新增藏书的图书馆。它并非采用单一长排书架，而是按层级划分。顶层设有指引：作者姓氏A–M区在左侧，N–Z区在右侧。只需一眼，便可排除半数藏书。向左行进，又会遇到进一步划分区域的指示牌，再经一次定位，即可走到对应的书架。只需要三次次判断，便能从数十万册图书中精准找到目标书籍。

新书上架时，管理员无需重新整理全部藏书，只需依照指引找到对应的书架，将新书插入即可。仅更新一个分支，其余保持不变。

电子邮件列上的 B 树索引查找。该查询以 O(log N) 步骤从根节点通过内部节点导航到确切的叶节点 - 无需扫描整个用户表。作者使用 Canva 创建的图像。

B树的工作原理基本与此相同。每个节点都会判断目标值大于还是小于参考值，并沿着对应分支进行查询，直至定位到目标记录。即便数据集不断增大，查询依然高效，新数据插入时也无需对整个结构重建。

正如上图所示，B树从根节点出发，经由内部节点导航至包含 PQR@email.com 的目标叶节点，仅通过三次判断即可定位单条记录，无需扫描整张用户表。

你让它查找与某一用户相似的五名用户。

B树不知道如何做到这一点。

为什么？因为它没有“相似”这个概念。

精准匹配目标值，正是关系数据库索引设计的核心思路。而相似度检索涉及空间几何特征、方向属性与距离度量，这些概念B树并不具备。因此在执行相似性查询时，数据库只能采取唯一方案：逐行扫描、计算每行距离并进行排序。在一亿条记录的场景下，单次查询耗时约需100秒，这类性能问题是无法通过调优解决的。

这本质上是问题需求与工具结构之间的不匹配。

二、精确匹配与相似性搜索：核心架构差异

SQL 数据库关心的是：这条精确记录在哪里？向量数据库关心的是：它附近还有哪些相似数据？

由于它们所解决的问题存在本质区别，因此需要完全不同的架构设计。

举例语义上相关的两段内容，如“可疑交易”和“欺诈支付”，或者“外面是晴天吗？ ”和一篇天气预报文章，在数学空间中应当彼此邻近。模型通过处理海量文本，会自动学习出这种语义的几何结构。

向量空间中的距离对应语义相似度。两个点在该空间中越接近，其语义关联就越强，而与具体表述文字无关。图片由作者使用 Canva 制作。

这些几何坐标以向量形式存储，也就是是一组代表高维空间点的数值序列。如上图所示，向量空间中的距离直接对应语义相似度，两点距离越近，其语义关联度就越强。

因此要实现相似文本检索，就需要一种基于邻近度而非等值匹配的数据结构，这就是HNSW（层次化可导航小世界）。

三、HNSW工作原理：向量相似性搜索背后的索引结构

HNSW即层次化可导航小世界算法，它采用与B树相似的分层检索逻辑，有效解决了相似性搜索问题。

查询从顶层开始，先找到距离最近的入口节点，再进入下一层密度更高的检索层。在每一层中，检索范围持续收窄，逐步定位到目标所在区域，最终找到最邻近的向量。该索引只需评估数千个候选数据，而非一亿条，查询时间从分钟级缩短至毫秒级。

 

HNSW（分层可导航小世界）搜索：查询在分层图中进行导航，利用长距离连接实现全局搜索，通过密集的局部连接完成精确的向量相似性搜索。作者使用 Canva 创建的图像。

然而，HNSW本身存在一个显著局限：一旦进程终止，所有数据便会消失。该索引存在于内存中，既无网络接口，也无法在不重建的前提下容纳新增数据。它更像是应用内部的一个组件，并不适合持续独立运行。虽然它运行时快速高效，但进程结束后，系统的其他部分就无法访问它了。

四、什么是向量数据库？

向量数据库以这套检索引擎为核心，构建出完整的配套基础设施。如下图所示，查询请求通过API层进入，可选择性经过元数据过滤模块（从元数据存储中获取筛选条件），再由内存中的 HNSW 执行向量相似度检索，最终返回最相似的结果集。整个过程中，底层索引会持续保存至磁盘持久化存储并支持从中加载复用。

 

向量数据库系统——生产架构。查询流程分为四个阶段：通过 API 层接入、执行可选的元数据过滤、在内存中基于 HNSW 进行向量相似性搜索、将最优相似结果返回给客户端。持久化存储层可保证索引在服务重启与部署后依然可用。图片由作者使用 OneNote 和 Canva 创建。

持久化存储层可确保索引在系统重启、重新部署或意外中断时保持完好无损。它支持系统安全地关闭与重启，并精准保留所有向量数据。

元数据过滤机制允许每个向量附带结构化属性，例如时间戳、分类、用户ID或语言标签等等，从而实现更精准的检索。比如查询指定日期之后的发布记录，或属于特定类别的前五个相关文档。过滤与向量搜索作为一个统一、连贯的流程协同运作，无需在应用程序中发起多次独立查询或编写额外逻辑。

由于HNSW直接运行在应用程序内部，对系统中的其他组件完全不可见。其它独立服务无法查询它，不同的编程语言也无法访问它，它仅对当前运行的进程可见。

向量数据库通过网络API对外暴露索引，从而解决了这一问题。该标准接口基于HTTP接受外部请求，应用只需发送查询指令，数据库完成处理后返回结果，底层的复杂实现对调用方完全透明。系统中的任何编程语言、服务器和服务，都能以统一的方式使用它。

人们所说的向量数据库，是一整套能力的集合：高效的相似性搜索、可靠的持久化存储、实时数据更新、结构化过滤，以及清晰的网络接口。它远不止是一个索引，正是这套完整的基础架构，才让相似性搜索能够在实际生产环境中落地运行。

五、向量数据库与关系数据库

任何架构选型都伴随权衡取舍，因此明确每种方案的代价至关重要。

HNSW返回的是近似最近邻，而非理论上保证的精确结果，这是最关键的取舍。但在实际应用中，这种近似精度极高，用户几乎察觉不到最优与次优结果之间的明显差异。

然而，在使用该系统之前，充分理解这一点依然至关重要。

另一个主要限制是内存。当向量规模达到十亿级别时，索引无法以经济的方式存放在单台机器上。生产环境中的向量数据库通常通过两种方式解决这一问题：分片（sharding）和量化（quantization）。量化通过压缩向量降低内存占用，但会以微小且可衡量的检索精度损失为代价。

向量数据库（HNSW）和关系型数据库（B树）的区别。每个系统都擅长对方无法胜任的任务——选择的关键不在于哪个更好，而在于你问的是什么问题。图片由作者使用Canva制作。

当你需要按已知ID精准查找记录、按精确日期筛选，或是在多系统间保证事务一致性时，关系型数据库是很好的选择。

对于开放式自然语言查询场景，向量数据库则是理想选择。用户查询由语义含义驱动，而非精确数值。即便措辞不同，返回结果在概念上依然相近。

在大多数生产级AI系统中，两者通常会结合使用。这就要说回我们团队构建的欺诈检测系统原型。

六、一个真实案例：结合向量数据库与关系型数据库的欺诈检测系统

项目的整体架构由我们的导师穆巴拉克·阿卜杜拉设计，我则负责带领团队完成系统实现。下图展示了整套系统的完整架构。

我团队构建的实时欺诈检测系统原型。向量数据库通过语义搜索找出行为相似的交易，而 MySQL 则存储结构化的欺诈记录供分析师查询——两种数据库，各司其职，共筑一个生产系统。鸣谢：穆巴拉克·阿卜杜拉。

查看该架构时，请尝试找出其中两个数据库，不要被其它组件分散注意力。

一方面，向量数据库（Vector DB）负责处理相似性检索。当新交易产生时，系统会将其转换为向量，并搜索行为模式相似的其他交易。这并非精确匹配的交易记录，而是在查找数学空间中处于同一区域的交易。通过这种方式，系统能够识别出从未以完全相同形式出现过的新型欺诈模式。

没有预设规则，是几何空间识别出来的。

我们可以用一个简单的方式理解它在实际中的意义。假设你居住在 A 国，几乎所有交易都发生在这里：超市购物、交通充值、月度订阅。这种行为模式就形成了你的金融指纹。现在，一笔交易从 B 国发起，发生在一个异常的时间点，金额也是你从未消费过的。虽然没有规定系统一定要“标记来自B国的交易”，但这笔交易的来源与你以往的所有交易记录都截然不同，这种差异本身就是信号。因此，系统标记这笔交易，并不是它匹配了某个已知的欺诈模式，而是它与你的个人记录不符。

这就是系统能够识别从未以完全相同形式出现过的欺诈模式的原理。在分析师还没来得及为其编写规则之前，向量空间的几何特征就已经先一步发现了异常。

另一方面，MySQL（欺诈数据库）负责存储结构化的欺诈记录，分析师可通过网页门户直接查询。一旦某笔交易被标记，其金额、时间戳、账户标识、欺诈分类等信息都会写入MySQL。随后，分析师可按日期范围、账户类型或欺诈类别进行筛选，精准查询所需记录。

这两种数据库无法互相替代。你无法用向量数据库按交易金额降序，查询上周二的所有欺诈记录；而MySQL也无法识别一笔与未知欺诈模式行为相似的新交易。它们不是相互竞争的工具，而是互补的技术层，共同解决同一问题的不同方面。

这不是权宜之计，而是深思熟虑的设计。

七、为什么HNSW采用近似最近邻搜索（以及为何这是正确的选择）

分析师在查询“找出与这笔标记交易相似的记录”时，并不一定需要数据集中数学上绝对最精确的向量结果。HNSW严格按相似度返回前五个结果，与返回最接近的第1、2、4、7、9近的结果，这两者之间的差异对分析师来说毫无意义。他们需要的只是若干高度相关的结果，并且能快速返回才有价值。因此，结果的质量没有区别，但查询速度从分钟级缩短到了毫秒级。这种工程设计思路几乎适用于所有现实场景中的语义检索问题。

元数据过滤进一步强化了这一点。在实际生产级AI系统中，近似相似性搜索和结构化条件过滤足以满足绝大多数业务需求。当需要精确匹配时，关系型数据库便可派上用场。

SQL 数据库关注的是精确记录在哪里，向量数据库关注的是附近还有哪些相似的数据。

问题从来不是二选一，而是误以为其中任意一种数据库能同时胜任两类任务。

在我们团队开发的欺诈检测系统中，这种差异并非只是理论上的区别。它正是这套系统能够有效运行的根本原因。

但本文还留有两个问题，或许也是更有意思的问题。当向量存储在向量数据库中并进行相似性查询时，数据库只计算距离，并不关心这些向量代表什么含义。那么，这些向量点一开始是如何落到正确位置上的？系统又是如何在无人编写规则的情况下，把“可疑交易”和“欺诈支付”在向量空间中归为邻近一类的？没有人告诉模型这些表述是相关的。它直接从原始文本中自主发现并学习了这种几何分布关系，无需标注，也无需指令。

关于这一点的解释，才是整个故事真正的精彩之处。

作者丨Tina Sharma     编译丨dbaplus社群

来源丨网址：
https://thequantasticjournal.com/vector-databases-exist-because-sql-has-one-blind-spot-aa4bca0ee7b2

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn