वास्तव में काम करने वाले AI एप्लिकेशन बनाना केवल एक सटीक प्रॉम्प्ट तैयार करने के बारे में नहीं है, बल्कि उस जानकारी को नियंत्रित करने के बारे में है जिसे आप मॉडल में डालते हैं। यदि आपने कभी किसी असिस्टेंट के साथ लंबी चैट की है और फिर आपको एहसास हुआ कि वह दस मिनट पहले कही गई कोई बात भूल गया है, तो आपने पहले ही महसूस कर लिया है कि कॉन्टेक्स्ट इंजीनियरिंग (context engineering) विफल होने पर क्या होता है। यह मान लेना आसान है कि AI की याददाश्त खराब है। वास्तव में, आप कॉन्टेक्स्ट विंडो (context window) की कठिन सीमाओं से टकरा गए थे।
विश्वसनीय और उत्तरदायी (responsive) सिस्टम बनाने के लिए, आपको तीन बुनियादी बातों को समझने की आवश्यकता है: टोकन (tokens), कॉन्टेक्स्ट विंडो (context windows), और कॉन्टेक्स्ट तथा मेमोरी (memory) के बीच का अंतर।
टोकन ही असली मुद्रा हैं
टोकन कोई शब्द नहीं है। जब आप किसी मॉडल को टेक्स्ट भेजते हैं, तो एक टोकनाइज़र (tokenizer) उसे छोटे टुकड़ों में तोड़ देता है। "cat" या "the" जैसे छोटे सामान्य शब्द प्रत्येक एक टोकन भर सकते हैं। "internationalization" जैसे घने तकनीकी शब्द को कई हिस्सों में काट दिया जाता है। विराम चिह्न, स्पेस और विशेष वर्ण भी गिने जाते हैं। यह महत्वपूर्ण है क्योंकि टोकन सब कुछ नियंत्रित करते हैं: आपका API बिल, प्रतिक्रिया की गति और आउटपुट की गुणवत्ता।
जो डेवलपर शब्दों को गिनकर लागत की योजना बनाता है, वह अंधेरे में तीर चला रहा है। कोड ब्रैकेट और लंबे वेरिएबल नामों से भरा सौ शब्दों का प्रॉम्प्ट उम्मीदों से कहीं अधिक बढ़ सकता है। इसीलिए टोकनाइज़र स्टैंडअलोन टूल के रूप में मौजूद हैं। कोई फीचर लॉन्च करने से पहले, अपने सामान्य पेलोड (payloads) को एक टोकनाइज़र के माध्यम से चलाकर देखें। आप अक्सर पाएंगे कि सिस्टम निर्देश, फॉर्मेटिंग बॉयलरप्लेट (boilerplate) और चैट हिस्ट्री, वास्तविक यूजर क्वेरी की तुलना में आपके बजट का अधिक हिस्सा खा जाते हैं। पहले दिन से ही टोकन को एक दुर्लभ संसाधन के रूप में मानें।
कॉन्टेक्स्ट विंडो एक निश्चित व्हाइटबोर्ड है
कॉन्टेक्स्ट विंडो उस जानकारी की कुल मात्रा है जिसे एक मॉडल एक ही अनुरोध (request) में देख सकता है। इसे निश्चित आयामों वाले एक व्हाइटबोर्ड के रूप में सोचें। आप इसे सिस्टम नियमों, बातचीत के इतिहास, प्राप्त दस्तावेजों और वर्तमान प्रश्न से भर सकते हैं। लेकिन एक बार सतह भर जाने के बाद, कुछ न कुछ कम करना ही होगा। पुराने नोट्स को मिटाना होगा, उनकी फोटो लेनी होगी और उन्हें सारांशित (summarize) करना होगा, अन्यथा बोर्ड भर जाएगा।
आधुनिक मॉडल कुछ हज़ार टोकन से लेकर सैकड़ों हज़ार टोकन तक की कॉन्टेक्स्ट विंडो का विज्ञापन करते हैं। बड़ी विंडो को असीमित स्टोरेज मानना लुभावना हो सकता है। लेकिन ऐसा नहीं है। व्हाइटबोर्ड की भी सीमाएं होती हैं। जब इतिहास सीमा से अधिक हो जाता है, तो एप्लिकेशन को पुराने संदेशों को हटाना पड़ता है या उन्हें कंप्रेस (compress) करना पड़ता है। इस बाधा को समझने से आपको विंडो को डेटाबेस की तरह नहीं, बल्कि एक सक्रिय कार्यक्षेत्र (active workspace) की तरह देखने में मदद मिलती है।
कॉन्टेक्स्ट मेमोरी नहीं है
यहाँ एक ऐसा अंतर है जो अनुभवी बिल्डर्स को भी भ्रमित कर देता है। मॉडल स्वयं 'स्टेटलेस' (stateless) होता है। यह आपको कल, पिछले सप्ताह, या दस मिनट पहले के किसी अलग सत्र (session) से याद नहीं रखता है। जब कोई AI ऐसा लगता है कि उसे याद है कि आप JavaScript के बजाय Python पसंद करते हैं, या आपको संक्षिप्त उत्तर पसंद हैं, तो वह मेमोरी एप्लिकेशन लेयर में होती है, मॉडल में नहीं।
एप्लिकेशन उन तथ्यों को डेटाबेस, कैश (cache) या मेमोरी स्टोर में संग्रहीत करता है। प्रत्येक नए अनुरोध पर, यह प्रासंगिक प्रोफाइल डेटा को वापस प्रॉम्प्ट में इंजेक्ट करता है। मॉडल केवल एक स्क्रिप्ट पढ़ रहा होता है जिसमें उसके पहले अंक (act one) के संवाद शामिल होते हैं। उसका कोई स्थायी अस्तित्व (persistent self) नहीं होता। एक बार जब आप इस अलगाव को समझ लेते हैं, तो आपका आर्किटेक्चर बदल जाता है। आप मॉडल से याद रखने के लिए कहना बंद कर देते हैं और ऐसे सिस्टम डिजाइन करना शुरू कर देते हैं जो सही समय पर सही कॉन्टेक्स्ट प्राप्त करते हैं।
अधिक कॉन्टेक्स्ट उल्टा क्यों पड़ सकता है
सामान्य ज्ञान कहता है कि अधिक बैकग्राउंड जानकारी से बेहतर उत्तर मिलने चाहिए। अक्सर, इसके विपरीत होता है। अत्यधिक कॉन्टेक्स्ट शोर (noise) पैदा करता है। यदि आप मॉडल को पूरा कोडबेस सौंप देते हैं जबकि आपको केवल एक फंक्शन ठीक करने की आवश्यकता है, तो आप उसे शोर (static) में संकेत (signal) खोजने के लिए मजबूर करते हैं। शोधकर्ताओं ने "Lost in the Middle" प्रभाव की पहचान की है: मॉडल अक्सर प्रॉम्प्ट की शुरुआत और अंत के विवरणों पर अधिक ध्यान देते हैं, जबकि बीच में दबी हुई जानकारी कम हो जाती है या अनदेखी कर दी जाती है। यह कोई बग नहीं है जिसे आप चालाकी भरी शब्दावली से ठीक कर सकें। यह ट्रांसफॉर्मर-आधारित आर्किटेक्चर में मौजूद एक संरचनात्मक व्यवहार है।
भारी-भरकम प्रॉम्प्ट आपको वहीं चोट पहुँचाते हैं जहाँ दर्द होता है। प्रत्येक अतिरिक्त टोकन के लिए गणना (computation) की आवश्यकता होती है। लेटेंसी (latency) बढ़ती है। लागत बढ़ती है। उपयोगकर्ता का धैर्य कम होता है। अप्रासंगिक दस्तावेजों से भरा प्रॉम्प्ट विरोधाभास पैदा करता है, मॉडल को अप्रासंगिक विवरणों से भटकाता है, और इस बात की संभावना बढ़ा देता है कि प्रतिक्रिया गलत समस्या पर केंद्रित हो जाए। मात्रा (volume) सटीकता की दुश्मन है।
बेहतर कॉन्टेक्स्ट को कैसे इंजीनियर करें
अच्छा कॉन्टेक्स्ट इंजीनियरिंग कठोर संपादन (ruthless editing) का अभ्यास है। इसे व्यवहार में लाने का तरीका यहाँ दिया गया है।
केवल वही भेजें जो कार्य के लिए आवश्यक हो। यदि कोई उपयोगकर्ता आपकी रिफंड पॉलिसी के बारे में पूछता है, तो उसमें एम्प्लॉई हैंडबुक, API डॉक्यूमेंटेशन और पिछली तिमाही का मार्केटिंग कॉपी शामिल न करें। व्यापकता से अधिक प्रासंगिकता महत्वपूर्ण है।
प्रासंगिक दस्तावेज़ों को प्राप्त करने के लिए RAG का उपयोग करें। Retrieval-Augmented Generation आपको एक बड़े नॉलेज बेस को खोजने और प्रॉम्प्ट में केवल सबसे सटीक मिलान वाले अंशों को शामिल करने की अनुमति देता है। विंडो में हज़ार पन्नों की मैनुअल डालने के बजाय, आप अपने दस्तावेज़ों को एम्बेड करते हैं, उपयोगकर्ता के प्रश्न के विरुद्ध एक सिमेंटिक सर्च चलाते हैं, और तीन सबसे प्रासंगिक पैराग्राफ शामिल करते हैं। मॉडल को वही मिलता है जिसकी उसे आवश्यकता है, और आपका टोकन बजट भी सुरक्षित रहता है।
पुरानी बातचीत का सारांश तैयार करें। चैट के पूरे ट्रांसक्रिप्ट महंगे और शोर भरे (noisy) होते हैं। लंबी मैसेज हिस्ट्री को निरंतर चलने वाले सारांशों (running summaries) से बदलें। उदाहरण के लिए, मॉडल को तीस बार-बार होने वाले मैसेज देने के बजाय, एक एकल पैराग्राफ स्टोर करें: "उपयोगकर्ता ने Django deployment के बारे में पूछा, एक static files error का सामना किया, और permissions ठीक कर दीं। वर्तमान समस्या Postgres 14 पर database migration का विफल होना है।" वह सारांश व्हाइटबोर्ड को अव्यवस्थित किए बिना स्थिति (state) को बनाए रखता है।
लॉन्ग-टर्म मेमोरी को एक्टिव चैट से अलग करें। उपयोगकर्ता की प्राथमिकताएं, प्रोजेक्ट सेटिंग्स और अकाउंट हिस्ट्री एक बाहरी मेमोरी स्टोर में होनी चाहिए। उस स्टोर से चुनिंदा रूप से क्वेरी करें। लाइव कॉन्टेक्स्ट विंडो में केवल तत्काल कार्य और निरंतरता बनाए रखने के लिए आवश्यक संक्षिप्त व्यक्तिगत संदर्भ ही होना चाहिए।
प्रोडक्शन में टोकन उपयोग की निगरानी करें। लेटेंसी स्पाइक्स (latency spikes) का सीधा संबंध अक्सर कॉन्टेक्स्ट के अत्यधिक विस्तार (context bloat) से होता है। जब अनुरोध आपके मॉडल की सीमा के करीब पहुँचें, तो अलर्ट सेट करें। उन प्रॉम्प्ट्स की पहचान करने के लिए लॉग्स की समीक्षा करें जो अनावश्यक भार (dead weight) ले जा रहे हैं। ऑप्टिमाइज़ेशन हर बार एक ही सवाल से शुरू होता है: हम कार्य को बाधित किए बिना क्या हटा सकते हैं?
असली निष्कर्ष
सर्वश्रेष्ठ AI एप्लिकेशन इसलिए नहीं जीतते क्योंकि उनके पास सबसे बड़े context windows होते हैं। वे इसलिए जीतते हैं क्योंकि वे अनुशासन के साथ context का प्रबंधन करते हैं। एक विशाल व्हाइटबोर्ड बेकार है यदि वह लकीरों से भरा हो। ऐसे सिस्टम बनाएं जो retrieve, summarize और filter करें। आपके उपयोगकर्ताओं को तेज़ उत्तर मिलते हैं, आपकी infrastructure लागत अनुमानित रहती है, और आपके मॉडल अंततः उस पर ध्यान देते हैं जो वास्तव में मायने रखता है।
स्रोत: AI Context Engineering: Tokens, Context Windows, & Memory
कम्युनिटी: GyaanSetu AI on Telegram