busya/BlackboxBook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d67af9836341e5250591cbdf4095d7a3958fd8c6
BlackboxBook/book/19_fine_tuning_and_post_training.md
busya d67af98363 init
2026-05-20 20:55:03 +03:00

60 KiB
Raw Blame History

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

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

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

Книга последовательно строила аргумент: главы 6–9 — prompt engineering, глава 12 — RAG, глава 13 — антигаллюцинационный контур. Всё это — inference-time стратегии: вы не меняете модель, вы меняете то, что ей подаёте. Fine-tuning — следующий уровень: вы меняете саму модель. Это мощнее, но дороже и рискованнее.

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

Модель, которую вы вызываете через API, прошла многоэтапный конвейер. Pre-training (главы 1–5) создаёт возможности — модель умеет следовать инструкциям, анализировать код, писать текст. 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). Разница — в данных: вместо сырого веб-текста — курированные пары «вход → выход». Модель учится не продолжать произвольный текст, а отвечать на вопрос в определённом формате.

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

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 давала высокоуровневый обзор; здесь — разбор с точки зрения дообучения.

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

Проблема Рекомендованный подход Почему
Модель не знает приватные / свежие данные 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.

Sycophancy

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

Митигация: 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

Навигация: