तुम्ही प्रॉम्प्टमध्ये शंभर पानांचे डॉक्युमेंटेशन पेस्ट करता आणि एक साधा प्रश्न विचारता. उत्तर चुकीचे येते. किंवा तुम्ही वर दिलेल्या फॉरमॅटिंग नियमांकडे ते दुर्लक्ष करते. तुम्ही त्याला सर्व काही दिले होते. ते काम करायला हवे होते. पण ते झाले नाही.
हा आहे कॉन्टेक्स्ट ट्रॅप (context trap). बहुतेक डेव्हलपर्सना असे वाटते की AI ला अधिक माहिती दिल्याने आपोआप चांगले परिणाम मिळतात. पण अनेकदा याच्या उलट घडते. विश्वसनीय AI ॲप्लिकेशन्स तयार करण्यासाठी तीन मुख्य गोष्टी समजून घेणे आवश्यक आहे: मॉडेल्स मजकूर कसा मोजतात, ते एका वेळी किती माहिती साठवू शकतात आणि संभाषण संपल्यानंतर माहितीचे काय होते.
टोकन्स: खरे चलन
टोकन ही लँग्वेज मॉडेलद्वारे प्रक्रिया केली जाणारी सर्वात लहान युनिट आहे. ते एक अक्षर, शब्दाचा तुकडा किंवा संपूर्ण सामान्य शब्द असू शकतो. "purchase" हा शब्द अनेकदा दोन टोकन्समध्ये विभागला जातो, तर "cat" सारखा छोटा शब्द पूर्ण राहतो. विरामचिन्हे आणि स्पेस देखील टोकन्स वापरतात. कोड विशेषतः जास्त टोकन्स खातो. नेस्टेड इंडेंटेशन आणि विशेष चिन्हे असलेला पायथन (Python) कोडचा ब्लॉक तुम्ही अंदाज लावू शकता त्यापेक्षा तीन किंवा चार पटीने जास्त टोकन्स घेऊ शकतो.
डेव्हलपर्सनी याची काळजी का घ्यावी? API चे दर प्रति टोकन असतात. तसेच प्रोसेसिंग वेळ देखील. दोन पानांच्या मजकुरासारखा दिसणारा प्रॉम्प्ट, त्यात काय आहे यावर अवलंबून काही पैसे किंवा डॉलर्स खर्च करू शकतो. अधिक वाईट म्हणजे, टोकन्स दोन्ही बाजूंनी मोजले जातात. तुम्ही तुमच्या प्रॉम्प्टमधील प्रत्येक टोकनसाठी पैसे देता आणि मॉडेलने तयार केलेल्या प्रत्येक टोकनसाठी देखील पैसे देता. अनियंत्रित कॉन्टेक्स्ट वाढीमुळे नफा (margins) हळूहळू कमी होत जातो.
कॉन्टेक्स्ट विंडो म्हणजे एक व्हाईटबोर्ड
कॉन्टेक्स्ट विंडो मॉडेल एका वेळी किती माहिती पाहू शकते याची मर्यादा ठरवते. एका लहान खोलीत टांगलेल्या व्हाईटबोर्डची कल्पना करा. तुम्ही तो सिस्टम सूचना (system instructions), वापरकर्त्याचे प्रश्न, शोधलेले दस्तऐवज आणि मागील संभाषण यांनी भरू शकता. पण बोर्ड कधीच मोठा होत नाही. जेव्हा नवीन मजकूर येतो, तेव्हा जुना मजकूर कडेने बाहेर पडतो.
हे महत्त्वाचे आहे कारण मॉडेलने मजकूर वगळायला सुरुवात केली की ते तुम्हाला सावध करत नाही. जर तुमची सिस्टम सूचना एखाद्या लांब संभाषणाच्या सुरुवातीला असेल आणि तुम्ही सतत संदेश जोडत गेलात, तर ती सूचना कालांतराने दृष्टीक्षेपाच्या बाहेर जाते. मॉडेल त्याच्या मूळ (default) वर्तनाकडे परत जाऊ शकते, तुमच्या फॉरमॅटिंग नियमांकडे दुर्लक्ष करू शकते किंवा आधीच्या मार्गदर्शनाच्या विरुद्ध वागू शकते. वेगवेगळ्या मॉडेल्सच्या मर्यादा वेगवेगळ्या असतात, काही हजारो टोकन्स हाताळतात तर काही लाखो, परंतु कार्यपद्धती सारखीच असते. इनपुट आणि आउटपुट एकाच बजेटमध्ये विभागले जातात. जे मॉडेल दोन हजार टोकन्सचे उत्तर देते, त्याच्याकडे तुम्ही सांगितलेली गोष्ट लक्षात ठेवण्यासाठी दोन हजार टोकन्स कमी उपलब्ध असतात.
मेमरी ही एक हॅक आहे, फीचर नाही
इन्फरन्स (inference) दरम्यान मॉडेल वेट्समध्ये (model weights) कोणतीही कायमस्वरूपी मेमरी नसते. अजिबात नाही. जेव्हा तुम्ही टॅब बंद करता आणि उद्या परत येता, तेव्हा मॉडेल तुम्हाला ओळखत नाही. प्रत्येक API कॉल हा एक 'कोल्ड स्टार्ट' (cold start) असतो.
जे मेमरीसारखे वाटते ते केवळ ॲप्लिकेशन लेयरद्वारे केलेले चपळ व्यवस्थापन (bookkeeping) आहे. फ्रंटएंड तुमचे संदेश डेटाबेसमध्ये साठवते. जेव्हा तुम्ही नवीन क्वेरी पाठवता, तेव्हा सॉफ्टवेअर संबंधित इतिहास घेते, त्याला एका नवीन प्रॉम्प्टमध्ये गुंफते आणि संपूर्ण पॅकेज मॉडेलकडे पाठवते. मॉडेलला याची काहीही कल्पना नसते.
उत्पादन टीम्ससाठी (product teams) हा फरक अत्यंत महत्त्वाचा आहे. जर तुम्ही वापरकर्त्याची पसंती "लक्षात ठेवण्यासाठी" मॉडेलवर अवलंबून असाल, तर तुम्ही वाळूवर इमारत बांधत आहात. तुम्हाला स्वतःला 'स्टेट मॅनेजमेंट' (state management) तयार करावे लागेल. काय कॅश (cache) करायचे ते ठरवा. ते कसे रिफ्रेश करायचे ते ठरवा. आणि हे लक्षात घ्या की तुम्ही पुन्हा पाठवलेला इतिहासाचा प्रत्येक बाईट तुमच्या व्हाईटबोर्डची जागा खातो.
जेव्हा कॉन्टेक्स्ट गोंधळ (Noise) बनतो
प्रॉम्प्टमध्ये खूप जास्त माहिती भरल्याने अपेक्षित नसलेले परिणाम मिळू शकतात.
गोंधळ (Noise) सिग्नल नष्ट करतो. जर तुम्ही एका बगबद्दल विचारण्यासाठी संपूर्ण कोडबेस टाकला, तर मॉडेलसमोर 'सुई शोधण्यासारखी' (needle-in-a-haystack) समस्या उभी राहते. ते चुकीच्या फाईलचा संदर्भ देऊ शकते, डेड कोडमध्ये (dead code) बदल सुचवू शकते किंवा सामान्य उत्तर देऊ शकते कारण ते