Corpora, Unicode and UTF-8المدونات النصية وUnicode وUTF-8

Two datasets both labelled "Arabic corpus" can be almost unrelated. One is Modern Standard Arabic newswire from 2005, written by trained journalists in a formal register. The other is Gulf-dialect tweets from 2024, full of Arabizi, emoji and code switching into English. A model trained on the first will stumble on the second, and a vocabulary learned from either will miss most of the other. Same language label, different domain, genre, time, demographics and variety.

مجموعتا بيانات تحملان كلتاهما وسم "مدونة عربية" قد لا تكاد تجمعهما صلة. الأولى أخبار بالعربية الفصحى المعاصرة من عام 2005، كتبها صحفيون مدرَّبون بأسلوب رسمي. والثانية تغريدات باللهجة الخليجية من عام 2024، مليئة بالعربيزي والرموز التعبيرية (emoji) والتبديل اللغوي إلى الإنجليزية. النموذج المدرَّب على الأولى سيتعثر في الثانية، والمفردات المتعلَّمة من أيٍّ منهما ستفوّت معظم ما في الأخرى. الوسم اللغوي نفسه، لكن المجال والنوع والزمن والخصائص الديموغرافية والتنوع اللغوي كلها مختلفة.

A Corpus is a structured collection of texts, often annotated, drawn from sources such as books, news, web crawls, social media and speech transcripts. The word "structured" matters: a corpus is a deliberate sample with metadata, not a pile of files. Jurafsky and Martin describe the dimensions along which such samples vary as language and variety (including code switching), genre, the demographics of the writer or speaker, and time. The table below adds domain, which the slides list separately, and gives an Arabic example for each.

المدونة النصية corpus مجموعة منظّمة من النصوص، كثيرًا ما تكون موسومة، مأخوذة من مصادر مثل الكتب والأخبار وعمليات الزحف على الويب ووسائل التواصل الاجتماعي ونصوص الكلام المفرَّغة. وكلمة "منظّمة" مهمة: فالمدونة عيّنة مقصودة مصحوبة ببيانات وصفية (metadata)، وليست كومة من الملفات. ويصف Jurafsky وMartin الأبعاد التي تتباين فيها هذه العينات بأنها: اللغة والتنوع اللغوي (بما في ذلك التبديل اللغوي code switching)، والنوع (genre)، والخصائص الديموغرافية للكاتب أو المتحدث، والزمن. ويضيف الجدول أدناه المجال (domain)، الذي تذكره الشرائح منفصلًا، ويعطي مثالًا عربيًا لكل بعد.

Models inherit their corpusالنماذج ترث مدونتها

A language model is a compressed description of its training corpus, so it inherits the corpus's biases and blind spots. Bender and Friedman argue that systems perform best for the populations represented in their training data, so bias and exclusion arise when that data does not match the people the system is deployed for, and the fix begins with knowing what the data contains. Without that knowledge, a result on a benchmark cannot be interpreted: a 95% accuracy on 2005 newswire says nothing about 2024 tweets. To interpret any result you need the metadata below.

النموذج اللغوي وصف مضغوط لمدونة تدريبه، ولذلك يرث تحيزاتها ونقاطها العمياء. ويرى Bender وFriedman أن الأنظمة تعمل بأفضل أداء مع الفئات الممثَّلة في بيانات تدريبها، فينشأ التحيز والإقصاء حين لا تطابق تلك البيانات الناس الذين يُنشر النظام لخدمتهم، والعلاج يبدأ بمعرفة ما تحتويه البيانات. ومن دون هذه المعرفة لا يمكن تفسير نتيجة على معيار قياس (benchmark): فدقة 95% على أخبار 2005 لا تقول شيئًا عن تغريدات 2024. ولتفسير أي نتيجة تحتاج إلى البيانات الوصفية أدناه.

Data statements and datasheetsبيان البيانات (data statement) وصحيفة البيانات (datasheet)

Two papers turned that metadata list into a standard document. Bender and Friedman (2018) proposed the data statement for NLP datasets, a short structured write-up with lettered sections from curation rationale through language variety, speaker and annotator demographics, speech situation and text characteristics. Gebru and colleagues (2021) proposed the datasheet for any machine learning dataset, borrowing the idea from electronics: a component datasheet lists operating ranges and test conditions, so a dataset should too. The slides merge the two into six fields.

حوّلت ورقتان علميتان قائمة البيانات الوصفية تلك إلى وثيقة قياسية. اقترح Bender وFriedman (2018) بيان البيانات data statement لمجموعات بيانات NLP، وهو وصف قصير منظّم بأقسام مرقّمة بالحروف تمتد من مبررات الانتقاء (curation rationale) مرورًا بالتنوع اللغوي والخصائص الديموغرافية للمتحدثين والموسِّمين، وموقف الكلام، وخصائص النص. واقترح Gebru وزملاؤه (2021) صحيفة البيانات (datasheet) لأي مجموعة بيانات في تعلم الآلة، مستعيرين الفكرة من الإلكترونيات: فصحيفة بيانات المكوِّن الإلكتروني تذكر نطاقات التشغيل وظروف الاختبار، وكذلك ينبغي لمجموعة البيانات أن تفعل. وتدمج الشرائح الاثنين في ستة حقول.

The payoff is transparency, reproducibility and responsible use. Transparency because a reader can judge whether your corpus matches their population. Reproducibility because someone else can rebuild or extend the sample. Responsible use because a datasheet states what the data must not be used for, which is the only place such a limit can live once the files are downloaded.

العائد هو الشفافية وقابلية إعادة الإنتاج والاستخدام المسؤول. الشفافية لأن القارئ يستطيع أن يحكم هل تطابق مدونتك الفئة التي يعمل عليها. وقابلية إعادة الإنتاج لأن شخصًا آخر يستطيع إعادة بناء العينة أو توسيعها. والاستخدام المسؤول لأن صحيفة البيانات تنص على ما يجب ألا تُستخدم فيه البيانات، وهي المكان الوحيد الذي يمكن أن يبقى فيه مثل هذا القيد بعد تنزيل الملفات.

Type the word café on two computers. On a Mac the é arrives as one unit, U+00E9. On a system with a decomposed input method it arrives as two, the plain letter U+0065 followed by a combining acute accent U+0301. On screen the two strings are pixel for pixel identical. In a program they are unequal, they have different lengths, and a tokenizer trained on one will split the other into pieces it never saw during training. Arabic has the same trap: a legacy keyboard emits the lam-alef ligature U+FEFB as one character, while a modern one emits U+0644 then U+0627.

اكتب كلمة café على حاسوبين. على جهاز Mac يصل الحرف é وحدةً واحدة، U+00E9. وعلى نظام يستخدم طريقة إدخال مفكَّكة يصل وحدتين: الحرف العادي U+0065 متبوعًا بعلامة الحدة المركِّبة (combining acute accent) U+0301. على الشاشة السلسلتان متطابقتان بكسلًا ببكسل. أما في البرنامج فهما غير متساويتين، وطولاهما مختلفان، والمقطِّع المدرَّب على إحداهما سيقسم الأخرى إلى قطع لم يرها أثناء التدريب قط. وللعربية الفخ نفسه: لوحة المفاتيح القديمة تُخرج رباط اللام ألف U+FEFB حرفًا واحدًا، بينما تُخرج الحديثة U+0644 ثم U+0627.

To reason about this you need three separate words. Unicode assigns every character a Code point, an integer between 0 and 0x10FFFF written with a U+ prefix in hexadecimal, such as U+0061 for the letter a. That gives 1,114,112 possible positions, and the standard covers Latin, Cyrillic, Arabic, Han, emoji and over 170 other scripts within them. A Glyph is the rendered shape a font draws for a code point. The Unicode core specification is explicit that an abstract character should not be confused with a glyph: the code point is the identity, the glyph is one of many possible pictures of it.

لتفكر في هذا تحتاج إلى ثلاث كلمات منفصلة. يعيّن Unicode لكل حرف نقطة ترميز code point، وهي عدد صحيح بين 0 و0x10FFFF يُكتب بالنظام الست عشري مع البادئة U+، مثل U+0061 للحرف a. وهذا يعطي 1,114,112 موضعًا ممكنًا، ويغطي المعيار ضمنها اللاتينية والسيريلية والعربية والهان (Han) والرموز التعبيرية وأكثر من 170 نظام كتابة آخر. أما الرسم الحرفي glyph فهو الشكل الذي يرسمه الخط لنقطة الترميز. والمواصفة الأساسية لـ Unicode صريحة في أن الحرف المجرد لا ينبغي أن يُخلط بالرسم الحرفي: نقطة الترميز هي الهوية، والرسم الحرفي صورة واحدة من صور كثيرة ممكنة لها.

The mapping runs many to many in both directions. One glyph can stand for several code points: the é above is one shape and two encodings, and Latin A (U+0041), Cyrillic А (U+0410) and Greek Α (U+0391) look identical in most fonts. One code point can also have several glyphs: the Arabic letter beh U+0628 is drawn as isolated, initial, medial or final form depending on its neighbours, yet the text stores a single code point and the font chooses the shape.

العلاقة متعدد إلى متعدد في الاتجاهين. فقد يمثّل رسم حرفي واحد عدة نقاط ترميز: الحرف é أعلاه شكل واحد بترميزين، والحرف اللاتيني A (U+0041) والسيريلي А (U+0410) واليوناني Α (U+0391) تبدو متطابقة في معظم الخطوط. وقد يكون لنقطة ترميز واحدة عدة رسوم حرفية: حرف الباء U+0628 يُرسم منفصلًا أو في أول الكلمة أو وسطها أو آخرها بحسب جيرانه، ومع ذلك يخزّن النص نقطة ترميز واحدة ويختار الخط الشكل.

ASCII: the first 128 code pointsASCII: أول 128 نقطة ترميز

The oldest slice of Unicode is ASCII, a 7-bit code with 128 positions defined in RFC 20, which occupies code points U+0000 to U+007F unchanged. The slide shows a fragment of the table in hexadecimal and decimal. The version below adds the binary column, because the binary reveals a fact you will use every time you write a case-folding rule.

أقدم شريحة في Unicode هي ASCII، وهو ترميز بسبع بتات فيه 128 موضعًا، معرَّف في RFC 20، ويشغل نقاط الترميز من U+0000 إلى U+007F دون تغيير. وتعرض الشريحة جزءًا من الجدول بالست عشري والعشري. والنسخة أدناه تضيف العمود الثنائي، لأن التمثيل الثنائي يكشف حقيقة ستستخدمها كلما كتبت قاعدة لتوحيد حالة الأحرف.

Compare A at 0100 0001 with a at 0110 0001. They differ in exactly one bit, bit 5, which is worth 0x20 or 32. Every uppercase letter sits 32 positions before its lowercase partner, so Case folding in ASCII is a single OR with 0x20, which is why it is so fast and why it breaks the moment text leaves ASCII. Arabic has no case, and Greek final sigma has no simple bit rule, so Unicode defines case folding as a table lookup instead.

قارن A عند 0100 0001 بـ a عند 0110 0001. يختلفان في بت واحد بالضبط، البت 5، وقيمته 0x20 أي 32. كل حرف كبير يقع قبل نظيره الصغير بـ 32 موضعًا، لذا فإن توحيد حالة الأحرف case folding في ASCII عملية OR واحدة مع 0x20، ولهذا هو سريع جدًا، ولهذا أيضًا ينكسر لحظة خروج النص عن ASCII. فالعربية لا حالة فيها، وحرف سيغما الختامي اليوناني لا قاعدة بتية بسيطة له، ولذلك يعرّف Unicode توحيد الحالة بالبحث في جدول بدلًا من ذلك.

Normalization: one canonical spelling for each characterالتطبيع: كتابة قياسية واحدة لكل حرف

Back to café. Unicode calls U+00E9 the precomposed form and U+0065 U+0301 the decomposed form, and declares them canonically equivalent: they must be treated as the same character. Arabic has the same pair. Alef with hamza above, U+0623, decomposes canonically to bare alef U+0627 plus the combining hamza above U+0654, as the Unicode code chart records. A different, weaker relation is compatibility equivalence: the lam-alef ligature U+FEFB is compatible with U+0644 U+0627, and the ligature fi (U+FB01) with the two letters f and i. Compatibility variants look different or carry formatting, so folding them loses information.

لنعد إلى café. يسمي Unicode الشكل U+00E9 الشكل المركَّب مسبقًا (precomposed)، والشكل U+0065 U+0301 الشكل المفكَّك (decomposed)، ويعلن أنهما متكافئان قانونيًا canonically equivalent: يجب أن يُعاملا بوصفهما الحرف نفسه. وللعربية الزوج نفسه. فالألف مع همزة فوقها، U+0623، تتفكك قانونيًا إلى ألف مجردة U+0627 مع الهمزة المركِّبة فوقها U+0654، كما يسجّل جدول رموز Unicode. وثمة علاقة أخرى أضعف هي التكافؤ التوافقي (compatibility equivalence): فرباط اللام ألف U+FEFB متوافق مع U+0644 U+0627، والرباط fi (U+FB01) متوافق مع الحرفين f وi. والمتغيرات التوافقية تبدو مختلفة أو تحمل تنسيقًا، لذا فإن طيّها يُفقد معلومات.

Unicode normalization converts text to one of four standard forms defined in Unicode Standard Annex 15. The D forms decompose, the C forms decompose and then recompose, and the K forms also apply the lossy compatibility mappings. The table gives the result for é, for the lam-alef ligature and for the fi ligature, with the UTF-8 byte count of each result so you can see that normalization changes lengths, not only identities.

تطبيع Unicode (Unicode normalization) يحوّل النص إلى أحد أربعة أشكال قياسية معرَّفة في الملحق 15 من معيار Unicode (UAX 15). أشكال D تفكّك، وأشكال C تفكّك ثم تعيد التركيب، وأشكال K تطبّق أيضًا تحويلات التوافق التي تُفقد معلومات. ويعطي الجدول النتيجة للحرف é ولرباط اللام ألف ولرباط fi، مع عدد بايتات UTF-8 لكل نتيجة، لترى أن التطبيع يغيّر الأطوال، لا الهويات فقط.

Here is the tokenizer bug normalization prevents. Suppose a BPE vocabulary is learned on NFC text, so "café" is one frequent token. Now NFD input arrives. The tokenizer sees c a f e U+0301, finds no merge that includes a lone combining mark, and emits "cafe" plus a separate accent token that no training word ever contained. Equality tests, dictionary lookups and Tokenization all fail in the same way, and all three are fixed by normalizing once, at ingestion, before anything else runs. Note that alef normalization in Arabic NLP toolkits, which folds U+0623, U+0625 and U+0622 into bare alef, is an application rule on top of Unicode, not one of the four forms.

هذا هو خلل المقطِّع الذي يمنعه التطبيع. افترض أن مفردات BPE تعلّمت على نص بصيغة NFC، فصارت "café" وحدة (token) واحدة متكررة. ثم وصل إدخال بصيغة NFD. يرى المقطِّع c a f e U+0301، ولا يجد أي دمج يتضمن علامة مركِّبة منفردة، فيُخرج "cafe" ومعها وحدة منفصلة للعلامة لم تحتوها أي كلمة في التدريب. واختبارات التساوي والبحث في القواميس والتقطيع tokenization تفشل كلها بالطريقة نفسها، وكلها تُصلَح بالتطبيع مرة واحدة عند الاستيعاب، قبل أن يعمل أي شيء آخر. ولاحظ أن تطبيع الألف في أدوات معالجة العربية، الذي يطوي U+0623 وU+0625 وU+0622 إلى ألف مجردة، قاعدة تطبيقية فوق Unicode، وليس أحد الأشكال الأربعة.

The Arabic word كتاب has four letters, and Python's len agrees: four. Encode it and count the bytes: eight. The English word "Hi" is two and two. The difference is the whole content of this concept. Every Code point above U+007F needs more than one byte, and the rule that decides how many, and which bits go where, is small enough to learn by heart.

كلمة كتاب العربية فيها أربعة حروف، والدالة len في Python توافق: أربعة. رمّزها وعُدّ البايتات: ثمانية. أما الكلمة الإنجليزية "Hi" فاثنان واثنان. هذا الفرق هو مضمون هذا المفهوم كله. فكل نقطة ترميز فوق U+007F تحتاج إلى أكثر من بايت، والقاعدة التي تحدد كم بايتًا، وأي البتات تذهب إلى أين، صغيرة بما يكفي لتحفظها عن ظهر قلب.

UTF-8 is a variable-length encoding form that maps each Unicode scalar value (a code point that is not a surrogate) to a sequence of one to four bytes. It is defined in the Unicode core specification and, for the Internet, in RFC 3629. Code points below 0x80 take one byte, and most other characters take two, three or four. The slide's mapping table is the exact rule, reproduced here with the payload capacity of each row.

UTF-8 صيغة ترميز متغيرة الطول تحوّل كل قيمة عددية في Unicode (scalar value، أي نقطة ترميز ليست بديلًا surrogate) إلى سلسلة من بايت واحد إلى أربعة بايتات. وهي معرَّفة في المواصفة الأساسية لـ Unicode، ولأغراض الإنترنت في RFC 3629. نقاط الترميز تحت 0x80 تأخذ بايتًا واحدًا، ومعظم الحروف الأخرى تأخذ اثنين أو ثلاثة أو أربعة. وجدول التحويل في الشريحة هو القاعدة الدقيقة، وهو منقول هنا مع سعة الحمولة لكل صف.

Read the templates as two kinds of byte. The first byte of every sequence is the lead byte, and its run of leading ones announces the length: 0 means one byte, 110 two, 1110 three and 11110 four. Every later byte is a continuation byte and starts 10, leaving six payload bits. The payload capacities are 7, 11, 16 and 21 bits, and the last is no accident: the largest code point U+10FFFF is exactly a 21-bit number, so four bytes suffice for the whole codespace.

اقرأ القوالب بوصفها نوعين من البايتات. البايت الأول في كل سلسلة هو البايت القائد lead byte، وسلسلة الآحاد في بدايته تعلن الطول: 0 تعني بايتًا واحدًا، و110 اثنين، و1110 ثلاثة، و11110 أربعة. وكل بايت بعده بايت استمرار (continuation byte) يبدأ بـ 10، فيترك ست بتات للحمولة. وسعات الحمولة هي 7 و11 و16 و21 بتًا، والأخيرة ليست مصادفة: فأكبر نقطة ترميز U+10FFFF عدد من 21 بتًا بالضبط، لذا تكفي أربعة بايتات لفضاء الترميز كله.

Now do it live. The simulator below encodes whatever you type, one character at a time, and shows the row, the payload bits, the templates and the resulting bytes. It preloads Hi كتاب 😀: nine code points, ten UTF-16 units and sixteen bytes. The € 中 preset exercises the three-byte row, the only one with a 1110 lead byte. Switch the normalization control to NFD with the café preset, or to NFKC with the ligature preset, and watch the byte count change before a single byte is encoded.

جرّبها الآن مباشرة. المحاكي أدناه يرمّز كل ما تكتبه، حرفًا حرفًا، ويعرض الصف وبتات الحمولة والقوالب والبايتات الناتجة. وهو يُحمَّل مسبقًا بالنص Hi كتاب 😀: تسع نقاط ترميز، وعشر وحدات UTF-16، وستة عشر بايتًا. والإعداد المسبق € 中 يختبر صف الثلاثة بايتات، وهو الصف الوحيد ذو البايت القائد 1110. حوّل عنصر التحكم في التطبيع إلى NFD مع الإعداد المسبق café، أو إلى NFKC مع الإعداد المسبق للرباط، وراقب عدد البايتات يتغير قبل أن يُرمَّز بايت واحد.

Decoding, and why the prefixes matterفك الترميز، ولماذا تهم البادئات

The prefixes are what make UTF-8 safe to read from any position. A decoder that sees a byte starting 0 knows it is a complete ASCII character. A byte starting 110, 1110 or 11110 announces one, two or three continuation bytes to follow. A byte starting 10 can never begin a character, so a decoder dropped into the middle of a stream steps backwards at most three bytes to find a lead byte. RFC 3629 lists this as a design property (character boundaries are easily found from anywhere in an octet stream), Jurafsky and Martin call it self-synchronizing, and it is why a corrupted byte damages one character rather than the rest of the file.

البادئات هي ما يجعل قراءة UTF-8 آمنة من أي موضع. فمفكِّك الترميز الذي يرى بايتًا يبدأ بـ 0 يعرف أنه حرف ASCII كامل. والبايت الذي يبدأ بـ 110 أو 1110 أو 11110 يعلن أن بعده بايت استمرار واحدًا أو اثنين أو ثلاثة. أما البايت الذي يبدأ بـ 10 فلا يمكن أن يبدأ حرفًا أبدًا، لذا فإن المفكِّك الذي يُلقى في منتصف تدفق يرجع إلى الخلف ثلاثة بايتات على الأكثر ليجد بايتًا قائدًا. ويذكر RFC 3629 هذا بوصفه خاصية تصميمية (حدود الحروف يسهل إيجادها من أي مكان في تدفق الثُّمانيات)، ويسميها Jurafsky وMartin المزامنة الذاتية (self-synchronizing)، وهي سبب أن البايت التالف يُفسد حرفًا واحدًا لا بقية الملف.

Three consequences follow from the table and are worth stating explicitly. First, backward compatibility with ASCII: every code point below 0x80 becomes the single byte with the same value, so an ASCII file is already a valid UTF-8 file and a UTF-8 file that happens to contain only ASCII is byte for byte an ASCII file. Second, bytes below 0x80 never appear inside a multibyte sequence, so a program that searches for a space or a newline byte will never find one in the middle of an Arabic letter. Third, some byte values are simply impossible: C0, C1 and F5 to FF never occur in valid UTF-8, because they would encode overlong sequences or code points past U+10FFFF (RFC 3629, section 1, with the syntax that rules them out in section 4).

ثلاث نتائج تترتب على الجدول وتستحق أن تُذكر صراحة. أولًا، التوافق مع ASCII: كل نقطة ترميز تحت 0x80 تصبح بايتًا واحدًا بالقيمة نفسها، لذا فإن ملف ASCII هو أصلًا ملف UTF-8 صالح، وملف UTF-8 لا يحتوي إلا ASCII هو ملف ASCII بايتًا ببايت. ثانيًا، البايتات تحت 0x80 لا تظهر أبدًا داخل سلسلة متعددة البايتات، لذا فإن البرنامج الذي يبحث عن بايت مسافة أو سطر جديد لن يجده أبدًا في منتصف حرف عربي. ثالثًا، بعض قيم البايتات مستحيلة ببساطة: C0 وC1 ومن F5 إلى FF لا تظهر أبدًا في UTF-8 صالح، لأنها سترمّز سلاسل مطوّلة (overlong) أو نقاط ترميز بعد U+10FFFF (RFC 3629، القسم 1، مع الصياغة التي تستبعدها في القسم 4).

A tokenizer trained with a character vocabulary in 2020 meets the melting face emoji 🫠, added as U+1FAE0 in Unicode 14 the following year. It has never seen the character, so it emits the unknown token. The same happens with an Arabizi spelling like "ktaab" typed into a word-level vocabulary, or any typo, any new script, any rare Han character. Now imagine the base symbols were bytes instead. Every UTF-8 byte is one of exactly 256 values, all of them already in the vocabulary, so there is nothing left to be unknown.

مقطِّع دُرِّب بمفردات من الحروف عام 2020 يصادف الرمز التعبيري للوجه الذائب 🫠، الذي أُضيف بوصفه U+1FAE0 في Unicode 14 في العام التالي. لم يرَ هذا الحرف قط، فيُخرج وحدة المجهول (unknown token). ويحدث الشيء نفسه مع كتابة بالعربيزي مثل "ktaab" تُكتب في مفردات على مستوى الكلمة، أو مع أي خطأ إملائي، أو أي نظام كتابة جديد، أو أي حرف هان نادر. والآن تخيّل أن الرموز الأساسية كانت بايتات بدلًا من ذلك. كل بايت في UTF-8 هو واحد من 256 قيمة بالضبط، وكلها موجودة أصلًا في المفردات، فلا يبقى شيء يمكن أن يكون مجهولًا.

That is Byte-level tokenization: treat the UTF-8 bytes of the text, not its characters, as the atoms. Radford and colleagues motivated it in the GPT-2 paper with the numbers. A Code point base vocabulary would start at over 130,000 symbols before a single merge (about 160,000 in Unicode 17), while a byte-level base needs only 256. Jurafsky and Martin draw the consequence: because there are only 256 possible byte values, there will be no unknown tokens, and the <UNK> symbol becomes unnecessary. Arbitrary scripts, emoji and typos all decompose into bytes the model has seen.

هذا هو التقطيع على مستوى البايت byte-level tokenization: عامِل بايتات UTF-8 للنص، لا حروفه، بوصفها الذرّات. وقد برّره Radford وزملاؤه في ورقة GPT-2 بالأرقام. فمفردات أساسية مبنية على نقاط الترميز ستبدأ بأكثر من 130,000 رمز قبل أي دمج (نحو 160,000 في Unicode 17)، بينما تحتاج القاعدة على مستوى البايت إلى 256 فقط. ويستخلص Jurafsky وMartin النتيجة: لأنه لا توجد إلا 256 قيمة ممكنة للبايت، فلن تكون هناك وحدات مجهولة unknown، ويصبح الرمز <UNK> غير ضروري. فأنظمة الكتابة أيًّا كانت والرموز التعبيرية والأخطاء الإملائية تتفكك كلها إلى بايتات رآها النموذج.

The price is structure. Bytes do not know where a character ends. The word كتاب becomes eight opaque symbols, and the letter ب is D8 A8, two units that mean nothing on their own. A sentence of Arabic is roughly twice as many base units as Latin text of the same length, which the simulator's كتاب preset shows as 4 characters against 8 bytes. Left alone, a byte model would spend its capacity relearning the UTF-8 table. So bytes are never used alone: they are combined with learned merges that glue frequent byte sequences back into characters, then into subwords. Jurafsky and Martin note that BPE over bytes rediscovers the two- and three-byte UTF-8 sequences early, and that it can also learn invalid sequences straddling a character boundary, which implementations filter out. GPT-2 adds a rule that prevents merges across character categories, because naive byte merges were sub-optimal.

الثمن هو البنية. فالبايتات لا تعرف أين ينتهي الحرف. كلمة كتاب تصبح ثمانية رموز معتمة، وحرف ب هو D8 A8، وحدتان لا تعنيان شيئًا بمفردهما. والجملة العربية تساوي تقريبًا ضعف عدد الوحدات الأساسية لنص لاتيني بالطول نفسه، وهو ما يُظهره الإعداد المسبق كتاب في المحاكي: 4 حروف مقابل 8 بايتات. ولو تُرك نموذج البايتات وحده لأنفق سعته في إعادة تعلّم جدول UTF-8. لذا لا تُستخدم البايتات وحدها أبدًا: بل تُجمع مع دمجات merges متعلَّمة تلصق سلاسل البايتات المتكررة لتعيدها حروفًا، ثم وحدات دون الكلمة subwords. ويلاحظ Jurafsky وMartin أن BPE على البايتات يعيد اكتشاف سلاسل UTF-8 ذات البايتين والثلاثة بايتات مبكرًا، وأنه قد يتعلم أيضًا سلاسل غير صالحة تمتد عبر حدود الحرف، وتقوم التطبيقات بتصفيتها. ويضيف GPT-2 قاعدة تمنع الدمج عبر فئات الحروف، لأن دمج البايتات الساذج كان دون المستوى الأمثل.