A housing authority rewrites a single policy chapter and needs the RAG index updated without rebuilding the entire corpus. Which vector-store practice best meets that need?
Select an answer to reveal the explanation.
Short Explanation
Don’t rebuild the whole library because one shelf got new binders. Incremental re-index refreshes just the changed chapter chunks so residents see the new policy without a full corpus rebuild.
Full Explanation
When a housing authority rewrites one policy chapter, the vector store should update with incremental re-index or sync so only affected chapter chunks change. That practice keeps the rest of the corpus online, shortens time-to-correct-answers for residents, and avoids expensive full rebuilds for localized edits. Incremental sync is the standard operational pattern for partial corpus change in RAG.
Deleting the whole vector index nightly regardless of what changed fails operationally—it creates unnecessary downtime risk and cost when only one chapter moved. Leaving embeddings unchanged and relying on the FM’s “memory” fails conceptually: the FM does not magically observe your rewritten chapter without retrieval updates. Retraining a new foundation model from scratch for one chapter edit fails because content refresh is not a full model-training event.
Exam caveat: Prefer incremental index maintenance for localized knowledge edits; full rebuilds and FM retrains are the wrong levers for a single chapter.
Operational check: detect chapter-level change sets from the CMS or document store, re-embed only those chunk IDs, verify old chapter vectors are removed or superseded, and spot-check resident answers citing the rewritten section within the SLA window.