मुझे लगता है कि इन दोनों पहलुओं पर पर्याप्त गंभीरता से विचार होना चाहिए।
कंपनी चलाने के लिए developers की ज़रूरत होती है, और अभी junior developers के लिए नौकरी पाना कठिन समय लग रहा है।
सार्वजनिक रूप से AI को वजह बताया जा रहा है, लेकिन COVID के दौरान बड़े पैमाने पर भर्ती होने और उसके अनुपात में सफलता न मिलने की तुलना में कंपनियों की कुल labor cost बढ़ गई, इसलिए उस बोझ के कारण भर्ती घटाई जा रही है। ऐसे हालात में जब LLM का उपयोग junior developer से काम करवाने जितनी या उससे अधिक efficiency दिखाने लगा, तो मेरा मानना है कि नौकरी का बाज़ार खुद ही और सिकुड़ गया है.
लेकिन जैसा लेख में भी लिखा है, junior developers होंगे तभी वे अंततः senior developers के रूप में विकसित हो सकेंगे।
अगर junior developer स्तर पर भर्ती ही नहीं होगी, तो senior developers पैदा ही नहीं हो सकते।
फिर भी, मुझे लगता है कि इस प्रक्रिया में काफ़ी संतुलन और समन्वय की ज़रूरत है।
बड़ी कंपनियों में शायद systems बेहतर बने होते हैं, इसलिए असर कम होगा, लेकिन जब junior developer आता है तो उसे कंपनी के मुख्य काम के बजाय कुछ सहायक काम (ऐसा काम जिसमें असफल होने पर भी कंपनी पर बड़ा असर न पड़े) देकर प्रशिक्षण दिया जाता है।
लेकिन senior developer के दृष्टिकोण से, जितना कम system स्थापित होगा, junior developer को मार्गदर्शन देना उतना ही कठिन होगा।
और विडंबना यह है कि LLM का उपयोग करते समय संबंधित ज्ञान ज़्यादा होना फ़ायदेमंद होता है; सिर्फ़ beginner developer होने से वही efficiency नहीं मिलती।
बल्कि सभी development कार्यों को junior कर्मचारियों से पूरी तरह बदल देना संभव नहीं है। बहुत होशियार और प्रतिभाशाली लोग शायद senior developer के बिना भी किसी तरह काम कर लें। लेकिन अगर काम धीरे-धीरे उसी व्यक्ति पर इकट्ठा होने लगे, तो क्या वह उसे संभाल पाएगा?
अर्थात, senior developers और junior developers दोनों की भर्ती होनी चाहिए, और उस प्रक्रिया में productivity तथा कंपनी की labor cost आदि को ध्यान में रखते हुए flexible hiring होनी चाहिए.
मैं समझता/समझती हूँ कि यह तर्क है कि LLM का क्रेज़ हद से ज़्यादा है, और इस बात से भी सहमत हूँ कि इसका काम करने का तरीका deduction या induction जैसी reasoning नहीं है। लेकिन artificial intelligence और intelligence एक ही चीज़ के पर्याय नहीं हैं, और समस्या उन लोगों की नहीं है जो दोनों को एक जैसा मानते हैं या उनका मानवीकरण करते हैं?
मेरी जानकारी के अनुसार, चाहे Windows हो या Linux, Chrome sandbox mode में चलता है। यानी... अगर कोई JavaScript वगैरह से exploit बनाकर किसी vulnerability पर हमला भी करे, तब भी उसका असर वास्तविक OS पर नहीं पड़ता।
लेकिन container mode में शायद वह फीचर चालू करने के लिए privileged mode ऑन करना पड़ेगा।
बेशक, ऐसा करने के लिए निर्देश दिया जा सकता है, लेकिन मैं तो container को ही एक sandbox मानता था। शायद इसे ऐसे कहूँ कि यह ऐसे Windows जैसा है जिसे आसानी से चालू और बंद किया जा सकता है...
इसी वजह से Chromium और Electron-आधारित vscode को sandbox के बजाय non-sandbox mode में चलने के लिए रखा गया है।
बात सिर्फ इतनी है कि अगर Chromium और vscode में vulnerability हो, और कोई हमलावर उसका इस्तेमाल करके exploit बना सके, तो यह खतरनाक हो सकता है।
मुझे यह जानकर जिज्ञासा हुई कि sandbox mode लागू न होना सुरक्षा संबंधी सावधानी क्यों माना गया।
क्या इसका मतलब है कि Docker अंदरूनी processes को sandbox feature नहीं देता? इसलिए क्या इसे मजबूरी में root के रूप में चलाना पड़ता है, और भले ही यह Docker से अलग-थलग किया गया environment हो, फिर भी host से mapped volume में malware घुसने का जोखिम हो सकता है? या फिर इसका मतलब यह है कि Docker के अंदर file system में user द्वारा बनाई गई files सुरक्षित न हों?
और अगर LLM कृत्रिम बुद्धिमत्ता नहीं हैं, तो आपको यह भी बताना होगा कि वे आखिर हैं क्या। आप तो कहते हैं कि यह तो सिर्फ स्नातक स्तर की पढ़ाई करने से ही पता चल जाता है, है ना?
तो क्या वे कंपनियाँ अनुभवहीन हैं, जो सैकड़ों करोड़ खर्च करके टैलेंट स्काउट करेंगी? आपको जो सबसे बेहतरीन ज्ञान पता है, वह शायद उनके लिए बेकार ज्ञान जैसा होगा।
अगर किसी संगठन का लक्ष्य न्यूनतम स्तर को ऊपर उठाना है, तो यह मानना ठीक है कि केवल web frontend developers वाली टीम या app developers टीम जैसी role-based organization उपयुक्त है.
लेकिन जिन टीमों या संगठनों का लक्ष्य उच्चतम स्तर हासिल करना है, उनके लिए role-based organization में बनना अनिवार्य रूप से सीमित होता है.
जैसा कि मूल लेख में कहा गया है, क्या सचमुच planner, designer, PM और engineer को अपने-अपने अलग काम लेकर, किसी फैक्टरी की conveyor belt की तरह काम करना चाहिए? यही सवाल उठता है. कुछ तयशुदा जिम्मेदारियां लेकर काम करने वाली पारंपरिक "in-charge" शैली के बजाय, अलग-अलग क्षेत्रों में specialty रखने वाले सदस्य इकट्ठा हों, साझा लक्ष्य साथ मिलकर तय करें, और पूरी टीम एक-दूसरे को support करे — यही आदर्श है.
कई कंपनियों में spin-off, team composition आदि के लिए task force के रूप में संगठन बनाए जाते हैं, लेकिन वहां भी सिर्फ लोगों (roles) को एक साथ बांध देने से नकारात्मक reinforcement पैदा हो सकती है — जैसे, "मैं कुछ करने की कोशिश कर रहा हूं, लेकिन कंपनी मदद नहीं कर रही, तो छोड़ देता हूं" जैसी प्रवृत्ति. इससे key members जैसे महत्वपूर्ण प्रतिभाशाली लोग ही खो सकते हैं. इसलिए purpose-based organization को भी role-based organization के सक्रिय support की जरूर जरूरत होती है.
LLM कृत्रिम बुद्धिमत्ता नहीं है
यह बात कि LLM बुद्धिमत्ता नहीं है, artificial intelligence का सिर्फ undergraduate स्तर पर अध्ययन करने से भी समझ आ जाती है, लेकिन समस्या यह है कि लोग एक high-school graduate यहूदी की marketing stunt जैसी चीज़ के झांसे में आ गए।
मौजूदा LLM उद्योग में जो बेहूदा बातें हो रही हैं, वे hydrogen truck के नाम पर धोखा देने वाली Nikola की याद दिलाती हैं।
जैसे hydrogen fuel cell बना न सकने वाला और सिर्फ hydrogen electric truck का खोल तैयार करने वाला एक vendor धोखाधड़ी करते हुए बर्बाद हो गया, वैसे ही बुद्धिमत्ता बना न सकने के बावजूद LLM chatbot बनाकर उसे ही intelligence बताकर तमाशा करने वाला high-school graduate यहूदी भी उसी स्तर का है।
अमेरिका अब किसी भी क्षेत्र में core technology को ठीक से हासिल करने की क्षमता नहीं रखता, और सिर्फ SBS के ज़रिये marketing करके पैसा खींचने वाली Madoff-स्तर की Ponzi scheme जैसा देश बनकर गिर चुका है, जिसका उसके अलावा कोई अस्तित्वगत कारण नहीं बचा।
आगे चलकर पैसे कमाने वाला AI क्षेत्र हर हाल में Computer Vision AI होगा, और यही भविष्य के युद्ध और सैन्य शक्ति को नियंत्रित करेगा।
लेकिन Computer Vision AI क्षेत्र में चीन दुनिया में नंबर 1 के रूप में तेज़ी से उभर रहा है और hegemonic power के रूप में बढ़ रहा है।
अगर अमेरिका की तरह LLM-केंद्रित विशाल पूंजी निवेश bubble की तरह फट गया, तो अमेरिका के लिए AI क्षेत्र की अगुवाई चीन को खो देने की संभावना बहुत बड़ी है।
पश्चिमी समाज में बहुसंख्यक Wordcel लोगों द्वारा संचालित मौजूदा LLM निवेश अब दीवार से टकरा रहा है, और इसके लाभ-हानि का हिसाब पूंजीपति बेहद कठोरता से करेंगे; इसका असर Computer Vision AI जैसे संबंधित क्षेत्रों तक फैल सकता है, जिससे काफ़ी समय तक AI उद्योग के सिमटने की संभावना है।
इसके विपरीत, जहाँ राज्य research and development को आगे बढ़ा रहा है, वह चीन ऐसे अमेरिकी AI bubble से तुलनात्मक रूप से सुरक्षित रह सकता है।
इसलिए, यह LLM पर अतिनिवेश अमेरिका को hegemonic nation से दूसरे दर्जे के देश में स्थिर कर देने का अवसर बन सकता है।
Context engineering- What+Why के साथ समझदारी से निर्देश देना!
इसके अलावा, जिन कई बातों को लेकर मैं आमतौर पर जिज्ञासु रहता था, उन्हें भी उन्होंने बहुत स्पष्टता से समझाया है :)
इतनी उच्च-गुणवत्ता की जानकारी मुफ्त में देख पाना सचमुच शर्मिंदा भी करता है और बहुत आभारी भी बनाता है!!!!
अब AWS में कोई एकल सेवा चुनकर इस्तेमाल नहीं की जा सकती।
कुछ भी करना हो तो कई चीज़ों को आपस में जोड़कर इस्तेमाल करना पड़ता है।
यह बिल्कुल भी सरल नहीं है।
startup में इसे इस्तेमाल करना हो तो सिर्फ cloud cost ही नहीं, बल्कि DevOps मैनपावर की लागत भी उठानी पड़ती है।
इसे ठीक से सेटअप करने के लिए development time इतना खिंच जाता है कि काम का बोझ जरूरत से ज्यादा बढ़ जाता है।
इसके अलावा managed services का इस्तेमाल ज़्यादा फायदेमंद होने वाले मामले बढ़ रहे हैं, इसलिए code level पर ही platform dependency बन जाती है.
अरे नहीं, इतनी माफ़ी माँगने की तो ज़रूरत ही नहीं... हाहा, इतने बढ़ा-चढ़ाकर कहने के लिए धन्यवाद।
मुझे लगता है कि इन दोनों पहलुओं पर पर्याप्त गंभीरता से विचार होना चाहिए।
कंपनी चलाने के लिए developers की ज़रूरत होती है, और अभी junior developers के लिए नौकरी पाना कठिन समय लग रहा है।
सार्वजनिक रूप से AI को वजह बताया जा रहा है, लेकिन COVID के दौरान बड़े पैमाने पर भर्ती होने और उसके अनुपात में सफलता न मिलने की तुलना में कंपनियों की कुल labor cost बढ़ गई, इसलिए उस बोझ के कारण भर्ती घटाई जा रही है। ऐसे हालात में जब LLM का उपयोग junior developer से काम करवाने जितनी या उससे अधिक efficiency दिखाने लगा, तो मेरा मानना है कि नौकरी का बाज़ार खुद ही और सिकुड़ गया है.
लेकिन जैसा लेख में भी लिखा है, junior developers होंगे तभी वे अंततः senior developers के रूप में विकसित हो सकेंगे।
अगर junior developer स्तर पर भर्ती ही नहीं होगी, तो senior developers पैदा ही नहीं हो सकते।
फिर भी, मुझे लगता है कि इस प्रक्रिया में काफ़ी संतुलन और समन्वय की ज़रूरत है।
बड़ी कंपनियों में शायद systems बेहतर बने होते हैं, इसलिए असर कम होगा, लेकिन जब junior developer आता है तो उसे कंपनी के मुख्य काम के बजाय कुछ सहायक काम (ऐसा काम जिसमें असफल होने पर भी कंपनी पर बड़ा असर न पड़े) देकर प्रशिक्षण दिया जाता है।
लेकिन senior developer के दृष्टिकोण से, जितना कम system स्थापित होगा, junior developer को मार्गदर्शन देना उतना ही कठिन होगा।
और विडंबना यह है कि LLM का उपयोग करते समय संबंधित ज्ञान ज़्यादा होना फ़ायदेमंद होता है; सिर्फ़ beginner developer होने से वही efficiency नहीं मिलती।
बल्कि सभी development कार्यों को junior कर्मचारियों से पूरी तरह बदल देना संभव नहीं है। बहुत होशियार और प्रतिभाशाली लोग शायद senior developer के बिना भी किसी तरह काम कर लें। लेकिन अगर काम धीरे-धीरे उसी व्यक्ति पर इकट्ठा होने लगे, तो क्या वह उसे संभाल पाएगा?
अर्थात, senior developers और junior developers दोनों की भर्ती होनी चाहिए, और उस प्रक्रिया में productivity तथा कंपनी की labor cost आदि को ध्यान में रखते हुए flexible hiring होनी चाहिए.
मैं समझता/समझती हूँ कि यह तर्क है कि LLM का क्रेज़ हद से ज़्यादा है, और इस बात से भी सहमत हूँ कि इसका काम करने का तरीका deduction या induction जैसी reasoning नहीं है। लेकिन artificial intelligence और intelligence एक ही चीज़ के पर्याय नहीं हैं, और समस्या उन लोगों की नहीं है जो दोनों को एक जैसा मानते हैं या उनका मानवीकरण करते हैं?
बड़े Dataset के साथ Eliza
मेरी जानकारी के अनुसार, चाहे Windows हो या Linux, Chrome sandbox mode में चलता है। यानी... अगर कोई JavaScript वगैरह से exploit बनाकर किसी vulnerability पर हमला भी करे, तब भी उसका असर वास्तविक OS पर नहीं पड़ता।
लेकिन container mode में शायद वह फीचर चालू करने के लिए privileged mode ऑन करना पड़ेगा।
बेशक, ऐसा करने के लिए निर्देश दिया जा सकता है, लेकिन मैं तो container को ही एक sandbox मानता था। शायद इसे ऐसे कहूँ कि यह ऐसे Windows जैसा है जिसे आसानी से चालू और बंद किया जा सकता है...
इसी वजह से Chromium और Electron-आधारित vscode को sandbox के बजाय non-sandbox mode में चलने के लिए रखा गया है।
बात सिर्फ इतनी है कि अगर Chromium और vscode में vulnerability हो, और कोई हमलावर उसका इस्तेमाल करके exploit बना सके, तो यह खतरनाक हो सकता है।
मुझे यह जानकर जिज्ञासा हुई कि sandbox mode लागू न होना सुरक्षा संबंधी सावधानी क्यों माना गया।
क्या इसका मतलब है कि Docker अंदरूनी processes को sandbox feature नहीं देता? इसलिए क्या इसे मजबूरी में root के रूप में चलाना पड़ता है, और भले ही यह Docker से अलग-थलग किया गया environment हो, फिर भी host से mapped volume में malware घुसने का जोखिम हो सकता है? या फिर इसका मतलब यह है कि Docker के अंदर file system में user द्वारा बनाई गई files सुरक्षित न हों?
मुझे लगता है कि आप यह कहकर ही गलत समझ रहे हैं कि llm artificial intelligence नहीं है।
लगता है आप अपनी ही दुनिया में खोए हुए हैं।
और अगर LLM कृत्रिम बुद्धिमत्ता नहीं हैं, तो आपको यह भी बताना होगा कि वे आखिर हैं क्या। आप तो कहते हैं कि यह तो सिर्फ स्नातक स्तर की पढ़ाई करने से ही पता चल जाता है, है ना?
तो क्या वे कंपनियाँ अनुभवहीन हैं, जो सैकड़ों करोड़ खर्च करके टैलेंट स्काउट करेंगी? आपको जो सबसे बेहतरीन ज्ञान पता है, वह शायद उनके लिए बेकार ज्ञान जैसा होगा।
वाह, सच में बहुत कुछ बदल गया है।
मुझे नहीं पता कि
git-reviewका तरीका अच्छा है या नहीं, लेकिन मैं इस बात से सहमत हूँ कि GitHub-आधारित PR review बेहद खराब है..आख़िर ऐसी टिप्पणियाँ हमेशा फेंक अकाउंट ही क्यों लिखते हैं
अगर किसी संगठन का लक्ष्य न्यूनतम स्तर को ऊपर उठाना है, तो यह मानना ठीक है कि केवल web frontend developers वाली टीम या app developers टीम जैसी role-based organization उपयुक्त है.
लेकिन जिन टीमों या संगठनों का लक्ष्य उच्चतम स्तर हासिल करना है, उनके लिए role-based organization में बनना अनिवार्य रूप से सीमित होता है.
जैसा कि मूल लेख में कहा गया है, क्या सचमुच planner, designer, PM और engineer को अपने-अपने अलग काम लेकर, किसी फैक्टरी की conveyor belt की तरह काम करना चाहिए? यही सवाल उठता है. कुछ तयशुदा जिम्मेदारियां लेकर काम करने वाली पारंपरिक "in-charge" शैली के बजाय, अलग-अलग क्षेत्रों में specialty रखने वाले सदस्य इकट्ठा हों, साझा लक्ष्य साथ मिलकर तय करें, और पूरी टीम एक-दूसरे को support करे — यही आदर्श है.
कई कंपनियों में spin-off, team composition आदि के लिए task force के रूप में संगठन बनाए जाते हैं, लेकिन वहां भी सिर्फ लोगों (roles) को एक साथ बांध देने से नकारात्मक reinforcement पैदा हो सकती है — जैसे, "मैं कुछ करने की कोशिश कर रहा हूं, लेकिन कंपनी मदद नहीं कर रही, तो छोड़ देता हूं" जैसी प्रवृत्ति. इससे key members जैसे महत्वपूर्ण प्रतिभाशाली लोग ही खो सकते हैं. इसलिए purpose-based organization को भी role-based organization के सक्रिय support की जरूर जरूरत होती है.
LLM कृत्रिम बुद्धिमत्ता नहीं है
यह बात कि LLM बुद्धिमत्ता नहीं है, artificial intelligence का सिर्फ undergraduate स्तर पर अध्ययन करने से भी समझ आ जाती है, लेकिन समस्या यह है कि लोग एक high-school graduate यहूदी की marketing stunt जैसी चीज़ के झांसे में आ गए।
मौजूदा LLM उद्योग में जो बेहूदा बातें हो रही हैं, वे hydrogen truck के नाम पर धोखा देने वाली Nikola की याद दिलाती हैं।
जैसे hydrogen fuel cell बना न सकने वाला और सिर्फ hydrogen electric truck का खोल तैयार करने वाला एक vendor धोखाधड़ी करते हुए बर्बाद हो गया, वैसे ही बुद्धिमत्ता बना न सकने के बावजूद LLM chatbot बनाकर उसे ही intelligence बताकर तमाशा करने वाला high-school graduate यहूदी भी उसी स्तर का है।
अमेरिका अब किसी भी क्षेत्र में core technology को ठीक से हासिल करने की क्षमता नहीं रखता, और सिर्फ SBS के ज़रिये marketing करके पैसा खींचने वाली Madoff-स्तर की Ponzi scheme जैसा देश बनकर गिर चुका है, जिसका उसके अलावा कोई अस्तित्वगत कारण नहीं बचा।
आगे चलकर पैसे कमाने वाला AI क्षेत्र हर हाल में Computer Vision AI होगा, और यही भविष्य के युद्ध और सैन्य शक्ति को नियंत्रित करेगा।
लेकिन Computer Vision AI क्षेत्र में चीन दुनिया में नंबर 1 के रूप में तेज़ी से उभर रहा है और hegemonic power के रूप में बढ़ रहा है।
अगर अमेरिका की तरह LLM-केंद्रित विशाल पूंजी निवेश bubble की तरह फट गया, तो अमेरिका के लिए AI क्षेत्र की अगुवाई चीन को खो देने की संभावना बहुत बड़ी है।
पश्चिमी समाज में बहुसंख्यक Wordcel लोगों द्वारा संचालित मौजूदा LLM निवेश अब दीवार से टकरा रहा है, और इसके लाभ-हानि का हिसाब पूंजीपति बेहद कठोरता से करेंगे; इसका असर Computer Vision AI जैसे संबंधित क्षेत्रों तक फैल सकता है, जिससे काफ़ी समय तक AI उद्योग के सिमटने की संभावना है।
इसके विपरीत, जहाँ राज्य research and development को आगे बढ़ा रहा है, वह चीन ऐसे अमेरिकी AI bubble से तुलनात्मक रूप से सुरक्षित रह सकता है।
इसलिए, यह LLM पर अतिनिवेश अमेरिका को hegemonic nation से दूसरे दर्जे के देश में स्थिर कर देने का अवसर बन सकता है।
Context engineering- What+Why के साथ समझदारी से निर्देश देना!
इसके अलावा, जिन कई बातों को लेकर मैं आमतौर पर जिज्ञासु रहता था, उन्हें भी उन्होंने बहुत स्पष्टता से समझाया है :)
इतनी उच्च-गुणवत्ता की जानकारी मुफ्त में देख पाना सचमुच शर्मिंदा भी करता है और बहुत आभारी भी बनाता है!!!!
docker का नाम lancard/xwindow-korean है
Wayland होने की वजह से repo का नाम https://github.com/lancard/xwindow-korean में बदल दिया गया है~
Ubuntu, Debian-आधारित होने की वजह से,
aptजैसी चीज़ें भी आसानी से इस्तेमाल की जा सकती हैं। Ubuntu की बेस इमेज से Debian मुझे ज़्यादा बेहतर लगा।मुझे लगता है कि Rust अकेली ऐसी भाषा है जो चाहे ठीक-ठाक लगती हो, लेकिन उसके toxic fandom(?) की वजह से उससे दूरी बनती है.
अब AWS में कोई एकल सेवा चुनकर इस्तेमाल नहीं की जा सकती।
कुछ भी करना हो तो कई चीज़ों को आपस में जोड़कर इस्तेमाल करना पड़ता है।
यह बिल्कुल भी सरल नहीं है।
startup में इसे इस्तेमाल करना हो तो सिर्फ cloud cost ही नहीं, बल्कि DevOps मैनपावर की लागत भी उठानी पड़ती है।
इसे ठीक से सेटअप करने के लिए development time इतना खिंच जाता है कि काम का बोझ जरूरत से ज्यादा बढ़ जाता है।
इसके अलावा managed services का इस्तेमाल ज़्यादा फायदेमंद होने वाले मामले बढ़ रहे हैं, इसलिए code level पर ही platform dependency बन जाती है.