12 नव॰ 2025·8 मिनट
एंड्रयू एनजी: कैसे एक शिक्षक ने डेवलपर्स को एआई सीखने में मदद की
एंड्रयू एनजी के कोर्स और कंपनियों ने लाखों डेवलपर्स को मशीन लर्निंग शुरू करने में मदद की। उनके शिक्षण शैली, प्रभाव और व्यावहारिक निष्कर्षों का पता लगाएँ।
एंड्रयू एनजी के कोर्स और कंपनियों ने लाखों डेवलपर्स को मशीन लर्निंग शुरू करने में मदद की। उनके शिक्षण शैली, प्रभाव और व्यावहारिक निष्कर्षों का पता लगाएँ।
एंड्रयू एनजी उन पहले नामों में से हैं जिनका कई डेवलपर्स जब पूछा जाता है, “आपने एआई कैसे शुरू किया?” तो ज़िक्र करते हैं। यह संयोग नहीं है। उनके कोर्स तब आए जब मशीन लर्निंग एक शोधकेंद्रित विषय से बदलकर इंजीनियरों की रेज़्यूमे पर एक व्यावहारिक कौशल बन रही थी—और उनका पढ़ाने का तरीका पहले कदम को करके दिखाने वाला बनाता था।
एनजी ने मशीन लर्निंग को स्पष्ट बिल्डिंग ब्लॉक्स के सेट के रूप में समझाया: समस्या को परिभाषित करें, मॉडल चुनें, ट्रेन करें, मूल्यांकन करें, इटरेट करें। फ्रेमवर्क और फ़ीचर शिप करने वाले डेवलपर्स के लिए वह संरचना परिचित लगी। एआई को रहस्यमयी गणित की तरह पेश करने के बजाय उन्होंने इसे एक व्यावहारिक वर्कफ़्लो के रूप में प्रस्तुत किया जिसे आप सीख सकते हैं, अभ्यास कर सकते हैं और बेहतर बना सकते हैं।
एआई को मुख्यधारा में लाने का मतलब हर डेवलपर को पीएचडी बनाना नहीं था। इसका मतलब था:
कई लोगों के लिए, उनके कोर्स ने आरंभिक ऊर्जा की बाधा घटा दी: आपको लैब, मेंटर या ग्रेजुएट प्रोग्राम की ज़रूरत नहीं थी शुरुआत करने के लिए।
यह लेख बताएगा कि वह प्रवेश द्वार कैसे बना: कैंपस से बाहर फैला स्टैनफोर्ड कोर्स, वह MOOC युग जिसने एआई सीखने को बदला, और वह शिक्षण शैली जिसने जटिल विषयों को व्यवस्थित और कार्ययोग्य महसूस कराया। हम बाद की कुछ विचारधाराओं—जैसे डेटा-सेंट्रिक एआई और करियर/प्रोडक्ट सोच—को भी देखेंगे, साथ ही सिर्फ़ शिक्षा के सीमाएँ। अंत में, आप अपने स्वयं के सीखने और प्रोजेक्ट्स में “एनजी अप्रोच” लागू करने का एक ठोस एक्शन प्लान पाएँगे।
एंड्रयू एनजी को एआई शिक्षा के साथ व्यापक रूप से जोड़ा जाता है, पर उनका पढ़ने का अंदाज़ वर्षों के शोध और सिस्टम बनाने के अनुभव से आकार लिया गया था। उस बदलाव को समझना बताता है कि उनके कोर्स इंजीनियर-फ्रेंडली क्यों लगते हैं: वे स्पष्ट समस्या सेटअप, मापने योग्य प्रगति, और व्यावहारिक आदतों पर ध्यान केंद्रित करते हैं जो वास्तविक प्रोजेक्ट्स में अनुवादित होती हैं।
एनजी का रास्ता कंप्यूटर साइंस से शुरू हुआ और जल्दी ही मशीन लर्निंग और एआई की ओर केन्द्रित हो गया—सॉफ्टवेयर का वह हिस्सा जो डेटा और अनुभव से बेहतर होता है बजाय हार्ड-कोडेड नियमों के। उनकी अकादमिक ट्रेनिंग और शुरुआती काम ने उन्हें उन मूल प्रश्नों के नज़दीक रखा जो आज भी डेवलपर्स का सामना करते हैं: समस्या को कैसे प्रतिनिधित्व करें, उदाहरणों से कैसे सीखें, और कैसे मूल्यांकन करें कि मॉडल वास्तव में बेहतर हो रहा है या नहीं।
यह आधार इसलिए महत्वपूर्ण है क्योंकि यह उनकी व्याख्याओं को पहले सिद्धांतों (एल्गोरिथ्म क्या कर रहा है) में एंकर करता है और उद्देश्य को ठोस रखता है (आप इसके साथ क्या बना सकते हैं)।
शोध संस्कृति सटीकता को पुरस्कृत करती है: मीट्रिक्स निर्धारित करना, साफ़ प्रयोग करना, और यह अलग करना कि वास्तव में परिणामों को क्या आगे बढ़ाता है। ये प्राथमिकताएँ उनके मशीन लर्निंग कोर्स मटेरियल और बाद के deeplearning.ai प्रोग्रामों की संरचना में दिखाई देती हैं। एआई को ट्रिक्स के ढेर के रूप में देखने के बजाय उनका पढ़ाना बार-बार इन पर लौटता है:
यही कारण है कि उनका बाद का डेटा-सेंट्रिक एआई पर जोर डेवलपर्स के साथ गूँजता है: यह प्रगति को केवल मॉडल बदलने की बजाय डेटा और फीडबैक लूप सुधारने के रूप में फिर से परिभाषित करता है।
ऊपर से देखा जाए तो, एनजी के करियर को कुछ सार्वजनिक मोड़ों ने चिह्नित किया है: उनका अकादमिक काम, स्टैनफोर्ड में पढ़ाना (जिसमें प्रसिद्ध स्टैनफोर्ड मशीन लर्निंग कोर्स शामिल है), और Coursera तथा deeplearning.ai के माध्यम से बड़े पैमाने पर एआई शिक्षा में विस्तार। इस दौरान, उन्होंने उद्योग के एआई टीमों में नेतृत्व भूमिकाएँ भी निभाईं, जिसने संभवतः वह करियर और प्रोडक्ट सोच और मजबूत की जो उनकी एआई करियर सलाह में दिखती है: बेसिक्स सीखो, फिर उसे किसी उपयोगकर्ता समस्या पर लागू करो।
संग्रहित रूप में, ये माइलस्टोन्स बताते हैं कि उनका शिक्षण सिद्धांत और निर्माणशीलता को पुल करता है—एक कारण कि उनकी Deep Learning Specialization और संबंधित प्रोग्राम डेवलपर्स के लिए प्रवेश-बिंदु बन गए।
एंड्रयू एनजी का स्टैनफोर्ड मशीन लर्निंग कोर्स इसलिए काम करता था क्योंकि उसने शुरुआती लोगों को संभावित बिल्डरों की तरह माना, उनमें भविष्य के अकादमिक्स की तरह नहीं। आश्वासन स्पष्ट था: आप मशीन लर्निंग के मानसिक मॉडल सीख सकते हैं और उन्हें लागू करना शुरू कर सकते हैं, भले ही आप गणित प्रमुख न हों।
कोर्स ने परिचित, डेवलपर-फ्रेंडली फ्रेमिंग इस्तेमाल की: आप एक सिस्टम को ऑप्टिमाइज़ कर रहे हैं, उसे माप रहे हैं, और इटरेट कर रहे हैं। अवधारणाएँ औपचारिक नोटेशन से पहले सहज उदाहरणों के साथ पेश की गईं। साप्ताहिक प्रोग्रामिंग असाइनमेंट्स ने abstract विचारों को कुछ ऐसा बनाया जिसे आप चला सकते थे, तोड़ सकते थे और ठीक कर सकते थे।
कई शिक्षार्थियों को यह “कई एल्गोरिद्म” के रूप में कम और सोचने के लिए एक चेकलिस्ट के रूप में ज़्यादा याद रहता है:
ये विचार टूल्स और ट्रेंड्स के बदलने पर भी काम आते हैं, इसलिए कोर्स तब भी उपयोगी रहा।
नीचे कैल्कुलस और लिनियर अल्जेब्रा होती है, पर कोर्स ने ज़्यादातर इस बात पर जोर दिया कि समीकरण सीखने के व्यवहार के लिए क्या मतलब रखते हैं। कई डेवलपर्स ने पाया कि मुश्किल हिस्सा व्युत्पन्न नहीं था—बल्कि प्रदर्शन को मापने की आदत बनाना, त्रुटियों का निदान करना, और एक बार में एक ही बदलाव करना था।
कई लोगों के लिए, ब्रेकथ्रू व्यावहारिक थे:
एंड्रयू एनजी का Coursera की ओर कदम केवल लेक्चर ऑनलाइन रखने जैसा नहीं था—इसने उच्च-स्तरीय एआई निर्देश को इतना पहुँचयोग्य बना दिया कि डेवलपर्स उसे एक सप्ताह में भी फिट कर सकें। स्टैनफोर्ड शेड्यूल की ज़रूरत नहीं रही; आप कमांड के बीच, कम्यूट पर, या वीकेंड स्प्रिंट में सीख सकते थे।
कुंजी थी वितरण। एक अच्छी तरह डिज़ाइन किया गया कोर्स लाखों तक पहुँच सकता था, जिसका मतलब यह था कि मशीन लर्निंग में प्रवेश का डिफ़ॉल्ट रास्ता अब किसी रिसर्च यूनिवर्सिटी में दाखिले का मोहताज नहीं रहा। प्रमुख टेक हब्स के बाहर के डेवलपर्स के लिए MOOCs जिज्ञासा और विश्वसनीय सीखने के बीच की खाई घटा देते हैं।
MOOC संरचना वैसे ही थी जैसे डेवलपर्स पहले से सीखते हैं:
यह फॉर्मेट गति को भी प्रोत्साहित करता है। आपको प्रगति के लिए पूरा दिन नहीं चाहिए; 20–40 मिनट भी आपको आगे बढ़ा सकते हैं।
जब हजारों शिक्षार्थी एक ही अड़चन पर ठोकर खाएँ, तो फोरम साझा ट्रबलशूटिंग परत बन गए। आप अक्सर पा सकते थे:
यह निजी TA जैसा नहीं था, पर सीखना कम अकेला महसूस होने लगा—और यह पैटर्न उभरने पर कोर्स स्टाफ को सुधार करने का संकेत भी देता था।
एक MOOC आमतौर पर स्पष्टता, गति, और कम्पलीशन के लिए ऑप्टिमाइज़ करता है, जबकि एक विश्वविद्यालय कोर्स अक्सर थ्योरी, गणितीय कठोरता, और खुले अंत के समस्या समाधान में गहराई बढ़ाता है। MOOCs आपको जल्दी उत्पादक बना सकते हैं, पर वे रिसर्च-स्तर की गहराई या ग्रेडेड इग्ज़ाम्स और इन-पर्सन बहस का दबाव नहीं दे सकते।
अधिकांश डेवलपर्स के लिए, यही ट्रेड-ऑफ़ का सार है: तेज़ व्यावहारिक क्षमता, और बाद में गहराई में जाने का विकल्प।
एंड्रयू एनजी का शिक्षण इसलिए अलग दिखाई देता है क्योंकि वह एआई को उस इंजीनियरिंग डिसिप्लिन की तरह पेश करते हैं जिसे आप अभ्यास कर सकते हैं—न कि रहस्यमयी तरकीबों का संग्रह। सैद्धांतिक बातों से शुरुआत करने के बजाय वह बार-बार अवधारणाओं को उन निर्णयों से जोड़ते हैं जो एक डेवलपर को लेने होते हैं: "हम क्या प्रेडिक्ट कर रहे हैं? हम कैसे जानेंगे कि हम सही हैं? जब परिणाम खराब हों तो क्या करें?"
एक बार-बार दिखने वाला पैटर्न है इनपुट, आउटपुट और मीट्रिक्स के संदर्भ में स्पष्ट फ्रेमिंग। यह बेसिक लगता है, पर यह बहुत सारा बर्बाद प्रयास रोकता है।
अगर आप यह नहीं कह सकते कि मॉडल क्या खाता है (इनपुट), क्या पैदा करेगा (आउटपुट), और "अच्छा" क्या मतलब है (ट्रैक करने योग्य मीट्रिक), तो आप और डेटा या फैंसी आर्किटेक्चर के लिए तैयार नहीं हैं। आप अभी भी अनुमान लगा रहे हैं।
याद रखने के बजाय मेमोराइज़ेशन के, वह विचारों को मेंटल मॉडल्स और दोहराए जाने योग्य चेकलिस्ट्स में तोड़ते हैं। डेवलपर्स के लिए यह शक्तिशाली है: यह सीखने को एक वर्कफ़्लो बनाता है जिसे आप प्रोजेक्ट्स पर बार-बार इस्तेमाल कर सकते हैं।
उदाहरणों में बायस बनाम वैरियंस के रूप में सोचना, विफलता मोड्स अलग करना, और साक्ष्य के आधार पर यह तय करना कि डेटा, फीचर या मॉडल पर मेहनत करनी चाहिए—शामिल हैं।
एनजी इटरेशन, डिबगिंग, और माप पर भी जोर देते हैं। ट्रेनिंग "एक बार चलाओ और आशा करो" नहीं है; यह एक लूप है:
उस लूप का एक अहम हिस्सा है जटिल मॉडलों से पहले सरल बेसलाइन का उपयोग करना। एक त्वरित लॉजिस्टिक रिग्रेशन या छोटा न्यूरल नेट यह दिखा सकता है कि आपका डेटा पाइपलाइन और लेबल्स समझ में आ रहे हैं—उससे पहले कि आप कुछ बड़ा ट्यून करने में दिन झोंक दें।
यह संरचना और व्यावहारिकता का मिश्रण है जो अक्सर उनके मटेरियल को तुरंत उपयोगी बनाता है: आप इसे सीधे अपने तरीके से बनाना, परीक्षण और शिप करना सीख सकते हैं।
एनजी के शुरुआती कोर्स कई डेवलपर्स को "क्लासिक" मशीन लर्निंग समझाने में मदद करते थे—लिनियर रिग्रेशन, लॉजिस्टिक रिग्रेशन, और बेसिक न्यूरल नेटवर्क। पर डीप लर्निंग अपनाने में तेज़ी तब आई जब सीखना एकल कोर्स से बदलकर स्ट्रक्चर्ड स्पेशलाइज़ेशन हो गया—जिसे लोग कौशल बनाने के तरीके के अनुसार क्रमवार सीखते हैं।
कई शिक्षार्थियों के लिए, एमएल की बुनियाद से डीप लर्निंग तक का छलाँग एक अलग अनुशासन जैसा लग सकता है: नई गणित, नया शब्दावली, और अपरिचित विफलता मोड। एक अच्छी तरह डिज़ाइन किया गया स्पेशलाइज़ेशन विषयों को इस तरह क्रमबद्ध करता है कि हर मॉड्यूल अपनी जगह कमाता है—व्यावहारिक intuition (डीप नेट क्यों काम करते हैं) से शुरू करके, फिर ट्रेनिंग मैकेनिक्स (इनीशियलाइज़ेशन, रेगुलराइज़ेशन, ऑप्टिमाइज़ेशन) पर जाता है, और उसके बाद विशेष क्षेत्रों में विस्तार करता है।
स्पेशलाइज़ेशन डेवलपर्स की मदद तीन तरीके से करती हैं:
डेवलपर्स आमतौर पर डीप लर्निंग से हैंड्स-ऑन टास्क के जरिए मिलते हैं जैसे:
ये प्रोजेक्ट्स छोटे होते हुए भी रियल प्रोडक्ट पैटर्न के करीब होते हैं।
सामान्य अड़चनों में ट्रेनिंग जो कन्वर्ज नहीं होती, भ्रमित मीट्रिक्स, और "यह मेरी नोटबुक पर काम करता है" सिंड्रोम शामिल हैं। समाधान अक्सर "ज़्यादा थ्योरी" नहीं है—यह बेहतर आदतें हैं: एक छोटा बेसलाइन शुरू करें, पहले डेटा और लेबल्स सत्यापित करें, एक मीट्रिक चुनें जो लक्ष्य से मेल खाता हो, और एक-बदलाव-एक-समय में बदलें। संरचित स्पेशलाइज़ेशन उस अनुशासन को बढ़ावा देते हैं, और इसी कारण वे कामकाजी डेवलपर्स के लिए डीप लर्निंग को सुलभ बनाते हैं।
एनजी ने डेवलपर्स के सोचने का एक सरल बदलाव लोकप्रिय किया: मॉडल को मुख्य लीवर मानना बंद करें, और डेटा को उत्पाद मानकर काम करना शुरू करें।
डेटा-सेंट्रिक एआई का मतलब है कि आप अपनी मेहनत का ज़्यादा हिस्सा प्रशिक्षण डेटा—उसकी सटीकता, सुसंगतता, कवरेज और प्रासंगिकता—सुधारने में लगाते हैं, बजाय इसके कि आप एल्गोरिद्म बार-बार बदलते रहें। अगर डेटा असली समस्या को अच्छी तरह दर्शाता है, तो कई "पर्याप्त अच्छे" मॉडल आश्चर्यजनक रूप से अच्छा प्रदर्शन कर देंगे।
मॉडल बदलाव अक्सर क्रमिक लाभ देते हैं। डेटा मुद्दे चुपचाप प्रदर्शन को सीमित कर सकते हैं चाहे आर्किटेक्चर कितना भी उन्नत हो। सामान्य कारणों में शामिल हैं:
इन समस्याओं को ठीक करने से मीट्रिक्स में अक्सर अधिक सुधार होता है—क्योंकि आप शोर हटाकर सिस्टम को सही कार्य सिखा रहे हैं।
डेवलपर-फ्रेंडली तरीका ऐप डिबगिंग की तरह इटरेट करना है:
कॉनक्रेट उदाहरण:
यह माइंडसेट प्रोडक्ट वर्क से अच्छी तरह मेल खाता है: एक बेसलाइन शिप करें, वास्तविक दुनिया की त्रुटियों की निगरानी करें, उपयोगकर्ता प्रभाव के आधार पर सुधारों को प्राथमिकता दें, और डेटासेट क्वालिटी को एक दोहराए जाने योग्य इंजीनियरिंग निवेश मानें—न कि एक बार का सेटअप।
एंड्रयू एनजी लगातार एआई को एक ऐसे उपकरण के रूप में फ्रेम करते हैं जिसका उपयोग आप परिणाम शिप करने के लिए करते हैं—न कि एक ऐसा विषय जिसे आप "खत्म" कर लें। वह प्रोडक्ट माइंडसेट डेवलपर्स के लिए विशेष रूप से उपयोगी है: यह आपको सीखने को सीधे नियोक्ताओं और उपयोगकर्ताओं की वेल्यू से जोड़ने के लिए प्रेरित करता है।
अवधारणाओं को इकट्ठा करने के बजाय, उन्हें टीम पर की जाने वाली गतिविधियों में बदलें:
यदि आप अपने काम को इन क्रियाओं—कलेक्ट, ट्रेन, इवैलुएट, डेप्लॉय, इम्प्रूव—में बयान कर सकते हैं, तो आप ऐसे तरीके से सीख रहे हैं जो वास्तविक भूमिकाओं से जुड़ता है।
एक “अच्छा” लर्निंग प्रोजेक्ट नवाचारपूर्ण आर्किटेक्चर का आवश्यक नहीं है। उसे स्पष्ट स्कोप और सबूत चाहिए।
एक संकुचित समस्या चुनें (जैसे सपोर्ट टिकट्स क्लासिफाई करना)। सफलता मीट्रिक परिभाषित करें। एक सरल बेसलाइन दिखाएँ, फिर लेबलिंग, एरर एनालिसिस, और स्मार्ट डेटा कलेक्शन जैसे सुधार दस्तावेज़ करें। हायरिंग मैनेजर उन प्रोजेक्ट्स पर अधिक भरोसा करते हैं जो निर्णय और इटरेशन दिखाते हैं, बजाय चमकदार डेमो के।
फ़्रेमवर्क और APIs तेज़ी से बदलते हैं। बुनियादी सिद्धांत (बायस/वैरियंस, ओवरफिटिंग, ट्रेन/वैलिडेशन स्प्लिट्स, मूल्यांकन) धीरे-धीरे बदलते हैं।
व्यावहारिक संतुलन यह है: कोर आइडियाज एक बार सीखें, फिर टूल्स को बदलने योग्य इंटरफ़ेस समझें। आपका पोर्टफोलियो यह दिखाना चाहिए कि आप अनुकूलित हो सकते हैं—उदाहरण के लिए, बिना ढिलाई के एक नई लाइब्रेरी में वही वर्कफ़्लो दोहरा सकते हैं।
प्रोडक्ट सोच में संयम भी शामिल है। उन दावों से बचें जो आपके मूल्यांकन समर्थन नहीं करते, फेलियर केसों का परीक्षण करें, और अनिश्चितता रिपोर्ट करें। जब आप मापी गई उपलब्धियों—नापी गई सुधार, मॉनिटर की गई व्यवहार, और दस्तावेज़ सीमाओं—पर ध्यान देते हैं, तो आप क्षमता के साथ साथ भरोसा भी बनाते हैं।
एंड्रयू एनजी के कोर्स कठिन विचारों को सुलभ बनाकर प्रसिद्ध हैं। यह ताकत कभी-कभी एक सामान्य गलतफ़हमी भी पैदा कर सकती है: “मैंने कोर्स पूरा कर लिया, तो मैं हो गया।” शिक्षा एक शुरुआत की रेखा है, खत्म नहीं।
एक कोर्स आपको यह सिखा सकता है कि ग्रेडिएंट डिसेंट क्या है और कैसे एक मॉडल का मूल्यांकन करें। पर यह आम तौर पर आपको व्यावसायिक समस्या की गंदी वास्तविकता—अस्पष्ट लक्ष्य, बदलती आवश्यकताएँ, सीमित कम्प्यूट, और अपूर्ण या असंगत डेटा—से कैसे निपटना है यह नहीं सिखाएगा।
कोर्स-आधारित सीखना ज्यादातर नियंत्रित अभ्यास है। वास्तविक प्रगति तब होती है जब आप कुछ एंड-टू-एंड बनाकर शिप करते हैं—सफलता मीट्रिक्स परिभाषित करना, डेटा इकट्ठा करना, मॉडल ट्रेन करना, एरर डिबग करना, और गैर-एमएल साथियों को ट्रेडऑफ़्स समझाना।
यदि आप कभी छोटा प्रोजेक्ट शिप नहीं करते, तो आप अपनी तैयारी का अधिक आकलन कर सकते हैं। यह अंतर तब दिखता है जब आप ऐसे प्रश्नों का सामना करते हैं:
एआई प्रदर्शन अक्सर फैंसी आर्किटेक्चर से कम और इस बात से ज़्यादा निर्भर करता है कि क्या आप डोमेन को समझते हैं और सही डेटा तक पहुँच है। एक मेडिकल मॉडल में क्लिनिकल संदर्भ चाहिए; एक फ्रॉड मॉडल को यह पता होना चाहिए कि फ्रॉड वास्तव में कैसे होता है। इसके बिना आप गलत चीज़ को ऑप्टिमाइज़ कर सकते हैं।
अधिकांश डेवलपर्स कुछ हफ्तों में शून्य से “एआई एक्सपर्ट” नहीं बनते। एक वास्तविकवादी रास्ता है:
एनजी का मटेरियल कदम 1 को तेज़ करता है। बाकी मेहनत इटरेशन, फीडबैक, और असली समस्याओं को सुलझाने में आएगी।
एंड्रयू एनजी का डेवलपर-फ्रेंडली वादा सरल है: कुछ ऐसा न्यूनतम सिद्धांत सीखें जो काम करने वाली चीज़ बनाने के लिए काफी हो, फिर स्पष्ट फीडबैक के साथ इटरेट करें।
एक ठोस फाउंडेशन पास से शुरू करें—इतना कि कोर आइडियाज (ट्रेनिंग, ओवरफिटिंग, मूल्यांकन) समझ में आ जाएँ और आप मॉडल आउटपुट को अनिश्चित रूप से न पढ़ें।
फिर जल्दी एक छोटा प्रोजेक्ट करें जो एंड-टू-एंड सोच को मजबूर करे: डेटा कलेक्शन, एक बेसलाइन मॉडल, मीट्रिक्स, एरर एनालिसिस, और इटरेशन। आपका लक्ष्य परफेक्ट मॉडल नहीं—एक दोहराए जाने वाला वर्कफ़्लो है।
कई छोटे प्रयोग शिप करने के बाद ही आप स्पेशलाइज़ेशन चुनें (NLP, विज़न, recommender systems, MLOps)। स्पेशलाइज़ेशन टिकेगा क्योंकि आपके पास असली समस्याओं से जुड़े "हुक्स" होंगे।
प्रगति को साप्ताहिक स्प्रिंट की तरह ट्रीट करें:
ओवरइंजीनियर करने से बचें। एक या दो अच्छी तरह दस्तावेज़ प्रोजेक्ट पाँच अधूरे डेमो से बेहतर होते हैं।
लक्ष्य रखें:
यदि आप टीम के रूप में सीख रहे हैं, तो सहयोग का एक मानकीकृत तरीका अपनाएँ:
यह एनजी के शिक्षण को दोहराता है: स्पष्टता, संरचना, और इटरेशन—आपके अपने काम पर लागू।
एक कारण कि एनजी का तरीका काम करता है वह यह है कि वह आपको जल्द से जल्द एंड-टू-एंड सिस्टम बनाकर इटरेट करने को प्रेरित करता है। यदि आपका लक्ष्य उस माइंडसेट को शिप्ड सॉफ़्टवेयर में बदलना है—विशेषकर वेब और बैकेंड फीचर्स—तो उन टूल्स का उपयोग करें जो “आइडिया → काम करता हुआ ऐप” लूप को छोटा करें।
उदाहरण के लिए, Koder.ai एक वाइब-कोडिंग प्लेटफ़ॉर्म है जहाँ आप चैट इंटरफ़ेस के ज़रिये वेब, सर्वर और मोबाइल ऐप बना सकते हैं, फिर प्लानिंग मोड, स्नैपशॉट्स, रोलबैक, और सोर्स कोड एक्सपोर्ट जैसी सुविधाओं के साथ जल्दी इटरेट कर सकते हैं। इसे ठीक तरह से इस्तेमाल करने पर, यह उसी इंजीनियरिंग रिदम का समर्थन करता है जो एनजी सिखाते हैं: परिणाम परिभाषित करें, एक बेसलाइन बनाएं, मापें, और सुधारें—बिना बोतलबेर्क में फंसने के।
एआई लर्निंग रिसोर्सेज़ कहीं अधिक तेजी से बढ़ते हैं बनिस्बत इससे कि कोई एक कोर्स पूरा कर पाए। लक्ष्य "सबसे अच्छा ढूँढना" नहीं है—यह एक ऐसा रास्ता चुनना है जो आपके परिणाम से मेल खाता हो, और फिर पर्याप्त समय तक उसके साथ टिके रहना कि वास्तविक कौशल बने।
नामांकन से पहले स्पष्ट रहें:
एक मजबूत कोर्स आमतौर पर तीन संकेत देता है:
अगर कोई कोर्स बिना प्रोजेक्ट्स के "मास्टरी" का वादा करता है, उसे मनोरंजन समझें।
यह आसान है कि आप फ्रेमवर्क्स, नोटबुक्स, और ट्रेंडिंग ट्यूटोरियल्स के बीच कूदते रहें। इसके बजाय, एक सीज़न के लिए एक प्राथमिक स्टैक चुनें और डेटा क्वालिटी, मूल्यांकन मीट्रिक्स, और एरर एनालिसिस जैसे सिद्धांतों पर ध्यान दें। टूल बदलेंगे; यह नहीं।
एंड्रयू एनजी का सबसे बड़ा प्रभाव किसी एक कोर्स या प्लेटफ़ॉर्म में नहीं है—यह डेवलपर सीखने की संस्कृति में बदलाव है। उन्होंने एआई को एक बिल्ड करने योग्य कौशल की तरह महसूस कराना संभव किया: परतों में सीखने योग्य, छोटे प्रयोगों के साथ अभ्यास करने योग्य, और फीडबैक के ज़रिये बेहतर बनाने योग्य।
बिल्डर्स के लिए स्थायी सबक नवीनतम मॉडल के पीछे भागने से ज़्यादा एक भरोसेमंद वर्कफ़्लो अपनाने के हैं:
एनजी का शिक्षण एक बिल्डर का माइंडसेट बढ़ावा देता है: पहले एक काम करने वाला एंड-टू-एंड सिस्टम बनाओ, फिर यह पता लगाओ कि वास्तव में क्या टूट रहा है। इस तरह टीमें शिप करती हैं।
यह एआई के आस-पास उत्पाद सोच को भी बढ़ावा देता है: पूछें कि उपयोगकर्ताओं को क्या चाहिए, कौन सी सीमाएँ हैं, और कौन से फेलियर मोड स्वीकार्य हैं—फिर उसी के अनुरूप मॉडल और डेटा पाइपलाइन डिज़ाइन करें।
एक छोटा समस्या चुनें जिसे आप एंड-टू-एंड पूरा कर सकें: सपोर्ट टिकट्स को वर्गीकृत करना, डुप्लिकेट रिकॉर्ड्स का पता लगाना, नोट्स का सारांश बनाना, या लीड्स रैंक करना।
एक साधारण संस्करण शिप करें, उसे मीट्रिक के साथ इंस्ट्रूमेंट करें, और वास्तविक गलतियों की समीक्षा करें। पहले डेटासेट (या अगर आप LLM वर्कफ़्लोज़ इस्तेमाल करते हैं तो प्रॉम्प्ट्स) में सुधार करें, फिर मॉडल को एडजस्ट करें। तब तक दोहराएँ जब तक यह उपयोगी न बन जाए—न कि परिपूर्ण।
उन्होंने मशीन लर्निंग को एक इंजीनियरिंग वर्कफ़्लो के तौर पर पढ़ाया: इनपुट/आउटपुट तय करो, एक बेसलाइन बनाओ, ट्रेन करो, मूल्यांकन करो, और फिर इटरेट करो।
यह फ्रेमिंग उन तरीकों से मेल खाती है जिनसे डेवलपर्स पहले से सॉफ़्टवेयर डिलिवर करते हैं, इसलिए एआई "रहस्यमय गणित" कम और अभ्यास योग्य कौशल अधिक लगा।
एक सामान्य “एनजी-स्टाइल” लूप यह है:
यह मॉडलों पर लागू संरचित डिबगिंग है।
वे छोटी लेक्चर को हैंड्स-ऑन असाइनमेंट और त्वरित फीडबैक (क्विज़/ऑटोग्रेडर्स) के साथ जोड़ते हैं।
व्यस्त डेवलपर्स के लिए यह 20–40 मिनट के सत्रों में प्रगति संभव बनाता है, और असाइनमेंट आपको अवधारणाओं को काम करने वाले कोड में बदलने के लिए मजबूर करते हैं—सिर्फ वीडियो देखने की बजाय।
ज़रूरी नहीं। सामग्री में कलन/लिनियर अल्जेब्रा के विचार होते हैं, लेकिन बड़े अवरोध आमतौर पर व्यावहारिक होते हैं:
आप सहज ज्ञान से शुरू कर सकते हैं और जरूरत पड़ने पर गणितीय गहराई बढ़ा सकते हैं।
यह डायग्नोस्टिक लेंस है:
यह अगला कदम मार्गदर्शित करता है—उदाहरण के लिए, वैरियंस के लिए डेटा/रेगुलराइज़ेशन बढ़ाएँ, या बायस के लिए मॉडल क्षमता/फीचर गुणवत्ता बढ़ाएँ—सिर्फ अनुमान लगाने की बजाय।
शुरू करें:
फिर एरर एनालिसिस करें और स्केल करने से पहले डेटा/लेबल्स में सुधार करें। यह "नोटबुक में काम करता है" वाली समस्याओं को रोकता है जो वास्तविक सीमाओं पर ढह जाती हैं।
यह विचार है कि डेटा गुणवत्ता अक्सर मुख्य рыवट है:
कई टीमों को नया आर्किटेक्चर बदलने से ज़्यादा फायदा डेटा और फीडबैक लूप बेहतर करने से मिलता है।
शिक्षा नियंत्रित अभ्यास देती है; असली काम में और भी बाधाएँ आती हैं:
कोर्सेस मूल बातें तेज़ी से सिखा सकते हैं, लेकिन वास्तविक योग्यता छोटे एंड-टू-एंड प्रोजेक्ट्स शिप करने और वास्तविक फेलियर मोड्स पर इटरेट करने से आती है।
एक संकुचित समस्या चुनें और पूरा लूप डॉक्यूमेंट करें:
एक अच्छी तरह समझाई गई 1–2 परियोजना निर्णय और इटरेशन दिखाती है—कई चमकदार डेमो से बेहतर।
एक साधारण फिल्टर अपनाएँ:
फिर किसी एक ट्रैक को उतना समय दें कि आप बनाकर शिप कर सकें—फ्रेमवर्क और ट्रेंड्स के बीच उछलने की जगह नहीं।