क्यों अधिक AI एजेंट हमेशा अधिक उत्पादकता का अर्थ नहीं होते

icon MarsBit
साझा करें
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconसारांश

expand icon
अल्टकॉइन जिन पर ध्यान देना चाहिए, वे ध्यान आकर्षित कर रहे हैं, क्योंकि डेवलपर्स AI एजेंट्स के प्रबंधन की छिपी हुई लागतों से निपट रहे हैं। डिप्लॉयमेंट की सुविधा में वृद्धि से ध्यान मानवीय आउटपुट के सर्वोत्तम प्रबंधन पर स्थानांतरित हो गया है। 'ऑर्केस्ट्रेशन टैक्स' में परिणामों की पुष्टि करना और संघर्षों का समाधान करना शामिल है—ऐसे कार्य जिन्हें समानांतर रूप से नहीं किया जा सकता। जैसे-जैसे अधिक एजेंट्स चलते हैं, समीक्षा की कतारें बढ़ती हैं, जिससे थकान और ऋण बढ़ता है। भय और लालच सूचकांक में परिवर्तन इन बॉटलनेक्स को प्रतिबिंबित कर सकते हैं। उत्पादकता में वृद्धि अधिक एजेंट्स से नहीं, बल्कि मानवीय ध्यान सीमाओं के साथ मेल खाने वाले प्रवाहों से होती है।

संपादकीय टिप्पणी: जब AI एजेंट लगातार सस्ते और आसानी से उपलब्ध होते जा रहे हैं, तो सॉफ्टवेयर विकास एक नए चरण में प्रवेश कर रहा है: सवाल अब यह नहीं है कि हम कितने अधिक एजेंट्स शुरू कर सकते हैं, बल्कि यह है कि मानव के पास उनके उत्पादन को प्रबंधित, निर्णय लेने और एकीकृत करने के लिए पर्याप्त ध्यान है या नहीं।

यह लेख एक बहुत ही प्रेरक अवधारणा प्रस्तुत करता है — “ऑर्केस्ट्रेशन टैक्स”। एजेंट को शुरू करने की लागत बहुत कम होती है, बस एक प्रॉम्प्ट या एक क्लिक की आवश्यकता होती है; लेकिन वास्तविक रूप से महंगा होता है अगले चरण: परिणामों की जाँच करना कि वे सही हैं, इसके सिस्टम आर्किटेक्चर पर प्रभाव को समझना, विभिन्न एजेंट्स के बीच संघर्षों को सुलझाना, और अंततः यह निर्णय लेना कि कौन सा कोड मुख्य शाखा में शामिल हो सकता है। ये कार्य सरलता से समानांतरीकृत नहीं किए जा सकते, और इन्हें फिर से एक ही क्रमिक संसाधन पर लौटना पड़ता है: मानवीय निर्णय क्षमता।

लेखक विकासकों की तुलना AI एजेंट सिस्टम में 'GIL' से करता है, जो एकल-थ्रेडेड लॉक है जो समानांतर सिस्टम की अंतिम थ्रूपुट को सीमित करता है। कई एजेंट एक साथ चल सकते हैं, लेकिन जब तक आर्किटेक्चर निर्णय, कोड रिव्यू और संघर्ष समायोजन के चरणों में प्रवेश नहीं करते, तब तक वे विकासक के मस्तिष्क से होकर ही गुजरने के लिए बाध्य होते हैं। इस प्रकार, एजेंट अधिक होने से आउटपुट आवश्यक रूप से अधिक नहीं होता, बल्कि यह केवल समीक्षा के लिए प्रतीक्षारत कार्यों की सूची को लंबा कर सकता है, और विकासकों को अधिक बार संदर्भ परिवर्तन और संज्ञानात्मक थकान में फंसा सकता है।

यह वर्तमान एआई प्रोग्रामिंग उपकरणों की लहर में एक ऐसा पहलू है जिसे अक्सर नज़रअंदाज़ किया जाता है: कार्यक्षमता का अहसास और वास्तविक उत्पादकता हमेशा एक ही बात नहीं होती। स्क्रीन भर में चल रहे एजेंट डैशबोर्ड से 'उत्पादक' होने का गलत अहसास पैदा होता है; लेकिन अगर डेवलपर्स इन परिवर्तनों को वास्तव में समझते, समीक्षा नहीं करते और एकीकृत नहीं करते, तो प्रणाली में अंततः उत्पादकता के बजाय तकनीकी कर्ज़ और संज्ञानात्मक कर्ज़ जमा हो सकता है।

इसलिए, इस लेख की वास्तविक चर्चा नहीं है कि “कैसे अधिक एजेंट का उपयोग करें”, बल्कि यह है कि “मानव ध्यान के चारों ओर कार्य प्रवाह को पुनः डिज़ाइन कैसे करें।” एजेंट युग में, महत्वपूर्ण क्षमता केवल प्रश्न पूछना या कार्य सौंपना नहीं है, बल्कि यह जानना है कि कौन से कार्य मशीनों को समानांतर संसाधित करने के लिए सौंपे जा सकते हैं और कौन से कार्य मानवीय निर्णय के लिए बने रहने चाहिए; कब बैच समीक्षा करनी चाहिए और कब संगठन बंद करके एक केंद्रीय समस्या पर पुनः केंद्रित होना चाहिए।

AI अब सॉफ्टवेयर उत्पादन की समानांतर क्षमता को बढ़ा रहा है, लेकिन मानव ध्यान अभी भी प्रणाली में सबसे दुर्लभ और अनुलिप्य संसाधन है। वास्तविक रूप से परिपक्व Agent वर्कफ्लो, सभी कार्यों को मशीन को सौंपने की बजाय, अपने ध्यान व्यवस्था को उत्पादन प्रणाली की तरह सावधानी से डिज़ाइन करना है।

निम्नलिखित मूल पाठ है:

अब, अधिक AI एजेंट शुरू करना आसान हो गया है। लेकिन अधिक एजेंट एक साथ चलने का मतलब यह नहीं है कि «आप» भी बढ़ गए हैं। आपकी ज्ञानात्मक बैंडविड्थ को समानांतर नहीं किया जा सकता। उन्हें निर्देशित करने, परिणामों का आकलन करने और संयोजित/संशोधित करने के लिए आवश्यक सभी वास्तविक निर्णय, अंततः एक ही क्रमिक प्रोसेसर से होकर ही गुजरते हैं—जो कि आप स्वयं हैं।

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

मैंने पहले Google I/O पर एक समूह चर्चा में भाग लिया था, जहाँ मैंने रिचर्ड सेरोटर, अजा हैमरली और सिएरा जास्पन के साथ सॉफ्टवेयर इंजीनियरिंग की वर्तमान स्थिति और इसके भविष्य के विकास के बारे में बात की। चर्चा के अंत के करीब, रिचर्ड ने हमसे पूछा: डेवलपर्स को इसके बाद क्या सबसे महत्वपूर्ण बात लेकर जानी चाहिए और बदलनी चाहिए?

Attention Architecture

मैंने इन कुछ महीनों से बार-बार सोची गई बात कह दी: व्यस्त महसूस करना, वास्तविक उत्पादन के बराबर नहीं है। आप एक साथ 20 एजेंट चला सकते हैं और खुद को बहुत व्यस्त महसूस कर सकते हैं। लेकिन इसका मतलब यह नहीं है कि आपने 20 एजेंट्स के संगत कार्य की मात्रा पूरी कर दी है।

उस बातचीत के शुरूआती हिस्से में, रिचर्ड ने इस समस्या का एक नाम दिया। उन्होंने कहा: "आप जो अभी बता रहे हैं, वह वास्तव में टैक्स ऑर्केस्ट्रेशन है। आप अपने मन में 20 एजेंट्स को सफलतापूर्वक प्रबंधित नहीं कर सकते।"

वह पूरी तरह सही है। मैं इस अवधारणा को अधिक पूर्णतः विभाजित करना चाहता हूँ, क्योंकि यह एक स्व-नियंत्रण की समस्या नहीं है, बल्कि एक आर्किटेक्चरल समस्या है।

उस गोल मेज बैठक में एक बात थी जो मैंने लगभग बेमतलब कह दी, जो मेरे मन में लगातार गूंजती रही: कई एजेंट चलाने का मतलब यह नहीं है कि दुनिया में आपका एक और संस्करण बन गया।

लोगों द्वारा शामिल नहीं किए गए असममिति

एजेंट वर्कफ्लो में एक छिपी हुई असममिति मौजूद है।

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

यह व्यक्ति आप हैं। और आप केवल एक हैं।

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

जब आप एजेंट विकास को एक समानांतर प्रणाली के रूप में देखना शुरू करते हैं, तो आप जान जाते हैं कि मानव इस प्रणाली का केवल एक घटक हैं। एक बहुत धीमा, अनुक्रमिक घटक।

तुम वह एकल-थ्रेडेड संसाधन हो

अगर आपने कभी कंकरेंट कोड लिखा है, तो आपके पास इस समस्या को समझने की एक अंतर्ज्ञान है। केवल आपने इस अंतर्ज्ञान का पिछले समय में गलत जगह पर उपयोग किया है।

पायथन में ग्लोबल इंटरप्रेटर लॉक (GIL) होता है। आप कितने भी थ्रेड्स बना सकते हैं, लेकिन एक ही समय में केवल एक ही थ्रेड Python बाइटकोड निष्पादित कर सकता है, क्योंकि सभी को पहले इस लॉक को प्राप्त करना होता है।

तुम अपने AI एजेंट का GIL हो।

वे सभी एक साथ चल सकते हैं। लेकिन जब तक उनका कार्य प्रणाली आर्किटेक्चर को समझने की आवश्यकता रखता है या संयोजन द्वंद्व को हल करने की आवश्यकता होती है, तब तक इस ताला को प्राप्त करना आवश्यक है। और इस ताले की केवल एक ही कुंजी है, जो आपके पास है।

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

एजेंट डेवलपमेंट में, यह सीरियल भाग निर्णय लेने की क्षमता है।

8 एजेंट्स शुरू करने से आपके निर्णय समय को तेज नहीं किया जा सकता। यह केवल आपके द्वारा संसाधित करने के लिए प्रतीक्षा कर रही कतार को लंबा बना देगा।

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

एजेंट के अनुकूलन से उस भाग को बेहतर बनाया गया है जो मूल रूप से प्रतिबंध नहीं था। वास्तविक प्रतिबंध रिव्यू चरण है, और पूरे सिस्टम की संसाधन क्षमता ठीक इसी चरण की संसाधन क्षमता के बराबर है।

टैक्स ऑर्गनाइजेशन, जो एजेंट की उत्पादकता और आपके वास्तविक रूप से एकीकृत करने में सक्षम सामग्री के बीच एक संरचनात्मक अंतर है। यह तब होता है जब आप एक सिंगल-थ्रेडेड संसाधन को एक कंकरेंट सिस्टम को प्रबंधित करने के लिए अनुमति देते हैं।

हार्ड कॉपी से संरचनात्मक सीमा को हल नहीं किया जा सकता

उस गोल मेज पर, मैंने एक बात कही: मैंने कभी इतना महसूस नहीं किया कि मेरे उपकरण इतने कुशल हैं, लेकिन मैंने कभी इतना थका भी नहीं।

ये दोनों भावनाएँ पूरी तरह सच्ची हैं, और ये एक ही कारण से उत्पन्न होती हैं।

इस थकान का एक बहुत ही विशिष्ट स्रोत है: यह एक सीरियल प्रोसेसर को लगातार 100% पर लोड करने और कोई भी बफर न देने का अनुभव है।

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

CPU इस कार्य को माइक्रोसेकंड में पूरा कर सकता है, फिर भी आर्किटेक्ट इसे बार-बार स्विच करने से बचने की कोशिश करते हैं। जबकि आपको इसे पूरा करने में कुछ मिनट लगेंगे, और आप कभी भी कॉन्टेक्स्ट को पूरी तरह से वापस नहीं ला सकते।

5 एजेंट 1 बार के काम को 5 बार दोहराने के बराबर नहीं हैं। यह 5 बार का कूल स्टार्ट-आधारित कंटेक्स्ट रीलोड है, जिसमें एक बैकग्राउंड में लगातार चल रहा ब्रेन प्रोसेस शामिल है जो लगातार चिंतित रहता है कि अभी आपको किस एजेंट की जांच करनी चाहिए।

आप एक संरचनात्मक सीमा को "अधिक मेहनत" से हल नहीं कर सकते। यह कर हमेशा देय होगा।

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

आप इस कर का स्वयं भुगतान करें या इसे अंधेरे में धीरे-धीरे अपनी प्रणाली के प्रति आपकी समझ को नष्ट करने दें।

अपना ध्यान डिज़ाइन सिस्टम की तरह डिज़ाइन करें

इसलिए, आपको अपना ध्यान एक दुर्लभ, अनुक्रमिक संसाधन के रूप में मानना चाहिए।

आप एक वितरित प्रणाली डिज़ाइन करते समय बॉलनेक को पूरी तरह से नज़रअंदाज़ नहीं करते। इसी तरह, अपने मस्तिष्क को भी समान सम्मान दें।

नीचे कुछ ऐसे तरीके हैं जो मेरे लिए वास्तव में काम करते हैं:

रिव्यू क्षमता के आधार पर एजेंट टीम का विस्तार करें, यूआई क्षमता के आधार पर नहीं।

एक अच्छा समानांतर प्रणाली प्रतिपीड़न तंत्र का उपयोग करती है, जिससे कतार का असीमित वृद्धि रोका जा सके। उत्पादक को उपभोक्ता की संसाधन क्षमता के अनुसार अपनी गति कम करनी चाहिए।

आपके एजेंट की संख्या उत्पादक है, और आपकी समीक्षा क्षमता उपभोक्ता है। सही समानांतर एजेंट संख्या वह होनी चाहिए जितनी आप ध्यान से कोड समीक्षा कर सकते हैं। अधिकांश लोगों के लिए, यह आमतौर पर बहुत कम एकल अंकों की संख्या होती है।

AI टूल निश्चित रूप से आपको 20 एजेंट्स शुरू करने की अनुमति देगा, लेकिन यह केवल एक UI फ़ंक्शन है, जो आपकी उन्हें प्रबंधित करने की वास्तविक क्षमता को नहीं दर्शाता।

Task categorization.

जब रिचर्ड ने मुझसे पूछा कि मैं इस मामले को कैसे संभालूं, तो मैंने इस विधि का उल्लेख किया था। मैं कार्य को दो ढेर में बांट दूंगा।

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

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

सबसे बड़ी गलती यह है कि आप दूसरे प्रकार के कार्यों को भी समानांतर बनाने की कोशिश करते हैं। कई जटिल कार्यों को समानांतर रूप से प्रोसेस करने से आपका आउटपुट बढ़ता नहीं है, बल्कि वह लॉक बार-बार लड़ी जाती है, और अंततः सभी परिणाम खराब हो जाते हैं।

Bulk review.

हर संदर्भ स्विचिंग से आपको बहुत अधिक लागत उठानी पड़ती है। एक बार में 4 एजेंट के परिणामों की समीक्षा करना, एक को देखकर कुछ और करना और फिर दूसरे को देखने के लिए फिर से शुरू करने की तुलना में कहीं अधिक सस्ता होता है।

एजेंट को लंबी रस्सी दें। काम को थोड़ा जमा होने दें, फिर उन्हें एक बैच के रूप में संभालें।

Use this lock only for judgment.

अपने दिमाग को उन चीजों पर बर्बाद मत करो जिन्हें मशीन स्वयं सत्यापित कर सकती है। एजेंट को उन परीक्षणों को लिखने दें जो सफल हों, या स्क्रीनशॉट जेनरेट करें।

अपने आप से साबित करें कि वह 80% थकान वाला लेकिन सत्यापित करने योग्य हिस्सा है। इस तरह, आपका सीमित ध्यान केवल उस 20% पर लगेगा जिसके लिए मानवीय निर्णय की आवश्यकता होती है।

Protect your serial time.

बॉटलनेक को आपका सर्वश्रेष्ठ समय चाहिए, न कि एजेंट जांचों के बीच का टुकड़ा समय।

कभी-कभी, सबसे अधिक लीवरेज की कार्रवाई पूरी तरह से व्यवस्था बंद करना होती है: उस कंप्यूटर को बंद कर दें जिसमें एजेंट भरे हुए हैं, केवल एक प्रश्न पर ध्यान केंद्रित करें, और पूरी प्रक्रिया में उस ताले को मजबूती से पकड़े रहें।

संगठन वास्तविक काम नहीं है। यह केवल काम के चारों ओर उत्पन्न ओवरहेड है।

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

मैं एक और बात जोड़ना चाहता हूँ: आप भी इस प्रणाली का एक घटक हैं। आपका ध्यान एक ज्ञात, बहुत कम अनुक्रमिक थ्रूपुट रखता है। प्रणाली या तो इस संख्या का सम्मान करती है, या फिर इसे छिपाकर आपके मानकों को कम करके पार कर लेती है।

व्यस्तता का अर्थ उत्पादकता नहीं है

यह बहुत महत्वपूर्ण है, क्योंकि यह विफलता का पैटर्न आपके लिए लगभग अदृश्य है।

20 चल रहे एजेंट आपको एक “उत्पादकता का भारी बोझ” महसूस कराते हैं। डैशबोर्ड भरा हुआ है, सब कुछ चल रहा है। लेकिन यह महसूस करना और उच्च गुणवत्ता वाले कोड को मुख्य शाखा में मर्ज करना अब अलग-अलग हो चुका है।

आप अपनी सीमा तक व्यस्त हो सकते हैं, लेकिन वास्तविक उत्पादन लगभग शून्य हो सकता है। आंतरिक अनुभव के अनुसार, ये दोनों लगभग एक जैसे हैं।

Ciera ने मार्गरेट-एन ब्टोरी के ऋण पर शोध का उल्लेख किया। हमने तकनीकी ऋण और संज्ञानात्मक ऋण दोनों के बारे में बात की।

बिना भुगतान किए गए ऑर्डर टैक्स आपको दोनों ऋणों को एक साथ जमा करने देते हैं।

आपने ऐसी चीजों को मिलाया है जिन्हें आपने ध्यान से नहीं पढ़ा है। आपका कोडबेस के बारे में मानसिक मॉडल पूरी तरह से पुराना हो चुका है। ये समस्याएँ आज डैशबोर्ड पर नहीं दिखेंगी। वे उत्पादन पर खराबी के समय प्रकट होंगी—जब आप सिस्टम को देखते हैं और अचानक एहसास होता है कि आपको यह नहीं पता कि यह कैसे काम करता है।

तो, वास्तविक निष्कर्ष यह है: एजेंट शुरू करना क्षमता नहीं है। कोई भी 20 चला सकता है।

सच्ची क्षमता, उस अनकॉपी किए जा सकने वाले, अनपैरेललाइज़ किए जा सकने वाले सीरियल संसाधन के चारों ओर प्रणाली को डिज़ाइन करना है।

यह संसाधन, आपका ध्यान है।

इसे किसी भी उत्पादन वातावरण में निर्भरता वाले महत्वपूर्ण घटक की तरह डिज़ाइन करें।

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