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?

A dual-index architecture 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. The 15-minute batch indexing fix is a pragmatic partial fix but doesn't achieve the 60-second requirement. The streaming indexing approach using a message queue (Kafka/SQS) 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. The retrieval-time freshness layer that supplements vector retrieval with a live SQL query for queries mentioning 'current,' 'today,' or 'latest' 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.