> contratar a un ingeniero de IA > a punto de enviar una oferta > pregúntele al candidato si es pytorch o desarrollador web >No entiende >Explicar las diferencias entre Pytorch y Web Dev >Todavía no lo entiende > diagrama ilustrado que explica qué es pytorch y qué es web dev >Se ríe y dice "Soy un buen ingeniero, señor" > lo contratan >solicitudes de importación

Cada persona que exige traer de vuelta a 4o es un enfermo mental, y estoy cansado de fingir lo contrario

Bien, hablemos de marcos, bibliotecas, RL y por qué probablemente no me guste tu base de código RL favorita. Sí, incluido ese. Lo inusual de RL es que el algoritmo es la parte fácil. GRPO es una ecuación de una sola línea en algunos logprobs. Si tiene los datos, calcular la pérdida es trivial y presumiblemente lo está usando con una biblioteca de backprop de su elección. Pero ese es el problema: obtener los datos. Es un dolor en el culo. En RL regular tienes que hacer despliegues, tal vez truncar algunos episodios, y manejar los extremos en consecuencia. Si no quieres ser un caracol, querrás vectorizar el entorno y adaptar el algoritmo para eso. Si quieres hacer un LLM, necesitas hacer todas las tonterías que hacen que los LLM quepan en la memoria. Debe tener cuidado con sus indicaciones, enmascarar las partes correctas para la pérdida. Necesita un motor de generación decente (vLLM), lo que hace que sea una molestia actualizar los pesos. Si desea hacer LLM RL de varios agentes y turnos, también podría cometer sudoku. Si bien tenemos muchos desacuerdos sobre casi cualquier cosa relacionada con RL, creo que Pufferlib de @jsuarez5341 ejemplifica este punto maravillosamente. Sin duda, es increíble en lo que hace: entrenar algoritmos de RL en entornos simulados muy, muy rápidamente. Pero la mayor parte de su novedad es pura infraestructura. Los algoritmos centrales son en gran medida los mismos que han sido durante años, y estoy dispuesto a apostar que representan menos del 10% del esfuerzo total de ingeniería. Naturalmente, esto tiene implicaciones en el código que necesita escribir para hacer algo más allá de ejecutar los ejemplos integrados. Lo que encuentro una y otra vez es que para muchos problemas de investigación suficientemente no triviales (léase: interesantes), se necesita una cantidad similar de tiempo para (a) escribir la cosa desde cero / a partir de primitivas simples, o (b) adaptar un marco existente para acomodar ideas locas. En el primero, te enfocas en escribir la lógica real. En este último, se discute el marco para permitirle agregar la lógica. Sé lo que me gusta más. Todo esto se debe a que el algoritmo es la parte fácil. La infraestructura es el dolor en el culo. Entonces, siempre que esté en condiciones de elegir, use las herramientas que simplifican la infraestructura y escriba el ciclo de capacitación usted mismo. No construyas frameworks, construye bibliotecas. Te lo agradecerás más tarde. Un gran saludo al supervisor de mi maestro de antaño, quien fue el primero en decirme que dejara rllib y simplemente escribiera PPO yo mismo en PyTorch. Y @hallerite por inspirarme a escribir finalmente esta diatriba. Podría escribir una publicación de esfuerzo adecuada con ejemplos en algún momento en el futuro si la gente lo exige.