演讲实录 | 杨传辉：AI 时代，OceanBase 带来了哪些产品革新？

各位来宾、数据库领域的新老朋友，大家上午好。刚刚我们正式发布并开源了 OceanBase 首款 AI 原生混合搜索数据库 seekdb，也提到了混合搜索这一核心方向。今天我的分享，同样围绕 AI 展开，主题是 “打造 AI 时代的一体化数据库”。

相信不少嘉宾在展区已经感受到，这次发布会和以往有明显不同 —— 我们带来了大量 AI 相关的新产品。所以今天的分享，我不会聚焦 TP 或分析 AP，核心想和大家聊聊我们对 AI 时代、混合搜索与 seekdb 的思考，以及近期的开发进展。

AI时代一体化数据库的变与不变

首先，我们不妨回顾一下数据库技术范式的演进。数据库技术奠基人之一 E.F.Codd 于 1970 年提出关系模型，当时这一模型主要面向交易场景；1993 年，他又提出了面向分析的 OLAP。而最近几年，业界涌现的所有新数据库产品，本质上都是面向 AI 的 —— 既包括大家熟悉的各类向量数据库，也涵盖 Supabase等 热门产品。不难发现，整个数据库领域的技术范式，正从原本的支撑应用服务，逐步延伸到智能服务的全新阶段。

我们注意到，Oracle、MongoDB 等业界主流数据库，也正纷纷在自身引擎中新增搜索能力，以此适配 AI 原生场景的需求。在 AI 领域有个常见概念叫 AI Ready，而我们认为，AI Ready 必然会向 AI Native 逐步演进。所谓 AI Native，绝非仅做好数据准备那么简单，核心是将模型能力深度集成到数据库中，最终实现数据与模型在数据库内的原生融合。近期行业内的多起收购事件也印证了这一趋势 ——MongoDB 收购 Voyage AI、Elastic 收购 Jina AI，核心诉求都是推动数据与模型的融合，我们高度认同这一行业趋势。

AI 时代的到来，既给数据库领域带来了巨大挑战，更孕育着前所未有的发展机遇。

首先，AI 时代的数据库，数据处理量会持续激增，用户与租户规模也将迎来量级式增长。与此同时，AI 还会给数据库带来全新的工作负载 —— 我们将其定义为“面向 Agent 的多路混合搜索”。

在 AI 时代，数据库的处理范畴不再局限于结构化数据与少量半结构化数据，还需要承载更多半结构化乃至无结构化数据。这意味着，除了传统关系模型，数据库还需支持 JSON 处理半结构化数据，并为无结构化数据构建各类语义索引，比如大家熟知的向量索引、图索引、全文索引等。在此基础上，我们更需要一套能覆盖结构化、半结构化、无结构化数据的混合搜索能力。

AI 还带来了显著的技术平权效应。过去，数据库主要由专业人士通过开发应用程序来使用，而在今天的 AI 时代，即便没有计算机相关背景，普通人也能借助大模型轻松开发自己的 Agent。这也意味着，未来数据库的用户量与租户数量，必将实现倍数级的爆发式增长。

聊完了 AI 时代数据库的变化，我们更要明确数据库的变与不变。其中一点我坚信不疑：数据库领域不仅不会被取代，在 AI 时代还会变得愈发重要。

无论 AI 如何迭代演进，数据库的核心基础能力始终不可或缺：我们仍需要可靠的数据库引擎，解决单机、分布式及多云平台的各类问题；仍需要行存数据库支撑交易场景，列存数据库处理分析需求，更需要强大的 SQL 优化器应对 HTAP 混合负载。同时，数据库还需提供丰富的 SQL 功能，助力大家平滑完成从 MySQL、Oracle 等系统的升级。

混合搜索是 AI 数据库的关键分水岭

在 AI 时代，一体化架构所承载的核心技术能力，只会愈发重要。一提到 AI 数据库，很多人首先想到的是向量搜索，但在我看来，向量搜索只是 AI 数据库的初级阶段。最终，所有向量搜索都会逐步演进为混合搜索 —— 能否支持混合搜索，正是衡量 AI 数据库核心实力的关键分水岭。

大家都知道，大模型具备强大的计算能力，但缺乏长期记忆。这就需要数据库为大模型提供支撑：存储并管理其上下文信息，同时精准输出大模型所需的上下文。这个过程，也被称为 “上下文工程”。要做好“上下文工程”，首先需要通过向量搜索、向量嵌入解决 “找相似” 的问题。但 “找相似” 只是上下文工程的一部分，除此之外，还可能需要通过全文搜索实现 “找相同”，或借助知识图谱与图索引，挖掘全局相关的信息。

“上下文工程”往往还涉及大量元数据管理，这就需要依托关系型数据库的能力 —— 通过关系过滤、关系查找缩小检索范围。每一路检索都会产出部分结果，最终要将各路结果融合，并经过全局重排序(rerank)，才能为大模型输出其真正需要的精准结果。这正是混合检索的核心逻辑。

首先，高性能且功能完备的向量搜索，是多路混合搜索的核心基础。目前，OceanBase 向量搜索性能已达到业界开源向量数据库的最优水平 —— 无论是稠密向量还是稀疏向量，在向量数据库领域主流 benchmark 测试中均表现突出。同时，我们的磁盘向量索引，在构建时间与存储占用两方面，也实现了业界领先。

具备强大的向量搜索能力后，我们进一步实现了向量搜索与全文搜索的深度融合，通过多路搜索显著提升召回效果。

左侧图示清晰呈现了不同搜索方式的召回表现：仅采用单一搜索路径（无论全文搜索、稠密向量还是稀疏向量），都难以达到最优召回效果；唯有将稀疏向量、稠密向量与全文搜索相结合，才能实现更优的召回表现，达成 1+1 大于 2 的协同效应。

值得一提的是，OceanBase 不仅拥有上述高性能向量搜索能力，还已落地生产级全文搜索功能。更重要的是，这两大能力均构建于 OceanBase 数据库原生架构之上，天然继承了分布式架构的弹性扩展特性与对象存储的高效适配能力。

在 AI 场景中，除了要开展多路搜索，还需妥善管理 AI 场景下的元数据。要做好 AI 数据库的元数据管理，不仅需要支持元数据的实时写入与事务一致性，还需实现元数据检索结果与多路搜索结果的 SQL 级联动。毫无疑问，支持 HTAP 的关系型数据库是更优选择。通过将关系模型与向量、全文、JSON 能力深度融合，OceanBase 最终形成了全面的混合搜索能力。

下面我简单分享几个 OceanBase 混合检索的客户实践案例：

货拉拉基于 OceanBase 混合检索，搭建了一站式企业 AI 数据底座。货拉拉的 AI 应用场景十分丰富，涵盖知识库、AI Coding、Agent 平台、ChatBI 等。此前，他们曾使用多款不同产品，包括搜索产品 V search 及两款不同的向量数据库；升级至 OceanBase 后，实现了多产品合一，不仅解决了原有开源组件的稳定性问题，还直接复用 OceanBase 的高可用能力，达成 RPO=0、RTO＜8 秒的高标准。

联通也是借助 OceanBase 的混合搜索能力，构建了公司级统一知识库平台，该场景此前采用 “关系数据库 + 全文向量搜索数据库” 的架构。将两者融合至 OceanBase 后，在 10 亿级向量规模下，OceanBase 的处理效率达到原全文向量搜索数据库的两倍以上；同时通过融合关系查找与多路搜索，成功解决了知识库的元数据管理难题，包括精细化权限管控及灵活的用户间权限共享需求。

蚂蚁百宝箱基于混合搜索实现了智能体在线搜索。此前他们曾使用向量数据库、搜索产品及 OceanBase 本身分别管理不同数据，最终全部融合至一套 OceanBase 后，不仅帮助客户统一了技术栈，还将业务层的多产品融合搜索能力下沉至数据库层，极大简化了数据架构。

AI 时代需要怎样的数据架构？

实现 AI 场景下的混合搜索，主要有两种路径：

第一种实现方式是从头开始搭建一个混合搜索的数据库；第二种方式是直接基于关系数据库增加混合搜索的功能。

在我看来，第二种路径更具优势，核心原因有两点：1.关系型数据库不管是在功能完备性、易用性还是生态成熟度上，均远超其他非关系型数据库；2.支撑 AI 场景，除了要有混合搜索能力，底层还需一套现代数据架构。

以 OceanBase 为代表的关系型数据库，已具备成熟的现代数据架构 —— 这种架构技术壁垒高，也是 AI 时代数据库的 Foundation。

那么什么是现代数据架构？我认为核心包含三个点：

第一个点：现代数据架构一定是非常好用的；

第二个点：现代数据架构一定是非常灵活的；

第三个点：一定是面向未来能够支撑 AI 的。

现代数据架构的底层核心是一体化架构，用户想要什么功能，数据库就提供相应的功能，无需根据功能的不同而选择不同的存储产品、学习不同的技术栈。现在的数据库架构非常灵活，在部署模式上，用户可自由选择上云、不上云或特定云平台。

同时，现代数据架构也需要能够支持按需使用。数据量小时用小规格部署，数据量增长后无缝扩容，完美适配从初创到规模化的全阶段需求。

更关键的是，现代数据架构需原生支持 AI 场景。除了前文提到的混合搜索能力，原生多租户能力也至关重要 —— 因为 AI 时代，数据库的使用者早已不局限于 DBA 或计算机专业开发人员，每一个普通人都能通过大模型轻松构建自己的 AI Agent。

一体化架构的核心，我将其总结为 “三多”：多负载、多模态、混合多云。

• 多负载：一套数据库引擎即可全面支持交易、分析、AI 等各类工作负载；

• 多模态：兼容多样化数据类型与索引 —— 既涵盖结构化数据的关系模型、半结构化数据的 JSON 格式，也支持无结构化数据的各类语义索引，比如向量、全文、图索引等；

• 混合多云：赋予用户完全的部署自由，可自主选择上云、不上云或特定云平台。更关键的是，用户只需使用一套产品，就能实现跨所有公有云、混合云平台的自动升级，无需额外适配。

目前，OB Cloud 已成为业界支持公有云平台最多的云数据库产品，已兼容 7 朵主流云：国内涵盖阿里云、华为云、腾讯云、百度云四大平台，海外覆盖 AWS、Azure、GCP 三大平台。我们的 OB Cloud 已落地 16 个国家和地区，覆盖超 60 个地域、240 多个可用区，无论你身处全球哪个角落、哪个时区，都能便捷获取 OB Cloud 一体化云数据库。

同时，依托一体化架构，我们实现了多云及混合云环境下的用户体验一致性，更支持跨云高可用能力。当用户需要跨云升级时，OceanBase 可全程保障业务连续性，确保升级过程中业务不中断。

AI 场景的工作负载具有极强的不确定性。AI Agent 这个生态虽然数量众多，但多数都默默无闻，仅有少数会迎来爆发式流量，且这类流量往往具备突发特性。因此，我们必须提供支持弹性伸缩架构的 Serverless 方案，以灵活应对流量波动。

此外，AI 场景需要管理海量数据 —— 包含大量长上下文数据，既有文本类型，也有多模态类型。这些数据中，大部分属于冷数据，仅近期高频访问、用户重点关注的数据为热数据。基于此，我们通过支持对象存储的冷热分离方案，高效解决海量数据的存储与管理难题。

蚂蚁集团也正基于 OceanBase 开展大模型预训练工作。为做好大模型预训练，蚂蚁需要将海量网页内容提取至内部，再进行网页的数据清洗与标注。这些网页数据中，大部分属于冷数据，但仍有部分网页更新频繁，因此我们通过基于对象存储的冷热分离方案，高效适配这一需求；同时，数据清洗与标注场景的流量具有明显突发性 ，当一批网页数据集中涌入时，需要动态调度计算资源实现弹性处理，而在这一过程中，就需要用到  OceanBase 的 Serverless 方案。

数模融合，一个正在被验证的趋势

我认为，数据与模型的深度融合，必将是未来的核心趋势。在数据库内直接集成模型能力，能大幅降低模型开发与使用的复杂度。

以我们的混合搜索为例：当文档进入数据库内部后，除了进行数据处理外，也需要对文档做切片、解析、embedding，以及多路搜索。这一过程既用到数据处理能力，也集成了模型服务能力，包括 Parse 解析模型、embedding 模型、Rerank 模型等。

为此，OceanBase 支持了“Document in, Data out”，用户只需将文档写入数据库，通过混合搜索，就能一步获取所需结果，真正实现开箱即用。相比传统开发模式 —— 我们需自行寻找各类模型与组件，反复实验拼凑，有了“Document in, Data out”，用户真正能开箱即用，大幅降低了 AI 应用的开发复杂度。

当数据库集成了模型服务之后，OceanBase 也同时提供了 MaaS 平台。所谓的 MaaS 就是 Model As a Service，提供了后训练到在线推理服务的全流程管理。MaaS 平台支持微调等后训练，我们也支持对模型做量化，也支持做推理的加速、模型的评测，以及各种算力的调度、模型的管理等。如今，OceanBase 的 MaaS 平台已经支持了业界不同场景主流的大语言模型，包括海外和国产 GPU。

AI 原生数据库的设计，必然要秉持开源、开放的核心理念。刚才我们已经正式发布了 OceanBase 首款 AI 原生混合搜索数据库 seekdb——基于 Apache2.0 协议的 AI 原生混合数据库，主要有以下核心能力与优势如下：

首先，seekdb 支持多模混合搜索，仅需一条查询，就能同时检索关系、JSON、向量、全文等多种类型的数据；其次，它内置 AI Function 功能。因构筑于 OceanBase 原生架构之上，所以它也天然继承了  OceanBase 原生的能力，包括 HTAP混合负载处理、MySQL 高度兼容等能力。

可能有朋友会问，seekdb 是不是 OceanBase 的轻量版？答案是，两者并不同。它远比轻量版更轻, 轻上加轻。此前 OceanBase 轻量版最低配置为 2C 8G，而 seekdb 首个版本已支持 1C2G ，未来还会把它的内存需求进一步降低至 1G 甚至 500M。这意味着，seekdb 不仅能部署在台式机、桌面端，未来更可适配各类嵌入式环境。

seekdb 是基于 Apache 2.0 协议的开源产品，我们希望与业界开发者共同探索，到底什么才是真正的 AI 原生数据库。因为有了业界开发者的参与，我相信，seekdb 的迭代速度也必将大幅提升。同时， OceanBase在 AI 的能力上将会跟进 seekdb 能力演进，为大规模、超大型 AI 应用提供落地能力和支撑。欢迎大家访问 OceanBase seekdb 的官方网站—— oceanbase.ai，也诚挚邀请现场及线上的开发者们加入 OceanBase seekdb 的开源社区共建开放生态。

OceanBase seekdb 是一款专为开发者打造的 AI 原生数据库，只需三行代码，就能快速构建应用，实现关系、JSON、向量、全文的混合搜索。这里给大家举一个简单的例子：

第一步，创建一个集合；第二步，在集合中添加文档，并且可灵活指定文档的元数据；第三步，直接使用 OceanBase 的混合搜索接口，直接获取最终结果。

今天，我们也正式开源了 OceanBase 的 PowerRAG 产品。PowerRAG 被认为是 OceanBase 基于混合搜索的最佳实践。PowerRAG 在 RAGFlow 的框架之上构建，有两个特点。第一个特点，是基于混合搜索做的重新设计；第二个特点，该产品已在蚂蚁集团内部真实业务场景中落地应用，具备成熟的企业级能力。PowerRAG 文档解析、处理能力，以及最终召回的效果，是具备企业级能力的，要好于业界已有的 RAG 解决方案。

同时，今天我们也正式发布并且开源 PowerMem 解决方案， PowerMem 和 PowerRAG 一样，也是基于混合搜索的一个解决方案。它兼容 Mem0 接口，帮助开发者、用户去管理大语言模型的上下文。同时，PowerMem 的性能在 LOCOMO Berchmark 里达到了业界开源 Memory 解决方案的 SOTA 水平（State of the Art），欢迎在座的朋友以及线上的开发者关注和加入 OceanBase 的 PowerRAG 以及 PowerMem 开源社区。

今天是 seekdb 是发布的第一天，我们已经和业界产品进行了生态对接。这里面既包括全球知名的产品 Dify、Qoder，也包括 AI 领域的创业公司。当然，我相信这些创业公司在刚开始的时候就选择 OceanBase 这样一个能够解决增长问题的产品，他们未来的增长也一定会有更多的可能。

未来，我相信所有数据类的产品都会用 AI 的方式重新改造一遍。ODC 是 OceanBase 面向开发者的工具，ODC 正式推出 DataPilot。对于 ODC 而言，大家都非常熟悉它的自然语言转化为 SQL，Text2SQL 的功能。但是，如果采用业界经典的 Text2SQL 的解决方案，会面临一个很大的问题，那就是准确率永远都没有办法满足业务的需求。

Text2SQL 领域有个权威榜单 BIRD-bench，行业内普遍认为，该榜单得分达到 80 分左右后，再想突破就十分困难。而 OceanBase 创新性地采用了 Text2Metrics 解决方案：我们先定义统一指标，对领域术语进行标准化规范，再通过这些指标约束大语言模型的生成范围。通过这一方式，我们将自然语言到 SQL 的转化准确率提升至 90 分以上 —— 目前已达到 92.2%，且在特定业务场景下，准确率仍有进一步提升空间。要知道，只有达到 90 分以上乃至更高的准确率，自然语言转 SQL 技术才能真正落地生产系统，具备实实在在的业务价值。

我们还采用 Agentic AI 理念，对诊断监控产品 OAS 进行了全新设计。具体来说，我们采用 Agentic AI Multi-Agent 架构，它有一个主 Agent 负责核心的任务拆解与分配，再将不同细分任务精准下发给对应的专项 Agent 执行 —— 这个架构相信很多在场嘉宾都非常熟悉。通过这一升级，OAS 实现了从查指标、找问题到对话即诊断的跨越。用户只需通过自然对话，就能全程完成诊断流程，系统还会一步步呈现诊断过程中的详细信息。这既方便开发者人工介入干预，也让 OAS 真正具备了在生产系统中落地应用的实用价值。

今天我们也正式发布了 OceanBase AI Stack 智能一体机。OceanBase 智能一体机最核心的组件是 OceanBase 的一体化架构，支持多模混合搜索的数据库。数据库之上，我们集成了 PowerRAG、Agent 开发平台，以及 OceanBase 数据领域的 Agent —— 包括之前提到的 ODC DataPilot、基于 Agentic AI 改造的 OAS 等。数据库之下则搭载了 MaaS 平台，可灵活支持各类模型与算力部署。

OceanBase AI 智能一体机有两大特点：第一是功能全面覆盖，从底层的算力，海外或者国产算力支持，到模型、数据、RAG，到 Agent 开发，再到数据领域智能体，能完整覆盖企业从数据底座搭建到 AI 应用开发的全生命周期需求；第二个特点，就是超高性价比，它定价亲民，无需高昂成本，企业就能直接拥有 OceanBase 这套完善的端到端解决方案。

最后，我们还是回到 OceanBase 的内核，我们看看这一次 OceanBase 的内核，到底带来哪些全新的能力？

OceanBase 4.4 版本是面向混合负载的 TP/AP 融合及向量增强 LTS 版本，它融合了 OceanBase 4.2.5 LTS 的 OLTP 能力与 OceanBase 4.3.5 LTS 的 AP 及向量能力，能够同时兼顾核心系统以及多元化业务系统对数据库的需求。

在 OLTP 的性能方面，OceanBase4.4 版本相比 4.2.5 有了进一步的提升，有大量主键冲突的场景，性能提升 15% 到 42%，回表场景的性能提升 5.7% 到 9.5%，PL 性能提升会更加明显，对于 UDF 执行的性能是提升了 2.3 倍，循环计算的性能提供了 4 倍，动态语句的处理性能提升了 3.6 倍，AP 的性能也提到了进一步的提升。相比 4.3.5 LTS，它的数据导入性能在 ClickBench 这个场景提升 37%，实时分析性能对于 ClickBench 提升 4%，TPC-H 提升 10%，TPC-DS 提升 13.7%，向量索引的性能也是得到进一步的提升。

向量索引总共有两种索引方式，IVF 和 HNSW。IVF 的索引提升 15%，HNSW 的性能提升 4%-32%。同时在向量索引上，也针对 ARM 架构进行大量的优化，在 ARM 架构，性能有倍数的提升。

OceanBase 4.4 版本的内核能力也做进一步增强。它具备更强的安全能力以及 Oracle 的兼容能力。OceanBase 4.4 版本不仅支持全密态数据库，还支持联邦查询和数据湖的融合，能够帮助企业，尤其是金融与政企行业企业打通数据孤岛。

OceanBase 4.4 版本同时支持存算一体架构，以及公有云上的存储计算分离部署模式，适配多样化部署需求。更值得关注的是，该版本新增了一项核心能力 —— 实时增量物化视图。这一功能大幅强化了 OceanBase 的 HTAP 实力：让一套引擎既能稳定支撑 OLTP 核心交易处理，又能通过动态实时的增量物化视图，实现多维度的实时分析，实现真正的 HTAP。

结语

各位嘉宾、朋友，AI 时代的浪潮已然来临。无论你是企业管理者，还是深耕技术的同行，大家都在思考：如何真正把 AI 用好、用深、用在业务里。在这样的背景下，一个开放、灵活、具备多模与混合搜索能力的数据库，正成为企业迈向 AI 的关键基础。它能帮你高效管理企业数据，更能将数据能力与 AI 能力深度融入业务流程，让 Data 与 AI 真正落地生根，为业务创造实实在在的价值。

这就是我的分享，感谢大家一直以来对 OceanBase 持续的支持。谢谢！