A transit agency stores alert embeddings in Cosmos DB for NoSQL and must meet semantic retrieval SLAs for the rider-info bot. What should the team configure?
Select an answer to reveal the explanation.
Short Explanation
Think of the vector index as the transit map index for meaning—Cosmos can jump to nearby alert embeddings fast instead of reading every stop announcement by hand.
Full Explanation
Azure Cosmos DB for NoSQL supports vector indexes on embedding properties so nearest-neighbor retrieval can meet latency and relevance SLAs for municipal generative workloads such as a transit rider-info bot. When alert embeddings live in Cosmos, configuring a vector index on the embedding path lets the service jump to semantically nearby alerts instead of scanning every document for each rider query. That design keeps request-unit consumption predictable and aligns retrieval quality with the agency’s published response-time targets for disruption and service notices.
Storing alert text only as plain strings and relying on full container scans fails the SLA concept: text scans are not vector similarity search, they burn RUs linearly with corpus size, and they cannot rank meaning the way embeddings do. Disabling all indexing so vector similarity never consumes RUs removes the very structures Cosmos needs for efficient retrieval; it trades temporary RU savings for unbounded query cost and missed SLAs. Moving every alert embedding into browser localStorage abandons a durable, shared data plane—rider devices cannot host the agency corpus, cannot enforce municipal access controls, and cannot satisfy multi-user semantic retrieval.
Exam caveat: vector indexing and vector search capabilities in Cosmos DB for NoSQL are version- and feature-flag dependent; associate scenarios expect you to choose the vector-index path when the stem emphasizes embeddings and semantic SLAs, not classic SQL text search alone. Operational check: confirm the embedding path is covered by the vector index policy, validate approximate nearest-neighbor recall on a sample of rider queries, watch RU/s and p95 latency during peak commute windows, and gate production on those metrics before expanding the alert corpus.