1Z0-1127-25 Practice Question: Building LLM Applications with RAG and Vector Search
A healthcare company is building a RAG-based chatbot to answer patient queries using medical documents stored in OCI Object Storage. They use OCI Generative AI service with Cohere Command R+ model and OCI OpenSearch as the vector database. The chatbot is deployed on OCI Compute with a Flask application. After deployment, the latency for each query is 15-20 seconds, which is unacceptable. Logs show that the embedding generation step (using OCI Generative AI embedding API) takes 8-10 seconds, and the vector search in OpenSearch takes 5-7 seconds. The team has already enabled connection pooling and increased the compute instance shape to the maximum allowed. Which action would MOST effectively reduce the overall latency?
⚠ Common exam trap
The trap here is that candidates may focus on optimizing the vector search or caching responses, but the real bottleneck is the embedding generation step, which must be eliminated at query time through pre-generation during ingestion.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Pre-generate embeddings for all documents during ingestion and store them in the vector database, so at query time only the query embedding is generated and compared.
The primary bottleneck is the embedding generation step (8-10 seconds). By pre-generating embeddings for all documents during ingestion and storing them in the vector database, the query-time embedding generation is eliminated, reducing the per-query latency to only the time needed to generate the query embedding and perform the vector search. This directly addresses the largest contributor to the 15-20 second latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Pre-generate embeddings for all documents during ingestion and store them in the vector database, so at query time only the query embedding is generated and compared.
Why this is correct
This eliminates the need to generate embeddings for each document during the query path, drastically reducing latency.
- ✗
Implement a caching layer with Redis to store previous query results and serve cached responses for identical queries.
Why it's wrong here
Caching only helps for repeated queries; most patient queries are unique, so cache hit rate will be low.
- ✗
Reindex the OpenSearch vector index with optimal settings (e.g., HNSW algorithm, ef_search param) to speed up vector search.
Why it's wrong here
While this may slightly improve search speed, the main bottleneck is embedding generation (8-10s), not search (5-7s).
- ✗
Switch to a faster embedding model like Cohere Embed v3 (English) which has lower latency.
Why it's wrong here
Switching models may reduce embedding time slightly but still requires a synchronous API call per query, so latency remains high.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 1Z0-1127-25 question from scratch — 768 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 1Z0-1127-25 practice question is part of Courseiva's free Oracle certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 1Z0-1127-25 exam.