Exam-style
A Bedrock knowledge base sits on an OpenSearch Serverless vector search collection. Over four months the corpus has grown fourfold, with thousands of documents a day replaced rather than added. The p99 search latency has tripled, SearchOCU peaks at four of a maximum sixteen, every ingestion job succeeds, and recall on a fixed set of 200 probe questions has fallen from 96 to 88 per cent. What should the team do?
Reveal the answer
D. Build a fresh faiss HNSW index with m and ef_construction sized for the corpus as it stands, point a new knowledge base at it, and re-run a retrieve-only evaluation against the probe set
A vector store fails in three ways, each with its own metric. Capacity saturation shows in OCU usage against the maximum; four of sixteen leaves compute spare. Data quality problems show in failed ingestion jobs and document age; every job is green. That leaves index degradation, which nothing reports directly. Replacing documents leaves deleted vectors in their segments until a merge clears them, and the graph was built for a quarter of the present size, so latency climbs while recall falls. Force merge is not available on a Serverless collection, so the remedy is a new index sized for the corpus as it stands. UpdateKnowledgeBase will not change storageConfiguration, so the new index needs a new knowledge base. A retrieve-only evaluation job scores context relevance and context coverage. As for the rest: more OCUs address a shortage the metrics rule out; a lower numberOfResults cuts latency by retrieving less, pushing recall down; a new embedding model treats a scoring fault that would have shown from day one; raising ef_search adds work to every search on a system already too slow.
Q. p99 search latency has tripled on a knowledge base collection, search OCUs peak at four of sixteen, ingestion is green, and recall on a fixed probe set has gone from 96 to 88 per cent. What now?
A. Build a new index with HNSW parameters sized for today’s corpus, point a new knowledge base at it, and re-run the recall probe.
Why? A vector store fails in three ways. Capacity saturation reads on OCU usage against the maximum. Data quality problems read on ingestion failures and document age, which data quality validation processes catch. Index degradation reads on nothing by default, so performance monitoring for vector databases needs a recall probe: known-good passages, run on a timer, graphed beside latency. Here the first two are clean. Four months of churn leaves deleted vectors waiting on a merge, and the graph carries a neighbour count chosen for a quarter of the data, so latency climbs as recall falls. Force merge is not available on a Serverless collection, so automated index optimization routines mean a rebuild, behind a new knowledge base, when the probe crosses a threshold. The parameters the graph is built with are chosen once, against one corpus size, which also makes the store chosen at the start worth a second look.