- มีการเปิดตัว FLE 0.3.0 ที่ใช้เกมอัตโนมัติโรงงาน Factorio เพื่อตรวจสอบ การวางแผนระยะยาวและการให้เหตุผลเชิงพื้นที่ ของเอเจนต์ พร้อมเดโมที่เชื่อม Claude Code เข้ากับ Factorio
- เวอร์ชันใหม่นี้ช่วยให้การทดลองวิจัยง่ายขึ้นด้วย การรันแบบ headless, ตัวเรนเดอร์การสังเกตแบบพิกเซล, อินเทอร์เฟซที่เข้ากันได้กับ OpenAI Gym, การรันการประเมินผ่าน CLI, และเครื่องมือบันทึกกับวิเคราะห์ของ Weights and Biases
- เอเจนต์ตัวอย่างทำการดีบักซ้ำ ๆ สำหรับการผลิตไฟฟ้า, การขุดแร่เหล็ก, การถลุง, การวางเครื่องประกอบ, และการเชื่อมสายพาน จนบรรลุเป้าหมายการผลิต iron gear wheel 16 ชิ้นต่อนาที
- เบนช์มาร์ก Lab-play ประเมิน Pass@8 กับโมเดลชั้นนำ ณ เดือนกันยายน 2025 โดยตั้งเป้าหมายการผลิตของแข็งที่ 16 ชิ้นต่อนาที และของเหลวที่ 250 หน่วยต่อนาที พร้อมจำกัดสูงสุด 64 ขั้นตอน
- แม้โมเดลระดับแนวหน้าจะดีขึ้นจาก v0.2.0 แต่ปัญหาอย่างการขนย้ายด้วยมือ, บัฟเฟอร์กล่อง, การใช้ API ผิด, และการประเมินสถานะเกมแบบไดนามิกผิดพลาดยังคงอยู่ ทำให้ Factorio ยังเป็นสภาพแวดล้อมที่ท้าทายซึ่งเผยให้เห็นความสามารถด้านการวางแผนระยะยาวและการฟื้นตัวแบบไดนามิก
สิ่งที่เปลี่ยนไปใน FLE 0.3.0
- FLE 0.3.0 คืออัปเดตใหญ่ของสภาพแวดล้อมการเรียนรู้ที่ใช้โจทย์สร้างโรงงานใน Factorio เพื่อทดสอบการวางแผนระยะยาว การให้เหตุผล และการสร้างแบบจำลองโลก
- ใน FLE paper ก่อนหน้านี้ โมเดลระดับแนวหน้าแสดงให้เห็นถึงความยากลำบากในการปรับตัวต่อสภาพแวดล้อมที่เปลี่ยนแปลง การตั้งเป้าหมายระยะยาว และการฟื้นตัวแบบไดนามิก ส่วน 0.2.0 ได้เพิ่ม multi-agency, backtracking agent และวิชันเข้ามา
- การเปลี่ยนแปลงหลักของ 0.3.0:
- เชื่อม Claude Code เข้ากับ Factorio ผ่าน FLE และสาธิตบน Twitch
- รองรับ การสเกลแบบ headless สำหรับการทดลองขนาดใหญ่ โดยตัดการพึ่งพาไคลเอนต์เกม Factorio ออก
- ตัวเรนเดอร์เกมแบบ headless ใหม่มอบการสังเกตแบบพิกเซลที่สมจริงสำหรับงานวิจัยเอเจนต์มัลติโหมด
- สภาพแวดล้อมการประเมินปรับให้เข้ากับอินเทอร์เฟซ OpenAI Gym ทำให้นำไปรวมกับโค้ดเบสงานวิจัยที่มีอยู่ได้ง่ายขึ้น
- รองรับการรันการทดลองด้วยคำสั่งเชลล์บรรทัดเดียวผ่าน FLE CLI และเปิดซอร์สทั้งโค้ดประเมิน การบันทึก Weights and Biases การกลับมารัน sweep ต่อ และเครื่องมือวิเคราะห์
เริ่มต้นอย่างรวดเร็ว
# 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, เริ่มคลัสเตอร์เซิร์ฟเวอร์ Factorio ด้วย fle cluster start แล้วรันการประเมินด้วย API key ใน .env และไฟล์ตั้งค่า
ตัวอย่างโรงงานผลิต iron gear wheel อัตโนมัติ
- เอเจนต์ตัวอย่างเริ่มต้นในโลก lab-play โดยได้รับอินเวนทอรีไอเท็มและเป้าหมายให้สร้างโรงงาน iron gear wheel
- มันโต้ตอบกับสภาพแวดล้อมเกมโดยเรียก FLE API ผ่าน Python และสังเกต standard output กับข้อความ error ของแต่ละการรัน
-
การจัดระบบไฟฟ้า
- ใช้
nearest(Resource.Water) เพื่อหาตำแหน่งน้ำและวาง offshore pump
- หลังจากวาง boiler และ steam engine แล้ว จะเชื่อมท่อด้วย
connect_entities และใส่ coal เข้าไปใน boiler
- รอ 5 วินาทีแล้วตรวจสอบค่า
energy ของ steam engine เพื่อยืนยันว่า มีการผลิตไฟฟ้า
-
การขุดและถลุงเหล็ก
- หลังหาตำแหน่ง iron ore แล้ว จะวาง electric mining drill 2 ตัวและ electric furnace
- คำนวณว่า iron gear wheel 16 ชิ้น/นาที ต้องใช้ iron plate 32 ชิ้น/นาที และ electric mining drill ขุด ore ได้ 30 ชิ้นต่อ 60 วินาที จึงต้องใช้ drill 2 ตัว
- ตัว drill และเตาไฟฟ้าจะเชื่อมเข้ากับโครงข่ายไฟของ steam engine ผ่าน medium electric pole
-
การวางเครื่องประกอบ
- วาง AssemblingMachine2 ให้ห่างจากพื้นที่ขุดอย่างน้อย 20 ไทล์
- ตั้งสูตรของเครื่องประกอบเป็น
Prototype.IronGearWheel, วาง inserter สำหรับรับเข้าและส่งออก แล้วเชื่อมเข้ากับโครงข่ายไฟฟ้า
- Assembling machine 2 สามารถผลิต iron gear wheel ได้ 90 ชิ้นต่อ 60 วินาที ดังนั้นสำหรับอัตราการผลิตเป้าหมายใช้เพียง 1 เครื่องก็พอ
-
การเชื่อมสายพานและการกู้คืนจากข้อผิดพลาด
- พยายามเชื่อมสายพานโดยตรงจาก furnace output inserter ไปยัง assembler input inserter แต่พบว่า storage chest ขวางเส้นทางอยู่
- นำ iron plate ออกจาก wooden chest 2 ใบที่ขวางอยู่และลบกล่องออก แต่ยังเหลือ input buffer chest ฝั่ง assembler ทำให้เกิดข้อผิดพลาดอีกครั้ง
- ในท้ายที่สุดจึงลบ assembler input chest ออกด้วย แล้วเชื่อมระบบโลจิสติกส์ที่ใช้ transport belt จน ระบบผลิต iron gear wheel อัตโนมัติ ไปถึงอัตราการผลิตเป้าหมาย
พื้นที่การสังเกตและ agent harness
- ในแต่ละขั้นตอน เอเจนต์จะได้รับอ็อบเจ็กต์ Observation แบบมีโครงสร้างที่บรรจุสถานะของเกม
- ฟิลด์หลัก:
raw_text: standard output และข้อความ error จากการรัน action program ครั้งก่อน พร้อมเลขบรรทัดของซอร์สโค้ดentities: เอนทิตีทั้งหมดในโลกเกม พร้อมตำแหน่ง ประเภท ทิศทาง อินเวนทอรี คำเตือน และคุณสมบัติอื่น ๆinventory: ประเภทและจำนวนไอเท็มในอินเวนทอรีส่วนตัวของเอเจนต์research: เทคโนโลยีที่วิจัยแล้ว ความคืบหน้าการวิจัยปัจจุบัน และเทคโนโลยีที่พร้อมใช้ซึ่งมีเงื่อนไขก่อนหน้าและต้นทุนgame_info: จำนวน tick, เวลาที่ผ่านไป, ความเร็วเกมflows: อัตราส่วนอินพุต/เอาต์พุต, ไอเท็มที่ผลิต, ทรัพยากรที่เก็บเกี่ยว, และตารางราคาทางเลือกสำหรับการประเมินเชิงเศรษฐกิจmessages: ข้อความระหว่างเอเจนต์สำหรับการประสานงานแบบ multi-agenttask_info: คำอธิบายเป้าหมาย, คำสั่ง, task identifier, และความยาว trajectory สูงสุดtask_verification: เมตาดาต้าความสำเร็จ/ล้มเหลวและความคืบหน้าของเป้าหมายserialized_functions: helper function และ abstraction ที่นิยามไว้ก่อนหน้าmap_image: เลย์เอาต์โรงงานแบบ PNG เข้ารหัส base64 สำหรับเอเจนต์เชิงภาพ
- พื้นที่การสังเกตนี้รองรับ การรับรู้เชิงพื้นที่, การติดตามตัวชี้วัดการผลิต, การดีบักข้อผิดพลาด และการวางแผนอัตโนมัติหลายขั้นตอน
- agent harness สำหรับการประเมินจะนำฟิลด์เหล่านี้มาต่อกันเป็น สตริง Markdown ที่จัดรูปแบบไว้
การตั้งค่าเบนช์มาร์ก Lab-play
- Lab-play คือสภาพแวดล้อมแบบจำกัดที่ให้ทรัพยากรคงที่และเอนทิตีเป้าหมายเพียงหนึ่งอย่าง เพื่อเพิ่ม throughput การผลิตให้สูงสุด
- Open-play ซับซ้อนกว่ามาก เพราะต้องเริ่มบนแผนที่ที่สร้างแบบขั้นตอนวิธีโดยไม่มีอินเวนทอรีเริ่มต้น และต้องจัดการกับทรัพยากรที่กระจัดกระจายกว่าและเป้าหมายที่ซับซ้อนกว่า
- มีการทำซ้ำวิธีวิทยาจาก FLE paper ดั้งเดิมให้เข้ากับการตั้งค่า lab-play เพื่อประเมินโมเดลชั้นนำ ณ เดือนกันยายน 2025
- agent harness แบบมาตรฐานจะเพิ่มปฏิสัมพันธ์กับสภาพแวดล้อมลงในประวัติการสนทนาเดียวต่อเนื่องกัน และเมื่อ budget ของโทเค็นใกล้หมด จะสรุปประวัติส่วนเก่าเพื่อให้อนุมานต่อได้
- ไม่มีการประเมินตรรกะ backtracking หรือ reflection ที่ใช้ใน FLE 0.2.0
-
เงื่อนไขการประเมิน
- เป้าหมาย: ทำให้ throughput การผลิตของแข็งถึง 16 ชิ้นต่อนาที และของเหลวถึง 250 หน่วยต่อนาที
- พรอมป์ต์: เอกสาร FLE API, สูตรของ Factorio, คู่มือแพตเทิร์นทั่วไป
- อินเวนทอรี: ชุดไอเท็มที่มีประโยชน์สำหรับสร้างโรงงานที่ใช้งานได้จริง
- จำนวนขั้นสูงสุด: 64 ขั้น โดยหยุดก่อนหากเสร็จสิ้น
- การให้เหตุผล: สำหรับโมเดลที่รองรับ reasoning จะใช้ค่าตั้งต้น
{"enabled": true}
ประสิทธิภาพของโมเดลและข้อจำกัดที่ยังเหลือ
- โมเดลโอเพนซอร์สไล่ตามประสิทธิภาพสูงสุดล่าสุดที่สังเกตได้ใน v0.2.0 เมื่อเดือนพฤษภาคม 2025 ได้ทันแล้ว และมีกรณีสำเร็จในการทำระบบอัตโนมัติสำหรับ electronic circuits, steel plate, sulfur และ plastic
- โมเดลระดับแนวหน้าล่าสุดพัฒนาขึ้นมากเมื่อเทียบกับ FLE v0.2.0 และประสบความสำเร็จเป็นครั้งแรกแม้ในครึ่งหนึ่งของ task ที่ยากกว่า ซึ่งต้องใช้ ingredient dependency มากกว่า 12 รายการ
- ใน FLE lab-play ลำดับอันดับและช่องว่างประสิทธิภาพของโมเดลขั้นสูงใกล้เคียงกับ Claude > GPT > Gemini > Grok และมีความคล้ายกับ GDPVal ของ OpenAI มากที่สุด
- ผลลัพธ์นี้ตัดกับเบนช์มาร์กแบบข้อสอบคงที่ เช่น Humanity's Last Exam, AIME 25, GPQA และ MMMU ซึ่งบางครั้งโมเดลที่อ่อนกว่าใน FLE กลับทำคะแนนได้สูงกว่า
- แม้แต่เอเจนต์ที่สำเร็จ ในงานที่ซับซ้อนก็มักพึ่งพา กลยุทธ์กึ่งแมนนวล แทนระบบอัตโนมัติที่แข็งแกร่ง
- ขนย้ายทรัพยากรด้วยตนเอง
- ใช้ storage chest เป็นบัฟเฟอร์ทรัพยากร
- เลี่ยงการสร้างห่วงโซ่โลจิสติกส์อัตโนมัติเต็มรูปแบบ
- บัฟเฟอร์ระหว่างทางอาจช่วยให้ผ่านการตรวจ throughput ได้ชั่วคราว จึงทำให้การวัดยากขึ้น
- การประเมินจึงบรรเทาปัญหานี้ด้วยการตรวจว่าเอเจนต์ยังคงทำได้ตามโควตาหรือไม่หลังจากปล่อยให้โรงงานทำงานต่อไปอีก 60 วินาทีในช่วง holdout period
- หากกำหนดเป้าหมาย throughput สูงขึ้น การผ่านด้วยโลจิสติกส์แบบแมนนวลจะยากขึ้น และอาจบังคับให้ต้องมีระบบอัตโนมัติที่เหมาะสม
ประเภทข้อผิดพลาดและความแตกต่างระหว่างโมเดล
- โมเดลระดับแนวหน้ายังแสดงให้เห็นอย่างต่อเนื่องว่ามีปัญหาในการฟื้นตัวเมื่อข้อผิดพลาดสะสมขึ้น
- เปรียบเทียบอัตราข้อผิดพลาดเฉลี่ย: {b:23,25,27,41}
- อัตราข้อผิดพลาดเฉลี่ย:
- Claude Opus 4.1: 22.99%
- GPT-5: 25.05%
- Gemini 2.5 Pro: 27.29%
- Grok 4: 40.89%
- Grok 4 มักติดอยู่ในลูปดีบักที่ถอยหลังลงคลอง ขณะที่ GPT-5 มีแนวโน้มกู้คืนได้อย่างสง่างามกว่า
- โมเดลส่วนใหญ่มีอัตราข้อผิดพลาดสูงขึ้นในช่วงกลางของ trajectory เมื่อความซับซ้อนของโรงงานเพิ่มขึ้น
-
ประเภทความล้มเหลว
- ข้อผิดพลาดเชิงไวยากรณ์: โค้ด Python ไม่ถูกต้อง, ความผิดพลาดทางไวยากรณ์, ข้อผิดพลาดที่ทำให้รันไม่ได้เลย
- ข้อผิดพลาดเชิงความหมาย: การใช้คำสั่ง FLE หรืออาร์กิวเมนต์ของเครื่องมือผิด, เข้าใจเอกสารผิด, เช่น
TypeError, AttributeError, NameError
- ข้อผิดพลาดเชิงปฏิบัติ: การให้เหตุผลเกี่ยวกับสถานะเกมปัจจุบันผิด เช่น พยายามใส่ไอเท็มที่ไม่มีในอินเวนทอรี
- ข้อผิดพลาดด้านการวางแผนและการควบคุม: แม้รู้ primitive แต่ไม่สามารถเชื่อมการกระทำเข้าด้วยกันอย่างสม่ำเสมอ ทำให้ได้ trajectory ที่ไม่มีประสิทธิภาพหรือไม่สมบูรณ์
- หมวดหมู่นี้ต้องพิจารณาความสอดคล้องของกลยุทธ์ระดับบน มากกว่าดูข้อผิดพลาดรายตัว จึงยากที่จะวัดเชิงปริมาณได้อย่างน่าเชื่อถือด้วยการวิเคราะห์ trajectory อัตโนมัติ
-
การกระจายของข้อผิดพลาดตามโมเดล
- Claude Opus 4.1 ไม่มีข้อผิดพลาดเชิงไวยากรณ์เลย และ 97.7% ของข้อผิดพลาดใกล้เคียงกับข้อผิดพลาดเชิงปฏิบัติ แสดงว่าเก่งด้านการสร้างโค้ด แต่ยังลำบากกับการรักษา mental model ของสถานะเกมให้แม่นยำ
- Gemini 2.5 Pro, Grok 4 และ GPT-5 แสดงข้อผิดพลาดด้านความเข้าใจ API ราว 12~17% สะท้อนว่าการใช้เอกสาร FLE API ให้ถูกต้องยังเป็นเรื่องยาก
- GPT-5 และ Grok 4 มีข้อผิดพลาดเชิงไวยากรณ์ 21% และ 17% ตามลำดับ ซึ่งถือว่ายังล้มเหลวบ่อยในการสร้าง Python ที่ถูกต้องสำหรับโมเดลที่ทำผลงานดีมากใน coding benchmark รุ่นล่าสุด
- มีเพียง Gemini 2.5 Pro ที่แสดงแนวทางนิยามและใช้ helper function กับ abstraction ในปัจจุบัน
Claude Code และ MCP
- ใน v0.2.0 มีการเปิดตัว MCP server เพื่อให้เอเจนต์ภายนอกโต้ตอบกับ FLE ได้
- ใน v0.3.0 ได้ขยายสิ่งนี้ต่อโดยรวม Claude Code adapter เข้าไปด้วย
- สามารถดูสตรีมที่ Claude Code เล่น Factorio ได้ที่ Twitch
ทิศทางการวิจัยถัดไป
- ปัจจุบันโมเดลระดับแนวหน้ายังเล่น Factorio ได้ไม่ดีมากนักเมื่อเทียบกับมนุษย์ และมีปัญหาในการแทนและสร้างแบบจำลองสภาพแวดล้อมแบบไดนามิก รวมถึงการพัฒนา formal abstraction เพื่อใช้เป็นเครื่องมือในอนาคต
- ถึงอย่างนั้น ความสามารถของโมเดลระดับแนวหน้าใน lab-play ก็พัฒนาขึ้นอย่างต่อเนื่องตลอดปี 2025
- Factorio ยังสามารถถูกใช้ต่อไปในฐานะสภาพแวดล้อมที่เปิดเผยความสามารถทั่วไปของโมเดล เช่น การวางแผนระยะยาว การปรับตัวตามโดเมน การสร้างแบบจำลองโลก และการให้เหตุผลเชิงพื้นที่
- FLE v0.3.0 สถาปนา lab-play ให้เป็น formal benchmark ตัวแรก แต่ก็ยังเป็นเพียงจุดเริ่มต้นของแผนการวิจัย
-
งานระยะใกล้
- เส้นฐานของมนุษย์: วัดประสิทธิภาพของมนุษย์อย่างเป็นระบบตามระดับความยากของ task เพื่อปรับเทียบความสามารถของเอเจนต์
- รับมือ Reward hacking: จัดการปัญหาที่เอเจนต์ใช้ manual crafting กับไอเท็มซับซ้อนแทนระบบอัตโนมัติที่เหมาะสม
- METR-style task scaling: พัฒนา scaling chart ที่เชื่อมความยากของ task กับความสามารถที่ต้องใช้แบบเป็นระบบ
-
งานระยะยาว
- ขยายสู่ Open-play และ megabase: ขยายระดับความยากจาก lab-play แบบจำกัด ไปสู่แผนที่สร้างอัตโนมัติ เป้าหมายหลายขั้น และ megabase ที่มีเครื่องจักรเชื่อมต่อกันนับพัน
- ประสิทธิภาพแบบเรียลไทม์ภายใต้ข้อจำกัดด้านเวลาแฝง: ปัจจุบันเวลาคิดระหว่างการกระทำยังไม่จำกัด แต่สามารถประเมินสมดุลระหว่างความหน่วงในการตอบสนองกับคุณภาพของวิธีแก้ ในเบนช์มาร์กที่ Factorio เดินต่อไปตลอดเวลา
- การประสานงานแบบ multi-agent: ครอบคลุมความร่วมมือ การแข่งขัน emergent market dynamics การแบ่งงาน การเจรจาจัดสรรทรัพยากร และการก่อตัวของความได้เปรียบเชิงเปรียบเทียบ
- สภาพแวดล้อมนอกการกระจายแบบอิง Mod: ประเมินว่าสามารถเรียนรู้ causal structure ใหม่ได้หรือไม่ใน tech tree และกลไกเกมแบบใหม่
- Native computer-use interface: ประเมินเอเจนต์ผ่านอินเทอร์เฟซคีย์บอร์ด เมาส์ และวิชันแบบเดียวกับมนุษย์ แทน Python API
- พลวัตเชิงปฏิปักษ์และความทนทาน: เพิ่ม hostile aliens และความท้าทายจากสภาพแวดล้อมไม่กำหนดแน่นอน เพื่อประเมิน adaptive control และ resilience
วิธีเข้าร่วม
- FLE เป็นโอเพนซอร์สทั้งโค้ดและภารกิจ
- ผู้ที่ต้องการมีส่วนร่วมได้แก่:
- นักวิจัย ที่สำรวจสถาปัตยกรรมใหม่สำหรับการวางแผนระยะยาวและการให้เหตุผลเชิงพื้นที่
- วิศวกร ที่เพิ่มประสิทธิภาพโครงสร้างพื้นฐานสำหรับการประเมินและการฝึกขนาดใหญ่
- Modder ที่ออกแบบ challenge domain ใหม่
- หากสนใจเข้าร่วมทีม สามารถหาได้ที่ Discord
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนนี้โดนตกเต็ม ๆ แล้ว และอยากสมัครเข้า ห้องแล็บ Factorio ของ Anthropic เดี๋ยวนี้เลย
ดูจากแค่论文หรือคอมเมนต์ยังไม่รู้ว่าส่งข้อมูลมัลติโมดัลกลับไปด้วยหรือเปล่า แต่หลายโมเดลไม่ใช่มัลติโมดัล ก็น่าจะไม่ใช่ อย่างไรก็ดี บางตัวทำได้ และ Qwen 2.5 VLM ที่เพิ่งออกมาก็ดูค่อนข้างแข็งแกร่งเมื่อเทียบกับขนาด
มีการเน้นค่อนข้างมากเรื่องการขาดความสามารถเชิงพื้นที่ และพูดถึงความยากทั้งด้านการวางแผนกับการวางแผนเชิงพื้นที่ เลยสงสัยว่าส่ง ภาพอย่างสกรีนช็อต ไปด้วยหรือไม่ ถ้าไม่ ก็อยากรู้ว่าคิดอย่างไรกับเรื่องนี้
แถมอีกอย่าง การเปิดใช้ไลบรารี Python ผ่าน MCP เพื่อให้ LLM ทุกตัวที่ใช้เครื่องมือได้มาเล่น Factorio ดูเหมือนเป็นเรื่องที่ควรต้องทำโดยธรรมชาติ
ในการทดสอบบางอย่าง แม้จะใส่สกรีนช็อตสถานะเกมเข้าไป ก็ไม่ได้ทำให้ประสิทธิภาพของโมเดลสำเร็จรูปดีขึ้น เมื่อสถานะเกมซับซ้อนขึ้นและมีเอนทิตีจำนวนมากในสกรีนช็อต โมเดลก็ยิ่งสับสนมากขึ้น ทั้งยังหลอนเรื่องทิศทางหรือเอนทิตี หรือแก้ข้อผิดพลาดที่เห็นได้ชัดอย่างสายพานลำเลียงที่ขาดหาย หรือ inserter ที่หมุนผิดทางไม่ได้
มองว่าเป็นเพราะ VLM ปัจจุบันยังไม่เก่งเรื่อง การให้เหตุผลเชิงพื้นที่ ในภาพที่มีรายละเอียดมาก และถ้า fine-tune ก็น่าจะดีขึ้นมากได้ ส่วน MCP กำลังมาแรงมากช่วงนี้ จึงตั้งใจจะลองดูเช่นกัน
เกมเล่นบนกริด ดังนั้นการแปลงสถานะเกมเป็น การแสดงผลแบบ ASCII น่าจะทำได้ไม่ยาก
ไม่นานมานี้มีโพสต์ของทีมหนึ่งบน HN ที่ฝึกเอเจนต์ด้วย reinforcement learning ให้เคลียร์ Pokémon Red ได้ พวกเขาบอกว่าต้องปรับ cost function ให้ให้รางวัลเล็ก ๆ กับการสำรวจ และให้รางวัลใหญ่กับ ภารกิจจำเป็น อย่างการโค่นยิม
สงสัยว่าจะใช้แนวทางเดียวกันกับ Factorio ได้ไหม ถ้าเทียบกับ Pokémon Red ภารกิจจำเป็นหลักของ Factorio คือการสร้างระบบอัตโนมัติสำหรับไอเท็มใหม่และ science pack ใหม่
ถ้าให้รางวัลเล็ก ๆ กับอัตราการผลิตต่อวินาทีของแต่ละไอเท็ม ให้รางวัลระดับกลางกับการทำ automation ของไอเท็มใหม่ และให้รางวัลใหญ่กับการทำ automation ของ science pack ใหม่ ก็น่าจะเป็น reward function ที่ดีได้
การบอกเอเจนต์ Factorio แค่ว่า “สร้างโรงงานใหญ่ ๆ” ก็เหมือนบอกเอเจนต์ Pokémon Red ว่า “เคลียร์เกมซะ” และควรแยกเป็นขั้นตอนเล็กลงพร้อม reward function ที่ปรับอย่างระมัดระวังมาก
พอคิดเรื่องนี้แล้วก็อยากกระโดดเข้าไปร่วมโปรเจกต์นี้เลย
เวลา玩家 Factorio สร้าง megabase ขนาดใหญ่ เป้าหมายไม่ใช่ขนาดในตัวมันเอง แต่คือ ปริมาณงานวิจัยวิทยาศาสตร์ต่อนาที (SPM) ตัวชี้วัดที่ควรให้เอเจนต์จึงควรเป็น SPM ไม่ใช่ฐานที่ “ใหญ่ที่สุด”
โมเดลเหล่านี้ทำภารกิจจำเป็นแบบนี้ได้ แต่เมื่อได้รับเป้าหมายทั่วไปอย่าง “เล่นเกมให้จบ” ก็ยังขาดระดับการวางแผนระยะยาวพอที่จะพยายามทำ มักไม่พยายามขยายโรงงานเดิม และสร้างแต่โครงสร้างเล็ก ๆ ที่ไม่ประสานกัน
หนึ่งในเป้าหมายก็คือการดูว่าโมเดลจะทำตัวอย่างไรเมื่อได้รับเป้าหมายที่คลุมเครือและกว้าง ๆ
ส่วนที่บอกว่าประเมินโมเดลภาษา frontier หกตัวในสองการตั้งค่านั้นน่าสนใจ แต่ก็มี benchmark แบบไดนามิก ที่ง่ายกว่านี้มาก ซึ่งสามารถทำให้ความสามารถในการวางแผนของโมเดลที่ไม่ใช่ reasoning model อิ่มตัวได้
แค่ให้รายชื่อเส้นทางเชื่อมต่อเที่ยวบินระหว่างเมือง แล้วถามหาเส้นทางเดินทางระหว่างเมืองเหล่านั้น พอ shortest path ระหว่างสองโหนดยาวพอ โมเดลพวกนี้ก็สับสนกันหมด
shortest path ระหว่างเมืองที่ยาวที่สุดซึ่งแต่ละโมเดลหาเจอได้อย่างเสถียร 8 ครั้งจาก 10 ครั้งสำหรับแต่ละความยาว มีดังนี้
| 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 |
อย่างไรก็ดี เราอยากสร้าง สภาพแวดล้อมประเมินผล ที่ครอบคลุมสเปกตรัมกว้างกว่า ทดสอบหลายความสามารถพร้อมกัน และยังคงใช้ได้ต่อไปในอนาคต
เนื้อหาที่บอกว่าเมื่อสร้างโรงงานหลายโซน ทุกโมเดลแสดงข้อจำกัดด้านการวางแผนเชิงพื้นที่นั้นฟังขึ้น ความล้มเหลวอย่างการวางเอนทิตีชิดกันเกินไป ไม่เผื่อพื้นที่เชื่อมต่อ หรือวาง inserter ผิด เป็นเรื่องที่พบได้บ่อย
เข้าใจว่าทำไม LLM ถึงอ่อนเรื่อง การให้เหตุผลเชิงพื้นที่ เพราะมีข้อมูลฝึกที่เหมาะกับเรื่องนี้ไม่มากนัก สงสัยว่าถ้าแก้ปัญหาการให้เหตุผลเชิงพื้นที่ได้แล้ว จะมีความสามารถในการให้เหตุผลเพิ่มเติมแบบไหนปรากฏขึ้น
แค่มี simulator ที่เรียบง่ายที่สุด ก็สร้างได้แทบไม่จำกัดแล้วไม่ใช่หรือ?
เช่น แค่เขียน tic-tac-toe บนกริดอนันต์ด้วยโค้ดสัก 10 บรรทัด ก็สร้าง ชุดฝึกแบบไม่จำกัด ได้แล้ว
อยากเห็น การออกแบบ balancer เป็นอีกหมวดหนึ่งของโจทย์ “Lab Play”
balancer ขนาดเล็กก็ซับซ้อนได้พอสมควร (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9) และคงน่าสนใจถ้าได้ดูความสามารถของโมเดลในการออกแบบและแก้ปัญหานี้
https://github.com/R-O-C-K-E-T/Factorio-SAT
เป็นไอเดียที่เจ๋งมาก
ดูเหมือนมีการทดลองที่น่าสนใจให้ลองทำได้เยอะตรงนี้ ผมคิดว่าการใส่องค์ประกอบด้านเวลาเข้าไปในสถานการณ์ lab-play เป็นความคิดที่ดี ผู้เล่น Factorio ส่วนใหญ่ที่เปิดไบเตอร์เล่นจะมองมันเป็นการผสมกันของข้อจำกัดด้านเวลาและพื้นที่ และการกำหนดเวลาจำกัดให้เอเจนต์ก็ทำให้เทียบเคียงกับสถานการณ์ในเกมจริงได้ในระดับหนึ่ง
ผมชอบที่การออกแบบเฟรมเวิร์กนี้ทดสอบสิ่งที่ต่างจาก ความสามารถในการควบคุมระดับไมโคร แบบที่เคยเห็นในการทดลอง DOTA 2 หรือ StarCraft 2 โดยเฉพาะใน StarCraft 2 ถ้ามี APM ไม่จำกัด ก็จะเกิดพฤติกรรมอย่างการควบคุมคนงานแบบละเอียดสุดโต่งเพื่อขุดแร่เพิ่มอีกนิด
พฤติกรรมแบบนี้เป็นผลลัพธ์การเรียนรู้ที่น่าสนใจในบริบทแคบ ๆ แต่ในความเป็นจริงมีภาระการควบคุมสูง และแม้แต่นักกีฬาอีสปอร์ตก็มีโอกาสพลาดได้ อีกทั้งดูเหมือนไม่ได้ให้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับประสิทธิภาพด้านการวางแผนระยะยาว การลงมือทำ และการวิเคราะห์ของเอเจนต์ด้วย
ในแง่นั้น FLE จึงน่าสนใจกว่ามากในฐานะ เฟรมเวิร์กประเมินการคิด ในระดับสูงกว่า ผมยังสงสัยด้วยว่ามีแผนทำเบนช์มาร์กการปรับเลย์เอาต์ให้เหมาะสมหรือไม่ เช่น เมื่อมีเซลล์โรงงานที่กำหนดให้มีอินพุต X รายการและเอาต์พุต Y รายการ แล้วให้ปรับประสิทธิภาพให้เหมาะสม
เป้าหมายคือทดสอบความสามารถของเอเจนต์ในการสร้างกลุ่มอุตสาหกรรมทางทหาร ประเด็นที่ตลกตอนพัฒนาไอเดียนี้คือโมเดลแนวหน้าลังเลที่จะสร้างเอนทิตีที่มีชื่ออย่าง ‘GunTurret’ ดูเหมือนมันจะมองว่าขัดกับรัฐธรรมนูญ บางทีอาจต้องเปลี่ยนชื่อป้อมปืนเป็นอะไรอย่าง ‘SuperSoaker’ แทน
ส่วนเบนช์มาร์กการปรับเลย์เอาต์ให้เหมาะสมนั้น จริง ๆ เพิ่งคุยกันเมื่อวาน คิดว่าต้องมีโจทย์เลย์เอาต์สองแบบคือ 1) ซ่อมโรงงานที่เสียแบบเล็กน้อย 2) ปรับปรุง throughput ของโรงงานนี้ การนำไปทำจริงน่าจะค่อนข้างง่าย จึงน่าลองดู
ยังไม่ค่อยเข้าใจ โมเดลเหล่านี้ถูก ฝึกภายหลัง ให้เล่น Factorio หรือเปล่า?
A) ถ้าใช่ แล้วทำได้อย่างไรกับโมเดลที่ไม่มี weight สาธารณะอย่าง Claude? B) ถ้าไม่ใช่ เอเจนต์รู้ได้อย่างไรว่า API ทำอะไร? ต่อให้เดาจากความหมายภาษาอังกฤษของคำสั่ง API ได้ เช่น
place_entity_next_toคือวางเอนทิตีไว้ข้าง ๆ อะไรสักอย่าง แล้วมันรู้สูตรการผลิตได้อย่างไร? ถ้าเป็นการลองแล้วเรียนรู้ ก็วนกลับไปที่ A อีกอ่าน PDF แล้วดูเหมือนไม่ได้มีการฝึกภายหลัง แต่ถ้าอย่างนั้นก็ไม่รู้ว่าจะอธิบายคำถามในข้อ B อย่างไร
ถ้าไม่มีการฝึกภายหลังจริง ๆ และคาดหวังให้ค้นหาสูตรการผลิตใน context window ผมคิดว่ามันสั้นเกินไปสำหรับการปรับปรุงแบบ reinforcement learning
สรุปคือผมไม่แน่ใจว่าพวกเขาทดสอบโมเดลเหล่านี้ด้วยการฝึกภายหลังได้หรือไม่ และถ้าทำโดยไม่มีการฝึกภายหลัง ทั้งหมดก็ทำได้ดีจนน่าเหลือเชื่อ
ถ้าผู้เขียนเห็น อยากรู้ว่าโดยเฉลี่ยแล้วใน context window มีคู่คำถาม API กับคำตอบ API อยู่กี่คู่ ต่อเนื่องจากนั้นก็อยากรู้ด้วยว่า ถ้าย่อชื่อ API call เพื่อใส่คู่คำตอบได้มากขึ้นใน context window เดียวกัน ผลลัพธ์จะดีขึ้นหรือไม่
คู่มือนี้อธิบายว่าเครื่องมือทำอะไร มีผลต่อสถานะเกมอย่างไร และตัวอย่างการใช้งานบางอย่าง เช่น วิธีใช้
place_entity_next_toเพื่อวาง inserter ข้างหีบที่มีอยู่ตามที่ Jack บอก ไม่มีการฝึกภายหลังเลย แต่เอเจนต์ทั้งหมดมี คำอธิบาย API แบบครบถ้วนในบริบท รวมถึงเครื่องมือ เอนทิตี และงานวิจัย ดังนั้นผลลัพธ์นี้จึงแสดงให้เห็นในระดับหนึ่งว่าเอเจนต์สมัยใหม่ใช้ API ที่อยู่นอกการกระจายโดยสิ้นเชิง แต่มีเอกสารประกอบที่เหมาะสม ได้ดีเพียงใด
ในบริบทสามารถใส่ได้สูงสุดประมาณ 128 คู่ แต่เพราะประสิทธิภาพเท่ากับ 32 คู่ จึงเลือกใช้ 32 คู่ในขั้นสุดท้ายด้วยเหตุผลด้านต้นทุนและ latency
การเข้ารหัสอินพุต/เอาต์พุตให้สั้นลงทำให้ประสิทธิภาพลดลง ดูเหมือนว่าชื่อที่มีความหมายเชิงบรรยายจะช่วยโมเดลที่ผ่าน pretraining มา เพราะให้ intuition ว่าสิ่งนั้นทำอะไร
น่าสนใจที่มีสถานการณ์ซับซ้อนเพียงไม่กี่แบบ ผมคิดมาตลอดว่า ถ้าอยากให้เอเจนต์เกมแบบ ML เรียนรู้กลไกเกมได้อย่างถูกต้อง ต้องมีพัซเซิลขนาดเล็กมาก ๆ หลายร้อยข้อ โดยแต่ละข้อมีรูปแบบแปรผันอีกหลายร้อยแบบ
ตัวอย่างเช่น โรงงานไม่มีไฟฟ้า ให้ติดเสาไฟที่ขาดไป, โรงงานขาดไอเท็ม ให้ใส่สายพานที่ขาดไป, สร้างและวางเครื่องประกอบ 200 เครื่อง, เครื่องประกอบหยุดด้วยเหตุผลบางอย่าง ให้แก้ไข, ผลผลิตโรงงานต่ำเกินไป ให้เพิ่มเป็นสองเท่า, เคลื่อนที่ไปยังจุดอื่นในโรงงานให้เร็วที่สุด, แก้ปัญหาไฟฟ้าไม่พอ และแบ่งโจทย์ทั้งหมดนี้เป็นกรณีที่มีหุ่นยนต์กับไม่มีหุ่นยนต์
สถานการณ์ตัวอย่างแบบนี้สักหลายพันแบบน่าจะ สร้างด้วยโปรแกรม ได้ค่อนข้างง่าย จากนั้นใช้เหมือนคลังข้อสอบ IQ โดยสุ่มมาสัก 12 ข้อจากคลัง แล้วประเมินประสิทธิภาพแต่ละข้อจากเวลาและวัสดุที่ใช้
ผมคิดว่าเอเจนต์ ML จะถูกประเมินจากตัวอย่างที่สุ่มมาจากคลังสถานการณ์ขนาดใหญ่ซึ่งความซับซ้อนเพิ่มขึ้นอย่างค่อยเป็นค่อยไป และเมื่อได้คะแนนสูงพอในระดับความซับซ้อนต่ำแล้ว พอเจอสถานการณ์ที่ซับซ้อนขึ้นก็จะเรียนรู้ได้เร็วกว่า
เท่าที่รู้ สุดท้ายก็ลงเอยเป็นงานแบบเดิมคือออกแบบสถานะเริ่มต้นและโจทย์ที่จะต้องทำให้เสร็จด้วยมือ
แต่เนื่องจากงานปัจจุบันมุ่งเน้นการประเมิน จึงไม่ได้ทำแบบนั้น “ความยาก” ของโจทย์ต่าง ๆ ค่อนข้างเป็นเรื่องเชิงอัตวิสัย จึงต้องตัดสินใจแบบตามอำเภอใจซึ่งอาจส่งผลต่อการประเมิน เช่น โจทย์ใดควรมาหลังสถานการณ์ใด และครอบคลุมระดับความยากทั้งหมดเพียงพอหรือไม่
สงสัยว่ามี เบนช์มาร์กผู้เล่นมนุษย์ สำหรับรูปแบบอินเทอร์เฟซแบบนี้หรือเปล่า ไม่ได้หมายความว่าจำเป็นหรือเกี่ยวข้อง แค่อยากรู้ว่า Factorio แบบโปรแกรมมิ่งให้ความรู้สึกอย่างไร
การใช้การให้เหตุผลเชิงพื้นที่ผ่านพรอมป์ข้อความน่าจะค่อนข้างยากแม้แต่กับผู้เล่นมนุษย์
สถิติปัจจุบันคือโหมดผู้เล่นเดี่ยวมากกว่า 4 ชั่วโมงเล็กน้อย และแบบทีมคือ 90 นาที แค่นี้ก็ชี้ให้เห็นว่ามีพื้นที่ให้ LLM ที่ทำมัลติทาสก์แซงมนุษย์ได้
สงสัยว่าอีกไม่กี่ปีข้างหน้า คู่ต่อสู้ทั้งหมดในเกมอาจกลายเป็น LLM ที่เข้าถึง API ควบคุมเกมแบบนี้ได้หรือไม่
และก็สงสัยด้วยว่ามีประเภทโจทย์ไหนที่โมเดลพบว่ายากเป็นพิเศษหรือเปล่า หรือความยากเพิ่มขึ้นตามจำนวนไอเท็มที่ต้องวางเป็นหลัก
เป้าหมายหลักของ AI ศัตรูไม่ใช่การเป็นสิ่งที่ยากที่สุดในโลก แต่คือการมอบความท้าทายที่น่าสนใจและผู้เล่นพอจะเอาชนะได้ ในเกมส่วนใหญ่ การสร้าง AI ประสิทธิภาพสูงมาก ๆ ไม่จำเป็นว่าจะยาก แต่ก็ไม่ได้แปลว่าจะทำให้เล่นสู้ด้วยแล้วสนุกขึ้น
เกมส่วนใหญ่มีสถานะเชิงตรรกะที่มีขอบเขตจำกัด เพียงแต่ใหญ่พอที่มนุษย์จะหาเฉลยทั้งหมดไม่ไหว แน่นอนว่ามนุษย์เก่งมากในการดันขอบของสถานะเหล่านี้เพื่อหาวิธีอ้อม
แม้แต่ในเกมที่มีปริมาณสถานะมากกว่าปกติมาก ก็ไม่ค่อยมีใครอยากได้ซูเปอร์ AI ตัวอย่างเช่น ใน FPS ไม่มีใครชอบเล่นสู้กับ เอมบอต
Factorio เป็นข้อยกเว้นจากเกมทั่วไป ตรงที่เงื่อนไข “ชนะ” ที่แท้จริงแทบขึ้นอยู่กับผู้เล่นทั้งหมด ใน Factorio ที่ไม่มี DLC เงื่อนไขชนะของเกมคือจรวด ซึ่งสามารถสร้างได้แทบไม่ต้องสร้างโรงงานเลย นอกจากสิ่งก่อสร้างพื้นฐานที่สุดสำหรับของที่ทำด้วยมือไม่ได้ แน่นอนว่าจะช้ามาก แต่ก็เป็นตัวเลือกที่เป็นไปได้ ดังนั้นเบนช์มาร์กแบบนี้จึงให้ความสำคัญกับ ประสิทธิภาพ มากกว่า “ใช้งานได้หรือไม่”
โมเดลมีปัญหาหลัก ๆ อยู่สองด้าน ด้านแรกคือการให้เหตุผลเชิงพื้นที่ โมเดลมักทำข้อผิดพลาดแบบ off-by-one และโรงงานก็ไวต่อความผิดพลาดแบบนี้มากเหมือนการเขียนโปรแกรม ทำให้กู้คืนได้ยาก
ด้านที่สองคือการวางแผนระยะยาว คือความสามารถในการเข้าใจว่าควรทำอะไรในเชิงกลยุทธ์ ก่อนจะสร้างเป้าหมายย่อยเชิงยุทธวิธี
ใน lab-play ความยากมักแปรผันตามความลึกของห่วงโซ่การผลิต หากต้องมีส่วนโรงงานหลายส่วนก่อนจึงจะสร้างไอเท็มบางอย่างได้ ก็จะยากขึ้นมาก เรื่องนี้ดูเกี่ยวข้องกับการวางแผน เพราะโมเดลมักจะลงลึกไปแก้รายละเอียดของปัญหาเล็ก ๆ มากกว่าจะวางแผนใหญ่ก่อน