ORPO-дообучение LLM: SFT и Preference Optimization без reference модели

ORPO-дообучение: где ломается классический цикл настройки

Классический цикл дообучения языковой модели устроен в два этапа: сначала настройка на инструкциях, затем отдельная настройка на предпочтениях. Между ними держат замороженную копию исходной модели — опорную модель, относительно которой считается отклонение поведения. Копия не обучается, но живёт в памяти рядом с рабочей и удваивает число проходов по данным.

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

ORPO-дообучение убирает это разделение. Штраф за отклонение от исходного поведения считается прямо в целевой функции вместе с настройкой на инструкциях, поэтому опорная модель перестаёт быть отдельным артефактом: один цикл, один набор весов, одна точка контроля метрик. Освободившийся ресурс уходит в длину контекста и размер порции данных, а не в поддержание второй копии.

На выпуске версий разница тоже видна: сравнение вариантов идёт по одному прогону, откат — возврат к одной сохранённой версии весов, а не согласование двух. Инструментарий для такого режима уже есть — например, Hugging Face TRL поддерживает его наряду с классическими схемами. Дальше разбираем, как выглядит цикл дообучения без опорной модели и где он даёт наибольший выигрыш.

Что даёт отказ от отдельного этапа согласования предпочтений

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

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

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

Для заказчика это более частые обновления: правки в разметке и новые требования попадают в модель за один цикл, а не за два, и не требуют отдельной инфраструктуры под опорную модель. Контрольные метрики — доля нежелательных ответов, доля корректных на размеченных сценариях, разброс между запусками — мы фиксируем до старта, чтобы эффект был проверяемым, а не оценочным.

Сравнение схем: полное дообучение, SFT и ORPO

Схемы различаются не «мощностью», а тем, сколько данных и памяти они требуют и что именно меняется в модели. Выбор определяется задачей: научить следовать формату, сдвинуть стиль ответов или поднять качество там, где примеры уже есть, а эталонных ответов нет.

Схемы не заменяют друг друга линейно: SFT и оптимизация по предпочтениям обычно идут парой, а адаптеры накладываются поверх любой из них. Ограничения в таблице — не недостатки, а цена, которую платят за конкретный эффект, поэтому подход подбираем под данные, срок жизни модели и требования к откату.

Как строится работа: от аудита данных до передачи модели

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

1. Аудит обучающих данных. Разбираем корпус на дубли, противоречия и утечки между выборками, проверяем, покрывают ли примеры целевые сценарии и редкие случаи. На выходе — отчёт с перечнем пробелов и объёмом данных, которого достаточно для обучения.

2. Разметка пар предпочтений. Формируем пары «лучший / худший ответ» по правилам, которые согласовали заранее, и фиксируем их в инструкции для разметчиков. Разногласия разбираем на контрольной партии — так в данные не попадает вкусовщина отдельного исполнителя.

3. Схема обучения. Определяем базовую модель, длину контекста и порядок стадий: сначала дообучение на инструкциях, затем оптимизация предпочтений. ORPO здесь выигрывает тем, что не требует отдельной модели-эталона — обучение идёт в один проход и не раздувает требования к ресурсам.

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

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

6. Передача модели. Отдаём веса, конфигурацию обучения, версионированный датасет, скрипты запуска и отчёт по метрикам. Проводим обучение вашей команды: как разворачивать, как обновлять данные, что делать при деградации.

7. Сопровождение. Отслеживаем качество на живом трафике по выборке запросов и планируем переобучение, когда распределение запросов смещается.

Артефакты и конфигурации, которые остаются у заказчика

Передаём не только веса модели, но и всё, что делает обучение воспроизводимым без нас. Без конфигурации прогона и описания данных повторный запуск через полгода превращается в разбор логов: непонятно, какой набор дал прирост, а какой — деградацию.

• Конфигурация обучения — гиперпараметры ORPO, схема разбиения на обучающую и отложенную выборки, фиксированное зерно генератора, перечень контрольных точек. По ней прогон повторяется один в один.
• Карточка модели — назначение, границы применимости, состав обучающих данных, известные слабые места, метрики на отложенной выборке.
• Регламент переобучения — триггеры (просадка метрик, дрейф запросов, новые тематики), периодичность, критерии приёмки, порядок отката на предыдущую версию.
• Политики доступа к данным — кто и в каком контуре читает выборку, как обрабатываются персональные данные, сроки хранения и правила выгрузки.
• Документация по модели — отличия от базовой версии, обоснование архитектурных решений, инструкции по запуску, обновлению и диагностике.
• Журнал экспериментов — какие конфигурации проверяли, что дало прирост качества, что отвергли и почему. Экономит месяцы повторных проб.
• Окружение сборки — воспроизводимые зависимости и порядок выкатки, чтобы результат не зависел от конкретной машины инженера.

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

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

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

Что изменили

Перешли на ORPO на актуальной ветке Hugging Face TRL: согласование ответов с предпочтениями идёт в одной стадии обучения, отдельная опорная модель не нужна. Освободившуюся память отдали под больший размер пакета и более длинный контекст, а освободившееся время инженеров — на расширение набора автоматических проверок.

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

Технические сомнения: что уточняют до начала работ

До старта дообучения фиксируем не только целевую метрику, но и условия воспроизводимости результата. ORPO сводит настройку на инструкциях и на предпочтениях в одну функцию потерь, без отдельной опорной модели, — и качество данных становится критичным. Ниже вопросы, которые задаём мы, и те, что стоит задать нам.

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

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

Можно ли обучать в закрытом контуре?

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

Что с граничными запросами?

Собираем отдельный набор: пустой и обрывочный ввод, противоречивые инструкции, темы вне зоны ответственности, попытки вывести модель за рамки. Ждём предсказуемый отказ с уточняющим вопросом, а не ответ любой ценой; эти же случаи идут в приёмку.

Обсудим задачу: что нужно для оценки и плана работ

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

• Примеры запросов и ответов — 50–100 живых пар: по ним видно формат, длину, стиль и типичные ошибки модели.
• Ограничения по данным: что нельзя выносить за контур, нужно ли обезличивание, какой объём корпуса доступен.
• Текущая схема обучения: что уже запускали, на каких данных, какие метрики снимали и что вышло по факту.
• Требования к поведению: тон, структура ответа, работа с неполным вводом, какие темы модель должна отклонять.
• Разметка предпочтений: есть ли пары «ответ лучше / хуже» — на них ORPO-дообучение идёт без отдельной модели-эталона.
• Условия эксплуатации: где работает модель, допустимое время ответа, ожидаемый объём обращений.
• Критерии приёмки: какая доля корректных ответов считается результатом и какие классы ошибок должны уйти.

Дальше собираем план: этапы, метрики, точки контроля качества, порядок отката на предыдущую версию. Есть пары предпочтений — начинаем с обучения, нет — планируем их сбор отдельным этапом. Опишите задачу — вернёмся с оценкой и планом работ.

Миграция на ORPO, если модель уже настроена на предпочтениях

Да, переход выполним и на модели, которая уже прошла дообучение на предпочтениях, но это не переобучение с нуля, а контролируемая миграция схемы обучения. В подходе ORPO: Monolithic Preference Optimization without Reference Model опорная модель и отдельная стадия предпочтений исчезают: сигнал выбранного и отклонённого ответа подаётся в том же цикле, что и настройка на инструкциях.

Вместо штрафа за отклонение от опорной копии работает отношение правдоподобий пары — поэтому вторая копия модели в памяти больше не нужна, а пары «выбранный/отклонённый» должны лежать рядом с инструкционными примерами в общем наборе.

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

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

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