Oracle AI Vector Search did not start with a desire to add one more kind of search. It started with a simple problem: people do not always search using the same words that appear in the information they need.

A traditional search looks for matching words, values, or attributes. That works well when the user knows the exact term. But it can miss useful information when the wording is different. Someone might search for “how to reduce database memory use,” while the document discusses “sizing the In-Memory column store.” The words are different, but the meaning is closely related.

AI Vector Search is designed to search by that meaning.

Search by meaning

To make this possible, an AI model known as an embedding model, converts text, images, audio, or other content into a numerical description called a vector. The vector is not a replacement for the original content. It is more like a map showing where that content belongs in relation to other content with similar meaning.

When a user asks a question, the question is converted into the same kind of numerical description. The database can then find the stored content that is closest in meaning to the question. The search model also matters. The same embedding model should be used for both the stored content and the user’s question so that they are being compared in the same semantic space.

This changes the experience from “find documents containing these words” to “find information related to what I am asking.”

That distinction matters in many situations. A product search may begin with a natural-language description and still need to consider price, availability, location, and manufacturer. A support assistant may need to understand the intent behind a question while also applying customer, product, or date filters. A legal or financial search may need to understand the broader topic but still find an exact company name, product code, or regulation.

The goal is not to replace traditional search. It is to give applications another way to find the right information for unstructured data.

Why put it in the database?

Most enterprise information already lives in a database. Customer records, orders, inventory, documents, permissions, and business rules are often stored together or connected through the database.

Moving that information into a separate search system can create additional copies, additional pipelines, and additional considerations for managing data access and security controls. It can also make it harder to search current business information. A separate system may know what a document says, but not whether the related product is still available or whether the person asking the question is allowed to see it.
Keeping vector search alongside business data makes it possible to combine both kinds of questions. An application can search for information that is similar in meaning while also applying ordinary business conditions and applicable database access controls.

This is one of the main reasons we built AI Vector Search into Oracle AI Database. The value is not only that the database can compare vectors. The value is that it can compare them in the same place where the business data, relationships, transactions, and controls already exist.

Why do we need different ways to make it fast?

The most straightforward way to find similar content is to compare a question with every stored vector. That gives a complete answer, but it becomes expensive as the amount of data grows.

Traditional relational indexes use the concepts of ‘less than’, ‘equal to’ or ‘greater than’ in the index data structures to enable efficient search while supporting exact-match and range-based queries. The concepts of ‘less than’ and ‘greater than’ do not make sense with vectors which are a set of numbers. Instead, the concept of vector distance is used. Vector distances are computationally expensive to calculate, so a tradeoff between accuracy and performance needs to be made. That tradeoff is intentional. In many applications, finding a sufficiently relevant result with a shorter response time is more useful than spending much longer finding the exact nearest match.

Oracle provides two main approaches for this:

  • The HNSW index approach keeps its search structure in memory. It is a strong choice when fast response times are important, and the index can comfortably fit within the available memory.
  • The IVF index approach organizes the vectors into groups and searches the most relevant groups. It can be suitable when the collection is too large for an entirely in-memory structure. It can also work well with partitioned data and larger enterprise workloads.

Neither approach is universally better. The right choice depends on the size of the data, the available memory, the expected response time, and the level of accuracy the application requires.

Why combine meaning with keywords?

Semantic search is powerful, but it is not always enough by itself for large text-based data.
A user may want information about “fraud involving ABC Corporation.” Semantic search is useful for understanding fraud and related concepts. Keyword search is useful for making sure the results actually concern ABC Corporation.

This is where hybrid search helps. It combines a search based on meaning with a search based on exact words. The two result sets are brought together and ranked as one.

Hybrid search is especially useful when a question includes names, product codes, technical terms, dates, organizations, or other details that should not be interpreted too loosely. Semantic search helps broaden the search when the wording is different. Keyword search helps keep the results focused.

Large documents also need more careful preparation. They are usually broken into smaller sections so that each section represents a more focused idea and can fit within the limits of the AI model. Smaller sections often improve relevance, but they can also lose some of the surrounding context. Combining document-level keyword search with section-level semantic search can help balance retrieval relevance and context. Breaking documents into smaller sections is called chunking, and the appropriate chunking and retrieval strategy can help improve search relevance for large documents.

Where RAG fits

Retrieval augmented generation, or RAG, uses vector search results to provide relevant context for an answer from a large language model.

A language model may know a great deal, but it does not automatically know a company’s private information or the latest version of an internal document. RAG first uses vector search on the organization’s data, selects the most relevant pieces, and gives them to the language model as context for the answer.

This helps the model respond with a natural language answer using current, business-specific information instead of relying only on its original training. It can help reduce unsupported or inaccurate responses when relevant information is retrieved and used appropriately and make responses more useful for questions that depend on private or changing information.

The quality of the answer depends heavily on the quality of the retrieved information. Too few results may leave out an important fact. Too many results may add unrelated information and distract the model. The goal is to retrieve a small, focused set of useful content and vector search can play an important role in supporting that process.

The bigger picture

AI Vector Search is not a replacement for the database, traditional search, or careful data design. It is a way to make meaning part of the way applications work with data.

We built AI Vector Search around a few practical ideas:

  • Search should understand more than exact words.
  • Business data and unstructured data should be searchable together.
  • Speed and accuracy should be adjustable to fit the application.
  • When unstructured enterprise data changes, the vectors which represent that unstructured data should also be able to be changed at the same time.
  • Keyword search and semantic search should be able to work together for large textual data.
  • Retrieved information should remain connected to its original source and business context.
  • Generative AI should be given relevant, current information instead of being expected to know everything on its own.

The result is a more complete approach to search. Applications can find information by meaning, narrow it using business rules, apply existing database access controls, as appropriately configured, and provide the results as context for AI-generated natural language responses.

That is why we built AI Vector Search: to make AI search useful in the places where enterprise data already lives.