MLOps 実践者のための GenAIOps
この記事では、既存の MLOps 投資があり、その投資を拡張してワークロードに生成 AI を含めることに関心のあるワークロード チームにガイダンスを提供します。 生成 AI ワークロードを運用化するには、MLOps への投資を GenAIOps (狭義では LLMOps と呼ばれることもあります) に拡張する必要があります。 この記事では、従来の機械学習と生成 AI ワークロードに共通する技術パターンと、生成 AI に特有のパターンについて概説します。 この記事は、運用化において既存の投資を適用できる場所と、それらの投資を拡張する必要がある場所を理解するのに役立ちます。
生成AIの技術パターン
生成 AI ワークロードは、従来の機械学習ワークロードとはいくつかの点で異なります。
生成モデルに重点を置く - 従来の機械学習ワークロードは、特定のタスクを実行するようにトレーニングされた新しいモデルのトレーニングに重点を置いています。 生成 AI ワークロードは、より幅広いユースケースに対応するために使用できる生成モデルを消費し、場合によってはマルチモーダルになります。
モデルの拡張に重点を置く - 従来の機械学習における重要な資産は、展開されたモデルです。 モデルへのアクセスは 1 つ以上のワークロード内のクライアント コードに提供されますが、ワークロードは MLOps プロセスの一部ではありません。 生成 AI ソリューションでは、生成モデルに提供されるプロンプトがソリューションの重要な側面となります。 プロンプトは作成する必要があり、1 つ以上のデータ ストアからのデータを含めることができます。 ロジックを調整し、さまざまなバックエンドを呼び出し、プロンプトを生成し、生成モデルを呼び出すシステムは、GenAIOps で管理する必要がある生成 AI システムの一部です。
一部の生成 AI ソリューションでは、モデルのトレーニングやチューニングなどの従来の機械学習手法が使用されていますが、いずれも標準化する必要がある新しいパターンを導入しています。 このセクションでは、生成 AI ソリューションの技術パターンの 3 つの大まかなカテゴリの概要を示します。
- 事前トレーニングとチューニング
- プロンプト エンジニアリング
- 検索拡張生成 (RAG)
言語モデルのトレーニングとチューニング
現在、多くの生成 AI ソリューションでは、使用前にチューニングする必要のない既存の基礎言語モデルが使用されています。 とはいえ、基礎モデルをチューニングするか、小規模言語モデル (SLM) などの新しい生成 AI モデルをトレーニングすることでメリットが得られるユースケースもあります。
新しい SLM のトレーニングや生成基盤モデルのチューニングは、論理的には従来の機械学習モデルのトレーニングと同じプロセスです。 これらのプロセスでは、既存の MLOps 投資を活用する必要があります。
プロンプト エンジニアリング
プロンプト エンジニアリングには、生成モデルへの入力として送信されるプロンプトの生成に関わるすべてのプロセスが含まれます。 通常、プロンプトを生成するワークフローを制御するオーケストレーターが存在します。 オーケストレーターは、任意の数のデータ ストアを呼び出してグラウンディング データなどの情報を収集し、必要なロジックを適用して最も効果的なプロンプトを生成できます。 次に、オーケストレーターは、インテリジェント アプリケーションのクライアント コードによってアクセスされる API エンドポイントとして展開されます。
図 1. 迅速なエンジニアリングアーキテクチャ
このカテゴリの技術パターンは、次のような多くのユースケースに対応できます。
- 分類
- 翻訳
- 概要
- 次のセクションで説明する検索拡張生成
検索拡張生成
検索拡張生成 (RAG) は、ドメイン固有のデータを言語モデルの基盤データとして使用することを目的としたプロンプト エンジニアリングを使用するアーキテクチャ パターンです。 言語モデルは特定のデータセットに対してトレーニングされます。 ワークロードによっては、会社、顧客、またはドメインに固有のデータに対する推論が必要になる場合があります。 RAG ソリューションでは、データがクエリされ、その結果が通常はオーケストレーション レイヤーを通じてプロンプトの一部として言語モデルに提供されます。
一般的な RAG 実装では、ドキュメントをチャンクに分割し、メタデータとともにベクター ストアに保存します。 Azure AI Search などのベクター ストアを使用すると、テキストとベクターの両方の類似性検索を実行して、コンテキストに関連する結果を返すことができます。 RAG ソリューションは、 他のデータ ストアを使用 してグラウンディング データを返すこともできます。
図 2. 検索拡張生成（RAG）アーキテクチャ
生成型 AI 技術パターンのための MLOps の拡張
このセクションでは、生成 AI 技術パターンの内部ループ フェーズと外部ループ フェーズの次の重要な側面を検討し、既存の MLOps 投資を適用できる場所と拡張する必要がある場所を確認します。
DataOps
MLOps と GenAIOps はどちらも DataOps の基礎を使用して拡張可能で再現可能なワークフローを作成し、実験と評価のためにデータが正しくクリーンアップ、変換、フォーマットされるようにします。 ワークフローの再現性とデータのバージョン管理は、すべての技術パターンにおいて DataOps にとって重要な機能ですが、データのソース、タイプ、および意図はパターンに依存します。
トレーニングとチューニング
この技術パターンでは、MLOps 実装の一環として行った既存の DataOps 投資を最大限に活用する必要があります。 再現性とデータのバージョン管理により、さまざまな特徴エンジニアリング データを試し、さまざまなモデルのパフォーマンスを比較し、結果を再現できます。
RAGと迅速なエンジニアリング
RAG ソリューションのデータの目的は、プロンプトの一部として言語モデルに提示される基礎データを提供することです。 RAG ソリューションでは、多くの場合、大規模なドキュメントを適切なサイズで意味的に関連するチャンクのコレクションに処理し、それらのチャンクをベクター ストアに永続化する必要があります。 詳細については、 RAG ソリューションの設計と開発 を参照してください。 RAG ソリューションの再現性とデータのバージョン管理により、さまざまなチャンキングおよび埋め込み戦略を試し、パフォーマンスを比較し、以前のバージョンにロールバックすることができます。
ドキュメントをチャンク化するためのデータ パイプラインは、従来の MLOps の DataOps の一部ではないため、アーキテクチャと操作の両方を拡張する必要があります。 データ パイプラインは、構造化データと非構造化データの両方を含む複数の異なるソースからデータを読み取ることができます。 変換されたデータを別のターゲットに書き込むこともできます。 データのグラウンディングに使用するデータ ストアを含めるようにアーキテクチャを拡張する必要があります。 これらのパターンに共通するデータ ストアは、Azure AI Search などのベクター ストアです。 トレーニングやチューニングと同様に、Azure Machine Learning パイプラインやその他のデータ パイプライン ツールを利用して、チャンク化のステージを調整できます。 Azure Machine Learning パイプラインのプロンプト フローを活用して、一貫性と再現性のある方法でデータを処理および強化することができます。 また、データ ストア内の検索インデックスの最新性と有効性を維持するために、操作を拡張する必要があります。
実験
内部ループの一部として、実験はソリューションの構築、評価 (次のセクションで説明)、改良を繰り返すプロセスです。 次のセクションでは、一般的な生成 AI 技術パターンの実験について説明します。
トレーニングとチューニング
既存の言語モデルをチューニングしたり、小さな言語モデルをトレーニングしたりするときに、現在の MLOps 投資を活用できます。 たとえば、Azure Machine Learning パイプラインは、実験を効率的かつ効果的に実行するための強力なツールキットを提供します。 これらのパイプラインを使用すると、データの前処理からモデルのトレーニングと評価まで、チューニングプロセス全体を管理できます。
RAGと迅速なエンジニアリング
プロンプト エンジニアリングと RAG ワークロードの実験には、MLOps への投資を拡張する必要があります。 これらの技術パターンの場合、ワークロードはモデルで終了しません。 ワークロードには、ロジックの実行方法、グラウンディング データなどの必要な情報を取得するためにデータ ストアを呼び出す方法、プロンプトを生成する方法、言語モデルを呼び出す方法などを認識しているシステムであるオーケストレーターが必要です。 データ ストアとストア内のインデックスもワークロードの一部です。 ワークロードのこれらの側面を管理するには、運用を拡張する必要があります。
プロンプト エンジニアリング ソリューションには、さまざまな指示、ペルソナ、例、制約、プロンプト チェーンなどの高度な手法など、実験できる複数の側面があります。 RAG ソリューションを実験する場合、次の領域を含む追加の実験領域があります。
- チャンク戦略
- チャンクを充実させるべきものとその方法
- 埋め込みモデル
- 検索インデックスの設定
- 実行する検索 (ベクター、フルテキスト、ハイブリッドなど)
DataOpsで説明したように、実験の鍵となるのは再現性とデータのバージョン管理です。 優れた実験フレームワークを使用すると、ハイパーパラメータやプロンプトの変更などの入力を、 実験を評価するときに使用する出力とともに保存できます。
既存の MLOps 環境と同様に、Azure Machine Learning パイプラインなどのフレームワークを利用できます。 Azure Machine Learning パイプラインには、インデックス作成をサポートし、Azure AI Search などのベクター ストアと統合する機能があります。 GenAIOps 環境では、パイプラインのこれらの機能を活用し、プロンプト エンジニアリングとカスタム前処理ロジックを管理するプロンプト フロー機能と組み合わせることができます。
評価と実験
評価は、ソリューションを構築、評価、改良する反復的な実験プロセスにおいて重要です。 変更を評価すると、改良を加えたり、現在の反復が要件を満たしていることを検証したりするために必要なフィードバックが提供されます。 次のセクションでは、一般的な生成 AI 技術パターンの実験フェーズでの評価について説明します。
トレーニングとチューニング
チューニングまたはトレーニングされた生成 AI モデルの評価には、既存の MLOps 投資を活用する必要があります。 たとえば、Azure Machine Learning パイプラインを使用して機械学習モデルのトレーニングを調整している場合は、基礎言語モデルのチューニングや新しい小規模言語モデルのトレーニングに同じ評価機能を利用できます。 これらの機能には、特定のモデル タイプに対して業界標準の評価メトリックを計算し、モデル間で結果を比較する モデル評価コンポーネント を活用することが含まれます。
RAGと迅速なエンジニアリング
生成 AI ソリューションを評価するには、既存の MLOps 投資を拡張する必要があります。 評価のための堅牢なフレームワークを提供するプロンプトフローなどのツールを活用できます。 プロンプト フローを使用すると、チームはカスタム評価ロジックを定義し、さまざまな プロンプト バリアント と言語モデル (LLM) のパフォーマンスを評価するための基準とメトリックを指定できます。 この構造化されたアプローチにより、ハイパーパラメータの調整やアーキテクチャのバリエーションなどのさまざまな構成を並べて比較し、特定のタスクに最適な設定を特定できます。
プロンプトフローのジョブは、実験プロセス全体を通じて入力データと出力データを自動的にキャプチャし、包括的な試験記録を作成します。 このデータを分析することで洞察を得て、将来の反復に役立つ有望な構成を特定できます。 プロンプトフローを使用して効率的かつ体系的な実験を実施することで、生成 AI ソリューションの開発を加速できます。
実験プロセスは、分類、要約、翻訳、さらには RAG など、生成 AI ソリューションのユースケースに関係なく同じです。 重要な違いは、さまざまなユースケースを評価するために使用するメトリックです。 以下は、ユースケースごとに考慮すべきメトリックの例です。
- 翻訳: BLEU
- 要約：ROUGE。 BLEU, BERTScore, METEOR
- 分類: 精度、再現率、正確度、クロスエントロピー
- RAG: 根拠、関連性
Note
言語モデルと RAG ソリューションの評価の詳細については、 LLM エンドツーエンド評価 を参照してください。
一般的に、生成 AI ソリューションは、機械学習チームの責任をモデルのトレーニングからエンジニアリングの促進、グラウンディング データの管理まで拡張します。 プロンプト エンジニアリングと RAG の実験と評価には必ずしもデータ サイエンティストは必要ないため、ソフトウェア エンジニアやデータ エンジニアなどの他の役割でこれらの機能を実行することは魅力的です。 プロンプト エンジニアリングと RAG ソリューションの実験からデータ サイエンティストを除外すると、課題に直面することになります。 他の役割では、多くのデータ サイエンティストのように結果を科学的に評価する方法についてのトレーニングは受けられません。 生成 AI ソリューションの設計の複雑さを理解するには、7 部構成の記事シリーズ RAG ソリューションの設計と開発 をお読みください。
生成 AI ソリューションに投資することで、データ サイエンス リソースの負担を軽減できます。 これらのソリューションではソフトウェア エンジニアの役割が拡大します。 たとえば、ソフトウェア エンジニアは、生成 AI ソリューションのオーケストレーション責任を管理する優れたリソースであり、プロンプト フローなどのツールで評価メトリックを設定することに長けています。 この作業はデータ サイエンティストの厳しい監視の下で行うことが重要です。 データ サイエンティストは、実験を適切に評価する方法を理解するためのトレーニングと経験を持っています。
展開
生成 AI ソリューションの中には、カスタムトレーニング済みモデルの導入や既存モデルのチューニングを必要とするものもあれば、そうでないものもあります。 生成 AI ソリューションは、オーケストレーターとデータ ストアを展開するための追加の責任を伴います。 次のセクションでは、一般的な生成 AI 技術パターンの展開について説明します。
トレーニングとチューニング
生成 AI モデルの導入と基礎モデルのチューニングには、既存の MLOps 投資を活用し、必要に応じて調整を加える必要があります。 たとえば、Azure OpenAI で大規模な言語モデルをチューニングするには、トレーニング データセットと検証データセットが JSONL 形式であることを確認し、REST API 経由でデータをアップロードする必要があります。 チューニングジョブも作成する必要があります。 トレーニング済みの小規模言語モデルをデプロイすると、既存の MLOps 投資を活用できます。
RAGと迅速なエンジニアリング
RAG およびプロンプト エンジニアリングの場合、オーケストレーション ロジック、インデックスやスキーマなどのデータ ストアの変更、データ パイプライン ロジックの変更など、展開する必要がある追加の考慮事項があります。 オーケストレーション ロジックは通常、プロンプト フロー、セマンティック カーネル、LangChain などのフレームワークにカプセル化されます。 現在カスタム モデルをデプロイしているリソースを含む、さまざまなコンピューティング リソースにオーケストレーターをデプロイできます。 Azure Machine Learning マネージド オンライン エンドポイントまたは Azure アプリ Service にプロンプト フローをデプロイする例についてはBaseline Azure OpenAI のエンド ツー エンド のチャットリファレンス アーキテクチャに関するページを参照してください。 Azure App Service にデプロイするために、ベースラインの Azure OpenAI チャット アーキテクチャは、フローとその依存関係をコンテナーとしてパッケージ化します。これにより、さまざまな環境間での移植性と一貫性が向上します。
データ モデルやインデックスの変更など、データベース リソースへの変更の展開は、GenAIOps で処理する必要がある新しい責任です。 大規模な言語モデルを扱う場合の一般的な方法は、 LLM の前でゲートウェイを使用することです。
Azure OpenAI から提供されるものなど、プラットフォームでホストされる言語モデルを使用する多くの生成 AI アーキテクチャには、 Azure API Management などのゲートウェイ が含まれています。 ゲートウェイの使用例には、負荷分散、認証、監視などが含まれます。 ゲートウェイは、新しくトレーニングされたモデルやチューニングされたモデルの展開に役割を果たし、新しいモデルを段階的に展開できるようにします。 ゲートウェイをモデルのバージョン管理とともに使用すると、変更を展開する際のリスクを最小限に抑え、問題が発生した場合は以前のバージョンにロールバックできます。
オーケストレーターなどの生成 AI 固有の問題の展開は、次のような適切な運用手順に従う必要があります。
- ユニットテストを含む厳格なテスト
- 統合テスト
- A/Bテスト
- エンドツーエンド テスト
- カナリアやブルー/グリーンデプロイメントなどの戦略を展開する
生成 AI アプリケーションの展開責任はモデル デプロイだけにとどまらないため、ユーザー インターフェイス、オーケストレーター、データ ストアなどの展開と監視を管理するための追加の職務が必要になる場合があります。 多くの場合、これらのロールは DevOps エンジニア スキル セットに合わせて調整されます。
推論と監視
推論とは、トレーニングされデプロイされたモデルに入力を渡し、応答を生成するプロセスです。 従来の機械学習ソリューションと生成 AI ソリューションの両方を、運用監視、運用からの学習、リソース管理という 3 つの観点から監視する必要があります。
運用監視
運用監視は、データ操作 (DataOps) やモデル トレーニングなど、システムの進行中の操作を監視することに関係します。 エラー、エラー率の変化、処理時間の変化などの偏差を探します。
モデルのトレーニングとチューニングの場合、一般的には、特徴データの処理、モデルのトレーニング、チューニングに関するデータ操作を観察している運用プロセスです。 これらの内部ループの問題の監視には、既存の MLOps および DataOps への投資を活用する必要があります。
生成 AI ソリューションの迅速なエンジニアリングには、追加の監視に関する懸念事項があります。 プロンプトの生成に使用されるグラウンディング データやその他のデータを処理するデータ パイプラインを監視する必要があります。 この処理には、インデックスの構築や再構築などのデータ ストア操作が含まれる場合があります。
生産から学ぶ
推論段階での監視の重要な側面は、実稼働環境から学習することです。 従来の機械学習モデルの監視では、精度、適合度、再現率などの指標を追跡します。 重要な目標は、予測のドリフトを防ぐことです。 分類に GPT モデルを使用するなど、予測を行うために生成モデルを使用しているソリューションでは、既存の MLOps モニタリング投資を使用する必要があります。
生成モデルを使用してグラウンディング データを推論するソリューションでは、 グラウンディング性、完全性、利用率、関連性などのメトリックが使用されます。 目標は、モデルがクエリに完全に答え、そのコンテキストに基づいて応答していることを確認することです。 ここでは、データドリフトなどの問題を防止します。 モデルに提供する基礎データとプロンプトが、ユーザーのクエリに最大限関連していることを確認する必要があります。
RAG ソリューションなど、非予測タスクに生成モデルを使用するソリューションは、エンドユーザーからの有用性の感情を評価するために人間からのフィードバックを活用することがよくあります。 ユーザー インターフェイスは、親指の賛成/反対などのフィードバックをキャプチャでき、このデータを使用して応答を定期的に評価できます。
生成 AI ソリューションの一般的なパターンは、 生成モデルの前にゲートウェイを展開することです。 ゲートウェイの使用例の 1 つは、基礎モデルを監視することです。 ゲートウェイを使用して、入力プロンプトと出力をログに記録できます。
生成ソリューションを監視するためのもう 1 つの重要な領域は、コンテンツの安全性です。 目標は、応答を調整し、有害または望ましくないコンテンツを検出することです。 Azure AI Content Safety Studio は、コンテンツをモデレートするために使用できるツールの例です。
リソース管理
Azure OpenAI など、サービスとして公開されているモデルを使用する生成ソリューションの場合、自分でデプロイするモデルとは異なるリソース管理上の懸念事項があります。 インフラストラクチャではなく、サービスのスループット、クォータ、スロットルについて懸念しています。 Azure OpenAI は、課金、スロットル、クォータにトークンの概念を使用します。 コスト管理とパフォーマンス効率のために、クォータの使用状況を監視する必要があります。 Azure OpenAI を使用すると、トークンの使用状況をログに記録できます。
ツール
多くの MLOps 実践者は、自動化、追跡、展開、実験などのさまざまなアクティビティを整理するためのツールキットを標準化し、それらのプロセスの多くの共通の懸念事項と実装の詳細を抽象化しています。 共通の統合プラットフォームは MLflowです。 GenAIOps パターンをサポートする新しいツールを探す前に、既存の MLOps ツールを調べて、生成 AI のサポートを評価する必要があります。 たとえば、MLflow は 言語モデルの幅広い機能をサポートしています。
MLOps と GenAIOps の成熟モデル
現在の MLOps 投資の一環として、 MLOps 成熟度モデルを使用して 機械学習の運用と環境の成熟度を評価している可能性があります。 生成 AI ワークロードに対する MLOps 投資を拡大する場合は、GenAIOps 成熟度モデル を使用してそれらの操作を評価する必要があります。 2 つの成熟度モデルを組み合わせたいと思うかもしれませんが、それぞれを個別に測定することをお勧めします。 MLOps と GenAIOps は互いに独立して進化します。 たとえば、MLOps 成熟度モデルではレベル 4 に達しているが、生成 AI を始めたばかりで、まだレベル 1 に過ぎない場合があります。
まとめ
MLOps への投資を拡張して生成 AI を含めるようにし始める場合、最初からやり直す必要がないことを理解することが重要です。 既存の MLOps への投資は、一部の生成 AI 技術パターンに使用できます。 生成モデルのチューニングは良い例です。 プロンプト エンジニアリングや RAG などの生成 AI ソリューションの領域には、まったく新しいプロセスがあり、既存の運用投資を拡張して新しいスキルを習得する必要があります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- パウロ・ラセルダ |クラウド ソリューション アーキテクト - Microsoft
- Marco Aurelio Cardoso | シニア ソフトウェア エンジニア - Microsoft
- Luiz Braz | シニア テクニカル スペシャリスト - Microsoft
- Ritesh Modi | プリンシパル ソフトウェア エンジニア - Microsoft
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。