AIのライフサイクルとは。

AIライフサイクルは、最初の決定から、人工知能を使って特定の問題を解決するまで、そしてトレーニング済みモデルを現実世界のワークフローで積極的に使用するまでのすべてを含みます。AIライフサイクルの概念は、機械学習オペレーション（MLOps）やAI管理システム（AIMS）と密接に関連しており、いずれもAIの開発、ガバナンス、保守に体系的なアプローチを含んでいます。

AI開発ライフサイクルという概念の中心は、AIソリューションは孤立して設計またはデプロイされるものではないという事実です。AIソリューションは動的なシステムであり、その持続的な有効性は慎重な計画と入念な監視にかかっています。AIの開発と実装のプロセスの各段階の間には重要な依存関係があります。これらの依存関係を理解することは、成功し、スケーラブルで持続可能なAI搭載ソリューションを構築するために不可欠です。

この記事では、AIライフサイクルの各重要なステップを詳しく説明します。

AIライフサイクル・マネジメントの最初の、そして間違いなく最も重要なフェーズは計画フェーズです。AIアプリケーションのユースケース、つまりAIを使って解決しようとする問題と、その解決のためにAIが実行できる具体的なタスクを特定することです。その後のすべての決定は、計画プロセス中に行われた決定を参照する必要があります。

綿密に準備し、あらゆる不測の事態を考慮することが重要です特定の考慮事項を省略すると、作業が節約されることはなく、作業が延期され、悪化するだけです。特定の専門知識や視点からメリットを得るため、また、ここから物事がどのように進むかについてコンセンサスが得られるように、計画段階ですべての関連する利害関係者を参加させて相談する必要があります。

• AIプロジェクトの範囲を定義する。AIソリューションは、問題のどの側面で機能するか、または役立ちますか。どの側面が範囲外なのか、

• ニーズを定義する。AIを活用する問題領域では、何をする必要があるでしょうか既存のAI機能の観点からこのプロジェクトを推進するために利用できるリソースの観点から、何が実現可能で何が実現不可能かを理解することが重要です。

• 成功を定義する。定性的に、そして（特に）定量的に、何を成功と見なすことができるでしょうか。早期に成功のメトリクスを確立することで、設計上の決定を導き、AIシステムの開発と最適化を管理することができます。

• リスクを評価する。これまでに対象範囲を絞ったAIソリューションが、組織やユーザーに悪影響を及ぼす可能性のある方法を特定してください。倫理的リスク、風評リスク、財務リスクは、データ収集段階に進む前にフラグを立てて対処する必要があります。特に、不十分なデータ管理がそのようなリスクの原因となることが多いためです。

技術レベルでは、トレーニング・データの品質と量は、AIモデルの強度において最も重要な要素です。

すべての機械学習は応用パターン認識に依存していることを考えてみましょう。トレーニングされた機械学習モデルは、トレーニング・データから「学習」したパターンを使用して、特定のインプットに対する最適なアウトプットを推測します。学習するパターンが、実際のアプリケーションで推論を実行する新しいデータのパターンと一致していることを保証するには、十分なデータ品質が必要です。モデルが利用する必要があるすべてのパターンを学習していることを保証し、過剰適合を回避するには、十分なデータ量が必要です。

Hugging FaceやKaggleのようなプラットフォームを通じて利用可能なオープンソースデータ・セットから、ウェブ・スクレイピング、組織独自のデータの活用まで、利用可能な関連データ・ソースを評価します。高品質のデータが極端に不足していたり、高価だったりする場合、合成データがギャップを埋めることがあります。

未加工データを機械学習の準備ができていることはほとんどありません。通常、モデルのトレーニング・パイプラインで使用するためには、ある程度の前処理が必要です。主要な機能エンジニアリングは、このプロセスで重要な役割を果たします。

教師あり学習ではデータのラベリングが必要であり、これには少なくともある程度の時間のかかる人間の手作業が多くの場合必要になります（自動化によってプロセスが効率化されることも多いが）。一部の専門的なデータ領域でのラベリングには、専門家の意見が必要になります。事前にラベル付けされたデータを含むデータ・セットであっても、ラベルの正確性と特定のユースケースへの関連性を確認するために検査する必要があります。

さまざまなデータ・ソースから抽出されたデータを正規化し、単位と形式の点で統一する必要があります。例えば、摂氏と華氏の両方の気象データでモデルをトレーニングすると、必然的に失敗につながります。

モデルのトレーニング後にデータを単に破棄してはなりません。システムを監査したり、性能の問題を調査したり、モデルを複製したり、GDPRや類似のフレームワークの規制要件に準拠したりする必要が生じた場合に備えて、保管・管理しておく必要があります。

適切なデータ・ガバナンスは、AIの説明可能性、データ・プライバシー、規制コンプライアンスにとって不可欠な構成要素であり、特にセンシティブな情報を含むデータを扱う業種・業務やユースケースでは重要です。また、特にAIワークフローが継続的に更新される独自データを利用する場合、スケーラブルなデータソーシングを合理化するためのデータパイプラインを確立するために不可欠なコンポーネントでもあります。

次はモデル選択です。ユースケース、トレーニング用データ、参考情報に最適なモデル・アーキテクチャーを選択することです。機械学習アルゴリズムには、小規模で単純な回帰から大規模で最先端のニューラル・ネットワークまで、膨大な種類が存在します。ディープラーニングモデルが必ずしも賢明な選択とは限りません。巨大なディープラーニング・モデルでは対応しきれないタスクもあれば、従来の機械学習モデルがディープラーニング・モデルよりも優れたパフォーマンスを発揮するタスクもあります。

生成AIに関しては、LLMやその他の種類の生成モデルをゼロからトレーニングするには、時間、データ、ハードウェア、エネルギーに多額の投資が必要です。ほとんどの場合、カスタマイズされた生成モデルの必要性は、事前に訓練されたモデルを 微調整することによってよりよく満たされます。しかし、既製モデルの世界であっても、モデルのサイズ、アーキテクチャー、機能の点で大きなスペクトルがあります。

ベンチマーク評価は、どのモデルが何を得意としているかを判断するための便利なガイドです。しかし、それらをすべての画一語として捉えるべきではありません。問題が明確に定義されている場合、モデルに実行させる必要のある特定のタスクのパフォーマンスを直接反映するカスタムベンチマーク開発の可能性を検討する価値があります。これは、後のモデル評価段階でも役立ちます。

生成AIはさておき、ほとんどのAIソリューションでは、独自のモデルのトレーニングが必要になります。IBMのモデル・トレーニングの解説では、さまざまな種類の機械学習から、損失関数（または強化学習では報酬関数）の選択、モデル・パラメーター（およびハイパーパラメーター）の最適化まで、モデル開発プロセスに関する詳細情報を提供します。通常、理想的なアーキテクチャーと学習スキームに到達する前に、ある程度の実験が必要です。

最終的なモデル・トレーニングの目標は、トレーニング用データ・セット内のサンプルに対するモデルの性能が、許容できる精度のしきい値に達するまで、モデル・パラメーターを調整することです。

モデルのトレーニングは反復的なプロセスであり、常に直線的で安定した方法で進むわけではありません。トレーニング・プロセス全体を通じて、モデルの重みの「チェックポイント」を定期的に保存することが重要です。このようなバージョン管理が行われていないと、1回のモデル更新で悲惨な結果となり、最初からやり直さざるを得なくなる可能性があります。バージョン管理は、デバッグ、再現性、チーム間のコラボレーションにも必要な手法です。

トレーニング・データでモデルの性能を最適化すること自体は、モデル・トレーニングの基本的な目標ではありません。モデル・トレーニングの真の目的は、まだ見たことのない新しいデータに対して適切に一般化できるモデルを開発することです。過剰適合を避けるためには注意が必要です。過剰適合は、機械学習で言うところの「テストに合わせた指導」に相当し、実際の「知識」よりも暗記に近いと理解できます。

モデルが未知のデータに対して適切に一般化されることを確認するために、トレーニング後の評価が不可欠です。この検証プロセスでは、実世界のタスクに似た新しいインプットの別のデータ・セットで、モデルのアウトプット品質をテストします。検証では、トレーニング中にモデルの精度を測定する損失関数に適したものよりも、はるかに幅広い性能メトリクスを使用できます。

モデルの評価とモデルのトレーニングは、通常、1つの反復サイクルの2つの部分を構成します。

• まず、モデルは、損失または報酬が許容できるしきい値を満たすまでトレーニングされます。

• 次に、さまざまな性能メトリクスを使用して、新しい一連のタスクでモデルの性能を検証します。

• モデルの評価の結果が満足のいくものではない場合、モデルはさらなるトレーニング（通常、検証段階で特定された欠点に対処することを目的とした戦略的な調整）が行われます。

モデルがトレーニングされ、検証が正常に完了すると、モデルはデプロイメント段階に移行し、実際の運用環境でモデルを運用し、既存のシステムやAPIと統合します。理想的には、モデルの評価フェーズでは、これらの実際のワークフローを使用するか、少なくともそれに近似したタスクでモデルの性能を検証しています。

モデルのデプロイメントにおいて考慮すべき構成は数多くありますが、おそらく最も重要なのは、動作するデプロイメント環境の種類です。

• オンプレミス・デプロイメント：このモデルは物理的なハードウェア（通常はAIアクセラレーター）上で実行されます。これにより、最も詳細に制御できるようになりますが、最も初期投資も必要になります。

• クラウド・デプロイメント：モデルは、大規模なデータセンターの別の場所に物理的に配置された、サードパーティーのクラウド・プロバイダーが所有・運用するハードウェア上で実行されます。クラウドへのデプロイメントは、一般に、拡張性を実現するための最も迅速な方法です。

• エッジ・デプロイメント：このモデルは、センサーやモノのインターネット（IoT）デバイスなどの分散型ローカル・ネットワークで「エッジ・デバイス」をデプロイします。

• デバイス上でのデプロイメント：モデルは、ノートPCやスマートフォンなどのエンド・ユーザーのデバイス上で直接実行されます。

デプロイされたモデルが、不活性な「完成品」製品と考えられることはほとんどありません。適切なAIガバナンスには、モデルの性能メトリクスとユーザーからのフィードバックを継続的に監視することが必要です。

実際のアプリケーションでは、事前にどれほど綿密に計画、テスト、レッド・チームを行っても、予期せぬ問題やエッジケースが発生することはほぼ避けられません。さらに、最適にトレーニングされたモデルであっても、時間の経過とともにモデル・ドリフトなどの問題により、性能の低下が生じる可能性があります。

したがって、デプロイされたモデルは通常、適切な性能を維持し、変化する状況に適応するために、定期的な再トレーニングが必要です。繰り返しになりますが、デバッグ、説明責任、クリティカルなシステムの更新を安全に行うためには、思慮深いバージョン管理スキーマが重要です。