लक्षित पाठक: एआई प्रोग्रामिंग टूल (जैसे कर्सर, विंडसर्फ, ट्रे...) का उपयोग करने वाले डेवलपर, और एआई लागतों के बारे में जागरूकता की कमी वाले तकनीकी प्रबंधक।

मुख्य बिंदु: टोकन न केवल एक साधारण बिलिंग इकाई है, बल्कि एक "ध्यान संसाधन" और एक "कंप्यूटिंग शक्ति मुद्रा" भी है। एजेंट मोड का दुरुपयोग करना और संदर्भ प्रबंधन को अनदेखा करना, वास्तव में सामरिक परिश्रम (एआई को बेतरतीब ढंग से काम करने देना) के साथ रणनीतिक आलस्य (खुद न सोचना) को कवर करना है।

आपका "एआई व्यय" आपकी तनख्वाह से भी अधिक हो सकता है

कुछ दिन पहले, मैंने अपने टोकन बिल की जाँच की। जब मैंने वह संख्या देखी, तो मैं थोड़ा हैरान था: 10 मिलियन टोकन। ध्यान दें, यह एक महीने का उपयोग नहीं है, यह एक दिन है।

मुझे लगा कि यह बहुत बेतुका है। बाद में मैंने टोकन गणना से संबंधित एक छोटा वीडियो पोस्ट किया।

परिणामस्वरूप, टिप्पणी अनुभाग ने मुझे दिखाया कि "आकाश की सीमा है" का क्या अर्थ है।

नीचे दी गई छवि उपयोगकर्ता "ओल्ड के डेली" द्वारा एक दिन में दो सौ मिलियन टोकन की खपत का स्क्रीनशॉट है:

शुरुआत में, मुझे लगा कि यह एक अलग मामला हो सकता है, लेकिन जब कई उपयोगकर्ताओं ने टिप्पणी की कि वे प्रतिदिन 100 मिलियन टोकन की खपत करते हैं, तो मुझे एहसास हुआ कि यह एक बहुत ही सामान्य घटना है।

एक सौ मिलियन टोकन क्या है? यदि हम "कुछ मुख्यधारा के वाणिज्यिक मॉडलों" के सामान्य बिलिंग पैमाने (इनपुट/आउटपुट अलग से बिल किया जाता है, मोटे तौर पर 10 डॉलर / मिलियन टोकन के पैमाने पर अनुमानित) के अनुसार गणना करते हैं, तो यह एक दिन में 1000 डॉलर जल जाता है। एक दिन में 7000 युआन जला दिए जाते हैं। कई जूनियर प्रोग्रामर की मासिक तनख्वाह शायद एआई को इस एक दिन के लिए "सोचने" के लिए भी पर्याप्त नहीं है।

(नोट: विभिन्न मॉडलों/विक्रेताओं की कीमतों में काफी अंतर होता है, और इनपुट और आउटपुट की इकाई कीमतें भी अक्सर अलग-अलग होती हैं। यहां उद्देश्य दशमलव के बाद दो अंकों तक सटीक गणना करना नहीं है, बल्कि पहले "परिमाण की भावना" स्थापित करना है।)

यदि आप स्वयं पुनर्गणना करना चाहते हैं, तो यहां एक सामान्य सूत्र है (कैश/छूट जैसे विशेष नियमों को अनदेखा करते हुए): लागत ≈ (इनपुट टोकन / 1,000,000) × यूनिट मूल्य_इन + (आउटपुट टोकन / 1,000,000) × यूनिट मूल्य_आउट

यह बहुत ही सहज ज्ञान युक्त है। हम हमेशा सोचते हैं कि एआई सस्ता है, और ओपनएआई कीमतों को कम भी कर रहा है। लेकिन वास्तविक इंजीनियरिंग में, टोकन की खपत घातीय रूप से क्यों बढ़ रही है?

आज, मैं आपके लिए इस "टोकन ब्लैक होल" के पीछे के तर्क को गहराई से तोड़ूंगा, और हम नुकसान को कैसे रोक सकते हैं।

1. टोकन "घातीय रूप से" क्यों बढ़ रहे हैं?

कई भाइयों को टोकन के आकार का कोई अंदाजा नहीं है। वे सोचते हैं: "अरे, क्या यह सिर्फ कुछ पंक्तियों का कोड नहीं है? इसमें कितना हो सकता है?"

1. एक स्पष्ट खाता बनाएं

हमें पहले इंजीनियरिंग उपयोग के लिए पर्याप्त मात्रात्मक धारणा स्थापित करनी चाहिए। आइए इसे थोड़ा और निश्चित रूप से कहें: टोकन न तो शब्दों की संख्या है और न ही वर्णों की संख्या। यह मॉडल द्वारा पाठ को विभाजित करने के बाद "एन्कोडिंग स्निपेट" है। विभिन्न मॉडल विभिन्न टोकनइज़र का उपयोग करते हैं, इसलिए हम केवल श्रेणी दे सकते हैं, न कि एक स्थिर जो "सभी के लिए उपयुक्त" हो।

नीचे दी गई संख्याओं को केवल "अनुमानित शासक" के रूप में मानें (उद्देश्य परिमाण का न्याय करना, लागत का अनुमान लगाना और नुकसान को रोकने के लिए निर्णय लेना है):

• 1 चीनी वर्ण: आमतौर पर 1-2 टोकन (उच्च-आवृत्ति वाले वर्ण 1 के करीब होते हैं, और दुर्लभ वर्ण/संयोजन 2-3 तक पहुंचना आसान होता है)

• 1 अंग्रेजी शब्द: आमतौर पर लगभग 1.2-1.5 टोकन (मोटे अनुमान के लिए 1.3 का उपयोग करना भी ठीक है)

• 1 पंक्ति का कोड ≈ 10-50 टोकन (इंडेंटेशन, टिप्पणियों और प्रकार घोषणाओं सहित)

• संक्षिप्त व्यावसायिक तर्क ≈ 12-20 टोकन

• प्रकार एनोटेशन, इंटरफ़ेस, जेएसडॉक, 4-स्पेस इंडेंटेशन के साथ ≈ 20-35 टोकन

• बड़ी संख्या में आयात / डेकोरेटर / टिप्पणियों के साथ ≈ 30-50+ टोकन

• 1 स्रोत फ़ाइल (400-600 लाइनें, आधुनिक टीएस/जावा परियोजनाएं) ≈ 4,000-24,000 टोकन बहुत आम है (मध्यिका ≈ 12,000-18,000)

• 1 मध्यम आकार की परियोजना (100-200 स्रोत फ़ाइलें, केवल src/ की गणना करें, जिसमें node_modules/ / जेनरेटेड कोड शामिल नहीं है)

• मुख्य स्रोत कोड को "पढ़ना" अक्सर लाखों टोकन से शुरू होता है

• यदि आप परीक्षण, कॉन्फ़िगरेशन, स्क्रिप्ट, निर्भरता घोषणाओं और लॉग को एक साथ जोड़ते हैं, तो दसियों लाख टोकन असामान्य नहीं हैं

आजकल फ्रंट-एंड प्रोजेक्ट्स सभी टाइपस्क्रिप्ट हैं, जो जटिल इंटरफ़ेस परिभाषाओं से भरे हुए हैं; या जावा, जो अक्सर दर्जनों पंक्तियों के आयात के साथ होता है। ये "बॉयलरप्लेट कोड" वास्तव में टोकन हत्यारे हैं। एक मध्यम आकार की परियोजना, यदि इसमें 100 फाइलें हैं, तो एआई को "कोड पढ़ने" देने से सीधे 1 मिलियन टोकन नष्ट हो सकते हैं।

2. टोकन का "स्नोबॉल" प्रभाव

टोकन की खपत का सबसे भयानक हिस्सा एकल बातचीत नहीं है, बल्कि कई दौर की बातचीत में संदर्भ का संचय है।

एलएलएम का तंत्र स्टेटलेस है। एआई को यह याद रखने के लिए कि आपने पिछली बार क्या कहा था, सिस्टम आमतौर पर "सिस्टम प्रॉम्प्ट + ऐतिहासिक बातचीत + आपके द्वारा संदर्भित फ़ाइलें/कोड स्निपेट + टूल कॉल आउटपुट (जैसे खोज परिणाम, त्रुटि लॉग)" को एक साथ पैक करके मॉडल को भेजता है। आपको लगता है कि आपने केवल एक प्रश्न पूछा है, लेकिन वास्तव में आप बार-बार "संपूर्ण संदर्भ पैकेज" के लिए भुगतान कर रहे हैं।

• पहला दौर: 10,000 टोकन भेजें, एआई 1,000 का उत्तर देता है।

• दूसरा दौर: (10,000 + 1,000 + नया प्रश्न) भेजें, एआई उत्तर देता है...

• 10वां दौर: आपका संदर्भ 200,000 टोकन तक बढ़ गया होगा।

इस समय, भले ही आप केवल "चर का नाम बदलने में मेरी सहायता करें" पूछते हैं, फिर भी आपको 200,000 टोकन की लागत आएगी। यही कारण है कि आपको लगता है कि आपने कुछ नहीं किया, लेकिन बिल बढ़ रहा है।

इससे भी बदतर: एजेंट मोड "सक्रिय रूप से फाइलें पढ़ता है"। आप कहते हैं "उपयोगकर्ता मॉड्यूल को अनुकूलित करने में मेरी सहायता करें", यह पहले संबंधित निर्देशिका को स्कैन कर सकता है, फिर निर्भरता का पता लगा सकता है, फिर कॉन्फ़िगरेशन का पता लगा सकता है, फिर परीक्षण का पता लगा सकता है... यह आलसी नहीं है, यह "डिफ़ॉल्ट रणनीति के अनुसार कर्तव्यनिष्ठ" है, और डिफ़ॉल्ट रणनीति अक्सर होती है: अधिक पढ़ें, अधिक प्रयास करें, अधिक दोहराएं।

2. दो प्रकार की "आलस्य" आपकी इंजीनियरिंग क्षमताओं को नष्ट कर रही हैं

टिप्पणी अनुभाग में उन "एक सौ मिलियन भाइयों" की समीक्षा करने के बाद, मुझे पता चला कि टोकन में वृद्धि का मूल कारण न केवल एआई की खपत तंत्र की समस्या है, बल्कि लोगों की आलस्य से भी निकटता से संबंधित है।

नीचे दो प्रकार की विशिष्ट "मानसिक आलस्य" हैं।

आलस्य एक: हाथ से बंद प्रकार

क्या आपके पास भी यह मानसिकता है:

• "यह पुरानी परियोजना बहुत गड़बड़ है, मैं तर्क को देखने की जहमत नहीं उठाता, बस इसे एआई को दे दो।"

• "कर्सर एजेंट मोड के साथ आया है, बहुत अच्छा, इसे स्वयं बग को ठीक करने दो।"

इसलिए, आप पूरे src फ़ोल्डर को एजेंट को सौंप देते हैं और एक अस्पष्ट निर्देश जारी करते हैं: "उपयोगकर्ता मॉड्यूल को अनुकूलित करने में मेरी सहायता करें।" एजेंट काम करना शुरू कर देता है:

• इसने 50 फाइलें पढ़ीं (500,000 की खपत)।

• इसने पाया कि utils का उल्लेख किया गया है, और टूल क्लास को पढ़ने चला गया (200,000 की खपत)।

• इसने संशोधित करने का प्रयास किया, एक त्रुटि हुई, और त्रुटि लॉग पढ़ा (100,000 की खपत)।

• इसने ठीक करने की कोशिश की, और फिर एक त्रुटि हुई...

यह बेतहाशा प्रयास कर रहा है, बेतहाशा टोकन की खपत कर रहा है। और आप? आप अपना फोन ब्राउज़ कर रहे हैं, यह सोचकर कि आप कितने कुशल हैं। सच्चाई यह है कि: आपने पैसे के बदले "छद्म दक्षता" खरीदी है, और बाद में बनाए रखने में असमर्थ कोड का एक गुच्छा तैयार किया है।

अधिक पेशेवर रूप से, यहां दो परतें हैं:

• लागत परत: इनपुट टोकन बड़ा हो जाता है, पुनरावृत्तियों की संख्या बढ़ जाती है, और लागत रैखिक रूप से जुड़ जाती है

• इंजीनियरिंग परत: आप संदर्भ और निर्णय लेने की शक्ति खो देते हैं, और अंत में केवल "यह चल सकता है" की अनियंत्रित प्रणाली बची है

आलस्य दो: सब कुछ एक साथ प्रकार

बग का सामना करते समय, आप इसे एआई को कैसे सौंपते हैं? क्या आप सीधे पूरे त्रुटि कंसोल को Ctrl+A कॉपी करते हैं, या एआई को स्वयं खोजने के लिए सीधे @Codebase करते हैं?

इसे "सब कुछ एक साथ" कहा जाता है। आप समस्या के मूल का पता लगाने की जहमत नहीं उठाते, और आप महत्वपूर्ण कोड स्निपेट को फ़िल्टर करने की जहमत नहीं उठाते। आप 99% बेकार जानकारी (शोर) और 1% उपयोगी जानकारी (संकेत) को एआई में एक साथ डाल देते हैं।

एआई एक एम्पलीफायर की तरह है।

• आप उसे स्पष्ट तर्क (संकेत) देते हैं, यह आपकी बुद्धि को बढ़ाता है, कम टोकन का उपयोग किया जाता है, और प्रभाव अच्छा होता है।

• आप उसे भ्रम और अस्पष्टता देते हैं, यह आपके भ्रम को बढ़ाता है, टोकन बेतहाशा बढ़ते हैं, और कचरा उत्पन्न होता है।

3. समाधान: एआई का कुशलतापूर्वक उपयोग कैसे करें और टोकन की खपत को कैसे कम करें

अपने बटुए की रक्षा के लिए, सबसे महत्वपूर्ण बात यह है कि अपनी इंजीनियरिंग नियंत्रण की रक्षा करें, हमें एआई के साथ अपने सहयोग के तरीके को बदलना होगा।

1. न्यूनतम संदर्भ सिद्धांत

यह एआई प्रोग्रामिंग का पहला सिद्धांत है। हमेशा एआई को केवल वर्तमान समस्या को हल करने के लिए संबंधित न्यूनतम कोड सेट दें।

कर्सर में, इन ऑपरेटरों का अच्छा उपयोग करें:

• @File: पूरे फ़ोल्डर के बजाय केवल संबंधित फ़ाइलों को संदर्भित करें।

• Ctrl+L कोड का चयन करें: पूरी फ़ाइल के बजाय चैट को केवल कर्सर द्वारा चयनित 50 पंक्तियों का कोड भेजें।

• @Docs: तृतीय-पक्ष पुस्तकालयों के लिए, अनुमान लगाने के बजाय दस्तावेज़ों को संदर्भित करें।

यह एक संरचित, पुन: प्रयोज्य एसओपी है जिसका मैं अक्सर उपयोग करता हूं (यदि आप इसका पालन करते हैं, तो टोकन स्पष्ट रूप से गिर जाएगा):

इस वाक्य का अर्थ है: एआई के साथ सहयोग करते समय, दक्षता और सटीकता पर ध्यान दें। विशिष्ट अभ्यास इस प्रकार हैं:

• पहले लक्ष्य को स्पष्ट करें: एआई को वर्तमान समस्या और वांछित परिणाम को संक्षेप में बताएं, इसे अनुमान लगाने न दें।

• समस्या प्रजनन को सरल बनाएं: यदि आप सबसे सरल विधि से समस्या को पुन: उत्पन्न कर सकते हैं, तो जटिल विधि का उपयोग न करें, सबसे कम और महत्वपूर्ण कोड पेस्ट करें, और बड़ी मात्रा में अप्रासंगिक सामग्री ढेर न करें।

• न्यूनतम आवश्यक जानकारी प्रदान करें: केवल 1-3 संबंधित फाइलें, महत्वपूर्ण फ़ंक्शन और त्रुटि स्टैक की पहली कुछ पंक्तियाँ दें, पूरी जानकारी नहीं।

• संशोधन बिंदु वापस करने के लिए कहें: एआई को केवल यह बताने दें कि कहां बदलना है और क्यों बदलना है, इसे पूरी बात को फिर से लिखने न दें।

• अंत में, स्वयं जांच करें: सबसे संक्षिप्त सत्यापन करें ताकि यह सुनिश्चित हो सके कि परिवर्तन से अन्य स्थानों पर कोई प्रभाव नहीं पड़ता है।

संक्षेप में, एआई को कम से कम और सबसे महत्वपूर्ण जानकारी के साथ काम करने दें, और अंतिम नियंत्रण और निर्णय लेने की शक्ति बनाए रखें।

2. सबसे महत्वपूर्ण बात यह भी है: पहले सोचें, फिर प्रॉम्प्ट करें, पहले योजना बनाएं, फिर कार्य करें

एंटर दबाने से पहले, खुद को 10 सेकंड के लिए रुकने के लिए मजबूर करें और खुद से तीन प्रश्न पूछें:

• मैं किस समस्या का समाधान कर रहा हूं? (सीमाओं को परिभाषित करें)

• इस समस्या में कौन से मुख्य मॉड्यूल शामिल हैं? (संदर्भ को फ़िल्टर करें)

• यदि मैं इसे स्वयं लिखता, तो मैं इसे कैसे लिखता? (विचार प्रदान करें)

आप 1 हैं, और एआई बाद में 0 है। यदि 1 खड़ा नहीं हो सकता है, तो बाद में 0 की संख्या चाहे कितनी भी हो, यह केवल अर्थहीन खपत है।

कुछ दिल से बातें

"एक दिन में एक करोड़ टोकन" की कहानी शायद हर किसी के साथ न हो। लेकिन टोकन बर्बाद करने का व्यवहार लगभग हर उस प्रोग्रामर द्वारा अनुभव किया जाएगा जो एआई प्रोग्रामिंग का उपयोग करता है।

हालांकि एआई ने प्रोग्रामिंग को आसान बना दिया है, लेकिन अभी भी एक सीमा है। जो लोग वास्तव में इसका उपयोग करना जानते हैं, वे पंखों पर पंख जोड़ेंगे।

पहले, आपके द्वारा लिखा गया खराब कोड केवल सहकर्मियों को "घृणित" करेगा। अब, आपकी आलस्य सीधे बिल पर एक संख्या बन जाएगी, जो बढ़ती लागत के साथ खुद को दंडित करेगी।इसलिए, 'हाथ झाड़ने वाले मालिक' न बनें। एक गहन चिंतन, सटीक अभिव्यक्ति, योजना बनाकर कार्रवाई करने वाला AI आर्किटेक्ट बनें। यही इस युग में हमारी सबसे बड़ी अपरिहार्यता भी है।