Factorio öğrenme ortamı – fabrika kuran ajanlar

(jackhopkins.github.io)

1 puan yazan GN⁺ 2025-03-12 | 1 yorum | WhatsApp'ta paylaş

Fabrika otomasyonu oyunu Factorio kullanılarak ajanların uzun vadeli planlama ve uzamsal akıl yürütme yeteneklerini doğrulayan FLE 0.3.0 yayımlandı; Claude Code’u Factorio’ya bağlayan bir demo da içeriyor
Yeni sürüm, headless çalıştırma, piksel gözlem renderer’ı, OpenAI Gym uyumlu arayüz, CLI ile değerlendirme çalıştırma, Weights and Biases günlükleme ve analiz araçlarıyla araştırma deneylerini kolaylaştırıyor
Örnek ajan; elektrik üretimi, demir cevheri madenciliği, ergitme, montaj makinesi yerleştirme ve bant bağlantılarını yinelemeli olarak debug ederek dakikada 16 iron gear wheel üretim hedefine ulaşıyor
Lab-play benchmark’ı, Eylül 2025 itibarıyla güçlü modeller için Pass@8’i değerlendiriyor; katı item’lar için dakikada 16, sıvılar için dakikada 250 üretim hedefi ve en fazla 64 adımlık sınır koyuyor
Frontier modeller v0.2.0’a göre ilerleme kaydetti; ancak elle taşıma, sandık buffer’ları, API’nin yanlış kullanımı ve dinamik oyun durumunu yanlış değerlendirme sorunları sürdüğü için Factorio, uzun vadeli planlama ve dinamik toparlanma becerisini ortaya çıkaran zorlu bir ortam olmayı sürdürüyor

FLE 0.3.0’da değişenler

FLE 0.3.0, Factorio’da fabrika inşa etme görevleriyle uzun vadeli planlama, akıl yürütme ve dünya modellemeyi test eden öğrenme ortamının büyük bir güncellemesidir
Önceki FLE paper, frontier modellerin değişen ortamlara uyum, uzun vadeli hedef belirleme ve dinamik toparlanmada zorlandığını göstermişti; 0.2.0 ise çoklu ajan yapısını, backtracking ajanını ve vision’ı tanıtmıştı
0.3.0’daki başlıca değişiklikler:
- Claude Code, FLE üzerinden Factorio’ya bağlandı ve Twitch’te gösterildi
- Factorio oyun istemcisi bağımlılığı kaldırılarak büyük ölçekli deneyleri mümkün kılan headless ölçekleme desteklendi
- Yeni headless oyun renderer’ı, multimodal ajan araştırmaları için gerçekçi piksel gözlemleri sağlıyor
- Değerlendirme ortamı OpenAI Gym arayüzüne uyarlanarak mevcut araştırma kod tabanlarıyla entegrasyonu kolaylaştırıldı
- FLE CLI ile tek satırlık shell komutlarıyla deney çalıştırma destekleniyor; değerlendirme kodu, Weights and Biases günlükleme, sweep’i sürdürme ve analiz araçları açık kaynak olarak sunuluyor

Hızlı başlangıç

# 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 uv ile kurulur; fle cluster start ile Factorio sunucu kümesi başlatılır, ardından .env içindeki API anahtarları ve yapılandırma dosyasıyla değerlendirme çalıştırılır

Otomatik iron gear wheel fabrikası örneği

Örnek ajan, lab-play dünyasında item envanteri ve iron gear wheel fabrikası kurma hedefi verilmiş halde başlar
Python ile FLE API’sini çağırarak oyun ortamıyla etkileşir ve her çalıştırma sonucunun standart çıktısını ve hata mesajlarını gözlemler
Elektrik kurulumu
- nearest(Resource.Water) ile su konumunu bulur ve offshore pump yerleştirir
- Boiler ve steam engine yerleştirdikten sonra connect_entities ile boruları bağlar ve boiler’a coal koyar
- 5 saniye bekledikten sonra steam engine’in energy değerini kontrol ederek elektrik üretimini doğrular
Demir madenciliği ve ergitme
- Iron ore konumunu bulduktan sonra 2 electric mining drill ve electric furnace yerleştirir
- Dakikada 16 iron gear wheel için dakikada 32 iron plate gerektiğini, electric mining drill’in 60 saniyede 30 ore çıkardığını hesaplayarak 2 drill gerektiği sonucuna varır
- Drill’ler ve electric furnace, medium electric pole ile steam engine elektrik ağına bağlanır
Montaj makinesi yerleştirme
- Madencilik alanından en az 20 tile uzaklıkta AssemblingMachine2 yerleştirir
- Montaj makinesinin recipe’sini Prototype.IronGearWheel olarak ayarlar; input/output inserter’ları yerleştirir ve elektrik ağına bağlar
- Assembling machine 2, 60 saniyede 90 iron gear wheel üretebildiği için hedef throughput için 1 adet yeterlidir
Bant bağlantısı ve hata toparlama
- Furnace output inserter ile assembler input inserter’ı doğrudan belt ile bağlamaya çalışır, ancak storage chest’in yolu kapattığını fark eder
- Yolu kapatan 2 wooden chest’ten iron plate’leri çıkarıp sandıkları kaldırır; ancak assembler tarafındaki input buffer chest’i bıraktığı için yeniden hata oluşur
- Sonunda assembler input chest’i de kaldırır ve transport belt tabanlı lojistik ağı bağlayarak otomatik iron gear wheel sistemi hedef throughput’a ulaşır

Gözlem uzayı ve ajan harness’i

Her adımda ajan, oyun durumunu içeren yapılandırılmış bir Observation nesnesi alır
Başlıca alanlar:
- raw_text: Önceki action program çalıştırmasının standart çıktısı ve hata mesajları, kaynak kod satır numaraları
- entities: Oyun dünyasındaki tüm entity’ler ve bunların konum, tip, yön, envanter, uyarı gibi özellikleri
- inventory: Ajanın kişisel envanterindeki item tipleri ve miktarları
- research: Araştırılmış teknolojiler, mevcut araştırma ilerlemesi, ön koşulları ve maliyetleri olan kullanılabilir teknolojiler
- game_info: Tick sayısı, geçen süre, oyun hızı
- flows: Girdi/çıktı oranları, üretilen item’lar, toplanan kaynaklar, ekonomik değerlendirme için isteğe bağlı fiyat listesi
- messages: Çoklu ajan koordinasyonu için ajanlar arası mesajlar
- task_info: Hedef açıklaması, talimatlar, task identifier, maksimum trajectory uzunluğu
- task_verification: Başarı/başarısızlık ve hedef ilerleme metadata’sı
- serialized_functions: Daha önce tanımlanmış helper function’lar ve abstraction’lar
- map_image: Görsel ajanlar için base64 kodlu PNG fabrika yerleşimi
Bu gözlem uzayı uzamsal farkındalığı, üretim metriklerini izlemeyi, hata debug etmeyi ve çok adımlı otomasyon planlamayı destekler
Değerlendirme ajan harness’i bu alanları biçimlendirilmiş bir Markdown string olarak birleştirir

Lab-play benchmark ayarı

Lab-play, sabit kaynaklar ve tek bir hedef entity verip üretim throughput’unu maksimize etmeye odaklanan sınırlı bir ortamdır
Open-play, prosedürel olarak oluşturulmuş haritalarda başlangıç envanteri olmadan, daha seyrek kaynaklar ve karmaşık hedeflerle uğraşmayı gerektirdiği için çok daha karmaşıktır
Eylül 2025 itibarıyla güçlü modeller için orijinal FLE paper’ın metodolojisi lab-play ayarına uyarlanarak tekrarlandı
Standartlaştırılmış ajan harness’i, ortam etkileşimlerini tek bir konuşma kaydına eklemeyi sürdürür; token bütçesi azaldığında eski kayıtları özetleyerek akıl yürütmenin devam etmesini sağlar
FLE 0.2.0’da kullanılan backtracking veya reflection mantığı değerlendirilmez
Değerlendirme koşulları
- Hedef: Katı item’larda dakikada 16, sıvılarda dakikada 250 üretim throughput’una ulaşmak
- Prompt: FLE API dokümantasyonu, Factorio recipe’leri, genel pattern kılavuzu
- Envanter: İşlevsel bir fabrika kurmak için yararlı item seti
- Maksimum adım: 64 adım; tamamlandığında erken sonlandırma
- Akıl yürütme: Reasoning’i destekleyen modellere varsayılan {"enabled": true} ayarı uygulanır

Model performansı ve kalan sınırlar

Açık kaynak modeller, Mayıs 2025’te v0.2.0’da gözlenen güncel en iyi performansı yakaladı; electronic circuits, steel plate, sulfur ve plastic otomasyonunda başarılı örnekler görüldü
En yeni frontier modeller FLE v0.2.0’a kıyasla belirgin biçimde iyileşti ve ilk kez 12’den fazla ingredient dependency kullanabilen, daha zor görevlerin yarısında da başarı sağladı
FLE lab-play’de gelişmiş modellerin sıralaması ve performans farkları yaklaşık olarak Claude > GPT > Gemini > Grok şeklindeydi ve OpenAI’nin GDPVal sonucuna en çok benziyordu
Humanity's Last Exam, AIME 25, GPQA, MMMU gibi statik sınav tipi benchmark’larda FLE’de zayıf kalan modellerin daha yüksek performans gösterdiği durumlar da olduğu için sonuçlar belirgin biçimde ayrışıyor
Başarılı ajanlar bile karmaşık task’lerde sağlam otomasyon yerine sık sık yarı manuel stratejilere dayanıyor
- Kaynakları doğrudan taşıma
- Storage chest’i kaynak buffer’ı olarak kullanma
- Tam otomatik lojistik zinciri kurmayı atlama
Ara buffer’lar throughput kontrolünü geçici olarak karşılayabildiği için ölçümü zorlaştırır
Değerlendirme, ajan fabrikayı 60 saniye boyunca olduğu gibi bıraktıktan sonraki holdout period sonunda kotanın karşılanıp karşılanmadığını kontrol ederek bu sorunu hafifletir
Daha yüksek throughput hedefleri verildiğinde manuel lojistikle geçmek zorlaşır ve uygun otomasyonu zorunlu kılabilir

Hata türleri ve modellere göre farklar

Frontier modeller, hatalar biriktiğinde bunlardan toparlanmakta zorlanmayı sürdürüyor
Ortalama hata oranı karşılaştırması: {b:23,25,27,41}
Ortalama hata oranı:
- Claude Opus 4.1: %22,99
- GPT-5: %25,05
- Gemini 2.5 Pro: %27,29
- Grok 4: %40,89
Grok 4 sık sık gerileyen debug döngülerine giriyor; GPT-5 ise daha zarif biçimde toparlanan bir örüntü gösteriyor
Çoğu modelde fabrika karmaşıklığının arttığı trajectory’nin orta bölümlerinde hata oranı yükseliyor
Başarısızlık türleri
- Söz dizimi hatası: Geçersiz Python kodu, gramer hataları, çalıştırmayı doğrudan engelleyen hatalar
- Anlam hatası: FLE komutlarının veya araç argümanlarının yanlış kullanımı, dokümantasyonu anlama başarısızlığı, TypeError, AttributeError, NameError vb.
- Pratik hata: Mevcut oyun durumu hakkında yanlış akıl yürütme; örneğin envanterde olmayan item’ı yerleştirmeye çalışma
- Planlama ve kontrol hatası: Primitive’leri bilse bile eylemleri tutarlı biçimde bağlayamama; verimsiz veya eksik trajectory’ye yol açma
- Bu kategori, tekil hata türlerinden çok üst düzey stratejik tutarlılığa bakmayı gerektirdiği için otomatik trajectory analiziyle güvenilir biçimde nicelleştirilmesi zordur
Modellere göre hata dağılımı
- Claude Opus 4.1’de söz dizimi hatası yoktur ve hataların %97,7’si pratik hataya yakındır; bu, kod üretiminin güçlü olduğunu ancak oyun durumunun doğru mental model’ını sürdürmekte zorlandığını gösterir
- Gemini 2.5 Pro, Grok 4 ve GPT-5, %12–17 düzeyinde API anlama hatası göstererek FLE API dokümantasyonunu doğru kullanmakta zorlanıyor
- GPT-5 ve Grok 4 sırasıyla %21 ve %17 söz dizimi hatası gösteriyor; güncel üst düzey coding benchmark modelleri için geçerli Python üretiminde başarısızlığın sık görüldüğüne işaret ediyor
- Yalnızca Gemini 2.5 Pro, mevcut helper function ve abstraction’ları tanımlayıp kullanan bir yaklaşım sergiliyor

Claude Code ve MCP

v0.2.0’da dış ajanların FLE ile etkileşebilmesi için MCP server yayımlandı
v0.3.0’da bu genişletilerek Claude Code adapter’ı eklendi
Factorio oynayan Claude Code yayını Twitch üzerinden izlenebilir

Sonraki araştırma yönleri

Mevcut frontier modeller, insan ölçütlerine göre Factorio’da çok iyi değil; dinamik ortam temsili ve modelleme ile gelecekte araç olarak kullanılabilecek formal abstraction geliştirme konularında zorlanıyor
Yine de 2025 boyunca lab-play’de frontier modellerin yetenekleri istikrarlı biçimde gelişti
Factorio, uzun vadeli planlama, domain adaptasyonu, dünya modelleme ve uzamsal akıl yürütme gibi genel model becerilerini ortaya çıkaran bir ortam olarak kullanılmaya devam edebilir
FLE v0.3.0, lab-play’i ilk formal benchmark olarak konumlandırıyor; ancak araştırma planının başlangıç noktasıdır
Yakın vadeli görevler
- İnsan baseline’ı: Task zorluğuna göre insan performansını sistematik biçimde ölçerek ajan becerisini kalibre etmek
- Reward hacking’e karşı önlem: Ajanların karmaşık item’larda uygun otomasyon yerine manual crafting kullanması sorununu ele almak
- METR-style task scaling: Task zorluğu ile gerekli becerileri sistematik olarak ilişkilendiren bir scaling chart geliştirmek
Uzun vadeli görevler
- Open-play ve megabase genişlemesi: Sınırlı lab-play’den prosedürel haritalara, çok aşamalı hedeflere ve binlerce bağlı makine içeren megabase’lere kadar zorluğu genişletmek
- Gecikme kısıtları altında gerçek zamanlı performans: Şu anda eylemler arasında düşünme süresi sınırsız; Factorio’nun çalışmaya devam ettiği benchmark’larla yanıt gecikmesi ve çözüm kalitesi arasındaki dengeyi değerlendirmek
- Çoklu ajan koordinasyonu: İş birliği, rekabet, emergent market dynamics, iş bölümü, kaynak tahsisi müzakereleri ve comparative advantage oluşumunu ele almak
- Mod tabanlı dağılım dışı ortamlar: Yeni tech tree ve oyun mekaniklerinde causal structure’ın yeniden öğrenilip öğrenilemediğini değerlendirmek
- Native computer-use interface: Python API yerine insan benzeri klavye, fare ve vision arayüzüyle ajanları değerlendirmek
- Karşıt dinamikler ve sağlamlık: Hostile aliens ve deterministik olmayan ortam zorlukları ekleyerek adaptive control ve resilience’ı değerlendirmek

Katılma yolu

FLE’nin hem kodu hem de görevleri açık kaynak
İhtiyaç duyulan katılımcılar:
- Uzun vadeli planlama ve uzamsal akıl yürütme için yeni mimarileri araştıran araştırmacılar
- Büyük ölçekli değerlendirme ve eğitim altyapısını optimize eden mühendisler
- Yeni challenge domain’leri tasarlayan modder’lar
Ekibe katılmakla ilgileniyorsanız Discord üzerinden ulaşabilirsiniz

1 yorum

GN⁺ 2025-03-12

Hacker News yorumları

Artık tamamen oltaya geldim; Anthropic Factorio araştırma laboratuvarına hemen başvurmak istiyorum.
Makaleden ya da yorumlardan multimodal veriyi geri gönderip göndermediklerini anlayamıyorum; ama birçok model multimodal olmadığı için muhtemelen göndermiyorlardır. Yine de bazıları bunu yapabiliyor ve yakın zamanda çıkan Qwen 2.5 VLM, boyutuna göre epey güçlü görünüyor.
Mekânsal beceri eksikliğini epey vurgulamışlar; hem planlama hem de mekânsal planlamadaki zorluklardan söz etmişler. Bu yüzden ekran görüntüsü gibi görüntüler de gönderip göndermediklerini merak ediyorum. Göndermiyorlarsa bu konudaki düşüncelerini de merak ediyorum.
Ek olarak, MCP ile Python kütüphanelerini etkinleştirip araç kullanabilen tüm LLM’lere Factorio oynatmak, doğal olarak mutlaka yapılması gereken bir şey gibi görünüyor.
- Şu anda yalnızca metin tabanlı bir ortam, ancak ileride görsel girdiyi desteklemeyi planlıyoruz.
  Bazı testlerde oyun durumunun ekran görüntüsünü eklemek, hazır modellerin performansını artırmadı. Oyun durumu karmaşıklaştıkça ve ekran görüntüsünde daha fazla varlık oldukça modeller daha da kafası karışık hâle geldi; yönleri ya da varlıkları halüsinasyona uğrattı veya eksik taşıma bantları, yanlış döndürülmüş inserter’lar gibi bariz hataları bile düzeltemedi.
  Bunun, mevcut VLM’lerin çok ayrıntı içeren görüntülerde mekânsal akıl yürütmeyi iyi yapamamasından kaynaklandığını düşünüyoruz; ince ayar yapılırsa ciddi ölçüde iyileşme potansiyeli var. MCP de son dönemde hızla yükseliyor, ona da bakacağız.
- Fabrika durumunun metinsel açıklaması yorumlaması daha kolaysa ve daha az kafa karıştırıyorsa ekran görüntüsüne neden ihtiyaç var, bilmiyorum.
  Oyun bir ızgara üzerinde ilerlediğine göre, oyun durumunu ASCII gösterime dönüştürmek basit olmalı gibi geliyor.
Kısa süre önce HN’de, pekiştirmeli öğrenmeyle Pokémon Red’i bitiren bir ajan eğiten bir ekibin yazısı vardı. Keşif için küçük ödüller, spor salonlarını yenmek gibi zorunlu görevler için büyük ödüller verecek şekilde maliyet fonksiyonunu ayarlamaları gerektiğini söylemişlerdi.
Aynı yaklaşımın Factorio’da da kullanılıp kullanılamayacağını merak ediyorum. Pokémon Red benzetmesiyle bakarsak, Factorio’daki başlıca zorunlu görevler yeni eşyalar ve yeni bilim paketleri için otomasyon kurmak.
Her eşyanın saniye başına üretim miktarına küçük bir ödül, yeni bir eşyanın otomasyonuna orta düzey bir ödül, yeni bir bilim paketinin otomasyonuna büyük bir ödül vermek iyi bir ödül fonksiyonu olabilir.
Factorio ajanına sadece “büyük bir fabrika yap” demek, Pokémon Red ajanına “oyunu bitir” demekle aynı; bunu daha küçük adımlara ve çok dikkatli ayarlanmış bir ödül fonksiyonuna bölmek gerekiyor.
Bunu düşündükçe bu projeye atlamak istiyorum.
- Factorio’da 2-3 bin saat geçirmiş biri olarak ekleyeyim: “mümkün olan en büyük fabrikayı” yapma hedefi fazla belirsiz ve doğru metrik değil.
  Factorio oyuncuları büyük megabase’ler kurarken boyutun kendisini değil, dakika başına bilim araştırması miktarını (SPM) hedefler. Ajana verilecek metrik “en büyük” üs değil, SPM olmalı.
- FLE’de yeni bir varlığın ilk kez üretildiği anı gösteren kilometre taşlarına erişim var; ama ödülleri otomasyon düzeylerine göre katmanlandırmak da gerçekten ilginç olur. Birlikte denemek güzel olurdu.
- İlginç bir nokta. Claude, lab-play’de demir dişli çark fabrikası gibi zorunlu görevleri ve basit otomasyonu yapabiliyordu; ama “en büyük fabrikayı yap” oyun bölümünde bunu denemedi bile.
  Modeller bu tür zorunlu görevleri yerine getirebiliyor; ancak “oyunu tamamla” gibi genel bir hedef verildiğinde, bunu deneyecek kadar uzun vadeli planlama düzeyinden yoksunlar. Çoğu zaman mevcut fabrikayı genişletmeye çalışmak yerine, koordine edilmemiş küçük yapılar inşa ediyorlar.
  Belirsiz ve genel bir hedef verildiğinde modelin nasıl davrandığını görmek de hedeflerimizden biriydi.
- Aynı yaklaşım hayatta da kullanılabilir.
- Sayfayı okuyup okumadığını merak ediyorum. Gerçekte üretilen her eşya için ödül verildi ve daha karmaşık eşyalara daha yüksek ödül verildi.
Altı frontier dil modelinin iki ayarda değerlendirildiği kısım ilginç, ancak akıl yürütme yapmayan modellerin planlama kapasitesini doyurabilecek çok daha basit dinamik benchmarklar da çok.
Şehirler arası uçuş bağlantılarının bir listesini verip aralarındaki yolculuğu sormak bile yeterli; iki düğüm arasındaki en kısa yol yeterince uzadığında bu modellerin hepsi kafası karışıyor.
Her uzunluk için 10 denemenin 8’inde istikrarlı biçimde bulunabilen şehirler arası en uzun en kısa yollar şunlardı:
| Model | Path Length |
|------------------+-------------|
| Claude Sonnet3.5 | 10 |
| GPT-4o | 7 |
| GPT-4o-mini | 4 |
| Deepseek-v3 | 6 |
| Gemini-2-Flash | Test edilmedi |
| Llama3.3-70B-Ins | 4 |
- Doğru. Bu modellerin planlama kapasitesini doyuran daha basit benchmark’lar var.
  Ancak biz birden fazla beceriyi aynı anda test eden ve gelecekte de geçerli kalabilecek daha geniş spektrumlu bir değerlendirme ortamı oluşturmak istedik.
Birden fazla bölgeden oluşan fabrikalar inşa ederken tüm modellerin mekânsal planlama sınırları göstermesi mantıklı. Varlıkları birbirine çok yakın yerleştirme, bağlantı için alan bırakmama, inserter’ları yanlış koyma gibi başarısızlıkların yaygın olduğu söyleniyor.
LLM’lerin mekânsal akıl yürütmede neden zayıf olduğunu anlıyorum. Buna uygun eğitim verisi çok fazla yok. Mekânsal akıl yürütme çözülürse hangi ek akıl yürütme becerilerinin ortaya çıkacağını merak ediyorum.
- Mekânsal verinin çok olmadığı kısmını pek anlayamıyorum.
  En basit simülatör bile olsa pratikte sonsuz miktarda üretilemez mi?
  Örneğin sonsuz bir ızgara üzerinde tic-tac-toe’yu 10 satır kadar kodla uygulamak bile sınırsız bir eğitim seti üretebilir.
“Lab Play” görevlerinin başka bir kategorisi olarak balancer tasarımı görmek isterim.
Küçük balancer’lar bile oldukça karmaşık olabilir (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9); modellerin bunları tasarlama ve sorun çözme becerisini görmek ilginç olurdu.
- Birileri bu probleme daha geleneksel bir SAT çözücü ile yaklaşmıştı.
  https://github.com/R-O-C-K-E-T/Factorio-SAT
Harika bir fikir
Burada denenebilecek çok sayıda ilginç deney var gibi görünüyor. lab-play senaryosuna zamanla ilgili bir unsur eklemek iyi bir fikir gibi. Isırıcıları açıp oynayan Factorio kullanıcılarının çoğu bunu zaman-mekân kısıtlarının birleşimi olarak ele alacaktır; ajana bir süre sınırı koymak da gerçek oyun durumlarıyla bir tür vekil karşılaştırma yapmayı mümkün kılar
Bu çerçeve tasarımının DOTA 2 veya StarCraft 2 deneylerinde gördüğümüz türden mikro yönetim becerisinden farklı bir şeyi test etmesi hoşuma gidiyor. Özellikle StarCraft 2'de sınırsız APM olduğunda, işçileri aşırı ince ayarla kontrol edip biraz daha fazla mineral toplatma gibi davranışlar ortaya çıkıyor
Bu davranış dar bağlamda ilginç bir öğrenme sonucu olsa da, pratikte kontrol yükü yüksek ve profesyonel oyuncuların bile hata yapma olasılığı var. Ayrıca ajanın uzun vadeli planlama, yürütme ve analiz performansı hakkında ek bir içgörü sağlıyor gibi de görünmüyor
Bu açıdan FLE, daha üst düzey bir düşünme değerlendirme çerçevesi olarak çok daha ilginç. Verilen bir fabrika hücresinde X adet girdi ve Y adet çıktı varken performansı optimize etmek gibi yerleşim optimizasyonu benchmark'ları planlanıyor mu, onu da merak ediyorum
- Isırıcıların X aşamada veya her X saniyede bir salıverildiği, biraz daha tower defense türüne yakın görevler oluşturmaktan bahsediyoruz
  Amaç, ajanın askeri-sanayi kompleksi kurma becerisini test etmek. Bu fikri geliştirirken komik olan sorun, frontier modellerin GunTurret gibi adlara sahip varlıklar oluşturmaktan kaçınmasıydı. Bunu anayasaya aykırı görüyor gibiler. Belki de taret adını SuperSoaker gibi bir şeye çevirmemiz gerekebilir
  Yerleşim optimizasyonu benchmark'ı konusunda aslında dün konuştuk. İki tür yerleşim görevi gerektiğini düşünüyorum. 1) Hafifçe bozulmuş bir fabrikayı düzeltmek, 2) bu fabrikanın throughput'unu iyileştirmek. Uygulaması nispeten kolay olur; bir bakmak iyi olabilir
Tam anlayamadım. Bu modeller Factorio oynamaları için sonradan eğitilmiş mi?
A) Öyleyse Claude gibi açık ağırlıkları olmayan modellerde bu nasıl mümkün? B) Değilse ajan API'nin ne yaptığını nasıl biliyor? API komutlarının İngilizce anlamından, örneğin place_entity_next_tonun bir şeyin yanına bir varlık koyduğu gibi çıkarım yaptığını varsaysak bile, tarifleri nasıl biliyor? Deneyip öğreniyorsa yine A'ya dönüyoruz
PDF'yi okuyunca sonradan eğitim yapılmamış gibi görünüyor; öyleyse B'deki soruların nasıl açıklandığını bilmiyorum
Gerçekten sonradan eğitim yoksa ve tarif keşfinin bağlam penceresinden beklenmesi söz konusuysa, bunun pekiştirmeli öğrenme tarzı iyileştirme için fazla kısa olduğunu düşünüyorum
Özetle, bu modellerin sonradan eğitimle test edilip edilemediğini bilmiyorum; sonradan eğitim olmadan yapıldıysa hepsi inanılması güç derecede iyi iş çıkarmış
Yazarlar görürse, ortalama olarak bağlam penceresine kaç API sorgusu ve API yanıtı çifti sığdığını merak ediyorum. Devamında, API çağrı adlarını kısaltıp bir bağlam penceresine daha fazla yanıt çifti koymanın sonuçları iyileştirip iyileştirmediğini de merak ediyorum
- Araçlar açısından ajanların fonksiyon imzalarına, yani araç docstring'lerine, giriş/çıkış tiplerine erişimi vardı; ayrıca her araç için küçük bir “kılavuz” da bulunuyordu
  Bu kılavuz aracın ne yaptığını, oyun durumunu nasıl etkilediğini ve place_entity_next_to ile mevcut bir sandığın yanına yerleştirici koyma gibi birkaç kullanım örneğini açıklıyordu
  Jack'in söylediği gibi sonradan eğitim hiç yoktu; ancak tüm ajanların bağlamında araçları, varlıkları ve araştırmaları içeren eksiksiz bir API açıklaması vardı. Dolayısıyla bu sonuçlar, modern ajanların uygun dokümantasyonu olan tamamen dağılım dışı bir API'yi ne kadar iyi kullanabildiğini bir ölçüde gösteriyor
- Bu modeller sonradan eğitilmedi; hepsi kullanıma hazır modellerin aynısıydı
  Bağlama en fazla yaklaşık 128 çift koyabiliyorduk, ancak 32 çiftle performans aynı olduğu için maliyet ve gecikme nedeniyle nihai olarak 32 çifti seçtik
  Girdi/çıktıyı daha kısa kodlamak performansı düşürdü. Ön eğitimli modellerde açıklayıcı adlar, ne yaptıklarına dair sezgi verdiği için yardımcı oluyor gibi görünüyor
- Yazar tanıtımındaki dipnotu okursanız, birinin Anthropic'te çalışıyor gibi göründüğünü görürsünüz. Muhtemelen içeriden erişimi vardı
Yalnızca birkaç karmaşık senaryo olması ilginç. ML oyun ajanlarının oyun mekaniklerini doğru düzgün öğrenebilmesi için, her birinin yüzlerce varyasyonu olan yüzlerce çok küçük bulmaca gerektiğini hep düşünmüşümdür
Örneğin şunlar gibi: fabrikada elektrik yok, eksik elektrik direğini yerleştir; fabrikada öğe eksik, eksik bandı yerleştir; 200 montaj makinesi üretip yerleştir; montaj makinesi bir nedenle durmuş, düzelt; fabrika üretimi çok düşük, iki katına çıkar; fabrika içindeki başka bir noktaya olabildiğince hızlı git; elektrik yetersizliğini düzelt; ve tüm bu görevleri robotların olduğu ve olmadığı durumlara ayır
Bu tür örnek senaryolardan birkaç bin tanesini programla üretmek nispeten kolay olmalı. Sonra bunlar bir IQ testi soru bankası gibi kullanılabilir; soru bankasından yaklaşık 12 tanesi çekilip, her biri süreye ve kullanılan malzemeye göre değerlendirilebilir
ML ajanlarının, karmaşıklığı yumuşak biçimde artan büyük bir senaryo bankasından örneklenerek değerlendirildiğinde ve düşük karmaşıklıkta yeterince yüksek puan aldıktan sonra daha karmaşık senaryolar sunulduğunda daha hızlı öğrendiğini düşünüyorum
- Önerdiğiniz gibi senaryoları metin olarak üretmek kolay, ancak başlangıç noktası olacak doğru fabrika oyun durumunu oluşturmak çok daha zor
  Bildiğim kadarıyla iş sonunda yine başlangıç durumunu ve tamamlanacak görevleri elle tasarlamaya varıyor
- Ek eğitim için böyle bir müfredat yaklaşımı düşünüyoruz
  Ancak mevcut çalışma değerlendirmeye odaklandığı için bunu yapmadık. Farklı görevlerin “zorluğu” oldukça öznel olduğundan, değerlendirmeyi etkileyebilecek keyfi kararlar almak gerekir. Örneğin hangi görevin hangi senaryodan sonra gelmesi gerektiği veya tüm zorluk seviyelerinin yeterince kapsanıp kapsanmadığı gibi meseleler var
Bu arayüz yöntemi için bir insan oyuncu benchmark'ı olup olmadığını merak ediyorum. Mutlaka gerekli ya da ilgili demek istemiyorum; programatik Factorio'nun nasıl hissettirdiğini merak ediyorum
Metin istemleri etrafında mekânsal akıl yürütme yapmak insan oyuncular için de epey zor olabilir
- Factorio'nun insan benchmark'ı, ilk roket fırlatmaya odaklanan speedrunner'lardır
  Mevcut rekor tek oyuncuda 4 saatin biraz üzerinde, takımda ise 90 dakika. Sadece bu bile çok görevli bir LLM'in insanları geçebileceği bir alan olduğunu gösteriyor
Birkaç yıl sonra oyundaki tüm rakiplerin, böyle bir oyun kontrol API’sine erişebilen LLM’ler olup olmayacağını merak ediyorum
Modellerin özellikle zorlandığı görev türleri var mıydı, yoksa zorluk esas olarak yerleştirilmesi gereken öğe sayısına göre mi artıyordu, onu da merak ediyorum
- LLM’lerin rakip rolünde kitlesel olarak kullanılması pek olası değil. Çoğu oyundaki düşman yapay zekâsı, makine öğreniminin gerektirdiği düzeyde bir karmaşıklığa ihtiyaç duymaz. Hesaplama maliyetini bir kenara bıraksak bile böyle
  Düşman yapay zekâsının temel amacı dünyadaki en zor varlık olmak değil, oyuncuya üstesinden gelebileceği ilginç bir meydan okuma sunmaktır. Çoğu oyunda çok yüksek performanslı bir yapay zekâ yapmak illa ki zor değildir, ama bu ona karşı oynamayı daha eğlenceli hale getirmez
  Çoğu oyunun sonlu bir mantıksal durumu vardır; sadece insanların tüm çözümleri bulması için yeterince büyüktür. Elbette insanlar bu durumların sınırlarını zorlayıp kestirme yollar bulmakta çok iyidir
  Durum uzayı normalden çok daha büyük olan oyunlarda bile süper yapay zekâ istenmesi nadirdir. Örneğin FPS’te aimbot’a karşı oynamayı seven kimse yoktur
  Factorio, “zafer”in gerçek koşulunun neredeyse tamamen oyuncuya bağlı olması bakımından sıradan oyunlardan ayrılan bir istisnadır. DLC’siz Factorio’da, oyunun kazanma koşulu olan roketi, elde yapılamayan şeyler için gereken en temel yapılar dışında neredeyse hiç fabrika kurmadan yapmak mümkündür. Çok yavaş olur ama mümkün bir seçenektir. Bu yüzden böyle bir benchmark’ta “çalışıyor mu”dan çok verimlilik önemlidir
- Bence mümkün. Çünkü çalıştırmak için ayrı bir eğitim hesaplaması gerekmiyor. API sağlandığında, yeni bir oyuna çeşitli modelleri plug and play bağlamak çok kolay
  Modeller iki ana alanda zorlanıyor. İlki uzamsal akıl yürütme. Modeller sık sık off-by-one hataları yapıyor ve fabrikalar, programlama gibi, bu tür hatalara çok duyarlı olduğundan toparlanmakta zorlanıyor
  İkincisi uzun vadeli planlama. Taktiksel alt hedefler oluşturmadan önce stratejik olarak ne yapılması gerektiğini kavrama becerisi
  lab-play’de zorluk genellikle üretim zincirinin derinliğiyle orantılı. Bir öğeyi üretmek için önce birden fazla fabrika bölümü gerekiyorsa iş çok daha zorlaşıyor. Bu planlamayla ilgili gibi görünüyor; çünkü modeller önce büyük bir plan kurmaktansa küçük sorunları düzeltmenin ayrıntılarına gömülme eğiliminde
- “Claude plays Pokémon”a bakınca Mount Moon’da zorlandığını görüyoruz; dört yaşındaki ben de öyleydim
- Neden LLM olmak zorunda? AlphaZero bu tür işlerde iyi değil mi? LLM dışında da çok daha fazla yararlı makine öğrenimi modeli var!

Factorio öğrenme ortamı – fabrika kuran ajanlar

FLE 0.3.0’da değişenler

Hızlı başlangıç

Otomatik iron gear wheel fabrikası örneği

Elektrik kurulumu

Demir madenciliği ve ergitme

Montaj makinesi yerleştirme

Bant bağlantısı ve hata toparlama

Gözlem uzayı ve ajan harness’i

Lab-play benchmark ayarı

Değerlendirme koşulları

Model performansı ve kalan sınırlar

Hata türleri ve modellere göre farklar

Başarısızlık türleri

Modellere göre hata dağılımı

Claude Code ve MCP

Sonraki araştırma yönleri

Yakın vadeli görevler

Uzun vadeli görevler

Katılma yolu

İlgili okumalar

1 yorum

Hacker News yorumları