मुझे लगा कि मैं बहुत चालाक बन रहा हूँ। मैंने एक हेल्पर फंक्शन लिखा जिसने कॉन्टेक्स्ट विंडो का ठीक तीस प्रतिशत हिस्सा

मुझे लगा कि मैं बहुत चतुर बन रहा हूँ। मैंने एक हेल्पर फंक्शन लिखा था जो हमारे AI पाइपलाइन के लिए कॉन्टेक्स्ट विंडो का ठीक तीस प्रतिशत थिंकिंग बजट के रूप में आरक्षित कर देता था। यह साफ-सुथरा था, अनुमानित था, और Opus 4.5 पर बहुत शानदार तरीके से काम करता था। फिर मैंने Opus 4.8 पर स्विच किया और हर एक रिक्वेस्ट 400 एरर के साथ फेल हो गई। मेरी सावधानी से तैयार की गई टोकन की गणना रातों-रात बेकार हो गई।

पुराना पैटर्न सरल था। आप एक budget_tokens वैल्यू सेट करते थे और मॉडल उस सीमा के भीतर रहने के लिए अपनी सोच (thinking) को सीमित कर लेता था। यदि मैं 128K कॉन्टेक्स्ट देता, तो मेरा कोड रीजनिंग के लिए लगभग 38,000 टोकन निकाल लेता और बाकी उत्तर के लिए छोड़ देता। यह जिम्मेदारी भरा लगता था। जैसे कार को स्पीड लिमिट के अंदर रखना।

वह मॉडल अब चला गया है। Opus 4.7 और 4.8 जैसे नए रिलीज़ 'adaptive thinking' का उपयोग करते हैं। अब आप कोई नंबर नहीं चुनते। इसके बजाय, आप एक effort knob पास करते हैं। यह सुनने में केवल नाम बदलने जैसा लग सकता है, लेकिन ये दोनों नियंत्रण एक-दूसरे से बिल्कुल अलग हैं। budget_tokens इस बात पर एक सख्त सीमा (hard ceiling) लगाता था कि मॉडल को कितना सोचने की अनुमति है। Effort यह नियंत्रित करता है कि मॉडल शुरुआत में कैसे सोचता और कार्य करता है। एक गैस पंप मीटर की तरह है, तो दूसरा इंजन मैप की तरह।

Effort को वास्तविक कार्य के साथ मैप करना

जब नियंत्रण बदला, तो मेरी पुरानी समझ काम करना बंद कर गई। मुझे यह फिर से सीखना पड़ा कि प्रत्येक सेटिंग वास्तव में क्या प्रदान करती है। मैंने यह पता लगाने के लिए हमारे आंतरिक ट्रैफिक पर परीक्षण किए कि व्यवहार में प्रत्येक effort level कहाँ तक पहुँचता है।

Classification और routing में लगभग हमेशा low effort का उपयोग किया जाना चाहिए। ये काम तेज़ निर्णय लेने वाले होते हैं। क्या यह रिफंड अनुरोध है या बिक्री से संबंधित प्रश्न? क्या इस लॉग एंट्री को एस्केलेशन की आवश्यकता है? आपको किसी लंबे भाषण (monologue) की आवश्यकता नहीं है। Low effort लेटेंसी को कम रखता है और लागत को नगण्य बना देता है।

अधिकांश ऐप ट्रैफिक, जैसे सारांश (summaries), रीराइट्स, सपोर्ट रिप्लाई और कंटेंट एक्सट्रैक्शन का दैनिक कार्य, medium से high effort के दायरे में आता है। यह संतुलन का बिंदु है। मॉडल को बिना किसी ऐसे कार्य पर टोकन बर्बाद किए, वास्तविक अस्पष्टता को सुलझाने के लिए पर्याप्त जगह मिल जाती है जिसे विस्तृत chain of thought की आवश्यकता नहीं है।

Coding और agentic loops को xhigh effort की आवश्यकता होती है। यहीं पर गलतियाँ बढ़ती जाती हैं। यदि मॉडल टूल-कॉलिंग लूप के पहले टर्न में एक खराब योजना बनाता है, तो वह अगले तीन चरणों में उस नुकसान की भरपाई करने में समय बिताएगा। या इससे भी बुरा, वह गलत टूल्स कॉल करेगा, पैरामीटर्स का भ्रम (hallucinate) पैदा करेगा, और उपयोगकर्ता को एक टूटे हुए वर्कफ़्लो के साथ छोड़ देगा। शुरुआत में बेहतर रीजनिंग उस चक्र को रोकती है।

Critical tasks को max effort मिलना चाहिए। इसका उपयोग हर चीज़ के लिए न करें। इसे उन क्षणों के लिए आरक्षित रखें जहाँ गलत उत्तर का खर्च किसी भी टोकन बिल से अधिक हो। वित्तीय मिलान (Financial reconciliations), सुरक्षा जाँच, आर्किटेक्चर संबंधी निर्णय और मेडिकल ट्राइएज इसके लिए सही फिट हैं। यदि किसी त्रुटि का अर्थ यह है कि किसी इंसान को घंटों तक उस उलझन को सुलझाना पड़ेगा, तो अतिरिक्त थिंकिंग के लिए भुगतान करें।

लागत का आश्चर्य

यहाँ वह हिस्सा है जिसने मेरे मानसिक मॉडल को तोड़ दिया। मैंने मान लिया था कि max effort हमेशा मेरी लागत को बढ़ा देगा। एक सिंगल टर्न पर, ऐसा ही होता है। रीजनिंग ट्रेस लंबा होता है। लेकिन मल्टी-स्टेप एजेंटिक कार्यों पर, कुल बिल अक्सर कम हो गया।

मॉडल पहली कोशिश में बेहतर योजना बनाता है। यह कम टूल कॉल करता है। यह खुद को गलत दिशा में भटकने से रोकता है। मैंने एक डेटा एक्सट्रैक्शन एजेंट को देखा जिसे सामान्य रूप से पांच बार आने-जाने (back-and-forth) की आवश्यकता होती थी, वह केवल दो टर्न में पूरा हो गया क्योंकि मॉडल के पास शुरुआत में ही स्कीमा को सही ढंग से समझने के लिए पर्याप्त रीजनिंग स्पेस था। जब आप लागत मापते हैं, तो काम पूरा होने (job completion) को देखें, न कि केवल रिक्वेस्ट को। प्रति स्टेप एक बड़ा थिंकिंग बजट कुल स्टेप्स को कम कर सकता है।

बाकी चीजों को खराब किए बिना माइग्रेट कैसे करें

यदि आपके कोडबेस में अभी भी budget_tokens मौजूद है, तो यहाँ उससे बाहर निकलने का सटीक रास्ता है। चरण तीन और पांच को न छोड़ें। मैंने छोड़ा था, और इसकी वजह से मुझे डिबगिंग में पूरी दोपहर लग गई।

अपने कोड में budget_tokens खोजें। हर इंस्टेंस को हटाना होगा। नए मॉडलों पर यह पैरामीटर काम नहीं करता और 400 एरर ट्रिगर करेगा।

बजट ऑब्जेक्ट को एक adaptive thinking ब्लॉक से बदलें। thinking: { type: "adaptive" } का उपयोग करें।

प्रत्येक कॉल के लिए एक स्पष्ट effort level के साथ output_config जोड़ें। यदि आपका ट्रैफिक मिश्रित है, तो इसे ग्लोबल डिफॉल्ट पर न छोड़ें। आपके हल्के क्लासिफिकेशन एंडपॉइंट को गलती से आपके कोडिंग एजेंट के समान effort सेटिंग विरासत में नहीं मिलनी चाहिए। कॉल साइट पर स्पष्ट रहें।

अपने बजट कैलकुलेशन हेल्पर को हटा दें। मुझे पता है। इसमें शायद यूनिट टेस्ट होंगे। मेरे कोड में भी थे। लेकिन अब यह बेकार बोझ है। प्लेटफॉर्म को आपकी टोकन गणना नहीं चाहिए। मॉडल अपनी गति खुद संभालता है।

temperature, top_p, और top_k को हटा दें। Opus 4.7 और 4.8 पर, ये sampling parameters 400 errors उत्पन्न करेंगे। प्लेटफ़ॉर्म ने उन्हें इस जनरेशन से हटा दिया है। आपकी पुरानी temperature-tuning ट्रिक्स यहाँ काम नहीं करेंगी, और उन्हें छोड़ने से आपका माइग्रेशन चुपचाप खराब हो जाएगा।

प्रत्येक मॉडल का व्यक्तिगत रूप से परीक्षण करें। Opus 4.5 और 4.8 बिल्कुल अलग हैं। एक पर काम करने वाला config ज़रूरी नहीं कि दूसरे पर भी काम करे। यदि आप कई वर्शन का समर्थन करते हैं, तो अपने लॉजिक को अलग करें (branch) या उन्हें अलग बैकएंड के रूप में मानें।

UI Freeze को ठीक करना

एक स्ट्रीमिंग व्यवहार (behavior) ऐसा है जो आपके उपयोगकर्ताओं को भ्रमित कर सकता है यदि आप इसे संभालते नहीं हैं। नए मॉडल्स पर, thinking blocks स्ट्रीम होते हैं लेकिन डिफ़ॉल्ट रूप से टेक्स्ट खाली रहता है। आपके इंटरफ़ेस में, यह बिना किसी दृश्य प्रगति के एक लंबे, अजीब ठहराव जैसा दिखता है। उपयोगकर्ताओं को लगेगा कि ऐप हैंग हो गया है।

इसे ठीक करने के लिए, thinking: { type: "adaptive", display: "summarized" } पास करें। इससे चैट विंडो में रॉ थॉट स्ट्रीम (raw thought stream) डाले बिना आपको एक दृश्य प्रगति संकेतक (visible progress indicator) मिल जाएगा। आपका frontend रिस्पॉन्सिव बना रहता है और आपके उपयोगकर्ताओं को पता चलता है कि बैकएंड में कुछ हो रहा है।

असली सबक

मैंने एक ऐसे पैरामीटर के ऊपर पूरा एब्स्ट्रैक्शन लेयर (abstraction layer) बनाया था जिसे वेंडर ने कभी स्थायी रखने का इरादा नहीं किया था। मैंने उनकी सेटिंग्स को अपने स्वयं के लॉजिक में लपेट दिया था क्योंकि मुझे लगा कि मैं प्लेटफ़ॉर्म की तुलना में ट्रेडऑफ़ (tradeoff) को बेहतर समझता हूँ। पर मैं गलत था। Adaptive thinking एक बेहतर विकल्प है क्योंकि मॉडल वास्तव में खुद तय करता है कि उसे कब गहराई से तर्क करने की आवश्यकता है और कब वह सामान्य रूप से काम कर सकता है। मेरा कोडबेस अब छोटा है। परिणाम और भी सटीक हो गए हैं। कभी-कभी सही इंजीनियरिंग कदम चालाकी भरे कोड को हटाना और प्लेटफ़ॉर्म को अपना काम करने देना होता है।

यदि आप मूल माइग्रेशन नोट्स पढ़ना चाहते हैं, तो आप उन्हें यहाँ पा सकते हैं। इस तरह की अधिक व्यावहारिक चर्चाओं के लिए, Telegram पर GyaanSetu AI कम्युनिटी से जुड़ें।