Fine-tuning (дообучение LLM): когда нужен, как спланировать и запустить

Когда действительно нужен fine-tuning (дообучение LLM)

Дообучение — не «серебряная пуля». Во многих кейсах достаточно промптинга и/или RAG. Быстрые ориентиры:

Коротко: факты — в RAG, поведение — в fine-tuning.

Виды дообучения (карта подходов)

1) DAPT/TAPT (continued pretraining). Продолжение предобучения на доменных/корпоративных текстах без разметки. Цель — «впитать» лексику и статистику языка. Полезно перед SFT, если у вас большой корпус (от миллионов токенов).

2) SFT (Supervised Fine-Tuning). Дообучение на парах «инструкция → желательный ответ». Это база для: стиля, структуры, соответствия формату, использования инструментов (через размеченные примеры).

3) Preference/Alignment-тюнинг. Калибровка «что такое хороший ответ» — через пары «A лучше B». Исторически: RLHF; в последнее время популярны DPO/IPO/ORPO/KTO (обучение по предпочтениям без сложного RL). Применяется после SFT.

4) PEFT (Parameter-Efficient Fine-Tuning). Дообучение не всей модели, а малых адаптеров: LoRA/QLoRA/IA³/Adapters. Это резко снижает VRAM/стоимость, упрощает версионирование и даёт модульность (одна база — много адаптеров по задачам). См. LoRA.

5) Мультимодальный FT. Если продукт требует изображений/аудио/таблиц, дообучают соответствующие «головы» и коннекторы; методология похожа: SFT + предпочтения + PEFT.

Как спланировать проект дообучения

Шаг 1. Скоп приоритета. Определите 2–3 конкретных юзкейса (не всё сразу): «ответы по базе знаний», «формальные письма», «инструментальные расчёты».

Шаг 2. Golden-набор и метрики. Соберите golden-сет из реальных запросов/ответов (обезличенных) и решите, чем мерить успех: EM/F1, pass@k, pairwise-win-rate, faithfulness при RAG (см. evals).

Шаг 3. Выбор модели и бюджета. 7B/13B подойдут для большинства ru/en-ассистентов; 34B/70B — если важны сложные рассуждения. При ограниченном железе — QLoRA.

Шаг 4. Данные. Размеченные пары для SFT (минимум 10–20k), корпус для DAPT (по возможности), и пары предпочтений для alignment.

Шаг 5. Безопасность/политики. Определите «красные зоны» (PII, юриспруденция, медицина, джейлбрейки). Политики реализуются и данными, и guardrails.

Шаг 6. План деплоя. Где и как жить адаптерам: онлайн-подмешивание ΔW, merge-in-place, версияция, rollback, A/B-эксперименты.

Подготовка данных: качество важнее объёма

Источники. Логи чатов, базовые документы, мануалы, код-репозитории, корпоративные шаблоны, публичные доменные тексты (с лицензиями).

Очистка и нормализация.

• удаление дубликатов и «копипастных ковров»;
• вынос PII/секретов (маскирование, синтетические значения);
• нормализация формата (заголовки, списки, таблицы → единая разметка);
• баланс языков (ru/en) и тематик, чтобы не «перекосить» стиль.

Разметка SFT. Шаблонная схема: instruction, input (если нужно), output (канонический ответ) + обязательные критерии (цитировать источник? давать ссылки? формат JSON?). Для инструментов — примеры вызовов с корректной схемой I/O.

Пары предпочтений (alignment). Берите реальные альтернативы («вариант A корректнее B»), не забывая про «ничья/оба плохи». Для DPO/IPO важно 5–30k пар — уже видно улучшение.

Сплиты. train/dev/test без протечки: одинаковые вопросы/документы не должны попадать в train и test одновременно.

Конфигурации обучения (практика)

Бюджеты VRAM (ориентиры).

• 7B + QLoRA (r=8–16) — 1×24–48 ГБ GPU.
• 13B + QLoRA — 2×24–48 ГБ или облако.
• 34B/70B — только кластер/облако; чаще PEFT.

Гиперпараметры SFT (стартовые).

• lr 1e-4…3e-4 для адаптеров; AdamW; cosine/linear decay;
• seq len по задаче; grad-accumulation для крупного batch;
• 1–3 эпохи (смотрите на переобучение и метрики dev);
• lora_dropout 0,05–0,2, rank r=16…32 (для 7B/13B).

Alignment (DPO/IPO).

• lr меньше, чем в SFT (1e-5…5e-5), 1–2 эпохи;
• важно не разрушить навыки SFT — контролируйте метрики и «красные линии» (toxicity, jailbreak-rate).

DAPT/TAPT.

• unlabeled-корпус; небольшой lr; длиннее шаги; мониторьте перплексию на доменных вал-наборах.

RAG + fine-tuning: дружим, не конкурируем

RAG решает извлечение фактов, fine-tuning — поведение и формат. Схема:

• RAG готовит короткий, чистый контекст (без воды/дубликатов);
• SFT обучает «подчиняться» контексту: цитировать источники, различать answerable/unanswerable;
• evals включают faithfulness (ответ только на базе контекста) и citation-precision.

Метрики и evals (что мерить)

• Факты/QA — EM/F1; при RAG — ещё faithfulness и цитаты (см. evals).
• Открытая генерация — LLM-as-a-Judge (pairwise win-rate).
• Код — pass@k на закрытом тест-наборе.
• Длинный контекст — устойчивость к «иголкам» и «lost-in-the-middle» (см. контекстное окно).
• Безопасность — jailbreak-проходимость, токс-скоры, ложные блоки (см. guardrails).

В проде добавляйте онлайн-сигналы: отказ-rate, жалобы, «не нашёл/непонятно», latency/cost.

Безопасность и комплаенс

Данные. Лицензии, права, PII. Маскируйте/анонимизируйте; храните «карты происхождения» примеров.

Политики. Определите «нельзя/можно/с предупреждением». Часть вшивается в SFT и alignment-данные, часть — в guardrails.

Регрессии. После каждой итерации дообучения — PR-evals на маленьком наборе (50–200 задач) + «глубокий слой» еженедельно.

Частые ошибки и как их избежать

• «Залили всё подряд». Плохие/дубликатные данные «учат» модель мусору. Делайте дедуп/нормализацию.
• Смешение задач в один датасет. Разделяйте стилевые/форматные и фактологические примеры.
• Нет тестов на безопасность. Любой прирост «умности» может повышать jailbreak-уязвимость.
• Гигантские промпты в SFT. Учите краткости и структуре — длинные подсказки плохо обобщаются.
• Отсутствие versioning. Храните версии адаптеров и наборов (v1, v2…) и логи гиперпараметров.
• Оценка «на глаз». Введите формальные метрики и слепые pairwise-сравнения.

Практические рецепты (шаблоны)

Рецепт A: «Официозный деловой стиль RU/EN».

1. Сбор 15k пар SFT из корпоративных шаблонов и писем (обезличено).
2. QLoRA r=16 на 7B, 2 эпохи; затем DPO на 10k пар предпочтений.
3. Evals: pairwise-win-rate, длина, формальность, отсутствие PII.
4. Деплой: адаптер онлайн, версия v1.0; A/B-тест с контрольной моделью.

Рецепт B: «Ассистент по базе статей с цитатами».

1. Индекс для RAG (чистые чанки, citation-friendly).
2. SFT на 10k парах «вопрос → ответ с цитатами».
3. DPO по критериям faithfulness/полнота.
4. Evals: EM/F1 + citation-precision; онлайн: answerable-rate, latency.

Рецепт C: «Кодовый помощник (pass@k)».

1. Датасет из внутренних репозиториев + открытых задач с тестами.
2. SFT на 50–100k примеров; QLoRA r=32; max-seq для кода выше.
3. Evals: pass@1/5/10, время компиляции; защита от утечек ключей/секретов.

Инфраструктура и деплой

Артефакты. Храните: базовую модель (sha/версия), адаптеры (LoRA-веса), конфиги HP, датасеты (id/дата), логи обучения.

Стратегии подключения адаптеров.

• Online merge (runtime). Гибко переключать адаптеры под юзкейс/язык.
• Merge-in-place. Удобно для продов без «онлайн-LoRA», но теряете гибкость.

Версияция и выпуск. Именуйте по принципу base-X.Y + sft-A + dpo-B (пример: 7B-bf16 + sft-v3 + dpo-v2). Все релизы проходят PR-evals и «глубокий слой».

Мониторинг. Latency, cost, доля ретраев инструментов, доля «answerable», доля пустых/слишком длинных ответов, безопасность.

Мини-глоссарий

• DAPT/TAPT — продолжение предобучения на доменном/таск-корпусе.
• SFT — супервизорное дообучение на размеченных парах.
• RLHF / DPO / IPO / ORPO / KTO — методы preference-обучения.
• PEFT — параметро-эффективное дообучение (LoRA/QLoRA/IA³/Adapters).
• Faithfulness — соответствие ответа контексту/источнику в RAG.
• pass@k — шанс, что хотя бы один из k образцов кода проходит тесты.

См. также

• RAG: как подбирать контекст вместо «лить всё»
• LoRA (Low-Rank Adaptation)
• Evals (метрики и бенчмарки)
• Контекстное окно
• Guardrails