Навчання власного судді LLM: від PandaLM та JudgeLM до Prometheus
Як створюються деталізовані моделі оцінювачів — від даних та рубрик до контролю упереджень та метаоцінки, а також практичний посібник з навчання судді LLM для конкретної галузі.
Джерела: Finetuning LLM Judges for Evaluation
Як тільки модель мови може писати есе, відповідати на запити підтримки та узагальнювати контракти, запитання „Чи є цей результат якісним?“ вже не має простої відповіді. Людський огляд є золотим стандартом, але він повільний та дорогий; класичні метрики перекриття ледве можуть вимірювати якість, а спонукання проприєтарної моделі оцінювати результати ефективне лише тоді, коли ваші критерії схожі на те, що вже знає ця модель. У цьому посібнику розглядаються дослідження щодо доопрацьованих суддів у вигляді LLM, відкритих моделей, навчених спеціально для оцінювання та критики інших моделей, а також наводиться конкретний план, який ви можете скористатися для створення інструменту оцінки для вашої сфери.
Чому оцінка сучасних LLM така складна
Дві особливості сучасних моделей фундації ускладнюють їх оцінку. Перша — це обсяг функцій: від однієї моделі очікують, що вона буде писати код, перекладати текст, міркувати, дотримуватися правил форматування, бути безпечною та дружелюбною, причому кожна з цих рис потребує окремого вимірювання. Друга — це відсутність чітких меж. Для майже будь-якого запиту існує велика кількість прийнятних варіантів відповідей, які відрізняються формулюванням, структурою, довжиною та акцентами, тому неможливо просто перевірити, чи результат збігається з очікуваним рядком. Навіть належне вимірювання однієї з цих здібностей є проблемою для досліджень, а у продакшн-моделях їх десятки.
Найнадійніші сигнали все ще надходять від людей, які читають результати та оцінюють їх. Проблема полягає у тому, що людські оцінки супроводжуються похибками, є дорогими та повільними у зборі, що не відповідає темпам розробки моделей. Команда, яка кілька разів на тиждень перенавчає або знову надсилає запити до моделі, не може чекати на нову кампанію анотацій після кожної зміни. Певний рівень людської оцінки залишається незамінним, але його потрібно доповнити чимось, що може масштабуватися.
Ця потреба призвела до появи концепції LLM-as-a-Judge, описаної у статті «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena»: ви запускаєте потужну пропрієтарну модель для оцінки результатів роботи іншої моделі. Цей підхід тепер широко використовується у дослідженнях, але має свою слабкість. Продукти, призначені для конкретних галузей, часто звертають увагу на дуже детальні критерії — наприклад, чи містить медичний огляд інформацію про дозування чи чи посилається юридична відповідь на правильну статтю — а універсальна модель може не оцінювати це надійно. У такій ситуації наступним логічним кроком є навчання спеціалізованого «судді», і саме розуміння того, як це зробити ефективно, є метою решти цієї статті.
Інструментарій оцінки: люди, метрики та судді на основі моделей
На практиці команди поєднують людську оцінку з автоматичними метриками. Люди надають остаточну інформацію щодо якості; автоматичні метрики забезпечують швидкість. Оскільки автоматичні оцінки є лише наближенням до думок людей, їх постійно порівнюють із періодичними людськими оглядами, але між цими оглядами можна порівняти набагато більше варіантів моделей, ніж люди змогли б переглянути.
Автоматична оцінка сучасних LLM здебільшого належить до двох категорій. Перша — це оцінка у стилі тестів на базі показників ймовірності чи перплекситету, яка охоплює більшість традиційних тестів з обробки природної мови, таких як MMLU та BIG-bench. Вони функціонують приблизно як тести з вибором відповіді, які перевіряють те, що знає модель. Вони корисні, але мало що говорять про те, наскільки добре модель може написати довгу, стилістично відповідну відповідь на відкрите запитання.
Для довгих, відкритих відповідей насправді існує лише два шляхи: або люди оцінюють відповіді, або це робить потужна модель. Враховуючи витрати першого підходу, оцінка за допомогою моделей стала стандартною. Вона не потребує контрольної відповіді, її легко налаштувати, і вона ефективно справляється з різноманітними завданнями. У наступних розділах ми по черзі розглядаємо кожен інструмент цього набору засобів, починаючи з людського аспекту, оскільки все інше порівнюється з ним.
Людська оцінка є основою істини, хоча й не ідеальною
Люди можуть помітити, що насправді має значення у відповіді: чи вона достатньо коротка, креативна, має правильний тон чи є чутливою до культурних особливостей. Саме тому людський огляд залишається основою для оцінки. Оцінювачі можуть бути з різних джерел. Ви можете залучити громадськість для голосування, як це робить Chatbot Arena, найняти спеціалізовану команду чи, як це робив проєкт Alpaca, дозволити самим розробникам моделей оцінювати результати. Використання людей як стандарту істинності не означає, що їхні оцінки є бездоганними. На практиці вони часто є непослідовними, складними у створенні та схильними до упереджень.
Узгодженість та калібрування
Навіть завдання, які здаються простими, часто призводять до дивовижно низького рівня згоди між анотаторами. Його можна кількісно оцінити за допомогою простого показника відповідності або статистики з корекцією на випадковість, такої як каппа Коена (два оцінювачі), каппа Флейсса (багато оцінювачів) чи альфа Кріппендорфа (гнучкий підхід при відсутності міток та різних типах шкал). Корекція на випадковість має значення: якщо 80 відсотків відповідей є „хорошими“, два оцінювачі, які позначають усе як „хороше“, будуть згоджуватися майже завжди, не навчаючись нічого нового.
Коли рівень згоди низький, рішенням є калібрування, тобто навчання анотаторів виконувати завдання однаково. Типовим етапом є сесія перегляду, під час якої оцінювачі розглядають елементи, щодо яких у них були розбіжності, обговорюють ситуації та доходять до спільної інтерпретації. Результати цих обговорень потім записуються назад у інструкції до завдання, щоб наступна партія роботи починалася з більш чітких основ.
Керівні принципи написання, які дійсно використовуються
Керівні принципи є письмовим договором для виконання завдання з анотування. Як мінімум, вони повинні вказувати, що оцінюється — тобто критерії — та як слід застосовувати кожен з них. Хороші керівні принципи поєднують інструкції у прозовій формі з прикладами правильних та неправильних міток, і анотатори користуються ними протягом усього процесу роботи, а не читають їх лише один раз. Вони роблять мітки більш послідовними та значно скорочують час адаптації нових оцінювачів. Корисний тест: якщо анотатору потрібні знання, яких немає в документі, щоб правильно позначити елемент, документ є неповним.
Інструкції також слід розглядати як динамічні документи. Команда InstructGPT, наприклад, описувала постійну корекцію своїх інструкцій для маркування протягом усього проекту відповідно до отриманих відгуків, змін у полях метаданих та розуміння цільової аудиторії, а також виправлення уривків, які виявлялися заплутаними чи суперечливими. Такий досвід є типовим. Завдання, які здаються очевидними, зазвичай приховують багато суб’єктивності, і вона проявляється лише тоді, коли група людей намагається дійти згоди щодо сотень реальних прикладів.
Контроль згоди з часом
Великі інвестиції здійснюються на початковому етапі: розробка критеріїв, налаштування оцінювачів та поступове вдосконалення процесу до досягнення прийнятної згоди. Лише тоді людські оцінки стають надійним показником якості моделі. Однак робота тут не закінчується. Згода може знижуватися через буденні причини: приєднуються нові оцінювачі, досвідчені поступово відхиляються від написаних правил, або самі інструкції змінюються. Постійний моніторинг згоди між оцінювачами, наприклад шляхом надсилання частини елементів кільком оцінювачам, — це єдиний спосіб виявити це до того, як воно потайки пошкодить ваші дані оцінювання.
Метрики, засновані на контрольних даних, та причини їхньої недієздатності
Ранні покоління моделей мови зазвичай оцінювалися за такими показниками, як ROUGE для стиснення тексту та BLEU для перекладу. Обидва вони ґрунтуються на контрольних відповідях: вони порівнюють результат роботи моделі з ідеальною відповіддю, переважно шляхом підрахунку перекриваючихся n-грам, та надають бали результатам, які містять більше слів та фраз із цим контрольним варіантом.
З покращенням моделей ці показники втратили свою актуальність. Дослідження результатів роботи великих мовних моделей показали, що такі показники слабко корелюють із людськими уподобаннями, настільки, що жоден із класичних показників не дозволяє точно оцінити судження людей. Вони залишаються в ужитку переважно тому, що їх можна обчислити майже безкоштовно. Якщо у вас вже є контрольні відповіді, вони все одно можуть слугувати швидкою перевіркою, наприклад, для виявлення регресії, коли модель раптово починає генерувати порожній або неактуальний текст.
Основна причина їхньої невдачі — структурна. Метрика, заснована на посиланні, по суті є складним алгоритмом фазового збігу щодо однієї-єдиної мети. Сучасні моделі є відкритими: один запит дозволяє отримати багато однаково хороших відповідей, які можуть мати мало спільних n-грамів із посиланням. Оцінка, яка винагороджує схожість із певною конкретною відповіддю, не може відобразити всю сукупність допустимих варіантів відповідей, тому вона карає абсолютно гарні парафрази та може винагороджувати правильний за змістом текст, який випадково використовує лексику посилання, хоча й є неправильним.
Оцінювачі LLM за запитом
Недоліки метрик перекриття спонукали галузь до більш гнучкої оцінки, заснованої на моделях. Найпопулярнішою формою є LLM-as-a-Judge: потужна модель отримує завдання оцінювати результати роботи іншої моделі. Дослідження MT-Bench та Chatbot Arena показали, що цей підхід добре узгоджується з людськими уподобаннями, для реалізації його достатньо лише добре сформульованого запиту, він природно обробляє відкриті результати та може враховувати багато різних критеріїв. У цих дослідженнях його представили як масштабовану, пояснювану апроксимацію людських уподобань, отримати дані про які інакше є складно та дорого.
У решті цієї статті термін „LLM-as-a-Judge“ означає конкретно використання готової пропрієтарної моделі, такої як GPT-4o чи Gemini 1.5, під впливом запиту, тоді як „фінтюнірований суддя“ — це модель, яку ви самостійно навчаєте для оцінки. Для отримання більш загальної інформації про суддів, які працюють під впливом запиту, корисними джерелами є практичний посібник з створення суддів, які сприяють прийняттю бізнес-рішень, аналіз ефективності оцінювачів на основі LLM та огляд досліджень у галузі LLM-as-a-Judge. Якщо ви вже використовуєте суддю, який працює під впливом запиту, у продакшені, аспекти його експлуатації розглянуті у нашому посібнику з керування LLM-as-a-Judge як живою системою продакшену.
Парний та точковий оцінювання
Існує два основні способи отримання вердикту від судді:
- По парах: суддя бачить запит та дві кандидатські відповіді та обирає кращу (часто існує опція нічиєї).
- По окремим пунктам: суддя бачить запит та одну відповідь та присвоює оцінку, зазвичай за шкалою Лікерта від 1 до 5.
Оцінювання по окремим пунктам також називається прямою оцінкою або оцінюванням з однією відповіддю. У будь-якому з цих форматів можна використовувати довідкові матеріали, додавши до запиту судді відому правильну відповідь, щоб суддя міг порівнювати з нею, а не покладатися лише на власні знання. Поширеним прикладом такого судді є AlpacaEval — табло лідерів, яке використовує LLM-as-a-Judge для прогнозування людських уподобань між результатами моделей та публікує всі свої запити для оцінювання, включаючи попередні версії.
Вибір формату оцінювання
Жодна система налаштувань не підходить у всіх випадках; правильний вибір залежить від конкретного застосування. Порівняння пар видає більш стабільні результати, адже порівнювати дві речі легше, ніж оцінювати щось на абсолютній шкалі. Недоліком є упередження, пов’язане з позицією — схильність віддавати перевагу тому варіанту, який з’являється першим (або другим), а також менша масштабованість: результати порівняння пар повідомляють лише про те, як результати взаємно ранжуються, а для порівняння багатьох систем потрібно багато таких пар. Оцінювання кожного результату окремо є більш універсальним, оскільки кожен результат отримує власну оцінку, яку можна зберегти, спростувати та порівняти пізніше. Водночас це ускладнює роботу оцінювача, адже йому доводиться ґрунтувати оцінку виключно на власному розумінні якості. Надання контрольної відповіді — поширений спосіб зробити оцінювання кожного результату більш надійним.
Природа критерію також має значення. Об’єктивні властивості, такі як фактичність чи відповідність джерельному документу, зазвичай є бінарними: відповідь є вірною або ні. Питання про те, яка з двох відповідей є „більш вірною“, погано сформульоване. Суб’єктивні критерії, такі як корисність, тон чи загальні уподобання, дозволяють робити відносні оцінки, адже людям та моделям легше та простіше порівнювати їх, ніж ставити абсолютні оцінки. Розумним стандартом є поетапна оцінка — часто бінарна — для об’єктивних перевірок та порівняння пар варіантів для оцінки суб’єктивної якості.
Упередження, які має кожен суддя
Якого б типу судді ви не використовували, навченого за допомогою запитів чи доопрацьованого, кілька систематичних упереджень постійно з’являються, і більшість методів доопрацювання, описаних далі в цій статті, призначені для їх усунення. До читання далі корисно знати їх назви:
- Упередженість щодо позиції: у режимі парного оцінювання суддя віддає перевагу першому чи другому варіанту незалежно від змісту.
- Упередженість щодо об’єму чи довжини: довші, більш детальні відповіді отримують вищі оцінки, навіть якщо додатковий текст нічого не додає.
- Упередженість щодо самопідвищення: суддя віддає перевагу результатам, написаним ним самим або моделями з тієї ж сім’ї.
- Упередженість щодо знань: суддя не може оцінити правильність у темах, які він добре не знає, і може похвалити впевнені, але неправильні відповіді.
- Упередженість щодо формату: суддя працює лише тоді, коли запит виглядає точно так само, як той, для якого він був створений чи налаштований.
Жоден з цих факторів не можна повністю усунути, але кожен з них можна виміряти. Зміна порядку кандидатів, додавання до відповіді безневинного „філеру“ чи оцінювання однакового контенту за двома різними шаблонами запитів — це прості експерименти, які показують, наскільки певного суддю впливають фактори, які не повинні мати значення. Проведення таких експериментів один раз під час призначення судді та ще раз після будь-яких змін у його шаблоні запиту чи моделі є однією з найцінніших практик у роботі з оцінкою.
Де проявляються недоліки суддів, створених за допомогою шаблонів
Використання ШІ як судді є ефективним та широко поширеним, але використання проприетарної моделі має серйозні недоліки:
- Модель є „чорною скринькою“, а надсилання даних для оцінки третій стороні може викликати проблеми з безпекою та конфіденційністю.
Майже всі ці проблеми виникають через залежність від моделі, яку неможливо перевірити чи змінити. Це підносить очевидне запитання: чи можна навчити власного оцінювача. Дослідження, наведені нижче, дають позитивну відповідь — добре налаштований оцінювач може надавати більш детальну та критичну інформацію, специфічну для певної галузі, за умови інвестування в відповідні дані.
Метаоцінка: вимірювання самого судді
Перш ніж навчати суддю, вирішіть, як будете визначати його ефективність. Відповіддю є набір оцінкових даних із людськими позначками, яким ви глибоко довіряєте, адже вони стають критерієм для кожного судді, якого ви створюєте. Метаоцінка, тобто оцінка самого оцінювача, полягає у тому, щоб запустити суддю на цих даних та порівняти його рішення з людськими.
Якщо суддя формує бінарний результат, наприклад вибір між двома опціями чи оцінку «пройшов/не пройшов», ви можете використовувати звичайні метрики класифікації, такі як точність, точність передбачення, відтворюваність та крива ROC. Оскільки їх дуже легко інтерпретувати, багато фахівців вважають, що бінарна оцінка є найбільш практичним підходом для суддів ШІ загалом.
Для небінарних оцінок, таких як шкала Лайкерта від 1 до 5, вимірюється ступінь кореляції між оцінками суддів та людськими оцінками. Як довідковий показник, у дослідженні G-Eval було зазначено, що оцінювач на основі GPT-4 досяг кореляції Спірмана 0,514 з людьми у тесті на стиснення інформації, що на той момент значно перевершувало попередні методи. Кореляція рангів Спірмана, ймовірно, є найпоширенішим вибором, але також можна зустріти кореляцію Тау Кендалла, кореляцію Пірсона та каппу Коена як показники згоди. Їх складніше аналізувати, ніж метрики класифікації, тому варто ознайомитися з особливостями того показника, який ви використовуєте. Кореляція Пірсона вимірює лінійну згоду та чутлива до відхилень; Спірман та Кендалл звертають увагу лише на порядок, тож суддя, який постійно оцінює трохи завищено, все одно може отримати ідеальні результати за цими показниками.
Практичні звички метаоцінювання
Кілька звичок роблять метаоцінку набагато інформативнішою. Звітуйте про згоду за кожним критерієм окремо, а не як про єдине сумарне число, оскільки суддя може чудово виявляти фактичні помилки, але погано оцінювати тон, і середнє значення це приховує. Розглядайте плутанину між сусідніми оцінками окремо від серйозних розбіжностей: ситуація, коли суддя ставить 4, тоді як люди — 5, значно відрізняється від ситуації, коли він ставить 1. Порівнюйте згоду судді та людей із згодою між самими людьми щодо одних і тих самих елементів; якщо два навчені анотатори погоджуються лише на 70 відсотків випадків, суддя, який погоджується з ними на 68 відсотків, фактично досягає максимуму, і прагнення до ще більшого рівня є марним. Нарешті, тримайте набір даних для метаоцінки абсолютно окремим від всього, що використовується для створення запитів чи навчання судді, інакше цифри будуть його перебільшувати.
Перше покоління доопрацьованих суддів
На початковому етапі майже всі використовували пропрієтарні моделі для оцінки у стилі судді, і на це була вагома причина. Якщо ви не надасте судді ідеальну відповідь, модель мусить бути здатною самостійно вирішити завдання, щоб розрізнити хорошу відповідь від поганої. Відкриті моделі довгий час відставали від закритих, тому закриті моделі були просто кращими оцінювачами. Це змінилося, коли з’явилися потужніші відкриті базові моделі, такі як LLaMA та LLaMA-2, і дослідники почали їх налаштовувати під спеціалізовані оцінювачі. У наведених нижче статтях описується ця перша хвиля.
Налаштований суддя Vicuna у статті MT-Bench
Саме той документ, у якому було представлено LLM-as-a-Judge, також містив один із перших експериментів із використанням налаштованого судді. Більша частина цих досліджень присвятована використанню стандартних шаблонів для запуску пропрієтарних моделей з метою прогнозування людських уподобань, але у короткому додатку розглядається можливість навчання відкритої моделі для виконання тієї ж роботи; у ньому було зроблено висновок, що налаштований Vicuna-13B є перспективною недорогою альтернативою пропрієтарним суддям.
Причини, які там наведені, досі залишаються основними аргументами для використання спеціалізованих суддів сьогодні:
- Оцінка за допомогою платної API стає дорогою у масштабному використанні.
- Пропрієтарна модель не забезпечує ні контролю, ні прозорості.
- Відкриті моделі постійно стають більш потужними, тож розрив між ними зменшується.
Якби налаштований відкритий суддя міг досягати рівня якості пропрієтарних моделей, усі три проблеми зникли б.
У експерименті використовувався Vicuna-13B, похідний від LLaMA. З самого початку цей модель показувала слабкі результати: у неї була висока частка помилок, вона часто не дотримувалася шаблону оцінки чи інструкцій, а також демонструвала сильну упередженість щодо позиції. Тонке налаштування суттєво змінило ситуацію. Модель була навчена на 20 тисячах голосувань людей у форматі одного кроку з Chatbot Arena, де порівнювалися результати різноманітних моделей; завдання було спрощене до трьохкатегорійної класифікації: перша відповідь перемагає, програє або є нічиєю. Після навчання упередженість щодо позиції різко знизилася, а узгодженість із голосуваннями людей значно покращилася, хоча навіть після тонкого налаштування модель все ще не досягла рівня GPT-4.
Формулювання завдання як трьохсторонньої класифікації є розумним спрощенням. Воно усуває необхідність калібрування числових оцінок, прямо відповідає способу збору голосів у Arena та дозволяє легко обчислювати точність порівняно з голосуванням людей. Недолік полягає у тому, що суддя не надає пояснень, тож коли він не погоджується з людьми, ми дізнаємося мало про причини.
Усе дослідження займає приблизно одну сторінку, але результати були настільки обнадійливими, що це стало поштовхом до роботи над відкритими оцінювачами.
PandaLM: суддя для вибору між чекпоїнтами моделей
Частим застосуванням судді є вибір моделі: серед кількох кандидатських моделей яка є найкращою? Це ускладнюється, коли всі кандидати є сильними та відрізняються лише незначно. Люди можуть приймати таке рішення, але повільно, тому суддя, який надійно виявляє невеликі різниці у якості, є цінним.
PandaLM був створений саме для цього. Його мета полягає не лише у перевірці правильності відповіді; він також оцінює суб’єктивні якості, такі як відносна лаконічність, зрозумілість, повнота інформації, формальність та дотримання інструкцій. Основне застосування — налаштування гіперпараметрів. Ви тренуєте кілька варіантів моделі з різними налаштуваннями, дозволяєте PandaLM порівняти їхні результати та залишаєте найкращу конфігурацію. У експериментах, описаних у статті, кожна модель, налаштована таким чином, показувала кращі результати, ніж за стандартних налаштувань, що демонструє можливість використання оцінок для безпосереднього впливу на процес навчання, а не лише для створення звітів.
Набір даних для навчання містить понад 300 тисяч прикладів. Кожен вхідний даний елемент — це тупла (instruction, input, response1, response2), а кожен цільовий елемент — тупла (evaluation result, evaluation rationale). Кожен приклад має орієнтовну відповідь, і результат або вказує кращу відповідь, або оголошує нічию. Команда доопрацювала моделі LLaMA різних розмірів на цих даних, використовуючи просте прогнозування наступного токену з втратою у форматі крос-ентропії, у стилі послідовність-до-послідовності, без окремої голови для класифікації. Іншими словами, вердикт та пояснення — це просто текст, який модель навчається генерувати.
Інструкції та вхідні дані походять з навчальних даних Alpaca. Пари відповідей були створені кількома моделями з приблизно 7 мільярдів параметрів, а саме LLaMA-7B, BLOOM-7B, Cerebras-GPT, OPT-7B та Pythia. Вердикти та обґрунтування для цих пар були синтетично створені за допомогою GPT-4 згідно з процесом у стилі Self-Instruct, а потім опрацьовані за допомогою евристик, таких як ручно створені правила та фільтри, що видаляють недійсні чи нестабільні оцінки. Окремо людські анотатори створили менший „золотий“ набір тестів, який використовується виключно для метаоцінки.
Коли PandaLM порівнюють з іншими оцінювачами, включаючи GPT-3.5 та GPT-4, їхні уподобання демонструють схожі тенденції: вони ранжують оцінювані моделі у послідовному порядку. У прямому змаганні з власними оцінювачами 7B-версія PandaLM є конкурентоспроможною, а 70B-версія перевершує GPT-4 за результатами оцінювання, що свідчить про те, що здатність до оцінювання, як і більшість функцій, покращується зі збільшенням обсягу даних.
PandaLM також добре справляється з завданнями у спеціалізованих галузях. У дослідженні її використовували для аналізу відповідей на запитання LSAT та для роботи з наборами даних у галузі біомедицини, причому більша версія моделі показувала особливо хороші результати. Оскільки вона навчалась спеціально на даних для оцінювання, вона ефективно застосовується до завдань оцінювання в конкретних галузях, які близькі до її дистрибуції навчання, а не лише до загальних завдань оцінювання чату.
JudgeLM: що насправді робить добрим відточений оцінювач
Більшість ранніх дороблених суддів майже нічого не казали про причини своєї роботи. JudgeLM мав на меті систематично дослідити ці фактори, зокрема:
- скільки даних для навчання використовується та наскільки вони якісні та різноманітні;
- розмір та якість базової моделі;
- як упередження впливають на рішення судді;
- чи може суддя застосовуватися до інших форматів, таких як багаторазовий чат, оцінювання з однією відповіддю, парне ранжування та багатомодальні дані.
Дороблена суддя може відставати від пропрієтарної з багатьох причин: слабка базова модель, шумні дані, систематичні упередження тощо. Цінність JudgeLM полягає у тому, що він демонструє, як можна безпосередньо вирішувати ці проблеми.
Найважливішим компонентом є великий набір даних високої якості, з деталізованою структурою та різноманітним змістом, причому команда JudgeLM прямо назвала свій набір даних найбільш різноманітним та якісним серед усіх, що були доступні на той момент. Він починається з 105 тисяч початкових інструкцій, взятих з публічних джерел, таких як ShareGPT, та версії даних Alpaca з відповідями GPT-4.
Для кожної початкової інструкції відповіді генеруються кількома моделями, зокрема Alpaca, Vicuna та LLaMA, і поєднуються з первісною відповіддю з початкового набору даних, тож кожна інструкція має кілька кандидатських відповідей разом із посиланням. Потім пари відповідей вибираються випадковим чином, GPT-4 оцінює кожну пару та пояснює свої міркування. GPT-4 фактично виступає у ролі вчителя: JudgeLM навчається відтворювати його оцінки.
Шаблони оцінювання GPT-4 існують у двох варіантах — зі зразком правильної відповіді та без нього. Вони дуже схожі на стандартні запити для громадських суддів, з однією важливою відмінністю: у них чітко викладені досить детальні критерії оцінювання. Це спонукає GPT-4 до більш дрібногранного аналізу, а подальша налаштування моделі на основі цих оцінок передає таку ж дрібногранність моделі JudgeLM.
JudgeLM була навчена з параметрами 7B, 13B та 33B на наборах даних від 3,5 тис. до 100 тис. прикладів, за допомогою налаштування за інструкціями з використанням керованої налаштування (SFT). Вхідні дані містять одну інструкцію, дві кандидатські відповіді та зразок правильної відповіді. Модель формує окремий бал для кожної відповіді та пояснює причини. Перетворити це на парне рішення дуже просто: перемагає та відповідь, яка має вищий бал, а при однакових балах — нічия. Приємним побічним ефектом такої конструкції є те, що одна модель може виконувати функції як оцінювача, так і порівняльника.
Зменшення упереджень було центральною метою. JudgeLM націлений на три види упереджень:
- Упередження через позицію: віддача переваги певній відповіді через її розташування в запиті, а не через зміст.
- Упередження, пов’язане зі знаннями: базова модель не має знань, отриманих під час попереднього навчання, необхідних для правильної оцінки відповіді.
- Упередження щодо формату: оцінювач працює ефективно лише тоді, коли запит відповідає точному формату, використаному під час додаткового навчання.
Кожен з цих проблем має досить пряме рішення. Упередженість через формат зменшується, коли суддя під час навчання бачить кілька форматів запитів. Упередженість через знання зменшується, коли ви надаєте судді орієнтовну відповідь, тож йому не потрібно самостійно знати факти. Упередженість через позицію усувається шляхом зміни порядку: кожну пару потрібно оцінювати в обох можливих порядках, як під час створення навчальних даних, так і під час виконання завдань. Якщо вердикт змінюється при зміні порядку, пару зазвичай вважають нічиєю. Зміна позицій під час навчання допомагає моделі зосереджуватися на змісті, а не на розташуванні, а зміна під час виконання завдань обмежує будь-які залишкові упередження. При спільному використанні ці методи суттєво зменшують упередженість JudgeLM.
Варто пам’ятати про витрати, пов’язані зі зміною позиції під час інференсу: це подвоює кількість викликів Judge для парного оцінювання. Для великих офлайн-оцінок це зазвичай прийнятно; проте для онлайн-використання, чутливого до затримок, це може бути проблемою.
На власному наборі даних для оцінювання JudgeLM перевершує PandaLM та GPT-3.5 як із допомогою контрольних відповідей, так і без них. Таке порівняння сприяє JudgeLM, оскільки він був навчений на даних майже з тієї ж розподільної функції, але він також демонструє гарні результати на наборі даних PandaLM. Слід зазначити, що більша частина результатів JudgeLM — це узгодженість із GPT-4, тим самим моделлю, яка створила його навчальні мітки, а не узгодженість із людьми. Загалом моделі демонструють стабільну продуктивність, покращуються зі збільшенням розміру та є більш стійкими до зміни позиції порівняно з альтернативами.
Це вказує на загальну обмеженість методу дистиляції суддів. Коли модель-студент навчається на вердиктах вчителя, точність вчителя діє як своєрідний „стелювальний“ фактор, а його сліпі зони та упередження передаються разом із сильними сторонами. Висока збігність із GPT-4 свідчить про те, що процес дистиляції відбувся успішно; проте це не означає, що суддя погоджується з вашими користувачами. Лише набір даних для тестування з людськими мітками може відповісти на це друге запитання.
Auto-J: заснований на реальних запитах користувачів
Auto-J, описаний у статті „Generative Judge for Evaluating Alignment“, — це ще один вдосконалений інструмент оцінювання, який зосереджується на оцінюванні в конкретних сценаріях у реалістичних умовах. Його характерні риси:
- Він підтримує як парне порівняння, так і оцінювання з однією відповіддю.
- Він надає пріоритет добре структурованим, високоякісним критичним коментарям у природній мові.
Результатом є суддя, який є гнучким, інтерпретованим та практичним.
Дані Auto-J починаються з визначення сценаріїв, кожен з яких має власне визначення та критерії оцінки. У дослідженні використано 58 сценаріїв, розділених на вісім більших категорій. Для кожного сценарію збираються реальні запити користувачів, генеруються відповіді, а GPT-4 формує оцінки. GPT-4 керується власноруч написаними критеріями, специфічними для кожного сценарію, а результати після обробки проходять через евристичні фільтри та нормалізацію формату для зменшення шуму. Кожен сценарій надає до 100 прикладів, що дає загалом близько 3 500 прикладів.
Запити переважно надходять з публічних джерел, створених на основі взаємодії людей, таких як Chatbot Arena та WebGPT. Оскільки вони відображають те, про що запитують люди у реальному житті, Auto-J спеціалізується на реалістичній оцінці. Як подвійні, так і одиночні мітки відповідей створюються за допомогою GPT-4, а фільтри видаляють прогнози, які є суперечливими або погано сформатованими.
Auto-J був доопрацьований на основі LLaMA-2-13B-Chat за допомогою цього набору даних змішаного формату. Цікавим рішенням у його проектуванні є те, що критерії оцінки не включаються до вхідних даних. Причиною цього стало те, що модель має неявно засвоювати ці критерії з даних, що робить її більш універсальною. Подальші дослідження, зокрема Prometheus, дійшли протилежного висновку та виявили, що введення рубрик та інших довідкових матеріалів є важливим для оцінювача. Щоб уникнути упередженості, Auto-J використовує просте методи розширення даних: кожен парний приклад дублюється зі зміною місцями двох відповідей, а позначки „Відповідь 1“ та „Відповідь 2“ у оцінці також змінюються місцями.
Набір даних Auto-J побудований так само, як і набір для навчання, за винятком того, що кожна мітка створена людськими анотаторами. Порівняно з різними іншими моделями Auto-J перевершує майже всі з них, за винятком GPT-4. Це підтверджує, що спеціалізований оцінювач, навчений на даних, відповідних конкретній галузі, може наблизитися до рівня пропрієтарних оцінювачів, а іноді навіть перевершити їх у своїй цільовій сфері. Однак його абсолютна згода з людьми у цьому наборі даних все ще низька, що нагадує про те, що якість оцінювачів в цілому має значний потенціал для покращення.
Критики, перевіряючі та генератори синтетичних даних
Окрім цих суддів, існує тісно пов’язана галузь досліджень, яка навчала моделі перевіряти, критикувати чи надавати відгуки щодо результатів іншої моделі. Як і судді, ці моделі оцінюють відповіді та пояснюють свої міркування. Різниця полягає у тому, що критики та перевіряючі також діють на основі цих висновків: вони коригують відповідь або ініціюють нову спробу, якщо первинний результат є недостатнім.
SelFee є гарним прикладом: це модель на основі LLaMA, навчена на генераціях ChatGPT, відгуках ChatGPT щодо них та перероблених версіях. Отримавши відповідь, SelFee пише відгук, а потім переписує її на основі цього відгуку, і може продовжувати цей процес до тих пір, поки результат не досягне певного рівня якості. Це робить її перевіряючою, оскільки вона перевіряє власні результати, та критиком, оскільки вона пише відгуки та вносить корективи.
Було запропоновано багато інших методів критики, зокрема моделі самокорекції, PEER та самокритичні моделі. Той самий механізм може генерувати та фільтрувати синтетичні навчальні дані для SFT чи налаштування переваг, як у RLAIF та Constitutional AI.
Якщо дивитися здалеку, усі ці системи — судді з підказками, дороблені судді, конвеєри синтетичних даних, критики та верифікатори — по суті роблять одне й те саме: створюють оцінку та пояснення. Відмінність полягає у тому, як використовується оцінка — чи для опису якості моделі, чи для вирішення, які зразки потраплять до навчального набору. Останні дослідження щодо генеративних верифікаторів та моделей нагород на основі критики стверджують, що принаймні деякі з цих функцій можна об’єднати в одну модель, яка б виконувала всі завдання з оцінювання.
Сімейство Prometheus: дороблені судді, які конкурують з GPT-4
Досягнувши популярності лише з Prometheus — моделлю, створеною для детальної оцінки в конкретних галузях, — вдосконалені оцінювачі почали активно використовуватися. Їхня методологія не є кардинально новою; основна зміна полягає у значно кращій вихідній основі в LLaMA-2 та ретельно підготовленому наборі даних. Оскільки вони досягали рівня багатьох пропрієтарних оцінювачів за якістю оцінок, вони швидко набули популярності та породили кілька наступних версій.
Prometheus: рубрики як першокласний вхідний даний
Використання пропрієтарного оцінювача є простим: достатньо описати критерії та дозволити моделі працювати. Проблеми полягають у вже згаданих неконтрольованій версіонуванні та витратах, а також у тому, що ці моделі здебільшого використовуються для оцінки загальних людських уподобань та можуть мати труднощі з індивідуальними критеріями. Prometheus вирішує цю проблему за допомогою вдосконаленого оцінювача, який після навчання для певної галузі може досягати рівня або навіть перевершувати пропрієтарні оцінювачі.
Ключова ідея полягає у тому, що Prometheus приймає вхідні дані у вигляді індивідуальної шкали оцінювання, що дозволяє йому адаптуватися до нових сфер та критеріїв без повторної підготовки. Він навчається на датасеті Feedback Collection — синтетичному наборі даних, створеному за допомогою GPT-4 та охоплюючому багато завдань на оцінку. Кожен приклад містить однакові компоненти:
- Інструкція: запит, який надається моделі для оцінювання.
- Відповідь: відповідь цієї моделі, яка потім оцінюється.
- Шкала: індивідуальні критерії, що описують, як слід оцінювати відповідь.
- Ідеальна відповідь: приклад відповіді, який отримає найвищу оцінку.
- Обґрунтування: пояснення того, чому відповідь отримала певну оцінку.
- Оцінка: бал від 1 до 5 за шкалою Лікерта.
Рубрика складається з двох частин: загального опису критерію та пояснення того, що означає кожна оцінка від 1 до 5. Використання цих даних дозволяє моделі ставити оцінки з високим рівнем деталізації та застосовувати їх до схем оцінювання, яких вона раніше не бачила. Дослідження Prometheus було одним із перших, які показали, наскільки сильно оптимізований оцінювач отримує користь від наявності багатого довідкового матеріалу, зокрема від зразків правильних відповідей.
Створення починається з 50 рубрик, написаних людьми, та проходить у трьох етапах:
- GPT-4, побачивши приклади ручно написаних рубрик, розширює їх до 1 тисячі рубрик.
- Для кожної рубрики GPT-4 пише 20 інструкцій, що дає загалом 20 тисяч інструкцій.
- Для кожної інструкції GPT-4 спочатку генерує відповідь, потім зворотний зв’язок щодо неї, а потім оцінку, у такій послідовності.
Два трюки балансування роблять дані кориснішими. По-перше, GPT-4 генерує по п’ять прикладів навчання на кожну інструкцію, по одному для кожної оцінки від 1 до 5, щоб розподіл оцінок був однорідним та щоб оцінювач не почав автоматично ставити високі бали. По-друге, ці приклади мають схожу довжину, щоб оцінювач не розвивав упередження на користь довших відповідей, тобто звички оцінювати їх вище незалежно від змісту.
Prometheus був доопрацьований на основі LLaMA-2-13B-Chat за допомогою наборів даних Feedback Collection разом із наборами оцінювання MT-Bench та Vicuna Bench. Завдяки наявності всього необхідного матеріалу у запиті модель навчається за методом SFT спочатку писати свою оцінку, а вже потім вказувати бал. Така послідовність є навмисною та відображає принципи доопрацювання з використанням ланцюга міркувань: написаний аналіз стає контекстом, на якому модель ґрунтується при виборі числа, а не просто поясненням, доданим пізніше. Команда Prometheus також наголошує на необхідності вставляти спеціальний токен-розділювач [RESULT] між оцінкою та балом, що запобігає погіршенню якості результатів під час інтерпретації та полегшує парсинг балу.
Prometheus порівнювали з GPT-3.5, GPT-4 та кількома відкритими базовими моделями на кількох наборах даних, оцінюючи як узгодженість із результатами людей, так і корисність його зворотного зв’язку. Його показники досягли коефіцієнта кореляції Пірсона 0.897 із оцінками людей, що дорівнює показникам GPT-4 та значно перевищує показники GPT-3.5. Отже, модель, налаштована за допомогою високоякісних даних для оцінки в певній галузі, може досягати або навіть перевершувати рівень узгодженості з людьми у багато разів більших пропрієтарних моделей.
Відгуки також підтверджують це. У 58,67% порівнянь людські рецензенти віддали перевагу відгукам Prometheus перед відгуками GPT-4, а у майже 80% — перед відгуками GPT-3.5. Коли їх запитували чому, рецензенти зазначили, що Prometheus є більш критичним та конкретнішим. У статті це узагальнюється як схильність GPT-4 залишатися нейтральним та абстрактним, тоді як Prometheus чітко висловлює думку щодо того, чи є відповідь хорошою. Ось перевага спеціалізації: Prometheus — це не універсальний асистент, навчений бути приємним у спілкуванні, а модель, єдиною функцією якої є критика.
Prometheus 2: одна модель для точкового та парного оцінювання
Prometheus 2 продовжує цю лінійку ще одним відкритим, деталізованим оцінювачем, який приймає користувацькі критерії. Він усуває дві слабкості попередньої версії: збіг із оцінками людей все ще потребував покращення, а ще важливіше те, що перший Prometheus міг здійснювати лише пряму оцінку. Можна було отримати рейтинг, порівнюючи дві оцінки за окремими пунктами, але ні Prometheus, ні більшість ранніх відкритих оцінювачів не могли природним чином порівнювати два варіанти відповідей. Prometheus 2 поєднує обидва режими в одну модель, яка точно відстежує результати як людей, так і GPT-4 у кожному з них.
Приклади парного порівняння в Prometheus 2 відрізняються від прикладів прямої оцінки трьома аспектами:
- У матеріалах для порівняння немає правильної відповіді.
- Вони складаються лише з опису критеріїв оцінювання.
- Формат зворотного зв’язку відрізняється.
У режимі парного порівняння зворотний зв’язок має порівнювати два варіанти відповідей, вказувати на відмінності та використовувати їх для обґрунтування вибору одного з них. Більшість ранніх наборів даних та моделей для парного порівняння спиралися на загальні критерії та часто надавали лише просте рішення без жодних пояснень порівняння.
Щоб навчити модель роботи в режимі парного порівняння, Prometheus 2 вводить механізм збору преференцій, який базується на зборі зворотного зв’язку. Оскільки останній містить п’ять варіантів відповідей на кожну інструкцію — по одному для кожного балу — можна сформувати всі можливі пари між ними: десять пар на кожну інструкцію. Мітка для кожної пари формується шляхом прямого порівняння двох балів за шкалою Лайкерта.
Оскільки пояснювальний зворотний зв’язок у стилі послідовного мислення є ключовим елементом підходу Prometheus, самої мітки було недостатньо. GPT-4 просили написати новий зворотний зв’язок для кожної пари, зосередившись на тому, що мають спільного дві відповіді та де вони відрізняються.
Існує кілька способів створити одного суддю, який би обробляв обидва режими оцінювання:
- Використання запитів: застосувати готову модель із різними запитами для кожного режиму.
- Навчання у єдиному форматі: навчити окрему модель для кожного режиму та використовувати ту, що підходить.
- Спільне навчання: навчити одну модель на суміші обох типів даних.
Лише спільне навчання дозволяє отримати одну спеціалізовану модель, яка покриває обидва режими; використання запитів ґрунтується на універсальних моделях, а навчання у єдиному форматі залишає дві моделі. Четвертий варіант — навчити дві моделі у єдиному форматі, а потім об’єднати їх шляхом злиття, що саме робить Prometheus 2. Два оцінювачі навчаються окремо — один на збір відгуків, інший на збір переваг, — а їхні ваги об’єднуються за допомогою простого лінійного злиття, що дає одну модель, здатну оцінювати в обох режимах.
Варто зазначити, що об’єднаний модель перевершує як спільно навчений модель, так і моделі окремого формату. Було випробовано кілька методів об’єднання, зокрема арифметичне поєднання, TIES та DARE. Більш складні методи іноді допомагають; наприклад, при використанні Mixtral 8x7B як основи найкращим виявився метод DARE. Однак просте лінійне об’єднання з коефіцієнтом 0,5, яке полягає у простому середньому значенні ваг обох моделей, добре працює у більшості конфігурацій та є дуже простим у реалізації. Однією з причин, чому це ефективно, є те, що обидва процеси навчання починаються з однієї основної моделі та опановують схожі навички, тому їхні ваги залишаються у сумісному діапазоні, де середнє значення поєднує здібності, а не руйнує їх.
Prometheus 2 був створений на основі Mistral-7B та Mixtral 8x7B: окремі копії моделей працюють з кожним набором даних та потім об’єднуються за допомогою різних алгоритмів. Отримані моделі перевершують усі інші відкриті моделі для оцінки у наборах тестів прямої оцінки та порівняльних тестів. Їхній коефіцієнт кореляції Пірсона з проприетарними моделями для оцінки покращується на 0,2 у всіх наборах даних, а у тестах порівняльного ранжування вони скорочують різницю з GPT-4 приблизно наполовину.
У парному режимі результати виглядають менш значущими, але там порівняння включає як моделі оцінки, так і моделі нагород. Моделі нагород, які використовуються у методах посиленого навчання на основі людських відгуків (RLHF), навчаються лише для визначення парних переваг, не надають письмових відгуків та демонструють високу точність у парних порівняннях. Prometheus 2 також показує кращу послідовність між режимами порівняно з іншими оцінювачами: відповідь, яку він віддає перевагу у парному порівнянні, зазвичай отримує вищий бал під час прямої оцінки. Ця властивість має велике значення на практиці, адже суддю, чиї оцінки у двох режимах не збігаються, важко довіряти ні в одному з них.
Prometheus-Vision: оцінювання моделей мови та зору
Усе, що було сказано досі, стосується моделей лише з текстом. Моделі зору та мови (VLM), які приймають як зображення, так і текст, стали поширеними як у пропрієтарних форматах, таких як GPT-4V та Gemini, так і у відкритих форматах, як LLaVA та версії Llama 3.2 для роботи з зображеннями. Окрім додаткової форми вхідних даних, вони навчаються та структуруються майже так само, як текстові LLM.
VLM генерує текст на основі зображення та інструкції, а його оцінка додає ще один вимір. Потрібно перевірити дві речі:
- Чи відповідає відповідь інструкції, як це є у будь-якому LLM.
- Чи ґрунтується відповідь на тому, що насправді показує зображення.
Коли робота була опублікована, не існувало жодних даних з відгуками, критикою чи перевагами для навчання деталізованого оцінювача VLM, тому команда створила їх самостійно. Колекція Perception побудована за принципами Колекції Feedback, і кожен екземпляр має п’ять частин вхідних даних:
- Зображення: знімок, який користувач надає VLM.
- Інструкція: текстова інструкція від користувача.
- Відповідь: текстова відповідь VLM на зображення та інструкцію.
- Критерії оцінки: детальні вказівки щодо оцінювання, включаючи опис критеріїв та кожної оцінки в масштабі від 1 до 5.
- Ідеальна відповідь: відповідь, яка отримала б оцінку 5, створена за допомогою GPT-4V.
Результати — це письмове обґрунтування та оцінка в масштабі від 1 до 5.
Будівництво відображає структуру набору текстових даних. У процесі вибираються 5 тисяч зображень із наборів даних MS-COCO та MMMU, вручну створюється 50 початкових критеріїв оцінювання, за допомогою GPT-4 вони розширюються до 15 тисяч критеріїв, генерується 30 тисяч інструкцій із відповідними зразками відповідей, а нарешті до кожної інструкції додаються п’ять варіантів відповідей — по одному на кожен бал — кожен з яких супроводжується відгуком. Порівняно з методом збору відгуків тут значно більше критеріїв оцінювання (15 тисяч проти 1 тисячі), але значно менше інструкцій на кожен критерій (дві проти 20).
Тут не можна використовувати базову модель лише з текстом; навчання має починатися з попередньо навченого VLM. Prometheus-Vision використовує версії LLaVA-1.5 розміром 7B та 13B. Схема є такою ж, як і раніше — тонке налаштування за принципом ланцюга міркувань: SFT навчає модель писати відгуки, а потім ставити оцінку. У кожному прикладі для навчання ці дві частини розділені фіксованим виразом Отже, загальна оцінка —, який виконує ту саму функцію, що й токен [RESULT] у текстовій моделі. Завдяки рубрикам та зразкам відповідей у вхідних даних модель налаштовується для індивідуальної, деталізованої оцінки.
Prometheus-Vision краще узгоджується з оцінками людей, ніж GPT-3.5-Turbo та проста версія Prometheus, але GPT-4 та GPT-4V в цілому більш точно збігаються з оцінками людей. Найгірші результати він показує на тесті VisIT-Bench, який складається ззображень із великою кількістю тексту. Там GPT-4 показує гарні результати, навіть кращі за GPT-4V, оскільки отримує як вхідні дані текст, видобутий з зображення, тоді як Prometheus-Vision має труднощі з його читанням. На інших тестах Prometheus-Vision приблизно на рівні з GPT-4 та GPT-4V, і в деяких випадках краще узгоджується з оцінками людей, ніж будь-хто з них.
Людські експерти оцінили якість його відповідей майже на рівні GPT-4 та GPT-4V. Команда також дослідила поширені упередження оцінювачів, такі як упередження щодо довжини — схильність до довших відповідей, та упередження самопідвищення — схильність до власних результатів. Вони не виявили жодних очевидних ознак жодного з цих упереджень, хоча зазначили, що експериментально ізолювати окреме упередження є справді складно.
Інші напрямки уточненої оцінки
Prometheus — не єдиний проект у цій галузі. Існує чимало інших проектів, які навчали мовні моделі для оцінки, кожен з яких пропонує унікальний підхід. Короткий огляд нижче стосується тих проектів, які є найбільш актуальними, якщо ви плануєте створити власного оцінювача.
Мовні моделі з самореєстрацією винагороди
Моделі з самореєстрацією нагород мають на меті автоматизувати узгодження за допомогою внутрішнього оцінювача. Замість того, щоб тренувати окрему модель нагород на основі людських уподобань, саму модель, яку потрібно узгодити, тренують на те, щоб вона оцінювала власні результати за допомогою запитів у стилі LLM-as-a-Judge, і ці оцінки стають нагородою. При застосуванні до LLaMA-2 цей метод дав корисний зворотний зв’язок та покращив основну модель. Концептуально він схожий на Prometheus, оскільки модель навчається діяти як суддя, але результати роботи цього судді безпосередньо використовуються як сигнал для тренування тієї самої моделі.
LLM-as-a-Meta-Judge
Обмеженням моделей з самооплатою є те, що ніщо не покращує саму навичку оцінювання; модель стає кращою у відповідах, але її оцінки залишаються на тому ж рівні, що й спочатку. Моделі з метаоплатою додають третю роль. Окрім функцій виконавця та судді, модель також виступає у ролі метасудді, яка оцінює власні рішення, що створює дані для навчання з метою покращення як самої навички оцінювання, так і алгоритму прийняття рішень. Обидві ці здатності покращуються разом протягом ітерацій навчання.
Самоосвічені оцінювачі
Самоосвічені оцінювачі повністю усувають з процесу людські мітки вподобань. Збір даних про людські уподобання є дорогим, а вони стають застарілими з покращенням моделей, тому цей підхід ітеративно створює синтетичні дані для оцінки. Виходячи з набору інструкцій, ШІ генерує пари контрастних результатів, причому один з них навмисно гірший за інший, а оцінювача навчають оцінювати їх, пишучи пояснення та вердикти. Повторення цього процесу з покращеним оцінювачем з кожного разу дає кращі дані для навчання. Без будь-яких даних із людськими мітками було повідомлено, що отримані оцінювачі перевершують як GPT-4, використовуваний як оцінювач, так і моделі, навчені на людських уподобаннях, за точністю оцінок.
Очевидною проблемою є циклічність. Суддя, який сам створює свої дані для навчання, може схилятися до того, що він вже вважає правильним, і без зовнішнього контролю цей схил є непомітним. Навіть якщо використовувати цикл самонавчання, лише невеликий набір даних із позначками від людини залишається єдиним способом підтвердити, що на кожному етапі справді відбувається покращення, а не просто зростає впевненість.
FLAMe: основні авторитети
Основні моделі великих авторитетних оцінювачів (FLAMe) діють протилежно щодо даних: їх навчають на дуже великій кількості людських оцінок — понад 5 млн з них у рамках понад 100 завдань оцінки якості. Порівняно з іншими оцінювачами, моделі FLAMe краще узагальнюють знання на невідомих завданнях оцінки, демонструють менше упередженості та є міцною основою для подальшої налаштування їх як спеціалізованих оцінювачів. Було повідомлено, що вони постійно перевершують оцінювачів, створених на основі варіантів GPT-4 та Claude, а також оцінювачів, налаштованих на синтетичних даних GPT-4.
Компроміс узагальнення
Емпіричне дослідження моделей суддів, налаштованих детально, під назвою «Моделі суддів, налаштовані детально, є класифікаторами, спеціалізованими на певних завданнях», ґлибоко дослідило переваги та недоліки їх порівняння з пропрієтарними моделями суддів. Його висновок: моделі суддів, налаштовані детально, є відмінними для виконання завдань у межах своєї сфери, іноді перевершуючи GPT-4 у тестових наборах, створених на основі їхньої дистрибуції навчання, але вони поступаються GPT-4 у здатності до узагальнення, справедливості, оцінці конкретних аспектів та масштабованості. Це не дивно – суддя, навчений на певній дистрибуції, засвоює саме її; якщо поставити йому запитання про щось інше, він буде поводитися як вузький класифікатор. Практичний висновок полягає у тому, що модель судді, налаштовану детально, слід використовувати лише для тих завдань, на які вона була навчена, та перевіряти її знову за допомогою людських міток щоразу, коли вхідні дані починають змінюватися.
Оптимізація пріоритетів прямого судження
Оптимізація вподобань шляхом прямого судження застосовує оптимізацію вподобань до оцінювачів, а не лише до SFT. Пари вподобань збираються для трьох сценаріїв використання: однократна оцінка, порівняння пар та бінарна класифікація. Перші два відповідають звичайним схемам оцінки по окремих пунктах та порівнянню пар; третій формулює оцінку як запитання «так/ні», наприклад, чи існує певна властивість у відповіді. Також додається допоміжне завдання: на основі інструкції та результату оцінки модель має визначити, яку саме відповідь оцінювали. Для кожного сценарію хороше та погане судження утворюють пару вподобань, і оцінювач навчається на них за допомогою прямої оптимізації вподобань (DPO). Перевагою є те, що оцінювач вчиться не лише імітувати хороші судження, а й віддавати їм перевагу перед правдоподібними поганими.
Що впливає на оцінки судді?
Справедливе запитання щодо будь-якого судді з ШІ полягає у тому, чи справді він застосовує критерії, які ви йому надаєте, чи просто нагороджує текст, схожий на його навчальні дані. Аналізи суддів з ШІ у різних системах оцінювання показали, що детальні інструкції з оцінювання у запиті лише трохи покращують їхні рішення, а оцінювання на основі плексикогенності, яке визначає реакцію за тим, наскільки ймовірною вона здається моделі, іноді краще узгоджується з людськими оцінками, ніж запити, особливо щодо якості тексту.
Це суперечить висновкам Prometheus про те, що референтний матеріал має величезне значення. Ці два результати легше узгодити, якщо зрозуміти, що саме вимірювалося. Аналізи, орієнтовані на показник переплутаності, зосереджуються переважно на загальній якості відповідей з точки зору людських уподобань. Більшість ШІ навчаються на даних про уподобання, тому цілком природно, що вони надають високу ймовірність відповідям, які подобаються людям. Prometheus, навпаки, орієнтується на широкий спектр індивідуальних критеріїв, які виходять за межі загальних уподобань, і для них чіткі критерії оцінювання містять інформацію, яку модель не може вивести лише з рівня плавності мовлення. Якщо ваші критерії близькі до питання „яку відповідь люди полюбляють більше“, критерії оцінювання можуть мало щось додати; якщо вони специфічні для вашої галузі, вони є абсолютно необхідними.
Крок за кроком: як створити власного оцінювача
З огляду на сучасний стан досліджень, корисно узагальнити його у певний процес. Робота Prometheus вже пропонує основні рамки, а наведена нижче версія трохи їх адаптує, враховуючи результати інших досліджень.
Крок 1: визначити критерії оцінки
Перш за все точно вирішіть, що саме ви будете оцінювати:
- Складіть список конкретних критеріїв, які мають значення для вашого застосунку.
- Напишіть детальний опис кожного з них, включаючи значення кожного рівня оцінки.
Прикладом такої шкали є система збору відгуків, яка містить опис критеріїв, пояснення до кожної оцінки та зразкові відповіді. Очікуйте, що критерії доведеться неодноразово коригувати. У міру того, як ви з’ясуєте, у чому розбіжності між людьми та моделями, ви будете удосконалювати та розширювати цю шкалу, а кожна корекція робить оцінку як людьми, так і моделями більш послідовною.
Крок 2: збір високоякісних людських міток
Перед навчанням або навіть перед використанням будь-якого оцінювача вам потрібні надійні дані для людської оцінки. Саме вони дозволяють з’ясувати, наскільки точним є оцінювач, і мають відображати дані, з якими він буде стикатися під час роботи. Якщо дані призначені лише для мета-оцінки, наприклад для перевірки оцінювача у вигляді LLM, то зазвичай достатньо невеликої кількості — близько 100–1000 прикладів. Для деталізованої налаштування оцінювача у стилі Prometheus потрібно значно більше даних — від 1000 до 100 000 прикладів.
Збір даних від людей є складним процесом, і саме тут команди найчастіше не вкладають достатньо ресурсів. Якщо люди не можуть дійти згоди щодо завдання, немає способу з’ясувати, чи ефективно працює модель, а навчання оцінювача за допомогою суперечливих міток марнує всі зусилля. Усе, що сказано у розділі про людську оцінку вище, також стосується цього випадку: необхідно калібрувати оцінювачів, дотримуватися правил та постійно перевіряти рівень згоди.
Крок 3: доповнення синтетичними даними
Моделі Prometheus демонструють, що синтетичні дані можуть створити ефективних оцінювачів: майже вся їхня навчальна інформація, включаючи інструкції, відповіді, оцінки та зворотний зв’язок, була створена за допомогою GPT-4. Чисто синтетичні дані несуть ризик, оскільки вони піддають модель вузькому спектру можливих вхідних даних та успадковують упередження моделі-вчителя. Поєднання даних, позначених людьми, та синтетичних даних зазвичай дає значно кращі результати, ніж використання будь-кого з них окремо. Використовуйте дані, позначені людьми, для забезпечення якості, а синтетичні дані — для досягнення об’єму та охоплення, необхідних для деталізованої налаштування, а також застосовуйте принципи балансування з розділу Збір зворотного зв’язку: рівномірний розподіл оцінок та контрольовану довжину відповідей під час їх створення.
Крок 4: інвестуйте у обґрунтування
Звісно, необхідні точні оцінки та рейтинги, але обґрунтування також потребують належної уваги. Відомо, що файн-тюнінг — це поганий спосіб внесення нових знань у модель; він добре підходить лише для навчання стилю та формату. Для судді формат зворотного зв’язку — це головне, що ви можете контролювати. Обґрунтування, які є конкретними, критичними та пов’язаними з критеріями оцінювання, сприяють тому, що пояснення судді будуть дійсно корисними, а оскільки модель пише обґрунтування перед оцінкою, кращі обґрунтування зазвичай призводять до кращих оцінок. Розмістіть фіксований розділовик між зворотним зв’язком та оцінкою, щоб результати було легко аналізувати.
Крок 5: додавайте приклади правильних відповідей там, де це можливо
Цей крок є необов’язковим, але зазвичай корисним. Орієнтовні відповіді допомагають як суддям, яких запитують, так і тим, хто їх доробляє. Для суддів, яких доробили, вони усувають упередження у знаннях, заповнюючи прогалини в тому, що навчив базовий модель під час попереднього навчання, та роблять оцінювання за окремими пунктами значно точнішим та стабільнішим. Для завдань, що потребують фактів чи глибоких знань у певній галузі, орієнтовна відповідь часто має більше значення, ніж формулювання запиту.
Крок 6: навчання та метаоцінювання
За наявності даних та, за бажанням, контрольних відповідей, навчіть суддю за допомогою стандартного SFT. Репозиторій Prometheus пропонує повну реалізацію цього процесу. З самого початку відкладіть частину даних, позначених людьми, для тестування та використовуйте її для метооцінки: показники класифікації, якщо результат судді є бінарним, та показники кореляції для всього іншого. Для пар суддів також вимірюйте, наскільки часто вердикт залишається незмінним після зміни порядку; суддя, який змінює свою думку при зміні порядку, ще не готовий до роботи.
Перш ніж покладатися на суддю, виконайте кілька додаткових перевірок:
- Оцініть його роботу на прикладах, що не належать до даного діапазону, щоб з’ясувати межі його компетентності.
- Порівняйте розподіл його балів із розподілом людських оцінок, щоб виявити систематичну схильність до пом’якшення чи посилення оцінок.
- Безпосередньо перевірте вплив довжини та порядку, змінюючи довжину відповіді та порядок для одного й того ж контенту.
Коли не варто використовувати фінтюнінг
Фінтюнінований оцінювач не завжди є правильним інструментом. Якщо ваші критерії є загальними, наприклад загальна корисність, достатньо добре налаштованого проприетарного оцінювача чи існуючого відкритого оцінювача, який коштуватиме значно дешевше. Якщо ви не можете зібрати надійний набір даних із позначками від людей, ви не зможете перевірити жодного оцінювача, незалежно від того, чи був він фінтюнінований чи ні, тож спочатку вирішіть цю проблему. Крім того, якщо розподіл завдань постійно змінюється, специфічний характер фінтюнінованих оцінювачів означає, що вам доведеться часто їх перенавчати. Фінтюнінг виграшний тоді, коли критерії є спеціалізованими, обсяг оцінки великим, і вам потрібен контроль над версіонуванням, витратами чи конфіденційністю даних.
Примітка щодо витрат та операцій
Володіння суддею лише зміщує витрати, а не усуває їх. Ви обмінюєте плату за кожен виклик API на час роботи GPU, хостинг моделі та інженерні зусилля, необхідні для підтримки версійності та відтворюваності судді. Натомість ви отримуєте фіксовану версію моделі, яка не може змінитися під вашим керуванням, дані оцінки, які ніколи не залишають вашої інфраструктури, та можливість виконувати мільйони оцінок, не спостерігаючи за зростанням рахунків. Ставтеся до судді як до будь-якої іншої продуктивної моделі: фіксуйте її ваги, записуйте, яка версія дала які результати, та зберігайте набір метаоцінок, щоб майбутнє перенавчання можна було порівняти з поточним на рівних умовах.
Ключові висновки
- Людські оцінки залишаються точкою відліку, але лише після калібрування, наявності актуальних правил та постійного відстеження угод вони стають достатньо надійними для порівняння з будь-чим іншим.