elmoはAperyの学習部を用いていた。何故、やねうら王の学習部を用いていなかったかと言うと、やねうら王の学習部がう○こだからだ。

学習部と言っても大きく3つの部品に分けられる。

1. 探索部

やねうら王では、search()関数を呼び出すためのジャンプ台みたいなのが用意してある。通常対局では、全スレッドで同じ局面を探索するわけだが、教師局面の生成時には、各スレッドが別の局面を探索するようにしてある。

このほうが効率的に探索できるからこうしてあるのだが、この部分に何らかバグがある可能性がある。昔のバージョンではなかっても、新しくなったときに何らかバグっている可能性がある。スレッドごとに個別に持っている情報と、全スレッドで共有している情報とがあって、後者が問題となることがある。困ったものである。

2. 教師局面の生成部

教師局面を生成するコードに何らかのバグがある可能性がある。あるいは、手法の違いにより、生成される教師局面の質に差が出ることがある。例えば、深い探索の評価値を取得するときに、search()の戻り値をそのまま用いる方法と、PVの指し手でleaf nodeまで進めて、そこでevaluate()を呼び出して評価値を得る方法とがある。前者は置換表の指し手で枝刈りされたときに、後者の値と異なる値になるので、後者の方法のほうが良いのかも知れない。比較実験はしていない。やねうら王では、そんなに変わらんやろ、ということで前者にしている。

3. 学習部

学習時にメモリを大量に消費する。evaluate()で評価値を計算するためのパラメーターのおおよそはs16(int16_t)だが、mini-batchで更新するときは、これをfloat型かdouble型で保持しておいて、そこを更新したのちに、その値をs16のほうにコピーすべきである。本来ならば。

やねうら王は、この部分、floatにしていた。(Aperyはdouble)　しかも、floatすらもったいないんじゃないかと思い、最近、直接s16の配列を更新するようにした。計算精度だだ下がりである。

あとAdaGradで用いている変数もfloatにしてある。(Aperyはdouble)　このへん、計算精度的に足りてない可能性もあるし、また、何らかバグっている可能性もある。

あと、次元下げの問題がある。やねうら王のいまの学習部、KPP/KKPのミラーぐらいしか次元下げをしていない。別にこれは問題にはならないと思うが、しかし、Aperyはたぶん昔にもっと細かく次元下げしてたころのコードが残ってて、それを使っている(使える)はずだ。このへんの差があるかも。(ないかも)

ともかく、折を見て、3.に関しては全面的に書き直すつもりだ。また、1.に問題がないことは、tanuki-さんに実験してもらっている最中である。1.と2.に問題がないことが判明したら3.を全面的に書き直そうと思っている。

何故、学習部の省メモリ化が大切なのか

やねうら王の学習部が省メモリ化を目指しているのは、評価関数が大きくなったときに(パラメーターの数が増えたときに)、学習に要するメモリをなるべく減らしたいためである。Aperyの方式では、1GB程度の評価関数ファイルの学習のためにその10倍以上のメモリを必要とする。あと、スレッドごとに勾配の計算用の配列(float型)を持っているとスレッド数に比例した分だけ追加でメモリを必要とする。

こういう状態では、仮に30GB程度の評価関数を学習させようと思うと500GB程度が必要となる。500GBのメモリはいささか現実的ではないように思う。だから、やねうら王では省メモリにしたかった。

しかし、最初から省メモリを目指したのでは、計算精度が足りてなくてきちんと学習できないのか、それとも何らかコードにバグがあって学習がうまくできないのかがわからない状態になってしまう。うまく学習できるコードが手元にないと比較実験すら出来ない。

この点、やねうら王のアプローチの仕方は間違っていたと認めざるを得ない。ともかく、まず学習部をAperyと同等の性能にする。また、その上で省メモリ化を目指す。

私はしばらくやねうら王の開発に時間が取れないが、そんな事情なので開発者の皆さんは、学習部の実験にはApery(elmo)を使ってくださいということで…。