An engineer at Meridian Line wants to increase the query throughput available to the port-operations copilot's retrieval step without changing which documents are indexed or how they are chunked. What should be scaled?
Select an answer to reveal the explanation.
Short Explanation
The index is your data; the endpoint is the compute answering questions about that data. If queries are the bottleneck and the data itself is fine, the endpoint is what you scale -- the index doesn't need to change at all.
Full Explanation
Databricks Vector Search separates the index, which holds the indexed vectors and metadata for a given set of documents, from the endpoint, which is the serving compute that actually executes similarity queries against one or more indexes -- query throughput is a function of the endpoint's provisioned capacity, so scaling the endpoint increases how many queries can be served concurrently without touching what is indexed or how. Adding columns to the backing Delta table changes what metadata is available for filtering, not query throughput, and does nothing to increase the compute available to answer queries faster or more concurrently. Changing chunking size affects how documents were split when the index was built -- a data-preparation decision that influences retrieval precision and recall, not the serving capacity that determines how many queries per second the system can handle. Switching to an embedding model with more dimensions changes the semantic representation and typically increases compute cost per comparison; it is unrelated to throughput scaling and would, if anything, require a full index rebuild rather than simply increasing capacity. Exam framing: understanding the endpoint-versus-index distinction in Vector Search -- data versus serving compute -- is foundational to both building retrieval in Section 3 and configuring Vector Search endpoints in Section 4.