Ross Nazarenko

Де фронтір? З RLHF в 2024 перейшли в RLVR в 2025. RLHF - це у нас є діалог, і кожне повідомлення експерти оцінюють по заздалегідь підготовленим критерія і кажуть, чому така оцінка. RLVR (reinforcement learning with verifiable rewards) - це ми перевіряємо відповідь моделі на критерії, де є обʼєктивна правда. Почалось це в кодінгу і математиці, бо код або працює, або ні. Модель (агент) потрапляє в середовище, де має набір інструментів (умовний калькулятор, або там можливість порухати шахи на дошці). І ми перевіряємо, чи 2+2 дорівнює 4 в кінці. Для дати, це означає, що нам треба помістити в таке саме середовище людину, і попросити у неї вирішити задачу, записуючи кожен її крок. Це є golden trajectory // oracle solution. Від звичайного tool use, індустрія пішла в більш складні кейси - step by step reasoning, free text output, etc.Зараз фронтір проходить довкола unverifiable domains (або шматків доменів, які мають багато субʼєктивності). Умовно - що таке гарний лендос? Ото ж. Scale опублікував RaR - rubrics as rewards. Це дозволяє враховувати не тільки аутпут, а проміжні кроки (що має бути в різонінгу, який стиль у таблиць і тд). Проблема з рубриками в тому, що вони стохастичні, бо побудовані як LLM judge. Здебільшого, люди просто запускали того джаджа 10-50-100-1000 разів і садили людину перевіряти результати, постійно модифікуючи інструкції джаджа. Зараз перемкнулись на наступну схему: - експерт створює 5-10-15 критеріїв (наступних кроків) - синтетично перетворюють це в 50 рубрик- запускають оцінку - відповіді джаджа вертають в пайплайн генерації джаджів - додають ще 10-30 рубрик - людина приходиться по результатам оцінки, і дає фідбек - фідбек улітає в пайплайн генерації джаджів - на виході чистий список, з яким погодилось декілька експертівСтаном на сьогодні, ускладнюють декілька штук, окрім рубрік: - комплексність синтетичного світу. Тепер це цілий набор інструментів і вони більш деталізовані. - кількість кроків - моделі класно справляються, коли це два-три кроки, а ось коли 7+ - то все сиплеться. Щоб ускладнювати світи, починають збирати форки даних - ту само проблему можно вирішити через кроки 1, 2, 3, а можна через 5, 6, 7. Це, в свою чергу, робить процес кратер дорожче, бо замі ми б легких задач з однією гілкою рішення, переходять до складних на 3-5-7 гілок. А кожна гілка - це валідація і алаймент. Що з цим робити - вже відомо, а розповім пізніше, як тікі запустимо це рішення. 👁️👄👁️

Давно тут не було ніц по темі. Сиджу в літаку, на шляху до 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 світи, менеджити людей, експериментувати з ревордами. Ну і там ще потроху.

Шукаємо на контракт мідлового фулстака. Команда, що створює AI-інфраструктуру для навчання та оцінки моделей, шукає тіммейта на part-time контракт (2-3 місяці) з можливістю переходу у full-time за кілька місяців.Основний фокус – створення POC-рішень для клієнтів.Технології та інструменти:Front-end: React (Next.js),  Zustand, Tailwind, Shadcn UIBack-end: Node.js (Nest.js), MongoDB, Firestore, PostgreSQLІнфраструктура: Google Cloud Platform (GCP), Vercel, DockerАналітика: PosthogТестування: Jest, PlaywrightІнше: Git, CI/CDЩо ти робитимеш:Розробка POC під конкретні задачі та швидкий вивід на ринокДодавання нового функціоналу на платформуНаписання та підтримка автотестівРобота з компонентними бібліотекамиІнтеграція сторонніх API та сервісівОбов’язково:Від 2 років комерційного досвідуЗдорове продуктове мислення – вміння оцінювати рішення не лише з технічного боку, а й з точки зору користувача та цінності для бізнесуБуде плюсом:Досвід запуску проектів з нуляДосвід побудови пайплайнів обробки даних та  парсерівЗнання Python (особливо FastAPI)Процес найму простий:Перегляд CV + GitHubДзвінок з командоюТехнічне інтерв’юПисати на пошту: [email protected]