🤖 machine learning

Towards Code-Oriented LM Embeddings for Surrogate-Assisted Neural Architecture Search

本論文は、既存の言語モデルを活用してニューラルアーキテクチャを PyTorch コードとして表現する低コストな戦略であるコード指向言語モデル埋め込み（COLE）を提案し、専門的な微調整なしに競合する代理モデル支援ニューラルアーキテクチャ探索を可能にし、最適なモデルを見つけるために必要な評価予算を大幅に削減する。

原著者： Pranav Somu, Advay Balakrishnan, Stepan Kravtsov, Aaron McDaniel, Jason Zutty

公開日 2026-05-18

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Pranav Somu, Advay Balakrishnan, Stepan Kravtsov, Aaron McDaniel, Jason Zutty

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

以下は、平易な言葉と日常的な比喩を用いた、この論文の解説です。

大きな問題：最高のレシピを見つけるのは高価である

あなたがケーキの絶対的に最高のレシピを見つけようとするシェフだと想像してください。あなたには、材料（小麦粉、砂糖、卵、スパイス）と方法（焼き時間、温度）の組み合わせが数百万通りもある巨大な料理本が手元にあります。

人工知能の世界では、これを**ニューラルアーキテクチャサーチ（NAS）**と呼びます。「レシピ」はニューラルネットワークの設計図であり、「味見」は AI を学習させてその性能を確認することです。問題は、「味見」をすべてのレシピに対して行うには時間がかかりすぎ、計算資源の面で莫大な費用がかかるということです。本に載っているすべてのケーキを焼くことはできません。

これを解決するため、科学者たちは**サロゲート（代理モデル、または「味見予測器」）**を使用します。これは、紙に書かれたレシピを見て、実際に焼かずにケーキがどのくらい美味しくなるかを予測するフードクリティックのようなものです。目標は、高速で安価かつ非常に正確なクリティックを見つけることです。

従来の方法：レシピを外国語に翻訳する

以前は、クリティックにレシピを理解させるために、科学者たちはニューラルネットワークの複雑なコードを、奇妙で単純化されたテキスト形式（レシピを化学式の一覧や奇妙な図解に変換するようなもの）に翻訳する必要がありました。

次のように考えてみてください。数百万冊の実際の料理本やレシピを読んで料理の仕方を学んだ、巨匠シェフ（大規模言語モデル、LM）がいます。しかし、実際のレシピを見せるのではなく、彼が一度も見たことのない言語で書かれた翻訳（「ONNX からテキストへ」や「導出木」など）を渡します。

この新しい言語をシェフに理解させるためには、彼を何週間もかけてファインチューニング（実質的にはゼロから再教育すること）する必要があります。これは遅く、高価であり、高速な「味見予測器」という目的そのものを台無しにしてしまいます。

新しいアイデア：実際のレシピを見せるだけ

この論文の著者、プラナヴ・ソム（Pranav Somu）と彼のチームは、単純な洞察を持っていました。ニューラルネットワークはすでにコードで書かれているのです。それらは Python プログラミングスクリプトのように見えます。

「巨匠シェフたち」（CodeLlama などの大規模言語モデル）は、すでに何兆行もの実際のコンピュータコードでトレーニングされているため、これらのレシピを完璧に読む方法をすでに知っています。彼らを再教育する必要はありません。

解決策（COLE）：
レシピを奇妙な形式に翻訳するのではなく、生きた Python コードをそのまま事前学習済みの AI に与えます。

ファインチューニングなし：AI を「そのまま（凍結された状態）」で使用します。これは、特定の料理本を読む方法をすでに知っているシェフを雇い、研修セミナーを必要としないようなものです。
埋め込み：AI がコードを読み、レシピの本質を捉えた数学的な「指紋」（埋め込み）に変換します。
予測器：小さな単純な計算機（回帰ヘッド）がその指紋を見て、アーキテクチャがどの程度性能を発揮するかを予測します。

彼らが発見したこと

チームはこのアイデアを 2 つの異なる「料理本」（探索空間）を用いてテストし、いくつかの驚くべき結果を得ました。

生コードの勝利：AI に実際の Python コードを与えた場合、奇妙で翻訳されたテキスト形式を与えた場合よりも、はるかに優れた性能予測を行いました。これは、シェフが「実際のレシピが理解できるよ。化学式に翻訳する必要はないよ」と言っているようなものです。
トレーニング不要：AI を何週間もファインチューニングする必要がないことを証明しました。「市販品（オフ・ザ・シェルフ）」のモデルは、すぐに素晴らしい結果を出しました。
高速な探索：この手法を使って（BANANAS というアルゴリズムを用いて）最高の AI アーキテクチャを探したところ、はるかに速く最高の設計を見つけ出しました。
- あるタスク（CIFAR-100）では、旧来の手法よりも34% 少ないコンピュータ評価で、最良の設計の上位 1% に到達しました。これは、100 個のケーキを味見する代わりに 66 個だけを味見して最高のレシピを見つけるようなものです。

これが重要な理由

このアプローチは、検索エンジンに汎用翻訳機を与えるようなものです。すべてのニューラルネットワークはコードとして記述でき、コードはこれらの AI モデルがすでに流暢に話す普遍的な言語であるため、この手法はカスタムエンジニアリングを必要とせず、ほぼあらゆる種類のアーキテクチャに機能します。

要約すると：賢い AI にニューラルネットワークを理解させるために、新しい奇妙な言語を学ばせる代わりに、著者たちは AI がすでに知っている言語、すなわちコードで話しかけました。これにより、時間と費用が節約され、より良い結果が得られます。

技術概要：代理支援ニューラルアーキテクチャ探索に向けたコード指向 LM 埋め込み

問題定義

ニューラルアーキテクチャ探索（NAS）は、高性能なニューラルアーキテクチャの発見を自動化するが、大きな計算上のボトルネックに直面している。すなわち、候補アーキテクチャの適合性を評価するコストが非常に高いことである。これを緩和するため、研究者らは完全なトレーニングを行わずに適合性を近似する代理モデル（性能予測器）を採用する。しかし、既存の代理アプローチには 2 つの主要な限界がある。

表現の硬直性: 構造エンコーディング（例：隣接行列、パスエンコーディング）は、しばしば特定の探索空間（セルベースの DAG など）に合わせて調整されており、カスタムエンジニアリングなしに新しいアーキテクチャへの一般化や、複雑なハイパーパラメータ（例：カーネルサイズ）の捕捉が困難である。
ファインチューニングのオーバーヘッド: 言語モデル（LM）を汎用回帰器として使用しようとする最近の試みは、アーキテクチャを非標準的なテキスト形式（例：導出木文字列や ONNX-to-text）に変換し、その後、これらの外部表現に対して LM をファインチューニングすることを必要とする。この「ウォームアップ」フェーズは、探索を開始する前に高価な事前トレーニングを必要とするため、代理モデルを使用することによる効率性の向上を相殺してしまう。

著者らは、これらの非効率性は、現在の手法がニューラルアーキテクチャが本質的に実行可能なコードとして存在するという事実を無視していることに起因すると仮説を立てている。LM は膨大なコードコーパスで事前トレーニングされているため、アーキテクチャの論理を理解するための内在的な「帰納的バイアス」を有しているが、人工的なテキストエンコーディングを投入すると、このバイアスは整合性を失う。

手法：COLE

著者らは、凍結された事前トレーニング済み言語モデルを NAS 向けのゼロショット特徴抽出器として活用する戦略、コード指向 LM 埋め込み（COLE）を提案する。

1. ネイティブコードの文字列化

アーキテクチャを抽象的な文字列に変換するのではなく、COLE は探索空間を直接PyTorch クラス定義（torch.nn.Module）にマッピングする。

NAS-Bench-201: 著者らは標準的なグラフトポロジー文字列を解析し、有効な Python クラスに変換した。3 つの冗長性レベルを検討した。
- ヘルパーメソッド: 複雑な操作を別々のクラスとして定義する。
- インライン: nn.Sequential を使用してクラス内でロジックを定義する。
- ヘルパー除外: ヘルパークラスの実装を定義せずに参照する（最もトークン効率が高い）。
einspace: 決定論的なトランスパイラが、文脈自由文法の導出木を直接実行可能な PyTorch コードに変換し、非終端ノード（例：Branching、Routing）をカスタムコンテナクラスに、終端ノードを原子プリミティブにマッピングする。

2. 凍結埋め込み抽出

システムは、生コードテキストを処理するために凍結された事前トレーニング済み LM（具体的にはCodeLlama Python 7B）を利用する。

ファインチューニングなし: LM のパラメータは完全に凍結され、ドメイン固有の事前トレーニングの計算コストが排除される。
プーリング: 最後の層の隠れ状態アクティベーションを、トークンシーケンス全体にわたって平均プーリング（Mean Pooling）して集約し、固定次元の埋め込みベクトルを生成する。

3. 代理ヘッド

高次元の埋め込み（例：4096 次元）は、軽量な回帰パイプラインによって処理される。

次元削減: 主成分分析（PCA）が埋め込みを 128 次元に削減し、低データ領域での過学習を防ぐ。
回帰: 3 層の多層パーセプトロン（MLP）がアーキテクチャの性能を予測する。
損失関数: モデルはペアワイズヒンジ損失を用いてケンダルのタウランク相関を最適化する。これは、正確な絶対精度値の予測よりも、候補の正しい順序付け（進化探索アルゴリズムにとって重要）を優先する。

主要な貢献

ネイティブコードの優位性: 著者らは、凍結された LM を使用する場合、アーキテクチャを生の PyTorch コードとして表現することが、他のテキストベースのエンコーディング（ONNX-to-text、導出木）よりも高い予測性能（ケンダルのタウ）をもたらすことを実証した。
ファインチューニングの排除: COLE は、効果的な NAS 埋め込みのために計算集約的なファインチューニングが厳密には必要ではないことを証明する。市販の LM は「箱から出してすぐ（out-of-the-box）」に競争力のある特徴抽出器として機能する。
SA-NAS との統合: COLE を代理支援探索アルゴリズムであるBANANASに統合することで、標準的な構造パスエンコーディングを使用する場合と比較して、探索効率が大幅に向上した。
実践的なチューニングガイドライン: 本研究は、トークン効率のための「ヘルパー除外」モードや次元削減のための PCA などの効果的な設定を記録しており、入力文字列に完全な実装詳細が含まれていなくても、LM が操作の意味を推論できることを示している。

実験結果

このフレームワークは、NAS-Bench-201とeinspace探索空間で評価された。

埋め込み品質:
- NAS-Bench-201 において、COLE（CodeLlama 7B 使用）は 879 個のトレーニングサンプルで0.703のケンダルのタウを達成し、ONNX-to-text エンコーディング（0.678）や導出木文字列（einspace では 0.763、PyTorch コードでは 0.778）を上回った。
- モデル選択: コード中心のモデル（CodeLlama、Yi Coder）は、一般のエンコーダのみモデル（ModernBERT、CodeBERT）よりも一貫して優れていた。興味深いことに、1.5B の小規模モデルは 7B/34B の大規模モデルと同等の性能を発揮し、大規模なスケールが厳密には必要ではないことを示唆している。
- 損失関数: 標準的な平均二乗誤差（MSE）は絶対誤差が低かったが、ペアワイズヒンジ損失の方がランク相関が良好であった。
探索効率（BANANAS）:
- BANANAS アルゴリズムにおいてパスエンコーディングを COLE に置き換えることで、ほぼ最適性能に達するために必要な評価予算が削減された。
- CIFAR-100: COLE は132 回の評価で最も適合したアーキテクチャの 1% 以内に到達し、パスエンコーディングが要求する 200 回と比較して34% の削減を達成した。
- CIFAR-10: 13% の削減（52 対 60 回）。
- ImageNet16-120: 18% の削減（164 対 200 回）。
- これらの改善は、探索軌道の大部分において統計的に有意（ $p < 0.05$ ）であった。

意義と主張

本論文は、COLE が事前トレーニング済み LM における既存のコード知識を活用することで、NAS を進展させるための汎用的かつ効率的な基盤を確立すると主張している。

探索非依存: 任意のニューラルアーキテクチャはコードとして表現できるため、COLE は構造エンコーディングとは異なり、新しい探索空間に対してエンコーディングスキームを再設計する必要がない。
コールドスタート機能: ファインチューニングの必要性を排除することで、COLE は代理モデルが即座に有効となる「コールドスタート」探索を可能にし、以前の LM ベースの NAS 手法における効率性のパラドックスに対処する。
一般化能力: このアプローチは、トポロジーとハイパーパラメータの表現を単一の形式（コード）で統合し、LM が構造的フローとパラメータ値（例：kernel_size=3）の両方を自然に解釈できるようにする。

著者らは、現在の評価が特定のベンチマーク（NAS-Bench-201、einspace）に限定されているものの、この手法は複雑な GNN やファインチューニングされたトランスフォーマーに対する実用的で低コストな代替手段を提供し、特にリソース制約のある NAS シナリオにおいて有効であると結論付けている。