Антипаттерн: дообучать модель там, где хватило бы промпта

MAATRIX

Модель отвечает не так, как нужно бизнесу: путает формат, не держит стиль, не понимает специфику вашего продукта — и первая мысль команды звучит как «надо дообучить модель на наших данных». Звучит solidно и по-инженерному, но в большинстве случаев это решение проблемы, которую ещё даже толком не пытались решить дешевле. Разберём, почему fine-tuning — это не первый шаг, а предпоследний, и какую цену вы платите, выбирая его раньше времени.

Как это выглядит на практике

Типичный сценарий: продуктовая команда подключила LLM для классификации обращений в поддержку или для генерации ответов в определённом формате. Модель на голом запросе вроде «классифицируй тикет» выдаёт что-то похожее на правду, но нестабильно — иногда путает категории, иногда добавляет лишний текст вместо чистой метки, иногда игнорирует часть инструкции. Команда делает вывод: «модель не понимает нашу задачу, значит, надо её дообучить», — и следующие недели уходят на сбор размеченного датасета, поиск GPU-сервера под обучение, эксперименты с LoRA-адаптерами и валидацию результата.

Проблема вскрывается на втором цикле: заказчик меняет одну категорию в классификации или просит немного другой формат ответа — и весь цикл «датасет → обучение → валидация» приходится повторять заново. При этом ни разу за всё это время никто не попробовал банально переписать системный промпт, дать модели пять-десять примеров нужного формата и посмотреть, не решится ли задача за десять минут вместо двух недель.

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

Почему тянутся сразу к дообучению

Здесь работает несколько понятных, но ошибочных мотивов.

Иллюзия контроля. Кажется, что если «зашить» поведение прямо в веса модели, оно станет надёжнее, чем если оно живёт в тексте промпта, который теоретически можно случайно стереть или проигнорировать. На практике устойчивость хорошо составленного системного промпта с чёткими инструкциями и примерами часто ничем не уступает поведению дообученной модели — а откатить его в случае ошибки можно за секунду правкой текста, а не повторным обучением.

Путаница между «модель не знает» и «модель не понимает, что от неё хотят». Если модель отвечает мимо цели, первый вопрос должен быть: ей не хватает информации (тогда нужен RAG) или она просто не поняла формулировку задачи (тогда нужен промпт получше)? Дообучение здесь применяют как универсальный молоток, не разобравшись, какая из проблем на самом деле мешает.

Одна неудачная попытка с промптом воспринимается как исчерпывающий тест. Команда пишет одну версию инструкции, видит нестабильный результат и делает вывод «промптингом это не лечится» — хотя даже не попробовала few-shot примеры, разбиение задачи на шаги или структурированный вывод. Базовые приёмы промпт-инжиниринга разобраны в статье «Промпт-инжиниринг для своих моделей: базовые приёмы» — стоит пройтись по ней перед тем, как признавать промптинг недостаточным.

Технический азарт. Развернуть LoRA-обучение на своём сервере — интересная инженерная задача сама по себе, и иногда за ней прячется желание заняться чем-то более «продвинутым», чем итеративная правка текста. Это понятный мотив, но он не имеет отношения к тому, какое решение на самом деле дешевле и надёжнее для конкретной задачи.

Что на самом деле дорого в fine-tuning

Дообучение не бесплатно ни на одном из этапов, и это стоит явно проговорить до того, как решение принято.

• Подготовка датасета. Нужны десятки, чаще сотни или тысячи качественных примеров «вход — правильный выход», покрывающих реальное разнообразие задач, включая пограничные случаи. Собрать и разметить их вручную — это отдельный проект: кто-то должен написать примеры, кто-то — проверить их корректность, кто-то — найти и исправить систематические ошибки в разметке. Дешёвый и грязный датасет даёт дообученную модель, которая выучивает шум вместе с сигналом.
• Инфраструктура под обучение. Даже с LoRA/QLoRA, которые заметно снижают требования к памяти по сравнению с полным дообучением всех весов, нужен сервер с GPU и достаточным объёмом VRAM — это отдельная статья расходов, которой не было бы при промптинге поверх готового API или уже развёрнутой модели.
• Цикл итерации становится дорогим. Изменили формулировку одной категории, добавили новое требование к формату, поправили тон ответа — при промптинге это правка нескольких строк текста и мгновенная проверка. При дообученной модели это новый или дополненный датасет, новый запуск обучения, новая валидация на регресс — и всё это на подготовку и прогон уходит не минуты, а часы или дни.
• Риск деградации на смежных задачах. Дообучение меняет веса модели не точечно, а во всей затронутой области — есть реальный шанс, что модель, ставшая лучше решать целевую задачу, чуть просядет на смежных, которые раньше решались нормально (эффект, близкий к catastrophic forgetting). Это придётся отдельно тестировать регрессионным набором, который тоже нужно собрать и поддерживать.
• Версионирование и откат сложнее. У промпта откат — это git diff и повторный деплой текстового файла. У дообученной модели — это отдельный артефакт весов, который нужно где-то хранить, версionировать, и откат к предыдущей версии означает переключение на другой файл модели, а не правку строки.

Отдельно о деньгах и о том, когда фактически дешевле RAG, а когда — дообучение, мы подробно считали в статье «Fine-tuning против RAG: что решает вашу задачу дешевле» — там разбор конкретных статей расходов по обоим сценариям.

Правильная иерархия: сначала промпт, потом RAG, и только затем — дообучение

Прежде чем тратить время на датасет и обучение, стоит пройти три уровня по порядку, и переходить на следующий только если предыдущий явно не справился.

Уровень 1 — промптинг. Системный промпт с чёткими инструкциями, ограничениями и явным описанием формата вывода; несколько few-shot примеров, показывающих желаемый результат на конкретных входных данных; при необходимости — разбиение сложной задачи на шаги (chain-of-thought) или структурированный вывод по схеме. Это самый дешёвый и самый быстрый в итерации уровень: правка занимает минуты, откат — секунды, тестирование — прогон нескольких примеров вручную или в скрипте.

Уровень 2 — RAG (Retrieval-Augmented Generation). Если проблема не в том, что модель «не поняла задачу», а в том, что ей не хватает конкретных фактов — актуальных цен, внутренних регламентов, содержимого документов, — промптинг эту проблему не решит в принципе, сколько инструкций ни добавляй. Здесь нужен поиск релевантных фрагментов и подстановка их в контекст запроса. Как поднять такой пайплайн на собственном сервере, разобрано в статье «Как поднять RAG по своим документам на сервере». Это по-прежнему не требует ни одного шага обучения — модель не меняется, меняются только данные, которые ей показывают.

Уровень 3 — дообучение. Только если после честной попытки на первых двух уровнях задача всё ещё не решается стабильно — и именно потому, что дело в поведении модели, а не в нехватке знаний или неудачной формулировке промпта.

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

Что закрывает промптинг без единого шага обучения

Чтобы не быть голословным — вот конкретные приёмы, которые в большинстве случаев решают то, ради чего команда собиралась дообучать модель.

Явный системный промпт с ролью, ограничениями и форматом. Вместо расплывчатого «классифицируй тикет» — точное описание допустимых категорий, формата вывода и правил на случай неоднозначности:

Ты — классификатор обращений в поддержку. Определи категорию тикета
строго из списка: [Оплата, Технический сбой, Вопрос по тарифу, Другое].

Правила:
- Если в тексте есть упоминание оплаты, счёта или списания — категория "Оплата".
- Если сервис не работает или выдаёт ошибку — "Технический сбой".
- Если сомневаешься между двумя категориями — выбери более специфичную.

Ответь ТОЛЬКО названием категории, без пояснений и знаков препинания.

Few-shot примеры. Три-пять пар «вход — правильный выход» почти всегда стабилизируют формат сильнее, чем любое словесное описание правил — модель ориентируется на образец лучше, чем на абстрактную инструкцию.

Структурированный вывод. Если проблема в том, что модель добавляет лишний текст вокруг нужных данных, чаще всего дело не в знаниях модели, а в отсутствии жёсткого формата на выходе — JSON-схема или constrained decoding решают это без единого шага обучения. Подробно об этом — в статье «Structured output в LLM: как получить JSON».

Разбиение задачи на шаги. Если модель путается в сложной многоэтапной инструкции, часто помогает не «дообучить её понимать сложные инструкции», а разбить один большой промпт на последовательность из двух-трёх более простых запросов, каждый из которых модель решает надёжно.

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

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

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

Fine-tuning — не плохое решение сам по себе, он плохой ровно тогда, когда его выбирают не разобравшись в альтернативах. Есть задачи, где он оправдан с самого начала:

• Устойчивый узкий формат или стиль, который должен работать без промпта на каждый запрос. Если контекстное окно жёстко ограничено (например, голосовой ассистент с коротким системным промптом на каждый вызов) и нет возможности каждый раз тратить токены на few-shot примеры, закрепление формата в весах становится практичным решением, а не прихотью.
• Узкоспециализированный домен с терминологией, которую базовая модель систематически путает. Если промптинг и примеры уже дают приемлемое качество, но модель регулярно путает специфичные термины отрасли (медицинские, юридические, отраслевой жаргон), а не поверхностный формат — это тот случай, где закрепление в весах даёт более устойчивый результат, чем бесконечное наращивание инструкций в промпте.
• Нужно снизить задержку и стоимость запроса за счёт меньшей специализированной модели. Вместо крупной модели с длинным промптом и множеством примеров на каждый запрос иногда выгоднее дообучить (или дистиллировать) модель меньшего размера под узкую задачу — она отвечает быстрее и дешевле по токенам, потому что не тратит контекст на инструкции при каждом вызове.
• Задача требует поведения, которое prompt injection может сломать. В сценариях, где системный промпт потенциально виден или частично контролируется пользовательским вводом, закреплённое в весах поведение устойчивее к попыткам переписать инструкции текстом запроса, чем поведение, целиком заданное промптом.

Во всех этих случаях дообучение имеет смысл начинать с LoRA, а не с полного дообучения всех весов — это заметно дешевле по GPU и данным. Как развернуть такой процесс на собственном сервере, разобрано в статье «LoRA fine-tuning своей модели на VPS».

Чек-лист перед тем, как начинать обучение

Прежде чем заводить датасет и бронировать GPU-сервер, стоит честно ответить на эти вопросы:

1. Пробовали ли переписать системный промпт с явными правилами и ограничениями формата? Не одну попытку, а хотя бы две-три итерации с разными формулировками.
2. Добавили ли few-shot примеры — минимум 5-10 пар «вход — правильный выход»? Если нет, задача может решиться на этом шаге без обучения вообще.
3. Проблема действительно в поведении, а не в нехватке знаний? Если модель не знает актуальных фактов — нужен RAG, а не дообучение, и это принципиально другое решение.
4. Проверили ли модель другого размера или семейства с тем же промптом? Иногда нестабильность решается сменой модели, а не изменением её весов.
5. Есть ли реально достаточный по объёму и качеству датасет — не 20 наспех собранных примеров, а представительная выборка с покрытием пограничных случаев? Дообучение на скудном датасете часто даёт модель хуже, чем хороший промпт.
6. Посчитана ли стоимость итерации при смене требований? Если бизнес-правила меняются раз в месяц, каждый цикл обучения — это регулярные издержки, которые нужно закладывать в план, а не разовая инвестиция.

Если хотя бы на один из первых трёх пунктов ответ «нет» — дообучение начинать рано.

Частые вопросы