Почему DPO-дообучение LLM буксует на первом прогоне
DPO-дообучение LLM срывается обычно не на запуске, а до него. Датасет предпочтений собирают формально: пары «выбранный/отклонённый ответ» размечают по общему впечатлению, без критериев, и никто не фиксирует, какой именно навык должен вырасти — следование формату, отказ от выдуманных фактов, аккуратность на длинных запросах.
Второй источник сбоя — незакреплённая эталонная модель. В дообучении без RLHF прирост считается относительно опорной политики, и если её версия меняется от прогона к прогону, веса тянут в разные стороны. Два запуска перестают быть сравнимыми: непонятно, что дало эффект — данные, порядок пар или обновлённая опора. Готовые реализации есть в Hugging Face, и вопрос не в коде запуска, а в том, что в него подают.
Дальше проявляется деградация после дообучения. Модель выигрывает на размеченных сценариях и проседает там, где похожих примеров не было: хуже держит контекст, соглашается с пользователем вместо возражения, теряет формат на составных запросах. Отложенная выборка это показывает, но прогоны уже израсходованы, а причина выглядит как «данных мало».
Корень в том, что выравнивание модели ведут как эксперимент с обучением, а не как проектирование данных и опоры. Разбираем ниже, как это закрывается: критерии разметки, фиксация эталона, контрольные замеры до и после дообучения.
Что даёт выравнивание: эффект в измеримых величинах
Эффект выравнивания измеряется не ощущением «стало лучше», а долей нежелательных ответов на фиксированном наборе запросов. Один и тот же набор прогоняется до и после дообучения: доля ответов, нарушающих заданную политику, падает в разы — с десятков процентов до единиц, и это видно по каждому классу запросов отдельно.
Качество ответов модели при этом не должно просесть. Выравнивание часто пересушивает модель — она начинает отказывать там, где ответ уместен. Поэтому в приёмку идут две метрики сразу: снижение нарушений и сохранение полноты полезных ответов на контрольной выборке. Если полнота падает, меняем состав предпочтительных пар, а не порог отказа.
Устойчивость на краевых запросах проверяется своим набором: провокации, двусмысленные формулировки, попытки вытащить системную инструкцию, вопросы вне предметной области. Здесь важна не средняя оценка, а доля корректных реакций — сколько раз модель отказала по делу и не сорвалась в шаблонный отказ на безобидный вопрос.
Время дообучения и повторного прогона — тоже часть эффекта. DPO не требует отдельно обученной модели вознаграждения, поэтому цикл короче: правку в наборе данных проверяем новым прогоном, а не планируем на неделю вперёд. На выходе — зафиксированная версия модели и протокол с метриками приёмки: доля нарушений политики, полнота уместных ответов, устойчивость на краевых запросах, воспроизводимость результата между прогонами.
Форматы работ: полный цикл, аудит или сопровождение LLM
Форматы работ по выравниванию различаются глубиной вмешательства: от разбора уже собранных данных до поддержки модели в рабочем контуре. Выбор определяется не размером модели, а состоянием корпуса пар предпочтений и наличием воспроизводимого протокола сравнения ответов. Если пары собраны разнородно, полный цикл дообучения начнётся с переразметки; если датасет валиден, но оценку нельзя повторить на одном и том же наборе, результат не получится ни подтвердить, ни откатить.
Сравнение режимов
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Аудит датасета | Есть пары «лучше/хуже», но выравнивание не сходится с ожидаемыми ответами | Модель не меняется: на выходе карта дефектов разметки и план правок, а не улучшенное поведение |
| Полный цикл дообучения | Нужно сместить тон, стиль и следование правилам предметной области на своём корпусе | Требует эталонного набора и фиксированного протокола оценки — при размытых критериях «лучше» модель теряет качество на общих запросах |
| Сопровождение модели | Модель уже выровнена и работает в продукте | Без регулярного пополнения пар предпочтений качество проседает на новых типах запросов |
Границы между режимами подвижны: аудит датасета часто переходит в полный цикл, а сопровождение включает периодическое переобучение на свежих парах. Общее ограничение одно — без эталонного набора и закреплённого порядка сравнения выравнивание нечем измерить, поэтому мы сначала проверяем, воспроизводится ли оценка, и только потом берёмся за обучение.
Этапы внедрения: от аудита данных до приёмки модели
Порядок этапов здесь важнее скорости. Если начать с подбора параметров обучения, а не с разбора данных, модель выучит шум в парах «предпочтительное / отклонённое» и начнёт уверенно воспроизводить его в живых запросах. Поэтому DPO дообучение строим от данных к приёмке: каждый шаг опирается на артефакт предыдущего.
- Аудит данных и метрик. Смотрим, что уже есть — журналы обращений, историю правок операторов, готовые пары предпочтений. Замеряем текущее качество базовой модели по 8–12 сценариям, чтобы было с чем сравнивать.
- Проектирование схемы выравнивания. Договариваемся, какие пары считаем предпочтительными и почему, как размечаем спорные случаи, какой профиль отказа попадает в обучение.
- Сборка набора данных. Убираем дубликаты и взаимные противоречия, делим массив на обучающую, валидационную и отложенную части до первого прогона.
- Прогоны дообучения. Подбираем скорость обучения и число проходов, следим, чтобы модель не потеряла общую полезность на фоне роста качества в целевых сценариях.
- Проверка на отложенной выборке — на данных, которых модель не видела. Сравниваем с базовой версией по тем же сценариям и смотрим не только средний результат, но и разброс по ним.
- Приёмка модели. Согласуем критерии на реальных задачах и по каждому принимаем решение: выпускать, доучивать или пересобирать данные.
- Передача решения. Отдаём веса, конфигурации прогонов, разметку и регламент переобучения, обучаем команду и настраиваем контроль качества в эксплуатации.
Артефакты выравнивания: датасет, конфигурации, регламенты
Комплект передаём не как «модель плюс пара файлов». Если у заказчика остаются только итоговые веса, повторить запуск, объяснить поведение системы или обновить её без нас уже не получится — каждый следующий цикл начинается с нуля. Поэтому сдаём набор артефактов, где каждый отвечает на свой вопрос: на чём учили, чем запускали, как проверяли и что делать при следующем обновлении.
- Размеченный датасет предпочтений — пары «ответ лучше / ответ хуже» с критериями сравнения, указанием разметчиков и журналом спорных случаев. Без него следующее дообучение начинается заново.
- Карточка модели — на каких данных выровнена, для каких задач пригодна, где границы применимости и известные слабые места.
- Рабочие конфигурации — параметры обучения и оценки, разбиение на выборки, условия остановки. Запуск воспроизводится один в один, а не «примерно так же».
- Метрики и отчёт по оценке — что было до выравнивания и что стало, на каких наборах проверяли, как исключали подсказки из контрольных примеров.
- Регламент обновлений — какие события запускают новый цикл: падение качества, приток свежих данных, смена требований к поведению; кто согласует выпуск.
- Документация по выравниванию — принятые компромиссы и запреты: почему выбран такой профиль ответов и какие ограничения наложены на генерацию.
Такой комплект живёт без нас: предпочтения можно добрать, оценку повторить, а спорный случай разобрать по записям разметки.
Кейс: выравнивание модели поддержки без роста отказов
До выравнивания
Модель поддержки на открытой ветке Qwen отвечала на обращения по тарифам и подключению. По замерам на выборке из 1200 диалогов 11% ответов содержали условия, которых нет в тарифной сетке: модель достраивала их по инерции, а оператор узнавал об ошибке от клиента. Ещё 8% диалогов она закрывала шаблонным «уточните вопрос» вместо эскалации, хотя тема была в зоне ответственности второй линии.
Что изменили
Собрали 14 тысяч пар предпочтений из истории переписки и разметки операторов: выбранный ответ против отклонённого, включая пары на тему «нужна эскалация». Дообучали методом DPO — без отдельной модели вознаграждения, с ограничением отклонения от исходной модели, чтобы не просесть на редких темах. Негативные примеры взвешивали выше: один уверенный выдуманный ответ обходится дороже, чем три лишних уточняющих вопроса.
Метрики до и после
Доля ответов с недостоверными условиями: 11% → 0,4%. Доля корректных эскалаций на вторую линию: 62% → 94%. Время первого ответа не выросло, инференс остался на одной модели — второй сети для оценки не потребовалось. Класс отказов «уверенный ответ вне зоны компетенции» на повторной выборке не воспроизвёлся ни разу, а замеры через месяц на новых диалогах дали те же доли: выравнивание держится, модель не сползла обратно к исходному поведению.
Как отличить слабый датасет от недообученной модели?
Первое, что отделяет слабый датасет от недообученной модели, — поведение метрики на отложенных парах предпочтений, которых модель не видела. У недообученной модели потеря на обучении и на проверке падает синхронно: добавляешь прогоны — растёт и уверенность в выборе, и качество на новых запросах.
Если разрыв между выбранным и отвергнутым ответом растёт, а качество на отложенном наборе стоит на месте, объём прогонов тут ни при чём. Тогда смотрим на разметку: как модель ведёт себя на парах с очевидным предпочтением и там, где аннотаторы расходились между собой.
Шумная разметка выдаёт себя нестабильным разрывом: на простых парах он узкий и гуляет от прогона к прогону. Прямая диагностика датасета — отдать часть пар на повторную разметку и посчитать долю противоречий: при низкой согласованности модель закрепляет случайные решения, и лишние прогоны лишь усиливают шум.
Признаки переобучения видны по форме ответов: модель копирует длину, вступления и обороты из обучающих пар, теряет разнообразие, растёт на обучении и проседает на отложенном наборе. Часто это не переобучение, а утечка — одни и те же темы и формулировки попадают и в обучение, и в проверку.
Проверка гипотез строится как контролируемый эксперимент. Фиксируем схему выравнивания и меняем только данные: убираем противоречивые пары, выравниваем распределение тем. Ожила отложенная метрика — вопрос был в разметке; нет сдвига ни при другой схеме, ни при большем числе прогонов — потолок задавали данные.
Технические сомнения: переобучение, деградация, откаты
Перед стартом выравнивания инженеры задают одни и те же вопросы: не «пережуёт» ли модель общий словарь ради узкого поведения, как откатиться, если качество просядет, и что происходит с доступами к чувствительным данным. Ниже — ответы по существу, без общих слов.
Как отличить переобучение модели от нормального роста качества?
Мы держим отложенный набор примеров, который не участвует в обучении. На нём переобучение видно как расхождение: согласие с разметкой растёт, а качество ответов на посторонних задачах падает. Обучение останавливается по этому расхождению, а не по фиксированному числу шагов.
Реально ли откатить версию после выравнивания?
Да. Базовая модель остаётся неизменной, а изменения живут отдельным слоем — откат версии занимает минуты, без пересборки всего контура. Каждый прогон получает свой артефакт и метрики, поэтому сравнение «до/после» сохраняется.
Что с безопасностью изменений и данными?
Работа идёт в изолированном контуре: данные для дообучения не покидают вашу инфраструктуру, доступы выдаются по ролям и логируются. Риски выравнивания — потеря части навыков и смещение тона — снимаются регрессионным набором задач, который прогоняется перед каждым выкатом.
Обсудим задачу: что прислать и как мы вернёмся с оценкой
Чтобы оценка дообучения опиралась на данные, а не на предположения, нам нужны вводные по проекту. Чем раньше приходит пример набора предпочтений и текущие метрики качества, тем точнее план работ и меньше итераций на согласование.
- Базовая модель и способ её получения: открытые веса или доступ через внешний сервис, ограничения лицензии на коммерческое использование, нужна ли поддержка нескольких языков.
- Данные предпочтений: пары «выбранный / отклонённый» ответ с кратким пояснением, кто и по какому критерию размечал. Если есть только инструкции и ответы без сравнений, это другой сценарий — скажем об этом сразу.
- Целевое поведение: что считаем хорошим ответом — следование формату, отказ от нежелательных тем, ссылки на источники, длина и тон.
- Контрольный набор вопросов, на котором вы сейчас видите разницу, и допустимая доля регрессий на нём.
- Ограничения: юридические и предметные запреты, обязательные предупреждения, требования к хранению данных и изоляции контура.
- Вычислительные ресурсы для обучения и запуска, а также кто отвечает за приёмку результата с вашей стороны.
После этого возвращаемся с оценкой дообучения, планом работ по этапам и схемой сотрудничества: что делаем мы, что остаётся на вашей стороне, где точки согласования и как устроен откат к предыдущей модели. Опишите задачу в свободной форме — обсудим задачу, уточняющие вопросы зададим сами.
