रिकर्सिव लैंग्वेज मॉडल (Recursive Language Models)

• बड़े लैंग्वेज मॉडल (LLM) को बहुत लंबे इनपुट प्रॉम्प्ट प्रोसेस करने में सक्षम बनाने के लिए नई reasoning strategy RLM (Recursive Language Model) प्रस्तावित की गई है
• RLM लंबे प्रॉम्प्ट को बाहरी environment के एक हिस्से के रूप में मानता है, और मॉडल को उन्हें programmatically खोजने, विभाजित करने और recursively call करने की अनुमति देता है
• यह तरीका मौजूदा context window limits से आगे बढ़कर अधिकतम करोड़ों tokens के स्तर तक के इनपुट को प्रोसेस करता है, और मौजूदा LLM की तुलना में गुणवत्ता को काफी बेहतर बनाता है
• प्रयोगों के नतीजों में, GPT-5 और Qwen3-Coder आधारित RLM ने विभिन्न long-context tasks में दो अंकों का performance improvement दिखाया, जबकि लागत समान या उससे कम रही
• इसे long-context processing की सीमाओं को पार कर LLM की reasoning क्षमता को बड़े पैमाने पर विस्तारित करने वाले सामान्य approach के रूप में आंका गया है

---

RLM का अवलोकन

• Recursive Language Model (RLM) को इस तरह डिज़ाइन किया गया है कि LLM लंबे इनपुट को सीधे neural network में डालने के बजाय, उसे बाहरी environment के variables की तरह मानकर उसके साथ interact करे
  • इनपुट प्रॉम्प्ट P को Python REPL environment के एक variable के रूप में लोड किया जाता है, और LLM उसे code के ज़रिए explore, decompose और recursively call करता है
  • LLM REPL environment की state (जैसे: string length) को पहचानता है, code execution के side effects को observe करता है, और धीरे-धीरे समस्या हल करता है
• यह संरचना मौजूदा context compaction या summary-based approaches में विवरण खो जाने की समस्या को हल करती है
• RLM को ऐसे सामान्य reasoning paradigm के रूप में प्रस्तुत किया गया है जो इनपुट और आउटपुट दोनों की लंबाई बढ़ा सकता है

मौजूदा approaches की सीमाएँ

• मौजूदा LLM, context window limits के कारण लंबे इनपुट में प्रदर्शन के तेज गिरने वाली context rot समस्या दिखाते हैं
• context compaction तकनीकें एक निश्चित लंबाई के बाद summarization को दोहराती हैं, लेकिन ऐसे tasks जिनमें बारीक जानकारी तक पहुंच ज़रूरी हो उनके लिए उपयुक्त नहीं हैं
• RLM प्रॉम्प्ट को बाहरी object की तरह संभालकर इनपुट आकार को मॉडल की सीमाओं से आगे बढ़ा सकता है

प्रयोग सेटअप

• मूल्यांकन मॉडल: GPT-5 (OpenAI, 2025) और Qwen3-Coder-480B-A35B (Team, 2025)
• तुलना के लिए:
  • बेसिक LLM direct call
  • Summary agent
  • CodeAct + BM25 retrieval-based agent
  • RLM (REPL environment सहित) और RLM (REPL, recursive calls के बिना)
• GPT-5 प्रयोगों में recursive calls के लिए GPT-5-mini और root model के लिए GPT-5 का उपयोग किया गया, ताकि performance और cost का संतुलन बना रहे

मूल्यांकन tasks

• S-NIAH: एकल ‘needle-in-a-haystack’ समस्या, जिसमें इनपुट लंबाई से अलग processing cost स्थिर रहती है
• BrowseComp-Plus: कई दस्तावेज़ों में जाने वाला multi-hop question answering task, जिसमें 1000 दस्तावेज़ों में सही उत्तर शामिल होता है
• OOLONG: ऐसा long-context reasoning task जिसमें इनपुट की लगभग सभी items को semantic रूप से transform और integrate करना पड़ता है, और processing cost इनपुट लंबाई के साथ रैखिक रूप से बढ़ती है
• OOLONG-Pairs: OOLONG का एक variant, जिसमें जोड़ी-स्तरीय जानकारी का संयोजन ज़रूरी है और processing cost इनपुट लंबाई के वर्ग के अनुपात में बढ़ती है
• LongBench-v2 CodeQA: code repository की समझ मांगने वाला multiple-choice task, जो नवीनतम मॉडलों के लिए भी कठिन है

प्रमुख परिणाम

• RLM में GPT-5 की तुलना में लंबे context पर भी प्रदर्शन में लगभग कोई गिरावट नहीं दिखी
  • GPT-5 में इनपुट लंबाई और task complexity बढ़ने पर प्रदर्शन तेज़ी से गिरा
  • RLM ने 272K token सीमा से बड़े इनपुट (अधिकतम 10M+ tokens) को भी प्रभावी ढंग से प्रोसेस किया
• सभी long-context tasks में RLM ने अन्य तरीकों की तुलना में दो अंकों का performance improvement दिखाया
• cost efficiency भी बनी रही, और प्रति query लागत मौजूदा approaches के समान या उससे कम रही

long-context tasks का complexity analysis

• LLM की व्यावहारिक context window भौतिक सीमा से भी task complexity के अनुसार और छोटी हो सकती है
  • सरल NIAH समस्या 1M+ tokens पर भी हल की जा सकती है
  • जटिल OOLONG-प्रकार के tasks में इससे कहीं कम लंबाई पर भी प्रदर्शन गिरने लगता है
• इसलिए task की information density और input length के संबंध को साथ में देखना ज़रूरी है

निष्कर्ष

• RLM, LLM की reasoning क्षमता को recursively विस्तारित करके ऐसे अत्यंत लंबे इनपुट को संभालने में सक्षम बनाता है जिन्हें मौजूदा मॉडल प्रोसेस नहीं कर सकते
• प्रॉम्प्ट को environment object की तरह मानने वाला डिज़ाइन इसकी मुख्य नवाचार है, जो long-context processing की संरचनात्मक सीमाओं को हल करता है
• इसे विभिन्न मॉडलों और tasks में performance, cost और scalability का संतुलन हासिल करने वाले सामान्य reasoning framework के रूप में प्रस्तुत किया गया है

[GN⁺]

Hacker News की राय

• यह बस subagent की अवधारणा जैसा लगता है
  यानी दूसरे LLM को बुलाकर फ़ाइलें पढ़वाना और ज़रूरी जानकारी निकलवाना, ताकि main context अनावश्यक रूप से जटिल न हो
  आइडिया अच्छा है, लेकिन पूरी तरह नया नहीं है

  • मैं इसे इंसानों जैसी मानवीकृत subagent अवधारणा से ज़्यादा context management के साधन के रूप में देखता हूँ
    अभी Scope प्रोजेक्ट में observable subagent के ज़रिए काम को recursive तरीके से तोड़ने का प्रयोग चल रहा है
    लेकिन इस planning stage evaluation को कैसे बेहतर किया जाए, यह समझ नहीं आ रहा
    हम markdown फ़ाइलों में heuristics दर्ज करते हैं, लेकिन संरचना ढीली होने की वजह से मापना मुश्किल है
    अगर किसी को संबंधित literature या project पता हो, तो बताना अच्छा होगा
  • पेपर में इसे इस तरह कहा गया है
    RLM न तो agent है, न ही summary
    एक ही system में कई LM calls का इस्तेमाल कोई नई अवधारणा नहीं है, और यही ज़्यादातर agentic scaffold करते हैं
    सबसे मिलता-जुलता उदाहरण ROMA agent है, जो समस्या को तोड़कर कई sub-agent से हल करता है
    साथ ही Cursor या Claude Code जैसे code assistants भी context लंबा होने पर उसे summarize या prune करते हैं
    ऐसे approaches आम तौर पर task units में decomposition करते हैं, लेकिन RLM context-unit decomposition पर ज़ोर देता है, और उसका चुनाव LM को ख़ुद करना चाहिए
  • शीर्षक से ऐसा लगता है मानो पूरा computation differentiable हो और एक ही model के रूप में train किया गया हो, लेकिन असल में यह बस model को बार-बार call करने जैसा दिखता है
  • अगर subagent किसी दूसरे subagent को अनंत रूप से call नहीं कर सकता, तो उसे recursive नहीं कहा जा सकता
  • लगता है यह ऐसे sub-agent की अवधारणा की बात कर रहा है जो उसी context (file system या REPL variables) तक पहुँच और उस पर काम कर सके

• मुख्य insight यह है कि लंबे prompt को सीधे neural network (Transformer) में डालने के बजाय, उसे ऐसे environment के हिस्से की तरह देखना चाहिए जिसके साथ LLM प्रतीकात्मक रूप से इंटरैक्ट कर सके
  लेकिन फिर सवाल है कि यह मूल रूप से RAG से अलग कैसे है
  figure 4 को देखकर लगता है कि फ़र्क सिर्फ़ इतना है कि retrieval mechanism इंसान नहीं, बल्कि LLM ख़ुद implement करता है

  • मेरे हिसाब से इसमें दो फ़र्क हैं
    1️⃣ RAG ज़्यादा workflow जैसा है, जबकि यह अधिक agentic है
    2️⃣ इसमें recursive structure है
    workflow में इंसान step-by-step flow डिज़ाइन करता है, लेकिन agentic approach में agent ख़ुद तय करता है कि क्या retrieve करना है, कितनी बार call करना है, और कब जवाब देना है
    उदाहरण के लिए Claude Code या Codex codebase को explore करते हुए फ़ाइलें पढ़ते हैं और ripgrep चलाते हैं
    इस तरह की recursive कोशिशें पहले भी हुई थीं (जैसे: babyagi, लगभग 2023), लेकिन उस समय model performance काफ़ी नहीं थी, इसलिए बहुत सारा glue code चाहिए होता था
    अब models इतने मज़बूत हो गए हैं कि ऐसी संरचना वास्तव में काम करती है

• “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down” वाला मज़ाक याद आता है, जो ऐसी संरचना का संकेत देता है जहाँ LLM लगातार दूसरे LLM को call करता रहता है

  • यह “attention is all you need” को बार-बार लागू करने जैसा है, और अंत में जिस चीज़ का हमें पीछा करना चाहिए, वह है precision

• इसका एक ज़्यादा पढ़ने-लायक संस्करण भी है: alexzhang13 का ब्लॉग पोस्ट

• 2026 के लिए मेरी इच्छा है कि Anthropic या OpenAI CLI plugin बनाने वालों को यह बताएँ कि “compaction कैसे execute होता है”
  यह तकनीक Claude Code में built-in feature की जगह ले सकती है, लेकिन अभी उचित hook या functionality expose नहीं की गई है

  • अगर Codex open source है, तो क्या उसे सीधे पढ़कर नहीं देखा जा सकता?
    मैंने Gemini का source देखा था, और जब context window भर जाती थी तो वह पूरे context को summarize करने वाले एक साधारण prompt structure का इस्तेमाल करता था

• यह पेपर इससे मिलता-जुलता लगता है: arXiv:2510.14826