मुख्य विचार: क्या हमें वास्तव में विशाल AI मशीनों की आवश्यकता है?

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

इस शोध पत्र के लेखक कहते हैं: "एक मिनट रुकिए। आपको गगनचुंबी इमारत की आवश्यकता नहीं है। आपको बस एक टॉर्च और एक मानचित्र (मैप) की आवश्यकता है।"

⚠️ महत्वपूर्ण कार्यक्षेत्र नोट:
यह शोध पत्र पूरी आर्टिफिशियल इंटेलिजेंस के बारे में नहीं है। यह विशेष रूप से क्षेत्र के एक कोने पर केंद्रित है: टेबुलर सॉफ्टवेयर इंजीनियरिंग समस्याएं (Tabular Software Engineering problems)। इसका अर्थ है वे कार्य जिनमें संख्याओं की तालिकाएं और विशिष्ट लक्ष्य शामिल हैं, जैसे कि अनुकूलन (optimization), वर्गीकरण (classification), भविष्यवाणी (prediction), रिग्रेशन (regression) और बुनियादी टेक्स्ट माइनिंग।

यह क्या कवर नहीं करता है: यह जेनेरेटिव AI कार्यों (जैसे ChatGPT या LLMs जो नया कोड, कहानियाँ या चित्र बनाते हैं) को संबोधित नहीं करता है। लेखकों ने अभी तक उन जेनेरेटिव कार्यों पर काम नहीं किया है; इन पाठों को उन पर लागू करना भविष्य का कार्य है जो वे करना चाहते हैं। यहाँ दावा यह है कि टेबुलर कार्यों के लिए, हम चीजों को बहुत जटिल बना रहे हैं।

उनका तर्क है कि सॉफ्टवेयर इंजीनियरिंग की एक बड़ी संख्या में समस्याओं के लिए (विशेष रूप से उन कार्यों के लिए जिनमें संख्याओं की तालिकाएं और लक्ष्य शामिल हैं), हम चीजों को बहुत जटिल बना रहे हैं। उन्होंने EZR नामक एक छोटा सा टूलकिट बनाया (केवल 400 लाइनों का कोड) जो भारी-भरकम सॉफ्टवेयर लाइब्रेरी के काम को कर देता है, लेकिन यह 500 गुना तेजी से चलता है और इसे सीखने के लिए लगभग न के बराबर डेटा की आवश्यकता होती है।

टूलकिट: एक स्विस आर्मी नाइफ बनाम एक गोदाम

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

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

• वर्गीकरण (Classification) (चीजों को समूहों में छाँटना)
• क्लस्टरिंग (Clustering) (प्राकृतिक समूह खोजना)
• अनुकूलन (Optimization) (सर्वश्रेष्ठ समाधान खोजना)
• टेक्स्ट माइनिंग (Text Mining) (प्रासंगिक दस्तावेज़ खोजना)

...ये सभी एक ही तीन सरल बिल्डिंग ब्लॉक्स पर निर्भर करते हैं:

1. Num: एक बाल्टी जो संख्याओं को गिनती है और उनका औसत निकालती है।
2. Sym: एक बाल्टी जो प्रतीकों (जैसे शब्द या श्रेणियां) को गिनती है।
3. Data: एक बॉक्स जो सूचनाओं की पंक्तियों (rows) को रखता है।

हर कार्य के लिए एक नया इंजन बनाने के बजाय, EZR इन सभी कार्यों को करने के लिए इन्हीं समान बाल्टियों का उपयोग करता है। यह ऐसा है जैसे यह महसूस करना कि चम्मच, कांटा और चाकू वास्तव में केवल एक विशिष्ट आकार वाला हैंडल हैं; आपको उन्हें बनाने के लिए तीन अलग-अलग कारखानों की आवश्यकता नहीं है।

छह आश्चर्यजनक खोजें

इस छोटे से टूलकिट का परीक्षण शोधकर्ताओं ने 120 से अधिक वास्तविक दुनिया की सॉफ्टवेयर समस्याओं पर किया। यहाँ उन्होंने क्या पाया, सरल रूपकों का उपयोग करते हुए:

1. "भारीपन" का मिथक (The "Heavy" Myth)

विश्वास: AI करने के लिए, आपको एक विशाल कंप्यूटर और बड़ी लाइब्रेरी की आवश्यकता है।
वास्तविकता: टेबुलर कार्यों के लिए, आप इसे एक छोटे से स्क्रिप्ट के साथ कर सकते हैं।
उपमा: यह एक लोरी सुनाने के लिए पूरे ऑर्केस्ट्रा की आवश्यकता होने के ऐसा सोचने जैसा है। लेखकों ने दिखाया कि एक अकेला वायलिन (EZR) उसी धुन को उतनी ही अच्छी तरह बजा सकता है, बिना उन 50 अन्य संगीतकारों (भारी डिपेंडेंसी) की आवश्यकता के।

2. "अलग विषय" का मिथक (The "Separate Subjects" Myth)

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

3. "पेड़" का मिथक (The "Tree" Myth)

विश्वास: संख्याओं की भविष्यवाणी करने वाले निर्णय वृक्ष (Decision trees - जैसे AI के लिए फ्लोचार्ट) और श्रेणियों की भविष्यवाणी करने वाले वृक्ष पूरी तरह से अलग हैं।
वास्तविकता: वे एक ही पेड़ हैं; बस फल अलग है।
उपमा: कल्पना कीजिए कि एक पेड़ है जिस पर सेब उगते हैं। यदि आप संतरे चाहते हैं, तो आपको एक नई प्रजाति के पेड़ की आवश्यकता नहीं है; आपको बस शाखा पर लेबल बदलना है। लेखों ने दिखाया कि संख्याओं और श्रेणियों के बीच स्विच करना कोड में केवल एक लाइन का बदलाव है।

4. "पुराना बनाम नया" मिथक (The "Old vs. New" Myth)

विश्वास: नए, जटिल खोज तरीके (रीस्टार्ट के साथ लोकल सर्च) हमेशा पुराने, सरल तरीकों (1983 का सिम्युलेटेड एनीलिंग) से बेहतर होते हैं।
वास्तविकता: अनुकूलन कार्यों के लिए, पुराना तरीका अक्सर उतना ही अच्छा, या बेहतर होता है।
उपमा: कल्पना कीजिए कि धुंधली घाटी में सबसे निचले बिंदु को खोजने की कोशिश कर रहे हैं। "नया" तरीका कहता है, "यदि आप फंस जाते हैं, तो शुरुआत में वापस कूदें और फिर से प्रयास करें!" "पुराना" तरीका कहता है, "यदि आप फंस जाते हैं, तो खुद को ढीला करने के लिए एक छोटा, यादृच्छिक कदम ऊपर लें।" लेखकों ने पाया कि "झटक कर ढीला करने" वाला तरीका (1983) "वापस कूदने" वाले तरीके की तुलना में उतना ही अच्छा काम करता है, लेकिन बिना लगातार रीस्टार्ट के शोर-शराबे के।

5. "अधिक डेटा" का मिथक (The "More Data" Myth)

विश्वास: एक अच्छा मॉडल बनाने के लिए आपको हजारों लेबल किए गए उदाहरणों और हजारों विशेषताओं (variables) की आवश्यकता होती है।
वास्तविकता: टेबुलर समस्याओं के लिए, आपको बहुत कम लेबल और बहुत कम विशेषताओं की आवश्यकता होती है।
उपमा: कल्पना कीजिए कि दौड़ के विजेता का अनुमान लगाने की कोशिश कर रहे हैं। आप सोच सकते हैं कि आपको धावक की ऊंचाई, वजन, जूते का आकार, आहार, नींद का समय और रक्त प्रकार जानने की आवश्यकता है (हजारों विशेषताएं)। लेखकों ने पाया कि विजेता की सटीक भविष्यवाणी करने के लिए केवल दो या तीन चीजें (जैसे "जूते का आकार" और "नींद") जानना पर्याप्त था। उन्होंने यह भी पाया कि केवल 50 उदाहरणों को लेबल करना एक ऐसे मॉडल को प्रशिक्षित करने के लिए पर्याप्त था जिसे आमतौर पर हजारों की आवश्यकता होती है।

6. "टेक्स्ट माइनिंग" का मिथक (The "Text Mining" Myth)

विश्वास: एक विशाल पुस्तकालय में प्रासंगिक दस्तावेज़ खोजने के लिए, आपको अरबों पैरामीटर वाले विशाल AI मॉडल (LLMs) की आवश्यकता होती है।
वास्तविकता: सरल दस्तावेज़ पुनर्प्राप्ति (document retrieval) के लिए, एक सरल गणितीय ट्रिक बेहतर काम करती है।
उपमा: कल्पना कीजिए कि घास के ढेर में एक विशिष्ट सुई ढूंढ रहे हैं। हाई-टेक दृष्टिकोण एक विशाल चुंबक का उपयोग करता है जिसका वजन बहुत अधिक है। लेखकों ने एक सरल "कॉम्प्लीमेंट्री बेयस" (Complementary Bayes) ट्रिक का उपयोग किया (30 लाइन का कोड) जो एक तेज सुई की तरह काम करता है। इसने विशाल चुंबक की तुलना में तेजी से और कम गलतियों के साथ प्रासंगिक दस्तावेज़ों को खोज निकाला, और यह उजागर किया कि उस विशाल चुंबक का उपयोग कैसे गलत तरीके से किया जा रहा था।

"एक्टिव लर्निंग" की महाशक्ति (The "Active Learning" Superpower)

EZR की सबसे शानदार चीजों में से एक है एक्टिव लर्निंग (Active Learning)।

• पैसिव लर्निंग (Passive Learning): कल्पना कीजिए कि एक छात्र किसी अवधारणा को सीखने के लिए 1,000 पन्नों की किताब पढ़ता है।
• एक्टिव लर्निंग (EZR): कल्पना कीजिए कि एक छात्र 10 पन्ने पढ़ता है, यह समझता है कि उसे क्या समझ नहीं आया, और शिक्षक से केवल उन विशिष्ट 10 पन्नों के लिए पूछता है।

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

निष्कर्ष: कोड पढ़ें, केवल हाइप (Hype) पर भरोसा न करें

शोध पत्र का मुख्य संदेश डेवलपर्स और शोधकर्ताओं के लिए एक आह्वान है: कोड पढ़ें।

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

मुख्य बात (Takeaway):
इससे पहले कि आप किराने के सामान के लिए फेरारी खरीदने के बजाय पैदल चलने की कोशिश करें।

• यदि आप अपने समस्या को एक छोटे, सरल टूलकिट (जैसे EZR) के साथ हल कर सकते हैं टेबुलर सॉफ्टवेयर इंजीनियरिंग कार्यों के लिए, तो आप समय, पैसा और ऊर्जा बचाते हैं।
• यदि सरल टूलकिट काम नहीं करता है, तो आपको वास्तव में पता चल जाएगा कि आपको एक जटिल समाधान की आवश्यकता है।
• लेकिन यदि आप केवल इसलिए जटिल समाधान की आवश्यकता मान लेते हैं क्योंकि "बाकी सब ऐसा ही कर रहे हैं," तो हो सकता है कि आप एक भारी बैकपैक लेकर चल रहे हों जबकि आपको केवल एक जेब चाकू की आवश्यकता थी।

लेखक निष्कर्ष निकालते हैं कि सॉफ्टवेयर इंजीनियरिंग अनुकूलन की दुनिया में, कम होना अक्सर अधिक होना है, और "कम" को खोजने का सबसे अच्छा तरीका हमारे पास मौजूद कोड को ध्यान से पढ़ना और उसे सरल बनाना है।

कार्यक्षेत्र पर अंतिम नोट: ये सबक विशेष रूप से टेबुलर SE कार्यों के लिए प्रदर्शित किए गए हैं। क्या ये सरल तरीके जेनेरेटिव AI (LLMs) की जटिल दुनिया में भी लागू होते हैं, यह एक खुला प्रश्न है और भविष्य के कार्य का एक लक्ष्य है। लेखक यह दावा नहीं कर रहे हैं कि उन्होंने सभी AI को हल कर दिया है, बल्कि यह कि हमने इसके एक बहुत बड़े और महत्वपूर्ण हिस्से को बहुत अधिक जटिल बना दिया है।