A RAG system for financial services processes real-time market data alongside static regulatory documents. The static corpus (200K documents) is indexed in a persistent vector store. Real-time data (current prices, recent filings) arrives continuously and must be queryable within 60 seconds of arrival. The current architecture indexes new documents in batch every 4 hours, causing a 4-hour knowledge gap for time-sensitive financial queries. What architectural pattern best achieves near-real-time RAG while maintaining stable retrieval quality for the static corpus?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — a dual-index architecture (persistent + hot index) is the production-correct pattern for mixed static/dynamic corpus RAG. The static corpus benefits from offline-optimized ANN indexes (HNSW, IVF-PQ) that are built once and provide fast, high-quality retrieval.
Full explanation below image
Full Explanation
A dual-index architecture (persistent + hot index) is the production-correct pattern for mixed static/dynamic corpus RAG. The static corpus benefits from offline-optimized ANN indexes (HNSW, IVF-PQ) that are built once and provide fast, high-quality retrieval. These indexes are expensive to rebuild incrementally — upserts to HNSW indexes are slow and degrade index quality. The hot index for recent documents (last 24 hours) can use simpler, faster-updating storage (brute-force similarity for a small document set, or a streaming-compatible index). Query fan-out to both indexes merges results before reranking, giving the freshness of the hot index with the quality of the optimized static index. Option C (streaming indexing to a single index) is correct about achieving sub-minute ingestion latency but continuous upserts to a large ANN index (200K documents) degrade index quality and retrieval performance over time — this is why production systems separate static and dynamic indexes. Option A (15-minute batch) is a pragmatic partial fix but doesn't achieve the 60-second requirement. Option D (SQL bypass for fresh queries) is a complementary pattern but not sufficient alone — many time-sensitive financial queries don't contain trigger words, and SQL full-text retrieval lacks semantic ranking quality.