Ambiente de aprendizado do Factorio – agentes que constroem fábricas

• Foi lançado o FLE 0.3.0, que usa o jogo de automação industrial Factorio para avaliar planejamento de longo prazo e raciocínio espacial de agentes, e inclui também uma demonstração conectando o Claude Code ao Factorio
• A nova versão facilita experimentos de pesquisa com execução headless, renderizador de observação em pixels, interface compatível com OpenAI Gym, execução de avaliações via CLI e ferramentas de logging e análise com Weights and Biases
• Um agente de exemplo depura repetidamente produção de energia, mineração de minério de ferro, fundição, posicionamento de máquinas de montagem e conexão de correias para atingir a meta de produzir 16 iron gear wheel por minuto
• O benchmark lab-play avalia Pass@8 em modelos fortes com base em setembro de 2025, com metas de produção de 16 itens sólidos por minuto e 250 unidades de fluido por minuto, além de limite máximo de 64 etapas
• Os modelos de fronteira melhoraram em relação ao v0.2.0, mas ainda persistem transporte manual, buffers com baús, uso incorreto da API e interpretação errada do estado dinâmico do jogo, mantendo o Factorio como um ambiente desafiador para revelar capacidade de planejamento de longo prazo e recuperação dinâmica

---

O que mudou no FLE 0.3.0

• FLE 0.3.0 é uma grande atualização do ambiente de aprendizado que testa planejamento de longo prazo, raciocínio e modelagem do mundo por meio da tarefa de construir fábricas no Factorio
• No artigo anterior do FLE, os modelos de fronteira mostraram dificuldade em adaptação a ambientes mutáveis, definição de objetivos de longo prazo e recuperação dinâmica; o 0.2.0 havia introduzido multiagência, agentes com backtracking e visão
• Principais mudanças do 0.3.0:
  • Conecta o Claude Code ao Factorio via FLE e o demonstra na Twitch
  • Remove a dependência do cliente do jogo Factorio para permitir escalonamento headless em experimentos de grande porte
  • Um novo renderizador headless do jogo fornece observações realistas em pixels para pesquisa com agentes multimodais
  • O ambiente de avaliação agora segue a interface do OpenAI Gym, facilitando integração com codebases de pesquisa existentes
  • A CLI do FLE permite executar experimentos com um comando de shell de 1 linha, e o código de avaliação, logging com Weights and Biases, retomada de sweeps e ferramentas de análise são oferecidos como open source

Início 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

• O FLE é instalado com uv, o cluster de servidores do Factorio é iniciado com fle cluster start e depois a avaliação é executada com as chaves de API no .env e um arquivo de configuração

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

• O agente de exemplo começa no mundo lab-play com um inventário de itens e o objetivo de construir uma fábrica de iron gear wheel
• Ele interage com o ambiente do jogo chamando a API do FLE em Python e observa a saída padrão e as mensagens de erro de cada execução

• Configuração de energia

  • Usa nearest(Resource.Water) para localizar água e posiciona uma offshore pump
  • Posiciona boiler e steam engine, conecta os canos com connect_entities e coloca coal no boiler
  • Após esperar 5 segundos, verifica o valor de energy da steam engine para validar a geração de energia

• Mineração e fundição de ferro

  • Encontra a posição de iron ore e posiciona 2 electric mining drill e um electric furnace
  • Calcula que 16 iron gear wheel/min exigem 32 iron plate/min e, como cada electric mining drill extrai 30 minérios por 60 segundos, são necessárias 2 perfuradoras
  • As perfuradoras e o forno elétrico são conectados à rede elétrica da steam engine com medium electric pole

• Posicionamento da máquina de montagem

  • Posiciona uma AssemblingMachine2 a pelo menos 20 tiles de distância da área de mineração
  • Define a receita da máquina de montagem como Prototype.IronGearWheel, posiciona inserters de entrada e saída e conecta à rede elétrica
  • A Assembling machine 2 consegue fabricar 90 iron gear wheel por 60 segundos, então 1 unidade basta para a vazão desejada

• Conexão de correias e recuperação de erros

  • Tentou conectar diretamente com correias o inserter de saída do furnace ao inserter de entrada do assembler, mas descobriu que um storage chest bloqueava o caminho
  • Removeu iron plate de 2 wooden chest que estavam bloqueando e retirou os baús, mas deixou o baú de buffer de entrada do assembler, causando novo erro
  • No fim, removeu também o baú de entrada do assembler e conectou uma malha logística baseada em transport belt, fazendo o sistema automático de iron gear wheel atingir a vazão-alvo

Espaço de observação e harness do agente

• A cada etapa, o agente recebe um objeto estruturado Observation contendo o estado do jogo
• Campos principais:
  • raw_text: saída padrão e mensagens de erro da execução do programa de ação anterior, além dos números de linha do código-fonte
  • entities: todas as entidades do mundo do jogo e atributos como posição, tipo, direção, inventário e avisos
  • inventory: tipos e quantidades de itens no inventário pessoal do agente
  • research: tecnologias pesquisadas, progresso atual e tecnologias disponíveis com pré-requisitos e custo
  • game_info: número de ticks, tempo decorrido e velocidade do jogo
  • flows: taxas de entrada e saída, itens produzidos, recursos coletados e tabela opcional de preços para avaliação econômica
  • messages: mensagens entre agentes para coordenação multiagente
  • task_info: descrição da meta, instruções, identificador da tarefa e comprimento máximo da trajetória
  • task_verification: metadados de sucesso/falha e progresso do objetivo
  • serialized_functions: helper functions e abstrações definidas anteriormente
  • map_image: layout da fábrica em PNG codificado em base64 para agentes visuais
• Esse espaço de observação oferece suporte a percepção espacial, acompanhamento de métricas de produção, depuração de erros e planejamento de automação em múltiplas etapas
• O harness de avaliação concatena esses campos em uma string Markdown formatada

Configuração do benchmark lab-play

• Lab-play é um ambiente restrito com recursos fixos e uma única entidade-alvo, no qual se busca maximizar a vazão de produção
• O open-play é muito mais complexo, pois começa em mapas gerados proceduralmente, sem inventário inicial, com recursos mais escassos e objetivos mais complexos
• Com base em setembro de 2025, a metodologia do artigo original do FLE foi reproduzida para a configuração lab-play em modelos fortes
• O harness padronizado do agente continua adicionando interações com o ambiente a um único histórico de conversa e, quando o orçamento de tokens fica curto, resume os registros antigos para continuar o raciocínio
• Não são avaliadas as lógicas de backtracking ou reflection usadas no FLE 0.2.0

• Condições de avaliação

  • Objetivo: atingir vazão de produção de 16 itens sólidos por minuto e 250 unidades de fluido por minuto
  • Prompt: documentação da API do FLE, receitas do Factorio e guia de padrões gerais
  • Inventário: conjunto de itens úteis para construir uma fábrica funcional
  • Máximo de etapas: 64 etapas, com encerramento antecipado ao concluir
  • Raciocínio: para modelos com suporte a reasoning, aplica-se a configuração padrão {"enabled": true}

Desempenho dos modelos e limitações restantes

• Modelos open source alcançaram o melhor desempenho recente observado em maio de 2025 no v0.2.0, com casos de sucesso na automação de electronic circuits, steel plate, sulfur e plastic
• Os modelos de fronteira mais recentes melhoraram muito em relação ao FLE v0.2.0 e, pela primeira vez, também tiveram sucesso na metade mais difícil das tarefas, que exigem usar mais de 12 dependências de ingredientes
• No lab-play do FLE, a ordem e a diferença de desempenho entre os modelos avançados ficaram mais próximas de Claude > GPT > Gemini > Grok, sendo o resultado mais parecido com o GDPVal da OpenAI
• Em benchmarks estáticos no estilo prova, como Humanity's Last Exam, AIME 25, GPQA e MMMU, às vezes modelos fracos no FLE mostram desempenho mais alto, criando contraste nos resultados
• Mesmo agentes bem-sucedidos frequentemente dependem de estratégias semimanuais em tarefas complexas, em vez de automação robusta
  • Transportam recursos manualmente
  • Usam storage chest como buffer de recursos
  • Contornam a construção de cadeias logísticas totalmente automatizadas
• Buffers intermediários podem satisfazer temporariamente a checagem de vazão, dificultando a medição
• Para mitigar isso, a avaliação verifica se o agente cumpre a cota após um holdout period em que a fábrica fica rodando sozinha por 60 segundos
• Metas de vazão mais altas podem dificultar aprovações com logística manual, exigindo automação adequada

Tipos de erro e diferenças entre modelos

• Os modelos de fronteira continuam tendo dificuldade para se recuperar quando os erros se acumulam
• Comparação de taxa média de erro: {b:23,25,27,41}
• Taxa média de erro:
  • Claude Opus 4.1: 22.99%
  • GPT-5: 25.05%
  • Gemini 2.5 Pro: 27.29%
  • Grok 4: 40.89%
• O Grok 4 frequentemente entra em loops regressivos de depuração, enquanto o GPT-5 tende a se recuperar de forma mais elegante
• A maioria dos modelos apresenta taxa de erro mais alta na parte intermediária das trajetórias, quando a complexidade da fábrica aumenta

• Tipos de falha

  • Erro de sintaxe: código Python inválido, erro gramatical ou falha que impede a execução em si
  • Erro semântico: uso incorreto de comandos ou parâmetros das ferramentas do FLE, falha de compreensão da documentação, TypeError, AttributeError, NameError etc.
  • Erro prático: raciocínio incorreto sobre o estado atual do jogo, como tentar inserir um item que não está no inventário
  • Erro de planejamento e controle: mesmo conhecendo as primitivas, o agente não consegue conectar as ações de forma consistente, levando a trajetórias ineficientes ou incompletas
  • Essa categoria exige observar consistência estratégica em nível superior, e por isso é difícil quantificá-la com confiabilidade por análise automática de trajetórias

• Distribuição de erros por modelo

  • O Claude Opus 4.1 não teve erros de sintaxe e 97,7% de seus erros se aproximaram de erros práticos, mostrando força em geração de código, mas dificuldade em manter um mental model preciso do estado do jogo
  • Gemini 2.5 Pro, Grok 4 e GPT-5 mostraram entre 12% e 17% de erros de compreensão da API, indicando dificuldade em usar corretamente a documentação da API do FLE
  • GPT-5 e Grok 4 mostraram 21% e 17% de erros de sintaxe, respectivamente, o que indica falhas frequentes em gerar Python válido, algo surpreendente para modelos no topo dos benchmarks de coding
  • Apenas o Gemini 2.5 Pro mostrou atualmente uma abordagem de definir e usar helper functions e abstrações

Claude Code e MCP

• No v0.2.0, foi lançado um servidor MCP para permitir que agentes externos interagissem com o FLE
• No v0.3.0, isso foi expandido para incluir um adaptador do Claude Code
• A transmissão do Claude Code jogando Factorio pode ser vista na Twitch

Próximas direções de pesquisa

• Os modelos de fronteira atuais ainda estão longe de jogar Factorio muito bem em termos humanos, e mostram dificuldade em representação e modelagem de ambientes dinâmicos e no desenvolvimento de abstrações formais que possam servir como ferramentas futuras
• Ainda assim, as capacidades dos modelos de fronteira no lab-play melhoraram de forma consistente ao longo de 2025
• O Factorio pode continuar sendo usado como um ambiente que revela capacidades gerais de modelos, como planejamento de longo prazo, adaptação ao domínio, modelagem do mundo e raciocínio espacial
• O FLE v0.3.0 estabelece o lab-play como seu primeiro benchmark formal, mas isso representa apenas o ponto de partida do plano de pesquisa

• Tarefas de curto prazo

  • Linha de base humana: medir sistematicamente o desempenho humano por dificuldade de tarefa para calibrar as capacidades dos agentes
  • Resposta a reward hacking: tratar o problema de agentes usarem manual crafting em vez de automação adequada para itens complexos
  • METR-style task scaling: desenvolver um gráfico de scaling que conecte sistematicamente a dificuldade da tarefa às capacidades necessárias

• Tarefas de longo prazo

  • Expansão para open-play e megabase: ampliar a dificuldade do lab-play restrito até mapas gerados proceduralmente, objetivos em múltiplas etapas e megabases com milhares de máquinas conectadas
  • Desempenho em tempo real sob restrições de latência: hoje o tempo de raciocínio entre ações é ilimitado, mas um benchmark com o Factorio rodando continuamente pode avaliar o equilíbrio entre latência de resposta e qualidade da solução
  • Coordenação multiagente: tratar cooperação, competição, emergent market dynamics, divisão de trabalho, negociação de alocação de recursos e formação de vantagem comparativa
  • Ambientes fora de distribuição baseados em mods: avaliar se é possível reaprender a estrutura causal em novas tech trees e mecânicas de jogo
  • Interface nativa de uso do computador: avaliar agentes com interface de teclado, mouse e visão como a de humanos, em vez da API Python
  • Dinâmica adversarial e robustez: introduzir aliens hostis e desafios ambientais não determinísticos para avaliar adaptive control e resilience

Como participar

• O FLE é open source tanto no código quanto nas missões
• Os perfis procurados incluem:
  • Pesquisadores que exploram novas arquiteturas para planejamento de longo prazo e raciocínio espacial
  • Engenheiros que otimizam infraestrutura de treinamento e avaliação em larga escala
  • Modders que projetam novos domínios de desafio
• Quem tiver interesse em participar da equipe pode encontrá-la no Discord

[GN⁺]

Comentários do Hacker News

• Agora estou completamente fisgado e quero me candidatar imediatamente ao laboratório de Factorio da Anthropic
  Só pelo artigo ou pelos comentários não dá para saber se eles enviam dados multimodais de volta, mas como vários modelos não são multimodais, provavelmente não. Ainda assim, alguns conseguem, e o recém-lançado Qwen 2.5 VLM parece bem forte para o tamanho
  Eles enfatizaram bastante a falta de capacidade espacial e também falaram das dificuldades tanto de planejamento quanto de planejamento espacial, então fico curioso se também estão enviando imagens como screenshots. Se não estiverem, também gostaria de saber o que pensam sobre isso
  Além disso, ativar bibliotecas Python via MCP para fazer qualquer LLM capaz de usar ferramentas jogar Factorio parece naturalmente algo que precisa ser feito

  • No momento é um ambiente somente texto, mas planejamos dar suporte a entrada visual no futuro
    Em alguns testes, incluir screenshots do estado do jogo não melhorou o desempenho dos modelos prontos. À medida que o estado do jogo ficava mais complexo e havia mais entidades no screenshot, os modelos ficavam mais confusos, alucinavam ou omitiam direções e entidades, e também não corrigiam erros evidentes, como esteiras transportadoras ausentes ou inserters girados incorretamente
    Acreditamos que isso se deve ao fato de os VLMs atuais não lidarem bem com raciocínio espacial em imagens com muitos detalhes, e há potencial de grande melhora com fine-tuning. MCP também vem ganhando muita força ultimamente, então pretendemos analisá-lo
  • Se a descrição textual do estado da fábrica é mais fácil de interpretar e causa menos confusão, não sei por que screenshots seriam necessários
    O jogo acontece sobre uma grade, então transformar o estado do jogo em uma representação ASCII deve ser simples

• Um tempo atrás houve no HN um post de uma equipe que treinou um agente com aprendizado por reforço para zerar Pokémon Red. Eles disseram que precisaram ajustar a função de custo para dar pequenas recompensas à exploração e grandes recompensas a tarefas obrigatórias, como derrotar ginásios
  Fico imaginando se a mesma abordagem poderia funcionar em Factorio. Pela analogia com Pokémon Red, as principais tarefas obrigatórias de Factorio são construir a automação de novos itens e de novos pacotes científicos
  Uma boa função de recompensa poderia dar pequenas recompensas pela produção por segundo de cada item, recompensas médias pela automação de novos itens e grandes recompensas pela automação de novos pacotes científicos
  Simplesmente dizer a um agente de Factorio “construa uma fábrica grande” é como dizer a um agente de Pokémon Red “zere o jogo”; é preciso dividir em etapas menores e usar uma função de recompensa ajustada com muito cuidado
  Pensar nisso me deu vontade de entrar nesse projeto

  • Como alguém que tem de 2 a 3 mil horas em Factorio, acrescento que o objetivo de criar “a maior fábrica possível” é vago demais e não é a métrica correta
    Quando jogadores de Factorio constroem megabases grandes, eles miram em ciência por minuto (SPM), não no tamanho em si. A métrica para dar ao agente deveria ser SPM, não a base “maior”
  • No FLE, temos acesso a marcos que indicam quando uma nova entidade foi criada pela primeira vez, mas também seria muito interessante estratificar recompensas por nível de automação. Seria ótimo explorar isso juntos
  • Essa é a parte interessante. No lab-play, Claude conseguia fazer tarefas obrigatórias e automação simples, como uma fábrica de engrenagens de ferro, mas nos episódios do jogo “construir a maior fábrica” ele nem tentava
    Os modelos conseguem executar essas tarefas obrigatórias, mas, quando recebem um objetivo genérico como “complete o jogo”, não têm planejamento de longo prazo suficiente para tentar fazê-las. Muitas vezes fazem apenas pequenas estruturas descoordenadas, sem tentar expandir a fábrica existente
    Um dos objetivos também era descobrir como os modelos se comportam quando recebem metas vagas e gerais
  • A mesma abordagem também pode ser usada na vida
  • Fico me perguntando se você leu a página. Na prática, eles deram recompensa para cada item produzido, e itens mais complexos recebiam recompensas maiores

• A parte em que avaliaram seis modelos de linguagem de fronteira em duas configurações é interessante, mas há muitos benchmarks dinâmicos bem mais simples que já conseguem saturar a capacidade de planejamento de modelos não voltados a raciocínio
  Só dar uma lista de conexões aéreas entre cidades e perguntar por um itinerário entre elas já deixa todos esses modelos confusos quando o caminho mais curto entre dois nós fica longo o suficiente
  O maior caminho mínimo entre cidades que conseguiam encontrar de forma confiável em 8 de 10 tentativas, para cada comprimento, foi o seguinte
  | 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 |

  • Sim. Há benchmarks mais simples que saturam a capacidade de planejamento desses modelos
    Ainda assim, queríamos criar um ambiente de avaliação de espectro mais amplo, que testasse várias capacidades ao mesmo tempo e pudesse continuar relevante no futuro

• Faz sentido a observação de que todos os modelos mostraram limites de planejamento espacial ao construir fábricas com várias áreas. Ou seja, falhas como posicionar entidades próximas demais, não reservar espaço para conexões ou colocar inserters de forma incorreta são comuns
  Entendo por que LLMs são fracos em raciocínio espacial: não há muitos dados de treinamento adequados para isso. Fico curioso para saber que capacidades adicionais de raciocínio surgiriam se o raciocínio espacial fosse resolvido

  • Não entendo bem a ideia de que não há muitos dados espaciais
    Mesmo com o simulador mais simples, não dá para gerar uma quantidade praticamente infinita?
    Por exemplo, só implementar jogo da velha em uma grade infinita com umas 10 linhas de código já permitiria gerar um conjunto de treinamento ilimitado

• Eu gostaria de ver projeto de balanceadores como outra categoria de tarefa do “Lab Play”
  Mesmo balanceadores pequenos podem ser bem complexos (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9), e seria interessante ver a capacidade dos modelos de projetá-los e resolver problemas

  • Alguém abordou esse problema com um solucionador SAT mais tradicional
    https://github.com/R-O-C-K-E-T/Factorio-SAT

• Ideia excelente.
  Parece haver muitos experimentos interessantes para fazer aqui. Acho uma boa ideia incluir elementos relacionados a tempo nos cenários de lab-play. A maioria dos jogadores de Factorio que joga com os biters ativados vai tratar isso como uma combinação de restrições de tempo e espaço, e impor um limite de tempo ao agente permite uma espécie de comparação substituta com situações reais de jogo.
  Gosto do fato de que o desenho desse framework testa algo diferente da capacidade de microgerenciamento que vimos em experimentos como DOTA 2 ou StarCraft 2. Em StarCraft 2, em particular, com APM infinito, surgem comportamentos como microgerenciar trabalhadores de forma extrema para extrair um pouco mais de minerais.
  Esse comportamento é um resultado de aprendizado interessante em um contexto estreito, mas, na prática, gera uma carga de controle grande e até jogadores profissionais têm alta chance de errar. Além disso, não parece oferecer insights adicionais sobre o desempenho do agente em planejamento de longo prazo, execução e análise.
  Nesse sentido, o FLE é muito mais interessante como um framework de avaliação de raciocínio em nível mais alto. Também fico curioso se há planos para benchmarks de otimização de layout, como otimizar o desempenho quando uma determinada célula de fábrica tem X entradas e Y saídas.

  • Estamos falando de criar uma tarefa mais próxima de tower defense, em que os biters seriam liberados a cada X etapas ou X segundos.
    O objetivo é testar a capacidade do agente de construir um complexo industrial militar. Um problema engraçado ao desenvolver essa ideia foi que os modelos de fronteira relutam em criar entidades com nomes como “GunTurret”. Parece que consideram isso inconstitucional. Talvez tenhamos que renomear a torre para algo como “SuperSoaker”.
    Sobre o benchmark de otimização de layout, na verdade discutimos isso ontem. Acho que precisamos de dois tipos de tarefas de layout: 1) consertar uma fábrica sutilmente quebrada, 2) melhorar a vazão dessa fábrica. A implementação deve ser relativamente fácil, então seria bom dar uma olhada nisso.

• Não entendi bem. Esses modelos foram pós-treinados para jogar Factorio?
  A) Se sim, como isso é possível em modelos sem pesos abertos, como o Claude? B) Se não, como o agente sabe o que a API faz? Mesmo que ele infira pelo significado em inglês dos comandos da API, por exemplo que place_entity_next_to coloca uma entidade ao lado de alguma coisa, como ele conhece as receitas? Se ele tenta e aprende, voltamos ao ponto A.
  Lendo o PDF, parece que não houve pós-treinamento; nesse caso, não sei como as perguntas do item B se explicam.
  Se realmente não há pós-treinamento e a exploração de receitas é esperada dentro da janela de contexto, acho que ela é curta demais para uma melhoria no estilo de aprendizado por reforço.
  Em resumo, não sei se foi possível testar esses modelos com pós-treinamento; e, se foi feito sem pós-treinamento, todos tiveram um desempenho inacreditavelmente bom.
  Se os autores estiverem lendo, gostaria de saber, em média, quantos pares de consulta à API e resposta da API entram na janela de contexto. Em seguida, também fico curioso se abreviar os nomes das chamadas de API, para colocar mais pares de resposta em uma janela de contexto, melhora os resultados.

  • Em relação às ferramentas, os agentes tinham acesso às assinaturas das funções, ou seja, às docstrings das ferramentas, aos tipos de entrada e saída, e também havia um pequeno “manual” para cada ferramenta.
    Esse manual explicava o que a ferramenta faz, como ela afeta o estado do jogo e alguns exemplos de uso, como colocar um inserter ao lado de um baú existente com place_entity_next_to.
    Como Jack disse, não houve nenhum pós-treinamento, mas todos os agentes tinham no contexto uma descrição completa da API, incluindo ferramentas, entidades e pesquisas. Portanto, esses resultados mostram, em certa medida, quão bem agentes modernos conseguem usar uma API totalmente fora de distribuição quando há documentação adequada.
  • Esses modelos não foram pós-treinados; todos eram modelos prontos, sem alterações.
    Cabiam no máximo cerca de 128 pares no contexto, mas como o desempenho foi igual ao de 32 pares, no fim escolhemos 32 pares por causa de custo e latência.
    Codificar entradas e saídas de forma mais curta piorou o desempenho. Parece que nomes descritivos ajudam porque dão aos modelos pré-treinados uma intuição sobre o que aquilo faz.
  • Lendo a nota de rodapé da apresentação dos autores, parece que um deles trabalha na Anthropic. Imagino que tenha havido acesso interno.

• É interessante que haja apenas alguns cenários complexos. Sempre achei que, para um agente de jogo de ML aprender bem as mecânicas de um jogo, seriam necessários centenas de quebra-cabeças bem pequenos, cada um com centenas de variações.
  Por exemplo: a fábrica está sem energia, então colocar o poste elétrico que está faltando; a fábrica está sem itens, então colocar a esteira que falta; fabricar e posicionar 200 máquinas de montagem; uma máquina de montagem parou por algum motivo, então consertá-la; a produção da fábrica está baixa demais, então dobrá-la; mover-se o mais rápido possível até outro ponto da fábrica; corrigir falta de energia; e dividir todas essas tarefas em casos com e sem robôs.
  Deveria ser relativamente fácil gerar programaticamente alguns milhares desses cenários de exemplo. Depois, eles poderiam ser usados como um banco de questões de teste de QI: escolher umas 12 questões do banco e avaliar o desempenho em cada uma com base no tempo e nos materiais usados.
  Acho que um agente de ML, ao ser avaliado por amostras de um grande banco de cenários com complexidade aumentando de forma suave, aprende mais rápido quando, depois de atingir uma pontuação suficientemente alta em baixa complexidade, recebe cenários mais complexos.

  • Como você sugeriu, gerar cenários em texto é fácil, mas criar o estado correto do jogo da fábrica que sirva como ponto de partida é muito mais difícil.
    Pelo que sei, no fim isso acaba virando o mesmo trabalho de projetar manualmente o estado inicial e a tarefa a ser concluída.
  • Para treinamento adicional, estamos pensando nessa abordagem de currículo.
    Mas o trabalho atual focou em avaliação, então não fizemos isso. A “dificuldade” de tarefas diferentes é bastante subjetiva, o que exigiria decisões arbitrárias que poderiam afetar a avaliação. Por exemplo, questões como qual tarefa deve vir depois de qual cenário, ou se todos os níveis de dificuldade estão suficientemente cobertos.

• Fico curioso se existe um benchmark de humanos jogando com esse tipo de interface. Não estou dizendo que seja necessário ou relevante; só tenho curiosidade sobre qual é a sensação de jogar Factorio de forma programática.
  Fazer raciocínio espacial em torno de prompts de texto parece ser bastante difícil até para jogadores humanos.

  • O benchmark humano de Factorio são os speedrunners que correm para lançar o primeiro foguete.
    O recorde atual é de pouco mais de 4 horas no modo solo e 90 minutos em equipe. Só isso já mostra que há espaço para um LLM multitarefa superar humanos.

• Fico curioso se, daqui a alguns anos, todos os adversários dentro dos jogos serão LLMs com acesso a esse tipo de API de controle do jogo
  Também fico curioso se havia tipos de tarefas especialmente difíceis para os modelos, ou se a dificuldade aumentava principalmente conforme o número de itens que precisavam ser posicionados

  • É muito improvável que LLMs sejam usados em massa como adversários. A IA dos inimigos na maioria dos jogos não precisa do nível de complexidade exigido por machine learning. Mesmo deixando de lado o custo computacional
    O principal objetivo da IA inimiga não é ser a entidade mais difícil do mundo, mas oferecer um desafio interessante que o jogador consiga superar. Na maioria dos jogos, criar uma IA extremamente poderosa não é necessariamente difícil, mas isso não a torna mais divertida de enfrentar
    A maioria dos jogos tem um estado lógico finito, só que grande o bastante para humanos não encontrarem todas as soluções. Claro, humanos são muito bons em pressionar as bordas desses estados e encontrar atalhos
    Mesmo em jogos com uma quantidade de estados muito maior que o normal, é raro alguém querer uma super IA. Por exemplo, ninguém gosta de jogar contra um aimbot em um FPS
    Factorio é uma exceção em relação a jogos comuns porque a condição real de “vitória” depende quase inteiramente do jogador. No Factorio sem DLC, é possível construir o foguete, que é a condição de vitória do jogo, quase sem montar uma fábrica além das estruturas mais básicas para coisas que não podem ser feitas à mão. Seria extremamente lento, mas é uma opção possível. Por isso, em um benchmark assim, eficiência é mais importante do que “funciona?”
  • Acho possível. Porque não é necessário nenhum cálculo de treinamento separado para fazê-lo funcionar. Se a API for disponibilizada, fica muito fácil conectar vários modelos novos a um jogo de forma plug and play
    Os modelos têm dificuldade principalmente em duas áreas. A primeira é raciocínio espacial. Os modelos frequentemente cometem erros off-by-one, e fábricas, como programação, são muito sensíveis a esse tipo de erro, tornando a recuperação difícil
    A segunda é planejamento de longo prazo. É a capacidade de entender estrategicamente o que precisa ser feito antes de criar subobjetivos táticos
    No lab-play, a dificuldade geralmente é proporcional à profundidade da cadeia de produção. Se, para criar um item, forem necessárias primeiro várias seções de fábrica, fica muito mais difícil. Isso parece estar relacionado ao planejamento, porque os modelos tendem a mergulhar nos detalhes de consertar pequenos problemas em vez de primeiro elaborar um plano maior
  • Vendo “Claude plays Pokémon”, ele sofre em Mount Moon, e eu também sofria quando tinha quatro anos
  • Por que precisa ser um LLM? Esse tipo de coisa não é algo em que AlphaZero é bom? Existem muitos modelos de machine learning úteis além de LLMs!