Môi trường học tập Factorio – Tác nhân xây dựng nhà máy

 (jackhopkins.github.io)
1 điểm bởi GN⁺ 2025-03-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • FLE 0.3.0 đã được công bố để kiểm chứng lập kế hoạch dài hạn và suy luận không gian của tác nhân bằng trò chơi tự động hóa nhà máy Factorio, đồng thời có cả bản demo kết nối Claude Code với Factorio
  • Phiên bản mới giúp thí nghiệm nghiên cứu dễ dàng hơn với chạy headless, trình dựng quan sát pixel, giao diện tương thích OpenAI Gym, chạy đánh giá qua CLI, cùng công cụ ghi log và phân tích với Weights and Biases
  • Tác nhân ví dụ lặp lại quá trình debug việc phát điện, khai thác quặng sắt, luyện kim, bố trí máy lắp ráp và nối băng chuyền để đạt mục tiêu sản xuất 16 iron gear wheel mỗi phút
  • Benchmark Lab-play đánh giá Pass@8 trên các mô hình mạnh tính đến tháng 9/2025, với mục tiêu sản xuất 16 đơn vị/phút cho vật phẩm rắn, 250 đơn vị/phút cho chất lỏng, và giới hạn tối đa 64 bước
  • Các mô hình frontier đã tiến bộ so với v0.2.0, nhưng vẫn còn các vấn đề như vận chuyển thủ công, buffer bằng chest, dùng sai API và đánh giá sai trạng thái game động, nên Factorio vẫn là một môi trường khó để bộc lộ năng lực lập kế hoạch dài hạn và phục hồi động

Những thay đổi trong FLE 0.3.0

  • FLE 0.3.0 là bản cập nhật lớn của môi trường học tập dùng bài toán xây dựng nhà máy trong Factorio để kiểm tra lập kế hoạch dài hạn, suy luận và mô hình hóa thế giới
  • Trong bài báo FLE trước đó, các mô hình frontier cho thấy khó khăn trong thích nghi với môi trường thay đổi, đặt mục tiêu dài hạn và phục hồi động; còn 0.2.0 đã giới thiệu multi-agency, tác nhân backtracking và thị giác
  • Các thay đổi chính của 0.3.0:
    • Kết nối Claude Code với Factorio thông qua FLE và trình diễn trên Twitch
    • Loại bỏ sự phụ thuộc vào game client Factorio để hỗ trợ mở rộng headless cho các thí nghiệm quy mô lớn
    • Trình dựng game headless mới cung cấp quan sát pixel chân thực cho nghiên cứu tác nhân đa phương thức
    • Môi trường đánh giá nay tương thích với giao diện OpenAI Gym, giúp dễ tích hợp với các codebase nghiên cứu hiện có
    • FLE CLI hỗ trợ chạy thí nghiệm bằng lệnh shell một dòng, đồng thời mã đánh giá, logging Weights and Biases, khôi phục sweep và công cụ phân tích đều được mở mã nguồn

Bắt đầu nhanh

# 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 được cài bằng uv, khởi động cụm máy chủ Factorio bằng fle cluster start, rồi chạy đánh giá bằng API key trong .env và tệp cấu hình

Ví dụ nhà máy iron gear wheel tự động

  • Tác nhân ví dụ bắt đầu trong thế giới lab-play với mục tiêu xây dựng nhà máy iron gear wheel và lượng vật phẩm ban đầu trong inventory
  • Nó gọi FLE API bằng Python để tương tác với môi trường game, đồng thời quan sát standard output và thông báo lỗi của từng lần chạy

  • Thiết lập điện

    • Dùng nearest(Resource.Water) để tìm vị trí nước và đặt offshore pump
    • Sau khi đặt boiler và steam engine, dùng connect_entities để nối đường ống và cho coal vào boiler
    • Chờ 5 giây rồi kiểm tra giá trị energy của steam engine để xác minh phát điện

  • Khai thác và luyện sắt

    • Sau khi tìm vị trí iron ore, nó đặt 2 electric mining drill và một electric furnace
    • Nó tính rằng để đạt 16 iron gear wheel/phút thì cần 32 iron plate/phút, và vì electric mining drill khai thác 30 ore mỗi 60 giây nên cần 2 drill
    • Các drill và lò điện được nối vào lưới điện của steam engine bằng medium electric pole

  • Bố trí máy lắp ráp

    • Đặt AssemblingMachine2 ở vị trí cách khu khai thác ít nhất 20 ô
    • Thiết lập recipe của máy lắp ráp là Prototype.IronGearWheel, đặt inserter đầu vào/đầu ra rồi nối vào lưới điện
    • Assembling machine 2 có thể chế tạo 90 iron gear wheel mỗi 60 giây, nên chỉ cần 1 máy là đủ cho throughput mục tiêu

  • Nối băng chuyền và phục hồi lỗi

    • Ban đầu tác nhân cố nối trực tiếp bằng belt giữa furnace output inserter và assembler input inserter, nhưng phát hiện một storage chest chặn đường
    • Nó lấy iron plate ra khỏi 2 wooden chest đang chặn và xóa các chest đó, nhưng lại để sót input buffer chest phía máy lắp ráp nên lỗi tái diễn
    • Cuối cùng, nó xóa cả chest đầu vào của assembler và nối mạng logistics dựa trên transport belt để hệ thống iron gear wheel tự động đạt throughput mục tiêu

Không gian quan sát và agent harness

  • Ở mỗi bước, tác nhân nhận được một đối tượng Observation có cấu trúc chứa trạng thái game
  • Các trường chính:
    • raw_text: standard output, thông báo lỗi và số dòng mã nguồn của lần thực thi action program ngay trước đó
    • entities: mọi entity trong thế giới game cùng vị trí, loại, hướng, inventory, cảnh báo và các thuộc tính khác
    • inventory: loại vật phẩm và số lượng trong inventory cá nhân của tác nhân
    • research: công nghệ đã nghiên cứu, tiến độ nghiên cứu hiện tại, cùng các công nghệ khả dụng có điều kiện tiên quyết và chi phí
    • game_info: số tick, thời gian đã trôi qua, tốc độ game
    • flows: tỷ lệ đầu vào/đầu ra, vật phẩm được chế tạo, tài nguyên được thu thập, và bảng giá tùy chọn để đánh giá kinh tế
    • messages: tin nhắn giữa các tác nhân để điều phối multi-agent
    • task_info: mô tả mục tiêu, chỉ dẫn, task identifier và độ dài trajectory tối đa
    • task_verification: metadata về thành công/thất bại và tiến độ mục tiêu
    • serialized_functions: các helper function và abstraction đã định nghĩa từ trước
    • map_image: ảnh PNG mã hóa base64 của bố cục nhà máy dành cho tác nhân thị giác
  • Không gian quan sát này hỗ trợ nhận thức không gian, theo dõi chỉ số sản xuất, debug lỗi và lập kế hoạch tự động hóa nhiều bước
  • Agent harness dùng cho đánh giá sẽ nối các trường này thành một chuỗi Markdown đã được định dạng

Thiết lập benchmark Lab-play

  • Lab-play là môi trường giới hạn, cung cấp tài nguyên cố định và một entity mục tiêu duy nhất để tối đa hóa throughput sản xuất
  • Open-play phức tạp hơn nhiều vì bắt đầu trên bản đồ sinh thủ tục, không có inventory ban đầu, với tài nguyên thưa hơn và mục tiêu phức tạp hơn
  • Với các mô hình mạnh tính đến tháng 9/2025, nhóm tác giả tái hiện phương pháp luận của bài báo FLE gốc theo cấu hình lab-play
  • Agent harness chuẩn hóa liên tục thêm các tương tác môi trường vào một lịch sử hội thoại duy nhất, và khi thiếu ngân sách token thì sẽ tóm tắt các đoạn cũ để tiếp tục suy luận
  • Logic backtracking hay reflection từng dùng trong FLE 0.2.0 không được đánh giá

  • Điều kiện đánh giá

    • Mục tiêu: đạt throughput 16 đơn vị/phút cho vật phẩm rắn, 250 đơn vị/phút cho chất lỏng
    • Prompt: tài liệu FLE API, recipe của Factorio, hướng dẫn các pattern phổ biến
    • Inventory: một bộ vật phẩm hữu ích để xây dựng nhà máy có chức năng
    • Số bước tối đa: 64 bước, kết thúc sớm nếu hoàn thành
    • Suy luận: với các mô hình hỗ trợ reasoning, áp dụng cấu hình mặc định {"enabled": true}

Hiệu năng mô hình và các giới hạn còn lại

  • Các mô hình nguồn mở đã bắt kịp mức hiệu năng tốt nhất mới nhất quan sát được ở v0.2.0 vào tháng 5/2025, với các ca thành công trong tự động hóa electronic circuits, steel plate, sulfur và plastic
  • Các mô hình frontier mới nhất đã cải thiện đáng kể so với FLE v0.2.0, và lần đầu thành công cả ở nửa khó hơn của các task có thể cần hơn 12 dependency nguyên liệu
  • Trong FLE lab-play, thứ hạng và khoảng cách hiệu năng của các mô hình cao cấp gần với Claude > GPT > Gemini > Grok, và giống nhất với GDPVal của OpenAI
  • Kết quả này đối lập với các benchmark tĩnh dạng bài thi như Humanity's Last Exam, AIME 25, GPQA, MMMU, nơi một số mô hình yếu hơn trong FLE lại có thể đạt điểm cao hơn
  • Ngay cả tác nhân thành công cũng thường dựa vào chiến lược bán thủ công thay vì tự động hóa vững chắc trong các task phức tạp
    • Tự vận chuyển tài nguyên
    • Dùng storage chest làm buffer tài nguyên
    • Lách việc xây dựng chuỗi logistics hoàn toàn tự động
  • Các buffer trung gian có thể tạm thời đáp ứng kiểm tra throughput, khiến việc đo lường trở nên khó khăn
  • Đánh giá giảm nhẹ vấn đề này bằng cách kiểm tra việc đáp ứng hạn ngạch sau holdout period khi tác nhân phải để nguyên nhà máy chạy trong 60 giây
  • Nếu đặt mục tiêu throughput cao hơn, việc vượt qua bằng logistics thủ công sẽ khó hơn, từ đó buộc phải có tự động hóa phù hợp

Các loại lỗi và khác biệt giữa các mô hình

  • Các mô hình frontier vẫn tiếp tục gặp khó khăn trong việc phục hồi khi lỗi tích lũy
  • So sánh tỷ lệ lỗi trung bình: {b:23,25,27,41}
  • Tỷ lệ lỗi trung bình:
    • Claude Opus 4.1: 22.99%
    • GPT-5: 25.05%
    • Gemini 2.5 Pro: 27.29%
    • Grok 4: 40.89%
  • Grok 4 thường rơi vào các vòng lặp debug thoái hóa, trong khi GPT-5 cho thấy kiểu phục hồi thanh thoát hơn
  • Phần lớn mô hình có tỷ lệ lỗi cao hơn ở đoạn giữa của trajectory, khi độ phức tạp của nhà máy tăng lên

  • Các kiểu thất bại

    • Lỗi cú pháp: mã Python không hợp lệ, lỗi ngữ pháp, lỗi chặn việc thực thi ngay từ đầu
    • Lỗi ngữ nghĩa: dùng sai lệnh FLE hoặc tham số công cụ, hiểu sai tài liệu, TypeError, AttributeError, NameError, v.v.
    • Lỗi thực dụng: suy luận sai về trạng thái game hiện tại, ví dụ cố chèn vật phẩm không có trong inventory
    • Lỗi lập kế hoạch/điều khiển: dù biết các primitive nhưng không thể nối hành động một cách nhất quán, dẫn đến trajectory kém hiệu quả hoặc không hoàn chỉnh
    • Danh mục này cần xem xét tính nhất quán chiến lược ở cấp cao hơn từng lỗi riêng lẻ, nên khó định lượng đáng tin cậy bằng phân tích trajectory tự động

  • Phân bố lỗi theo mô hình

    • Claude Opus 4.1 không có lỗi cú pháp và 97.7% lỗi của nó gần với lỗi thực dụng, cho thấy khả năng sinh mã mạnh nhưng khó duy trì mental model chính xác về trạng thái game
    • Gemini 2.5 Pro, Grok 4 và GPT-5 cho thấy 12~17% lỗi hiểu API, tức vẫn gặp khó khi sử dụng chính xác tài liệu FLE API
    • GPT-5 và Grok 4 lần lượt có 21% và 17% lỗi cú pháp, cho thấy việc sinh Python hợp lệ vẫn thường xuyên thất bại dù là các mô hình hàng đầu trên benchmark coding hiện đại
    • Chỉ riêng Gemini 2.5 Pro hiện thể hiện cách tiếp cận định nghĩa và sử dụng helper function cùng abstraction

Claude Code và MCP

  • Ở v0.2.0, một MCP server đã được công bố để các tác nhân bên ngoài có thể tương tác với FLE
  • Trong v0.3.0, hệ thống này được mở rộng để bao gồm adapter Claude Code
  • Có thể xem luồng Claude Code chơi Factorio trên Twitch

Hướng nghiên cứu tiếp theo

  • Các mô hình frontier hiện tại vẫn chơi Factorio chưa tốt nếu so theo chuẩn con người, và gặp khó trong biểu diễn, mô hình hóa môi trường động cũng như phát triển abstraction hình thức để dùng như công cụ trong tương lai
  • Dù vậy, năng lực của các mô hình frontier trong lab-play đã cải thiện đều trong suốt năm 2025
  • Factorio vẫn có thể tiếp tục được dùng như một môi trường bộc lộ các năng lực mô hình tổng quát như lập kế hoạch dài hạn, thích nghi theo miền, mô hình hóa thế giới và suy luận không gian
  • FLE v0.3.0 xác lập lab-play như benchmark hình thức đầu tiên, nhưng mới chỉ là điểm khởi đầu của kế hoạch nghiên cứu

  • Các bài toán gần hạn

    • Đường cơ sở của con người: đo lường có hệ thống hiệu năng của con người theo độ khó task để hiệu chỉnh năng lực tác nhân
    • Ứng phó reward hacking: xử lý vấn đề tác nhân dùng manual crafting thay cho tự động hóa phù hợp đối với các vật phẩm phức tạp
    • METR-style task scaling: phát triển biểu đồ scaling liên kết có hệ thống giữa độ khó task và các năng lực cần thiết

  • Các bài toán dài hạn

    • Mở rộng sang Open-play và megabase: nâng độ khó từ lab-play giới hạn lên bản đồ sinh thủ tục, mục tiêu nhiều tầng và megabase với hàng nghìn máy kết nối
    • Hiệu năng thời gian thực dưới ràng buộc độ trễ: hiện thời gian suy nghĩ giữa các hành động là không giới hạn, nhưng benchmark có thể để Factorio tiếp tục chạy nhằm đánh giá cân bằng giữa độ trễ phản hồi và chất lượng lời giải
    • Điều phối multi-agent: xử lý hợp tác, cạnh tranh, emergent market dynamics, phân công lao động, đàm phán phân bổ tài nguyên và hình thành lợi thế so sánh
    • Môi trường ngoài phân phối dựa trên mod: đánh giá liệu mô hình có thể học lại causal structure trong tech tree và cơ chế game mới hay không
    • Giao diện native computer-use: đánh giá tác nhân bằng giao diện bàn phím, chuột và thị giác giống con người thay cho Python API
    • Động lực đối kháng và độ bền vững: đưa hostile aliens và các thách thức môi trường không xác định vào để đánh giá adaptive control và resilience

Cách tham gia

  • FLE có cả mã nguồn lẫn mission đều được mở mã nguồn
  • Những người được cần đến gồm:
    • Nhà nghiên cứu khám phá các kiến trúc mới cho lập kế hoạch dài hạn và suy luận không gian
    • Kỹ sư tối ưu hạ tầng huấn luyện và đánh giá quy mô lớn
    • Modder thiết kế các challenge domain mới
  • Nếu quan tâm tham gia cùng nhóm, bạn có thể tìm họ trên Discord

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-03-12
Ý kiến Hacker News

  • Giờ thì tôi hoàn toàn bị câu rồi và muốn nộp đơn vào phòng thí nghiệm Factorio của Anthropic ngay lập tức
    Chỉ đọc bài báo và bình luận thì tôi không rõ họ có gửi lại dữ liệu đa phương thức hay không, nhưng có lẽ là không vì nhiều mô hình không phải multimodal. Dù vậy một số mô hình có thể làm được, và Qwen 2.5 VLM ra gần đây có vẻ khá mạnh so với kích thước của nó
    Họ nhấn mạnh khá nhiều vào sự thiếu hụt năng lực không gian, đồng thời cũng nói đến khó khăn ở cả lập kế hoạch lẫn quy hoạch không gian, nên tôi tò mò không biết họ có gửi cả hình ảnh như ảnh chụp màn hình hay không. Nếu không thì tôi cũng muốn biết họ nghĩ gì về việc đó
    Nói thêm thì việc kích hoạt thư viện Python qua MCP để cho mọi LLM có khả năng dùng công cụ chơi Factorio có vẻ tự nhiên là việc nhất định phải làm

    • Hiện tại đây là môi trường chỉ văn bản, nhưng có kế hoạch hỗ trợ đầu vào thị giác trong tương lai
      Trong một vài bài test, ngay cả khi đưa thêm ảnh chụp trạng thái trò chơi thì hiệu năng của các mô hình có sẵn cũng không được cải thiện. Khi trạng thái game trở nên phức tạp hơn và số thực thể trong ảnh chụp màn hình tăng lên, mô hình càng bị rối hơn, đồng thời cũng không sửa được các lỗi dễ thấy như ảo giác về hướng hoặc thực thể, hay băng chuyền bị thiếu, hoặc inserter bị xoay sai
      Chúng tôi cho rằng nguyên nhân là VLM hiện nay chưa giỏi suy luận không gian trên các hình ảnh nhiều chi tiết, và fine-tuning có thể sẽ cải thiện đáng kể. MCP cũng đang nổi lên rất nhanh gần đây nên chúng tôi định sẽ xem xét
    • Nếu mô tả văn bản về trạng thái nhà máy dễ diễn giải hơn và ít gây nhầm lẫn hơn, thì tôi không hiểu tại sao lại cần ảnh chụp màn hình
      Vì trò chơi diễn ra trên lưới, có lẽ việc chuyển trạng thái game sang biểu diễn ASCII phải khá đơn giản

  • Cách đây không lâu trên HN có một bài của nhóm huấn luyện tác tử phá đảo Pokémon Red bằng reinforcement learning. Họ nói rằng phải tinh chỉnh hàm chi phí để thưởng nhỏ cho việc khám phá, và thưởng lớn cho các nhiệm vụ bắt buộc như đánh bại gym
    Tôi tự hỏi liệu có thể dùng cùng cách tiếp cận đó cho Factorio không. Nếu ví theo Pokémon Red, thì các nhiệm vụ bắt buộc chính của Factorio là xây tự động hóa cho item mới và gói khoa học mới
    Một hàm thưởng tốt có thể là: thưởng nhỏ cho sản lượng mỗi giây của từng item, thưởng trung bình cho tự động hóa item mới, và thưởng lớn cho tự động hóa gói khoa học mới
    Việc chỉ nói với tác tử Factorio rằng “hãy xây một nhà máy lớn” cũng giống như nói với tác tử Pokémon Red rằng “hãy phá đảo game”, và cần chia nhỏ thành các bước nhỏ hơn cùng hàm thưởng được điều chỉnh hết sức cẩn thận
    Nghĩ đến đây lại làm tôi muốn lao vào dự án này

    • Với tư cách người đã chơi Factorio khoảng 2~3 nghìn giờ, tôi xin bổ sung rằng mục tiêu tạo ra “nhà máy lớn nhất có thể” là quá mơ hồ và không phải thước đo đúng
      Khi người chơi Factorio xây các megabase lớn, họ không nhắm đến kích thước tự thân mà nhắm đến sản lượng nghiên cứu khoa học mỗi phút (SPM). Chỉ số đưa cho tác tử nên là SPM chứ không phải căn cứ “lớn nhất”
    • Trong FLE, có thể truy cập các mốc biểu thị thời điểm một thực thể mới được chế tạo lần đầu, nhưng cách phân tầng phần thưởng theo mức độ tự động hóa cũng sẽ rất thú vị. Sẽ hay nếu cùng thử làm
    • Đây là điểm rất thú vị. Claude trong lab-play có thể làm các nhiệm vụ bắt buộc và tự động hóa đơn giản như nhà máy bánh răng sắt, nhưng trong các episode game “xây nhà máy lớn nhất” thì thậm chí còn không thử
      Các mô hình có thể thực hiện những nhiệm vụ bắt buộc này, nhưng khi nhận mục tiêu chung kiểu “hoàn thành trò chơi”, chúng thiếu mức độ lập kế hoạch dài hạn cần thiết để thực sự thử làm điều đó. Chúng thường không cố mở rộng nhà máy hiện có mà chỉ dựng những cấu trúc nhỏ lẻ không được điều phối
      Một trong các mục tiêu cũng là tìm hiểu mô hình sẽ hành xử thế nào khi nhận mục tiêu mơ hồ và tổng quát
    • Cùng cách tiếp cận đó cũng có thể áp dụng cho cuộc sống
    • Tôi tự hỏi bạn có đọc trang đó không. Trên thực tế họ thưởng cho từng item thực sự được sản xuất ra, và item càng phức tạp thì phần thưởng càng cao

  • Phần nói rằng họ đánh giá sáu mô hình ngôn ngữ frontier trong hai thiết lập là khá thú vị, nhưng cũng có nhiều benchmark động đơn giản hơn nhiều mà vẫn có thể làm bão hòa năng lực lập kế hoạch của các mô hình không suy luận
    Chỉ cần đưa danh sách các chuyến bay nối giữa các thành phố rồi hỏi về hành trình giữa chúng, khi đường đi ngắn nhất giữa hai nút đủ dài thì tất cả các mô hình này đều bắt đầu rối
    Đường đi ngắn nhất dài nhất giữa các thành phố mà mỗi mô hình có thể tìm ổn định với xác suất 8 trên 10 cho từng độ dài là như sau
    | 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 |

    • Đúng vậy. Có những benchmark đơn giản hơn có thể làm bão hòa năng lực lập kế hoạch của các mô hình này
      Tuy vậy, chúng tôi muốn tạo ra một môi trường đánh giá có phổ rộng hơn, có thể kiểm tra nhiều năng lực cùng lúc và vẫn giữ được giá trị trong tương lai

  • Nội dung nói rằng mọi mô hình đều bộc lộ giới hạn quy hoạch không gian khi xây nhà máy nhiều khu là điều hợp lý. Những kiểu thất bại như đặt thực thể quá sát nhau, không chừa chỗ để kết nối, hoặc đặt inserter sai là khá phổ biến
    Tôi hiểu vì sao LLM yếu ở suy luận không gian. Không có nhiều dữ liệu huấn luyện phù hợp cho việc đó. Tôi tò mò nếu suy luận không gian được giải quyết thì sẽ xuất hiện thêm những năng lực suy luận nào

    • Tôi không thực sự hiểu ý nói dữ liệu không gian là không nhiều
      Chỉ cần một trình mô phỏng đơn giản nhất thôi chẳng phải đã có thể tạo ra gần như vô hạn rồi sao?
      Ví dụ, chỉ cần triển khai cờ caro trên lưới vô hạn bằng chừng 10 dòng code là có thể sinh ra tập huấn luyện không giới hạn

  • Tôi muốn thấy thiết kế balancer như một hạng mục khác của bài toán “Lab Play”
    Ngay cả balancer nhỏ cũng có thể khá phức tạp (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9), và sẽ rất thú vị khi xem các mô hình có thể thiết kế và giải quyết vấn đề đó đến đâu

  • Đây là một ý tưởng rất hay
    Có vẻ có rất nhiều thử nghiệm thú vị có thể làm ở đây. Mình nghĩ việc đưa yếu tố thời gian vào các kịch bản lab-play là một ý hay. Hầu hết người chơi Factorio bật biter đều sẽ xem đó là sự kết hợp của các ràng buộc thời gian-không gian, và nếu đặt giới hạn thời gian cho tác tử thì có thể tạo ra một kiểu so sánh đại diện với tình huống trong game thực tế
    Mình thích ở chỗ thiết kế framework này kiểm tra thứ khác với khả năng vi mô hóa điều khiển mà ta từng thấy trong các thí nghiệm DOTA 2 hay StarCraft 2. Đặc biệt ở StarCraft 2, nếu có APM vô hạn thì sẽ xuất hiện kiểu hành vi như vi điều khiển công nhân đến mức cực đoan để khai thác thêm một ít khoáng sản
    Loại hành vi này là một kết quả học thú vị trong bối cảnh hẹp, nhưng trong thực tế thì gánh nặng thao tác rất lớn và ngay cả tuyển thủ chuyên nghiệp cũng dễ mắc lỗi. Ngoài ra, nó dường như cũng không mang lại thêm nhiều hiểu biết về năng lực lập kế hoạch dài hạn, thực thi và phân tích của tác tử
    Theo nghĩa đó, FLE thú vị hơn nhiều như một khung đánh giá tư duy ở cấp độ cao hơn. Mình cũng tò mò liệu có kế hoạch làm benchmark tối ưu bố cục kiểu tối ưu hiệu năng khi một ô nhà máy cho trước có X đầu vào và Y đầu ra hay không

    • Bên mình đang nói tới việc tạo ra một bài toán gần với tower defense hơn, kiểu biter được thả ra mỗi X giai đoạn hoặc X giây
      Mục tiêu là kiểm tra khả năng của tác tử trong việc xây dựng một tổ hợp công nghiệp quân sự. Vấn đề buồn cười nảy sinh khi phát triển ý tưởng này là các mô hình frontier dường như ngại tạo ra các thực thể có tên như GunTurret. Có vẻ như chúng coi đó là vi phạm hiến pháp. Có lẽ phải đổi tên tháp pháo thành kiểu SuperSoaker gì đó
      Còn về benchmark tối ưu bố cục thì đúng là hôm qua bọn mình đã bàn đến. Mình nghĩ cần hai loại bài toán bố cục. 1) sửa một nhà máy bị hỏng nhẹ một cách tinh vi, 2) cải thiện thông lượng của nhà máy này. Việc triển khai có lẽ tương đối dễ, nên rất đáng để thử

  • Tôi không hiểu lắm. Những mô hình này có được hậu huấn luyện để chơi Factorio không?
    A) Nếu có thì với các mô hình không có trọng số công khai như Claude, điều đó được thực hiện như thế nào? B) Nếu không, thì làm sao tác tử biết API làm gì? Dù có thể đoán ý nghĩa tiếng Anh của các lệnh API, ví dụ place_entity_next_to là đặt một thực thể cạnh thứ gì đó, thì làm sao nó biết công thức chế tạo? Nếu là thử rồi học thì lại quay về A
    Đọc PDF thì có vẻ là không có hậu huấn luyện, nhưng nếu vậy thì tôi không rõ các câu hỏi ở B được giải thích như thế nào
    Nếu thật sự không có hậu huấn luyện và việc khám phá công thức chế tạo được trông đợi từ cửa sổ ngữ cảnh, thì tôi thấy nó quá ngắn để có cải thiện kiểu học tăng cường
    Tóm lại, tôi không rõ liệu các mô hình này có thể được kiểm tra bằng hậu huấn luyện hay không, còn nếu làm mà không có hậu huấn luyện thì chúng đã làm tốt đến mức khó tin
    Nếu tác giả có đọc được, tôi tò mò trung bình có bao nhiêu cặp truy vấn API và phản hồi API được đưa vào cửa sổ ngữ cảnh. Và tiếp theo, liệu việc rút gọn tên lời gọi API để nhét được nhiều cặp phản hồi hơn vào một cửa sổ ngữ cảnh có cải thiện kết quả hay không

    • Về công cụ, các tác tử có quyền truy cập vào chữ ký hàm, tức docstring của công cụ, cùng với kiểu đầu vào-đầu ra, và mỗi công cụ cũng có một “sổ tay” nhỏ
      Sổ tay này giải thích công cụ làm gì, nó ảnh hưởng đến trạng thái game ra sao, và một vài ví dụ sử dụng như cách đặt inserter cạnh một chiếc hộp hiện có bằng place_entity_next_to
      Như Jack đã nói, hoàn toàn không có hậu huấn luyện, nhưng mọi tác tử đều có trong ngữ cảnh một mô tả API đầy đủ bao gồm công cụ, thực thể và nghiên cứu. Vì vậy, kết quả này phần nào cho thấy các tác tử hiện đại có thể sử dụng tốt đến mức nào một API hoàn toàn ngoài phân phối nếu có tài liệu phù hợp
    • Những mô hình này không được hậu huấn luyện, tất cả đều là mô hình có sẵn nguyên bản
      Có thể nhét tối đa khoảng 128 cặp vào ngữ cảnh, nhưng vì hiệu năng giống với 32 cặp nên cuối cùng bọn mình chọn 32 cặp do chi phí và độ trễ
      Mã hóa đầu vào-đầu ra ngắn hơn lại làm giảm hiệu năng. Có vẻ với các mô hình đã được tiền huấn luyện, những cái tên có tính mô tả giúp tạo trực giác về chức năng của chúng
    • Nếu đọc chú thích ở phần giới thiệu tác giả thì có vẻ một người làm ở Anthropic. Chắc hẳn đã có quyền truy cập nội bộ

  • Điều thú vị là chỉ có vài kịch bản phức tạp. Tôi luôn nghĩ rằng để tác tử game ML thực sự học được cơ chế game, cần hàng trăm câu đố rất nhỏ, mỗi câu có hàng trăm biến thể
    Ví dụ như: nhà máy không có điện nên đặt cột điện còn thiếu, nhà máy thiếu vật phẩm nên đặt băng chuyền còn thiếu, chế tạo và triển khai 200 máy lắp ráp, máy lắp ráp dừng vì lý do nào đó nên sửa nó, sản lượng nhà máy quá thấp nên tăng gấp đôi, di chuyển nhanh nhất có thể đến một điểm khác trong nhà máy, khắc phục thiếu điện, và tách tất cả các bài toán này theo trường hợp có robot và không có robot
    Sẽ tương đối dễ để tạo bằng chương trình vài nghìn kịch bản ví dụ như vậy. Sau đó có thể dùng chúng như một ngân hàng câu hỏi kiểu bài kiểm tra IQ, rút ra khoảng 12 câu từ ngân hàng và chấm hiệu năng từng câu theo thời gian và vật liệu đã dùng
    Tôi nghĩ tác tử ML nên được đánh giá bằng cách lấy mẫu từ một ngân hàng lớn các kịch bản có độ phức tạp tăng dần mượt mà, và sau khi đạt điểm đủ cao ở mức phức tạp thấp thì sẽ học nhanh hơn khi được đưa các kịch bản phức tạp hơn

    • Tạo kịch bản bằng văn bản như bạn đề xuất thì dễ, nhưng tạo ra trạng thái game nhà máy đúng làm điểm khởi đầu lại khó hơn nhiều
      Theo mình biết thì rốt cuộc nó vẫn quy về cùng một công việc là thiết kế thủ công trạng thái ban đầu và nhiệm vụ cần hoàn thành
    • Bọn mình có nghĩ đến cách tiếp cận curriculum như vậy cho việc huấn luyện bổ sung
      Nhưng công việc hiện tại tập trung vào đánh giá nên đã không làm theo hướng đó. “Độ khó” của các nhiệm vụ khác nhau khá chủ quan, nên sẽ phải đưa ra các quyết định tùy ý có thể ảnh hưởng tới đánh giá. Ví dụ như nhiệm vụ nào nên đến sau kịch bản nào, hay liệu đã bao quát đủ mọi mức độ khó chưa

  • Tôi tò mò liệu có benchmark người chơi cho kiểu giao diện này không. Không phải nói là nó bắt buộc hay liên quan, chỉ là tôi muốn biết kiểu chơi Factorio theo cách lập trình này cảm giác ra sao
    Suy luận không gian thông qua các prompt văn bản có vẻ cũng sẽ khá khó ngay cả với người chơi là con người

    • Benchmark con người trong Factorio là các speedrunner chạy mục tiêu phóng tên lửa đầu tiên
      Kỷ lục hiện tại là hơn 4 giờ một chút cho chơi đơn và 90 phút cho đội nhóm. Chỉ riêng điều này thôi cũng cho thấy LLM đa nhiệm có chỗ để vượt con người

  • Tò mò không biết vài năm nữa liệu mọi đối thủ trong game rồi sẽ là LLM có thể truy cập các API điều khiển game kiểu này hay không
    Cũng tò mò liệu có loại nhiệm vụ nào mà các mô hình đặc biệt gặp khó, hay độ khó chủ yếu tăng theo số lượng vật phẩm cần phải bố trí

    • Khả năng LLM được dùng hàng loạt để đóng vai đối thủ là rất thấp. AI địch trong đa số trò chơi không cần mức độ phức tạp mà học máy đòi hỏi. Bỏ qua chi phí tính toán thì vẫn vậy
      Mục tiêu chính của AI địch không phải là trở thành thứ khó nhất thế giới, mà là tạo ra thử thách thú vị để người chơi có thể vượt qua. Trong đa số trò chơi, làm ra AI siêu mạnh không hẳn là điều khó, nhưng điều đó cũng không khiến nó trở nên vui hơn khi đối đầu
      Phần lớn trò chơi có số trạng thái logic hữu hạn, chỉ là đủ lớn để con người không thể tìm ra hết mọi lời giải. Dĩ nhiên, con người rất giỏi đẩy tới rìa những trạng thái này để tìm ra cách lách luật
      Ngay cả ở những trò chơi có lượng trạng thái lớn hơn nhiều so với bình thường, nhu cầu muốn có siêu AI cũng hiếm. Ví dụ, chẳng ai thích đối đầu với aimbot trong game FPS cả
      Factorio là ngoại lệ so với game thông thường ở chỗ điều kiện “chiến thắng” thực sự gần như hoàn toàn do người chơi quyết định. Trong Factorio không có DLC, bạn có thể chế tạo tên lửa — điều kiện thắng của game — gần như không cần xây nhà máy, ngoài những công trình cơ bản nhất cho các thứ không thể làm bằng tay. Sẽ cực kỳ chậm, nhưng đó vẫn là một lựa chọn khả thi. Vì vậy, với benchmark kiểu này, hiệu quả quan trọng hơn việc nó chỉ đơn thuần “có hoạt động hay không”
    • Tôi nghĩ là có thể. Vì không cần thêm phép tính huấn luyện nào để vận hành nó. Chỉ cần có API là có thể kết nối nhiều mô hình khác nhau vào game mới theo kiểu plug-and-play rất dễ
      Các mô hình chủ yếu gặp khó ở hai mảng lớn. Thứ nhất là suy luận không gian. Chúng thường tạo ra lỗi off-by-one, mà nhà máy thì giống lập trình ở chỗ cực kỳ nhạy với những sai sót như vậy và rất khó khôi phục
      Thứ hai là lập kế hoạch dài hạn. Tức là khả năng xác định về mặt chiến lược cần làm gì trước khi tạo ra các mục tiêu con ở cấp chiến thuật
      Trong lab-play, độ khó thường tỷ lệ với độ sâu của chuỗi sản xuất. Nếu để làm một vật phẩm mà trước đó cần nhiều công đoạn nhà máy khác nhau thì sẽ khó hơn rất nhiều. Điều này có vẻ liên quan đến việc lập kế hoạch, vì các mô hình có xu hướng đào sâu vào chi tiết để sửa các vấn đề nhỏ nhặt thay vì trước tiên lập ra một kế hoạch lớn
    • Nhìn vào “Claude plays Pokémon” thì thấy nó chật vật ở Mount Moon, mà hồi tôi bốn tuổi cũng thế
    • Tại sao phải là LLM? Những việc như thế này chẳng phải AlphaZero làm tốt sao? Ngoài LLM ra còn có rất nhiều mô hình học máy hữu ích khác nữa!