Orkas Orkas
डाउनलोड GitHub
मुखपृष्ठ ब्लॉग आर्किटेक्चर
आर्किटेक्चर

काम पूरा घोषित करना, उसके पूरा होने की पुष्टि नहीं है: लंबे कार्यों वाले एजेंटों के लिए पड़ावों की रूपरेखा

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

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

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

संक्षिप्त विवरण पूरा वही है जिसे जाँच पूरा कहे, एजेंट नहीं Orkas किसी पड़ाव को पूरा कहने से पहले सत्यापित करता है, और चुपचाप आगे बढ़ने के बजाय बताता है कि क्या अनसुलझा रह गया।
Orkas डाउनलोड करें — मुफ़्त

सवाल सही तरह से पूछें

सवाल यह नहीं है कि "एजेंट को कैसे पता चलता है कि उसने चरण पूरा कर लिया।" सवाल है "कैसे सिस्टम को पता चलता है कि वह सचमुच पूरा हुआ, सिर्फ़ पूरा होने की घोषणा नहीं हुई।"

सिर्फ़ एक परत का अंतर है, लेकिन विश्वसनीयता की तुलना ही नहीं की जा सकती।

हमारे पास दोनों हिस्से पहले से थे, लेकिन हमने उन्हें कभी जोड़ा नहीं

अपना कार्यान्वयन पढ़ते समय यही हिस्सा चौंकाने वाला था।

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

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

अंतर यहीं है। एक पंक्ति कहती है मैंने पूरा कर लिया। दूसरी कहती है फ़ाइल का हैश A से B हो गया। किसी ने कभी इन्हें साथ रखकर नहीं देखा।

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

शोधपत्र की सबसे उपयोगी चीज़ सूत्र नहीं है

BEACON अपने दो पैमानों वाले लाभ के लिए जाना जाता है, लेकिन अपनाने लायक हिस्सा यह है कि वह डिटेक्टर Φ को कैसे स्थापित करता है।

Φ को न प्रशिक्षित मॉडल चाहिए, न मानवीय एनोटेशन। वह केवल परिवेश की प्रतिक्रिया में दिखने वाले स्थिति बदलाव पढ़ता है: ALFWorld में वस्तु की स्थिति के बदलाव (सफलतापूर्वक उठा लिया गया, गर्म करना पूरा हुआ), WebShop में पृष्ठ बदलाव, और ScienceWorld में वह बस परिवेश द्वारा पहले से दिए जा रहे उपलक्ष्य संकेत का उपयोग करता है।

शून्य अतिरिक्त मॉडल, शून्य अतिरिक्त सैंपलिंग लागत। विकल्पों से तुलना करें: प्रक्रिया रिवॉर्ड मॉडल को महँगा एनोटेशन चाहिए और उसे चकमा दिया जा सकता है, जबकि Monte-Carlo मूल्य आकलन में हर निर्णय बिंदु पर अतिरिक्त रोलआउट चाहिए। Φ इसी लागत से बचाता है।

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

अगर इसे बनाना हो, तो तीन परतें

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

दूसरी परत: दोनों हिस्से जोड़ें। सबसे मूल्यवान कदम। जब मॉडल किसी चरण को पूरा घोषित करे, तो आँख मूँदकर भरोसा करने के बजाय उस अवधि में पहली परत के साक्ष्य देखें। साक्ष्य हों, तो उसे चिह्नित करें सत्यापित रूप से पूरा। साक्ष्य न हों, तो चिह्नित करें पूरा घोषित। इससे मॉडल कोई घोषणा करने से नहीं रुकता; यह केवल साक्ष्य-समर्थित और असमर्थित घोषणाओं को अलग करता है।

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

हमने एक मानदंड जोड़ा: अपरिवर्तनीयता, महत्व नहीं

यह शोधपत्र में नहीं है।

BEACON के पड़ाव इसलिए काम करते हैं क्योंकि वे ऐसे स्थिति बदलाव दर्शाते हैं जिन्हें वापस नहीं लिया जा सकता। एक बार चाबी मिल जाए, तो दुनिया बदल जाती है। इसलिए मानदंड होना चाहिए क्या इस कार्रवाई से कोई अपरिवर्तनीय बाहरी प्रभाव पैदा हुआ, इसके बजाय कि क्या यह चरण महत्वपूर्ण था.

अपरिवर्तनीय: फ़ाइल लिखना, कोड कमिट करना, संदेश भेजना, सशुल्क API कॉल करना, डेटाबेस में कमिट करना। प्रतिवर्ती: फ़ाइल पढ़ना, खोजना, पृष्ठ लाना, सोचना।

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

दो आँकड़े: एक हिम्मत के लिए, एक सावधानी के लिए

हिम्मत देने वाला आँकड़ा गिरावट के प्रयोग का है। आधे पड़ाव यादृच्छिक रूप से हटा दें, तब भी स्कोर 72.8 के आधार स्तर के मुकाबले 82.8 रहता है — दस अंक आगे। गिरावट धीरे-धीरे होती है, अचानक नहीं। इसे जारी करने वाले के लिए यही अहम बात है: इसे चालू करने से पहले Φ को बिल्कुल सही बनाना ज़रूरी नहीं। आधे पड़ाव समेटने से भी लाभ मिलता है।

सावधान करने वाला आँकड़ा विभाजन की तुलना का है।

विभाजनस्कोरआधाररेखा (72.8) की तुलना में
बेतरतीब 5 हिस्सों में विभाजन74.2+1.4
वास्तविक पड़ाव91.4+17.2

पहली टिप्पणी में भी ये आँकड़े दिए गए थे, लेकिन यहाँ उनका अर्थ अधिक सीधा है। अगर आपके पड़ाव अंतर्ज्ञान से तय होते हैं, तो वे लगभग यादृच्छिक विभाजन जैसे हैं और मेहनत बेकार जाती है। पड़ाव तभी मूल्यवान हैं जब वे काम की वास्तविक संरचना से मेल खाते हैं।

किन बातों को अभी सीमित दावे के रूप में लें

शोधपत्र का अपना परिशिष्ट स्वचालित पड़ाव खोज को एक अनसुलझी समस्या बताता है। तीनों बेंचमार्क अपने पड़ाव नियमों से लेते हैं: परिवेश की प्रतिक्रियाओं में पैटर्न मिलाना, पृष्ठ बदलाव, या परिवेश से सीधे मिलने वाला संकेत। वास्तव में खुले दायरे वाले कामों — ब्राउज़र संचालन, कोडबेस रिफ़ैक्टर, गहन शोध — में ऐसा तैयार सत्यापनीय बदलाव नहीं होता।

इसलिए यह संरचित परिवेशों में सत्यापित पद्धति है, ऐसा समाधान नहीं जिसे पूरा का पूरा उठाकर लागू कर दें। इसे एजेंट उत्पाद में उपयोगी बनाती है टूल कॉल की संरचित सीमा, शोधपत्र में पहले से दिया गया कोई जवाब नहीं।

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

अगर सिर्फ़ एक काम करें

दूसरी परत बनाएँ।

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

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

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