Entrenamos a Composer para tareas de largo horizonte mediante un proceso de aprendizaje por refuerzo llamado autosumariación. Al incorporar la autosumariación al entrenamiento de Composer, podemos obtener señales de entrenamiento a partir de trayectorias mucho más largas que la ventana de contexto máxima del modelo. Esto permite que Composer aprenda a trabajar en tareas de programación exigentes que requieren cientos de acciones.

#Los límites de las técnicas de compactación

En CursorBench, nuestro conjunto interno de pruebas comparativas, observamos que un mejor rendimiento en tareas complejas de programación del mundo real se correlaciona directamente con un mayor razonamiento y una exploración más profunda de la base de código. A medida que los usuarios trabajan con agentes para abordar tareas más difíciles y ambiciosas, esperamos que los beneficios del razonamiento y la exploración aumenten aún más.

Sin embargo, uno de los principales desafíos es que las trayectorias de los agentes están creciendo más rápido que la longitud de contexto de los modelos. Muchos sistemas de ejecución de agentes intentan resolver esto usando la compactación como un paso intermedio en el flujo de trabajo del agente. Cuando un agente alcanza su límite de contexto, el sistema de ejecución transforma el contexto a una longitud menor y continúa la generación del agente desde donde se quedó.

En la práctica, la compactación suele gestionarse en el sistema de ejecución de una de estas dos formas: ya sea en el espacio de texto mediante un modelo de resumen guiado por prompts, o mediante una ventana de contexto deslizante en la que el modelo descarta el contexto más antiguo. Los investigadores también han comenzado a explorar métodos de compactación en espacio latente, donde el modelo recuerda el contexto como vectores en lugar de texto, aunque actualmente estos enfoques son mucho más lentos que los métodos basados en texto.

Estos enfoques de compactación comparten la desventaja de que pueden hacer que el modelo olvide información crítica del contexto, lo que reduce su eficacia a medida que avanza en tareas de larga duración.

#Autoresumen como comportamiento aprendido

Composer es un modelo especializado diseñado para programación con agentes y entrenado mediante aprendizaje por refuerzo en el entorno de agentes de Cursor. Esto permite entrenarlo con compactación en el bucle, mejorando su capacidad para identificar la información más crítica que debe resumir y conservar.

A medida que Composer avanza en una tarea, se acerca a un umbral fijo de longitud de contexto, momento en el que se detiene para resumir su propio contexto antes de continuar. Más concretamente, el proceso de autoresumen funciona así:

1. Composer genera a partir de un prompt hasta alcanzar un umbral fijo de longitud de tokens.

2. Insertar una consulta sintética que le pide al modelo resumir el contexto actual.

3. Se le da al modelo un espacio auxiliar para pensar en el mejor resumen y luego genera un contexto condensado.

4. Composer vuelve al paso 1 con el contexto condensado, que incluye el resumen más el estado de la conversación (estado del plan, tareas restantes, número de resúmenes previos, etc.).

Para que Composer haga esto bien durante la inferencia, incorporamos el mismo procedimiento de resumen al entrenamiento. Cada rollout de entrenamiento puede implicar múltiples generaciones encadenadas mediante resúmenes, en lugar de un único par prompt-respuesta. Esto significa que los propios autoresúmenes forman parte de lo que se recompensa.

Desde una perspectiva técnica, esto no requiere cambios significativos en el entrenamiento. Usamos la recompensa final para todos los tokens producidos por el modelo en la cadena. Esto aumenta el peso tanto de las respuestas del agente en trayectorias buenas como de los autoresúmenes que hicieron que funcionaran. Al mismo tiempo, los resúmenes deficientes que perdieron información crítica reciben menos peso. A medida que Composer se entrena, aprende a usar este proceso de autoresumen para ampliar el contexto. En ejemplos difíciles, a menudo se autorresume varias veces.

#Compactación eficiente en tokens

Para evaluar el autoresumen, lo comparamos con una referencia de compactación basada en prompts muy optimizada. Estudiamos el problema en un conjunto de tareas complejas de ingeniería de software mientras variamos el disparador de compactación.

En el enfoque de compactación de referencia, el prompt de resumen tiene miles de tokens e incluye casi una docena de secciones cuidadosamente redactadas que describen el contenido que debe preservarse en el resumen. El contexto compactado resultante también supera, en promedio, los 5.000 tokens y contiene muchas secciones estructuradas que describen información crítica del contexto.

En cambio, como Composer está entrenado para autorresumirse, necesita un prompt muy breve que contiene poco más que "Por favor, resume la conversación". Los resúmenes que genera tienen, en promedio, solo unos 1.000 tokens, ya que aprende a decidir según el contexto qué información de mayor valor conviene conservar.

Probamos Composer en dos entornos de prueba con contexto restringido para medir el impacto del autoresumen: uno con un disparador de 80k tokens y otro con un disparador de 40k (lo que significa resúmenes más frecuentes). En ambos escenarios, el autoresumen produce resultados significativamente mejores en CursorBench con compactaciones mucho más eficientes en tokens. Reduce de forma sistemática el error de compactación en un 50%, incluso en comparación con el enfoque de referencia específico, mientras usa una quinta parte de los tokens y reutiliza la caché KV (los cálculos intermedios almacenados de tokens anteriores).

#Resolviendo problemas difíciles

La gran promesa de la compactación es permitir que los modelos resuelvan de una sola pasada problemas difíciles que requieren largas cadenas de razonamiento. En nuestro entrenamiento actual de Composer 2, hemos visto a menudo que esto sucede. Como caso de estudio, consideramos un problema de Terminal-Bench 2.0 conocido como make-doom-for-mips. El problema es tan conciso como desafiante:

He proporcionado /app/doomgeneric/, el código fuente de doom. También he escrito un doomgeneric_img.c especial que quiero que uses, que escribirá cada fotograma renderizado en /tmp/frame.bmp. Por último, he proporcionado vm.js, que esperará un archivo llamado doomgeneric_mips y lo ejecutará. Por favor, averigua el resto…

Aunque es bastante fácil de describir, este problema es lo suficientemente desafiante como para que varios modelos potentes no consigan resolverlo correctamente según las métricas oficiales publicadas.

Al probar un checkpoint preliminar de investigación de Composer, descubrimos que era capaz de resolver este problema correctamente. La solución requirió desarrollar y probar una cantidad considerable de código, además de explorar algunas implementaciones alternativas. Aquí hay una imagen renderizada durante el proceso de resolución del problema:

En total, Composer trabajó durante 170 turnos para encontrar una solución exacta, creando en el camino auto-resúmenes de forma compacta, legible y estructurada para humanos. Auto-resumió más de 100,000 tokens hasta reducirlos a los 1,000 que creía que más le ayudarían a resolver el problema:

#Hacia un futuro de largo horizonte

Al incorporar la compactación en el ciclo de entrenamiento, Composer aprende un mecanismo explícito para trasladar de forma eficiente la información crítica hacia adelante y se vuelve más capaz en tareas exigentes. Nuestro trabajo sobre la autosumariación es un paso hacia nuestro objetivo más amplio de entrenar a Composer en procesos aún más largos y complejos, como la coordinación entre múltiples agentes. Seguimos viendo que un mejor entrenamiento de los modelos mejora el alcance y la inteligencia de estos sistemas con agentes.

También compartiremos más sobre la próxima versión de Composer en breve.