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