कुछ समय पहले मैंने एक रिट्रीवल पाइपलाइन को वह एकमात्र दस्तावेज़ गँवाते देखा जो मायने रखता था। एक प्राइसिंग मेमो, 40 दस्तावेज़ों के ढेर में दबा हुआ, चुपचाप 51वें स्थान पर रैंक हो गया जबकि हम शीर्ष 50 लौटा रहे थे। एजेंट ने बाकी 49 का सारांश बनाया और एक आत्मविश्वास से भरी संख्या ग्राहक को भेज दी। गलत संख्या। समाधान बड़ी संदर्भ विंडो नहीं था। समाधान रैंकर को ठीक करना था।
जब भी कोई 1.2 करोड़-token संदर्भ LLM को लेकर उत्साहित होता है, मैं यह किस्सा याद करता हूँ, क्योंकि प्रचार हमेशा यही होता है: "सब कुछ प्रॉम्प्ट में डाल दो और समस्या खत्म।" ऐसा नहीं होता। आइए मैं समझाता हूँ क्यों, और असल में क्या आने वाला है।
पहले, ईमानदार अस्वीकरण। जब मैं यह लिख रहा हूँ, कोई 1.2 करोड़-token मॉडल शिप नहीं हुआ है। अग्रणी सीमा 10 लाख token पर है — Claude Opus 4.8 और Fable 5 दोनों 10 लाख token की संदर्भ विंडो पर चलते हैं, और Gemini की लंबे-संदर्भ श्रृंखला भी इसी स्तर पर है। नीचे जो कुछ भी है वह विश्लेषण है, कोई बेंचमार्क नहीं जो मैंने चलाया हो। मैं भौतिकी के आधार पर तर्क करना पसंद करता हूँ, न कि किसी कीनोट को दोहराना।
1.2 करोड़-token संदर्भ LLM को उप-द्विघात अटेंशन की जरूरत क्यों है
यही दीवार है। मानक अटेंशन अनुक्रम की लंबाई के वर्ग के साथ स्केल होती है। अपने इनपुट को बारह से गुणा करें और अटेंशन की लागत बारह के वर्ग — यानी 144 गुना अधिक कंप्यूट और मेमोरी — बढ़ जाती है। आप और अधिक H100 लगाकर इसे पार नहीं कर सकते। एकमात्र रास्ता गणित बदलना है।
यही पूरी उप-द्विघात शोध-पंक्ति है। Mamba जैसे स्टेट स्पेस मॉडल, रैखिक और विरल अटेंशन वेरिएंट, RWKV-शैली की पुनरावृत्तियाँ, और हाइब्रिड डिज़ाइन जो मुख्यतः-रैखिक बैकबोन पर कुछ वास्तविक अटेंशन परतें जोड़ते हैं। Mamba पेपर अनुक्रम की लंबाई में रैखिक स्केलिंग और तुलनीय Transformer से लगभग 5 गुना अधिक अनुमान थ्रूपुट रिपोर्ट करता है, जिसमें लाखों-लंबाई के अनुक्रमों में गुणवत्ता बनी रहती है।
लेकिन वही पेपर समस्या के बारे में सीधा है। लेखक नोट करते हैं कि ये आर्किटेक्चर "भाषा जैसी महत्वपूर्ण विधाओं पर अटेंशन जितना अच्छा प्रदर्शन नहीं कर पाई हैं।" यह अंतर ही पूरा खेल है। रैखिक अटेंशन सस्ती है क्योंकि वह अतीत को एक निश्चित आकार की स्थिति में कुचल देती है, और कुचलने का मतलब भूलना है। एकमात्र सवाल जो मायने रखता है वह यह है कि क्या वह उस चीज़ को भूल जाती है जिसकी आपको जरूरत थी। हाइब्रिड यहाँ सबसे चतुर दांव है — सटीकता के लिए कुछ पूर्ण-अटेंशन परतें रखें, बाकी को बड़े पैमाने पर उप-द्विघात चलाएँ। आप यह गारंटी खो देते हैं कि हर token बाकी हर token को देखता है। 1.2 करोड़ token पर आप वैसे भी वह गारंटी नहीं उठा सकते थे।
वह विफलता-मोड जिसका कोई मूल्य नहीं लगाता: संदर्भ-क्षय
हम पहले से मौजूद 10 लाख-token विंडो का पूरी तरह उपयोग नहीं कर सकते। यही हिस्सा मुझे "अधिक संदर्भ सब ठीक कर देता है" वाले ढाँचे पर संशय करवाता है।
Chroma के संदर्भ-क्षय पर शोध ने कई अग्रणी मॉडलों का परीक्षण किया और पाया कि इनपुट बढ़ने के साथ सटीकता घटती है, भले ही विंडो भरी न हो। Token जोड़ें, सटीकता खोएँ। यह अटेंशन-तनुकरण की समस्या है, क्षमता की नहीं।
इसका क्लासिक लक्षण है "बीच में खो जाना।" Liu एट अल. (2023) ने दिखाया कि मॉडल लंबे इनपुट की शुरुआत और अंत पर तो अच्छा ध्यान देते हैं लेकिन बीच में दबी चीज़ों पर बुरा, और जब प्रासंगिक तथ्य गलत स्थान पर हो तो सटीकता तेज़ी से गिरती है। अब 1.2 करोड़ token पर उसी को उस उप-द्विघात बैकबोन पर सोचें जो डिज़ाइन से ही क्षतिपूर्ण है। आप स्थितिगत तनुकरण के ऊपर आर्किटेक्चरल भूल जाना ढेर कर रहे हैं।
और रिट्रीवल तर्क नहीं है — यही वह जाल है जिसमें लोग गिरते हैं। एक मॉडल सुई-घास-के-ढेर टेस्ट जीत सकता है, 1 करोड़ token में एक लगाए गए वाक्य को ढूँढ सकता है, और फिर भी उसी ढेर में बिखरे चालीस तथ्यों से कोई निष्कर्ष संश्लेषित करने में पूरी तरह विफल हो सकता है। किसी तथ्य को ढूँढना लुकअप है। कई तथ्यों पर तर्क करना अलग, कठिन काम है, और NoLiMa जैसे कठिन लंबे-संदर्भ मूल्यांकन जो शाब्दिक कीवर्ड मिलान से आगे जाते हैं, लगातार यह अंतर उजागर करते हैं। 1.2 करोड़-token सुई-परीक्षण की जीत आपको लगभग कुछ नहीं बताती कि मॉडल उस ढेर पर सोच सकता है या नहीं।
1.2 करोड़-token संदर्भ LLM की यथार्थवादी समयरेखा
मैं एक सीमा देने की प्रतिबद्धता करूँगा, इस चेतावनी के साथ कि मैं पहले समयरेखा के अनुमान गलत लगा चुका हूँ।
12 से 24 महीने: अनुसंधान-स्तर और डेमो-स्तर का 1.2 करोड़ संदर्भ, ज़्यादातर हाइब्रिड आर्किटेक्चर, तारांकन के साथ। मजबूत सुई-स्मरण, अस्थिर क्रॉस-दस्तावेज़ तर्क। वह चीज़ जो बेंचमार्क में अच्छी लगती है और आपके एजेंट लूप के अंदर निराश करती है।
24 से 48 महीने: उत्पादन पहुँच जहाँ गहराई पर तर्क-गुणवत्ता वास्तविक काम के लिए भरोसेमंद हो, प्रीफिल विलंबता सहनीय हो, और कीमत बेतुकी न हो। वह आखिरी वाक्यांश सबसे ज़्यादा वज़न उठाता है।
अर्थशास्त्र क्रूर है, भले ही आर्किटेक्चर काम करे। 1.2 करोड़-token का प्रीफिल मॉडल का एक भी आउटपुट token उत्सर्जित करने से पहले का बड़ा कंप्यूट बोझ है। सेकंड से मिनट की विलंबता, और उसी हिसाब का बिल। आज Opus 4.8 प्रति दस लाख इनपुट token 5 डॉलर पर चलती है। एक ठंडा 1.2 करोड़-token प्रीफिल केवल इनपुट में 60 डॉलर है, हर बार, जब तक कैशिंग न बचाए। प्रॉम्प्ट कैशिंग एक अच्छी सुविधा रहने के बजाय भार-वाहक बन जाती है। समस्या यह है कि कैशिंग तभी मदद करती है जब आपका उपसर्ग स्थिर हो, और एजेंट लूप में वह अक्सर नहीं होता।
अपने एजेंट वर्कफ़्लो को कैसे तैयार करें
आप 1.2 करोड़ का इंतजार नहीं करते। आप इस तरह बनाते हैं जैसे यह आने वाला है और जैसे यह आपको नहीं बचाएगा।
संदर्भ विंडो को कबाड़ की दराज मानना बंद करें। सहज प्रवृत्ति होगी कि पूरा कोडबेस, हर दस्तावेज़, पूरा चैट इतिहास डाल दो और मॉडल को सुलझाने दो। ऐसे ही संदर्भ-क्षय शुरू होता है। बड़ी विंडो पर जीतने वाली टीमें वे हैं जो छोटी विंडो पर अनुशासित हुईं।
अभी करने लायक कुछ चीज़ें: ऐसी रिट्रीवल बनाएँ जिस पर आप सच में भरोसा करते हों, ताकि मॉडल गलत 1.2 करोड़ token की जगह सही 50,000 token देखे — और हाँ, इसका मतलब है उस स्थिति को पकड़ना जहाँ ज़रूरी दस्तावेज़ 51वें स्थान पर रैंक होता है। मेमोरी को एक स्पष्ट स्टोर मानें जिसे एजेंट पढ़ता और लिखता है — फ़ाइलें, डेटाबेस या संरचित नोट्स — न कि "ट्रांसक्रिप्ट में ऊपर स्क्रोल करो।" पुराने टूल परिणामों को हटाएँ और पूरे हुए उप-कार्यों का सारांश बनाएँ ताकि कार्यशील सेट दुबला रहे। ये सभी कौशल आगे काम आते हैं। इनमें से कोई भी तब अप्रचलित नहीं होता जब विंडो बड़ी हो जाती है।
अगर आपका एजेंट केवल इसलिए काम करता है क्योंकि आप सब कुछ एक प्रॉम्प्ट में ठूँस सकते हैं, तो 1.2 करोड़-token विंडो आपके डिज़ाइन को नहीं ठीक करती। यह आपको बड़े पैमाने पर और अधिक लागत पर विफल होने देती है।
क्या संदर्भ ही बाधा है?
नहीं। और यही वह बात है जिसका मैं बचाव करूँगा।
कच्ची संदर्भ लंबाई स्पेक-शीट की संख्या है। बाज़ार में लाना आसान, सुई-परीक्षण से बेंचमार्क करना आसान, प्रगति समझने की गलती करना भी आसान। आपमें से अधिकांश लोग जो एजेंटिक काम कर रहे हैं, उसके लिए असली बाधा रिट्रीवल, मेमोरी और एजेंट डिज़ाइन है। सवाल कभी नहीं था "क्या मॉडल 1.2 करोड़ token रख सकता है।" सवाल है "क्या वह सही token ढूँढ सकता है, तौल सकता है और उन पर तर्क कर सकता है" — और बड़ी घास-के-ढेर इसे सख्ती से कठिन बना देती है।
मुझे सटीक रिट्रीवल वाला 2 लाख-token मॉडल दें, बजाय उस 1.2 करोड़-token मॉडल के जो बीच में सड़ जाता है। हर दिन। 1.2 करोड़-token संदर्भ LLM जब आएगी, कुछ वास्तविक समस्याओं के लिए वास्तविक उपकरण होगी: पूरे-रेपो विश्लेषण, लंबी-अवधि के एजेंट जिन्हें सच में इतिहास चाहिए। आपके निर्माण के अधिकांश हिस्से के लिए, यह उसी गलती को अधिक महँगे तरीके से करने का साधन होगी जो मेरी पाइपलाइन ने की — आत्मविश्वास से गलत संख्या भेजना क्योंकि सही वाली कभी मॉडल के अटेंशन में नहीं पहुँची।
संदर्भ कठिन हिस्सा नहीं है। यह तय करना कि उसमें क्या जाए, यही पूरा काम है।