लेखक: Systematic Long Short
संपादित: शेनचाओ टेकफ्लो
शन डायरेक्शन: इस लेख का मुख्य तर्क केवल एक वाक्य है: AI एजेंट के आउटपुट की गुणवत्ता आपके द्वारा निवेश किए गए टोकन की संख्या के समानुपाती होती है।
लेखक केवल सामान्य सिद्धांतों की बात नहीं कर रहा है, बल्कि दो व्यावहारिक विधियाँ प्रस्तुत कर रहा है जिन्हें आज से ही शुरू किया जा सकता है, और 'नवीनता समस्या' के माध्यम से टोकन को नहीं बनाया जा सकता इस सीमा को स्पष्ट रूप से परिभाषित किया है।
एजेंट का उपयोग करके कोड लिख रहे या वर्कफ्लो चला रहे पाठकों के लिए, जानकारी का घनत्व और कार्यात्मकता दोनों बहुत अधिक हैं।
परिचय
ठीक है, आपको स्वीकार करना होगा कि यह शीर्षक वास्तव में ध्यान आकर्षित करता है—लेकिन सच बताऊं, यह मजाक नहीं है।
2023 में, जब हम LLM का उपयोग उत्पादन कोड चलाने के लिए कर रहे थे, तो हमारे आसपास के सभी लोग हैरान रह गए, क्योंकि उस समय सामान्य धारणा यह थी कि LLM केवल अक्षम कचरा ही उत्पन्न कर सकते हैं। लेकिन हमें एक ऐसी बात पता थी जो दूसरों को नहीं पता थी: एजेंट की आउटपुट गुणवत्ता, आपके द्वारा निवेश किए गए Token की संख्या का फलन है। बस इतना ही।
आप खुद कुछ प्रयोग करके इसे देख सकते हैं। एजेंट को एक जटिल, थोड़ा अज्ञात प्रोग्रामिंग कार्य पूरा करने के लिए दें—जैसे कि एक प्रतिबंधित कॉन्वेक्स ऑप्टिमाइजेशन एल्गोरिथम को शून्य से लागू करना। सबसे कम सोच स्तर के साथ शुरू करें; फिर सबसे उच्च सोच स्तर पर स्विच करें, और इसे अपने कोड की समीक्षा करने के लिए कहें कि वह कितने बग्स खोज सकता है। मध्यम और उच्च स्तर दोनों का परीक्षण करें। आप स्पष्ट रूप से देख पाएंगे: बग्स की संख्या Token की मात्रा के साथ निरंतर घटती है।
यह समझना आसान है, है ना?
जितने अधिक टोकन = उतनी कम त्रुटियाँ। आप इस तर्क को आगे बढ़ा सकते हैं, जो मूल रूप से कोड रिव्यू उत्पाद के पीछे (सरलीकृत) केंद्रीय विचार है। एक पूरी तरह से नए संदर्भ में, भारी मात्रा में टोकन का उपयोग करें (उदाहरण के लिए, इसे कोड को पंक्ति दर पंक्ति विश्लेषण करने दें और प्रत्येक पंक्ति में बग है या नहीं, यह निर्धारित करें) — इससे लगभग सभी, यहाँ तक कि सभी बग्स को पकड़ा जा सकता है। इस प्रक्रिया को दस बार, सौ बार दोहराया जा सकता है, प्रत्येक बार कोडबेस को 'अलग-अलग कोण' से देखते हुए, और आप अंततः सभी बग्स को निकाल सकते हैं।
"अधिक टोकन जलाने से एजेंट की गुणवत्ता में सुधार होता है" इस विचार का एक प्रमाणित समर्थन भी है: जो टीमें दावा करती हैं कि वे एजेंट का उपयोग करके पूरी तरह से कोड लिखकर उसे उत्पादन में ला सकती हैं, वे या तो बेस मॉडल प्रदाता हैं, या फिर अत्यधिक धन से सुसज्जित कंपनियाँ हैं।
तो, अगर आप अभी भी एजेंट के उत्पादन-स्तरीय कोड न निकालने की समस्या से परेशान हैं—सीधे बोलूं तो, समस्या आपके साथ है। या फिर, आपके वॉलेट के साथ।
कैसे पता करें कि मैंने पर्याप्त टोकन जला दिए हैं?
मैंने एक पूरा लेख लिखा था कि समस्या आपके द्वारा बनाए गए फ्रेमवर्क (harness) में नहीं है, "सरल रखें" से भी उत्कृष्ट चीजें बनाई जा सकती हैं, मैं अभी भी इस दृष्टिकोण पर टिका हूँ। आपने वह लेख पढ़ा, उसके अनुसार किया, लेकिन फिर भी एजेंट के आउटपुट से निराश हो गए। आपने मुझे DM किया, मैंने पढ़ लिया, लेकिन जवाब नहीं दिया।
This is the reply.
आपका एजेंट कमजोर प्रदर्शन करता है और समस्याओं को हल नहीं कर पाता, ज्यादातर मामलों में इसका कारण आपके द्वारा जलाए गए टोकन की कमी है।
किसी समस्या को हल करने के लिए कितने टोकन की आवश्यकता होगी, यह पूरी तरह से उस समस्या के आकार, जटिलता और नवीनता पर निर्भर करता है।
"2+2 कितना होता है?" इसके लिए कोई अधिक Token की आवश्यकता नहीं है।
"मुझे एक बॉट लिखने में मदद करें, जो Polymarket और Kalshi के बीच सभी बाजारों को स्कैन करे, जिनमें अर्थगत रूप से समान बाजार हों जो एक ही घटना के आसपास सेटल होने चाहिए, बिना आर्बिट्रेज की सीमाएँ निर्धारित करे, और जब कोई आर्बिट्रेज अवसर आए तो निम्न लेटेंसी के साथ स्वचालित रूप से ट्रेड करे" — इसके लिए काफी सारे Token जलाने पड़ेंगे।
हमने अभ्यास में एक दिलचस्प बात पाई।
अगर आप पैमाने और जटिलता के कारण उत्पन्न समस्याओं को हल करने के लिए पर्याप्त टोकन लगाते हैं, तो एजेंट किसी भी तरह से समस्या को हल कर देगा। दूसरे शब्दों में, अगर आप एक अत्यधिक जटिल, बहुत सारे घटकों और कोड की पंक्तियों वाली चीज़ बनाना चाहते हैं, तो जब तक आप इन समस्याओं में पर्याप्त टोकन डालते रहेंगे, वे अंततः पूरी तरह से हल हो जाएंगी।
यहाँ एक छोटा लेकिन महत्वपूर्ण अपवाद है।
आपका प्रश्न बहुत नवीन नहीं हो सकता। वर्तमान चरण में, कितने भी टोकन हों, वे "नवीनता" समस्या को हल नहीं कर सकते। पर्याप्त मात्रा में टोकन जटिलता के कारण होने वाली त्रुटियों को शून्य तक कम कर सकते हैं, लेकिन एजेंट को वह कुछ भी आविष्कार करने में सक्षम नहीं बना सकते जो उसे पता नहीं है।
यह निष्कर्ष वास्तव में हमें आराम देता है।
हमने बहुत अधिक प्रयास किया, और बहुत, बहुत, बहुत अधिक टोकन जलाए, ताकि हम यह जांच सकें कि क्या एजेंट बिना किसी मार्गदर्शन के संस्थागत निवेश प्रक्रिया को पुनः बना सकता है। इसका एक कारण यह भी था कि हम जानना चाहते थे कि हम (मात्रात्मक शोधकर्ता) AI द्वारा पूरी तरह से प्रतिस्थापित होने से कितने वर्ष दूर हैं। परिणाम यह पाया गया कि एजेंट संस्थागत निवेश प्रक्रिया के करीब भी नहीं पहुंच सकता। हमारा मानना है कि इसका कारण यह है कि उन्होंने कभी ऐसा कुछ नहीं देखा है—अर्थात, संस्थागत निवेश प्रक्रिया प्रशिक्षण डेटा में मौजूद नहीं है।
इसलिए, अगर आपका प्रश्न नया है, तो टोकन जमा करके इसे हल करने की उम्मीद मत करें। आपको खुद अन्वेषण प्रक्रिया का नेतृत्व करना होगा। लेकिन जब आप कार्यान्वयन योजना तय कर लें, तो आप निश्चिंत होकर टोकन जमा कर सकते हैं—चाहे कोडबेस कितना भी बड़ा हो या कंपोनेंट कितने भी जटिल हों, कोई समस्या नहीं है।
एक सरल हेयुरिस्टिक सिद्धांत है: टोकन बजट को कोड की पंक्तियों के साथ अनुपातिक रूप से बढ़ाया जाना चाहिए।
बहुत सारे टोकन का जलाना वास्तव में क्या कर रहा है
व्यवहार में, अतिरिक्त टोकन आमतौर पर निम्नलिखित तरीकों से एजेंट की इंजीनियरिंग गुणवत्ता में सुधार करते हैं:
एक ही प्रयास में अधिक समय तक तर्क करें, ताकि वह स्वयं तर्क की गलतियों को खोजने का अवसर पाए। जितना गहरा तर्क, उतना बेहतर योजना बनाना = एक ही प्रयास में सफलता की संभावना अधिक।
इसे कई स्वतंत्र प्रयास करने दें, अलग-अलग समाधान रास्ते अपनाएं। कुछ रास्ते दूसरों की तुलना में बेहतर होते हैं। इसे एक से अधिक बार प्रयास करने दें, ताकि यह सर्वोत्तम विकल्प चुन सके।
इसी तरह, अधिक स्वतंत्र योजनाएँ इसे कमजोर दिशाओं को छोड़ने और सबसे आशाजनक दिशाओं को बनाए रखने की अनुमति देती हैं।
अधिक टोकन इसे अपने पिछले कार्य को एक नए संदर्भ में समीक्षा करने और उसे सुधारने का अवसर देते हैं, बजाय इसके कि यह किसी एक «तर्क की आदत» में फंस जाए।
और मुझे सबसे अच्छा लगता है: अधिक टोकन का मतलब है कि इसे टेस्टिंग और टूल्स के साथ सत्यापित किया जा सकता है। कोड को वास्तविक रूप से चलाकर देखना कि यह काम करता है या नहीं, उत्तर की सही पुष्टि करने का सबसे विश्वसनीय तरीका है।
यह तर्क काम करता है क्योंकि एजेंट की इंजीनियरिंग विफलता यादृच्छिक नहीं होती। यह लगभग हमेशा शुरुआत में गलत मार्ग चुनने, इस मार्ग की वास्तविकता की जांच न करने, या त्रुटि पाने के बाद पुनर्स्थापित और पीछे हटने के लिए पर्याप्त बजट न होने के कारण होती है।
कहानी यही है। टोकन शब्दशः आपके द्वारा खरीदे गए निर्णय की गुणवत्ता है। इसे अनुसंधान के कार्य के रूप में कल्पना करें: यदि आप किसी व्यक्ति को तुरंत एक कठिन प्रश्न का उत्तर देने के लिए कहते हैं, तो समय के दबाव के साथ उत्तर की गुणवत्ता घटती जाती है।
अध्ययन, अंततः, "उत्तर जानना" इस मूल बात को जन्म देता है। मानव बायोलॉजिकल समय खर्च करते हैं ताकि बेहतर उत्तर प्राप्त कर सकें, जबकि एजेंट बेहतर उत्तर प्राप्त करने के लिए अधिक कैलकुलेशन समय खर्च करते हैं।
आप अपने एजेंट को कैसे बेहतर बनाएं
आप शायद अभी भी संदेह में हों, लेकिन इस बात का समर्थन कई पेपर्स करते हैं, और ईमानदारी से कहूं तो, "रीजनिंग" रेगुलेटर के मौजूद होने का ही आपको जो भी सबूत चाहिए, वही है।
मुझे एक अत्यंत पसंदीदा पेपर है, जिसमें शोधकर्ताओं ने एक छोटे से सावधानी से चयनित तर्क नमूनों के सेट के साथ प्रशिक्षण किया, और फिर एक तरीके से मॉडल को रुकने के बजाय सोचना जारी रखने के लिए मजबूर किया—विशेष रूप से, जब यह रुकना चाहता है, तो उसके बाद "Wait" (इंतजार करें) जोड़ दिया जाता है। केवल इसी के कारण, किसी बेंचमार्क में 50% से बढ़कर 57% हो गया।
मैं सीधे बात करूँगा: अगर आप हमेशा एजेंट द्वारा लिखे गए कोड की शिकायत कर रहे हैं, तो एकल अधिकतम विचार स्तर शायद आपके लिए अभी भी पर्याप्त नहीं है।
मैं आपको दो बहुत सरल समाधान देता हूँ।
सरल उपाय 1: WAIT (इंतजार करें)
आज ही आप जो सबसे सरल काम कर सकते हैं: एक स्वचालित चक्र बनाएं—इसे बनाने के बाद, एजेंट को नए संदर्भ के साथ N बार समीक्षा करने दें, और हर बार जब कोई समस्या मिले, तो उसे ठीक कर दें।
अगर आपको लगता है कि यह सरल ट्रिक ने आपके Agent इंजीनियरिंग परिणामों में सुधार किया है, तो आपने कम से कम समझ लिया है कि आपकी समस्या केवल टोकन की संख्या की है—तो आइए टोकन जलाने के क्लब में शामिल हों।
सरल विकल्प 2: VERIFY (प्रमाणीकरण)
Agent को अपना काम जल्दी और बार-बार सत्यापित करने दें। यह साबित करने के लिए टेस्ट लिखें कि चुनी गई पथ वास्तव में काम करती है। यह अत्यधिक जटिल और गहराई से नेस्टेड प्रोजेक्ट्स के लिए विशेष रूप से उपयोगी है—एक फंक्शन को नीचे कई अन्य फंक्शन्स द्वारा कॉल किया जा सकता है। अगर आप ऊपरी स्तर पर त्रुटियों को पकड़ लें, तो आपको बाद के कई कैलकुलेशन समय (Token) बच सकते हैं। इसलिए, जहां संभव हो, पूरी बिल्ड प्रक्रिया में “वेरिफिकेशन चेकपॉइंट्स” सेट करें।
कुछ लिखने के बाद, मुख्य एजेंट कहता है कि पूरा हो गया? दूसरे एजेंट को एक बार फिर जांचने के लिए भेजें। असंबंधित विचार प्रवाह प्रणालीगत पूर्वाग्रह के स्रोत को कवर कर सकते हैं।
इतना ही है। मैं इस विषय पर और भी बहुत कुछ लिख सकता हूँ, लेकिन मुझे लगता है कि अगर आप इन दो बातों को समझें और उन्हें अच्छी तरह से लागू करें, तो यह आपकी 95% समस्याओं का समाधान कर देगा। मैं यकीन करता हूँ कि सरल चीजों को बेहतरीन तरीके से करना है, और फिर आवश्यकता के अनुसार जटिलता जोड़नी है।
मैंने उल्लेख किया था कि "नवीनता" एक ऐसी समस्या है जिसे टोकन से हल नहीं किया जा सकता, मैं इसे फिर से जोर देकर कहना चाहता हूँ, क्योंकि आप अंततः इस फंदे में फंसेंगे और मुझसे शिकायत करेंगे कि टोकन जमा करने से कोई फायदा नहीं हुआ।
जब आपको हल करने के लिए ट्रेनिंग सेट में नहीं मिलने वाली समस्या का सामना करना पड़ता है, तो आप ही वह व्यक्ति हैं जिसे वास्तव में हल प्रदान करना होता है। इसलिए, क्षेत्रीय विशेषज्ञता अभी भी अत्यंत महत्वपूर्ण है।