大模型时代数据库技术创新

本文整理自 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 要经过数据提取、数据索引、检索、生成四个阶段，每个阶段都有不少难点。我这里简单提一下给大家做参考：

首先是数据提取。核心是要把各种结构化，非结构化数据能提取出来，用于后面的处理。这里的复杂度主要是：
- 文件格式复杂，以 pdf 为例子，不光有文字，还夹杂有图表，图片里面又有文字。
- 文件有上下文，要把上文相关的元信息提取出来，后面就更容易处理。如果不提取元信息，那下一步数据分块，就容易切分错误。
其次数据索引。这一步做好文档的切分， embedding 模型，把文件 embedding 成向量，才可以把向量存到向量数据库里面去。这里的难点又有两个：
- 数据切分，过大，过小都会有问题。所以一般是按照 300～400 个字节切分。还有处理更精细的，是按意图切分。
- 另外就是 embedding 模型，文本类的有 BGE，openAI 的 text-embedding-3；文图关联的只有 CLIP。现在这块的多模态模型是下一步重点。
然后就是检索。检索主要分 query 预处理，召回两个步骤：
- query 预处理主要的步骤是意图识别，同义词生成，专有名词生成等。
- 召回主要就是向量数据库的工作，要支持向量检索，文本检索，多路召回能力，召回之后重排技术。
最后是生成阶段。检索出来的结果在给大模型之前，还要 prompt 优化，包括 promot 加上 step by step ，针对场景的加上相应的提示词等。
最后的结果依赖大模型的理解，生成，逻辑推理能力。大模型能力的强弱也直接决定 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 是一个典型的全栈数据库体系，从接入服务、查询索引、数据引擎、分布式能力、向量索引，底层多种存储适配全栈能力，还有配套的生态集成、集群管理、平台管理能力。熟悉数据库的体系的同学就能知道，只有一个成熟的数据库，全栈的能力，才可以各方面都优化的很好，实现一个综合的效果。