BPE Tokenizer بنائیں: آپ کا model R کیوں نہیں گن سکتا

network کو text دینے کے دو واضح طریقے ہیں، اور دونوں ایسی وجوہات سے ناکام ہوتے ہیں جنہیں سمجھنا ضروری ہے، کیونکہ یہی ناکامی solution کی شکل طے کرتی ہے۔

Words. spaces پر split کریں، ہر word کو ایک number دے دیں۔ English میں word forms لاکھوں ہیں اور model کو ہر ایک کے لیے embedding row چاہیے، لہٰذا vocabulary — اور output layer، جسے ہر entry کے لیے score پیدا کرنا ہوتا ہے — بہت بڑی ہو جاتی ہے۔ اس سے بھی برا inference پر ہوتا ہے: ایسا word جو model نے training میں کبھی نہ دیکھا ہو، اس کا کوئی number نہیں ہوتا۔ یہ out-of-vocabulary مسئلہ ہے، اور عام patch یہ ہے کہ ہر unknown چیز کو ایک ہی <UNK> token پر map کر دیا جائے، جس سے information ضائع ہو جاتی ہے۔ پھر "word" خود بھی اچھی طرح defined تصور نہیں: Chinese اور Japanese words کے درمیان spaces نہیں رکھتے، اور German ایک noun کو دوسرے noun کے ساتھ غیر محدود حد تک compound کر دیتا ہے۔

Characters. out-of-vocabulary مسئلہ نہیں، اور vocabulary سو کے لگ بھگ symbols کی۔ مگر sequences بہت لمبی ہو جاتی ہیں، اور Chapter 9 دکھائے گا کہ attention cost sequence length کے ساتھ quadratically بڑھتی ہے۔ 1000-word document تقریباً 5000 characters ہوتا ہے — ضرورت سے چار سے پانچ گنا لمبی sequence، quadratic قیمت کے ساتھ۔ اور ہر character اکیلا تقریباً کوئی meaning نہیں رکھتا، اس لیے پہلے چند layers وہ words دوبارہ جوڑنے میں خرچ ہو جاتے ہیں جو tokenizer صحیح سالم دے سکتا تھا۔

جواب ان دونوں کے بیچ ہے: subwords۔ عام words ایک token بن جاتے ہیں، rare words ٹکڑوں میں split ہوتے ہیں، اور کچھ بھی کبھی unknown نہیں ہوتا کیونکہ آخر میں pieces individual bytes تک پہنچ جاتے ہیں۔ دلچسپ بات یہ ہے کہ split کوئی انسان design نہیں کرتا۔ tokenizer train کیا جاتا ہے، model جیسی ہی data پر، اور یہ count کر کے سیکھتا ہے کہ کون سی byte sequences اپنے الگ number کے قابل ہیں کیونکہ وہ کتنی بار اکٹھی آتی ہیں۔

یہ algorithm 1994 کا ہے، اور یہ compression algorithm تھا۔ Philip Gage نے اسے C Users Journal میں files کو چھوٹا کرنے کے طریقے کے طور پر publish کیا: adjacent bytes کے سب سے frequent pair کو بار بار ایسے byte سے replace کرنا جو data میں موجود نہ ہو۔¹ یہ بائیس سال وہیں پڑا رہا، یہاں تک کہ Sennrich, Haddow اور Birch نے 2016 میں machine translation کے لیے اسے out-of-vocabulary مسئلہ حل کرنے کی خاطر repurpose کیا۔² اب بنیادی طور پر ہر large language model اسی طرح پڑھتا ہے۔

training loop چار steps کو repeat کرتا ہے:

یہ پورا trainer ہے:

def get_stats(ids):
    counts = {}
    for a, b in zip(ids, ids[1:]):
        counts[(a, b)] = counts.get((a, b), 0) + 1
    return counts


def merge(ids, pair, idx):
    out, i = [], 0
    while i < len(ids):
        if i < len(ids) - 1 and ids[i] == pair[0] and ids[i + 1] == pair[1]:
            out.append(idx)
            i += 2
        else:
            out.append(ids[i])
            i += 1
    return out


class BPE:
    def __init__(self):
        self.merges = {}
        self.vocab = {i: bytes([i]) for i in range(256)}

    def train(self, text, vocab_size):
        ids = list(text.encode("utf-8"))
        for i in range(vocab_size - 256):
            stats = get_stats(ids)
            if not stats:
                break
            pair = max(stats, key=stats.get)      
            idx = 256 + i                         
            ids = merge(ids, pair, idx)           
            self.merges[pair] = idx               
            self.vocab[idx] = self.vocab[pair[0]] + self.vocab[pair[1]]
        return ids

اسے English prose کے 151,191 bytes پر چلائیں اور پہلے بارہ merges print کریں جیسے جیسے وہ ہوتے ہیں۔ یہ حصہ آہستہ پڑھنے کے قابل ہے، کیونکہ کسی نے algorithm کو English کے بارے میں کچھ نہیں بتایا:

merge   1: b'e' + b' '   -> b'e '     (occurred 4433 times)
merge   2: b' ' + b't'   -> b' t'     (occurred 3302 times)
merge   3: b'\xe2' + b'\x80' -> b'\xe2\x80'  (occurred 3247 times)
merge   4: b' ' + b'a'   -> b' a'     (occurred 2335 times)
merge   5: b' t' + b'h'  -> b' th'    (occurred 2253 times)
merge   6: b'i' + b'n'   -> b'in'     (occurred 2011 times)
merge   7: b't' + b' '   -> b't '     (occurred 1904 times)
merge   8: b'e' + b'r'   -> b'er'     (occurred 1813 times)
merge   9: b'd' + b' '   -> b'd '     (occurred 1703 times)
merge  10: b'o' + b'u'   -> b'ou'     (occurred 1554 times)
merge  11: b' ' + b's'   -> b' s'     (occurred 1467 times)
merge  12: b' th' + b'e '-> b' the '  (occurred 1270 times)

اس list میں تین چیزیں خاص طور پر دکھانے کے قابل ہیں۔

Merge 12 word "the" ہے — اس سے پہلے space اور اس کے بعد space کے ساتھ، ایک single unit کے طور پر، ایک ایسے loop کی بارہویں iteration پر discovered جو pairs count کرتا ہے۔ کسی نے dictionary نہیں دی۔ یہ اس لیے ہے کہ یہ پانچ bytes English میں کسی بھی دوسرے پانچ bytes سے زیادہ ساتھ ساتھ آتے ہیں۔

Merge 3 text ہے ہی نہیں۔ \xe2\x80 typographic punctuation — em dash، curly quotes — کی UTF-8 encoding کے پہلے دو bytes ہیں۔ algorithm کو اندازہ نہیں کہ UTF-8 موجود ہے، اور اس نے ابھی اس کی structure کا ایک ٹکڑا دوبارہ discover کر لیا ہے، کیونکہ multi-byte encodings بنائی ہی ایسی sequences کے طور پر جاتی ہیں جو ہمیشہ ساتھ آتی ہیں۔

ابتدائی merges میں سے اکثر space شامل کرتے ہیں، اور space عموماً left پر ہوتی ہے۔ یہی practice میں ایک بہت confusing behaviour کی اصل ہے، جس پر ہم تھوڑی دیر میں واپس آتے ہیں۔

ہر merge sequence کو چھوٹا اور vocabulary کو بڑا کرتا ہے۔ اسے کہاں تک push کرنا ایک حقیقی فیصلہ ہے، اور اسے measure کیا جا سکتا ہے — یہاں اسی 151,191 bytes پر:

Diminishing returns صاف نظر آتے ہیں۔ 512 سے 1024 تک double کرنے سے 0.78 bytes per token ملتے ہیں؛ 2048 سے 4096 تک double کرنے سے 1.07 — یہاں بہتر صرف اس لیے ہے کہ یہ corpus اتنا چھوٹا ہے کہ longer merges ابھی بھی فائدہ دے رہے ہیں۔ real corpus پر curve بہت سخت flatten ہو جاتی ہے۔

اور بڑی vocabulary کی cost صرف memory نہیں۔ ہر token کو embedding row چاہیے، اور — زیادہ مہنگا — model کی output layer کو ہر step پر vocabulary کی ہر entry کے لیے score پیدا کرنا ہوتا ہے، اس لیے final matrix multiply vocabulary size کے ساتھ scale کرتا ہے۔ real models 32,000 اور 200,000 کے درمیان ہوتے ہیں: GPT-2 نے 50,257 استعمال کیے، GPT-4 کا cl100k 100,277 استعمال کرتا ہے، GPT-4o کا o200k اسے تقریباً double کر دیتا ہے۔ trend اوپر کی طرف ہے، اور وجہ اگلے section میں ہے۔

یہی paragraph، translated، OpenAI کے ship کیے ہوئے real tokenizers سے measured:

وہی content، وہی meaning، اور cl100k کے ساتھ Russian version ڈھائی گنا tokens consume کرتا ہے۔ چونکہ APIs per token bill کرتی ہیں اور context windows tokens میں measured ہوتی ہیں، یہ linguistic curiosity نہیں — یہ budget کی line ہے، چھوٹی effective context window ہے، اور slow response ہے، تینوں ایک ساتھ، ہر اس شخص کے لیے جو English میں کام نہیں کرتا۔

mechanism training data ہے۔ زیادہ تر English پر trained tokenizer اپنا merge budget English byte sequences پر خرچ کرتا ہے۔ Spanish Latin alphabet share کرتی ہے، اس لیے اسے پھر بھی کچھ benefit ملتا ہے؛ Russian کو تقریباً نہیں، کیونکہ Cyrillic characters UTF-8 میں دو bytes لیتے ہیں اور ان pairs میں سے کم ہی training corpus میں اتنے common تھے کہ merge کما سکیں۔ Japanese اس سے بھی worse ہے: فی character تین bytes، اور 72 characters 79 tokens بن جاتے ہیں — characters سے زیادہ tokens۔

o200k column دکھاتا ہے کہ یہ مسئلہ حل ہو سکتا ہے اور حل ہو رہا ہے۔ vocabulary double کرنے اور training data کو rebalance کرنے سے Spanish overhead +39 % سے +16 % تک، اور Russian +152 % سے +39 % تک کٹ جاتا ہے۔ vocabularies کے بڑھتے رہنے کی اصل وجہ یہی ہے: compression اپنی خاطر نہیں، بلکہ یہ حقیقت کہ previous generation خاموشی سے دنیا کے بڑے حصے سے extra charge لے رہی تھی۔

Training نے merges کی ordered list پیدا کی۔ نئی text encode کرنا اسے replay کرتا ہے — اور اسے اسی order میں replay کرنا ضروری ہے، کیونکہ merge 12 merges 5 اور 1 کے results کو combine کرتا ہے۔ انہیں مختلف order میں apply کریں تو مختلف، غلط tokenization ملے گی جو training میں model نے جو کچھ دیکھا اس سے match نہیں کرے گی۔

    def encode(self, text):
        ids = list(text.encode("utf-8"))
        while len(ids) >= 2:
            stats = get_stats(ids)
            # the pair whose merge came FIRST during training wins   
            pair = min(stats, key=lambda p: self.merges.get(p, float("inf")))   
            if pair not in self.merges:
                break
            ids = merge(ids, pair, self.merges[pair])
        return ids

    def decode(self, ids):
        return b"".join(self.vocab[i] for i in ids).decode("utf-8", errors="replace")

Decoding اس کے مقابلے میں trivial ہے: ہر id کے bytes look up کریں، concatenate کریں، UTF-8 کے طور پر decode کریں۔ errors="replace" نوٹ کریں: model ایسی token sequence emit کر سکتا ہے جو character کے بیچ میں ختم ہو، اور یہ hypothetical نہیں — یہی ہوتا ہے جب streaming response کسی emoji کے بیچ میں cut off ہو جائے، اسی لیے streaming APIs token by token decode کرنے کے بجائے partial bytes buffer کرتی ہیں۔

Round-tripping کسی بھی چیز پر کام کرتی ہے، یہی byte-level BPE کا وعدہ ہے:

'strawberry'                            -> 6 tokens, decode == original: True
'Alice was beginning to get very tired' -> 14 tokens, decode == original: True
'café — naïve — 日本語'                   -> 23 tokens, decode == original: True

جب mechanism clear ہو جائے تو بظاہر غیر متعلق complaints کا ایک set اسی ایک complaint میں بدل جاتا ہے۔

Arithmetic. numbers کسی consistent طریقے سے split نہیں ہوتے:

1234     -> 2 tokens  ['123', '4']
12345    -> 2 tokens  ['123', '45']
1000000  -> 3 tokens  ['100', '000', '0']
3.14159  -> 4 tokens  ['3', '.', '141', '59']
2024     -> 2 tokens  ['202', '4']

1234 اور 12345 کو add کرنے کے لیے model کو پہلے یہ work out کرنا ہوتا ہے کہ ['123','4'] اور ['123','45'] numbers ہیں جن کے digits ایک خاص طریقے سے align ہوتے ہیں — اور alignment ہر pair of numbers کے لیے مختلف ہوتی ہے۔ ایک number کے digits اگلے number میں انہی جگہوں پر نہیں ہوتے۔ کچھ newer tokenizers digits کو لازماً تین کے consistent groups میں split کرتے ہیں، precisely اس obstacle کو remove کرنے کے لیے، اور ان کے ساتھ trained models arithmetic میں measurably بہتر ہوتے ہیں۔

Python indentation.

'    x = 1'      -> 5 tokens  ['   ', ' x', ' =', ' ', '1']
'        x = 1'  -> 5 tokens  ['       ', ' x', ' =', ' ', '1']
'\tx = 1'        -> 4 tokens  ['\tx', ' =', ' ', '1']

چار spaces اور آٹھ spaces different single tokens ہیں، اور tab اپنے بعد والے character کے ساتھ fused ہے۔ Indentation، جو Python میں syntax ہے، inconsistently represented ہے — یہی اس بات کا بڑا حصہ ہے کہ models پہلے subtly wrong indentation والی Python کیوں produce کرتے تھے، اور code-focused tokenizers common indentation runs کے لیے explicit tokens کیوں add کرتے ہیں۔

Spelling اور reversing. وہی وجہ جو r گننے میں تھی: model سے strawberry reverse کرنے کو کہنا تین opaque ids کے اندر letters کو reorder کرنے کو کہنا ہے۔ models یہ training کے دوران spellings memorise کر کے کرتے ہیں، دیکھ کر نہیں، اسی لیے common words پر اچھا اور rare words پر برا کرتے ہیں۔

Glitch tokens. سب سے striking case SolidGoldMagikarp اور اسی طرح کی strings کا ایک set ہے جس نے GPT-2 اور GPT-3 کو bizarre behave کرایا — انہیں repeat کرنے سے انکار، unrelated output پیدا کرنا، کبھی user کو insult کرنا۔ explanation mundane ہے اور اس fact سے براہِ راست نکلتی ہے کہ tokenizer model سے الگ train کیا جاتا ہے: وہ strings tokenizer کے training corpus میں frequent تھیں (وہ Reddit usernames تھیں)، اس لیے انہوں نے اپنا token کما لیا، مگر model کے training corpus میں rare یا absent تھیں۔ نتیجہ ایک ایسی embedding row ہے جو randomly initialise ہوئی اور تقریباً کبھی update نہیں ہوئی۔ model کے پاس ایک symbol ہے جسے اس نے essentially کبھی نہیں دیکھا، اور وہاں اس کا behaviour وہی ہے جو random initialisation اتفاقاً بن گئی۔

tokenizer text اور numbers کے درمیان ایک lossy interface ہے، اور اس chapter کا ہر عجیب behaviour اسی interface کا ظاہر ہونا ہے۔ یہ واضح رکھنا ضروری ہے کہ trade deliberate ہے: byte-level BPE کا مطلب ہے کوئی input کبھی unrepresentable نہیں، sequences characters کے مقابلے میں چار سے پانچ گنا چھوٹی ہیں، اور common words intact آتے ہیں۔

قیمت یہ ہے کہ model کے atoms ہمارے atoms نہیں۔ یہ ایسی text کے بارے میں reason کرتا ہے جسے یہ spell نہیں کر سکتا، ایسے units میں جو ایک ایسے corpus پر frequency count سے چنے گئے جسے اس نے نہیں دیکھا، اور per-language cost کے ساتھ جس پر کسی نے negotiation نہیں کی۔

اب آپ کے پاس integers کی sequence ہے۔ Part II کے باقی ہر حصے کا input format یہی ہے۔

جو آپ کے پاس نہیں، وہ یہ ہے کہ ایک integer کے بعد دوسرا integer کیوں آئے۔ اگلا chapter وہ objective introduce کرتا ہے جس پر ہر language model train ہوتا ہے، اور یہ حیران کن حد تک simple ہے: اب تک کے tokens دیے جائیں، اگلا predict کریں۔ یہی single objective — no labels، no annotation، صرف text جس کا اپنا future target ہے — پورے internet کو training data میں بدل دیتا ہے، اور model کی پہلی genuine representations یہیں سے آتی ہیں۔

اس کے لیے Chapter 2 کی chain rule of probability کا بالکل درست ہونا بھی ضروری ہے، کیونکہ یہ claim کہ ایک وقت میں ایک token predict کرنا whole documents model کرنے جیسا ہے، factorisation ہے، metaphor نہیں۔

Chapter 8 autoregressive objective، embeddings، اور وہ پہلی جگہ ہے جہاں model ایسی چیز سیکھتا ہے جو کسی نے وہاں نہیں رکھی۔

Kudo, T. Subword Regularization: Improving Neural Network Translation Models with Multiple Subword Candidates (arXiv:1804.10959) Unigram model introduce کرتا ہے؛ Kudo and Richardson, SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing (arXiv:1808.06226) وہ implementation ہے جسے زیادہ تر multilingual models استعمال کرتے ہیں؛ Schuster and Nakajima, Japanese and Korean Voice Search (ICASSP 2012) WordPiece کی origin ہے۔ Andrej Karpathy کا Let's build the GPT Tokenizer اور accompanying karpathy/minbpe repository اس chapter کے code کے direct ancestors ہیں اور کافی آگے جاتے ہیں، بشمول GPT-4 regex اور special-token handling۔ Hugging Face LLM Course کا Chapter 6 تینوں algorithms کو worked examples کے ساتھ side by side cover کرتا ہے۔