LLM को लेकर सब कुछ अब भी जादू जैसा और इच्छाधारित सोच है
(dmitriid.com)- LLM टूल्स की सफलता की कहानियों में अक्सर प्रोजेक्ट की शर्तें, यूज़र की विशेषज्ञता, और बाद में लगने वाले काम जैसे तुलना के मानदंड छूट जाते हैं, इसलिए उनकी वास्तविक उपयोगिता का आकलन करना मुश्किल होता है
- MCP, टूल उपयोग, और एजेंट पर होने वाली चर्चाओं में आलोचकों को “गहराई से न देखने वाला” बताकर खारिज करने का रवैया पिछली crypto बहसों जैसा लगता है
- LLM और एजेंट non-deterministic हैं, इसलिए एक ही समस्या पर जो तरीका अभी काम कर रहा है, वह 1 मिनट बाद भी वैसे ही काम करेगा, यह मानना मुश्किल है
- Claude Code के बारे में यह मशहूर दावा कि वह “legacy bugs को संभालता है”, codebase के आकार, bug के प्रकार, और management के तरीके जैसी जानकारी के बिना ही 1.8k likes और 204 reposts पा गया
- कई टूल्स को वास्तव में इस्तेमाल कर चुके दृष्टिकोण से भी, LLM non-deterministic statistical machine के अधिक करीब हैं; वे काम करें तो जादू जैसे लग सकते हैं, लेकिन उन्हें साफ़ तौर पर जादू या engineering कहना कठिन है
LLM अनुभवों की आपस में तुलना करना मुश्किल क्यों है
- LLM टूल्स के पक्ष और विपक्ष के अनुभव आम तौर पर अलग-अलग टुकड़ों में साझा किए जाते हैं, इसलिए यह जांचना कठिन होता है कि क्या वे सच में एक जैसी परिस्थितियों की बात कर रहे हैं
- प्रोजेक्ट और codebase की प्रकृति अक्सर गायब रहती है
- यह स्पष्ट नहीं होता कि वह greenfield है, mature codebase है, या proprietary codebase है
- यूज़र की विशेषज्ञता की भी सीधी तुलना करना कठिन है
- यह पता नहीं चलता कि वह विशेषज्ञता उसी domain, उसी codebase, और उसी language पर लागू होती है या नहीं
- review, fixes, deployment, और समापन जैसे अतिरिक्त काम कितने लगे, यह भी मूल्यांकन पर बड़ा असर डालता है
- यदि एक व्यक्ति यह सारी जानकारी दे भी दे, तब भी दूसरों की परिस्थितियाँ न मालूम हों तो अनुभवों के बीच तुलना सीमित ही रहती है
- इसके ऊपर LLM systems और agents की non-determinism भी जुड़ जाती है
- एक ही समस्या पर अभी काम करने वाला तरीका 1 मिनट बाद भी काम करेगा, यह नहीं माना जा सकता
- React greenfield project पर काम करने वाले senior engineer का अनुभव और OCaml proprietary codebase पर काम करने वाले non-developer designer का अनुभव, model और agent बदलते ही और भी कम तुलनीय हो जाता है
- एक ही model और agent होने पर भी हर run में परिणाम बदल सकते हैं, इसलिए सीधी तुलना कठिन है
गरमाई हुई बहस और वास्तविक टूल उपयोग के बीच की दूरी
- LLM आलोचकों को “MCP और टूल्स को पर्याप्त रूप से न देखने वाला” मानने वाली प्रतिक्रिया AI बहस की अतिशयोक्ति दिखाती है
- “industry leaders” के उदाहरण के रूप में Steve Yegge का Claude Code संबंधी बयान सामने आता है
- इसमें कहा गया कि Claude Code ने पुराने codebase के legacy bugs पर कई दिनों तक आक्रामक रूप से काम किया
- इसमें ऐसी अभिव्यक्ति भी शामिल थी कि Claude Code बिना context को सीधे चुने भी आगे बढ़ता है
- यह भी कहा गया कि जब तक banking approvals मिलते रहें, bug fixes production deployment तक जाते हैं और यूज़र logs देखे जाते हैं
- लेकिन इस उदाहरण में भी निर्णय के लिए ज़रूरी जानकारी गायब है
- codebase का आकार ज्ञात नहीं है
- यह नहीं पता कि bug किस तरह का था
- अतिरिक्त supervision थी या नहीं, यह अस्पष्ट है
- programming language और framework भी सामने नहीं आते
- इसके बावजूद उस बयान को 1.8k likes और 204 reposts मिले
- संशयवादियों और आलोचकों का यह मतलब नहीं कि वे टूल्स का उपयोग ही नहीं करते
- Vercel ka v0 से पूरी तरह डिज़ाइन किया गया एक side project मौजूद है
- Swift न जानते हुए भी Claude Code से एक SwiftUI monitoring app बनाया गया
- Midjourney से event poster बनाए गए
- Elixir में MCP server को vibe-coding किया गया, लेकिन phoenix.new का उपयोग नहीं किया गया
- वास्तविक उपयोग का अनुभव संक्षेप में “50% समय में सिर्फ 50% ही काम करता है” जैसा बताया गया
- LLM non-deterministic statistical machines हैं, और जब वे काम करते हैं तो जादू जैसे लग सकते हैं, लेकिन वे न तो जादू हैं और न ही engineering स्वयं
- LLM पर होने वाली बहसें अक्सर इन्हें सिर्फ जादू या सिर्फ engineering में से एक मानकर चलती हैं
1 टिप्पणियां
Hacker News की राय
जहाँ मैं काम करता हूँ, वहाँ की management से productivity में 10x सुधार जैसी बातें सुनकर झुंझलाहट होती है। ऐसे कुछ दावे कंपनी के अंदर के early adopters से भी आते हैं
लेकिन expectations बहुत ज़्यादा बढ़ गई हैं। इसकी एक वजह Amdahl's law है, क्योंकि असल में coding से कहीं ज़्यादा समय सोचने और मेरे code के customers यानी दूसरे लोगों से communicate करने में जाता है। coding 10x तेज़ हो भी जाए तो भी ज़्यादातर काम वैसे नहीं होते, और कुल productivity लगभग 10–15% बेहतर होने के स्तर तक ही जाती है। यह नज़रअंदाज़ करने लायक नहीं है, लेकिन 10x नहीं है
LLM के साथ सोचने वाला काम करने का अनुभव करीब 20 साल पहले web search सीखने जैसा लगता है। search engines तब जानकारी तक पहुँच देते थे जब आपको पता हो कि क्या ढूँढना है; अब LLM यह पता लगाने में मदद करते हैं कि शुरू में ढूँढना क्या चाहिए, और search भी कर देते हैं। पहले जो काम मेहनत और अनिश्चितता की वजह से मुश्किल माने जाते थे, वे अब मामूली हो गए हैं
अभी मैं web searches का लगभग 1/3 ChatGPT o3 से करता हूँ, और अब इसे छोड़ना मुश्किल है
कच्चे विचारों को व्यवस्थित करने और rubber duck की तरह उन्हें सुनने/सहेजने का psychological effect भी है, जिससे बहुत सारे काम काफी कम बोझिल लगते हैं, और केवल यही अपने-आप में बड़ा फर्क डालता है
अगर किसी एक senior को अच्छी तरह tuned LLM workflow दे दिया जाए, तो उसका LLM से पहले वाले 10 juniors जितना productive होना हैरानी की बात नहीं होगी। बल्कि खराब developer तो senior का समय खाकर productivity को negative भी बना सकता है, इसलिए उस स्थिति में multiplier लगभग अनंत जैसा है
ठीक-ठाक junior भी आम तौर पर low-level repetitive कामों में बंधा रहता है, और LLM ऐसे काम पहले से बेहतर कर सकता है
इसलिए यह बात समझ आती है कि नौकरियाँ सचमुच खत्म हो सकती हैं
AI का यह दौर 2000s की शुरुआत में software engineers को बड़े पैमाने पर offshore outsource करने की कोशिश की याद दिलाता है। executives के बीच भारी उम्मीदें थीं, कागज़ पर बात सही लगती थी, लेकिन ज़्यादातर प्रयास बड़ी नाकामी पर खत्म हुए और लगभग सारी नौकरियाँ फिर से US लौट आईं
बहुत लोग यह अनदेखा करते हैं कि software engineer पूरी चीज़ को जोड़कर रखने वाले अनगिनत छोटे-छोटे काम करता है। AI में ऐसी चीज़ों की बहुत कमी है। इसका मतलब यह नहीं कि विदेशी लोगों में यह नहीं होता, लेकिन language barrier, time zone difference, cultural differences वगैरह की वजह से मिलती-जुलती समस्याएँ पैदा हुईं। code quality और maintainability बहुत गिर गई, और outsourcing firms ने जो बहुत-सा output बनाया, उसे फेंकना पड़ा
जिन codebases पर मैं काम करता हूँ, उनमें भी पहले से AI की गंदगी जमा होने लगी है। code review में pass हो चुकी ऐसी चीज़ों को पकड़ना बहुत मुश्किल है, क्योंकि diff में वे reasonable दिखती हैं। समस्या hidden duplicate code और ऐसी अजीब abstractions हैं जो high level से देखने पर बिल्कुल sense नहीं बनातीं
मैं ठीक उसी वर्ग में आता/आती हूँ जिसकी शिकायत लेखक कर रहा है। उस दौर से, जब सिर्फ ChatGPT था और उसकी performance भी खास नहीं थी, मैं गैर-तुच्छ greenfield products लॉन्च करता/करती आया/आई हूँ। शुरुआत में Claude इस्तेमाल करते हुए web chat और XCode के बीच copy-paste करता/करती था/थी, और बाद में Cursor मिला
Cursor कई परेशान करने वाले build errors छोड़ देता था, लेकिन productivity फिर भी कम-से-कम 3 गुना थी। अब agents बेहतर हो गए हैं और Claude 4 आने के बाद मैं लगभग खुद code नहीं लिखता/लिखती, और मुझे यह बुरा भी नहीं लगता। मैं architect/manager role की तरफ ज्यादा झुक गया/गई हूँ, और जरूरत पड़ने पर अपनी विशेषज्ञता से agent को दिशा देता/देती हूँ
एक demanding startup में आए कुछ महीने हो गए हैं, लेकिन अभी तक हाथ से code की एक भी line नहीं लिखी। PR बनाने से पहले सब कुछ खुद audit करता/करती हूँ और thorough testing करता/करती हूँ, लेकिन Cursor + Sonnet उस codebase में सचमुच अविश्वसनीय रूप से powerful है। code lines जैसी बेकार metrics के हिसाब से नहीं, बल्कि इस मायने में कि जब उस codebase के experts भी अजीब bugs लेकर आते हैं, तो उस domain में नया होने के बावजूद मैं 5–30 मिनट में उसे narrow down कर पाता/पाती हूँ—इसी वजह से मुझे यकीन है कि मैं सबसे productive employee हूँ
अपने पूरे career में जिस frontend developer काम से बचता/बचती रहा/रही, Claude की वजह से दिखने वाली छोटी समस्याएँ ठीक करते-करते उसमें भी उतरना पड़ा। यह vibe coding नहीं है; इसमें investigation, planning, careful exploration की प्रक्रिया है और agent को सफल होने के लिए set up करने का काम है। domain knowledge भी चाहिए। लेकिन सच में हैरानी होती है कि कुछ लोग इससे वही utility कैसे नहीं निकाल पा रहे, और लगता है ऐसे लेख हर हफ्ते दो-दो आ रहे हैं
आप भरोसा करना मुश्किल लगने वाली बातें कर रहे हैं, फिर भी evidence एक भी share नहीं किया। यहाँ तक कि identity verification और claim validation को असंभव बनाने के लिए throwaway account भी बना लिया
इसलिए यह मजाक जैसा लगता है
इसका मतलब यह नहीं कि curation की जरूरत खत्म हो जाती है। वह अब भी मेरी जिम्मेदारी है, और PhD training का हिस्सा भी होना चाहिए। आप X क्यों कर रहे हैं, Y से क्या दिखाना चाहते हैं—इसे सटीक और reflective तरीके से संभालना, और हर step को तोड़कर किसी और को समझाने की क्षमता, एक बहुत बड़ी soft skill है। agents के पास persistent world model नहीं होता, और clever compression इस्तेमाल करने पर भी वे interaction का goal जल्दी भूल जाते हैं, इसलिए यह अभी और महत्वपूर्ण हो गया है
अगर मैं बिल्कुल स्पष्ट तरीके से communicate कर रहा/रही हूँ, तो Claude Code का इस्तेमाल करके computational work को ऐसे organize कर सकता/सकती हूँ जो पहले संभव नहीं था
अगर quality की परवाह है, तो यह programming से आसान नहीं है; यह अलग है, और अलग idioms मांगता है
agent सच में तब useful होता है जब बड़े पैमाने पर mechanical refactoring करनी हो। perfect vim macro या AST rewrite script पर माथापच्ची करने के बजाय मैं agent को दे देता/देती हूँ
average तौर पर prompt कितना लंबा होता है, और unit tests भी LLM ही लिखता है?
निजी तौर पर मुझे लगता है कि experience को बहुत ज्यादा चमकाकर पेश किया जा रहा है
व्यक्तिगत रूप से मैं इसे ठीक से समझ नहीं पाता
दुनिया भर की service industry में बहुत बड़ी मात्रा में काम असल में एक Excel sheet से दूसरी Excel sheet में, या CRM/email से Excel में manual data movement करने जैसा ही है। लगभग हर बड़ी enterprise में ऐसे काम रोज़ करने वाले सैकड़ों से लेकर हज़ारों full-time कर्मचारी होते हैं, और उनमें से काफ़ी outsourced होते हैं। मेरे हिसाब से हर 1 software engineer पर ऐसे manual data pipeline वाले काम करने वाले 100 लोग तो होंगे
इसलिए LLM को बहुत बड़ी value बनाने के लिए OCaml में बेहद अच्छा होना ज़रूरी नहीं है। Excel में इंसान से थोड़ा बेहतर होना ही काफ़ी है। MCP सच में जहाँ मदद करता है, वह यह है कि इन systems को आसानी से जोड़ा जा सकता है। ऐसे कामों में कई errors पूरे task को एक बार में context में डालने की कोशिश से आते हैं। अगर MCP से email लाकर data extract किया जा सके, और फिर MCP से CRM में एक-एक line डाल सकें, तो मेरे अनुभव में hallucination rate बहुत कम होता है। कम-से-कम overworked junior employee के स्तर का तो होता ही है
शायद लेख का point भी यही रहा होगा, लेकिन ऐसे use case में non-determinism समस्या नहीं है। क्योंकि इसमें जुड़े लोग भी deterministic नहीं होते। non-deterministic system, जैसे human system, की quality enforce करने वाले systems और processes बनाए जा सकते हैं
अंत में, मैंने cryptocurrency और LLM दोनों को काफ़ी करीब से follow किया है, और utility व adoption के लिहाज़ से दोनों समान नहीं दिखते। सबसे करीबी तुलना smartphone adoption से है। जब iPhone पहली बार आया था, मेरे कई non-technical दोस्तों ने कहा था कि उन्हें smartphone की ज़रूरत नहीं है, लेकिन कुछ सालों में सबके पास था। LLM भी वैसा ही है। अब मेरे लगभग सभी non-technical दोस्त इसे बहुत अलग-अलग कामों के लिए इस्तेमाल कर रहे हैं
हालांकि social reaction technology worship की धारा जैसा है, और लंबे समय से यह सब देख चुके कई engineers का थक जाना स्वाभाविक है। Unrealistic दावे आसानी से मिल जाते हैं, और सबसे बुरे दावे AI company CEOs से आते हैं
साथ ही, सच में बहुत से लोग लगभग computer illiterate हैं। जिन लोगों ने basic automation तक शायद ही देखा हो, उनके लिए यह कितना रोमांचक लगेगा, इसका अंदाज़ा लगाया जा सकता है। SF में हम जिस “बोलने वाले computer” से परिचित रहे हैं, वह लगभग reality बनता जा रहा है
कुछ साल पहले, AI से पहले मैंने machine learning और natural language processing किया था, और सबसे प्रमुख बात यह है कि यह field में हुई किसी भी चीज़ की तुलना में कहीं ज़्यादा mainstream हो गया है। उसी अनुपात में ऐसे लोग भी बढ़ गए हैं जिनके पास statistical inference के आधार पर design करने का अनुभव कम है। कुछ समय तक opinions, successful implementations और realistic project ideas सीखने—हर मामले में यह Wild West जैसा रहेगा
इसे ऐसे देखिए। अब आप novel-जैसे app idea लेकर आने वाले दोस्त से कह सकते हैं कि वह खुद बनाकर देखे। यह कम-से-कम सबके लिए फायदेमंद है
नौकरी न जाने देने की survival instinct, बेहतर करने की ambition, और अजीब manager को दूसरे रास्ते से report करने की ethics व judgment जैसी चीज़ों के कारण company में emotional investment भी हो सकता है
LLM context से बाहर की किसी वजह से value अजीब दिखने पर organization के किसी दूसरे node को phone करके confirm नहीं करता। उदाहरण के लिए, कल one-off bank holiday था इसलिए value 0 होनी चाहिए—ऐसी situation। इन numbers के accurate होने की guarantee देने की value किसी full-time salary जितनी हो सकती है। और जब वे accurate न हों, तो blame करने, fire करने या जेल भेजने के लिए कोई इंसान होना भी value रखता है
जो सच में automate किया जा सकता था, वह पहले ही automate हो चुका है। मुझे लगता है AI बड़ा disruption लाएगा, लेकिन अधिकांश white-collar jobs “email jobs” या data entry हैं—इस view को लेकर मैं बहुत skeptical हूँ। यह मेरे experience से मेल नहीं खाता, और मैंने उन बड़ी bureaucratic companies में भी काम किया है जिन्हें यहाँ के लोग past में अटका हुआ कह सकते हैं
मैं एक retired programmer हूँ। probability से generated code पर mission-critical systems में भरोसा करना कल्पना करना मुश्किल है। अगर वह लगभग सही हो और बस छोटे edits चाहिए हों तो समझ सकता हूँ, लेकिन मेरा direct experience नहीं है
मेरा मुख्य कहना यह है कि LLM coding के अलावा वाले क्षेत्रों में—जैसे brainstorming, मुक्त विचार, research details भरना, और मुझे खुद पर विचार कराने वाले सवाल पूछना—कमाल का है। मैं LLM को thinking partner की तरह treat करता हूँ। यह गलतियाँ करता है, लेकिन उन्हें दूसरे sources से verify करके, या किसी दूसरे LLM से conclusions review कराकर आसानी से पकड़ा जा सकता है
24 घंटे से कम में मैंने कुछ बना लिया, जिसे शुरू करने में ही मुझे महीनों लग जाते, और अभी जैसी polished version तक पहुँचने में उससे भी ज्यादा समय लगता। सबसे impressive बात यह है कि यह वे काम तेज़ी से कर देता है जो मैं कर सकता हूँ। उससे भी ज्यादा impressive यह है कि जिन कामों के लिए मुझे hire करना पड़ता या outsource करना पड़ता, क्योंकि मैं खुद नहीं कर पाता, वे भी यह बहुत कम पैसे और समय में कर देता है, और किसी इंसान से communicate करने की तुलना में कहीं तेज़ iteration speed के साथ
यह perfect नहीं है और कभी-कभी बेहद frustrating होता है। मना करने के बावजूद values hardcode कर देता है, या यह झूठ बोलता है कि उसने कोई specific fix किया है जबकि असल में किसी बिल्कुल unrelated चीज़ को बदल देता है। फिर भी मेरे हिसाब से यह game changer है
खासकर जब किसी नए field में knowledge निकालने की कोशिश कर रहे हों, तो LLM से mislead होना आसान और खतरनाक है। सामान्य search engine इस्तेमाल करें तो source sites देखकर reliability judge कर सकते हैं, लेकिन LLM में ऐसा कुछ नहीं होता। Output practically कुछ भी हो सकता है, और मैं इस बात से सहमत नहीं हूँ कि गलतियाँ हमेशा आसानी से पकड़ी जा सकती हैं
बेशक मैं इसके लिखे code को check करता हूँ, लेकिन इसकी intelligence और accuracy देखकर लगभग रोज़ हैरान होता हूँ। यह cryptocurrency से बिल्कुल अलग है
अगर आप LLM output को uncritically इस्तेमाल कर रहे हैं तो गलत इस्तेमाल कर रहे हैं, लेकिन human output को भी uncritically इस्तेमाल करना गलत ही है
हाँ, LLM कोई magic नहीं है, और मुझे चिंता है कि लोग copilot या agent models वगैरह से bad engineering practices छिपाएँगे, और long-term में important efficiency, safety और redesign के बजाय boilerplate और ज्यादा जमा करेंगे
दिक्कत यह है कि LLM को यह context देना पड़ता है कि मैं क्या कर रहा हूँ, और ChatGPT-style chat में वह context दिया नहीं जाता या झंझट की वजह से दे नहीं पाते। यहीं Claude Code game बदल देता है
मान लीजिए आपके पास एक PCAP file है जिसमें हर UDP packet में कई messages हैं। IP, port, protocol, time को कैसे filter करेंगे? LLM इस्तेमाल करें और output check कर लें। Pattern A, AB, AAB, ABB आदि वाले packets की संख्या कैसे निकालेंगे? LLM इस्तेमाल करें और output check कर लें। Testing के लिए सिर्फ ऐसे packets वाला PCAP कैसे बनाएँगे? LLM इस्तेमाल करें और output check कर लें
यह code भी पढ़ सकता है, इसलिए सच कहूँ तो आपका काम कोई इतना खास नहीं है, और यह अंदाजा कहीं बेहतर लगा सकता है कि आप क्या करने की कोशिश कर रहे हैं। वैसे भी, सिर्फ यह fact कि आप “ऊपर के सभी functions के लिए unit tests लिख दो” कह सकते हैं, इसे खुद verify करने में मददगार बना देता है
एक बात है कि “ज्यादातर skeptics और critics की तरह मैं भी ये tools रोज़ इस्तेमाल करता हूँ। और 50% cases में ये करीब 50% काम करते हैं”, लेकिन मैं लगभग 1 साल से काम में लगभग रोज़ LLM इस्तेमाल कर रहा हूँ और यह मेरी समस्याओं का करीब 90% हल कर देता है
यह तय करना बहुत मुश्किल है कि ऐसी AI/LLM complaints को seriously लेना चाहिए या उन्हें कुछ users के irrational usage patterns के रूप में देखना चाहिए। उदाहरण के लिए, मैंने कभी LLM में codebase डालकर यह उम्मीद नहीं की कि वह magic की तरह काम करेगा। मैं अपनी understanding की boundaries के भीतर direct और specific questions पूछता हूँ, और solutions को जानबूझकर testable तरीके से apply करता हूँ
अगर कोई अलग तरीके से approach करते हुए LLM से शिकायत करता है, तो मैं इसे गलत इस्तेमाल मानने के ज्यादा करीब हूँ। और वह छोटी, उपयोगी और काफी consistent असली magic को miss कर रहा है
मैं भी Cursor के जरिए gpt और Claude रोज़ इस्तेमाल करता हूँ। gpt o3 general knowledge search के लिए काफी ठीक है। Claude अक्सर टूट जाता है, लेकिन मैंने यह भी देखा है कि tokens waste करते हुए self-display करने के दौरान भी यह real problem से जुड़े points को कई बार छू लेता है
Models बेवकूफ हैं, genius idiot से ज्यादा बस idiot के करीब। फिर भी कभी-कभी relevant चीज़ पकड़ लेते हैं। अगर आपको roughly पता है कि क्या होना चाहिए और आप LLM को farm field में चूहे पकड़ने वाले terrier की तरह treat करें, तो इसे सही तरह इस्तेमाल कर सकते हैं
90% वाला आँकड़ा भी थोड़ा suspicious लगता है
यह लेख discourse की inaccuracy से नाराज़ लगता है, और सच कहूँ तो वह inaccuracy supporters की तुलना में opponents की तरफ ज्यादा फैली हुई है। क्योंकि supporters को आम तौर पर इसकी flaws और limits से रोज़ deal करना पड़ता है
यह निष्कर्ष कि LLM के आसपास सब कुछ magical thinking है, काफी arrogant लगता है। क्योंकि पिछले 5 सालों में translation, transcription, और एक निश्चित scale तक code generation जैसे पहले लगभग मुश्किल से संभलने वाले problems पूरी तरह या लगभग solve हो चुके हैं
Google Translate, Whisper, code generators LLM के बिना भी काफी पहले से मौजूद थे
“क्रिप्टोकरेंसी वापस आ गई है” वाली बात पर, क्रिप्टोकरेंसी मेरे लिए जीवनरेखा है। क्योंकि जिस देश में मैं रहता हूँ, वहाँ ऐसे कारणों से मैं बैंक खाता नहीं खोल सकता जिन्हें न मैं नियंत्रित कर सकता हूँ, न ठीक कर सकता हूँ
इसलिए अगर क्रिप्टोकरेंसी आपके लिए बेकार है, तो अच्छी बात है। मेरे लिए और मेरे जैसे लाखों लोगों के लिए यह जीवन-मरण का सवाल है
LLM भी इसी तरह कुछ लोगों के लिए जादू है, और दूसरों के लिए भरोसेमंद deterministic tool, और साथ ही जादू भी। अभी-अभी सैकड़ों invoices को classify और sort किया। हाँ, यह जादू है
इसलिए वैध अर्थव्यवस्था में क्रिप्टोकरेंसी से होने वाला कोई उपयोगी काम ढूँढना मुश्किल है। क्योंकि इसे ऐसे transactions संभव बनाने के लिए design किया गया है जिन्हें सरकार नहीं चाहती या facilitate नहीं कर सकती। कुछ मामलों में इसके humanitarian applications हैं, और illegal applications भी बहुत हैं
“वहाँ मौजूद रहे हों तभी यकीन कर पाएँगे” https://x.com/0xbags/status/1940774543553146956
AI craze भी अभी कुछ वैसी ही phase से गुजर रहा है। कोई भी criticism हो, उसे ऐसे व्यक्ति की बात मान लिया जाता है जिसे कुछ पता नहीं और जो बेवकूफ है
अगर इसे currency की तरह इस्तेमाल करना है, तो coin को pump-and-dump करके पैसा कमाने का जरिया बनाने वाले लोग आपके दुश्मन हैं। तेज उछाल और गिरावट वाले rollercoaster के बजाय जितनी stability होगी, आपके लिए उतना अच्छा है
मुझे लगता है crypto पक्ष में जानबूझकर बोले गए झूठ ज्यादा हैं और पाने लायक value कम है, लेकिन दोनों मामलों में जो लोग सच में फायदा उठा सकते हैं वे बेईमानी और distortion के कारण threshold तक पहुँचने से पहले ही लौट जाते हैं। और दोनों ही मामलों में आज वास्तविक value पाने के उदाहरण मौजूद हैं
थोड़ा संबंधित मुद्दा है, लेकिन आजकल AGI शब्द, और कभी-कभी AI शब्द तक, जिस तरह इस्तेमाल होता है वह परेशान करता है। खासकर scientific papers में उम्मीद होती है कि सब कुछ अच्छी तरह defined होगा, कम से कम उस paper के अंदर इस्तेमाल के हिसाब से तो होना ही चाहिए
हम AGI क्या है इसकी definition क्यों नहीं बना सकते? तब तार्किक रूप से prove किया जा सकेगा कि कौन-सा AI उस definition में fit बैठता है। भले ही practical रूप से यह बहुत उपयोगी न लगे, लेकिन terms को बिना meaning के इस्तेमाल करने से तो theoretical रूप से कहीं ज्यादा उपयोगी है
अभी यह किसी तरह का बच निकलने का रास्ता लगता है। Wikipedia में लिखा है “AI का ऐसा प्रकार जो लगभग सभी cognitive tasks में human abilities के बराबर या उनसे आगे हो।” इसे measure कैसे करेंगे? अगर यह prove नहीं किया जा सकता कि किसी system में यह property है, तो इसका मतलब क्या रह जाता है?
थोड़ी शिकायत है, लेकिन उम्मीद है कुछ हद तक पढ़ने लायक लगेगी
यह कुछ वैसा है जैसे मेरे लिए “crypto” अब भी cryptography है, cryptocurrency नहीं। कभी-कभी mainstream बस अलग राय रखता है
“AI वह है जो अभी तक नहीं कर पाया गया”[1]
हाल ही में हमारी company ने LLM इस्तेमाल करना शुरू किया, और पहला काम था 20,000 customer calls को transcribe करने के बाद ये जानकारी निकालना
जो research पहले कई हफ्ते लेती थी, वह कुछ घंटों में खत्म हो गई। इसने नई strategy बनाने में मदद की और वास्तविक business value बनाई
मैं LLM को बस natural language processing engine की तरह देखता हूँ, और उस use के लिए यह शानदार है। हाँ, कुछ लोग बढ़ा-चढ़ाकर बताते हैं, लेकिन इससे यह तथ्य नहीं बदलता कि हमारे case में यह सच में useful था। “LLM खराब है” जैसी posts इतनी ज्यादा क्यों हैं, समझ नहीं आता। अगर आपके काम का नहीं है तो आगे बढ़ जाएँ। किसी को किसी के सामने क्या prove करना है? यह बस एक tool है
ऐसी posts expectations को ठंडा करने के लिए जरूरी हैं। जब लोग LLM बेचते हैं, तो वे आम तौर पर customer support calls summarize करने की बात नहीं करते, बल्कि यह idea बेचने की कोशिश करते हैं कि customer support staff को निकाला जा सकता है
वर्षों तक web पर अधिकांश translations में context नहीं था। अब उनमें context हो सकता है
सावधान राय रखने के लिए जाने जाने वाले भरोसेमंद और rational tech figures ने बताया है कि उन्होंने कई तरह की generative AI इस्तेमाल करके programming tasks में significant improvements हासिल किए
यहाँ significant का मतलब कितना है? 5% से 100% के बीच, यानी ऐसा स्तर जिसे ignore नहीं किया जा सकता
कम से कम यह कहना safe है कि generative AI काफी लोगों के लिए काफी beneficial tool है, या हो सकता है
इस हद तक निष्कर्ष reasonable होने के लिए CPU count, lines of code, processed bytes जैसी सारी details disclose करना जरूरी नहीं है