本文整理自 2024 年 6 月 ArchSummit(深圳站) Data4AI 和 AI4Data 方面的探索和实践案例专题的同名主题分享。
大家好,我今天讲的内容总共分为三部分,先是数据库和大模型的演变历程,尤其是两者的结合的过程。然后在分别介绍向量数据库,以及大模型在数据库运维应用结合的实践经验。讲这些之前,先简单回顾数据库的发展历史。在 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、私有知识库,以及被大模型改造过的传统应用等等。向量数据库不是一个新技术,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 是一个典型的全栈数据库体系,从接入服务、查询索引、数据引擎、分布式能力、向量索引,底层多种存储适配全栈能力,还有配套的生态集成、集群管理、平台管理能力。熟悉数据库的体系的同学就能知道,只有一个成熟的数据库,全栈的能力,才可以各方面都优化的很好,实现一个综合的效果。首先是成熟的分布式架构。向量还是一个偏 NoSQL 的场景,企业内部的数据可大,可小。所以我们利用原来多年积累的存储,数据库分布式经验,在系统的每一层都是可以扩展的:代理节点,这个是无状态对等的,同时支持自动的负载均衡。
管理节点,通过 raft 协议做高可用,负责集群的拓扑,资源管理等。
数据节点,复杂数据的增删改,查询和索引。支持自动的 failover 和弹性的伸缩能力。
成熟的分布式架构可以说是向量数据库的一切的基石,只有成熟的架构才能很好的支持高可靠,高可用,强扩展,大规模的能力。右边的图是 VectorDB 的数据引擎逻辑图。最核心的几个能力包括:- 支持强 schema 模型,同时支持标量和向量数据存储。
- 能够硬件上充分利用芯片的指令集,编译器的能力,获得很好的性能。
我们通过从底到上,从芯片到架构的深度的优化实现了一个高性能的数据引擎。在实践中,经常需要融合文本检索和向量检索的能力,向量解决近似查询,标量解决复杂条件过滤。检索预过滤。
检索时过滤。
检索后过滤。
按统计信息对索引进行不同的过滤机制。
前面讲的核心机制,现在看看 VectorDB 和开源的对比。我们在相同的召回率条件下,整个 QPS 或者吞吐超越开源 3~7.5 倍。关于这个测试报告,大家可以在我们的 VectorDB 产品官网帮助中找到测试的规格、数据、测试代码,整个测试是可以复现。最后来简单总结下 VectorDB 核心优势,包括:综合来说,百度智能云向量数据库 VectorDB 是一个成熟高效,综合能力领先的向量数据库。前面一起讨论了 RAG、向量数据库,接下来看数据库和大模型结合的另外一个方向 AI4DB,大模型赋能数据库运维应用,通过大模型改进数据库运维能力。我们的产品叫 DBSC,中文是数据库智能驾驶舱。先用一张图来看下我们的数据库智能驾驶舱的能力全景。整个服务包括数据库运维的方方面面,包括请求分析、智能运维、智能压测、数据库 devops 等。另外我们用大模型整体改造了产品的实现,让这些能力都能结合上大模型的能力,有更好的使用体验。大家可能会问,百度智能云这个产品和业界竞品的优势是什么。其实技术上不是这个产品的核心能力,这个产品和业界拉开差距的核心原因是要有积累大量的知识,其次才是将知识转化成产品能力。百度和百度智能云在过去的 18 年的数据库使用和开发经验,服务了大量的客户,沉淀了多年的经验。现在我们将这些能力和经验沉淀在 DBSC 这个服务里面,免费开放给内外部客户。这样 DBSC 就在支持内外部客户不停地开发、运维、和智能优化的过程中,又持续的将更多知识和能力沉淀下来,持续优化。这就形成了一个数据飞轮。用户越多,使用就越多,飞轮就会转的越来越快,服务的能力也就会进一步提升。智能领航员技术上简单说一下,就是用的 RAG 技术,embedding 模型用的文心千帆的 text 模型,向量数据库用的 VectorDB。用 VectorDB 存储积累的大量专业知识,所以用户使用下来,效果非常不错,根据我们的测试满意度 80% 以上。今天我分享的主要内容就是这些,最后我们简单畅享一下未来。大模型和数据库会持续结合,我们也看到了很多新的趋势,从底层的 IaaS,模型会从云端扩展到端;PaaS 会从现在纯文本模型扩展到多模态,上层应用会从当前主流的 Copilot 扩展到 Agent,更充分利用大模型的自主决策能力。谢谢大家!在人工智能的浪潮之下,AI Agent 正逐渐成为技术前沿探索与实践的焦点,不仅推动着各行各业的革新,也在企业生产、办公自动化、零售连锁等多个领域展现出巨大的潜力和价值。我们精选了2024年InfoQ技术大会上关于AI Agent的精彩演讲内容,带你了解华为、微软等大厂的探索方向和实践经验。关注「AI前线」,回复关键词「Agent」免费获取PPT资料。AICon 全球人工智能开发与应用大会,为资深工程师、产品经理、数据分析师等专业人群搭建深度交流平台。聚焦大模型训练与推理、AI Agent、RAG 技术、多模态等前沿议题,汇聚 AI 和大模型超全落地场景与最佳实践,期望帮助与会者在大模型时代把握先机,实现技术与业务的双重飞跃。
在主题演讲环节,我们已经邀请到了「蔚来创始人 李斌」,分享基于蔚来汽车 10 年来创新创业过程中的思考和实践,聚焦 SmartEV 和 AI 结合的关键问题和解决之道。大会火热报名中,7 月 31 日前可以享受 9 折优惠,单张门票节省 480 元(原价 4800 元),详情可联系票务经理 13269078023 咨询。