基于大模型的 AI 技术已经成为行业共识，各个行业的企业都在知识库、AI Coding、智能客服、ChatBI、Agent 开发等场景落地大模型。然而，在真正进入企业业务后，会暴露两个问题：
缺乏企业的私有数据：基础大模型采用海量公网数据做预训练，虽然具备一定的“智能涌现”，但永远不可能理解企业的私有数据。这就像企业招聘了一位新员工，虽然经过了良好的教育，但还需要通过一段时间的新员工培训和动手实践才能真正胜任企业的日常工作。
缺乏记忆。大模型底层采用 transformer 架构，只能批量训练（预训练 / 后训练），无法根据用户的实时行为动态反馈。
因此，为了让 AI 在企业落地，需要依赖数据库实时存储企业私有数据和用户的实时行为，并通过智能搜索得到大模型需要的上下文，这个过程也被称作上下文工程。对于企业来讲，大模型基础能力是通用的，私有数据和用户行为才是核心资产，如何通过数据库把这些核心资产用好，决定了企业在 AI 时代的核心竞争力。
另外，AI 时代将会带来技术平权，原先只能通过专业人士开发的应用 /APP 来读写数据库，而在 AI 时代，每个不懂技术的非专业人士也能利用大模型技术通过多轮对话的方式构建自己的 AI Agent，这些海量的 AI Agent 底层都需要用到数据库，使得数据库的用户规模 / 租户规模会有数量级的提升。
基于这些变化，AI 场景正在驱动数据库出现一个全新的工作负载，我把它称为：面向 Agent 的多模混合搜索。首先，数据库不仅仅需要处理结构化数据（关系），也需要处理半结构化数据（JSON），以及无结构化数据，除了支持关系表的二级索引，也能支持全文索引，向量语义索引，图索引等，即具备多模能力。其次，数据库需要能够支持结构化、半结构化和无结构化数据的混合搜索。最后，数据库需要支持海量 Agent 同时使用，即具备海量多租户能力。
在 OceanBase 2025 发布会上，我们讨论过一个观点：AI 时代，数据库的变与不变。
数据库在 AI 时代虽然新增了“面向 Agent 的多模混合搜索”工作负载，但是，不管未来 AI 如何发展，数据库的核心需求是会一直存在的，需要通过行存来做交易，通过列存来做分析，并通过强大的 SQL 优化器来支持复杂查询和 HTAP。数据库需要确保数据不丢，确保稳定可靠，支持各种灵活的部署方式。
从实现路径来看，目前有两种思路实现 AI 数据库。第一种是从零开始构建一个“多模混合搜索”数据库，如向量数据库、全文搜索数据库；第二种是在成熟的关系数据库基础之上扩展多模混合搜索的功能，PostgreSQL，Oracle 和 OceanBase 都属于这一方向。关系数据库不管是在功能丰富度、易用性、开发者和 DBA 生态、成熟度和稳定性等方面都远远好于其它非关系数据库，且经过了大量企业的核心业务场景打磨验证，技术壁垒非常高。未来，两种方式会长期共存，第二种技术路线很大概率会占据主流。
提到 AI 原生搜索，很多人首先会想到向量搜索。向量搜索确实是当前主流的 AI 语义搜索方式，通过向量 embedding 可以搜索文本、图片甚至视频等多模态数据。然而，向量搜索只是 AI 数据库的初级阶段，随着 AI 应用的逐步深入，搜索需求必然会从“向量单一路径”走向“多模混合搜索”。
为了让大模型拿到更精准的上下文，需要用到向量搜索解决“找相似”的问题。然而，除了找相似之外，还需要通过全文搜索“找相同“，部分场景甚至需要通过基于知识图谱的图搜索在全局范围内“找相关”。AI 数据库不仅要管理多模数据，还需要管理这些多模数据对应的元数据，例如文档的权限，权重等等。因此，还需要通过关系模型管理这些元数据，提供实时写入和一致性事务。每一种搜索方式都可能找到部分结果，将这些结果融合之后通过多轮排序（粗排 =>精排）才能得到最后的结果。每一轮排序可能基于规则，也可能直接用模型。
因此，AI 时代的搜索不再是单一向量搜索，而是多种搜索方式、数据与模型（embedding/rerank 等）深度融合的整体过程。为了更准确描述这一能力，我们把它称为 AI 原生混合搜索（AI native search）。
从一体化架构开始，OceanBase 一直在思考现代数据架构。在我们看来，现代数据架构可以总结为三个特点：
易用：现代数据架构面向开发者做了专门设计，开发者想要什么能力，直接使用现代数据架构提供的功能或者服务，而不是根据不同的功能选择不同的产品，学习不同的技术栈。这个设计理念也是 OceanBase 一体化架构的初衷，通过在一套引擎中支持 OLTP、OLAP 和 AI 原生搜索来屏蔽底层数据库的技术细节。
灵活：现代数据架构必须支持按需使用，能够支持从“无限”小到“无限”大的工作负载。这是因为，AI 场景的工作负载具有不确定性，大部分 AI Agent 都是默默无闻的，少部分的 AI Agent 的流量很高，且流量具备突发性。为了支持“无限”小，需要能够支持 Serverless，为了支持“无限”大，需要底层能够支持原生分布式架构实现在线扩展。
面向未来：拥抱 AI，已经不再是前瞻性的选择，而是面向未来的必然起点。现代数据架构需要能够原生支持 AI 工作负载，既包括多模混合搜索，也包括海量多租户的能力。
OceanBase 的 AI 战略叫做“Data x AI”，而不是“Data+AI”。从技术发展趋势来看，数据与模型的深度融合正在成为必然方向。首先，多模混合搜索既要做多模数据的搜索，也要用模型做 embedding 和 rerank，这本身就是一种数据与模型的融合。
其次，业界开始出现一些流行的 AI 原生应用，比如飞书和钉钉的 AI 多维表格，可以直接在表格的每个数据单元执行 AI Function，包括大模型总结、翻译、打标签、等等，这是一种技术趋势。通过数据和模型的融合（简称“数模融合”），一方面能够大幅简化 AI 应用开发，另一方面也能创造一些 AI 特色的功能。举个例子，当我们想要给所有年龄在 30-35 岁之间所有关注下一代成长的妈妈发一封通过大语言模型自动生成的邮件时，只需要一条 SQL 语句加上 AI Function 就可以实现。
除了 AI Function，数据库也可以通过一些方式帮助大模型更好地理解数据。例如，Oracle 26ai 版本引入的 Annotations（注释）功能，通过轻量式声明，帮助大模型理解数据，这也是数据与模型逐步融合的一种体现。
可以预见，AI 数据库将从“AI Ready”逐步演进到“AI Native”。数据库既可以只做数据处理，把数据准备好，由应用从数据中搜索出精准的上下文作为提示词调用模型，也可以直接在数据库中调用模型，一条 SQL 语句既操作数据也调用模型，实现数据与模型的深度融合。
总体来看，AI 数据库有三个核心特点：
从“为应用服务”到“为智能服务”。既能处理传统的 OLTP、OLAP，也能够支持一种新的工作负载，既多模混合搜索。
面向 AI 场景的现代数据架构。通过 Serverless 和分布式架构，实现从“无限小”到“无限大”的完全弹性能力，支持海量多租户与灵活部署。
数据与模型的深度融合，逐步走向“AI native“，未来会有越来越多在数据库中直接融合模型能力的 AI 原生数据库。
基于这些思考，我们在 OceanBase 中逐步增加 AI 数据库能力，并基于 Apache 2.0 协议开源了 AI 原生数据库 seekdb。接下来的几个部分会深入探讨 AI 数据库的思考，包括：
<<从向量搜索到 AI 原生混合搜索>>：介绍 AI native search 背后的思考。
<<AI Ready的现代数据架构
<<从 AI Ready 到 AI Native>>：介绍数据和模型融合背后的思考。
<<为什么要做 AI 原生数据库 seekdb>>：介绍 OceanBase seekdb 的初心、定位、现有核心能力与不足。
数据库最早为应用服务，处理结构化数据，得到的是确定性的结果。而在 AI 场景下，数据库不仅为应用服务，更为智能服务，需要处理无结构化数据，通过规则和模型得到语义近似的结果，这个过程通常称为搜索。由于这个过程涉及到结构化数据（关系表）、半结构化数据（JSON）以及无结构化数据的各类索引（向量索引、全文索引、图索引），因此可以统称为多模混合搜索，或者 AI 原生混合搜索。
RAG 技术的出现主要是为了解决大模型的幻觉和知识陈旧问题。最早的 RAG 一般依赖向量搜索：应用层对文档等无结构化数据进行 embedding，接着在向量数据库执行向量近似查询（similarity search），并通过向量索引来实现查询加速。然而，为了提升搜索效果，仅仅向量搜索是不够的，还需要融入关系查询、JSON 查询、全文搜索，某些场景甚至还需要基于知识图谱的图搜索，以获取更全面和准确的上下文信息。
业界已有一些流行的向量数据库，比如 Milvus、Pinecone、Qdrant 等，这些产品在向量搜索方面表现优秀，部分产品也在逐步引入全文搜索等功能，但全文搜索能力距离实际业务的需求相比仍有差距。全文搜索数据库最典型的代表是 Elastic Search（简称 ES），ES 的全文搜索能力较强，但向量搜索能力还有待提升，且不支持关系数据库的多表 Join 操作。另外，不管是向量数据库还是 ES，往往缺乏数据库的综合能力，比如数据库安全及权限管理，SQL 优化器自动选择执行路径等。
相比单一路径的向量搜索，混合搜索能够大幅提高召回效果。实验和实践表明，如果只采用单一路径搜索——无论是全文、稀疏还是稠密向量，都难以达到最优结果；只有将全文、稀疏和稠密向量结合起来执行混合搜索，才能最大化召回效果。理论上，只要重排序（rerank）算法足够出色，搜索方式越多，效果越好。当然，实际生产系统中往往是搜索效果和执行效率的一个平衡。一般来讲，向量和全文的混合搜索就能达到不错的效果，少部分场景会引入知识图谱来获取全局信息。知识图谱的难点并不在算法本身，而在于很难自动构建一个准确率比较高的知识图谱，因此，往往应用在一些特定领域，比如用于表示医疗、法律等行业的特定术语和这些术语之间的关联关系。
多路搜索得到的数据最终需要融合在一起，进行重排序后才能返回客户。常见的重排序算法包括：
Reciprocal Rank Fusion(RRF)：RRF 为每路召回的结果列表中的每个文档都根据其排序位置分配一个分数，通常，得分是其排名的倒数。例如，排名第一的文档得分为 1，排名第二的得分为 0.5，排名第三的得分为 0.33，以此类推。那么最终文档的得分就是各路召回结果的累加。
加权权重融合：RRF 的鲁棒性较好，但它完全按照各路召回的排名进行打分，丢失了每一路召回结果的相似度和权重信息。加权权重融合算法简单地让用户配置每一路搜索召回结果的权重，并基于权重做加权平均。
基于模型的算法：BGE-reranker 是一种常见的排序模型，随着大模型技术的发展，我们发现 Qwen-rerank 等排序模型的效果经常更加出色。
业界的混合搜索系统，比如 Elastic Search，除了支持搜索功能，也能实现常见的关系过滤。那么，在关系数据库上构建混合搜索有什么优势呢？我们举一个简单的例子进行说明。
文档知识库是一个常见的 AI 应用场景，将文档写入到数据库后执行混合搜索，这就可能导致引用了用户无权访问的数据，这个问题也被称为隐式越权。为了避免这样的问题，需要给每个文档设置权限，比如只允许某些人，或者某些部门访问。
如果采用 ES 来实现文档搜索，由于 ES 的数据模型是大宽表，不支持多表做 Join，因此，只能对每个文档增加一列用来表示允许访问的用户以及部门列表。当允许访问的用户或者部门越来越多，或者需要经常修改时，无论是搜索性能还是更新效率都会大幅下降。
关系数据库支持完整的 SQL 功能，可以单独维护一张文档权限表，并在搜索时根据文档的编号对文档权限表与文档内容表做多表 Join 操作，实时性和灵活性大幅提升。一般来讲，企业刚开始构建文档知识库时往往只考虑搜索的效果，等到搜索效果满足业务需求之后会逐步引入文档权限，文档共享等多种丰富的功能，而这些功能正是关系数据库所擅长的。
另外，关系数据库具备很强的 SQL 优化执行能力，可以根据统计信息自动地选择最优的执行路径，例如，先做关系过滤还是向量搜索，还是边过滤边搜索，等等。除了关系数据之外，还会经常用到 JSON。这是因为，源端往往有多个不同的数据源，数据入库时经常映射到相同的一张表格，因此，将部分无法统一的字段用 JSON 来表示，并且通过在 JSON 上构建 Search Index，支持对于 JSON 字段的实时查询。
知识库天然需要用到混合搜索，业界有一个流行的开源框架 ragflow，为了更好地支持混合搜索，OceanBase 基于 ragflow 二次开发了企业级 RAG 解决方案 PowerRAG，已应用在蚂蚁集团并在 github 开源。
知识库 RAG 分为离线部分和在线部分：
离线部分从数据入库 =>文档解析切片 =>文档 / 切片入库。
在线部分从查询意图理解 =>混合搜索（多路搜索、粗排、精排）=>生成提示词调用 LLM。
可以看到，离线部分相当于是数据库的 ETL，在线部分主要是数据库的混合搜索。
大模型缺乏记忆，而记忆又可分为长记忆与短记忆。由于大模型的上下文窗口有限，一般会对长记忆做概要总结，把长记忆的概要数据和短记忆一起作为大模型的输入上下文。
业界已出现一些流行的大模型记忆解决方案，比如 Mem0，为了更好地支持混合搜索，OceanBase 在 github 开源了兼容 Mem0 接口的企业级 Mem 解决方案 PowerMem，在针对 Mem 场景的 LOCOMO benchmark 上达到了开源 Mem 解决方案的 SOTA 水准。
长记忆的数据量很大，需要低成本存储，短记忆和概要数据的数据量较小，需要保证搜索性能。为了从长短记忆中查找精确的上下文，需要关系 +JSON+ 向量 + 全文的混合搜索，底层需要基于对象存储 + 本地缓存的冷热分离解决方案。
AI Agent 往往需要同时查找关系、JSON、GIS、向量、全文，等。例如，在蚂蚁的百宝箱应用中，有一个常见的场景：
“推荐距离五百米以内，人均消费 25 元以下、评分 4.5 以上，多数人喜欢的咖啡厅”。
这个场景涉及到 GIS（五百米以内），也涉及到关系查找（人均消费 25 以下，评分 4.5 以上），还涉及到语义搜索（多数人喜欢）。传统的方案往往是采用多种不同的数据库，包括关系数据库、GIS 数据库、向量数据库，并在 AI Agent 应用层做拼装，有了混合搜索数据库之后，这些繁琐的业务逻辑都可以下沉到数据库。相比传统方案，混合搜索数据库有两个优势：一个是实现多合一，统一技术栈；另外一个是通过算子下压能够在数据库层面做优化，避免中间结果过大等一系列问题。
AI 原生混合搜索在一套引擎完成关系、JSON、向量、全文的混合搜索，部分场景通过图搜索进一步提升搜索效果。通过在关系数据库基础上构建混合搜索，能够复用关系数据库已有的实时写入、事务一致性和 HTAP 关系查询的能力，使得混合搜索不仅用于 AI 创新尝试，也用于尝试后的实际生产系统。OceanBase 混合搜索已经应用到知识库 RAG、大模型记忆、智能搜索等多种实际生产系统中的 AI 场景，实现了数据库多合一、统一技术栈、简化业务、提升召回效果等业务价值。
AI 时代带来技术平权，从数据库使用方式来看，主要带来两点变化：一是每个普通用户通过 AI Agent 使用数据库，带来海量多租户需求；二是新增了全新的多模混合搜索工作负载。同时，原先的 OLTP、OLAP 以及 HTAP 的需求仍然存在。
以蚂蚁集团在 2025 年 11 月 18 日推出的全模态通用 AI 助手“灵光”为例，灵光的右上角有一个用户喜欢的功能“闪应用”，使得每个即便不懂技术的普通用户都能够创建自己的 AI Agent，每个 AI Agent 相当于数据库的一个租户，每个租户可以拥有独立的表格、索引等 schema。对于 AI Agent 来说，通常大部分用户创建的 Agent 都是不太活跃的，只有少量用户创建的 Agent 流量很高。而且 Agent 的流量具有很强的突发性，某些默默无闻的应用可能因为某些事件短时间内成为热门应用。
现代数据架构是随着业务需求逐步发展起来的。数据库最早采用 IOE 集中式架构（IBM 大型机 / 小型机 +Oracle+EMC 存储），数字化进程到来之后集中式架构的并发能力不足，开始转向分布式架构。云计算通过集约化管理能够大幅提升效率，这就产生了云原生架构，且随着云计算的不断演进，很多企业发现某些云的成本很高且每年都会出现某个公有云整体故障的系统性风险，因此逐步走向云中立和混合云，产生了混合多云架构；AI 时代来临之后，由于 AI Agent 的使用方式和工作负载的特点，需要支持极致的弹性，从“无限小”的 Serverless 到“无限大”的全分布式架构。
在设计理念上，分布式与集中式最大的区别在于“Take failure as granted”，把故障当成是一种正常现象，并通过软件冗余的方式来实现自动容错、自动恢复。相比集中式架构，分布式架构带来如下几点好处：
自动容错：当服务器、机房、甚至城市发生故障时，能够自动恢复，完全不丢失数据。OceanBase 甚至做到了 RPO=0，RTO<8 秒。
自动扩缩容：系统处理能力不足时，可以通过在线增加服务器来自动提升系统的处理能力。业务高峰期过后，也可以在线删除服务器。原生分布式数据库能够做到自动扩缩容对业务无感。
低存储成本：早期的数据库采用 B+ 树存储引擎，而以分布式数据库为代表的新型数据库，往往采用 LSM-Tree 存储引擎。B+ 树比较适合数据量较小，更新比较频繁的数据，而 LSM-Tree 比较适合数据量较大的场景，而新型数据库在设计时往往假设数据量比较大。LSM-Tree 的存储成本远低于 B+ 树，OceanBase 在很多场景通过采用 LSM-Tree 替换传统数据库的 B+ 树将存储成本降低了 70%~90%。
分布式数据库引入了一个问题，那就是分布式架构本身带来的额外开销。分布式数据库为了保证高可用和分布式事务，往往会对数据进行分片 / 分区，每个分片 / 分区需要通过 Paxos 协议来实现自动容错，对于跨分片 / 分区的操作，即使在一台机器上，也需要通过两阶段提交协议（Two Phase Commit）来保证事务的一致性。这些开销在集中式数据库中是不存在的。为了解决这个问题，OceanBase 4.0 版本提出了一种全新的架构方案，叫做单机分布式一体化架构，使得分布式数据库在不涉及跨机事务时没有额外的分布式开销。
一体化架构的核心是：多负载、多模和混合多云，简称“三多”。
首先，一体化架构在一套引擎中同时支持 OLTP、OLAP 和 AI 混合负载。HTAP 数据库是一种现代数据架构，能够实现在线实时分析，有两种典型的实现方案：
多副本：OLTP 采用行存，OLAP 采用列存，行存和列存采用不同的副本，并通过 SQL 优化器来将用户的请求自动路由到不同的副本；
单副本：采用行列混合存储（类 PAX 方案）在一个副本上同时支持 OLTP 和 OLAP 两种工作负载。
这两种方案各有优势，第一种方案可以更好地支持 OLTP 和 OLAP 两种工作负载的隔离，适合 OLAP 工作负载较重的场景，第二种方案能够更好地保证在线分析的实时性，适合 OLAP 工作负载较轻的场景，比如简单的跑批或者简单的在线统计。OceanBase 同时支持了这两种模式，在 OceanBase 4.4 版本中还实现了一个增量实时物化视图功能。通过该功能，数据库会自动通过增量刷新的方式维护一个实时物化视图，从而支持在同一个副本中既做交易，也做在线分析，并将在线分析由原始表的批量扫描变成实时物化视图的点查。
其次，一体化架构在存储层支持多模，从而在一套系统中同时支持结构化、半结构化和无结构化数据。结构化数据的底层采用关系表，半结构化数据采用 JSON，无结构化数据一般会构建语义索引，包括向量索引、全文索引，等等。
最后，一体化架构支持多云和混合云，简称混合多云。为了支持多云，需要采用云中立的架构方案。对象存储是一种云中立的存储方案，所有的主流云平台都支持兼容 S3 接口的对象存储。多云架构强依赖 K8s 做调度，OceanBase 在做多云架构时发现不同云平台的 K8s 实现不完全相同，例如阿里云 K8s 支持固定 IP 且升级 K8S 时对业务无损，而 AWS 的 K8s 无法支持固定 IP 且升级对业务有损，因此，为了实现多云原生架构，OceanBase 只能自己实现云中立的 K8s 方案。多云原生架构还需要能够实现跨云容灾，比如主集群和备集群分别部署在不同的公有云，或者单个集群支持跨云部署和跨云容灾。
业界很多数据库开始支持对象存储。对象存储是每个公有云的标配，优势在于存储无限扩展且有极低的存储成本，劣势在于读写延迟较高。AI 时代的数据量变得越来越大，且大部分数据为冷数据，少部分数据为热数据，对象存储天然适应这种业务访问模式。为了减少对象存储的延迟，需要支持自动缓存热点数据，从而实现自动的冷热分离。LSM-Tree 存储引擎分为基线数据（基线 SSTable）、增量数据（增量 SSTable）以及重做日志（redo 日志），基线数据和增量数据通过 major compaction 和 minor compaction 操作批量写入，写入延迟不是核心问题，优化的关键在于读取延迟，因此，OceanBase 会在数据库服务器上缓存热点数据，当数据库故障或者需要弹性扩容的时候，也需要通过预热缓存来优化读取延迟。重做日志的写入延迟在事务的主路径上，为了优化该性能，OceanBase 抽象了独立的 log service 服务，log service 服务采用了高性能的本地盘 / 云盘，只需要将重做日志在 log service 写入成功即可，由 log service 在后台将重做日志批量同步到对象存储。
AI 场景的工作负载具有很强的不确定性，大部分 AI Agent 都是没有多少访问量的，这就要求 AI 数据库原生支持海量多租户和 Serverless。Serverless 架构有几个核心指标：当某个租户访问量为 0 时占用的最小资源，当没有访问的冷租户突然有流量时需要的加载时间，以及有突发流量时弹性扩容需要的时间。海量多租户带来的核心挑战包括两点：一个是不同租户之间的资源隔离问题，包括 CPU、内存、存储 IO、以及网络等，另外一个是海量多租户带来的海量表格 schema 管理的问题。OceanBase 广泛应用在 SaaS 行业，包括用友以及零售 SaaS 等，刚开始经常遇到表格太多导致资源消耗过大的问题，为了解决这个问题，我们成立了专门的 schema 优化项目组，对每个表格 schema 占用的内存和 schema 管理后台任务占用的 CPU 资源进行了大量的优化，最终将单个集群支持的表格数提升了一到两个数量级，满足了 SaaS 行业和 AI 场景的海量表格需求。
为了支持 AI 场景，需要与之匹配的 AI Ready 现代数据架构。AI Ready 数据架构是弹性的，支持从“无限小”的 Serverless 到“无限大”的全分布式架构；AI Ready 数据架构是易用的，通过统一的技术栈支持多种不同的工作负载，具有很好的实时性；AI Ready 数据架构是面向未来的，能够很好地支持 AI 场景需要的海量多租户和多模混合搜索，等等。
数据和模型之间的关系到底是什么？首先，AI 时代的数据库需要 AI Ready，即帮助 AI 把大模型需要的上下文准备好。然而，随着 AI 应用逐步深入，我们发现越来越多的 AI 原生应用需要同时操作数据和模型，数据库仅仅 AI Ready 是不够的，还需要进一步融合数据和模型的能力，成为 AI Native 数据库。
数据库和 AI 融合并不是一个全新的概念，学术界和工业界一直在探索。难点在于如何定义数据库和 AI 的边界，让数据库擅长的归数据库，让 AI 擅长的归 AI。过去，学术界曾经尝试用 AI 的方式来实现数据库的内核模块，比如用 AI 写优化器，但是在实际生产系统很难落地，根本原因在于 AI 在写优化器处理结构化数据这件事情上并不如专业的程序员。我认为，大模型在数据领域的优势主要有两点：一是具有很强的泛化能力，能够理解自然语言，简化数据库的使用界面；二是能够对非结构化数据进行语义处理。数据库和 AI 融合的关键在于如何将这两项能力融入到数据库中。
业界越来越多数据库产品开始将 AI 能力融入内核。Snowflake 是一个典型的代表，通过集成 Cortex 平台和 AISQL 操作符，可以直接将数据管理能力扩展到非结构化数据和 LLM 推理领域；微软也在最近（2025.11.19）宣布了一个新产品 Azure HorizonDB，其中一项重要改进就是内置了模型的能力，包括 Generate、Embedding、Rerank 等各类模型。
DataAgent 的一个核心目标是通过自然语言的交互方式直接操作数据库，这里面涉及到一项重要能力：Text2SQL/NL2SQL。Text2SQL 的难点在于准确率，业界有一些针对 Text2SQL 的 benchmark，包括 BIRD-bench，然而，不管是直接采用大模型，还是基于大模型做通用的 DataAgent，BIRD-bench 准确率达到 80% 左右就很难再往上提升，无法满足业务对 Text2SQL 的准确率要求。因此，需要提供一些方式让大模型能够理解行业或者业务本身的信息。有两种做法，一种是向内看，在数据库内核通过语义打标让大模型理解数据库的 schema，比如 Oracle 26ai 中的注释（Annotations）功能，又如 Snowflake 中的 Tags 功能；另外一种是向外看，在 DataAgent 中引入指标层，统一业务术语，通过指标约束生成范围，从而提高准确率。OceanBase 的 DataAgent 叫做 ODC DataPilot，通过引入指标层的 Text2Metrics 的做法，将准确率提升到 90% 以上。Text2Metrics 这种做法的好处在于可以通过专家介入的方式不断提升准确率，直到最终达到业务要求。
知识库 RAG 分为离线部分和在线部分。对于离线部分，外部的各种数据源的不同格式的数据往往会转化为中间格式（PDF/markdown），接着再对中间格式进行文档解析，包括内容理解、领域适配、结构化提取、多模态理解，等等，解析后的文档直接写入或者分片后再写入到数据库；对于在线部分，会对用户的提问进行检索预处理（意图理解、查询扩展、领域适配、跨语言翻译等）、检索、重排、检索后处理（结果裁剪与压缩、信息汇总），最后通过提示词工程调用 LLM。离线部分相当于是数据库的 ETL，主要涉及各种数据处理任务的调度和工作流，比较适合放到数据库的外部，文档或者分片入库以及入库之后的检索涉及的主要操作是标准化的多模混合搜索，比较适合集成到数据库内部。
飞书和钉钉新增了一项很受用户欢迎的功能，叫做多维表格。在多维表格中，每个单元格都可以调用 AI 功能：信息提取，从一段文本中提取关键信息，如从店铺名称中提取城市；数据生成，为每个店铺生成随机销售数据；格式转换，将杂乱的数据自动整理为标准格式；内容翻译，一键将单元格内容翻译成多种语言。这些操作不再需要复杂的公式或脚本，只需简单的自然语言指令即可完成。多维表格可以同时调用多个 AI 模型（DeepSeek、Qwen 等）为表格服务，每一列数据都可以使用不同的 AI 进行处理，支持展示 AI 的完整思维链与输出结果，以分列形式呈现。多维表格的底层可以采用 AI 原生数据库来实现，每个列都可以支持 AI Function 调用，并且还能使用数据库触发器等机制在每个列发生变化的时候自动调用 AI Function。
混合搜索的执行过程同时涉及数据处理和模型调用，执行过程中涉及的模型包括：
Embedding 模型：MongoDB 收购的 VoyageAI 号称能够做到 embedding 模型的 SOTA，可惜是闭源的，而开源模型比较推荐 qwen3-embedding，bge-m3，bge-large-zh-v1.5 等；
Rerank 模型：之前使用 bge-rerank 居多，随着大模型的发展，qwen3-rerank 的效果经常更好；
Generate 模型：国外的推荐 gpt 等模型，国内推荐 deepseek 和 qwen3 系列。
在数据库内部直接集成 embedding 模型有两个好处：一是不再需要从数据库拖数据出去调模型，简化业务实现；二是能够确保文档入库和用户查询使用的 embedding 模型总是保持一致，不会出现二者不一致导致的搜索效果下降问题。
“Document In,Data Out”能够大幅简化 AI 应用开发。原先开发一个 RAG 应用，需要选择多个不同的数据库（关系数据库、向量数据库、全文搜索数据库等），再根据不同的场景选择不同的模型，并在应用层对这些数据库和模型进行组装并调试效果。有了基于混合搜索的“Document In,Data Out”之后，只需要把文档或者切片写入 AI 原生数据库即可，AI 原生数据库会自动执行多路搜索并选择合适的模型。如果想要基于业务场景对模型做深度定制或者微调，也可以通过简单的数据库 DDL 操作来更换默认模型。
AI 原生数据库内置 AI Function，将这些 AI Function 融入到数据库的执行算子中。常见的 AI Function 包括：
混合搜索算子：包括 embedding 算子 ai_embed，rerank 算子 ai_rerank，LLM 生成算子 ai_complete 等；
文档处理算子（document ai）：包括文档解析算子 ai_parse_document，文档分类算子 ai_classify，文档提取算子 ai_extract 等，翻译算子 ai_translate，情绪分析算子 ai_sentiment，相似度分析算子 ai_similarity 等；
SQL 语义计算算子（AISQL）：包括语义过滤算子 ai_filter，语义连接算子 ai_join，语义聚合算子 ai_agg，文本摘要聚合算子 ai_summarize_agg 等。
通过 AI Function，开发者可以在一个 SQL 查询中完成以下任务：使用 ai_filter 过滤出客户表达不满意的工单记录，使用 ai_join 将这些工单与产品目录关联，使用 ai_classify 对问题严重性进行分类，并使用 ai_summarize_agg 按产品分类生成聚合摘要。AI Function 使得对结构化数据和无结构化数据的混合分析成为可能。另外，在这种模式下，数据库可以在底层系统对 AI 调用进行整体优化，减少大模型调用所需的 token。
AI 时代的数据库用户由原来的应用 /APP 变成大模型生成的 AI Agent。为了支持 AI 场景，首先需要一个现代化的 AI Ready 数据架构，这个架构能够支持 Serverless、弹性扩展等能力。AI Ready 只是 AI 数据库的起点，随着 AI 应用的逐步深入，会产生新的工作负载，即多模混合搜索。数据和模型也会深度融合，通过 AI Function 等技术在系统中直接处理无结构化数据，成为 AI 原生数据库。
2025 年 11 月 18 日，我们在 OceanBase 年度发布会正式发布并开源了 AI 原生数据库 seekdb(官网：https://www.oceanbase.ai/）。从官网可以看到，seekdb 在一个数据库中支持关系、JSON、向量和全文的混合搜索，支持 AI Function，继承了 OceanBase 原有的 MySQL 兼容性和 HTAP 能力，起步配置为 1C2G。
回到第一性原理，我认为，传统数据库主要用来处理结构化数据和半结构化数据，而 AI 数据库除了具备传统数据库的能力，还应该能够直接处理无结构化数据，而多模混合搜索是最终的方向。然而，现有的数据库产品都无法很好地支持关系、JSON、向量和全文的多模混合搜索，向量数据库做不好全文搜索，全文数据库做不好向量搜索，向量数据库和全文数据库都做不好关系查询，也不能很好地支持轻量部署，等等。
OceanBase 采用一体化架构，4.4 版本已经支持了 OLTP、OLAP 和向量搜索的能力，并计划在 4.5 版本中全面增强全文搜索、混合搜索和 JSON 的能力。既然这样，能否让 OceanBase 直接支持轻量部署，来满足开发者对于 AI 原生数据库的需求？很可惜，OceanBase 轻量版只能做到 2C8G 或者 2C6G，再往下则会遇到越来越多的工程化的挑战。而我始终坚信，AI 会改变整个软件行业，随着 AI 应用的逐步深入，每个开发者都会有自己的 AI 原生数据库，这个数据库既要有强大的多模混合搜索功能，也要像开源关系数据库（比如 MySQL/PostgreSQL）一样小，可以部署在笔记本甚至是嵌入式设备上。因此，我们决定抛开历史包袱，正式立项 AI 原生数据库。
首先，需要给我们的 AI 原生数据库一个正式的名字。我们内部做了很多次讨论，有各种提议但很难达成一致，既有直给型的，比如 searchdb，aidb，aisearch，也有隐喻型的，比如 venusdb,orca，等等。直到某一天研发负责人羡林突然提议 seekdb 并立即获得所有人的一致认同。seekdb 这个名字既是我们在 AI 原生数据库上的探索，也是向 DeepSeek 致敬；既有强大的能力，也有极低的使用门槛，并对全球开源开放。
seekdb 的定位是面向开发者的 AI 原生数据库，我们做的第一件事情是基于 OceanBase 的代码做轻量化改造，删除了部分不必要的代码，包括分布式和 Oracle 兼容功能。seekdb 只提供面向开发者的线下部署版本，如果想要在公有云上使用或者想要购买商业化版本，怎么办？我给的答案是直接使用 OceanBase。为此，我们做了一个设计约束：seekdb 的功能是 OceanBase 功能的子集。seekdb 面向开发者，与社区共建，且专注于开发者在 AI 场景的需求，因此，产品迭代速度会更快，而 OceanBase 会持续 follow seekdb 的功能并融入到 OceanBase。从使用者的角度看，基于 seekdb 开发的应用可以无需改造直接迁移到 OceanBase 商业版。
那么，seekdb 和 OceanBase 的定位有何不同呢？首先，不管是 seekdb 还是 OceanBase 都是一个能够支持 AI 场景的 AI 数据库，不同点在于，seekdb 只支持单机（含单机主备）且专注做好 AI 原生功能，即关系、JSON、向量和全文的多模混合搜索，而 OceanBase 具备完整的 OLTP、OLAP 和混合搜索能力，支持单机和分布式等全部部署模式。如果用在 AI 创新场景，数据量没有那么大，或者想要部署在端侧等资源受限场景，推荐 seekdb；如果想要完整的 OLTP、OLAP 和 AI 功能，或者想要商业服务，推荐 OceanBase。
自从有了 seekdb 的想法之后，我和很多 AI 应用的开发者做了沟通，大家对 seekdb 的定位还是非常认同的。很多开发者都在开发自己的知识库 RAG，我们之所以会提出 AI 原生混合搜索，正是看到了知识库 RAG 需要拼装各种不同的数据库且经常遇到文档的权限管理和共享问题。除了 RAG 以外，seekdb 也适合用在记忆管理和 AI Agent 开发。原先 AI Agent 开发需要多种不同的数据库并在应用层做拼装，有了 seekdb 之后，直接在数据库层面通过一条 SQL 执行混合搜索即可。
对于开发者而言，seekdb 最重要的价值有两个：一个是实现了多合一，简化应用开发，另外一个是相比原先的向量 / 全文数据库更加轻量。全文和向量数据库的最小规格需要 4GB 甚至 8GB 的内存，而 seekdb 的第一个版本在实现多合一的前提下只需要 2GB 内存，且后续还会进一步优化到 1GB 乃至 500MB。虽然部分向量数据库单独提供了轻量版，但功能往往较为简化，seekdb 在同等资源下支持的功能提供更强的能力，达到甚至超越业界已有的向量 / 全文数据库。
在 OceanBase 2025 年度发布会，我们展示了 oceanbase.ai 上的一个 demo，通过三行代码构建一个 AI 知识库。seekdb 在 SQL 的基础上封装了单独的 Python SDK，同时支持了嵌入式的部署模式。在 AI 的世界里，Python，Javascript 等才是开发者更加喜欢的语言。当然，要构建一个真实的 AI 应用，三行代码肯定是远远不够的，但我们相信，一个更好的支持多模混合搜索的 SDK 一定能够简化 AI 开发。
