एजेंट द्वारा कार्य अपने हाथ में लेने के बाद, सबसे पहले कार्य इकाई को कसने की आवश्यकता होती है।

मैं हाल ही में एजेंट के बारे में बहुत सारी चर्चाएं पढ़ रहा हूं, और अंत में मैं हमेशा एक ही प्रश्न पर लौटता हूं: काम का एक टुकड़ा किसे देना चाहिए, इसे सौंपने से पहले इसे कैसे पैक किया जाना चाहिए, और इसे वापस करने के बाद इसे कैसे स्वीकार किया जाएगा। एक बार जब किसी परियोजना में यह समस्या उत्पन्न हो जाती है, तो पहली चीज़ जो बढ़ती है वह अक्सर मॉडल की लागत नहीं, बल्कि कार्य इकाई की जटिलता होती है। यदि कार्य बहुत बड़ा हो गया है, तो मॉडल “ऐसा प्रतीत होगा मानो यह किया जा सकता है”; वास्तविक समस्याएँ आम तौर पर रोलबैक, पुनरुत्पादन और स्वीकृति में होती हैं।

कार्य इकाई को पहले स्वीकार किए जाने में सक्षम होना चाहिए

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

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

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

सेल्फ-होस्टिंग नियंत्रण सतह को ऊपर लाती है

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

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

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

स्वीकृति और लक्ष्यों को आउटसोर्स नहीं किया जा सकता

सैम रूबी की “ब्रिंग मी ए रॉक” ने एक और मुद्दा प्रकाश में लाया। मॉडल को कार्य देना एक निष्पादक को जोड़ने के बराबर है; जिम्मेदारी ख़त्म नहीं होती. प्रबंधक अन्वेषण के लिए एलएलएम का उपयोग कर सकते हैं, और वे इसे पहले उम्मीदवार समाधानों का एक समूह उगलने दे सकते हैं, लेकिन अंतिम स्वीकृति मानदंड अभी भी मानव हाथों में पड़ना है। छिपे हुए लक्ष्य सबसे अधिक परेशानी वाले होते हैं। अनुमतियाँ, गोपनीयता, विनाशकारी गतिविधियाँ और संदर्भ रिसाव अक्सर मूल आवश्यकताओं में शामिल नहीं होते हैं।

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

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

अनुभव और पढ़ने के कौशल में अभी भी सुधार हो रहा है

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

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

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