आपका एजेंट अपनी संदर्भ विंडो के 80% तक पहुँचता है। संक्षेपण शुरू होता है और सबसे पुरानी बारियाँ हट जाती हैं। दस मिनट बाद वह पहले पढ़ी हुई फ़ाइल फिर पढ़ता है और पहले जवाब दिए हुए सवाल को फिर पूछता है।
सीमा को पता था कि जगह खत्म हो रही है। उसे यह नहीं पता था कि क्या खोना सुरक्षित है।
यह लंबे समय तक चलने वाले एजेंटों के डिज़ाइन पर श्रृंखला की तीसरी टिप्पणी है, जिसकी प्रेरणा मिला इसके गहन अध्ययन से: BEACON (झेजियांग विश्वविद्यालय, arXiv:2605.06078)। पहली में ठहराव की पहचान पर चर्चा थी, दूसरी में पड़ावों के डिज़ाइन पर।
अपनी कार्यान्वयन व्यवस्था से शुरुआत
Orkas कई एजेंटों वाला डेस्कटॉप क्लाइंट है। यहाँ लंबे कार्य सामान्य हैं, इसलिए संक्षेपण रोज़ सामने आता है। हमारा कार्यान्वयन टोकन सीमा पर सक्रिय होता है और संदर्भ विंडो लगभग 80% भरने पर संक्षेपण करता है। इसे लिखने तक हममें से किसी को इसमें कुछ गलत नहीं लगा था।
व्यवहार में लगभग तीन आम सीमाएँ मिलती हैं: विंडो का प्रतिशत, बारी की संख्या, या मॉडल को पुरानी सामग्री समेटने वाला सारांश लिखने देना। हमारा तरीका पहले प्रकार का है।
पहले दो सामग्री देखते ही नहीं। तीसरा देखता है, लेकिन क्या महत्त्वपूर्ण है, यह पूरा सवाल मॉडल को सौंप देता है।
तीनों इसका जवाब देते हैं मुझे कुछ कब हटाना ही पड़ेगा। असली सवाल है क्या हटाना सुरक्षित है। सीमा पर काटने से सबसे पुरानी सामग्री हटती है, सबसे कम महत्त्वपूर्ण नहीं।
पड़ाव की सीमा, और उसके नीचे की धारणा
पिछली टिप्पणी के पड़ाव इन तीनों से बेहतर सीमा दे सकते हैं। लेकिन यहाँ एक जाल है, और पिछली टिप्पणी ने इसे कुछ ज़्यादा ही सहज दिखाया था।
BEACON में एक धारणा है जिसे पड़ाव का मार्कोव गुण कहते हैं। सरल शब्दों में: किसी पड़ाव पर पहुँचने के बाद आगे क्या होगा, यह केवल बचे हुए उपलक्ष्यों पर निर्भर करता है, वहाँ तक पहुँचने के तरीके पर नहीं। चाबी मिल जाने के बाद मायने यह रखता है कि आप कौन-सा दरवाज़ा खोलते हैं, यह नहीं कि चाबी कैसे मिली।
यह संक्षेपण की छूट जैसा लगता है: पड़ाव पार होने के बाद उससे पहले के हिस्से को समेटकर हटाया जा सकता है।
लेकिन यह धारणा है, तथ्य नहीं। शोधपत्र में ≈ लिखा है, = नहीं, और लेखक चर्चा करते हैं कि यह कहाँ विफल होती है।
प्रशिक्षण के लिए पर्याप्त, संक्षेपण के लिए अपर्याप्त
एक ही धारणा, दो उपयोग, सख्ती में दस गुने स्तर का अंतर।
प्रशिक्षण में इसे केवल सांख्यिकीय रूप से सही होना होता है। कुछ हज़ार परीक्षण क्रमों में से कुछ दर्जन इसका उल्लंघन करें, तो औसत में पक्षपात का असर मिट जाता है। प्रशिक्षण में सुरक्षा के लिए नीचे कार्य-पथ स्तर का संकेत भी चलता है; उस परत को हटाएँ तो ALFWorld 91.4 से 23.4 पर गिर जाता है, जो कुछ भी न करने से भी बहुत नीचे है।
संक्षेपण में इसे सही होना होता है हर विशिष्ट मामले में, सामने मौजूद इसी एक रन के लिए। एक बार गलत चीज़ हटा दें और वह कार्य खत्म। औसत निकालने के लिए कुछ नहीं है।
इसलिए शोधपत्र का इस धारणा पर निर्भर होना यह नहीं दर्शाता कि आप इसे संक्षेपण में भी लागू कर सकते हैं। दोनों उपयोग इससे एक जैसी अपेक्षा नहीं रखते।
चार मामले जहाँ यह टूटती है
संक्षेपण नीति पर विचार करते समय हम इन्हें जाँच-सूची की तरह इस्तेमाल करते हैं।
1. रास्ते में जमा हुआ निहित ज्ञान। शुरुआत में किसी चरण पर पता चलता है कि कोई API टाइमस्टैम्प UTC में लौटाता है। यह किसी पड़ाव का हिस्सा नहीं है, और बाद के हर चरण को इसकी ज़रूरत है।
2. पहले ही खर्च हो चुके संसाधन। टोकन बजट, कॉल कोटा, बचा हुआ समय। पड़ाव यह दर्ज नहीं करता मैं बजट का 60% खर्च कर चुका हूँ, लेकिन यही संख्या तय करती है कि दोबारा कोशिश करना अभी भी संभव है या नहीं।
3. अपनाए गए रास्ते पर निर्भर अतिरिक्त प्रभाव। पड़ाव कहता है रीफ़ैक्टर पूरा। डिबगिंग शुरू होते ही आपको जानना पड़ता है कि वास्तव में कौन-सी पाँच फ़ाइलें बदली गई थीं।
4. पड़ाव खुद पर्याप्त स्पष्ट नहीं है। चारों में यह सबसे बुरा है। शोधपत्र में पड़ाव परिवेश की पूरी स्थिति है — आपके पास चाबी है या नहीं है, कोई अस्पष्टता नहीं। योजना का चरण प्राकृतिक भाषा का एक वाक्य होता है। "डेटा की सफ़ाई पूरी करें" उस दौरान हुई सारी बातों को समेटने के आसपास भी नहीं पहुँचता।
इसके बजाय आगे क्या ले जाएँ
सिर्फ़ सारांश न रखें। सारांश मॉडल लिखता है, जो अपने अंदाज़े से तय करता है कि क्या महत्त्वपूर्ण था।
इंसान द्वारा चुने गए निश्चित फ़ील्ड रखें। कम से कम चार:
- कार्यक्षेत्र अभी कैसा है — कौन-सी फ़ाइलें बदली गईं, और किस स्थिति में पहुँचीं।
- कितना बजट बचा है — टोकन, कॉल कोटा, समय।
- क्या स्थापित हो चुका है — UTC वाला तथ्य, और उसी तरह की हर बात जो आगे के निर्णयों को प्रभावित करेगी।
- क्या अभी अनसुलझा है — वह चीज़ जिसने एक बार रोका, जिसे किसी तरह पार किया गया, और जो वापस आ सकती है।
इन्हें ऊपर के चार विफलता मामलों के सामने रखें, तो वे एक-से-एक मेल खाते हैं। यह मेल परखने का सबसे सरल तरीका है कि संक्षेपण नीति पर्याप्त है या नहीं।
इसका आधा हिस्सा लगभग मुफ़्त है। जैसा पिछली टिप्पणी में बताया गया था, होस्ट हर टूल कॉल के बाद पहले से ही निश्चित तथ्य दर्ज करता है: फ़ाइल सचमुच दोबारा लिखी गई या नहीं, कमांड वास्तव में चला या नहीं। यह डेटा पड़ावों के सत्यापन के लिए इकट्ठा हुआ था, लेकिन यह ही है कार्यक्षेत्र का स्नैपशॉट है, इसलिए संक्षेपण इसे सीधे आगे ले जा सकता है, बिना किसी मॉडल से इसका फिर सारांश बनवाए।
कठिन आधा हिस्सा बाकी दो हैं। क्या स्थापित हुआ और क्या अभी अनसुलझा है, ये फिलहाल तभी मौजूद होते हैं जब मॉडल उन्हें लिखता है, और यही कारण है कि संक्षेपण में सबसे पहले यही खोते हैं।
इसे मापा जा सकता है, बहस की ज़रूरत नहीं
संक्षेपण के बाद यदि एजेंट उस फ़ाइल को फिर पढ़े जो संक्षेपण में हट गई थी, या पहले उत्तर दिए गए सवाल को फिर पूछे, तो उस कार्य पर धारणा विफल हुई और प्रमाण सामने है।
मापन व्यवस्था सरल है: संक्षेपण के बाद पढ़े गए फ़ाइल पथों और उससे पहले दर्ज पथों का साझा हिस्सा निकालें।
उस संख्या के साथ, किन प्रकार के कार्यों में अधिक संक्षेपण किया जा सकता है और किनमें नहीं डिज़ाइन की बहस के बजाय एक क्वेरी का विषय बन जाता है। यह इस श्रृंखला की पहली टिप्पणी वाला ही तरीका है: पहले मापें, फिर कुछ बदलें।
किन बातों को अभी सीमित दावे के रूप में लें
इसमें से कुछ भी अभी जारी नहीं हुआ है। हम डिज़ाइन और मापन व्यवस्था के चरण में हैं।
कौन-से फ़ील्ड रखने हैं और कितने विस्तार में, यह उस डेटा से तय होना चाहिए जो बताए कि वास्तव में क्या दोबारा प्राप्त किया जाता है। अभी निर्णय लेना गलत निर्णय लेने का अच्छा तरीका है।
और यह कई तरीकों में से एक है। किसी अलग तरह के उत्पाद में सीमा कहाँ हो और फ़ील्ड कैसे परिभाषित हों, यह पूरी तरह अलग दिख सकता है। चार मामलों की जाँच-सूची दूसरी जगह काम आती है; विशिष्ट उत्तर नहीं।
इस श्रृंखला की अगली और अंतिम टिप्पणी आत्मचिंतन पर है: एजेंट के निकाले हुए सबक बार-बार "ज़्यादा सावधान रहें" जितने सामान्य क्यों निकलते हैं, और उसके इनपुट में क्या होता है और क्या नहीं, इससे जुड़ी एक सचमुच चौंकाने वाली बात।