Gemini के कई मॉडल, 10 लाख या इससे ज़्यादा टोकन वाली बड़ी कॉन्टेक्स्ट विंडो के साथ आते हैं. पहले, लार्ज लैंग्वेज मॉडल (एलएलएम) में एक बार में सीमित मात्रा में ही टेक्स्ट (या टोकन) पास किया जा सकता था. Gemini की लंबी कॉन्टेक्स्ट विंडो की मदद से, डेवलपर कई नए तरीकों से एआई का इस्तेमाल कर सकते हैं.
टेक्स्ट जनरेट करने या मल्टीमोडल इनपुट जैसे मामलों के लिए पहले से इस्तेमाल किया जा रहा कोड, लॉन्ग कॉन्टेक्स्ट के साथ बिना किसी बदलाव के काम करेगा.
इस दस्तावेज़ में बताया गया है कि 10 लाख या इससे ज़्यादा टोकन वाली कॉन्टेक्स्ट विंडो वाले मॉडल का इस्तेमाल करके, क्या-क्या किया जा सकता है. इस पेज पर, कॉन्टेक्स्ट विंडो के बारे में खास जानकारी दी गई है. साथ ही, यह बताया गया है कि डेवलपर को लंबी कॉन्टेक्स्ट विंडो के बारे में कैसे सोचना चाहिए, असल दुनिया में लंबी कॉन्टेक्स्ट विंडो के इस्तेमाल के अलग-अलग उदाहरण क्या हैं, और लंबी कॉन्टेक्स्ट विंडो के इस्तेमाल को ऑप्टिमाइज़ करने के तरीके क्या हैं.
किसी मॉडल के लिए कॉन्टेक्स्ट विंडो के साइज़ की जानकारी पाने के लिए, मॉडल पेज पर जाएं.
कॉन्टेक्स्ट विंडो क्या होती है?
Gemini मॉडल का इस्तेमाल करने का बुनियादी तरीक़ा यह है कि मॉडल को जानकारी (कॉन्टेक्स्ट) दी जाए. इसके बाद, मॉडल जवाब जनरेट करेगा. कॉन्टेक्स्ट विंडो को शॉर्ट टर्म मेमोरी की तरह समझा जा सकता है. किसी व्यक्ति की कम समय के लिए याद रखने की क्षमता सीमित होती है. जनरेटिव मॉडल के साथ भी ऐसा ही होता है.
Gemini 4 (gemini-4-argon) में, 10 लाख टोकन वाली कॉन्टेक्स्ट विंडो को इनपुट, सोच-विचार, और आउटपुट टोकन के बीच शेयर किया जाता है. साथ ही, यह मॉडल लॉन्ग डिकोड का इस्तेमाल करके, 10 लाख आउटपुट टोकन जनरेट कर सकता है. अगर आपके इनपुट टोकन और max_output_tokens की संख्या 10,48,576 टोकन से ज़्यादा हो जाती है, तो एपीआई अपने-आप आउटपुट की सीमा को कॉन्टेक्स्ट विंडो में बची हुई जगह (1,048,576 में से आपके इनपुट टोकन घटाने के बाद बची जगह) तक सीमित कर देता है. Gemini 3 और 2.5 मॉडल के लिए, इनपुट और आउटपुट के बजट अलग-अलग होते हैं. इनपुट के लिए 10 लाख टोकन और आउटपुट के लिए 64 हज़ार टोकन का बजट होता है.
मॉडल के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, जनरेटिव मॉडल की गाइड पढ़ें.
लॉन्ग कॉन्टेक्स्ट विंडो का इस्तेमाल शुरू करना
जनरेटिव मॉडल के पुराने वर्शन, एक बार में सिर्फ़ 8,000 टोकन प्रोसेस कर पाते थे. नए मॉडल में, 32,000 या 1,28,000 टोकन स्वीकार किए जा सकते हैं. Gemini, 10 लाख टोकन स्वीकार करने वाला पहला मॉडल है.
असल में, 10 लाख टोकन कुछ इस तरह दिखेंगे:
- कोड की 50,000 लाइनें (हर लाइन में स्टैंडर्ड 80 वर्ण)
- पिछले पांच सालों में भेजे गए सभी टेक्स्ट मैसेज
- अंग्रेज़ी में औसतन आठ उपन्यास
- औसत लंबाई वाले 200 से ज़्यादा पॉडकास्ट एपिसोड की ट्रांसक्रिप्ट
कई अन्य मॉडल में कॉन्टेक्स्ट विंडो की क्षमता कम होती है. इसलिए, उनमें अक्सर पुरानी जानकारी को हटाने, कॉन्टेंट की खास जानकारी देने, वेक्टर डेटाबेस के साथ आरएजी का इस्तेमाल करने या टोकन बचाने के लिए प्रॉम्प्ट को फ़िल्टर करने जैसी रणनीतियों की ज़रूरत पड़ती है.
हालाँकि, ये तकनीकें कुछ ख़ास मामलों में अब भी काम की हैं, लेकिन Gemini की बड़ी कॉन्टेक्स्ट विंडो की वजह से, अब सीधे तौर पर काम किया जा सकता है. यानी, काम की सारी जानकारी एक ही बार में दी जा सकती है. Gemini मॉडल को खास तौर पर, बड़े कॉन्टेक्स्ट को समझने की क्षमता के साथ बनाया गया है. इसलिए, ये कॉन्टेक्स्ट के हिसाब से सीखने की बेहतर क्षमता दिखाते हैं. उदाहरण के लिए, Gemini ने सिर्फ़ इन-कॉन्टेक्स्ट इंस्ट्रक्शनल मटीरियल (500 पेज की व्याकरण की किताब, एक डिक्शनरी, और ≈400 मिलते-जुलते वाक्य) का इस्तेमाल करके, अंग्रेज़ी से कलामंग भाषा में अनुवाद करना सीखा. कलामंग, पापुआ की एक भाषा है जिसे 200 से भी कम लोग बोलते हैं. Gemini ने इस भाषा में अनुवाद करना उसी क्वालिटी के साथ सीखा जिस क्वालिटी के साथ कोई इंसान इन मटीरियल का इस्तेमाल करके सीखता. इससे पता चलता है कि Gemini की बड़ी कॉन्टेक्स्ट विंडो की वजह से, किस तरह से बदलाव आया है. साथ ही, इन-कॉन्टेक्स्ट लर्निंग की मदद से, नई संभावनाओं को बढ़ावा मिला है.
लंबे कॉन्टेक्स्ट के इस्तेमाल के उदाहरण
ज़्यादातर जनरेटिव मॉडल के लिए, स्टैंडर्ड इस्तेमाल का उदाहरण अब भी टेक्स्ट इनपुट है. हालांकि, Gemini मॉडल फ़ैमिली, मल्टीमोडल इस्तेमाल के उदाहरणों का एक नया उदाहरण पेश करती है. ये मॉडल टेक्स्ट, वीडियो, ऑडियो, और इमेज को आसानी से समझ सकते हैं. इनके साथ Gemini API भी उपलब्ध है, जो मल्टीमोडल फ़ाइल टाइप को स्वीकार करता है. इससे उपयोगकर्ताओं को सुविधा मिलती है.
लंबा टेक्स्ट
टेक्स्ट, एलएलएम के आस-पास के ज़्यादातर मोमेंटम को बेहतर बनाने वाली इंटेलिजेंस की लेयर साबित हुआ है. जैसा कि पहले बताया गया है, एलएलएम की कई व्यावहारिक सीमाएं इसलिए थीं, क्योंकि उनके पास कुछ टास्क करने के लिए, कॉन्टेक्स्ट विंडो काफ़ी बड़ी नहीं थी. इस वजह से, रिट्रीवल ऑगमेंटेड जनरेशन (आरएजी) और अन्य तकनीकों को तेज़ी से अपनाया गया. ये तकनीकें, मॉडल को संदर्भ के हिसाब से काम की जानकारी डाइनैमिक तरीके से उपलब्ध कराती हैं. अब बड़ी से बड़ी कॉन्टेक्स्ट विंडो के साथ, नई तकनीकें उपलब्ध हो रही हैं. इनसे नए इस्तेमाल के उदाहरण सामने आ रहे हैं.
टेक्स्ट पर आधारित लंबे कॉन्टेक्स्ट के लिए, इस्तेमाल के कुछ नए और स्टैंडर्ड उदाहरण यहां दिए गए हैं:
- टेक्स्ट के बड़े कॉर्पस की खास जानकारी जनरेट करना
- छोटे कॉन्टेक्स्ट मॉडल के साथ खास जानकारी देने के पिछले विकल्पों के लिए, स्लाइडिंग विंडो या किसी अन्य तकनीक की ज़रूरत होती थी. इससे पिछले सेक्शन की स्थिति को बनाए रखा जाता था, क्योंकि मॉडल को नए टोकन पास किए जाते थे
- सवाल और जवाब
- पहले, यह सिर्फ़ आरएजी की मदद से किया जा सकता था. इसकी वजह यह थी कि कॉन्टेक्स्ट की मात्रा सीमित थी और मॉडल, तथ्यों को सही तरीके से याद नहीं रख पाते थे
- एजेंटिक वर्कफ़्लो
- टेक्स्ट के ज़रिए ही एजेंट यह याद रखते हैं कि उन्होंने क्या काम किया है और उन्हें क्या काम करना है. दुनिया और एजेंट के लक्ष्य के बारे में पूरी जानकारी न होने की वजह से, एजेंट के भरोसेमंद होने की संभावना कम हो जाती है
लंबे कॉन्टेक्स्ट वाले मॉडल की मदद से, कॉन्टेक्स्ट के हिसाब से कई उदाहरणों के साथ जवाब देने की सुविधा मिलती है. यह सुविधा, सबसे खास सुविधाओं में से एक है. रिसर्च से पता चला है कि "सिंगल शॉट" या "मल्टी-शॉट" वाले सामान्य उदाहरणों का इस्तेमाल करके, मॉडल को किसी टास्क के एक या कुछ उदाहरणों के साथ पेश किया जाता है. इसके बाद, उसे सैकड़ों, हज़ारों या लाखों उदाहरणों तक बढ़ाया जाता है. इससे मॉडल की नई क्षमताएं सामने आ सकती हैं. यह भी देखा गया है कि कई उदाहरणों के साथ प्रॉम्प्ट देने का तरीका, किसी खास टास्क के लिए फ़ाइन-ट्यून किए गए मॉडल की तरह ही काम करता है. ऐसे मामलों में जहां Gemini मॉडल की परफ़ॉर्मेंस, प्रोडक्शन रोलआउट के लिए काफ़ी नहीं है, वहां कई शॉट वाले तरीके को आज़माया जा सकता है. जैसा कि आपने लॉन्ग कॉन्टेक्स्ट ऑप्टिमाइज़ेशन सेक्शन में देखा होगा, कॉन्टेक्स्ट के लिए कैश मेमोरी की सुविधा, इस तरह के ज़्यादा इनपुट टोकन वाले वर्कलोड को काफ़ी किफ़ायती बनाती है. साथ ही, कुछ मामलों में इंतज़ार का समय भी कम करती है.
लंबी अवधि के वीडियो
वीडियो कॉन्टेंट की उपयोगिता लंबे समय से सीमित रही है, क्योंकि यह माध्यम सभी के लिए सुलभ नहीं था. कॉन्टेंट को तेज़ी से पढ़ना मुश्किल था. ट्रांसक्रिप्ट अक्सर वीडियो की बारीकियों को कैप्चर नहीं कर पाती थीं. साथ ही, ज़्यादातर टूल इमेज, टेक्स्ट, और ऑडियो को एक साथ प्रोसेस नहीं करते थे. Gemini में, लंबे कॉन्टेक्स्ट वाले टेक्स्ट को प्रोसेस करने की क्षमता होती है. इससे, मल्टीमॉडल इनपुट के बारे में तर्क करने और सवालों के जवाब देने की क्षमता मिलती है. साथ ही, यह लगातार बेहतर परफ़ॉर्म करता है.
वीडियो के लंबे कॉन्टेक्स्ट के लिए, इस्तेमाल के कुछ नए और स्टैंडर्ड उदाहरण यहां दिए गए हैं:
- वीडियो से जुड़े सवाल और जवाब
- वीडियो मेमोरी, जैसा कि Google के Project Astra में दिखाया गया है
- वीडियो के लिए कैप्शन
- वीडियो के सुझाव देने वाले सिस्टम, मौजूदा मेटाडेटा को टेक्स्ट, इमेज वग़ैरह को प्रोसेस करने वाले नए मॉडल के साथ बेहतर बनाते हैं
- वीडियो को पसंद के मुताबिक बनाना. इसके लिए, डेटा के कॉर्पस और उससे जुड़े वीडियो के मेटाडेटा को देखा जाता है. इसके बाद, वीडियो के उन हिस्सों को हटा दिया जाता है जो दर्शक के लिए काम के नहीं होते
- वीडियो कॉन्टेंट को मॉडरेट करना
- रीयल-टाइम वीडियो प्रोसेसिंग
वीडियो के साथ काम करते समय, यह ध्यान रखना ज़रूरी है कि वीडियो को टोकन में कैसे प्रोसेस किया जाता है. इससे बिलिंग और इस्तेमाल करने की सीमाओं पर असर पड़ता है. प्रॉम्प्टिंग गाइड में, वीडियो फ़ाइलों के साथ प्रॉम्प्ट करने के बारे में ज़्यादा जानकारी दी गई है.
लंबी अवधि का ऑडियो
Gemini मॉडल, पहले ऐसे नेटिव मल्टीमॉडल लार्ज लैंग्वेज मॉडल थे जो ऑडियो को समझ सकते थे. आम तौर पर, डेवलपर के वर्कफ़्लो में ऑडियो को प्रोसेस करने के लिए, डोमेन के हिसाब से कई मॉडल को एक साथ इस्तेमाल किया जाता था. जैसे, बोली को लिखाई में बदलने वाला मॉडल और टेक्स्ट प्रॉम्प्ट से टेक्स्ट जनरेट होने की प्रोसेस वाला मॉडल. इसकी वजह से, कई बार अनुरोध करने और जवाब पाने में ज़्यादा समय लगता था. साथ ही, कई मॉडल सेटअप के डिसकनेक्ट किए गए आर्किटेक्चर की वजह से, परफ़ॉर्मेंस में कमी आती थी.
ऑडियो कॉन्टेक्स्ट के कुछ नए और स्टैंडर्ड इस्तेमाल के उदाहरणों में ये शामिल हैं:
- बोले जा रहे शब्दों को रीयल-टाइम में टेक्स्ट में बदलने और अनुवाद की सुविधा
- पॉडकास्ट / वीडियो से जुड़े सवाल और जवाब
- मीटिंग में बोले जा रहे शब्दों को टेक्स्ट में बदलने और खास जानकारी पाने की सुविधा
- वॉइस असिस्टेंट
ऑडियो फ़ाइलों के साथ प्रॉम्प्ट देने के बारे में ज़्यादा जानने के लिए, प्रॉम्प्ट देने से जुड़ी गाइड पर जाएं.
लंबे कॉन्टेक्स्ट के लिए ऑप्टिमाइज़ेशन
लंबे कॉन्टेक्स्ट और Gemini मॉडल के साथ काम करते समय, मुख्य ऑप्टिमाइज़ेशन के लिए कॉन्टेक्स्ट के लिए कैश मेमोरी का इस्तेमाल करना ज़रूरी है. पहले, एक अनुरोध में कई टोकन प्रोसेस नहीं किए जा सकते थे. इसके अलावा, एक और मुख्य समस्या यह थी कि ऐसा करने पर ज़्यादा शुल्क लगता था. अगर आपके पास "अपने डेटा से चैट करें" ऐप्लिकेशन है, जहां कोई उपयोगकर्ता 10 PDF, एक वीडियो, और कुछ ऑफ़िस के दस्तावेज़ अपलोड करता है, तो आपको इन अनुरोधों को प्रोसेस करने के लिए, ज़्यादा जटिल RAG टूल या फ़्रेमवर्क का इस्तेमाल करना होगा. साथ ही, कॉन्टेक्स्ट विंडो में ले जाए गए टोकन के लिए, आपको काफ़ी ज़्यादा रकम चुकानी होगी. अब, उपयोगकर्ता की अपलोड की गई फ़ाइलों को कैश मेमोरी में सेव किया जा सकता है. साथ ही, उन्हें हर घंटे के हिसाब से सेव करने के लिए पेमेंट किया जा सकता है. उदाहरण के लिए, Gemini Flash के साथ हर अनुरोध के लिए इनपुट / आउटपुट की लागत, स्टैंडर्ड इनपुट / आउटपुट की लागत से ~4 गुना कम है. इसलिए, अगर उपयोगकर्ता अपने डेटा के साथ चैट करता है, तो डेवलपर के तौर पर आपकी काफ़ी बचत होती है.
लंबे कॉन्टेक्स्ट की सीमाएं
इस गाइड के अलग-अलग सेक्शन में, हमने इस बारे में बात की है कि Gemini मॉडल, भूसे के ढेर में सुई ढूंढने जैसे मुश्किल टास्क को पूरा करने के लिए, अलग-अलग तरह के इवैल्युएशन में बेहतर परफ़ॉर्मेंस कैसे देते हैं. इन टेस्ट में सबसे बुनियादी सेटअप को ध्यान में रखा जाता है. इसमें आपके पास एक सुई होती है, जिसे आपको ढूंढना होता है. अगर आपको कई "नीडल" या जानकारी के कुछ खास हिस्सों को ढूंढना है, तो मॉडल उतनी सटीक जानकारी नहीं दे पाता. कॉन्टेक्स्ट के हिसाब से, परफ़ॉर्मेंस में काफ़ी अंतर आ सकता है. इस पर विचार करना ज़रूरी है, क्योंकि सही जानकारी पाने और लागत के बीच एक स्वाभाविक समझौता होता है. आपको एक ही क्वेरी पर ~99% कैश हिट रेट मिल सकता है. हालांकि, आपको हर बार उस क्वेरी को भेजने पर इनपुट टोकन की लागत चुकानी होगी. इसलिए, 100 आइटम की जानकारी पाने के लिए, अगर आपको 99% परफ़ॉर्मेंस की ज़रूरत है, तो आपको 100 अनुरोध भेजने होंगे. यह इस बात का अच्छा उदाहरण है कि कॉन्टेक्स्ट के लिए कैश मेमोरी की सुविधा, Gemini मॉडल का इस्तेमाल करने की लागत को काफ़ी कम कर सकती है. साथ ही, इससे परफ़ॉर्मेंस भी बेहतर बनी रहती है.
अक्सर पूछे जाने वाले सवाल
कॉन्टेक्स्ट विंडो में अपनी क्वेरी कहां डालनी चाहिए?
ज़्यादातर मामलों में, मॉडल की परफ़ॉर्मेंस बेहतर होगी. खास तौर पर, तब जब पूरा कॉन्टेक्स्ट लंबा हो. इसके लिए, आपको अपनी क्वेरी / सवाल को प्रॉम्प्ट के आखिर में (अन्य सभी कॉन्टेक्स्ट के बाद) रखना होगा.
क्या क्वेरी में ज़्यादा टोकन जोड़ने से, मॉडल की परफ़ॉर्मेंस पर असर पड़ता है?
आम तौर पर, अगर आपको मॉडल को टोकन पास करने की ज़रूरत नहीं है, तो उन्हें पास न करना सबसे अच्छा होता है. हालांकि, अगर आपके पास टोकन का बड़ा हिस्सा है, जिसमें कुछ जानकारी है और आपको उस जानकारी के बारे में सवाल पूछने हैं, तो मॉडल उस जानकारी को निकालने में बहुत ज़्यादा सक्षम है. कई मामलों में, यह 99% तक सटीक जानकारी निकाल सकता है.
मैं लंबी क्वेरी के लिए, लागत कैसे कम करूं?
अगर आपके पास टोकन / कॉन्टेक्स्ट का ऐसा सेट है जिसका इस्तेमाल आपको कई बार करना है, तो कॉन्टेक्स्ट कैश मेमोरी का इस्तेमाल करें. इससे उस जानकारी के बारे में सवाल पूछने से जुड़ी लागत कम हो सकती है.
क्या कॉन्टेक्स्ट की लंबाई से मॉडल की लेटेंसी पर असर पड़ता है?
किसी भी अनुरोध में कुछ समय लगता है. यह समय अनुरोध के साइज़ पर निर्भर नहीं करता. हालांकि, आम तौर पर लंबी क्वेरी में ज़्यादा समय लगता है (पहले टोकन के लिए समय).