टोकनकास्टः LLM एजेंट निष्पादन के दौरान token उपयोग की भविष्यवाणी करना

मेटा विवरणः
टोकनकास्ट LLM एजेंट token के उपयोग की भविष्यवाणी करता है, औसत त्रुटि को 14.5% तक कम कर देता है और बजट रिप्ले में 21.3% tokens बचाता है, एसडब्ल्यूई-बेंच सत्यापित पर प्रति रन 32.8 एमएस का उपयोग करते हुए।

टैगः टोकनकास्ट, LLM एजेंट, token पूर्वानुमान, बजट नियंत्रण, एसडब्ल्यूई-बेंच सत्यापित

विशेष रुप से प्रदर्शित छवि: एक शाखा एजेंट कार्यप्रवाह पर token मीटर का अनुकूल अमूर्त चित्रण, नरम ज्यामितीय आकृतियों के साथ, कोई पाठ नहीं, कोई लोगो, कोई लोग नहीं।

टोकनकास्ट पूर्वानुमान LLM एजेंट token का उपयोग करें और त्रुटियों को 14.5 प्रतिशत तक काटें

LLM एजेंटों को चलाने वाली टीमों के लिए plan भाषा-मॉडल सिस्टम जो योजना बनाते हैं, टूल कॉल करते हैं और उन उपकरणों के आधार पर काम करना जारी रखते हैं oken टोकनकास्ट एक पूर्वानुमान पद्धति है जो token की खपत का अनुमान लगाती है जबकि कोई एजेंट अभी भी निष्पादित कर रहा है। रिपोर्ट किए गए परिणाम एक सामान्य दर्द बिंदु पर लक्षित होते हैंः एक एजेंट कार्य में केवल थोड़ा खर्च हो सकता है, जबकि उसी कार्य का दूसरा रन परिमाण के आदेश से अधिक tokens का उपभोग कर सकता है। टोकेनकास्ट ने 96 संयोजन मूल्यांकन में सबसे मजबूत तुलनाकर्ता के खिलाफ 14.5% औसत औसत पूर्ण त्रुटि कमी की सूचना दी, और ऑफलाइन बजट नियंत्रण रिप्ले में यह मेल खाने वाले ट्रैक पूरा होने पर एक निश्चित-बजट नीति की तुलना में 21.3% कम tokens उपयोग करता है। भविष्यवाणी ओवरहेड को एसडब्ल्यूई-वेरिफाइड पर प्रति रन 32.8 एमएस के औसत संचयी भविष्यवाणी समय के रूप में बताया गया है।

एजेंट token का उपयोग इतना परिवर्तनशील क्यों है

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

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

कैसे TokenCast भागों में समस्या टूट जाता है

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

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

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

टीमों के लिए रिपोर्ट किए गए आंकड़ों का क्या अर्थ है

4 कार्य सूट और 6 एजेंट मॉडल में, सबसे मजबूत तुलनित्र के मुकाबले औसत पूर्ण त्रुटि कमी 96 मूल्यांकन किए गए संयोजनों पर 14.5% है। यह एक व्यापक परिणाम है, न कि एकल चेरी-चयनित कार्य। फिर भी, यह एक त्रुटि-कमी संख्या है, इस बात की गारंटी नहीं है कि प्रत्येक तैनाती से पैसे बचेगा। ऑफ़लाइन बजट नियंत्रण रिप्ले परिणाम लागत से अधिक सीधे जुड़ा हुआ हैः मिलान ट्रेस पूरा होने पर, टोकनकास्ट निश्चित-बजट नीति की तुलना में औसतन 21.3% कम tokens का उपयोग करता है।

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

व्यावहारिक मूल्य अंतराल से आता है, JUST का मतलब नहीं। एक रिप्ले में 21.3% की बचत उपयोगी होती है, लेकिन पूर्वानुमान अवधि टीमों को बताती है कि उन्हें पूंछ जोखिम के लिए कितनी बार योजना बनानी चाहिए। यदि कोई भविष्यवाणी कहती है कि रन कम लागत के साथ समाप्त हो सकता है लेकिन इसमें व्यापक ऊपरी पूंछा है, तो सिस्टम अधिक सतर्क बजट चुन सकता है। अगर पूर्वानुਮਾਨ तंग है, यह एजेंट को जारी रखने की अनुमति दे सकता है.

किसको इसका उपयोग करना चाहिए/कौन इसे छोड़ना चाहिए

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

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

अगला क्या है

पाठकों के लिए अगला प्रश्न न केवल यह है कि टोकनकास्ट बेहतर पूर्वानुमान करता है, बल्कि एक मंच को भविष्यवाणी पर कैसे कार्य करना चाहिए। एक भविष्यवाणी अंतराल जल्दी रोकना, पुनः प्रयास सीमाएं, टूल-आउटपुट ट्रंकेशन या सस्ते मॉडल में स्विच कर सकता है। विधि के कंपोजेबल सेगमेंट भी लागत डैशबोर्ड के लिए एक मार्ग का सुझाव देते हैंः टीमें देख सकती हैं कि token खर्च को ब्लैक बॉक्स की तरह व्यवहार करने के बजाय अनुमान कहां से आया था?

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