एजंट्सना मुक्तपणे चालवण्याची लपलेली किंमत
AI कोडिंग एजंट्सनी एकल प्रश्नांची उत्तरे देणे थांबवून स्वतःहून काम करू लागल्यावर त्यांचे अर्थशास्त्र बदलते. एक-वेळचा अंदाज स्वस्त असतो. मात्र, दीर्घ, देखरेखीविना चालणारी फेरी स्वस्त नसते: विचार करण्याच्या पायऱ्या टूल कॉल्सवर रचल्या जातात, त्या फीडबॅक लूपवर रचल्या जातात, आणि प्रत्येक चक्रासोबत टोकनचे बिल वाढत जाते. Nvidia संशोधकांनी एका पेपरमध्ये अशा प्रणालीचे वर्णन केले आहे जी या बिलावर अनपेक्षित कोनातून हल्ला करते — मूळ मॉडेल चालवणे स्वस्त करून नाही, तर त्याभोवतीचे स्कॅफोल्डिंग पुन्हा लिहून.
संशोधकांच्या मते, SoL-Pi नावाची त्यांची पद्धत कार्यक्षमता जवळपास तशीच ठेवून टोकनचा वापर जवळपास निम्म्यावर आणते. The Decoder ने या कामाची नोंद दिली असून, प्रणाली मॉडेलऐवजी हार्नेस नावाच्या नियंत्रण स्तरावर लक्ष केंद्रित करते असे नमूद केले आहे.
हार्नेस प्रत्यक्षात काय करतो
हार्नेस म्हणजे मॉडेल आणि ते ज्या वातावरणात कार्यरत असते त्यामधील सॉफ्टवेअरचा स्तर. तो एजंटला तो कोणत्या स्थितीत आहे हे दाखवतो, कृती कशा प्रकारे अंमलात येतील हे ठरवतो, आणि त्यानंतर मॉडेलकडे कोणता फीडबॅक परत येईल हे निश्चित करतो. Codex, Claude Code आणि OpenClaw यांसारखी परिचित उत्पादने भाषा मॉडेलला फाइल्स संपादित करू शकणारे, चाचण्या चालवू शकणारे आणि पुनरावृत्ती करू शकणारे स्वरूप देण्यासाठी याच प्रकारच्या हार्नेसवर अवलंबून असतात.
हा स्तर लूपचा इतका मोठा भाग नियंत्रित करत असल्याने खर्चावर त्याचा असमान्य परिणाम होतो. प्रत्येक अनावश्यक टूल कॉल, प्रत्येक अतिविशाल कॉन्टेक्स्ट विंडो, प्रत्येक उशिरा सुरू होणारी पडताळणी पायरी — या सर्व कडून कठोरपणे आवश्यक नसलेली टोकन्स जोडली जातात. आतापर्यंत बहुतेक कार्यक्षमतेचे काम अन्यत्र केंद्रित होते — वेगवान अटेंशन कर्नल्स आणि सर्व्हिंग इन्फ्रास्ट्रक्चरद्वारे एका टोकनची किंमत कमी करणे, क्वांटायझेशनद्वारे मॉडेल्स संकुचित करणे, किंवा काम लहान, स्वस्त मॉडेल्सकडे वळवणे.
हार्नेस ऑप्टिमायझेशन कठीण का आहे
हार्नेस हाताने ट्यून करणे कठीण आहे कारण त्याच्या जबाबदाऱ्या घट्टपणे गुंफलेल्या आहेत. टूल वापर, कॉन्टेक्स्ट व्यवस्थापन, पडताळणी नित्यक्रम आणि अबॉर्ट लॉजिक — सर्व एकमेकांशी संवाद साधतात. एका टप्प्यात टोकन्स कमी करणारा बदल दुसरीकडे अपयश आणू शकतो, किंवा खर्च फेरीच्या नंतरच्या टप्प्यात सरकवू शकतो जिथे तो दिसणे कठीण असते.
प्रत्यक्षात, अभियंते दीर्घ अंमलबजावणी ट्रेस वाचतात, वारंवार येणारे अपयशाचे नमुने शोधतात, आणि त्या निरीक्षणांचे कोड बदलांमध्ये रूपांतर करतात. हे संथ, हस्तकीय काम आहे जे एखाद्याने तीच चूक दहाव्यांदा लक्षात घेण्यावर अवलंबून असते.
SoL-Pi शोध कसा स्वयंचलित करतो
SoL-Pi तो मानवी लूप घेऊन त्याला स्वयंचलित करतो. एक संशोधन एजंट दुसऱ्या एजंटने तयार केलेले ट्रेस निरीक्षण करतो, हार्नेसमध्ये सुधारणा सुचवतो, आणि नंतर त्या प्रस्तावांची चाचणी तयार केलेल्या वातावरणांमध्ये करतो. उमेदवार बदल क्षमता तपासणी आणि कार्यक्षमता तपासणी — दोन्हींमधून तपासले जातात, आणि केवळ जे प्रकार खर्च कमी करताना कार्यक्षमता स्थिर ठेवतात तेच ठेवले जातात.
लेखक या दृष्टिकोनाचे वर्णन पुनरावर्ती स्व-सुधारणेवर आधारित असे करतात: एक AI प्रणाली प्रत्यक्षात दुसऱ्याच्या कार्यरत परिस्थिती सुधारत असते. एक महत्त्वाचा तपशील म्हणजे अंतिम निकाल ठरवण्यासाठी वापरलेले मूल्यांकन हार्नेस गोठवल्यानंतरच होते, आणि ते राखून ठेवलेले मूल्यांकन शोधात परत फीड होत नाही. हे विभाजन महत्त्वाचे आहे, कारण ऑप्टिमायझेशन प्रक्रिया अखेरीस भेटणाऱ्या चाचण्यांशी स्वतःला किती जुळवू शकते हे ते मर्यादित करते.
प्रयोगाचा विस्तार
शोध व्यापक होता. 535 कार्यान्वयनीय वातावरणांमध्ये SoL-Pi ने 152 वेगवेगळ्या दिशा शोधल्या. कार्यांच्या मिश्रणात समाविष्ट होते:
- GitHub इश्यू आणि पुल रिक्वेस्ट जोड्यांवरून तयार केलेली 495 कार्ये
- मूल्यांकनासाठी तयार केलेली 40 कृत्रिम चाचणी प्रकरणे
- एकूण 3,000 हून अधिक फेऱ्या
- 60,000 हून अधिक एजंट-वातावरण संवाद
संशोधक हा आकारमान प्रणालीने किती व्यापक शोध घेतला याचा पुरावा म्हणून मांडतात, पण ते हेही सावध करतात की अधिक शोध घेतल्याने आपोआप चांगले परिणाम मिळत नाहीत. व्यापकता उपयुक्त हार्नेस संरचना सापडण्याची शक्यता वाढवते, पण त्याची हमी देत नाही.
मोजलेली बचत
मुख्य आकडे लक्षणीय आहेत. संशोधकांच्या मते, EdgeBench वर SoL-Pi ने Codex च्या तुलनेत 50 टक्के आणि Claude Code च्या तुलनेत 54.3 टक्के टोकन्स वाचवले, तर कार्यक्षमता जवळपास समान राहिली. पेपर एकूण टोकन कपात 49 टक्क्यांपर्यंत, कार्य क्षमतेत फारसा बदल न होता, अशी मांडणी करतो.
ही मांडणी महत्त्वाची आहे. एजंटला अधिक वेळा अपयशी होऊ दिले, पडताळणी वगळली, किंवा वैध कार्यांवर लवकर अबॉर्ट केले तर टोकन वापर कमी करणे सोपे आहे. येथील दावा वेगळा आहे: बचत क्षीण झालेल्या वर्तनातून नाही तर अधिक कार्यक्षम नियंत्रण लॉजिकमधून येते, म्हणूनच निवड प्रक्रियेत क्षमता तपासणी कार्यक्षमता तपासणीसोबत ठेवली आहे.
ओव्हरफिटिंगचा प्रश्न
या संशोधन शाखेत एक ज्ञात धोका आहे. पूर्वीच्या कामांनी दाखवले आहे की स्वयंचलितपणे ऑप्टिमाइझ केलेले हार्नेस ओव्हरफिट होण्याची प्रवृत्ती दाखवतात — ज्या ट्रेसवर ते ट्यून केले गेले त्यावर अत्यंत कार्यक्षम होतात, पण नवीन परिस्थितींमध्ये खराब सामान्यीकरण करतात. Nvidia लेखक याबाबत जागरूक असल्याचे दिसते, म्हणूनच अंतिम मूल्यांकन गोठवलेल्या हार्नेसवर आणि शोध लूपपासून वेगळे केले जाते.
तरीही, ही सूचना पुढे नेण्यासारखी आहे. येथे वापरलेली वातावरणे असंख्य असली तरी कोडिंग एजंट्सना भेटणाऱ्या गोंधळलेल्या वास्तवाचा ती अजूनही मर्यादित नमुना आहेत. 535 वातावरणांमध्ये सुधारित हार्नेस खऱ्या अर्थाने अपरिचित रेपॉझिटरी, अस्थिर चाचणी संच, किंवा संदिग्ध बग रिपोर्टसमोर टिकतो का, हा प्रश्न खुला आहे आणि त्याचे उत्तर केवळ व्यापक तैनातीतून मिळेल.
एजंट अर्थशास्त्रासाठी याचा अर्थ
प्रयोगशाळेबाहेर निकाल टिकले तर त्याचे परिणाम तात्विक नाहीत तर व्यावहारिक आहेत. स्वायत्त कोडिंग एजंट्स चालवणारे संघ प्रति टोकन पैसे देतात, आणि एजंट्सना उपयुक्त बनवणाऱ्या दीर्घ, देखरेखीविना चालणाऱ्या सत्राच — तीच त्यांना महाग बनवतात. क्षमता न गमावता कार्यप्रवाहातून जवळपास निम्मी टोकन्स बाहेर काढल्यास बजेट किती अशी सत्रे टिकवू शकते हे बदलते.
हे काम ऑप्टिमायझेशनचा प्रयत्न कुठे खर्च करणे योग्य आहे यातही बदल सुचवते. मॉडेल-स्तरीय कार्यक्षमता वर्षानुवर्षे डीफॉल्ट लक्ष्य राहिली आहे, आणि ती निश्चितच अजूनही महत्त्वाची आहे. पण कॉन्टेक्स्ट, पडताळणी आणि पुनर्प्रयत्नांबाबतचे निर्णय हार्नेसमध्ये घेतले जातात, आणि हा पेपर दाखवतो त्याप्रमाणे अपव्ययाचा मोठा वाटा तिथेच जमा होतो. मॉडेल आणि वातावरणामधील अंतर हे पाहण्यासाठी उरलेले सर्वाधिक फलदायी स्थान असू शकते.
हा लेख The Decoder च्या अहवालावर आधारित आहे. मूळ लेख वाचा.
Originally published on the-decoder.com
