BPE (Byte Pair Encoding) टोकनाइजेशन में व्हाइटस्पेस और विराम चिह्न सामान्य अक्षरों की तरह ही टोकन बनने का हिस्सा होते हैं, लेकिन उनकी स्थिति और आस-पास के अक्षर यह तय करते हैं कि वे किसी शब्द के साथ जुड़ेंगे या अलग टोकन बनेंगे। इसी वजह से "Hi!" और "Hi !" के टोकन विभाजन अलग-अलग हो सकते हैं, जिससे टोकन संख्या और उसके आधार पर API लागत भी बदल सकती है। नीचे हम इसे क्रम से, ठोस उदाहरणों के साथ समझते हैं।
BPE टोकनाइजेशन की मूल बातें
BPE एक डेटा-संचालित विधि है जिसमें टोकनाइजर पहले टेक्स्ट को छोटी इकाइयों में तोड़ता है और फिर बार-बार सबसे अधिक मिलने वाले जोड़े (pair) को एक नए टोकन में मिला देता है। शुरुआत में ये इकाइयाँ बाइट्स या कैरेक्टर हो सकती हैं; प्रशिक्षण के दौरान जो जोड़े लगातार साथ आते हैं, वे एक ही टोकन बन जाते हैं। इस प्रक्रिया से शब्दों के सामान्य टुकड़े (जैसे "ing", "tion") और सामान्य संयोजन (जैसे "the", "and") एकल टोकन बन जाते हैं, जिससे सीक्वेंस छोटा होता है।
यहाँ एक जरूरी बात समझें: BPE "शब्द" की सीमा को समझने के लिए व्हाइटस्पेस पर निर्भर नहीं करता; वह केवल उन कैरेक्टर-सीक्वेंस पर काम करता है जो उसे दिए जाते हैं। कई आधुनिक टोकनाइजर पहले टेक्स्ट को शब्दों/खंडों में बाँटते हैं (pre-tokenization) और फिर हर खंड पर BPE लागू करते हैं। इस pre-tokenization चरण में व्हाइटस्पेस और विराम चिह्न के साथ क्या किया जाता है, यह अंतिम टोकन विभाजन को सीधे प्रभावित करता है।
एक और तकनीकी शब्द: "वोकैब" (vocabulary) वह सूची है जिसमें सभी ज्ञात टोकन होते हैं। अगर कोई कैरेक्टर-सीक्वेंस वोकैब में किसी एकल टोकन के रूप में नहीं है, तो टोकनाइजर उसे छोटे टुकड़ों में तोड़ता है। इसलिए यह समझना जरूरी है कि "Hi!" और "Hi !" में अंतर इसलिए पैदा होता है कि टोकनाइजर के पास इन दोनों संयोजनों के लिए अलग-अलग टोकन उपलब्ध हैं या नहीं, और pre-tokenization ने उन्हें कैसे बाँटा।
व्हाइटस्पेस और विराम चिह्न कैसे संभाले जाते हैं
व्यवहार में टोकनाइजर व्हाइटस्पेस को तीन तरीकों से देख सकता है। पहला, शब्द-आरंभिक स्पेस को टोकन के साथ जोड़ा जा सकता है—जैसे " हैलो" में स्पेस और "हैलो" एक ही टोकन का हिस्सा बन सकते हैं। दूसरा, स्पेस को अलग टोकन माना जा सकता है। तीसरा, कई स्पेस या न्यूलाइन को किसी खास टोकन (जैसे "▁" या "Ġ" जैसे मार्कर) से दर्शाया जा सकता है जो शब्द की शुरुआत का संकेत देता है। किस टोकनाइजर में क्या होता है, यह उसके डिजाइन और प्रशिक्षण डेटा पर निर्भर करता है; इसलिए एक ही स्ट्रिंग अलग-अलग मॉडलों में अलग टोकन संख्या दे सकती है।
विराम चिह्न के साथ भी यही लचीलापन है। कुछ टोकनाइजर विराम चिह्न को शब्द से अलग कर देते हैं, तो कुछ में सामान्य संयोजन जैसे "!" या "?" शब्द के साथ जुड़े टोकन के रूप में सीख लिए जाते हैं। उदाहरण के लिए, अगर प्रशिक्षण डेटा में "Hi!" बहुत बार आया है, तो "Hi" और "!" का जोड़ा एक टोकन बन सकता है, जिससे "Hi!" एक ही टोकन बन जाता है। इसके विपरीत, "Hi !" में स्पेस आने से सीक्वेंस बदल जाता है और जोड़ा "Hi" + स्पेस + "!" के रूप में टूट सकता है, जिससे टोकन संख्या बढ़ जाती है।
इसे सूत्र की तरह देखें (यह एक सामान्यीकृत मॉडल है, किसी विशेष टोकनाइजर का सटीक नियम नहीं):
tokens("Hi!") ≈ [ "Hi" ] या [ "Hi", "!" ] (वोकैब पर निर्भर)
tokens("Hi !") ≈ [ "Hi", " ", "!" ] (स्पेस के कारण अतिरिक्त विभाजन)
यहाँ यह समझना जरूरी है कि टोकनाइजर "अर्थ" नहीं देखता; वह केवल कैरेक्टर-सीक्वेंस और सीखे गए जोड़ों की आवृत्ति देखता है। इसलिए एक अतिरिक्त स्पेस या विराम चिह्न का स्थान बदलना टोकन विभाजन को बदल सकता है, भले ही मनुष्य के लिए दोनों का अर्थ लगभग एक जैसा लगे। यही कारण है कि प्रॉम्प्ट लिखते समय व्हाइटस्पेस और विराम चिह्न की स्थिति को हल्के में नहीं लेना चाहिए—यह सीधे टोकन गणना और लागत से जुड़ी है।
'Hi!' बनाम 'Hi !' — टोकन विभाजन का कार्य-कारण उदाहरण
BPE (Byte Pair Encoding) टोकनाइजर पहले टेक्स्ट को छोटे-छोटे टुकड़ों में तोड़ता है, फिर बार-बार मिलने वाले जोड़ों को जोड़कर टोकन बनाता है। यहाँ मुख्य बात यह है कि टोकनाइजर की ट्रेनिंग के दौरान जो पैटर्न बार-बार दिखे, वही एक टोकन बनते हैं। कई आधुनिक टोकनाइजर (जैसे GPT-शैली के) शब्द से पहले आने वाले व्हाइटस्पेस को शब्द के साथ जोड़कर एक टोकन मानते हैं, यानी " Hi" एक टुकड़ा है, अलग से " " नहीं।
"Hi!"मेंH,i,!क्रमशः जुड़ते हैं। अगर"Hi"और"!"दोनों ट्रेनिंग में सामान्य हैं, तो यह["Hi", "!"]जैसा विभाजन दे सकता है — कुल 2 टोकन (यह टोकनाइजर की शब्दावली पर निर्भर है)।"Hi !"में अंत में एक स्पेस है जो अलग टुकड़ा बनता है। टोकनाइजर इसे["Hi", " ▁", "!"]या["Hi", " ", "!"]जैसा तोड़ सकता है — कुल 3 टोकन।
कारण स्पष्ट है: स्पेस खुद एक अलग टोकन (या शब्द-सीमा चिह्न) है, और BPE उसे "मिला देने" का कोई कारण तब तक नहीं देखता जब तक ट्रेनिंग में " !" (स्पेस+विस्मयादिबोधक) का जोड़ा बार-बार न आया हो। इसलिए एक ही व्याकरणिक अर्थ वाले दो स्ट्रिंग अलग टोकन संख्या देते हैं।
एक और बात: विराम चिह्न अक्सर अपने आप में एक टोकन होते हैं क्योंकि वे शब्दों से अलग बार-बार आते हैं, पर शब्द से चिपके होने पर वे शब्द के टुकड़े के साथ नहीं जुड़ते जब तक वह पैटर्न ट्रेनिंग में मजबूत न हो।
टोकन गणना और API लागत पर प्रभाव
API लागत लगभग हमेशा इनपुट टोकन + आउटपुट टोकन पर टिकी होती है, प्रति-टोकन दर से। इसलिए "एक टोकन ज़्यादा" का सीधा असर पड़ता है। मान लें (यह केवल एक अनुमानित उदाहरण है, वास्तविक दरें अलग होंगी):
- इनपुट दर: 1 डॉलर प्रति 10 लाख टोकन (यानी 0.000001 डॉलर/टोकन)
- आउटपुट दर: 3 डॉलर प्रति 10 लाख टोकन (0.000003 डॉलर/टोकन)
अब 1,00,000 अनुरोध भेजे जाएँ, हर अनुरोध में "Hi!" की जगह "Hi !" (और मान लें आउटपुट में भी एक अतिरिक्त टोकन जुड़ता है):
अतिरिक्त इनपुट टोकन = 1,00,000 × 1 = 1,00,000
अतिरिक्त इनपुट लागत = 1,00,000 × 0.000001 = 0.10 डॉलर
अतिरिक्त आउटपुट टोकन = 1,00,000 × 1 = 1,00,000
अतिरिक्त आउटपुट लागत = 1,00,000 × 0.000003 = 0.30 डॉलर
कुल अतिरिक्त लागत ≈ 0.40 डॉलर
छोटा लगता है, पर पैमाने पर यह बढ़ता है: 10 लाख अनुरोधों पर यही अंतर लगभग 4 डॉलर हो जाता है, और अगर हर अनुरोध में कई जगह फालतू स्पेस/विराम हों तो गुणक बढ़ता जाता है। इसके अलावा लंबा टोकन-स्ट्रीम संदर्भ-सीमा (context window) भी जल्दी भरता है, जिससे ट्रंकेशन या अतिरिक्त चंकिंग की नौबत आ सकती है।
व्यावहारिक चेकलिस्ट (प्री-प्रोसेसिंग से पहले):
[ ] विराम चिह्न से पहले का स्पेस हटाएँ (जब तक शैलीगत रूप से ज़रूरी न हो)
[ ] कई स्पेस को एक में बदलें
[ ] टेम्पलेट में स्टैटिक स्पेस/न्यूलाइन की समीक्षा करें
[ ] भेजने से पहले टोकन-काउंटर से गिनें, फिर सैंपल पर लागत आकलित करें
[ ] A/B: "Hi!" बनाम "Hi !" का टोकन अंतर लॉग करें
छोटा सा नियम: टोकन गणना को डिज़ाइन-निर्णय मानें, बाद की चिंता नहीं। जहाँ अर्थ न बदले, वहाँ स्पेस और विराम को साफ़ रखना मुफ़्त बचत है।
अक्सर पूछे जाने वाले प्रश्न
BPE में व्हाइटस्पेस को अलग टोकन क्यों माना जाता है?
BPE (Byte Pair Encoding) टोकनाइजर को ट्रेनिंग के दौरान जो टेक्स्ट दिखता है, वह कैरेक्टर की एक सतत स्ट्रीम होती है—स्पेस भी उसी स्ट्रीम का एक कैरेक्टर है, इसलिए वह भी दूसरे कैरेक्टर की तरह मर्ज-नियमों में हिस्सा लेता है। चूँकि स्पेस शब्दों की सीमा तय करता है और बहुत बार आता है, BPE एल्गोरिद्म अक्सर स्पेस को पिछले या अगले शब्द-टुकड़े के साथ मिलाकर एक नया टोकन बना देता है (जैसे "▁Hi" जैसा रूप, जहाँ ▁ स्पेस का प्रतीक है)। इसका नतीजा यह है कि स्पेस "मुफ़्त" नहीं रहता—वह या तो टोकन के अंदर सिमट जाता है या अलग टोकन बन जाता है, और दोनों ही स्थितियों में उसकी उपस्थिति टोकन की गिनती और टोकन की पहचान बदल देती है।
'Hi!' और 'Hi !' के टोकन अलग क्यों बनते हैं?
क्योंकि BPE कैरेक्टर-स्तर की सटीक अनुक्रम (sequence) पर काम करता है, और "Hi! और "Hi !" दो अलग अनुक्रम हैं—पहले में स्पेस नहीं है, दूसरे में है। ट्रेनिंग डेटा में "Hi!" जैसा पैटर्न जितना बार आया होगा, "Hi" और "!" उतनी ही मज़बूती से एक ही टोकन में मर्ज हो सकते हैं; लेकिन "Hi !" में स्पेस बीच में आ जाने से वही जोड़ी टूट जाती है, और टोकनाइजर को "Hi", स्पेस, और "!" को अलग-अलग संभालना पड़ता है। यानी टोकनाइजर अर्थ नहीं, बाइट-अनुक्रम देखता है—एक स्पेस की मौजूदगी पूरा विभाजन बदल देती है।
विराम चिह्न टोकन गणना को कैसे बढ़ाते हैं?
विराम चिह्न अक्सर शब्दों से चिपके रहते हैं, और BPE उन्हें तभी एक टोकन में मर्ज करता है जब वह जोड़ी ट्रेनिंग में पर्याप्त बार मिली हो; अन्यथा "!" या "?" अलग टोकन बन जाता है। जब आप शब्द और विराम चिह्न के बीच स्पेस डालते हैं, तो स्पेस भी एक अलग इकाई बन जाता है, इसलिए एक ही वाक्यांश के टोकन तीन तक पहुँच सकते हैं—शब्द, स्पेस, चिह्न। इसके अलावा, कई विराम चिह्नों के समूह (जैसे "!!!" या "?!") भी अलग-अलग टोकन में टूट सकते हैं, जिससे गिनती और बढ़ जाती है।
इससे API लागत में कितना अंतर आ सकता है?
लागत सीधे टोकन की संख्या से जुड़ी होती है, इसलिए अनुमान लगाना आसान है: अगर "Hi!" एक टोकन है और "Hi !" दो या तीन टोकन बनता है, तो उस अंश में टोकन गिनती लगभग दोगुनी या तिगुनी हो सकती है। मान लीजिए किसी टेक्स्ट में ऐसे 1,000 स्थान हैं जहाँ स्पेस जोड़ा गया; अगर हर स्थान पर एक अतिरिक्त टोकन जुड़ता है, तो कुल टोकन में लगभग 1,000 की बढ़ोतरी होगी—यह अनुमान है, वास्तविक आँकड़ा टोकनाइजर और टेक्स्ट पर निर्भर करेगा। चूँकि API बिल टोकन-दर से गुणा करके बनता है, यह बढ़ोतरी सीधे लागत में जुड़ जाती है; बड़े बैच या लंबे प्रॉम्प्ट में यह अंतर महसूस होने लगता है।
क्या टोकन-काउंटर टूल से लागत का अनुमान लगाया जा सकता है?
हाँ, लेकिन शर्त के साथ: टूल को उसी मॉडल का टोकनाइजर इस्तेमाल करना चाहिए जिसका आप API में कर रहे हैं, क्योंकि हर मॉडल का BPE शब्दावली और मर्ज-नियम अलग होते हैं। आप अपने वास्तविक प्रॉम्प्ट (स्पेस और विराम चिह्नों सहित, बिल्कुल जैसा भेजा जाएगा) को टूल में डालकर टोकन गिन सकते हैं, और उसे अपने टोकन-दर से गुणा करके अनुमानित लागत निकाल सकते हैं। यह अनुमान है, गारंटी नहीं—क्योंकि असली बिल में सिस्टम-प्रॉम्प्ट, रोलिंग कॉन्टेक्स्ट जैसी अतिरिक्त चीज़ें भी जुड़ सकती हैं, इसलिए इसे ऊपरी अनुमान की तरह इस्तेमाल करें।