Cinco de nosotros, de la [Universidad del Valle de Guatemala](https://noticias.uvg.edu.gt/eficiencia-en-el-puerto-de-singapur-el-desafio-que-llevo-a-team-uvg-al-segundo-lugar-del-2025-winter-simulation-challenge/), entramos al [Winter Simulation Conference Simulation Challenge](https://meetings.informs.org/wordpress/wsc2025/simulation-challenge/) en Seattle. Ninguno había construido una simulación de eventos discretos (un modelo que avanza cada vez que pasa algo, como un buque que llega o un AGV que mueve un contenedor) antes de que empezara el año. Volvimos a casa con la medalla de plata. El problema era minimizar el tiempo total promedio que los buques pasan en una terminal de contenedores totalmente automatizada modelada según el Puerto de Tuas, en Singapur, la terminal totalmente automatizada más grande del mundo. Nuestra solución, la que se llevó el segundo lugar, es una política adaptativa que selecciona la heurística correcta para cada escenario, en lugar de tratar de encontrar la única heurística que maneje todo. ## Lo que rompió nuestra primera solución La competencia da a cada equipo el mismo hardware. Y hace cuatro preguntas por cada contenedor que llega. ¿Qué buque debe atracar primero? ¿Qué atracadero debe usar? ¿Qué AGV debe mover cada contenedor? ¿En qué bloque del patio debe quedar cada contenedor? La mayoría de equipos, nosotros incluidos durante las primeras tres rondas, construyen funciones de puntuación fijas para cada una de esas cuatro decisiones. Pesas el tiempo de espera, la distancia, la congestión y el balance de distribución, y luego eliges la opción con mayor puntuación cada vez. Funcionó, hasta que dejó de funcionar. Mientras más avanzábamos en la competencia, más obvio se volvía que un único conjunto de pesos manejaba algunos escenarios bien y otros mal. Una heurística ajustada para un horario de carga máxima era la herramienta equivocada para uno disperso. Estábamos tratando de encontrar *los* mejores pesos. El problema real era que ningún conjunto de pesos podía ser correcto en todos lados, y íbamos a seguir perdiendo puntos hasta que lo aceptáramos. Cada heurística es una página de un libro. El bandit lee el escenario y va a la página correcta. Esquema en planta de la terminal de contenedores modelada: 4 atracaderos con grúas pórtico arriba, carriles de tránsito de AGVs en medio, 16 bloques de patio abajo con contenedores apilados.

Esquema en planta de la terminal de contenedores modelada: 4 atracaderos con grúas pórtico arriba, carriles de tránsito de AGVs en medio, 16 bloques de patio abajo con contenedores apilados.

## Cómo llegamos ahí Todo empezó como una recomendación. Dos de nuestros profesores en UVG, la Mgtr. Dulce Chacón y la Mgtr. Ingrid de León, sugirieron que el equipo aplicara al Simulation Challenge. Los cinco (Rafael O'Meany, Juan Fernando Zúñiga, Kenneth Monterroso, Ángel Esquit y yo) aceptamos antes de que ninguno tuviera una idea clara de a qué nos estábamos comprometiendo. La primera ronda corrió en agosto de 2025. La mayor parte de lo que hicimos esa ronda fue aprender qué significaban en código *distribución de llegadas de buques* y *asignación de atracaderos*. Para las rondas uno a tres, nuestra solución fue una pila de funciones de puntuación fijas, una para cada uno de los cuatro problemas de decisión. La selección de buques puntuaba cada buque en espera por urgencia, equidad de cola, estimación del tiempo de servicio, banderas de viabilidad, y un filtro top-down que limitaba el número de buques que evaluábamos. La asignación de atracaderos puntuaba cada atracadero disponible por proximidad, congestión del lado del patio, y una reservación anticipada para buques grandes que llegarían pronto. La asignación de AGV puntuaba cada vehículo disponible por distancia, ETA, tiempo inactivo, y qué tan concentrados estaban los AGVs en una zona, con pesos adaptativos a la congestión que hacían la distancia más importante cuando el sistema estaba ocupado. La asignación de bloques de patio puntuaba cada bloque candidato por tiempo de transporte, tiempo de espera de la grúa de patio, la utilización actual del bloque, y una penalización de distribución sigmoidal que evitaba que descargáramos todos los contenedores de un buque en el mismo bloque. Para la ronda tres ya sabíamos que la ronda oculta (el escenario final que los jueces no habían publicado) casi con certeza iba a ser distinta a cualquier cosa para la que hubiéramos ajustado parámetros. La versión con reglas fijas iba a perder puntos ahí. Así que cambiamos el enfoque. Construimos un bandit contextual usando LinUCB. El modelo mental: imagina una máquina tragamonedas con siete brazos, donde jalar cada brazo corre la simulación con una estrategia distinta. El bandit lee la situación, apuesta por el brazo que espera que puntúe más alto, y actualiza sus probabilidades según el resultado. Siete brazos, cada brazo un conjunto de parámetros ajustado para un grupo específico de escenarios. Un vector de contexto de 28 características resumía el escenario al inicio de la simulación: seis para patrones de llegada de buques, once para distribución de carga por día de la semana, cuatro para concurrencia de atracaderos y activos, siete para variabilidad de flujo y carga. El bandit predecía el desempeño esperado de cada brazo dado el contexto, escogía el más alto, y cargaba ese conjunto de parámetros en las cuatro funciones de puntuación antes de que la simulación corriera. Lo difícil no fue el bandit. Fue el agrupamiento de escenarios que hacía que los siete brazos tuvieran sentido en primer lugar. Calculamos dos matrices de distancia euclidiana de 25 por 25, una sobre datos de llegadas de buques y otra sobre datos de transhipment, las fusionamos y agrupamos los escenarios por similitud. Algunos grupos estaban densamente clusterizados, lo que nos permitió especializar sus conjuntos de parámetros agresivamente. Otros grupos estaban dispersos, lo que forzó que sus conjuntos de parámetros fueran más generalistas. Una vez que los grupos eran estables, usamos optimización Bayesiana (una búsqueda inteligente que aprende de cada prueba dónde probar después, en vez de evaluar todas las combinaciones a la fuerza) para desarrollar los conjuntos de parámetros, enfocándonos en los cinco parámetros más influyentes (todos pesos de puntuación de bloques de patio, ya que la colocación en patio es lo que codifica la congestión futura del sistema). Cada conjunto de parámetros tomaba de cuatro a cinco días para optimizar en el hardware que teníamos, que era la restricción que limitaba qué tan agresivamente podíamos iterar. La simulación comienza y le pide al bandit un conjunto de parámetros. Carga datos de llegadas de buques, datos de transhipment, y estado del patio en una pipeline de características. Se construye un vector de contexto de 28 características y se pasa al modelo LinUCB. LinUCB predice el tiempo total esperado para cada uno de los siete conjuntos de parámetros dado este contexto. El brazo con la puntuación predicha más alta es escogido para este escenario. El conjunto de parámetros del brazo seleccionado se carga en las cuatro funciones de puntuación, y la simulación corre como un sistema heurístico el resto del escenario. Un miembro del equipo en el podio en Seattle presentando la diapositiva Optimization of the scoring functions. Dos jueces sentados a la derecha escuchan.

Un miembro del equipo en el podio en Seattle presentando la diapositiva Optimization of the scoring functions. Dos jueces sentados a la derecha escuchan.

En las rondas uno a tres ajustamos las cuatro funciones de puntuación manualmente para cada grupo de escenarios. Funcionaba en patrones familiares y se rompía en los desconocidos. Para la ronda oculta cambiamos a LinUCB con siete brazos. El problema pasó de "encontrar los mejores parámetros" a "seleccionar los parámetros correctos en tiempo de ejecución", y ese reencuadre fue todo el cambio. Las cuatro funciones de puntuación tenían decenas de variables ajustables. Optimizarlas todas por grupo de escenario estaba fuera de nuestro presupuesto de cómputo. Nos comprometimos a optimizar los cinco parámetros de puntuación de bloques de patio porque la colocación en patio codifica la congestión futura: dónde pones un contenedor ahora condiciona dónde puede ir el siguiente. La mayor palanca por hora de CPU, por mucho. Con veinticinco escenarios por ronda, "vamos a adivinar cuáles son parecidos" era el modo de falla que queríamos evitar. Las matrices de distancia euclidiana de 25 por 25 sobre datos de llegadas de buques y de transhipment forzaron que el agrupamiento fuera dirigido por datos. Algunos grupos se especializaron, otros generalizaron. Pudimos ver cuál era cuál antes de ajustar un solo parámetro. Después de la ronda uno, el patrón fue claro: nuestra puntuación era reactiva cuando necesitaba ser predictiva. Un atracadero que se ve óptimo ahora mismo es la elección equivocada si un buque grande llega en treinta minutos. Agregamos penalizaciones anticipadas (reservación de buques, ponderación por carga futura en bloques de patio) y la puntuación empezó a ver el siguiente movimiento, no solo el actual. También intentamos anclar el trabajo fuera de la simulación. Uno de nosotros entrevistó a operadores portuarios en Guatemala sobre cómo funciona realmente el manejo de contenedores en la práctica. Las entrevistas fueron útiles para entender lo que no sabíamos. Las operaciones que describían eran demasiado distintas de una terminal totalmente automatizada como para mapearse limpiamente sobre el modelo. La versión honesta es que aprendimos la simulación fallando dentro de ella, ronda por ronda, dejando que cada falla nos dijera qué señal habíamos estado ignorando. ## Lo que el bandit nos dio En la ronda uno estábamos tratando de encontrar *la mejor heurística*. Para cuando estábamos preparando la ronda oculta, habíamos abandonado ese objetivo y estábamos en cambio tratando de encontrar *la heurística correcta para este escenario*. Ese reencuadre es por lo que la arquitectura de la medalla de plata es estructuralmente un tipo de sistema distinto a una sola política ajustada. El bandit nos dio una mejora promedio del tres al cuatro por ciento sobre nuestra mejor entrega con reglas fijas, con hasta siete y medio a diez por ciento de mejora bajo escenarios específicos de alta congestión. En el contexto de operaciones portuarias, cualquier cosa por encima del uno por ciento es operacionalmente significativa. Tres por ciento sobre un sistema que maneja treinta y siete millones de contenedores al año es dinero real. ## Lo que me llevé Un modelo más simple sobre el que puedes razonar y correr mil veces es más útil que uno fiel que puedes correr dos veces. El realismo del modelado es un trade-off, y el nivel correcto de abstracción depende de lo que estás optimizando, no de cómo "realmente" se ve el sistema. La lección más grande generaliza bastante más allá de la logística portuaria. Un problema de ajuste que no converge a menudo se convierte en un problema de selección que se resuelve limpio. El mayor criterio de ingeniería en este proyecto no estaba en la matemática del bandit. Estaba en el momento en que dejamos de buscar una política perfecta y empezamos a buscar la correcta para usar ahora mismo. Team UVG y los asesores que nos acompañaron, parados juntos frente al banner del WSC 2025 Simulation Challenge en el venue de Seattle, después de que terminó la competencia.