जब बातचीत या दस्तावेज़ मॉडल के लिए बहुत लंबा हो जाए

छोटा जवाब

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

चार चीज़ें आपको सीधे अस्वीकार करती हैं, और हर एक अपना नाम खुद बताती है:

मैसेज	HTTP कोड	ट्रिगर
This message is {count} characters, over the 100,000 character limit. Attach a shorter file, or ask about one section at a time.	400 message_too_long	एक मैसेज, आपकी फाइलों से निकाला गया टेक्स्ट शामिल करते हुए, 100,000 कैरेक्टर से ज़्यादा है
This conversation has {count} messages, over the 100 message limit.	400 too_many_messages	एक ही रिक्वेस्ट में 100 से ज़्यादा मैसेज का ट्रांसक्रिप्ट भेजा गया
Request is too large.	413 request_too_large	पूरा JSON रिक्वेस्ट बॉडी रूट की बाइट सीमा से बड़ा हो गया
That system prompt is missing or over the 32,000 character limit.	400 invalid_system_prompt	सिस्टम प्रॉम्प्ट 32,000 कैरेक्टर से ज़्यादा

कैरेक्टर लिमिट वाली स्ट्रिंग में {count} की जगह आपकी असली संख्या भरी जाती है, जो थाउज़ेंड सेपरेटर के साथ फ़ॉर्मेट होती है। हर स्ट्रिंग के साथ दिया कोड नेटवर्क ट्रेस में दिखता है, भले ही इंटरफेस में सिर्फ वाक्य दिखे।

अगर आपने कोई ऐसा मैसेज देखा जो कॉन्टेक्स्ट लेंथ या टोकन काउंट का नाम लेता है, तो वह Whizi से नहीं आया। सीधे आखिरी सेक्शन पर जाइए।

हर मॉडल को मिलने वाला बजट, और उसके पार जाने पर क्या होता है

कैटलॉग का हर मॉडल एक टर्न के लिए एक जैसा बजट पाता है: 40,000 इनपुट टोकन और 20,000 आउटपुट टोकन। कनाडाई CPA एजेंट अकेला अपवाद है, जिसे 55,000 इनपुट टोकन और 40,000 आउटपुट टोकन मिलते हैं।

जब बातचीत उस बजट से आगे निकल जाती है, तो बैकएंड इतिहास को मॉडल के टोकन बजट तक चुपचाप छोटा कर देता है, अस्वीकार करने के बजाय। इसके लिए कोई टोस्ट, कोई बैनर और कोई एरर कोड नहीं है।

Whizi जिस टोकन काउंट के आधार पर छोटा करता है वह एक अनुमान है, असली टोकनाइज़र नहीं। यह JSON पर असली टोकनाइज़र से 1.66 गुना तक कम गिन सकता है, इसलिए सबसे बुरी नापी गई स्थिति को कवर करने के लिए इनपुट पर 1.8 गुना की छूट लागू की जाती है।

बड़े कॉन्टेक्स्ट वाले मॉडल पर स्विच करना ज़्यादा नहीं भेजता

यह सबसे आम गलत तरीका है। 40,000 टोकन का इनपुट बजट स्थिर है: यह उतना ही रहता है चाहे मॉडल की विंडो दस लाख टोकन की हो या 2,00,000 टोकन की। एक लंबी बातचीत को एक बड़ी विंडो वाले मॉडल से दूसरे बड़ी विंडो वाले मॉडल पर ले जाने से यह नहीं बदलता कि उसमें से कितना हिस्सा भेजा जाता है।

कॉन्टेक्स्ट विंडो का साइज़ बजट को सिर्फ एक दिशा में बदलता है, नीचे की तरफ। जिस भी मॉडल की विंडो 93,000 टोकन से कम है उसे स्थिर बजट के बजाय एक छोटा, आनुपातिक बजट मिलता है, जिसमें आउटपुट विंडो के 40 प्रतिशत तक सीमित रहता है और 1,000 टोकन की सुरक्षा मार्जिन रोकी जाती है। कैटलॉग के 31 मॉडल इस तरह सीमित हैं, और इनमें सबसे छोटी विंडो 6,144 टोकन की है।

तो जो स्विच असल में मदद करता है वह उससे उल्टा है जो लोग आज़माते हैं: किसी छोटे, सीमित मॉडल से हटकर एक सामान्य मॉडल पर जाना। दो बड़ी विंडो वाले मॉडल के बीच बदलाव लंबाई पर कोई असर नहीं डालता। बातचीत के बीच में मॉडल बदलने पर क्या होता है, यह बातचीत के बीच मॉडल बदलना में बताया गया है।

93,000 के आंकड़े के पीछे एक और बात, जानने लायक है अगर आप सोच रहे हैं कि किसी छोटी सी चीज़ को मॉडल ने क्यों अस्वीकार किया: OpenRouter मॉडल की विंडो के आगे इनपुट के साथ-साथ मांगा गया अधिकतम आउटपुट भी गिनता है, सिर्फ इनपुट नहीं।

लंबे अपलोड को काटा जाता है, और यह आपको बताता है

अपलोड आम तौर पर वह वजह होते हैं जिससे एक मैसेज 100,000 कैरेक्टर से आगे निकल जाता है, क्योंकि PDF, Word और स्प्रेडशीट फाइलें आपके ब्राउज़र में टेक्स्ट में निकाली जाती हैं और वह टेक्स्ट उसी सीमा में गिना जाता है जिसमें आपका टाइप किया हुआ कुछ भी गिना जाता है।

जब निकाला गया टेक्स्ट फिट नहीं बैठता, तो उसे अस्वीकार करने के बजाय छोटा किया जाता है, और दो स्ट्रिंग दिखती हैं। टोस्ट में लिखा होता है Your upload was too large, so only the first part of it was sent. Ask about a smaller section for full coverage. मैसेज में खुद कटे हुए हिस्से पर यह मार्कर होता है [Attachment truncated: the upload was larger than one message can carry, so the content past this point was not included.], ताकि मॉडल देख सके कि उसकी कॉपी कहां रुकती है।

अगर मैसेज को छोटा करने के बजाय अस्वीकार कर दिया जाता है, तो आपको पहली टेबल वाली message_too_long स्ट्रिंग मिलती है। इसका समाधान वही है जो एरर खुद बताता है: छोटी फाइल अटैच करें, या एक बार में एक सेक्शन के बारे में पूछें।

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

लागत से जुड़ी एक बात, क्योंकि लंबाई इससे तय करती है कि एक टर्न की कीमत क्या है। Auto पर, लगभग 6,000 कैरेक्टर से बड़ा मैसेज लॉन्ग-फॉर्म पायदान पर 4 क्रेडिट में रूट होता है, इस तर्क पर कि इतना लंबा मैसेज कोई सवाल नहीं बल्कि एक पेस्ट किया गया दस्तावेज़ है। छोटा सवाल क्विक पायदान पर 1 क्रेडिट में रूट होता है। क्रेडिट स्केल क्रेडिट कैसे काम करते हैं में है।

पिन किए गए प्रोजेक्ट फाइलों की कीमत हर टर्न पर प्रॉम्प्ट में जुड़ती है

पिन की गई प्रोजेक्ट फाइल उस प्रोजेक्ट के हर एक टर्न पर प्रॉम्प्ट टेक्स्ट की तरह साथ चलती है, एक बार नहीं, यही वजह है कि इमेज को जानबूझकर पिन की जा सकने वाली फाइल टाइप्स से बाहर रखा गया है।

सीमाएं अपनी अलग हैं: हर पिन की गई फाइल ज़्यादा से ज़्यादा 32,000 कैरेक्टर का निकाला हुआ टेक्स्ट देती है, और पूरा प्रोजेक्ट ब्लॉक ज़्यादा से ज़्यादा 10 पिन की गई फाइलों में 120,000 कैरेक्टर तक सीमित है। प्रोजेक्ट कस्टम इंस्ट्रक्शन 32,000 कैरेक्टर तक हो सकते हैं।

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

अगर आपने कोई कॉन्टेक्स्ट लेंथ एरर देखा

तो वह Whizi से नहीं, मॉडल प्रोवाइडर से आया, और वह पासथ्रू के ज़रिए आप तक पहुंचा। कोई भी अपस्ट्रीम फेलियर जो रेट लिमिट न हो, HTTP 502 के साथ provider_error कोड में लौटाया जाता है, जिसमें प्रोवाइडर का मैसेज 300 कैरेक्टर तक काटकर शामिल होता है। जब प्रोवाइडर एरर बॉडी को बिल्कुल भी पार्स नहीं किया जा सकता, तो आपको इसके बजाय The model provider rejected the request. मिलता है।

लंबाई पर प्रोवाइडर की अस्वीकृति एक कॉन्टेक्स्ट लेंथ और एक टोकन काउंट का नाम लेगी। ये नंबर बताते हैं कि प्रोवाइडर आपकी रिक्वेस्ट को Whizi द्वारा भेजी गई विंडो से छोटी विंडो के आगे गिन रहा है, और सपोर्ट को देखने के लिए ठीक यही चाहिए होता है।

कोई इंटरफेस सेटिंग इसे नहीं बदलती। अपना जवाब पाने के लिए किसी दूसरे मॉडल पर स्विच कीजिए, और सपोर्ट को वे नंबर शामिल करते हुए ठीक वही मैसेज भेजिए।

दो और स्ट्रिंग हैं जिन्हें लोग लंबाई की समस्या समझ लेते हैं। Generation failed mid-stream. और The model stream was interrupted. जवाब के बीच में होने वाली कनेक्शन फेलियर हैं, लंबाई की अस्वीकृति नहीं। इन्हें दोबारा आज़माइए। Too many requests. Please wait and try again. एक रेट लिमिट है, प्रति मिनट 10 मैसेज पर, जिसका लंबाई से कोई लेना-देना नहीं है।