Lingkungan Pembelajaran Factorio – Agen yang Membangun Pabrik

 (jackhopkins.github.io)
1 poin oleh GN⁺ 2025-03-12 | 1 komentar | Bagikan ke WhatsApp
  • FLE 0.3.0, yang menggunakan game otomasi pabrik Factorio untuk menguji perencanaan jangka panjang dan penalaran spasial agen, telah dirilis, dan mencakup demo yang menghubungkan Claude Code ke Factorio
  • Versi baru ini memudahkan eksperimen riset dengan eksekusi headless, renderer observasi piksel, antarmuka kompatibel OpenAI Gym, eksekusi evaluasi via CLI, logging Weights and Biases, serta alat analisis
  • Agen contoh secara iteratif men-debug produksi listrik, penambangan bijih besi, peleburan, penempatan mesin perakitan, dan koneksi belt untuk mencapai target produksi 16 iron gear wheel per menit
  • Benchmark Lab-play mengevaluasi Pass@8 pada model-model kuat per September 2025, dengan target produksi 16 item per menit untuk item padat dan 250 per menit untuk fluida, serta batas maksimum 64 langkah
  • Model frontier sudah lebih baik dibanding v0.2.0, tetapi pengangkutan manual, buffer peti, penyalahgunaan API, dan salah menilai status game yang dinamis masih tersisa, sehingga Factorio tetap menjadi lingkungan yang menantang untuk mengungkap kemampuan perencanaan jangka panjang dan pemulihan dinamis

Perubahan di FLE 0.3.0

  • FLE 0.3.0 adalah pembaruan besar untuk lingkungan pembelajaran yang menguji perencanaan jangka panjang, penalaran, dan pemodelan dunia melalui tugas membangun pabrik Factorio
  • Dalam makalah FLE sebelumnya, model frontier menunjukkan kesulitan dalam beradaptasi dengan lingkungan yang berubah, menetapkan tujuan jangka panjang, dan pemulihan dinamis; 0.2.0 memperkenalkan multi-agensi, agen backtracking, dan vision
  • Perubahan utama di 0.3.0:
    • Menghubungkan Claude Code ke Factorio melalui FLE dan mendemonstrasikannya di Twitch
    • Menghapus dependensi pada klien game Factorio untuk mendukung scaling headless yang memungkinkan eksperimen skala besar
    • Renderer game headless baru menyediakan observasi piksel realistis untuk riset agen multimodal
    • Lingkungan evaluasi disesuaikan dengan antarmuka OpenAI Gym, sehingga lebih mudah diintegrasikan dengan codebase riset yang ada
    • FLE CLI mendukung menjalankan eksperimen dengan perintah shell satu baris, serta menyediakan kode evaluasi, logging Weights and Biases, pelanjutan sweep, dan alat analisis sebagai open source

Mulai cepat

# 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 diinstal dengan uv; setelah memulai klaster server Factorio dengan fle cluster start, evaluasi dijalankan menggunakan API key di .env dan file konfigurasi

Contoh pabrik iron gear wheel otomatis

  • Agen contoh dimulai di dunia lab-play dengan inventori item dan tujuan membangun pabrik iron gear wheel
  • Agen memanggil FLE API dengan Python untuk berinteraksi dengan lingkungan game, serta mengamati output standar dan pesan error dari setiap eksekusi

  • Konfigurasi listrik

    • Menemukan lokasi air dengan nearest(Resource.Water) lalu menempatkan offshore pump
    • Setelah menempatkan boiler dan steam engine, agen menghubungkan pipa dengan connect_entities dan memasukkan coal ke boiler
    • Setelah menunggu 5 detik, agen memeriksa nilai energy pada steam engine untuk memverifikasi pembangkitan listrik

  • Penambangan dan peleburan besi

    • Setelah menemukan lokasi iron ore, agen menempatkan 2 electric mining drill dan electric furnace
    • Agen menghitung bahwa produksi 16 iron gear wheel/menit membutuhkan 32 iron plate/menit, dan karena electric mining drill menambang 30 ore per 60 detik, dibutuhkan 2 drill
    • Drill dan electric furnace terhubung ke jaringan listrik steam engine melalui medium electric pole

  • Penempatan mesin perakitan

    • Menempatkan AssemblingMachine2 setidaknya 20 tile dari area penambangan
    • Mengatur resep mesin perakitan ke Prototype.IronGearWheel, menempatkan inserter input dan output, lalu menghubungkannya ke jaringan listrik
    • Assembling machine 2 dapat membuat 90 iron gear wheel per 60 detik, sehingga 1 unit sudah cukup untuk target throughput

  • Koneksi belt dan pemulihan error

    • Agen mencoba menghubungkan furnace output inserter dan assembler input inserter langsung dengan belt, tetapi menemukan bahwa storage chest menghalangi jalur
    • Agen mengambil iron plate dari 2 wooden chest yang menghalangi dan menghapus petinya, tetapi error kembali terjadi karena input buffer chest di sisi assembler masih tersisa
    • Pada akhirnya, agen juga menghapus assembler input chest dan menghubungkan jaringan logistik berbasis transport belt, sehingga sistem iron gear wheel otomatis mencapai target throughput

Ruang observasi dan harness agen

  • Di setiap langkah, agen menerima objek Observation terstruktur yang berisi status game
  • Field utama:
    • raw_text: output standar dan pesan error dari eksekusi action program sebelumnya, beserta nomor baris kode sumber
    • entities: semua entitas di dunia game beserta lokasi, tipe, arah, inventori, peringatan, dan atribut lainnya
    • inventory: tipe dan jumlah item dalam inventori pribadi agen
    • research: teknologi yang sudah diteliti, progres riset saat ini, teknologi yang tersedia beserta prasyarat dan biayanya
    • game_info: jumlah tick, waktu berlalu, kecepatan game
    • flows: rasio input/output, item yang dibuat, resource yang dikumpulkan, dan tabel harga opsional untuk evaluasi ekonomi
    • messages: pesan antarap agen untuk koordinasi multi-agen
    • task_info: deskripsi tujuan, instruksi, task identifier, panjang trajectory maksimum
    • task_verification: metadata keberhasilan/kegagalan dan progres tujuan
    • serialized_functions: helper function dan abstraksi yang didefinisikan sebelumnya
    • map_image: layout pabrik PNG berenkode base64 untuk agen visual
  • Ruang observasi ini mendukung kesadaran spasial, pelacakan metrik produksi, debugging error, dan perencanaan otomasi multi-tahap
  • Harness agen untuk evaluasi menggabungkan field-field ini menjadi string Markdown terformat

Pengaturan benchmark Lab-play

  • Lab-play adalah lingkungan terbatas yang memberikan resource tetap dan satu entitas tujuan untuk memaksimalkan throughput produksi
  • Open-play jauh lebih kompleks karena dimulai di peta yang dibuat secara prosedural tanpa inventori awal, dengan resource lebih jarang dan tujuan yang lebih rumit
  • Per September 2025, metodologi dari makalah FLE asli direplikasi untuk model-model kuat dengan menyesuaikannya ke pengaturan lab-play
  • Harness agen yang distandardisasi terus menambahkan interaksi lingkungan ke satu riwayat percakapan; ketika anggaran token hampir habis, riwayat lama diringkas agar penalaran dapat berlanjut
  • Logika backtracking atau reflection yang digunakan di FLE 0.2.0 tidak dievaluasi

  • Kondisi evaluasi

    • Tujuan: mencapai throughput produksi 16 per menit untuk item padat dan 250 per menit untuk fluida
    • Prompt: dokumentasi FLE API, resep Factorio, panduan pola umum
    • Inventori: sekumpulan item berguna untuk membuat pabrik fungsional
    • Langkah maksimum: 64 langkah, berhenti lebih awal saat selesai
    • Penalaran: untuk model yang mendukung reasoning, diterapkan pengaturan default {"enabled": true}

Performa model dan keterbatasan yang tersisa

  • Model open source telah mengejar performa terbaik terkini yang diamati pada v0.2.0 Mei 2025, dengan contoh keberhasilan pada otomasi electronic circuits, steel plate, sulfur, dan plastic
  • Model frontier terbaru meningkat besar dibanding FLE v0.2.0, dan untuk pertama kalinya berhasil pada separuh task yang lebih sulit yang dapat memanfaatkan lebih dari 12 dependency ingredient
  • Di FLE lab-play, peringkat dan kesenjangan performa model canggih kurang lebih mengikuti urutan Claude > GPT > Gemini > Grok, dan paling mirip dengan GDPVal dari OpenAI
  • Hasil ini kontras dengan benchmark tipe ujian statis seperti Humanity's Last Exam, AIME 25, GPQA, dan MMMU, di mana model yang lemah di FLE terkadang menunjukkan performa lebih tinggi
  • Bahkan agen yang berhasil sering mengandalkan strategi semi-manual pada task kompleks, bukan otomasi yang robust
    • Membawa resource secara langsung
    • Menggunakan storage chest sebagai buffer resource
    • Menghindari pembangunan rantai logistik yang sepenuhnya otomatis
  • Buffer perantara dapat memenuhi pemeriksaan throughput untuk sementara, sehingga menyulitkan pengukuran
  • Evaluasi mengurangi masalah ini dengan memeriksa apakah kuota terpenuhi setelah holdout period ketika agen membiarkan pabrik berjalan apa adanya selama 60 detik
  • Dengan target throughput yang lebih tinggi, lolos lewat logistik manual menjadi lebih sulit, sehingga dapat menuntut otomasi yang tepat

Jenis error dan perbedaan antar model

  • Model frontier masih kesulitan memulihkan diri ketika error menumpuk
  • Perbandingan rata-rata tingkat error: {b:23,25,27,41}
  • Rata-rata tingkat error:
    • Claude Opus 4.1: 22.99%
    • GPT-5: 25.05%
    • Gemini 2.5 Pro: 27.29%
    • Grok 4: 40.89%
  • Grok 4 sering terjebak dalam loop debug regresif, sementara GPT-5 menunjukkan pola pemulihan yang lebih elegan
  • Sebagian besar model mengalami kenaikan tingkat error di bagian tengah trajectory, saat kompleksitas pabrik meningkat

  • Jenis kegagalan

    • Error sintaks: kode Python tidak valid, kesalahan tata bahasa, error yang mencegah eksekusi itu sendiri
    • Error semantik: penyalahgunaan perintah FLE atau argumen tool, kegagalan memahami dokumentasi, TypeError, AttributeError, NameError, dan sejenisnya
    • Error praktis: penalaran yang salah tentang status game saat ini, misalnya mencoba memasukkan item yang tidak ada di inventori
    • Error perencanaan dan kontrol: meski mengetahui primitive, agen gagal merangkai tindakan secara konsisten sehingga menghasilkan trajectory yang tidak efisien atau tidak lengkap
    • Kategori ini sulit dikuantifikasi secara andal dengan analisis trajectory otomatis, karena perlu melihat konsistensi strategi tingkat tinggi, bukan jenis error individual

  • Distribusi error per model

    • Claude Opus 4.1 tidak memiliki error sintaks, dan 97,7% error-nya cenderung merupakan error praktis, menunjukkan bahwa generasi kodenya kuat tetapi kesulitan mempertahankan mental model yang akurat atas status game
    • Gemini 2.5 Pro, Grok 4, dan GPT-5 menunjukkan error pemahaman API pada kisaran 12–17%, menandakan kesulitan menggunakan dokumentasi FLE API dengan tepat
    • GPT-5 dan Grok 4 masing-masing menunjukkan 21% dan 17% error sintaks, sehingga kegagalan menghasilkan Python yang valid cukup sering muncul meski keduanya adalah model benchmark coding papan atas terbaru
    • Hanya Gemini 2.5 Pro yang tampak mendefinisikan dan menggunakan helper function serta abstraksi saat ini

Claude Code dan MCP

  • Pada v0.2.0, MCP server dirilis agar agen eksternal dapat berinteraksi dengan FLE
  • Pada v0.3.0, ini diperluas dengan menyertakan adapter Claude Code
  • Stream Claude Code yang memainkan Factorio dapat dilihat di Twitch

Arah riset berikutnya

  • Model frontier saat ini belum terlalu mahir memainkan Factorio menurut standar manusia, dan masih kesulitan dalam representasi serta pemodelan lingkungan dinamis, serta pengembangan formal abstraction untuk dipakai sebagai tool masa depan
  • Meski begitu, selama 2025 kemampuan model frontier di lab-play terus membaik
  • Factorio dapat terus digunakan sebagai lingkungan yang mengungkap kemampuan model umum seperti perencanaan jangka panjang, adaptasi domain, pemodelan dunia, dan penalaran spasial
  • FLE v0.3.0 menetapkan lab-play sebagai benchmark formal pertama, tetapi ini masih merupakan titik awal dari rencana riset

  • Tugas jangka dekat

    • Baseline manusia: mengukur performa manusia secara sistematis berdasarkan tingkat kesulitan task untuk mengalibrasi kemampuan agen
    • Menangani reward hacking: menangani masalah ketika agen memanfaatkan manual crafting untuk item kompleks alih-alih otomasi yang tepat
    • METR-style task scaling: mengembangkan scaling chart yang mengaitkan tingkat kesulitan task dengan kemampuan yang dibutuhkan secara sistematis

  • Tugas jangka panjang

    • Ekspansi Open-play dan megabase: memperluas tingkat kesulitan dari lab-play terbatas ke peta yang dibuat prosedural, tujuan multi-tahap, hingga megabase dengan ribuan mesin terhubung
    • Performa real-time di bawah batasan latensi: saat ini waktu berpikir antartindakan tidak dibatasi, tetapi benchmark yang membuat Factorio terus berjalan akan mengevaluasi trade-off antara latensi respons dan kualitas solusi
    • Koordinasi multi-agen: menangani kerja sama, kompetisi, emergent market dynamics, pembagian kerja, negosiasi alokasi resource, dan pembentukan keunggulan komparatif
    • Lingkungan out-of-distribution berbasis mod: mengevaluasi apakah agen dapat mempelajari ulang causal structure pada tech tree dan mekanika game baru
    • Native computer-use interface: mengevaluasi agen melalui antarmuka keyboard, mouse, dan vision seperti manusia, bukan Python API
    • Dinamika adversarial dan robustness: memperkenalkan hostile aliens dan tantangan lingkungan non-deterministik untuk mengevaluasi adaptive control dan resilience

Cara berpartisipasi

  • Baik kode maupun misi FLE bersifat open source
  • Partisipan yang dibutuhkan:
    • Peneliti yang mengeksplorasi arsitektur baru untuk perencanaan jangka panjang dan penalaran spasial
    • Engineer yang mengoptimalkan infrastruktur evaluasi dan pelatihan skala besar
    • Modder yang merancang challenge domain baru
  • Jika tertarik bergabung dengan tim, Anda dapat menemukannya di Discord

Bacaan terkait

1 komentar

 
GN⁺ 2025-03-12
Komentar Hacker News

  • Sekarang saya benar-benar terpancing, dan jadi ingin segera melamar ke laboratorium Factorio Anthropic
    Dari makalah atau komentarnya saja saya tidak tahu apakah mereka mengirim kembali data multimodal, tetapi karena beberapa model bukan multimodal, mungkin tidak. Namun sebagian bisa, dan Qwen 2.5 VLM yang baru-baru ini keluar tampak cukup kuat untuk ukurannya
    Mereka cukup menekankan kurangnya kemampuan spasial, dan juga membahas kesulitan dalam perencanaan maupun perencanaan spasial, jadi saya penasaran apakah mereka juga mengirim gambar seperti screenshot. Kalau tidak, saya juga penasaran apa pendapat mereka tentang hal itu
    Selain itu, mengaktifkan library Python lewat MCP agar semua LLM yang bisa menggunakan tool dapat memainkan Factorio terlihat seperti hal yang secara alami wajib dilakukan

    • Saat ini ini adalah lingkungan khusus teks, tetapi ada rencana untuk mendukung input visual ke depannya
      Dalam beberapa pengujian, menyertakan screenshot status game tidak meningkatkan performa model siap pakai. Semakin kompleks status game dan semakin banyak entitas di screenshot, model justru makin bingung, berhalusinasi soal arah atau entitas, atau tidak mampu memperbaiki kesalahan yang jelas terlihat seperti transport belt yang hilang atau inserter yang salah rotasi
      Kami menduga ini karena VLM saat ini belum bagus dalam penalaran spasial pada gambar yang penuh detail, dan fine-tuning mungkin bisa sangat memperbaikinya. MCP juga sedang naik daun belakangan ini, jadi akan kami lihat juga
    • Kalau deskripsi teks tentang status pabrik lebih mudah ditafsirkan dan tidak terlalu membingungkan, saya tidak mengerti mengapa screenshot diperlukan
      Karena game berlangsung di atas grid, seharusnya cukup mudah mengubah status game menjadi representasi ASCII

  • Beberapa waktu lalu ada tulisan tim di HN yang melatih agen untuk menyelesaikan Pokémon Red dengan reinforcement learning. Mereka mengatakan harus menyesuaikan fungsi biaya agar memberi reward kecil untuk eksplorasi dan reward besar untuk tugas wajib seperti mengalahkan gym
    Saya penasaran apakah pendekatan yang sama bisa dipakai di Factorio. Kalau memakai analogi Pokémon Red, tugas wajib utama di Factorio adalah membangun otomatisasi untuk item baru dan science pack baru
    Memberi reward kecil untuk jumlah produksi per detik tiap item, reward sedang untuk otomatisasi item baru, dan reward besar untuk otomatisasi science pack baru bisa menjadi fungsi reward yang bagus
    Menyuruh agen Factorio begitu saja “buat pabrik besar” sama seperti menyuruh agen Pokémon Red “selesaikan game”, dan harus dipecah menjadi tahap-tahap yang lebih kecil dengan fungsi reward yang disetel sangat hati-hati
    Memikirkan hal ini membuat saya ingin ikut terjun ke proyek ini

    • Sebagai tambahan dari orang yang sudah bermain Factorio 2–3 ribu jam, tujuan membuat “pabrik sebesar mungkin” terlalu ambigu dan bukan metrik yang tepat
      Saat pemain Factorio membuat megabase besar, targetnya bukan ukuran itu sendiri, melainkan science per minute (SPM). Metrik yang diberikan ke agen seharusnya SPM, bukan basis yang “terbesar”
    • Di FLE, kita bisa mengakses milestone yang menunjukkan kapan entitas baru pertama kali dibuat, tetapi pendekatan memberi reward berlapis berdasarkan tingkat otomatisasi juga akan sangat menarik. Akan bagus kalau bisa dikerjakan bersama
    • Ini bagian yang menarik. Di lab-play, Claude bisa melakukan tugas wajib dan otomatisasi sederhana seperti pabrik iron gear wheel, tetapi dalam episode game “membuat pabrik terbesar” ia bahkan tidak mencobanya
      Model-model ini bisa menjalankan tugas wajib semacam itu, tetapi ketika diberi tujuan umum seperti “selesaikan game”, mereka tidak punya tingkat perencanaan jangka panjang yang cukup untuk mencobanya. Mereka sering hanya membuat struktur kecil yang tidak terkoordinasi, alih-alih mencoba memperluas pabrik yang sudah ada
      Salah satu tujuan kami memang melihat bagaimana model bertindak ketika diberi tujuan yang ambigu dan umum
    • Pendekatan yang sama juga bisa dipakai dalam hidup
    • Saya penasaran apakah Anda membaca halamannya. Mereka sebenarnya memberi reward untuk setiap item yang diproduksi, dan memberi reward lebih tinggi untuk item yang lebih kompleks

  • Bagian bahwa mereka mengevaluasi enam model bahasa frontier dalam dua setting memang menarik, tetapi ada banyak benchmark dinamis yang jauh lebih sederhana yang juga bisa menjenuhkan kemampuan perencanaan model non-reasoning
    Cukup dengan memberi daftar koneksi penerbangan antar-kota dan menanyakan perjalanan di antaranya, semua model ini akan bingung jika jalur terpendek antara dua node cukup panjang
    Jalur terpendek antarkota terpanjang yang bisa ditemukan secara stabil 8 dari 10 kali untuk tiap panjang adalah sebagai berikut
    | Model | Panjang Jalur |
    |------------------+-------------|
    | Claude Sonnet3.5 | 10 |
    | GPT-4o | 7 |
    | GPT-4o-mini | 4 |
    | Deepseek-v3 | 6 |
    | Gemini-2-Flash | Tidak diuji |
    | Llama3.3-70B-Ins | 4 |

    • Benar. Ada benchmark yang lebih sederhana yang dapat menjenuhkan kemampuan perencanaan model-model seperti ini
      Namun kami ingin membuat lingkungan evaluasi dengan spektrum yang lebih luas, yang menguji beberapa kemampuan sekaligus dan tetap relevan ke depannya

  • Masuk akal bahwa semua model menunjukkan keterbatasan perencanaan spasial saat membangun pabrik dengan beberapa area. Maksudnya, kegagalan yang umum terjadi adalah menempatkan entitas terlalu berdekatan, tidak menyediakan ruang koneksi, atau salah menaruh inserter
    Saya mengerti mengapa LLM lemah dalam penalaran spasial. Karena tidak banyak data latih yang cocok untuk itu. Saya penasaran kemampuan penalaran tambahan apa yang akan muncul jika penalaran spasial terpecahkan

    • Saya kurang paham maksudnya data spasial tidak banyak
      Bukankah dengan simulator paling sederhana saja kita bisa membuatnya hampir tak terbatas?
      Misalnya, cukup mengimplementasikan tic-tac-toe di grid tak terbatas dalam sekitar 10 baris kode, kita sudah bisa menghasilkan set pelatihan tanpa batas

  • Saya ingin melihat desain balancer sebagai kategori lain dalam tugas “Lab Play”
    Balancer kecil pun bisa cukup kompleks (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9), dan akan menarik melihat kemampuan model untuk merancangnya dan memecahkan masalahnya

  • Ide yang keren
    Tampaknya ada banyak eksperimen menarik yang bisa dicoba di sini. Menambahkan unsur terkait waktu ke skenario lab-play sepertinya ide bagus. Sebagian besar pengguna Factorio yang bermain dengan biter aktif akan memperlakukannya sebagai kombinasi batasan waktu-ruang, dan memberi agen batas waktu memungkinkan semacam perbandingan proksi dengan situasi permainan nyata
    Saya suka bahwa desain framework ini menguji sesuatu yang berbeda dari kemampuan micro-management seperti yang terlihat dalam eksperimen DOTA 2 atau StarCraft 2. Khususnya di StarCraft 2, jika ada APM tak terbatas, muncul perilaku seperti memicro pekerja secara ekstrem untuk menambang sedikit lebih banyak mineral
    Perilaku seperti ini memang hasil pembelajaran yang menarik dalam konteks sempit, tetapi dalam praktiknya beban kontrolnya besar dan bahkan pemain profesional pun sangat mungkin melakukan kesalahan. Selain itu, tampaknya juga tidak memberi wawasan tambahan tentang kinerja perencanaan jangka panjang, eksekusi, dan analisis agen
    Dari sisi itu, FLE jauh lebih menarik sebagai framework evaluasi penalaran pada level yang lebih tinggi. Saya juga penasaran apakah ada rencana benchmark optimasi layout, misalnya mengoptimalkan kinerja ketika sebuah sel pabrik tertentu memiliki X input dan Y output

    • Kami sedang membicarakan pembuatan tugas yang lebih mirip tower defense, misalnya biter dilepas setiap X tahap atau X detik
      Tujuannya adalah menguji kemampuan agen untuk membuat kompleks industri militer. Masalah lucu saat mengembangkan ide ini adalah model-model frontier enggan membuat entitas bernama seperti ‘GunTurret’. Sepertinya mereka menganggapnya bertentangan dengan konstitusi. Mungkin nama turret harus diganti menjadi sesuatu seperti ‘SuperSoaker’
      Untuk benchmark optimasi layout, kami sebenarnya membahasnya kemarin. Menurut saya diperlukan dua jenis tugas layout. 1) Memperbaiki pabrik yang rusak secara halus, 2) meningkatkan throughput pabrik ini. Implementasinya seharusnya relatif mudah, jadi layak untuk dicoba dilihat

  • Saya kurang paham. Apakah model-model ini di-post-train agar bisa bermain Factorio?
    A) Jika ya, bagaimana itu mungkin untuk model tanpa bobot terbuka seperti Claude? B) Jika tidak, bagaimana agen tahu apa yang dilakukan API? Andaikan ia menebak dari makna bahasa Inggris perintah API, misalnya place_entity_next_to berarti meletakkan entitas di samping sesuatu, bagaimana ia tahu resep crafting-nya? Jika ia mencoba lalu belajar, itu kembali lagi ke A
    Setelah membaca PDF, sepertinya tidak ada post-training, tetapi kalau begitu saya tidak tahu bagaimana pertanyaan-pertanyaan di B dijelaskan
    Jika benar-benar tidak ada post-training dan eksplorasi resep diharapkan terjadi di context window, menurut saya itu terlalu singkat untuk perbaikan ala reinforcement learning
    Ringkasnya, saya tidak tahu apakah model-model ini bisa diuji melalui post-training, dan jika dilakukan tanpa post-training, semuanya berhasil dengan tingkat yang sulit dipercaya
    Jika para penulis melihat ini, saya penasaran rata-rata berapa banyak pasangan kueri API dan respons API yang masuk ke context window. Selanjutnya, saya juga penasaran apakah hasilnya membaik jika nama panggilan API disingkat agar lebih banyak pasangan respons dapat dimasukkan dalam satu context window

    • Terkait tool, para agen memiliki akses ke signature fungsi, yaitu docstring tool, tipe input-output, dan juga ada “manual” kecil untuk tiap tool
      Manual ini menjelaskan apa yang dilakukan tool, bagaimana dampaknya pada status game, serta beberapa contoh penggunaan seperti cara meletakkan inserter di sebelah peti yang sudah ada dengan place_entity_next_to
      Seperti yang dikatakan Jack, sama sekali tidak ada post-training, tetapi semua agen memiliki deskripsi API lengkap di dalam konteks, termasuk tool, entitas, dan riset. Jadi hasil ini sampai tingkat tertentu menunjukkan seberapa baik agen modern dapat menggunakan API yang sepenuhnya di luar distribusi jika dokumentasinya memadai
    • Model-model ini tidak di-post-train, semuanya adalah model siap pakai apa adanya
      Konteks dapat memuat hingga sekitar 128 pasangan, tetapi karena kinerjanya sama dengan 32 pasangan, akhirnya kami memilih 32 pasangan karena biaya dan latensi
      Mengenkode input-output dengan lebih pendek justru menurunkan kinerja. Sepertinya nama yang deskriptif membantu karena memberi model pralatih intuisi tentang apa yang dilakukan sesuatu
    • Jika membaca catatan kaki di bagian perkenalan penulis, tampaknya salah satunya bekerja di Anthropic. Kemungkinan mereka punya akses internal

  • Menarik bahwa hanya ada beberapa skenario yang kompleks. Saya selalu berpikir agar agen game ML benar-benar mempelajari mekanisme game, dibutuhkan ratusan puzzle sangat kecil, masing-masing dengan ratusan variasi
    Contohnya seperti ini. Pabrik tidak punya listrik, jadi pasang tiang listrik yang hilang; pabrik kekurangan item, jadi pasang belt yang hilang; buat dan tempatkan 200 assembling machine; assembling machine berhenti karena suatu alasan, jadi perbaiki; produksi pabrik terlalu rendah, jadi gandakan; bergerak secepat mungkin ke titik lain di dalam pabrik; perbaiki kekurangan daya; dan bagi semua tugas ini menjadi kasus dengan robot dan tanpa robot
    Beberapa ribu skenario contoh seperti ini seharusnya relatif mudah dibuat secara programatis. Lalu bisa digunakan seperti bank soal tes IQ, dengan mengambil sekitar 12 soal dari bank soal dan menilai kinerja masing-masing berdasarkan waktu dan material yang digunakan
    Menurut saya agen ML akan dievaluasi dengan mengambil sampel dari bank skenario besar yang kompleksitasnya meningkat secara halus, dan setelah mendapat skor cukup tinggi pada kompleksitas rendah, ia akan belajar lebih cepat ketika diberi skenario yang lebih kompleks

    • Membuat skenario dalam teks seperti yang Anda usulkan memang mudah, tetapi membuat status game pabrik yang benar sebagai titik awal jauh lebih sulit
      Sejauh yang saya tahu, pada akhirnya itu tetap bermuara pada pekerjaan yang sama: merancang keadaan awal dan tugas yang harus diselesaikan secara manual
    • Untuk pelatihan tambahan, kami memang memikirkan pendekatan kurikulum seperti ini
      Namun pekerjaan saat ini berfokus pada evaluasi, jadi kami tidak melakukannya. “Tingkat kesulitan” berbagai tugas cukup subjektif, sehingga perlu membuat keputusan arbitrer yang bisa memengaruhi evaluasi. Misalnya, tugas mana yang harus datang setelah skenario tertentu, atau apakah semua tingkat kesulitan sudah tercakup dengan cukup baik

  • Saya penasaran apakah ada benchmark permainan manusia untuk cara antarmuka seperti ini. Bukan berarti itu wajib atau relevan, saya hanya penasaran seperti apa rasanya Factorio secara pemrograman
    Melakukan penalaran spasial di sekitar prompt teks tampaknya juga cukup sulit bagi pemain manusia

    • Benchmark manusia untuk Factorio adalah para speedrunner yang berlari mengejar peluncuran roket pertama
      Rekor saat ini sedikit di atas 4 jam untuk permainan solo, dan 90 menit untuk tim. Ini saja menunjukkan bahwa LLM yang mampu multitasking punya ruang untuk mengungguli manusia

  • Saya juga penasaran apakah dalam beberapa tahun ke depan semua lawan di dalam game bisa menjadi LLM yang memiliki akses ke API kontrol game seperti ini
    Saya juga penasaran apakah ada jenis tugas tertentu yang sangat sulit bagi model, atau apakah tingkat kesulitannya terutama meningkat seiring jumlah item yang harus ditempatkan

    • Kemungkinan LLM digunakan secara massal sebagai lawan sangat rendah. AI musuh di kebanyakan game tidak membutuhkan kompleksitas setingkat yang diperlukan machine learning. Itu pun bahkan jika biaya komputasinya dikesampingkan dulu
      Tujuan utama AI musuh bukan menjadi entitas tersulit di dunia, melainkan memberikan tantangan menarik yang layak diatasi pemain. Di kebanyakan game, membuat AI superkuat belum tentu sulit, tetapi bukan berarti akan menyenangkan untuk dilawan
      Sebagian besar game memiliki state logika yang terbatas, hanya saja cukup besar sehingga manusia tidak bisa menemukan semua solusinya. Tentu saja manusia sangat piawai mendorong batas-batas state seperti ini untuk menemukan jalan pintas
      Bahkan pada game dengan jumlah state jauh lebih besar dari biasanya, jarang ada yang menginginkan super AI. Misalnya, tidak ada orang yang suka melawan aimbot di FPS
      Factorio adalah pengecualian dibanding game biasa karena syarat sebenarnya untuk “menang” hampir sepenuhnya bergantung pada pemain. Di Factorio tanpa DLC, roket yang menjadi syarat kemenangan game bisa dibuat nyaris tanpa membangun pabrik selain struktur paling dasar untuk hal-hal yang tidak bisa dibuat dengan tangan. Itu akan sangat lambat, tetapi tetap merupakan opsi yang memungkinkan. Jadi dalam benchmark seperti ini, efisiensi lebih penting daripada sekadar “apakah berfungsi”
    • Menurut saya mungkin saja. Karena tidak perlu komputasi pelatihan terpisah untuk menjalankannya. Jika API disediakan, sangat mudah menghubungkan berbagai model ke game baru secara plug and play
      Model kesulitan terutama di dua area. Pertama adalah penalaran spasial. Model sering membuat kesalahan off-by-one, dan pabrik sangat sensitif terhadap kesalahan seperti ini, mirip pemrograman, sehingga sulit dipulihkan
      Kedua adalah perencanaan jangka panjang. Ini adalah kemampuan memahami apa yang harus dilakukan secara strategis sebelum membuat subtujuan taktis
      Di lab-play, tingkat kesulitan biasanya sebanding dengan kedalaman rantai produksi. Jika untuk membuat suatu item diperlukan beberapa bagian pabrik terlebih dahulu, itu menjadi jauh lebih sulit. Ini tampaknya berkaitan dengan perencanaan, karena model cenderung tenggelam dalam detail memperbaiki masalah kecil alih-alih terlebih dahulu menyusun rencana besar
    • Kalau melihat “Claude plays Pokémon”, ia kesulitan di Mount Moon, dan saya juga begitu saat berumur empat tahun
    • Mengapa harus LLM? Bukankah hal seperti ini justru cocok untuk AlphaZero? Ada jauh lebih banyak model machine learning yang berguna selain LLM!