Building LLM Applications with RAG and Vector Search →hardMultiple SelectObjective-mapped

1Z0-1127-25 Practice Question: Building LLM Applications with RAG and Vector Search

Which THREE techniques effectively reduce query latency in a RAG system?

⚠ Common exam trap

Oracle often tests the misconception that increasing model size or shard count always improves performance, but in RAG systems, these changes can introduce latency penalties due to higher computational overhead or distributed coordination costs.

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-compute embeddings for all documents

Pre-computing embeddings for all documents eliminates the need to generate embeddings at query time, which is a computationally expensive step. By storing pre-computed vector representations, the system can directly perform similarity searches against the index, significantly reducing 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-compute embeddings for all documents
Why this is correct
Pre-computed embeddings avoid real-time embedding calls during query.
✓
Use approximate nearest neighbor search
Why this is correct
ANN is faster than exact search, reducing vector search latency.
✗
Use a larger generation model
Why it's wrong here
Larger generation models increase generation latency.
✗
Increase the number of shards
Why it's wrong here
More shards may increase parallelism but also overhead; not a guaranteed latency reduction.
✓
Use a smaller embedding model
Why this is correct
Smaller models have lower inference latency for embedding creation.

Go deeper

1Z0-1127-25 Practice Question: Building LLM Applications with RAG and Vector Search

Why each option matters

Option-by-option breakdown

Related to this question