Context Length Exceeded: अनुरोध छोटा करें और परिणाम जाँचें
हर context घटक मापें, सुरक्षित डुप्लिकेट और अप्रासंगिक इतिहास हटाएँ, उत्तर के लिए जगह रखें और सुनिश्चित करें कि जरूरी तथ्य न खोएँ।
विषय-सूची
Context Length Exceeded: अनुरोध छोटा करें और परिणाम जाँचें
Context length exceeded आने पर prompt का आधा हिस्सा अंदाज़े से हटाना सही उपाय नहीं है। पहले चुने हुए मॉडल और पूरे अनुरोध के घटकों का हिसाब लें। फिर यांत्रिक डुप्लिकेट, काम से बाहर हो चुका इतिहास और भारी tool results घटाएँ। दोबारा अनुरोध भेजने के बाद केवल त्रुटि का गायब होना नहीं, बल्कि जरूरी तथ्य और उत्तर की पूर्णता भी जाँचें।
BetterToken के मौजूदा API Docs खोलें, एक छोटा test request चलाएं और उसे Dashboard में खोजें। context घटाने से पहले और बाद के input, output और cache tokens मिलाएं; input tokens कम होना पुष्टि करता है कि fix असली call तक पहुँचा। Dashboard पूरा prompt नहीं दिखाता और भेजने से पहले की token counting का विकल्प नहीं है।
Context window में क्या शामिल होता है
Context केवल अंतिम user prompt नहीं, एक request की कार्यशील स्मृति है। सरल रूप में इसमें ये हिस्से होते हैं:
system instructions
+ conversation history
+ current message
+ images and documents
+ tool definitions
+ tool results
+ output / thinking budget
= total context usageAnthropic की context-window दस्तावेज़ीकरण में system prompt, सभी messages, images, documents, tool definitions, tool results और generated response शामिल हैं। Prompt caching दोबारा इस्तेमाल हुए tokens की लागत बदल सकता है, लेकिन उन्हें window से हटाता नहीं है।
किसी सार्वभौमिक सीमा को code में स्थिर न करें। Context window और overflow का व्यवहार मॉडल तथा API पर निर्भर है; configuration के दिन वर्तमान model card देखें।
सबसे भारी हिस्सा कैसे खोजें
| घटक | क्या मापें | सुरक्षित कमी |
|---|---|---|
| System instructions | दोहराए नियम और लंबे उदाहरण | समान नियम मिलाएँ, अनिवार्य सीमाएँ रखें |
| Conversation history | प्रत्येक message और पुरानी शाखा के tokens | अप्रासंगिक शाखा हटाएँ या जाँचने योग्य summary रखें |
| Files और RAG fragments | दस्तावेज़ आकार, डुप्लिकेट, कम-प्रासंगिक chunks | top_k घटाएँ, deduplicate करें, केवल जरूरी भाग दें |
| Tool definitions | इस चरण में न इस्तेमाल होने वाले tools | सिर्फ वर्तमान चरण के tools भेजें |
| Tool results | पूरा JSON, logs, HTML, base64, दोहराए responses | आवश्यक fields, links और identifiers रखें |
| Output budget | max_tokens और thinking budget | वास्तविक उत्तर के लिए जगह रखें या काम चरणों में बाँटें |
Claude का Token Counting API request भेजने से पहले messages और tools का हिसाब कर सकता है। दूसरे provider के लिए उसका अपना counter हो तो उसी का उपयोग करें। स्थानीय tokenizer प्रारंभिक चेतावनी दे सकता है, पर उसे किसी दूसरे model की server-side गिनती न मानें।
अर्थ बचाते हुए आकार घटाने का क्रम
1. यांत्रिक डुप्लिकेट हटाएँ
बार-बार आए system rules, एक ही file के कई message, duplicate RAG chunks, दोहराई schemas और पूरा log दोबारा चिपकाया गया है या नहीं देखें। इस चरण में काम का उद्देश्य नहीं बदलता, इसलिए यह सबसे सुरक्षित कमी है।
2. अप्रासंगिक इतिहास अलग करें
स्थायी तथ्यों को बातचीत की अस्थायी प्रक्रिया से अलग करें। लक्ष्य, स्वीकृत निर्णय, अनिवार्य constraints और खुले प्रश्न रखें। पुराना reasoning, अस्वीकार किए विकल्प और पहले संसाधित tool results हटाएँ या संरचित summary में बदलें।
“integration पर चर्चा हुई” जैसी summary पर्याप्त नहीं है। उपयोगी summary चुना endpoint, schema version, स्वीकृत constraints, पुष्टि किए तथ्य और अगला कदम दर्ज करती है।
3. Files, RAG और tool results को संक्षिप्त करें
पूरा document भेजने के बजाय संबंधित sections भेजें। Tool result में अगले चरण को चाहिए fields रखें, पूरा HTTP response या log नहीं। केवल request को फिट करने के लिए sources या अनिवार्य data न हटाएँ; ऐसे काम को कई जाँचने योग्य चरणों में बाँटना बेहतर है।
4. उत्तर के लिए जगह छोड़ें
Input और output कुल budget साझा करते हैं। यदि input लगभग पूरी window भर दे तो मॉडल पूरा उत्तर नहीं दे पाएगा। वैकल्पिक input घटाएँ, यथार्थवादी output budget तय करें या परिणाम को भागों में बाँटें। महत्वपूर्ण facts हटाने से पहले duplicate हटाएँ।
5. मापने के बाद ही model बदलें
जिस document को सुरक्षित रूप से बाँटना संभव नहीं है, उसके लिए बड़ा context वाला model उचित हो सकता है। लेकिन duplicates हटाए बिना बड़ी window पर जाना अगली समस्या को केवल आगे धकेलता है।
भेजने से पहले न्यूनतम जाँच
components = count_by_section(request)
estimated_input = sum(components)
reserved_output = requested_output_budget
if estimated_input + reserved_output approaches current_model_window:
remove exact duplicates
drop irrelevant history
compact tool results and retrieved chunks
count again
send only after required facts and constraints remain presentयहाँ approaches को किसी तय प्रतिशत से नहीं बदला गया है। आवश्यक headroom counter की accuracy, model, thinking और API के व्यवहार पर निर्भर करता है।
सुधार को कैसे सत्यापित करें
नए request को इस checklist से मिलाएँ:
- API अब
context length exceededयाprompt is too longन लौटाए। - उत्तर output budget के कारण बीच में कटने के बजाय सामान्य रूप से पूरा हो।
- उत्तर में सभी जरूरी facts, constraints और अपेक्षित format मौजूद हों।
- Quotes और links अभी भी दिए गए sources से मेल खाते हों।
- Tool calls सही arguments से हों और compaction में महत्वपूर्ण परिणाम न खोए हों।
- नया input usage पहले से वास्तव में कम हो।
त्रुटि चली जाए लेकिन मॉडल कोई मुख्य constraint भूल जाए, तो सुधार सफल नहीं है। अनिवार्य block वापस रखें और कम-प्रासंगिक history या भारी tool result से जगह निकालें। यदि उत्तर कट रहा है, output budget अलग से जाँचें—वह भी उसी कुल window का हिस्सा है।
निष्कर्ष और स्रोत
काम का क्रम है: model पहचानें → components गिनें → exact duplicates हटाएँ → अप्रासंगिक history निकालें → files और tool results संक्षिप्त करें → उत्तर के लिए जगह छोड़ें → फिर भेजें → गुणवत्ता जाँचें। इससे कारण पर काम होता है और context मनमाने ढंग से काटे गए तथ्यों का ढेर नहीं बनता।
