A 311 team is building a semantic-search assistant over historical service-request text and needs to select an embedding model to convert that text into vectors for retrieval. Which consideration should most directly guide this embedding-model selection?

Embedding-model selection should be driven by whether the model's training domain fits the target text — a model trained broadly on general web text may represent municipal service-request jargon less precisely than one better suited to that register — combined with whether its output dimensionality matches the vector store's index configuration, and ultimately validated by testing retrieval quality against representative real queries rather than assumed on paper. Assuming larger output dimensionality means better semantic accuracy ignores that dimensionality is a design tradeoff: higher dimensions increase storage and compute cost and don't automatically improve retrieval quality for a given domain, and some smaller models outperform larger ones on domain-specific text. Optimizing for the least preprocessing effort inverts the priority for a search assistant, where retrieval relevance is the feature users actually depend on; preprocessing convenience is a secondary engineering concern, not the deciding factor. Treating Bedrock's embedding models as interchangeable ignores that different foundation models are trained differently and produce vector spaces with meaningfully different retrieval characteristics for the same input text — swapping models without validation can silently degrade search quality. Scope note: once a model is chosen, the whole corpus must be re-embedded consistently; mixing vectors from two different embedding models in one index breaks similarity comparisons. Operational check: run a small set of known representative 311 queries through candidate embedding models and compare retrieved results against expected relevant records before committing to one.