历时 5 个月从零到一研发一款数据库产品，这些坑他们已经踩过了 ｜InfoQ 独家专访百度智能云向量数据库团队

作者 | 冬梅

采访嘉宾｜百度数据库产品总架构师朱洁、百度数据库高级架构师郭波

生成式人工智能技术发展带动了大规模预训练模型的广泛应用，向量数据库成为了整个发展链条中的重要一环。人工智能和机器学习可以将非结构化数据（文本，图像，视频等）转换成数学上的向量表示。向量数据库正是一种专门用于存储和检索向量数据的数据库，向量数据库实现对向量的处理从而实现了非结构化数据的检索和相似性计算。对于大模型来说，向量数据库意味着更高效、更精准的模型应用。

借着大模型崛起这股东风，众多向量数据库厂商也获得了资本的青睐。去年上半年，荷兰 AI 原生向量数据库厂商 Weaviate 获得 5000 万美元 B 轮融资；美国明星向量数据库厂商 Pinecone 宣布筹集了 1 亿美元的 B 轮融资。这些资本驻足的背后，是向量数据库的关注度已经达到了前所未有的高度。

那么，向量数据库为何会受到如此高的关注？那就要从向量数据库对于大模型的助益来说起。

大语言模型存在知识更新不及时、会产生幻觉、无法具备特定行业或私有知识，以及难以实现安全回答等问题。通过引入向量存储模块作为大语言模型的长期记忆体，通过向量存储模块中数据的反馈和干预，能够以较低的成本解决上述问题。

正是由于向量数据库在大模型应用中的显著优势，越来越多的厂商开始推出自家的向量数据库产品。

1 月底，百度智能云推出了一款面向企业级市场的专业向量数据库产品 VectorDB（简称 VDB）1.0 版本。这款 VectorDB 采用了全新设计的数据库内核，能够支持百亿级弹性伸缩，相比同类开源产品，VectorDB 1.0 的 QPS 性能在不同场景下能够提升 1 倍到 10 倍不等。

那么，百度智能云为何选择在这样一个时间点来推出这款专用向量数据库？专用向量数据库的需求是真实存还是市场泡沫？在研发一款专用向量数据库时百度智能云解决了哪些技术上的难题？

近日，有幸独家专访了来自百度向量数据库研发团队的百度数据库产品总架构师朱洁和百度数据库高级架构师郭波揭秘这款向量数据库研发背后的故事。

郭波：去年 BES 团队对外介绍过，文心一言当时确实使用的是百度的 ES（简称 BES），但在向量检索这块，使用的并不是 FAISS 库，而是 BES 团队利用 C++ 语言基于开源 HNSW 算法进行优化以及据此研发的专用向量检索。

我认为大模型的应用场景不局限于这类应用，还有更多场景可以利用大模型来实现，例如知识库管理和 RAG 等场景。这些场景除了需要强大的检索能力，也需要数据库相关的能力。尤其当我们的产品面向 B 端客户，特别是大型 B 端客户时，向量检索能力只是其中一个诉求，还有许多与数据库相关的高级功能也同样重要。

市场上有非常多的开源产品，具备一定的向量相关能力，向量检索算法和检索库非常丰富，这些都很容易被获取和应用。在我看来，未来向量数据库的竞争力不仅仅在于“向量”二字，更在于“数据库”这三个字。向量数据库不仅包含向量相关的能力，更需要包含数据库的功能。去年我们观察到，市场上的向量数据库大多重视“向量”而忽视“数据库”。对于这类向量数据库而言，它们可能只重视接入开源的向量能力，忽视了数据库相关能力，尤其是一些高级能力的建设。短期内，这类向量数据库产品可能能够服务一些规模较小且需求宽松的客户，但从中长期来看，它们可能难以满足大规模且要求非常严格的 B 端客户的需求。去年，我们在充分调研之后认为，百度有必要立项研发一款专业的向量数据库，这款数据库不仅要做好“向量”，更要做好“数据库”本身，立足于长远发展。

朱洁：我想补充一下关于郭波提到的关于“数据库”三个字的具体含义。在业务发展到现在这个阶段，我们遇到了很多实际客户，他们确实有这样的需求。这不仅仅是指向量检索能力，还包括对更多数据类型的支持和处理，包括数据库的一些 ToB 的高级能力，包括对高可靠、高可用、低成本、易用性等看起来老生常谈但是确实又非常关键的能力等等。我们可以举几个例子。

首先，为了解决企业用户的文档管理问题，企业有很多安全方面的需求。比如，如何实现多租户隔离，确保不同职能部门具有相应的不同权限，以及如何进行敏感数据的访问审计。其次，我们有客户提出了异地多活的需求，这就是典型地对高可用和高可靠的能力的诉求，这种能力还可以在一些更深入的场景中被使用。目前市场上的向量数据库大多只提供简单的向量检索能力，在其他方面却比较欠缺。从长远来看，包括我们现在实际接触到的客户，这些能力都是不可或缺的。我们认为，专业的、面向企业级客户的这些定位对向量数据库而言是非常有必要的，这就要求数据库不仅要具备向量检索相关的能力，更要能够满足企业级用户在数据类型支持、灵活性、接口易用性、安全特性、多租户隔离、访问审计以及异地多活等方面的需求。

郭波： 我的回答是“是的”。我们可以对市面上常见的向量数据库类型进行简单的阐述。

关系型数据库如 MySQL 和 PostgreSQL 是非常经典的数据库，这类数据库在其特定的场景下表现出色，但在数据存储组织上并不适合向量数据，也缺乏专门优化的向量检索引擎，接口形态上也缺乏 API 等现代化形式，同时，在面向大规模数据的分布式管理能力方面也所不足。从这些分析来看，我认为它们并不适合用来作为向量数据库来承接相关场景。

非关系型数据库如 MongoDB 和 ES 等，虽然它们在某些方面比传统关系型数据库会更加合适一点，然而对于百度来说，仍然存在一些因素导致我们不能依赖这类数据库。众所周知，MongoDB 和 Elasticsearch 的许可证已经变更为 SSPL，在某个版本之后，我们无法再依赖它们来构建产品。另一方面，这类系统，在分布式能力上不及我们的预期，对向量场景也缺乏相应的优化（例如内存有效利用率偏低，大规模场景下导致成本偏高等），长期来看也不合适。

因此，从百度智能云客户及自身的各类诉求出发，确实需要自主研发一个适合我们的客户需求的向量数据库。既然我们决定进行自主研发，就必须要针对性地对整个数据库进行系统性工程优化，确保无论是在分布式层面、存储引擎、检索引擎，还是向量相关能力等方面，都能达到一个理想的状态。

郭波： 之前提到的 HNSW 算法等，这些是基于开源的。其他所有东西，包括百度自研的 Puck 算法都是我们自己或百度其他团队研发的。我们数据库团队自研的部分涵盖从存储格式、存储引擎、检索引擎、Schema 以及数据类型、分布式架构、再到产品的管控层，以及控制台和前端等等。

关于检索引擎，并不是说有一个 HNSW 算法，就可以直接提供向量检索服务了，实际上，我们需要在这些算法和存储引擎之上，与数据库系统的其它组件进行融合，构建出检索引擎，才能对外提供检索服务。

郭波：去年我们经过充分调研之后，认为确实有必要自主研发一款向量数据库。同时，从人才储备的角度来看的话，我们也有能力做到。因此，8 月份我们开始了项目的立项工作以及系统的设计工作，到了 9 月中旬，我们进入了紧张的研发阶段。到今年 1 月底，我们完成了第一个版本的开发和测试，并成功上线公测。

我们的团队由来自不同背景的成员构成，主要来自于云存储和数据库两个部门，团队中既有精通分布式存储引擎的专家，也有非常了解数据库产品研发的开发人员，是一个人才组合很平衡的团队。

郭波：我们系统和产品是全新研发的，在设计阶段就原生地赋予了系统较强的向量能力，而不是在已有的系统中事后添加。在已有的系统中，事后添加向量插件，会导致难以针对向量特性进行优化。

例如，在存储方面，我们认为列存引擎比传统的行存引擎更加适合向量数据的管理，为此专门研发了列存引擎。我们也充分利用了指令集和编译器优化，提高性能。在工程层面，我们尽量降低非浮点计算的额外开销，提高资源效率；尽力优化内存开销，提升内存有效利用率等。

郭波：我以底层数据组织方式来举个例子，我们认为，列存引擎可能比行存引擎更适合向量数据 。 假设一条数据包含多个向量字段，而这些字段又来自不同的原始内容，并且可能使用了不同的 embedding 模型。在这种情况下，如果要为这些字段的数据建立索引，需要分别处理，甚至需要对不同字段建立不同类型的向量索引，退一步来说，即使采用相同的索引方法，其索引参数也可能不同。因此，使用列存引擎可以更好地将不同向量字段的数据进行隔离，从而使得系统能够更精细地处理它们。例如，在构建索引和向量检索的过程中都只需要访问与目标字段相关的原始数据和索引数据，而不用访问其它字段的相关数据，这极大地避免了额外的资源开销。这就是一种典型的针对向量场景的优化措施，而且是从最底层的数据存储组织上开始的优化。 所以可以看出，我们会根据向量数据和场景本身的特点，自底向上，在各个层面都执行针对性的优化，以确保充分利用资源，发挥性能优势。

郭波：我们最近完成了性能测试和 Benchmark 的建设工作。我们完成了与某款知名开源向量数据库的详细性能对比。总体来说，我们的性能表现明显更加出色。我总结了两点：

第一， 我们在 128 维、768 维和 960 维三种数据集上都进行了测试，在所有数据集场景下，在相同的召回率下，我们数据库的检索性能都大幅超越了开源系统。在一些场景中，性能提升接近一倍，而在一些其他的场景中最大能有十倍的提升，这个提升可谓相当明显。

第二， 从召回率的视角来看，当我们放宽召回率要求时，比如从 99% 降到 95%，再降到 90% 时，我们数据库的检索性能够实现显著的线性提升。

郭波：客观来说，肯定遇到了一些技术挑战。其中一个大的挑战是存储引擎，尤其是列存引擎的研发。在综合考察了开源社区、友商等方案后，我们发现百度智能云内部的一款自研的列式存储格式库最符合向量场景，该格式库支持列存、列式压缩、KV 分离等关键特性，是非常好的引擎基础。但它仅仅只是一个格式库，还不是一个完整的引擎，没有具备像 Schema 体系、内存表、快照、Compaction、查询优化、异常恢复等等这些引擎层面的关键特性，这就需要我们自己在此基础上继续进行研发。面对这样的挑战，第一步，我们快速借调了一些比较懂 KV 引擎的同学，然后大家一起合作，将大问题拆解为一系列的小问题，然后来回讨论，逐步解决这些问题，在解决了全部问题之后，做好各个子模块的接口定义和层次划分，然后高效完成研发，达成目标。

另一个大的挑战是向量检索引擎的设计和研发。这包括两个方面：第一，将我们的检索库与存储引擎进行对接；第二，在对接的基础上构建完整的检索引擎。我们从开源社区仅能够获得基础的检索库，要将检索库与后端进行对接需要做很多的改造，包括 Schema、存储组织、索引组织、标量向量混合检索机制等方面的工作。此外，在构建检索引擎时，我们还需要考虑其通用性，进行抽象设计，以支持各类不同的向量索引和检索方法，从而针对不同的算法、参数和场景构建出一个统一的检索引擎。以上这些工作的效果决定了整个检索机制的性能和灵活性。面对这个挑战，我们首先让团队成员相互了解对方的工作，包括具体的任务和设计背后的考量。然后通过不断迭代确定方案并最终解决问题。

在应对这些技术挑战的过程中，我们发现，培养或发掘团队中善于构造异常场景的人才是非常有效果的做法。因为这类人才非常善于针对设计方案来推理和构造各种可能的异常场景，然后反过来用这些场景去挑战设计方案，来检验方案的完整性和健壮性。通过这种方式，我们能够快速地进行设计的迭代，加速研发和问题解决的过程。

我们的里程碑大概是这样的：10 月底，存储引擎完成了基本功能并能够正常运行；11 月底，检索引擎层全部打通，可以跑向量检索；到了 12 月初，可以跑基本的性能测试，当时虽然是第一轮性能测试，但性能表现已经超越知名开源系统。

郭波：开发用的是 C++ 17 版本。

我们的测试主要分为两个大方向，一个是云产品层面的测试，另一个则是更底层的数据库内核层面的测试。在数据库内核层面，测试工作又进一步分为功能测试和混沌测试。功能测试关注的是功能和接口的正确性，确保系统能够按照预期正确响应用户请求。混沌测试，是针对分布式系统的健壮性，或者说高可用高可靠等特性的测试机制。在这个测试中，我们会尝试引入各种异常情况，包括硬件异常、网络异常、资源异常，以及节点宕机等，模拟出非常恶劣的运行环境。如果在这种环境下，我们的数据库内核系统仍能够持续稳定地运行下去，那就说明系统具备了非常强的异常环境容错能力。

在数据库内核层面专门进行这样的混沌测试，也是源自于百度分布式存储领域的优良传统。在百度智能云内部，所有的分布式存储系统都要通过这样的测试，而且是将这类测试作为例行化测试的一部分。我本人此前做了多年的分布式存储，因此在带队开发向量数据库时，自然也将这个优良传统给继承过来了。专业的混沌测试不仅可以验证系统的稳定性和可靠性，还能够确保系统在面对各种环境挑战时，能够保持更加稳定的性能。通过这些严格的测试，我们尽最大努力高标准满足客户对于云服务的稳定性期望。除了混沌测试之外，我们这边还有一个优良传统，即对分布式系统进行形式化验证，从而能够在早期发现分布式逻辑层面的问题，我们对向量数据库内核也进行了形式化验证。

朱洁： 关于多模态，我们认为在向量数据库层面更多地是提供相应的数据库能力以支持多模态，但并不直接负责处理多模态，多模态的处理更多是在产品层面或者解决方案层面端到端进行的。例如，我们的向量数据库支持非常丰富的数据类型，能够支持将不同模态的原始数据，以及它们对应的向量数据，关联性地进行存储和管理，比如将它们都存储到同一行中。那么未来在向量检索时，可以将目标向量相关的各种模态的原始数据信息一并召回出来，方便更上层的机制来进行处理。

另一方面，如果期望能够从端到端的角度处理多模态数据，比如文本、图片、视频等，需要在前端具备 embedding 的能力，需要有相应的模型来帮助业务进行 embedding。目前，在产品层面，我们会接入百度智能云千帆大模型，会提供 High-Level SDK，通过调用千帆的能力来实现文本 embedding 和图片 embedding 等，然后通过调用向量数据库实现这些数据的关联存储和召回。

所以从上面这些角度来看，我们是端到端地支持多模态的。我们会进一步丰富 High-Level SDK 等工具套件，让用户能够更加方便地处理多模态，或者构建一些 AI 工作流。

朱洁： 目前，多模态领域仍处于发展之中，例如最近爆火的 Sora 技术也是刚刚起步。在多模态方面，虽然我们还没有看到业界的非常强大的案例，但确实有一些客户，例如自动驾驶企业，正在与我们合作进行测试多模态支持。自动驾驶企业需要基于图片的内容语义，对图片进行管理和处理。还有一些娱乐文化领域的企业，他们拥有大量图片和视频资源，而且这些资源还具备相应的文本信息，是非常直接的多模态场景，他们也在构建相应的解决方案。虽然目前还没有看到哪个多模态场景已经深度落地，但我相信这个领域的繁荣发展将来一定会催生一些多模态相关的 AI 原生应用。

朱洁：RAG 并不是一个新概念，而是由 OpenAI 重新带火的一种技术。RAG 并不是与向量数据库在同一层次，而可以被视为一种技术或解决方案。最初，RAG 的概念起源于搜索引擎领域，结合了企业内部搜索的能力来增强搜索功能。

OpenAI 最初是将向量数据库作为外部工具来使用。后来，为了简化用户使用，他们在系统内部开发了一个插件，使用户可以更容易地上传文档数据，形成了一个简化版的 RAG 系统。这样做的好处是，使用 OpenAI 后，它可以帮助你处理文档并创建 demo，特别适合小型团队快速制作产品原型。然而，这种插件式的应用有其局限性，例如限制上传文档的数量和缺乏权限管理机制，无法满足企业级应用的需求。此外，其价格昂贵，且在文档处理和索引定制方面存在限制。

从长期来看，我们认为大型企业和机构的数据，特别是那些大模型无法获取的内部生产研发数据，才是 RAG 系统真正发挥作用的地方。 因为这些数据通常具有严格的权限管理需求，而且大模型无法获取这些数据进行训练。

未来，我们相信真正有长期发展潜力的将是大模型与企业级向量数据库的结合。企业级向量数据库需要具备更强的扩展能力、全面的安全权限管理、分布式性能以及低成本，以满足企业级客户的需求。随着大模型的不断进化，它们能够获取和学习的信息越来越多，但在企业内部独特的数据面前，RAG 系统仍然有其价值。OpenAI 推广的 RAG 概念虽然有其价值，但真正有意义的应用场景还是在企业级数据中。只有当企业拥有自己独特的数据时，RAG 系统才有必要存在。

朱洁： 目前，我们并没有急于讨论开源这个问题。大模型和向量数据库还处在非常快的发展阶段，我们认为最核心的任务还是持续去构建更强大的产品能力，这是首要的事情。

开源的一个核心作用是让更多人能低门槛使用产品。这一点通过云上或其他手段已经能够做到。目前，我们已经在云上免费提供给大家使用，欢迎大家直接登录官网来使用 VectorDB。未来，我们可能会考虑让客户在他们自己的环境里使用我们的产品，这是我们未来规划中的一部分。

郭波：在整个研发过程中，我们对团队成员的工作状态确实有一些非常深刻的感受。首先，团队整体士气非常地积极和自信，包括我自己也是这样的。大家都认为，有机会参与这样一个新颖的项目是非常令人兴奋的，同时大家也都能感受到项目的紧迫性，非常投入地工作，努力保持项目进度，尽管工作强度大，但并没有多少抱怨。

其次，团队成员对不同方面的技术方案的理解能力和接受度都非常好。团队中有些成员擅长分布式系统，而有些则擅长存储引擎，还有些则专注于向量索引和检索，另一些则具备丰富的产品管控和控制台研发经验。大家都积极地去了解和学习彼此擅长的领域，这使得每个人都能更深入地理解整个系统和产品。这样的团队合作精神极大地提高了我们在遇到问题时的解决效率。

朱洁： 非常认同郭波刚才所讲的内容，团队的所有同学都非常认真负责。首先，从我自己的观察来看，从上到下，大家都对这个项目感到非常兴奋。因为大模型是云计算和人工智能领域未来数年中能够看到的唯一巨大的机会，这个机会带来了向量数据库领域的巨大发展机遇，无论是产品团队还是技术团队，都对能参与其中感到非常激动，也非常珍惜这个机会。

其次，目前我们的产品已经上线公测，从实际的情况来看，市场反馈非常积极。在非常短的时间我们就有大量的用户开通了免费集群进行使用和测试，而且每周这个数据在呈现一个非常快速的增长。在使用之后，他们也会提出各种各样新的需求，这给我们带来了非常正面的反馈。我们看到用户数量的快速增长，受到大家的认可，以及收到各种不同的问题和需求的反馈，都是非常令人兴奋的事情，对我们而言，这些都非常有价值。

朱洁： 预测未来的应用场景是非常困难的，从本源出发，一个企业拥有哪些数据，这些数据将决定未来可能出现的应用场景。 就像滴滴打车的出现，本质上是因为手机中的位置数据。有了这样的核心数据，就有了创新的空间。企业的创新能力取决于它拥有的数据类型。如果一个企业只有办公数据，那么它可能孵化出与办公相关的应用。如果企业拥有自动驾驶相关的图片数据，那么它可能会孵化出自动驾驶相关的应用。因此，一个企业能够使用向量数据库孵化出什么样的应用，取决于它拥有的数据。

各行各业的企业拥有不同类型的数据，这也是我们认为大模型可能会重构当前所有系统的原因。向量数据库无疑会对现有的系统，如办公自动化、自动驾驶图片管理、销售流程、ERP，甚至财务系统，起到增强和重构的作用。

另一方面，未来可能会出现我们现在甚至没有想到的 AI 原生应用。就像移动手机的位置数据催生了新业务一样，未来可能会有更多的智能体出现，它们需要知识，这些知识可能来自大模型，也可能是企业内部的专有知识。因此，企业的数据将是这些智能体知识的重要来源。总的来说，向量数据库将在未来的企业和 AI 应用中发挥关键作用，无论是增强现有系统，还是孵化全新的 AI 原生应用。

郭波：目前，我们的大量文档类数据仍然以 pdf、doc、ppt 等文件形式存在，它们存储在个人电脑中，或者存储在云上的对象存储和文件存储中，由于是非结构化数据形态，这些文档的内容并没有得到很好的挖掘和管理。造成这种现象的核心原因，并非是文档内容缺乏价值，恰恰相反，我们认为内容非常有价值，只是此前的技术难以实现其价值发现。

因此，当大模型技术突破之后，足够在语义层面对文档内容进行深度挖掘和管理，补齐了文档内容管理的最后一个短板，大家又重新开始重视文档内容的价值。我们可以从各类文件中提取内容，进行各种精细地处理，包括解析、分割、向量化、关键词索引、语义索引、提取元数据、甚至根据语义或者多模态技术构建不同内容之间的关系等等。然后将所有这些信息存储在向量数据库中，并基于这些信息进行各种复杂的检索或处理，支撑众多的内容类应用，例如目前非常火的 RAG 等。

这样，各类企业就能够释放非结构化文件内容的价值，为存量业务提效，甚至寻找新的业务机会。我们认为，在未来，文档管理的主阵地有很大的可能从非结构化的对象存储转移到半结构化的数据库系统中，尤其是向量数据库系统。这是我们所畅想的新场景，我们认为这里面存在着巨大的机会。

郭波：今年我们将重点关注三个方向。第一个方向是 RAG。正如上一个问题所指出的那样，我们认为 RAG 是一个非常重要的方向，为了支持好 RAG，向量数据库除了需要支持好向量检索，还需要支持好全文检索、多路检索召回和融合排序等关键技术，这些技术的研发和优化，是我们今年的关键攻关点之一。

第二个方向是，更高效，更低成本的能力。从内外部客户的情况来看，有一些客户对成本非常敏感，尤其是在当前这个降本增效的时代，一些企业期望进行相关的尝试，又难以提供很高的预算。为了服务好这类成本敏感性客户，我们今年会重点发力低成本的向量索引和检索机制。进一步地，我们还会尝试研究将一些智能化能力引入到这些索引和检索技术中，进一步提升效价比。

第三个方向是，立足于向量数据库的 AI 应用套件或框架。我们会以 RAG 和多模态为突破口，提供全流程的工作流套件，大大降低这类应用的开发难度，降低开发门槛，提升开发效率。

朱洁： 我们将会特别关注内外部生态的融合，比如和百度内部大模型生态的充分融合，包括将我们的技术应用到百度的各种服务中，如百度网盘、文库等。我们的目标是通过这种融合和应用，产品得到进一步深度的打磨，这样也能帮助企业更好地利用我们的技术。这也是百度的一个核心优势。我相信，除了技术之外，我们强大的生态系统是我们的数据库产品能够成功的关键因素。这是非常重要的。

郭波：从技术上看，未来向量数据会持续在如下几个方向上发力：1、持续夯实大规模、高效率、低成本、高性能、高可用和高可靠等基础能力，构建不同风格的产品形态，服务不同诉求的客户；2、各类 AI 原生应用及场景所依赖的关键技术，例如提供并优化各类复杂索引和检索的能力，持续提升检索效率和效果，提供文档内容管理和知识库构建所需要的各类存储索引等能力，甚至是在数据模型层面进行深度创新来解决问题；3、丰富的企业级特性，满足企业级客户在二次开发、成本、效果、安全、审计、运管、以及融入复杂的存量业务架构的能力；4、深度融入大模型生态，为客户提供好用易用的端到端工具、套件以及解决方案，推动更多客户以更容易的方式触达大模型技术生态；5、更长远来看，还可以向上构建基于语义的内容管理平台，推动内容管理进入 AI 原生时代。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

谷歌大裁员引发元老集体抗议：领导脑袋空空，无能的中层管理团队不断扩大

德国再次拥抱Linux：数万系统从windows迁出，能否避开二十年前的“坑”？