Identifying potentiating events in evolutionary search using replay experiments

कल्पना कीजिए कि आप एक वीडियो गेम देख रहे हैं जहाँ एक पात्र एक विशाल पहेली को सुलझाने की कोशिश कर रहा है। आप देखते हैं कि वह आखिरकार कोड को तोड़ देता है और जीत जाता है, लेकिन आपको यह पता ही नहीं है कि वह वहाँ कैसे पहुँचा। क्या उसने किसी भाग्यशाली ट्रिक का सहारा लिया? क्या उसने खेल के बीच में कोई गुप्त कौशल सीखा जिसने बाकी खेल को आसान बना दिया? कंप्यूटर विज्ञान की दुनिया में, इवोल्यूशनरी कंप्यूटिंग (Evolutionary Computing) नामक एक क्षेत्र है। यह एक डिजिटल पेट्री डिश की तरह है जहाँ हम बैक्टीरिया के बजाय कंप्यूटर प्रोग्रामों को "पालते" हैं। हम इन प्रोग्रामों को विकसित होने देते हैं, उन्हें आपस में मिलाते और उनमें उत्परिवर्तन (mutation) करते हैं ताकि यह देखा जा सके कि वे समस्याओं को हल करने में बेहतर हो सकते हैं या नहीं, जैसे कि सॉफ़्टवेयर में बग ठीक करना या रोबोट की गतिविधियों को डिजाइन करना।

आमतौर पर, जब कोई कंप्यूटर प्रोग्राम अंततः एक कठिन समस्या को हल कर लेता है, तो हम बस जीत का जश्न मनाते हैं। लेकिन वैज्ञानिक जिज्ञासु हैं: क्यों इसने इस बार काम किया और पिछली बार क्यों नहीं? क्या कोड में कोई विशिष्ट परिवर्तन था जिसने बाद में सफलता को संभव बनाया? यहीं पर पोटेंशिएशन (potentiation) का विचार आता है। इसे एक वीडियो गेम में "पावर-अप" की तरह समझें। आप शायद तुरंत उस पावर-अप का कुछ भी करते हुए नहीं देख पाएंगे, लेकिन यह पात्र को बदल देता है ताकि बाद में, जब उसे एक विशिष्ट चाबी मिले, तो वह उस दरवाजे को खोल सके जिसे वह पहले नहीं खोल सकता था। यह पेपर जिस प्रश्न का समाधान करता है वह यह है: हम कंप्यूटर के इतिहास को कैसे देख सकते हैं ताकि उन छिपे हुए पावर-अप्स को खोज सकें जिन्होंने एक समाधान को संभव बनाया, भले ही उस समय कंप्यूटर पहले की तुलना में अधिक "स्मार्ट" नहीं दिख रहा था?

---

डिजिटल जीवन की टेप को रिवाइंड करना

इस पेपर में, ऑस्टिन फर्ग्यूसन और अलेक्जेंडर ललेजिनी एक नया तरीका पेश करते हैं जिससे हम इन डिजिटल विकासों का अध्ययन करने के लिए रिप्ले प्रयोगों (replay experiments) का उपयोग करते हैं। आप इसे एक फिल्म को "रिवाइंड" बटन दबाने की तरह समझ सकते हैं, लेकिन केवल उसी फिल्म को फिर से देखने के बजाय, आप उसे अलग-अलग क्षणों पर रोकते हैं, उस समय पात्रों की एक प्रति (copy) बनाते हैं, और उसी बिंदु से कई नई फिल्में शुरू करते हैं।

वास्तविक दुनिया में, वैज्ञानिकों ने यह बैक्टीरिया के साथ किया है। वे प्रयोगशाला प्रयोग में विभिन्न दिनों के बैक्टीरिया के नमूनों को फ्रीज कर देते हैं। बाद में, वे उन्हें पिघलाते हैं और उन्हें फिर से विकसित होने देते हैं ताकि यह देखा जा सके कि क्या वे अभी भी एक नया गुण विकसित कर सकते हैं, जैसे कि एक नए प्रकार के भोजन को खाना। यदि वे ऐसा कर सकते हैं, तो इसका मतलब है कि बैक्टीरिया ने पहले ही कुछ छिपे हुए परिवर्तनों के साथ खुद को "तैयार" कर लिया था।

लेखक इस विचार को कंप्यूटर प्रोग्रामों की दुनिया में लाते हैं। उनका तर्क है कि हम सॉफ़्टवेयर के साथ भी ऐसा ही कर सकते हैं। केवल एक प्रोग्राम को विकसित होते हुए देखने और उम्मीद करने के बजाय, हम हर चरण पर प्रोग्राम का "स्नैपशॉट" ले सकते हैं। फिर, हम उन स्नैपशॉट को ले सकते हैं और उस बिंदु से विकास के सैकड़ों नए, थोड़े अलग संस्करण चला सकते हैं। यह देखकर कि ये नए संस्करण कितनी बार सफल होते हैं, हम समस्या को हल करने की प्रोग्राम की क्षमता (potential/potentiation) को माप सकते हैं।

बड़ी हैरानी: सफलता हमेशा "मजबूत" होने के बारे में नहीं होती

लेखकों ने जेनेटिक प्रोग्रामिंग (Genetic Programming) नामक एक सरल प्रकार के कंप्यूटर प्रोग्राम का उपयोग करके एक प्रदर्शन चलाया। उन्होंने 1,000 अलग-अलग समूहों को सेट किया और उन्हें एक विशिष्ट पहेली को हल करने की कोशिश करने दी: संख्याओं को "छोटा", "बड़ा", या "दोनों में से कोई नहीं" में छाँटना।

यहाँ ट्विस्ट है जो उन्हें मिला, और यह उनकी कहानी का सबसे महत्वपूर्ण हिस्सा है: समस्या में बेहतर होना हमेशा इसका मतलब नहीं है कि आप जीतने के करीब पहुँच रहे हैं।

उनके प्रयोग में, उन्होंने दो चीजों को ट्रैक किया:

1. फिटनेस (Fitness): प्रोग्राम उस क्षण में कितनी अच्छी तरह प्रदर्शन कर रहा है (जैसे कि गेम में स्कोर)।
2. पोटेंशिएशन (Potentiation): इस बात की संभावना कि यदि वे विकसित होते रहे तो प्रोग्राम पहेली को पूरी तरह से हल कर देगा।

उनके परीक्षण समूहों में से एक (Population A) में, प्रोग्राम एक "लोकल ऑप्टिमम" (local optimum) पर पहुँच गया। यह एक वीडियो गेम में एक खिलाड़ी के फंस जाने जैसा है। उनका स्कोर सुधरना बंद हो गया और लंबे समय तक 75% पर स्थिर रहा। एक पर्यवेक्षक के लिए, यह ऐसा लग रहा था जैसे प्रोग्राम बस एक ही जगह घूम रहे हैं। लेकिन फिर, लेखकों ने "रिवाइंड" बटन दबाया और रिप्ले चलाए।

उन्होंने पाया कि उस समूह के इतिहास के एक विशिष्ट क्षण में, पोटेंशिएशन अचानक 1% से बढ़कर 40% हो गया। प्रोग्राम अचानक पहेली को पूरी तरह से हल करने के लिए कहीं अधिक संभावित हो गए थे, भले ही उनकी फिटनेस (स्कोर) में कोई बदलाव नहीं हुआ था! वे अभी भी 75% पर अटके हुए थे, लेकिन उन्होंने गुप्त रूप से एक "पावर-अप" प्राप्त कर लिया था जिसने एक पूर्ण समाधान को संभव बना दिया था।

यह एक बड़ी बात है क्योंकि यह सुझाव देता है कि विकासवादी खोज (evolutionary search) में, आप केवल वर्तमान स्कोर को देखकर यह नहीं जान सकते कि आप जीत रहे हैं या नहीं। एक प्रोग्राम विफल होता हुआ या अटका हुआ लग सकता है, लेकिन वह एक ऐसे खजाने पर बैठा हो सकता है जिसकी क्षमता अभी तक स्कोर में नहीं दिखी है।

उन्होंने इसे कैसे किया (द "इंजीनियर्ड" रिप्ले)

इसे साबित करने के लिए, लेखकों ने केवल अनुमान नहीं लगाया। उन्होंने इंजीनियर्ड रिप्ले (engineered replay) नामक एक चतुर तकनीक का उपयोग किया। कल्पना कीजिए कि आपके पास एक पात्र के दो संस्करण हैं: एक लाल टोपी वाला और एक लाल टोपी और नीले स्कार्फ वाला। आप जानना चाहते हैं कि किस वस्तु ने उन्हें जीतने में मदद की।

एक सामान्य रिप्ले में, आप "लाल टोपी" वाले संस्करण और "लाल टोपी + नीला स्कार्फ" वाले संस्करण से नए गेम शुरू करेंगे। लेकिन बहुत सटीक होने के लिए, लेखकों ने "इंजीनियर्ड" संस्करण बनाए। उन्होंने केवल नीले स्कार्फ वाला एक नया पात्र बनाया (जो मूल इतिहास में वास्तव में कभी मौजूद नहीं था) और उससे भी रिप्ले चलाए। इससे उन्हें यह पता लगाने में मदद मिली कि कोड में कौन सा छोटा सा बदलाव वह गुप्त पावर-अप था।

भविष्य के लिए इसका क्या अर्थ है

यह पेपर यह दावा नहीं करता है कि इसने विकास के सभी रहस्यों को सुलझा लिया है, बल्कि यह सुझाव देता है कि रिप्ले प्रयोग एक शक्तिशाली उपकरण हैं जिनका हमने पर्याप्त उपयोग नहीं किया है। यह दर्शाता है कि:

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

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