मेरा प्रॉम्प्ट कितने टोकन का है?

भाषा मॉडल अक्षर या शब्द नहीं पढ़ते। वे टोकन पढ़ते हैं: ऐसे टुकड़े जो ट्रेनिंग डेटा से सीखी गई एक तय शब्दावली के हिसाब से टेक्स्ट को तोड़कर बनते हैं।

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

unbelievable जैसा शब्द एक टोकन नहीं है — यह संभवतः Un + believ + able जैसे टुकड़ों में बँट जाता है। वहीं the एक टोकन है, और international भी, क्योंकि यह ट्रेनिंग में इतनी बार आया कि इसे अपनी अलग एंट्री मिल गई।

इसीलिए टोकन की गिनती अनूठी लगती है। यह इकाई भाषिक नहीं, सांख्यिकीय है। ट्रेनिंग कॉर्पस में किसी चीज़ की आवृत्ति तय करती है कि वह एक टोकन होगी या चार।

अंग्रेज़ी गद्य के लिए:

• 1 टोकन ≈ 4 अक्षर
• 1 टोकन ≈ 0.75 शब्द
• 1,000 शब्द ≈ 1,300 टोकन
• एक मानक पेज (~500 शब्द) ≈ 650 टोकन

सामान्य गद्य से बाहर ये नियम जल्दी टूट जाते हैं:

सामग्री का प्रकार	लगभग
अंग्रेज़ी गद्य	0.75 शब्द प्रति टोकन
कोड	समतुल्य गद्य से 2–3 गुना ज़्यादा टोकन
लंबी keys वाला JSON	बहुत ज़्यादा — विराम चिह्न और कोट अलग-अलग टोकन होते हैं
चीनी, जापानी, कोरियाई	अक्सर 1–2 टोकन प्रति अक्षर
सिरिलिक, देवनागरी, अरबी	समान अर्थ के लिए अंग्रेज़ी से आमतौर पर 2–3 गुना
URL और हैश	बेहद ज़्यादा — बेतरतीब स्ट्रिंग खराब टोकनाइज़ होती हैं
दोहराया गया स्पेस	हर सिलसिला अपना अलग टोकन हो सकता है

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

हर मॉडल परिवार अपने टोकनाइज़र और अपनी शब्दावली इस्तेमाल करता है, इसलिए एक ही टेक्स्ट की गिनती अलग-अलग आती है।

GPT मॉडल byte-pair encoding के वेरिएंट इस्तेमाल करते हैं — GPT-4 युग के मॉडलों के लिए cl100k_base और नए मॉडलों के लिए o200k_base। Claude एक अलग टोकनाइज़र और अलग शब्दावली इस्तेमाल करता है। Llama और Mistral जैसे ओपन मॉडलों के भी अपने-अपने टोकनाइज़र हैं।

एक ही अंग्रेज़ी टेक्स्ट पर परिवारों के बीच 10–20% का अंतर सामान्य है, और कोड व गैर-अंग्रेज़ी टेक्स्ट पर यह अंतर और बढ़ जाता है, जहाँ शब्दावलियाँ सबसे ज़्यादा अलग होती हैं।

व्यावहारिक रूप से इसका मतलब:

• किसी एक टोकनाइज़र की गिनती दूसरे मॉडल के लिए सिर्फ़ एक अनुमान है।
• सटीक संख्या सिर्फ़ प्रोवाइडर का अपना टोकनाइज़र ही देता है, उसी के हिसाब से बिलिंग होती है।
• लिमिट के बिल्कुल करीब फिट करने के बजाय कुछ मार्जिन छोड़कर बजट बनाएँ।

हमारा Token Counter GPT-4o की गिनती और Claude का अनुमान साथ-साथ दिखाता है, जिससे आमतौर पर यह पता चल जाता है कि प्रॉम्प्ट लिमिट के भीतर आराम से है या खतरनाक रूप से करीब।

लागत। API की कीमत प्रति टोकन होती है, इनपुट और आउटपुट की अलग-अलग दरें होती हैं, और आउटपुट आमतौर पर कई गुना महँगा होता है। सिस्टम प्रॉम्प्ट दोगुना करने से हर कॉल की वह लागत दोगुनी हो जाती है — ऐसी चीज़ जो टेस्टिंग में नहीं दिखती लेकिन बड़े पैमाने पर महँगी पड़ती है।

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

कटौती (Truncation)। जब इनपुट लिमिट से ज़्यादा हो जाता है, तो कुछ हटा दिया जाता है — अक्सर चुपचाप, और अक्सर सबसे पुरानी सामग्री। जो मॉडल आपके निर्देश "भूल" गया, अक्सर उन निर्देशों को ही काट दिया गया होता है।

रिट्रीवल के लिए चंकिंग। एम्बेडिंग के लिए दस्तावेज़ बाँटना टोकन में होता है, अक्षरों में नहीं। अक्षर गिनती से बने चंक असंगत होते हैं, और बीच-वाक्य से कटे चंक खराब रिट्रीव होते हैं। लंबे टेक्स्ट को काम के हिस्सों में बाँटने के लिए Text Splitter शब्द के बीच से नहीं, पैराग्राफ की सीमा के पास कट लगाता है।

सबसे असरदार तरीके, लगभग इसी क्रम में:

1. बातचीत का इतिहास घटाएँ। लंबी चैट में यही सबसे बड़ा हिस्सा होता है। पुराने दौरों को जस का तस दोबारा भेजने के बजाय उनका सारांश भेजें।
2. दोहराए गए निर्देश हटाएँ। किसी नियम को तीन तरह से दोहराने से वह तीन गुना ज़्यादा माना नहीं जाता। लेकिन उस नियम की लागत तीन गुना ज़रूर हो जाती है।
3. फ़ॉर्मैटिंग के अवशेष हटाएँ। अदृश्य अक्षर, दोहराया स्पेस और सजावटी विभाजक लाइनें — सब टोकनाइज़ होते हैं, और चालीस हाइफ़न वाली लाइन ऊपर के वाक्य से ज़्यादा महँगी हो सकती है। Remove Invisible Characters उन्हें साफ़ करता है जो दिखते नहीं।
4. संरचित प्रॉम्प्ट में JSON keys छोटी करें। {"n": ...} बनाम {"customer_full_name": ...} — हज़ार रिकॉर्ड पर गुणा करने से बहुत बड़ा अंतर बन जाता है।
5. सिर्फ़ ज़रूरी अंश भेजें। पूरा दस्तावेज़ पेस्ट करने से बेहतर है तीन प्रासंगिक पैराग्राफ खोजकर भेजना — इससे सस्ते के साथ-साथ बेहतर जवाब भी मिलते हैं।

जो मदद नहीं करता: सामान्य विराम चिह्न हटाना, छोटे शब्द काटना या टेलीग्राफ़ की तरह कटी-कटी भाषा में लिखना। बचत मामूली होती है और आउटपुट की गुणवत्ता को नुकसान बहुत ज़्यादा।