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's Project Astra में दिखाया गया है
- वीडियो में कैप्शन जोड़ना
- वीडियो के सुझाव देने वाले सिस्टम. इसके लिए, मौजूदा मेटाडेटा को टेक्स्ट, इमेज वग़ैरह को प्रोसेस करने वाले मॉडल से मिली नई जानकारी के साथ बेहतर बनाया जाता है
- वीडियो को पसंद के मुताबिक बनाना. इसके लिए, डेटा के कॉर्पस और वीडियो के मेटाडेटा को देखा जाता है. इसके बाद, वीडियो के उन हिस्सों को हटाया जाता है जो दर्शकों के लिए काम के नहीं हैं
- वीडियो कॉन्टेंट को मॉडरेट करना
- वीडियो को रीयल-टाइम में प्रोसेस करना
वीडियो के साथ काम करते समय, यह ध्यान रखना ज़रूरी है कि वीडियो को टोकन में कैसे प्रोसेस किया जाता है. इससे बिलिंग और इस्तेमाल करने की सीमाओं पर असर पड़ता है. प्रॉम्प्टिंग गाइड में जाकर, वीडियो फ़ाइलों के साथ प्रॉम्प्ट करने के बारे में ज़्यादा जानें.
लंबी अवधि के ऑडियो
Gemini मॉडल, अलग-अलग सोर्स से मिले इनपुट को समझने वाले पहले लार्ज लैंग्वेज मॉडल थे, जो ऑडियो को समझ सकते थे. पहले, डेवलपर के वर्कफ़्लो में, अलग-अलग डोमेन के खास मॉडल को एक साथ इस्तेमाल करना पड़ता था. जैसे, ऑडियो को प्रोसेस करने के लिए, बोली को लिखाई में बदलने वाला मॉडल और टेक्स्ट प्रॉम्प्ट से टेक्स्ट जनरेट होने की प्रोसेस वाला मॉडल. इससे, राउंड-ट्रिप के कई अनुरोध करने की वजह से, अतिरिक्त लेटेंसी की ज़रूरत पड़ती थी. साथ ही, परफ़ॉर्मेंस में कमी आती थी. इसकी वजह यह थी कि कई मॉडल सेटअप के आर्किटेक्चर अलग-अलग होते थे.
ऑडियो कॉन्टेक्स्ट के इस्तेमाल के कुछ नए और स्टैंडर्ड उदाहरण यहां दिए गए हैं:
- बोले जा रहे शब्दों को रीयल-टाइम में टेक्स्ट में बदलने और अनुवाद की सुविधा
- पॉडकास्ट / वीडियो से जुड़े सवाल और जवाब
- मीटिंग में बोले जा रहे शब्दों को टेक्स्ट में बदलने और खास जानकारी तैयार करने की सुविधा
- वॉइस असिस्टेंट
प्रॉम्प्टिंग गाइड में जाकर, ऑडियो फ़ाइलों के साथ प्रॉम्प्ट करने के बारे में ज़्यादा जानें.
लंबी कॉन्टेक्स्ट विंडो को ऑप्टिमाइज़ करना
लंबी कॉन्टेक्स्ट विंडो और Gemini मॉडल के साथ काम करते समय, ऑप्टिमाइज़ेशन का मुख्य तरीका, कॉन्टेक्स्ट कैशिंग का इस्तेमाल करना है. एक ही अनुरोध में ज़्यादा टोकन प्रोसेस न कर पाने की समस्या के अलावा, दूसरी मुख्य समस्या लागत थी. अगर आपके पास "अपने डेटा के साथ चैट करें" वाला कोई ऐप्लिकेशन है, जिसमें कोई उपयोगकर्ता 10 पीडीएफ़, एक वीडियो, और काम से जुड़े कुछ दस्तावेज़ अपलोड करता है, तो इन अनुरोधों को प्रोसेस करने के लिए, आपको ज़्यादा जटिल रिट्रीवल ऑगमेंटेड जनरेशन (आरएजी) टूल / फ़्रेमवर्क का इस्तेमाल करना पड़ता था. साथ ही, कॉन्टेक्स्ट विंडो में ले जाए गए टोकन के लिए, ज़्यादा पेमेंट करना पड़ता था. अब, उपयोगकर्ता की अपलोड की गई फ़ाइलों को कैश किया जा सकता है और उन्हें हर घंटे के हिसाब से स्टोर करने के लिए पेमेंट किया जा सकता है. उदाहरण के लिए, Gemini Flash के साथ, हर अनुरोध के लिए इनपुट / आउटपुट की लागत, स्टैंडर्ड इनपुट / आउटपुट लागत से ~4 गुना कम होती है. इसलिए, अगर उपयोगकर्ता अपने डेटा के साथ ज़्यादा चैट करता है, तो डेवलपर के तौर पर आपके लिए यह लागत में काफ़ी बचत साबित हो सकती है.
लंबी कॉन्टेक्स्ट विंडो की सीमाएं
इस गाइड के अलग-अलग सेक्शन में, हमने बताया है कि Gemini मॉडल, अलग-अलग नीडल-इन-अ-हेस्टैक रिट्रीवल इवैल में बेहतर परफ़ॉर्मेंस कैसे देते हैं. इन टेस्ट में, सबसे बुनियादी सेटअप को ध्यान में रखा जाता है. इसमें, आपको सिर्फ़ एक नीडल ढूंढनी होती है. अगर आपको एक से ज़्यादा "नीडल" या जानकारी के खास हिस्से ढूंढने हैं, तो मॉडल उतनी सटीक परफ़ॉर्मेंस नहीं देता. कॉन्टेक्स्ट के आधार पर, परफ़ॉर्मेंस में काफ़ी अंतर आ सकता है. यह ध्यान रखना ज़रूरी है, क्योंकि सही जानकारी पाने और लागत के बीच, स्वाभाविक रूप से समझौता करना पड़ता है. एक क्वेरी पर ~99% सटीक जवाब मिल सकता है. हालांकि, उस क्वेरी को भेजने पर, आपको हर बार इनपुट टोकन की लागत चुकानी होगी. इसलिए, अगर आपको 100 तरह की जानकारी चाहिए और आपको 99% सटीक जवाब चाहिए, तो आपको 100 अनुरोध भेजने होंगे. यह एक अच्छा उदाहरण है कि कॉन्टेक्स्ट कैशिंग की मदद से, Gemini मॉडल का इस्तेमाल करने से जुड़ी लागत को काफ़ी कम किया जा सकता है. साथ ही, परफ़ॉर्मेंस को बेहतर बनाए रखा जा सकता है.
अक्सर पूछे जाने वाले सवाल
कॉन्टेक्स्ट विंडो में, अपनी क्वेरी कहां डालें?
ज़्यादातर मामलों में, खास तौर पर अगर कुल कॉन्टेक्स्ट लंबा है, तो मॉडल की परफ़ॉर्मेंस बेहतर होगी. इसके लिए, अपनी क्वेरी / सवाल को प्रॉम्प्ट के आखिर में (अन्य सभी कॉन्टेक्स्ट के बाद) डालें.
किसी क्वेरी में ज़्यादा टोकन जोड़ने पर, क्या मॉडल की परफ़ॉर्मेंस कम हो जाती है?
आम तौर पर, अगर मॉडल को टोकन पास करने की ज़रूरत नहीं है, तो उन्हें पास न करना ही बेहतर है. हालांकि, अगर आपके पास कुछ जानकारी वाले टोकन का बड़ा हिस्सा है और आपको उस जानकारी के बारे में सवाल पूछने हैं, तो मॉडल उस जानकारी को निकालने में काफ़ी सक्षम है. कई मामलों में, यह 99% तक सटीक जवाब दे सकता है.
लंबी कॉन्टेक्स्ट विंडो वाली क्वेरी के साथ, लागत कैसे कम की जा सकती है?
अगर आपके पास टोकन / कॉन्टेक्स्ट का ऐसा सेट है जिसे आपको कई बार इस्तेमाल करना है, तो कॉन्टेक्स्ट कैशिंग की मदद से, उस जानकारी के बारे में सवाल पूछने से जुड़ी लागत को कम किया जा सकता है.
क्या कॉन्टेक्स्ट की लंबाई से मॉडल की लेटेंसी पर असर पड़ता है?
किसी भी अनुरोध में, साइज़ के बावजूद, कुछ तय लेटेंसी होती है. हालांकि, आम तौर पर लंबी क्वेरी में ज़्यादा लेटेंसी (पहले टोकन में लगने वाला समय) होती है.