वे एआई भटकाव जिनका खर्च आपको नहीं उठाना चाहिए

ऐसा नहीं है कि अग्रणी एआई कंपनियाँ टोकन बेचते समय अपने पक्ष में पलड़ा झुकाने की कोशिश नहीं करेंगी, अगर वे ऐसा करके बच सकती हों—आखिरकार, Anthropic ने जून में कीमत में प्रभावी रूप से 30% की बढ़ोतरी की; DeepSeek ने अगस्त में एपीआई की कीमतें बढ़ाईं; और OpenAI ने सितंबर के अंत में अपने मध्यम-स्तर के टोकन भत्ते में की गई कटौती को अनिच्छा से वापस लिया। इसलिए, अब किफ़ायत की ओर बढ़ता रुझान काफ़ी स्पष्ट है।

दरअसल, यह ख़याल तब बार-बार आता है जब आपका एआई एजेंट 45 मिनट में आपका रोज़ का टोकन भत्ता ऐसे कोड पर खर्च कर डालता है जिसे बहुत शानदार तो नहीं कहा जा सकता, और फिर आपको 3-4 घंटे बाद लौटने को कहता है। ऐसे निराशाजनक पल में मन में यह सवाल उठना स्वाभाविक है कि इस प्रक्रिया में होने वाली कुछ गतिविधियाँ कहीं सेवा-प्रदाताओं के फ़ायदे के लिए तो नहीं होतीं। आखिरकार, यह हमसे टोकन की विशेष अतिरिक्त खेप के लिए पैसे खर्च करवाने—या यहाँ तक कि ‘स्वचालित रीफ़िल’ चालू करवाने—का एक अच्छा तरीका है।

ख़ैर, अगर वाकई ऐसा है, तो इस दौर में अग्रणी कंपनियाँ इस धारणा की आड़ लेने का पूरा जायज़ आधार रखती हैं कि हमें यह पूरी तरह समझ नहीं आता कि एजेंट-आधारित कार्यभारों में, अलग-अलग मॉडलों और ढाँचों के तहत, टोकनों का इस्तेमाल कैसे होता है। और उन्हें भी यह समझ नहीं आता। उनके भुगतान शुरू करने की प्रक्रियाओं को छोड़ दें (जो सचमुच बहुत सहज हैं), तो बाकी सब कुछ पूर्व-अल्फ़ा चरण में है और अत्याधुनिक शोध का विषय बना हुआ है—भले ही इस उत्पाद का व्यापक रूप से एक जैसी वस्तु बन जाना आम हो गया हो।

बर्बादी का प्रबंधन

यह बात कि एजेंट-आधारित कार्यप्रवाहों में एआई एजेंट तर्क करते समय टोकन (और इसलिए आपका पैसा) बर्बाद करते हैं, पहले से अच्छी तरह स्थापित है: ठीक एक साल पहले मैंने नए शोध के बारे में लिखा था, जिसमें बताया गया था कि तर्क करने वाले एआई मॉडल किस हद तक ‘बड़बड़ाते’ हुए टोकन खर्च कर सकते हैं; इस साल की शुरुआत में मैंने ऐसे और शोध के बारे में लिखा था, जिसमें विचार-श्रृंखला तर्क को ‘दिखावटी’ बताया गया था; और पिछले हफ़्ते, Tsuga के उत्पाद प्रमुख Nils Bunge ने यहाँ एक विचार-नेतृत्व लेख में कहा:

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

कम ज्ञात बात यह है कि टोकन किस तरीके से गैर-ज़रूरी कार्यों या प्रक्रियाओं में बर्बाद होते हैं; और आज इसी विषय पर मेरा ध्यान फिर खींचने वाले एक नए शोध-पत्र का केंद्र यही है।

एआई एजेंट आपका पैसा कैसे बर्बाद करते हैं? शीर्षक वाला यह नया अमेरिकी अकादमिक सहयोग* एक ऐसा समग्र ढाँचा प्रस्तुत करता है, जो यह माप सकता है कि एजेंट-आधारित प्रक्रियाएँ वास्तव में कितने टोकन बर्बाद करती हैं। जहाँ मॉडल ओपन-सोर्स नहीं होते, वहाँ ‘शैडो’ पद्धति को सेवा-प्रदाताओं के आधिकारिक आँकड़ों और मापदंडों के साथ मिलाकर इस बात का वैसा ही विस्तृत ब्योरा तैयार किया जाता है कि एआई के तर्क करने और काम करने के दौरान टोकनों के साथ क्या हुआ:

एआई के बर्बाद हुए टोकनों को मापने की नई विधि। हर एजेंट के तर्क, कार्रवाइयों और लागतों को दर्ज किया जाता है, फिर दोहराव, गैर-ज़रूरी अनुरोधों और टाले जा सकने वाले भटकावों के लिए उनकी जाँच की जाती है। पहचानी गई बर्बादी को हटा दिया जाता है और फिर जाँचा जाता है कि एजेंट मूल कार्य पूरा कर सकता है या नहीं। स्रोत

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

परीक्षणों में शोधकर्ताओं ने पाया कि एजेंटों के आउटपुट टोकनों में से लगभग 18% बर्बाद हुए। 45% से अधिक कार्यों में, एक एजेंट ने उसी काम को सफलतापूर्वक पूरा करने के लिए दूसरे एजेंट की ज़रूरत से अधिक टोकन बर्बाद किए। उन्होंने यह भी पाया कि गैर-ज़रूरी तर्क के 41–46% हिस्से को हटाने का प्रदर्शन पर बहुत कम असर पड़ा। इससे पता चलता है कि नतीजों से कोई बड़ा समझौता किए बिना काफ़ी बचत संभव है।

शोध-पत्र में कहा गया है:

‘इकट्ठा किए गए सभी क्रमों में, आउटपुट टोकनों में से लगभग 18% को बर्बादी के रूप में पहचाना गया।’

‘गौरतलब है कि 45% से अधिक कार्यों में, एक एजेंट का अकेले बर्बाद हुआ आउटपुट उस दूसरे एजेंट के पूरे आउटपुट से अधिक होता है, जो उसी कार्य को सफलतापूर्वक पूरा करता है।’

इसके अलावा, अध्ययन में पाया गया कि अपरिचित टूलों का इस्तेमाल करते समय और ऐसे तरीकों पर आगे बढ़ते हुए, जिनका अंततः कोई नतीजा नहीं निकलता, एजेंट सबसे अधिक संसाधन बर्बाद करते हैं; साथ ही, तर्क के प्रयास को बढ़ाने से लगातार बेहतर नतीजे नहीं मिलते। अधिकतम प्रयास पर Kimi-K3 ने कम प्रयास की तुलना में 6.6 गुना अधिक तर्क-टोकन उत्पन्न किए, लेकिन इससे बेहतर नतीजों की कोई गारंटी नहीं मिली।

पाँच बेंचमार्क में तर्क-प्रयास के चार स्तरों पर Kimi-K3 के प्रदर्शन के परीक्षण नतीजे। तर्क-प्रयास बढ़ाने से सफलता दर में लगातार सुधार नहीं हुआ, और अधिकतम प्रयास से कभी-कभी निचली सेटिंग की तुलना में खराब नतीजे मिले।

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

शोधपत्र में यह भी जाँचा गया है कि टोकन की बर्बादी में अलग-अलग हार्नेस की क्या भूमिका है। इसमें पाया गया कि एक ही AI मॉडल, Kimi-K3, समान कार्यों पर इस्तेमाल किए गए हार्नेस के आधार पर चार गुने से भी अधिक तर्क-टोकन उत्पन्न कर सकता है, जबकि इससे बेहतर नतीजे मिलना ज़रूरी नहीं है।

कुछ बर्बादी की वजह बुनियादी सॉफ़्टवेयर त्रुटियाँ थीं। पाया गया कि OpenCode, Kimi Code CLI और OpenClaw बार-बार गलत Python परिवेश में कार्य शुरू करते थे, जिससे त्रुटियाँ होती थीं और टोकन खर्च करने वाले प्रयास दोहराने पड़ते थे। Kimi Code CLI में AI को ऐसे टाइमआउट माँगने की अनुमति भी थी जिन्हें उसका अपना सॉफ़्टवेयर अस्वीकार कर देता था, जिसके कारण और भी महँगे प्रयास करने पड़ते थे।

विपरीत लगने के बावजूद, अधिक टूल देने वाले हार्नेस ज़रूरी नहीं कि अधिक बर्बादी करें। कुछ बार-बार दिखने वाली अक्षमताएँ इस बात पर निर्भर नहीं थीं कि कौन-सा हार्नेस मॉडल को नियंत्रित कर रहा था, बल्कि वे स्वयं मॉडल में पैदा होती दिखीं।

‘[Several]हार्नेस की देखने में स्पष्ट लगने वाली विशेषताएँ बर्बादी में देखे गए अंतर को लगातार स्पष्ट नहीं करतीं। उदाहरण के लिए, जैसा कि [below]दिखाया गया है, अधिक टूल उपलब्ध कराने वाले हार्नेस ज़रूरी नहीं कि अधिक बर्बादी करें। OpenClaw अन्य हार्नेस की तुलना में कहीं अधिक टूल उपलब्ध कराता है, फिर भी इसमें बर्बादी का स्तर मध्यम है। इसके अलावा, बर्बादी के सभी पहलू हार्नेस के साथ नहीं बदलते।

‘[Below right]यह दिखाता है कि SWE-bench Verified पर एक बार-बार दोहराया जाने वाला भटकाव सामने आता है: Kimi-K3 उस सुधार को लिखता है जिसे वह परियोजना का मूल सुधार मानता है, और बाद में उसे छोड़ देता है। ‘

AI एजेंट हार्नेस में बर्बाद हुए टोकन की तुलना करने वाले परीक्षण नतीजे। बायाँ: अधिक टूल उपलब्ध कराने से बर्बादी ज़रूरी नहीं कि बढ़े। दायाँ: Kimi-K3 बार-बार एक कथित मूल सॉफ़्टवेयर सुधार को आज़माता है और छोड़ देता है—हार्नेस चाहे जो भी हो; लेकिन अलग तरह के कार्य में ऐसा बहुत कम करता है।

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

कार्यविधि

AI एजेंट की गतिविधियों को फिर से समझने के लिए, शोधकर्ताओं ने मॉडल और उसे नियंत्रित करने वाले सॉफ़्टवेयर के बीच हर संवाद पर नज़र रखी और उसके तर्क, जवाब, टूल अनुरोध तथा टोकन की लागत दर्ज की। विवरण का स्तर प्रदाता के अनुसार अलग-अलग था: Kimi-K3 अपनी पूरी तर्क-प्रक्रिया दिखाता है; Gemini 3.1 Pro केवल सारांश दिखाता है; और Claude कुछ भी नहीं दिखाता।

शोधकर्ताओं ने हर टूल के नतीजे एजेंट को वापस दिए, जिससे वे प्रक्रिया पूरी होने तक या एजेंट की संचालन-सीमा पहुँचने तक उसका अनुसरण कर सके।

AI एजेंटों के टोकन इस्तेमाल करने के चार उदाहरण। पहले से ज्ञात जानकारी दोहराना, एक जैसी खोजें करना और बेवजह माफ़ी जोड़ना बर्बादी माना जाता है; जबकि असफल खोज को ज़रूरी नहीं कि बर्बादी कहा जाए, क्योंकि एजेंट के पास उसे आज़माने की कोई वाजिब वजह हो सकती है।

एजेंटों के अनुरोधों को उनकी गतिविधि पर नज़र रखने के लिए एक प्रॉक्सी के ज़रिए भेजा गया। इसके लिए कोड में केवल मामूली बदलाव करने पड़े और हर अनुरोध पर उसका बेंचमार्क, रन, कार्य और परीक्षण-प्रयास दर्ज किया गया। (OpenClaw में ऐसे टैग का समर्थन नहीं है, इसलिए उस स्थिति में हर परीक्षण के लिए एक अलग प्रॉक्सी—जिसे LiteLLM पर बनाया गया था—इस्तेमाल की गई।)

चार तरह की बर्बादी

अध्ययन में टोकन की बर्बादी के चार बार-बार दिखने वाले रूप बताए गए हैं: पुनर्कथन (पहले से ज्ञात जानकारी दोहराना); दोहराव वाली खोज (अनावश्यक टूल अनुरोध दोहराना); भराव (ग़ैर-ज़रूरी पाठ जोड़ना); और भटकाव (ऐसे तरीके अपनाना जो उचित लगते हैं, लेकिन अंततः बेनतीजा रहते हैं)।

रिकॉर्ड किए गए हर सत्र की जाँच LLM-as-a-Judge (LLMaJ**) ने की। उसे मूल कार्य, पूरा रिकॉर्ड और अपव्यय के चारों पैटर्न की पहचान के मानदंड दिए गए थे। संभावित अपव्यय को चिह्नित करके हटा दिया गया और बचे हुए टोकन फिर से गिने गए, ताकि अपव्यय का अनुपात और लागत निकाली जा सके। इसके बाद, इन गिनतियों का मिलान हर प्रदाता के अपने टोकनाइज़र या गणना उपकरणों से किया गया और उपयोग किए गए आउटपुट की उनकी रिपोर्ट से भी जाँच की गई (रिपोर्ट में केवल मामूली फ़ॉर्मैटिंग अंतर बताए गए)।

परीक्षण

अध्ययन में इन मॉडलों का परीक्षण किया गया: Kimi-K3; Gemini 3.1 Pro; GPT-5.6 Terra; GPT-6 Astra; Claude Sonnet 5; और Claude Fable 5.1। इनका परीक्षण निम्नलिखित बेंचमार्क पर किया गया: τ²-bench (एयरलाइन और खुदरा ग्राहक सेवा); SWE-bench Verified (सॉफ़्टवेयर इंजीनियरिंग); Claw-Eval; और MCP-Atlas (सामान्य प्रयोजन के लिए टूल का उपयोग)।

इसके अलावा, Kimi-K3 का परीक्षण तर्क के अलग-अलग स्तरों पर किया गया और पाँच एजेंट-हार्नेस की तुलना की गई: OpenCode; OpenClaw; OpenHands; Hermes; और Kimi Code CLI। इन बाद के तुलनात्मक परीक्षणों से यह आकलन किया गया कि मॉडल, कार्य, तर्क में लगाया गया प्रयास और हार्नेस का डिज़ाइन टोकन के अपव्यय को कैसे प्रभावित करते हैं (और प्रदर्शन पर इसके असर की जाँच के लिए आगे के परीक्षणों में संभावित अपव्यय को हटाया भी गया)।

यह पता लगाने के लिए कि हर मॉडल के कारण कितनी धनराशि बर्बाद हुई, अनावश्यक पाठ और टूल कॉल की लागत की तुलना कुल आउटपुट लागत से की गई और चारों बेंचमार्क के नतीजों का औसत निकाला गया। आंतरिक तर्क का अलग से आकलन Kimi-K3 के लिए किया गया—यह एकमात्र मॉडल था जिसने अपनी पूरी तर्क-प्रक्रिया दिखाई:

छह एआई मॉडलों के आउटपुट की अपव्यय-लागत की तुलना के परीक्षण नतीजे; चार बेंचमार्क के आधार पर औसत निकाला गया है। बाईं ओर: कुल अपव्यय दरें, जिसमें Kimi-K3 का आंतरिक तर्क अलग से दिखाया गया है। दाईं ओर: सफल और असफल कार्यों में अपव्यय दरें; असफल कार्यों में आम तौर पर अपव्यय अधिक था।

जैसा कि ऊपर दिखाया गया है, जवाब तैयार करने और टूल इस्तेमाल करने पर खर्च की गई धनराशि में से 11% से 24.9% तक को बर्बाद माना गया। GPT-6 Astra का प्रदर्शन सबसे अच्छा और Claude Sonnet 5 का सबसे खराब रहा। Kimi-K3 के मामले में, जवाबों और टूल के इस्तेमाल में लगभग हर छह में से एक टोकन बर्बाद हुआ; इसके आंतरिक तर्क के दौरान यह बढ़कर हर चार में से एक से अधिक हो गया।

आम तौर पर, कार्य असफल होने पर अपव्यय अधिक पाया गया, हालाँकि Kimi-K3 के तर्क में इसका उलटा था; और इस बात का कोई स्पष्ट प्रमाण नहीं मिला कि अनावश्यक काम पर अधिक टोकन खर्च करने से सफलता की संभावना बढ़ी।

एक अन्य परीक्षण में, एआई के काम जारी रहने के दौरान बर्बाद होने वाले टोकन घटाने की कोशिश की गई: हर चरण पर एआई जज** की मदद से मॉडल के तर्क में दोहराई गई जानकारी और निरर्थक पाठ हटाया गया, फिर कार्य को आगे बढ़ने दिया गया:

दो बेंचमार्क पर सफलता दरों पर अनावश्यक एआई तर्क हटाने के असर को दिखाने वाले परीक्षण नतीजे। तर्क का 41-46% हटाने से प्रदर्शन पर बहुत कम असर पड़ा, जबकि पूरा तर्क हटाने से असफलताएँ काफ़ी बढ़ गईं।

SWE-bench Verified पर तर्क का 41% हटा दिया गया और प्रदर्शन में कोई गिरावट नहीं आई; बल्कि सफलता दर 89% से बढ़कर 89.5% हो गई। MCP-Atlas पर 46% तर्क हटाया गया और सफलता दर में केवल मामूली गिरावट आई—65% से 62.3% तक।

दूसरे शब्दों में, काम करते समय लगभग आधे तर्क को हटाया जा सकता था, और इससे काम पूरा करने की एआई की क्षमता पर कोई गंभीर असर नहीं पड़ा।

अंत में^†, अलग-अलग एजेंट-हार्नेस का इस्तेमाल करके समान कार्यों पर Kimi-K3 का परीक्षण किया गया। जैसा कि नीचे दिखाया गया है, तर्क के आउटपुट में चार गुने से भी अधिक अंतर आया, लेकिन प्रदर्शन में कोई नियमित सुधार नहीं हुआ:

दो बेंचमार्क पर अलग-अलग एजेंट-हार्नेस में Kimi-K3 के टोकन इस्तेमाल की तुलना के परीक्षण नतीजे। आंतरिक तर्क नीले रंग में, और जवाब तथा टूल कॉल नारंगी रंग में दिखाए गए हैं। कोडिंग के कार्यों में, Mini-SWE के साथ Hermes की तुलना में चार गुने से भी अधिक तर्क तैयार हुआ।

कुछ अपव्यय की वजह सॉफ़्टवेयर की बुनियादी खामियाँ थीं। OpenCode, Kimi Code CLI और OpenClaw ने कोडिंग परीक्षण गलत Python परिवेश में शुरू किए, जिससे त्रुटियाँ हुईं और उन्हें फिर से चलाना पड़ा।

निष्कर्ष

यह उस शोधपत्र की बस एक झलक है, जिसे विस्तार और सावधानीपूर्वक अपनाई गई पद्धति के कारण और गहराई से पढ़ने पर लाभ हो सकता है।

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

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

* University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) और एक स्वतंत्र शोधकर्ता का स्पष्ट रूप से समान योगदान।

* जहाँ तक मैं समझ पाया हूँ, शोधपत्र में यह नहीं बताया गया है कि किस मॉडल का इस्तेमाल किया गया था।

^†यह इस लेख के लिए है, शोधपत्र के लिए नहीं। शोधपत्र मेरी आम तौर पर निर्धारित सीमा से लंबा है और उसमें इतने अधिक परीक्षण और गहराई हैं कि हम उन्हें यहाँ शामिल नहीं कर सकते। अधिक जानकारी के लिए ऊपर लिंक की गई मूल PDF देखें।

पहली बार प्रकाशित: शुक्रवार, 6 नवंबर 2026