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, sync the knowledge base into it, and schedule a retrieve-only evaluation job against the fixed question set
A vector store fails in three ways, each with its own metric. Capacity saturation shows in OCU usage against the maximum, and four of sixteen leaves compute spare. Data quality problems show in failed ingestion jobs and rising 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 with parameters chosen at 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 built for the corpus as it stands, then a full sync into it. Bedrock retrieve-only evaluation jobs make the probe set a scheduled measurement. As for the rest: more OCUs address a shortage the metrics rule out; a lower numberOfResults cuts latency by retrieving less, pushing recall further 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 whose symptom is latency.
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, sync into it, and schedule the recall measurement.
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 when the probe crosses a threshold. The parameters the graph is built with are set once against a corpus size, and a fourfold corpus has outrun them, which is why the store chosen at the start is worth a second look.