週末にかけて体調を崩していたのもあり、あまりハッキリとした進捗はない。
MineRL
画像サイズを256x256 → 128x128にした
前回は、256x256サイズで35000ステップほど進むと損失が急に落ちて、なんとなく気配は感じられる画像が出てくることがわかった。しかし、手元の計算資源だとそこまでに12時間ほどかかってしまうため、いろいろな試行錯誤を回すには時間がかかりすぎてしまう。
よって128x128サイズで学習を行うようにした。バッチサイズを上げられる(計算通り4倍にできた)ことでの高速化がメインだと考えていたが、問題が簡単になることにより学習が速くなるという効果もあるようだった。学習結果は以下の通り。
バッチサイズ4倍がそのままステップ数に効くとすると8000ステップくらいで下がる想定だったが、それよりも早いタイミングで損失が落ちている。
生成結果は以下の通り。左上から0フレーム目で、右および下に行くとフレームが進んでいる。
GT | 予測 |
---|---|
やはり一番画面の切り替えが大きく出るのはinventoryを開いた/閉じたときだが、そのタイミングが合っているわけではないので、行動に基づく変化を学習できているわけではなさそう。
行動としてinventoryボタンだけを入力して学習
生成結果を見てわかった通り、まだ行動を上手く考慮に入れられていないと思われる。今は移動やカメラ操作や各種行動など、取れる行動をすべて入力しているが、今回はとりあえずinventoryボタンの行動だけを入力とするように変更した。
結果としてはこれでもダメだった。
GT | 予測 |
---|---|
今は行動の入力をかなり適当にニューラルネットワークに入れているが、もう少しちゃんと工夫しないといけないのかもしれない。
調査
拡散モデルに対して条件付けをしたい場合の入力の入れ方について調べる。
単純なものであれば、時刻に対して加算するという方法がまず挙がるらしい。しかし、今回は条件となる情報が「過去数フレームの画像 + 行動」なのでかなり量が多いと感じており、それを時刻と同じ次元の一つのものにまで圧縮して渡すことが良いのかわかっていない。とはいえ次回はそのように圧縮する方法も試してみる。(TODO1)
やりたいこととしては動画生成に若干近いところがあるので、ちょうどこの前でたMetaのMovie Genについても参考にできるところがないか調べる。
主に動画生成部分の説明をパッと見たところ、temporal autoencoderというものを使って時系列フレームも1/8に圧縮した空間で生成モデルを学習あせるらしい。学習にはFlow Matchingを使っている。アーキテクチャ的にはContextはCrossAttentionで入れる。
やはりものすごい工夫があるとはあまり思えていない。単純にプログラムをバグらせていないかとか、学習時間とかそういう方向を考えた方が良いかもしれない。