大模型时代数据库技术创新
本文整理自 2024 年 6 月 ArchSummit（深圳站） Data4AI 和 AI4Data 方面的探索和实践案例专题的同名主题分享。
大家好，我今天讲的内容总共分为三部分，先是数据库和大模型的演变历程，尤其是两者的结合的过程。然后在分别介绍向量数据库，以及大模型在数据库运维应用结合的实践经验。
但是我们会看到在过去的 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 是一个典型的全栈数据库体系，从接入服务、查询索引、数据引擎、分布式能力、向量索引，底层多种存储适配全栈能力，还有配套的生态集成、集群管理、平台管理能力。熟悉数据库的体系的同学就能知道，只有一个成熟的数据库，全栈的能力，才可以各方面都优化的很好，实现一个综合的效果。
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，更充分利用大模型的自主决策能力。谢谢大家！
- - - - - - - - - - END - - - - - - - - - -
点击阅读原文，了解向量数据库 VectorDB 更多信息
传送门