Когда промптинга недостаточно

Короткая версия

О fine-tuning обычно стоит думать, когда:

1. Промпт уже хороший, но качество упёрлось в потолок.
2. Нужна высокая стабильность формата на большом потоке.
3. Нужен устойчивый стиль или voice, а не просто разовая удача.
4. Промпт разрастается до дорогого и хрупкого монстра.
5. Вы измерили это на evals, а не просто раздражены несколькими плохими ответами.

Что fine-tuning особенно хорошо улучшает

Нужно стабильно классифицировать тикеты в один и тот же JSON-формат на 100 000 запросов в день.

Первый вопрос перед fine-tuning

Не “можем ли мы дообучить модель?”, а:

промпт, retrieval и output constraints уже действительно исчерпаны?

1. Когда проблема ещё не в fine-tuning

Очень часто источник проблемы другой:

• плохой системный промпт;
• нет few-shot примеров;
• schema / structured outputs не используются;
• retrieval даёт шум;
• нет output validation;
• задача вообще не сформулирована как узкая и повторяемая.

Если вы этого ещё не сделали, fine-tuning почти наверняка преждевременен.

По current OpenAI guidance порядок здоровый:

1. собрать evals;
2. улучшить prompt;
3. убедиться, что задача действительно повторяемая;
4. только потом инвестировать в training data.

2. Главный признак: поведение важно сильнее, чем знания

Fine-tuning особенно оправдан, когда вы хотите менять не “что модель знает”, а как именно она отвечает:

• в каком формате;
• в каком стиле;
• с какой степенью лаконичности;
• как она классифицирует;
• как выбирает структуру и phrasing;
• насколько стабильно соблюдает internal rubric.

Если же главная проблема — отсутствие свежих или приватных данных, это чаще не fine-tuning issue, а retrieval issue.

3. Prompt plateaus — самый честный сигнал

Самый полезный practical сигнал: вы уже:

• сделали хороший system/developer prompt;
• попробовали few-shot;
• включили structured outputs или tool schema;
• настроили validation;
• всё это проверили на eval-наборе,

но метрика всё равно не дотягивает.

Это и есть момент, когда fine-tuning перестаёт быть “интересной идеей” и становится логичным следующим шагом.

4. Где fine-tuning особенно полезен

Чаще всего:

• classification;
• extraction;
• formatting-heavy generation;
• brand / support / legal style;
• domain-specific instruction following;
• reducing prompt length for a repeated workflow.

OpenAI current docs прямо подают SFT как сильный инструмент для:

• classification;
• nuanced translation;
• specific output formats;
• исправления instruction-following failures.

Это хороший ориентир: fine-tuning лучше работает там, где есть много хороших демонстраций правильного поведения.

5. Где fine-tuning обычно не лучший ответ

Обычно не лучший вариант, если:

• знания часто обновляются;
• нужны citations;
• ответ должен опираться на свежие документы;
• задача меняется каждую неделю;
• у вас нет хорошего и стабильного датасета.

В таких случаях чаще выигрывают:

• RAG;
• better prompting;
• structured outputs;
• output validators;
• hybrid approach.

6. Economics длинного промпта тоже имеют значение

Иногда fine-tuning нужен не ради качества “вообще”, а ради операционной экономики.

Если каждый запрос тащит:

• длинный system prompt;
• длинный policy block;
• 10-20 демонстраций;
• повторяющиеся format rules,

то даже умеренный improvement после fine-tuning может окупиться за счёт:

• меньшего prompt size;
• меньшей latency;
• более короткого context path;
• меньшего числа downstream validation failures.

Но это надо считать на реальном объёме, а не по ощущению.

7. Данные важнее идеи

Fine-tuning имеет смысл только если есть dataset, который:

• отражает реальные user inputs;
• содержит действительно “gold” outputs;
• не состоит из случайных красивых примеров;
• покрывает реальные edge cases.

Current OpenAI docs прямо рекомендуют начинать хотя бы с нескольких десятков качественных примеров и обязательно иметь holdout eval set.

Главное правило:

плохой training set не исправляет плохой продукт, а масштабирует его ошибки.

8. Чеклист перед переходом

9. Practical decision rule

Если коротко:

• нужны свежие знания -> сначала RAG;
• нужен устойчивый стиль, формат или классификация -> смотрите в fine-tuning;
• нужно и то, и другое -> чаще всего fine-tuning + RAG;
• нет evals и датасета -> fine-tuning пока рано.

Минимальная mental model

bad results
-> fix prompt/retrieval/schema first
-> measure on evals
-> if behavior still plateaus
-> collect training examples
-> run SFT
-> compare against baseline

Практически fine-tuning в 2026 имеет смысл подавать как optimization layer after eval-ready prompt stack, а не как первый инструмент кастомизации.