एजेंट्स को खुला छोड़ने की छिपी लागत
AI कोडिंग एजेंट्स का अर्थशास्त्र तब बदल जाता है जब वे अकेले सवालों के जवाब देना छोड़कर स्वयं काम करने लगते हैं। एक बार का अनुमान सस्ता होता है। लंबा, बिना निगरानी वाला रन नहीं: रीज़निंग स्टेप्स टूल कॉल्स पर ढेर हो जाते हैं, जो फीडबैक लूप्स पर ढेर हो जाते हैं, और हर चक्र के साथ टोकन बिल बढ़ता जाता है। Nvidia के शोधकर्ताओं ने एक पेपर प्रकाशित किया है जिसमें एक ऐसी प्रणाली का वर्णन है जो उस बिल पर एक अप्रत्याशित दृष्टिकोण से हमला करती है—अंतर्निहित मॉडल को चलाने के लिए सस्ता बनाकर नहीं, बल्कि उसके चारों ओर के स्कैफोल्डिंग को फिर से लिखकर।
शोधकर्ताओं के अनुसार, उनकी विधि, जिसे SoL-Pi कहा जाता है, परफ़ॉर्मेंस को लगभग अपरिवर्तित रखते हुए टोकन खपत को लगभग आधा कर देती है। इस काम की रिपोर्ट The Decoder ने दी, जिसमें कहा गया है कि यह प्रणाली मॉडल के बजाय हार्नेस नामक कंट्रोल लेयर को लक्षित करती है।
हार्नेस वास्तव में क्या करता है
हार्नेस एक मॉडल और उसके संचालन के एनवायरनमेंट के बीच बैठी सॉफ़्टवेयर की परत है। यह एजेंट को दिखाती है कि वह किस स्थिति में है, तय करती है कि क्रियाएँ कैसे निष्पादित होंगी, और यह निर्धारित करती है कि बाद में मॉडल को कौन-सा फीडबैक वापस मिलेगा। Codex, Claude Code और OpenClaw जैसे परिचित उत्पाद भाषा मॉडल को ऐसी चीज़ में बदलने के लिए इसी तरह के हार्नेस पर निर्भर करते हैं जो फ़ाइलें संपादित कर सके, टेस्ट चला सके और पुनरावृत्ति कर सके।
चूँकि यह परत लूप के इतने बड़े हिस्से को नियंत्रित करती है, इसका लागत पर अत्यधिक प्रभाव पड़ता है। हर अनावश्यक टूल कॉल, हर अत्यधिक बड़ी कॉन्टेक्स्ट विंडो, हर सत्यापन चरण जो बहुत देर से सक्रिय होता है, ऐसे टोकन जोड़ता है जो सख्ती से आवश्यक नहीं थे। अब तक, अधिकांश दक्षता-कार्य अन्यत्र केंद्रित रहा है—तेज़ अटेंशन कर्नेल और सर्विंग इन्फ्रास्ट्रक्चर के ज़रिए एक टोकन की कीमत घटाने पर, क्वांटाइज़ेशन के ज़रिए मॉडल को संपीड़ित करने पर, या काम को छोटे, सस्ते मॉडलों तक रूट करने पर।
हार्नेस ऑप्टिमाइज़ेशन कठिन क्यों है
हार्नेस को हाथ से ट्यून करना कठिन है क्योंकि इसकी ज़िम्मेदारियाँ आपस में कसकर गुँथी हुई हैं। टूल उपयोग, कॉन्टेक्स्ट प्रबंधन, सत्यापन दिनचर्याएँ और अबॉर्ट लॉजिक सभी परस्पर क्रिया करते हैं। एक चरण में टोकन घटाने वाला बदलाव कहीं और विफलताएँ पैदा कर सकता है, या बस लागत को रन के बाद के चरण में स्थानांतरित कर सकता है जहाँ उसे देखना कठिन होता है।
व्यवहार में, इंजीनियर लंबे निष्पादन ट्रेस पढ़ते हैं, बार-बार होने वाले विफलता पैटर्न को पहचानते हैं, और उन अवलोकनों को कोड परिवर्तनों में बदलते हैं। यह धीमा, मैनुअल काम है जो इस पर निर्भर करता है कि कोई व्यक्ति दसवीं बार वही गलती नोटिस करे।
SoL-Pi खोज को कैसे ऑटोमेट करता है
SoL-Pi उस मानवीय लूप को उठाकर ऑटोमेट कर देता है। एक रिसर्च एजेंट दूसरे एजेंट द्वारा उत्पन्न ट्रेस का अवलोकन करता है, हार्नेस में संशोधन प्रस्तावित करता है, और फिर उन प्रस्तावों को तैयार एनवायरनमेंट में परखता है। उम्मीदवार परिवर्तनों को क्षमता जाँच और दक्षता जाँच दोनों से छाना जाता है, और केवल वे वेरिएंट रखे जाते हैं जो लागत घटाते हुए परफ़ॉर्मेंस स्थिर रखते हैं।
लेखक इस दृष्टिकोण को रिकर्सिव सेल्फ-इम्प्रूवमेंट से प्रेरित बताते हैं: एक AI प्रणाली प्रभावी रूप से दूसरे की संचालन स्थितियों को बेहतर बना रही है। एक महत्वपूर्ण विवरण यह है कि अंतिम परिणाम को आँकने के लिए इस्तेमाल किया गया मूल्यांकन हार्नेस के फ़्रीज़ होने के बाद ही होता है, और वह होल्ड-आउट मूल्यांकन खोज में वापस फीड नहीं होता। यह अलगाव महत्वपूर्ण है, क्योंकि यह सीमित करता है कि ऑप्टिमाइज़ेशन प्रक्रिया उन परीक्षणों के अनुरूप खुद को कितना ढाल सकती है जिनका उसे अंततः सामना करना है।
प्रयोग का पैमाना
खोज व्यापक थी। 535 निष्पादन योग्य एनवायरनमेंट में, SoL-Pi ने 152 अलग-अलग दिशाओं का पता लगाया। कार्य-मिश्रण में शामिल थे:
- GitHub issue और pull request जोड़ों से बने 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