深層学習分野の英語表現（日常編）

日本で深層学習関係の仕事をしていたとき、よく扱う事柄／よく出くわす状況なのに、適切な表現がないな、と思うことがあった。アメリカに来てから、そのうちのいくつかに、（少なくとも自分の周囲では）ある程度定まった表現が使われているのを知った。

そうした、論文にはあまり出てこないが、日頃の業務に出てくる表現を、その文脈と共に取り上げる。なお、アメリカに来てから1年半ほど経ったので、今では日本語でも良い言葉があるかもしれない。

Babysit: 安定しない大規模学習を人間が監視して障害に対応すること

GPUを数百、ときには1000や2000使うような大規模学習をずっと走らせていると、どこかで調子が悪くなる。1024 GPUの学習が一週間ノートラブルなんて、聞いたことがない。いずれかのGPUの障害で止まったり、通信が極端に遅くなったり、何らかの問題が起きる。ハードウェアの問題が無くても、lossのスパイクが増えたり、発散したりということもある。

正常に進行しなくなった学習をそのままにしておくと、GPUリソースの大変な無駄なので、学習の進行を見守り、問題があったら再起動したり、といった対応が必要になる。これをよく Babysit と表現する。
The new cluster is incredibly unstable. Someone needs to babysit the training this weekend.
といった具合である。なお英語では、手間がかかるもののお世話をすることを言うのに、babysitとよく言われるようだ。

日本で仕事をしていた頃、GPU含むインフラの障害に出くわす度、こんなこと対応してたらとてもやってられない、と思っていた。だが、こんな表現がよく使われること自体、ビッグテックでもスタートアップでも、世界中で多くのエンジニア・研究者が babysitting を余儀なくされているということだろう（アメリカに来てからは、自分はやっていないが……）。
例えば以下の記事は、GPUクラスタの不安定さについての不満が挙げられていて、話題になっていた。

Training great LLMs entirely from ground up in the wilderness as a startup — Yi Tay

なお、どうして監視と復旧を自動化できないんだ？という人もいるだろう。そこには色々複雑な事情がある。いずれどこかで掘り下げて考えてみたい。

Recipe: 理屈が説明できないがうまく行くとされている学習設定

学習率、バッチサイズ、Adamのbeta、その他諸々をまとめて、 training recipe と呼ぶことがある。

モデルアーキテクチャやアルゴリズムなど、技術のアイデアとなる部分とは別の部分を指したいことがあるため、この用語は便利である。論文で良いとされていたアルゴリズムにしてみたがうまくいかない、自分の用途での training recipe を探索する必要がある……というわけだ。

最初この言葉を聞いたとき、皮肉が効いていると思ったものだった。「砂糖を大さじ2」というとき、どのようにそれを導き出したか、説明することはほとんどない。大体は類似の料理や既存のレシピがあり、そこから「まあこれくらいでしょ」でキリよく選ぶだろう。それ以上の理屈を説明するのは難しい。

科学的であるべき深層学習研究だが、学習設定については、実務では料理と同じである。バッチサイズ・学習率その他に関する論文は数多くあるが、参考にはなっても、決め手に欠ける。実務においては、自分の経験や、公開されている他のモデル学習を参考にするのが普通だろう。

Correctness issue / Accuracy issue: 数式通りプログラミングしたはずがそれでも発生する問題

システムが出力する計算結果は、時に期待するだけの正確さではないことがある。多くの人は、コンピュータというものは、柔軟性には欠けるものの、足し算やかけ算といった計算は、人間が "z=x+y" のように数式をそれらしくプログラミングすれば、高速かつ「完全に」正確に計算が行われると考えているが、実際にはそうではない。

特に、深層学習システムは、正確さとパフォーマンスの両立が極限まで求められる領域である。だがパフォーマンスを追求すると、正確さが損なわれることがある。単純にバグがある（e.g. 並列計算における同期がおかしい）、といったケースも多いが、手法に起因する原因のこともある。結果として、モデルの学習が十分に収束しない、ダウンストリームタスクで十分な性能が出ない、といったことが起きる。
こうした問題を、計算結果が正しくないという意味で correctness issue ということがある。また、必要なだけの正確さではないというニュアンスで accuracy issue ということもある。日常では、これらを特に区別せずにして使うこともある。

今では誰もが使っているFlash Attentionだが、バージョン2が出た頃、数値計算の結果が良くないのでは、という話題がちらほら聞かれた。以下では、"stability"という言い方だが、同種の問題について言及されている。

こうした言葉が使われるのは、「数式を正しくプログラミングした（はず）」と「大規模学習でそれが期待通り働く」のギャップが大きいからである。計算順序を変えたり、GPU数を変えるだけで、浮動小数点の数値域が変わり、計算精度が変わり、学習後のモデル性能が変わるということはよくある。そしてこういう問題は、デバッグもなかなか難しい。だが、システムが専門でない人は、そのギャップがなかなか理解できない。

エライ人に「論文の数式なんて2行なのに、なぜまだ動かないんだ？」と言われると、システムを作る立場としてはつらい（そんなことを実際に言われたことはないが）。おそらくこうした用語を使う側には、数式をそれらしくプログラムで書くことと、実際にそれを大規模計算に使うことのギャップの存在を明示し、周囲の理解を醸成したいという気持ちがある。