Evaluating RL Explainability Methods by How Much They Help Fix Bugs in Agents
यह शोध पत्र EvalXRL का प्रस्ताव करता है, जो एक नया बेंचमार्क है जो व्याख्यात्मक सुदृढीकरण शिक्षण (XRL) विधियों का मूल्यांकन उनके उस व्यावहारिक उपयोगिता के आधार पर करता है जो एक LLM कोडिंग एजेंट को खराबी वाले RL एजेंटों को पुनरावृत्तीय रूप से निदान करने और सुधारने में मदद करता है, जो पारंपरिक मेट्रिक्स से आगे बढ़कर एक क्लोज्ड-लूप, परिणाम-संचालित मूल्यांकन की ओर ले जाता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
आर्टिफिशियल इंटेलिजेंस की दुनिया में, मशीन लर्निंग सिस्टम को समझने योग्य बनाने के लिए समर्पित एक बढ़ता हुआ क्षेत्र है। ये सिस्टम, जिन्हें अक्सर 'एजेंट्स' कहा जाता है, अलग-अलग क्रियाएं करके और यह देखकर कि क्या होता है, निर्णय लेना सीखते हैं—यह एक प्रक्रिया है जिसे 'रिनफोर्समेंट लर्निंग' (reinforcement learning) कहा जाता है। कभी-कभी, ये एजेंट पूरी तरह से काम करते हैं, लेकिन अन्य समय में वे अजीब तरीकों से विफल हो जाते हैं, जैसे लूप में फंस जाना या ऐसे चुनाव करना जो पूरी तरह से तर्कहीन लगते हैं। जब ऐसा होता है, तो डेवलपर्स को जानने की जरूरत होती है कि ऐसा क्यों हुआ। उन्हें ऐसे स्पष्टीकरणों की आवश्यकता होती है जो केवल यह न बताएं कि एजेंट ने क्या किया; उन्हें अंतर्निहित कारणों को समझने की आवश्यकता है ताकि वे समस्या को ठीक कर सकें। वर्षों से, शोधकर्ता यह मापने की कोशिश कर रहे हैं कि उनके स्पष्टीकरण कितने अच्छे हैं, या तो लोगों से यह पूछकर कि क्या उन्हें लगता है कि वे समझ गए हैं, या यह जाँचकर कि क्या स्पष्टीकरण कंप्यूटर के आंतरिक गणित से मेल खाता है। लेकिन यह महसूस करना कि आप समझ गए हैं, वास्तव में एक टूटी हुई मशीन को ठीक करने में सक्षम होने के समान नहीं है।
शोधकर्ताओं की एक टीम का एक नया प्रस्ताव इन स्पष्टीकरण उपकरणों (explanation tools) को परखने का एक अधिक व्यावहारिक तरीका सुझाता है। लोगों से यह पूछने के बजाय कि वे कैसा महसूस करते हैं, वे यह परीक्षण करने का प्रस्ताव देते हैं कि क्या स्पष्टीकरण वास्तव में एक कोडर को टूटे हुए एजेंट की मरम्मत करने में मदद करते हैं। मूल विचार सरल है: यदि कोई स्पष्टीकरण वास्तव में उपयोगी है, तो उसे किसी विशिष्ट त्रुटि को पहचानने और उसे ठीक करने में मदद करनी चाहिए, जिससे एक बेहतर प्रदर्शन करने वाली मशीन प्राप्त हो सके। यह दृष्टिकोण समझ के अमूर्त सिद्धांतों से हटकर एक ठोस, कार्यात्मक परिणाम पर ध्यान केंद्रित करता है। शोधकर्ता अपने प्रस्तावित परीक्षण को "EvalXRL" कहते हैं। इसे एक मानक बेंचमार्क के रूप में डिज़ाइन किया गया है जहाँ विभिन्न स्पष्टीकरण विधियों को अंतिम परीक्षा दी जाती है: क्या वे एक सॉफ्टवेयर एजेंट को दूसरे सॉफ्टवेयर एजेंट में बग खोजने और उसे ठीक करने में मदद कर सकते हैं?
शोधकर्ताओं ने एक नियंत्रित प्रयोग डिजाइन किया है जहाँ वे जानबूझकर रिनफोर्समेंट लर्निंग एजेंटों को खराब करते हैं। वे कोड में विशिष्ट, ज्ञात त्रुटियां पैदा करते हैं, जैसे कि एजेंट कैसे पुरस्कार (rewards) प्राप्त करता है इसे बदलना या उस वातावरण को बदलना जिसमें वह कार्य करता है। उदाहरण के लिए, वे एक खजाना खोजने वाले एजेंट को बड़े सिक्कों की तुलना में छोटे सिक्कों को अधिक महत्व देने के लिए प्रोग्राम कर सकते हैं, या वे एक ट्रैफिक कंट्रोल सिस्टम को केवल एक सेकंड के लिए ट्रैफिक को तेज़ दिखाने के लिए लंबी कारों की कतारें बनाने के लिए धोखा दे सकते हैं। एक बार जब ये एजेंट खराब हो जाते हैं, तो शोधकर्ता एक कृत्रिम बुद्धिमत्ता कोडर (AI coder), जो सॉफ्टवेयर लिखने और ठीक करने के लिए प्रशिक्षित एक लार्ज लैंग्वेज मॉडल है, को पेश करते हैं। इस कोडर को खराब एजेंट और एक विशिष्ट स्पष्टीकरण उपकरण तक पहुंच दी जाती है। कोडर का काम उस टूल का उपयोग करके यह पता लगाना है कि क्या गलत है और फिर कोड को ठीक करने के लिए लिखना है।
प्रयोग एक बंद लूप (closed loop) की तरह सेट किया गया है। कोडर केवल एक स्पष्टीकरण को देखकर अनुमान नहीं लगाता। इसके बजाय, कोडर स्पष्टीकरण उपकरण से जानकारी मांग सकता है, उत्तर का विश्लेषण कर सकता है, क्या गलत है इसके बारे में एक नया सिद्धांत बना सकता है, और फिर एक अलग प्रश्न या सेटिंग के साथ टूल से दोबारा पूछ सकता है। यह प्रक्रिया एक मानव इंजीनियर के काम करने के तरीके की नकल करती है, जो समस्या हल होने तक परिकल्पनाओं (hypotheses) का परीक्षण करता है। शोधकर्ता एक सैंडबॉक्स्ड कंप्यूटर वातावरण का उपयोग करते हैं ताकि कोडर इंटरनेट पर उत्तर खोजकर धोखाधड़ी न कर सके। कोडर की सफलता का एकमात्र तरीका स्पष्टीकरण उपकरण का प्रभावी ढंग से उपयोग करना है। प्रत्येक स्पष्टीकरण विधि की सफलता को बाद में मरम्मत किए गए एजेंट के प्रदर्शन के आधार पर मापा जाता है। यदि एजेंट सही ढंग से काम करने लगता है और उच्च स्कोर अर्जित करता है, तो स्पष्टीकरण उपकरण को सफल माना जाता है। यदि एजेंट टूटा हुआ रहता है या और भी खराब हो जाता है, तो टूल को कम उपयोगी माना जाता है।
टीम विभिन्न स्पष्टीकरण विधियों का परीक्षण करने की योजना बना रही है, जिसमें इमेज के महत्वपूर्ण हिस्सों को उजागर करने वाले विजुअल मैप्स से लेकर टेक्स्ट विवरण तक शामिल हैं जो बताते हैं कि एजेंट ने एक निश्चित विकल्प क्यों चुना। वे इन विधियों की तुलना दो चरम सीमाओं के विरुद्ध करेंगे: एक बेसलाइन जहाँ कोडर के पास कोई स्पष्टीकरण उपकरण नहीं है और उसे कच्चे कोड के आधार पर अनुमान लगाना पड़ता है, और एक "रेफरेंस" परिदृश्य जहाँ कोडर को सरल भाषा में बताया जाता है कि बग वास्तव में क्या है। यह सेटअप उन्हें यह देखने की अनुमति देता है कि क्या स्पष्टीकरण उपकरण केवल सोर्स कोड होने के अलावा कोई वास्तविक मूल्य प्रदान करते हैं, और वे तुरंत उत्तर जानने वाले आदर्श परिदृश्य के कितने करीब आते हैं।
शोधकर्ताओं की इस बेंचमार्क के संबंध में तीन मुख्य अपेक्षाएं हैं। पहला, उन्हें संदेह है कि कोई भी एक स्पष्टीकरण उपकरण हर प्रकार के बग को ठीक करने में सर्वश्रेष्ठ नहीं होगा। कुछ उपकरण रिवॉर्ड की गणना से संबंधित त्रुटियों को खोजने में बेहतरीन हो सकते हैं, जबकि अन्य एजेंट के वातावरण को समझने से जुड़ी समस्याओं को पकड़ने में बेहतर हो सकते हैं। इसका मतलब है कि क्षेत्र को एक सार्वभौमिक समाधान के बजाय विविध उपकरणों के समूह की आवश्यकता है। दूसरा, उन्हें उम्मीद है कि भले ही कोडर को ठीक-ठीक बताया जाए कि बग क्या है, फिर भी वे हमेशा इसे पूरी तरह से ठीक नहीं कर पाएंगे। यह दिखाएगा कि समस्या का निदान करना केवल आधी लड़ाई है; वास्तव में समाधान को इंजीनियर करना अक्सर कठिन हिस्सा होता है। अंत में, और शायद सबसे आश्चर्यजनक रूप से, वे भविष्यवाणी करते हैं कि कुछ स्पष्टीकरण उपकरण चीजों को वास्तव में बदतर बना सकते हैं। एक टूल एक आत्मविश्वासी लेकिन भ्रामक स्पष्टीकरण दे सकता है जो कोडर को गलत रास्ते पर ले जाता है, जिससे वह कोड के गलत हिस्से को ठीक करने लगता है। यह सिद्ध करेगा कि एक अच्छी तरह से लिखा गया स्पष्टीकरण हमेशा मददगार नहीं होता है।
यह प्रस्ताव वर्तमान में एक भविष्य के अध्ययन की एक योजना है, न कि पूर्ण परिणामों का एक सेट। शोधकर्ता अपने डिजाइन और अपनी परिकल्पनाओं को वैज्ञानिक समुदाय के सामने प्रस्तुत कर रहे हैं ताकि पूर्ण प्रयोग चलाने से पहले फीडबैक प्राप्त किया जा सके। वे इस पर इनपुट मांग रहे हैं कि क्या उनके द्वारा चुने गए बग के प्रकार वे हैं जो अभ्यासकर्ताओं (practitioners) के लिए सबसे महत्वपूर्ण हैं, और क्या एक कृत्रिम बुद्धिमत्ता कोडर का उपयोग करना एक मानव इंजीनियर के लिए उचित विकल्प है। वे स्वीकार करते हैं कि हालांकि AI कोडर तेज़ और सस्ते होते हैं, लेकिन वे मनुष्यों की तरह नहीं सोच सकते। हालांकि, उनका तर्क है कि जैसे-जैसे इंजीनियरिंग का अधिक कार्य स्वचालित (automated) हो रहा है, यह समझना कि ये उपकरण AI एजेंटों को अन्य AI एजेंटों को ठीक करने में कैसे मदद करते हैं, अपने आप में अत्यंत महत्वपूर्ण होता जा रहा है।
इस कार्य का अंतिम लक्ष्य 'एक्सप्लेनेबल आर्टिफिशियल इंटेलिजेंस' (Explainable AI) के क्षेत्र को व्यक्तिपरक रेटिंग से हटाकर वस्तुनिष्ठ, कार्यात्मक प्रमाण की ओर ले जाना है। यह मापकर कि सफलता एक टूटे हुए सिस्टम को मरम्मत करने की क्षमता पर आधारित है, शोधकर्ता एक ऐसा मानक बनाने की आशा करते हैं जो स्पष्ट रूप से दिखाता है कि कौन से स्पष्टीकरण तरीके वास्तव में उपयोगी हैं। यदि उनका दृष्टिकोण काम करता है, तो यह वर्तमान में उपलब्ध विभिन्न उपकरणों में से सही चुनाव करने में मदद करके, डेवलपर्स को सही काम के लिए सही टूल चुनने में सहायता कर सकता है। यह एक ऐसे भविष्य का मार्ग प्रदान करता है जहाँ हम केवल यह नहीं पूछते कि क्या कोई AI हमें समझ में आता है, बल्कि यह कि क्या वह हमें बेहतर, अधिक विश्वसनीय सिस्टम बनाने में मदद करता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।