Select AI 入门：从自然语言查询到 AI Ready Data 的完整梳理
Select AI 入门：从自然语言查询到 AI Ready Data 的完整梳理
Select AI 让用户用自然语言直接查询 Oracle Database 中的数据。本文按六个常见疑问组织：多语言提问、NL2SQL 与元数据、业务语义的表达方式、AI Ready 评估、凭据管理，以及 SQL 与 RAG 结合的综合案例，并给出可复现的命令与参数说明。
Select AI 是 Oracle Database 提供的一项能力：用户用自然语言提问，由大语言模型生成 SQL，再由数据库执行，最终把结果返回给用户。它解决的是「会写业务问题、但不一定会写 SQL」这类场景——业务人员、数据分析初学者，以及需要快速探查陌生数据集的工程师，都可以借助它把问题直接变成查询。本文按六个常见疑问组织内容：能不能用非英语提问、模型依据什么生成 SQL、业务含义怎么传给模型、如何评估数据是否「AI Ready」、连接凭据怎么管、以及把这些能力组合起来能做什么。文中涉及的价格、配额、版本与可用性，请以官网当前信息为准。
准备工作
在动手之前，需要先确认几项前置条件。这些条件决定了后面哪些步骤能跑通、哪些只能跳过。
- 数据库实例：Select AI 的验证通常在 Autonomous Database 上进行。部分元数据能力（例如 ANNOTATIONS 与 Domain）依赖较新的数据库版本，使用前先确认实例版本是否支持。
- AI 服务与模型：需要确定调用哪家 AI 服务。可以选择 OCI Generative AI，也可以自带 OpenAI 等服务的 API Key。不同服务对应的 provider、model 取值不同。
- 认证信息：如果使用 OCI Generative AI，可以通过 Resource Principal 让数据库自身作为认证主体；如果使用外部 API Key，则需要一个凭据管理位置，例如 OCI Vault。
- 数据库用户权限：执行 Select AI 的数据库用户需要具备相应权限，并且要能访问目标表或视图。注意，在 AI Profile 的 object_list 里列出对象，与数据库层面的访问授权是两件独立的事，两者都要配置。
- 示例数据：文中多处使用 SH 示例模式（商品与销售数据）以及 HR、OE 示例模式。这些示例模式便于对照验证结果。
如果只是先感受一下效果，可以跳过凭据管理的部分，直接使用已有的连接方式；但要在生产环境使用，凭据管理这一节建议完整读完。
操作步骤
第一步：配置 AI Profile
AI Profile 是 Select AI 的核心配置对象，它定义了「用哪个 AI 服务、用哪份凭据、参考哪些对象的元数据」。主要配置项如下：
| 配置项 | 作用 |
|---|---|
| provider / model | 指定使用的 AI 服务与模型 |
| credential_name | 连接 AI 服务所需的认证信息 |
| object_list | SQL 生成时可供参考的表、视图等对象 |
| comments / annotations / constraints | 决定注释、标注、约束是否被写入提示词 |
这里有一个容易被忽略的点：即使数据库里写了说明，如果 Profile 中对应的开关没有打开，这些说明也不会传给模型。所以配置完成后，不要假设「写了就一定生效」，而要实际检查提示词内容。另外，object_list 用于限定模型可见的对象范围，是否强制生效还取决于 enforce_object_list 之类的设置，需要一并确认。
第二步：用不同 Action 观察数据流
Select AI 提供多个 Action，分别对应流程中的不同环节。理解它们的区别，是排查问题的关键。
| Action | 可以看到什么 |
|---|---|
| SHOWPROMPT | 为生成 SQL 而拼装的完整提示词 |
| SHOWSQL | 模型生成的 SQL 语句 |
| EXPLAINSQL | 用自然语言解释生成 SQL 的处理逻辑 |
| RUNSQL | 在数据库中执行生成 SQL 后的结果 |
| NARRATE | 基于 SQL 执行结果，由模型生成的自然语言说明 |
| CHAT | 把问题直接交给模型，以文本形式回答 |
需要特别区分 CHAT 与其他 Action：CHAT 并不通过 SQL 去检索数据库中的表，因此它不适合用来统计真实的行数或销售额。要查询实际数据，应使用 RUNSQL 或 NARRATE。
调用方式很直接，例如：
SELECT AI SHOWPROMPT 有効顧客は何人ですか？;
SELECT AI SHOWSQL 有効顧客は何人ですか？;在常规的 NL2SQL 流程中，提示词里加入的是模式元数据（表名、列名、数据类型、主键外键、注释等），而不是表的行数据。NARRATE 则不同，它会把 SQL 的执行结果交给模型来组织语言。RAG 场景下也是类似思路：把检索到的文档内容作为回答素材传给模型。使用哪个 Action，决定了哪些信息会进入模型，抓住这一点，整个数据流就清楚了。
还有一点值得提醒：先执行 SHOWSQL 再执行 RUNSQL，并不构成一个「确认后批准执行」的机制。如果希望严格核对同一条 SQL 的结果，应当直接查看输出的 SQL 文本，再把它当作普通 SQL 自行执行。
第三步：把业务含义写进数据库
假设提问「有效客户有多少人」，而模型并不知道「有效」对应哪个代码值，它就可能生成错误的条件。解决办法是把含义显式写进元数据。例如给客户表的状态列加注释：
COMMENT ON COLUMN cust_mst.stat_cd IS 'Customer status code. A means active and I means inactive.';同时确认 AI Profile 中的 comments 开关已启用，并检查该说明确实出现在提示词里。在验证中可以看到明显差异：不提供代码含义时，生成的过滤条件是 STAT_CD = '1'，返回 0 条；通过注释说明 A 与 I 的含义后，条件变为 STAT_CD = 'A'，返回 3 条。这说明向模型传达什么信息，会直接改变生成的 SQL 条件。当然，加了注释并不等于所有问题都能答对，它只是把一部分猜测变成了明确信息。
表达业务含义的方式不止注释一种，几种手段各有适用场景：
| 方式 | 承载什么 | 典型用途 |
|---|---|---|
| COMMENT | 以文字描述表或列 | 快速说明「该列的 A 表示有效客户」 |
| ANNOTATIONS | 以键值等形式附加元数据 | 把说明、别名、取值含义分项管理 |
| Domain | 可复用的数据类型、约束与含义 | 统一多张表中反复出现的客户 ID、状态码定义 |
| View | 用 SQL 定义连接、过滤与聚合 | 构造「已确认的有效客户销售额」这类业务对象 |
ANNOTATIONS 并非 Select AI 专属功能，它是以应用程序可解析的形式携带元数据的机制；Domain 的价值在于避免把同一段说明逐列重复书写，而是定义一次、关联到多个列。需要注意，ANNOTATIONS 与 Domain 是较新版本引入的能力，使用前确认数据库版本。选择哪一种，与其问「哪个更聪明」，不如问「这项业务含义放在哪里最便于管理和复用」。
第四步：用主键外键和视图整理查询对象
主键用于标识行，外键表达与参照表之间的关系。这些信息不仅是数据库设计的常规内容，也是模型理解表间关系的线索。有验证通过 MCP（Model Context Protocol）让 AI 应用读取数据库元数据并绘制 ER 图，结果中连跨模式的外键关系也能体现出来。这说明写在数据库里的关系，是可以传达给模型的。即使没有主键外键，模型也可能推测出关系，但显式声明正确的业务关系，可以减少对推测的依赖。
另一个整理手段是视图。业务数据往往需要多表连接并附加条件后才可用，把这些定义固化到视图中，模型面对的查询对象就更清晰。常见的数据分层思路是：
| 层次 | 数据状态 | 实现示例 |
|---|---|---|
| Bronze | 刚导入的原始数据 | 对象存储上的 CSV、Parquet、JSON 等 |
| Silver | 类型、去重、关联已整理 | Table、External Table 等 |
| Gold | 可直接用于业务提问与分析 | Table、View、Materialized View、Analytic View |
例如把「演出计划」「演出实绩」「舞台名称」连接成一个视图，使用者就能针对单一对象提问「该舞台延误了多少分钟」。但要强调：并不是叫 View 的对象就自动成为 Gold 层，关键在于它是否按业务可用的粒度与规则整理过，列的含义、权限、数据新鲜度是否也一并明确。另外，普通视图只保存 SQL 定义，创建视图本身不会保存聚合结果，也不保证查询一定更快；如果关心结果存储与刷新方式，需要另行考虑 Materialized View 等方案。
第五步：评估数据是否 AI Ready
把注释、标注、Domain、主键外键、视图这些手段统称为「语义层」。接下来自然会问：自己的模式到底整理到什么程度了？评估思路是先用 SQLcl 收集元数据，再用 Python 生成评估报告与改进 SQL。值得注意的是，元数据收集与打分过程本身不调用大语言模型。
这里的 AI Ready 指的是：数据不仅存在，而且其含义、关系、新鲜度等信息可被理解，便于 AI 使用。评估结果可以分几轮来看：
- 第一轮，HR 示例模式：表与列的注释、主键的完备率为 100%，衡量含义与关系的 Contextual 得分为 1.00，说明用于 NL2SQL 的说明与关系本来就整理得不错。但统计信息与新鲜度指标存在不足，整体扫描的综合得分为 0.67。把「含义与关系是否完备」和「所有评估项是否都完备」分开看，才能看清优势与改进空间。这也说明，长期认真设计的模式，本身就已经含有可供 AI 使用的信息。
- 第二轮，刻意制造缺失：准备一个元数据不足的模式，注释、主键外键、新鲜度与来源信息都缺失，评估得分为 0.22；按报告提示补充注释、约束、必要列与统计信息后，得分升至 0.97。需要明确，0.97 不是 SQL 正确率 97%。在整理后的数据上，用典型业务问题验证生成 SQL 与结果，基线表现为 10 题中 7 题通过、2 题有条件通过、1 题失败；对失败题目还尝试更换模型做补充验证，说明数据侧整理与模型侧能力需要同时观察。此外，改进 SQL 不会自动判定业务的正确含义——「这个代码代表什么」「哪一列才是正确的连接键」，仍需与熟悉业务的人确认后再落地。
- 第三轮，把标注与 Domain 的语义信息也纳入观察：评估工具扩展到可以收集从 Domain 继承而来的标注，并在报告中呈现内容、登记位置、继承来源以及覆盖列的比例。举例来说，当状态码是 Q7 与 X9 时，仅凭列名很难判断哪个表示有效；把「Q7 为有效、X9 为取消」登记进去后，再验证 Select AI 能否使用这些信息。在最小实验中，直接标注与 Domain 继承两种方式，在 annotations 关闭时与预期结果一致的比例为 0/3，开启时为 3/3，有效订单的合计金额达到预期的 2000。而在另一组已用注释整理过含义的对比中，关闭与开启均为 6/6。可见并非「加了标注就一定改善」，关键是确认所需的含义究竟通过哪条信息路径到达了模型。另外，这一轮新增的语义信息报告并不参与 AI Ready 总分的加分，它只是把总分难以体现的语义细节展开来看。
第六步：管理连接凭据
能跑通之后，凭据管理就成了下一个关注点。两种典型情形如下：
连接 OCI Generative AI 时使用 Resource Principal。Resource Principal 把数据库这类资源本身当作 OCI 上的认证主体。做法是把目标数据库加入 Dynamic Group，通过 IAM Policy 授予访问 OCI Generative AI 的权限，在数据库侧启用 Resource Principal，并在 AI Profile 的 credential_name 中指定 OCI$RESOURCE_PRINCIPAL。这种配置下，不需要把 OCI 用户的 API 签名私钥注册到数据库里管理。更准确地说，它并不是让密钥管理彻底消失，而是把「自行持有 OCI 用户私钥」这件事，交给数据库身份与 IAM 机制来处理。
自带 API Key（例如 OpenAI）时使用 OCI Vault。数据库通过 Resource Principal 访问 OCI Vault，再经由 Vault Secret Credential 使用密钥，AI Profile 中指定该 Credential。两种情形都出现 Resource Principal，容易混淆，区别在于：连接 OCI Generative AI 时，Resource Principal 用于让数据库以自身身份访问该服务；而自带 API Key 时，Resource Principal 用于访问 OCI Vault，真正连到外部服务的仍是 Vault 中保管的 API Key。验证中还包括密钥轮换后 Select AI 仍能正常工作。其他云平台也有各自的密钥管理服务，但上述实测基于 OCI Vault 的配置。
此外，官方文档中还有 Azure OpenAI 的对应做法：使用 Service Principal，无需注册 API Key 即可从 Select AI 连接，AI Profile 中指定 provider: azure 与 credential_name: AZURE$PA，并在 Azure 侧配置访问权限。这属于文档层面的支持信息，而非实测结果，采用前请以官网当前说明为准。
一个完整示例
下面把前面的环节串成一个最小可跑通的流程，目标是用自然语言查询「最畅销的商品及其销量」。示例使用 SH 示例模式的商品与销售数据。
第一步，确认连接与 AI Profile 已配置完成。包括 provider、model、credential_name 以及 object_list 中已包含相关表。
第二步，先用 SHOWSQL 观察模型生成的语句。
SELECT AI SHOWSQL 最も売れた商品と、その販売数は？;检查生成的 SQL 是否引用了正确的表和列，是否包含必要的聚合与排序。
第三步，用 NARRATE 获取自然语言回答。NARRATE 会把 SQL 的执行结果交给模型组织成文字：
SELECT AI NARRATE 最も売れた商品と、その販売数は？;在泰语提问的验证中，返回结果为商品名 Mouse Pad、销量 29282；换成阿拉伯语提问，返回的仍是同一商品与同一销量。这说明不同语言的提问可以落到同一份数据上。语言支持程度与回答质量也取决于所使用的模型，因此实际投入使用时，应针对自己业务中真正会用到的语言与术语做验证。
第四步，把 SQL 与 RAG 组合起来。当问题同时涉及表内数值与文档内容时，可以先用 SQL 取得结构化结果，再把检索到的文档片段一并作为素材交给模型，由模型综合成回答。若流程中还需要执行动作，可以设计为带审批环节的形式，即先生成待执行内容、经确认后再执行。这样既保留了自然语言交互的便利，也避免模型直接改动数据。
注意事项
- Profile 开关决定信息是否传达。数据库里写了注释或标注，并不代表模型一定看得到，需要确认 comments、annotations 等设置，并实际检查提示词内容。
- object_list 与访问权限是两回事。限定模型可见对象，与给数据库用户授予权限，需要分别配置；是否强制生效还要看 enforce_object_list 等设置。
- CHAT 不查表。需要真实数据统计时使用 RUNSQL 或 NARRATE。
- SHOWSQL 加 RUNSQL 不是审批机制。要严格核对结果，请直接查看 SQL 文本并作为普通 SQL 执行。
- 版本差异。ANNOTATIONS 与 Domain 属于较新版本引入的能力，使用前确认数据库版本。
- 评估分数不等于正确率。AI Ready 得分反映元数据整备情况，与 SQL 正确率是不同概念；标注报告也不参与总分加分。
- 改进 SQL 不能替代业务确认。代码含义、正确的连接键等仍需业务人员确认。
- 视图不等于性能优化。普通视图只保存定义，不保存聚合结果，也不保证更快。
- 凭据管理要分清对象。Resource Principal 在两种场景下访问的目标不同，配置时注意区分。
- 多语言效果依赖模型。不同语言的支持程度与回答质量会随模型变化，请用实际业务语言验证。
把上述环节连起来看，Select AI 的使用并不只是「问一句话、拿一个答案」，而是围绕元数据、语义表达、评估与凭据管理形成的一套流程。先让模型看到正确的信息，再让它生成可核对的 SQL，最后把结果与文档素材结合，才能稳定地支撑实际业务中的查询与分析。