Oracle Select AI: NL2SQL, RAG, and In-Database Agents Across 26ai and 19c

Select AI is Oracle's in-database natural language layer. It lets you generate SQL from plain text, retrieve semantically relevant content from vector stores, build agentic workflows, and produce synthetic data, all from within the database engine using SQL and PL/SQL as the integration surface. It is included with Oracle AI Database and Oracle Autonomous AI Database at no additional license cost. You supply the LLM.

This article covers what Select AI actually does at the execution level: how the NL2SQL pipeline constructs prompts, how auto object selection narrows schema context using vector search, how RAG retrieval works, and what the 26ai version boundary means in terms of which features depend on Oracle AI Vector Search.

Version Matrix: 26ai vs. 19c

The capability split between releases is determined primarily by Oracle AI Vector Search availability. Vector Search is available in 26ai but not in 19c, and several Select AI features depend on it directly. For Oracle AI Database, version 23.26.1 is the 26ai release. Autonomous AI Database maps to 26ai through its own release track.

AI Profile Configuration in Select AI

Every Select AI operation is scoped to an AI profile. The profile defines which LLM provider and model the operation uses, along with the database objects that are in scope for NL2SQL. You create profiles with DBMS_CLOUD_AI.CREATE_PROFILE, passing a JSON configuration object that specifies the provider, model, credential, and object list.

Supported providers include OCI Generative AI, OpenAI, Azure OpenAI, Cohere, Google, Anthropic, Hugging Face, Amazon Bedrock, OpenAI-compatible third-party endpoints, and private LLM deployments. The provider selection is isolated to the profile, so different Select AI operations in the same database can target different models by switching the active profile with DBMS_CLOUD_AI.SET_PROFILE.

How the NL2SQL Pipeline Works in Select AI

When you invoke a Select AI NL2SQL action, the database constructs an augmented prompt before the LLM ever sees your input. It reads schema metadata, table names, column names, data types, and any comments you have added, from the objects listed in your AI profile. That metadata is injected into the prompt alongside your natural language query, giving the LLM the structural context it needs to generate valid SQL against your specific schema.

The NL2SQL actions are GENERATE, RUNSQL, NARRATE, and EXPLAINSQL. Generate returns the SQL text without executing it. Runsql executes the query and returns results. Narrate executes the query and returns a prose summary of the results. Explainsql returns a natural language explanation of what a given SQL statement does. You invoke these through the AI keyword in a SQL select statement or through PL/SQL procedure calls.

Auto Object Selection in 26ai

In a large schema with hundreds of tables, including all object metadata in every NL2SQL prompt is impractical. The prompt grows too large, the LLM's attention is distributed across irrelevant tables, and token cost rises with every query, regardless of which tables are actually needed. Auto object selection addresses this directly.

When auto object selection is enabled, Select AI automatically builds a vector index over the schema metadata for all objects in your AI profile. At query time, it runs a semantic similarity search over that index using your natural language prompt as the query vector. Only the metadata for the top-matching tables is included in the augmented prompt sent to the LLM. You do not configure the index manually; the database creates and maintains it on the objects your profile references.

The practical effect is that NL2SQL accuracy improves for large schemas because the LLM receives focused context rather than a metadata dump. Token cost per query also decreases because the prompt payload is smaller. You do not need to manually curate a reduced object list in your profile to get this behavior in 26ai.

NL2SQL Feedback Mechanism in Select AI

NL2SQL feedback is a 26ai capability that lets users correct generated queries and store those corrections as a training signal. Feedback is submitted from the SQL command line or through PL/SQL procedure calls. The feedback records the original prompt, the generated SQL, and the corrected SQL or the quality signal indicating whether the generation was acceptable.

This feedback is used to improve query generation accuracy for subsequent calls. The mechanism is relevant for schemas with non-obvious column naming conventions, domain-specific terminology, or business logic that does not surface naturally from schema metadata alone. Over time, the feedback loop tightens the relationship between the vocabulary your users actually use and the SQL Select AI generates for them.

RAG Pipeline Architecture of Select AI

Select AI RAG in 26ai integrates LLM reasoning with content stored in Oracle AI Vector Search. The pipeline has three stages: embedding generation, retrieval, and prompt augmentation. When you add documents to your vector store, the database generates embeddings using the embedding model specified in your AI profile and stores them alongside the source content. At query time, Select AI generates an embedding for your prompt, retrieves the top-K semantically similar content chunks from the vector store, and injects that retrieved content into the LLM prompt before generation.

The embedding model and the generation model are configured independently in your AI profile. You can use a lightweight embedding model for the retrieval stage and a larger reasoning model for generation, which is a common cost optimization. The vector store itself is a standard Oracle AI Vector Search index on a database table, so it inherits all of Oracle's standard backup, replication, and access control behaviors without additional configuration.

Select AI Synthetic Data Generation

Synthetic data generation produces schema-conformant data using the LLM specified in your profile. The database reads the target table's schema and any column-level comments you have added, then generates INSERT-ready rows that match the data types, constraints, and semantic intent of the schema. This is useful for populating development clones, generating test data sets, or producing labeled training data for ML pipelines where production data access is restricted by policy.

The quality of the generated data depends significantly on the column comments in your schema. A column named CUST_TYPE without a comment gives the LLM almost no signal about valid values. A column with a comment that specifies the domain, format, or valid value set produces much more usable synthetic rows. Adding meaningful comments to your schema before invoking synthetic data generation is the single highest-leverage configuration step for this feature.

In-Database AI Agents

The Select AI agent framework lets you build autonomous, multi-step workflows that execute inside the database. An agent takes a goal expressed in natural language, determines a plan, calls tools to execute steps, evaluates intermediate results, and iterates until the goal is satisfied. The entire execution happens in the database engine, with logic written in PL/SQL.

Agents support both built-in tools, such as NL2SQL execution and RAG retrieval, and custom tools that you define as PL/SQL procedures. Custom tool registration tells the agent what the tool does, what parameters it accepts, and when to use it. The agent's reasoning loop calls these tools as appropriate based on the current state of the task. Memory across conversation turns is maintained in the database, so long-running agent sessions survive process restarts without external session state management.

The architectural consequence of running agents in the database rather than in an application tier is that data movement is minimized. The agent operates directly on the data it is reasoning about without serializing query results through an application layer, a network call, and a vector store lookup on a separate service. For workflows that involve iterative data examination, this colocation materially reduces both latency and complexity.

Summarization and Conversational Context

Summarization in Select AI converts query result sets into prose using the active AI profile's LLM. You get a readable description of what the data says rather than raw rows. This is surfaced through the NARRATE action in NL2SQL or as a standalone capability for arbitrary database content.

Conversations extend all Select AI capabilities to multi-turn sessions. Context from prior turns is maintained and passed to subsequent prompts within the same conversation, allowing follow-up questions that reference earlier results without restating the full context. A conversation is scoped to a session by default, and conversation state is stored in the database, which means you can retrieve and continue prior conversations rather than starting fresh on each connection.

Select AI Translation

Translation in Select AI routes through external translation APIs rather than the primary LLM in your AI profile. Supported backends include OCI Language, Google Cloud Translation, AWS Translate, and Azure Translator. You configure the translation provider as a separate credential in the database and reference it in translation-specific Select AI calls. This keeps translation costs separate from LLM costs and lets you use a purpose-built translation service rather than consuming LLM tokens for language conversion.

Conclusion

The version boundary between 19c and 26ai in Select AI comes down to Oracle AI Vector Search availability. If your deployment is on 26ai, you get auto object selection for focused schema context, feedback-driven NL2SQL refinement, and a fully managed in-database RAG pipeline on top of the core capabilities that 19c also provides. If you are on 19c, you still have NL2SQL, agents, synthetic data generation, summarization, and conversation, which covers most production use cases.

The highest-leverage configuration steps are accurate column comments for NL2SQL and synthetic data quality, a correctly scoped object list in your AI profile, and independent selection of embedding and generation models to balance cost against quality for RAG workloads.