लांब एजंट टर्न्स context window मध्ये ठेवणे

मॉडेल एका वेळी फक्त इतकेच वाचू शकते, ज्याला त्याचा context window म्हणतात. Mythex चा एजंट लांब काम करतो: अनेक फाईल्स वाचणे, commands चालवणे, मर्यादित कामे sub-agents ना देणे. लांब काम कसे तुटते याचे तीन मार्ग आम्हाला सापडले: sub-agents इतके वाढले की मॉडेल प्रत्येक request नाकारू लागले, एक sub-agent खोली संपली आहे असे समजून लवकर थांबला, आणि रशियन, चिनी आणि जपानी मजकुरासाठी आमचे token मोजणे खूपच चुकीचे होते. आम्ही काय बदलले ते इथे आहे.

आधी काही संज्ञा

• Tokens म्हणजे मॉडेल वाचते ते तुकडे. मर्यादा आणि खर्च अक्षरांमध्ये किंवा शब्दांमध्ये नव्हे तर tokens मध्ये मोजले जातात.
• Context window म्हणजे मॉडेल एका request मध्ये जास्तीत जास्त किती वाचू शकते. आम्ही प्रत्येक request साठी स्वतःचे कमी बजेट देखील ठरवतो, जेणेकरून खर्च आणि वेग वाजवी राहतील.
• Tool results म्हणजे एजंटला त्याच्या tools कडून परत मिळणारे: त्याने वाचलेल्या फाईलची सामग्री, त्याने चालवलेल्या command चे आउटपुट. लांब कामात तेच बहुतेक पाठवले जाते.
• Sub-agent म्हणजे मुख्य एजंट एखाद्या स्वयंपूर्ण कामासाठी सुरू करणारा मदतनीस, जसे “हे प्रकरण नोट्सशी तपासा”. त्याला एक सूचना मिळते, आणि मग तो स्वतःहून अनेक tool calls करत काम करतो.

समस्या 1: sub-agents इतके वाढले की मॉडेल त्यांना नाकारू लागले

प्रत्येक पायरीवर एजंट आतापर्यंतचे संभाषण मॉडेलला पाठवतो. ते खूप मोठे झाले की आमचा कोड त्याला छाटत असे, पण फक्त user message च्या सुरुवातीला, जेणेकरून tool call आणि त्याचा परिणाम कधीच वेगळे होत नसत. तो पहिला संदेश ठेवत असे, “आधीचे संभाषण छाटले आहे” अशी नोंद जोडत असे, आणि बसणारे सर्वात नवे पूर्ण turns ठेवत असे.

Sub-agent ला नेमका एकच user message असतो: त्याची सूचना. तिथे कापायला जागाच नव्हती. म्हणून तो प्रत्येक पायरीवर त्याचा संपूर्ण इतिहास पाठवत होता, आणि प्रत्येक वेळी तो वाढत जात होता, शेवटी request मॉडेल स्वीकारेल त्यापेक्षा मोठी होईपर्यंत, म्हणजे सुमारे दहा लाख tokens. अशा 8 sub-agents च्या चाचणीत, सर्व 8 नाकारले गेले.

उपाय: आधी जुने tool results साफ करा

आता request तीन पायऱ्यांत बजेटमध्ये बसवली जाते, मागील पायरी पुरेशी नसेल तरच पुढची वापरून:

1. सर्वात जुने tool results साफ करा. त्यांची सामग्री एका छोट्या नोंदीने बदलली जाते: निकाल संभाषण मॉडेलच्या context मध्ये ठेवण्यासाठी साफ केला, आणि गरज पडल्यास एजंट tool पुन्हा चालवू शकतो. एक तासापूर्वी वाचलेली फाईल सहसा request मधील सर्वात मोठी आणि कमी उपयोगी गोष्ट असते, आणि फाईल तरीही पुन्हा वाचता येते. नवीन निकाल पूर्ण राहतात.
2. पूर्ण user turns ठेवा. आधीप्रमाणेच: पहिला संदेश, एक नोंद, आणि बसणारे सर्वात नवे पूर्ण turns.
3. पूर्ण tool rounds ठेवा. एका लांब turn च्या आत, जो sub-agent कडे असलेला एकमेव प्रकार आहे: पहिला संदेश, एक नोंद, आणि “tool कॉल करा, निकाल मिळवा” या सर्वात नव्या पूर्ण rounds.

हे फक्त पाठवले जाणारे आकार ठरवते. एजंटचा saved history सर्व काही राखतो. त्याच चाचणीत 8 पैकी 0 नाकारले गेले आणि सर्व 8 पूर्ण झाले.

Caching चालू राहावे म्हणून batches मध्ये साफ करा

Model providers एखाद्या request ची सुरुवात मागील request सारखीच असेल तर तिचे काम पुन्हा वापरू शकतात: ही prefix cache आहे. प्रत्येक call वर एकच जास्तीचा निकाल साफ केला तर request ची सुरुवात प्रत्येक call वर बदलेल आणि cache कधीच मदत करणार नाही.

म्हणून सर्वात जुने निकाल एकावेळी एक नव्हे तर चार चार करून साफ केले जातात. साफ केलेला भाग मग अनेक calls मध्ये तसाच राहतो. नोंदीपेक्षा फार मोठा नसलेला निकाल सोडला जातो: तो साफ केल्यास जवळजवळ काहीच वाचणार नाही आणि request ची सुरुवात तरीही बदलेल. किती भाग पूर्ण राहील हे संख्येवरून नव्हे तर आकारावरून ठरते: बजेटच्या एक चतुर्थांश भागात बसणारे सर्वात नवे निकाल पूर्ण राहतात, आणि किमान एक नेहमी राहतो. आधीच्या आवृत्तीत नेहमी सहा पूर्ण ठेवले जात होते, जे छोट्या command आउटपुटसाठी योग्य होते, पण लांब फाईल वाचनांसह जुन्या निकालांना बजेटचा बहुतेक भाग देत होते.

नकार आता स्पष्ट सांगतात

मॉडेलने अवैध म्हणून नाकारलेली request आता पुन्हा try केली जात नाही; तीच request पुन्हा पाठवल्यास तेच उत्तर येते. संभाषण मॉडेलसाठी खूप मोठे असेल तर व्यक्तीला दिसते: “हे संभाषण मॉडेलला एका वेळी वाचण्यासाठी खूप मोठे झाले. पुढच्या पायरीसाठी नवीन चॅट सुरू करा; आतापर्यंत बनवलेले सर्व काही टिकून राहील.” ती कृती व्यक्तीने करायची आहे, outage नाही, त्यामुळे ते आम्हाला page करत नाही.

समस्या 2: एजंट “खोली वाचवण्यासाठी” थांबला

एका sub-agent ला 40 मोठे धडे वाचायला सांगितले होते, तो 2 नंतर थांबला, आणि म्हणाला की त्याला खोली वाचवायची आहे. त्याने 400,000-token बजेटपैकी सुमारे 100,000 tokens वापरले होते.

जुने निकाल आता त्याच्यासाठी साफ केले जातील हे त्याला माहीत नव्हते. म्हणून आम्ही ते सांगितले. एजंटच्या सूचनांमध्ये आता असे म्हटले आहे की संभाषण मॉडेल स्वीकारू शकेल त्यापेक्षा मोठे झाले की सर्वात जुने tool results साफ केले जातात आणि सर्वात नवे पूर्ण राहतात. त्यामुळे खोली वाचवण्यासाठी लांब काम थांबवू नका; पुढे जा, आणि जे साफ झाले ते हवे असल्यास फाईल पुन्हा वाचा.

मॉडेलला न दिसणारी दुरुस्ती मॉडेलच्या दृष्टीने दुरुस्ती नसते. यंत्रणा तेव्हाच मदत करते जेव्हा एजंट तिच्यावर विश्वास ठेवतो.

समस्या 3: सर्व काही इंग्रजी असल्यासारखे tokens मोजणे

आम्ही tokenizer न चालवता tokens अंदाजे काढत होतो: अक्षरे चारने भागून. इंग्रजीसाठी हा वाजवी अंदाजाचा नियम आहे. पण इतर लिपींसाठी नाही: रशियन सुमारे 2.2 अक्षरे प्रति token, आणि चिनी किंवा जपानी सुमारे एक.

त्यामुळे रशियन धडे वाचणारा sub-agent सुमारे 640,000 tokens ची request पाठवत होता, आणि आमचा अंदाज ती 400,000 च्या बजेटखाली असल्याचे सांगत होता. तो अंदाज सहज मॉडेलच्या कठोर मर्यादेपलीकडे request ढकलू शकला असता.

आता अंदाज लिपीनुसार मोजतो: साधा ASCII चार अक्षरे प्रति token, चिनी, जपानी आणि कोरियन एक, आणि बाकी सर्व — सिरिलिक, ग्रीक, अरबी, accented अक्षरे, emoji — दोन. तो जास्त अंदाज करण्याच्या दिशेने चुकेल असा हेतू आहे. एका रशियन धड्यावर तो आता 43,423 tokens अंदाजतो, तर मोजणीत सुमारे 44,600 आले; आधी तो 25,023 म्हणत होता. संदेश लिहिल्यानंतर कधीच बदलत नसल्याने त्याचा अंदाज एकदाच काढून ठेवला जातो, प्रत्येक पायरीवर नव्हे.

आम्ही काय शिकलो

• आकार जिथे प्रत्यक्ष आहे तिथे छाटा. एजंटच्या कामात ते tool results असतात, user messages नव्हे.
• एजंटला त्याच्या स्वतःच्या सुरक्षा जाळ्यांबद्दल सांगा. नाहीतर तो आता लागू नसलेल्या मर्यादांभोवती योजना आखतो.
• “अक्षरे ÷ 4” ही इंग्रजी गृहीतक आहे. बहुभाषिक वापरकर्त्यांसाठी tokens मोजणाऱ्या कोणत्याही गोष्टीने लिपीनुसार मोजले पाहिजे, किंवा खरा tokenizer वापरला पाहिजे.
• Cache जपा. प्रत्येक call वर सुरुवात बदलणारी request जास्त खर्च करते आणि हळू चालते.

तुम्ही तुमच्या स्वतःच्या अ‍ॅपमध्ये AI वैशिष्ट्ये बांधत असाल तर LLM म्हणजे काय आणि LLM APIs कसे वापरायचे या guides मध्ये सुरुवातीपासूनच context windows आणि tokens समजावलेले आहेत. Mythex मध्ये sub-agents कसे चालतात याबद्दल अधिक sub-agents docs मध्ये आहे.