我刚接触 Select AI 这个功能的时候，其实是持怀疑态度的。让 AI 自动写 SQL？先不说安全风险，它连我库里的表结构、字段含义都不知道，写出来的东西能靠谱吗？直到实际用了 Oracle 26ai 版本的实现，才发现这个功能的成熟度比预想中高很多。今天就聊聊它背后的核心逻辑，特别是大家最关心的 “精准转换”，到底靠什么支撑。

一、核心底层：不是纯靠大模型，是元数据驱动的工程化体系

很多人对这类功能有个误区，觉得就是用户说一句自然语言，大模型直接输出 SQL。实际上 Oracle 的思路非常务实 —— 它没有把所有希望都寄托在 LLM 的通用能力上，而是在中间做了一层非常扎实的工程化缓冲层。

整个体系的核心载体叫 AI Profile，你可以把它理解成 AI 查询的 “权限与边界说明书”。每个 Profile 里必须明确配置三类信息：用哪家的模型来处理、允许查询哪些数据库对象（比如指定 Schema 下的某几张表）、以及其他附加规则（比如是否开启 RAG 能力）。

为什么说元数据是精准度的核心？因为 LLM 生成 SQL 最大的痛点，就是 “不知道你的表长什么样”。如果只丢给 LLM 一句 “查一下有多少客户”，它大概率会生成一句语义正确但完全不匹配你表结构的 SQL。

Oracle 的解决方式很直接：当你输入 SELECT AI showsql how many customers exist这类语句时，系统会识别到 AI 关键字，立刻根据 Profile 里配置的对象列表，去拉取目标表的完整元数据 —— 包括字段名、数据类型、约束条件、字段注释，甚至外键关联关系和业务注解。这些信息会被组织成结构化的系统提示词，和用户的自然语言问题一起打包发给 LLM。

相当于在提问之前，先把 “数据字典” 甩给了 LLM。它知道了 CUST_CITY是城市字段、 CUST_MARITAL_STATUS代表婚姻状态，后续遇到 “旧金山的已婚客户” 这类问题时，才能精准写出 WHERE UPPER(CUST_CITY) = ... AND UPPER(CUST_MARITAL_STATUS) = ...这类条件。这是保障精准度的第一道防线。

二、完整执行链路：从自然语言到结果的全流程

我们用一个实际例子走一遍完整流程，假设 Profile 已经配置好，指向 SH Schema 下的 CUSTOMERS 表，用户输入： SELECT AI showsql how many customers in San Francisco are married?

第一步： 识别触发与元数据抓取Select AI 识别到 SQL 语句中的 AI 关键字，暂停常规的 SQL 解析流程，转入 AI 处理链路。同时根据 Profile 的配置，拉取 SH.CUSTOMERS 表的完整元数据信息。

第二步： 结构化 Prompt 构建系统会自动拼接多层提示词：最上层是角色与规则指令（“你是 Oracle SQL 专家，仅生成符合 Oracle 语法的合法 SQL”），中间层是 Schema 元数据（表结构、字段定义、注释信息），再加上用户的自然语言问题，最后是输出约束（“仅输出 SQL 语句，不要额外解释”）。

第三步： LLM 推理生成 SQL拼接好的 Prompt 发送给大模型，LLM 基于元数据理解字段含义，匹配 “旧金山”“已婚” 对应的字段与条件，结合 COUNT 聚合函数，生成符合语法的 SQL 语句。

第四步： 结果返回生成的 SQL 交回 Select AI 模块处理。如果用的是 showsql，就只返回生成的 SQL 语句；如果是 runsql，会直接执行 SQL 并返回数据结果。

这里有个很实用的细节： explainsql动作。它不会返回查询结果，而是让 LLM 解释自己生成的 SQL 逻辑。实际调试的时候特别好用 —— 先跑一遍 explainsql，看看 AI 的理解和逻辑对不对，确认没问题了再切到 runsql 执行，能避开很多没必要的坑。

三、26ai 版本的精准度升级：三个直击痛点的优化

26ai 这个版本在精准度上做了不少落地的优化，其中有三个点我觉得是真正解决了实际使用的痛点。

1. 自动对象选择（Auto Object Selection）

之前的版本里，你必须在 Profile 里手动维护 object_list，告诉 AI 可以访问哪些表。表少还好，表多了不仅配置麻烦，大量无关表的元数据一起塞给 LLM，反而会引入噪音，增加生成错误的概率。

26ai 的做法很巧妙：把所有表的结构信息、业务注释都做向量化，建立一个专门的对象向量索引。用户提问的时候，系统先把你的自然语言问题做向量化，去这个索引里做语义检索，自动匹配出最相关的几张表，只把这几张表的元数据发给 LLM。

相当于给 AI 配了个 “图书管理员”，不用把整个图书馆都搬过来，而是根据问题精准找对应的参考书。既减少了无关信息的干扰，也降低了 LLM 的推理成本，速度和准确率都有提升。

2. 反馈机制（Feedback）

这是我认为最解决根本问题的功能。实际用的时候 LLM 难免出错，比如该用 SUM 的地方用了 COUNT，或者 JOIN 逻辑不符合业务习惯。放在以前，你只能接受结果，或者调整提示词重新提问。

26ai 新增了 DBMS_CLOUD_AI.FEEDBACK过程，你可以直接给 AI 反馈：“这次查询不对，应该用 SUM 聚合而不是 COUNT”。系统会把这条反馈和对应的 sql_id 一起存入专门的反馈向量索引。下次再遇到类似的查询请求，系统会自动检索历史反馈，把纠正信息一起放进 Prompt 里，相当于让 AI“吃一堑，长一智”。

这个机制直接让 Select AI 从 “静态翻译器” 变成了 “可学习的助手”。用得越久、反馈越多，它就越适配你的数据环境和业务查询习惯。

3. 数据库内 ONNX Runtime

对于 RAG 场景来说，向量化是核心步骤。以前很多方案都需要把数据拉出数据库，到外部服务做向量化再返回结果，一来一回有延迟，更关键的是存在数据安全风险。

Oracle 26ai 直接在数据库内核里集成了 ONNX Runtime，可以把预训练好的 Transformer 模型导入到数据库中。这样一来，文档分块、向量化、用户提问的向量化，全部在数据库内部完成，数据全程不出库，既安全又低延迟。对于有大量内部文档、同时对数据安全要求极高的企业场景，这个特性可以说是刚需。

四、能力延伸：联邦查询与图查询

Select AI 的能力不止于单库单表。

• 联邦查询：通过 Database Links、Cloud Links 和 Table Hyperlinks，它可以实现跨库查询。也就是说你可以基于本地表提问，AI 生成的 SQL 会自动 JOIN 远端的 PostgreSQL 或者其他 Autonomous Database 的数据，跨库关联逻辑都在后台自动处理，只需要提前在 Profile 里定义好即可。
• 属性图查询（PGQ）：如果数据库里定义了属性图，你可以直接问 “帮我查一下产品之间的关联路径”，AI 会自动生成 GRAPH_TABLE 查询。以前需要写复杂模式匹配语句的知识图谱场景，现在一句自然语言就能搞定。

五、实战经验：怎么让 Select AI 达到生产级可用

踩过一些坑之后会发现，想让这个功能真正好用，几个前提条件必须满足。

第一， 表设计的质量决定了上限。字段命名要尽量语义化，注释一定要写全。如果一张表里全是 COL1、COL2 这种无意义命名，又没有业务注释，LLM 生成的 SQL 大概率会出错。26ai 强化了 Annotation 功能，可以给表和字段补充业务注解，这些注解会被自动识别并加入到提示词里，这是成本最低、见效最快的精准度优化手段。

第二， Profile 的边界一定要清晰。一个精准的小 Profile，远好过一个大而全的 Profile。限制 AI 的可见范围，反而能提升精准度，同时也保障了数据安全。建议按业务模块拆分，不同场景用不同的 Profile，不要贪多求全。

第三， 不要期待一次就完美，善用工具磨合。多用 showsql 预览 SQL，用 explainsql 核对逻辑，遇到错误就通过 feedback 功能反馈修正。把它当成一个需要熟悉业务的新人 DBA，通过反馈机制逐步适配你的环境。这个系统是越用越准的。

最后

回到最开始的问题：自然语言到底是怎么精准转换成 SQL 的？ Oracle 26ai Select AI 给出的答案，从来不是靠大模型的 “魔法”，而是靠一套完整的工程体系 —— 元数据治理打底、向量检索做筛选、反馈闭环做迭代、再加上联邦与图查询的扩展能力。LLM 负责执行 “翻译” 的动作，而数据库侧负责提供 “上下文” 和 “记忆”。

它的定位从来不是取代 DBA 或者 SQL 开发，反而更像一个高效的副驾驶。它把人从繁琐的语法细节、字段核对里解放出来，让我们可以把精力放回 “我到底想从数据里获得什么信息” 这个本质问题上。

如果还没试过的话，建议找个测试库，配置一个简单的 Profile，对着你最熟悉的业务表问几个最关心的问题。那种 “说出需求，马上拿到结果” 的体验，确实很不一样。