Factorio学習環境 – 工場を建設するエージェント

 (jackhopkins.github.io)
1 ポイント 投稿者 GN⁺ 2025-03-12 | 1件のコメント | WhatsAppで共有
  • 工場自動化ゲーム Factorio を使ってエージェントの 長期計画・空間推論 を検証する FLE 0.3.0 が公開され、Claude Code を Factorio に接続したデモも含まれる
  • 新バージョンでは ヘッドレス実行、ピクセル観測レンダラー、OpenAI Gym 互換インターフェース、CLI 評価実行、Weights and Biases のロギングと分析ツールにより、研究実験を容易にする
  • 例示エージェントは電力生産、鉄鉱石採掘、製錬、組立機配置、ベルト接続を反復的にデバッグし、毎分16個の iron gear wheel 生産目標を達成した
  • Lab-play ベンチマークは 2025年9月時点の強力なモデルを対象に Pass@8 を評価し、固体アイテムは 毎分16個、流体は 毎分250個 の生産目標と最大64ステップ制限を設ける
  • フロンティアモデルは v0.2.0 より改善したが、手動運搬、チェストバッファ、API 誤用、動的なゲーム状態の誤認が残っており、Factorio は長期計画と動的復旧能力をあらわにする難しい環境であり続けている

FLE 0.3.0で変わった点

  • FLE 0.3.0 は、Factorio の工場建設タスクで長期計画、推論、ワールドモデリングをテストする学習環境の主要アップデートである
  • 以前の FLE paper では、フロンティアモデルは変化する環境への適応、長期目標設定、動的復旧に困難を示し、0.2.0 ではマルチエージェンシー、バックトラッキングエージェント、ビジョンが導入された
  • 0.3.0 の主な変更点:
    • Claude Code を FLE 経由で Factorio に接続し、Twitch で実演した
    • Factorio ゲームクライアント依存を取り除き、大規模実験が可能な ヘッドレススケーリング をサポートした
    • 新しいヘッドレスゲームレンダラーが、マルチモーダルエージェント研究向けに現実的なピクセル観測を提供する
    • 評価環境を OpenAI Gym インターフェースに合わせ、既存の研究コードベースと統合しやすくなった
    • FLE CLI により 1 行のシェルコマンドで実験を実行でき、評価コードと 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 でインストールし、fle cluster start で Factorio サーバークラスターを起動した後、.env の API キーと設定ファイルで評価を実行する

自動 iron gear wheel 工場の例

  • 例示エージェントは lab-play ワールドで、アイテムインベントリと iron gear wheel 工場の構築目標を与えられた状態から開始する
  • Python で FLE API を呼び出してゲーム環境と相互作用し、各実行結果の標準出力とエラーメッセージを観測する

  • 電力構成

    • nearest(Resource.Water) で水の位置を見つけ、offshore pump を配置する
    • ボイラーと蒸気機関を配置した後、connect_entities でパイプを接続し、ボイラーに coal を入れる
    • 5秒待機後に蒸気機関の energy 値を確認して 電力生成 を検証する

  • 鉄の採掘と製錬

    • iron ore の位置を見つけた後、electric mining drill 2台と electric furnace を配置する
    • 毎分16個の iron gear wheel には毎分32個の iron plate が必要で、electric mining drill は 60秒あたり ore を30個採掘するため、ドリルが 2台必要だと計算する
    • ドリルと電気炉は medium electric pole で蒸気機関の電力網に接続される

  • 組立機の配置

    • 採掘エリアから少なくとも 20 タイル以上離れた場所に AssemblingMachine2 を配置する
    • 組立機のレシピを Prototype.IronGearWheel に設定し、入力・出力 inserter を配置した後、電力網に接続する
    • Assembling machine 2 は 60秒あたり iron gear wheel を90個作れるため、目標スループットには 1 台で十分である

  • ベルト接続とエラー復旧

    • furnace output inserter と assembler input inserter を直接ベルトで接続しようとしたが、storage chest が経路を塞いでいることを発見した
    • 邪魔になっていた wooden chest 2個から iron plate を取り出してチェストを撤去したが、assembler 側の input buffer chest を残したため再びエラーが発生した
    • 最後には assembler input chest まで撤去し、transport belt ベースの物流網を接続して 自動 iron gear wheel システム が目標スループットに到達した

観測空間とエージェントハーネス

  • 各ステップでエージェントは、ゲーム状態を含む構造化された Observation オブジェクトを受け取る
  • 主なフィールド:
    • raw_text: 直前の action program 実行の標準出力とエラーメッセージ、ソースコード行番号
    • entities: ゲーム世界の全エンティティと位置、タイプ、方向、インベントリ、警告などの属性
    • inventory: エージェント個人のインベントリにあるアイテムタイプと数量
    • research: 研究済み技術、現在の研究進行、前提条件とコストを持つ利用可能技術
    • game_info: tick 数、経過時間、ゲーム速度
    • flows: 入出力率、製作アイテム、採取資源、経済評価用の任意価格表
    • messages: マルチエージェント協調のためのエージェント間メッセージ
    • task_info: 目標説明、指示、task identifier、最大 trajectory 長
    • task_verification: 成功・失敗と目標進行のメタデータ
    • serialized_functions: 以前に定義した helper function と抽象化
    • map_image: 視覚エージェント向けの base64 エンコード PNG 工場レイアウト
  • この観測空間は 空間認識、生産指標の追跡、エラーデバッグ、多段階自動化計画を支援する
  • 評価用エージェントハーネスは、これらのフィールドを整形された Markdown 文字列 として連結する

Lab-play ベンチマーク設定

  • Lab-play は、固定された資源と単一の目標エンティティを与え、生産スループットを最大化する制限付き環境である
  • Open-play は手続き生成されたマップで開始インベントリなしに、より希少な資源と複雑な目標を扱う必要があるため、はるかに複雑である
  • 2025年9月時点の強力なモデルを対象に、元の FLE paper の方法論を lab-play 設定に合わせて再現した
  • 標準化されたエージェントハーネスは、単一の会話履歴に環境との相互作用を継続的に追加し、トークン予算が不足すると古い履歴を要約して推論を継続できるようにする
  • FLE 0.2.0 で使われたバックトラッキングや reflection ロジックは評価しない

  • 評価条件

    • 目標: 固体アイテムは毎分16個、流体は毎分250個の生産スループット達成
    • プロンプト: FLE API ドキュメント、Factorio レシピ、一般パターンガイド
    • インベントリ: 機能する工場を作るために有用なアイテムセット
    • 最大ステップ: 64 ステップ、完了時は早期終了
    • 推論: reasoning をサポートするモデルには既定設定 {"enabled": true} を適用

モデル性能と残る限界

  • オープンソースモデルは 2025年5月の v0.2.0 で観測された最新最高性能に追いつき、electronic circuits、steel plate、sulfur、plastic 自動化で成功例が出ている
  • 最新のフロンティアモデルは FLE v0.2.0 と比べて大きく改善し、初めて 12 個を超える ingredient dependency を活用できる、より難しい半数のタスクでも成功した
  • FLE lab-play における高性能モデルの順位と性能差は Claude > GPT > Gemini > Grok に近く、OpenAI の GDPVal と最も類似している
  • Humanity's Last Exam、AIME 25、GPQA、MMMU のような静的な試験型ベンチマークでは、FLE で弱いモデルのほうが高い性能を示す場合もあり、結果は対照的である
  • 成功したエージェントでも、複雑なタスクでは堅牢な自動化ではなく 半手動戦略 にしばしば依存する
    • 資源を直接運ぶ
    • storage chest を資源バッファとして使う
    • 完全自動の物流チェーン構築を迂回する
  • 中間バッファは一時的にスループット検査を満たせるため、測定を難しくする
  • 評価では、エージェントが工場を 60 秒間そのまま動かす holdout period の後に割り当て量を満たすかを検査し、この問題を緩和する
  • より高いスループット目標を与えると手動物流では通過しにくくなり、適切な自動化を要求できる

エラー種別とモデルごとの差異

  • フロンティアモデルは、エラーが蓄積したときにそれを復旧することに引き続き苦労している
  • 平均エラー率比較: {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 は構文エラーが 0 で、エラーの 97.7% が実用エラーに近く、コード生成は強いがゲーム状態の正確な mental model を維持することに苦労している
    • Gemini 2.5 Pro、Grok 4、GPT-5 は 12〜17% 水準の API 理解エラーを示し、FLE API ドキュメントを正確に使うことに苦労している
    • GPT-5 と Grok 4 はそれぞれ 21%、17% の構文エラーを示し、最新最高性能の coding benchmark モデルにしては有効な Python 生成の失敗が頻繁に見られる
    • Gemini 2.5 Pro だけが、現在 helper function と抽象化を定義して使うアプローチを示している

Claude Code と MCP

  • v0.2.0 では、外部エージェントが FLE と相互作用できるよう MCP server が公開された
  • v0.3.0 では、これを拡張して Claude Code adapter を含めた
  • Factorio をプレイする Claude Code の配信は Twitch で確認できる

今後の研究方向

  • 現在のフロンティアモデルは、人間基準では Factorio がまだかなり不得手で、動的環境表現とモデリング、将来のツールとして使える formal abstraction の開発に苦労している
  • それでも 2025 年を通じて、lab-play におけるフロンティアモデルの能力は着実に改善している
  • Factorio は、長期計画、ドメイン適応、ワールドモデリング、空間推論のような一般モデル能力を明らかにする環境として引き続き活用できる
  • FLE v0.3.0 は lab-play を最初の formal benchmark として確立するが、研究計画の出発点にあたる

  • 近い課題

    • 人間ベースライン: タスク難易度ごとの人間性能を体系的に測定し、エージェント能力を補正する
    • Reward hacking への対応: エージェントが複雑なアイテムで適切な自動化の代わりに manual crafting を使う問題に対処する
    • METR-style task scaling: タスク難易度と必要能力を体系的に結び付ける scaling chart を開発する

  • 長期課題

    • Open-play と megabase 拡張: 制限された lab-play から、手続き生成マップ、多段階目標、数千台の接続機械を持つ megabase まで難易度を拡張する
    • 遅延制約下でのリアルタイム性能: 現在は行動間の思考時間が無制限だが、Factorio が動き続けるベンチマークで応答遅延と解法品質のバランスを評価する
    • マルチエージェント協調: 協力、競争、emergent market dynamics、分業、資源配分交渉、比較優位の形成を扱う
    • Mod ベースの分布外環境: 新しい tech tree とゲームメカニクスで causal structure を再学習できるかを評価する
    • Native computer-use interface: Python API ではなく、人間と同じキーボード・マウス・ビジョンインターフェースでエージェントを評価する
    • 敵対的ダイナミクスと頑健性: hostile aliens と非決定的な環境課題を導入し、adaptive control と resilience を評価する

参加方法

  • FLE はコードもミッションもオープンソースである
  • 必要とされる参加者は次のとおり:
    • 長期計画と空間推論のための新しいアーキテクチャを探究する 研究者
    • 大規模評価と訓練インフラを最適化する エンジニア
    • 新しい challenge domain を設計する Modder
  • チーム参加に関心があれば Discord で見つけられる

関連記事

1件のコメント

 
GN⁺ 2025-03-12
Hacker Newsの意見

  • もう完全に釣られてしまって、AnthropicのFactorio研究所に今すぐ応募したくなった
    論文やコメントを見ただけではマルチモーダルデータを送り返しているのか分からないけど、複数のモデルはマルチモーダルではないので、おそらく違うのだろう。ただ一部は可能だし、最近出たQwen 2.5 VLMはサイズの割にかなり強そうに見える
    空間能力の不足をかなり強調していて、計画と空間計画の両方の難しさにも触れていたけど、スクリーンショットのような画像も送っているのか気になる。そうでないなら、それについての考えも気になる
    ついでに言うと、MCPでPythonライブラリを有効にして、ツール利用可能なすべてのLLMにFactorioをプレイさせるのは、自然に必ずやるべきことのように見える

    • 現在はテキスト専用環境だが、今後は視覚入力をサポートする予定
      いくつかのテストでは、ゲーム状態のスクリーンショットを含めても既製モデルの性能は向上しなかった。ゲーム状態が複雑になり、スクリーンショット内のエンティティが増えるほどモデルはさらに混乱し、方向やエンティティを幻覚したり、欠けている輸送ベルトや誤って回転したインサータのような目立つミスも修正できなかった
      現在のVLMは細部の多い画像で空間推論が苦手なためだと見ており、ファインチューニングすれば大きく改善する可能性がある。MCPも最近急浮上しているので調べる予定
    • 工場状態のテキスト説明が解釈しやすく混乱も少ないなら、なぜスクリーンショットが必要なのか分からない
      ゲームは格子上で進行するので、ゲーム状態をASCII表現に変えるのは簡単なはず

  • 少し前にHNで、強化学習でPokémon Redをクリアするエージェントを学習させたチームの記事があった。彼らは探索には小さな報酬を、ジム攻略のような必須タスクには大きな報酬を与えるようにコスト関数を調整する必要があったと言っていた
    Factorioにも同じアプローチを使えるのか気になる。Pokémon Redの比喩で言えば、Factorioの主な必須タスクは新しいアイテムと新しいサイエンスパックの自動化を構築すること
    各アイテムの秒間生産量には小さな報酬、新アイテムの自動化には中程度の報酬、新しいサイエンスパックの自動化には大きな報酬を与える、という形なら良い報酬関数になり得る
    Factorioエージェントにただ「大きな工場を作れ」と言うのは、Pokémon Redエージェントに「ゲームをクリアしろ」と言うのと同じで、より小さなステップと非常に慎重に調整された報酬関数に分ける必要がある
    これを考えていたら、このプロジェクトに飛び込みたくなってきた

    • Factorioを2〜3千時間やった立場から付け加えると、「可能な限り最大の工場」を作るという目標は曖昧すぎるし、正しい指標ではない
      Factorioプレイヤーが大型メガベースを作るときは、サイズそのものではなく**分あたりのサイエンス研究量（SPM）**を目標にする。エージェントに与える指標は「最大」の基地ではなくSPMであるべき
    • FLEでは新しいエンティティが初めて作られた時点を示すマイルストーンにアクセスできるが、自動化レベルごとに報酬を階層化する方式も本当に興味深いはず。一緒にやってみたい
    • 興味深い部分だ。Claudeはlab-playで鉄の歯車工場のような必須タスクと単純な自動化はできたが、「最大の工場を作る」ゲームエピソードでは試みることすらしなかった
      モデルはこうした必須タスクを実行することはできるが、「ゲームを完了せよ」のような一般的な目標を与えられると、それを試みるだけの長期計画レベルが足りない。既存の工場を拡張しようとせず、調整されていない小規模な構造物だけを作ることが多かった
      曖昧で一般的な目標を与えたときにモデルがどう行動するかを知ることも、目標の一つだった
    • 同じアプローチは人生にも使える
    • ページを読んだのか気になる。実際に生産されたアイテムごとに報酬を与え、より複雑なアイテムにはより高い報酬を与えていた

  • 6つのフロンティア言語モデルを2つの設定で評価したという部分は興味深いが、非推論モデルの計画能力を飽和させられる、はるかに単純な動的ベンチマークもたくさんある
    都市間の航空便接続リストを与えて、その間の旅程を尋ねる程度でも、2ノード間の最短経路が十分に長くなると、これらのモデルはすべて混乱する
    各長さについて10回中8回安定して見つけられた都市間の最長最短経路は次のとおりだった
    | 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 |

    • その通り。こうしたモデルの計画能力を飽和させる、もっと単純なベンチマークがある
      ただし私たちは、複数の能力を同時にテストし、今後も有効であり続けられる、より広いスペクトラムの評価環境を作りたかった

  • 複数区画からなる工場を作るとき、すべてのモデルが空間計画の限界を示したという内容は納得できる。エンティティを近すぎる位置に置く、接続用のスペースを確保しない、インサータを間違って配置する、といった失敗が一般的ということだ
    LLMが空間推論に弱い理由は理解できる。それに合った学習データが多くないからだ。空間推論が解決されたら、どんな追加の推論能力が現れるのか気になる

    • 空間データが多くないというのがよく分からない
      最も単純なシミュレータさえあれば、事実上無限に作れるのでは？
      例えば無限グリッド上の三目並べを10行程度のコードで実装するだけでも、無制限の学習セットを生成できる

  • 「Lab Play」課題の別カテゴリとして、バランサー設計を見てみたい
    小さなバランサーでもかなり複雑になり得るし（https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9）、モデルがそれを設計し、問題を解く能力を見るのは興味深いはず

  • 素晴らしいアイデアだと思う
    ここで試せる興味深い実験がたくさんありそう。lab-playシナリオに時間に関する要素を入れるのは良い考えだと思う。バイターを有効にしてプレイするFactorioユーザーの多くは、これを時間・空間制約の組み合わせとして扱うだろうし、エージェントに制限時間を設ければ、実際のゲーム状況との一種の代理比較が可能になる
    このフレームワーク設計が、DOTA 2やStarCraft 2の実験で見たようなマイクロ管理能力とは違うものをテストしている点が良い。特にStarCraft 2では、無限のAPMがあるとワーカーを極端に細かく操作して、鉱物を少し多く採るような行動が出てくる
    こうした行動は狭い文脈では興味深い学習結果だが、実際には操作負荷が大きく、プロ選手でもミスする可能性が高い。また、エージェントの長期計画、実行、分析性能について追加の洞察を与えるようにも思えない
    その点でFLEは、より高いレベルの思考評価フレームワークとしてずっと興味深い。与えられた工場セルにX個の入力とY個の出力があるとき、性能を最適化するようなレイアウト最適化ベンチマークの計画があるのかも気になる

    • バイターがX段階ごと、またはX秒ごとに解放されるような、もう少しタワーディフェンスに近い課題を作る話をしている
      目的は、エージェントが軍需産業複合体を作る能力をテストすること。このアイデアを開発していて面白かった問題は、フロンティアモデルが「GunTurret」のような名前のエンティティを作るのを嫌がる点だった。憲法に反すると見なしているようだ。おそらくタレットの名前を「SuperSoaker」のようなものに変えないといけないかもしれない
      レイアウト最適化ベンチマークについては、実は昨日議論した。2種類のレイアウト課題が必要だと思う。1) 微妙に壊れた工場を直す、2) この工場のスループットを改善する。実装は比較的簡単なはずなので、一度見てみると良さそう

  • よく理解できない。これらのモデルはFactorioをプレイするように事後学習されたのか？
    A) そうだとすると、Claudeのように公開重みのないモデルではどうやって可能なのか？ B) そうでないなら、エージェントはAPIが何をするのかをどうやって知るのか？APIコマンドの英語の意味、たとえば place_entity_next_to が何かの隣にエンティティを置く、というように推測するとしても、レシピはどうやって知るのか？試行して学習するなら、またAに戻る
    PDFを読んでみると事後学習はしていないようだが、だとするとBの疑問がどう説明されるのかわからない
    本当に事後学習がなく、レシピ探索をコンテキストウィンドウ内で期待していたのだとしたら、強化学習的な改善には短すぎると思う
    要するに、事後学習でこれらのモデルをテストできたのかがわからないし、事後学習なしでやったのなら、どれも信じがたいほどよくできている
    著者が見ているなら、平均してコンテキストウィンドウにAPIクエリとAPI応答のペアがいくつ入るのか知りたい。続けて、API呼び出し名を短縮して1つのコンテキストウィンドウにより多くの応答ペアを入れると、結果が良くなるのかも気になる

    • ツールに関しては、エージェントは関数シグネチャ、つまりツールのdocstring、入力・出力型にアクセスでき、各ツールごとに小さな「マニュアル」もあった
      このマニュアルは、ツールが何をするのか、ゲーム状態にどんな影響を与えるのか、そして place_entity_next_to で既存の箱の隣にインサータを置く方法のような、いくつかの使用例を説明していた
      Jackが言ったように事後学習はまったくなかったが、すべてのエージェントはツール、エンティティ、研究を含む完全なAPI説明をコンテキストに持っていた。したがってこの結果は、現代のエージェントが、適切なドキュメントのある完全に分布外のAPIをどれだけうまく使えるかをある程度示している
    • これらのモデルは事後学習されておらず、すべて既製モデルそのままだった
      コンテキストには最大で約128ペアを入れられるが、32ペアと性能が同じだったため、コストとレイテンシのため最終的に32ペアを選んだ
      入出力をより短くエンコードすると性能は下がった。事前学習モデルには、説明的な名前が何をするものかについて直感を与えるため、役に立つようだ
    • 著者紹介の脚注を読むと、1人はAnthropicで働いているようだ。内部アクセスがあったのだと思う

  • 複雑なシナリオが数個しかないという点が興味深い。MLゲームエージェントがゲームメカニクスをきちんと学ぶには、それぞれに数百種類のバリエーションがある、ごく小さなパズルが何百個も必要だとずっと思っていた
    たとえばこういうものだ。工場に電力がないので不足している電柱を置く、工場にアイテムが足りないので不足しているベルトを置く、組立機200台を製作して配置する、組立機が何らかの理由で止まっているので直す、工場の生産量が低すぎるので2倍にする、工場内の別の地点までできるだけ速く移動する、電力不足を直す、そしてこれらすべての課題をロボットがいる場合といない場合に分ける
    こうした例示シナリオを数千個、プログラムで生成するのは比較的簡単なはずだ。それからIQテストの問題バンクのように使って、問題バンクから12個程度を選び、時間と使用した材料を基準にそれぞれの性能を評価すればよい
    MLエージェントは、複雑度が滑らかに増していく大きなシナリオバンクから標本抽出されて評価され、低い複雑度で十分に高いスコアを得た後に、より複雑なシナリオが提示されると、より速く学ぶのだと思う

    • 提案のようにシナリオをテキストで生成するのは簡単だが、出発点となる正しい工場のゲーム状態を作るのははるかに難しい
      知る限り、結局は初期状態と完了すべき課題を手作業で設計するのと同じ作業に行き着く
    • 追加学習にはこのようなカリキュラムアプローチを考えている
      ただし現在の作業は評価に焦点を当てていたため、こうはしなかった。異なる課題の「難易度」はかなり主観的で、評価に影響しうる任意の決定をしなければならないからだ。たとえば、どの課題がどのシナリオの後に来るべきか、すべての難易度レベルを十分に網羅しているか、といった問題がある

  • このようなインターフェース方式についての人間プレイのベンチマークがあるのか気になる。必ず必要だとか関連があるという意味ではなく、プログラミング方式のFactorioがどんな感じなのか気になる
    テキストプロンプト周りで空間推論をするのは、人間プレイヤーにとってもかなり難しそうだ

    • Factorioの人間ベンチマークは、初のロケット打ち上げを目指して走るスピードランナーたちだ
      現在の記録はソロプレイで4時間少し超、チームでは90分。これだけ見ても、マルチタスクLLMが人間を上回る余地があることがわかる

  • 数年後には、ゲーム内のすべての対戦相手が、こうしたゲーム制御APIにアクセスできるLLMになっているのかも気になる
    モデルが特に苦手とする課題の種類があったのか、それとも難易度は主に配置すべきアイテム数に応じて上がるのかも気になる

    • LLMが対戦相手役として大量に使われる可能性は非常に低い。ほとんどのゲームの敵AIには、機械学習が要求するほどの複雑さは必要ない。計算コストはいったん脇に置いてもそうだ
      敵AIの主な目的は世界で最も手強い存在になることではなく、プレイヤーが乗り越えるに値する面白い挑戦を提供することだ。多くのゲームで超高性能AIを作ること自体が必ずしも難しいわけではないが、だからといって相手にして楽しくなるわけでもない
      ほとんどのゲームは有限の論理状態を持っていて、それが人間がすべての解法を見つけるには十分大きいだけだ。もちろん人間は、こうした状態の端を押し広げて迂回策を見つけるのが非常に得意だ
      状態量が通常よりはるかに大きいゲームでも、スーパーAIが求められることはまれだ。たとえばFPSでエイムボットを相手にしたい人はいない
      Factorioは通常のゲームと違い、「勝利」の本当の条件がほぼ完全にプレイヤー次第である点で例外だ。DLCなしのFactorioでは、ゲームの勝利条件であるロケットを、手作業では作れないもののためのごく基本的な構造物以外にはほとんど工場を作らなくても製作できる。ものすごく遅いだろうが、可能な選択肢だ。だからこの種のベンチマークでは、「動くか」よりも効率のほうが重要になる
    • 可能だと思う。動かすのに別途学習の計算が必要ないからだ。APIさえ提供されれば、新しいゲームにさまざまなモデルをプラグアンドプレイで接続するのは非常に簡単だ
      モデルは大きく2つの領域で苦戦する。第一に空間推論だ。モデルはしばしばoff-by-oneエラーを起こし、工場はプログラミングと同じくこうしたミスに非常に敏感で、復旧が難しい
      第二に長期計画だ。戦術的な下位目標を作る前に、戦略的に何をすべきかを把握する能力である
      lab-playでは、難易度は通常、生産チェーンの深さに比例する。あるアイテムを作るために先に複数の工場区画が必要になると、ずっと難しくなる。これは計画に関係しているように見える。モデルはまず大きな計画を立てるよりも、些細な問題を直す細部に入り込む傾向があるからだ
    • 「Claude plays Pokémon」を見ると、おつきみやまで苦戦しているが、4歳のときの私もそうだった
    • なぜLLMである必要があるのか？ こういうのはAlphaZeroが得意なのでは？ 有用な機械学習モデルはLLM以外にもはるかに多い！