Historical meeting-minute chunks must be loaded into Cosmos DB for AI retrieval at city scale. What ingest approach fits?
Select an answer to reveal the explanation.
Short Explanation
Bulk ingest with staged RU is the moving truck for years of meeting minutes—load the Cosmos RAG store in planned waves instead of carrying one box a day through the portal.
Full Explanation
Historical meeting-minute chunks destined for Cosmos DB AI retrieval at city scale should be bulk-imported with throughput staging appropriate to the corpus. Bulk ingest APIs and planned RU increases (then scale-down) let the city load years of minutes efficiently without relying on interactive portal clicks. Partition-aware bulk loading keeps the RAG store ready for semantic retrieval after the historical backfill.
Inserting one document per day manually through the portal with no throughput planning cannot finish a multi-year corpus in useful time. Sending the entire corpus as a single oversized item that exceeds practical document limits fails size constraints and prevents chunk-level retrieval. Loading everything through a single unpartitioned container (in effect one logical partition) as volume grows creates hot partitions and RU bottlenecks.
Exam caveat: Cosmos practical item size limits and partition-key design still apply during bulk load—chunk the minutes and choose a partition key that spreads historical volume. Operational check: stage RU throughput for the bulk window, run bulk import of meeting-minute chunks, monitor throttling and failed ingest, verify item counts and partition distribution, then return throughput to steady-state levels before opening the assistant to production query load.