Чому індійські мови коштують більше токенів у LLM і як лагодять токенізатори

Скажіть те саме коротке речення п'ятьма мовами й порахуйте, скільки доведеться перетравити LLM. Результати навіть близько не схожі, і складність мови тут майже ні до чого.

Одне речення, п'ять цінників

Вимірювання для одного короткого речення:

Мова	Символи	Байти	Слова	Токени
Англійська	18	18	4	5
Гінді	12	30	3	13
Телугу	17	45	3	20
Каннада	16	44	2	22
Тамільська	30	84	3	34

Зміст однаковий. Важливий останній стовпець. Токени — це маленькі шматочки, які модель насправді читає: ціле слово, фрагмент або лише кілька символів. Англійській знадобилося приблизно по токену на слово. Тамільській — майже одинадцять.

Річ зовсім не в тому, що тамільську важче зрозуміти. Розрив з'явився через рішення, ухвалене задовго до того, як хтось набрав промпт: як було побудовано токенізатор моделі. І наслідки цілком реальні. Розмови індійськими мовами швидше заповнюють контекстне вікно, дорожче коштують і повільніше повертаються, навіть коли кажуть рівно те саме, що англомовний користувач каже дешевше.

Далі — чому цей розрив існує, що невеликий експеримент показує про його скорочення і що потрібно, щоб полагодити токенізатор у вже навченої моделі.

Що робить токенізатор

Перш ніж модель обробить речення, токенізатор ріже його на токени, базові будівельні блоки, трохи схожі на кубики Lego. Усе, що далі, зокрема пам'ять моделі про чат, витрачені обчислення та швидкість відповіді, рахується в токенах, а не в словах чи літерах. Таблиця вище — це пряме свідчення того, наскільки ефективно нарізано кожну мову.

Цю нарізку ніхто не вигадує вручну. Вона вивчається на величезній купі тексту за допомогою байтового BPE, скорочення від Byte Pair Encoding. Рецепт простий: почати із сирих байтів, знайти пару, яка найчастіше трапляється поруч у навчальному тексті, і злити її в новий токен. Повторити. Перші кроки виглядають так:

t h  →  th
th e →  the

Після тисяч раундів виходить словник, де кожен запис заслужив місце частотою. Шматочки на кшталт «the», «-ing» і «-tion» стають окремими дешевими токенами в корпусі з перевагою англійської, бо трапляються постійно.

Чому байти — хибний слід

Англійські літери займають по одному байту. Більшість індійських писемностей, як-от деванагарі, телугу, тамільське письмо й каннада, займають по три байти на символ, бо їхні набори символів значно більші. Хочеться зробити висновок, що три байти — це три токени, але це неправильно. Байтовий токенізатор може злити кілька байтів в один токен, тож трибайтовий символ не обов'язково коштує три. Його ціна залежить від того, чи вивчив токенізатор добре злиття для цієї послідовності байтів, а це, своєю чергою, залежить від того, скільки тексту цією мовою він бачив.

Тож справжнє пояснення — навчальні дані, а не складність писемності. Навчіть на 90% англійської й 10% усього іншого, і англійські патерни отримають тисячі шансів заробити ефективні однотокенні злиття. Індійські отримають значно менше й лишаться дрібними дорогими шматками. Алгоритм не упереджений у жодному моральному сенсі. Частота — просто єдине, що оптимізує BPE.

Експеримент: чи допомагає перебалансування даних?

Щоб це перевірити, з нуля навчили три невеликі токенізатори, змінюючи між ними лише склад мов:

• Токенізатор A: 90% англійської й 10% індійських мов, як будуються багато реальних токенізаторів, адже більшість тексту в інтернеті англійською
• Токенізатор B: рівно 50/50 між англійськими та індійськими текстами
• Токенізатор C: рівні частки англійської, гінді, телугу, тамільської й каннада

Одне застереження. Корпус був малим і зібраним власноруч, щоб ізолювати одну змінну. Це не промисловий масштаб, тож напрямок і відносний розмір зсувів важливіші за абсолютні цифри.

Токенів на слово на відкладених тестових реченнях:

Мова	A (90% англійської)	B (50/50)	C (збалансований)
Англійська	3.05	3.08	3.60
Гінді	5.34	4.32	4.34
Телугу	7.79	6.36	6.36
Тамільська	10.75	8.47	7.84
Каннада	8.86	7.34	7.07

Перехід від A до B, який дає індійським мовам справедливішу частку, знизив вартість гінді приблизно на 19%, телугу приблизно на 18% і тамільської приблизно на 21%, а англійська майже не зрушила. Якийсь час перебалансування дає дуже добру віддачу.

Подальший перехід до повністю збалансованого складу дав спадну віддачу для індійських мов і відкусив шматок в англійської (з 3.08 до 3.60). Тож більше балансу — не завжди краще. Є оптимальна точка, а не пряма лінія.

Чи виправить це більший словник?

На тому самому збалансованому корпусі перебрали розмір словника. Токенів на слово:

Мова	300	800	1,500	3,000
Англійська	5.28	3.70	3.70	3.70
Гінді	6.75	3.55	3.55	3.55
Телугу	9.64	6.42	6.42	6.42
Тамільська	10.72	7.78	7.78	7.78
Каннада	10.17	7.17	7.17	7.17

Перехід із 300 на 800 сильно допоміг усім мовам. Далі нічого не змінювалося, бо в крихітному корпусі закінчилися часті патерни, які варто було б перетворювати на нові токени. У промисловому масштабі варто чекати кривої тієї самої форми зі спорідненої причини: кожен новий слот захоплює дедалі рідкісніші патерни, тож виграш стискається. У будь-якому разі більший словник не кращий автоматично. Він роздуває таблицю ембедингів і вихідний шар, тож це реальна ціна, а не безкоштовний апгрейд.

Жоден із важелів, ні перебалансування, ні зростання словника, сам по собі не дає чистого рішення. Звідси складніше питання: що робити з уже навченою моделлю з поганим, перекошеним в бік англійської токенізатором, коли почати наново не можна.

Чому токенізатор не можна просто замінити

Замінити старий токенізатор кращим багатомовним — очевидна ідея, і вона провалюється, бо токенізатор глибоко вшитий у модель.

Навчання дає кожному токену власний ембединг — вектор, що позначає зміст цього токена, і всі інші шари працюють із цими векторами. Припустімо, ID 1234 відповідає ембедингу для «hello». Якщо новий токенізатор віддасть 1234 привітанню гінді, ембединг у цьому слоті все одно означатиме «hello». Ніщо не повідомляє трансформеру, що зміст змінився. Вивід стає безладним, бо вивчені знання моделі досі прив'язані до старих ID, а цей зв'язок тихо обірвався.

Як команди додають мови заднім числом: розширити словник, заморозити ваги

Техніка, яку використовують по всій індустрії, — розширення словника, і роблять його обережно, щоб уникнути саме цієї поломки. Загалом:

1. Не чіпати наявний словник. Жоден поточний ID токена не перепризначається, бо саме перепризначення спричиняє розузгодження.
2. Дописати нові токени для цільових мов. Свіжий набір злиттів, часто навчений на багатомовному чи мовному корпусі, додається новими ID після наявних, тож нічого не замінюється. Словник на 32K може вирости понад 100K.
3. Ініціалізувати нові ембединги. Випадкові значення працюють, але усереднення споріднених ембедингів дає тепліший старт, бо суто випадковий вектор нічого не каже зовсім новому токену.
4. Заморозити початкові ваги й спершу навчати лише нові ембединги. На цьому кроці тримається весь підхід. Усе, що модель уже знає про англійську, міркування й код, лишається заблокованим. Змінюватися можуть лише нові рядки ембедингів і часто нові рядки вихідного шару. Модель дізнається, що означають нові токени, не ризикуючи катастрофічним забуванням — відомим збоєм, коли нове навчання перезаписує старі знання.
5. Продовжити передзавчання на текстах новими мовами, і далі тримаючи більшу частину моделі замороженою, доки нові ембединги не наберуть достатньо змісту, щоб заморожені шари могли ними користуватися.
6. Розморожувати поступово. Іноді спершу верхні шари, іноді все одразу, і навчання триває, щоб уся мережа пристосувалася до збільшеного словника.

Уявіть, що до будинку прибудовують нові кімнати, а не зносять його й будують наново. Наявні знання на ранніх етапах лишаються незайманими, поки нові кімнати облаштовують окремо, і лише потім увесь будинок перебудовується навколо них.

Це ж показує, чому зміни словника стосуються не лише входу. Модель має читати нові токени, і це робота вхідних ембедингів, а ще породжувати їх у відповідях. Це завдання вихідного шару, який іноді називають LM head: він оцінює кожен запис словника як можливий наступний токен. Навчання має охоплювати обидва кінці, а чи ділять ці два шари ваги, залежить від архітектури.

Зауваження щодо точності: конкретні промислові рецепти, тобто графіки заморожування, обрані розміри словника й тривалість кожного етапу, пропрієтарні й у кожної команди свої, тож без публічного джерела жоден із них не варто приписувати конкретній компанії. Поетапний патерн розширення, розігріву й поступового розморожування — загальний задокументований підхід, а конкретні цифри не публікуються.

Чого це не доводить

Ефективність токенізації — не те саме, що якість моделі. Низьке число токенів на слово не показує, що модель розуміє мову, ясно нею міркує чи добре з неї перекладає. Дешева токенізація може поєднуватися зі слабкою моделлю, а дорога — із сильним розумінням. Усе це стосується економічного шару, тобто вартості, затримки й витрати контексту, а не розуміння.

Увесь ланцюжок цілком

Різні писемності отримують різні байтові представлення. BPE вивчає злиття за частотою в навчальних даних. Недостатньо представлені мови отримують менше ефективних злиттів. Тому їм потрібно більше токенів, щоб сказати те саме, а це означає менше корисного контексту, повільніші відповіді й більші рахунки за однакові розмови.

Перебалансування даних і збільшення словника допомагають, але обидва виходять на плато й обидва мають реальну ціну. Розширення словника із замороженими вагами, проведене акуратно, щоб уникнути катастрофічного забування, складніше за кожен важіль окремо. Саме тому команди обирають його, а не перенавчають із нуля більший і збалансованіший токенізатор.

Для багатомовних LLM токенізатор — не другорядна попередня обробка. Це частина економіки мови, і правильно полагодити його після навчання — справжня інженерна робота, а не просто кращі дані. Пам'ятайте, що цифри вище отримано на іграшковій конфігурації BPE, побудованій так, щоб змінювати одну річ за раз, і вони нічого не кажуть про те, як працює будь-який реальний токенізатор.