A team configures an Amazon OpenSearch Service vector index to hold embeddings for a large municipal code corpus supporting a legal-research assistant. The embedding model produces 1,536-dimension vectors. Which configuration decision most directly affects whether retrieval works correctly?
Select an answer to reveal the explanation.
Short Explanation
Think of the vector dimension like a plug and socket — a 1,536-dimension embedding has to plug into a 1,536-dimension index field, or nothing connects no matter how well-built the rest of the system is. Rounding to a cleaner number like 1,024 doesn't make an index tidier, it makes the vectors it's supposed to hold not fit. Get the dimension and the matching distance metric right, and retrieval has a chance; get those wrong, and shard count or anything else you tune won't save it.
Full Explanation
A k-NN vector index in OpenSearch Service must be configured with a field dimension that exactly matches the embedding model's output size, because similarity search computes distances between vectors of the same length; a mismatched dimension causes indexing errors or forces silent truncation, breaking retrieval before any query is even run. The distance metric (cosine, Euclidean, dot product) and k-NN algorithm should also align with how the embedding model was trained and intended to be compared, since using an incompatible metric can rank semantically similar documents poorly even when the dimensions match. Rounding the dimension to a cleaner number assumes OpenSearch Service silently resizes vectors to fit, which it does not — a dimension mismatch is a configuration error, not an auto-adjusted convenience. Prioritizing shard count based on document volume addresses a scaling and performance concern, not retrieval correctness; a well-sharded index with the wrong vector dimension or distance metric still returns poor or broken results. Disabling k-NN search and relying on default text relevance scoring abandons semantic retrieval altogether, defeating the purpose of embedding the municipal code corpus in the first place. Scope note: if the embedding model is ever upgraded or swapped, the index needs to be rebuilt with the new dimension, not patched in place. Operational check: index a small test batch of embeddings and confirm a known query returns the expected top matches before scaling to the full corpus.