एक ही प्रॉम्प्ट, अलग परिणाम: उत्पादन में पुनरुत्पादकता

जब एक ही इनपुट हर बार एक जैसा आउटपुट नहीं देता, तो किसी परिणाम पर भरोसा उस एकल आउटपुट स्वयं से नहीं, बल्कि उसे उत्पन्न करने वाले शर्तों के रिकॉर्ड से आता है। संभाव्य जनरेटर के लिए पुनरुत्पादकता बिट-स्तर पर बिल्कुल वही परिणाम वापस लाने का अर्थ नहीं है; इसका अर्थ है कि समान परिस्थितियों में पर्याप्त रूप से समान परिणाम को भरोसेमंद तरीके से फिर से प्राप्त कर पाना। भरोसा आउटपुट पर नहीं; आउटपुट के कैसे बने इसकी प्रक्रिया पर होता है।

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

निर्धारक और संभाव्य उत्पादन के बीच की सीमा

निर्धारक उत्पादन वह व्यवहार है जिसमें एक ही इनपुट हर बार वही आउटपुट देता है। दो संख्याओं का योग तय है; एक फ़ाइल एक ही नियम के अनुसार बदली जाए तो आउटपुट हर बार समान रहेगा। इस ज़मीन पर पुनरुत्पादकता लगभग मुफ्त मिल जाती है, क्योंकि परिवर्तनशीलता मौज़ूद ही नहीं होती।

संभाव्य उत्पादन बिलकुल अलग मैदान पर खड़ा है। यहाँ कोई आउटपुट एकल सही जवाब के पुनः कॉल जैसा नहीं होता; बल्कि संभावित कई आगे बढ़ने के विकल्पों में से संभाव्यता वितरण के अनुसार एक चयन होता है। एक ही प्रॉम्प्ट समान वितरण पैदा करता है; पर उस वितरण से लिया गया नमूना हर बार वही होने की बाध्यता नहीं रखता। आउटपुट का बदलना कोई त्रुटि नहीं, बल्कि सिस्टम की डिज़ाइन का हिस्सा है।

इस अंतर को न समझना गलत अपेक्षाएँ पैदा करता है। निर्धारक सिस्टम पर विकसित किया गया बग-फिक्सिंग का तरीका, अगर वैसा ही तौर-तरीका संभाव्य सिस्टम पर लगाया जाए तो काम नहीं करेगा। "एक बार काम किया, तो वह सही है" जैसा निष्कर्ष केवल वितरण से दिया गया एकल नमूना देखने जैसा होता है। इसके विपरीत भी सत्य है: एक रन का खराब निकलना सिस्टम खराब होने का सबूत नहीं होता; संभवतः वितरण की लंबी पूँछ का एक नमूना ही देखा गया हो।

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

तापमान और सीड आउटपुट स्थिरता को कैसे प्रभावित करते हैं

नमूनाकरण तापमान एक सामान्य अवधारणा है जो यह समायोजित करती है कि वितरण से चयन करते समय कितनी विविधता की अनुमति है। कम तापमान पर चयन सबसे संभाव्य आगे बढ़ने की ओर सिमट जाता है; आउटपुट अधिक स्थिर, अधिक अनुमाननीय पर कम विविध होता है। उच्च तापमान पर वितरण के कम संभाव्य क्षेत्रों तक भी पहुँच बनती है; आउटपुट में विविधता आती है, पर स्थिरता कम हो जाती है।

सीड (तोहू) एक अलग लीवरेज है। सीड नमूनाकरण के दौरान रैंडमनेस को निर्धारित करने वाला प्रारंभिक मान होता है; वही सीड समान परिस्थितियों में समान नमूनाकरण पथ को दोहरा देता है। जहाँ तापमान विविधता की चौड़ाई को समायोजित करता है, वहीं सीड उस विविधता के भीतर कौन सा पथ चुना जाएगा उसे स्थिर करता है। दोनों को साथ में सोचना चाहिए: सीड को फिक्स करने से, उच्च तापमान पर भी किसी खास रन को पुनः प्राप्त किया जा सकता है।

फिर भी सीड फिक्स करना खुद में पुनरुत्पादकता की गारंटी नहीं है। वही सीड तभी वही परिणाम देगा जब परिवेश की हर चीज़ समान बनी रहे; यदि उत्पादन वातावरण का कोई भी हिस्सा बदले तो वही सीड अलग पथ पर गिर सकता है। इसलिए सीड स्थिरता का अकेला आधार नहीं है; यह एक बड़े 'फ्रीज़' रणनीति का सिर्फ़ एक हिस्सा है।

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

संस्करण फिक्सिंग और वातावरण को जमे हुए रूप में रखने का महत्व

किसी आउटपुट को फिर से पैदा करने के लिए, उसे उत्पन्न करने वाली हर चीज़ बराबर रहनी चाहिए। संस्करण फिक्सिंग एक उत्पादन वातावरण के घटकों को एक निश्चित और अपरिवर्तनीय स्थिति में 'काँटने' की प्रथा है। वह वातावरण जो अपने आप अपडेट हो रहा है आरामदेह हो सकता है पर पुनरुत्पादकता का सबसे चुपचाप खलनायक भी होता है: कल प्राप्त आउटपुट आज वापस नहीं आएगा, और कारण भी दिखाई नहीं देगा।

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

इसका एक मूल्य भी है। जमे हुए वातावरण बाहरी दुनिया के सुधारों से भी कट जाता है; समय के साथ वह पुराना पड़ जाता है और किसी बिंदु पर उसे अपडेट करने की ज़रूरत होती है. संस्करण फिक्सिंग एक उत्पादन वातावरण के घटकों और सेटिंग्स को इस तरह से बाँधने की प्रथा है कि बाद में उन्हें एक-एक करके वापस लाया जा सके। मूल मुद्दा यह है कि जमे रखना और बहने देना के बीच एक जानबूझकर संतुलन बनाना।

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

"पर्याप्त रूप से समान" का अर्थ: बिट-समता और अर्थगत समतुल्यता

पुनरुत्पादकता कहते ही पहले जो ख्याल आता है वह यह है कि दो आउटपुट अक्षर दर अक्षर समान हों। पर संभाव्य उत्पादन में यह कठोर मानदंड अक्सर न तो यथार्थवादी है न ही आवश्यक। असली सवाल यह है कि क्या दोनों आउटपुट एक ही कार्य एक ही गुणवत्ता के साथ कर रहे हैं; यानी बिट-स्तर की समानता चाहिए या अर्थगत समतुल्यता।

सही मापदंड चुनना कार्य की प्रकृति पर निर्भर करता है। पहचान बनाने या गणना करने वाले चरण में बिट-स्तर समानता आवश्यक है; एक छोटी सी विचलन परिणाम को खराब कर सकती है। किसी पाठ को पुनर्लेखन करने या सुझाव देने वाले चरण में दो भिन्न आउटपुट दोनों समान रूप से सही हो सकते हैं। गलत मापदंड ठेलना, मौजूद न होने वाली समस्या के पीछे दौड़ने या असली समस्या को नज़रअंदाज़ करने का कारण बनता है।

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

एक आउटपुट को कैसे नियंत्रित और पुनरुत्पादित किया जाए

किसी आउटपुट को बाद में समझाना उसे उत्पन्न करने वाली शर्तों के उस वक़्त रिकॉर्ड होने पर निर्भर करता है। नियंत्रणक्षमता कोई संयोग नहीं, बल्कि अनुशासन का परिणाम है। नीचे दी गई क्रमावली सिद्धांत स्तर पर किसी आउटपुट को पुनरुत्पादित करने के लिए आवश्यक कदमों का वर्णन करती है।

1. आउटपुट को उत्पन्न करने वाली शर्तें रिकॉर्ड करें: प्रॉम्प्ट का पूरा स्वरूप, सेटिंग्स, सीड और जमे हुए संस्करण की जानकारी।
2. पहले तय करें कि किस प्रकार की समतुल्यता चाहिए: बिट-स्तर समानता या अर्थगत समतुल्यता।
3. वातावरण को रिकॉर्ड की गई स्थिति में वापस लाएँ; बहता नहीं, फिक्स्ड संस्करण के साथ पुनः चलाएँ।
4. नए आउटपुट की तुलना चुने हुए समतुल्यता मानदंड के अनुसार पुराने से करें, बिना कच्ची समानता की अपेक्षा किए।
5. यदि विचलन है, तो किस शर्त से आया यह अलग-अलग चीज़ें बदलकर अलग-थलग करके खोजें।
6. इस रिकॉर्ड को आउटपुट के साथ संग्रहीत रखें; बिना रिकॉर्ड के परिणाम को समझाया नहीं जा सकता, सिर्फ़ पुनरागमन की आशा की जा सकती है।

इन कदमों के पीछे कुछ अवधारणाएँ निहित हैं। उन्हें अलग करना चर्चा को साफ़ करता है।

नियंत्रणक्षमता

यह क्षमता कि बाद में यह ट्रेस किया जा सके और बताया जा सके कि किसी आउटपुट को किन शर्तों के तहत उत्पन्न किया गया था।

अर्थगत समतुल्यता

दो आउटपुट जो अक्षर दर अक्षर समान नहीं हैं, फिर भी एक ही अर्थ रखते हैं और एक ही कार्य करते हैं, यह मानना।

स्रोत पृथक्करण

किसी अंतर का स्रोत कौन-सी शर्त है, यह बाकी सब स्थिर रखते हुए एक-एक करके अलग करना।

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

अनिश्चितता हमेशा दोष नहीं—कब वह वांछनीय है

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

इसलिए अनिश्चितता कोई सार्वभौमिक दोष नहीं है; यह एक समायोजन है जिसका मूल्य कार्य के अनुसार बदलता है। गलत है अनिश्चितता स्वयं नहीं, बल्कि उसे गलत जगह पर रखना है। जहाँ विविधता चाहिए वहाँ जबरन स्थिरता थोपना आउटपुट को गरीब बना देता है; जहाँ स्थिरता चाहिए वहाँ अनिश्चितता की अनुमति देना विश्वास को धराशायी कर देता है। कौशल यह पहचानने में है कि किस चरण को क्या चाहिए।

परिपक्व दृष्टिकोण अनिश्चितता को मिटाने की कोशिश नहीं करता; बल्कि उसे सीमित करने की कोशिश करता है। जहाँ विविधता मुक्त है, वहाँ भी पैदा हुए हर वेरिएशन की शर्तें रिकॉर्ड की जाती हैं; ताकि किसी पसंदीदा वेरिएशन को बाद में वापस बुलाया जा सके। अनिश्चितता और नियंत्रणक्षमता परस्पर विरोधी नहीं हैं: अस्थिरता की अनुमति देकर भी शर्तों को रिकॉर्ड करना दोनों को साथ में संभव करता है।

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