Entorno de aprendizaje de Factorio: agentes que construyen fábricas

 (jackhopkins.github.io)
1 puntos por GN⁺ 2025-03-12 | 1 comentarios | Compartir por WhatsApp
  • Se presentó FLE 0.3.0, que usa el juego de automatización de fábricas Factorio para evaluar la planificación a largo plazo y el razonamiento espacial de los agentes, e incluye también una demo que conecta Claude Code con Factorio
  • La nueva versión facilita los experimentos de investigación con ejecución headless, un renderizador de observación por píxeles, una interfaz compatible con OpenAI Gym, ejecución de evaluaciones por CLI y herramientas de logging y análisis con Weights and Biases
  • Un agente de ejemplo depura repetidamente la producción de energía, la minería de hierro, la fundición, la colocación de máquinas ensambladoras y la conexión de cintas para alcanzar la meta de producir 16 iron gear wheel por minuto
  • El benchmark Lab-play evalúa Pass@8 sobre modelos sólidos al corte de septiembre de 2025, con objetivos de producción de 16 unidades por minuto para ítems sólidos y 250 por minuto para fluidos, además de un límite máximo de 64 pasos
  • Los modelos frontier mejoraron frente a v0.2.0, pero siguen mostrando transporte manual, buffers con cofres, mal uso de la API y errores al interpretar estados dinámicos del juego, por lo que Factorio sigue siendo un entorno exigente para revelar capacidades de planificación a largo plazo y recuperación dinámica

Qué cambió en FLE 0.3.0

  • FLE 0.3.0 es una actualización importante del entorno de aprendizaje que pone a prueba planificación a largo plazo, razonamiento y modelado del mundo con tareas de construcción de fábricas en Factorio
  • En el paper anterior de FLE, los modelos frontier mostraban dificultades para adaptarse a entornos cambiantes, fijar objetivos de largo plazo y recuperarse dinámicamente, y la versión 0.2.0 introdujo multiagencia, agentes con backtracking y visión
  • Cambios principales en 0.3.0:
    • Conecta Claude Code con Factorio a través de FLE y lo muestra en Twitch
    • Elimina la dependencia del cliente del juego Factorio para permitir escalado headless apto para experimentos a gran escala
    • Un nuevo renderizador headless del juego ofrece observaciones realistas por píxeles para investigación con agentes multimodales
    • El entorno de evaluación ahora sigue la interfaz de OpenAI Gym, lo que facilita su integración con codebases de investigación ya existentes
    • El CLI de FLE permite ejecutar experimentos con una sola línea de shell y libera como open source el código de evaluación, el logging con Weights and Biases, la reanudación de sweeps y herramientas de análisis

Inicio rápido

# 1. Install FLE with uv
uv add factorio-learning-environment



# 2. Start a Factorio server cluster
fle cluster start



# 3. Run an evaluation (with API keys in .env)
fle eval --config configs/gym_run_config.json
  • FLE se instala con uv, luego se inicia un clúster de servidores de Factorio con fle cluster start, y después se ejecuta una evaluación con las API keys en .env y un archivo de configuración

Ejemplo de fábrica automática de iron gear wheel

  • El agente de ejemplo comienza en el mundo lab-play con un inventario de objetos y la meta de construir una fábrica de iron gear wheel
  • Interactúa con el entorno del juego llamando a la API de FLE desde Python y observa la salida estándar y los mensajes de error de cada ejecución

  • Configuración de energía

    • Usa nearest(Resource.Water) para encontrar agua y colocar una offshore pump
    • Después coloca boiler y steam engine, conecta las tuberías con connect_entities y carga coal en el boiler
    • Tras esperar 5 segundos, verifica el valor energy de la steam engine para validar la generación de energía

  • Minería y fundición de hierro

    • Encuentra la ubicación del iron ore y coloca 2 electric mining drill junto con un electric furnace
    • Calcula que para 16 iron gear wheel/min se necesitan 32 iron plate/min, y como un electric mining drill extrae 30 de ore cada 60 segundos, hacen falta 2 drills
    • Los drills y el horno eléctrico se conectan a la red eléctrica de la steam engine mediante medium electric pole

  • Colocación de la máquina ensambladora

    • Coloca una AssemblingMachine2 al menos a 20 tiles de distancia del área de minería
    • Configura la receta de la ensambladora como Prototype.IronGearWheel, coloca inserters de entrada y salida, y la conecta a la red eléctrica
    • Assembling machine 2 puede fabricar 90 iron gear wheel cada 60 segundos, así que una sola unidad basta para el throughput objetivo

  • Conexión de cintas y recuperación ante errores

    • Intentó conectar directamente con cintas el furnace output inserter y el assembler input inserter, pero detectó que un storage chest bloqueaba la ruta
    • Sacó iron plate de 2 wooden chest que bloqueaban el camino y retiró esos cofres, pero dejó el input buffer chest del lado del assembler, causando otro error
    • Al final eliminó también el assembler input chest y conectó una red logística basada en transport belt, con lo que el sistema automático de iron gear wheel alcanzó el throughput objetivo

Espacio de observación y harness del agente

  • En cada paso, el agente recibe un objeto estructurado de Observation con el estado del juego
  • Campos principales:
    • raw_text: salida estándar y mensajes de error de la ejecución del action program anterior, junto con números de línea del código fuente
    • entities: todas las entidades del mundo del juego y sus propiedades, como posición, tipo, dirección, inventario y advertencias
    • inventory: tipos de ítems y cantidades en el inventario personal del agente
    • research: tecnologías investigadas, progreso actual de investigación y tecnologías disponibles con prerequisitos y costos
    • game_info: número de ticks, tiempo transcurrido y velocidad del juego
    • flows: tasas de entrada/salida, ítems fabricados, recursos recolectados y una tabla opcional de precios para evaluación económica
    • messages: mensajes entre agentes para coordinación multiagente
    • task_info: descripción del objetivo, instrucciones, identificador de tarea y longitud máxima de la trayectoria
    • task_verification: metadatos sobre éxito o fracaso y progreso del objetivo
    • serialized_functions: helper functions y abstracciones definidas previamente
    • map_image: layout de la fábrica en PNG codificado en base64 para agentes visuales
  • Este espacio de observación soporta percepción espacial, seguimiento de métricas de producción, depuración de errores y planificación de automatización en múltiples etapas
  • El harness del agente para evaluación concatena estos campos en una cadena Markdown formateada

Configuración del benchmark Lab-play

  • Lab-play es un entorno restringido que entrega recursos fijos y una sola entidad objetivo para maximizar el throughput de producción
  • Open-play es mucho más complejo porque parte de mapas generados proceduralmente, sin inventario inicial, y debe lidiar con recursos más escasos y metas más complejas
  • Con base en modelos sólidos al corte de septiembre de 2025, se replica la metodología del paper original de FLE adaptada a la configuración de lab-play
  • El harness estandarizado del agente sigue agregando interacciones con el entorno a un único historial de conversación y, cuando se agota el presupuesto de tokens, resume el historial antiguo para continuar el razonamiento
  • No se evalúa la lógica de backtracking ni de reflection usada en FLE 0.2.0

  • Condiciones de evaluación

    • Objetivo: alcanzar un throughput de producción de 16 unidades por minuto para ítems sólidos y 250 por minuto para fluidos
    • Prompt: documentación de la API de FLE, recetas de Factorio y guías de patrones generales
    • Inventario: un conjunto de ítems útiles para construir una fábrica funcional
    • Pasos máximos: 64 pasos, con finalización anticipada al completar la tarea
    • Razonamiento: para modelos con soporte de reasoning se aplica la configuración predeterminada {"enabled": true}

Rendimiento de los modelos y limitaciones pendientes

  • Los modelos open source ya alcanzaron el mejor rendimiento de punta observado en mayo de 2025 en v0.2.0, con casos exitosos en automatización de electronic circuits, steel plate, sulfur y plastic
  • Los modelos frontier más recientes mejoraron de forma importante frente a FLE v0.2.0 y por primera vez también lograron tareas más difíciles de la mitad superior, donde deben aprovechar más de 12 ingredient dependency
  • En FLE lab-play, el orden y la brecha de rendimiento entre los modelos avanzados se acercó a Claude > GPT > Gemini > Grok, y fue lo más parecido a GDPVal de OpenAI
  • En benchmarks estáticos tipo examen como Humanity's Last Exam, AIME 25, GPQA y MMMU, algunos modelos débiles en FLE llegan a rendir mejor, lo que contrasta con estos resultados
  • Incluso los agentes exitosos suelen depender de estrategias semimanuales en tareas complejas en vez de una automatización robusta
    • Transportan recursos directamente
    • Usan storage chest como buffers de recursos
    • Evitan construir una cadena logística completamente automatizada
  • Los buffers intermedios pueden satisfacer temporalmente las comprobaciones de throughput, lo que dificulta la medición
  • La evaluación mitiga este problema verificando si el agente cumple la cuota después de un holdout period en el que la fábrica se deja funcionando tal cual durante 60 segundos
  • Si se fijan objetivos de throughput más altos, resulta más difícil aprobar con logística manual, lo que puede exigir una automatización adecuada

Tipos de errores y diferencias entre modelos

  • Los modelos frontier siguen teniendo dificultades para recuperarse cuando los errores se acumulan
  • Comparación de tasa de error promedio: {b:23,25,27,41}
  • Tasa de error promedio:
    • Claude Opus 4.1: 22.99%
    • GPT-5: 25.05%
    • Gemini 2.5 Pro: 27.29%
    • Grok 4: 40.89%
  • Grok 4 suele caer en loops de depuración regresivos, mientras que GPT-5 muestra patrones de recuperación más elegantes
  • La mayoría de los modelos eleva su tasa de error en los tramos intermedios de la trayectoria, cuando aumenta la complejidad de la fábrica

  • Tipos de fallo

    • Errores sintácticos: código Python inválido, fallos de gramática, errores que impiden la ejecución misma
    • Errores semánticos: mal uso de comandos o argumentos de herramientas de FLE, mala comprensión de la documentación, TypeError, AttributeError, NameError, etc.
    • Errores prácticos: razonamiento incorrecto sobre el estado actual del juego, por ejemplo intentar insertar un ítem que no está en el inventario
    • Errores de planificación y control: aunque conoce las primitivas, no logra encadenar las acciones de forma consistente, produciendo trayectorias ineficientes o incompletas
    • Esta categoría requiere observar la consistencia estratégica de alto nivel más que tipos de error individuales, por lo que es difícil cuantificarla con fiabilidad mediante análisis automático de trayectorias

  • Distribución de errores por modelo

    • Claude Opus 4.1 no tiene errores sintácticos y el 97.7% de sus errores se acercan a errores prácticos, lo que indica fortaleza en generación de código pero dificultades para mantener un modelo mental preciso del estado del juego
    • Gemini 2.5 Pro, Grok 4 y GPT-5 muestran entre 12% y 17% de errores de comprensión de API, lo que sugiere dificultades para usar con precisión la documentación de la API de FLE
    • GPT-5 y Grok 4 muestran 21% y 17% de errores sintácticos respectivamente, algo frecuente para modelos de coding benchmark de última generación pese a su alto rendimiento
    • Gemini 2.5 Pro es el único que actualmente muestra un enfoque de definir y usar helper functions y abstracciones

Claude Code y MCP

  • En la v0.2.0 se publicó un MCP server para que agentes externos pudieran interactuar con FLE
  • En la v0.3.0 esto se amplía con un adaptador para Claude Code
  • El stream de Claude Code jugando Factorio puede verse en Twitch

Próximas líneas de investigación

  • Los modelos frontier actuales todavía están muy lejos de jugar Factorio realmente bien en comparación con humanos, y muestran dificultades para representar y modelar entornos dinámicos, además de desarrollar abstracciones formales que luego sirvan como herramientas
  • Aun así, durante 2025 las capacidades de los modelos frontier en lab-play mejoraron de manera constante
  • Factorio puede seguir usándose como entorno para revelar capacidades generales de los modelos, como planificación a largo plazo, adaptación al dominio, modelado del mundo y razonamiento espacial
  • FLE v0.3.0 establece lab-play como primer benchmark formal, pero esto apenas representa el punto de partida del plan de investigación

  • Tareas cercanas

    • Línea base humana: medir de forma sistemática el rendimiento humano por nivel de dificultad de la tarea para calibrar las capacidades de los agentes
    • Mitigación de reward hacking: abordar el problema de que los agentes usen manual crafting en vez de automatización adecuada para ítems complejos
    • METR-style task scaling: desarrollar una gráfica de scaling que conecte de forma sistemática la dificultad de la tarea con las capacidades necesarias

  • Tareas de largo plazo

    • Expansión a Open-play y megabase: ampliar la dificultad desde el lab-play restringido hasta mapas generados proceduralmente, objetivos multietapa y megabases con miles de máquinas conectadas
    • Rendimiento en tiempo real bajo restricciones de latencia: actualmente el tiempo de pensamiento entre acciones es ilimitado, pero un benchmark con Factorio corriendo continuamente permitiría evaluar el equilibrio entre latencia de respuesta y calidad de la solución
    • Coordinación multiagente: abordar cooperación, competencia, emergent market dynamics, división del trabajo, negociación de asignación de recursos y formación de ventaja comparativa
    • Entornos fuera de distribución basados en mods: evaluar si el agente puede volver a aprender la estructura causal en nuevos tech tree y mecánicas de juego
    • Native computer-use interface: evaluar agentes con una interfaz de teclado, mouse y visión similar a la humana en lugar de la API de Python
    • Dinámicas adversariales y robustez: introducir aliens hostiles y desafíos de entorno no determinista para evaluar adaptive control y resilience

Cómo participar

  • Tanto el código de FLE como las misiones son open source
  • Se busca participación de:
    • Investigadores que exploren nuevas arquitecturas para planificación a largo plazo y razonamiento espacial
    • Ingenieros que optimicen infraestructura de entrenamiento y evaluación a gran escala
    • Modders que diseñen nuevos challenge domain
  • Si te interesa sumarte al equipo, puedes encontrarlos en Discord

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-03-12
Opiniones de Hacker News

  • Ya caí por completo en el anzuelo y ahora quiero postularme de inmediato al laboratorio de Factorio de Anthropic.
    Por el paper o los comentarios no me queda claro si están enviando de vuelta datos multimodales, pero como varios modelos no son multimodales, probablemente no. Aunque algunos sí pueden, y el reciente Qwen 2.5 VLM parece bastante potente para su tamaño.
    Hicieron bastante énfasis en la falta de capacidad espacial y también hablaron de las dificultades tanto de planificación como de planificación espacial; me pregunto si también están enviando imágenes como capturas de pantalla. Si no, también me gustaría saber qué piensan al respecto.
    Además, habilitar una biblioteca de Python con MCP para que cualquier LLM capaz de usar herramientas juegue Factorio parece algo que naturalmente hay que hacer.

    • Actualmente es un entorno solo de texto, pero planeamos admitir entrada visual más adelante.
      En algunas pruebas, incluir capturas de pantalla del estado del juego no mejoró el rendimiento de los modelos disponibles. A medida que el estado del juego se volvía más complejo y había más entidades en la captura, los modelos se confundían más, alucinaban o pasaban por alto direcciones y entidades, y tampoco corregían errores evidentes como cintas transportadoras faltantes o insertadores rotados incorrectamente.
      Creemos que se debe a que los VLM actuales no son buenos en razonamiento espacial con imágenes muy detalladas, y es posible que el ajuste fino lo mejore mucho. MCP también está creciendo mucho últimamente, así que pensamos revisarlo.
    • Si una descripción textual del estado de la fábrica es más fácil de interpretar y causa menos confusión, no sé por qué harían falta capturas de pantalla.
      El juego ocurre sobre una cuadrícula, así que convertir el estado del juego en una representación ASCII debería ser sencillo.

  • Hace poco hubo en HN un artículo de un equipo que entrenó con aprendizaje por refuerzo a un agente para terminar Pokémon Red. Decían que tuvieron que ajustar la función de costo para dar recompensas pequeñas por explorar y recompensas grandes por tareas obligatorias como vencer gimnasios.
    Me pregunto si se podría usar el mismo enfoque en Factorio. Siguiendo la analogía con Pokémon Red, las principales tareas obligatorias en Factorio son crear automatización para nuevos ítems y nuevos paquetes de ciencia.
    Dar recompensas pequeñas por la producción por segundo de cada ítem, recompensas medianas por automatizar nuevos ítems y recompensas grandes por automatizar nuevos paquetes de ciencia podría ser una buena función de recompensa.
    Decirle a un agente de Factorio simplemente “construye una fábrica grande” es como decirle a un agente de Pokémon Red “termina el juego”; hay que dividirlo en pasos más pequeños y con una función de recompensa ajustada con mucho cuidado.
    Pensar en esto me dieron ganas de meterme en este proyecto.

    • Como alguien que ha jugado Factorio entre 2 y 3 mil horas, agregaría que el objetivo de construir “la fábrica más grande posible” es demasiado ambiguo y no es la métrica correcta.
      Cuando los jugadores de Factorio construyen grandes megabases, el objetivo no es el tamaño en sí, sino la ciencia por minuto (SPM). La métrica para el agente no debería ser la base “más grande”, sino el SPM.
    • En FLE podemos acceder a hitos que indican cuándo se creó por primera vez una nueva entidad, pero también sería muy interesante estratificar las recompensas por niveles de automatización. Sería genial hacerlo juntos.
    • Es una parte interesante. Claude, en lab-play, pudo hacer tareas obligatorias y automatización simple como una fábrica de engranajes de hierro, pero en los episodios del juego de “construir la fábrica más grande” ni siquiera lo intentó.
      Los modelos pueden realizar esas tareas obligatorias, pero cuando reciben un objetivo general como “completa el juego”, les falta el nivel de planificación a largo plazo necesario para intentarlo. Muchas veces no intentaban expandir una fábrica existente y solo construían pequeñas estructuras descoordinadas.
      Uno de los objetivos también era ver cómo se comportan los modelos cuando reciben metas ambiguas y generales.
    • El mismo enfoque también se puede aplicar a la vida.
    • Me pregunto si leíste la página. De hecho, daban una recompensa por cada ítem producido, y recompensas más altas para los ítems más complejos.

  • Es interesante la parte en la que evaluaron seis modelos de lenguaje de frontera en dos configuraciones, pero también hay muchos benchmarks dinámicos mucho más simples que pueden saturar la capacidad de planificación de los modelos sin razonamiento.
    Con solo dar una lista de conexiones de vuelos entre ciudades y preguntar por el itinerario entre ellas, todos estos modelos se confunden si el camino más corto entre dos nodos es lo bastante largo.
    El camino más corto más largo entre ciudades que pudieron encontrar de forma estable 8 de cada 10 veces para cada longitud fue el siguiente:
    | Model | Path Length |
    |------------------+-------------|
    | Claude Sonnet3.5 | 10 |
    | GPT-4o | 7 |
    | GPT-4o-mini | 4 |
    | Deepseek-v3 | 6 |
    | Gemini-2-Flash | Not tested |
    | Llama3.3-70B-Ins | 4 |

    • Correcto. Hay benchmarks más simples que saturan la capacidad de planificación de estos modelos.
      Sin embargo, queríamos crear un entorno de evaluación de espectro más amplio que pruebe varias capacidades a la vez y que pueda seguir siendo válido en el futuro.

  • Tiene sentido que todos los modelos mostraran límites de planificación espacial al construir fábricas de varias zonas. Fallaban de formas comunes: colocaban entidades demasiado cerca, no dejaban espacio para conexiones o ponían mal los insertadores.
    Entiendo por qué los LLM son débiles en razonamiento espacial: no hay muchos datos de entrenamiento adecuados para eso. Me pregunto qué capacidades adicionales de razonamiento aparecerán cuando se resuelva el razonamiento espacial.

    • No entiendo bien eso de que no haya muchos datos espaciales.
      ¿No se podrían generar prácticamente de forma infinita con el simulador más simple?
      Por ejemplo, con solo implementar en unas 10 líneas de código un tic-tac-toe sobre una cuadrícula infinita, se podría generar un conjunto de entrenamiento ilimitado.

  • Me gustaría ver diseño de balanceadores como otra categoría de tareas de “Lab Play”.
    Incluso los balanceadores pequeños pueden ser bastante complejos (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9), y sería interesante ver la capacidad de los modelos para diseñarlos y resolver problemas con ellos.

  • Es una idea genial.
    Parece que hay muchos experimentos interesantes que se pueden hacer acá. Me parece buena idea incorporar elementos relacionados con el tiempo en el escenario lab-play. La mayoría de los jugadores de Factorio que juegan con los biters activados lo tratarían como una combinación de restricciones de tiempo y espacio, y ponerle un límite de tiempo al agente permitiría una especie de comparación indirecta con situaciones reales del juego.
    Me gusta que el diseño de este framework pruebe algo distinto a la capacidad de microgestión que vimos en experimentos como DOTA 2 o StarCraft 2. En StarCraft 2, en particular, si hay APM infinitas, aparecen comportamientos como microgestionar trabajadores de forma extrema para extraer un poco más de minerales.
    Ese comportamiento es un resultado de aprendizaje interesante en un contexto estrecho, pero en la práctica implica una gran carga de control y hasta un jugador profesional probablemente cometería errores. Además, tampoco parece aportar más información sobre la planificación a largo plazo, la ejecución y el rendimiento analítico del agente.
    En ese sentido, FLE es mucho más interesante como framework de evaluación del razonamiento de más alto nivel. También me pregunto si hay planes para un benchmark de optimización de layout, como optimizar el rendimiento cuando una celda de fábrica dada tiene X entradas y Y salidas.

    • Estamos hablando de crear una tarea más parecida a tower defense, en la que los biters se liberen cada X etapas o cada X segundos.
      El objetivo es probar la capacidad del agente para crear un complejo industrial militar. Un problema gracioso al desarrollar esta idea fue que los modelos frontier se mostraban reacios a crear entidades con nombres como “GunTurret”. Parece que lo consideran contrario a su constitución. Quizás haya que cambiar el nombre de la torreta a algo como “SuperSoaker”.
      Sobre el benchmark de optimización de layout, de hecho lo discutimos ayer. Creo que hacen falta dos tipos de tareas de layout: 1) arreglar una fábrica sutilmente rota, 2) mejorar el throughput de esta fábrica. La implementación debería ser relativamente sencilla, así que sería bueno revisarlo.

  • No lo entiendo bien. ¿Estos modelos fueron post-entrenados para jugar Factorio?
    A) Si es así, ¿cómo es posible con modelos sin pesos abiertos, como Claude? B) Si no, ¿cómo sabe el agente qué hace la API? Incluso si infiere por el significado en inglés de los comandos de la API —por ejemplo, que place_entity_next_to coloca una entidad junto a algo—, ¿cómo conoce las recetas? Si prueba y aprende, volvemos a A.
    Leí el PDF y no parece que hayan hecho post-entrenamiento; entonces no sé cómo se explican las preguntas de B.
    Si realmente no hubo post-entrenamiento y se esperaba que la exploración de recetas ocurriera dentro de la ventana de contexto, creo que es demasiado corta para una mejora al estilo de aprendizaje por refuerzo.
    En resumen, no sé si pudieron probar estos modelos con post-entrenamiento, y si lo hicieron sin post-entrenamiento, todos rindieron increíblemente bien.
    Si los autores ven esto, me gustaría saber cuántos pares de consulta a la API y respuesta de la API caben en promedio en la ventana de contexto. Y, relacionado con eso, si abreviar los nombres de las llamadas a la API para meter más pares de respuesta en una ventana de contexto mejora los resultados.

    • En cuanto a las herramientas, los agentes tenían acceso a las firmas de función, es decir, los docstrings de las herramientas, los tipos de entrada y salida, y también había un pequeño “manual” para cada herramienta.
      Ese manual explicaba qué hace la herramienta, cómo afecta el estado del juego y algunos ejemplos de uso, como colocar un inserter junto a un cofre existente con place_entity_next_to.
      Como dijo Jack, no hubo ningún post-entrenamiento, pero todos los agentes tenían en el contexto una descripción completa de la API, incluidas herramientas, entidades e investigaciones. Por lo tanto, estos resultados muestran en cierta medida qué tan bien pueden usar los agentes modernos una API completamente fuera de distribución cuando cuenta con documentación adecuada.
    • Estos modelos no fueron post-entrenados; todos eran modelos estándar, tal cual.
      En el contexto podían entrar hasta unos 128 pares, pero como el rendimiento era igual con 32 pares, finalmente elegimos 32 por costo y latencia.
      Codificar entradas y salidas de forma más corta empeoró el rendimiento. Parece que los nombres descriptivos ayudan porque les dan a los modelos preentrenados una intuición sobre qué hace cada cosa.
    • Si lees la nota al pie de la presentación de los autores, parece que uno trabaja en Anthropic. Probablemente tenían acceso interno.

  • Me resulta interesante que haya solo unos pocos escenarios complejos. Siempre pensé que, para que un agente de juegos de ML aprenda bien las mecánicas de un juego, se necesitan cientos de puzles muy pequeños, cada uno con cientos de variantes.
    Por ejemplo, cosas como estas: la fábrica no tiene electricidad, así que hay que colocar el poste eléctrico faltante; a la fábrica le faltan ítems, así que hay que colocar la cinta transportadora faltante; fabricar y colocar 200 máquinas ensambladoras; una máquina ensambladora se detuvo por algún motivo, así que hay que arreglarla; la producción de la fábrica es demasiado baja, así que hay que duplicarla; moverse lo más rápido posible hasta otro punto de la fábrica; arreglar la falta de energía; y dividir todas estas tareas entre casos con robots y sin robots.
    Debería ser relativamente fácil generar programáticamente miles de estos escenarios de ejemplo. Luego se podrían usar como un banco de preguntas tipo test de IQ: elegir unas 12 del banco y evaluar el rendimiento en cada una según el tiempo y los materiales usados.
    Creo que un agente de ML aprendería más rápido si se lo evalúa con muestras de un gran banco de escenarios cuya complejidad aumenta suavemente, y luego se le presentan escenarios más complejos una vez que obtiene una puntuación suficientemente alta en niveles de baja complejidad.

    • Como propones, generar escenarios en texto es fácil, pero crear el estado de juego de la fábrica correcto como punto de partida es mucho más difícil.
      Hasta donde sé, al final termina siendo el mismo trabajo de diseñar manualmente el estado inicial y la tarea a completar.
    • Para entrenamiento adicional estamos considerando este enfoque de currículo.
      Pero el trabajo actual se centró en la evaluación, así que no lo hicimos así. La “dificultad” de distintas tareas es bastante subjetiva, por lo que habría que tomar decisiones arbitrarias que podrían afectar la evaluación. Por ejemplo, qué tarea debería venir después de qué escenario, o si se cubren suficientemente todos los niveles de dificultad.

  • Me pregunto si existe un benchmark humano para este tipo de interfaz. No digo que sea necesario ni relevante; solo tengo curiosidad por saber cómo se siente Factorio de forma programática.
    Hacer razonamiento espacial alrededor de prompts de texto parece que también sería bastante difícil para jugadores humanos.

    • El benchmark humano de Factorio son los speedrunners que compiten por lanzar el primer cohete.
      El récord actual es de un poco más de 4 horas en solitario y 90 minutos en equipo. Con eso solo ya se ve que hay margen para que un LLM multitarea supere a los humanos.

  • Me pregunto si, dentro de unos años, todos los oponentes dentro de los juegos serán LLM con acceso a este tipo de API de control del juego.
    También me pregunto si hubo tipos de tareas que a los modelos se les hicieran especialmente difíciles, o si la dificultad aumenta sobre todo según la cantidad de ítems que hay que colocar.

    • Es muy poco probable que los LLM se usen masivamente como oponentes. La IA enemiga de la mayoría de los juegos no necesita el nivel de complejidad que requiere el aprendizaje automático. Incluso dejando de lado el costo computacional.
      El objetivo principal de la IA enemiga no es ser lo más difícil del mundo, sino ofrecer un desafío interesante que el jugador pueda superar. En la mayoría de los juegos, crear una IA de altísimo rendimiento no necesariamente es difícil, pero eso tampoco la vuelve divertida como rival.
      La mayoría de los juegos tienen un estado lógico finito; solo que es lo bastante grande como para que los humanos no encuentren todas las soluciones. Claro que los humanos son muy buenos empujando los bordes de esos estados para encontrar atajos.
      Incluso en juegos con una cantidad de estados mucho mayor de lo normal, rara vez se quiere una super IA. Por ejemplo, en un FPS, a nadie le gusta enfrentarse a un aimbot.
      Factorio es una excepción frente a los juegos comunes, en el sentido de que las verdaderas condiciones de “victoria” dependen casi por completo del jugador. En Factorio sin DLC, se puede construir el cohete —la condición de victoria del juego— casi sin armar una fábrica, salvo las estructuras más básicas para las cosas que no se pueden fabricar a mano. Sería increíblemente lento, pero es una opción posible. Por eso, en un benchmark así importa más la eficiencia que si “funciona”.
    • Creo que es posible. Porque no hace falta cómputo de entrenamiento adicional para hacerlo funcionar. Si se ofrece una API, es muy fácil conectar distintos modelos a un juego nuevo en modo plug and play.
      Los modelos tienen dificultades principalmente en dos áreas. La primera es el razonamiento espacial. Los modelos suelen cometer errores off-by-one, y las fábricas, como la programación, son muy sensibles a ese tipo de errores y les cuesta recuperarse.
      La segunda es la planificación a largo plazo: la capacidad de entender qué hay que hacer estratégicamente antes de crear subobjetivos tácticos.
      En lab-play, la dificultad suele ser proporcional a la profundidad de la cadena de producción. Si para fabricar un ítem primero hacen falta varias secciones de fábrica, se vuelve mucho más difícil. Esto parece estar relacionado con la planificación, porque los modelos tienden a meterse en detalles para arreglar problemas menores en vez de trazar primero un plan general.
    • Si ves “Claude plays Pokémon”, se traba en Mount Moon, y a mí también me pasaba a los cuatro años.
    • ¿Por qué tendría que ser un LLM? ¿No es este el tipo de cosas en las que AlphaZero es bueno? ¡Hay muchos modelos de aprendizaje automático útiles además de los LLM!