>нанимаем инженера по ИИ >собираемся отправить предложение >спросите кандидата, знает ли он pytorch или веб-разработку >он не понимает >объясните различия между pytorch и веб-разработкой >он все еще не понимает >вытяните иллюстрированную диаграмму, объясняющую, что такое pytorch и что такое веб-разработка >он смеется и говорит: "я хороший инженер, сэр" >нанимайте его >импортируйте requests

Каждый человек, который требует вернуть 4o, психически болен, и мне надоело делать вид, что это не так.

Ладно, давайте поговорим о фреймворках, библиотеках, RL и о том, почему, вероятно, мне не нравится ваша любимая кодовая база RL. Да, включая ту самую. Необычно в RL то, что алгоритм — это легкая часть. GRPO — это однострочное уравнение на некоторых логарифмических вероятностях. Если у вас есть данные, вычислить потерю тривиально, и, предположительно, вы используете это с библиотекой обратного распространения по вашему выбору. Но в этом и проблема — получить данные. Это настоящая головная боль. В обычном RL вам нужно делать роллы, возможно, обрезать некоторые эпизоды и соответствующим образом обрабатывать концы. Если вы не хотите быть улиткой, вам нужно векторизовать среду и адаптировать алгоритм для этого. Если вы хотите сделать LLM, вам нужно сделать всю ерунду, которая позволяет LLM помещаться в память. Вам нужно быть осторожным с вашими подсказками, замаскировать правильные части для потерь. Вам нужен приличный генератор (vLLM), что затем делает обновление весов настоящей головной болью. Если вы хотите сделать многопользовательский многоповоротный LLM RL, лучше уж заняться судоку с коммитами. Хотя у нас много разногласий по поводу всего, что связано с RL, я думаю, что Pufferlib @jsuarez5341 прекрасно иллюстрирует эту точку. Это безусловно невероятно в том, что оно делает — обучение RL алгоритмов в смоделированных средах очень-очень быстро. Но большая часть его новизны — это чистая инфраструктура. Основные алгоритмы в значительной степени такие же, как были на протяжении многих лет, и я готов поспорить, что они составляют менее 10% от общего объема инженерных усилий. Естественно, это имеет последствия для кода, который вам нужно написать, чтобы сделать что-то большее, чем запуск встроенных примеров. Что я снова и снова обнаруживаю, так это то, что для многих достаточно нетривиальных (читай: интересных) исследовательских задач требуется примерно одинаковое количество времени, чтобы (a) написать это с нуля/из простых примитивов или (b) адаптировать существующий фреймворк для учета безумных идей. В первом случае вы сосредотачиваетесь на написании фактической логики. Во втором случае вы заставляете фреймворк позволить вам добавить логику. Я знаю, что мне нравится больше. Все это потому, что алгоритм — это легкая часть. Инфраструктура — это настоящая головная боль. Поэтому, когда у вас есть возможность выбора — используйте инструменты, которые упрощают инфраструктуру, и пишите цикл обучения сами. Не создавайте фреймворки, создавайте библиотеки. Вы поблагодарите себя позже. Большой привет моему научному руководителю магистратуры с тех пор, кто первым сказал мне бросить rllib и просто написать PPO сам в PyTorch. И @hallerite за вдохновение, чтобы наконец написать этот поток мыслей. Возможно, я напишу полноценный пост с примерами в какой-то момент в будущем, если люди этого потребуют.