Oracle Database 23ai：当数据库本身成为 AI 引擎
图：Oracle Database 23ai——AI 能力与数据库内核的深度融合
摘要：2024 年，Oracle 正式发布 Database 23ai，将版本号中的"c"换成了"ai"，这不是一次简单的命名游戏，而是宣告了一个新时代的到来：AI 不再是外挂于数据库之上的工具，而是数据库本身的一部分。本文深入解析 23ai 的核心 AI 特性、架构原理与企业落地价值。
一、起：一个字母的革命
2024 年，当 Oracle 把新版本命名为"Database 23ai"时，很多人以为这不过是一次营销噱头。
但当你真正翻开 23ai 的特性列表，会发现那个小写的ai背后承载的分量：超过 300 项新特性，其中近一半与人工智能直接相关。向量数据类型原生内置、SELECT AI自然语言查询、AI 微服务框架、属性聚簇表……Oracle 用一个版本号的更迭，完成了数据库行业数年的 AI 转型路线图。
这不是在数据库旁边搭一个 AI 帽子，而是让数据库从骨子里长出 AI 能力。
对于 DBA 和架构师而言，23ai 意味着游戏规则的彻底改变——你不再需要把数据导出到 Python 脚本或外部向量库才能做 AI，数据在哪，智能就在哪。
二、承：23ai 的四大 AI 核心能力
2.1 AI Vector Search：让相似性搜索成为数据库原语
23ai 最具标志性的特性是原生支持向量数据类型（VECTOR）和向量索引（HNSW / IVF Flat）。
-- 创建带向量列的表 CREATE TABLE products ( id NUMBER PRIMARY KEY, name VARCHAR2(200), embedding VECTOR(1536, FLOAT32) -- 1536维向量，对应 text-embedding-3-small ); -- 创建 HNSW 向量索引 CREATE VECTOR INDEX products_vec_idx ON products(embedding) ORGANIZATION INMEMORY NEIGHBOR GRAPH DISTANCE COSINE WITH TARGET ACCURACY 95; -- 向量相似性搜索 SELECT name FROM products ORDER BY VECTOR_DISTANCE(embedding, :query_vec, COSINE) FETCH FIRST 10 ROWS ONLY;这意味着什么？过去构建 AI 应用需要维护两套系统：关系型数据库存业务数据，向量数据库（Pinecone、Milvus、Weaviate）存 Embedding。23ai 将两者合二为一，彻底消除了数据同步、一致性维护和双套运维的复杂度。
图：Oracle AI Vector Search——在数据库原生空间中进行语义相似性检索
2.2 SELECT AI：用自然语言直接查数据库
23ai 引入了DBMS_CLOUD_AI包，允许开发者配置 LLM 提供商（OpenAI、Cohere、Azure OpenAI 等），然后用自然语言直接查询数据库：
-- 配置 AI Profile BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'OPENAI_PROFILE', attributes => '{"provider":"openai","credential_name":"OPENAI_KEY", "object_list":[{"owner":"SALES","name":"ORDERS"}, {"owner":"SALES","name":"CUSTOMERS"}]}' ); END; -- 用自然语言查询！ SELECT DBMS_CLOUD_AI.GENERATE( prompt => '查询上个季度每个地区销售额最高的前三名客户', profile_name => 'OPENAI_PROFILE', action => 'narrate' ) FROM DUAL;LLM 理解业务语义，自动生成 SQL，数据库执行并返回结果，整个链路无需开发者手写一行 SQL。这对于 BI 自助分析场景具有颠覆性意义。
2.3 原生 RAG 支持：企业知识库的终极形态
RAG（检索增强生成）是当前企业 AI 落地最主流的模式，23ai 将 RAG 所需的全部能力内置其中：
- 文档自动分块（Chunking）：
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS支持按句子、段落、固定长度等多种策略切分文档 - 批量向量化：
DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDINGS调用外部或本地 Embedding 模型批量生成向量 - 混合检索：向量语义检索 + 全文关键词检索 + 结构化过滤，三路融合提升召回质量
- 端到端管道：一条 PL/SQL 调用完成"文档入库→向量化→检索→LLM生成"全流程
图：基于 Oracle 23ai 构建企业 RAG 知识库——文档、向量、业务数据在同一个数据库中协同
2.4 JSON Relational Duality：AI 应用开发的弹性基座
23ai 的JSON 关系二元视图（JSON Relational Duality Views）允许开发者同时以 JSON 文档和关系表的视角操作同一份数据，无需数据复制。AI 应用通常需要灵活的 Schema（适合 JSON），同时业务报表又需要强关系型查询——23ai 让两者完美共存。
三、转：23ai 的真正价值不在技术，在架构简化
每次新版本发布，技术特性都令人眼花缭乱，但企业真正该关心的问题只有一个：这能帮我省多少钱、少踩多少坑？
以构建一个企业级 RAG 知识库系统为例，对比两种方案：
| 维度 | 传统多组件方案 | Oracle 23ai 方案 |
|---|---|---|
| 存储层 | PostgreSQL + Pinecone/Milvus | Oracle 23ai（一个数据库） |
| 数据同步 | ETL 管道 + CDC | 无需同步，原生统一存储 |
| 事务一致性 | 跨系统最终一致性，复杂 | ACID 事务天然保障 |
| 运维成本 | 多套系统独立监控/备份 | 统一 DBA 运维体系 |
| 安全审计 | 多套权限体系难统一 | Oracle 统一安全框架 |
| 开发复杂度 | 多 SDK，多连接池 | 单一数据库连接 |
架构简化本身就是最大的 ROI。减少一个系统组件，意味着减少一套故障点、一套运维流程、一批学习成本。
当然，23ai 也不是没有局限。对于超大规模向量检索（十亿级以上）、需要极致低延迟的在线场景，专业向量数据库仍有其优势。Oracle 23ai 的定位是：已有 Oracle 数据库投入的企业，AI 能力的最低阻力路径。
四、合：数据库即 AI 平台的时代已经到来
回顾数据库的发展历程：从最初的文件系统，到关系型数据库统一天下，再到 NoSQL 的百花齐放，每一次范式转移背后都是应用需求的根本性变化。
AI 原生时代，数据库的核心竞争力将不再只是存储和查询，而是能否成为 AI 应用的智能底座。
Oracle 23ai 给出了自己的答案：把向量、语义、LLM 调用、文档处理全部内置到数据库内核，让 AI 能力随着数据一起，受到事务、安全、高可用的全套保护。
对于企业架构师而言，现在是时候重新审视那个经典问题："我们应该把 AI 加到应用层，还是下沉到数据层？"
Oracle 23ai 的出现，让"数据层即 AI 层"从设想变成了现实。目前是26ai版本，可以提供本地下载
图：Oracle 23ai 驱动的企业 AI 应用——开发者用自然语言查询数据库，AI 与业务数据无缝融合