Search latency is the top priority on a very large index. Which configuration fits?
Why B is the answer
Standard Vector Search, with hybrid and reranking off
Hybrid search and reranking add latency, so standard search with both off fits a latency-first requirement.
In detail
- Hybrid search and reranking add time to each query.
- When latency comes first, keep the extras off on a Standard endpoint.
- Test relevance after you remove the extras.
Use case
An illustrative scenario, not a real incident.
A product search must answer in milliseconds. Standard search with hybrid and reranking off meets the target. Relevance tests confirm it is still good enough.
See it in different ways
flowchart TD
A{"Top priority"} -->|"Lowest latency"| B["Standard, keep hybrid and reranking off"]
A -->|"Very large scale at lower cost"| C["Storage optimized"]
A -->|"Best relevance"| D["Turn on hybrid search and reranking"]mindmap
root((RAG app))
Data
Delta tables
Chunks
Retrieval
Vector index
Reranking
Chain
MLflow
Agent Framework
Serving
Model Serving
Governance
Unity Catalogflowchart TD
Q{"What matters most?"}
Q -->|"Lowest latency"| A0["Standard, extras off"]
Q -->|"Best relevance"| A1["Hybrid and reranking on"]
Q -->|"Scale at lower cost"| A2["Storage optimized"]Key point: Every extra search step adds latency.
Why the other options are wrong
- A. A larger top-k on each query
- More results take longer to return and process.
- C. Storage optimized search, with all extras on
- Storage optimized suits scale and cost, and the extras add latency.
- D. Reranking every query for accuracy
- Reranking every query adds time.

