百度智能云向量数据库创新和应用实践分享

在 IT 行业，数据库有超过 70 年的历史了。对于快速发展的 IT 行业来说，一个超过 70 年历史的技术，感觉像恐龙一样，非常稀有和少见。

但是数据库之所以有这么长的生命力，核心是在不停的变更和创新。

简单回顾一下数据库的历史，在过去的 70 年里面，数据库一直跟着底层基础设施和上层业务的变化的潮流，一直在变化。从最早的大型机再演变到后面的小型机、PC 服务器、数据中心 + 互联网、云、以及现在的 AI 。

数据库在不停地演变和革新，每隔一段时间，新的硬件和新的应用就会催生新的数据库技术。所以每个时代都会有不同的当红数据库。像 PC 时代的 Oracle，互联网时代的 MySQL，云时代的云数据库。到 AI 时代硬件演变成了 GPU + CPU，应用的负载也从 CPU 往 GPU 迁移。在大模型时代，数据库与大模型相互成就。数据库这个领域当前最红的就是向量数据库，以及通过大模型加持的各种智能运维能力。另外，还有一个非常有潜力的方向是大模型数据工程，负责给大模型训练和 AI 原生应用准备数据，提升模型训练效果和加速应用落地。

如果把数据库放到整个 AI 技术栈来看，主要是处在 PaaS 和 SaaS 这一层，向量数据库和数据工程在 PaaS，运维应用在 SaaS 这一层。除了数据之外，还有大模型，以及配套的工具链 Model Builder。为了应用实现的更简单，还有 Agent Builder 和 App Builder 等等。

大模型时代未来帮助客户快速构建大模型相关应用，应用、模型、数据三者缺一不可。前面是模型和应用相关技术栈发展较快，现在工业界的普遍共识是数据技术栈这块欠缺比较多，国内外有大量的投资投向了这个领域。

为什么数据相关技术栈会成为热点，主要是数据和模型是相互相成，不可或缺的。数据平台和大模型相互成就，这个体现在两个方面，一个是大模型成就数据库，另外一个是数据库成就大模型。

大模型表现出理解、生成、推理、记忆四大能力，激发了数据库与 AI 的深度融合，让场景更通用、能力更实用。所以大家看到了把大模型应用到数据平台中可以解决一系列运维，提升易用性的潜力。

另外，大模型效果让人惊艳，但是还是存在知识更新不及时，容易幻觉，没有最新企业的内部知识和数据，无法解决企业真实业务问题，所以带火了 RAG 技术。根据现在调查，目前超过 80% 的落地应用基本都是 RAG。

RAG 是检索增强生成（Retrieval-augmented Generation），利用向量相似度检索技术搜索文档，然后组合成 prompt 喂给大模型，大模型再生成最终的答案。这就规避了刚才讲到的大模型几个典型问题。尤其是 2B 场景里面，缺乏企业自主的数据，企业无法解决企业智能问题。通过向量数据库为主的 RAG 方案是一个比较好的解决大模型数据更新不足的解决方案。

但是要做好 RAG 要经过数据提取、数据索引、检索、生成四个阶段，每个阶段都有不少难点。我这里简单提一下给大家做参考：

首先是数据提取。核心是要把各种结构化，非结构化数据能提取出来，用于后面的处理。这里的复杂度主要是：

文件格式复杂，以 pdf 为例子，不光有文字，还夹杂有图表，图片里面又有文字。
文件带有上下文信息，要把上文相关的元信息提取出来，后面就更容易处理。如果不提取元信息，那下一步数据分块就容易切分错误。

其次数据索引。这一步做好文档的切分，使用 embedding 模型把文件 embedding 成向量，才可以把向量存到向量数据库里面去。这里的难点又有两个：

数据切分，过大或者过小都会有问题。所以一般是按照 300～400 个字节切分。还有处理更精细的，比如按意图切分。
另外就是 embedding 模型，文本类的有 BGE， OpenAI 的 text-embedding-3，文图关联的只有 CLIP。现在多模态模型是下一步重点。

然后就是检索。检索主要分 query 预处理，召回两个步骤：

query 预处理主要的步骤是意图识别、同义词生成、专有名词生成等。
召回主要就是向量数据库的工作，要支持向量检索、文本检索、多路召回能力、召回之后重排技术。

最后是生成阶段。检索出来的结果在给大模型之前，还要 prompt 优化，包括 prompt 加上 step by step ，针对场景加上相应的提示词等。

最终的结果依赖大模型的理解，生成，逻辑推理能力。大模型能力的强弱也直接决定 RAG 的效果。

所以大家会看到要把 RAG 作为大模型应用目前主要落地场景，但还是有非常多改进的空间的，这方面的创业公司也很多，技术发展也很快，机会很多。

RAG 技术从业务逻辑上来讲，是对大模型最新的知识的补充，所以 RAG 未来的空间，核心是企业私有化知识到底多不多，有没有用于业务价值的地方。这并不取决于大模型本身能力发展到什么程度，大模型变得多智能。因为大模型再智能也无法获取私有的数据。

在 RAG 里面承担向量召回的能力，业界主要有两个流派，一个是在传统数据库里面支持插件，一个是全新自研一个以向量为场景为主的专用向量数据库。

首先我们看场景，RAG 最主要的是私域知识库场景。在这个场景里面，每家企业自己的私有数据通过 embedding 存在向量数据库里面，去做各种业务，比如智能问答，客服等。

每家企业的数据是不一样的，部署的要求是不一样的。因此对向量数据库也有很多要求，需要能支持全生命周期的数据管理能力。技术上有很多关键的点要支持，比如

各种版本管理，全量更新能力；
复杂的查询，包括标量，向量的混合查询；
公有云，私有化的部署，尤其是私有化上一般会有小型化的诉求。

我们还看到很多企业规划统一的知识库，这就要求向量数据库能有很强的扩展性，性价比，在私有化上有多租户的能力等等。我们会看到从客户场景角度，需要的是一个专业全面的能力的数据库，不是一个简单的插件可以完成的。

另外，相比专业的向量数据库，传统向量数据库在系统架构、索引、存储方案上都不是为向量专项设计的，从而导致写入性能，查询时延，并发效率都比较低。是很难满足大模型时代的要求，也是缺乏竞争力的。

我们在实践中看到这些问题，因此选择全新自研百度智能云 AI 原生向量数据库 VectorDB。虽然全新自研难度更高，但是同时带来的天花板也更高。

从架构，存储引擎，计算引擎和平台能力都可以更有针对性的设计，以及取得更好的效果。在今年 6 月份我们正式推出了 1.0 版本。这个也带来很强的产品能力，主要的特点有四个方面：

首先是分布式架构。这是向量数据库的基础，分布式架构设计的好坏直接决定向量数据库的天花板，百度智能云向量数据库 VectorDB，支持百亿级的海量的存储，超过 4096 高维向量等。如果是基于传统数据库，不是从底层架构开始考虑，扩展性方面会非常难做。
第二个是高性能访问。这就需要深度的索引算法优化，目前我们支持比较全的种类开源算法以及我们自研的 puck 算法。性能上，不管是时延，还是QPS 等都相比开源综合下来要高 3～7.5 倍。
第三个是全栈的能力和端到端方案。客户需要实现的是一个业务，所以不止向量数据库，是否全套的能力和方案很重要。目前我们支持主流的各种开源框架，结合百度内部的 embedding 库等，实现更好的中文实体和短语的识别等等。
最后是企业级能力上，尤其是弹性和高可用能力上做到了一个向量数据库目前业界天花板的水位。

综合来说，选择全新自研这条路，从而带来了一个功能，性能更强大，使用更简单的产品。