BudgetMem (arXiv:2511.04919) is an architecture that lets large language models handle long documents by selectively remembering only salient information, rather than storing everything as traditional RAG systems do.
Key points
Motivation
- Processing 100K+ token contexts can require ~40GB of GPU memory, making long-context processing expensive.
- Conventional RAG stores all chunks indiscriminately, drowning in low-value content. BudgetMem instead asks: *what should be remembered?*
- Short docs (SQuAD v2.0, 237 tokens avg): F1 dropped 0.8011 → 0.7232 (−9.7%), only 15.5% memory savings — little benefit on short text.
- Long docs (200 synthetic academic papers, ~7200 tokens): F1 0.8123 → 0.8042 (−1.0%) while memory fell from 100% to 27.6% (72.4% savings); latency rose 20.8% (2.45s → 2.96s).
- Budget sweep: 10% budget → F1 0.6245; 30% budget → F1 0.8042 (sweet spot); 40% → 0.8156 with 60.1% savings; diminishing returns beyond 50%.
- Baselines (30% budget, long docs): random 0.6892, First-N 0.7254, Last-N 0.6734, TF-IDF-only 0.7689 vs. BudgetMem's full features at 0.8042 (+3.5 points over the best naive baseline).
- Strong for: long documents (5K+ tokens), structured content (papers, contracts), localized Q&A, hardware-constrained deployments (mobile, IoT, cost-sensitive cloud).
- Weak for: short documents, answers spanning multiple low-salience chunks, queries about appendices/footnotes, latency-critical real-time systems.
- Validation on real benchmarks (Qasper, GovReport, LongBench); learned write policies instead of hand-tuned weights; adaptive per-document budgets; multimodal salience scoring (tables, charts, code); human-in-the-loop evaluation.
- Use 30–40% budget on resource-constrained hardware for long texts; use full-context models below ~1K tokens.
- Zero-shot deployment works with hand-tuned feature weights; the whole pipeline runs on Google Colab Pro (~$10/month).
- [1] Alla, C. V. K., Gaddam, H. N., & Kommi, M. (2025). *BudgetMem: Learning Selective Memory Policies for Cost-Efficient Long-Context Processing in Language Models*. arXiv:2511.04919v1.
- [2] Borgeaud, S., et al. (2022). *Improving language models by retrieving from trillions of tokens*. ICML.
- [3] Lewis, P., et al. (2020). *Retrieval-augmented generation for knowledge-intensive NLP tasks*. NeurIPS.
- [4] Karpukhin, V., et al. (2020). *Dense passage retrieval for open-domain question answering*. EMNLP.
- [5] Raffel, C., et al. (2020). *Exploring the limits of transfer learning with a unified text-to-text transformer*. JMLR.
Architecture
1. What to write: A trainable "gatekeeper" computes a salience score per chunk from six features — entity density (SpaCy, weight 0.2), TF-IDF (0.2), positional bias toward start/end (0.15), numeric content (0.15), discourse markers (0.1), and presence of questions (0.1):Chunks are selected via TopK under a budget \(B\): \(S = \text{TopK}(\{s_i\}, K = B)\). 2. How to store: A dual-tier memory — episodic memory holds the 10–20 most recent chunks; semantic memory stores 80–120-token distilled summaries (Llama-3.2-3B LoRA summarizer) each tagged with a 768-dim embedding. 3. What to retrieve: A three-stage pipeline — hybrid dense + BM25 search (7:3 fusion) yields 40 candidates; a 300M-parameter cross-encoder reranks to 5–8 chunks; recent episodic memory is always appended. A ranking loss
trains the scorer to rank answer-bearing chunks above distractors. Summaries are trained with a multi-task loss (ROUGE-L content coverage + answerability).