लंबे एजेंट टर्न को context window के भीतर रखना

एक मॉडल एक बार में सिर्फ़ इतना पढ़ सकता है, वह उसकी context window है। Mythex का एजेंट लंबा काम करता है: कई फ़ाइलें पढ़ना, commands चलाना, और सीमित काम sub-agents को सौंपना। हमने देखा कि लंबा काम तीन तरीकों से टूटता था: sub-agents इतने बढ़ जाते थे कि मॉडल हर request ठुकरा देता था, एक sub-agent यह सोचकर जल्दी रुक जाता था कि उसके पास जगह नहीं बची, और रूसी, चीनी और जापानी टेक्स्ट के लिए हमारी token गिनती बुरी तरह गलत थी। यहाँ बताया है कि हमने क्या बदला।

पहले कुछ शब्द

• Tokens वे टुकड़े हैं जो मॉडल पढ़ता है। सीमाएँ और खर्च अक्षरों या शब्दों में नहीं, tokens में गिने जाते हैं।
• Context window वह सबसे ज़्यादा है जो मॉडल एक request में पढ़ सकता है। हम हर request के लिए अपना कम budget भी तय करते हैं, ताकि खर्च और गति उचित रहे।
• Tool results वह हैं जो एजेंट को उसके tools से वापस मिलते हैं: किसी पढ़ी गई फ़ाइल की सामग्री, या चलाए गए command का आउटपुट। लंबे काम में यही सबसे ज़्यादा भेजा जाता है।
• Sub-agent वह सहायक है जिसे मुख्य एजेंट एक स्वतंत्र काम के लिए शुरू करता है, जैसे "इन अध्यायों को नोट्स से मिलाओ"। उसे एक निर्देश मिलता है, फिर वह अपने आप कई tool calls में काम करता है।

समस्या 1: sub-agents इतने बढ़ जाते थे कि मॉडल उन्हें मना कर देता था

हर कदम पर एजेंट मॉडल को अब तक की बातचीत भेजता है। जब वह बहुत बड़ी हो जाती, तो हमारा कोड उसे काटता था, लेकिन सिर्फ़ किसी user message की शुरुआत पर, ताकि tool call और उसका नतीजा कभी अलग न हों। वह पहला message रखता था, एक नोट जोड़ता था कि पुरानी बातचीत काटी गई, और सबसे नए पूरे turns रखता था जो फ़िट हों।

Sub-agent के पास ठीक एक user message होता है: उसका निर्देश। वहाँ काटने की कोई जगह नहीं थी। तो वह हर कदम पर पूरा इतिहास भेजता था, और वह हर बार बढ़ता जाता था, जब तक request उस आकार से बड़ी न हो जाए जिसे मॉडल बिल्कुल स्वीकार करता है: लगभग एक मिलियन tokens। 8 ऐसे sub-agents वाले एक test में, आठों मना कर दिए गए।

समाधान: पहले पुराने tool results साफ़ करो

अब request तीन चरणों में बजट के भीतर फ़िट होती है, और हर अगला तभी आज़माया जाता है जब पिछला काफ़ी न हो:

1. सबसे पुराने tool results साफ़ करो। उनकी सामग्री एक छोटे नोट से बदल दी जाती है: नतीजा मॉडल की context के भीतर रखने के लिए साफ़ किया गया, और एजेंट चाहे तो tool फिर से चला सकता है। एक घंटे पहले पढ़ी गई फ़ाइल आम तौर पर request की सबसे बड़ी और सबसे कम उपयोगी चीज़ होती है, और फ़ाइल फिर पढ़ी जा सकती है। सबसे नए नतीजे पूरे रहते हैं।
2. पूरे user turns रखो। पहले की तरह: पहला message, एक नोट, और सबसे नए पूरे turns जो फ़िट हों।
3. पूरे tool rounds रखो। एक लंबे turn के भीतर, यानी वही प्रकार जो sub-agent के पास होता है, पहला message, एक नोट, और सबसे नए पूरे rounds रखो: "एक tool कॉल करो, उसका नतीजा पाओ"।

यह सिर्फ़ यह तय करता है कि क्या भेजा जाए। एजेंट का सेव किया हुआ इतिहास सब कुछ रखता है। उसी test में, 8 में से 0 मना हुए और सभी 8 पूरे हुए।

बैच में साफ़ करना, ताकि caching काम करे

Model providers किसी request की शुरुआत का काम दोबारा इस्तेमाल कर सकते हैं, अगर वह पिछली request से हूबहू मेल खाए। इसे prefix cache कहते हैं। अगर हम हर कॉल पर एक और नतीजा साफ़ करते, तो request की शुरुआत हर कॉल पर बदल जाती, और cache कभी मदद न करता।

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

मना होने पर अब साफ़ बताया जाता है

जिस request को मॉडल अमान्य कहकर ठुकराता है, उसे अब दोबारा नहीं भेजा जाता; वही request वही जवाब पाएगी। अगर बातचीत मॉडल के लिए बहुत लंबी हो जाए, तो व्यक्ति को दिखता है: "यह बातचीत मॉडल एक बार में पढ़ने के लिए बहुत लंबी हो गई। अगले कदम के लिए नया चैट शुरू करें — अब तक बना सब कुछ रहेगा।" यह व्यक्ति के करने की बात है, कोई outage नहीं, इसलिए यह हमें पेज नहीं करता।

समस्या 2: एजेंट "जगह बचाने" के लिए रुक जाता था

एक sub-agent से 40 लंबे अध्याय पढ़ने को कहा गया, वह 2 के बाद रुक गया, यह कहते हुए कि उसे जगह बचानी है। उसने 400,000 tokens के बजट में लगभग 100,000 tokens इस्तेमाल किए थे।

उसे पता नहीं था कि अब उसके लिए पुराने नतीजे साफ़ होंगे। तो हमने उसे बताया। एजेंट के निर्देश अब कहते हैं कि जब बातचीत मॉडल की क्षमता से बढ़ जाए, तो सबसे पुराने tool results साफ़ होते हैं और सबसे नए पूरे रहते हैं, इसलिए लंबा काम जगह बचाने के लिए न रोकें; आगे बढ़ते रहें, और जो साफ़ हुआ उसकी ज़रूरत हो तो फ़ाइल दोबारा पढ़ें।

जो फ़िक्स मॉडल को दिखता नहीं, वह मॉडल की नज़र से फ़िक्स नहीं है। यह तंत्र तभी मदद करता है जब एजेंट उस पर भरोसा करे।

समस्या 3: tokens ऐसे गिनना जैसे सब कुछ अंग्रेज़ी हो

हम tokenizer चलाए बिना tokens का अनुमान लगाते थे: अक्षर ÷ 4। अंग्रेज़ी के लिए यह ठीक-ठाक नियम है। बाकी लिपियों के लिए नहीं: रूसी लगभग 2.2 अक्षर प्रति token चलती है, और चीनी या जापानी लगभग एक।

तो रूसी अध्याय पढ़ता एक sub-agent लगभग 640,000 tokens की request भेज रहा था, जबकि हमारा अनुमान कहता था कि वह 400,000 के बजट के नीचे है। यही अनुमान उतनी ही आसानी से request को मॉडल की कठोर सीमा से भी ऊपर भेज सकता था।

अनुमान अब लिपि के हिसाब से गिनता है: सादा ASCII 4 अक्षर प्रति token, चीनी, जापानी और कोरियाई 1 पर, और बाकी सब, यानी Cyrillic, Greek, Arabic, accented अक्षर और emoji, 2 पर। यह जानबूझकर ज़्यादा अनुमान लगाने की ओर झुका है। एक रूसी अध्याय पर अब यह 43,423 tokens का अनुमान देता है, जबकि मापा गया लगभग 44,600 था; पहले यह 25,023 कहता था। चूँकि एक message लिखे जाने के बाद कभी नहीं बदलता, उसका अनुमान एक बार निकाला जाता है और याद रखा जाता है, हर कदम पर नहीं।

हमने क्या सीखा

• आकार जहाँ है वहीं काटें। एजेंट के काम में वह tool results में है, user messages में नहीं।
• एजेंट को उसकी अपनी सुरक्षा जालों के बारे में बताएँ। वरना वह उन सीमाओं के हिसाब से योजना बनाता है जो अब लागू नहीं होतीं।
• "अक्षर ÷ 4" एक अंग्रेज़ी धारणा है। जो भी बहुभाषी उपयोगकर्ताओं के लिए tokens गिनता है, उसे लिपि के हिसाब से गिनना होगा, या एक असली tokenizer इस्तेमाल करना होगा।
• Cache का ध्यान रखें। जो request हर कॉल पर शुरुआत में बदलती है, वह ज़्यादा खर्च और धीमी चलती है।

अगर आप अपने ऐप में AI फ़ीचर जोड़ रहे हैं, तो LLM क्या है और LLM APIs कैसे इस्तेमाल करें गाइड शुरुआत से context windows और tokens को समझाती हैं। Mythex में sub-agents कैसे काम करते हैं, इस पर और sub-agents docs में है।