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

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

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

GPT-4o के टोकनाइज़र से मापने पर unbelievable शब्द अकेला खड़ा हो तो तीन टोकन बनता है: un + bel + ievable। लेकिन वाक्य में जैसा वह असल में आता है — अपने आगे लगे स्पेस के साथ — वैसे लिखने पर वह एक ही टोकन है: unbelievable। यह आगे लगे स्पेस वाले नियम का असर है: मॉडल ने जो एंट्री सीखी है वह स्पेस लगे रूप की है, क्योंकि चलती हुई भाषा में यह शब्द लगभग हमेशा इसी तरह आता है। the और international भी ऐसे ही बर्ताव करते हैं — स्पेस जुड़ा हो तो एक-एक टोकन।

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

अंग्रेज़ी गद्य के लिए, GPT-4o के टोकनाइज़र से बोलचाल के लेखन से लेकर तकनीकी संदर्भ-सामग्री तक अलग-अलग शैलियों पर मापा गया:

• 1 टोकन ≈ 4.3–5.9 अक्षर
• 1 टोकन ≈ 0.75–0.95 शब्द
• 1,000 शब्द ≈ 1,050–1,350 टोकन
• एक मानक पेज (~500 शब्द) ≈ 530–680 टोकन

शैली का असर अनुमान के ज़्यादातर नियमों में जितना माना जाता है, उससे कहीं ज़्यादा होता है। हल्का-फुल्का, बोलचाल जैसा लेखन इस दायरे के निचले सिरे के पास बैठता है — प्रति हज़ार शब्द करीब 1,060 टोकन — क्योंकि उसमें आम शब्दों की एक छोटी-सी शब्दावली बार-बार लौटती है और उनमें से हर शब्द एक ही टोकन में समा जाता है। सघन तकनीकी गद्य — जिसमें खुद इसी साइट की गाइड भी शामिल हैं — ऊपरी सिरे के पास बैठता है, करीब 1,310, क्योंकि विशेषज्ञ शब्द टुकड़ों में बँट जाते हैं। प्रति हज़ार शब्द 1,300 टोकन वाला चिर-परिचित इकहरा आँकड़ा इस दायरे का तकनीकी सिरा है, बीच नहीं, इसलिए वह सामान्य लेखन को करीब पाँचवें हिस्से जितना ज़्यादा आँकता है। कॉन्टेक्स्ट विंडो का बजट बनाते समय गलती की यही दिशा सुरक्षित है।

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

सामग्री का प्रकार	लगभग
अंग्रेज़ी गद्य	0.75–0.95 शब्द प्रति टोकन, शैली के अनुसार
कोड	प्रति अक्षर गद्य से करीब 1.2 गुना टोकन, और एक ही बात दोनों तरह से कहने पर करीब 1.5 गुना
लंबी keys वाला JSON	बहुत ज़्यादा — विराम चिह्न और कोट अलग-अलग टोकन होते हैं
चीनी, जापानी, कोरियाई	करीब 0.6–0.7 टोकन प्रति अक्षर — यानी एक अक्षर पर एक टोकन से भी कम, फिर भी उतने ही अक्षरों पर अंग्रेज़ी से कई गुना ज़्यादा
सिरिलिक, देवनागरी, अरबी	एक ही सामग्री के लिए अंग्रेज़ी से करीब 1.4–1.6 गुना
URL और हैश	बेहद ज़्यादा — बेतरतीब स्ट्रिंग खराब टोकनाइज़ होती हैं
दोहराया गया स्पेस	महँगा नहीं, सस्ता — byte-pair encoding लंबे सिलसिलों को जोड़ देती है, इसलिए लगातार चालीस स्पेस मिलकर एक टोकन बनते हैं

बहुभाषी अंतर असली है, लेकिन लोककथाओं में जितना बताया जाता है उससे कहीं छोटा। इसी साइट के अंग्रेज़ी पेजों की उनके पेशेवर अनुवादों से तुलना करने पर जापानी संस्करण की लागत अंग्रेज़ी से करीब 1.7 गुना निकली, कोरियाई की करीब 1.5 गुना, चीनी की करीब 1.2 गुना, हिंदी की करीब 1.6 गुना और अरबी की करीब 1.4 गुना। पुराने cl100k_base टोकनाइज़र पर यही जोड़े क्रमशः 2.3, 2.3, 1.7, 4.7 और 2.9 गुना पड़ते थे — "अंग्रेज़ी से दो-तीन गुना" वाला आँकड़ा, जो हर जगह दोहराया जाता है, वहीं से आया है। तब वह सही था; नई शब्दावलियों ने यह अंतर काफ़ी हद तक पाट दिया है।

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

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

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

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

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

हमारा Token Counter GPT-4o की गिनती और Claude का अनुमान साथ-साथ दिखाता है। GPT-4o वाली संख्या असली टोकनाइज़र से निकली गिनती है। Claude वाली संख्या जानबूझकर नहीं है: Anthropic ने ऐसा कोई टोकनाइज़र सार्वजनिक नहीं किया है जिसे हम आपके ब्राउज़र में चला सकें, इसलिए वह प्रति 3.5 अक्षर एक टोकन के हिसाब से लगाया गया अक्षर-आधारित अनुमान है। अंग्रेज़ी गद्य पर यह अनुमान GPT-4o की गिनती से 22–50% ऊपर बैठता है — सामान्य लेखन में करीब एक-तिहाई ज़्यादा — इसलिए इस फ़ासले को अनुमान की चौड़ाई मानें, दोनों मॉडल परिवारों के बीच मापा गया अंतर नहीं। फिर भी यह जोड़ी इतना बता देने के लिए काफ़ी है कि प्रॉम्प्ट लिमिट के भीतर आराम से है या खतरनाक रूप से करीब; और जब संख्या बिल्कुल सटीक चाहिए, तो प्रोवाइडर का अपना काउंटर इस्तेमाल करें।

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

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

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

रिट्रीवल के लिए चंकिंग। एम्बेडिंग के लिए दस्तावेज़ बाँटना टोकन में होता है, अक्षरों में नहीं। अक्षर गिनती से बने चंक असंगत होते हैं, और बीच-वाक्य से कटे चंक खराब रिट्रीव होते हैं, इसलिए रिट्रीवल पाइपलाइन को ऐसा स्प्लिटर चाहिए जो वाक्य और पैराग्राफ की संरचना का ध्यान रखे। हमारा Text Splitter वह टूल नहीं है: यह ज़्यादा से ज़्यादा 2,000 अक्षरों के तय आकार वाले हिस्से काटता है और कट सबसे नज़दीकी व्हाइटस्पेस पर लगाता है, ताकि कोई शब्द बीच से न टूटे — यानी कोई हिस्सा वाक्य के बीच में भी खत्म हो सकता है। इसे लंबे दस्तावेज़ को कॉन्टेक्स्ट विंडो या पेस्ट की सीमा से गुज़ारने के लिए इस्तेमाल करें — रिट्रीवल के लिए एम्बेडिंग चंक बनाने के लिए नहीं।

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

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

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