Vibe coding करने वालों का दायरा non-developers से लेकर अनुभवी developers तक बहुत व्यापक है. उनके पास मौजूद ज्ञान के स्तर के अनुसार, इस लेख की सामग्री से पूरी तरह अलग रहते हुए भी output की quality में बहुत बड़ा अंतर हो सकता है.
किसी के मामले में Cursor इस्तेमाल करने की शर्त पर .cursorrules में बुनियादी OOP नियम और class/method separation के नियम शामिल करके इसे ऐसे चलाया जा सकता है कि refactoring की लगभग ज़रूरत ही न पड़े,
जबकि किसी और के मामले में बुनियादी और महत्वपूर्ण बातों की समझ की कमी के कारण low-level code की भरमार हो सकती है.
यहाँ तक कि, project rules सेट करके code quality को अच्छी बनाए रखने के बारे में लिखे गए लेख और अनुभव पहले से ही बहुत हैं.
यह इस संभावना की ओर इशारा करता है कि कुछ लोग बिना explicit refactoring के भी token usage के लिहाज़ से लाभ देख रहे हो सकते हैं.
हालाँकि, ऊपर के मामलों में उन rules की परिभाषा के ज़रिए प्रति execution unit token usage में कितनी स्पष्ट कमी आती है, यह व्यवस्थित रूप से नहीं बताया गया है. इसलिए इस लेख में codebase quality के अनुसार token usage के अंतर का परीक्षण करके उसके परिणामों को संक्षेप में प्रस्तुत किया गया है.
अर्थात, उपयोगकर्ता के अनुसार explicit refactoring की संख्या स्वयं फिर से 0~n बार तक एक variable बन जाती है,
और इस लेख का मूल उद्देश्य शायद यह समझाना है कि 'अच्छी quality के codebase पर ध्यान देना क्यों अच्छा है?'
मुझे ठीक से समझ नहीं आ रहा कि आप कमेंट में क्या कहना चाह रहे हैं। मेरी टिप्पणी यह थी कि अगर दोनों तरीकों की निष्पक्ष तुलना करनी है, तो कुल खर्च हुए tokens की संख्या की तुलना नहीं करनी चाहिए क्या? क्या refactoring में भी tokens खर्च नहीं होते?
इसके अलावा, आपने जो जवाब दिया है वह न तो लेख में लिखा हुआ लगता है और न ही ऐसा लगता है कि उस पर कोई experiment किया गया है। मेरा समझना है कि आप यह कह रहे हैं कि per-query token comparison की बजाय, कई बार query करने पर refactoring overhead कम हो जाता है और हर query पर अपेक्षित tokens की संख्या घटने से कुल token count में फायदा होगा। लेकिन यह बात तभी सही होगी जब कई queries के दौरान भी, जैसा आप सोच रहे हैं, cost down बना रहे। यह मुझे बहुत ideal स्थिति मानकर कही गई बात लगती है। इस बात की कोई गारंटी नहीं दी जा सकती कि refactoring से होने वाला cost down अगली queries की संख्या से स्वतंत्र होकर बना रहेगा, और बिना experiment के इसे मान भी नहीं लेना चाहिए। अगर आप अपनी मंशा के मुताबिक यह दावा करना चाहते हैं, तो 1 से अधिक queries पर होने वाले cost down को experiment से दिखाना चाहिए। लेकिन क्या आपने experiment सिर्फ 1 बार ही किया और उसी की तुलना की है?
साथ ही, यह सिर्फ मेरी एक धारणा है, लेकिन अगर एक ही लक्ष्य (ideal final output) के लिए queries को अनंत बार दोहराया जाए, तो ideal स्थिति में refactoring हो या न हो, code को अंततः एक ही रूप में converge करना चाहिए। (ideal final output अद्वितीय है)
अगर यह एक उचित धारणा है, तो queries दोहराए जाने के साथ refactoring होने या न होने का अंतर कम होता जाएगा, इसलिए token cost down का लाभ भी धीरे-धीरे कम होगा। इसलिए macro स्तर पर सोचें, तो अगर इस cost down का लाभ पर्याप्त समय तक बना नहीं रहता, तो queries में इस्तेमाल होने वाले कुल tokens की संख्या का अंतर शायद meaningful न भी हो सकता है, क्या ऐसा नहीं है?
प्रीप्रोसेसिंग से पहले और बाद के source code की तुलना करने की ज़रूरत है.
सबटाइटल सामग्री के साथ पूरी तरह मेल नहीं खाता। अगर इसे फिर से व्यवस्थित करें, तो 'टोकन में कमी लाने वाले अधिक स्पष्ट कारकों के विश्लेषण की ज़रूरत है' सबटाइटल के रूप में अधिक उपयुक्त लगता है.
इस बात के कई हिस्सों से मैं सहमत हूँ। हालांकि, इस लेख की प्रकृति में 'इस लेख को पढ़ने वालों के लिए व्यावहारिक लागू करने के तरीके सुझाना' वाला तत्व भी शामिल है.
पहले से ही, इस लेख पर लगे कमेंट्स को देखकर माहौल का अंदाज़ा लगाया जा सकता है। मुझे भी हाल ही में पता चला, लेकिन ऐसा अनुमान है कि AI उपयोगकर्ताओं में non-developer vibe coders भी काफ़ी हैं.
अगर AI के बिना, लेखक द्वारा सीधे समायोजित किए गए code से शानदार परिणाम निकलते हैं,
तो इसे आसानी से ऐसे देखा जा सकता है कि लेखक अपनी development skill का प्रदर्शन कर रहा है और AI की क्षमता को कम करके दिखा रहा है.
इसीलिए, मैंने ऐसे उदाहरण को लिया जिसे कोई भी महसूस कर सके, और उसका माध्यम 'prompt' जैसा तत्व बनाया जिसे आम vibe coders भी इस्तेमाल कर सकें.
आशा है कि इस शोध के बाद, AI token usage को प्रभावित करने वाले कारकों को और अधिक बारीकी से विभाजित करने वाले शोध आगे जारी रहेंगे.
vibe coding में आउटपुट सिर्फ 1 prompt से पूरा नहीं होता।
अगर 1 बार के structural revision के ज़रिए n बार के prompt की token consumption rate को कम करने का प्रभाव मिलता है, तो token reduction की मात्रा उसी तरह किए जाने वाले n बार में परिलक्षित होगी।
n एक ऐसा मान है जो project के उद्देश्य, features की संख्या, और इसके लिए आवश्यक code की मात्रा व जटिलता से तय होता है,
और हाल में cursor / claude code agent भी infinite repetition या AI के अनियंत्रित token उपयोग की समस्या को हल करने के लिए execution unit को छोटा रखने वाले updates ला रहे हैं,
इसलिए मेरा मानना है कि project complexity से जुड़े n मान पर शोध अलग से किया जाना उचित है।
समझ को अधिकतम आसान बनाने के लिए, मैंने ऐसे code से code improvement का उदाहरण दिया जिसमें अलग से कोई निर्देश न होने पर AI द्वारा लिखी गई structural problems मौजूद होती हैं।
यहाँ जो बात नहीं छूटनी चाहिए, वह यह है कि structure में improvement, code development से पूरी तरह स्वतंत्र होकर होने वाली क्रिया बिल्कुल नहीं है।
यह शुरुआती prompt, या AI ruleset (.cursorrules) जैसी constraints के माध्यम से base context के रूप में प्रभाव डाल सकता है,
और project development cycle के दौरान 1 बार का structural improvement हर समस्या का समाधान नहीं कर सकता।
अर्थात, तय अंतराल पर code improvement की योजना बनाने की बजाय base context के रूप में सही structure guidance देना बेहतर दिशा है।
साथ ही, base context के रूप में structure-guiding prompt rules होने और न होने की स्थितियों पर शोध भी अलग से किया जाना उचित लगता है।
बिंदु 1 को संक्षेप में कहें तो,
base context के रूप में structure-guiding prompt rules होने पर कुल token usage कम होने की संभावना भी है,
और n बार के prompt commands के माध्यम से final output प्राप्त होने का एक variable मौजूद है,
इसलिए यह कहना कि 1 बार के structural improvement prompt command की token usage को जोड़कर गणना करनी चाहिए, उचित नहीं है।
मुझे भी कुछ हद तक ऐसा ही लगा।
लेखक की मंशा क्या थी, यह मैं समझ सकता हूँ, लेकिन जो किया गया है उसकी तुलना में लेख कुछ ज़्यादा ही जटिल लगता है।
शायद आप प्रयोग में इस्तेमाल किए गए details को ज़्यादा से ज़्यादा लेख में शामिल करना चाहते थे, इसलिए इसे इस तरह लिखा गया होगा।
लेकिन अगर आप सिर्फ़ मुख्य बिंदुओं को संक्षेप में चुनकर लिखें, तो इस विषय में रुचि रखने वाले लोग शायद आसानी से समझ सकेंगे।
अगर आप बेझिझक details कम करके सिर्फ़ सार रखें, तो शायद यह और बेहतर होगा।
मुझे लेखक की मंशा और परिणाम, दोनों अपने आप में दिलचस्प लगे।
मुख्य तर्क शायद यह है कि बेहतर source code कम token खपत की ओर ले जाता है,
और उसी से संबंधित experiment design करके उसे चलाया गया लगता है।
जहाँ तक मैंने प्रयोग को समझा है, उसे इस तरह सूचीबद्ध कर सकता हूँ:
AI से पूछताछ के लिए दो source code तैयार किए गए — एक मूल source code, और दूसरा वही source code जिसे prompt से pre-process(?) किया गया
GPT5 और Sonnet में, दोनों source code को 5-5 बार चलाकर token खपत की तुलना की गई
शायद यही प्रक्रिया थी।
और अगर मेरी समझ सही है, तो निष्कर्ष यह लगता है कि prompt से pre-process किया गया source code आम तौर पर कम token खर्च करता है।
निष्कर्ष दिलचस्प है, लेकिन experiment पर मेरी राय इस प्रकार है।
यह निष्पक्ष तुलना नहीं है
संख्याओं में कमी दिखती है, लेकिन तुलना source code को process करने में लगे कुल tokens के आधार पर होनी चाहिए।
दूसरे शब्दों में, pre-processing के लिए इस्तेमाल हुए tokens की संख्या भी ध्यान में रखी जानी चाहिए।
अगर pre-processing में इस्तेमाल tokens बहुत ज़्यादा थे, तो वास्तव में कुल token खपत बढ़ गई होगी और यह निष्कर्ष अर्थहीन हो सकता है; और अगर वे कम भी हों, तब भी वास्तविक token खपत का अंतर लेख में दिख रहे अंतर से काफ़ी कम हो सकता है।
pre-processing से पहले और बाद के source code की तुलना करना ज़रूरी है
अगर pre-processing में इस्तेमाल हुए tokens को अलग रख दें, तो query के समय token खपत में कमी अर्थपूर्ण लगती है।
लेकिन source code में ठीक कौन-सा अंतर इस कमी का कारण बना, इसका विश्लेषण किया जाए तो लेख का महत्व और बढ़ सकता है।
क्योंकि इसका मतलब होगा कि उस अंतर को अधिकतम करने के लिए pre-processing prompt optimization संभव है।
लेखक कहते हैं कि code structure refactoring से यह परिणाम आया, लेकिन मैं इससे सहमत नहीं हूँ; मेरा मानना है कि अभी यह निश्चित रूप से नहीं कहा जा सकता।
क्योंकि यह भी संभव है कि AI से refactoring के अलावा किसी और हिस्से में सुधार करवाने पर भी token खपत घटे।
और अधिक विविध प्रयोगों की ज़रूरत है
मेरा मानना है कि मौजूदा code के अलावा दूसरे codebase पर भी यही experiment चलाना चाहिए।
तभी यह तय किया जा सकेगा कि यह परिणाम लगातार अच्छा आता है या नहीं।
हालाँकि व्यावहारिक रूप से यह test करना कठिन हो सकता है, इसलिए इसे अभी सिर्फ़ संदर्भ के तौर पर लेना बेहतर होगा।
इसके अलावा, इस्तेमाल किए गए प्रॉम्प्ट से जुड़ी बातों का सार साझा कर रहा/रही हूँ.
किसी भी हालत में, डेवलपर्स के लिए structure improvement वाले प्रॉम्प्ट लिखना ज्यादा फायदेमंद रहता है. हर प्रोग्राम की प्रकृति अलग होती है, इसलिए high-efficiency improvement के लिए कुछ हद तक development knowledge की जरूरत होती है.
लेकिन इसका मतलब यह नहीं है कि non-developer vibe coders इस तरीके का इस्तेमाल नहीं कर सकते. efficiency में फर्क हो सकता है, लेकिन 프로젝트 코드 정리좀 해줘. 사용하지 않는 코드들은 제거해. जैसी simple command से भी AI files और classes को अलग करके व्यवस्थित करने जैसा काम करता है.
हालांकि, structure improvement की detail में अंतर efficiency में अंतर पैदा कर सकता है, इसलिए संदर्भ सामग्री देखते समय सावधानी जरूरी है.
इस लेख में इतनी रुचि दिखाने के लिए धन्यवाद। चूँकि इसका मुख्य उद्देश्य overseas distribution था, इसलिए लेख अंग्रेज़ी में लिखा गया था, और लगता है कि इसके कारण तरह-तरह की समस्याएँ पैदा हो रही हैं.
इसीलिए, मैं इसका कोरियाई में व्यवस्थित किया गया पोस्ट साझा कर रहा हूँ.
मुख्य बात यह है कि AI को code structure refactoring करने का निर्देश देने के बाद खपत होने वाले tokens की मात्रा कम हो गई।
इसके उलट, यह भी कहा जा सकता है कि अगर code में structural defects की स्थिति में ही commands देते रहें, तो token usage बढ़ जाता है।
संक्षेप में, बात source code की structure improvement होने की है; इसका मतलब यह नहीं है कि prompt में सिर्फ़ मुख्य बातें ही तार्किक ढंग से रखनी चाहिए।
क्या मतलब यह है कि prompt में सिर्फ़ ज़रूरी बातें ही तार्किक तरीके से जोड़नी चाहिए? यानी prompt में जितनी ज़्यादा इधर-उधर की बातें जोड़ेंगे, उतना noise बढ़ेगा, और नतीजे में आने वाला code भी उतना ही ज़्यादा जटिल और noisy हो जाएगा?
मुझे भी यह परिचय और मूल लेख इतने ज़्यादा लंबे-चौड़े और ऐसे लगे जैसे किसी ऐसे व्यक्ति ने लिखे हों जो लिखने में बहुत अच्छा न हो, इसलिए पढ़ते समय दिक्कत हुई।
सार यह है
"टोकन कम करने वाली संरचनात्मक बाधाएँ शामिल करने वाला एक एक-पंक्ति निर्देश जोड़ें"
इतना कहा जा सकता है।
Web Codecs API की परफॉर्मेंस खुद ही इतनी अच्छी है कि वेब मीडिया लाइब्रेरीज़ लगभग सभी बेहतरीन परफॉर्मेंस देती हैं। इसलिए इसे पूरी तरह pure ts कहना थोड़ा मुश्किल लगता है।
मैं फिर से समझाने की कोशिश करता हूँ.
Vibe coding करने वालों का दायरा non-developers से लेकर अनुभवी developers तक बहुत व्यापक है. उनके पास मौजूद ज्ञान के स्तर के अनुसार, इस लेख की सामग्री से पूरी तरह अलग रहते हुए भी output की quality में बहुत बड़ा अंतर हो सकता है.
किसी के मामले में Cursor इस्तेमाल करने की शर्त पर
.cursorrulesमें बुनियादी OOP नियम और class/method separation के नियम शामिल करके इसे ऐसे चलाया जा सकता है कि refactoring की लगभग ज़रूरत ही न पड़े,जबकि किसी और के मामले में बुनियादी और महत्वपूर्ण बातों की समझ की कमी के कारण low-level code की भरमार हो सकती है.
यहाँ तक कि, project rules सेट करके code quality को अच्छी बनाए रखने के बारे में लिखे गए लेख और अनुभव पहले से ही बहुत हैं.
यह इस संभावना की ओर इशारा करता है कि कुछ लोग बिना explicit refactoring के भी token usage के लिहाज़ से लाभ देख रहे हो सकते हैं.
हालाँकि, ऊपर के मामलों में उन rules की परिभाषा के ज़रिए प्रति execution unit token usage में कितनी स्पष्ट कमी आती है, यह व्यवस्थित रूप से नहीं बताया गया है. इसलिए इस लेख में codebase quality के अनुसार token usage के अंतर का परीक्षण करके उसके परिणामों को संक्षेप में प्रस्तुत किया गया है.
अर्थात, उपयोगकर्ता के अनुसार explicit refactoring की संख्या स्वयं फिर से 0~n बार तक एक variable बन जाती है,
और इस लेख का मूल उद्देश्य शायद यह समझाना है कि 'अच्छी quality के codebase पर ध्यान देना क्यों अच्छा है?'
मुझे ठीक से समझ नहीं आ रहा कि आप कमेंट में क्या कहना चाह रहे हैं। मेरी टिप्पणी यह थी कि अगर दोनों तरीकों की निष्पक्ष तुलना करनी है, तो कुल खर्च हुए tokens की संख्या की तुलना नहीं करनी चाहिए क्या? क्या refactoring में भी tokens खर्च नहीं होते?
इसके अलावा, आपने जो जवाब दिया है वह न तो लेख में लिखा हुआ लगता है और न ही ऐसा लगता है कि उस पर कोई experiment किया गया है। मेरा समझना है कि आप यह कह रहे हैं कि per-query token comparison की बजाय, कई बार query करने पर refactoring overhead कम हो जाता है और हर query पर अपेक्षित tokens की संख्या घटने से कुल token count में फायदा होगा। लेकिन यह बात तभी सही होगी जब कई queries के दौरान भी, जैसा आप सोच रहे हैं, cost down बना रहे। यह मुझे बहुत ideal स्थिति मानकर कही गई बात लगती है। इस बात की कोई गारंटी नहीं दी जा सकती कि refactoring से होने वाला cost down अगली queries की संख्या से स्वतंत्र होकर बना रहेगा, और बिना experiment के इसे मान भी नहीं लेना चाहिए। अगर आप अपनी मंशा के मुताबिक यह दावा करना चाहते हैं, तो 1 से अधिक queries पर होने वाले cost down को experiment से दिखाना चाहिए। लेकिन क्या आपने experiment सिर्फ 1 बार ही किया और उसी की तुलना की है?
साथ ही, यह सिर्फ मेरी एक धारणा है, लेकिन अगर एक ही लक्ष्य (ideal final output) के लिए queries को अनंत बार दोहराया जाए, तो ideal स्थिति में refactoring हो या न हो, code को अंततः एक ही रूप में converge करना चाहिए। (ideal final output अद्वितीय है)
अगर यह एक उचित धारणा है, तो queries दोहराए जाने के साथ refactoring होने या न होने का अंतर कम होता जाएगा, इसलिए token cost down का लाभ भी धीरे-धीरे कम होगा। इसलिए macro स्तर पर सोचें, तो अगर इस cost down का लाभ पर्याप्त समय तक बना नहीं रहता, तो queries में इस्तेमाल होने वाले कुल tokens की संख्या का अंतर शायद meaningful न भी हो सकता है, क्या ऐसा नहीं है?
यह लेख 'प्रयोग' शोध के अधिक करीब है,
इसलिए, इस लेख में शामिल सभी संख्यात्मक आँकड़े इस बात पर केंद्रित हैं कि इसे पढ़ने वाला हर व्यक्ति 'पुनरुत्पादन' कर सके।
इसी कारण, इस्तेमाल किया गया मूल source code और परीक्षण में उपयोग की गई सभी प्रक्रियाएँ पूरी तरह दर्ज की गई हैं,
ताकि सभी प्रयोगकर्ताओं को समान परिणाम मिल सकें, और सामग्री का फोकस इसी जानकारी को देने पर है।
टिप्पणियों का माहौल देखकर मुझे लगता है कि,
आगे से शायद 3-पंक्ति सारांश वाले एक लेख और,
विस्तार जानना चाहने वालों के लिए अलग लेख — इस तरह दो लेख लिखने चाहिए।
अगर आप बता दें कि इस लेख का कौन-सा हिस्सा जरूरत से ज्यादा जटिल या बहुत लंबा लगा,
तो आगे लेख लिखने में मुझे बहुत मदद मिलेगी।
मैं पूरी तरह सहमत हूँ। इस तरह की आलोचना का मैं दिल से स्वागत करता हूँ।
दुनिया में कोई अकेला नहीं जीता, और हर व्यक्ति की क्षमता या परिस्थिति अलग होती है।
मैं भी आखिरकार सिर्फ एक डेवलपर हूँ, और अपनी व्यक्तिगत लागत से सभी टेस्ट नहीं कर सकता।
मेरी आशा है कि यह लेख एक बीज बने, बहुत से लोगों पर अच्छा प्रभाव डाले, और आगे होने वाले अनेक शोधों के लिए एक शुरुआती बिंदु बने।
सबटाइटल सामग्री के साथ पूरी तरह मेल नहीं खाता। अगर इसे फिर से व्यवस्थित करें, तो 'टोकन में कमी लाने वाले अधिक स्पष्ट कारकों के विश्लेषण की ज़रूरत है' सबटाइटल के रूप में अधिक उपयुक्त लगता है.
इस बात के कई हिस्सों से मैं सहमत हूँ। हालांकि, इस लेख की प्रकृति में 'इस लेख को पढ़ने वालों के लिए व्यावहारिक लागू करने के तरीके सुझाना' वाला तत्व भी शामिल है.
पहले से ही, इस लेख पर लगे कमेंट्स को देखकर माहौल का अंदाज़ा लगाया जा सकता है। मुझे भी हाल ही में पता चला, लेकिन ऐसा अनुमान है कि AI उपयोगकर्ताओं में non-developer vibe coders भी काफ़ी हैं.
अगर AI के बिना, लेखक द्वारा सीधे समायोजित किए गए code से शानदार परिणाम निकलते हैं,
तो इसे आसानी से ऐसे देखा जा सकता है कि लेखक अपनी development skill का प्रदर्शन कर रहा है और AI की क्षमता को कम करके दिखा रहा है.
इसीलिए, मैंने ऐसे उदाहरण को लिया जिसे कोई भी महसूस कर सके, और उसका माध्यम 'prompt' जैसा तत्व बनाया जिसे आम vibe coders भी इस्तेमाल कर सकें.
आशा है कि इस शोध के बाद, AI token usage को प्रभावित करने वाले कारकों को और अधिक बारीकी से विभाजित करने वाले शोध आगे जारी रहेंगे.
अगर 1 बार के structural revision के ज़रिए n बार के prompt की token consumption rate को कम करने का प्रभाव मिलता है, तो token reduction की मात्रा उसी तरह किए जाने वाले n बार में परिलक्षित होगी।
n एक ऐसा मान है जो project के उद्देश्य, features की संख्या, और इसके लिए आवश्यक code की मात्रा व जटिलता से तय होता है,
और हाल में cursor / claude code agent भी infinite repetition या AI के अनियंत्रित token उपयोग की समस्या को हल करने के लिए execution unit को छोटा रखने वाले updates ला रहे हैं,
इसलिए मेरा मानना है कि project complexity से जुड़े n मान पर शोध अलग से किया जाना उचित है।
यहाँ जो बात नहीं छूटनी चाहिए, वह यह है कि structure में improvement, code development से पूरी तरह स्वतंत्र होकर होने वाली क्रिया बिल्कुल नहीं है।
यह शुरुआती prompt, या AI ruleset (
.cursorrules) जैसी constraints के माध्यम से base context के रूप में प्रभाव डाल सकता है,और project development cycle के दौरान 1 बार का structural improvement हर समस्या का समाधान नहीं कर सकता।
अर्थात, तय अंतराल पर code improvement की योजना बनाने की बजाय base context के रूप में सही structure guidance देना बेहतर दिशा है।
साथ ही, base context के रूप में structure-guiding prompt rules होने और न होने की स्थितियों पर शोध भी अलग से किया जाना उचित लगता है।
बिंदु 1 को संक्षेप में कहें तो,
इसलिए यह कहना कि 1 बार के structural improvement prompt command की token usage को जोड़कर गणना करनी चाहिए, उचित नहीं है।
मुझे भी कुछ हद तक ऐसा ही लगा।
लेखक की मंशा क्या थी, यह मैं समझ सकता हूँ, लेकिन जो किया गया है उसकी तुलना में लेख कुछ ज़्यादा ही जटिल लगता है।
शायद आप प्रयोग में इस्तेमाल किए गए details को ज़्यादा से ज़्यादा लेख में शामिल करना चाहते थे, इसलिए इसे इस तरह लिखा गया होगा।
लेकिन अगर आप सिर्फ़ मुख्य बिंदुओं को संक्षेप में चुनकर लिखें, तो इस विषय में रुचि रखने वाले लोग शायद आसानी से समझ सकेंगे।
अगर आप बेझिझक details कम करके सिर्फ़ सार रखें, तो शायद यह और बेहतर होगा।
मुझे लेखक की मंशा और परिणाम, दोनों अपने आप में दिलचस्प लगे।
मुख्य तर्क शायद यह है कि बेहतर source code कम token खपत की ओर ले जाता है,
और उसी से संबंधित experiment design करके उसे चलाया गया लगता है।
जहाँ तक मैंने प्रयोग को समझा है, उसे इस तरह सूचीबद्ध कर सकता हूँ:
शायद यही प्रक्रिया थी।
और अगर मेरी समझ सही है, तो निष्कर्ष यह लगता है कि prompt से pre-process किया गया source code आम तौर पर कम token खर्च करता है।
निष्कर्ष दिलचस्प है, लेकिन experiment पर मेरी राय इस प्रकार है।
यह निष्पक्ष तुलना नहीं है
संख्याओं में कमी दिखती है, लेकिन तुलना source code को process करने में लगे कुल tokens के आधार पर होनी चाहिए।
दूसरे शब्दों में, pre-processing के लिए इस्तेमाल हुए tokens की संख्या भी ध्यान में रखी जानी चाहिए।
अगर pre-processing में इस्तेमाल tokens बहुत ज़्यादा थे, तो वास्तव में कुल token खपत बढ़ गई होगी और यह निष्कर्ष अर्थहीन हो सकता है; और अगर वे कम भी हों, तब भी वास्तविक token खपत का अंतर लेख में दिख रहे अंतर से काफ़ी कम हो सकता है।
pre-processing से पहले और बाद के source code की तुलना करना ज़रूरी है
अगर pre-processing में इस्तेमाल हुए tokens को अलग रख दें, तो query के समय token खपत में कमी अर्थपूर्ण लगती है।
लेकिन source code में ठीक कौन-सा अंतर इस कमी का कारण बना, इसका विश्लेषण किया जाए तो लेख का महत्व और बढ़ सकता है।
क्योंकि इसका मतलब होगा कि उस अंतर को अधिकतम करने के लिए pre-processing prompt optimization संभव है।
लेखक कहते हैं कि code structure refactoring से यह परिणाम आया, लेकिन मैं इससे सहमत नहीं हूँ; मेरा मानना है कि अभी यह निश्चित रूप से नहीं कहा जा सकता।
क्योंकि यह भी संभव है कि AI से refactoring के अलावा किसी और हिस्से में सुधार करवाने पर भी token खपत घटे।
और अधिक विविध प्रयोगों की ज़रूरत है
मेरा मानना है कि मौजूदा code के अलावा दूसरे codebase पर भी यही experiment चलाना चाहिए।
तभी यह तय किया जा सकेगा कि यह परिणाम लगातार अच्छा आता है या नहीं।
हालाँकि व्यावहारिक रूप से यह test करना कठिन हो सकता है, इसलिए इसे अभी सिर्फ़ संदर्भ के तौर पर लेना बेहतर होगा।
लगता है बेकार गिफ्ट देना काफ़ी लोकप्रिय है.. नए बेकार गिफ्ट खोजने के लिए यह अच्छा रहेगा
इसके अलावा, इस्तेमाल किए गए प्रॉम्प्ट से जुड़ी बातों का सार साझा कर रहा/रही हूँ.
किसी भी हालत में, डेवलपर्स के लिए structure improvement वाले प्रॉम्प्ट लिखना ज्यादा फायदेमंद रहता है. हर प्रोग्राम की प्रकृति अलग होती है, इसलिए high-efficiency improvement के लिए कुछ हद तक development knowledge की जरूरत होती है.
लेकिन इसका मतलब यह नहीं है कि non-developer vibe coders इस तरीके का इस्तेमाल नहीं कर सकते. efficiency में फर्क हो सकता है, लेकिन
프로젝트 코드 정리좀 해줘. 사용하지 않는 코드들은 제거해.जैसी simple command से भी AI files और classes को अलग करके व्यवस्थित करने जैसा काम करता है.हालांकि, structure improvement की detail में अंतर efficiency में अंतर पैदा कर सकता है, इसलिए संदर्भ सामग्री देखते समय सावधानी जरूरी है.
अगर आपको geospatial जानकारी का उपयोग करना है, तो यह एक अच्छा विकल्प है।
इस लेख में इतनी रुचि दिखाने के लिए धन्यवाद। चूँकि इसका मुख्य उद्देश्य overseas distribution था, इसलिए लेख अंग्रेज़ी में लिखा गया था, और लगता है कि इसके कारण तरह-तरह की समस्याएँ पैदा हो रही हैं.
इसीलिए, मैं इसका कोरियाई में व्यवस्थित किया गया पोस्ट साझा कर रहा हूँ.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
मुख्य बात यह है कि AI को code structure refactoring करने का निर्देश देने के बाद खपत होने वाले tokens की मात्रा कम हो गई।
इसके उलट, यह भी कहा जा सकता है कि अगर code में structural defects की स्थिति में ही commands देते रहें, तो token usage बढ़ जाता है।
संक्षेप में, बात source code की structure improvement होने की है; इसका मतलब यह नहीं है कि prompt में सिर्फ़ मुख्य बातें ही तार्किक ढंग से रखनी चाहिए।
क्या मतलब यह है कि prompt में सिर्फ़ ज़रूरी बातें ही तार्किक तरीके से जोड़नी चाहिए? यानी prompt में जितनी ज़्यादा इधर-उधर की बातें जोड़ेंगे, उतना noise बढ़ेगा, और नतीजे में आने वाला code भी उतना ही ज़्यादा जटिल और noisy हो जाएगा?
ऊपर पर ऊपर
मैं लेखक हूँ। फ़ीडबैक के लिए धन्यवाद। अगला लेख लिखते समय इसे ध्यान में रखूँगा।
मुझे भी यह परिचय और मूल लेख इतने ज़्यादा लंबे-चौड़े और ऐसे लगे जैसे किसी ऐसे व्यक्ति ने लिखे हों जो लिखने में बहुत अच्छा न हो, इसलिए पढ़ते समय दिक्कत हुई।
सार यह है
"टोकन कम करने वाली संरचनात्मक बाधाएँ शामिल करने वाला एक एक-पंक्ति निर्देश जोड़ें"
इतना कहा जा सकता है।
अचानक सारे full stop गायब हो गए
निष्कर्ष
AI का उपयोग करने पर उत्पादकता बढ़ने से
लागत घटाने में मदद मिलती है, लेकिन
वह अपने आप में पैसा कमाने वाली चीज़ नहीं है।
nodejsजैसी चीज़ों को दूसरी applications में bind करना काफ़ी झंझटभरा हो जाता है, थोड़ा आसान होता तो अच्छा रहता।Web Codecs API की परफॉर्मेंस खुद ही इतनी अच्छी है कि वेब मीडिया लाइब्रेरीज़ लगभग सभी बेहतरीन परफॉर्मेंस देती हैं। इसलिए इसे पूरी तरह pure ts कहना थोड़ा मुश्किल लगता है।