Vector Search is Hard
In spite of the demos you have seen, implementing vector search for a real-world application is hard.
Google Search has set user expectations for search. Those expectations carry over into APEX apps.
I implemented vector search for an APEX app that manages projects. Entities included requirements, questions, risks, issues, etc. Each one of these entities has attributes like name, status, content, owner, etc. The expectation was a Google style search on all fields across all projects.
So how can you vectorize 100 fields across 20 tables? The answer is with great difficulty. You have to choose the content that makes sense to vectorize and use traditional structured filters for the rest.
But even a simple example is not simple. Take a project question; at its core you have a question (CLOB) and an answer (CLOB).
With large CLOBs, a single vector can blur together too many concepts. Breaking the content into chunks introduces another set of decisions:
How big should the chunks be?
How much should the chunks overlap?
Where should you split the chunks?
Do you need to convert HTML to plain text first?
How will you link each chunk back to the original question or answer?
You also have to choose an embedding model that works well for your languages and content, and decide whether to run it inside the Oracle database using ONNX or call an external API.
I haven't even gotten into vector indexes or keeping chunks and embeddings up to date when content changes or is deleted.
My advice:
Do not start with vector search. Start with the searches your users need.
Ask yourself (or your users) for the top 10 searches and the results each should return. Use those examples to decide whether you need vector search, structured filters, Oracle Text, Oracle Ubiquitous Search, or a combination. Some expectations may need resetting.
