- AlphaEvolveは、言語モデルがコードを変更し、実行結果で候補を選び続ける探索の仕組みである。
- 4×4の複素行列積に必要なスカラー乗算を従来の49回から48回へ減らす構成を見つけた。
- 成果には課題ごとの正確な自動評価が必要で、自由な研究作業すべてを任せられるわけではない。
何を確かめた研究か
AlphaEvolveの原論文は、言語モデルにコードを一度書かせるだけでなく、候補を実行して採点し、その結果を次の変更に使う方法を調べた。科学・工学の問題を、プログラムで作った解を自動評価できる形に変える。初期のプログラム、変更してよい箇所、採点用のコードを人が用意する。論文の初公開と参照版は2025年6月16日である。
どう検証したか
複数の言語モデルが、保存された良い候補を参考にコード差分を提案する。実行できた候補は、正しさや速さなど課題ごとの指標で評価し、結果とともにデータベースへ戻す。次の試行はそこから候補を選ぶ。単純に同じ初期コードへ何度も修正を頼む場合や、課題の説明を省く場合とも比較した。
従来のFunSearchが主に短い一つの関数を変えたのに対し、AlphaEvolveは複数の関数を含むコード片を探索できる。とはいえ、探索範囲が広いほど採点を繰り返す費用も増す。モデルの提案が優れているかは、実際に走らせて評価する工程で決まる。
対象には、行列積の計算方法、数学的な構成、データセンターの計算資源配分、機械学習の計算核が含まれる。各問題の評価器は異なる。たとえば配分の候補は過去の負荷を使ったシミュレーションで探し、別の未使用データで評価した。計算核は実機の実行時間を測った。
何が分かったか
表2では、4×4の複素行列積の構成が従来49回のスカラー乗算に対して48回になった。これは特定の行列積の代数的な回数であり、一般の行列計算が一律に速くなる数字ではない。著者らは14種類の行列積の目標で既知の上限を更新したと報告する。
Googleのデータセンター向け配分規則は、未使用の負荷データによる確認後に運用され、全体の計算資源の平均0.7%を取り戻したと論文は記す。別の計算核では、専門家が設計した規則より平均23%速く、Gemini全体の学習時間を約1%短縮した。23%は計算核の速度で、全体の学習短縮率とは異なる。
配分規則は候補の機械を順位付けするもので、利用できない機械へ仕事を割り当てる変更ではない。計算核の改良も、演算そのものではなく分割方法を選ぶ規則を最適化した。どの部分を変更可能にするかという人の設計が、正しさと探索の幅を左右する。
限界は何か
著者ら自身が、自動で評価できない手作業の実験は対象外と明記する。評価器が見落とす誤りや、限られた入力だけに適合した変更があれば、良い点を取っても目的を満たさない。論文中の具体例では、別の入力による検証や専門家の確認を組み合わせている。
データセンターの0.7%や計算核の23%はGoogleの機器、負荷、既存規則のもとで得た結果である。導入先を変えたときの改善率ではない。必要な試行回数や評価器の準備費用を除いて、一般の開発業務より効率的だとも言えない。
仕事との接点
コードを自動改良する仕組みを試すなら、まず速度だけでなく正しさを確認する評価器を作る。変更に使う入力と、最後に独立して試す入力を分け、実行費用と人の確認時間も記録する。これはTRAIL編集部の提案である。