第36回世界コンピュータ将棋選手権　感想戦

はじめに

まずはじめに、本大会の運営に携わった皆様、対局いただいた皆様、本当にお疲れさまでした。 そして素晴らしい大会を開催していただき、ありがとうございました。

おかげさまで、「氷彗」は第36回世界コンピュータ将棋選手権で優勝することができました。

正直なところ、今回はそこまで「優勝を狙うぞ」という感じで出場したわけではありませんでした。 自分はこれまで選手権で二次予選を突破したことがなく、コンピュータ将棋を長くやってきた中で、それだけがずっと心残りになっていました。 決勝は会場に行かなくてはならず、そのハードルが高かったため、二次予選突破したら辞退しようかと思っていました。

そのため、電竜戦が終わってからは、選手権向けに短期的な調整をするというより、中長期的にソフトを強くする方向を優先していました。 実際、電竜戦以降そこまで大きく強くなったわけではありません。それでも今回優勝することができ、かなりうれしく思っています。

有効だったこと

コーディングエージェントの活用

今回かなり大きかったのが、コーディングエージェントの活用でした。

大会前の修正の多くは、コーディングエージェントを使って短時間で実装しています。 単純な実装補助だけではなく、将棋プログラム自体の改善案や実装もいくつか行ってもらいました。

特に大きかったのは、「Stockfishとの差分を極力減らす」という考え方をやめられたことかなと思っています。

これまでは、

  • upstream に追従しやすくする
  • 差分管理を楽にする
  • 大規模変更時のマージを簡単にする

といった理由から、かなり Stockfish 互換を意識していました。差分が大きくなればなるほど追従コストもかなり大きくなります。 ですが最近は、コーディングエージェントによってそのあたりのコストをかなり下げられるようになってきました。

その結果、 「Stockfish と違うからやめておこう」 という判断をしなくてよくなったのは大きかったと思っています。

今後は、Stockfish互換性をそれほど意識しない方向になるかもしれません。

nnue-pytorch の高速化

最近は bullet-shogi を使って学習するチームもかなり増えてきているようです。 github.com

一方で自分は引き続き nnue-pytorch を使っているのですが、以前から不満だったのが GPU 使用率でした。

学習中、GPU 使用率が30%程度しか出ておらず、かなり効率が悪い状態になっていました。 そこで学習部分を見直し、GPU をほぼフルに使えるように修正しました。 これによって学習速度がかなり改善し、実験サイクルを高速に回せるようになりました。

体感では、学習時間は以前の1/3程度になっていると思います。 現状では bullet-shogi と比較してもかなり近い速度が出ています。

この高速化によって、今まで重くて試せていなかった実験にも手を出せるようになりました。 実際、選手権後に試した実験だけでも、すでにレートが70程度向上しています。 こんなに伸びそうならば、もっと早く取り組んでおけばよかったかなと思っています。

自動対局システム

大会期間中、常にPCの前に張り付くことが難しかったため、USIエンジンをCSAサーバーへ接続する自動対局システムを構築しました。 前回の電竜戦で不戦敗となった対局があったので、ネットワーク監視やエンジンプロセス監視を強化したいと思っていました。 実装はGolangで行い、主に以下の機能を持っています。

  • ネットワーク切断時の自動再接続
  • エンジン異常終了時の自動復旧
  • 連続対局

将棋AIそのものとは直接関係ありませんが、大会運用面ではかなり重要だったと思っています。 特に長時間大会では、「安定して動き続けること」の価値はかなり大きいです。

時間制御の修正

電竜戦は比較的短時間なので、これまでは時間制御をそれほど重視していませんでした。 一方で選手権は持ち時間が長めなので、時間の使い方によるレーティング差はかなり大きいと感じています。 そのため今回、時間制御周りにもある程度手を入れました。

本当は SPSA でしっかり最適化したかったのですが、そこまでは間に合いませんでした。 それでも以前よりはかなり改善できたかなと思っています。

長時間対局では、

  • どこで時間を使うか
  • どこで節約するか
  • 評価値が揺れている局面でどう粘るか

といった部分の積み重ねがかなり効いてくる印象があります。 このあたりはまだ改善余地が大きそうです。

有効ではなかったこと

dlshogi 60ブロックモデルでの revalue

電竜戦後、dlshogi の60ブロックモデルを使った revalue を試していました。 ただ結果としては、あまりうまくいきませんでした。

おそらく値が正常についていない局面があり、かなり不自然な挙動をしていました。 まだ原因を追い切れていないため、今後もう少し調査したいと思っています。

利き特徴量を考慮した新特徴量

Stockfish では full_threats 特徴量など、新しい特徴量が少しずつ導入されています。 NNUE系はかなり成熟してきていますが、長期的には特徴量を更新していかないと頭打ちになると思っています。

将棋では実績のある利き情報を考慮した新特徴量を試していましたが、現状ではあまり良い結果にはなりませんでした。 ただ、nnue-pytorch の高速化によって実験速度はかなり改善したので、今後も継続して試していきたいところです。

HalfKAv2_hm 特徴量

HalfKAv2_hm も試していました。 結果としては、ほんの少し弱くなる程度でした。

ただ、L1層を伸ばせそうな感触自体はあるので、完全に諦めたわけではありません。 こちらももう少し別方向から試してみたいと思っています。

今後

LayerStack

今回、いくつかのチームが進行度ベースで LayerStack を切り替えていました。 自分も「現状の構成が最適ではないだろうな」と思いつつ、長らく放置していた部分になります。

ただ、選手権後の実験で、進行度とは別の切り分けによって、20〜30程度レートが伸びそうなものが見つかっています。 進行度ベースも含め、どの切り方が良いのか今後探していきたいと思っています。

学習方法

nnue-pytorch を高速化できたので、学習周りについては今後さらに進めていきたいと思っています。 なお、現時点では bullet-shogi に乗り換える予定はありません。

理由としては、

  • PyTorch ecosystem の自由度が高い
  • 実験しやすい
  • 小回りが利く という点が大きいです。

また、Stockfish側も現状 nnue-pytorch を捨てていないため、しばらくはこちらを使っていく予定です。

ネットワーク構成

これまでは「Stockfish互換」をかなり意識していたため、効果が薄くても残している構成がいくつかありました。 ただ、コーディングエージェントによって実装コストがかなり下がったので、この辺りも今後はもっと自由に変えていきたいと思っています。 そろそろ、「互換性のためだけに残しているもの」は見直していく時期なのかなと思っています。

特徴量

長期的にさらに壁を突破するには、やはり特徴量の進化は必要だと思っています。 最近のNNUEはかなり成熟しているとはいえ、まだ改善余地はあるはずです。 今回うまくいかなかった実験も含め、今後も継続して試していきたいと思っています。

第6回電竜戦感想戦

はじめに

まずはじめに、本大会の運営に携わった皆様、対局いただいた皆様、本当にお疲れさまでした。 そして、素晴らしい大会を開催していただきありがとうございます。

おかげさまで、「氷彗」は 文部科学大臣杯第6回世界将棋AI電竜戦本戦 で優勝することができました。

1年前のバージョンと比較して、レーティングはおよそ 186 向上しました。 この1年間、試行錯誤を繰り返してきましたが、ここではその中で「うまくいったこと」「うまくいかなかったこと」、そして今後の展望について技術的な視点から振り返ってみたいと思います。

うまくいったこと

この1年で成果につながった主な取り組みは以下の4点です。

dlshogi からの知識蒸留

これは昨年の電竜戦後に nodchipさんが提唱された手法 です。

Stockfish界隈では、Leela Chess Zeroのデータを用いて学習を行っているようです（参考）。 以前、将棋でもdlshogiのデータで学習したことがあったのですが、その時はまったく強くなりませんでした。 しかし、nodchipさんの手法を取り入れたところ、レーティングが約 40 向上しました。nodchipさんすごい。

現在の氷彗は、dlshogiの 50ブロックモデル で点数を付け直したものから学習しました。 点数の付け直しに時間がかかることから、どのモデルがよいか等の比較実験はできていません。単純に「大きなモデルがより良い成果につながる」と信じて採用しています。

L1 層を増やす

一般的にNNUEではモデルサイズを大きくする方が強くなる傾向（スケーリング則）がありますが、知識蒸留を行う前は頭打ち感があり、サイズを増やしても強くなりませんでした。

しかし、前述の知識蒸留データを用いることで、モデルサイズの上限をさらに引き上げることが可能になりました。 今回の電竜戦バージョンでは、L1 サイズを 2304 まで拡張しています。

やねうら王 v9 ベースで作り直し

これまでは、やねうら王からフォークし、独自の修正を重ねて開発を行っていました。 しかし、最新の「やねうら王 v9」ベースと、私の独自修正版を比較したところ、強さはほぼ互角でした。

そこで、以下の理由からベースをv9に移行し、作り直すことにしました。

  • 独自修正による伸び代: 今までの独自の修正を移植すれば、より強くなりそう。
  • チェス由来の機能: v9には pawn history など、チェスのゲーム性に依存した機能が含まれており、これらを将棋向けに変えることで、さらなる強化が見込めそう。
  • SPSAによるチューニング: パラメータ調整を行えば強くなりそう。

SPSA によるチューニング

Stockfishでは、NNUEモデルが変わると SPSA によるパラメータチューニングを行っています。 将棋でも同様に、評価関数モデルの変化に合わせてパラメータを再調整した方が良いはずです。

また、Kaggleの チェスコンペ に参加した際、QhapaqさんがSPSAでチューニングし、レーティングを向上させていました。 その経験から、SPSAでパラメーターをチューニングすることはかなり重要なのではないかと感じていました。

何度かに分けて行っているため、これ単体でどれくらい上昇したかは正確には分かりませんが、トータルで レーティング 40 程度の向上 くらいだと思います。

うまくいかなかったこと

一方で、試してみたものの成果が出なかった取り組みも多くあります。

Dual Network

Stockfishでは、 big net と small net の2つのネットワークを切り替えて使っています。 将棋の終盤においても、読みの速さが重要視され、より深く読める方が詰みを見つけやすく正確な評価が期待できる一方、複雑な局面は小さなネットワークでは正確に評価できないというトレードオフがあります。

今回は 128-15-64 の小さなネットワークを学習させ、いろいろと試しましたが、結果として弱くなる結果となったため、今回はボツになりました。

L1 層を増やす（2304以上）

うまくいった項目で「2304まで増やした」と書きましたが、それ以上に増やそうと試みたところ、逆に弱くなる結果となりました。現在のデータや構造ではこのあたりが限界のようです。

Pawn History 等チェス固有修正の削除

やねうら王 v9 に含まれる pawn history などのチェス由来の修正を無効にしてみましたが、結果は弱くなりました。 将棋においてなぜこれらが有効に働くのか理解できませんが、現状では残す方が強いようです。

以前の探索で効果のあった修正の適用

Killer Move は、現在のやねうら王v9（およびStockfish）では削除されています。以前の実験では「Killer Moveを削除した方が弱くなる」という結果だったため、将棋では消せないと思っていました。しかし、v9ベースで再適用しても弱くなってしまいました。 他にもいくつか修正を入れたのですが、どれもうまくいきませんでした。

学習データの選別（Best Moveが取る手の除外）

現在、氷彗では、山岡さんが提唱されている 「qsearch（静止探索）で動く局面を学習から除外する」という手法 を採用しています。これは随分前に導入しそのままになっています。

以前、Stockfishの「Best Move（最善手）が駒を取る手、または王手となる局面」も学習データから除外する実験を行いましたが、その時は強さに差がありませんでした。

Stockfishでは以前から学習データの選別に様々な工夫が凝らされており、私も基本的には「NNUEの学習に適していない局面は除外した方がよい」という考えを持っています。そこで、dlshogiのPolicyにおいて最善手が「駒を取る手」に該当する局面を弾く処理を試みたのですが、結果としてはうまくいきませんでした。

  • 時間切れ: 本格的な検証を行う時間が足りず、大会に間に合いませんでした。
  • 効果の限定性: 少し実験した限りでは、これを行っても強さは変わらなさそうな感触でした。

今後

今後の開発で考えているアイデアです。

Full Threats

StockfishのNNUEがv10になり、full threats という特徴量が追加されました。 スケーリング則が崩れている以上、将棋でも試す価値はあると考えています。ただ、個人的にはこの特徴が将棋で有効そうには思えません。

方向性としては、昔の「技巧」のように「利きの特徴」を追加するような方向を考えています。利きの特徴量追加は技巧やdlshogiでうまくいっています。ただ halfkpe9 のような追加だとサイズが増えすぎるので、別のやり方がよいと思っています。

halfka_v2_hm

Stockfishでは、単純なhalfkaではなく、モデルサイズを小さくする工夫が入っています。 L1スケーリング則が効かなくなった理由として、サイズが大きくなりすぎているのも一因としてあるのかなと思ったので、こちらも試してみたいところです。

nnue-pytorch の改善

現状、学習に1ヶ月くらい時間がかかっており、ここがボトルネックになっています。 Chess界隈ではRust製の bullet というツールがあり学習が早いらしいですが、Stockfishは使っていなさそうです。 私の環境はnodchipさんの将棋対応ブランチから派生しており、pytorch-lightningも昔のバージョンのままです。今まで面倒で取り組んでいませんでしたが、そろそろここもなんとかしないといけないかなと思っています。

学習データの刷新

以前、L1層のスケーリング則が効かなくなったときは学習データを改善することで強くなりました。 1年以上学習データを作っていないので、そろそろ作り直す時期かもしれないと感じています。

dlshogiの60ブロックモデルで評価値の付け直し

知識蒸留をdlshogiの 60ブロックモデル から行えば、もしかすると強くなるかもと思っています。 50ブロックでもものすごく時間がかかるので、全部ではなく一部のデータのみでもやってみようかなと思っています。

将棋特有の探索

やねうら王 v9 は Stockfish から結構そのまま持ってきています。 今までの実験では将棋用に変えても強くならなかったのですが、SPSAを含めていろいろやると、変えた方がよいのではと思っています。

コンピュータ将棋での先手勝率

はじめに

WCSC35が近づいてきました。
近年、コンピュータ将棋では「先手が有利」とよく言われますが、自己対局の結果を見ると先手勝率は55〜60％程度で、そこまで圧倒的に勝っている印象はありません。
大会では高性能なマシンを用い、膨大な局面を読むため、こうした環境が先手勝率に影響を与えている可能性があります。
そこで今回は、「読む局面数（＝時間をかけること）」が先手勝率にどのような影響を与えるのかを調べてみました。

実験

自己対局は、将棋ソフト「氷彗」を用いて以下の条件で行いました。
持ち時間は1手あたり1秒、4秒、8秒、12秒の4パターンで、それぞれ1000局ずつ対局させています。

  • スレッド数：4
  • 最大手数：320手で引き分け
  • 平手初期局面

結果

結果は以下の通りです（引き分けは0.5勝として計算）。

一手の秒数 先手勝ち 後手勝ち 引き分け 先手勝率
1秒 547 369 84 58.90 %
4秒 529 322 149 60.35 %
8秒 514 295 191 60.95 %
12秒 535 257 208 63.90 %

対局数が1000局とやや少ないものの、時間を長くするほど引き分けが増え、先手勝率が高くなる傾向が見られました。

おわりに

12秒までの範囲で調査した結果、持ち時間を長くすればするほど先手勝率が上がる傾向が確認できました。
大会のように、さらに多くの局面を読む環境では、先手勝率はこれ以上になる可能性もあります。

以下は今後の課題として考えられますが、現時点ではさらに調査する予定はありません。

  • 長く読むことでどのくらいまで先手勝率が高くなるか
    • 大会のように数億局面以上読めば、先手勝率がより高くなるのかそれともある程度で上限があるのか
  • DL系ではどうなのか
  • より弱いソフトではどうなのか
    • 昔のソフトならそれほど先手勝率が高くならないのか

最強の振り飛車ソフトを作りたい！

はじめに

この記事はただのネタ記事です。

コンピュータ将棋において振り飛車は、不利飛車とも言われ呪いの装備の扱いとなっています。
現在、最強の一般公開されているソフトはたややんさん作の振電3です。（たややんさん調べ）

youtu.be

最強フリーソフトの振電3であっても、水匠10beta2などの最強クラスの居飛車ソフトと比較するとちょっと分が悪そうに見えます。（独自調査）

多くの人が振り飛車の将棋ソフトを開発し、大会に挑んだり公開されたり、振り飛車には人を惹きつける何かがあるようです。
しかし、居飛車の壁は分厚く、多くの振り飛車ソフトは跳ね返されてきました。

そんな居飛車時代にピリオドを打つべく、最強の振り飛車専門ソフトを作ってみたいなと思います。

方針

振り飛車ソフトというとほとんどの人が振り飛車評価関数を作ろうと試みます。 しかし、振り飛車専門といわれるソフトは、無理に振り飛車を教えてるせいか、ちょっと弱くなってしまうように見えます。

なので、まずは強い評価関数をつくり、探索部に調整を加えることによって振り飛車を指してもらうようなソフトにします。

強い評価関数

頑張って作ります。

振り飛車探索部

探索に以下の制限を追加します。

/**
 * @brief 振り飛車制限ルールに基づく駒の移動制限をチェックする
 * 
 * この振り飛車制限ルールでは以下の制限が適用されます：
 * 1. 飛車が一度でも動いた後は制限なし
 * 2. 振り飛車制限を受けているプレイヤーの手番でのみ制限が適用
 * 3. 18手目以降は飛車以外の駒の移動を制限
 * 4. 飛車の移動に関して：
 *    - 段を変える移動は制限
 *    - 3マス未満の横移動は制限
 * 
 * @param move            検証する手
 * @param pos            現在の局面
 * @param handicappedColor 振り飛車制限を受けている側の手番
 * @return true          移動が制限される場合
 * @return false         移動が許可される場合
 */
bool is_move_restricted_by_handicap(const Move& move, const Position& pos, Color handicappedColor) {
    // 早期リターンによる基本的なチェック
    if (pos.state()->rookMoved || pos.side_to_move() != handicappedColor) {
        return false;
    }

    const Piece movingPiece = pos.piece_on(move.from_sq());
    const bool isRook = type_of(movingPiece) == ROOK;
    const int gamePly = pos.game_ply();

    // 飛車以外の駒の移動制限（18手目以降）
    if (gamePly > 18 && !isRook) {
        return true;
    }

    // 飛車の移動に関する制限
    if (isRook) {
        const Square fromSq = move.from_sq();
        const Square toSq = move.to_sq();

        // 段が異なる移動
        if (rank_of(fromSq) != rank_of(toSq)) {
            return true;
        }

        // 近距離の横移動
        const int fileDiff = abs(file_of(fromSq) - file_of(toSq));
        if (fileDiff < 3) {
            return true;
        }
    }

    return false;
}

検証

現状手に入る最強ソフトの一つである、水匠10beta2と以下の条件で対戦させてみます。

  • スレッド数: 4
  • 秒読み: 1秒
  • 平手初期局面より3000戦対局
2007-866-127 (69.02 %)

勝率69%！圧勝ですね。振り飛車の時代がやってきました。

おわりに

最強の振り飛車ソフトが出来上がりましたので、試しにfloodgateに投入してみましょう。

http://wdoor.c.u-tokyo.ac.jp/shogi/view/show-player.cgi?event=LATEST&filter=floodgate&show_self_play=1&user=hisui_test-40c

名前が40cと40コアのように書いていますが、ミスにより実際は20コア40スレッドです。

なんか、初手を指すと-150から-250くらいになっているような気がしますが、見なかったことにしましょう。

おまけ

たややんさんの振電3に触発されて、振り飛車を指すソフトを実験してみましたというだけのネタです。
実際のところは、初手のマイナス分勝率が下がっているはずです。 floodgateでも強豪ソフトに対して、中盤で押し返せずにそのまま持っていかれてしまっています。

第5回電竜戦感想戦

はじめに

2024/11/30 から 2024/12/1にかけて行われた文部科学大臣杯第5回世界将棋AI電竜戦本戦 に「氷彗」というソフトで出場していました。

最終戦では2連敗してしまいましたが、なんとか優勝を果たすことができました。

https://denryu-sen.jp/denryusen/dr5_production/league_table_a.html

今まで特に隠してはいなかったのですが、少しずつ開発を進め、何度か大会に出場していました。 今回、なんとか成果を出すことができたので、氷彗の開発と工夫した点について簡単にまとめます。

氷彗について

基本的なテーマとしては、StockfishからのNNUEの逆輸入です。 Stockfishでは、NNUEが採用されて以降、さまざまな工夫が施されています。

https://github.com/official-stockfish/nnue-pytorch/blob/master/docs/nnue.md#historical-stockfish-evaluation-network-architectures

一方で、将棋のNNUEは長らくHalfKP 256x2-32-32またはHalfKP 1024x2-8-32という構成でネットワーク構造については大きく変化していません。 これをStockfish風に変え、強くするというのが氷彗の開発コンセプトです。

名前の由来

名前は、コンピュータ将棋界の伝統「強いソフトの名前からインスパイア」を踏襲して命名しました。 NNUE最強のソフトは「水匠」なので、水と宝石に関連する名前をChatGPTに提案してもらい、「氷彗」としました。

ちなみに、個人的なこだわりで内部的には「hayabusa」という名前でコードを管理しています。

nnue-pytorchによる学習

学習にはnnue-pytorchを使用しています。 nodchipさんが対応した将棋用ブランチをベースに、Stockfishの学習手法に近づける形で修正を加えています。

現在の評価関数の1回の学習にはA100 x 1で、約2週間かかります。 Stockfishには学習速度向上のための改良が入っていますが、残念ながらそれらを取り込む余裕がなく、現時点では放置しています。

HalfKA 1536-15-64

今回の電竜戦で採用したNNUEアーキテクチャーは、「HalfKA 1536-15-64」です。

  • HalfKA: 入力特徴量がHalfKA
  • 1536: L1層の入力次元数
  • 15: L2層の入力次元数
  • 64: L3層の入力次元数

HalfKA

氷彗では入力特徴量として「HalfKA」を採用しています。 これはStockfishに由来するもので、詳細は以下に記載されています：

https://github.com/official-stockfish/nnue-pytorch/blob/master/docs/nnue.md#halfkp

ただし、現在のStockfishでは「HalfKAv2_hm」を採用されています：

https://github.com/official-stockfish/nnue-pytorch/blob/master/docs/nnue.md#halfkav2_hm-feature-set

氷彗が「HalfKA」を維持している理由は以下の通りです：

  • v2: 強さにほぼ影響がないと考えられるのと、実装が煩雑なため。
  • hm: 将棋では弱くなる可能性が高いため。

ただし、v2については将来的に対応するかもしれません。

L1層(1536)

L1層の入力次元数は1536です。 やねうら王での表記では「768x2」と表現するのが一般的なようですが、本記事ではStockfishの表記に合わせます。

やねうら王では、入力特徴量->Linear->ClippedReLUでL1層に渡していますが、 Stockfishでは多少改良が入っており、「Element-wise multiply」というのが挟まれています。 StockfishのSSNNv4から導入され、以下の図に詳細があります：

nnue-pytorch/docs/nnue.md at master · official-stockfish/nnue-pytorch · GitHub

氷彗でも、「Element-wise multiply」を導入しています。

L2層(15)

L2層の入力次元数は15です。 L1層の出力16を「1」と「15」に分割し、15をL2層の入力に、残りの1は出力層に直接加算しています。 Stockfishでは、SSNNv4から導入されています。

さらに、入力を通常のClippedReLUとSqrClippedReLUの2種類の活性化関数に通し、それらを線形結合してL3層に渡しています。 Stockfishでは、SSNNv5から導入されています：

https://github.com/official-stockfish/nnue-pytorch/blob/master/docs/nnue.md#sfnnv5-architecture

こちらも、氷彗に導入済みです。

L3層(64)

L3層は64次元で、nodchipさんの研究成果を参考に、実験で最も強かった64としています。

LayerStacks

StockfishではL1層以降のネットワークを8つ持ち、駒数に応じて切り替える構造を採用しています。 このアーキテクチャはSSNNv2から導入されています：

https://github.com/official-stockfish/nnue-pytorch/blob/master/docs/nnue.md#sfnnv2-architecture

Stockfishのドキュメントに正式名称がないため、学習コードから勝手に「LayerStacks」と呼んでいます。 氷彗では玉の段に応じて4つのネットワークを切り替える構造としています。 これは入玉の評価を分離する意図があるのですが、まだ試行錯誤中であり、今後変更の可能性があります。

探索部

氷彗の探索部はやねうら王をフォークして独自の修正が入っています。

まとめ

だいたい2年くらい少しずつ、StockfishのNNUEを将棋に逆輸入するというのをやってきました。 現在の強さは、電竜戦の出場時に書いた通り、水匠10betaに対して勝率約76%です。 地道に細かく積み上げた結果です。

最後に、大会を運営していただいた主催者様、お疲れさまでした。 また、氷彗と対戦いただいた参加者の皆さまありがとうございました。

DMM英会話を30000分やってみた

はじめに

3年前に「DMM英会話を6000分やっても英語は話せない話」というのを書きましたが、これの続編です。

saihyou.hatenadiary.jp

これ以降もなんとかDMM英会話を継続していて、11月のはじめに30000分を達成することができました。 ほぼ毎日約3年半くらい続けたことになります。長かった。

DMM英会話には英会話時間に応じてランクが設定されていて、30000分を達成すると最高峰のレジェンドの称号を得ることができます。 ただ残念ですが、レジェンドを取得しても何もメリットはありません。

englishfactor.jp

レジェンドを取得したということで、DMM英会話について振り返っておこうというのが今回です。

DMM英会話のレッスンの進め方

前回に書いた時から何も変更はなく、毎日デイリーニュースをやっていました。

https://eikaiwa.dmm.com/app/daily-news

毎日ニュースも更新されており、特に何か考えなくても話題が提供されるので続けるのにはとても良い教材だと思います。 毎日更新されているとはいえ、特に興味のないニュースもたくさんあるので、だいたい2～3日は同じ教材を使っていました。

講師は決まった人を作らずに、なるべく4.6以上の評価の人を予約していました。4.9以上の人は結構当たりのことが多かったです。 ただ、土日やフィリピンが休みの日には講師の人がほとんどいなくなりいい人の取り合いで大変でした。

DMM英会話を30000分続けるとどうなるのか

こんな感じで、30000分も続けると、

  • 予習しなくても困ることはない
  • 相手が話していることは集中して聞かなくても何となく理解できる
  • 話していることも何となく通じている

くらいはできるようになっており、なんとなく英語を話しているように見えます。 また、リスニング力はとても伸びました。当初は一瞬でも気を抜くと相手が何を言っているかわからなくなってしまいましたが、集中しなくても70%くらいは何を言っているのかが理解できるようになりました。 始める前は英語を話そうと思っても一切単語が出てこない状態でしたが、現在は何かしらそれっぽい単語をつなげて思うことを表現することはできるようになったかなと思います。

ただ、子供用のアニメでさえも字幕なしではほとんど意味が取れないですし、文法もかなり間違っていたり、適切な表現ではなかったりと実際の英語力はそれほど高くはなりませんでした。

オンライン英会話だけの限界

よく、オンライン英会話だけでは英語力は伸びないというのを目にしますが、実際その通りだと思います。 20000分あたりからこのまま続けても英語力は伸びなさそうだなと感じていました。 原因としては以下があげられます。

使える表現が増えない

意図してインプットを増やさない限り、語彙やフレーズ等は増えず決まった適当な表現で済ますことが多くなっていきます。 語彙はDMM英会話を漫然と続けているだけではなかなか増えないです。 これを克服するには、英会話中にこういうことを言おうとして言えなかったというようなものを記録して、 終わった後でChatGPTにどういうのが正解かを教えてもらい、それを身につくまで復習するといったようなことが必要だなと思いました。

文法力が上がらない

ある程度文法があっていれば違和感はあるけれど何となくは通じるができてしまうので、指摘されることが減ります。 このあたりは、ネイティブプランで文法を重点的に指摘してほしい等のリクエストを出すとか、 そうしなくても、気になったところをメモしておき、終わった後でChatGPTに聞くとかできると改善できそうです。

発音があまり向上しない

LとRについては、初期のころ結構指摘されるのですが、これを克服してしまうと発音について指摘されることがほぼなくなります。 これは、スタンダードプランでネイティブ以外の人が講師だからというのもありますが、ネイティブプランでネイティブにいろいろ指摘されても同じ結果になったかもと思います。 発音を伸ばすには、かなりの反復練習が必要だと感じますし、発音に集中するとフレーズとか文法とかがおざなりになるので、発音を伸ばすことのみを目的に一定期間練習しないと厳しそうだなと思っています。

おわりに

最後の方は本当にただ惰性で続けていましたが何とか30000分を達成することができました。 きちんと復習の時間を取ってオンライン英会話をやればもっと伸びたのかもしれませんが、なかなか難しいです。

DMM英会話はとても良いと思いますが、これ以上惰性でやってもどうしようもないので一旦辞めました。 現在はSpeakという英会話アプリをやっています。

app.usespeak.com

これについてもある程度やったら何か書くかもしれません。

wcsc31について

はじめに

時々ブログを書いているのですが、コンピューター将棋の大会について書いたことがなかったので、今回はちょっとまとめてみようと思います。

wcsc31について

sakuraという名前のソフトで第31回世界コンピュータ将棋選手権(wcsc31)に出場しました。

www2.computer-shogi.org

2次予選9位でn回目の決勝まであと一歩でした。 DeepLearningShogiを使っているチームの中ではトップで、DL勢の中ではPALについで2番目ということにしておきます。
// Ryfamateは合議らしいので除外です。

sakuraについて

基本的には大量の局面でベースを作って、レベルの高い棋譜で仕上げていこうと思っていました。 NNUEのdepth8で40億局面程度用意し、それを学習させベースのモデルを作成しました。 このdepth8の40億局面で学習したモデルをベースに、depth20から22の局面を2億程度使って学習させました。

結果としては、depth8は40億を用意する必要はなさそうで、もっと手早く強くなったのではという気がしています。

教師局面の生成

教師局面はほぼ全てNNUEを使用しています。 現在の将棋ソフトは十分に強いので、これを使って教師を生成したほうが手っ取り早いはずです。 ほぼこれだけで、DeepLearning勢のトップに追いついたのでNNUEで教師を作るのは悪くないと思っています。 むしろRyzen Threadripperを持っている人たちはNNUEで教師を作ったほうが良いのではと思っています。

seresnet

seresnetを使ったのはコンピューター将棋業界に伝わる「コンピューターチェスで成功したものはまず盲目的に試してみる」という格言に従ったものです。 lc0でseresnetを使っているので使ってみたというだけです。 実際にseやるのとやらないのでの比較をしていないので本当は効果がないかもしれないです。

label smoothing

これは、機械学習コンペやっているとよく出てくるやつだと思っています。

Label Smoothing - Qiita

policyの正解ラベルに(1.0 - 0.001 * NumOf合法手)、合法手に0.001で他は0としています。 これも比較実験をしていないのでわからないのですが、これはいくつかやった工夫の中で唯一効いたと思っています。 // 後で実験して結果を乗せるかもしれません。

DeepLearningShogiについて

今回はDeepLearningShogiにほぼ全面的に乗っかりました。

github.com

学習してみた感想としては、結構かんたんに強くなります。 少し前まではNNUE勢と全く勝負にもならなかったのに、ここまでのものを作った山岡さんはすごいです。

DeepLearningを使った将棋ソフト

今回の大会は電竜線でのGCTの成功に触発されたのか、それともNNUEに限界を感じたのか多くのチームがDeepLearningに乗り換えています。 事後孔明ですが、DeepLearningの将棋ソフトは現状だとNNUEと同等くらいまでしか強くならないような気がしています。 また、計算リソースがないのできちんと計測していませんが、現状だとまだNNUEが優位かなと思っています。 floodgateベースでもRTX3090のソフトが他を圧倒しているわけではないですし、A100 x 16を用意しても伸びしろはあまり大きくないと思っています。

将棋ソフトの今後

良くも悪くもやねうら王次第となっていますが、NNUEの発展は今後やねうら王とそのユーザーがどの程度頑張るかに依存しているかなと思っています。 なんだかんだ、Stockfishの最新に追随して見る人とか、学習の工夫をして見る人もいるので、次のイノベーションが見つかってDeepLearningを突き放す未来があっても不思議ではないと思っています。

DeepLearningベースについては、あとひとつ工夫をしないとNNUEに対して優位には立てないかなと思っています。 基本的には層を増やしていくとlossが明確に下がるので何も考えずによりDeepなモデルを作っていく方向性が考えられますが、 これだけでは劇的に強くするのは難しいかもという気がしています。 ただ、こちらは評価関数だけでも、入力特徴量、出力ラベル、ネットワーク構造等工夫ポイントはたくさんあると思いますので、 こちらのほうが伸びやすそうかなという気がしています。