Over the years, working with enterprise databases, middleware and production support environments, I have learned one simple thing.
Finding the right information during a production issue
is not always easy!
Sometimes we know exactly what we are looking for. It could
be an Oracle error such as ORA-12541, a database name, an incident number or a
configuration parameter.
But sometimes we only know the problem.
For Ex:
“The application cannot connect to the database after the
DR switch.”
We may have solved exactly the same problem before, but the
old incident or RCA could describe it using completely different words.
This is where I find Hybrid Search in Oracle AI Database
26ai particularly interesting.
It combines something we already know very well - text
search - with semantic vector search.
And for enterprise AI, I think we need both.
Vector Search Changed the Way We Search!
Traditional search mainly depends on words.
If I search for,
“Database connection failure after server restart”
a normal text search looks for those words.
Vector search takes a different approach. It tries to
understand the meaning of the query.
It may therefore find something such as:
“Application unable to connect to DB following reboot.”
Or:
“Connection pool failed after database startup.”
The words are different, but technically we may be talking
about a very similar problem.
That is the power of semantic search.
Oracle AI Database allows us to represent this meaning using
vectors and perform similarity searches directly against data stored in Oracle
Database.
A simplified vector query could look like this,
SELECT id,
document_text,
VECTOR_DISTANCE(
embedding,
:query_vector,
COSINE
) AS distance
FROM support_documents
ORDER BY distance
FETCH FIRST 5 ROWS ONLY;
Here we are not searching for an exact phrase.
We are asking Oracle to find vectors that are closest to the
vector representing our question.
That opens some very interesting possibilities for
enterprise knowledge search.
But there is a problem.
Meaning is not always enough. In Enterprise IT, Exact
Information Still Matters!
Think about a support engineer searching for:
ORA-12541
In this situation, I don't necessarily want the system to
find something that is simply semantically similar to ORA-12541.
I want information about that exact error.
The same applies to many things we deal with every day,
- Oracle error codes
- Database and server names
- Incident numbers
- Customer IDs
- Application names
- Product codes
- Configuration parameters
- Software versions
Now consider:
“ORA-12541 after Data Guard switchover.”
This is different.
I want an exact match for:
ORA-12541
But I also want the system to understand the context:
Something happened following a Data Guard switchover.
That is where Hybrid Search starts making sense.
Keyword Search + Semantic Search
I look at Hybrid Search in a very simple way.
Keyword search asks:
“Does this document contain what I am looking for?”
Vector search asks:
“Does this document mean something similar to what I am
looking for?”
Hybrid Search can use both.
Conceptually:
For me, this is much closer to how an experienced engineer
actually investigates a production issue.
We rarely search using only one method.
We combine the error, symptoms, environment and our
understanding of what happened.
Oracle 26ai Hybrid Vector Index
Oracle AI Database 26ai provides the Hybrid Vector Index,
bringing Oracle Text and vector-search capabilities together.
A simplified example is:
CREATE HYBRID VECTOR INDEX
support_hybrid_idx
ON
support_documents(document_text)
PARAMETERS ('MODEL
my_embedding_model');
Once the index is available, we can perform hybrid searches
through Oracle's DBMS_HYBRID_VECTOR.SEARCH functionality.
For example:
SELECT DBMS_HYBRID_VECTOR.SEARCH(
JSON('{
"hybrid_index_name" :
"support_hybrid_idx",
"search_text" :
"ORA-12541 after Data Guard
switchover"
}')
)
FROM dual;
The important part for me is not simply the SQL syntax.
It is what is happening behind it.
Instead of asking the database only:
“Find these words.”
or only:
“Find something semantically similar.”
we can bring both approaches into the retrieval process.
A Practical Support Example
Imagine we maintain a knowledge base containing previous
incidents.
A very simplified table could look like this:
CREATE TABLE support_documents (
id NUMBER PRIMARY KEY,
incident_no VARCHAR2(30),
environment VARCHAR2(20),
incident_date DATE,
document_text CLOB
);
We may have records such as:
INSERT INTO support_documents
VALUES (
101,
'INC-2026-001',
'PRODUCTION',
SYSDATE - 20,
'ORA-12541 occurred after Data Guard switchover.
Listener configuration was validated and
service
registration was restored.'
);
INSERT INTO support_documents
VALUES (
102,
'INC-2026-002',
'PRODUCTION',
SYSDATE - 40,
'Application connectivity was interrupted following
database role transition. Database
services were
restarted and connectivity was restored.'
);
Now lets look at these two incidents.
The first contains the exact error:
ORA-12541
The second does not.
But the second incident could still be technically relevant
to someone investigating a connectivity problem following a Data Guard role
change.
A keyword only search may give more importance to the first
incident.
A semantic search may understand the relationship with the
second incident.
A Hybrid Search can potentially use both signals.
This is where I see the real value.!
Think About the Knowledge We Already Have
Most enterprises already have a huge amount of technical
knowledge.
The problem is often finding it.
Think about all the information stored across:
- Incident records
- RCA documents
- Support tickets
- Troubleshooting guides
- SOPs
- Architecture documents
- Configuration documents
- Vendor support cases
I have seen this many times in support environments.
A new incident happens and somebody says,
“I think we had something similar before.”
Then we start searching old tickets, emails, folders, RCA
documents and vendor cases.
Sometimes we end up asking the engineer who handled the
problem several years ago.
Now imagine asking:
“Have we previously experienced database connectivity
problems following a DR switch?”
An old RCA may say:
“Application connectivity was interrupted following
database role transition.”
There may be no exact keyword match.
But semantically, it is highly relevant.
This is exactly the type of problem where vector search
helps.
Add an exact Oracle error or configuration parameter to that
question, and Hybrid Search becomes even more useful.
Hybrid Search Can Improve RAG
This becomes even more important when we start building Retrieval
Augmented Generation (RAG) solutions.
A basic RAG architecture normally looks something like this,
But there is something I think we sometimes overlook.
The LLM can only work with the context we provide.
If the retrieval layer gives the LLM poor or irrelevant
information, simply using a bigger or more powerful model will not solve
everything.
This is why I believe retrieval architecture deserves more
attention in enterprise AI projects.
With Hybrid Search, the architecture becomes more
interesting..
Now we are giving the LLM context based on both exact
terminology and semantic meaning.
For enterprise RAG, I see this as an important improvement.
Don't Forget the Structured Data
There is another area that makes this interesting from a
database perspective.
Enterprise searches are rarely only about documents.
Imagine asking,
“Show me similar Oracle listener incidents affecting
production systems during the last six months.”
There are several requirements here.
“Similar Oracle listener incidents” requires semantic
understanding.
Specific Oracle terminology may benefit from text search.
But,
Environment = PRODUCTION
And,
Incident Date >= Last Six Months
are structured conditions.
This is where the database becomes much more than a place to
store embeddings.
We already have valuable relational information around our
enterprise data.
That context should also be part of our AI architecture.
AI Does Not Remove the Need for Good Database
Architecture
There is a lot of discussion today around LLMs.
1.
Which model should we use?
2.
Which embedding model?
3.
Cloud or on-premises?
4.
How large should the model be?
All are valid questions.
But from my experience working with enterprise technology, I
would add another one..
Are we giving AI the right information in the first
place?
For production AI systems, retrieval quality, security,
availability, performance, data governance and observability still matter.
Our traditional database and enterprise architecture
experience does not become irrelevant because of AI.
I believe it becomes even more important.
I Would Not Use Hybrid Search Everywhere!
Hybrid Search should also not become the answer to every
search problem.
If I need an exact customer ID, normal relational search may
be enough.
If I only need conceptually similar documents, vector search
may be enough.
But if the requirement includes both exact information and
semantic understanding, Hybrid Search becomes very interesting.
For me, the important principle is..
Use the search architecture that matches the problem!
We should not use vector search simply because vectors are
part of the current AI discussion.
Technology should solve the requirement, not the other way
around!
Comments
Post a Comment