OpenAI Fine-tuning: практический гайд

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

OpenAI fine-tuning в 2026 удобно делить так:

С чего начинать

Почти всегда порядок такой:

1. хороший baseline prompt;
2. eval set;
3. SFT;
4. только потом DPO или RFT, если они действительно нужны.

Задача: стабильно извлекать поля из документов в строгий JSON.

Где OpenAI fine-tuning особенно хорош

• classification;
• extraction;
• style and format adaptation;
• voice consistency;
• task-specific chat behavior;
• multimodal labeling or interpretation patterns через vision SFT.

1. Почему current OpenAI framing шире старого “fine-tune job”

Раньше fine-tuning часто подавали как один режим: загрузили training file, обучили chat model, получили новый model id.

В 2026 official framing уже шире:

• есть разные objective families;
• акцент смещён в eval-first;
• важно не просто “натренировать”, а выбрать правильный optimization path;
• distillation и graders тоже становятся частью общей истории optimization.

Поэтому guide по OpenAI fine-tuning должен объяснять не только API, но и decision logic.

2. SFT — default path

Supervised fine-tuning остаётся главным starting point.

Он особенно хорош для задач, где есть:

• понятный input;
• хороший target output;
• относительно узкий task shape;
• чёткая метрика качества.

Типичные примеры:

• classification;
• structured extraction;
• translation in a particular style;
• support response formatting;
• domain-specific instruction following.

SFT полезен потому, что:

• проще объясняется;
• проще дебажится;
• проще сравнивается с baseline;
• не требует preference pairs или reward signal.

3. DPO нужен, когда examples уже недостаточно

Direct Preference Optimization полезен там, где “правильный ответ” не всегда один, но вы можете сказать, какой из двух ответов лучше.

Это особенно важно для:

• nuanced style quality;
• answer ranking;
• safety / refusal nuance;
• response helpfulness beyond raw format accuracy.

То есть DPO useful, когда у вас есть:

• baseline model outputs;
• pairwise preferences;
• желание сдвинуть модель в сторону лучшего ответа без full RL stack.

4. RFT — уже не просто “ещё одно обучение”

Reinforcement fine-tuning в current OpenAI framing особенно интересен для reasoning-heavy задач, где можно определить:

• grader;
• reward signal;
• pass/fail criterion;
• quality function, которую можно оптимизировать.

Это уже более серьёзный engineering path:

• нужен хороший evaluator;
• нужен measurement loop;
• важнее task design;
• выше риск оптимизировать не ту метрику.

Поэтому RFT не является default upgrade после SFT. Он нужен, когда задача действительно выигрывает от feedback-optimized reasoning behavior.

5. Vision fine-tuning расширяет scope, но не отменяет дисциплину данных

OpenAI current docs отдельно разводят vision fine-tuning, и это важно:

• задачи могут включать изображения;
• датасет уже не только текстовый;
• важно, чтобы examples отражали реальный multimodal workload.

Но логика та же:

• сначала baseline;
• потом evals;
• потом tuning.

Мультимодальность не отменяет требований к качеству данных.

6. Eval-first — самая важная часть

Практически сильный OpenAI fine-tuning workflow сегодня выглядит так:

1. сформировать baseline prompt;
2. собрать eval set;
3. понять exact failure modes;
4. выбрать SFT/DPO/RFT;
5. обучить;
6. сравнить с baseline не “на глаз”, а по метрике.

7. Что чаще всего ломает результат

Неудачный fine-tuning обычно связан не с API, а с одним из этих факторов:

• слабый dataset;
• inconsistent labels;
• нет holdout set;
• task слишком широкий;
• expectations перепутаны: пытаются решить retrieval problem через tuning;
• выбрали слишком сложный method раньше времени.

Именно поэтому best practices у OpenAI так сильно упирают в:

• data quality;
• data quantity;
• consistency;
• hyperparameter iteration;
• test split.

8. Когда OpenAI fine-tuning особенно оправдан

Сильнее всего он окупается, когда:

• вы уже в OpenAI ecosystem;
• задача узкая и повторяемая;
• важно сократить промпт;
• нужен managed path без own training infra;
• есть eval loop и нормальный dataset.

Менее оправдан, когда:

• нужно много low-level control;
• хочется экспериментировать с adapters и merge paths;
• задача завязана на self-hosted open models;
• нужен дешёвый локальный training stack.

Тогда уже логично смотреть в сторону LoRA/QLoRA.

Minimal SFT example

from openai import OpenAI

client = OpenAI()

job = client.fine_tuning.jobs.create(
    training_file="file-abc123",
    model="gpt-4o-mini-2024-07-18",
    method={"type": "supervised"},
)

Но сама команда должна быть не первой мыслью, а последней:

baseline prompt
-> evals
-> choose method
-> train
-> compare to baseline