मला वाटले मी खूप हुशार आहे. मी एक हेल्पर फंक्शन लिहिले होते जे आमच्या AI पाइपलाइनसाठी कॉन्टेक्स्ट विंडोच्या नेमक्या तीस टक्के भागाला थिंकिंग बजेट म्हणून राखून ठेवत असे. ते स्वच्छ, प्रेडिक्टेबल होते आणि Opus 4.5 वर ते उत्तम प्रकारे काम करत होते. मग मी Opus 4.8 वर स्विच केले आणि प्रत्येक रिक्वेस्ट 400 एररसह फेल झाली. माझे काळजीपूर्वक तयार केलेले टोकन मॅथ रातोरात कचरा झाले होते.
जुना पॅटर्न साधा होता. तुम्ही budget_tokens व्हॅल्यू सेट करायचा आणि मॉडेल त्या मर्यादेत बसण्यासाठी आपल्या विचार प्रक्रियेचे नियोजन करायचे. जर मी 128K कॉन्टेक्स्ट दिले, तर माझा कोड रीझनिंगसाठी अंदाजे 38,000 टोकन्स वेगळे काढायचा आणि उरलेले टोकन्स उत्तरासाठी सोडायचा. ते जबाबदारीपूर्ण वाटत होते. जणू गाडी वेगाच्या मर्यादेत ठेवणे.
तो मॉडेल आता संपला आहे. Opus 4.7 आणि 4.8 सारखे नवीन रिलीज 'अॅडॉप्टिव्ह थिंकिंग' (adaptive thinking) वापरतात. तुम्हाला आता एखादी संख्या निवडण्याची गरज नाही. त्याऐवजी, तुम्ही एक 'एफर्ट नॉब' (effort knob) पास करता. हे फक्त नाव बदलल्यासारखे वाटू शकते, पण या दोन कंट्रोल्समध्ये जमीन-अस्मानाचा फरक आहे. budget_tokens मॉडेलला किती विचार करण्याची परवानगी आहे यावर एक कडक मर्यादा (hard ceiling) लावत असे. एफर्ट (Effort) मॉडेल नेमके कसे विचार करते आणि कसे कार्य करते हे नियंत्रित करते. एक म्हणजे पेट्रोल पंपाचा मीटर आहे, तर दुसरे म्हणजे इंजिन मॅप आहे.
एफर्टचे प्रत्यक्ष कामाशी मॅपिंग
जेव्हा कंट्रोल बदलला, तेव्हा माझी जुनी समज काम करणे थांबली. प्रत्येक सेटिंग प्रत्यक्षात काय देते, हे मला पुन्हा शिकावे लागले. प्रत्येक एफर्ट लेव्हल प्रत्यक्षात कुठे लागू होते हे शोधण्यासाठी मी आमच्या अंतर्गत ट्रॅफिकवर चाचण्या केल्या.
क्लासिफिकेशन आणि राउटिंग साठी जवळजवळ नेहमीच low एफर्ट वापरला पाहिजे. ही कामे जलद निर्णयांची असतात. ही रिफंड विनंती आहे की सेल्स प्रश्न? या लॉग एंट्रीला एस्केलेशनची गरज आहे का? तुम्हाला तिथे दीर्घ संवादाची (monologue) गरज नाही. low एफर्टमुळे लॅटन्सी कमी राहते आणि खर्चही नगण्य असतो.
बहुतेक ॲप ट्रॅफिक, जसे की दैनंदिन कामे - समरी तयार करणे, रीराईट्स, सपोर्ट रिप्लाय आणि कंटेंट एक्स्ट्रॅक्शन - हे medium ते high एफर्टमध्ये बसतात. हा एक समतोल बिंदू आहे. मॉडेलला अशा कामासाठी टोकन्स वाया न घालवता, जिथे दीर्घ विचार प्रक्रियेची (chain of thought) गरज नाही, तिथे अस्पष्टता सोडवण्यासाठी पुरेसा वाव मिळतो.
कोडिंग आणि एजेंटिक लूप्स साठी xhigh एफर्टची आवश्यकता असते. इथे चुकांचे परिणाम गंभीर असू शकतात. जर मॉडेलने टूल-कॉलिंग लूपच्या पहिल्या टर्नमध्येच चुकीचे नियोजन केले, तर ते पुढच्या तीन स्टेप्स फक्त तो गोंधळ सुधारण्यात घालवेल. किंवा त्याहून वाईट म्हणजे, ते चुकीची टूल्स कॉल करेल, पॅरामीटर्स हॅलुसिनेट करेल आणि वापरकर्त्याला तुटलेल्या वर्कफ्लोकडे पाहत ठेवेल. सुरुवातीलाच चांगले रीझनिंग असल्यास हे टाळता येते.
महत्त्वाची कामे (Critical tasks) यासाठी max एफर्ट वापरला पाहिजे. हे प्रत्येक गोष्टीसाठी वापरू नका. हे अशा क्षणांसाठी राखून ठेवा जिथे चुकीच्या उत्तरामुळे टोकन बिलापेक्षा जास्त नुकसान होऊ शकते. फायनान्शिअल रिकॉन्सिलिएशन, सेफ्टी चेक्स, आर्किटेक्चर डिसिजन आणि मेडिकल ट्रायज ही यासाठी योग्य कामे आहेत. जर एखाद्या चुकीमुळे मानवाला तासनतास तो गोंधळ सोडवावा लागणार असेल, तर अतिरिक्त विचार प्रक्रियेसाठी पैसे द्या.
खर्चाचा धक्का
येथे असा एक भाग आहे ज्याने माझी समज बदलली. मला वाटले होते की max एफर्टमुळे माझा खर्च नेहमीच वाढेल. एका सिंगल टर्नमध्ये तसे होतेच. रीझनिंग ट्रेस मोठा असतो. पण मल्टी-स्टेप एजेंटिक टास्कमध्ये, एकूण बिल अनेकदा कमी झाले.
मॉडेल पहिल्या प्रयत्नातच अधिक चांगले नियोजन करते. ते कमी टूल कॉल्स करते. ते स्वतःला चुकीच्या दिशांना जाण्यापासून रोखते. मी एका डेटा एक्स्ट्रॅक्शन एजंटचे निरीक्षण केले ज्याला सामान्यतः पाच फेऱ्यांची गरज पडायची, तो केवळ दोन फेऱ्यांत पूर्ण झाला, कारण मॉडेलकडे सुरुवातीलाच स्कीमा योग्यरित्या समजून घेण्यासाठी पुरेसे रीझनिंग स्पेस होते. जेव्हा तुम्ही खर्चाचे मोजमाप करता, तेव्हा प्रत्येक रिक्वेस्टचा नाही, तर काम पूर्ण होण्याचा विचार करा. प्रति स्टेप मोठा थिंकिंग बजेट म्हणजे एकूण स्टेप्स कमी होऊ शकतात.
इतर गोष्टी बिघडवून न टाकता मायग्रेट कसे करावे
जर तुमच्या कोडबेसमध्ये अजूनही budget_tokens वापरले जात असतील, तर बाहेर पडण्याचा नेमका मार्ग खालीलप्रमाणे आहे. स्टेप तीन आणि पाच वगळू नका. मी त्या वगळल्या होत्या आणि त्यामुळे मला डेबगिंगमध्ये अख्खी दुपार घालवावी लागली.
तुमच्या कोडमध्ये budget_tokens शोधा. प्रत्येक इन्स्टन्स काढून टाकणे आवश्यक आहे. नवीन मॉडेल्समध्ये हा पॅरामीटर आता अस्तित्वात नाही आणि तो वापरल्यास 400 एरर येईल.
बजेट ऑब्जेक्टच्या जागी अॅडॉप्टिव्ह थिंकिंग ब्लॉक वापरा. thinking: { type: "adaptive" } चा वापर करा.
प्रत्येक कॉलसाठी स्पष्ट एफर्ट लेव्हलसह output_config जोडा. जर तुमचे ट्रॅफिक मिश्र स्वरूपाचे असेल, तर हे ग्लोबल डिफॉल्टवर सोडू नका. तुमच्या हलक्या (lightweight) क्लासिफिकेशन एंडपॉइंटला चुकून तुमच्या कोडिंग एजंटसारखीच एफर्ट सेटिंग वारसा म्हणून मिळू नये. कॉल साइटवर स्पष्टता ठेवा.
तुमचे बजेट कॅल्क्युलेशन हेल्पर डिलीट करा. मला माहित आहे. कदाचित त्याचे युनिट टेस्ट्स असतील. माझे होते. पण आता ते निरुपयोगी ओझे आहे. प्लॅटफॉर्मला तुमच्या टोकन मॅथची गरज नाही. मॉडेल स्वतःच्या गतीचे नियोजन स्वतः करते.
temperature, top_p, आणि top_k काढून टाका. Opus 4.7 आणि 4.8 वर, हे सॅम्पलिंग पॅरामीटर्स (sampling parameters) 400 एरर्स देतील. प्लॅटफॉर्मने या जनरेशनमधून ते काढून टाकले आहेत. तुमच्या जुन्या टेम्परेचर-ट्यूनिंगच्या (temperature-tuning) युक्त्या येथे लागू होणार नाहीत आणि ते तसेच ठेवल्यास तुमचे मायग्रेशन न कळत बिघडून जाईल.
प्रत्येक मॉडेलची स्वतंत्रपणे चाचणी घ्या. Opus 4.5 आणि 4.8 पूर्णपणे वेगळी आहेत. एकावर चालणारी कॉन्फिग (config) दुसऱ्यावरही चालेलच असे नाही. जर तुम्ही अनेक व्हर्जनला सपोर्ट करत असाल, तर तुमच्या लॉजिकमध्ये विभागणी करा किंवा त्यांना स्वतंत्र बॅकएंड्स (backends) म्हणून हाताळा.
UI फ्रीझिंगची समस्या सोडवणे
एक स्ट्रीमिंग बिहेवियर (streaming behavior) असे आहे जे जर तुम्ही हाताळले नाही, तर ते तुमच्या वापरकर्त्यांना गोंधळात टाकू शकते. नवीन मॉडेल्समध्ये, थिंकिंग ब्लॉक्स (thinking blocks) स्ट्रीम होतात पण डिफॉल्टनुसार मजकूर रिकामा असतो. तुमच्या इंटरफेसमध्ये, हे कोणत्याही दृश्य प्रगतीशिवाय (visible progress) एक मोठा आणि विचित्र विलंब असल्यासारखे वाटते. वापरकर्त्यांना वाटेल की ॲप हँग (hung) झाले आहे.
ते सुधारण्यासाठी, thinking: { type: "adaptive", display: "summarized" } पास करा. यामुळे चॅट विंडोमध्ये रॉ थॉट स्ट्रीम (raw thought stream) न टाकता तुम्हाला एक दृश्य प्रोग्रेस इंडिकेटर (progress indicator) मिळेल. तुमचे फ्रंटएंड रिस्पॉन्सिव्ह राहील आणि तुमच्या वापरकर्त्यांना समजेल की बॅकएंडला काहीतरी प्रक्रिया सुरू आहे.
खरा धडा
मी एका अशा पॅरामीटरवर संपूर्ण ॲबस्ट्रॅक्शन लेयर (abstraction layer) तयार केला होता, जो व्हेंडरला (vendor) कायमस्वरूपी ठेवण्याचा उद्देश नव्हता. मी त्यांच्या सेटिंग्ज माझ्या स्वतःच्या लॉजिकमध्ये गुंडाळल्या होत्या कारण मला वाटले की मला प्लॅटफॉर्मपेक्षा ट्रेडऑफ (tradeoff) अधिक चांगल्या प्रकारे समजला आहे. पण तसे नव्हते. ॲडॉप्टिव्ह थिंकिंग (Adaptive thinking) हा एक उत्तम पर्याय आहे कारण मॉडेल स्वतः ठरवते की त्याला कधी सखोल विचार करण्याची गरज आहे आणि कधी ते सहज काम करू शकते. आता माझा कोडबेस (codebase) लहान झाला आहे. निकाल अधिक अचूक झाले आहेत. कधीकधी योग्य इंजिनिअरिंग निर्णय म्हणजे चतुर कोड काढून टाकणे आणि प्लॅटफॉर्मला त्याचे काम करू देणे हा असतो.
जर तुम्हाला मूळ मायग्रेशन नोट्स वाचायच्या असतील, तर त्या तुम्ही येथे पाहू शकता. अशा अधिक प्रत्यक्ष चर्चेसाठी, Telegram वरील GyaanSetu AI कम्युनिटीमध्ये सामील व्हा.