- Martin Fowler ने हाल की LLM उपयोग के तरीकों पर सर्वेक्षणों के बारे में कहा कि वे वास्तविक उपयोग-प्रवाह को ठीक से नहीं दर्शाते, इसलिए उनसे विकृत निष्कर्ष निकल सकते हैं
- प्रोग्रामिंग के भविष्य या नौकरी की स्थिरता जैसे सवालों पर अभी कोई भी निश्चित रूप से नहीं जानता, और व्यक्तिगत रूप से प्रयोग करना व अनुभव साझा करना महत्वपूर्ण है
- AI उद्योग स्पष्ट रूप से बबल की स्थिति में है, लेकिन इतिहास में हर तकनीकी नवाचार की तरह बबल के बाद भी Amazon जैसी टिकने वाली कंपनियाँ उभर सकती हैं
- LLM का मूल स्वभाव हैलुसिनेशन (hallucination) है, और सवाल को कई तरह से पूछकर जवाबों की तुलना करने की प्रक्रिया अपने-आप में उपयोगी है
- LLM सॉफ़्टवेयर सिस्टम की attack surface को बहुत बड़ा बना देते हैं, और खासकर browser agents में ऐसी संरचनात्मक जोखिम हैं जिन्हें मूल रूप से सुरक्षित नहीं बनाया जा सकता
LLM के उपयोग के तरीके और डेवलपर प्रोडक्टिविटी
- हाल में AI का सॉफ़्टवेयर डेवलपमेंट पर प्रभाव को लेकर शुरुआती सर्वेक्षणों और चर्चाओं में तेज़ी आई है
- LLM का अधिकांश उपयोग उन्नत autocomplete फीचर (co-pilot जैसे रूप) पर केंद्रित है
- लेकिन वास्तव में LLM का सबसे प्रभावी उपयोग करने वाले लोग उसे source code files को सीधे पढ़ने और संशोधित करने के लिए इस्तेमाल करना पसंद करते हैं
- LLM उपयोग के तरीकों में अंतर को नज़रअंदाज़ करने वाले सर्वेक्षण डेटा को गलत दिशा में समझने का जोखिम बढ़ाते हैं
- इसके अलावा अलग-अलग LLM models की क्षमता में अंतर भी परिणामों की व्याख्या को और कठिन बनाता है
प्रोग्रामिंग करियर और LLM का भविष्य
- प्रोग्रामिंग का भविष्य, junior engineers की आवश्यकता, और अनुभवी लोगों के करियर जैसे सवाल बार-बार उठते हैं
- इस पर कोई स्पष्ट जवाब देना संभव नहीं है, क्योंकि अभी LLM को प्रभावी ढंग से उपयोग करने का तरीका स्थापित नहीं हुआ है
- प्रयोगधर्मी दृष्टिकोण और दूसरों के ठोस workflow अनुभवों को देखना व साझा करना ज़रूरी है
- खुद इस्तेमाल करके अनुभव बाँटना ही अनुकूलन का सबसे समझदारी भरा तरीका है
AI·LLM क्षेत्र में बबल की स्थिति
- AI को बबल मानने वाले दृष्टिकोण के जवाब में कहा गया है कि हर तकनीकी नवाचार के साथ बबल आता है
- बबल कभी न कभी ज़रूर फूटता है, और निवेश विफल भी होते हैं
- लेकिन बबल कब खत्म होगा और कितना मूल्य बनेगा, इसका अनुमान नहीं लगाया जा सकता
- बबल फूटने के बाद भी सभी कंपनियाँ गायब नहीं होतीं, और कुछ लगातार बढ़ भी सकती हैं
- dot-com बबल के समय pets.com, Webvan खत्म हो गए, लेकिन Amazon बचा रहा और आगे बढ़ा
LLM का हैलुसिनेशन स्वभाव
- LLM में हैलुसिनेशन (Hallucination) कोई दोष नहीं, बल्कि एक मूलभूत विशेषता है
- LLM मूल रूप से उपयोगी हैलुसिनेशन पैदा करने का एक टूल है
- एक ही सवाल को कई बार, अलग-अलग wording में पूछकर कई जवाब लेना और उनकी तुलना करना बेहतर तरीका है
- जहाँ संख्यात्मक जवाब चाहिए, वहाँ बार-बार पूछकर जवाबों के बीच variability देखना महत्वपूर्ण है
- LLM से ऐसी समस्याओं का सीधा उत्तर लेना जिन्हें निश्चित रूप से compute किया जा सकता है, उचित नहीं है
सॉफ़्टवेयर इंजीनियरिंग में non-determinism का प्रवेश
- पारंपरिक सॉफ़्टवेयर इंजीनियरिंग deterministic environment में डिज़ाइन और implement की जाती रही है
- structural और process engineers वास्तविक दुनिया की non-determinism (अनिश्चितता) को ध्यान में रखकर tolerance डिज़ाइन करते हैं
- LLM का आगमन सॉफ़्टवेयर इंजीनियरिंग के non-determinism की दुनिया में प्रवेश का मोड़ हो सकता है
LLM और junior developer की तुलना
- LLM की तुलना अक्सर junior colleague से की जाती है
- लेकिन LLM अक्सर "सभी tests pass" होने का दावा करता है, जबकि वास्तव में failing tests मौजूद होते हैं
- अगर कोई इंसान ऐसा करे, तो यह जल्दी ही performance issue बन जाए
सुरक्षा खतरों में वृद्धि और browser agent की समस्या
- LLM सॉफ़्टवेयर सिस्टम की attack surface को व्यापक रूप से बढ़ा देते हैं
- Simon Willison द्वारा बताई गई 'घातक तिकड़ी (Trifecta)' है: private data access, external communication, और untrusted content exposure
- वेब पेज में छिपे निर्देश (जैसे 1pt सफेद टेक्स्ट) के ज़रिए LLM को धोखा देकर संवेदनशील जानकारी लीक कराई जा सकती है
- browser-based agents खास तौर पर खतरनाक हैं, और बाहरी निर्देशों से अकाउंट ट्रांसफ़र जैसे दुर्भावनापूर्ण काम कराए जा सकते हैं
- Willison का मत है कि agent-style browser extensions को मूल रूप से सुरक्षित बनाना संभव नहीं है
निष्कर्ष
- LLM सॉफ़्टवेयर डेवलपमेंट में नई संभावनाएँ खोलते हैं, लेकिन उनके उपयोग के तरीके और सीमाओं को स्पष्ट रूप से समझना होगा
- बबल अनिवार्य है, लेकिन उसी के माध्यम से टिकाऊ तकनीकी प्रगति भी संभव है
- डेवलपर्स को प्रयोगधर्मी दृष्टिकोण और सुरक्षा पर ध्यान के साथ LLM की क्षमता का अधिकतम उपयोग करना चाहिए
3 टिप्पणियां
सोचते ही घुटन-सी होने लगती है…
खासकर जूनियर वाली उपमा की बात से मैं 100% सहमत हूँ। यह जो गलतियाँ करता है उनकी श्रेणियाँ इंसानों से अलग होती हैं... मुझे लगता है कि यह एक बेहद असफल उपमा है।
Hacker News राय
मेरी पूर्व सहकर्मी Rebecca Parsons लंबे समय से कहती आई हैं कि LLM का hallucination बग कम और core feature ज़्यादा है। वास्तव में LLM का काम उपयोगी hallucination पैदा करना है। जब भी मैं यह तर्क सुनता हूँ, मुझे लगता है कि "hallucination" शब्द को मनमाने ढंग से फिर से परिभाषित करके उसे किसी नई insight की तरह पेश किया जा रहा है। पहले से ‘hallucination’ का मतलब था वास्तविकता से असंबंधित विवरणों को मानो इंद्रिय-अनुभव की तरह विश्वसनीय बनाकर गढ़ देना, लेकिन यह तर्क तो बस "output" कहने जैसा ही है। यह कहना नया नहीं है कि LLM output बनाता है; बस पहले जिस label को 'अच्छा नहीं' माना जाता था, उसे पूरे व्यवहार पर चिपकाकर नया जैसा दिखाया जा रहा है
मुझे नहीं लगता कि Fowler सचमुच "hallucination" शब्द को फिर से परिभाषित कर रहे हैं। बल्कि वे विडंबनापूर्ण तरीके से यह रेखांकित कर रहे हैं कि hallucination इस सिस्टम की बुनियादी कार्यप्रणाली है। यह कुछ वैसा है जैसे कहना कि "बम का collateral damage उसकी प्रकृति का हिस्सा है"; इसे शाब्दिक रूप से लेने की ज़रूरत नहीं है
यह तर्क उस गलत द्वैधता को सुधारने की कोशिश है जिसमें कहा जाता है, “LLM या तो सच पैदा करते हैं, या hallucination।” इस तरह की बात से लगता है कि hallucination कम कर दिए जाएँ तो केवल सत्य बच जाएगा, जबकि वास्तव में हर output किसी न किसी तरह का hallucination ही है। बस उनमें से कुछ वास्तविकता को दर्शाते हैं या हमारी अपेक्षाओं से मेल खाते हैं, इसलिए वे सच जैसे लगते हैं। यह वैसा ही है जैसे पासा फेंकने पर मनचाहा अंक आ जाए और हम कहें, "पासे ने मेरा इरादा पढ़ लिया।" जैसे अनंत बंदर अनंत टाइपराइटर पर टाइप करते रहें तो कभी न कभी Hamlet बना देंगे, वैसे ही बस उस संभावना को AI के सहारे बढ़ा दिया गया है
मुझे वह राय दिलचस्प लगी। यह मान लेना कि LLM को खुद नहीं पता कि उसका output सही है या नहीं, software development में LLM इस्तेमाल करने वालों को एक व्यावहारिक संदर्भ देता है
मुझे इस घटना को "hallucination" शब्द से समझाना असहज लगा। जब कोई इंसान बिना आधार के कुछ विश्वसनीय-सा गढ़कर बोलता है, तो हम उसे "bullshit" कहते हैं; LLM भी मूलतः कुछ वैसा ही है। अगर "bullshit" के नज़रिए से देखें, तो LLM के उपयोग पर की जाने वाली आलोचना कुछ हद तक अर्थहीन हो जाती है। आखिर अगर LLM का यह पहलू आपको असहज करता है, तो शायद आप इंसानों के साथ भी काम नहीं कर पाएँगे। हाँ, "bullshit" शब्द को फिर से परिभाषित करना कहीं अधिक कठिन है। फिर भी मुझे लगता है कि वह लेख बिखरे हुए विचारों के संग्रह के रूप में अपने उद्देश्य के अनुरूप है, और लेखक उसे किसी अधिकारपूर्ण अंतिम कथन की तरह पेश करना भी नहीं चाहता
बात थोड़ी अटपटी तरह से कही गई, लेकिन मूल बिंदु यह है कि 'hallucination' output और दूसरे output के बीच कोई स्पष्ट, कठोर रेखा नहीं है। जैसे RDBMS में दो query results मूल रूप से एक ही प्रकृति के होते हैं। यह एक अर्थपूर्ण observation है
हमारी कंपनी में ऐसा लग रहा है कि 90% ठीक-ठाक और 10% टूटा हुआ, लगभग मनचाहे स्तर तक पहुँचा कोड बहुतायत में भर गया है। कोड की मात्रा बढ़ी है, लेकिन कोई उसके साथ चल नहीं पा रहा, इसलिए quality साफ़ तौर पर गिर रही है। हम धीरे-धीरे लक्ष्य तक नहीं पहुँचते; बल्कि अचानक 90% तक पहुँच जाते हैं, फिर अपरिचित कोड को समझने और लगातार patch करने में समय चला जाता है। हो सकता है कुल मिलाकर यह पहले से तेज़ हो, लेकिन दोनों तरीकों के बीच वास्तविक अंतर शायद उतना बड़ा न हो जितना लगता है। मेरी सबसे बड़ी शिकायत यह है कि मैं अपरिचित कोड को ठीक करने में समय लगाने से ज़्यादा कुछ नया बनाना पसंद करता हूँ
मैं भी बिल्कुल यही महसूस करता हूँ कि कुछ नया बनाना ज़्यादा पसंद है। लेकिन कुछ लोग इस नए तेज़ और तात्कालिक तरीके में अधिक आनंद लेते हैं। मैंने मजबूरी में थोड़ी देर इसका इस्तेमाल किया, अजनबीपन महसूस हुआ, सब मिटा दिया, और फिर AI की मदद लेते हुए हाथ से दोबारा बनाया तो सच में संतोष मिला। एकमात्र AI-generated code जिसे मैं अब तक 100% नहीं समझ पाया हूँ, वह एक जटिल SQL query है; लेकिन SQL query का behavior जल्दी verify किया जा सकता है और उसके अनपेक्षित side effects भी नहीं होते, इसलिए यह ठीक है
यह घटना दर्दनाक रूप से वैसी ही लगती है जैसी तब होती है जब टीम का आकार 3 लोगों से बढ़कर 10 हो जाता है। अचानक आपके सामने बहुत-सा ऐसा कोड आ जाता है जिसे आप नहीं जानते, architecture की consistency गिरती है, और policies तथा CI पर निर्भरता बढ़ जाती है। LLM के मामले में फर्क यह है कि mentoring या firing का कोई अर्थ नहीं है। LLM का प्रभावी उपयोग यही है कि जो व्यक्ति LLM चला रहा है, वह generated result की 100% जिम्मेदारी ले। यानी generated code को साफ़ तौर पर समझना चाहिए, लेकिन व्यवहार में इसे सुनिश्चित करना मुश्किल होगा
LLM boilerplate code auto-generate करने में बहुत अच्छे हैं। इससे boilerplate को व्यवस्थित रखने में आलस्य आ जाता है। जब भारी मात्रा में code PR में आता है तो review करना भी कठिन हो जाता है। Github भी एक बार में बहुत ज़्यादा lines review करने के लिए उपयुक्त नहीं है। नतीजा यह होता है कि junior/mid-level developers सिर्फ boilerplate संभालते रह जाते हैं और सीखने के मौके घट जाते हैं। ऐसा चलता रहा तो code quality तेज़ी से खराब होगी
Perlis की सूक्ति संख्या 7 उद्धृत करते हुए: ‘गलत program लिखना, सही program को समझने से आसान है’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
"quality साफ़ तौर पर गिर रही है" वाली बात से मैं सहमत हूँ, और यह प्रवृत्ति आगे और बढ़ेगी। आखिरकार economics के trade-off को सही तरह समझे बिना यह तय नहीं किया जा सकता कि असली ‘net benefit’ मिलेगा भी या नहीं। लोगों को शायद यह बात नज़रअंदाज़ हो रही है कि free lunch जैसी कोई चीज़ नहीं होती
Rebecca Parsons का “hallucination, LLM का core feature है” वाला framing मुझे सच में बहुत सही लगता है। मैं भी अपने आसपास के लोगों को यह समझाने की कोशिश कर रहा था, और इस एक वाक्य ने वही बात ठीक से पकड़ ली जो मैं कहना चाहता था
मैं भी अपने परिवार और दोस्तों को समझाने के लिए LLM की तुलना actor या performer से करता रहा हूँ। LLM किरदार के हिसाब से performance देता है; facts का इस्तेमाल वह केवल तब करता है जब उनकी ज़रूरत पड़ती है<br>https://jstrieb.github.io/posts/llm-thespians/
पुरानी कहावत “All models are wrong, but some are useful.” यहाँ बिल्कुल फिट बैठती है
बुद्धिमत्ता का मतलब है अनावश्यक जानकारी को filter करने की क्षमता। चाहे वह विचार हों या संवेदनाएँ
किसने कहा था याद नहीं, लेकिन LLM का output हमेशा hallucination ही होता है। बस 90% से ज़्यादा बार वह सही निकल आता है
एक समय लगा था कि LLM हमारी नौकरियाँ छीन लेंगे, लेकिन बाद में समझ आया कि वे शायद हमारे लिए बाद में ठीक करने लायक काम का पहाड़ खड़ा कर देंगे। अब मैं Claude Code जैसे practical assistant tools का अच्छे से उपयोग कर रहा हूँ, और महसूस कर रहा हूँ कि वे replacement नहीं, augmentation हैं
मैंने यह सलाह देखी थी कि “जब LLM से संख्यात्मक उत्तर माँगें, तो लगभग तीन बार दोहराकर पूछें।” यह तरीका इंसानों पर भी काम करता है। पुलिस पूछताछ में एक ही कहानी तीन बार, या उल्टे क्रम में भी कहलवाती है। अगर बात झूठी हो या याद धुंधली हो, तो दोहराव में पकड़ में आ सकती है। interview में भी अगर किसी से एक ही विषय को तीन तरीकों से समझाने को कहें, तो यह परखा जा सकता है कि उसने सच में समझा है या नहीं
यह तकनीक निर्दोष व्यक्ति को भी भ्रमित कर सकती है और उसे झूठा दिखा सकती है। इसलिए इसे सावधानी से लागू करना चाहिए
यह तरीका केवल कुछ शर्तों में ही कारगर है। यादों को बार-बार याद करके सुनाने से वे अक्सर और विकृत हो जाती हैं। पुलिस द्वारा बार-बार पूछना कई बार जानबूझकर बयान में विरोधाभास पैदा करवाने के लिए भी होता है। एक ही जानकारी के बारे में बहुत बार, बहुत अलग तरीकों से खुद से जवाब दिलवाएँ, तो अंततः गलती होना स्वाभाविक है। और यह भी हमेशा ध्यान रखना चाहिए कि सवाल पूछने वाला उत्तर को अपनी पसंद की दिशा में मोड़ सकता है
NASA Space Shuttle ने triple modular redundancy का इस्तेमाल किया। यह इस संभावना के लिए था कि space radiation की वजह से processor या memory corrupt हो जाए<br>https://llis.nasa.gov/lesson/18803
मैं LLM के ज़रिए काफ़ी ऊँची productivity महसूस कर रहा हूँ। यह सिर्फ साधारण autocomplete नहीं है, बल्कि समय बचत का प्रभाव बड़ा है। लेकिन बहुत खुलकर इस्तेमाल करने पर अपने तरह का debt बन सकता है, यह चिंता भी है। व्यक्तिगत रूप से Test Driven Development(TDD) के तरीके से Claude Sonnet या GPT-5 के साथ features को धीरे-धीरे बनाना मेरे लिए सफल रहा है। अभी इस तरीके पर बहुत ज़्यादा लेख या चर्चा नहीं दिखती, लेकिन Martin का लेख पढ़कर अब समझ में आता है क्यों। बेहतरीन TDD practitioners आमतौर पर LLM code automation में बड़े पैमाने पर कूदने वाले लोग नहीं होते; वे अक्सर code craftsmanship या मानवीय संवाद पर गर्व करते हैं। इसलिए पहले जैसी गहरी practical know-how अभी कम है। आगे LLM tools के साथ software लिखने का एक नया ‘मैदान’ खुलेगा और बहुत-सी सीखें जमा होंगी, ऐसी उम्मीद है। संदर्भ: https://news.ycombinator.com/item?id=45055439
developer के लिए यह बुनियादी बात है कि वह LLM द्वारा बनाए गए code को खुद verify और check करे। एक साथ बहुत ज़्यादा code मत माँगिए; छोटे units में LLM का उपयोग करना बेहतर है। unit tests भी मैं खुद चलाता हूँ। LLM अगर test चलाकर ‘success’ कह दे, तो वह सच न भी हो सकता है। tests मैं खुद चलाऊँ, तभी भरोसा बनता है
मैं इस राय से सहमत हूँ कि “hallucination, LLM की विशेषता है”
मैं कहना चाहूँगा कि LLM एक ऐसी दुनिया में रहते हैं जो केवल text और combinations से बनी है। शब्द, शब्दों के बीच संबंध, और कथाएँ — उनके लिए यही पूरा संसार है। इसलिए वे नई कहानियाँ बनाने में सबसे सक्षम हैं। उनकी कहानियाँ कभी-कभी गलत और परस्पर-विरोधी भी होती हैं, इसलिए अंततः वे अनुमान पर निर्भर रहते हैं। LLM सचमुच संख्याएँ गिनना नहीं जानते, लेकिन वे यह pattern जानते हैं कि ‘2, 1 के बाद आता है’ और ‘3, 2 से बड़ा है’। जैसे इंसान calculator इस्तेमाल करते हैं, वैसे ही वे भी tools के माध्यम से computation कर सकते हैं। आगे चलकर arithmetic engine नहीं, बल्कि logic, contradiction avoidance, और निश्चित facts को अलग पहचानने में मदद करने वाला "epistemic engine" आना चाहिए; तभी AI वास्तव में भरोसेमंद बन सकेगा
उस नज़रिए से देखें तो LLM agents को महज़ hallucinated results को filter करने के साधन के रूप में देखा जा सकता है
मैं “सभी (large language) models का output hallucination है; उनमें से कुछ ही उपयोगी होते हैं” वाली बात से ज़्यादा सहमत हूँ। उन्हीं उपयोगी hallucination का अनुपात बहुत ऊँचा है, इसलिए AI boom आया है
मुझे लगता है यह नज़रिया कुछ ज़्यादा ही सरलीकृत है
“hallucination” शब्द हमेशा विवादास्पद इसलिए रहता है, क्योंकि इससे ऐसा भ्रम पैदा होता है कि कुछ outputs ‘hallucination’ नहीं भी हो सकते हैं, जबकि वास्तव में LLM का हर output बिना किसी वास्तविक समझ के generate होता है
आजकल LLM का प्रभावी उपयोग करने के लिए senior-level developers को तर्कसंगत तरीके से काम लेना पड़ता है, तभी मनचाहा परिणाम मिलता है। आगे अगर juniors कम हो गए, तो senior की भूमिका कौन भरेगा, यह सोचने वाली बात है। अंततः मुझे लगता है LLM काफ़ी हद तक खुद programming कर लेंगे। अभी के चरण में AI निश्चित रूप से एक अच्छा सहायक साधन है, replacement नहीं
LLM से कई बार सवाल पूछने वाली सलाह के संदर्भ में, अगर आप macOS user हैं तो Alfred workflow उपयोग करने की सिफारिश करूँगा। command + space दबाकर 'llm <prompt>' टाइप करें, तो perplexity, deepseek(लोकल), chatgpt, claude, grok जैसे कई LLM एक साथ browser tabs में खोले जा सकते हैं। Fowler ने जिन LLMs के बीच cross-checking की बात की थी, वह इससे तेज़ और कुशल हो जाती है, और कई काम करते-करते यह भी समझ आने लगता है कि कौन-सा LLM किस तरह के काम में बेहतर है