本文整理自 2024 年 6 月 ArchSummit（深圳站） Data4AI 和 AI4Data 方面的探索和实践案例专题的同名主题分享。

大家好，我今天讲的内容总共分为三部分，先是数据库和大模型的演变历程，尤其是两者的结合的过程。然后在分别介绍向量数据库，以及大模型在数据库运维应用结合的实践经验。

1    数据库与大模型

首先是第一部分，数据库和大模型的演变历程。

讲这些之前，先简单回顾数据库的发展历史。在 IT 行业，数据库有超过 70 年的历史了，对于快速发展的 IT 行业来说，一个超过 70 年历史的技术，感觉像恐龙一样。

但是我们会看到在过去的 70 年里面，从最早的大型机再演变到后面的小型机，PC 服务器，数据中心 + 互联网，云，以及现在的 AI 时代。数据库在不停地演变和革新，每隔一段时间，新的硬件，新的应用就会催生新的数据库技术。

所以每个时代都会有不同的当红数据库。像 PC 时代的 Oracle，互联网时代的 MySQL，云时代的云数据库。

到 AI 时代硬件演变成了 GPU + CPU，应用变成了 AI 原生应用，像微软的各种 Copilot，创业公司 Midjourney 等等。在大模型时代，数据库这个领域当前最红的就是向量数据库，以及通过大模型加持的各种智能运维能力，比如百度智能云的 DBSC。DBSC 是数据库智能驾驶舱的英文缩写，我们取名叫数据库智能驾驶舱，寓意就是像给数据库也和电车一样有一个智能驾驶舱的能力，实现一定程度的自动化，改善体验，降低门槛。

其实 AI 和数据库结合是老生常谈。那为什么现在工业界比以往要更兴奋？主要原因还是大模型今天表现出理解、生成、推理、记忆四大能力。

这和以往 AI 还是有本质的提升，大模型和数据库的结合相比以前的 AI 技术，让场景更通用、能力更实用。所以说大模型二次激发了数据库和 AI 结合的浪潮。

讨论这个之前，我们先来看下大模型技术栈。

IaaS 这一层发生了很大的变更，从原来的以 CPU 为中心，演变成现在 CPU + GPU 的模式。

PaaS 这一层有大模型，以及配套的工具链 Model Builder。为了应用实现的更简单，还有 Agent Builder 和 App Builder 等等。

向量数据库在 PaaS 这一层，通常向量数据库厂家还会带一个 RAG Flow，方便用户快速构建 RAG 应用。

而刚才提的数据库智能驾驶舱，属于 SaaS，是大模型和数据库结合的一种应用形式。其他的 SaaS 还有很多原生的 Agent、私有知识库，以及被大模型改造过的传统应用等等。

2    DB4AI：向量数据库

接下来我们分别讲讲这两大块，首先是向量数据库。

向量数据库不是一个新技术，2015 年的时候 Facebook 就在开发相似度检索库 Faiss，这个也是目前很多

向量数据库最早演变的基础。综合下来，向量数据库主要有三个场景：

• 首先是相似度检索，这个场景以向量检索能力为主。主要应用在多模态检索，推荐系统，分类系统里面。这些内容，熟悉的同学肯定立马反应过来在互联网里面电商等，政企里面公安等场景广泛有应用。

• 第二个是语义检索，这个应用到文本和向量的混合检索，需要用到多路召回的能力，有语义排序模型一起。主要是企业内部搜索场景。

• 第三个是现在比较火的 RAG 场景，RAG 是检索增强生成技术，利用到向量加持大模型，让大模型给出的结果更准确，主要应用各类知识库，客服，大模型记忆问答场景。

大模型效果让人惊艳，但是还是存在知识更新不及时，容易幻觉，没有内部知识的原因，所以带火了 RAG 技术，根据现在调查，目前超过 80% 的落地应用基本都是 RAG。RAG 是检索增强生成（Retrieval-augmented Generation）。利用向量相似度检索技术搜索文档，然后组合成 prompt 喂给大模型，大模型再生成最终的答案。这就规避了刚才讲到的大模型几个典型问题。RAG 是一个非常实用的技术。

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

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

   文件格式复杂，以 pdf 为例子，不光有文字，还夹杂有图表，图片里面又有文字。

   文件有上下文，要把上文相关的元信息提取出来，后面就更容易处理。如果不提取元信息，那下一步数据分块，就容易切分错误。

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

   数据切分，过大，过小都会有问题。所以一般是按照 300～400 个字节切分。还有处理更精细的，是按意图切分。

   另外就是 embedding 模型，文本类的有 BGE，openAI 的 text-embedding-3；文图关联的只有 CLIP。现在这块的多模态模型是下一步重点。

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

   query 预处理主要的步骤是意图识别，同义词生成，专有名词生成等。

   召回主要就是向量数据库的工作，要支持向量检索，文本检索，多路召回能力，召回之后重排技术。

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

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

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

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

但是给大模型补充知识的方法有好几种，大模型精调，利用大模型长文本能力把数据全部 prompt 进去，以及 RAG。

最近国内外大模型厂商都卷起了长文本技术，国内国外的大模型都有很大的提升，长文本都支持到了 1M 甚至更多。把数据全部喂给大模型，这个好处是充分利用模型的推理能力，能实现更强的推理效果。但是 RAG 技术有以下几个显著的优势：

• 成本更低，VectorDB 运算用的资源是 CPU，大模型是用 GPU 的，两者性价比差很远。

• 性能好，尤其是响应的时延更好，这也是机制决定的，用过大模型的就是知道，大模型响应时延瓶颈还是比较大。

• 问答稳定，数据库召回的每次结果都是稳定的，大模型回答存在随机性，还有幻觉问题。

• 复杂问题解决的更好，比如安全问题涉及到复杂过滤，在 RAG 里面都可以有很好的解决方案，而大模型会比较难解决。

• 定位问题方便，大模型还是黑盒，而 RAG 方案，整个过程都是可以追溯和分析的，可以更好的改进 corner case。

因此综合来说，RAG 在通用性，性价比上占据明显的优势。

前面讲到 RAG 核心是解决大模型最新知识的补充问题，所以 RAG 里面最典型的场景就是私域知识库。

在这个场景里面，每家企业自己的私有数据通过 embedding 存在向量数据库里面，去做各种业务，比如智能问答，客服等等。

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

• 各种版本管理，全量更新能力；

• 复杂的查询，包括标量，向量的混合查询；

• 公有云，私有化的部署，尤其是私有化上一般会有小型化的诉求。

我们还看到很多企业规划统一的知识库，这就要求向量数据库能有很强的扩展性，性价比，在私有化上有多租户的能力等等。

当然除了知识库场景， RAG 还能做大模型记忆库等其他场景。

实现向量有很多种方案，到底是传统数据库上支持向量插件，还是在需要一个专业的向量数据库。我们现在实践下来的答案是需要一个专业的向量数据库。

相比专业的向量数据库，传统向量数据库在系统架构，索引，存储方案上都不是为向量专项设计的，所以优化起来会比较复杂。包括架构上，索引，存储方案都不是给向量准备的，从而导致写入性能，查询时延，并发效率都比较低。是很难满足大模型时代的要求，也是缺乏竞争力的。

我们在实践中看到这些问题，因此我们全新自研了百度智能云 AI 原生向量数据库 VectorDB。主要的特点有四个方面

• 首先是分布式架构，这是向量数据库的基础，分布式架构设计的好坏直接决定向量数据库的天花板，百度智能云向量数据库 VectorDB，支持百亿级的海量的存储，超过 4096 高维向量等等。

• 第二个是高性能访问，这就需要深度的索引算法优化，目前我们支持比较全的种类开源算法以及我们自研的 puck 算法。性能上不管是时延，还是 QPS 等都相比开源综合下来要高 3～7.5 倍。

• 第三个是，全栈的能力，E2E 方案。客户需要实现的是一个业务，所以不止向量数据库，是否全套的能力和方案很重要。目前我们支持主流的各种开源框架，还结合百度内部的 embedding 库等，实现更好的实体，短语的识别等等。

• 最后是企业级能力上，尤其是弹性，高可用能力上。

综合来说，百度智能云向量数据库是一个成熟，功能齐全，性能卓越，简单易用的产品。

接下来，我就深度解析下，百度智能云向量数据库 VectorDB 几个核心技术。

先用一张图来看下整体技术体系，VectorDB 是一个典型的全栈数据库体系，从接入服务、查询索引、数据引擎、分布式能力、向量索引，底层多种存储适配全栈能力，还有配套的生态集成、集群管理、平台管理能力。熟悉数据库的体系的同学就能知道，只有一个成熟的数据库，全栈的能力，才可以各方面都优化的很好，实现一个综合的效果。

VectorDB 有三大核心能力和特点：

首先是成熟的分布式架构。向量还是一个偏 NoSQL 的场景，企业内部的数据可大，可小。所以我们利用原来多年积累的存储，数据库分布式经验，在系统的每一层都是可以扩展的：

• 代理节点，这个是无状态对等的，同时支持自动的负载均衡。

• 管理节点，通过 raft 协议做高可用，负责集群的拓扑，资源管理等。

• 数据节点，复杂数据的增删改，查询和索引。支持自动的 failover 和弹性的伸缩能力。

成熟的分布式架构可以说是向量数据库的一切的基石，只有成熟的架构才能很好的支持高可靠，高可用，强扩展，大规模的能力。

第二个是高性能数据引擎。

右边的图是 VectorDB 的数据引擎逻辑图。最核心的几个能力包括：

• 支持强 schema 模型，同时支持标量和向量数据存储。

• 支持二级索引，支持向量和标量的混合检索能力。

• 支持行存，列存，行列混存多种模式。

• 支持数据压缩能力。

• 具备快照，多版本的恢复能力。

• 能够硬件上充分利用芯片的指令集，编译器的能力，获得很好的性能。

我们通过从底到上，从芯片到架构的深度的优化实现了一个高性能的数据引擎。

第三个就是向量和标量的混合检索。

在实践中，经常需要融合文本检索和向量检索的能力，向量解决近似查询，标量解决复杂条件过滤。

要很好的实现这点就要有多种的过滤机制：

• 检索预过滤。

• 检索时过滤。

• 检索后过滤。

• 按统计信息对索引进行不同的过滤机制。

前面讲的核心机制，现在看看 VectorDB 和开源的对比。我们在相同的召回率条件下，整个 QPS 或者吞吐超越开源 3～7.5 倍。关于这个测试报告，大家可以在我们的 VectorDB 产品官网帮助中找到测试的规格、数据、测试代码，整个测试是可以复现。

最后来简单总结下 VectorDB 核心优势，包括：

• 远高于竞品的 QPS，以及降低超过 90% 的内存开销。

• 全栈的能力。

• 事务数据库级别的高可用能力。

• 海量数据库存储检索。

• 代码自研，兼容各种平台。

综合来说，百度智能云向量数据库 VectorDB 是一个成熟高效，综合能力领先的向量数据库。

3    AI4DB：数据库运维应用

前面一起讨论了 RAG、向量数据库，接下来看数据库和大模型结合的另外一个方向 AI4DB，大模型赋能数据库运维应用，通过大模型改进数据库运维能力。

我们的产品叫 DBSC，中文是数据库智能驾驶舱。先用一张图来看下我们的数据库智能驾驶舱的能力全景。

整个服务包括数据库运维的方方面面，包括请求分析、智能运维、智能压测、数据库 devops 等。另外我们用大模型整体改造了产品的实现，让这些能力都能结合上大模型的能力，有更好的使用体验。

大家可能会问，百度智能云这个产品和业界竞品的优势是什么。其实技术上不是这个产品的核心能力，这个产品和业界拉开差距的核心原因是要有积累大量的知识，其次才是将知识转化成产品能力。

百度和百度智能云在过去的 18 年的数据库使用和开发经验，服务了大量的客户，沉淀了多年的经验。现在我们将这些能力和经验沉淀在 DBSC 这个服务里面，免费开放给内外部客户。

这样 DBSC 就在支持内外部客户不停地开发、运维、和智能优化的过程中，又持续的将更多知识和能力沉淀下来，持续优化。这就形成了一个数据飞轮。用户越多，使用就越多，飞轮就会转的越来越快，服务的能力也就会进一步提升。

智能领航员技术上简单说一下，就是用的 RAG 技术，embedding 模型用的文心千帆的 text 模型，向量数据库用的 VectorDB。用 VectorDB 存储积累的大量专业知识，所以用户使用下来，效果非常不错，根据我们的测试满意度 80% 以上。

今天我分享的主要内容就是这些，最后我们简单畅享一下未来。大模型和数据库会持续结合，我们也看到了很多新的趋势，从底层的 IaaS，模型会从云端扩展到端；PaaS 会从现在纯文本模型扩展到多模态，上层应用会从当前主流的 Copilot 扩展到 Agent，更充分利用大模型的自主决策能力。谢谢大家！