खरोखर काम करणारी AI ॲप्लिकेशन्स तयार करणे हे केवळ एक परफेक्ट प्रॉम्प्ट तयार करण्याबद्दल नसून, तुम्ही मॉडेलला पुरवलेली माहिती नियंत्रित करण्याबद्दल अधिक आहे. जर तुम्ही कधी एखाद्या असिस्टंटसोबत दीर्घ चॅटमध्ये बसला असाल आणि तुम्हाला अचानक लक्षात आले असेल की त्याने दहा मिनिटांपूर्वी तुम्ही सांगितलेली गोष्ट विसरली आहे, तर कॉन्टेक्स्ट इंजिनीअरिंग (context engineering) का अपयशी ठरते, याचा अनुभव तुम्हाला आधीच आला असेल. AI ची स्मरणशक्ती खराब आहे असे मानणे सोपे आहे. पण प्रत्यक्षात, तुम्ही कॉन्टेक्स्ट विंडोच्या (context window) कडक मर्यादांना भिडला होतात.

विश्वासार्ह आणि प्रतिसाद देणारी सिस्टीम तयार करण्यासाठी, तुम्हाला तीन मूलभूत गोष्टी समजून घेणे आवश्यक आहे: टोकन्स (tokens), कॉन्टेक्स्ट विंडो (context windows), आणि कॉन्टेक्स्ट आणि मेमरीमधील फरक.

टोकन्स हेच खरे चलन आहेत

टोकन म्हणजे शब्द नव्हे. जेव्हा तुम्ही मॉडेलला मजकूर पाठवता, तेव्हा टोकनायझर (tokenizer) त्याचे लहान तुकड्यांमध्ये विभाजन करतो. "cat" किंवा "the" सारखे लहान आणि सामान्य शब्द प्रत्येकी एक टोकन घेऊ शकतात. "internationalization" सारखा तांत्रिक शब्द अनेक तुकड्यांमध्ये विभागला जातो. विरामचिन्हे, स्पेस आणि विशेष चिन्हे देखील मोजली जातात. हे महत्त्वाचे आहे कारण टोकन्स सर्व गोष्टींवर नियंत्रण ठेवतात: तुमचे API बिल, प्रतिसादाचा वेग आणि आउटपुटची गुणवत्ता.

जो डेव्हलपर शब्दांची गणना करून खर्चाचे नियोजन करतो, तो दिशाहीन काम करत असतो. कोड ब्रॅकेट्स आणि लांब व्हेरिएबल नावांनी भरलेला शंभर शब्दांचा प्रॉम्प्ट अपेक्षेपेक्षा खूप जास्त खर्च वाढवू शकतो. म्हणूनच टोकनायझर्स स्वतंत्र टूल्स म्हणून अस्तित्वात आहेत. एखादे फीचर रिलीज करण्यापूर्वी, तुमचे सामान्य पेलोड्स (payloads) एका टोकनायझरमधून चालवून पहा. तुम्हाला अनेकदा असे दिसून येईल की सिस्टम सूचना (system instructions), फॉरमॅटिंग बॉयलरप्लेट आणि चॅट हिस्ट्री तुमच्या प्रत्यक्ष युजर क्वेरीपेक्षा जास्त बजेट खर्च करतात. पहिल्या दिवसापासून टोकन्सकडे एक दुर्मिळ संसाधन म्हणून पहा.

कॉन्टेक्स्ट विंडो म्हणजे एक ठराविक आकाराचा व्हाईटबोर्ड आहे

कॉन्टेक्स्ट विंडो म्हणजे एका सिंगल रिक्वेस्टमध्ये मॉडेल किती माहिती पाहू शकते याचे एकूण प्रमाण. याला एका ठराविक आकाराच्या व्हाईटबोर्डसारखे समजा. तुम्ही त्यावर सिस्टम नियम, संभाषणाचा इतिहास, शोधलेली कागदपत्रे आणि सध्याचा प्रश्न भरू शकता. पण एकदा का पृष्ठभाग पूर्ण भरला की, काहीतरी सोडावे लागते. जुन्या नोंदी पुसून टाकाव्या लागतात, त्यांचे फोटो काढून सारांश लिहावा लागतो, अन्यथा बोर्ड ओव्हरफ्लो होतो.

आधुनिक मॉडेल्स काही हजार टोकन्सपासून ते लाखो टोकन्सपर्यंतच्या कॉन्टेक्स्ट विंडोची जाहिरात करतात. मोठ्या विंडोला अमर्याद स्टोरेज मानणे मोहक वाटते. पण तसे नाही. व्हाईटबोर्डला अजूनही कडा (edges) असतात. जेव्हा इतिहास मर्यादेपेक्षा जास्त होतो, तेव्हा ॲप्लिकेशनला जुने मेसेज काढून टाकावे लागतात किंवा ते कॉम्प्रेस करावे लागतात. ही मर्यादा समजून घेतल्यास तुम्हाला विंडोला डेटाबेसप्रमाणे न वापरता एक सक्रिय कार्यक्षेत्र (active workspace) म्हणून वापरण्यास मदत होईल.

कॉन्टेक्स्ट म्हणजे मेमरी नाही

येथे एक असा फरक आहे जो अनुभवी बिल्डर्सनाही गोंधळात टाकतो. मॉडेल स्वतः 'स्टेटलेस' (stateless) असते. ते तुम्हाला कालच्या, गेल्या आठवड्याच्या किंवा दहा मिनिटांपूर्वीच्या वेगळ्या सेशनमधील गोष्टी लक्षात ठेवत नाही. जेव्हा एखादे AI तुम्हाला असे आठवून देते की तुम्हाला JavaScript पेक्षा Python आवडते, किंवा तुम्हाला संक्षिप्त उत्तरे आवडतात, तेव्हा ती मेमरी ॲप्लिकेशन लेयरमध्ये असते, मॉडेलमध्ये नाही.

ॲप्लिकेशन ती तथ्ये डेटाबेस, कॅशे किंवा मेमरी स्टोअरमध्ये साठवते. प्रत्येक नवीन रिक्वेस्टवर, ते संबंधित प्रोफाइल डेटा पुन्हा प्रॉम्प्टमध्ये समाविष्ट (inject) करते. मॉडेल फक्त एक स्क्रिप्ट वाचत असते ज्यामध्ये पहिल्या अंकातील (act one) संवाद समाविष्ट असतात. त्याचे स्वतःचे कोणतेही कायमस्वरूपी अस्तित्व (persistent self) नसते. एकदा का तुम्ही हा फरक समजून घेतला की, तुमची आर्किटेक्चर बदलून जाईल. तुम्ही मॉडेलला लक्षात ठेवण्यास सांगणे थांबवाल आणि योग्य वेळी योग्य कॉन्टेक्स्ट मिळवून देणारी सिस्टीम डिझाइन करण्यास सुरुवात कराल.

जास्त कॉन्टेक्स्टमुळे उलट परिणाम का होऊ शकतात

सामान्य ज्ञान सांगते की अधिक बॅकग्राउंड माहितीमुळे अधिक चांगले उत्तर मिळायला हवे. पण अनेकदा याच्या उलट घडते. अतिरिक्त कॉन्टेक्स्टमुळे गोंधळ (noise) निर्माण होतो. जर तुम्हाला फक्त एक फंक्शन फिक्स करायचे असेल आणि तुम्ही मॉडेलला संपूर्ण कोडबेस देऊन टाकला, तर तुम्ही त्याला गोंधळातून सिग्नल शोधण्यास भाग पाडता. संशोधकांनी "Lost in the Middle" परिणाम ओळखला आहे: मॉडेल्स अनेकदा प्रॉम्प्टच्या सुरुवातीच्या आणि शेवटच्या भागातील तपशिलांकडे अधिक लक्ष देतात, तर मध्यभागी दडलेली माहिती दुर्लक्षित केली जाते किंवा तिचे महत्त्व कमी होते. ही अशी त्रुटी नाही जी तुम्ही शब्दांच्या फेरफारने सुधारू शकता. हे ट्रान्सफॉर्मर-आधारित आर्किटेक्चरमधील (transformer-based architectures) एक संरचनात्मक वर्तन आहे.

अवाढव्य प्रॉम्प्ट्समुळे तुमच्या खर्चावरही परिणाम होतो. प्रत्येक अतिरिक्त टोकनसाठी संगणकीय प्रक्रिया (computation) आवश्यक असते. यामुळे लॅटन्सी (latency) वाढते, खर्च वाढतो आणि वापरकर्त्याचा संयम कमी होतो. अप्रासंगिक कागदपत्रांनी भरलेला प्रॉम्प्ट विसंगती निर्माण करतो, मॉडेलचे लक्ष भरकटवतो आणि प्रतिसादाने चुकीच्या समस्येवर लक्ष केंद्रित करण्याची शक्यता वाढवतो. माहितीचा अतिरेक हा अचूकतेचा शत्रू आहे.

अधिक चांगल्या प्रकारे कॉन्टेक्स्ट इंजिनीअरिंग कसे करावे

चांगले कॉन्टेक्स्ट इंजिनीअरिंग हे कठोर संपादनाचे (ruthless editing) एक कार्य आहे. ते प्रत्यक्ष अमलात आणण्याचे मार्ग खालीलप्रमाणे आहेत.

केवळ कामासाठी आवश्यक असलेली माहितीच पाठवा. जर वापरकर्त्याने तुमच्या रिफंड पॉलिसीबद्दल विचारले, तर त्यात कर्मचारी पुस्तिका (employee handbook), API डॉक्युमेंटेशन आणि गेल्या तिमाहीची मार्केटिंग कॉपी समाविष्ट करू नका. सर्व माहिती देण्यापेक्षा सुसंगतता (relevance) अधिक महत्त्वाची आहे.

संबंधित कागदपत्रे मिळवण्यासाठी RAG चा वापर करा. Retrieval-Augmented Generation तुम्हाला मोठ्या ज्ञानकोशात (knowledge base) शोध घेण्यास आणि केवळ सर्वाधिक जुळणारे उतारे प्रॉम्प्टमध्ये (prompt) समाविष्ट करण्यास अनुमती देते. विंडोमध्ये हजार पानांचे मॅन्युअल टाकण्याऐवजी, तुम्ही तुमची कागदपत्रे एम्बेड (embed) करता, वापरकर्त्याच्या क्वेरीनुसार सिमेंटिक सर्च (semantic search) करता आणि सर्वात संबंधित तीन परिच्छेद समाविष्ट करता. मॉडेलला नेमकी हवी तीच माहिती मिळते आणि तुमचा टोकन बजेट (token budget) देखील सुरक्षित राहतो.

जुने संवाद सारांशित करा. पूर्ण चॅट ट्रान्सक्रिप्ट्स महागड्या आणि गोंधळ निर्माण करणाऱ्या असतात. लांबलचक मेसेज हिस्ट्रीऐवजी सतत अपडेट होणारे सारांश वापरा. उदाहरणार्थ, मॉडेलला तीस वेळा झालेली चॅट पाठवण्याऐवजी, एकच परिच्छेद साठवा: "वापरकर्त्याने Django deployment बद्दल विचारले, static files error आला आणि permissions दुरुस्त केल्या. सध्याची समस्या Postgres 14 वर database migration अयशस्वी होणे ही आहे." असा सारांश व्हाईटबोर्डवर गोंधळ न करता स्थिती (state) कायम ठेवतो.

दीर्घकालीन मेमरी आणि सक्रिय चॅट वेगळे ठेवा. वापरकर्त्याच्या आवडीनिवडी (preferences), प्रोजेक्ट सेटिंग्स आणि खाते इतिहास (account history) हे बाह्य मेमरी स्टोअरमध्ये (external memory store) असावेत. त्या स्टोअरमधून निवडक माहितीच क्वेरी करा. लाइव्ह कॉन्टेक्स्ट विंडोमध्ये (live context window) केवळ तात्काळ कार्य आणि सातत्य राखण्यासाठी आवश्यक असलेला अत्यंत संक्षिप्त वैयक्तिक संदर्भ असावा.

प्रोडक्शनमध्ये टोकन वापराचे निरीक्षण करा. लेटन्सी वाढण्याचे (latency spikes) मुख्य कारण अनेकदा कॉन्टेक्स्टचा अतिरेक (context bloat) हे असते. जेव्हा विनंत्या (requests) तुमच्या मॉडेलच्या मर्यादेच्या जवळ पोहोचतात, तेव्हा अलर्ट सेट करा. अनावश्यक माहिती असलेले प्रॉम्प्ट्स ओळखण्यासाठी लॉग्स तपासा. ऑप्टिमायझेशनची सुरुवात प्रत्येक वेळी एकाच प्रश्नाने होते: कार्य बिघडवून न टाकता आपण काय काढून टाकू शकतो?

मुख्य निष्कर्ष

सर्वोत्तम AI ॲप्लिकेशन्स त्यांच्याकडे सर्वात मोठे कॉन्टेक्स्ट विंडोज (context windows) असल्यामुळे जिंकत नाहीत. तर ते कॉन्टेक्स्टचे शिस्तबद्ध व्यवस्थापन करतात म्हणून जिंकतात. जर व्हाईटबोर्ड पूर्णपणे विस्कळीत नोंदींनी भरलेला असेल, तर तो निरुपयोगी ठरतो. असे सिस्टम्स तयार करा जे माहिती शोधतात (retrieve), सारांशित करतात (summarize) आणि फिल्टर करतात. यामुळे तुमच्या वापरकर्त्यांना जलद उत्तरे मिळतात, तुमच्या इन्फ्रास्ट्रक्चरचा खर्च अंदाजित राहतो आणि तुमचे मॉडेल्स शेवटी खरोखर महत्त्वाच्या गोष्टींकडे लक्ष देतात.

स्रोत: AI Context Engineering: Tokens, Context Windows, & Memory

समुदाय: GyaanSetu AI on Telegram