# ГЛАВА 19. ДООБУЧЕНИЕ И POST-TRAINING: КОГДА ПРОМПТ УЖЕ НЕ СПАСАЕТ

---

Prompt engineering — это подробная инструкция для нового сотрудника. RAG — справочная библиотека, к которой он обращается по мере необходимости. Fine-tuning — отправка на специализированное обучение: после него человек *работает иначе*, навык встроен в голову, а не записан на бумажке. Вы не отправляете каждого стажёра в аспирантуру — дорого, долго, последствия необратимы. Но иногда инструкция и библиотека *не справляются*: сотруднику нужно не знание, а навык.

Эта глава объясняет post-training pipeline — SFT, RLHF, DPO, GRPO, LoRA — чтобы вы могли принимать обоснованные решения: когда дообучение оправдано, а когда проще переписать промпт. Цель — не превратить вас в ML-исследователя, а дать достаточно понимания, чтобы разговаривать с ML-командой на одном языке и принимать архитектурные решения.

Книга последовательно строила аргумент: [главы 6](06_prompt_is_a_protocol.md)–[9](09_multistep_reasoning.md) — prompt engineering, [глава 12](12_rag.md) — RAG, [глава 13](13_anti_hallucination_loop.md) — антигаллюцинационный контур. Всё это — inference-time стратегии: вы не меняете модель, вы меняете то, что ей подаёте. Fine-tuning — следующий уровень: вы меняете *саму модель*. Это мощнее, но дороже и рискованнее.

---

## 19.1. Post-training pipeline: от pre-training к deployment

Модель, которую вы вызываете через API, прошла многоэтапный конвейер. Pre-training ([главы 1](01_tokens_vectors_and_semantic_space.md)–[5](05_long_context.md)) создаёт *возможности* — модель *умеет* следовать инструкциям, анализировать код, писать текст. Post-training создаёт *поведение* — модель *делает* то, что вы хотите, и не делает того, чего не хотите.

```
Pre-training (веб-данные, триллионы токенов)
         ↓
    Base model (знает язык, факты, паттерны)
         ↓
    SFT (пары инструкция–ответ)
         ↓
    Instruction model (следует инструкциям)
         ↓
    RLHF / DPO (предпочтения людей)
         ↓
    Aligned model (helpful, harmless, honest)
         ├──→ Deployment + prompt engineering + RAG
         ↓
    GRPO / RFT (RL на reasoning-задачах)
         ↓
    Reasoning model (chain-of-thought, self-verification)
         ↓
    Deployment + prompt engineering + RAG
```

**Pre-training** — грубая огранка: модель учит статистику языка на петабайтах текста. Base model может продолжить любой текст, но не умеет отвечать на вопросы — она с равной вероятностью продолжит ваш промпт цитатой из Википедии, рекламным текстом или случайным форумным постом.

**SFT (Supervised Fine-Tuning)** — первый этап post-training: модель учится формату «вопрос → ответ». После SFT base model превращается в instruction model — ту самую, с которой можно разговаривать.

**RLHF / DPO** — второй этап: модель учится не просто отвечать, а отвечать *хорошо*. Из нескольких корректных ответов выбирать тот, который полезнее, безопаснее — ближе к тому, что предпочёл бы человек.

Когда вы fine-tune'ите модель через API (OpenAI, Together AI, Fireworks), вы повторяете один или оба этапа post-training — но на *своих* данных.

---

## 19.2. SFT: supervised fine-tuning

SFT — самый простой и понятный метод дообучения. Вы берёте набор пар (инструкция, ответ) и обучаете модель на них тем же cross-entropy loss, что использовался при pre-training. На каждом токене модель сравнивает свой прогноз с эталонным ответом и штрафуется за расхождение.

Функция потерь идентична pre-training (см. [Главу 3, раздел 3.1](03_hallucinations.md)). Разница — в данных: вместо сырого веб-текста — курированные пары «вход → выход». Модель учится не продолжать произвольный текст, а *отвечать на вопрос в определённом формате*.

### Исторический контекст

**FLAN** (Wei et al., 2021) показал, что instruction tuning на наборе задач кардинально улучшает zero-shot способности. Модель, обученная отвечать на тысячи разнородных инструкций, начинает справляться с инструкциями, которых не видела при обучении. Это — первая демонстрация того, что формат «инструкция → ответ» обобщается.

**Alpaca** (Stanford, 2023) продемонстрировал, что это дёшево. 52K синтетических пар, сгенерированных text-davinci-003 методом Self-Instruct, менее $500 на генерацию данных. Результат: fine-tuned LLaMA 7B, конкурентоспособная с text-davinci-003 на многих задачах. Модель стоимостью в пиццу показала уровень модели стоимостью в суперкомпьютер — потому что данные были правильного формата.

### Когда SFT — правильный выбор

SFT работает, когда проблема — не *знание*, а *формат и стиль*. Типичные сценарии:

- Модель знает предметную область, но отвечает не в том формате (нужен JSON, модель даёт Markdown).
- Модель справляется с задачей, но тон не тот (нужен формальный юридический, модель даёт разговорный).
- Модель понимает задачу, но вы хотите, чтобы она всегда следовала определённому протоколу (шаги анализа, шаблон ответа).

SFT *не* добавляет новых знаний. Если модель не знает ваш внутренний API — SFT не поможет, нужен RAG. Если модель *знает*, но *не следует* — SFT поможет.

---

## 19.3. RLHF: reinforcement learning from human feedback

SFT учит модель *отвечать*. RLHF учит модель *отвечать хорошо* — по критериям, которые сложно формализовать: полезность, безопасность, честность. Это различие принципиально: вы не можете написать в loss function «будь полезной». Но вы можете показать модели два ответа и спросить человека: «какой лучше?»

Ouyang et al. (2022) — статья про InstructGPT — заложила фундамент. Три этапа:

### Этап 1: SFT на демонстрациях

Люди пишут идеальные ответы на набор промптов. Модель обучается на этих парах стандартным SFT. Это — стартовая точка.

### Этап 2: обучение reward model

Для каждого промпта модель генерирует несколько ответов. Люди ранжируют их: какой лучше, какой хуже. На этих ранжировках обучается **reward model** — отдельная нейросеть, которая принимает пару (промпт, ответ) и выдаёт одну числовую оценку качества.

Reward model конвертирует качественные человеческие суждения («этот ответ полезнее») в дифференцируемый сигнал, который можно использовать для оптимизации. Это — ключевой инженерный трюк: вы переводите неформализуемое понятие «качество» в числовую функцию.

### Этап 3: PPO fine-tuning

Модель оптимизируется алгоритмом PPO (Proximal Policy Optimization) — стандартным методом из reinforcement learning. Практический смысл целевой функции такой: модель должна чаще выдавать ответы с высокой наградой, но при этом не уходить слишком далеко от SFT-версии. Для этого в objective одновременно есть бонус за высокий score reward model и штраф за чрезмерное отклонение от исходной instruction-model.

Без этого штрафа модель быстро находит «дыры» в reward model — генерирует бессмысленные, но высокооценённые последовательности (reward hacking).

### Результат

InstructGPT 1.3B — модель со ~135× меньшим числом параметров, чем GPT-3 175B — была предпочтена людьми в слепых сравнениях. RLHF не добавил знаний — он научил модель *использовать* имеющиеся знания так, как хотят люди.

### Проблемы RLHF

- **Дорого.** Нужны люди-оценщики, это медленный и дорогостоящий процесс.
- **Нестабильно.** PPO — капризный алгоритм: чувствителен к гиперпараметрам, легко расходится.
- **Сложно.** Три отдельных этапа обучения (SFT → RM → PPO), каждый — отдельная ML-задача.
- **Reward hacking.** Модель оптимизирует proxy (reward model), а не реальную цель (закон Гудхарта). Gao et al. (2022) формализовали scaling laws для этого эффекта: чем дольше оптимизация, тем сильнее расхождение между оценкой RM и реальным качеством.

Именно эти проблемы мотивировали поиск альтернатив — и привели к DPO.

---

## 19.4. DPO: direct preference optimization

Rafailov et al. (2023) задали вопрос: можно ли обойтись без reward model и PPO? Оказалось — можно.

### Ключевая идея

Стандартный RLHF — это цепочка: предпочтения людей → reward model → PPO-оптимизация модели. DPO показал, что reward model можно *репараметризовать* через саму language model, исключив два промежуточных этапа. Название статьи — «Your Language Model is Secretly a Reward Model» — буквально описывает идею: любая language model *уже является* reward model через соотношение log-вероятностей.

### Loss function

Вместо трёхэтапного конвейера DPO использует одну целевую функцию. Интуиция: для каждого промпта DPO сравнивает, насколько текущая модель предпочитает «хороший» ответ над «плохим» — и насколько это предпочтение отличается от reference model. Loss штрафует модель, если она недостаточно сильно разделяет хороший и плохой ответы.

Что это значит на словах: DPO поощряет модель *увеличивать* разрыв между тем, насколько она предпочитает хороший ответ и плохой, относительно reference model. `pi_ref` — это SFT-модель, от которой DPO стартует. `beta` — параметр, контролирующий, насколько далеко модель может уйти от reference.

### Результаты и преимущества

DPO показал качество на уровне PPO-based RLHF и выше — на задачах суммаризации и диалогов (Rafailov et al., 2023). При этом:

| Характеристика | RLHF (PPO) | DPO | GRPO (§19.5) |
|----------------|-----------|-----|------|
| Количество этапов | 3 (SFT → RM → PPO) | 1 (SFT → DPO) | 1 (SFT → GRPO) |
| Reward model | Нужна отдельная | Не нужна | Не нужна |
| Reference model | Нужна | Нужна | Не нужна |
| Данные | Ранжировки от людей | Пары предпочтений | Rule-based сигналы |
| Стабильность | Чувствителен к гиперпараметрам | Стабильнее | Стабильный |
| GPU-память | RM + Policy + Reference | Policy + Reference | Только Policy |
| Гиперпараметры | Много (PPO: clip ratio, GAE λ, learning rate…) | Мало (`beta`, learning rate) | Rule-based rewards |

### Доступность

DPO доступен через OpenAI fine-tuning API для моделей gpt-4.1, gpt-4.1-mini, gpt-4.1-nano. Формат данных — пары предпочтений: для каждого промпта указывается предпочтённый и отвергнутый ответ. Это упрощает миграцию с SFT на DPO: если вы уже собрали данные с оценками качества, конвертировать их в preference pairs — тривиально.

### После DPO: reference-light и reference-free семейство

После успеха DPO появилось целое семейство методов, которые пытаются ещё сильнее упростить preference optimization. Идея общая: **сохранить эффект alignment, но убрать лишние сущности из training loop** — reference model, отдельную фазу RL или требование к строго парным данным.

| Метод | Что упрощает | Когда особенно полезен | Ограничение |
|------|--------------|------------------------|-------------|
| **ORPO** | Встраивает preference optimization прямо в SFT и убирает reference model | Когда хотите максимально простой pipeline «SFT + alignment в одном проходе» | Менее стандартизирован в проде, чем DPO |
| **KTO** | Учится на бинарном сигнале desirable / undesirable вместо парных сравнений | Когда у вас есть thumbs up / thumbs down, accept / reject, но нет пар предпочтений | Качество сильно зависит от калибровки бинарных меток |
| **SimPO** | Использует reference-free reward на основе average log probability | Когда paired preferences есть, но memory / compute budget ограничен | Всё ещё требует аккуратной настройки margin и eval-набора |

Практическая эвристика: **DPO остаётся самым надёжным дефолтом**, если у вас уже есть pairwise preference data и инфраструктура под него. ORPO, KTO и SimPO — это не «замена по умолчанию», а более лёгкие инструменты под конкретный тип данных и ресурсных ограничений.

DPO убрал reward model из pipeline. Следующий шаг — GRPO — убирает и reference model. Подробнее — в §19.5.

---

## 19.5. GRPO и Reinforcement Fine-Tuning: alignment без reward model

GRPO (Group Relative Policy Optimization) — следующий шаг упрощения после DPO. Если DPO убрал из pipeline reward model, то GRPO убирает *и* reward model, *и* reference model.

### GRPO: идея

Shao et al. (2024) предложили альтернативу PPO, в которой преимущество (advantage) каждого ответа вычисляется не отдельной моделью, а *внутри группы*. Для каждого промпта модель генерирует группу из $G$ ответов, каждый оценивается простой rule-based функцией (например, «ответ правильный» / «формат корректный»). Преимущество ответа — его нормализованное отклонение от средней награды в группе.

Ключевое упрощение: не нужно обучать отдельную reward model, не нужно хранить reference model для KL-штрафа. Модель учится, сравнивая свои собственные ответы друг с другом. Это значительно дешевле и стабильнее, чем PPO и DPO.

> В некоторых вариантах GRPO KL-штраф относительно reference model может сохраняться, но ключевое упрощение — вычисление advantage внутри группы без отдельной reward model.

### DeepSeek-R1: GRPO в production

DeepSeek-R1 (Guo et al., 2025) продемонстрировал, что reasoning-способности можно формировать через RL с минимальным количеством начальных человеческих данных. Статья опубликована в Nature (vol. 645, 2025).

Proof-of-concept — **R1-Zero** — использовал *только* GRPO с rule-based наградами (correctness, format) на base model, без какого-либо SFT. Reasoning-паттерны — chain-of-thought, self-verification, «aha-момент» — возникли спонтанно, только через RL. Однако R1-Zero страдал от нестабильного форматирования и смешения языков.

Финальный **R1** добавил cold-start SFT для стабильности:

1. **Cold-start SFT** на небольшом наборе длинных CoT-примеров → модель получает стабильный формат рассуждений.
2. **GRPO** с rule-based наградами (correctness, format) → модель развивает reasoning-способности.
3. **Rejection sampling** лучших reasoning-траекторий + SFT для стабилизации.
4. **Финальный GRPO** с дополнительными reward-сигналами (helpfulness, safety).

Важнейший результат: R1-Zero показал, что reasoning-паттерны *могут* возникнуть без обучения на примерах рассуждений. Финальный R1 использовал этот инсайт, но добавил cold-start SFT, чтобы сделать результат production-ready.

### Reinforcement Fine-Tuning (RFT)

OpenAI предлагает **Reinforcement Fine-Tuning (RFT)** — коммерческий API-аналог GRPO-подобного подхода. RFT доступен для модели o4-mini (`o4-mini-2025-04-16`) и позволяет обучать модель через reward signal на domain-specific задачах.

Принцип: вы определяете grader (функцию оценки), модель генерирует рассуждения, grader оценивает результат, модель обучается. Это — тот же принцип, что и в GRPO, но упакованный в managed API.

Когда использовать RFT/GRPO вместо SFT/DPO:

- Задача имеет *проверяемый* ответ (математика, код, извлечение фактов).
- Вам нужен *reasoning*, а не просто формат.
- У вас нет пар предпочтений, но есть автоматическая метрика качества.

GRPO (open-weight) и RFT (hosted API) — два пути к одной цели: модель учится *рассуждать* через RL на rule-based наградах.

### Многостадийный RL для агентности

Для диалоговой helpfulness-задачи достаточно думать о post-training как о выравнивании ответов. Но для агентов этого мало. GLM-5 хорошо показывает новую логику: если целевая способность — длинные tool-use траектории, post-training должен отдельно обучать **рассуждение**, **действие** и **перенос между режимами**.

Практическая схема выглядит так: сначала reasoning-centric RL, затем agentic RL на длинных средах, затем более общий RL-этап для универсальности. Это важно, потому что single-stage обучение легко даёт перекос: модель может стать сильнее в коротком chain-of-thought, но хуже держать длинный loop с инструментами, или наоборот. Cross-stage distillation между этапами становится способом не потерять уже выученные навыки при переходе к следующему режиму.

Отсюда инженерное следствие: если вы fine-tune'ите модель под агента, не задавайте один общий reward «будь полезной». Разделяйте сигналы хотя бы на correctness, tool-use success, long-horizon completion и safety. Чем длиннее траектория, тем менее правдоподобно, что один scalar reward покроет всё нужное поведение. А инфраструктурно rollouts всё чаще генерируются асинхронно и отдельно от update-шага, иначе long-horizon среда простаивает дороже, чем сама оптимизация.

### Online iterative RLHF: следующий производственный шаг

SFT, DPO и даже GRPO часто описываются как **offline-этапы**: вы собрали датасет, обучили модель, выкатили новую версию. Но в живом продукте предпочтения пользователей дрейфуют: меняются задачи, UX-ожидания, acceptable tone, типовые ошибки. Поэтому современный post-training всё чаще выглядит как **итеративный online-loop**: новая версия модели → сбор preference signals из реального трафика → обновление proxy preference model или grader → следующий раунд обучения.

Это не отменяет offline-этапы; скорее, ставит их в более широкий цикл. Если у вас статичная узкая задача, offline DPO или RFT может быть достаточным. Если у вас живой продукт с постоянным потоком обратной связи, online iterative RLHF становится естественным продолжением post-training.

---

## 19.6. LoRA и QLoRA: parameter-efficient fine-tuning

### Проблема: стоимость полного fine-tuning

Полный fine-tuning модели с 70B параметрами требует десятков GPU уровня A100/H100 — только чтобы в память влезли градиенты и optimizer states. Для большинства инженерных команд это неподъёмно.

### LoRA: low-rank adaptation

Hu et al. (2021) заметили, что изменения весовых матриц при fine-tuning имеют *низкий ранг* — большая часть информации о дообучении «живёт» в пространстве малой размерности. Вместо того чтобы обновлять исходную матрицу целиком, LoRA замораживает базовые веса и добавляет к ним компактную обучаемую поправку из двух маленьких матриц. Типичный ранг такой поправки — от 4 до 64.

Для GPT-3 175B это сокращает число обучаемых параметров в 10 000 раз, потребление GPU-памяти — в 3 раза.

**Интуиция:** представьте, что вы корректируете траекторию огромного корабля. Полный fine-tuning — это перестройка всего корпуса. LoRA — это пара маленьких рулей: они сдвигают направление ровно на столько, сколько нужно, не трогая основную конструкцию.

При inference LoRA-адаптер *сливается* с базовыми весами как компактная добавка к исходной матрице, что не добавляет латенси. Можно хранить несколько LoRA-адаптеров и переключать их на лету — один для юридических задач, другой для медицинских, третий для кодогенерации.

### QLoRA: LoRA + квантизация

Dettmers et al. (2023) пошли дальше: если базовую модель квантизовать до 4 бит, а LoRA-адаптеры оставить в полной точности, можно fine-tune'ить 65B модель на *одном* GPU с 48GB памяти.

Три ключевые инновации QLoRA:

- **NF4 (4-bit NormalFloat):** тип данных, оптимизированный для нормально распределённых весов нейросетей — точнее, чем стандартный int4.
- **Double quantization:** квантизация констант квантизации (сохраняет 0.37 бита на параметр дополнительно).
- **Paged optimizers:** выгрузка optimizer states в RAM при GPU OOM, автоматический возврат при необходимости.

Результат: Guanaco (QLoRA fine-tune LLaMA 65B) достиг 99.3% качества ChatGPT на Vicuna benchmark, обучаясь на одном GPU.

### Практическое значение

LoRA/QLoRA — это *основной* способ, которым инженеры fine-tune'ят open-weight модели без кластера. Большинство fine-tuning API (Together AI, Fireworks, Modal) используют LoRA под капотом. Когда вы запускаете fine-tuning через SaaS — скорее всего, это LoRA.

**Промпт для генерации кода:**

> Сгенерируй конфигурацию LoRA-адаптера для causal LM на базе Hugging Face PEFT. Параметры: rank 16, alpha 32, target modules — q_proj и v_proj, dropout 0.05. Покажи инициализацию PEFT-модели из base model и вывод числа обучаемых параметров (процент от общего числа). Стек: transformers + peft. Результат — готовый к запуску скрипт.

---

## 19.7. Синтетические данные для fine-tuning

Главный барьер для fine-tuning — не compute, а *данные*. Сбор тысяч качественных пар (инструкция, ответ) вручную — месяцы работы. Три стратегии решают эту проблему, используя сильную модель для генерации обучающих данных.

### Self-Instruct: масштаб через автогенерацию

Wang et al. (2022) предложили цикл: модель генерирует инструкции → фильтрует дубликаты и некачественные → сама же генерирует ответы → из этого обучается новая версия. Alpaca — наиболее известное применение: 52K пар от text-davinci-003 менее чем за $500.

### Textbook quality: качество важнее количества

Gunasekar et al. (2023) показали, что 1.3B модель (Phi-1), обученная на *тщательно курированных* синтетических данных «учебного качества», достигает 50.6% на HumanEval — уровень моделей в 10× крупнее. Ключевой вывод: один идеальный пример стоит сотни посредственных.

### Explanation traces: perенос рассуждений

Mukherjee et al. (2023) в Orca обучали 13B модель не просто на ответах GPT-4, а на *explanation traces* — цепочках рассуждений с промежуточными шагами. Студент учится не только *что* отвечать, но *как* рассуждать. Это — transfer chain-of-thought, и он работает: Orca 13B превосходит ChatGPT на ряде бенчмарков.

### Сравнение стратегий

| Стратегия | Механизм | Пример | Ключевой инсайт |
|-----------|----------|--------|-----------------|
| **Self-Instruct** | LLM генерирует пары (инструкция, ответ); фильтрация и SFT | Alpaca: 52K пар, <$500 | Масштаб через автогенерацию |
| **Textbook quality** | Курированные высококачественные синтетические данные | Phi-1: 1.3B → 50.6% HumanEval | Качество > количество |
| **Explanation traces** | Студент учится на рассуждениях учителя, а не только на ответах | Orca: 13B, traces от GPT-4 | Перенос reasoning через chain-of-thought |

Все три стратегии — это формы **distillation**: сильная модель передаёт знания и навыки более слабой через свои выходы.

---

## 19.8. Distillation: от дорогой модели к дешёвой

### Концепция

Distillation — обучение маленькой модели-студента на выходах большой модели-учителя. Идея фундаментальна: Hinton et al. (2015) показали, что «мягкие» вероятности на выходе большой модели содержат больше сигнала, чем жёсткие метки. Учитель не просто говорит «это кошка» — он говорит «это на 90% кошка, на 8% рысь и на 2% собака», и эта информация о *структуре* пространства передаётся студенту.

Для LLM distillation выглядит прагматичнее: у вас есть работающий промпт на frontier-модели (Claude Opus 4.6, GPT-5.4), inference стоит дорого. Вы собираете пары (промпт, ответ frontier-модели), делаете SFT на меньшую модель — и получаете специализированного студента, который на *вашей* задаче работает сопоставимо, но стоит в 10–100× дешевле.

### Pipeline

```
1. Сформулировать задачу, промпт, eval-набор
2. Прогнать 1000–10000 запросов через frontier-модель
3. Отфильтровать некачественные ответы (автоматически + выборочно вручную)
4. SFT на собранных парах → модель-студент
5. Оценить студента на eval-наборе
6. Итерировать: добавить примеров на ошибки, перезапустить SFT
```

### Когда distillation работает

Distillation эффективна, когда задача *чётко определена* и формат выхода *консистентен*. Примеры: классификация писем, извлечение сущностей из договоров, генерация SQL по вопросу на естественном языке, суммаризация в фиксированном формате.

Distillation *плохо* работает для открытых задач (brainstorming, creative writing) и задач, где нужен полный спектр знаний frontier-модели — студент не может вместить всё.

OpenAI поддерживает distillation через API Model Optimization: stored completions от gpt-4.1 можно использовать как данные для fine-tuning gpt-4.1-mini и gpt-4.1-nano.

MiniLLM (Gu et al., 2024) показал, что специализированные методы distillation с минимизацией KL-дивергенции стабильнее наивного SFT — особенно когда студент значительно меньше учителя.

---

## 19.9. Дерево решений: промпт, RAG или fine-tuning?

Это — ключевая практическая секция. Большинство задач, для которых инженеры рефлекторно тянутся к fine-tuning, решаются проще. Таблица из [Главы 12, раздел 12.9](12_rag.md) давала высокоуровневый обзор; здесь — разбор с точки зрения дообучения.

### Таблица решений

| Проблема | Рекомендованный подход | Почему |
|----------|----------------------|--------|
| Модель не знает приватные / свежие данные | **RAG** | Добавляет знания без переобучения |
| Модель знает, но форматирует неправильно | **Prompt engineering** | Нулевая стоимость, мгновенно, обратимо |
| Модель следует инструкциям, но стиль/тон не тот — на масштабе | **SFT** | Встраивает поведение в веса |
| Нужно alignment: «лучше» vs «хуже» | **DPO** | Учится на парных предпочтениях |
| Есть только бинарный feedback (лайк / дизлайк, accept / reject) | **KTO** | Не требует pairwise preferences |
| Нужны paired preferences, но budget ограничен | **ORPO / SimPO** | Более лёгкие варианты preference optimization |
| Нужен domain-specific reasoning (проверяемые задачи) | **GRPO / RFT** (§19.5) | RL на rule-based наградах; не нужны пары предпочтений |
| Предпочтения меняются вместе с продуктом | **Online RLHF / iterative RFT** | Замыкает цикл на живой обратной связи |
| Frontier-модель работает, но слишком дорога | **Distillation** | То же качество, меньшая модель |

### Дерево решений

```
Проблема в знаниях? ─── ДА ──→ RAG
       │
      НЕТ
       │
Проблема в формате / следовании инструкциям? ─── ДА ──→ Prompt engineering
       │
      НЕТ
       │
Проблема в стиле/тоне/персоне — на масштабе? ─── ДА ──→ SFT
       │
      НЕТ
       │
Есть данные предпочтений (лучше / хуже)? ─── ДА ──→ DPO
       │
      НЕТ
       │
Есть автоматическая метрика качества? ─── ДА ──→ GRPO / RFT
       │
      НЕТ
       │
Frontier-модель слишком дорога? ─── ДА ──→ Distillation
       │
      НЕТ
       │
Вопрос: подходит ли задача для LLM вообще?
```

### Практическая расшифровка дерева решений

Если читать дерево решений как инженерный playbook, то после 2024–2025 оно уточняется так:
- **Есть pairwise preferences и нужен зрелый, понятный pipeline** → начинайте с DPO.
- **Есть только бинарный product-feedback** → KTO часто естественнее, чем насильственно собирать pairs.
- **Память и compute ограничены, но pairs уже есть** → рассмотрите ORPO или SimPO как более лёгкую альтернативу.
- **Качество можно проверять автоматически** (математика, unit tests, компилятор, exact match) → лучше смотреть в сторону GRPO / RFT.
- **Продукт живой и предпочтения плывут со временем** → планируйте iterative online-loop, а не один «магический» fine-tune.

### Анти-паттерны

**Fine-tuning вместо промпта.** Команда потратила неделю на сбор данных и обучение, чтобы модель выдавала JSON. Правильный ответ — `structured outputs` или пятистрочный промпт с примером. Потеряны неделя и GPU-часы.

**Fine-tuning на <100 примерах.** При таком объёме модель переобучается (запоминает примеры) или не учится ничему значимому. Минимум для SFT — сотни примеров, для DPO — сотни–тысячи пар предпочтений в зависимости от задачи.

**Fine-tuning без eval-набора.** Без метрики «до» и «после» вы не узнаете, помогло ли дообучение. Сначала eval set — потом fine-tuning. Не наоборот.

**Distillation без проверки учителя.** Если frontier-модель допускает ошибки на 15% запросов, студент унаследует эти ошибки — и усилит их. Фильтрация выходов учителя — обязательный этап.

---

## 19.10. Failure modes: что может пойти не так

Дообучение — не волшебная кнопка. Каждый метод имеет характерные режимы отказа, и о них нужно знать *до* запуска обучения.

### Reward hacking

Модель оптимизирует proxy (reward model), а не реальную цель. Закон Гудхарта в действии: «когда метрика становится целью, она перестаёт быть хорошей метрикой». Gao et al. (2022) формализовали scaling laws для reward overoptimization: после определённого порога дальнейшая оптимизация по RM *ухудшает* реальное качество.

**Митигация:** KL-штраф (уже встроен в RLHF и DPO), разнообразные reward signals, early stopping по held-out метрике.

### Catastrophic forgetting

Fine-tuning на узкой области деградирует общие способности модели. Вы обучили модель на юридических документах — она начала хуже писать код. Причина: градиентные обновления оптимизируют под новую задачу, «затирая» веса, отвечавшие за другие навыки.

**Митигация:** LoRA (минимальные изменения весов по конструкции), replay buffer (подмешивание general-domain данных при обучении), оценка на широком наборе задач до и после fine-tuning.

### Mode collapse

Модель начинает генерировать монотонные, однообразные ответы — теряет разнообразие. Характерно для агрессивного RLHF: модель находит «безопасный» паттерн высокой награды и повторяет его.

**Митигация:** разнообразие в training data, контроль температуры при sampling, мониторинг diversity-метрик (distinct-n, self-BLEU).

### Alignment tax

Alignment (safety-обучение) снижает производительность на бенчмарках. Модель отказывается отвечать на легитимные вопросы, перестаёт быть полезной. Это — осознанный компромисс, но его масштаб можно контролировать.

**Митигация:** Constitutional AI (Bai et al., 2022) — alignment через принципы, а не паранойю. Упомянут в [Главе 13, раздел 13.5](13_anti_hallucination_loop.md).

### Sycophancy

RLHF-модель соглашается с пользователем, даже когда пользователь неправ, — потому что «согласие» получает высокую оценку от reward model. Если пользователь говорит «2+2=5, правда?», модель отвечает «да, вы абсолютно правы». Механизм подробно разобран в [Главе 3, раздел 3.2](03_hallucinations.md).

**Митигация:** training на примерах корректного несогласия, Constitutional AI, self-critique.

### Сводная таблица

| Failure mode | Описание | Митигация |
|--------------|---------|-----------|
| **Reward hacking** | Оптимизация proxy, а не реальной цели (Гудхарт) | KL-штраф, diverse rewards, early stopping |
| **Catastrophic forgetting** | Узкий fine-tuning деградирует общие способности | LoRA, replay buffer, mixed-domain data |
| **Mode collapse** | Монотонные ответы, потеря разнообразия | Diverse training data, temperature control |
| **Alignment tax** | Safety-обучение снижает полезность | Constitutional AI, калиброванные guardrails |
| **Sycophancy** | Модель соглашается даже с неправым пользователем | Примеры несогласия, self-critique |

---

## Практический вывод

Дерево решений в виде чек-листа:

1. **Начинайте с prompt engineering** — это бесплатно, мгновенно и обратимо. Structured outputs, few-shot примеры, chain-of-thought решают большинство задач форматирования и рассуждения.

2. **Добавляйте RAG**, когда модели не хватает *знаний* — приватных данных, свежей информации, специфических документов.

3. **Рассматривайте fine-tuning только когда промпт и RAG не справляются.** Типичные показания: стиль/тон на масштабе (SFT), preference alignment (DPO), reasoning на проверяемых задачах (GRPO/RFT), distillation для снижения стоимости.

4. **Для open-weight моделей — LoRA/QLoRA.** Для hosted моделей — API fine-tuning (SFT/DPO). Полный fine-tuning — только если у вас есть ML-команда и кластер.

5. **Для снижения стоимости at scale — distillation.** Соберите пары (промпт, frontier-ответ), отфильтруйте ошибки, SFT на меньшую модель.

6. **Eval set — до fine-tuning.** Без baseline невозможно измерить улучшение. Сначала метрика — потом обучение.

7. **Мониторьте failure modes.** Reward hacking, catastrophic forgetting, sycophancy — это не экзотика, это типичные проблемы. Закладывайте мониторинг в pipeline.

8. **Помните: fine-tuning дорог и необратим. Промпт — дёшев и обратим.** Если вы не уверены — оставайтесь на inference-time стратегиях.

> **Промпт для ИИ:** «Напиши Python-скрипт для сравнения fine-tune vs RAG vs prompt-only на одном eval-наборе. Скрипт принимает JSONL-файл с тест-кейсами (input, expected_output) и для каждого подхода измеряет: accuracy, latency, cost_per_query. Для fine-tune: вызывает модель (предполагается, что LoRA-адаптер уже задеплоен). Для RAG: embedding retrieval + генерация. Для prompt-only: прямой вызов frontier-модели. Вывод — сводная таблица и рекомендация. Добавь type hints и docstrings.»

> **Промпт для ИИ:** «Напиши Python-скрипт для LoRA-дообучения на кастомных данных (HuggingFace PEFT + transformers). Скрипт: принимает JSONL-файл с парами (instruction, response), модель (например, Llama 4 Scout), параметры LoRA (r=16, alpha=32, target_modules). Выполняет SFT с оценкой loss на validation split. После обучения: замеряет качество на hold-out тестовом наборе (exact match, BLEU, LLM-judge score), сравнивает с базовой моделью. Сохраняет адаптер. Покажи полный пайплайн: загрузка → обучение → оценка → сохранение. Предупреди о GPU-требованиях в комментарии.»

### Decision tree: fine-tune, RAG или промпт?

Выбор между тремя стратегиями адаптации модели к доменным задачам зависит от четырёх параметров: объём данных, стабильность задачи, требования к стилю/тону, latency-бюджет.

Пройдите по дереву решений:

1. **Задача требует фактической актуальности?** (примеры: цены, курсы валют, наличие товаров, статусы заказов)
   - Да → данные меняются быстрее, чем цикл переобучения → **RAG**.
   - Нет → переходите к шагу 2.

2. **У вас есть размеченный датасет из 500+ примеров?**
   - Нет → **Промпт-инжиниринг.** Пишите хороший промпт с примерами, используйте few-shot. Переходите к fine-tune только когда исчерпали промпт и накопили данные.
   - Да → переходите к шагу 3.

3. **Задача требует специфического стиля, тона или формата?** (примеры: ответы в стиле бренда, специфическая терминология домена, особый формат вывода)
   - Да → **Fine-tune (SFT)**. Few-shot в промпте даёт ~60-80% желаемого стиля; fine-tune — 90%+.
   - Нет, задача решается хорошим промптом → переходите к шагу 4.

4. **Latency критична? Запросы высокочастотные?**
   - Да (чат, автокомплит, real-time) → **Fine-tune + distillation** на маленькую модель. RAG добавляет retrieval overhead (100-300ms).
   - Нет (батчевая обработка, nightly jobs) → **RAG** или **prompt-only** на frontier-модели.

### Сравнительная таблица

| Критерий | Prompt-only | RAG | Fine-tune (SFT/LoRA) |
|----------|------------|-----|----------------------|
| Время до результата | Минуты (написать промпт) | Дни (настроить retrieval) | Дни-недели (собрать данные + обучить) |
| Стоимость внедрения | $0 (только время инженера) | $100-1000 (vector DB, embedding) | $100-5000 (GPU-часы + разметка) |
| Поддержка актуальности | Зависит от модели (knowledge cutoff) | Всегда актуально (индекс обновляется) | Устаревает (нужен re-train) |
| Контроль стиля/тона | Ограниченный (через промпт) | Ограниченный (через промпт) | Высокий |
| Качество на узких доменах | Среднее (зависит от few-shot) | Высокое (если хороший retrieval) | Высокое (если хорошие данные) |
| Latency overhead | 0 | +100-300ms (retrieval) | 0 (дешевле модели часто быстрее) |

### Антипаттерн: Fine-tune для фактов

Fine-tune вносит знания в веса модели. Но факты устаревают, а модель не умеет их «забывать» выборочно. Если вы делаете fine-tune на данных с ценами, курсами валют или списком сотрудников, модель будет помнить их на момент обучения и молча устаревать. Для фактов — RAG. Fine-tune — для поведения (стиль, тон, формат, следование инструкциям).

### Пример расчёта

**Задача:** Классификация обращений в техподдержку по 15 категориям.

- **Prompt-only:** GPT-5.4-mini, промпт с описанием категорий и 3 few-shot примерами. Accuracy: 78%. Стоимость: $0.03/запрос.
- **Fine-tune:** LoRA на GPT-5.4-mini, 2000 размеченных примеров, 2 часа GPU. Accuracy: 92%. Стоимость: $0.003/запрос + $100 GPU.
- **Решение:** При 10 000 запросов/день fine-tune окупается за 2 дня на разнице в стоимости запросов. При 100 запросах/день — не окупается, лучше prompt-only.

> **Промпт для ИИ:** «Напиши Python-скрипт для расчёта ROI fine-tune vs prompt-only. Принимает: requests_per_day, prompt_tokens_per_request, model_price_per_1M, fine_tune_cost, fine_tune_model_price_per_1M, accuracy_prompt, accuracy_finetune, cost_per_error. Считает годовую стоимость каждого подхода с учётом стоимости ошибок. Вычисляет break-even point (дней до окупаемости fine-tune). Вывод — таблица и рекомендация.»

### Задания

1. **Соберите пилотный dataset для SFT.** Выберите production-задачу, где промпт не справляется (тон, формат, протокол). Соберите 200 пар (инструкция, идеальный ответ) — 100 напишите вручную, 100 сгенерируйте frontier-моделью и отфильтруйте. Результат: JSON-файл в формате OpenAI fine-tuning API, готовый к загрузке.

2. **Проведите A/B-сравнение промпта и SFT.** Возьмите задачу, которую frontier-модель решает через длинный промпт с few-shot примерами. Сделайте SFT на mini-модели (gpt-4.1-mini или open-weight 7–8B через LoRA). Сравните по eval-набору: качество, latency, стоимость на 10K запросов. Ожидаемый результат: таблица trade-off «качество vs стоимость» с обоснованием выбора.

3. **Постройте distillation pipeline.** Выберите узкую задачу (классификация, извлечение сущностей, генерация SQL). Соберите 1000+ пар от frontier-модели с цепочками рассуждений (explanation traces). Отфильтруйте ошибочные ответы (автоматически + выборочная проверка). SFT на меньшую модель. Измерьте: accuracy студента vs учителя, стоимость inference студента vs учителя. Ожидаемый результат: студент на 80%+ качества учителя при 10× снижении стоимости.

4. **Примите решение fine-tune vs RAG для вашей задачи.** Возьмите реальную задачу из проекта. Пройдите decision tree выше. Если вывод — fine-tune: оцените, есть ли у вас 500+ размеченных примеров, рассчитайте стоимость. Если вывод — RAG: оцените, как часто обновляются данные. Задокументируйте решение с обоснованием. **Ожидаемый результат:** документ с анализом и принятым решением.

---

## Источники

- Ouyang, L., et al. (2022). "Training language models to follow instructions with human feedback." arXiv:2203.02155
- Rafailov, R., et al. (2023). "Direct Preference Optimization: Your Language Model is Secretly a Reward Model." arXiv:2305.18290
- Hong, J., et al. (2024). "ORPO: Monolithic Preference Optimization without Reference Model." arXiv:2403.07691.
- Ethayarajh, K., et al. (2024). "KTO: Model Alignment as Prospect Theoretic Optimization." arXiv:2402.01306.
- Meng, Y., et al. (2024). "SimPO: Simple Preference Optimization with a Reference-Free Reward." arXiv:2405.14734.
- Dong, H., et al. (2024). "RLHF Workflow: From Reward Modeling to Online RLHF." arXiv:2405.07863.
- Hu, E., et al. (2021). "LoRA: Low-Rank Adaptation of Large Language Models." arXiv:2106.09685
- Dettmers, T., et al. (2023). "QLoRA: Efficient Finetuning of Quantized LLMs." arXiv:2305.14314
- Wei, J., et al. (2021). "Finetuned Language Models Are Zero-Shot Learners." arXiv:2109.01652
- Wang, Y., et al. (2022). "Self-Instruct: Aligning Language Models with Self-Generated Instructions." arXiv:2212.10560
- Gunasekar, S., et al. (2023). "Textbooks Are All You Need." arXiv:2306.11644
- Mukherjee, S., et al. (2023). "Orca: Progressive Learning from Complex Explanation Traces of GPT-4." arXiv:2306.02707
- Hinton, G., Vinyals, O., Dean, J. (2015). "Distilling the Knowledge in a Neural Network." arXiv:1503.02531
- Gu, Y., et al. (2024). "MiniLLM: Knowledge Distillation of Large Language Models." arXiv:2306.08543
- Gao, L., et al. (2022). "Scaling Laws for Reward Model Overoptimization." arXiv:2210.10760
- Bai, Y., et al. (2022). "Constitutional AI: Harmlessness from AI Feedback." arXiv:2212.08073
- Shao, Z., et al. (2024). "DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models." arXiv:2402.03300
- Guo, D., et al. (2025). "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning." Nature, vol. 645; arXiv:2501.12948
- Du, Z., et al. (2026). "GLM-5: from Vibe Coding to Agentic Engineering." arXiv:2602.15763
- OpenAI. "Model Optimization." https://developers.openai.com/api/docs/guides/model-optimization
- OpenAI. "Reinforcement Fine-Tuning." https://developers.openai.com/api/docs/guides/reinforcement-fine-tuning

---

**Навигация:**
- Назад: [Глава 18. Мультимодальные системы](18_multimodal_systems.md)
- Далее: [Глава 20. Паттерны проектирования LLM-приложений](20_llm_application_design_patterns.md)
