>Наймання інженера зі штучного інтелекту >Ось-ось надішлемо пропозицію >Запитайте кандидата, чи є він pytorch або веб-розробником >Він не розуміє >Поясніть різницю між pytorch і веб-розробником >Він досі не розуміє цього >Витягніть ілюстровану діаграму, яка пояснює, що таке pytorch і що таке web dev >Він сміється і каже: «Я хороший інженер,» >найміть його > запитів на імпорт

Кожна людина, яка вимагає повернути 4о, психічно хвора, і я втомився вдавати протилежне

Давайте поговоримо про фреймворки, бібліотеки, RL і про те, чому мені, ймовірно, не подобається ваша улюблена кодова база RL. Так, в тому числі і цей. Незвичайність RL полягає в тому, що алгоритм є легкою частиною. GRPO — це однолінійне рівняння на деяких логарифмічних зондах. Якщо у вас є дані, обчислення втрати є тривіальним, і тоді, ймовірно, ви використовуєте їх з бібліотекою backprop на ваш вибір. Але в цьому і полягає проблема – отримання даних. Це біль у попі. У звичайному RL вам доведеться робити викочування, можливо, скоротити деякі епізоди і відповідно обробляти кінці. Якщо ви не хочете бути равликом, вам захочеться векторизувати середовище та адаптувати алгоритм для цього. Якщо ви хочете зробити LLM, вам потрібно зробити всі дурниці, які змушують LLM поміщатися в пам'ять. Потрібно уважно ставитися до своїх підказок, маскувати правильні деталі для програшу. Вам потрібен двигун пристойного покоління (vLLM), який потім ускладнює оновлення ваг. Якщо ви хочете зробити багатоагентний багатоходовий LLM RL, ви також можете виконати sudoku commit. Хоча у нас є багато розбіжностей майже з усього, що пов'язано з RL, я думаю, що Pufferlib від @jsuarez5341 чудово ілюструє цей момент. Він, без сумніву, неймовірний у тому, що він робить - дуже і дуже швидко тренує RL algos на змодельованих середовищах. Але більша частина його новинки – це чиста інфра. Основні алгоритми в основному такі ж, якими вони були протягом багатьох років, і я готовий посперечатися, що вони становлять менше 10% від загальної інженерної роботи. Звичайно, це впливає на код, який вам потрібно написати, щоб зробити щось, крім запуску вбудованих прикладів. Я знову і знову виявляю, що для багатьох достатньо нетривіальних (читай: цікавих) дослідницьких проблем потрібно стільки ж часу, щоб (а) написати річ з нуля / з простих примітивів, або (б) адаптувати існуючу структуру для розміщення божевільних ідей. У першому випадку ви зосереджуєтеся на написанні справжньої логіки. В останньому випадку ви скручуєте фреймворк, щоб дозволити вам додати логіку. Я знаю, що мені більше подобається. Все це тому, що алгоритм – це найпростіша частина. Інфра – це біль у попі. Тому щоразу, коли у вас є можливість вибору - використовуйте інструменти, які спрощують інфрачервону інфраструктуру, і напишіть тренувальний цикл самостійно. Не будуйте фреймворки, а створюйте бібліотеки. Ви подякуєте собі пізніше. Велике спасибі моєму керівнику Master's ще з тих часів, який був першим, хто сказав мені кинути rllib і просто написати PPO самому в PyTorch. І @hallerite за те, що надихнули мене нарешті написати цю фразу. Можливо, в якийсь момент у майбутньому я напишу відповідний пост з прикладами, якщо люди цього вимагають.