テクニカルサマリー: $i$ML – 実行可能、問題に基づいた、広範な探索を行うコード駆動型AutoML

1. 問題提起

自動機械学習（AutoML）は機械学習へのアクセスを民主化してきましたが、既存のシステムは柔軟性、透明性、および実行の信頼性において重大な限界に直面しています。従来のAutoMLツールは、定義された探索空間（例：表形式データ）に制限された硬直的な「ブラックボックス」として機能することが多く、複雑またはマルチモーダルな問題に対してパイプラインをカスタマイズする能力に欠けています。

最新の大規模言語モデル（LLM）ベースのエージェントは、前処理、学習、および評価のための実行可能なコードを合成するコード駆動型AutoMLへと移行しています。しかし、現在のアプローチには以下の3つの決定的な欠陥があります：

1. 実行可能性の欠如： 生成されたコードはテキストとしてはもっともらしく見えますが、実行時のエラー、型の不一致、または検証されていない仮定により、実行時に失敗します。
2. 不十分な問題への接地（グラウンディング）： プランニングの決定が、実際のデータセットの経験的な分析ではなく、検証されていないテキスト上の仮定や「幻覚（ハルシネーション）」によるデータ特性に依存しています。
3. 狭い探索範囲： 多くのシステムは、単一のモデリングパス（例：モノリシックなスクリプトの洗練や、AutoGluonのような固定されたバックエンドのラッピング）に早期にコミットしてしまい、伝統的なML、事前学習済みモデルの適応、およびカスタムニューラルアーキテクチャにわたる、最新かつ多様なソリューション戦略の探索に失敗します。

2. メソドロジー: $i$ML フレームワーク

著者らは、実行可能性、問題への接地、および広範な探索という3つのコア要件を満たすように設計された、マルチエージェント・コード駆動型AutoMLフレームワークである$i$MLを提案しています。このフレームワークは、以下の3つの調整されたフェーズを通じて動作します。

フェーズI: コード誘導型戦略的プランニング

直接的なコード生成プロンプトではなく、$i$MLはまず、問題に基づいた戦略的ブループリント（$B$）を構築します。

• タスク分析とプロファイリング： 「タスクアナライザー」が意味的な制約を抽出し、「プロファイリングエージェント」が、スキーマ、欠損パターン、データ品質を含むメタ特徴量（$F_{meta}$）を生成するために生のデータセット（$\mathcal{D}$）を経験的に分析します。
• 知識検索： 「ナレッジリトリーバー」が、外部ソースからドメイン制約と前処理戦略を取得します。
• ブループリント合成： 「ガイドラインエージェント」が、前処理の指示、モデル選択ロジック（伝統的ML、事前学習済み適応、またはカスタムニューラルアーキテクチャの選択）、学習プロトコル、および評価指標を指定する構造化されたブループリントを合成します。このブループリントは、探索空間を制約するためのアーキテクチャ上の不変量として機能します。

フェーズII: コード・モジュラー実装

特化したコーディングエージェントが、明示的なインターフェース契約（$IC_{\mathcal{T}}$）の下で、コンポーネントを個別に実装します。

• 前処理コーダー： 生データを、モデリング段階で要求されるスキーマを厳格に満たす検証済みの表現（$\mathcal{D}'$）へと変換するスクリプト（$S_{prep}$）を生成します。
• モデリングコーダー： 学習と推論のためのスクリプト（$S_{model}$）を生成し、検証された $\mathcal{D}'$ との数学的な互換性を確保します。
• 契約駆動型設計： このモジュール性は、ロジックの絡み合いを防ぎ、コンポーネントの独立した開発と修復を可能にします。

フェーズIII: コード検証型統合

「アセンブラエージェント」が $S_{prep}$ と $S_{model}$ を統合して、統一されたパイプライン（$S$）を構築します。

• 動的実行と検証： システムは、モデリング段階で要求されるインターフェース契約に対して、実行時の特性（形状、型）を検証するために、データ上で $S_{prep}$ を実行します。
• 反復的なデバッグ： 実行に失敗した場合、「エラーアナライザー」が実行時のトレースバックを使用してフォルト（例：APIのミスマッチ、テンソル形状のエラー）を特定します。「デバッグエージェント」は、必要に応じてウェブ検索を利用して最新の構文を確認しながら、有効なパイプラインが得られるまで、特定のコンポーネントを反復的に修復します。

3. 主な貢献

1. 新しい設計原則： 本論文は、理想的なコード駆動型AutoMLのための3つの基準、すなわち実行可能性（信頼できるエンドツーエンドの合成）、問題への接地（経験的なデータと検索された知識に基づく決定）、および多様な/更新された探索（異種混合のソリューショントラックにわたる探索）を確立しています。
2. $i$ML フレームワーク： 経験的なプロファイリング、検索に基づくプランニング、モジュール式のコード合成、および動的検証を通じて、これらの原則を具現化したマルチエージェント・アーキテクチャを提供します。
3. 広範な実験的検証： MLE-BENCHおよび新たに導入された$i$ML-BENCH（2021年から2025年までの16の多様なKaggleコンペティションをカバー）における包括的な評価により、優れた運用信頼性と競争力のあるパフォーマンスを実証しています。

4. 実験結果

著者らは、$i$MLを、従来のAutoML（AutoGluon）やコード駆動型エージェント（MLZERO, MLE-STAR, AutoML-Agent）を含む最先端のベースラインと比較評価しました。

MLE-BENCH (Lite) におけるパフォーマンス

• 信頼性： $i$MLは90%の有効なサブミッション率を達成し、MLE-STAR (55%) や AutoML-Agent (40%) を大幅に上回りました。
• 競争力のある質： 45%のタスクでメダル（金/銀/銅）を獲得し、**80%の「中央値以上（Above Median）」**を記録しました。
• パフォーマンススコア： 平均パフォーマンススコア（APS）は0.82であり、LLMベースのベースラインに対して52%〜273%の向上を示しました。

$i$ML-BENCH におけるパフォーマンス

• 堅牢性： $i$MLは最高のAPS（0.54）を達成し、MLZERO（0.19）のパフォーマンスをほぼ3倍に引き上げました。
• 複雑なタスク： AutoGluonやMLZEROのようなベースラインが複雑なマルチモーダルタスク（例：PetFinder、マルチラベル分類）で失敗（スコア0.00）した一方で、$i$MLは高いスコア（それぞれ0.67および0.69）を維持しました。
• 記述の剥離： タスクの説明が大幅に削られ、一般的なプロンプトになった場合でも、$i$MLは70%の成功率と0.63のAPSを維持し、曖昧なユーザー意図に対する耐性を示しました。

アブレーション研究

• 実行可能性： 動的検証またはモジュール式統合を削除すると、有効なサブミッション率とAPSが大幅に低下し、静的なチェックだけでは不十分であることが確認されました。
• 接地（グラウンディング）： 経験的なデータプロファイリングを削除すると、APSが0.82から0.66に低下し、データへの接地が競争力のある質の主要な推進力であることが証明されました。
• 探索： $i$MLを単一のモデリングトラック（例：伝統的MLのみ）に制限すると、非表形式タスクにおいてパフォーマンスが崩壊し、マルチトラック探索の必要性が検証されました。

5. 重要性と主張

本論文は、$i$MLが高レベルの戦略的推論と経験的に検証可能な実装の間の溝を埋めることで、堅牢なAutoMLのパラダイムを確立すると主張しています。

• 妥当性よりも信頼性： テキストとしては妥当だが脆弱なコードを生成する以前のエージェントとは異なり、$i$MLは組み立て、実行、診断、修正のクローズドループプロセスを通じて実行可能性を強制します。
• 経験的接地： 観察されたデータの特性と検索された知識にプランニングを固定することで、実行時の失敗を招く幻覚的な仮定を回避します。
• 人間レベルの競争力： $i$MLは、タスク固有のネイティブなパイプラインを構築することで、コード駆動型AutoMLが「ブラックボックス」型の最適化ツール（AutoGluonなど）の性能上限を超えられることを示しています。

著者らは、$i$MLが信頼できる、人間と競争可能な自律的エンジニアリングへの変革的な一歩であり、次世代のMLシステムのための検証可能な基礎を提供するものであると結論付けています。マルチモーダルタスクにおけるパフォーマンスの最適化は今後の課題として残されているものの、本フレームワークは、現在のAutoMLエージェントにおけるロジックの絡み合いと実行の信頼性という核心的な課題を解決したと述べています。