software

Oracle AI Database 26ai 在生产环境中

发布: (2025年12月23日 GMT+8 12:12)
14 分钟阅读
原文: Dev.to

Source: Dev.to

Oracle AI Database 26ai 通过将 AI 能力直接嵌入数据库引擎，改变了将数据迁移到外部 AI 系统的传统模式。向量搜索、语义相似度和 AI‑ready 检索现在可以与 SQL、事务和安全控制并行运行，使工程师能够在无需新数据管道或外部向量数据库的情况下构建 AI 驱动的应用。

本文从技术角度解释了 Oracle AI Database 26ai 的工作原理，以及它如何用于构建真实的生产级 AI 系统。

什么是 Oracle AI Database 26ai？

Oracle AI Database 26ai 是 Oracle 最新的长期支持版旗舰数据库，专为需要 AI 能力的数据平台的企业而设计。它取代了之前的 Oracle Database 23ai 版本，且 23ai 的所有功能都已包含在 26ai 中。

核心理念是 将 AI 架构到数据管理的基础层，实现智能处理、分析和应用支持，而无需将数据导出到外部系统。

关键亮点

  • AI 深度集成于数据引擎
  • 原生向量支持与相似性搜索
  • 对关系型、文档、JSON、图、空间等多种数据类型的统一支持
  • 开发者生产力特性，如 AI 辅助代码生成
  • 企业级性能、治理和安全性
  • 分布式和多云部署选项

为什么在数据库中使用 AI？

传统的 AI 架构通常依赖多层系统，数据需要从数据库迁移到特征存储、向量层或外部服务。这种迁移会带来复杂性、延迟和安全挑战。

Oracle 的方法有所不同：

数据库本身成为一个统一的平台，用于数据存储、向量计算、智能和 AI 驱动的工作流。

好处

  • 性能： 分析和 AI 在数据所在的位置运行，减少往返成本。
  • 安全性： 数据治理和访问控制在数据库层面强制执行。
  • 简洁性： 需要管理的系统和管道更少。
  • 可扩展性： 企业工作负载可以随分布式数据库特性进行扩展。

关键技术创新

本地向量搜索和多模态支持

Oracle AI Database 26ai 包含对向量数据类型的内置支持，使得在 SQL 查询中直接进行语义和相似度搜索成为可能。您可以对从文本、图像或其他媒体生成的向量进行索引和搜索，而无需外部系统。

使用场景

  • 企业知识库的语义搜索
  • 关系型 + 向量混合查询
  • 业务逻辑与最近邻搜索相结合

智能代理工作流

Oracle AI Database 26ai 引入了对 数据库内 AI 代理 的支持——这些框架可以代表应用执行自主或半自主任务。这些代理能够在不离开数据平台的情况下，结合数据访问、分析、决策逻辑和行动。

通过将代理纳入数据库生态系统，Oracle 简化了原本需要外部编排层的复杂 AI 工作流。

统一湖仓与数据织网

26ai 战略的核心组成部分是 Oracle Autonomous AI Lakehouse，它支持 Apache Iceberg 等开放数据格式。这将分析、数据治理和 AI 融合在可能位于数据湖的大规模数据集之上。

湖仓能力模糊了传统的 OLTP、OLAP 与 AI 工作负载之间的界限，实现了：

  • 统一治理
  • 实时分析
  • 模式灵活性
  • 大数据集的高效存储

开发者生产力与应用开发

Oracle AI Database 26ai 也致力于让 AI 开发更简便：

  • 集成的 AI 增强代码生成支持

  • 带有 AI 助手的 APEX 增强功能

  • JavaScript 存储过程及现代语言支持

  • 针对 AI 逻辑的 SQL 与 PL/SQL 增强

  • 参考资料： Oracle Blog – AI Database 26ai

开发者可以使用熟悉的数据库工具和语言构建智能应用。

企业级就绪度

Oracle 将 26ai 定位为关键任务工作负载的解决方案：

  • 在主要云平台上可用（OCI、AWS、Azure、GCP）
  • 支持本地部署，未来将推出 Linux x86‑64 版本
  • 基于 Raft 的复制实现分布式数据库能力
  • 集成的安全、审计和治理功能
  • 免费和开发者版可用于实验核心特性

这些能力使 26ai 适用于需要 AI 能力与运营可靠性的大型企业。

对从业者的意义

对于工程师和架构师而言，Oracle AI Database 26ai 代表了一个 单一、统一的平台，在该平台上数据存储、向量计算和 AI 逻辑共存。它消除了对独立特征库或外部向量数据库的需求，降低了延迟，简化了治理——同时提供企业工作负载所需的性能和可扩展性。

构建 AI 驱动系统方式的转变

将复杂的 AI 逻辑更靠近数据

  • 减少对外部向量数据库或特征库的依赖
  • 使用单一平台进行分析、AI 和事务处理
  • 在企业规模上保持安全性和治理

在数据库层面采用 AI 可以简化 AI 流水线中的许多传统挑战，尤其是对数据治理至关重要的受监管行业。

从架构设计来看，26ai 将数据库从被动的数据存储转变为主动的 AI 平台。这标志着数据库工程的重大演进，并为构建高性能、安全的 AI 驱动应用打开了无需复杂外部堆栈的路径。

如果您正在为企业工作负载探索 AI，26ai 值得进行认真的技术评估。

Oracle AI Database 26ai 作为 AI 执行引擎

该说法只有在以下方面经得起检验时才有意义：

  • 查询计划
  • 实际检索管道
  • 运营约束
  • 与现有开源栈的对比

让我们进行恰当的验证。

1. 向量查询的 EXPLAIN PLAN（优化器实际做了什么）

一个常见的担忧是向量搜索是否被视为一等公民，还是仅仅作为昂贵的函数调用。

示例查询

EXPLAIN PLAN FOR
SELECT doc_id, title
FROM knowledge_base
WHERE category = 'payments'
ORDER BY VECTOR_DISTANCE(embedding, :query_embedding)
FETCH FIRST 5 ROWS ONLY;

简化的 EXPLAIN PLAN 输出示例

------------------------------------------------------------
| Id | Operation                 | Name                |
------------------------------------------------------------
|  0 | SELECT STATEMENT          |                     |
|  1 |  SORT ORDER BY            |                     |
|  2 |   VECTOR INDEX RANGE SCAN | KB_VECTOR_IDX       |
|  3 |    TABLE ACCESS BY INDEX  | KNOWLEDGE_BASE      |
------------------------------------------------------------

为什么这很重要

关键观察

  • VECTOR INDEX RANGE SCAN 是原生访问路径。
  • 关系谓词（category = 'payments'）在早期就被应用。
  • 向量距离计算由优化器计成本。
  • 该计划可以像其他 Oracle 查询一样并行执行。

这与以下方式根本不同：

  • 外部向量数据库调用
  • 在应用代码中后置过滤结果
  • 将大规模候选集合拉入内存

在 Oracle 26ai 中，向量搜索参与与连接、过滤和聚合相同的优化框架。

2. 使用 OCI 生成式 AI 的端到端 RAG

架构概览

RAG Architecture Diagram
图 1 – 高层流程

OCI Generative AI Integration
图 2 – OCI 生成式 AI 服务

Secure Retrieval in Oracle 26ai
图 3 – 安全上下文检索

流程

  1. 用户提交自然语言查询
  2. 应用生成嵌入向量
  3. Oracle 26ai 安全检索相关上下文
  4. 上下文发送至 OCI 生成式 AI
  5. 模型生成有依据的响应

步骤 1 – 生成查询嵌入

通常使用 OCI 生成式 AI 的嵌入模型完成。

# Pseudo‑code (application layer)
query_embedding = generate_embedding(
    model="cohere.embed-english",
    text=user_query
)

步骤 2 – 在 Oracle 26ai 中进行安全上下文检索

SELECT content
FROM knowledge_base
WHERE VECTOR_DISTANCE(embedding, :query_embedding) < 0.30
ORDER BY VECTOR_DISTANCE(embedding, :query_embedding)
FETCH FIRST 5 ROWS ONLY;

重要要点

  • 行级安全自动生效。
  • 被掩码的列仍保持掩码状态。
  • 审计记录访问情况。

这一步是大多数 RAG 系统在治理层面失效的关键点。Oracle 没有这个问题。

步骤 3 – 使用检索到的上下文调用 OCI 生成式 AI

提示模板示例

You are an enterprise assistant.
Answer the question using only the context below.

Context:
{{retrieved_documents}}

Question:
{{user_query}}

数据库永不暴露未授权的数据，模型也不会在批准的上下文之外产生幻觉。

3. Oracle 26ai 与 PostgreSQL + pgvector 的对比

Dimension（维度）Oracle AI Database 26aiPostgreSQL + pgvector
Vector type本机内核类型 (Native kernel type)扩展 (Extension)
Query optimizer完全向量感知 (Fully vector‑aware)成本感知有限 (Limited cost awareness)
Security行级安全、掩码、审计 (Row‑level, masking, auditing)—

Source: …

功能Oracle 26aiPostgreSQL + pgvector
向量搜索原生集成通过扩展实现
检索增强生成 (RAG)强默认弱
高可用性 & 灾难恢复内置企业级DIY（自行实现）
运营开销低中等至高
合规准备度高取决于实现方式

Conclusion – Oracle的 26ai 将向量搜索引入核心关系引擎，提供原生优化、企业级安全和治理，这些在使用如 pgvector 等附加扩展时难以实现。对于需要强大、受监管的 AI 工作负载的组织，集成式方法是一个有吸引力的替代方案。

On Setup

关键洞察

  • pgvector 适用于原型、研究以及中小规模工作负载。
  • Oracle 26ai 旨在为受监管的企业、关键任务系统以及大规模运营 AI 提供支持。

区别不仅在于性能；更在于 在高压下的运营正确性。

AI 数据库生产检查清单

数据与模式设计

  • 有意选择嵌入维度
  • 将原始文本与嵌入分离
  • 若模型变化，进行嵌入版本管理
  • 为关系过滤规范化元数据

索引与性能

  • 明确创建向量索引
  • 监控向量索引使用情况
  • 定期验证 EXPLAIN PLAN
  • 使用关系谓词缩小搜索空间

安全与治理

  • 对源表实施行级安全
  • 在 RAG 之前对敏感列进行掩码处理
  • 为 AI 访问路径启用审计
  • 将嵌入视为敏感数据

运营准备

  • 将向量索引纳入备份策略
  • 使用 AI 工作负载测试灾难恢复（DR）场景
  • 单独监控向量查询延迟
  • 为混合 OLTP + AI 工作负载进行容量规划

模型与提示卫生

  • 将提示模板存储在带版本的表中
  • 记录提示和响应以实现可追溯性
  • 为 RAG 使用严格的系统提示
  • 避免自由形式的上下文注入

DevOps 与平台集成

  • 将 AI 查询视为一等工作负载
  • 为 AI 检索延迟添加 SLO
  • 升级后监控计划回退
  • 将 AI 部署与数据库变更管理对齐

最终视角

Oracle AI Database 26ai 并不试图取代模型；它取代的是脆弱的架构。通过将向量、检索、安全和优化纳入数据库引擎，Oracle 减少了 AI 系统可能出错的环节。对于企业而言，这比新奇更重要。AI 在每天、在负载下、在审计下都能正常工作时才令人印象深刻——而 26ai 正是为这种现实而构建的。

Back to Blog

相关文章

阅读更多 »