Context
The bounded lazy snapshot and streaming scorer fix the current production failure mode for namespaces of roughly 60,000 chunks, while preserving retrieval quality. A real local 600,000-row PostgreSQL corpus still takes about 112 seconds to load and 64 seconds to score, with peak RSS around 646 MiB.
Problem
Map-nav retrieval is not yet suitable for substantially larger namespaces because the full snapshot index and repeated section queries still make total request latency and memory grow too far.
Required outcome
- Support at least 600,000 chunks within the production request and database timeout budgets.
- Reduce snapshot/index memory and total retrieval latency, measured against the reproducible local PostgreSQL corpus.
- Preserve retrieval quality exactly: BM25 channels, weights, RRF scoring, tie-breaking, selected sections, and hydrated evidence must remain parity-equivalent to the current implementation.
- Add contract coverage for result parity, query count/latency bounds, and memory-relevant bounded loading.
Baseline evidence
- 100 documents / 600,000 chunks.
- Snapshot load: 111.5s.
- Scoring: 64.1s.
- Total: 175.6s.
- Peak RSS: 645.7 MiB.
- Existing 60k eager/lazy parity test: identical map and unit scores.
Scope ideas
Investigate a compact reference index, fewer batched SQL round trips, and database/index plans before changing ranking or candidate selection. Any optimization must include an exact quality-parity comparison.
Context
The bounded lazy snapshot and streaming scorer fix the current production failure mode for namespaces of roughly 60,000 chunks, while preserving retrieval quality. A real local 600,000-row PostgreSQL corpus still takes about 112 seconds to load and 64 seconds to score, with peak RSS around 646 MiB.
Problem
Map-nav retrieval is not yet suitable for substantially larger namespaces because the full snapshot index and repeated section queries still make total request latency and memory grow too far.
Required outcome
Baseline evidence
Scope ideas
Investigate a compact reference index, fewer batched SQL round trips, and database/index plans before changing ranking or candidate selection. Any optimization must include an exact quality-parity comparison.