AI एजेंट सेल्फ-प्रोग्रामिंग-सक्षम बनाने के लिए आवश्यक घटक क्या हैं?

Question

एक एआई एजेंट को अक्सर "सेंसर", "एक मेमोरी", "मशीन लर्निंग प्रोसेसर" और "प्रतिक्रिया" घटक होने के बारे में सोचा जाता है। हालांकि, इन के साथ एक मशीन जरूरी नहीं कि एक आत्म-प्रोग्रामिंग AI एजेंट बन जाए। ऊपर वर्णित भागों के अलावा, क्या कोई अन्य तत्व या विवरण है जो किसी मशीन को स्व-प्रोग्रामिंग एआई एजेंट होने में सक्षम बनाने के लिए आवश्यक है?

उदाहरण के लिए, 2011 के एक पेपर ने घोषित किया कि बुद्धिमत्ता को अधिकतम करने की अनुकूलन समस्या को हल करना स्वयं-प्रोग्रामिंग प्रक्रिया के लिए आवश्यक विशेषता है, जैसा कि नीचे उद्धृत किया गया है:

एक प्रणाली को स्व-प्रोग्रामिंग का एक उदाहरण देने के लिए कहा जाता है जब यह अपने "संज्ञानात्मक बुनियादी ढांचे" के कुछ तत्व के बारे में सीखने से गुजरता है, जहां बाद को सिस्टम के "खुफिया-महत्वपूर्ण" विशेषताओं के फजी सेट के रूप में परिभाषित किया गया है; और एक सिस्टम फीचर की बुद्धिमत्ता-महत्वपूर्णता को "फीचर क्वालिटी" के रूप में परिभाषित किया जाता है, जिसे मल्टी-फीचर सिस्टम की बुद्धिमत्ता को अधिकतम करने की अनुकूलन समस्या को हल करने के दृष्टिकोण से माना जाता है।

हालांकि, "बुद्धि का अनुकूलन" का यह वर्णन अस्पष्ट है। क्या स्व-प्रोग्रामिंग एजेंटों के लिए आवश्यक घटकों के लिए कोई स्पष्ट परिभाषा या बेहतर सारांश दे सकता है?

_{यह प्रश्न 2014 के बंद बीटा से है, जिसमें पूछने वाले का 23 का यूआईडी है।}

Comments

यहाँ आत्म-अनुकूलन पर बहुत अंतिम शब्द है: arxiv.org/abs/cs/0309048

— NietzscheanAI

खोए हुए बीटा में खोई और अच्छी सामग्री के पुनरुद्धार के लिए धन्यवाद । :-)

— पीटर - मोनिका

Answer 1

उच्चतम स्तर पर, कोड ऑब्जेक्ट्स को शामिल करने के लिए पहले से ही चर्चा की गई विभिन्न प्रणालियों के लिए इसकी सभी आवश्यकताएं हैं। अगर यह अपने स्रोत कोड / मॉडल आर्किटेक्चर को स्वरूपित टेक्स्ट ऑब्जेक्ट्स से रेखांकित कर सकता है, तो उन्हें एक उपयोगी एमएल मॉडल होने के संदर्भ में 'समझ' सकता है, और अपनी प्रतिक्रिया के साथ कोड को बदल सकता है, फिर यह स्वयं-प्रोग्राम कर सकता है।

यही है, एक बेहतर सुधार के पीछे बुनियादी लूप सरल है। यह खुद की जांच करता है, एक नया संस्करण लिखता है, और फिर वह नया संस्करण स्वयं की जांच करता है और एक नया संस्करण लिखता है, और इसी तरह।

कठिन घटक निम्न स्तरों पर आता है। हमें 'सेंसर' की तरह एक नई अवधारणा का आविष्कार करने की आवश्यकता नहीं है, जो हमें करने की आवश्यकता है वह बहुत, बहुत परिष्कृत सेंसर का निर्माण है जो कोड को समझने और सुधार लिखने के लिए पर्याप्त रूप से समझने के कार्य के बराबर हैं।

Comments

हालाँकि, अपने स्वयं के कोड को समझने वाली प्रणालियों के बारे में बयानों के लिए घुटने के झटका कंप्यूटर विज्ञान की प्रतिक्रिया अक्सर रुकने की समस्या का हवाला देते हैं, यह पता चलता है कि एआई दृष्टिकोण के बारे में कहने के लिए कुछ उपयोगी है: cs.stackexchange.com/questions/69393/ …

— नीत्शेचियन १०

ठीक है, हॉल्टिंग समस्या सभी संभावित कोड को पूरी तरह से समझने के लिए एक नो-गो प्रमेय है , लेकिन किसी को भी अधिकांश कोड की अच्छी समझ होने से नहीं रोकती है जो आप वास्तव में देखते हैं।

— मैथ्यू ग्रेव्स

वास्तविक रूप से रुकने की समस्या केवल 'टर्निंग मशीन' पर लागू होती है जो कि शुद्ध गणितीय निर्माण हैं जो वास्तव में मौजूद नहीं हो सकते हैं (उन्हें उदाहरण के लिए असीमित मेमोरी के लिए एक अनंत टेप की आवश्यकता होती है) और अनंत समय तक चल सकते हैं। वास्तविक दुनिया के कंप्यूटरों में सीमित मात्रा में मेमोरी होती है। ऐसे सॉफ़्टवेयर लिखने के तरीके हैं जो औपचारिक रूप से सत्यापित किए जा सकते हैं (इदरिस, कॉक)। निर्भर प्रकारों का उपयोग करना। एक सरणी का आकार (यानी <राशि या राम) सीमित करें। एक कार्यक्रम को स्मृति में खुद को संशोधित करने की अनुमति नहीं देना, जो औपचारिक सबूतों का उल्लंघन कर सकता है। कोई अनंत छोर नहीं। कोई बाइट लूप / डिवाइड ज़ीरो से नहीं। आदि ...

— डेविड सी। बिशप