Lean4AgenticRL: LAR-27B logra un 77,3% en TerminalBench-2.1 con recompensas formales

El equipo detrás de Lean4AgenticRL propone una forma de entrenar agentes LLM que no se limita al resultado final, sino que también valora la calidad de los pasos intermedios. Esos pasos se verifican de manera formal, mediante un esquema en Lean4. Con el framework se entrenaron los modelos LAR-9B y LAR-27B. La versión mayor alcanzó un 77,3% en TerminalBench-2.1. De media, los modelos superaron al modelo base en un 9,89%, y al mejor de los modelos de tamaño comparable que conocen los autores, en un 5,07%.

El problema: el agente aprende a partir de la puntuación final

Las tareas agénticas en desarrollo de software y trabajo con terminal son largas. El agente lee el repositorio, ejecuta comandos, edita archivos, lanza tests, da marcha atrás y vuelve a intentarlo. Los LLM actuales para estos escenarios suelen pasar por un reentrenamiento con RL a gran escala. Según los autores, en ese proceso domina la outcome reward: una recompensa por el resultado, por ejemplo, por los tests superados.

Esta señal tiene un defecto evidente. Llega al final y no dice cuál de las decenas de pasos fue acertado y cuál sobraba. Las llamadas a herramientas, en el nivel inferior, y las etapas del flujo de trabajo, en el intermedio, casi no reciben una recompensa propia. Los autores consideran que esto hace el entrenamiento menos eficiente.

Cómo funciona Lean4AgenticRL

El enfoque se construye en torno a una formalización en Lean4. Los autores afirman que es el primer framework en el que las recompensas de proceso multinivel para RL agéntico abierto se apoyan en un único esquema de Lean4. La cadena es la siguiente.

Primero se construye un problem-specific workflow, es decir, un flujo de trabajo adaptado a cada tarea. Debe mantener el equilibrio entre las capacidades propias del agente y su controlabilidad: no se encorseta al agente con un guion rígido, pero se le da una estructura que permite verificar su comportamiento.

Después se formaliza el workflow y se asignan recompensas en varios niveles. Esto permite verificar las acciones del agente dentro de un harness universal. Para el entrenamiento se usa GRPO con normalización por etapas del workflow. La idea es comparar y promediar la señal dentro de cada etapa, y no sobre toda la trayectoria a la vez.

Parámetros clave del trabajo:

• framework: Lean4AgenticRL, con recompensas en tres niveles (llamada a herramienta, etapa del workflow y resultado final);
• algoritmo: workflow-stage-normalized GRPO;
• modelos: LAR-9B y LAR-27B;
• mejor resultado: 77,3% para LAR-27B en TerminalBench-2.1;
• mejora respecto al modelo base: 9,89% de media;
• ventaja sobre el segundo mejor modelo de tamaño comparable: 5,07%.

Qué muestran las cifras

Un 77,3% en TerminalBench-2.1 para un modelo de 27.000 millones de parámetros parece un resultado sólido. Pero el resumen del artículo no incluye los detalles necesarios para evaluarlo con precisión. No se indica el modelo base. No se especifica el conjunto completo de benchmarks con los que se calculó la media. No se aclara si el 9,89% y el 5,07% son puntos porcentuales o magnitudes relativas. Tampoco se dice cuál es exactamente el «segundo mejor modelo». Mientras no se analice el texto completo del artículo, conviene leer estas cifras como una afirmación de los autores y no como una comparación independiente.

Aun así, la dirección es clara. Si las recompensas por pasos pueden obtenerse de forma verificable, sin un modelo de recompensa entrenable y sin la evaluación ruidosa de otro LLM, la señal de proceso se vuelve más barata y fiable. En eso se apoya la apuesta por los métodos formales.

Qué deberían hacer los equipos con esto

Para quienes reentrenan agentes por su cuenta en tareas de SWE y de terminal, la conclusión principal es de ingeniería: conviene mirar la estructura de la trayectoria y no solo el pass/fail final. Incluso sin Lean4, resulta útil etiquetar las etapas típicas (exploración, edición, verificación) y medir el progreso en cada una.

Conviene esperar al texto completo y, si los autores lo publican, al código y a los pesos de LAR-9B/27B. Entonces se podrá comprobar cuánto trabajo exige formalizar el workflow para una nueva clase de tareas y si la mejora se mantiene fuera de los benchmarks de terminal. El coste de ese etiquetado determinará si el enfoque se convierte en una herramienta de trabajo o se queda en una demostración de investigación.