OceanBase CTO 杨传辉在 2026 世界人工智能大会「贵州·AI 驱动东西部协同发展论坛」发表主题演讲
OceanBase 始创于 2010 年，至今已经有 16 年的历程。我们在交易和分析两个领域，分别打破了 TPC-C 和 TPC-H 测试世界纪录，是全球唯一同时打破这两项世界纪录的数据库；在墨天轮国内数据库流行度排行中，OceanBase 连续三年每月位居第一，是中国流行度最高的数据库产品。
OceanBase 有一个突出的特点：所有代码完全自主研发，不依赖任何开源系统。今天，OceanBase 已服务超过 4000+ 家客户，其中 60% 以上的客户将 OceanBase 作为核心系统，支撑企业的关键业务负载。面向金融、能源、政务、交通等国计民生重点领域，OceanBase 为数字基础设施的稳定运行提供坚实保障，助力千行百业数智化转型行稳致远。
OceanBase 原来做的是分布式数据库，今天我们提出了一个新的定位——AI 数据库。为什么要提 AI 数据库？因为我们在服务企业的过程中发现，企业在 AI 场景下确实有很多新的需求，这些新需求需要新一代的数据基础设施来承接。
传统 IT 时代，企业需要的是集中式数据库；到了互联网、移动互联网时代，数据量急剧变大，企业需要的是分布式数据库；到了 AI 时代，企业需要的是 AI 数据库。这不是修修补补的改良，而是一次系统性的重构。
通过与大量企业的交流，我们发现，AI 时代的数据管理正在发生三个根本性变化：
-
使用者变了——从人变成了 Agent；
-
数据形态变了——从结构化变成了结构化与多模态融合；
-
交互方式变了——从 SQL 变成了自然语言。
传统数据库里存的是字段、是行和列，但大模型要的是上下文、是语义、是能够直接被消费的信息。如果数据库还停在原地，再好的模型、再强的算力，也难以在企业真实场景中发挥价值。
具体到数据库设计上，最直接的变化有两点。
第一，原来的数据库是为人设计的——人写 SQL、人看报表、人做决策；今天到了 AI 时代，数据库需要为 Agent 设计，也就是为智能体设计。
第二，原来的数据库主要管理结构化数据，所有数据都是由人先做好结构化再录入；今天到了 AI 时代，除了结构化数据，还必须直接管理多模态数据，让结构化数据与多模态数据实现融合，并且让数据能够被 AI 所理解、在系统之间自由流通。这是最大的变化。
基于这样的判断，OceanBase 给出的解决方案，一句话概括就是“多模离在线一体化数据底座”。
它有四个核心设计理念。
第一，多模。把结构化和非结构化数据统一放到一起，并且像数据库一样保持一致性。
第二，离在线一体。原先的系统里，数据库主要用来做在线业务，数仓和大数据平台用来做离线业务；到了 AI 时代，Agent 是不分在线离线的。以前企业领导看报表可能一天看一次，因为他只有晚上不开会的时候才有空；到了 Agent 时代，Agent 什么时候都在处理数据，需要非常实时地处理所有的多模态数据。所以在线和离线必须做成一体。
第三，Agent 友好。Agent 使用数据库的方式和人不一样，数据库要为 Agent 而设计。
第四，开放。Agent 处理的数据既有结构化的、也有非结构化的；对于非结构化数据，处理方式一定不是封闭式的，而是要有各种 AI 能力的参与。因此，数据库必须采用一种开放的架构。
围绕上面四个理念，OceanBase AI 数据库在具体设计上呈现出五个关键变化。
变化一：从本地存储到对象存储
数据库以前是基于封闭式的假设——最早的数据库是单体式、存储计算一体的设计。之所以这样设计，是为了把延迟做得比较低、把性能做得比较好。
但是到了 AI 时代，我们要处理的是一个开放的环境，设计假设发生了变化。OceanBase 的做法是采用存算分离的方案：把结构化、半结构化、非结构化以及向量、多模态数据，统一存放到对象存储之上；上层计算层弹性扩展，下层对象存储保证统一、低成本、高可靠。存储和计算不再绑死，也就为多种负载共享同一份数据打下了基础。
变化二：从关系表到多模表
关系型数据库的底层有一个基础的数据结构叫表，主要管理结构化数据——所有数据都是由人做好结构化以后再存储到数据库。
到了 AI 时代，除了管理结构化数据，我们还需要在数据库里直接管理非结构化数据。我们认为，AI 数据库与原先数据库最大的区别，就是把非结构化数据作为数据库的一等数据资产。
具体的做法是：在同一张表里，除了传统的关系列，还引入了多模列和 AI 列。图片、音视频、PDF、网页快照、向量、JSON 等多模态数据，可以作为字段直接入表；Embedding、摘要、标签等模型生成结果，可以作为 AI 列沉淀在表中，支持异步生成、失败重试和一致性保障。用户看到的仍然是一张表，同一事务、同一权限、同一版本、同一生命周期。
正因为如此，当一张表里的很多行都是多模态数据、需要做 AI 计算的时候，我们能够确保这些 AI 计算采用相同的算法，要么都成功、要么都失败——多模态数据也需要一致性。这是 AI 数据库和过去数据库一个非常本质的区别。
变化三：从关系查找到混合搜索
原来的数据库大家比较熟悉，一般用来处理交易、处理分析，主要是关系查找。到了 AI 时代，我们的第一个判断是：混合搜索会成为一类和事务、分析同等重要的工作负载。为此，OceanBase 也在和国家部委一起推进相关标准的制定。
具体的做法是：在一张多模表之上，同时完成关系查找、全文搜索、向量搜索、图搜索和 AI 计算。
很多人比较熟悉向量数据库——向量搜索确实是多模态数据里最主流的搜索方式，但它并不代表全部。
向量搜索解决“找相似”的问题，全文搜索解决“找相同”的问题，图搜索解决“找相关”的问题。只有把关系查找与向量、全文、图搜索融合起来，形成融合搜索，才能真正提升混合搜索的准确率，让 AI 做“准”，而不仅仅是做了这件事。
这套融合搜索还有一个直接的好处：数据库先在库内完成粗排、缩小候选集，模型只需要处理高价值候选，Token 用得更省、结果更可控。
变化四：从人类友好到 Agent 友好
Agent 使用数据库的方式和人不一样。我们观察到两个非常突出的特点。
第一，Agent 一定会犯错误。所以数据库需要支持快速试错的能力——错了能很快回滚回来。为此我们引入了 Fork Database 的能力：每个 Agent 都可以从基线库秒级创建一个独立的数据沙箱，读写隔离、失败可回滚，试错用完即弃。
第二，未来一个人可能同时驱动几十个、上百个 Agent，海量 Agent 并发访问会带来“连接爆炸”的问题。为此，OceanBase 引入了逻辑表：每个 Agent 拥有独立的数据边界，共享底层资源池，逻辑隔离、冷热分离、按需唤醒，闲时资源可以归零。单个 Agent 安全试错，海量 Agent 低成本并行运行——这些能力都需要在数据库设计之初就预置进去。
变化五：从 SQL 计算到开放计算
原来数据库里的 SQL 计算主要做交易、做分析、做搜索，本质上还是一种在线服务。
到了 AI 场景，在线和离线融合在一起。除了在线服务，数据库还要能承接离线的一体化处理，包括离线的 AI 计算——比如非结构化数据的清洗、切分、Embedding、转写和理解，都是典型的离线 AI 加工链路。
在线和离线怎么共享数据？不需要把数据从一个系统搬到另一个系统。通过存算分离，在底层通过多模表、通过对象存储直接实现数据共享，避免数据搬迁。在这一层，OceanBase 兼容 Spark ETL、Daft on Ray 等主流 AI 加工链路，把整个开放生态“接”到统一的数据底座上。
有了这些能力之后，我们还需要一层语义网络。
数据库里只有表格、只有列，AI 虽然能看到数据，但不知道数据的含义，是用不起来的。所以要在数据库之上构建一层语义网络。
语义网络本身有一个国际标准，叫 OSI（Ontology Semantic Interoperability）。OceanBase 也实现了这一能力，叫 OceanBase OSI，它的底层是 Ant-OSI，也就是蚂蚁集团在语义网络领域对 OSI 的实现，已经在蚂蚁内部经过大量场景验证。
基于 Ant-OSI，我们进一步具备自动构建上下文图谱、自动构建业务语义层的能力，最终形成一个业务语义平台，让 Agent 真正能“认识”数据、直接把数据用起来。
这也解释了一个业界经常讨论的问题：为什么同样一个大模型，接到不同企业的数据库上，问数准确率差异会那么大？根本差异不在模型本身，而在于数据之上有没有一层高质量的语义上下文。
把这些能力合在一起，就是 OceanBase 湖库一体的 AI 数据库。
最底层是湖库引擎，采用存算分离的架构，用一张多模表统一管理结构化与非结构化数据，通过开放计算完成在线和离线的处理；中间是语义层，也就是上下文层，承载 Ant-OSI 的开放语义、上下文图谱和 Memory、RAG 等 Agent 上下文能力；最上层，是各种各样的 AI 应用与 Agent。
对企业来说，这意味着一件事：不必在多个系统之间搬运数据，事务处理、实时分析和 AI 能力直接生长在同一份数据之上。
相较传统多系统方案，OceanBase AI 数据库可以将整体 TCO 降低约 30%–50%。
从应用场景来看，OceanBase 原先作为分布式数据库，主要处理交易需求，也就是核心业务场景：包括分布式核心系统升级、集中式系统向分布式升级、替换 Oracle，以及实时分析。
到了 AI 时代，具体到行业：
-
比如金融行业要做实时风控，金融场景中有大量的交易行为数据以及非结构化数据，需要多模态的处理能力；
-
比如智能驾驶和交通行业，有大量的行驶数据、轨迹数据，这些也是多模态数据，需要 AI 数据库来处理；
-
再比如智能制造，像新能源汽车，制造过程中会有很多设备和生产信息，如果出现了错误怎么办？就需要用 AI 的方式，智能化地把错误直接定位出来——比如引擎出了问题，系统直接就能发现。
在“东模西数”的框架下，模型和算力是两条大家谈得比较多的主线，但两者之间还有一个容易被忽视的关键环节——数据。
没有统一、高效、智能的数据基础设施，模型无法获取可信的上下文，东西部协同就缺少了“最后一公里”的支撑。OceanBase 在西部的实践，恰恰是围绕这“最后一公里”展开的。
案例一：西部某“老字号”银行，一体化数据底座沉淀
第一个案例，是西部一家拥有百年历史的“老字号”银行。
此前，该行拥有近 30 款数据库系统，不同业务负载分散在不同集群里，运维和成本压力都非常大。基于 OceanBase 一体化数据底座，该行将交易、实时分析、实时数仓等负载统一整合，无需再为每个业务负载单独建设分布式集群。
目前，约 50% 的系统已经运行在 OceanBase 之上，大幅节约了投资成本；按照规划，到 2027 年这一比例将升至全行系统的 85%。面向 AI 时代，该行正在推进大模型与知识库建设，向量、文档等多模能力也将沉淀到同一个底座上，让数据真正成为 AI 的“燃料库”。
用杨传辉的话说：“过去数据是孤岛，要等它‘翻山越岭’去往不同的系统；现在数据成为智能底座，所有能力都可以在上面自然生长。”
案例二：西部某大型航司，智能问数跨越准确率瓶颈
第二个案例，来自西部一家大型航司。它的难点，在于让数据“被信任”。
这家航司的智能问数服务，曾长期卡在“准确率瓶颈”上——答不准，业务就不敢用，更谈不上辅助决策，数据价值无从释放。
基于 OceanBase，这家航司重构了智能问数场景：底层用湖库一体的 AI 数据库统一管理票务、运力、轨迹与多模态数据；数据之上叠加一层高质量的语义网络，把业务口径、指标定义、计算逻辑统一沉淀下来。
最终的效果是，业务人员用自然语言提问即可秒级取数，问数准确率显著提升，实时洞察进入经营一线，直接辅助核心决策。数据，也从“不敢信”的资产变成核心决策的信任底座。
这两个案例，一个是把“孤岛”沉淀为“底座”，一个是把“数据”升级为“决策”。它们背后共同回答了一个问题：在“东模西数”的协同新范式下，AI 时代的数据底座，到底应该长成什么样。
大模型学了全人类的知识，但可能读不懂你公司的一张表。这也是我们坚持要做 AI 数据库的原因。
目前，这套湖库一体的 AI 数据库已经在蚂蚁阿福、灵光等场景完成了大规模验证，并正在加速走向企业级市场。从承载千行百业的核心系统升级，到面向 AI 时代的数据智能引擎，OceanBase 正在从“存放数据”升级为“驱动智能”。
“大模型是引擎，数据是燃料，数据库是底盘。底盘不稳，引擎再强也跑不起来。我们有信心，在 AI 时代再造一个 OceanBase。”
OceanBase AI 数据库，连接模型、算力与数据，助力“东模西数”落地。
立即试用 OceanBase 企业版，体验国产数据库能力立即试用 OceanBase 企业版，体验国产数据库能力