Un ingeniero de IA escribió una sola función de recompensa para equipos de agentes: la tasa de victorias subió del 51% al 90%

Un equipo de robots o de unidades de juego solo aprende a actuar de forma coordinada si se le indica a tiempo qué está haciendo bien. Esas indicaciones se llaman función de recompensa. Si solo se premia la victoria final, los agentes apenas entienden qué acciones de quién llevaron a ella.

Por eso los ingenieros añaden a mano incentivos intermedios y los rehacen desde cero cuando cambia el mapa o la composición del equipo. D. Urgun, de la Universidad de Karabük (Turquía), ha propuesto el método GARDEN, que delega ese trabajo en un modelo de lenguaje.

Va más allá de los sistemas anteriores: la recompensa se escribe una sola vez para toda una familia de escenarios similares y se traslada a los nuevos sin una sola corrección.

Qué se probó y qué cifras se obtuvieron

El método se probó en la biblioteca JaxMARL con dos benchmarks.

• Overcooked. Dos cocineros preparan una sopa en una cocina estrecha: echan ingredientes en la olla, sacan el plato listo y llevan el plato. La recompensa estándar da 20 puntos por plato y pequeñas bonificaciones por los pasos intermedios: 3 por cada ingrediente en la olla, 3 por el plato y 5 por la sopa terminada. La disposición de las mesas determina cómo se reparten el trabajo los cocineros.
• SMAX. Es una versión reescrita en JAX del StarCraft Multi-Agent Challenge: un grupo de unidades aliadas combate contra enemigos controlados por scripts integrados. La recompensa es 1 si los enemigos quedan destruidos y sobrevive al menos una unidad propia. La media por episodios coincide con el porcentaje de victorias. La bonificación estándar se concede por el daño causado a los enemigos.

Para la recompensa eran nuevos cuatro escenarios. En Overcooked, dos disposiciones de cocina: una con encimera divisoria y otra con encimera central. En SMAX, un combate contra un equipo ampliado de marines y otro con tipos y posiciones iniciales de unidades aleatorios. En ellos, el resultado total en Overcooked superó al de la recompensa estándar en un 58,2% y un 52,5%. El porcentaje medio de victorias en SMAX subió del 51,0% al 89,9%. Como comparación se tomaron dos enfoques con el mismo número de candidatos y de ejecuciones de prueba. El informe diagnóstico fijo logró un 84,2%, y la reflexión al estilo Eureka (el modelo corrige la recompensa a partir de las estadísticas de entrenamiento) logró un 79,2%.

Cómo busca el modelo qué falla en la recompensa

En la mayoría de los métodos anteriores, incluido Eureka, el formato de la retroalimentación está fijado de antemano: el modelo recibe curvas de entrenamiento resumidas y reescribe el código a partir de ellas. Si el problema de coordinación no se ve en esas curvas, pasa inadvertido. En GARDEN, el LLM-ingeniero trabaja como una persona en una terminal. A través de un shell de comandos restringido lee el código fuente del entorno y del algoritmo, la lógica de la recompensa estándar, las configuraciones, las trayectorias, las pérdidas y los checkpoints. Cuando lo necesita, escribe sus propios scripts de análisis. No se le da una lista de comprobaciones prefabricada.

Las hipótesis las verifica con entrenamientos de prueba. Son un número limitado de ejecuciones del borrador en uno de los escenarios de desarrollo, con el mismo algoritmo, el mismo presupuesto y la misma semilla aleatoria que en la evaluación final. A cada versión de la recompensa el modelo adjunta un informe breve: qué datos examinó, qué mecanismo supone y cuáles son los puntos débiles.

El proceso avanza por generaciones de candidatos:

• Cada candidato trabaja en una sesión independiente y no ve los borradores ni las pruebas de sus «hermanos» de generación. Sí tiene acceso a los resultados de las generaciones anteriores.
• Tras fijar la versión, se entrena y se evalúa en cada escenario de desarrollo.
• La recompensa final la elige una fórmula: la mejora media sobre la recompensa estándar en los escenarios de desarrollo. En caso de empate se mira el peor escenario, luego el resultado medio y después el identificador. Las preferencias del modelo y los datos de los escenarios nuevos no intervienen en la elección.
• El código elegido se congela, se calcula su hash y se entrenan agentes nuevos desde cero en los escenarios ocultos.

El modelo no conoce el número del escenario y debe deducirlo de la geometría del mapa o de la composición del equipo. Puede leer el código de la recompensa estándar, pero no puede llamarla desde su propio código. La «memoria» entrenable de la recompensa es limitada y se reinicia al comienzo de cada episodio. Los escenarios ocultos están protegidos mediante carpetas de trabajo depuradas y un registro de acciones.

Qué aporta en la práctica y dónde están los límites

La transferencia afecta aquí a la propia recompensa, no a las políticas ya entrenadas: en los mapas nuevos se vuelve a entrenar a los agentes. Los autores subrayan que lo que miden es la generalización de la señal de entrenamiento. Para los ingenieros, esto supone un ahorro: una única recompensa escrita automáticamente puede sustituir a la reescritura para cada disposición o composición de escuadra. Para la robótica y la logística, con configuraciones de equipo cambiantes, esto es especialmente relevante.

Hay limitaciones. Los experimentos cubren dos familias de tareas y cuatro escenarios ocultos. El autor no ofrece garantías de transferencia: la elección se basa en datos de desarrollo y los resultados en los escenarios ocultos no se conocen de antemano. Para que la comparación fuera justa, el shaping estándar de Overcooked se mantuvo constante, aunque en la configuración de referencia de JaxMARL decae. Probar el método en otros entornos tendrá que hacerlo la comunidad: el código, los prompts y las configuraciones están en el repositorio abierto DoganUrgun/GARDEN.