モデル開発の自動化への重要なステップ

AI 研究の次の重要なマイルストーンは、モデル開発の自動化です。推論、言語、認識の進歩は、いくつかの意味で、その目標に向けたステップです。ただし、モデル自動化への道は、まず解決しなければならない基礎的な課題があります。

その目標への橋は、機械学習 (ML) エンジニアリングを通じて直接結びついています。一般的な誤解は、ML が現代の AI の前身技術であり、基礎モデルがそれに取って代わったというものです。しかし、この関係は誤解です。学術的な分野として、ML はすべてのモデル訓練の側面、現在の AI の中心にある基礎モデルの訓練を含みます。ただし、スケールとデータの複雑さには、重要な違いがあります。

従来の ML モデルは、通常、慎重にキュレーションされた、ドメイン固有のデータセットに基づいて訓練されます。このデータセットには、数千または数百万の例が含まれています。一方、基礎モデルは、同時に数千のデータセットに基づいて訓練されます。これらのデータセットは、さまざまなソースから取得され、形式、出典、品質が一貫しません。このデータのスケールとヘテロジニアス性の違いは、データ管理がより困難で重要になる理由です。

これは、モデル開発の自動化における重要なボトルネックです。ヘテロジニアスなデータを解釈し、周囲のパイプラインを改善できる AI システムは、原則として、自身の訓練プロセスを改善し、より優れたモデルを構築するのに役立ちます。AI が訓練プロセスを改善できるようになると、AI が適用されるすべてのドメインに改善が広がります。

道に立ちはだかる 3 つの障壁

最初の障壁は、コンテキストの断片化です。ほとんどの組織では、特定のモデリング問題に関連するシグナル、実験、機能定義、機関の知識は、相互に通信するように設計されていないデータウェアハウス、ノートブック、パイプラインに散在しています。ヘルスケアシステムが敗血症検出モデルを構築することを考えてみましょう。該当する臨床基準、たとえば重要なしきい値、ラボ値、文書化基準は、電子ヘルスレコードシステムのまったく別のモジュールに存在する可能性があります。

2 番目の障壁は、意味の曖昧さです。意味はデータに内在するのではなく、文脈と組織によって決まります。2 つの異なるデータベースの同じフィールド名は、微妙に異なるものを指す可能性があります。収益、有効ユーザー、チャーンなどの概念は、1 つの会社内で複数の有効な定義を持つことができます。収益という概念は、問題を引き起こす可能性があります。セールスチームは、収益を今期に署名された契約の総額として定義するかもしれませんが、財務チームは、実際に受け取った現金として定義する可能性があります。製品チームは、別の理解を持っています。つまり、サブスクリプション期間にわたる収益を認識することを意味します。3 つのチームすべてが、それぞれのシステムの「収益」という名前のフィールドから情報を取得していますが、チーム間のレポートを組み合わせると、3 つの互換性のない数字が静かに混在します。

3 番目で最もシステム的な障壁は、文書化された組織の記憶の欠如です。出典を追跡し、不一致を解決し、多数のソース間で信号の品質を維持することは、人間のチームにとっても未解決の問題です。何が試みられ、どれほどうまくいったかという記憶がなければ、モデル自動化メカニズムは、同じ死角を再発見し続け、時間とリソースを浪費します。

小売会社のデータサイエンスチームが需要予測モデルを構築することを考えてみましょう。3 年間で、12 人のアナリストがそれぞれ独立に、生の天気データが祝日週の間にモデル性能を低下させ、特定のサプライヤーの在庫フィードにシステム的な遅れがあること、および標準的なプロモーションイベントの処理方法がターゲット漏れを引き起こすことを発見しました。当初のアナリストが他のチームに移動したり会社を辞めたりすると、彼らが持っていた知識も一緒に去りました。試みられたこと、失敗したこと、その理由についての記録がなければ、モデル自動化メカニズムは蓄積された経験に基づいて構築することはできません。ゼロから始めなければなりません。繰り返し、時間を無駄に浪費します。

実際の解決策の要件

ML 自動化の歴史は、部分的な解決策の歴史です。AutoML は、ハイパーパラメーターの調整という狭い問題に対処しましたが、目的の不一致や組織の意図について推論することはできませんでした。MLOps は、プロダクション パイプラインをより堅牢で監視しやすいものにしましたが、MLOps ツールは戦略を実行するだけで定義することはできません。より最近のコーディング エージェントは、実際の進歩を表していますが、同じ盲点を継承しています。コードを生成するのはうまくいきますが、組織のコンテキストや機関の記憶が欠けています。

真正に自律的な ML エンジニアリングが可能なシステムは、現在のツールでは提供されていない機能が必要です。ビジネス目標をモデル目標にマッピングする必要があります。これは、データから推測できない翻訳です。断片化されたシステムに散在する関連データを発見し、自動的にコンプライアンス、ガバナンス、セキュリティの制約に従う必要があります。人間が別のプロセスとして管理するのではなく、既存の作業を浮き彫りにし、過去の実験がなぜ放棄されたかを理解し、同僚がすでに知っていることの上に構築するための機関の記憶が必要です。

データバージョン、機能定義、コードコミットをまたいで出典を追跡する厳格な監査証跡が、システムを実際に何が起こったかに根ざすための核心メカニズムとして必要です。また、人間とシステムの相互作用のレベルに応じて、タスク、利害関係、システムの自信に応じて、思慮深い人間とシステムの相互作用の設計が必要です。重要な時点での人間の判断をバイパスする自動化は、うまく設計された AI の機能ではありません。失敗モードです。

まだ解決されていないのは、組織のデータの意味を理解するセマンティック理解の作成です。特定の機関のコンテキストでデータが何を意味するかを理解することです。MCP は、接続性の問題を解決します。まだ意味の問題を解決しません。それは、まだ開かれた研究のフロンティアです。

何が可能になるか

これらの問題を解決することの経済的影響は大きいです。現在、カスタム ML 開発には、専門の実践者と数週間の反復が必要です。問題定義からデータ発見、モデル開発、モデル評価までの全ワークフローを自律的にナビゲートできるシステムは、その方程式を劇的に変え、タイムラインを圧縮し、現在はリソースが不足しているため追求できない、高価値のユースケースを開放します。数週間かけて深い ML の専門知識を持つチームで行っていたプロジェクトは、ML の専門家の時間をあまり使わずに数日で完了できます。

コンテキストの断片化、意味の曖昧さ、機関の記憶の欠如という課題は、エンタープライズ ML に固有のものではありません。基礎モデルトレーニングパイプラインの構築では、数千のヘテロジニアスなデータセットを集め、フィルタリングし、反復的に改良する必要があります。2 つの設定は構造と目的で異なりますが、両方とも同じ根本的なボトルネックによって制限されています。コンテキストを回復し、出典を追跡し、反復をまたいで以前の作業の上に構築することができるシステムが不足していることです。エンタープライズでのモデル開発の自動化は、自己改善が可能な AI システムへの道における重要なステップです。