Correctness, confidence, and context: Framing software assurance in the AI age

द ग्रेट सॉफ्टवेयर पज़ल: क्यों "परफेक्ट" होना लक्ष्य नहीं है

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

अब, कल्पना कीजिए कि एक नया तरह का सहायक आया है: आर्टिफिशियल इंटेलिजेंस (AI)। यह AI अनुमान लगाने में अविश्वसनीय रूप से स्मार्ट है, जैसे कि एक सुपर-फास्ट गेसर (अनुमान लगाने वाला) जिसने अब तक पढ़ी गई लगभग हर किताब पढ़ ली हो। लेकिन पुराने जमाने के इंजीनियरों के विपरीत, जो चीजों को सिद्ध करना चाहते थे, यह AI संभाव्यता (probabilities) पर काम करता है। यह कहता है, "मुझे 90% यकीन है कि यह सही उत्तर है," बजाय इसके कि "मैं निश्चित रूप से जानता हूँ कि यह सही उत्तर है।" यह एक बड़ी समस्या पैदा करता है: जब हमें सुरक्षा की आवश्यकता हो, तो हम एक ऐसे सिस्टम पर कैसे भरोसा करें जो अनुमानों पर बना है? यह वही पहेली है जिसे मैरी शॉ हल कर रही हैं। वह इस बारे में सोचने के तरीके को बदलना चाहती हैं कि सॉफ्टवेयर में "सटीकता" क्या है, और इसे "परफेक्शन" के असंभव सपने से हटाकर एक अधिक व्यावहारिक, इंजीनियर-जैसे दृष्टिकोण की ओर ले जाना चाहती हैं, जहाँ यह सुनिश्चित किया जा सके कि चीजें अपने काम के लिए "पर्याप्त अच्छी" हैं।

---

द पेपर का बड़ा विचार: "परफेक्ट" से "पर्याप्त अच्छा" तक

सॉफ्टवेयर इंजीनियरों के लिए इस मुख्य भाषण (keynote presentation) में, मैरी शॉ तर्क देती हैं कि हमें अपने सॉफ्टवेयर को 100% परफेक्ट सिद्ध करने की कोशिश करना बंद करना चाहिए और इसके बजाय इस पर ध्यान केंद्रित करना चाहिए कि क्या वह अपने उद्देश्य के लिए उपयुक्त (fit for its purpose) है। उनका सुझाव है कि सोचने का पुराना तरीका—एक प्रोग्राम को सही साबित करने के लिए नियमों का एक आदर्श सेट लिखने की कोशिश करना—टूटा हुआ है, खासकर अब जब हम AI का उपयोग कर रहे हैं।

यहाँ उनके तर्क की कहानी है, जिसे सरल भागों में विभाजित किया गया है:

1. द शैडो प्रॉब्लम: जो AI देख नहीं सकता

कल्पना कीजिए कि आप अपने एक दोस्त को एक जटिल वस्तु, जैसे कि फोल्डिंग पेपर कप, का वर्णन करने की कोशिश कर रहे हैं जिसने इसे पहले कभी नहीं देखा है। आप उसे केवल दीवार पर पड़ने वाली उसकी छाया दिखा सकते हैं। सामने से, छाया एक वर्ग (square) जैसी दिखती है। बगल से, यह एक त्रिकोण (triangle) जैसी दिखती है। ऊपर से, यह एक वृत्त (circle) जैसी दिखती है। यदि आपके पास केवल छायाएँ होतीं, तो आप अनुमान लगा सकते थे कि यह एक अजीब ब्लॉक है, लेकिन आप इस तथ्य को मिस कर जाते कि यह एक कप है जो पानी रख सकता है।

शॉ कहती हैं कि AI मॉडल उस दोस्त की तरह हैं जो छायाओं को देख रहा है। उन्हें "डिजिटल छायाओं" पर प्रशिक्षित किया जाता है—वह टेक्स्ट, कोड और डेटा जो ऑनलाइन मौजूद है। लेकिन वास्तविक दुनिया टैसिट नॉलेज (tacit knowledge - अंतर्निहित ज्ञान) से भरी है: ऐसी चीजें जिन्हें हम जानते हैं लेकिन लिखते नहीं हैं। इसमें कार्यस्थल का "वाइब", संस्कृति के अनकहे नियम, या एक अनुभवी मैकेनिक की सहज भावना शामिल है जब वह इंजन में अजीब आवाज सुनता है। क्योंकि यह ज्ञान लिखा हुआ नहीं है, इसलिए AI इसे देख नहीं सकता। वह केवल छाया देखता है, वास्तविक वस्तु नहीं। जब AI सॉफ्टवेयर बनाने की कोशिश करता है, तो वह इन महत्वपूर्ण, अदृश्य विवरणों को छोड़ सकता है, जिससे ऐसी गलतियाँ हो सकती हैं जिन्हें एक मानव विशेषज्ञ तुरंत पकड़ लेता।

2. कोडिंग का "कार्गो कल्ट"

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

वह चेतावनी देती हैं कि AI का उपयोग करके कोड लिखना कभी-कभी "कार्गो कल्ट" बन सकता है। हम AI से ऐसा कोड लिखने के लिए कह सकते हैं जो सही दिखता हो (छाया), बिना यह समझे कि कोड को इस तरह क्यों होना चाहिए (गहरा कारण)। यदि हम केवल "वाइब कोडिंग" (एक भावना या साधारण प्रॉम्प्ट के आधार पर कोड लिखना) के माध्यम से बिना छिपे हुए नियमों को समझे काम करते हैं, तो हम ऐसे सिस्टम बना सकते हैं जो अच्छे दिखते हैं लेकिन वास्तविक दुनिया की समस्याओं के आने पर बिखर जाते हैं।

3. "स्पेसिफिकेशन" के बजाय "क्रेडेंशियल्स"

पारंपरिक रूप से, इंजीनियर एक परफेक्ट "स्पेसिफिकेशन" (specification) लिखने की कोशिश करते हैं—नियमों की एक विशाल, कठोर किताब जो बताती है कि सॉफ्टवेयर को वास्तव में क्या करना चाहिए। शॉ का सुझाव है कि यह असंभव है क्योंकि दुनिया बदलती रहती है, और हम सब कुछ अनुमानित नहीं कर सकते।

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

• एक स्कूबा डाइवर एक कार्ड दिखाता है, "मैं 30 मीटर तक गोता लगा सकता हूँ।"
• एक पायलट एक लाइसेंस दिखाता है, "मैं इस विमान को उड़ा सकता हूँ।"
• एक सॉफ्टवेयर सिस्टम को एक "क्रेडेंशियल" दिखाना चाहिए जो कहता है, "मुझे 1,000 उपयोगकर्ताओं को संभालने में 90% विश्वास है," या "मुझे इस विशिष्ट कार्य के लिए सुरक्षित होने के लिए टेस्ट किया गया है।"

ये क्रेडेंशियल्स परफेक्ट प्रमाण नहीं हैं; ये इस बात के ईमानदार बयान हैं कि हमें कितना विश्वास है, वह विश्वास कहाँ से आया है, और उनकी सीमाएँ क्या हैं। यह कहने का एक तरीका है, "हमने इसकी जाँच की है, और हम इतने निश्चित हैं।"

4. इंजीनियर का चुनाव: सैटिसफाइसिंग (Satisficing)

पेपर सुझाव देता है कि हमें परफेक्ट होने की कोशिश करना बंद करना चाहिए और सैटिसफाइसिंग (satisficing) शुरू करना चाहिए। यह "एक ऐसा समाधान खोजने" के लिए एक फैंसी शब्द है जो "पर्याप्त अच्छा" है।

• यदि आप एक गेम बना रहे हैं, तो आपको 100% पूर्णता की आवश्यकता नहीं हो सकती है। यदि गेम मजेदार और सस्ता है, तो कुछ बग्स ठीक हैं।
• यदि आप एक मेडिकल डिवाइस बना रहे हैं, तो आपको विश्वास के बहुत उच्च स्तर की आवश्यकता है।

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

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

शॉ यह नहीं कह रही हैं कि AI बुरा है। वह कह रही हैं कि हम AI को एक जादू की छड़ी की तरह नहीं मान सकते जो सब कुछ हल कर देती है। हमें इसका उपयोग करने के बारेंे में अधिक स्मार्ट होना होगा। हमें यह स्वीकार करना होगा कि AI अनुमानों (सांख्यिकी) पर काम करता है और यह मानव संस्कृति और अनुभव की अदृश्य "छायाओं" को नहीं देख सकता।

उनका मुख्य संदेश सॉफ्टवेयर समुदाय के लिए एक आह्वान है: आइए हम सब कुछ परफेक्ट होने का ढोंग करना बंद करें। इसके बजाय, आइए हम ईमानदार इंजीनियर बनें। आइए हम ऐसे सिस्टम बनाएं जहाँ हमें पता हो कि हम किस बारे में आश्वस्त हैं, हम किस बारे में नहीं हैं, और क्यों। ऐसा करके, हम AI का उपयोग बेहतर सॉफ्टवेयर बनाने के लिए कर सकते हैं, बिना इस जाल में फंसे कि हमने अनसुलझे को हल कर लिया है।

संक्षेप में, पेपर का सुझाव है कि सॉफ्टवेयर का भविष्य "सही" होने के बारे में नहीं है (गणित की किताब के अर्थ में)। यह उद्देश्य के लिए उपयुक्त (fit for purpose) होने, अपनी सीमाओं को जानने और डिजिटल दुनिया को सुरक्षित रूप से चलाने के लिए स्मार्ट, लागत प्रभावी विकल्प चुनने के बारे में है।