दोहराव पहचानना, ठहराव पहचानना नहीं है: बिना दोहराए चक्कर काटते एजेंटों को पकड़ना

यह लंबे समय तक चलने वाले एजेंटों के डिज़ाइन पर टिप्पणियों की श्रृंखला की पहली कड़ी है, जिसकी प्रेरणा मिला इसके गहन अध्ययन से: BEACON (झेजियांग विश्वविद्यालय, arXiv:2605.06078).

हमारे विचार से किसी एजेंट को लंबे कार्य में टिके रहने के लिए दो बातें सही होनी चाहिए:

• वह लक्ष्य की ओर लगातार प्रगति करता रहे। इसके अंतर्गत संदर्भ संक्षेपण (क्या भूलना सुरक्षित है), पड़ावों का डिज़ाइन (कैसे पता चले कि कोई चरण सचमुच पूरा हो गया है), और ठहराव की रोकथाम (जब वह अटके, तो किसी व्यवस्था को इसका पता चलना चाहिए) आते हैं।
• वह आत्मचिंतन और सुधार कर सके।

इस लेख में ठहराव की रोकथाम पर चर्चा है, क्योंकि इसी की हमें सबसे ज़्यादा कीमत चुकानी पड़ी।

लक्षण

हमें उपयोगकर्ताओं से रिपोर्ट मिलीं, और हमने आंतरिक तौर पर भी देखा: कुछ बहुत लंबे कार्य बीच में आगे बढ़ना बंद कर देते हैं।

लॉग देखें तो एजेंट व्यस्त है — फ़ाइलें पढ़ रहा है, खोज कर रहा है, कमांड चला रहा है, कभी खाली नहीं बैठता। लेकिन आधे घंटे बाद भी कुछ आगे नहीं बढ़ा होता।

हमारी पहली व्याख्या संदर्भ खोना थी: संक्षेपण में यह रिकॉर्ड हट गया कि कोई रास्ता पहले ही आज़माया जा चुका है, इसलिए एजेंट ने उसे फिर आज़माया। कोड और लॉग साथ पढ़ने पर पता चला कि यह कहानी का सिर्फ़ आधा हिस्सा था।

हमारे पास पहले से सुरक्षा उपाय थे — तीन स्तरों पर

तीसरे स्तर की टिप्पणी में शब्दशः लिखा है: संयुक्त संकेत: "संदर्भ खोने के बाद संभवतः चक्कर काट रहा है"। किसी ने इसे पहले ही आते देख लिया था। इसलिए समस्या कभी यह नहीं थी कि कुछ बनाया ही नहीं गया — समस्या यह थी कि जो हमने बनाया, वह इसे पकड़ नहीं सकता था।

कमी: तीनों डिटेक्टर इनपुट पर आधारित हैं

हर स्तर जिस पहचान-चिह्न पर निर्भर करता है, वह है टूल का नाम + मानकीकृत आर्ग्युमेंट। यह ठीक एक सवाल का जवाब देता है: क्या आप एक ही काम दो बार कर रहे हैं?

लेकिन अटका हुआ सक्षम मॉडल कॉल नहीं दोहराता। वह यह करता है:

फ़ाइल A पढ़ना → grep X → A को अलग पंक्ति-सीमा के साथ फिर पढ़ना
  → थोड़ा अलग कमांड चलाना → फ़ाइल B पढ़ना → फिर grep करना …

हर कॉल का पहचान-चिह्न अलग है। तीनों स्तर चुप रहते हैं। और इस पूरे दौरान सत्यापन योग्य स्थिति-परिवर्तनों की संख्या शून्य रहती है: वास्तव में कोई फ़ाइल दोबारा नहीं लिखी गई, किसी कमांड से नया परिणाम नहीं मिला, कोई भी ऐसा बदलाव नहीं हुआ जिसे वापस न किया जा सके।

लूप का पता लगाना ठहराव का पता लगाना नहीं है। पहला इनपुट देखता है। दूसरे को आउटपुट देखना होता है।

शोधपत्र ठीक यही आउटपुट-आधारित परिभाषा देता है

BEACON का खंड के भीतर मिलने वाला प्रतिफल:

r_t = R_ms · γ^(t_k − t)    यदि खंड किसी पड़ाव पर समाप्त होता है
    = 0                     अन्यथा

जो खंड किसी पड़ाव पर समाप्त नहीं होता, उसे मिलता है ठीक शून्य, चाहे उसमें कितनी भी कार्रवाइयाँ हुई हों। कार्रवाई की संख्या सूत्र में आती ही नहीं। यह इसकी सबसे स्पष्ट औपचारिक परिभाषा है: व्यस्त होना ≠ प्रगति करना जो हमने देखी है।

आधाररेखा वाला स्तर और भी सख्त है। आधाररेखा समूह का औसत प्रति-चरण प्रतिफल है, इसलिए जिस खंड में 8 चरण लगे जबकि समूह का औसत 5 था, उसका पूरा लाभ ऋणात्मक दिशा में झुक जाता है, और जितना अधिक सीमा से आगे जाता है, दंड उतना बढ़ता है। चक्कर काटना केवल प्रतिफल से वंचित नहीं रहता; उसे सक्रिय रूप से और अनुपात में दंडित किया जाता है।

शोधपत्र का चित्र 8 एक विफल कार्य-पथ दिखाता है, जिसमें अंतिम दो कार्रवाइयों को मिलता है एक समान −2.20। वह अंतिम हिस्सा — आखिरी पड़ाव के बाद का वह क्रम जो अगले पड़ाव तक कभी नहीं पहुँचता — चक्कर काटने का गणितीय रूप है। और यह आम है: कम से कम एक उपलक्ष्य पूरा करने लेकिन पूरे कार्य में विफल होने वाले कार्य-पथों का हिस्सा स्थिर रहता है 39–47% नमूनों में।

एक घटक-हटाव परीक्षण चरणों की संख्या पर आधारित ट्रिगर को खारिज करता है

मनमानी चरण-संख्या के आधार पर विभाजन का लगभग कोई लाभ नहीं है। वास्तविक संरचना के आधार पर विभाजन का बहुत लाभ है।

अब हमारे तीसरे स्तर के मानदंड पर फिर नज़र डालें — टूल-लूप बजट का 75% खर्च। यह मनमानी चरण-संख्या वाला ट्रिगर है। यह पूछता है कि आपने कितना खर्च किया, यह नहीं कि क्या हासिल किया। सही रूप यह है:

✗  यदि चरण > N                              → हस्तक्षेप करें
✓  यदि चरण > N और सत्यापित पड़ाव शून्य हों → हस्तक्षेप करें

दूसरा मानदंड सचमुच लंबे लेकिन प्रगति कर रहे कार्य पर गलत हस्तक्षेप नहीं करेगा, क्योंकि ऐसा कार्य रास्ते में पड़ाव पूरे करता है। पहला करेगा।

खुद को बढ़ाता हुआ एक चक्र भी है

स्थिरांकों को साथ रखकर देखें। संदर्भ विंडो के 82% भरने पर संक्षेपण शुरू होता है। चक्कर काटने के संयुक्त संकेत वाला उपाय सक्रिय होने से पहले दो संक्षेपण और लूप बजट का 75% खर्च होना चाहता है।

चक्कर काटना → संदर्भ भरना → संक्षेपण होना → स्थायी स्थिति सारांश में खो जाना
     → खोई जानकारी फिर निकालना → और चक्कर काटना

डिटेक्टर बार-बार संक्षेपण होने से अनुमान लगाता है कि एजेंट चक्कर काट रहा है — लेकिन संक्षेपण ही वह चरण है जो भूलने का कारण बनता है। वह बाद में दिखाई देने वाले लक्षण को पकड़ रहा है, और उसे चक्र के दो बार पूरा होने का इंतज़ार करना पड़ता है।

इससे भी बुरा यह है कि उसका हस्तक्षेप मॉडल को अपनी स्थायी स्थिति पर फिर टिकने के लिए प्रेरित करना है। अगर स्थायी स्थिति ही संक्षेपण में हट गई हो, तो दोबारा टिकने के लिए कुछ बचता ही नहीं। यह स्थिति-स्तर की समस्या पर प्रॉम्प्ट-स्तर का पैबंद है।

हम क्या जोड़ रहे हैं: आउटपुट-आधारित ठहराव का पता लगाना

दो काउंटरों से बना चौथा स्तर। दोनों की गणना उन टूल अवलोकनों से यांत्रिक रूप से होती है जिन्हें होस्ट पहले से दर्ज करता है; किसी को मॉडल के निर्णय की ज़रूरत नहीं है।

अंतिम सत्यापित पड़ाव के बाद से हुए चरण। प्रगति का सबसे सरल संभव माप, जिसका इस्तेमाल अकेले करने के बजाय ऊपर दिए गए संयुक्त मानदंड में किया जाता है।

दोहराव हटाने के बाद बचे नए स्थिति-परिवर्तन। दोनों में से अधिक उपयोगी:

• ऐसी फ़ाइल रीड जिसका सामग्री हैश पिछली रीड से मेल खाता है, नई जानकारी नहीं है — उसी फ़ाइल को अलग पंक्ति-सीमा में दोबारा पढ़ने से हैश नहीं बदलता।
• ऐसा कमांड जिसका नाम, एग्ज़िट कोड और आउटपुट हैश, तीनों किसी पिछले रन से मेल खाते हों, नई जानकारी नहीं है।
• ऐसी राइट जिसमें बाद का हैश पहले के हैश के बराबर हो, इसका मतलब है कि वास्तव में कुछ भी नहीं लिखा गया।

यह काउंटर ठीक उसी मामले को निशाना बनाता है जिसे पहचान-चिह्न का मिलान चूक जाता है: हर कार्रवाई अलग, नई जानकारी शून्य। यह मानदंड यांत्रिक है और इसके लिए अर्थ समझने की ज़रूरत नहीं है।

फिर दबाव एक बार के संकेत के बजाय लगातार होना चाहिए:

काउंटर को संदर्भ में दिखाएँ ताकि मॉडल उसे देख सके
  → योजना में संशोधन अनिवार्य करें (मानें कि यह रास्ता बंद है)
    → उपयोगकर्ता से पूछें
      → बंद करें, लेकिन पहले से हासिल पड़ाव सुरक्षित रखें

वह आखिरी पायदान मायने रखता है। यदि कार्य रुकना ही है, तो उसे अपनी उपलब्धियाँ सँभालकर रुकना चाहिए — यही वह 39–47% आंशिक प्रगति है जिसे शोधपत्र में बेकार जाते हुए मापा गया था।

शोधपत्र हमें क्या नहीं देता

BEACON एक प्रशिक्षण विधि है। यह ग्रेडिएंट को इस तरह ढालती है कि प्रशिक्षित नीति के भटकने की संभावना कम हो, लेकिन इसका अपना रनटाइम पर पता लगाने या हस्तक्षेप करने का कोई तंत्र नहीं है । यह प्रगति की परिभाषा देता है, नियंत्रक नहीं। सीमाएँ, क्रमशः बढ़ते हस्तक्षेप के स्तर और कार्य बंद करने की शर्तें हमें खुद डिज़ाइन करनी हैं।

इसकी प्रति-चरण आधाररेखा को संदर्भ के लिए समूह की औसत खंड-लंबाई भी चाहिए। वास्तविक उपयोग में किसी उपयोगकर्ता का कार्य आम तौर पर ठीक एक बार चलता है, इसलिए कोई समूह होता ही नहीं। सबसे अच्छा उपलब्ध विकल्प समान कार्यों के ऐतिहासिक आँकड़े हैं, जो काफ़ी अधिक शोरयुक्त हैं और शोधपत्र की विचरण को अलग रखने की कोई गारंटी नहीं देते।

पहला कदम मापना है, सुधारना नहीं

कोई भी निर्णय-तर्क बदलने से पहले हम मापन व्यवस्था जोड़कर उस सवाल का जवाब चाहते हैं जिसका जवाब अभी हमारे पास नहीं है: वास्तविक उपयोग में होने वाले ठहरावों में कितने भूलने वाले प्रकार के हैं और कितने ग्रेडिएंट-रहित प्रकार के?

• मुख्य रूप से साथ दिखाई देता है नई जानकारी शून्य, जबकि सभी कॉल के पहचान-चिह्न अलग हैं → ग्रेडिएंट-रहित प्रकार। मौजूदा तीन स्तर संरचनात्मक रूप से इसे पकड़ ही नहीं सकते, और आउटपुट-आधारित पहचान इसका समाधान है।
• मुख्य रूप से साथ दिखाई देता है उस सामग्री को दोबारा पढ़ना जो संक्षेपण में पहले ही हट चुकी थी → भूलने वाला प्रकार। सुधार इस बात में चाहिए कि संक्षेपण क्या सुरक्षित रखता है।

इन दोनों निष्कर्षों के लिए बिल्कुल अलग निवेश चाहिए। पहले मापना, पहले डिज़ाइन करने से सस्ता है, और मापन व्यवस्था लगभग मुफ़्त है क्योंकि अवलोकन पहले से मौजूद हैं।

ऊपर की सारी बातें एक ऐसी धारणा पर निर्भर हैं जिसका यह टिप्पणी बिना परिभाषा दिए इस्तेमाल करती रही है: एक सत्यापित पड़ाव। अगली टिप्पणी इसी पर है। किसी चरण को पूरा घोषित कर देना उसके पूरा होने का प्रमाण क्यों नहीं है, कौन-से दो हिस्से उत्पाद में पहले से मौजूद हैं लेकिन कभी जुड़े नहीं, और एक ऐसा मानदंड जो शोधपत्र में नहीं है: महत्त्व के बजाय यह देखें कि बदलाव वापस किया जा सकता है या नहीं।