百亿级向量检索的向量数据库是如何构建的？

采访嘉宾｜李莅，百度智能云大数据技术负责人

OpenAI 掀起的这波 AI 变革，让向量数据库越来越受关注。

AI 技术不断向前发展，一个核心驱动因素，就是背后的存储、处理和分析大量数据所需要的强大基础设施也在不断发生进步。这波“新基建”浪潮也催生出又一颗冉冉升起的新星——向量数据库，一种用于管理非结构化数据，包括数字形式的文本、音频、图像和视频的强大解决方案。

随着市场对 AI 基础设施需求的不断增加，向量数据库预计也将保持强劲的发展势头，并一步步成为未来 AI 技术愿景的重要基石。

受到近期 AI 火爆现象的影响，更多企业开始大力投资向量数据库以提升算法准确性和效率。据相关统计，2023 年 4 月的 AI 投资领域呈增长趋势，尤其是向量数据库领域的投资活动颇为活跃，Pinecone、Chroma 和 Weviate 等向量数据库初创公司都在这个月获得了融资。

那么，向量数据库究竟是炒作还是刚需？向量数据库在大模型企业中是如何应用的？在向量数据库选型过程中他们是倾向于自研还是从外采购？近期，在北京 QCon 大会之际，InfoQ 有幸采访到了百度智能云大数据技术负责人李莅，听他聊一聊百度在向量数据库技术上的实践和思考。

以下为访谈实录，经编辑。

InfoQ：李莅老师能方便介绍一下您整个的工作经历，包括在目前在百度智能云负责什么工作？

李莅：我毕业后就来百度了，在百度工作了十余年。刚来的时候主要是做基础架构相关的技术工作，专注在消息队列和存储方向。后来百度智能云成立后，就一直在从事云相关的产品研发，偏底层组件的产品，依然是聚焦在消息队列和存储方面。最近几年我开始做大数据方向的工作，包括像 Hadoop、ElasticSearch（搜索数据分析引擎）等这些偏技术的开源组件的平台研发，或者是内核优化等工作。

InfoQ：那您是从什么时候开始接触向量数据库？

李莅： 19 年左右百度智能云开始计划在 ElasticSearch 公有云的场景上面去做一些向量的能力，这个时候我开始关注向量检索技术。

百度智能云的向量数据库建设技术实践

InfoQ：那个时候百度就在有意识地去搞一个向量数据库了吗？

李莅：Elastic Search 在广义上它也是属于数据库的一种，它是 NoSQL 数据库。如果再细分的话，它可以算是文档型的数据库，或者搜索型的数据库，然后我们给 ElasticSearch 加上了向量检索的能力。由于会有各种搜索场景的需求，所以它会存向量的数据。既然存了向量的数据，ES 又是一个搜索型的数据库，自然也要搜索向量的数据，所以我们又给它加上了向量检索的能力。

InfoQ：也就是说 Elastic  Search 这款数据库天然就有这个场景？

李莅：对，天然有这个需求。

InfoQ：那您能具体讲一下 Elastic  Search 上都有哪些更具体与向量搜索相关的能力吗？

李莅：向量其实不复杂。向量在这个大模型火起来之前它主要就是用来做语义搜索的。各种语义数据的搜索，包括最基本的文本的搜索、图片搜索，还有可能有一些视频的缩略图之类的搜索。ElasticSearch 上的搜索能力通常就是用向量去表达的，向量本身搜索起来并不难，比如把这个数据从头到尾扫一遍，肯定是可以搜出结果的，但是这样做性能就太差了。所以我们在 ElasticSearch 上做了两点改造：一是支持了向量数据列式存储格式，二是基于社区开源的向量相似度引擎做了一些搜索加速的改进。

大概 17 年的时候 Facebook 开源了 Faiss，全称为 Facebook AI Similarity Search，是 Facebook AI Research 开源的高维向量索引和聚类库，Faiss 面向的也是传统的向量场景。到了 2020 年的时候，我们在 ElasticSearch 上加了向量数据这个格式，同时把开源的引擎给引进来跟 ElasticSearch 去做了一个结合，让它能够通过这些向量搜索引擎能够加速向量的检索速度。

在引入 Faiss 之前，ElasticSearch 自身的向量检索速度是非常慢的，需要通过 ES 原生的 Script 机制一个一个地去计算相似度，性能上无法满足业务需求。在加上了开源的向量引擎之后，它的性能提高了几十倍，满足了业务需求。

InfoQ：那当时我们为什么没有想到去自研一款搜索引擎？还是说这个开源的 Faiss 已经足够满足我们的需求了，也就不需要自研了？

李莅：是的，因为社区的已经足够满足需求了，Faiss 的表现的还是不错的。把它引入过来之后，我们自己也做了一些改造。

InfoQ：所以现在百度智能云的向量数据库的能力还是基于 ElasticSearch+Faiss 做的吗？

李莅：基本上是这样的。虽然百度用到了开源的向量引擎，但在向量检索这部分我们做了很多自研工作，比如在将 ElasticSearch 和 Faiss 结合的很多地方都做了比较底层的改造。

InfoQ：能详细展开下都做了哪些改造工作吗？

李莅：ElasticSearch 是一个开源的数据库，以前主要是用作文本搜索的，它底下核心的引擎是一套叫 Lucene 的搜索引擎，Lucene 有自己的各种格式，当然早期它不支持向量这个格式。首先数据得存进来，并且得存到磁盘上，而且得用 Lucene 的格式去表达，所以我们在 Lucene 的基础上自研了一套定制的列式存储格式，这一套是我们自己设计和实现的，可以让向量的数据比较高性能地存进来，并加载到内存里。然后我们做了一些跟社区版向量引擎的对接能力。跟 Faiss 对接就是让社区的引擎可以在我的存储格式上进行加速计算，同时也做了一些适配工作。

Faiss 引擎一开始是有自己的格式的，我们要使两边的格式能够对得上，防止它两边各存一份，带来性能损耗。这就是在 Lucene 和 Faiss 这两个东西怎么紧密地结合、发挥最大的效果这件事情上我们做了很多改造。

InfoQ：那你们有没有测试过，在改造之前，它的效果是什么样的？改造之后效果如何？收益如何？有没有一个这样的对比呢？

李莅：整体性能提升了一倍多。

InfoQ：之前这款向量数据库还只是服务于百度内部，那现在它变成了一个对外服务的数据库，它整个产品化的过程耗时多久？

李莅：其实 ES 的向量检索能力很早就完成了产品化，大概也就用了一年左右的时间吧，可以说在大模型还没有火起来以前他就已经完成产品化了。

InfoQ：整个期间做了几次优化？然后每次优化它的重点是什么？

李莅：优化这个事情我们是一直在做的，从产品孵化到走向成熟到稳定服务客户，整个过程都是都是在不断地进行优化。比如客户在使用过程中反馈某个接口不是很友好，那我们就会进行针对性的进行优化。。

在 2020 年的第一版产品中，我们实现了主要功能。然后到 22 年我们做了很多关键的优化，推出了第二代版本。然后再到今年，因为大模型的需求来了，我们继续深度优化这个产品，进入到了第三代版本。第三版本相比上一个版本，总体提升了大概一倍多的性能。

目前，第三代版本已经可以支持百亿级的高维度向量的存储和检索需求了，并投入了实际生产中。

InfoQ：目前这款向量数据库它的架构是怎样的？是单机的，还是分布式的架构？

李莅：分布式的，但是单机也可以支持。

传统数据库+搜索引擎就是向量数据库了？

InfoQ：可以看到，大模型火了以后，向量数据库受到了特别高的关注，您是如何看待这种现象呢？您认为向量数据库是一个刚需产品吗？

李莅：是的。大模型是在今年才崭露头角，或者说是在今年才备受瞩目的。虽然在此之前也有类似模型的存在，但是它们并没有像现在这样受到广泛的关注和重视。大模型已经成为今年最热门的话题之一。向量数据库作为大模型的配套设施，具有不可或缺的作用。

从多个方面来看，向量数据库都是大模型的必要设施。首先，大模型自身能够存储的数据是有限的，而大量的各种知识数据需要被存储起来，以供大模型在问答时使用。这些知识数据可以提供给大模型作为输入，从而使其回答更加准确和可靠。这些知识数据也可以成为人类想要大模型回答的内容，以确保其回答更加准确。

另外，向量数据库可以回答更加实时的内容，比如大模型它回答不了最新的数据，比如 ChatGPT 只能回答 2021 年和之前的数据，你让它回答 2023 年的问题，它就会瞎说了。这时，通过一些外置的数据库，当向它提问时，就可以把这些外置数据库中存储的数据直接输给它，这样大模型就可以结合这些数据去做出一个更准确的回答，所以在一些社区和工具链里面，向量数据库都是一个必须的组件。

InfoQ：虽然您认为它是刚需，但也有人认为我可能不是需要一款企业级的向量数据库，而是需要一个向量引擎。我可以在传统的数据库上加一个向量引擎，然后它就变成了一款向量数据库，您觉得他们这样的想法是可行的吗？

李莅：这个想法我认为是完全可行的。大模型在这个方面的核心需求就是向量检索的能力，一般不需要特别复杂的数据库的功能。

我们可以通过大模型，或者是各种其他的简化版的模型去做 embedding，把各种文档、文字、图片、转化成向量。所以对于向量既要把它们存起来，又要可以被工具链调用，从里面能够查出来。比如像 LangChain 这种就可以支持很多向量数据库类型，如果我要做数据的增删改查，单纯的向量引擎是搞不定的，但在数据库上加入向量的能力就可以搞定这个事情了。

所以，单从场景和功能出发，我觉得在传统的数据库，或者是一些 NoSQL 的数据库上去加上向量能力是完全行得通的。

但是，当业务的规模发展得很大之后，那传统的数据库加上向量引擎就不一定能搞得定了。这时可能就需要一个更加跟向量检索耦合的技术实现，来保证向量检索这一部分的性能需求。比如一款大模型应用，要支持上亿用户访问量，这个量级肯定就不是一个传统的数据库可以搞定的，它上面就肯定要做各种架构考量，比如存算分离之类的技术去保证它的规模能够扩展。

InfoQ：那这种传统的数据库加向量插件的方式和 AI native 的向量数据库两者之间的区别是什么？做 AI native 的向量数据库有哪些技术难点？

李莅：向量检索算法是向量领域最核心的技术挑战。目前，主流的算法是基于图的算法，部分算法可以使用倒排索引等算法，并结合一些量化技术来降低成本。如果能够自主优化该算法，将会成为核心技术，例如，通过优化算法可以提高性能或吞吐量，这是第一层技术挑战。社区已经对此进行了很好的处理，但真正具备这方面能力的公司很少。

第二层技术挑战是与具体的系统相结合。因为算法需要依托于一个工程实现。这个工程实现通常会选择基于数据库或从头实现一个框架。这个框架的选择会对整体性能产生影响，因此也存在技术挑战。

如果基于已有的开源系统，成本会降低很多，例如直接在 ElasticSearch 或 Redis 上进行开发。因此，许多研究人员会选择成熟的系统来解决工程问题，并且会考虑使用开源社区的引擎。这样，他们可以更专注于开发应用程序和生态系统，例如与 AI 生态系统、长期存储进行对接，或者开发更多的案例以及上下游工具。因此，技术挑战主要包括两个方面：算法和后端的系统。

InfoQ：向量数据库会像传统数据库一样面临着选型问题吗？您能介绍下，什么样的企业适合什么类型的向量数据库吗？是单机版的还是插件版的，还是企业级的？

李莅：选型的出发点还是要看需求。如果业务量级不是特别大，而且有成本方面的考虑，想尽快用到这个技术，那就可以采用我上面提到的将两个现成的技术结合起来，这是最快也最省事儿了方式。这个里面再具体一点的就要看用户的使用习惯，比如说他这个公司他很喜欢用 MySQL，或者很喜欢用 PostgreSQL，或者可能还是喜欢用 Redis 或者 ElasticSearch 都可以在上面加上向量引擎能力，小规模的公司比较适合这种。

其他的体量更大的公司考虑的可能就不太一样了，数据肯定是更上一个量级的，这种情况下多半会倾向于自研。但是自研也不一定完全自研一个向量数据库，也可能只是定制一款向量引擎，和他的业务系统进行结合。

未来趋势展望

InfoQ：其实现在传统数据库市场就已经非常卷了，市面上有几百款数据库，在您看来以后向量数据库市场会不会更卷？

李莅：我认为向量数据库这个方向可能没那么卷。它跟传统的数据库不一样，传统的数据库是整个互联网或者信息行业任何地方都要用到的东西，而向量数据库现在火起来完全是作为大模型的配套设施，它一定是要捆绑在大模型上的。如果大模型用不起来，或者不火的话，向量数据库就没有那么多生意了。所以它不会像传统数据库那么卷，能入局这一领域的玩家，它一定是要有大模型方面的能力才能走下去的，因为它还有上下游生态需要考虑，向量数据库只是其中的一个环节。

InfoQ：您是否认为，以后所有的数据库它都会原生地支持用向量？

李莅：传统数据库广义上也分好几类：一类是关系型的，一类是 NoSQL 类的，还有一类是分析型的数据库。我觉得关系型的这种数据库它往上去做向量的不会很多，因为关系型数据库跟大模型的使用习惯还是不太相符的。它还是偏一个传统的 SQL 的场景，SQL 去做事务、写入数据、做一些查询，然后对接上层应用。关系型数据库去加向量的能力的也比较少，目前主要就是 PostgreSQL 加了向量插件。

然后 NoSQL 这类的，我觉得大部分都会加上。因为 NoSQL 支撑的就是半结构化或者非结构化的数据，它本身就能对接各种杂七杂八的应用，其中就包括 AI 相关的应用，所以它加上向量的能力是很自然的。在 NoSQL 上加上向量能力这个事情本身不困难，基本上 NoSQL 数据库都已经加了这种能力，比如说 ElasticSearch、Redis、还有 MongoDB 这些 NoSQL 他们都会加上。

还有一种就是分析型数据库，分析型数据库我觉得也必然会加上向量能力的。因为分析型数据库其实就是为大数据行业服务的，大数据跟 AI 本身就是一个非常紧密的结合关系，大数据就是属于 AI 的产业链里面一环，所以它很有必要去加上向量能力。

InfoQ：那您认为向量数据库未来的发展趋势是什么样的？会往哪方面发展呢？

李莅：这个趋势就现在已经可以看到了，一个是精研算法，算法还是有一定的提升空间。只是说这个东西可能不会那么早的对外公开的一个东西，各家都在做技术竞争力，不一定会马上就落到社区上面去推广。

还有一个就是架构层面的改动，一定是会往云原生和存算分离的这个方向去发展的，因为向量现在的技术上还是需要有大量的资源去构建索引。这个构建索引的资源开销是比较大的，但是构建完了之后可能一时半会儿也用不到了，那么这个时候如果要降本的话，就希望能有一些弹性资源去做这个事情。

此外，在不同量级数据的查询时也希望能弹性缩放。比如今天要搞一个活动，可能今天的请求就达到了平时的十倍、百倍，这时就要一下拉起大量的资源。活动结束之后，再把这份资源释放掉，也是希望有些弹性的资源。这就会需要存算分离的技术去支撑，可以很快速地把计算层去扩容和缩容，所以未来向量数据库技术要往这个方向去发展。

以「启航·AIGC 软件工程变革」为主题的 QCon 全球软件开发大会·北京站将于 9 月 3-5 日在北京•富力万丽酒店举办，此次大会策划了向量数据库、大前端新场景探索、大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构计算、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近 30 个精彩专题。

现已确认 130+ 名嘉宾，咨询购票优惠信息可联系票务经理 18514549229（微信同手机号）。