无处不在,搜你所想

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

首先是第一部分，数据库和大模型的演变历程。讲这些之前，先简单回顾数据库的发展历史。在 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. 首先是数据提取。核心是要把各种结构化，非结构化数据能提取出来，用于后面的处理。这里的复杂度主要是：

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

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

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

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

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

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

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

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

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 有三大核心能力和特点：

分享到：