モデル開発の自動化への重要な道

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 システムが自らを改善できる道への重要なステップです。