Foundation Models でオセロを作ってみたが、、

これの続き。型安全に構造化したデータを出力できる特徴を活かして何かできないか?と選んだテーマがオセロだったが、結果的にはゲームが成立しなかった。そもそもFoundation Modelsで一番最初に作るモノとしては適切でなかったかもしれない笑

紆余曲折経て、最終的に以下のようなデータモデルになった。

@Generable(description: "Represents the current state of an Othello game.")
struct OthelloGame {
    @Generable(description: "Represents the coordinates of a disc. Expressed as 'x:y' in string format (e.g., a:5).")
    struct DiscCoordinate {
        @Generable(description: "The X coordinate of the disc (a...h).")
        enum XCoordinate: String {
            case a, b, c, d, e, f, g, h
        }
        @Generable(description: "The Y coordinate of the disc (1...8).")
        enum YCoordinate: String {
            case `1`, `2`, `3`, `4`, `5`, `6`, `7`, `8`
        }
        
        @Guide(description: "The X position of the disc.")
        var x: XCoordinate
        @Guide(description: "The Y position of the disc.")
        var y: YCoordinate
    }
    
    @Guide(description: "Coordinates occupied by the white player.")
    var whiteDiscs: [DiscCoordinate] = [.init(.d, .`4`), .init(.e, .`5`)]
    
    @Guide(description: "Coordinates occupied by the black player.")
    var blackDiscs: [DiscCoordinate] = [.init(.e, .`4`), .init(.d, .`5`)]
    
    @Guide(description: "A message shown to the opponent based on the current state of the game when you make a move.")
    var message: String
}

うまくいかなかったというのは具体的には、初期状態の盤からゲームを進めるたびに最新の盤を返すよう instruction に指示していたがそれが不完全だったり、あり得ない場所に石を置いたりするといった感じだ。

ちなみにChatGPTだと次のように、間違うことはあれど一定成立するので、広義にLLMがオセロをできない、というわけではない。

たかだか2時間程度の試行錯誤なので、もっと頑張れば精度上げられたかもしれないが、大前提として以下のような向き不向きがあると思いやめた。

現状の Foundation Models 自体がオセロゲームを正確に扱えない

構造化した出力だけでなく、ChatGPT と同様に自然言語的なやりとりでも試みてみたが、初手から出力精度は ChatGPT 4o にはるかに下がる傾向があり、オンデバイスという特徴であったり、Foundation Models 自体の学習内容からして、オセロ自体に向いていないのではと考えている。

構造化させすぎることでコンテクスト上限を容易に超えてしまう

ゲームの向き不向き以外にも、数ターンでコンテクストの上限を迎える問題があった。検証してはいないのであくまで仮説だが、上述のように @Generable を構造化した分、レスポンスに要するトークンは増大すると推測している(データモデルを表す文字列が長くなるため)。もちろんゲームの特徴上、本来は会話のように過去の履歴を残す必要はなく、最後の盤とターンだけを引き継いだセッションを再生成すれば良いだろうが。


こうしたことからなんとなく掴めたことがふたつある。まずは、Foundation Models の得意分野としては、過度な構造化が不要な自然言語を軸としたユースケースで(素直に)活用するのが良いと思っている。また、構造化するしないを置いておいても、省トークンの工夫として型の命名などに気を付ける必要があるかもしれない。

次に、いきなり @Generable といったデータモデルを設計実装する前に、まず自然言語で対話してみて、ユースケースを満たす性能を有しているか、事前検証してみるのが良いと思った。Playgournd でも良いし、チャットアプリ作ってでも良い。Foundation Models が LLM をアプリに組み込みやすくしてくれているおかげで、チャットレベルであれば30分もかからず実装することができる。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です