- नवीनतम LLM की input token सीमा (context window) अब लाखों तक बढ़ गई है, लेकिन साधारण retrieval benchmark (Needle in a Haystack, NIAH) में ऊंचे स्कोर मिलने पर भी वास्तविक लंबे input में प्रदर्शन गिरना स्पष्ट रूप से मौजूद है
- शोधकर्ताओं ने 18 models पर विभिन्न प्रयोग किए, और केवल input length बढ़ाने को नियंत्रित करने पर भी प्रदर्शन में गिरावट और असंगत पैटर्न बार-बार दिखाई दिए
- प्रश्न-उत्तर समानता में कमी, distractor वाक्य जोड़ना, passage structure में बदलाव के अनुसार प्रदर्शन गिरने की गति तेज हो जाती है या अप्रत्याशित रूप से बदल जाती है
- संरचित context (तार्किक paragraph flow) को बनाए रखना भी उल्टा प्रदर्शन पर नकारात्मक असर डाल सकता है, यानी input की arrangement और format का LLM प्रदर्शन पर बड़ा प्रभाव पड़ता है
- बहुत आसान काम, जैसे साधारण repeated text copy, में भी input length बढ़ने पर लगातार एकसमान परिणाम न दे पाने की सीमा सामने आई, जिससे वास्तविक उपयोग में context design (context engineering) के महत्व पर जोर पड़ता है
शोध की पृष्ठभूमि और उद्देश्य
- हाल के वर्षों में LLM का context window 10 लाख~1 करोड़ token तक बढ़ने के साथ, लंबे input पर भी “प्रदर्शन सुनिश्चित है” जैसी धारणा फैल गई
- Gemini 1.5 Pro, GPT-4.1, Llama 4 आदि इसके प्रतिनिधि उदाहरण हैं
- प्रमुख benchmark Needle in a Haystack(NIAH) केवल साधारण sentence retrieval तक सीमित है, इसलिए वास्तविक long-form document summarization या question answering जैसे जटिल कार्यों में प्रदर्शन गिरावट को ठीक से नहीं दर्शाता
- यह शोध केवल input length को बदलकर, जबकि task difficulty स्थिर रखी गई, प्रदर्शन में बदलाव का व्यवस्थित सत्यापन करता है
प्रमुख प्रयोग और परिणाम
- 18 आधुनिक LLMs (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen आदि) पर कुल 4 प्रकार के प्रयोग किए गए:
- प्रश्न-उत्तर (Needle-Question) semantic similarity में बदलाव
- distractor वाक्य जोड़ना
- passage (haystack) के विषय/संरचना में बदलाव
- repeated word copy (output length और input length दोनों का विस्तार)
- सभी प्रयोगों में input length बढ़ने के साथ प्रदर्शन तेजी से गिरा, और खासकर semantic similarity कम होने या distractor ज्यादा होने पर गिरावट और बड़ी हुई
- प्रश्न-उत्तर समानता जितनी कम होती है, लंबे input में गलत उत्तर का अनुपात उतनी तेजी से बढ़ता है
- सिर्फ एक distractor वाक्य जोड़ने पर भी accuracy तुरंत गिर जाती है, और 4 या उससे अधिक जोड़ने पर model के अनुसार confusion और hallucination बहुत बढ़ जाते हैं
- उदाहरण: Claude family गलत उत्तर देने की बजाय “सही उत्तर नहीं मिला” कहकर बचने की प्रवृत्ति अधिक दिखाती है, जबकि GPT family अधिक आत्मविश्वास के साथ गलत उत्तर देती है
- passage structure (logical flow / random arrangement) के अनुसार प्रदर्शन उलट जाने जैसी असामान्य घटना भी देखी गई
- तार्किक प्रवाह बनाए रखने वाले मूल (Original) passage में उल्टा model performance और खराब हुआ
- बेतरतीब ढंग से shuffled sentences वाले passage में उल्टा retrieval performance अधिक रहा
- repeated word copy experiment में भी input और output token बढ़ने के साथ गलतियां, task refusal, और मनमाने शब्द उत्पन्न होने जैसे अप्रत्याशित पैटर्न बढ़े
- उदाहरण: 2,500~5,000 शब्दों के बाद कुछ models में copy से इनकार, random text generation जैसी असामान्य प्रतिक्रियाएं तेजी से बढ़ीं
LongMemEval: वास्तविक उपयोग जैसा दीर्घ संवाद मूल्यांकन
- वास्तविक conversation history शामिल करने वाले LongMemEval benchmark में focused input (केवल सही उत्तर से संबंधित भाग) और full input (सही उत्तर से असंबंधित context सहित) की तुलना की गई
- सभी models में focused input ने कहीं अधिक accuracy दिखाई, जबकि full input में संबंधित सामग्री ढूंढना ही एक अतिरिक्त task बन गया और प्रदर्शन काफी गिर गया
- Claude family models में खासकर अस्पष्ट स्थितियों में “कोई सही उत्तर नहीं” कहकर बचने की प्रवृत्ति स्पष्ट रही
अतिरिक्त विश्लेषण और निहितार्थ
- distractor-वार confusion rate, answer position accuracy, random word generation position जैसे model-विशिष्ट internal behavior patterns का विभिन्न graphs से सूक्ष्म विश्लेषण किया गया
- repeated word copy experiment में, सही शब्द जितना आगे की ओर स्थित होता है, accuracy उतनी अधिक होती है जैसी position-dependent विशेषताएं भी मिलीं
- context design (सूचना की arrangement, logical flow management आदि) का model performance पर प्रभाव बहुत बड़ा है, इसलिए वास्तविक service deployment में सिर्फ context window बढ़ाने से स्थिर प्रदर्शन की उम्मीद नहीं की जा सकती
निष्कर्ष
- LLM की long-input processing क्षमता केवल benchmark score से सुनिश्चित नहीं होती, और वास्तविक input length बढ़ने मात्र से भी असंगत प्रदर्शन गिरावट दिखाई देती है
- संबंधित जानकारी को सिर्फ शामिल कर देना पर्याप्त नहीं है; जानकारी की arrangement, structure, distractor, और similarity सभी प्रदर्शन पर निर्णायक प्रभाव डालते हैं
- LLM के उपयोग में long-context management और design (context engineering) अनिवार्य है
2 टिप्पणियां
2.5 आए हुए भी काफ़ी समय हो गया है, फिर 1.5 क्यों?
Hacker News की राय
मेरा भी अनुभव कुछ ऐसा ही रहा है। खासकर Gemini Pro इस्तेमाल करते समय, अगर लंबे टेक्स्ट रेफ़रेंस दिए जाएँ, तो कई दस्तावेज़ों को एक साथ context window में डालने के बजाय पहले हर दस्तावेज़ का सारांश बनाकर सवाल पूछना, और ज़रूरत पड़ने पर बाद में पूरी डिटेल दस्तावेज़ों को RAG स्टाइल या किसी साधारण agent loop के ज़रिए देना, कहीं बेहतर जवाब देता था। इसी तरह Claude Code को Opus या Sonnet के साथ इस्तेमाल करते समय भी मैंने सीधे देखा है कि जितना ज़्यादा compaction होता है, नतीजे उतने खराब हो जाते हैं। यह सारांश की गुणवत्ता गिरने की वजह से है या context window में कम प्रासंगिक डेटा का अनुपात बढ़ने से, यह साफ़ नहीं है, लेकिन अगर context साफ़ करके सिर्फ़ relevant files दोबारा पढ़ने को कहा जाए, तो नतीजे बहुत बेहतर आते थे, भले ही वे पहले के सारांश में पहले से उल्लेखित हों
Gemini chat context की सीमा तक पहुँचने से पहले ही consistency और reasoning में टूटने लगता है। फिर भी इस रिपोर्ट के मुताबिक कई मायनों में यह टॉप मॉडल है। निष्कर्ष यही है कि context engineering अब भी महत्वपूर्ण है, और RAG approach अब भी वैध है
क्या "compaction" आख़िरकार transcript को summary में छोटा करना ही नहीं है? अगर ऐसा है, तो performance गिरना स्वाभाविक है, क्योंकि जानकारी वास्तव में खो रही है। लेकिन यह context rot की वजह से नहीं है। context rot का असली संकेत auto-compact threshold के पास पहुँचते समय दिखना चाहिए। क्या मैं सही समझ रहा हूँ?
एक आदर्श coding agent शायद यह सब अपने-आप कर दे। ज़रूरी code, MCP responses, repo map वगैरह इकट्ठा करे, बीच-बीच में उनका सारांश बनाए, और सबको नए chat messages में मिलाकर सिर्फ़ वही रखे जो सच में ज़रूरी है। मैं पहले से aider नाम के टूल के साथ कुछ ऐसा ही तरीका इस्तेमाल कर रहा हूँ, और जहाँ बहुत context चाहिए होता है वहाँ यह agentic या automated workflow की तुलना में काफ़ी बेहतर चला। बस, इसमें हाथ का काम बहुत है
क्या आपने NotebookLM इस्तेमाल किया है? यह app बैकग्राउंड में दस्तावेज़ों को chunk और summarize करता है, और RAG के ज़रिए पूरे दस्तावेज़ से chat-style सवाल पूछने देता है
मैंने Cursor में भी देखा है कि किसी नए feature या code changes पर जितनी देर बात करते जाओ, आउटपुट उतना खराब होता जाता है। सबसे अच्छे नतीजे तब मिले जब पहले साफ़ और specific instructions तथा plan बनाया, और जिन files को बदलना था उन्हें सीधे context prompt में खींचकर डाल दिया
"Explore → plan → code → test → commit" flow में काम करना काफ़ी ज़्यादा मददगार रहा। ज़रूरत हो तो हर चरण पर context clear करके असर बढ़ाया जा सकता है
किसी खास task के लिए पर्याप्त जानकारी इकट्ठी हो जाए, तब मैं उस समय का context सेव कर लेता हूँ। अगर quality गिरती दिखे, तो अब तक के काम का फिर से सारांश बनाकर उसे पिछले checkpoint में जोड़ देता हूँ
यह phenomenon काफ़ी जाना-पहचाना है, लेकिन इसका ठीक से documentation बहुत कम है, इसलिए यह लेख देखकर बहुत अच्छा लगा। मुझे लगता है कि benchmark से आसानी से मापना मुश्किल होने के बावजूद इसका practical impact कहीं बड़ा है। सच में उपयोगी LLM-based apps वहीं काम आते हैं जहाँ मॉडल अपनी क्षमता की सीमा के पास होता है। यानी जब किसी वास्तविक सवाल या task में context को logical रूप से कई बार "jump" करना पड़ता है, तब इसकी अहमियत बढ़ती है। और जितने ज़्यादा logical "jump" चाहिए हों, context rot की समस्या उतनी ही विस्फोटक रूप से बढ़ती है, क्योंकि हर jump पर ध्यान रखने वाली चीज़ों की संख्या बढ़ जाती है
context को आसानी से काटने का कोई अच्छा तरीका ज़रूरी है। अगर मैं मॉडल और पूरी बातचीत को सीधे manage कर पाता, तो शायद लगभग 2 लाख tokens की coding session से बहुत बेहतर performance निकाल पाता। लेकिन असलियत यह है कि अच्छा instance होने पर भी लगभग 20,000 tokens के बाद मॉडल अजीब होने लगता है, और session भी पूरी तरह rot हो जाती है। काश इस हिस्से को बस काटकर हटाया जा सकता
local LLM में आप अपनी मर्ज़ी से context edit कर सकते हैं, इसलिए अगर LLM के जवाब को ही बदलकर रख दिया जाए, तो बाद में मॉडल यह मान सकता है कि उसने शुरुआत में वही कहा था। इस वजह से उसे अपनी इच्छित दिशा में ले जाना आसान हो जाता है। दूसरी तरफ़ LLM-as-a-service मॉडल ऐसी सुविधा नहीं देते, क्योंकि इससे censorship bypass करना बहुत आसान हो जाएगा
मैंने यह प्रयोग किया कि, "Hey Claude, मैं अब context reset करने वाला हूँ, आगे काम जारी रखने के लिए मेरे लिए एक prompt बना दो।" फिर Claude के सुझाए prompt को पहले देखकर, थोड़ा सुधारकर, दोबारा डाला
अगर पिछले checkpoint पर आसानी से rollback किया जा सके, तो वह सच में कमाल का feature होगा
ज़्यादातर CLI agents में /compress command से यह किया जा सकता है
Claude code इस्तेमाल करते-करते यह धीरे-धीरे अपनी गलतियों और मेरे निर्देशों में फ़र्क करना बंद कर देता है। जब यह उलझना शुरू करे, तो नया session खोलना ही सही जवाब है। session जितना लंबा होता है, यह उतना ही एक ही loop में फँसता है या फिर ज़ोर देकर कहता है कि test पहले से ही broken हैं और उन्हें ignore कर देता है, जबकि असल में वे इसी session में टूटे होते हैं। शायद गलती मेरे prompt की हो, लेकिन आजकल Claude जैसे अचानक 30 IQ कम हो गया हो ऐसा लगता है
मुझे भी बिल्कुल यही महसूस हुआ है। Max plan पर भी performance कभी अच्छी होती है, कभी साफ़ तौर पर खराब
यह सोचना कि "शायद मेरे prompt और context में ही समस्या है", हम सबके भीतर बैठी gaslighting जैसा लगता है
यह information retrieval समस्या का एक प्रकार है, लेकिन मुझे लगता है कि context length बदलने से performance degradation साधारण retrieval सवालों से अलग तरह से काम कर सकता है। उदाहरण के लिए, “इस button को लाल कैसे करें?” जैसे सवाल, या “ऊपर के वाक्य किस category में आते हैं?” जैसी समस्याएँ अलग व्यवहार कर सकती हैं। एक पुराना प्रभावशाली पेपर Many-Shot In-Context Learning था। इस शोध में दिखाया गया कि context को examples से भरने पर performance काफ़ी बढ़ सकती है। आख़िरकार हर समस्या पर सीधे परीक्षण करना ही पड़ेगा, तभी पता चलेगा कि context की सामग्री और लंबाई के अनुसार LLM कैसे बदलता है। यह मान लेना सही नहीं कि context लंबा होते ही performance हमेशा गिरती है
यह बहुत cool और insightful लेख है। बस media literacy के नज़रिए से यह ध्यान रखना अच्छा होगा कि Chroma एक vectorDB कंपनी है
मैंने हाल ही में Gemini 2.5 Flash के साथ कई लंबी novels लिखीं, और context rot साफ़ महसूस हुई, लेकिन इस लेख में बताए गए बिंदु से काफ़ी बाद में। मेरे मामले में लगभग 50,000 से 100,000 tokens के बाद ही शुरुआती context, जैसे output language, को नज़रअंदाज़ करना शुरू हुआ। शायद creative जैसे complex tasks में इसका असर मापना मुश्किल होता है या कम स्पष्ट होता है। फिर भी, बीच-बीच में छूटा हुआ context दोबारा दे दिया जाए, तो उपयोगी स्तर बना रहता है
मेरा अनुभव भी कुछ ऐसा ही था। एक प्रोजेक्ट के दौरान मैं वीडियो transcript search feature बना रहा था, और टेक्स्ट बहुत लंबा था। GPT 4.1 जैसे मॉडल का context window बड़ा होने के कारण मुझे लगा था कि RAG की ज़रूरत नहीं पड़ेगी, लेकिन खासकर छोटे models में अजीब behavior बार-बार दिखा। वे सवाल का ठीक से जवाब देने के बजाय पूरे content का summary भर दे देते थे
दिलचस्प रिपोर्ट है। सोच रहा हूँ कि क्या हर मॉडल के लिए कोई recommended context size जैसा कुछ है। यह जानने का कोई तरीका है या नहीं कि मेरे use case के लिए किस सीमा तक जाना ठीक रहेगा