Predecir los resultados de los comandos ayuda en el entrenamiento posterior del agente
Un agente que trabaja en una terminal intenta ejecutar un programa. Envía un comando, lee un mensaje de error y elige la siguiente acción. Para ello, debe relacionar el resultado con el comando anterior: reconocer si faltaba un archivo, memoria o el argumento adecuado. De eso depende que el siguiente intento mejore la situación.
Un agente así puede aprender a partir de los registros del trabajo de un modelo más capaz. El registro contiene tanto los comandos como las respuestas de la terminal, pero el entrenamiento suele evaluar únicamente la predicción del texto escrito por el agente. Las respuestas de las herramientas están disponibles como contexto para las decisiones posteriores. Sin embargo, el modelo no tiene que predecir por sí mismo qué respuesta seguirá a un comando determinado.
Tras imitar las demostraciones, el agente puede seguir aprendiendo mediante sus propios intentos. Sin embargo, dos modelos que reproduzcan igual de bien las acciones exitosas pueden reaccionar de forma distinta ante situaciones nuevas. Por tanto, una evaluación realizada inmediatamente después de aprender de las demostraciones puede no mostrar qué modelo será un mejor punto de partida para el entrenamiento posterior.
Esta relación se estudia en Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL. Es un preprint del 17 de septiembre de 2026 sobre el entrenamiento de agentes basados en modelos de lenguaje. Juzheng Zhang, Disha Makhija, Manoj Ghuhan Arivazhagan, Vinayshekhar Bannihatti Kumar y Rashmi Gangadharaiah proponen ActObs: durante el aprendizaje a partir de demostraciones, el modelo también predice las respuestas del entorno, denominadas en adelante observaciones. El algoritmo posterior de aprendizaje mediante recompensas sigue siendo el mismo.
La respuesta de la terminal puede ser contexto o un objetivo de entrenamiento
El aprendizaje a partir de demostraciones ya preparadas es aquí una variante del ajuste fino supervisado, abreviado SFT: el registro muestra al modelo la secuencia de acciones deseada y el entrenamiento ajusta sus parámetros. El texto se divide en tokens, las unidades que procesa el modelo. En cada posición evaluada, el modelo debe predecir el siguiente token a partir del texto anterior.
El enmascaramiento de la pérdida determina qué posiciones influyen en la función de pérdida, es decir, la evaluación numérica del error utilizada para modificar los parámetros. En la variante ActionSFT se evalúan los tokens del agente, que incluyen su razonamiento y sus comandos. Los tokens de las respuestas de la terminal permanecen en la secuencia, pero no son objetivos de predicción. Excluirlos de la pérdida no los elimina del contexto.
ActObs incluye ambos grupos en la pérdida. El modelo aprende a predecir un comando y, a continuación, el texto de la respuesta de la herramienta que sigue a ese comando. La instrucción inicial de la tarea sigue excluida de la evaluación. Durante el funcionamiento real, la respuesta sigue procediendo de la herramienta; ActObs no sustituye la ejecución del comando por texto inventado por el modelo.
La predicción se evalúa mediante la entropía cruzada: cuanto menor sea la probabilidad que el modelo haya asignado al token presente en la demostración, mayor será la penalización. En la variante básica de ActObs, cada token de acción y de observación tiene el mismo peso. La media se calcula sobre todos los tokens evaluados, no sobre grupos de «comandos» y «respuestas» con pesos equivalentes. Por tanto, una respuesta más larga de la terminal aporta más términos a la pérdida. La ecuación 1 del artículo define esta normalización.
Los mismos dos comandos proporcionan tres o cinco objetivos de predicción
El siguiente ejemplo se ha preparado para explicar el método; no procede del experimento. El usuario pide leer el número guardado en un archivo. Una herramienta en miniatura admite dos comandos: list indica el nombre del archivo y read lee el archivo especificado. En la demostración se registró:
agente: list
herramienta: report.csv
agente: read report.csv
herramienta: 42
Para el cálculo, supongamos una forma hipotética de dividir el texto en tokens (un tokenizador), en la que list, read, report.csv y 42 son tokens individuales. Omitimos los marcadores de rol. La secuencia contiene cinco posiciones: tres pertenecen al agente y dos a la herramienta. report.csv aparece dos veces y ocupa una posición distinta en cada ocasión.
ActionSFT evalúa la predicción de list y, después, de read y del argumento report.csv. Cada una de estas tres posiciones contribuye con 1/3 a la pérdida media. Las dos respuestas de la herramienta tienen peso cero. El modelo ve el primer report.csv antes de predecir el comando read, pero no se evalúa su predicción de ese nombre como resultado de list.
ActObs procesa exactamente el mismo registro, pero evalúa las cinco posiciones, cada una con una contribución de 1/5. La primera diferencia aparece en la respuesta a list: el modelo recibe ahora una señal de entrenamiento para predecir report.csv. La segunda aparece en 42, que debe predecir después de read report.csv. En ambos casos, solo ve la parte anterior del registro y, durante el entrenamiento, las posiciones sucesivas reciben el texto anterior real de la demostración.
Los comandos corresponden al conjunto de tokens de acción del algoritmo, y los resultados de la herramienta al conjunto de tokens de observación. Cambia su contribución a la pérdida; ninguna parte de la demostración se vuelve a muestrear ni se elimina. La señal en el resultado de read exige ajustar la predicción al efecto del comando anterior. Esto no significa que el modelo pueda conocer cualquier contenido de un archivo que aún no se ha leído: la información impredecible puede seguir causando errores.
Cinco tokens y dos llamadas son solo una simplificación didáctica. En el estudio, las secuencias contienen razonamiento, comandos completos y respuestas largas de la terminal. ActObs no añade demostraciones ni pasadas del modelo separadas, porque las respuestas de las herramientas ya se procesaban como contexto. Todo el entrenamiento sigue incluyendo la recopilación de demostraciones y la posterior ejecución de tareas por el agente; su presupuesto se indica más abajo.
La ventaja apareció tras el mismo entrenamiento con GRPO
Después del SFT, los autores aplicaron GRPO, un algoritmo de aprendizaje por refuerzo (RL) que compara las recompensas de un grupo de intentos de realizar la misma tarea. Aquí, un intento abarca toda la interacción con el terminal, es decir, un rollout. Un verificador automático concede una recompensa por completar la tarea. En esta etapa ambos modelos tienen el mismo algoritmo, datos y presupuesto, y ActObs ya no añade una pérdida por predecir las respuestas del entorno.
pass@k indica la probabilidad de obtener al menos una ejecución correcta entre un número determinado de intentos; un resultado mayor es mejor. pass@1 se refiere a un único intento, aunque su tasa de éxito puede estimarse a partir de muchas ejecuciones.
El resultado de transferencia más claro corresponde a Qwen3-4B en aider-polyglot, un conjunto de tareas de edición de código en varios lenguajes de programación, comprobadas mediante pruebas unitarias. Tras el mismo calendario de GRPO, el modelo final que partió de ActionSFT alcanzó un 9,7% de pass@1, y el que partió de ActObs, un 13,9%. La diferencia fue de 4,2 puntos porcentuales. Las tareas de esta evaluación no aparecían ni en las demostraciones de SFT ni en el entrenamiento con GRPO. Antes de GRPO, la variante ActionSFT tenía el resultado más alto en esta evaluación. pass@1 se estimó a partir de cuatro intentos por tarea; no se seleccionó la mejor de las cuatro respuestas.
Un experimento separado con el Qwen3-8B, de mayor tamaño, en tareas de terminal reveló un compromiso: ActObs empeoró el resultado de un único intento, pero mejoró la probabilidad de éxito con varios intentos. Por tanto, no fue una inicialización uniformemente mejor para todos los presupuestos. Es una diferencia relevante entre un sistema que debe realizar una tarea una sola vez y otro que puede repetir los intentos y comprobar sus resultados.
Detalles del experimento
Fuente de la configuración y los resultados: §3.1, tabla 1 y apéndices A–B del preprint v1. Las comparaciones principales se refieren a los checkpoints finales, es decir, versiones guardadas de los parámetros tras el mismo calendario de entrenamiento. Los autores los describen como políticas finales y comparan el estado al terminar el entrenamiento; las cifras siguientes no son máximos extraídos de la curva de entrenamiento.
SFT. Qwen3-4B y Qwen3-8B se entrenaron con 50 mil registros de trabajo en la terminal de varios turnos, procedentes de la parte sintética de Nemotron-Terminal-Corpus. DeepSeek-V3.2 generó las demostraciones. El corpus contenía 0,71 mil millones de tokens, de los cuales aproximadamente el 45% eran observaciones. El entrenamiento duró una época, 781 pasos, con 64 ejemplos por lote (batch size) y un coeficiente máximo del paso de actualización de parámetros (learning rate) de 0,00001, que se redujo siguiendo un calendario cosenoidal. ActObs básico utilizó un peso de las observaciones de 1; ActionSFT, de 0. La normalización incluía el número de tokens de acción y el número ponderado de tokens de observación.
GRPO. A continuación se realizaron 135 pasos sobre 2392 tareas de Endless Terminals, sin solapamiento con el corpus de SFT. Se utilizaron 16 rollouts por tarea, batch size 32, learning rate 0,000001 y verificadores binarios. Los conjuntos de evaluación no se solapaban con ninguna de las dos etapas de entrenamiento. Estos rollouts no deben confundirse con las dos llamadas a la herramienta en miniatura del ejemplo.
Evaluación en terminal. Terminal-Bench 2.0 contenía 89 tareas. Cada checkpoint principal se evaluó con 16 intentos por tarea, reunidos en cuatro lotes lanzados por separado, de cuatro intentos cada uno. Se utilizó el agente terminus-2, los límites de tiempo oficiales y una configuración común para servir los modelos: un motor vLLM en ocho GPU A100, 12 intentos paralelos, un contexto de 40 960 tokens y una utilización de memoria de la GPU fijada en 0,90. La temperatura, parámetro que influye en la aleatoriedad de la selección de tokens, era de 0,6. Top-p limitaba el conjunto de muestreo a tokens con una probabilidad acumulada de al menos 0,95, y top-k, a los 20 tokens más probables. Los errores del modelo recibían cero; los errores de infraestructura se reintentaban una vez. La configuración para servir los modelos se fijó después de comparar nueve ajustes y se utilizó después para todos los métodos.
Evaluación de edición de código. Aider-polyglot incluía 225 tareas en seis lenguajes de programación, con cuatro intentos por tarea. La configuración para servir los modelos mencionada arriba corresponde a Terminal-Bench 2.0; no debe atribuirse automáticamente a la evaluación de aider.
Cada fila siguiente compara ActionSFT→GRPO con ActObs→GRPO en la misma configuración. La tabla incluye los resultados principales de GRPO estándar, sin la variante ECHO, que añade predicción de observaciones también durante RL.
| Modelo y evaluación | Métrica | ActionSFT→GRPO | ActObs→GRPO |
|---|---|---|---|
| Qwen3-4B, aider-polyglot, 4 intentos por tarea | pass@1 | 9,7 ± 0,6% | 13,9 ± 0,7% |
| Qwen3-4B, aider-polyglot, 4 intentos por tarea | pass@4 | 20,4 ± 0,9% | 25,3 ± 1,0% |
| Qwen3-4B, Terminal-Bench 2.0, 16 intentos por tarea | pass@1 | 5,6 ± 0,4% | 7,2 ± 0,4% |
| Qwen3-4B, Terminal-Bench 2.0, 16 intentos por tarea | pass@16 | 18,0 ± 1,4% | 19,1 ± 1,4% |
| Qwen3-8B, Terminal-Bench 2.0, 16 intentos por tarea | pass@1 | 12,3 ± 0,5% | 11,0 ± 0,5% |
| Qwen3-8B, Terminal-Bench 2.0, 16 intentos por tarea | pass@16 | 23,6 ± 1,2% | 27,0 ± 1,3% |
Para Qwen3-4B en aider-polyglot antes de RL, pass@1 era del 1,4 ± 0,3% tras ActionSFT y del 1,0 ± 0,3% tras ActObs. Por tanto, la ventaja posterior de ActObs no consistió simplemente en conservar un resultado inicial mejor.
Los valores después del signo ± representan un error estándar estimado mediante bootstrap: 20 mil remuestreos de los intentos manteniendo el mismo conjunto de tareas. Miden la incertidumbre debida al número limitado de ejecuciones del agente. No miden la variabilidad entre entrenamientos independientes ni entre distintos conjuntos de tareas. pass@k se calculó con un estimador que tiene en cuenta el número de éxitos en los intentos disponibles.
Controles y diagnósticos. La variante Obs→Act aprendía primero solo a predecir observaciones y después solo acciones; necesitaba dos épocas y no reprodujo la ventaja del aprendizaje conjunto con presupuestos de intentos mayores. Mezclar las respuestas entre demostraciones empeoró los resultados después de SFT. Son controles separados, no otros resultados principales de GRPO. El análisis de gradientes utilizó 256 demostraciones reservadas, y la evaluación de la predicción de observaciones, 300 registros de la parte de validación del corpus. Las mediciones de entropía, una medida de la dispersión de las probabilidades del siguiente token, en los modelos finales abarcaron 200 registros de evaluación por modelo. En el control de igualación de la entropía, se aumentó la temperatura de ActionSFT→GRPO de 0,6 a 0,64; esto no eliminó la diferencia en pass@16 en Qwen3-8B.
ActObs conserva la predicción de los efectos y más variantes de los comandos
Los autores comprobaron cómo predecían los modelos las respuestas de la terminal en demostraciones reservadas después de SFT. ActionSFT empeoraba esta capacidad respecto al modelo anterior a SFT, mientras que ActObs la conservaba y mejoraba. El efecto abarcaba el contenido real de los resultados, incluidos los errores y los mensajes del intérprete de comandos, y no solo el encabezado repetitivo de la respuesta de la herramienta.
El diagnóstico de gradientes, es decir, de las direcciones de cambio de los parámetros derivadas de la pérdida, ayuda a explicar por qué aprender solo los comandos no garantizaba esa capacidad. Durante SFT, la dirección que mejoraba la predicción de acciones dejaba rápidamente de coincidir con la que mejoraba la predicción de observaciones. ActionSFT omitía la segunda señal. ActObs la incluía durante todo el entrenamiento, aunque los resultados directos de ejecución de tareas tras SFT seguían siendo similares.
Después de GRPO, ActObs conservaba una entropía mayor, es decir, una mayor dispersión de las probabilidades del siguiente token. La diferencia era especialmente visible en las posiciones posteriores del comando, donde aparecen argumentos, opciones y rutas. Más variantes de este tipo seguían disponibles al muestrear el siguiente intento. Esto no significa que el agente descubriera más estrategias completamente distintas: el análisis de las ejecuciones exitosas apuntaba principalmente a diferencias en la realización de procedimientos similares.
Estas mediciones respaldan una explicación relacionada con la conservación de alternativas útiles, pero no demuestran que la entropía por sí sola sea responsable de la mejora. Aumentar la aleatoriedad del modelo ActionSFT hasta un nivel similar no reprodujo el resultado de ActObs. El cambio controlado de la máscara muestra la influencia del objetivo de SFT en los resultados posteriores; la cadena completa desde la predicción de observaciones hasta una acción exitosa concreta sigue siendo una interpretación respaldada por los diagnósticos.
Evalúa la inicialización después del entrenamiento posterior y con el presupuesto de intentos previsto
El estudio se limita a una familia de modelos en dos tamaños, demostraciones de un solo modelo y entrenamiento en la terminal. La transferencia a la edición de código amplía el alcance de la evaluación, pero no confirma que el método funcione en un navegador, una interfaz gráfica o robótica. Los autores también revelan diferencias entre los entornos de las distintas etapas: durante RL, los comandos se ejecutaban en un intérprete de comandos nuevo y no interactivo, mientras que la evaluación en terminal utilizaba una sesión persistente de tmux. Las comparaciones entre métodos dentro de cada etapa estaban controladas, pero esas diferencias pueden modificar los resultados absolutos. Los autores anuncian que el código y los artefactos detallados se publicarán tras la aceptación del artículo.
La evaluación de SFT debería tener en cuenta el efecto del RL posterior, porque un resultado similar después de las demostraciones no garantiza un efecto similar del entrenamiento posterior. Una prueba de ActObs en un entorno propio debería mantener los mismos datos y presupuesto, y después comparar los modelos tras completar todo el entrenamiento previsto. Dado que el modelo más grande del estudio mejoraba con varios intentos a costa de uno solo, hay que medir ambos resultados y el coste de repetir los intentos; pass@k no resuelve el problema de reconocer qué intento terminó correctamente.
Fuente: Juzheng Zhang y coautores, Don't Mask the Environment: Observation Supervision Changes How Agents Explore Under RL, arXiv:2609.20715v1, 2026. Reseña en polaco basada en el texto completo publicado con licencia CC BY 4.0.
Utilizo contenido generado por IA como parte de mi proceso de aprendizaje diario.