A city RAG store keeps ordinance chunk embeddings in Azure Cosmos DB for NoSQL for the permits bot. How should the back end retrieve nearest neighbors?
Select an answer to reveal the explanation.
Short Explanation
For your permits bot, store ordinance chunk embeddings in Cosmos DB and use vector similarity search to retrieve the nearest chunks. That gives you semantic matches; alphabetical string sorting, nightly CSV spreadsheet filters, and a Word-document folder without embeddings do not.
Full Explanation
Store ordinance chunk embeddings in Azure Cosmos DB for NoSQL and run vector similarity search to retrieve the nearest chunks for the permits bot. This is the right approach for RAG because the query can rank ordinance passages by embedding similarity and provide relevant chunks to ground the bot’s response. Storing embeddings only as plain strings and sorting them alphabetically fails because alphabetical order does not measure vector similarity or find semantically related passages. Exporting the entire container to CSV nightly and searching with spreadsheet filters fails because that process is offline and does not perform Cosmos vector retrieval. Replacing Cosmos DB with a shared folder of Word documents and no embeddings fails because it removes both the embeddings and vector-based nearest-neighbor search. Exam caveat: embeddings must be stored and indexed appropriately in Cosmos, and the vector dimensions and distance metric must match the embedding model. Vector retrieval alone does not guarantee correct legal answers; authorization, chunk quality, and grounding validation still matter. Practical check: insert ordinance chunks with embeddings, run a vector similarity query for a sample permit question, verify the returned passages are relevant, and measure RU consumption and latency under expected query load.