「AIプロジェクトはどのように異なるのか」
AIプロジェクトの違いは何ですか
私はよく見込みのあるクライアントから人工知能(AI)ソフトウェアのプロセスを説明するように求められます。そして最近では、MLOpsを実装したいというソフトウェア開発とデータサイエンスの経験豊富なマネージャーからも質問を受けました。
この記事は、AIソフトウェアのプロセスについての包括的な議論ではなく、主要な違いを概説するものです。
背景
AIプロジェクトは実験的な性質を持つため、ソフトウェアプログラムのいくつかまたは多くの部分が時間の経過とともに置き換えられたり変更されたりすることがあります。そのため、変更は通常、顧客/システムの要件ではなく、プロセスのさまざまなステップの結果として生じることが多いです。そのため、実験結果が異なるアプローチを示唆する場合に全体の再構築を必要としないようにシステムを設計することが重要です。実際、科学的なコードの作成には2つの特性があります。数学的なエラーと実験的な性質です。
計算のミスは、コードが意味的に正しい場合でも追跡が難しいことがあります。バグは見つかりません。例外は発生しません。すべてがうまく見えますが、(数値的な)結果が明らかに正しくありません。確率モデルを実装する場合、結果は初期条件やランダムな要素によって良く見えるかもしれません。
- 「Embroid」を紹介します:複数の小さなモデルから埋め込み情報を組み合わせるAIメソッドで、監視なしでLLMの予測を自動的に修正することができます
- 「ONNXフレームワークによるモデルの相互運用性と効率の向上」
- トムソン・ロイターが6週間以内に開発したエンタープライズグレードの大規模言語モデルプレイグラウンド、Open Arena
No Free Lunch Theorem(無償の昼食の定理):どんな2つのアルゴリズムも、パフォーマンスがすべての可能な問題にわたって平均化される場合には等価です。
常に変化する実験的な部分が存在するでしょう。したがって、重要なのは、各コンポーネントを設計して、ほとんどの作業を維持し、次の開発段階の基盤として機能させることです。
そのため、[3]などの多くの記事では、より頑健で再利用可能なコードを作成し、バグを少なくするためのデザインパターンに焦点を当てています。
MLOpsプロセス
MLOpsは、機械学習(ML)モデルを信頼性と効率を持って本番環境に展開および維持するための一連の手法と技術です。MLOpsは、機械学習、DevOps、データエンジニアリングの交差点です。
一般的に、MLOpsプロセスは次の8つのステージで構成されます:
- データの準備
- 特徴エンジニアリング
- モデル設計
- モデルのトレーニングと最適化
- モデルの評価
- モデルの展開
- モデルの提供
- モデルのモニタリング
MLOpsライフサイクルの各ステップは独自のシステム上に構築されていますが、MLアプリケーションをスケーリングするために必要な最小限の接続が必要です。
MLOpsの議論には踏み込まずに、プロジェクトの違いについていくつかの重要なアイデアを特定できます:
- コード、データ、モデルのバージョン管理の必要性
- 継続的なデリバリーと継続的なトレーニング
- モデルの実験の追跡
- 機械学習のフィーチャーの管理
- 本番環境でのモデルのモニタリング
モデルの実験の追跡
伝統的なソフトウェア開発サイクルとは異なり、モデル開発サイクルのパラダイムには2つの主な違いがあります:フィーチャーの管理とモデルのモニタリング。
機械学習のフィーチャーの管理
フィーチャーストアは、いくつかの重要な運用上の課題に対処します。トレーニングと推論の間で一貫したデータセットを提供し、データの偏りや手違いによるデータ漏洩を回避します。トレーニング時のバッチデータおよびストリーミングデータ上でのフィーチャー変換のカスタム機能を提供し、推論時に過去のデータでリクエストを補完することができます。これは大規模な不正行為および異常検出モデル、およびレコメンダーシステムで一般的です。
本番環境でのモデルのモニタリング
時間の経過とともに、機械学習アプリケーションにはさまざまな問題が発生する可能性があります[4]:
- データのドリフト:特徴の値の突然の変更やデータ分布の変化。
- モデル/コンセプトのドリフト:モデルのパフォーマンスがどのように、なぜ、いつ変化するのか。
- モデルの障害:モデルが説明できない理由で失敗することがあります(システムの障害、悪いネットワーク接続、システムの過負荷、悪い入力または破損したリクエスト)。したがって、早期に原因を検出するかその頻度を把握することが重要です。
- 外れ値:外れ値や予期しない状況の場合に、モデルの結果とパフォーマンスを追跡する必要があります。
- データの品質:本番環境で受信したデータがトレーニングデータと同じ方法で処理されていることを確認する。
- システムのパフォーマンス:トレーニングパイプラインの失敗や実行時間の長さ、非常に高いレイテンシなど。
- システムの劣化過負荷:モデルサーバーやサービスの健康状態を常に監視することも重要です。
結論
明らかに、AIプロジェクトの実験的な性質は、従来のソフトウェア開発との重要な違いです。また、MLOpsの文脈でのAIプロジェクトにはいくつかの重要な違いがあります: コード、データ、モデルのバージョン管理の必要性、モデルの実験の追跡、本番環境でのモデルの監視などがあります。
参考文献
[1] E. Alpaydin, Introduction to Machine Learning, 3rd ed., MIT Press, ISBN: 978–0262028189, 2014.
[2] S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 4th ed. Upper Saddle River, NJ: Prentice Hall, ISBN: 978–0–13–604259–4, 2021.
[3] O. Zero, “How to write better scientific code in Python,” Towards Data Science, Feb. 15, 2022.
[4] M. Galarnyk, “Considerations for Deploying Machine Learning Models in Production,” Towards Data Science, Nov. 19, 2021.
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
- Amazon SageMakerを使用して、オーバーヘッドイメージで自己教師ありビジョン変換モデルをトレーニングする
- MLOpsとは何ですか
- LangChain チートシート
- マイクロソフトは、エンタープライズ向けにカスタマイズされたAzure ChatGPTを発表しました
- 「Cheetorと会ってください:幅広い種類の交互に織り交ぜられたビジョン言語の指示を効果的に処理し、最先端のゼロショットパフォーマンスを達成する、Transformerベースのマルチモーダルな大規模言語モデル(MLLMs)」
- メタAIのハンプバック!LLMの自己整列と指示逆翻訳による大きな波を起こしています
- 「3D-VisTAに会いましょう:さまざまな下流タスクに簡単に適応できる、3Dビジョンとテキストの整列のための事前学習済みトランスフォーマー」