A county's RDS-with-pgvector knowledge base backing its open-data assistant costs more to query than the team expects at its current configuration, and they want to bring per-query cost down. Which lever should they examine first?
Select an answer to reveal the explanation.
Short Explanation
A vector index is the difference between flipping through a card catalog and scanning every shelf by hand. Its configuration decides how much work each search does, which is exactly what shows up as query cost. Tune that knob before reaching for a bigger, pricier model.
Full Explanation
A vector index's configuration — index type, number of neighbors examined, and similarity-search parameters — directly determines how much compute each retrieval query performs, which is why it's the first lever to examine when per-query cost on a vector store climbs: tuning it trades a controlled amount of recall for a real reduction in compute per query. Pointing at the generation model instead skips over the retrieval layer entirely, and in a RAG pipeline the generation model's cost is a separate line item from the vector search that feeds it context. Claiming chunking strategy has no bearing on query-time compute is also wrong in spirit — chunking affects corpus size and retrieval quality, but even where it matters, it is not the lever this question asks about, since the team's stated problem is index configuration cost, not retrieval quality. IAM policy attachments govern access, not the compute cost of running a similarity search — permissions and pricing are unrelated dimensions of the same service. Scope caveat: any index change that reduces recall should be validated against a retrieval-quality benchmark before rolling it out broadly, since cheaper queries that return worse context aren't actually a win. Operational check: compare average query latency and cost before and after a configuration change on a representative query sample.