Навчання корпоративних AI-агентів: вибір між SFT, DPO, GRPO та RAG.

Уявіть собі, що десять днів тому аналітик поставив запитання агенту підприємства: чому минулого кварталу продажі в Північній Америці знизилися? Система запитала, що означає „минулий квартал“, і визначила його як другий квартал фінансового року 2026. Вона прив’язала Північну Америку до схваленої регіональної ієрархії, створила SQL-запити, пов’язані з конкретним користувачем, перевірила кілька гіпотез та надала посилану на джерело звіт.

Сьогодні аналітик ставить схоже запитання. Агент все ще пам’ятає правильний діапазон даних, проте генерує некоректний JSON-формат інструменту, присвячує кілька абзаців поясненню гіпотези, яка вже не спрацювала, та з великою впевненістю посилається на чернетку фінансової звітності.

На цьому етапі багато команд вирішують, що модель потребує доробки. Іноді це правильно. Але досить часто вони намагаються навчити неправильний об’єкт.

З’ясуйте, що пішло не так. Карта регіонів — це факт, фінансова записка — це знання, яке підпорядковується певним правилам, а схема SQL — це інтерфейс, який постійно змінюється, тому всі три елементи знаходяться в пам’яті, механізмах пошуку та контрактах інструментів. Натомість параметри ваг мають відображати більш стабільні звички: виконання коректних викликів інструментів, дотримання протоколу обробки даних, відновлення після отримання порожнього результату, віддавання переваги висновкам, підкріпленим посиланнями, та відмова відповідати, коли наявні у агента докази є недостатніми.

Це розділення є основою для всієї адаптації в корпоративних системах:

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

Оновлення моделі — це не просто результат роботи з нотатником. Це контрольоване випускання, а його слід доказів починається ще до першого кроку оптимізатора та має вижити під час скасування роботи в продакшені.

У наступному розділі розглядається звичайний набір інструментів після навчання з точки зору корпоративного агента — цілі, яка суттєво відрізняється від моделі для порівняння. Основні теми:

• вирішення питання, чи належить дефект до категорій запитів, пошуку, пам’яті, інструментів чи ваг;
• створення системи обробки даних, яка буде відповідати законодавству та стійкою до забруднення;
• вибір між продовженням попереднього навчання, керованим доробкою, LoRA, QLoRA, DoRA та повним доробком;
• підбір методів DPO, IPO, KTO, ORPO та SimPO відповідно до форми даних про переваги;
• розрізнення проблем, які вирішують методи PPO, GRPO, DAPO, GSPO, RLOO та навчання з перевірюваними винагородами;
• використання техніки дистиляції вчителя та учня для перетворення передових можливостей на економічно ефективні рішення;
• реєстрація, оцінка, тестування, моніторинг та скасування адаптерів як продуктів у середовищі виробництва.

Одна основна справа пронизує все нижчезазначене: INV-22041 — це розслідування у сфері продажів з участю кількох агентів для орендаря acme-eu. Воно складається з чотирьох логічних етапів (поглиблення інформації, достатність даних, перевірка гіпотез та підготовка звіту). Кожен етап має власні інструменти та підпроцеси, проте договір про навчання залишається видимим на кожному рубежі етапів.

Коли навчання — це правильне рішення

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

Виберіть найменш незворотний рівень, який усуває дефект:

1. Пакет запитів або системний пакет керує прямими діями, які базова модель вже надійно виконує.
2. RAG обробляє актуальні корпоративні знання, які мають бути прив’язані до конкретного джерела.
3. Пам’ять зберігає уподобання користувача, стабільні зв’язки та раніше схвалені результати.
4. Контроль інструментів та схем забезпечує детермінізм, авторизацію та контроль над побічними ефектами.
5. SFT або PEFT спрямовані на формування стабільної структури відповідей, граматики інструментів, шаблонів відновлення та стилю в певній галузі.
6. Оптимізація уподобань застосовується, коли кілька варіантів вихідних даних є дійсними, але один з них постійно кращий.
7. Навчання з підкріпленням використовується, коли успіх можна оцінити лише після низки рішень.

Виконайте INV-22041 за тією самою схемою. Знання про те, що „Північна Америка“ відповідає схваленому вузлу регіону NA_01, є завданням для керованої пам’яті чи метаданих. Прив’язка tenant_id, використання тільки для читання семантичного шару та повернення типізованого JSON у кожному SQL-запиті є частиною умов роботи та поведінки інструменту, який можна навчати. Віддавання переваги короткому поясненню з посиланням перед переконливою історією без посилань є чудовою метою для навчання вподобань.

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

Виберіть метод відповідно до наявних у вас даних

Команди часто починають з назви алгоритму. Натомість почніть з доказів, які у вас справді є.

• Якщо є підказки, що поєднуються з ідеальними відповідями чи ідеальними слідами використання інструментів, використовуйте SFT.
• У разі наявності обраних та відхилених відповідей застосовуйте методи класу DPO.
• Якщо існують незалежні мітки, які позначають результати як бажані чи небажані, і немає їхнього поєднання, KTO є природним вибором.
• Якщо детерміністичний оцінювач може оцінити кожен результат (валідність SQL, точну відповідь, тести одиниць, перевірки політики), то оптимізація з верифікованими винагородами, така як GRPO чи RLVR, є підходящою.
• Коли якість є суб’єктивною та не може бути зведена до правила, якому довіряють усі, класична модель винагород разом із налаштуванням PPO залишається актуальною.

Усе це не є ідеологією. Кожен вибір визначає, що можуть довести ваші дані.

Інваріант випуску, який варто зберегти

Для кожного прикладу навчання записуйте туплу, яка містить ідентифікатор прикладу та джерела його походження, причини надання згоди та мету її надання, того, до якого користувача він належить, версію політики, хеш застосованої трансформації, групу, до якої він потрапив, а також версію того, хто створив його (етикетувальника чи оцінювача). Після розгортання ця тупла дозволяє відповісти на складні запитання: звідки походить певна поведінка? Чи був приклад санкціонований? Чи може він потрапити до інших користувачів? Яка трансформація його створила? Чи з’являвся він також під час оцінки?

Платформа корпоративних даних

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

Походження даних — перед попередньою обробкою

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

Приватність, секрети та мінімізація даних

Цензура є необхідною, але її недостатньо. Набір даних може не мати очевидних назв, проте все одно містити конфіденційну бізнес-логіку, рідкісні ідентифікатори, значення, специфічні для клієнтів, чи секрети, які можна відновити. Врахуйте наступні аспекти:

• скануйте на наявність персональних даних та секретів як до, так і після трансформації;
• зберігайте ізоляцію користувачів через вибірку даних, їх зберігання та оцінку;
• фільтруйте за метою використання, а не лише за правами доступу;
• перевіряти на наявність майже ідентичних елементів у тестових наборах та захищених корпусах даних;
• фіксувати ланцюжок видалень, щоб запит на отримання даних дійшов до первинних даних, похідних прикладів, контрольних точок, адаптерів, кешів та результатів оцінки.

Забруднення можна виміряти

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

Для людських міток потрібен контракт

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

1. дотримання вимог щодо авторизації та конфіденційності;
2. фактична підтримка та правильні посилання;
3. статистична достовірність;
4. калібрована невизначеність;
5. повнота;
6. конкретність та стиль.

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

Як виглядає запис навчання у продакшні

Корисним результатом є не просто пара запиту та відповіді. Це запис, який дозволяє здійснювати об’єднання даних для керування та оцінювання:

{
  "example_id": "inv22041-sft-01842",
  "tenant_scope": "synthetic-enterprise",
  "purpose": "tool_format_and_recovery",
  "messages": [
    {"role": "user", "content": "Why are sales down in the last quarter?"},
    {"role": "assistant", "content": "I will use the previously approved Q2 FY2026 scope and test the cited hypotheses."}
  ],
  "tool_trace": {
    "name": "query_semantic_layer",
    "arguments": {"tenant_id": "acme-eu", "region_id": "NA_01", "period": "FY2026-Q2"}
  },
  "source_ids": ["memory:m-492", "schema:v17", "policy:p-31"],
  "transform_hash": "sha256:…",
  "split": "train"
}

Ці значення створюються навмисно. Але структура — ні: один об’єкт містить вміст разом із інформацією про того, хто його авторизував, звідки він походить та як він ідентифікується під час оцінки.

SFT, продовження попередньої та середньої підготовки

Люди об’єднують ці методи під поняттям „тонкої налаштування“, проте кожен з них оптимізує різну розподілу даних.

Керована тонка налаштування

SFT змушує модель імітувати бажану відповідь чи траєкторію. Функція втрати є негативною сумою за всі позиції: маска помножується на лог-ймовірність, яку модель присвоює цільовому токену з урахуванням вхідних даних та попередніх цільових токенів. У цій формулі x — це вхідний контекст, yₜ — цільовий токен на позиції t, маска mₜ дорівнює (1) для токенів, які підлягають нагляду, та (0) для промпту, заповнювачів та всього іншого, що виключено, а θ позначає параметри, які можна навчати.

Токени системи, користувача, результату роботи інструменту та заповнювачі забезпечують контекст, не генеруючи градієнти. Лише обрані цільові токени асистента впливають на функцію втрати, яка використовується для нагляду.

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

Що насправді робить мета функції крос-ентропії

На кожній позиції з наглядом модель генерує один логіт для кожного токена словника, а функція softmax перетворює ці логіти на ймовірності. У функції softmax ймовірність токена дорівнює його експоненційованому логіту, поділеному на суму експоненційованих логітів усього словника, тож результати є додатніми та дорівнюють одиниці.

Потім крок крос-ентропії обчислює вартість для моделі як від’ємний логарифм ймовірності, яку вона надала правильному токену. Правильний токен з ймовірністю 0,8 коштує приблизно 0,223. При ймовірності 0,01 це коштує приблизно 4,605. Тож помилки, зроблені з впевненістю, створюють набагато більші градієнти, ніж прогнози, які вже є правильними.

Одна з наслідків має велике значення в підприємствах. Невелика кількість прикладів високоякісних інструментів може ефективно виправити систематичну проблему форматування, за умови, що ціль є однозначною. Коли два приклади демонструють семантично ідентичні запити, поєднані з суперечливими схемами інструментів, це призводить до несумісних прогнозів.

Втрата послідовності, втрата токенів та їхнє бізнес-значення відрізняються

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

Коли правильність відмови, зобов’язання орендаря чи вибір інструменту мають велике значення для бізнесу, самі приклади не можуть відобразити цю важливість. Існують такі варіанти:

• балансування пакетів за класом поведінки;
• надання більшої ваги прикладам чи обраним токенам;
• скорочення занадто довгих цілей;
• перевибір рідкісних межових випадків;
• розділення оцінки якості генерації та перевірки умов контракту під час оцінки.

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

Примус від викладача та упередження через вплив

Під час SFT кожен токен прогнозується після правильних попередніх токенів-цілей. Однак під час виконання модель читає те, що сама створила, тож навіть невелика помилка може призвести до ситуації, якої ніколи не було під час навчання.

Для агента ця прогалина проявляється у послідовних збоях інструментів:

1. Модель генерує ідентифікатор ентитета, який є трохи неправильним.
2. Інструмент повертає порожній результат.
3. Модель ніколи раніше не бачила такого стану.
4. Вона вигадує результат та не виправляє запит.

Включіть траєкторії відновлення разом із ідеальними демонстраціями. Методи на-політи-дистиляція та посилення навчання більш прямо вирішують проблему зміни розподілу пізніше.

Правильне маскування розмов з інструментами

Реалістичний запис містить політику системи, мову користувача, міркування асистента, аргументи інструменту, результати інструменту та кінцеву відповідь. Вирішіть, які токени мають використовуватися для формування поведінки:

• токени системи та користувача зазвичай отримують маску 0;
• виклики інструменту асистентом зазвичай отримують маску 1;
• чистий вихід інструменту зазвичай отримує маску 0, оскільки це спостереження з середовища, а не мова, яку асистент має імітувати;

Аналіз асистента чи приховане міркування відбувається згідно з правилами постачальника моделі та політикою розгортання;

кінцева відповідь отримує маску 1.

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

Пакування без витоку між прикладами

Припустимо, приклади A, B та C використовують 700, 900 та 1 100 токенів відповідно. Розмістіть кожен з них у окремій послідовності об’ємом 4 096 токенів, і в середньому використовується лише близько 22% виділених позицій. Пакування підвищує ефективність використання, проте об’єднана послідовність потребує захисних механізмів:

• необхідно дотримуватися власних правил моделі щодо обробки позицій;
• усе, що не повинно бути оброблено (додаткові дані, виключені елементи), отримує мітку ігнорування від фреймворку, зазвичай −100;
• Якщо метод розглядає приклади як незалежні, увага не повинна переходити від одного прикладу до іншого;
• для відлагодження та запитів на видалення все одно необхідно, щоб метадані кожного прикладу залишалися доступними.

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

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

Продовження попереднього навчання

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

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

Змішування даних галузі з даними для повторного використання

Назвімо нову дистрибуцію доменів D_domain, а зразком можливостей, які мають зберегтися, буде D_replay. Мета простого змішування полягає у додаванні зваженої очікуваної втрати для даних домену до зваженої очікуваної втрати для даних повторного використання. Жоден з цих коефіцієнтів не є універсальною константою. Щільно спеціалізована локальна модель може приймати більший коефіцієнт для даних домену, тоді як спільна корпоративна базова модель зазвичай потребує сильнішого чинника збереження.

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

Швидкість навчання визначає радіус поширення змін

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

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

Середина процесу навчання

Проміжне навчання знаходиться між розширеним попереднім навчанням та фінальним післянавчальним етапом. Селекційні дані з довгим контекстом, розумовими операціями, багатомодальними даними чи слідами дій агента змінюють його здібності ще до досягнення узгодженості. Для INV-22041 це може означати довгі записи про розслідування, під час яких агент бачить порожній результат SQL, замислюється, чи причиною є розмір часових інтервалів чи семантичне мапування, виправляє запит, оновлює свій набір гіпотез та складає стислий звіт про докази.

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

SFT чи проміжне навчання: діагностика

Запитайте себе, чи можна проявити бажану поведінку за допомогою досить короткої пари вхідних/вихідних даних.

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

Для INV-22041 дійсний SQL JSON є метою для фін-тюнінгу. Ретельно підібрані довгі траєкторії можуть допомогти агенту відновитися під час 30-крокового розслідування з кількома невдалими гіпотезами. Показники сьогоднішніх продажів залишаються даними про час виконання.

Тюнінг із ефективним використанням параметрів: LoRA, QLoRA, DoRA та тюнінг префіксів

Фін-тюнінг із ефективним використанням параметрів має стати стандартом для корпорацій, оскільки він дозволяє використовувати одну спільну базову модель разом із невеликими, версіонованими змінами її поведінки.

LoRA

LoRA заморожує матрицю ваг W та навчається коригуванню низького рангу. Адаптована матриця дорівнює W плюс добуток двох малих матриц B та A, масштабований значенням альфа, розділеним на ранг r.

Припустимо, що W перетворює 4096 вхідних даних у 4096 вихідних, а ранг становить 16. У такому разі щільна матриця містить приблизно 16,8 мільйона параметрів, тоді як дві матриці LoRA мають лише 131 072 параметрів, які можна навчити для цього перетворення (16 × 4096 плюс 4096 × 16). Це становить близько 0,78% від кількості параметрів щільної матриці.

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

Чому низький ранг може бути достатнім

Щільне оновлення дозволяє кожному напрямку вхід-вихід змінюватися окремо. LoRA припускає, що оновлення, специфічне для завдання, знаходиться у значно меншому внутрішньому підпросторі. Замість того, щоб вивчати значення d_out × d_in, вона вивчає лише r(dᵢ + dₒ), де dᵢ — ширина вхідних даних, а dₒ — ширина вихідних даних.

Для квадратної проекції розміром 4096 на 4096 при рангу 16 ці числа є такими:

• щільне оновлення вимагало б 16,777,216 параметрів;
• оновлення LoRA вимагає 131,072 параметрів;
• частка параметрів, які можна навчати, становить 0,0078125, або 0,78125%.

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

Коефіцієнт масштабування — це не декоративний елемент

З значенням alpha 32 та рангом 16 множник LoRA дорівнює 2. Якщо підвищити ранг до 64, залишивши alpha на рівні 32, множник зменшується до 0,5. Навчені матриці та динаміка оптимізації змінюються, навіть якщо набір даних та базова модель залишаються незмінними.

У деяких реалізаціях замість формули alpha/ранг використовується стабілізоване масштабування, пропорційне alpha до квадратного кореня рангу. Це змінює порівняння між рангами. Обов’язково записуйте правила масштабування, версію бібліотеки, спосіб ініціалізації та параметри dropout.

Де приєднувати адаптери

Кожен з елементів проєкцій уваги виконує окрему функцію:

• q_proj формує запит, який поточний токен адресує до контексту;
• k_proj визначає, як ранні токени передають інформацію про свій зміст;
• v_proj встановлює сам зміст, який фактично отримується з них;

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

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

Складання адаптерів не є автоматично адитивним

Два адаптери, які добре працюють окремо, все одно можуть вступати у конфлікт, коли обидва активні. Їхні дельти можуть штовхати одні й ті самі шари в суперечливих напрямках, змінювати статистику активації або використовувати різні набори систем. Сприймайте складену структуру як новий рецепт: сумарні ваги — це базові ваги плюс дельта кожного адаптера, помножена на його масштаб sᵢ. Це рівняння здається простим, але оновлені проекції проходять через шари уваги, нормалізації та MLP нелінійно, тому тестуйте складену структуру саме так, як вона подається.

QLoRA

QLoRA зберігає заморожену базу у 4-бітному форматі, тоді як градієнти надходять лише до адаптерів LoRA. Він використовує технологію NF4, подвійну квантацію констант квантації та оптимізатори з пагінацією, які запобігають різкому зростанню використання пам’яті.

Два аспекти допомагають уникнути помилок у продакшені:

• QLoRA — це техніка для економії пам’яті під час навчання. Вона сама по собі не визначає параметри квантації під час використання.
• Один лише адаптер не свідчить про те, що квантована версія буде працювати так само. Повторіть оцінки якості, затримки, витоків даних та використання інструментів на тій версії, яку ви насправді використовуєте.

Чому важливі NF4 та подвійна квантація

Звичайні 4-бітні цілі числа ділять діапазон на рівномірно розташовані значення. Заздалегідь навчені ваги часто мають нормальний розподіл, тому рівномірне розташування значень неефективно використовує їхні репрезентативні рівні. NF4 дозволяє розміщувати значення так, щоб вони краще відповідали цьому розподілу.

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

Як приблизна оцінка пам’яті для заморожених ваг, потрібно помножити кількість параметрів на кількість бітів на вагу, поділити на 8 та додати метадані. Якщо зберігати дані в ідеалі у 4 біти, модель із 7 мільярдів параметрів потребуватиме близько 3,5 ГБ для зберігання самих ваг (7 млрд × 4 / 8). До цього додаються буфери, тимчасова деквантизація, адаптери, градієнти, стан оптимізатора, активації та інші витрати фреймворку, тому твердження про те, що модель із 7 мільярдів параметрів поміщається у 3,5 ГБ, нічого не гарантує щодо пам’яті під тренування.

QLoRA економить пам’ять завдяки замороженим базовим вагам та оптимізації адаптерів. Однак пам’ять, необхідна для активацій, все одно залежить від розміру пакету даних, довжини послідовності, ширини шарів та політики зберігання проміжних результатів, що означає, що тренування з довгим контекстом може залишатися обмеженим обсягом пам’яті для активацій навіть при використанні ваг у 4 біти.

Оптимізатори з пагінацією

Перевірка стану активації та довгі послідовності можуть спричинити тимчасове зростання навантаження на пам’ять. Оптимізатори з пагінацією використовують керовану пам’ять для переміщення сторінок оптимізатора між CPU та GPU за потреби. Це може запобігти збоям через нестачу пам’яті, хоча пагінація може знизити продуктивність. Вимірюйте час виконання та навантаження на пам’ять хоста, і не вважайте успішне виділення пам’яті ознакою успішної оптимізації.

DoRA

DoRA розділяє вагу на величину та напрямок та застосовує оновлення низького рангу переважно до напрямку. Адаптована вага — це навчена величина m, помножена на оновлена матриця W + ΔW, нормалізована стовпець за стовпцем. Тут ΔW — це оновлення у стилі LoRA. Ідея полягає у тому, що величина та напрямок виконують різні функції, і їх розділення дозволяє відновити якість при помірних рангах за рахунок додаткової складності.

Знаменник нормалізації фіксує кожен оновлений напрямок, а m контролює його величину. Це наближає DoRA до ступенів свободи, доступних під час повної налаштуваності, але за рахунок додаткових параметрів та операцій. Питання для корпорацій є емпіричним: чи зберігається покращення якості після додаткової складності у навчанні, обробці даних та керуванні реєстром?

Налаштування префіксу та запиту

Налаштування префіксу дозволяє створювати безперервні віртуальні токени, які спрямовують увагу, не торкаючись базових ваг. Це робить його компактним та підходящим для вузького керування, хоча він демонструє меншу ефективність, ніж LoRA, коли метою є граматика інструментів чи багатоетапна поведінка.

Sidecar чи об’єднання?

Адаптери Sidecar підходять для ізоляції користувачів чи завдань, швидкого скасування змін, маршрутизації типу A/B та забезпечення можливості аудиту. Об’єднання є доцільним лише для версій, які мають залишатися незмінними, після того, як точний чексум об’єднаного варіанту було оцінено та зареєстровано.

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

Об’єднання зменшує навантаження на адаптер під час виконання та може спростити розгортання, проте воно стирає чітку межу між базовою версією та її змінами. Зберігайте нероз’єднану версію, створюйте чексум для об’єднаної моделі та ніколи не об’єднуйте її з непідтримуваною «найновішою» базовою версією. Компактна конфігурація навчання виглядає так:

from peft import LoraConfig
from trl import SFTConfig, SFTTrainer
lora = LoraConfig(
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=["q_proj", "v_proj"],
    task_type="CAUSAL_LM",
)
trainer = SFTTrainer(
    model=base_model,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    peft_config=lora,
    args=SFTConfig(
        output_dir="runs/inv22041-sft-v3",
        assistant_only_loss=True,
        packing=True,
        max_length=4096,
    ),
)
trainer.train()

Серед важливих параметрів — це значення, більші за r=16 та lora_alpha=32. Параметр assistant_only_loss=True контролює межу втрат, фіксовані цільові модулі визначають область дії адаптера, а форматування має бути сумісним із масками шаблону чату.

Оптимізація переваг в офлайн-режимі

SFT спонукає модель до імітації. Оптимізація переваг — це спонукання до вибору одного з можливих варіантів. Уявімо два звіти щодо одного дослідження, обидва граматично та статистично коректні. Обраний звіт наводить підтверджуючі докази, озвучує свої припущення та на цьому зупиняється. Відхилений звіт додає непідтверджену причинно-наслідкову інформацію. Така пара дає сильніший сигнал, ніж ще одна ідеальна відповідь.

Погляд Бредлі-Террі

Моделі парної переваги зазвичай виходять з одного твердження: ймовірність того, що відповідь yʷ буде кращою за відповідь yˡ для вхідних даних x, дорівнює сигмоїді різниці у нагородах, σ[r(x, yʷ) − r(x, yˡ)]. Тут yʷ — це обрана відповідь, yˡ — відхилена, а r — неявна або явна нагорода. Важлива лише різниця між цими двома нагородами.

DPO

DPO оптимізує політику безпосередньо на парах переваг, пов’язуючи її з базовою політикою. Функція втрати дорівнює від’ємному лог-сигмоїду коефіцієнта beta помноженому на маржу; маржа — це різниця між лог-ймовірностями обраної відповіді за політикою та базовою політикою, віднята відповідна величина для відхиленої відповіді. У позначеннях πθ — це політика, яка піддається навчанню, π₀ — заморожена базова модель, а β визначає ступінь сили маржі переваг відносно базової політики.

Базовий чекпоїнт та значення beta вважаються метаданими випуску. Зміна будь-кого з них змінює цільову функцію, навіть якщо набір даних залишається ідентичним.

Приклад обчислення DPO

Припустимо, що поточна політика та базова політика дають такі лог-ймовірності для послідовностей:

• поточна політика, обрана відповідь: −8.0;
• базова політика, обрана відповідь: −9.0;
• текуща політика, відхилений звіт: −7.5;
• довідковий звіт, відхилений звіт: −7.0.

У порівнянні з довідковим звітом політика покращила обраний варіант на −8.0 − (−9.0) = 1.0. Для відхиленого варіанта зміна становить −7.5 − (−7.0) = −0.5. Маржа DPO дорівнює 1.0 − (−0.5) = 1.5. За умови beta = 0.2 значення beta помножене на маржу дорівнює 0.3, а втрата становить −log σ(0.3), приблизно 0.554.

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

Розрахунок також показує, чому посилання має значення. DPO не просто шукає ту відповідь, яка має вищу первинну ймовірність. У цьому прикладі відхилена відповідь все ще має вищу поточну лог-ймовірність (−7,5 проти −8,0), але політика рухається у правильному напрямку відносно посилання.

Довжина є частиною сигналу

Лог-ймовірність послідовності — це сума за всі токени, тому довші послідовності схильні накопичувати більше від’ємних лог-ймовірностей. Створення наборів даних та варіанти цілей вирішують цю проблему різними способами.

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

SimPO використовує середню лог-ймовірність, яка нормалізується з урахуванням довжини послідовності, та додає маржу цільової винагороди. Це зменшує залежність від окремої моделі-референту, але створює власні вимоги щодо марж та масштабування. Відсутність референту не означає відсутності гіперпараметрів.

Сила переваги та розбіжності

Бінарна пара вказує лише на те, що y_w виграла. Вона не вказує, чи була перемога очевидною чи незначною. По можливості зберігайте голоси оцінювачів, рівень впевненості, параметри оцінювання та розбіжності.

Розподіл голосів 3-2 не обов’язково має мати таку саму вагу під час навчання, як одностайне рішення 5-0. Зниження ваги неоднозначних пар також має свої недоліки, адже дійсні переваги меншості можуть зникнути. Перед вибором правила вагу перевіряйте за групою користувачів, мовою, географією та класом завдання.

Зміщення референту

Кажуть, що навчання з урахуванням уподобань має починатися з sft-v3, але виконувач DPO тихо завантажує sft-latest. Математична база для порівняння змінилась. Потрібно зберігати як політику ініціалізації, так і заморожену політику для порівняння, яка використовується під час обчислення втрати. Зазвичай вони є однаковими, хоча це не обов’язково, і для відтворюваності результатів потрібні як ідентифікатори, так і контрольні суми.

Сусідні методи

• IPO замінює необмежений підхід до обчислення втрати, заснованої на уподобаннях, на скінченну мету у форматі маржі, що допомагає уникнути переобучення DPO у випадку, коли б детерміністичні мітки призвели до цього.
• KTO навчається на прикладах, позначених як бажані чи небажані, окремо, тому не потрібні спарені результати.
• ORPO поєднує навчання за інструкціями та штраф за різницю шансів у одну мету, без окремої моделі для порівняння.
• SimPO не використовує референси, а базується на нормалізованій за довжиною лог-ймовірності послідовностей разом із цільовою маржою.

Жоден метод не усуває необхідність тестів на витік інформації чи базового підходу SFT. Тренування на основі уподобань може підвищити шанси на успіх, але при цьому погіршити калібрування, довжину відповіді, межі відмови чи якість роботи з меншинами.

Вибір у межах родини DPO

Робіть вибір на основі записів рішень, а не тенденцій:

• обирайте DPO для добре сформованих пар та стабільної референсної моделі, яку можна без проблем запустити;
• спробуйте IPO, коли детерміністичні чи з низьким рівнем шуму уподобання змушують DPO до надмірних марж;
• обирайте KTO, коли зворотний зв’язок надходить у вигляді окремих результатів „добре“ чи „погано“, а створення пар буде штучним;
• спробуйте ORPO, якщо єдина фаза, що поєднує SFT та навчання на основі уподобань, спрощує процеси.
• Спробуйте SimPO, якщо обмеження щодо пам’яті для моделі-орієнтира є найсуворішим, а нагороди, нормалізовані за довжиною послідовності, підходять для завдання.

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

from trl import DPOConfig, DPOTrainer
trainer = DPOTrainer(
    model=sft_model,
    ref_model=reference_sft_model,
    train_dataset=preference_dataset,
    args=DPOConfig(
        output_dir="runs/inv22041-dpo-v1",
        beta=0.2,
        max_length=4096,
        max_prompt_length=2048,
    ),
)
trainer.train()

Посиланням має бути контрольна точка, вказана у маніфесті виконання, а не те, що наразі називається реєстром моделей „найновішою“.

Класичний RLHF: модель нагород, PPO та RLAIF

У класичному RLHF одночасно використовуються три моделі. Політика генерує кандидатські відповіді, модель нагород оцінює їх, а PPO коригує політику, стримуючи будь-які зміни, які можуть її дестабілізувати.

PPO ґрунтується на об’єктивній функції з обмеженням. Коротко кажучи, вона бере очікуване мінімум значення добутку співвідношення ймовірностей на перевагу та добутку обмеженого співвідношення на перевагу, а потім віднімає штраф KL, який вимірює відхилення від контрольної точки. Символи означають наступне:

• ρₜ — це співвідношення ймовірностей між новою та старою політиками;
• Aₜ оцінює, чи дія, вибрана для аналізу, перевершує очікування;

ε визначає максимальний розмір оновлення політики;

штраф KL тримає політику близько до референтного стану.

Оберіть цю стек-структуру, коли якість є справді суб’єктивною, існує достатньо порівнянь для побудови моделі нагороди, а онлайн-оптимізація політики виправдовує додаткову операційну складність.

Навчання моделі нагороди

Модель нагороди зазвичай використовує ту саму парну функцію втрати Bradley-Terry: від’ємний лог-сигмоїд навченого балу для обраної відповіді мінус бал для відхиленої. Функція оцінювання rφ — це навчена скалярна функція з параметрами φ, яка навчається ранжувати обрані відповіді вище за відхилені.

Абсолютна величина нагороди сама по собі не має жодного значення. Оцінка 7 — це не „сім одиниць користі“, і лише порівняння в межах каліброваної дистрибуції є інформативними. Масштаб нагород може відрізнятися від однієї точки перевірки, набору даних чи класу запиту до іншої.

Розглядайте модель нагород як систему ранжування та вимірюйте:

• точність на парах даних, які не використовувалися під час навчання;
• калібрування за різницею оцінок;
• узгодженість із людськими мітками;
• стійкість до адверсарських вхідних даних;
• чутливість до довжини, форматування, кількості посилань та термінів, що визначають ідентичність;
• поведінку поза межами дистрибуції.

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

Обрізка PPO з використанням дійсних чисел

Припустимо, що стара політика дає ймовірність дії 0,20, а оновлена — 0,25. Співвідношення становить 0,25 / 0,20 = 1,25. За умови ε = 0,2 механізм обрізки обмежує це співвідношення до 1,20. Для позитивної переваги у 2:

• значення без обрізки — 1,25 × 2 = 2,50;
• значення після обрізки — 1,20 × 2 = 2,40;
• PPO бере менше з цих двох значень, а саме 2,40.

Оновлення все одно посилює дію, але не дозволяє отримати повну вигоду від значного зростання ймовірності.

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

Контролер KL

Показник KL стримує політику від занадто сильного відхилення від еталону. Коригована нагорода — це навчена нагорода за вирахуванням коефіцієнта βᴋʟ помноженого на розбіжність KL між політикою та еталоном. Якщо βᴋʟ занадто малий, політика може експлуатувати модель нагород, стати повторюваною або втратити якість мовлення. Якщо він занадто великий, процес навчання сповільнюється. Деякі системи адаптують значення бета, щоб тримати показник KL у цільовому діапазоні.

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

Модель актора-критика

Класичний PPO зазвичай вимагає шести компонентів. Це актор, який проходить навчання, а також заморожений знімок його попередньої версії, політика посилання, яка фіксує значення KL, та модель значень, яка виступає в ролі критика. До списку також належать модель винагороди та механізм реалізації. Вони можуть ділитися вагами чи інфраструктурою, залишаючись при цьому окремими об’єктами. Методи офлайн-вибору та методи без критика приваблюють тим, що вони усувають частини складної та схильної до збоїв розподіленої системи.

Не обирайте PPO лише тому, що це стандартний метод RLHF. Він заслуговує на своє місце тоді, коли оптимізація з використанням навченої, суб’єктивної метрики винагороди виправдовує додаткові зусилля з її запуску та підтримки.

RLAIF замінює деякі або всі людські ознаки вподобань на рішення ШІ, які керуються писаною конституцією. Це додає масштаб, але ніколи не замінює об’єктивної істини. Договір щодо обробки даних має враховувати запит до судді та конституцію, версію судді, яка використовувалась, ділянки, де судді не погоджуються, та моменти, коли втручається людина.

Найнебезпечнішою проблемою є маніпулювання нагородами: алгоритм знаходить поверхневу ознаку, яка дає високі бали, але не сприяє досягненню справжньої мети. Модель нагород для підприємств може вважати, що довші звіти, додаткові посилання чи часте використання фраз-захистів означають „кращість“. Адверсарські тести та прямі показники виконання завдань не повинні входити до складу обчисленої нагороди.

RLAIF та конституційні рішення

Конституція перетворює принципи на протокол оцінки. Для INV-22041 вона може доручити судді спочатку оцінювати авторизацію, потім підтвердження за посиланнями, статистичну достовірність, калібровану невизначеність та лаконічність.

Мітки, засновані на суддях, додають ще три елементи для відстеження:

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

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

Навчання з підкріпленням із перевірюваними винагородами

Якщо успіх можна перевірити механічно, модель навчення винагород може зовсім не знадобитися. SQL можна аналізувати та виконувати в умовах обмежень. Код можна запускати з використанням тестів. Статистичні висновки можна порівняти з очікуваними результатами та припущеннями.

GRPO

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

Уявіть собі вісім кандидатських планів SQL із винагородами, відсортованими від найгірших до найкращих: −0.3, −0.2, 0, 0, 0.5, 0.8, 0.8 та 1.0. Їхнє середнє значення становить 0.325, а стандартне відхилення приблизно 0.47. Кожен кандидат піднімається або опускається відносно своїх аналогів з групи, що усуває потребу у окремо навченому критику, хоча ефективність цього методу залежить від якості його винагород.

Для найкращої траєкторії нормалізована перевага становить приблизно (1,0 − 0,325) / 0,47, тобто близько 1,44. Для найгіршої – (−0,3 − 0,325) / 0,47, приблизно −1,33.

Точні числа залежать від того, чи використовується реалізація дисперсія всього набору даних чи вибірки, а також від того, як попередньо обробляються нагороди. Варто фіксувати ці деталі, оскільки вони впливають на масштаб градієнта.

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

Для INV-22041 композитна нагорода може вимагати наступного:

• чи є JSON коректним згідно зі схемою;
• чи є предикат орендаря;
• чи є SQL лише для читання;
• чи запит виконується в межах ліміту витрат;
• Отримані дані достатні для проведення оголошеного тесту;
• У звіті наводяться лише докази, які були надані агенту.

Проста сума з вагами дозволяє відмінним результатам у одному вимірі компенсувати серйозні порушення. Уявімо нагороду, яка складається з 0,3 від правильності, 0,2 від якості доказів, 0,2 від коректності SQL-запиту та 0,3 від стилю. Запит, спрямований до кількох користувачів, все одно може отримати позитивний бал, якщо відповідь та стиль є хорошими. Тому для забезпечення безпеки та авторизації потрібні суворі обмеження. У такій формі нагорода дорівнює нулю, якщо авторизація провалилась або сталося витік захищених даних. Інакше це є сумою з вагами нагород за правильність, інструменти та докази, віднятою від суми з вагами витрат.

У більш ризикованих умовах порушення може призвести до отримання негативної кінцевої нагороди замість нуля. Важливо те, що не відбувається компенсації, адже відмінні результати ніколи не можуть компенсувати несанкціонований доступ.

Зберігайте компоненти винагороди окремо, щоб їх можна було спостерігати. Оптимізатору потрібен один скаляр, але панель керування, яка окремо відображає правильність, авторизацію, дійсність інструментів, якість доказів, витрати та довжину, дозволяє виявити спроби маніпуляції з винагородою.

Нормалізація винагород може приховати масштаб бізнесу

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

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

Співвідношення політик та обрізка значень

Цілі у стилі GRPO зазвичай зберігають коефіцієнти важливості та механізм обрізання з PPO. Для кожного токена цей коефіцієнт ділить ймовірність нової політики на ймовірність старої, а ціллю є очікуване мінімум значення добутку цього коефіцієнта на перевагу та обрізаного коефіцієнта на перевагу, за вирахуванням члена KL. Перевагу можна визначати для кожної послідовності, тоді як коефіцієнти застосовуються до кожного токена, що є невідповідністю, яка частково спонукала до створення наступників на рівні послідовностей, таких як GSPO.

DAPO: більш стабільне навчання для довгих процесів міркування

DAPO використовує чотири практичні механізми. Межі обрізання розділені, групи вибираються динамічно, градієнт політики обробляється для кожного токена, а зразки, які виконуються занадто довго, обробляються безпосередньо. Динамічне вибірку видаляє групи, у яких усі нагороди ідентичні, оскільки вони не несуть жодного відносного сигналу.

Vanilla GRPO може зазнавати колапсу ентропії, нестабільності довгих ланцюгів чи пакетів, що містять виключно правильні або виключно неправильні групи, і саме тоді допомагає DAPO. Його принципи можна описати як чотири інженерні рішення проблем, що виникають під час навчання:

1. Clip-Higher. Верхні та нижні межі обрізки розділені, що дає корисним токенам з низькою ймовірністю більше простору для розвитку, не спричиняючи при цьому симетричної нестабільності скрізь.
2. Динамічне вибірку. Підказки, групи яких після вибірки є виключно правильними або виключно неправильними, відфільтровуються, оскільки їхні нормалізовані переваги не створюють значного контрасту.
3. Втрата політики на рівні токенів. Довгі відповіді обчислюються з урахуванням кількості токенів та не знецінюються через усереднення на рівні зразків.

Надто довге формування винагороди. Штрафи за довжину вводяться поступово, щоб уникнути різкого переходу, який створював би нестабільні градієнти біля максимальної довжини.

Кожен механізм вирішує окрему проблему. Не використовуйте цей абревіатурний термін як єдиний цілісний пакет, не перевіривши, яка саме проблема існує у вашій робочій навантаженні.

У корпоративному SQL-агенті динамічне вибірка дозволяє зосередити процес навчання на запитах, де лише деякі плани підходять для конкретного користувача. Механізм надто довгого формування запобігає тому, щоб модель витрачала тисячі токенів на обробку простого запиту, а Clip-Higher допомагає, коли корисні дії відновлення відбуваються з дуже низькою ймовірністю.

GSPO: послідовність як одиниця

GSPO обчислює співвідношення важливості та параметри обрізки для всієї послідовності, а не окремо для кожного токена. Це краще підходить до оцінки нагород на рівні послідовностей, і саме завдяки цьому GSPO допомагає стабілізувати процес навчання за допомогою методу RL у дуже великих моделях типу Mixture-of-Experts.

Урок полягає не в тому, що GSPO замінює GRPO. Урок у тому, що одиниця оптимізації має відповідати як нагородам, так і архітектурі. Коли результати діяльності оцінюються для кожної послідовності, а політика — це модель типу Mixture-of-Experts, GSPO заслуговує на пробну реалізацію.

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

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

RLOO

Метод REINFORCE Leave-One-Out використовує інші зразки в групі як базовий рівень для кожного зразка. Це оцінювач методу політики з градієнтом без критика та зручний критерій для порівняння методів, заснованих на групах.

При наявності G зразків зразок i отримує базовий рівень, що дорівнює середній винагороді інших G − 1 зразків, а його перевага — це його винагорода мінус цей базовий рівень. Не відбувається ділення на стандартне відхилення групи, як у нормалізації за z-очком. Оцінювач є простим та неупередженим за умов конструкції REINFORCE, хоча масштаб винагороди безпосередньо впливає на масштаб градієнта.

Візьмемо винагороди 1,0, 0,8 та 0,2. Для першого зразка базовий рівень за методом leave-one-out дорівнює (0,8 + 0,2) / 2 = 0,5, що дає перевагу 0,5. Базовий рівень для третього зразка становить (1,0 + 0,8) / 2 = 0,9, що дає значення −0,7.

RLVR та деталізована налаштування підсилення

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

Винагороди за результат перевіряють, чи є кінцева відповідь правильною, тоді як винагороди за процес оцінюють проміжні кроки. Контроль процесу дозволяє визначити місце збою, але оцінювачі кроків коштують багато та можуть надмірно обмежувати правильне міркування. У корпоративних агентах винагороди за процес забезпечують ефективність через спостережувані інтерфейси (вибір інструментів, авторизація, формування аргументів, надання доказів та передача даних) і ніколи не ґрунтуються на прихованій послідовності міркувань.

Винагорода за результат проти винагороди за процес

Нагорода у форматі SQL, яка оцінює лише результат, може бути простим індикатором, який дорівнює 1, коли результат збігається з очікуваним, і 0 в інших випадках. Це об’єктивно та недорого для обчислення, проте дозволяє моделі дійти відповіді за допомогою небезпечного або дорогого запиту.

Нагороди, що враховують процес, додають спостережувані інваріанти, які складаються з шести членів. Вони охоплюють чи є схема коректною, чи прив’язаний користувач, чи залишається запит тільки для читання, яку він коштує, чи правильний результат та чи були належним чином оприлюднені докази. Кожен член має бути перевіреною функцією видимих елементів. Оцінювання має враховувати дерево синтаксису SQL, рішення щодо авторизації, план виконання, повернений набір даних, запис статистичного тесту та посилання, але ніколи не приватні логічні послідовності мислення.

Тести градерів — це тести моделей

Створіть матрицю тестів градерів перед кожним запуском RL:

• Проходить відомий коректний шлях виконання;
• Неправильний „орендар“ зазнає невдачі;
• Умова, прихована у підзапиті, читається правильно;
• Коментар у SQL не може імітувати необхідну умову;
• Порожній результат відрізняється від помилки виконання;
• Дорогий картезіанський з’єднання зазнає невдачі;
• Сфабрикована цитата зазнає невдачі навіть тоді, коли кінцеве число правильне;
• Тайм-аут оцінювача призводить до невдачі;
• Неправильний вихід оцінювача не може стати позитивною нагородою.

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

Мислення має свою ціну

Лише критерій правильності може сприяти марному міркуванню, тому потрібно додати показник обмеженої вартості: винагорода дорівнює правильності мінус лямбда помножене на вартість міркувань Tₕ. Ця вартість може бути кількістю токенів для міркувань, мілісекундами чи нормалізованими ресурсами обчислювальної потужності, а λ визначає, скільки додатково коштує ретельне обмірковування. Штраф слід застосовувати лише після перевірки правильності та безпеки, інакше модель навчиться відповідати швидко, але неправильно.

Припустимо, два правильні варіанти виконання завдання отримують базову винагороду 1,0; один з них використовує 400 токенів для міркувань, а інший — 1 000. Якщо вартість токенів нормалізована до 1 000, а lambda = 0,1, то коротший варіант отримує 0,96 (зі знижкою 0,04), а довший — 0,90 (зі знижкою 0,10).

Отже, коротший правильний варіант виявляється кращим. Проте неправильна відповідь, що складається з 100 токенів, повинна пройти перевірку на правильність та не отримувати значення −0,01, щоб не конкурувати з правильними відповідями.

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

RL-агент з кількома етапами

Рішення моделі, результати роботи інструментів, зчитування з пам’яті та передача контролю агенту — усе це входить до складу корпоративної траєкторії. Зберігайте її переходи станів та оцінюйте кінцевий бізнес-контракт на додаток до локальних інваріантів.

Наприклад, модуль Enrichment може не отримати прямої винагороди за постановку уточнювального запитання. Його цінність проявляється тоді, коли модуль Data Sufficiency формулює правильний запит, а модуль Reporting уникає хибних причинно-наслідкових тверджень. Призначення кредитів не повинно стирати цю залежність.

Траєкторія — це журнал подій з типізацією

Представляйте процес реалізації не просто як текст чату. Кожен перехід має містити:

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

Ця форма дозволяє відтворювати процеси, аналізувати їх поза межами політики та точно присвоювати винагороди. Вона також запобігає тому, щоб процес навчання розглядав спостереження інструментів так, ніби їх створив асистент.

Ієрархічні винагороди

Для чотириетапного дослідження необхідно визначити місцеві винагороди за контракт та кінцеву бізнес-винагороду. Загальна винагорода дорівнює кінцевій винагороді R★ плюс зважена сума винагород за чотири етапи R₁ до R₄ — по одній для етапів збагачення даних, достатності даних, перевірки гіпотез та підготовки звіту, причому ваги для них становлять γ₁ до γ₄.

Місцеві винагороди прискорюють процес навчання, але вони також можуть вступати у конфлікт. Етап збагачення даних може максимізувати якість уточнень, ставлячи занадто багато запитань. Етап підготовки звіту може оптимізувати стислість, пропускаючи згадку про певні обмеження. Кінцева винагорода та жорсткі інваріанти мають переважати над місцевою зручністю.

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

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

Дистиляція: передача можливостей, а не копіювання моделі

Дистиляція перетворює складну поведінку „вчителя“ на простішу модель „учня“, яку легше впроваджувати.

Дистиляція Logit

Студента навчають так, щоб він дотримувався розподілу токенів від викладача зі зменшеною інтенсивністю. Значення втрати дорівнює квадрату температури помноженому на розбіжність KL між функціями softmax від викладача та студента; обидві функції обчислюються на основі логітів, розділених на температуру T. Квадратний множник зберігає масштаб градієнта. Вища температура дозволяє бачити відносні ймовірності токенів, що знаходяться поза першими місцями, тобто „темні знання“, які залишаються поза увагою при використанні жорстких міток.

Як змінюється температура

Уявіть собі викладача, який має логіти 8, 4 та 2 для трьох кандидатських токенів. При T = 1 функція softmax концентрує майже всю ймовірність на першому токені. При T = 2 ефективні логіти знижуються до 4, 2 та 1, і розподіл стає більш рівномірним, тож студент розуміє, що перший токен є найімовірнішим, а також те, що другий токен має більші шанси, ніж третій.

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

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

Поєднання жорстких та м’яких цілей

Поширеною метою є поєднання двох чинників: ваги для втрат від SFT та ваги для втрат від дистиляції. Жорсткі мітки зберігають відомий правильний результат, а м’які ймовірності вчителя передають відносні переваги. Ці дві ваги визначають баланс.

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

Послідовнісна та дистиляція в межах політики

Послідовнісна дистиляція тренується на результатах, створених «вчителем». Вона проста, але учень бачить лише розподіл станів «вчителя».

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

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

Фільтри для стиснення послідовностей

Результати, створені вчителем, є синтетичними даними для навчання, і вони потребують таких самих механізмів контролю, як і дані, написані людьми:

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

Вибір найкращих екземплярів може підвищити якість синтезу, але звужує різноманітність та може посилити упередження селектора. Зберігайте статистику генерації та відбору, щоб можна було відновити розподіл даних учня.

Цикл дистиляції за правилами політики

Цикл дистиляції за правилами політики складається з п’яти кроків:

1. Учень генерує дані за допомогою своєї поточної політики.
2. Вчитель оцінює ці стани або надає для них розподіли токенів.
3. Небезпечні чи недійсні траєкторії видаляються.
4. Учень оновлює свої моделі на основі залишених станів.
5. Експертиза перевіряє можливості та зміщення моделі.

Цей цикл спрямований на усунення реальних помилок учня. Він вимагає більше ресурсів, ніж статичні дані вчителя, та може успадкувати нестабільність від постійно змінюваного розподілу даних учня. Фіксуйте ідентичність вчителя та робіть знімки результатів роботи учня після кожної ітерації.

Дистиляція — це не спекулятивне декодування

Дистиляція навчає „учня“ апроксимувати „вчителя“. Спекулятивне декодування використовує менший проект на етапі висновків та змушує цільову модель перевіряти запропоновані токени. „Учень“, отриманий шляхом дистиляції, може виконувати роль проекту, але ці дві техніки прагнуть до різних цілей.

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

Контракт на корпоративну дистиляцію

Чітко визначте кожен з наступних елементів:

• модель „вчителя“ та версію API;
• параметри генерації та середовище інструменту;
• версію запиту чи системного пакету;
• правила фільтрації та оцінки;
• базу „учнів“, токенізатор та лінійку адаптерів;

Оцінка рівня безпеки як для вчителя, так і для учня;

Права на використання даних, що стосуються робіт вчителя.

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

Які фронтальні моделі змінилися під час навчання та доробки

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

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

DeepSeek-R1

DeepSeek-R1 розмістив метод посилення навчання в центрі адаптації міркувань. R1-Zero починався з попередньо навченої базової моделі та застосовував метод посилення навчання, не навчаючи її спочатку жодних послідовностей міркувань, написаних людиною. Експеримент мав на меті перевірити, чи можуть міркування виникати з оптимізації результатів, а не з копіювання підготовлених слідів міркувань.

Основним методом була оптимізація відносної політики групи (GRPO). Політика генерує групу кандидатів на виконання певного завдання, і кожен з них отримує нагороду. Перевага полягає у порівнянні з групою — а саме у різниці між нагородою та середнім значенням групи, доданому до стандартного відхилення групи плюс ε; при цьому не використовується окремо навчений модель оцінювання. Відповіді, які перевершують своїх конкурентів, отримують позитивну перевагу, а слабші — негативну. Відмова від критика дозволяє скоротити використання пам’яті та обчислювальних ресурсів, зберігаючи при цьому корисний сигнал для навчання.

GRPO особливо добре працювала там, де можна було автоматично перевірити правильність: перевірка відповідей у математиці, компіляція та тести коду, а також перевірка формату структурованих відповідей. Модель навчалася на об’єктивних результатах, без необхідності використання етикеток людських уподобань для кожного кроку міркувань.

R1-Zero показав, що такі поведінки, як перевірка, зворотний пошук та витрачання більше обчислень на складні задачі, можуть виникати завдяки RL. Він також виявив обмеження чистого навчання на основі результатів. Міркування можуть стати важкими для розуміння, непослідовними у мовленні або орієнтованими на винагороду без формування витонченої відповіді.

Повний підхід DeepSeek-R1 подолав ці обмеження за допомогою поетапної програми навчання. Він починається з зрозумілих прикладів для початкового етапу, переходить до RL для міркувань, потім до вибіркового зразкування, далі до поєднання міркувань та загального SFT, і завершується RL для узгодження. Дані для початкового етапу забезпечили зрозумілий стиль міркувань, RL для міркувань розширив можливості за межі імітації, вибіркове зразкування зберегло кращі самостійно створені траєкторії, SFT на даних міркувань та загальних даних уніфікував поведінку, зберігаючи широку корисність, а останній етап RL покращив корисність та безпеку.

Сама GRPO не була чимось новим. Важливим було те, як були послідовно використані методи керованого навчання, перевірюваного RL, самостійно створених даних та фінальної налаштуваності.

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

Qwen3 та фузія режимів

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

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

GSPO та ступінь деталізації оновлення

GSPO (Group Sequence Policy Optimization) змінив ступінь деталізації оновлення політики. Методи на рівні токенів зазвичай обчислюють та обмежують коефіцієнти важливості окремо для кожного токену, навіть якщо нагорода охоплює всю відповідь, що може призводити до несуворісних оновлень у межах однієї генерованої послідовності.

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

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

Kimi K2: стабільність та агентні траєкторії

Kimi K2 використовує методи стабілізації під час навчання, які роблять дуже масштабні процеси оптимізації більш надійними. MuonClip поєднує оптимізацію матриць у стилі Muon із механізмами контролю, які запобігають нестабільному зростанню ваг. QK-Clip стежить за поведінкою механізму уваги та вибірково обмежує проблемні проекції запитів та ключів, коли їхні логіт-значення стають екстремальними.

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

Післянавчальний процес Kimi K2 також ґрунтується на агентних траєкторіях: програмуванні, виклику інструментів, обробці спостережень та виконанні багатокрокових завдань. Під час навчання використовуються послідовності дій із зворотним зв’язком від середовища, а не лише пари запитання-відповідь. Типовий шлях починається з завдання, переходить до вибору інструменту, генерації аргументів, отримання зворотного зв’язку про виконання, відновлення після помилок та підтвердження результату.

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

Моделі взаємодії викладач-студент у Meta

Meta’s Muse Spark та Muse Glimmer ілюструють більш повний процес взаємодії вчителя та учня. Вчитель може створювати кінцеві відповіді, проміжні міркування, багатомодальні аналізи, рішення щодо інструментів та стратегії виправлення помилок, але жоден з цих елементів не стає матеріалом для навчання, доки не пройде фільтрацію щодо правильності, безпеки, походження, різноманітності та релевантності.

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

• Дистиляція логітів передає розподіл ймовірностей вчителя, а не лише обраний ним токен. Це забезпечує передачу інформації про ймовірні альтернативи та відносну впевненість, яку метод навчання з жорсткими мітками відкидає.
• Процес навчання посередині дозволяє студентові опрацьовувати дані з довгим контекстом та агентські дані ще до вузької налаштування за інструкціями, тож ці навички потрапляють до його більш широкого представлення та не залишаються як тонкий шар, доданий наприкінці.
• Метод дистиляції знань у межах політики усуває основну слабкість звичайної дистиляції. Навчаючись лише за траєкторіями вчителя, студент опановує стани вчителя, проте під час інференсу стикається зі станами, створеними власними помилковими рішеннями. Якщо студент створює траєкторію, а вчитель дає поради щодо цих станів, розбіжності зменшуються.
• Потім машинне навчання з підкріпленням посилює ті поведінки, які мають вимірювані результати.

Разом ці кроки перетворюють процес дистиляції на багатоетапну програму передачі можливостей замість однієї процедури стиснення.

Тепер видно повну схему роботи: дані під керуванням для визначення поведінки, перевірювана методика машинного навчання для імітації, синтетичні траєкторії для охоплення необхідних діапазонів, блок оптимізації, який відповідає рівню деталізації винагороди (ціла послідовність), а також процес дистиляції на власних станах „учня“ з метою передачі його здібностей моделям, які можна використовувати в практиці.

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

Навчання – це процес випуску моделей

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

Ідентичність реєстру

Як мінімум, необхідно зареєструвати:

• чексуми базової та базової для порівняння моделей;
• дайджести набору даних та його трансформацій;
• справку про розділення та звіт про забруднення;
• ціль, оптимізатор, насіння, гіперпараметри та цільові модулі;
• дайджести коду та контейнера;
• апаратне забезпечення та числову точність;
• версії оцінювача, моделі нагород, судді та політики;
• звіт про оцінку, схвалення, власника, термін дії та ціль для скасування.

Оцінка вимагає мінімальних критеріїв та порівнянь

Застосуйте два критерії:

1. Абсолютні пороги. Швидкість витоків дорівнює нулю у захищених модулях, коректність схеми інструментів перевищує встановлений поріг, ступінь прив’язки орендаря становить 100%, а критерії відхилення та безпеки також задоволені.
2. Відносне покращення. Кандидат має показати кращі результати, ніж поточний рецепт виробництва, щодо цільового дефекту, при цьому всі пороги мають залишатися задоволеними.

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

Не зводьте якість корпоративних рішень до однієї середньої величини

Нехай Mₖ — це метрика для оцінки сегмента k. Зважений бал S дорівнює сумі ваг кожного сегмента, помножених на їхні метрики, причому сума ваг дорівнює 1, що дозволяє чітко узагальнити результати. Однак зважена середня значення дозволяє компенсувати недоліки, тож значний приріст у стандартних англійських звітах може приховувати серйозний відступ у рівні ізоляції користувачів або у мовах із обмеженою кількістю даних.

Фільтруйте за лексикографічним порядком у такій послідовності:

1. мінімальні стандарти безпеки, конфіденційності та авторизації;
2. мінімальні вимоги щодо збереження функціональності;
3. покращення результатів у цільовій задачі;
4. обмеження щодо витрат та затримок;
5. загальний ранг серед кандидатів, які пройшли всі попередні фільтри.

Це відображає принцип проектування винагород: умови, які є непереговорними, не можна компенсувати стилем чи продуктивністю.

Інтервали впевненості та незначні прирости

Шум вибірки може пояснити спостережувану різницю в точності. Для бінарної метрики з пропорцією p̂ серед n незалежних елементів стандартна похибка приблизно дорівнює квадратному кореню з p̂(1 − p̂) / n. При p̂ = 0,90 та n = 100 вона становить близько 0,03, що робить підвищення на одну позицію непереконливим.

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

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

Набір тестів на забування

Цільова ефективність не повинна стирати загальні здібності. Зберігайте фіксований набір елементів, які охоплюють:

• слідування інструкціям;
• межі безпеки та відмов;
• поведінку у різних мовах;
• вибір відповідного інструменту та форматування його виклику;
• знаходження фактів у довгих контекстах;
• калібровану впевненість та знання моменту, коли потрібно утриматися;
• завдання з суміжних сфер, які не були ціллю;
• адверсарські та приватність-орієнтовані тести.

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

Два рівні квантування

Коли використовується QLoRA або більш пізнє квантування під час роботи, оцінюйте двічі:

1. Блок контролю навчальних артефактів використовує базову версію разом із адаптером під час оцінки точності на етапі розробки.
2. Блок контролю продуктивних артефактів використовує те, що використовується під час роботи в продакшені: саме об’єднану версію чи версію типу sidecar, ядра часу виконання, процедури квантації, токенайзер та шаблони чату.

Перший метод дозволяє з’ясувати, чи навчання справді навчило систему потрібній поведінці. Другий показує, чи збереглася ця поведінка після розгортання.

Канарки та відкат

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

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

Арифметика канарок

Припустимо, що критичні збої історично трапляються з частотою p. При n незалежних запитах типу «канарка» ймовірність того, що буде зафіксовано принаймні один такий збій, становить 1 − (1 − p)ⁿ. При частоті збоїв 1% та 100 запитах це дорівнює 1 − 0.99¹⁰⁰, що становить майже 63,4%, тож невелика кількість «канарок» може легко проігнорувати рідкісні, але серйозні збої.

Дизайн механізму «канарок» слід ґрунтувати як на відсотках, так і на ризиках. Навмисно використовуйте для тестування ризиковані шляхи виконання, незвичайні мови, дуже довгі контексти, запити, що знаходяться на межі дозволів, запити, які не повертають жодних даних, та окремі групи користувачів. Метод тіньової оцінки збільшує охоплення без побічних ефектів, але не може виявити всі ефекти взаємодії реальних дій.

Тригери для запуску та скасування

Визначте тригери ще до початку роботи «канарки»:

• абсолютне порушення політики означає негайну зупинку;
• Витік захищених даних означає зупинку процесу обробки інциденту та збереження доказів;
• Помилка інструменту або затримка, що перевищує встановлений поріг, означає призупинку та діагностику;
• Статистично достовірна регресія у цілі означає скасування попередніх змін;
• Незрозуміла зміна показників винагороди чи оцінок суддів означає призупинення процедури підвищення;
• Відсутність телеметричних даних означає невдалий результат, оскільки неможливо оцінити реліз.

Ніхто не повинен вигадувати критерії прийняття, дивлячись на панель керування. Це перетворює процес управління на переговори під тиском розгортання.

Зберігайте записи про відхилені виконання

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

• Виконання qlora-v4 підвищило дійсність інструменту на три пункти;
• Проте відповіді, засновані на цитатах, були на п’ять пунктів менш точними після застосування квантизації даних;
• система відхилила їх;
• детальніше досліджуючи ситуацію, команда пов’язала це погіршення з прогнозами результатів, які погано реагують на квантизацію;
• у виробництві продовжував використовуватися dpo-v1.

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

release_id: inv22041-reporting-dpo-v1
base_sha256: "…"
reference_release: inv22041-sft-v3
adapter:
  method: lora
  rank: 16
  alpha: 32
dataset_digest: "sha256:…"
grader_version: sql-cage-12
policy_version: p-31
gates:
  tenant_binding: 1.0
  protected_leak_rate: 0.0
  tool_json_validity_min: 0.98
canary:
  mode: shadow
  duration_hours: 72
rollback_to: inv22041-sft-v3

У маніфесті вказано ідентифікатор версії, контрольну суму базового варіанта, базову версію для порівняння (попередню версію SFT) та деталі адаптера. Він достатньо короткий, щоб його можна було переглянути, і достатньо деталізований, щоб підтвердити зроблені твердження.

Покрокове керівництво: INV-22041

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

1. Визначте дефект. Карта регіонів зберігається в керованій пам’яті, поточні дані про продажі — у семантичному шарі, а права доступу — у політиці часу виконання. Навчання спрямоване на граматику інструментів, механізми відновлення, посилання та коректне відхилення запитів.
2. Створіть план обробки даних. Скомпілюйте 4 200 прикладів SFT разом із 1 100 записами багатоетапного відновлення, додайте інформацію про походження даних, видаліть проєктні фінансові документи та забезпечте, щоб contamination_rate = 0 у всій комплектації для випуску.
3. Сконструюйте SFT. Навчіть адаптер LoRA з рангом 16 та альфою 32 на вибраних проекціях уваги. Рівень успішності обробки за допомогою інструментів підвищується з 0,71 до 0,94, тоді як загальні показники функціональності залишаються стабільними.
4. Додайте дані про переваги. Оцінювачі віддають перевагу стислим звітам з посиланнями перед більш плавними, але не підтримуваними варіантами. Алгоритм DPO працює з параметром beta = 0,2 на основі фіксованого джерела SFT, досягаючи рівня успішності 0,78 при нульовому рівні витоків даних.
5. Використовуйте перевірені методи RL лише там, де це обґрунтовано. На етапі оцінки достатності даних необхідно створити по вісім траєкторій роботи SQL-запитів та інструментів для кожного запиту та оцінити їх за ступенем прив’язки до умов завдання, достовірністю, можливістю виконання, витратами та достатністю даних. GRPO покращує процес відновлення, а DAPO використовується, якщо групи з ідентичними нагородами та довгі результати послаблюють сигнал.
6. Перевірте відповідність архітектури. Якщо студент є моделлю типу MoE, чиї коефіцієнти важливості на рівні токенів ускладнюють роботу RL, порівняйте GSPO з аналогічним інструментом оцінювання та приблизною кількістю ресурсів.
7. Використовуйте метод дистиляції, коли це вимагають економічні фактори. Перенесіть спостережувану поведінку інструментів у меншу локальну модель студента, використовуючи результати роботи вчителя та дані про стан системи, а потім повторіть тести на точній квантованій версії моделі.
8. Оприлюдніть рецепт. Фіксуйте кожен компонент, проводьте тестування протягом 72 годин, підвищуйте рівень лише тоді, коли будуть досягнуті абсолютні мінімуми та відносні показники, а також залиште один навмисно відхилений результат у записах аудиту.

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

Дерево невдач: де йдуть не так хороші проекти навчання

Постійною проблемою є оптимізація проксі без наявності корпоративного контракту:

• Висока точність навчання може приховувати спотворені результати оцінювання.
• Переваги у порівняннях можуть походити від довших відповідей чи витоків цитат.
• Крива винагород може відображати зловживання з боку оцінювачів.
• Учні переймають небезпечні звички вчителя разом із його навичками.
• Адаптер, який здається бездоганним, може зламатися під час роботи в квантованому середовищі, яке насправді використовується.
• Повернення до попереднього стану може зазнати невдачі, якщо воно відновлює ваги, але залишає решту елементів без змін.

Мета навчання доводить лише те, що відбулася оптимізація. Докази релізу — це єдине, що може показати покращення в корпоративній системі.

Доведення концепції проти корпоративної адаптації

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

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

Дванадцять правил роботи

1. Зберігайте постійні зміни даних у сховищах та стабільну поведінку в адаптерах.
2. Вибирайте алгоритм згідно з контрактом нагляду та винагород, який у вас насправді є.
3. Фіксуйте версію моделі-орієнтира, інструменту оцінки, судді та політики.
4. Для SFT у чаті використовуйте функцію втрат, призначену лише для асистента, та перевіряйте межі пакування даних.
5. Віддавайте перевагу методу PEFT, вважаючи повне налаштування моделі винятком, який потребує письмового обґрунтування.
6. Навчання з використанням QLoRA не означає роботи з квантованою моделлю.
7. Для методу DPO потрібен фіксований орієнтир та параметр beta, а методи без орієнтира все одно потребують базових значень.
8. Проводьте модульні тести кожної перевіряємої винагороди щодо адверсарських траєкторій.
9. Використовуйте DAPO або GSPO тому, що виявлена несправність це виправдовує, а не тому, що вони новіші.
10. Процес дистиляції передає як поведінку, так і способи виникнення несправностей, тому оцінюйте «учня» окремо.
11. Зберігайте рівень забруднення на нулі для наборів коду, які визначають випуск.
12. Зареєструйте повний алгоритм роботи та протестуйте процедуру скасування змін перед їх запровадженням.

Контракти, а не драбина

Адаптація в корпоративних умовах — це не підйом від SFT до все більш модних абревіатур. Це ланцюг контрактів.

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

Якщо ці договори сформульовані правильно, LoRA, DPO, GRPO, дистиляція та будь-які інші методи після навчання стають корисними інженерними інструментами. Без них навіть гарна крива винагород є лише дорожчою демонстрацією.