El entrenamiento de RL para agentes es actualmente un desorden desorganizado de scripts personalizados y pensamiento optimista. La mayor parte de lo que vemos en flujos de trabajo “agénticos” es solo un bucle de prompts y una plegaria para que el modelo no se alucine hasta meterse en un callejón sin salida. Cuando la gente realmente intenta implementar Aprendizaje por Refuerzo (RL) para solucionar esto, por lo general termina con una pila monolítica de código donde el entorno, la lógica de evaluación y el runtime de ejecución están todos fusionados de una manera que hace que todo el conjunto sea frágil. Esto imposibilita cambiar un modelo, actualizar una dependencia o modificar una tarea sin reescribir la mitad de la base de código y pasar un fin de semana depurando por qué la señal de recompensa se fue a cero de repente.
La idea central aquí—separar el “qué” del “cómo” y el “dónde”—es ingeniería de software básica, pero ha sido extrañamente ignorada en el espacio de los agentes de RL. Piénsalo como una cocina profesional: el chef ejecutivo escribe el menú (Taskset), el chef de partida prepara los ingredientes (Harness) y el cocinero de línea gestiona la estufa real (Runtime). Al dividirlos, puedes cambiar tu runtime—digamos, pasar de un contenedor Docker local a una instancia en la nube remota—sin tener que tocar la definición de la tarea en sí. ¿Por qué seguimos fingiendo que codificar un prompt en un script de bash y llamarlo un “framework de agente” es una estrategia de entrenamiento viable? Es un movimiento de aficionado que crea una pesadilla de mantenimiento en el momento en que escalas más allá de un único ejemplo de juguete.
El verdadero valor, sin embargo, está en el servidor de interceptación. En la mayoría de las configuraciones de RL, grabar una traza para el entrenamiento es una pesadilla de registros frágiles y capturas de estado que a menudo se rompen en el momento en que el entorno se actualiza. El enfoque de Prime Intellect de hacer proxy de las solicitudes (que básicamente es actuar como un intermediario para la recopilación de datos) permite crear trazas listas para el entrenamiento sin contaminar la lógica del entorno. Por supuesto, añadir una capa de proxy introduce un poco de latencia de red y otro punto de fallo en la pila (otra cosa más para que los SREs se quejen), pero es un intercambio justo por no tener que analizar manualmente los logs durante seis horas solo para descubrir por dónde se salió el modelo de la vía.
Este movimiento hacia la composibilidad es una jugada estratégica para la capa de infraestructura. Si la industria se decide por un estándar sobre cómo se definen y verifican las tareas agénticas, quien posea el framework del verificador poseerá el cuello de botella. La mayoría de los laboratorios están construyendo actualmente sus propios jardines amurallados, pero la fricción de hacerlo se está volviendo evidente. O quizás no—algunos laboratorios aman sus silos porque oculta cuánto se están basando en el azar. De cualquier manera, si esto gana tracción, convertirá el entrenamiento de agentes en una operación plug-and-play en lugar de un proyecto de doctorado. Cambia el enfoque de “¿cómo ejecuto esto” a “cuál es la señal de recompensa real”, que es donde ocurre el verdadero trabajo intelectual.
Nos estamos moviendo hacia un mundo donde el verificador es más importante que el modelo en sí. Si no puedes verificar con precisión una tarea agéntica compleja de múltiples pasos, no puedes proporcionar una señal de recompensa, y sin una señal de recompensa, el RL es solo adivinación costosa con mucho consumo de GPU. Para el Q4, veremos el primer modelo de RL agéntico de código abierto que supere a GPT-4o en el leaderboard de SWE-bench Lite utilizando exactamente este framework. Esto no se trata solo de una nueva librería; se trata de si podemos realmente escalar la inteligencia agéntica más allá de la simple ingeniería de prompts. Puedes leer el desglose técnico completo en el anuncio de MarkTechPost.
Una limpieza necesaria de un cuarto desordenado.
