ORPO-донавчання LLM: SFT і Preference Optimization без еталонної моделі

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 опорна модель і окрема стадія уподобань зникають: сигнал вибраної та відхиленої відповіді подається в тому самому циклі, що й налаштування на інструкціях.

Замість штрафу за відхилення від опорної копії працює відношення правдоподібностей пари — тому друга копія моделі в пам'яті більше не потрібна, а пари «вибраний/відхилений» мають лежати поруч з інструкційними прикладами в спільному наборі.

Порядок кроків такий. Спочатку зафіксувати поточну модель і зняти метрики на відкладеній вибірці — це точка відліку, без неї збереження якості нічим підтвердити. Потім привести дані до єдиного формату, задавши явну частку інструкційних прикладів і пар уподобань у суміші.

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

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

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

Контроль тримається на двох наборах: вузькому — з доменів, де збирали уподобання, і широкому — із загальних задач, до навчання не дотичних.

Якщо якість на першому зростає, а на другому падає, модель пішла в переоптимізацію: допомагає збільшення частки інструкційних прикладів і рання зупинка за широким набором.