आपका LLM-संचालित एजेंट डेमो में तो बिल्कुल सही चल सकता है, लेकिन कुछ ही चरणों (turns) के बाद इसकी गति धीमी हो सकती है और इसका बिल बढ़ सकता है। इसका छिपा हुआ कारण कोई अस्थिर मॉडल नहीं है—बल्कि यह token drift है, यानी प्रॉम्प्ट का वह क्रमिक विस्तार (gradual bloat) जिसे मॉडल को हर बार प्रोसेस करना पड़ता है।

Token drift तब होता है जब हर बातचीत मॉडल के इनपुट कॉन्टेक्स्ट (input context) में और अधिक टेक्स्ट जोड़ देती है। बातचीत का इतिहास, टूल स्कीमा, API रिस्पॉन्स और रिट्रीव किए गए दस्तावेज़ सब जमा होते जाते हैं, जिससे प्रत्येक अगले कॉल में डेटा का भार (payload) बढ़ जाता है। चूंकि इनपुट टोकन की संख्या के साथ मॉडल का प्रोसेसिंग समय और कीमत बढ़ती है, इसलिए लागत रैखिक (linearly) के बजाय चतुर्घातीय (quadratically) रूप से बढ़ती है।

यह समस्या प्रोडक्शन में क्यों दिखाई देती है, डेमो में क्यों नहीं

वास्तविक डिप्लॉयमेंट सब कुछ सुरक्षित रखते हैं: उपयोगकर्ता का हर शब्द, हर टूल का आउटपुट, रिट्रीव किए गए ज्ञान का हर हिस्सा। यह संचय तब तक छिपा रहता है जब तक कि लेटेंसी (latency) अचानक न बढ़ जाए और बिल न आ जाए।

Token drift के सामान्य स्रोत

  • दोहराए गए ट्रांसक्रिप्ट (Repeated transcripts) – पुराने संदेशों को सारांशित (summarize) करने या हटाने के बजाय उन्हें प्रॉम्प्ट में ही बनाए रखना।
  • भारी टूल स्कीमा (Heavy tool schemas) – हर टर्न पर टूल की क्षमताओं के बड़े JSON डेफिनिशन भेजना।
  • भारी टूल परिणाम (Bulky tool results) – पूरे API रिस्पॉन्स या डेटाबेस की पंक्तियों (rows) को शामिल करना, जिनमें एजेंट की वास्तविक आवश्यकता से अधिक डेटा होता है।
  • RAG bloat – Retrieval-augmented generation (RAG) जो कई दस्तावेज़ों के टुकड़े (chunks) जोड़ देता है, जिनमें से कुछ पुराने या अप्रासंगिक हो सकते हैं।
  • डुप्लिकेट मेमोरी (Duplicated memory) – एक सारांश, एक स्टेट ऑब्जेक्ट और कच्चे ट्रांसक्रिप्ट को एक साथ पैक करना, जिससे एक ही जानकारी तीन बार दोहराई जाती है।

इनमें से प्रत्येक ऐसे टोकन जोड़ता है जो नई तर्क शक्ति (reasoning power) में योगदान नहीं देते, फिर भी वे प्रॉम्प्ट के आकार को बढ़ा देते हैं।

टोकन बजट को नियंत्रण में कैसे रखें

1. लेयर्ड कॉन्टेक्स्ट डिज़ाइन (Layered context design) अपनाएं

  • स्थिर निर्देश (Stable instructions) – सिस्टम प्रॉम्प्ट और सुरक्षा नियमों को सबसे ऊपर रखें और उन्हें हर टर्न पर दोबारा भेजने के बजाय केवल उनका संदर्भ (reference) दें।
  • स्ट्रक्चर्ड स्टेट (Structured state) – लक्ष्यों, निर्णयों और पहचानकर्ताओं (identifiers) का एक संक्षिप्त रूप स्टोर करें जिसे एजेंट जल्दी से पढ़ सके।
  • कंप्रेस्ड हिस्ट्री (Compressed history) – पुराने टर्न्स को एक छोटे, मानव-पठनीय पैराग्राफ में सारांशित करें, और इसे केवल तभी अपडेट करें जब कोई सीमा (threshold) पार हो जाए।
  • हालिया टर्न्स (Recent turns) – निरंतरता बनाए रखने के लिए पिछले कुछ संदेशों को शब्दशः (verbatim) शामिल करें।

स्थिर टेक्स्ट को सारांशित करने योग्य सामग्री से अलग करने से आप बार-बार एक ही शब्दों को भेजने से बच जाते हैं।

2. टूल आउटपुट को कम करें (Trim tool outputs)

  • केवल उन्हीं फ़ील्ड्स को निकालें जिनका एजेंट वास्तव में उपयोग करता है; विस्तृत विवरण (verbose descriptions) हटा दें।
  • बड़े परिणामों को एक संक्षिप्त सारांश या रेफरेंस ID से बदलें, और पूरे पेलोड को डेटाबेस, कैश या ब्लब स्टोर (blob store) में स्टोर करें।
  • जब कोई टूल एक सूची (list) लौटाता है, तो केवल शीर्ष-N आइटम भेजें जो वर्तमान निर्णय के लिए महत्वपूर्ण हों।

3. स्मार्ट सारांश (Smart summarization) लागू करें

  • हर टर्न के बाद सारांश बनाने से बचें; अतिरिक्त प्रोसेसिंग से ओवरहेड बढ़ता है।
  • सारांश को केवल तभी रिफ्रेश करें जब पुराने टर्न्स की संचित टोकन संख्या (accumulated token count) एक पूर्व-निर्धारित सीमा को पार कर जाए।
  • महत्वपूर्ण तथ्यों—जैसे ID, राशि, टाइमस्टैम्प—को गद्य (prose) में शामिल करने के बजाय एक स्ट्रक्चर्ड स्टोर में रखें, ताकि सारांश छोटा बना रहे।

4. सही मेट्रिक्स (Metrics) ट्रैक करें

  • टोकन उपयोग को केवल प्रति उपयोगकर्ता अनुरोध (per user request) नहीं, बल्कि प्रति मॉडल कॉल (per model call) लॉग करें। इससे इनपुट की ओर होने वाली छिपी हुई वृद्धि का पता चलता है।
  • हर टर्न में जोड़े गए इनपुट टोकन की संख्या की निगरानी करें; अचानक उछाल 'ड्रिफ्ट' के स्रोत की ओर इशारा करता है।
  • कैश किए गए टोकन (पिछले कॉल्स से पुन: उपयोग किए गए) को नए उत्पन्न टोकन से अलग करें; केवल पहले वाले ही ड्रिफ्ट का कारण बनते हैं।

प्रॉम्प्ट को एक सीमित संसाधन के रूप में मानें, न कि एक अनंत ट्रांसक्रिप्ट के रूप में। सावधानीपूर्वक मापकर, सारांशित करके और ट्रिम करके, आप अपने LLM एजेंट को तेज़, किफायती और प्रोडक्शन स्केल के लिए तैयार रखते हैं।

निष्कर्ष (Takeaway): Token drift चुपचाप लागत बढ़ाता है और एजेंटों की गति धीमी करता है। अपने प्रॉम्प्ट के बढ़ते हुए हिस्सों की पहचान करें, उन्हें कंप्रेस या एक्सटर्नलाइज़ करें, और प्रति कॉल टोकन उपयोग पर नज़र रखें। एक अनुशासित दृष्टिकोण अप्रत्याशित बिल के झटकों को एक प्रबंधनीय और बजट के अनुकूल ऑपरेशन में बदल देता है।