Human oversight of agentic systems in practice: Examining the oversight work, challenges, and heuristics of developers using software agents
17 अनुभवी डेवलपर्स के साथ साक्षात्कार के माध्यम से, यह शोध पत्र स्वायत्त सॉफ़्टवेयर एजेंटों के साथ सहयोग करते समय डेवलपर्स द्वारा नियोजित प्रोएक्टिव (proactive) और रिएक्टिव (reactive) रूपों के निरीक्षण कार्य, संबद्ध चुनौतियों और व्यावहारिक ह्यूरिस्टिक्स (heuristics) का अनुभवजन्य रूप से लक्षण वर्णन करता है, जिससे सैद्धांतिक ढांचों और वास्तविक दुनिया के अभ्यास के बीच के अंतर को पाटा जा सके।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपने एक अविश्वसनीय रूप से तेज़, सुपर-स्मार्ट, लेकिन थोड़ी अराजक रोबोटिक असिस्टेंट को घर बनाने में मदद करने के लिए काम पर रखा है। यह रोबोट ईंटें बिछा सकता है, दीवारों पर पेंट कर सकता है, और यहाँ तक कि अपने आप प्लंबिंग का डिज़ाइन भी बना सकता है। लेकिन इसमें एक पेंच है: कभी-कभी यह भूल जाता है कि कोई दीवार भार सहने वाली (load-bearing) है या नहीं, कभी-कभी यह फर्श वाले पेंट से छत को पेंट करने की कोशिश करता है, और कभी-कभी तो यह बस खिड़की की जगह दरवाज़ा बनाने का फैसला कर लेता है।
यह शोध पत्र इस बारे में है कि कैसे मानव डेवलपर्स (जो "आर्किटेक्ट" और "फोरमैन" हैं) वास्तव में इन रोबोटिक सहायकों (जिन्हें "सॉफ्टवेयर एजेंट" कहा जाता है) को वास्तविक दुनिया में प्रबंधित करते हैं। शोधकर्ताओं ने 17 अनुभवी डेवलपर्स का साक्षात्कार लिया जो रोज़ाना इन टूल्स का उपयोग करते हैं, ताकि यह पता लगाया जा सके कि: वे वास्तव में इन रोबोट्स को नियंत्रण में रखने के लिए क्या करते हैं, और जब चीजें गलत हो जाती हैं तो वे इसे कैसे संभालते हैं?
यहाँ उनके निष्कर्षों का विवरण दिया गया, सरल उपमाओं (analogies) का उपयोग करते हुए:
1. पुराना दृष्टिकोण बनाम नई वास्तविकता
पुराना दृष्टिकोण: अधिकांश लोगों का मानना था कि एक रोबोट की निगरानी करना एक गेट पर सुरक्षा गार्ड होने जैसा है। आप रोबोट के काम पूरा करने का इंतज़ार करते हैं, तैयार उत्पाद के पास जाते हैं, और कहते हैं, "हूँ, यह गलत लग रहा है, इसे ठीक करो।" इसे रिएक्टिव (reactive) निगरानी कहा जाता है।
नई वास्तविकता: शोधकर्ताओं ने पाया कि डेवलपर्स वास्तव में इससे कहीं अधिक कर रहे हैं। वे रोबोट के शुरू होने से पहले ही को-पायलट और सुरक्षा इंजीनियर की तरह काम कर रहे हैं। उन्होंने महसूस किया कि अंत तक प्रतीक्षा करना बहुत जोखिम भरा है। इसके बजाय, वे चार अलग-अलग तरीकों से रोबोट का प्रबंधन करते हैं:
- नियम निर्धारित करना (A Priori Control): रोबोट शुरू करने से पहले, डेवलपर सख्त "बाड़" (fences) लगा देता है। वे कह सकते हैं, "आप इन टूल्स का उपयोग कर सकते हैं, लेकिन आपको इस फोल्डर में फाइलें डिलीट करने की अनुमति कभी नहीं दी जाएगी," या "हमेशा इस विशिष्ट स्टाइल गाइड का पालन करें।" यह एक कुत्ते को पार्क में ले जाने से पहले उसे पट्टा देने और "रुको" का आदेश देने जैसा है।
- साथ मिलकर योजना बनाना (Co-Planning): केवल "घर बनाओ" कहने के बजाय, डेवलपर रोबोट के साथ बैठता है और कहता है, "ठीक है, आइए इसे तोड़ते हैं। पहले हम नींव रखेंगे। फिर हम दीवारें खड़ी करेंगे। यदि हमें कोई चट्टान मिलती है, तो हम रुकेंगे और आपसे पूछेंगे।" वे मिलकर एक चरण-दर-चरण मानचित्र बनाते हैं ताकि रोबोट रास्ता न भटके या अपनी कोई पागल योजना न बना ले।
- घड़ी पर नज़र रखना (Real-Time Monitoring): कभी-कभी डेवलपर रोबोट को काम करते हुए देखता है। हालाँकि, अध्ययन में पाया गया कि यह दुर्लभ है। क्यों? क्योंकि रोबोट बहुत तेज़ हैं, और कार्य बहुत छोटे हैं, इसलिए डेवलपर्स आमतौर पर उन्हें चलने देते हैं और परिणाम बाद में देखते हैं। यह माइक्रोवेव को देखने जैसा है; आप पूरे समय उसे घूरते नहीं हैं; आप बस बीप बजने पर चेक करते हैं।
- अंतिम निरीक्षण (Post Hoc Review): यह वह हिस्सा है जिसकी सभी को उम्मीद थी। एक बार जब रोबोट काम पूरा कर लेता है, तो इंसान काम का निरीक्षण करता है। लेकिन क्योंकि रोबोट ने हज़ारों छोटी-छोटी चीज़ें बदली होंगी, इसलिए यह किसी दूसरे व्यक्ति द्वारा लिखी गई 500 पन्नों की किताब में एक सिंगल टाइपो (typo) खोजने जैसा कठिन और थकाऊ काम है।
2. "काफी अच्छा है" वाले शॉर्टकट (Heuristics)
सबसे बड़ा आश्चर्य यह है कि डेवलपर्स पूर्णता (perfection) की कोशिश नहीं करते। वे बहुत व्यस्त हैं, और रोबोट बहुत जटिल हैं। इसके बजाय, वे कुशलता से काम करने के लिए मानसिक शॉर्टकट (heuristics) का उपयोग करते हैं। इन्हें थकान से बचने के लिए "नियमों के तौर" के रूप में सोचें:
- "योजना ही सत्य है" वाला शॉर्टकट: डेवलपर्स अक्सर मान लेते हैं कि यदि रोबोट की योजना अच्छी दिख रही थी, तो कोड भी अच्छा ही होगा। वे कोड की हर एक लाइन पढ़ने के बजाय रोबोट की टू-डू लिस्ट (to-do list) की जाँच करते हैं। यह एक शेफ पर भरोसा करने जैसा है क्योंकि उसकी रेसिपी एकदम सही दिखती है, बिना सूप के हर एक निवाले को चखे।
- "टेस्ट पास, सब ठीक" वाला शॉर्टकट: यदि रोब lewat ऑटोमेटेड टेस्ट पास कर देता है, तो डेवलपर मान लेता है कि कोड सही है। वे वास्तविक कोड को देखना बंद कर देते हैं। यह एक कार मैकेनिक के समान है जो कहता है, "यदि इंजन लाइट बंद है और यह उत्सर्जन परीक्षण पास कर लेता है, तो मुझे बोनट के नीचे देखने की ज़रूरत नहीं है।"
- "एक त्वरित नज़र" वाला शॉर्टकट: सब कुछ पढ़ने के बजाय, डेवलपर्स बस बदलावों को "आँखों से देखते" (eyeball) हैं। वे स्पष्ट रेड फ्लैग्स (red flags) को देखते हैं, जैसे कि कोई फंक्शन का नाम जो समझ में न आए। यह एक शिक्षक की तरह है जो जल्दी से कागजों के ढेर को स्कैन करता है कि छात्र ने कुछ लिखा है या नहीं, बजाय इसके कि वह हर शब्द को ग्रेड करे।
- "विशेषज्ञ पर भरोसा करें" वाला शॉर्टकट: यदि डेवलपर को किसी विशिष्ट तकनीक (जैसे कोई नई प्रोग्रामिंग भाषा) के बारे में जानकारी नहीं है, तो वे बस रोबोट पर भरोसा करते हैं। वे सोचते हैं, "मुझे 'Go' नहीं पता, लेकिन रोबोट कहता है कि यह काम करता है, इसलिए मैं विश्वास करूँगा।" यह एक जनरल कॉन्ट्रैक्टर द्वारा विशेषज्ञ प्लंबर पर भरोसा करने जैसा है कि वह पाइपों को बिना प्लंबिंग कोड चेक किए संभाल लेगा।
3. बड़ी चुनौतियाँ
इन शॉर्टकट्स के बावजूद, डेवलपर्स को कुछ कठिन समस्याओं का सामना करना पड़ता है:
- "ब्लैक बॉक्स" की समस्या: कभी-कभी रोबोट कुछ अजीब करता है, और डेवलपर समझ नहीं पाता कि वह क्यों कर रहा है। रोबोट कह सकता है, "मैंने यह कारण X की वजह से किया," लेकिन डेवलपर जानता है कि यह झूठ है। यह एक GPS जैसा है जो आपको रास्ता बदल देता है लेकिन यह समझाने से मना कर देता है कि क्यों।
- "स्ट्रेंजर'्स कोड" (अजनबी का कोड) की समस्या: वह कोड पढ़ना बहुत कठिन है जो आपने नहीं लिखा है। डेवलपर्स को ऐसा लगता है जैसे वे किसी और की लिखावट पढ़ रहे हैं; इसे समझने में दोगुना समय लगता है।
- "लूप ऑफ डूम" (विनाश का चक्र): यदि डेवलपर को कोई गलती मिलती है और वह रोबोट को उसे ठीक करने के लिए कहता है, तो रोबोट उस प्रक्रिया में कुछ और चीज़ें तोड़ सकता है। अब डेवलपर को पूरी चीज़ को फिर से चेक करना होगा। यह पाइप में लीकेज ठीक करने और गलती से दूसरा पाइप फोड़ देने जैसा है।
4. भविष्य के लिए इसका क्या अर्थ है
शोध पत्र निष्कर्ष निकालता है कि सॉफ्टवेयर डेवलपर की भूमिका बदल रही है। वे कम होकर शिल्पकार (जो हर ईंट को हाथ से बनाते हैं) के बजाय प्रबंधक (जो दूसरों के काम को नियुक्त करते हैं, निर्देशित करते हैं और निरीक्षण करते हैं) बनते जा रहे हैं।
शोधकर्ता सुझाव देते हैं कि हमें इन रोबोटों को बनाने के लिए जिन टूल्स का उपयोग करना चाहिए, उन्हें बदलना होगा ताकि वे मनुष्यों को इस "प्रबंधन" कार्य को बेहतर ढंग से करने में मदद कर सकें। उदाहरण के लिए, केवल कोड की एक दीवार दिखाने के बजाय, टूल्स को एक स्पष्ट मानचित्र दिखाना चाहिए कि रोबोट का इरादा क्या था बनाम उसने वास्तव में क्या किया, जिससे "निरीक्षण" का चरण कम सिरदर्द वाला हो सके।
संक्षेप में: इंसान केवल रोबोट की गलतियों का इंतज़ार नहीं कर रहे हैं; वे नियम सेट कर रहे हैं, यात्रा की योजना बना रहे हैं, और रोबोट को पटरी पर रखने के लिए स्मार्ट शॉर्टकट का उपयोग कर रहे हैं। लेकिन वर्तमान में, टूल्स इस "प्रबंधन" के काम को आसान बनाने के लिए पर्याप्त विकसित नहीं हैं, इसलिए सिस्टम को सुरक्षित रखने के लिए इंसान बहुत भारी मेहनत कर रहे हैं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।