A library open-data bot needs grounded answers from Cosmos DB items that include both chunk text and embeddings. How should each item be modeled?
Select an answer to reveal the explanation.
Short Explanation
Keep the recipe card with the dish—chunk text and its embedding ride in the same Cosmos item so the open-data bot can retrieve meaning and still cite the actual library wording.
Full Explanation
For civic retrieval-augmented generation (RAG) on Azure Cosmos DB for NoSQL, each item should commonly hold both the source chunk text and its embedding vector in the same document. That co-location lets similarity search return not only a nearby vector but also the exact library open-data wording needed to ground the bot’s answer and cite the municipal source. Without the chunk text beside the embedding, the open-data assistant can find “similar meaning” but cannot reliably quote or attribute the underlying library material.
Keeping only the embedding and discarding the source chunk after the first index build fails grounding: vectors support ranking, not readable citations. Storing embeddings as image attachments without linking them to any library document text breaks the retrieval contract—there is no traversable path from similarity hit to the prose residents expect. Putting every library chunk into a single unpartitioned JSON file on a public share ignores Cosmos partitioning, RU accounting, access control, and scale; it is not a production municipal data model for grounded answers.
Exam caveat: Cosmos items can store arrays of floats as embedding properties; the exam focus is the modeling pattern (chunk + embedding together for grounded retrieval), not a specific vector dimension count. Operational check: after ingest, sample retrieval hits and verify each returned item includes usable chunk text, a stable document or chunk id for citation, and an embedding whose dimension matches the embedding model; reject any pipeline that indexes vectors without retaining the corresponding open-data text.