Давно тут не було ніц по темі. Сиджу в літаку, на шляху до ICLR. 20 годин дорога, а все тому, що у нас прийняли наші наукові статті, а декілька членів команди запросили провести воркшопи. Сідайте зручніше, поговоримо за стан ринку даних та А(G)I. Претрейнінг закінчився. По мірках індустрії, можна сказати - доволі давно. Фокус на мідтрейнінгу і RL environments. В цілому, ніхто не відмовився від ідеї того, що без різонінгу чуда не буде, але рецепт пошуку цього різнонінгу трошки інакший. Замість one shot тренування через SFT (пара питання-відповідь), індустрія погодилась, що треба робити багатокрокове навчання. На практиці, RL світ має в собі набір задач та інструменти їх виконання. Агент отримує задачу. І починає крок за кроком її виконувати. Найскладніше - побудувати оціночні критерії. Як зрозуміти, що агент робить те, що робити треба? Почалось все з verifiable domains - код і математика. Критерій - це хардкодом прописані правила. Наприклад, не вказавши FROM table_x - sql кверя не спрацює. Для такої оцінки, нам не треба LLM-as-a-judge. Для такої оцінки - нам треба люди, які будуть писати ці критерії, запускати агента, дивитись де він облажався, міняти критерії і так по колу. Далі до лаб дійшло, що будь-який домен має both - verifiable and unverifiable частини. Як тільки це зʼясувалось, ми побачили швидкий ріст в медицині, лайф-сайнсі, лігалі і інших (раніше) недоторканних доменів. Тут все ще є куди рости, і основних обмежень тут два: - треба навчитись перекладати те, що традиційно вважається «наукою» в набор готових правил - або зменшувати шум (= покращувати точність) для unverifiable складових. Умовно, пацієнту з діагнозом Х треба виписати лікі Y - це правило, яке перевіряється наступним чином: - (агент робить діагностику) - агент створює замовлення на ліки (бажано використовуючи АРІ коли схожі на систему в якій лікар виписує лікі) - ми перевіряємо, чи в функції переданий правильний діагноз, і правильна назва лік. Запускаємо агента 10-100-1000 разів, і руками переглядаємо результат. Чому руками? Бо модель може сказати «ібупрофен» і якщо першочергово ми сказали, що тільки «аспірин» є прийнятним - то ібупрофенбуде зарахований як помилка. Тому людина має глянути і додати «аспірин», як прийнятий варіант. І це - verifiable. А тепер модель може сказати - «пий аспірин два рази на день дві таблетки» або ж «в цьому випадку, варто приймати пігулки аспірину двічі на день в дозуванні XYZ, і якщо через 3 дні стан не покращиться - треба звернутись до лікаря». Тут вже мова про емпатію і правила не напишеш, доводиться давати оціночне судження по шкалі від 1 до 10. Але ж скільки людей - стільки і думок. І хоча можна назбирати велику вибірку - це і є проблема шуму в тренуванні. А далі зʼявиться ще проблема - за виконання яких кроків яку винагороду ми даємо моделі? Для цього треба робити рекорд функцію. І тут ми приходимо до найцікавішого. Scale з ринку витиснув Mercor. Їх швидкість і якість була краща за Scale, за рахунок старту з чистого аркушу. Вони побудували набагато кращі інструменти для аналізу даних і зробили це швидко. Але Mercor (як і Scale) ніц не розуміють в доменах. До чого тут домени?Щоб побудувати реворд - треба доволі багато ітерацій. Ітерацій, де ти будуєш той реворд, дивишся як міняється відповідь моделі в результаті перетренування, і міняєш дизайн. Це означає - що треба одночасно розумітись на тренуванні моделей, а ще і на домені (олсо, ще одна причина чому все з кодінгу почалось - бо кодити вони всі вміють самі).І тут можна було б сказати - тю, так Mercor може ж купити собі доменних експертів в команду. Може, але рісьорч + фінанси, це напрочуд непопулярний стек. І таких людей не дуже багато, мʼяко кажучи. І ось виходить, що основні проблеми в індустрії: - таланти, яких геть не вистачає - а якщо їх не вистачає, ми намагаємось будувати інфру і закривати той гєп технологіями - а щоб будувати інфру, треба зараз одночасно менеджити GPU, збирати RL світи, менеджити людей, експериментувати з ревордами. Ну і там ще потроху.