AI context क्या है? — 1M-token युग की "पढ़ता है लेकिन पढ़ता नहीं" वाली हक़ीक़त

2023 में, 32K-token का context window "विशाल" लगता था। आज शीर्ष model के लिए 10 लाख token (1M) श्रेणी का window एक मान ली गई बात है। सितंबर 2026 तक, Anthropic, OpenAI और Google — तीनों अपने शीर्ष model की आधिकारिक विशिष्टताओं में लगभग 10 लाख token की input सीमा बताते हैं। विशिष्ट model नाम और आँकड़े हर रिलीज़ के साथ बदलते हैं, इसलिए उन्हें मैं वर्तमान model और cutoff तिथियों की सूची तथा हर vendor के आधिकारिक पेजों पर छोड़ता हूँ। यह लेख उस पर केंद्रित है जो पीढ़ी बदलने पर भी काम आता है: आँकड़ों को कैसे पढ़ें, और उनके साथ कैसे काम करें।

"दस लाख token" मोटे तौर पर अंग्रेज़ी में 8–10 paperback किताबों, या दसियों हज़ार लाइन source code के बराबर है। अब हम एक ही session में इतना कुछ "दृष्टि में" रख सकते हैं। लेकिन किसी दस्तावेज़ का कंटेनर में समा जाना और model का उसे पूरा पढ़ पाना एक बात नहीं है। OpenAI अपने multi-needle long-context benchmark (MRCR) के जो score प्रकाशित करता है, वे दिखाते हैं कि एक ही model का score input लंबा होने के साथ गिरता है, और गिरावट कितनी होगी यह model और पीढ़ी के अनुसार बहुत बदलता है (§1 और §4 में विस्तार से)।

मैं अपनी राय शुरू में ही रख देता हूँ: केवल कंटेनर के आकार पर model चुनने का युग ख़त्म हो चुका है। जो मायने रखता है वह "प्रभावी context × लागत × देने का तरीका" की त्रयी है। यह लेख बताता है कि context वास्तव में क्या है, spec sheet कैसे पढ़ें, केवल बड़ा होना क्यों काफ़ी नहीं, अपने उपयोग के लिए प्रभावी सीमा कैसे मापें, लंबे input पर मूल्य कैसे उछलता है, और पाँच बचत रणनीतियाँ जिन्हें एकल डेवलपर और छोटी टीमें आज ही अपना सकती हैं — आधिकारिक आँकड़ों और प्रकाशित benchmark डेटा के साथ।

1. 1M समर्थन अब आम है — लेकिन "अंत तक पढ़ना" अलग बात है

पिछले दो वर्षों में 1M समर्थन तेज़ी से फैला। अप्रैल 2025 में OpenAI का GPT-4.1 लगभग 10.5 लाख token के साथ आया, अगस्त 2025 में Anthropic का Claude Sonnet 4 (beta में) 10 लाख token तक पहुँचा, और सितंबर 2026 तक Anthropic, OpenAI और Google के शीर्ष model सभी अपनी आधिकारिक विशिष्टताओं में लगभग 10 लाख token बताते हैं। 2023 में 32K विशाल लगता था — यानी केवल तीन वर्षों में 30 गुना से अधिक। कंटेनर के आकार की दौड़ पूरी होती दिख रही थी।

लेकिन जब आप वे long-context score देखते हैं जो कंपनियाँ ख़ुद प्रकाशित करती हैं, तो तस्वीर इतनी सरल नहीं रहती। लंबाई के हिसाब से पूरे परिणाम OpenAI के MRCR v2 (8 needle) में मिलते हैं। यह AI के साथ एक लंबी बातचीत में एक ही तरह के आठ अनुरोध छिपा देता है — जैसे "tapir पर एक कविता लिखो" — और फिर उनमें से ठीक एक को लौटाने को कहता है, जैसे "दूसरी कविता लौटाओ"। model को लगभग एक जैसी चीज़ों को उनके क्रम तक पहचानना होता है, इसलिए यह multi-needle needle-in-a-haystack परीक्षण है। score इस पर मिलता है कि लौटाया गया पाठ सही पाठ से कितना मेल खाता है। लंबाई के अनुसार परिणाम ये हैं:

• GPT-5.5: 4K–8K पर 98.1%, 128K–256K पर 87.5%, 512K–1M पर 74.0%
• GPT-5.4 (उसी तालिका में पिछली पीढ़ी): इन्हीं तीन दायरों में 97.3% → 79.3% → 36.6%
• Claude Opus 4.7 (वे मान जो OpenAI ने उसी तालिका में रखे): 128K–256K पर 59.2%, 512K–1M पर 32.2%
• GPT-6 Astra (सितंबर 2026 में घोषित): 256K–512K पर 100.0%, 512K–1M पर 96.3% (उसी तालिका में GPT-5.6 Sol: 91.5% और 73.8%)

स्रोत (26 सितंबर 2026 को जाँचा गया): OpenAI के "Introducing GPT-5.5" (23 अप्रैल 2026) और "GPT-6 Astra" (3 सितंबर 2026) की मूल्यांकन तालिकाएँ। benchmark कैसे काम करता है: OpenAI MRCR dataset का विवरण। model नाम हर घोषणा के समय के हैं।

दो बातें साफ़ दिखती हैं। पहली, एक ही model का score input लंबा होने के साथ गिरता है। दूसरी, गिरावट कितनी तेज़ है, यह model और पीढ़ी के अनुसार बहुत बदलता है — 1M के सबसे क़रीब वाले दायरे में GPT-5.4 40% से नीचे चला गया, जबकि सितंबर 2026 में घोषित GPT-6 Astra 90% से ऊपर टिका रहा। हर पीढ़ी में रैंकिंग बदलती है, इसलिए ये संख्याएँ जल्दी पुरानी हो जाती हैं। जो सबक टिकता है वह यह है: घोषित सीमा और वह दायरा जहाँ सटीकता सच में बनी रहती है, दो अलग संख्याएँ हैं।

ग़लत मत समझिए। यह "Claude या GPT ख़राब हैं" की बात नहीं है। जिन उपयोगों को सच में पूरा 1M चाहिए, वे जितना लगता है उससे कम हैं। अगर कोई model 300K (लगभग 2–3 किताबें) तक स्थिर रूप से पढ़ ले, तो लगभग हर coding, शोध और सारांश का काम उसमें पूरा हो जाता है। समस्या केवल "1M समर्थित" संख्या देखकर चुनने में है — इसी से निर्णय के मानदंड ग़लत हो जाते हैं।

2. context क्या है? — कंटेनर को उसकी सामग्री से अलग समझें

त्वरित शब्दावली। इस क्षेत्र में तीन शब्द आपस में मिल जाते हैं।

साथ ही: "context" को "memory" से न मिलाएँ। context session के अंदर रहता है — chat बंद करिए और यह चला जाता है। ChatGPT Memory या Claude Memory जैसी सुविधाएँ, दूसरी ओर, एक अलग cross-session धारण तंत्र हैं। memory की सामग्री अंततः context window में इंजेक्ट हो जाती है, लेकिन उपयोगकर्ता के दृष्टिकोण से यह स्थायी संग्रहण बनाम क्षणिक कार्यस्थल है।

3. कंटेनर का आकार तीन संख्याओं से पढ़ें

किसी model की spec sheet देखते समय, context से जुड़ी केवल तीन चीज़ें जाँचनी होती हैं। इन्हें समझ लें, तो कोई भी model आए, उसी तरीके से तुलना कर सकते हैं।

नीचे 29 सितंबर 2026 तक हर vendor के आधिकारिक पेजों के आँकड़े हैं। पीढ़ी के साथ आँकड़े बदलते हैं, इसलिए इसे इस उदाहरण की तरह पढ़ें कि ऊपर के तीन अक्ष वास्तविक अंतर में कैसे बदलते हैं। आज के विशिष्ट model नाम वर्तमान model और cutoff तिथियों की सूची में देखें, और आँकड़े हर vendor के आधिकारिक पेजों पर।

स्रोत (29 सितंबर 2026 को जाँचे गए): Anthropic Models overview और Pricing / OpenAI के GPT-6 Astra और GPT-6 Sol model पेज / Google Gemini 3.1 Pro Preview और Gemini API pricing

तालिका में सभी vendor की input सीमाएँ लगभग बराबर हैं; अंतर output सीमा और मूल्य-निर्धारण के ढाँचे में है। सीमाएँ बराबर हों तो window का आकार चुनने का कारण नहीं रह जाता। असली अंतर यह है: Anthropic सीमा तक एक ही दर रखता है, जबकि OpenAI और Google एक निश्चित लंबाई के बाद दर बढ़ा देते हैं — यानी एक ही "1M समर्थित" लेबल के नीचे लंबा input कितनी बेफ़िक्री से भेजा जा सकता है, यह अलग है। यह केवल मूल्य का ब्योरा नहीं, बल्कि long-context workload के प्रति अलग दृष्टिकोण को दिखाता है। लागत वाले अध्याय में इसकी गणना करेंगे।

व्यवहार में चुनाव ऐसे होता है। आप नियमित रूप से जिस आकार के दस्तावेज़ संभालते हैं, उसी से तय करें। अगर वे लगभग 200K के भीतर आ जाते हैं, तो window के आकार के बजाय उस दायरे में सटीकता की स्थिरता और मूल्य-सीमा से नीचे रह पाने के आधार पर चुनें। केवल तब, जब आप लगातार 300K से बड़े विशाल दस्तावेज़ संभालते हों, प्रभावी सीमा की चौड़ाई और लंबे input की दर निर्णायक बनती है। एक ही model पर मत टिकिए — उपयोग के अनुसार बाँटिए। निर्णय लेने का यह तरीका पीढ़ी बदलने पर भी वही रहता है।

सीमाएँ कहाँ जाँचें

आँकड़े संकलन वेबसाइटों या लेखों की तालिकाओं (इसमें यह लेख भी शामिल है) में नहीं, बल्कि हर vendor के आधिकारिक पेजों पर जाँचें। कहाँ देखना है, यह काफ़ी तय है:

• Anthropic: model overview पेज की तुलना तालिका में "Context window" और "Max output" की पंक्तियाँ हैं। लंबे input का मूल्य pricing पेज के "Long context pricing" खंड में है
• OpenAI: API दस्तावेज़ में हर model के पेज पर "context window" और "max output tokens" के साथ लंबे prompt के मूल्य पर टिप्पणी होती है
• Google: Gemini API के model पेज पर "Input token limit" और "Output token limit" हैं, और pricing पेज पर "prompts > 200k tokens" की अलग श्रेणी है

एक और बात जो आसानी से छूट जाती है: एक ही सीमा में अलग-अलग model में अलग मात्रा का पाठ समाता है। सीमाएँ token में गिनी जाती हैं, इसलिए tokenizer (पाठ को token में बाँटने की विधि) बदलने पर उसी दस्तावेज़ की token संख्या भी बदल जाती है (§5 की टिप्पणी देखें)। model बदलने के बाद अपने दस्तावेज़ों से दोबारा गिनें, ताकि पक्का हो कि सीमा के मुक़ाबले अभी भी गुंजाइश है।

4. "बड़ा बेहतर है" क्यों नहीं टिकता — तीन कारण

पिछले अध्याय की तालिका केवल कंटेनर का भौतिक आकार दिखाती है। तो क्या model सच में घोषित कंटेनर का पूरा उपयोग करता है? निष्कर्ष पहले: यह मानकर न चलें कि वह सीमा तक एक जैसी सटीकता से पढ़ता है। इसके तीन कारण हैं।

कारण ①: Lost in the Middle

यह वह घटना है जिसे 2023 में Stanford और अन्य संस्थानों के शोधकर्ताओं (Liu और सहयोगी) ने "Lost in the Middle" शोध-पत्र में दर्ज किया। कई दस्तावेज़ों में उत्तर खोजने जैसे कामों में model तब सबसे अच्छा उत्तर देते थे जब उत्तर input के शुरू या अंत में हो, और बीच में होने पर सटीकता काफ़ी गिर जाती थी — long context के लिए बनाए गए model में भी यही रुझान दिखा।

रोज़मर्रा में यह ऐसे दिखता है: "एक लंबा PDF पूरा चिपकाइए, पूछिए 'X का आँकड़ा क्या है?', और model ठीक बीच वाला आँकड़ा गड़बड़ कर देता है।" यही Lost in the Middle है। इसकी तीव्रता model के अनुसार अलग होती है, लेकिन सुरक्षित यही है कि मान लें दस्तावेज़ के बीच की जानकारी आसानी से छूट जाती है, और उसी हिसाब से देने का तरीका बदलें।

कारण ②: Context Rot

बातचीत जितनी लंबी चलती है, शुरुआती निर्देश उतने ही धुंधले पड़ते जाते हैं। शुरुआत में आपने औपचारिक लहजा माँगा था, और 20 बार के आदान-प्रदान के बाद model फिर अनौपचारिक हो गया — यही Context Rot है।

दो कारण हैं। ① बातचीत के इतिहास में शुरुआती निर्देश अपेक्षाकृत पुराने और हल्के माने जाने लगते हैं। ② लंबा इतिहास attention को बिखेर देता है, जिससे किसी ख़ास token का संदर्भ लेना कठिन हो जाता है। Anthropic अपने डेवलपर दस्तावेज़ में token संख्या बढ़ने पर सटीकता और recall में आने वाली गिरावट को context rot कहता है, और लिखता है कि context में क्या डाला जाए, यह चुनना उतना ही अहम है जितना कि उसमें कितना समाता है। सितंबर 2025 में उसने "Effective context engineering for AI agents" शीर्षक वाले तकनीकी लेख में इस समस्या से निपटने को एक सोच-समझकर सीखे जाने वाले कौशल के रूप में समझाया।

कारण ③: विज्ञापित context ≠ प्रभावी context

§1 के मानों में से केवल 1M के सबसे क़रीब वाला दायरा (512K–1M) साथ रखें, तो तस्वीर यह बनती है। सभी मान OpenAI की घोषणाओं की मूल्यांकन तालिकाओं से हैं और एक ही benchmark, OpenAI MRCR v2 (8 needle), के हैं।

इसका मतलब यह नहीं कि "कम score वाले model ख़राब हैं"। उसी तालिका के छोटे दायरे में GPT-5.5 और GPT-5.4 दोनों 97% से ऊपर हैं, और अधिकांश वास्तविक काम — code review, लंबा लेखन, बैठक-नोट्स का सारांश, शोध का संश्लेषण — 1M से काफ़ी पहले पूरा हो जाता है। समस्या "1M है तो 1M डाल दो" वाली सोच में है। यह भी ध्यान रखें कि ये OpenAI द्वारा अपनी घोषणाओं में दिए गए मान हैं, और इनकी तुलना केवल एक ही तालिका के भीतर की जा सकती है। Google भी Gemini 3.1 Pro के model card (फ़रवरी 2026) में MRCR v2 (8 needle) के परिणाम देता है — 128K (औसत) पर 84.9% और 1M पर 26.3% — लेकिन वह लंबाई के दायरे अलग तरह से बाँटता है, इसलिए वह ऊपर की पट्टियों में शामिल नहीं है। Claude Opus 5.5 और Anthropic के अन्य मौजूदा model के घोषणा-पृष्ठों पर लंबाई के अनुसार ऐसे score नहीं दिए गए हैं। आज आप जो model इस्तेमाल करते हैं उसकी असली क्षमता जानने के लिए, नीचे के तरीके से अपने उपयोग पर जाँचें।

अपने उपयोग के लिए "प्रभावी सीमा" मापें

benchmark के आँकड़े ऐसे दस्तावेज़ों और प्रश्नों से आते हैं जो आपके उपयोग से अलग हैं। सबसे भरोसेमंद तरीका है अपने दस्तावेज़ों से एक छोटा needle-in-a-haystack परीक्षण बनाना।

1. वही प्रकार का दस्तावेज़ लें जो आप सच में इस्तेमाल करते हैं (code, बैठक-नोट्स, अनुबंध आदि), और स्पष्ट उत्तर वाले 3–5 तथ्य शुरू, बीच और अंत में बिखेरकर रखें (दस्तावेज़ में पहले से मौजूद तथ्य भी चलेंगे)
2. कहें कि "सभी को सूचीबद्ध करो और बताओ हर एक कहाँ लिखा है", ताकि उसे एक साथ कई तथ्य निकालने पड़ें। केवल एक पूछने पर model वास्तविकता से बेहतर दिखता है (एक needle और कई needle का अंतर)
3. वही प्रश्न 50K, 200K, 500K जैसी अलग-अलग लंबाइयों पर दोहराएँ, और वह लंबाई दर्ज करें जहाँ उत्तर बिगड़ने लगते हैं
4. केवल निकालने वाले नहीं, तथ्यों को जोड़ने वाले प्रश्न भी रखें ("A और B की तुलना करो")। जिन प्रश्नों में संश्लेषण चाहिए, वे आमतौर पर जल्दी टूटते हैं

जहाँ गड़बड़ी शुरू होती है, उससे ठीक पहले की लंबाई ही उस model की उस उपयोग के लिए "प्रभावी context" है। model बदलें तो दोबारा मापें। इसमें कुछ दसियों मिनट लगते हैं, लेकिन यह spec sheet की किसी भी संख्या से बेहतर वास्तविक निर्णय में मदद करता है।

5. लागत का जाल — लंबे input पर दर बढ़ाने वाले model और न बढ़ाने वाले model

पिछले अध्याय में देखा कि प्रभावी सीमा घोषित सीमा से पहले ही आ जाती है। उसके ऊपर एक दूसरा जाल भी है: लंबा input भेजने पर बिल उछल सकता है। यहाँ vendor ने अलग-अलग ढाँचे अपनाए हैं।

आइए गणना करें। मान लीजिए आप 500K token का दस्तावेज़ भेजते हैं और 50K का एक उत्तर पाते हैं — बड़े codebase या वार्षिक रिपोर्ट को एक बार में सारांशित करने का सामान्य परिदृश्य।

• Claude Opus 5.5 (एक समान दर): $4.00 × 0.5 + $20.00 × 0.05 = $3.00
• GPT-6 Sol (272K से ऊपर अधिभार): $4.00 × 0.5 + $15.00 × 0.05 = $2.75 (अधिभार के बिना $1.50)
• Gemini 3.1 Pro (200K से ऊपर की दर): $4.00 × 0.5 + $18.00 × 0.05 = $2.90 (200K तक की दर पर $1.60)
• GPT-6 Astra (272K से ऊपर अधिभार): $20.00 × 0.5 + $75.00 × 0.05 = $13.75

इसे दो तरह से पढ़ा जा सकता है। पहला, सीमा पार होते ही वही model लगभग 1.8 गुना महँगा हो जाता है। छोटे input पर GPT-6 Sol, Claude Opus 5.5 से आधे दाम का है, लेकिन 500K पर अंतर लगभग मिट जाता है — "कौन-सा model सस्ता है", यह input की लंबाई के साथ उलट जाता है। दूसरा, जब अधिभार पहले से महँगे flagship model पर लगता है, तो लागत दूसरे पैमाने पर पहुँच जाती है (GPT-6 Astra, Opus 5.5 से 4 गुना से भी अधिक)। चुनने से पहले, जिन model की तुलना कर रहे हैं उनके साथ और अपनी औसत input लंबाई के साथ दोबारा गणना करें।

सीमा-आधारित मूल्य में, जो काम बाँटा जा सकता है उसे सीमा से नीचे के टुकड़ों में बाँटें। 500K को 250K के दो अनुरोधों में भेजें तो GPT-6 Sol अधिभार नहीं लेता — कुल $1.50 (हालाँकि जिन कामों में सब कुछ एक साथ देखना ज़रूरी है, उनमें यह नहीं चलता)। यह वही ढाँचा है जिसकी चर्चा "AI token और session लागत-बचत" में की गई है।

6. पाँच बचत रणनीतियाँ — एकल डेवलपर के लिए वास्तविक प्रभाव से क्रमित

"कंटेनर 1M है लेकिन प्रभावी दायरा उससे काफ़ी पहले ख़त्म हो जाता है, और इसे लंबा उपयोग करना महँगा हो जाता है।" हमने इसे कवर किया है। तो फ़ील्ड में आप वास्तव में क्या कर सकते हैं? यहाँ पाँच रणनीतियाँ हैं जो मैं रोज़ाना उपयोग करता हूँ, जो सबसे बड़ा फ़ायदा देती है उसके अनुसार क्रमित।

मेरी व्यक्तिगत सर्वोत्तम प्रथा: केवल ① और ② को निरंतर करना ही अनुभूत सटीकता को स्पष्ट रूप से बदल देता है। Claude Code के साथ भी, एक लंबे session को धकेलने के बजाय, हर विषय परिवर्तन पर /compact मारना या नया session शुरू करना अंतिम output गुणवत्ता को स्थिर रखता है।

सारांश

इस लेख के मुख्य बिंदु:

• context window = एक आदान-प्रदान में AI जितने अधिकतम token संभाल सकता है। कंटेनर का आकार
• सितंबर 2026 तक, Anthropic, OpenAI और Google के शीर्ष model सभी 10 लाख token श्रेणी में हैं। input सीमाओं में बहुत कम अंतर है; अंतर output सीमा और लंबे input के मूल्य में है
• घोषित सीमा और प्रभावी सीमा अलग बातें हैं। OpenAI द्वारा प्रकाशित multi-needle benchmark MRCR (8 needle) में एक ही model का score input लंबा होने के साथ गिरता है, और 1M के क़रीब मान Claude Opus 4.7 के 32.2% (OpenAI की तालिका) से GPT-6 Astra के 96.3% तक फैले थे
• प्रभावी सीमा जानने का सबसे भरोसेमंद तरीका है अपने दस्तावेज़ों में तथ्य बिखेरकर अलग-अलग लंबाई पर परखना। model बदलें तो दोबारा मापें
• लंबे input का मूल्य दो रूपों में आता है: सीमा तक एक ही दर (Anthropic), या एक सीमा के बाद अधिभार (OpenAI में 272K, Google में 200K)। सस्ता कौन है, यह input की लंबाई के साथ उलट जाता है
• बचत पाँच कदमों में है: session काटें, अंश भेजें, अंत में निर्देश दोहराएँ, cache करें, और पते स्पष्ट करें — ① और ② सबसे अधिक असरदार हैं

कंटेनर बड़ा हो गया, फिर भी हम असल में वही कर रहे हैं: क्या देना है और क्या छोड़ना है, इसका चयन। आज AI का मुख्य कौशल "सब कुछ ठूँस देने की क्षमता" नहीं रहा। यह है ठीक वही जो ज़रूरी है, सही ढंग से देने का विवेक — एक ऐसा कौशल जो model की कितनी भी पीढ़ियाँ बदल जाएँ, काम आता रहेगा। 1M के सामान्य हो जाने के इस दौर में यही मेरा निष्कर्ष है।

FAQ