LLM से कोड लिखवाकर 10 मिलियन टोकन पढ़वाना - RLM कैसे काम करता है

हर कुछ महीने किसी न किसी कंपनी की हेडलाइन आती है - “अब हमारा मॉडल 1 मिलियन टोकन सपोर्ट करता है,” “अब 2 मिलियन।” Gemini ने 10 मिलियन तक का दावा कर दिया। सुनने में लगता है कि बस context window बड़ी कर दो और सारी समस्याएँ खत्म। लेकिन असलियत कुछ और है।

बड़ी context window का मतलब यह नहीं कि मॉडल उस पूरी जानकारी को ठीक से समझ पा रहा है। यहीं पर RLM - Recursive Language Model - सामने आता है। यह एक ऐसा framework है जो LLM को कोड लिखने देता है ताकि वह खुद तय करे कि विशाल दस्तावेज़ों में से क्या पढ़ना है और क्या छोड़ना है।

Context Rot: बड़ी विंडो का असली मसला

Context rot एक सीधी-सी बात है - जितना ज़्यादा text आप context window में ठूँसते हैं, मॉडल की accuracy उतनी गिरती है। यह कोई theoretical समस्या नहीं है। Google का Gemini 10 मिलियन टोकन claim करता है, लेकिन रिसर्च बार-बार दिखाती है कि लंबे context में मॉडल बीच के हिस्से भूल जाता है, “Lost in the Middle” effect पैदा होता है, और जवाबों में hallucination बढ़ जाता है।

सोचिए - आपके पास 500 पेज की एक लीगल डॉक्यूमेंट है। आप पूरी कॉपी-पेस्ट करके LLM से पूछते हैं कि “clause 47(b) में liability cap क्या है?” मॉडल को पूरे 500 पेज प्रोसेस करने पड़ेंगे, जबकि जवाब शायद दो पैराग्राफ में है। यह बेकार है - slow भी, expensive भी, और गलत जवाब का risk भी ज़्यादा।

RAG (Retrieval-Augmented Generation) इसका एक जवाब है, लेकिन RAG में embedding quality और chunking strategy पर सब कुछ टिका होता है। अगर retrieval step सही chunk नहीं उठा पाया, तो बाकी pipeline बेकार है।

RLM बिल्कुल अलग सोच से चलता है: क्या हो अगर मॉडल खुद कोड लिखे जो data को explore करे, ज़रूरी हिस्सा निकाले, और तभी पढ़े जब ज़रूरत हो?

RLM का मूल विचार: Store in Python, Read via Code

RLM का core idea यह है कि पूरा document LLM की context window में नहीं डाला जाता। इसके बजाय, document को Python data structures (dictionaries, lists, strings) में store किया जाता है, और LLM को एक REPL environment दिया जाता है जहाँ वह Python कोड लिखकर उस data को selectively पढ़ सकता है।

यानी LLM अब एक passive reader नहीं है। वह एक active researcher बन गया है जो decide करता है कि कौन-सा हिस्सा explore करना है, कौन-सा skip करना है, और कब enough information मिल गई है।

यह बिल्कुल वैसा है जैसे कोई अनुभवी रिसर्चर किसी विशाल किताब को handle करता है - पहले index देखो, relevant chapter खोलो, सिर्फ़ काम के section पढ़ो, और बाकी छोड़ दो।

तीन Components: Orchestrator, LMHandler, Environment

RLM architecture तीन हिस्सों पर टिका है:

1. Orchestrator (ऑर्केस्ट्रेटर) यह पूरे system का coordinator है। यह decide करता है कि अभी किस phase में हैं - exploration, decomposition, aggregation, या termination। Orchestrator LLM और environment के बीच conversation manage करता है और हर step पर यह तय करता है कि आगे क्या करना है।

2. LMHandler (LM हैंडलर) यह LLM API से बात करता है। जब orchestrator को LLM से code generate करवाना होता है या किसी sub-question का जवाब चाहिए होता है, तो LMHandler यह call handle करता है। इसमें एक special function है - llm_query() - जो REPL के अंदर से callable है। यानी LLM अपने लिखे code के बीच में ही एक और LLM call कर सकता है, जैसे recursion में function खुद को call करता है।

3. Environment / REPL यह Python execution environment है जहाँ LLM का लिखा code actually run होता है। Document data यहीं stored है। LLM जो भी code लिखता है - data['section_3']['subsection_b'] या len(paragraphs) - वह यहीं execute होता है। और llm_query() function इसी environment में available है, जिससे LLM अपने code के अंदर से nested LLM calls कर सकता है।

Execution Flow: चार चरण

RLM एक structured loop में काम करता है:

Explore (खोजो)

LLM पहले data का structure समझने के लिए code लिखता है। जैसे - list(data.keys()) चलाकर देखता है कि document में कौन-कौन से sections हैं। यह किसी library में जाकर पहले catalog देखने जैसा है।

Decompose (तोड़ो)

अगर सवाल complex है, तो LLM उसे छोटे sub-questions में तोड़ता है। हर sub-question के लिए llm_query() call होती है - यानी एक नया mini-RLM session शुरू होता है जो independently उस sub-question का जवाब ढूँढता है। यहीं “Recursive” शब्द सार्थक होता है।

Aggregate (जोड़ो)

सभी sub-questions के जवाब आने के बाद, LLM उन्हें combine करके final answer बनाता है। यह सिर्फ़ concatenation नहीं है - मॉडल contradictions check करता है, missing pieces identify करता है, और एक coherent response तैयार करता है।

Terminate (रुको)

जब LLM को लगता है कि enough information मिल गई है और confident answer दिया जा सकता है, तो वह loop से बाहर आ जाता है। यह important है - बिना termination condition के system अनंत loop में फँस सकता है।

Ralph Wiggum Connection: नाम के पीछे की कहानी

RLM का नाम सुनकर शायद The Simpsons के Ralph Wiggum याद आ जाएँ - जो बार-बार “I’m in danger” कहता है। रिसर्चर्स ने यह नाम इसलिए नहीं रखा कि system बेवकूफ़ है, बल्कि इसलिए कि Ralph की तरह यह system भी recursively अपने आप से बात करता है। RLM में LLM खुद से सवाल पूछता है, खुद code लिखकर जवाब ढूँढता है, और फिर खुद evaluate करता है कि जवाब काफ़ी है या नहीं। यह self-referential loop ही इसकी ताकत है।

इसके अलावा, “Recursive Language Model” abbreviation RLM बनता है, जो Ralph Wiggum के catchphrase “Me fail English? That’s unpossible!” की spirit से मेल खाता है - एक ऐसा system जो theoretically “impossible” काम कर रहा है।

Practical Tips: RLM-style सोच अपने काम में कैसे लाएँ

आपको RLM का पूरा framework implement करने की ज़रूरत नहीं। इसके principles आज ही काम आ सकते हैं:

Context window में सब कुछ मत डालो। अगर आप किसी बड़े codebase के बारे में LLM से सवाल पूछ रहे हैं, तो पहले directory structure दो, फिर relevant files माँगो, फिर specific functions पर focus करो। यही RLM का Explore-Decompose pattern है।

LLM को tool access दो। Claude Code, Cursor, Aider - ये सब tools LLM को file system access देते हैं। यह RLM का simplified version है। मॉडल खुद decide करता है कि कौन-सी file पढ़नी है।

बड़े सवालों को छोटे हिस्सों में तोड़ो। “इस पूरे codebase का review करो” के बजाय “पहले architecture समझो, फिर security issues ढूँढो, फिर performance bottlenecks identify करो” - यह decomposition LLM को बहुत बेहतर results देता है।

llm_query() जैसा pattern अपनाओ। अगर आप multi-agent systems बना रहे हैं, तो sub-agents को nested LLM calls करने दो। एक agent research करे, दूसरा analyze करे, तीसरा synthesize करे। यही RLM की recursive spirit है।

निष्कर्ष: Context Window Race ग़लत दिशा है

AI industry में context window size की race चल रही है - 128K, 1M, 10M। लेकिन RLM हमें याद दिलाता है कि असली सवाल यह नहीं कि कितना data एक बार में ठूँसा जा सकता है, बल्कि यह है कि कितनी intelligently data को access किया जाता है।

इंसान भी ऐसे ही काम करते हैं। कोई भी researcher पूरी library एक बार में नहीं पढ़ता। वह search करता है, relevant material ढूँढता है, selective reading करता है, और synthesize करता है। RLM ने LLM को बिल्कुल यही capability दी है - code के ज़रिए।

सबसे दिलचस्प बात यह है कि RLM मौजूदा LLMs के ऊपर काम करता है। इसके लिए किसी नए मॉडल की ज़रूरत नहीं। बस एक smarter orchestration layer चाहिए जो मॉडल को passive reader से active researcher में बदल दे। और यही आने वाले AI tools का direction है - बड़ी memory नहीं, बेहतर strategy।