Язык и стиль: continued pretraining, DPO и ORPO

Язык — это знание, стиль — это поведение

Язык — словарь, морфология, реалии. Если базовая модель путает казахские падежи и вставляет русские слова, это пробел в знании, и SFT на паре тысяч диалогов его не закроет: нужен continued pretraining (CPT, продолжение предобучения на сыром тексте языка) на миллиардах tokens. Стиль — тон, длина, структура ответа, запреты. Это поведение: хватает prompt, затем SFT (supervised fine-tuning, обучение на парах «запрос → эталон») на сотнях – низких тысячах пар, а тонкую настройку «так лучше, так хуже» даёт preference tuning (обучение на парах ответов).

Перед любым решением — замер. Прогони базовую instruct-модель (версию, уже обученную быть ассистентом) с хорошим prompt на наборе вопросов на целевом языке. Ответы грамотны, не хватает тона — CPT не нужен. Для русского, которого в открытых корпусах много, так часто и выходит, но решает замер, а не ожидание.

Шаг 1: tokenizer fertility

Tokenizer fertility (плодовитость tokenizer) — среднее число tokens на слово. Tokenizer, обученный в основном на английском, режет казахское слово на много мелких кусков. Статья «Language Model Tokenizers Introduce Unfairness Between Languages» нашла, что один и тот же текст в разных языках даёт число tokens с разницей «up to 15 times»; это бьёт по цене, задержке и объёму текста, который помещается в context.

Условный пример. 1 000 английских слов — 1 300 tokens (1,3 на слово). 1 000 казахских слов — 3 100 tokens (3,1 на слово). Значит, казахский ответ той же длины в 2,4 раза дороже и медленнее, а в context на 32 000 tokens помещается в 2,4 раза меньше казахских документов. Меряешь на своих 10 000 словах, а не на чужой таблице.

Лечение — vocabulary extension (расширение словаря новыми tokens). Но строкам embedding (числового вектора token) и выходного слоя lm_head для новых tokens нужны начальные значения и обучение, поэтому расширять словарь имеет смысл только вместе с CPT. Цена: модель больше не совместима по tokens с оригиналом, и готовые adapters и малые модели для speculative decoding (ускорения генерации с помощью малой модели-черновика) к ней не подходят.

Шаг 2: CPT с replay

Главный риск CPT — catastrophic forgetting (катастрофическое забывание): модель становится лучше в казахском и хуже в английском, математике, коде. Статья «Simple and Scalable Strategies to Continually Pre-train LLMs» показывает, что комбинации «LR re-warming, LR re-decaying, and replay of previous data» достаточно, чтобы сравняться с полным переобучением на всех данных, в том числе при сдвиге с английского на немецкий. Replay — подмешивание данных старого распределения; re-warming и re-decaying — снова поднять, а потом плавно опустить скорость обучения.

Публичный пример — issai/Qwen3.5-35B-A3B-Base-Kazakh (карточка открыта 10.10.2026): - около 15,9 млрд tokens, смесь 50/50 казахский и английский; казахская половина — дедуплицированный корпус из FineWeb-2, CulturaX, FinePDFs, FineWiki; английская — «retention replay» из FineWeb-Edu, Nemotron-CC и Stack-Edu (код); культурные казахские наборы повторены 3 раза; - словарь 248 320 → 264 192 tokens, плюс 16 000 в основном кириллических казахских tokens; новые строки инициализированы методом FVT (Fast Vocabulary Transfer): среднее embeddings тех старых кусков, на которые слово резалось раньше; - 1 эпоха, длина последовательности 16 384, скорость обучения 1e-5 с косинусным спадом до 1e-6, 2 % warmup (разогрев); - полное обучение всех параметров, не LoRA, на двух узлах по 8 H100.

Логика выбора понятна: сдвиг большой, данных миллиарды tokens, а статья «LoRA Learns Less and Forgets Less» показала, что на continued pretraining LoRA заметно уступает полному обучению в целевом домене.

Шаг 3: вернуть ассистента и измерить цену

CPT на сыром тексте портит умение вести диалог. Обычный путь — SFT на инструкциях на целевом языке. ISSAI пошла другим путём: chat vector. Разность весов «официальная instruct минус официальная base» прибавили к CPT-модели: θ_merged = θ_cpt + (θ_inst − θ_base). Статья Chat Vector утверждает, что так модель получает диалог на новом языке «without the need for further training». Деталь, которая отличает инженера: строки special tokens (<|im_start|>, <|im_end|>, <think>) закрепили на значениях официальной модели, потому что сырой chat vector их сбивает и модель «loop and never terminate». Карточка пишет: «No additional post-training (SFT, RLHF, or RLVR) is used.»

Карточка сама показывает компромисс на benchmarks (стандартных наборах тестов): KazMMLU 82,6 → 84,0, KazCulture 60,3 → 68,7, а английский MMLU 91,2 → 89,3, GPQA-Diamond 86,9 → 82,3, GSM8K на казахском 92,7 → 89,3. Цену не прячут — её меряют и решают, приемлема ли она для задачи. Ассистенту, который считает комиссии, просадку в математике закрывают tools.

Стиль: SFT, потом DPO или ORPO

SFT учит «делай вот так». Preference tuning учит «вот это лучше того» и полезен, когда хороший и плохой ответ отличаются тонко: оба по делу, но один снисходительный.

• RLHF с PPO (reinforcement learning from human feedback, старая схема) — сначала обучить reward model (модель-оценщик), потом RL с генерацией во время обучения. Авторы DPO называют это «a complex and often unstable procedure».
• DPO (direct preference optimization) решает ту же задачу «with only a simple classification loss». Данные — тройки prompt, chosen, rejected. Обучение раздвигает вероятности хорошего и плохого ответа относительно reference model (замороженной копии стартовой модели); параметр beta (в TRL v1.15.0 по умолчанию 0.1) держит модель рядом с reference: чем больше beta, тем меньше отход. Документация TRL отмечает, что на практике это чаще достигается снижением вероятности плохого ответа, а не ростом хорошего. Следи за rewards/margins и rewards/accuracies в журнале.
• ORPO (odds ratio preference optimization) берёт те же пары, но без reference model и без отдельного этапа: штраф через odds ratio (отношение шансов) добавляется к обычному SFT loss. SFT и preference за один проход, меньше памяти. В TRL v1.15.0 он лежит в trl.experimental.orpo.

Откуда пары: два ответа модели на один запрос, человек выбирает лучший; или исправленный оператором ответ (chosen) против исходного (rejected). Без письменных правил выбора пары противоречат друг другу, и модель учит шум.

{"prompt": [{"role": "user", "content": "Почему мне отказали в кредите?"}],
 "chosen": [{"role": "assistant", "content": "Понимаю, это неприятно. Причины отказа банк сообщает в письме..."}],
 "rejected": [{"role": "assistant", "content": "Вам же написали, читайте внимательнее."}]}