Как файн-тюнить модель: с чего начать

Короткий ответ

Начинать fine-tuning нужно не с запуска обучения, а с проверки, что он действительно нужен. Если задача в том, чтобы модель стабильнее соблюдала формат ответа, тон, стиль, схему извлечения полей, правила классификации или доменные формулировки, файн-тюн обычно уместен. Если модели не хватает актуальных фактов, длинного контекста, доступа к вашей базе знаний или внешним инструментам, чаще лучше сработают RAG, поиск, правила, постобработка или улучшение промпта. Метод плохо подходит, когда у вас мало чистых примеров, нет закрытого test-набора, требования к ответу меняются каждую неделю или вы не можете назвать метрику, по которой модель должна стать лучше.

Практически это выглядит так: сначала снимите baseline без обучения, затем соберите небольшой, но качественный набор примеров, разделите его на train, validation и test, начните с дешевого и обратимого способа обучения вроде PEFT/LoRA или fine-tuning через API, и сравнивайте результат только на заранее отложенных данных. Первый успешный пилот почти всегда узкий: одна задача, один формат выхода, одна метрика, один набор контрольных кейсов.

Что понадобится

• Четкая постановка задачи. Нужно зафиксировать, какой вход получает модель, какой выход считается правильным и что именно вы хотите улучшить: точность классификации, полноту извлечения, соблюдение JSON-схемы, стиль ответа или снижение доли ручных правок.
• Качественные примеры. Лучше брать реальные продовые запросы и хорошие эталоны ответов, а не «красивые» демонстрации, собранные в отрыве от эксплуатации. Для первой итерации важнее чистота и репрезентативность, чем большой объем.
• Разделение данных. Нужны отдельные наборы train, validation и test без пересечений по документам, шаблонам, пользователям или почти идентичным примерам.
• Базовая модель и допустимая лицензия. Сразу проверьте, можно ли ее дообучать в вашем сценарии и где вы будете запускать обучение.
• Инструменты для обучения и логирования. Для open-weight моделей обычно используют Transformers, PEFT и при необходимости TRL. Для учета экспериментов удобно подключить Weights & Biases. Если вы работаете через API-провайдера, ориентируйтесь на официальное руководство, например OpenAI fine-tuning.
• Проверка данных на риски. До обучения убедитесь, что в примерах нет запрещенных к передаче персональных данных, коммерческих секретов без нужного контура защиты и конфликтов в разметке.

Как выбрать подход

Выбор зависит от трех критериев: где находится «знание» задачи, насколько сильно нужно менять поведение модели и сколько у вас контроля над инфраструктурой. Если вам нужно научить модель лучше отвечать в заданном формате, обычно хватит PEFT/LoRA или API fine-tuning. Если проблема в фактах и документах, файн-тюн не заменит поиск по базе знаний.

Сценарий	Подход	Когда подходит	Когда не подходит
Нужно стабилизировать формат, стиль или классификацию	PEFT/LoRA	Быстрый пилот, ограниченные ресурсы, нужен обратимый эксперимент	Если требуется глубокая перестройка поведения большой open-weight модели
Модель доступна только через API	Fine-tuning через API	Когда провайдер поддерживает ваш тип задачи и формат данных	Если нужен полный контроль над обучением, логами и весами
Есть open-weight модель и своя инфраструктура	Полный fine-tuning	Когда пилот показал потолок PEFT и вы готовы платить за сложность	Для первой итерации, при дефиците данных и без надежной оценки
Не хватает знаний из внутренних документов	RAG вместо fine-tuning	Когда нужно подтягивать актуальные факты и ссылки на источники	Если задача не в знаниях, а в устойчивом формате и стиле ответа

Пошаговый план

1. Зафиксируйте задачу и критерий успеха

Сформулируйте задачу в виде контракта: что приходит на вход, что должно быть на выходе и как вы измеряете качество. Для классификации это может быть precision, recall или F1; для извлечения полей — exact match или доля корректно заполненных полей; для генерации — сочетание автоматической проверки формата и ручной оценки по рубрике. Если метрика не определена, обучение лучше не начинать: вы не поймете, стало лучше или просто «по-другому».

2. Снимите baseline без обучения

Перед файн-тюном проверьте, что задачу нельзя закрыть дешевле: улучшенным системным промптом, few-shot примерами, жесткой схемой ответа, валидатором JSON, RAG или внешним инструментом. Сохраните результаты baseline на одном и том же наборе кейсов. Это важный контроль: без него вы не узнаете, действительно ли выигрываете от обучения, или просто компенсируете слабый промпт.

Если baseline уже покрывает большую часть сценариев, fine-tuning может быть избыточным. В таком случае имеет смысл сначала сузить задачу до тех случаев, где провал стабилен и повторяется.

3. Соберите датасет из реальных сценариев

Для первого цикла лучше меньше, но чище. Выбирайте примеры из реальных пользовательских запросов, тикетов, переписок, документов или уже существующих размеченных задач. Важно, чтобы эталонный ответ отражал именно то поведение, которое вы хотите получить в проде. Если вы делаете модель для извлечения полей, не добавляйте в датасет длинные объяснения; если обучаете форматированному ответу, включайте именно целевой формат.

Уберите дубликаты, противоречивые метки и почти одинаковые шаблоны. Если один и тот же шаблон размножен сотни раз, модель выучит шаблон, а не задачу. Если используете синтетику, добавляйте ее как усиление покрытия, а не как замену реальным данным, и проверяйте вручную хотя бы выборку на ошибки и неестественные формулировки.

4. Разделите данные без утечек

Разбиение на train, validation и test должно отражать будущую эксплуатацию. Главная ошибка — случайно раскидать похожие примеры по всем частям и получить завышенную оценку. Если данные связаны документом, клиентом, источником или шаблоном, разделяйте именно по этим сущностям. Отдельно соберите небольшой набор «трудных» кейсов: редкие форматы, шумный ввод, конфликты в инструкции, длинные тексты, неоднозначные запросы.

5. Выберите минимально достаточный способ обучения

Для первого старта разумно предпочесть PEFT/LoRA или fine-tuning через API. Эти варианты быстрее запускать, проще откатывать и легче сравнивать. Полный fine-tuning имеет смысл, когда вы работаете с open-weight моделью, у вас есть опыт эксплуатации обучения и пилот уже показал, что легкого способа недостаточно.

Не пытайтесь на первом проходе одновременно решать все задачи: стиль, факты, безопасность, tool use и классификацию. Узкий fine-tune проще оценить и проще отлаживать. Также заранее определите формат обучающего примера: для chat-модели он должен совпадать с тем, как вы будете обращаться к модели в проде.

6. Запустите пилот, а не «большое обучение»

Первая цель — проверить конвейер, а не выжать максимум качества. Возьмите ограниченный набор данных, консервативные параметры обучения и короткий прогон. Вам нужно увидеть, что loss снижается, формат примеров корректный, токенизация не ломает данные, а модель действительно начинает воспроизводить нужный тип ответа.

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

7. Оцените результат на закрытом test-наборе

Сравнивайте только два состояния: baseline и fine-tuned модель. Оценка должна включать и автоматические метрики, и ручной просмотр примеров. Для генеративных задач удобно использовать рубрику: корректность фактов, соблюдение формата, полнота ответа, отсутствие лишнего текста, безопасность. Для извлечения и классификации обязательно разбирайте ошибки по классам и срезам, а не только среднее значение метрики.

Если модель выиграла в одной метрике, но стала хуже на критичном срезе, это неуспешный релиз. Например, она может лучше соблюдать формат, но чаще путать редкие категории; или отвечать короче, но терять обязательные поля.

8. Зафиксируйте артефакты и подготовьте эксплуатацию

Сохраните версию датасета, промпт-шаблон, гиперпараметры, commit кода и итоговую оценку. Без этого вы не воспроизведете результат через месяц. Перед выкладкой в прод соберите регрессионный набор из обязательных кейсов и прогоняйте его при каждом обновлении модели. Если предметная область меняется за счет новых фактов, запланируйте не только retraining, но и обновление базы знаний: это разные контуры.

Типичные ошибки

• Тюнить без baseline. Тогда невозможно доказать, что обучение дало выигрыш, а не замаскировало слабый промпт.
• Учить на «витринных» примерах. Модель получается красивой в демо и слабой в реальном потоке, потому что продовый шум не был представлен в данных.
• Смешивать несколько задач в первом цикле. Одновременно учить формат, классификацию и длинные объяснения почти всегда означает получить трудно диагностируемые ошибки.
• Допускать утечки между train и test. Повторяющиеся шаблоны, документы и почти дубликаты дают ложное ощущение качества.
• Игнорировать качество меток. Несогласованная разметка портит обучение сильнее, чем небольшой объем данных.
• Лечить нехватку знаний файн-тюном. Если модели нужны свежие факты, ссылки и документы, сначала смотрите в сторону RAG.
• Не проверять побочные эффекты. Fine-tuned модель может лучше решать целевую задачу, но хуже справляться с безопасностью, отказами или общими инструкциями.

Как проверить результат

1. Сравните с baseline на закрытом test-наборе. Никаких ручных «лучше на глаз» и никаких сравнений на обучающих примерах.
2. Проведите слепой ручной просмотр. Покажите экспертам ответы двух моделей без указания, где какая, и попросите оценить по простой рубрике.
3. Проверьте сложные срезы отдельно. Редкие категории, длинные входы, конфликтующие инструкции, шумные документы и пограничные случаи должны оцениваться отдельными списками.
4. Измерьте не только качество, но и пригодность. Учитывайте соблюдение формата, долю валидных JSON, объем постобработки, задержку, стабильность результатов при повторных запросах и стоимость эксплуатации.
5. Соберите регрессионный пакет. В него входят примеры, на которых ошибка недопустима: юридические формулировки, обязательные поля, чувствительные категории, опасные инструкции.
6. Следите за дрейфом после релиза. Если входные данные меняются, качество fine-tuned модели может быстро снижаться, даже если офлайн-оценка была хорошей.

Хороший признак зрелого результата — когда вы можете объяснить, на каких классах задач модель стала лучше, на каких не изменилась и где все еще нужен другой механизм, например поиск по знаниям или правила валидации.

FAQ

Сколько данных нужно для первого старта?

Строгого числа нет. Для узкой задачи с четким форматом небольшой, но чистый набор может быть полезнее большого шумного. На первом этапе важнее покрыть типовые и трудные сценарии, чем гнаться за объемом.

Что выбрать первым: LoRA или полный fine-tuning?

Для пилота обычно лучше LoRA или другой PEFT-подход. Он дешевле, быстрее и проще в откате. Полный fine-tuning имеет смысл позже, когда вы уже доказали полезность метода и понимаете, что именно нужно улучшить.

Можно ли файн-тюнить модель, чтобы она знала новые факты о компании?

Иногда да, но это плохой базовый способ хранения знаний. Для меняющихся фактов, внутренних документов и ссылок надежнее RAG или другой контур поиска. Fine-tuning лучше учит поведению, чем поддерживает постоянно актуальную базу знаний.

Можно ли использовать синтетические данные?

Да, но осторожно. Синтетика полезна для расширения покрытия, балансировки классов и генерации редких форматов. Нельзя слепо заменять ею реальные примеры: ошибки синтетики быстро закрепляются в модели. Минимум — ручная проверка выборки и обязательное смешивание с реальными данными.

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

Обычно это видно по расхождению между train и validation, по деградации на редких или шумных примерах и по слишком шаблонным ответам. Если модель блестяще воспроизводит знакомые паттерны, но сыплется на чуть измененных формулировках, это тревожный сигнал.

Нужен ли RLHF на старте?

Нет, в большинстве прикладных сценариев стартуют с supervised fine-tuning на качественных примерах. RLHF и близкие техники имеют смысл позже, когда базовое целевое поведение уже стабильно и вы понимаете, что именно хотите дополнительно выровнять.