MLOps 実践者のための GenAIOps
この記事では、既存の機械学習の運用 (MLOps) 投資があり、その投資を拡張してワークロードに生成 AI を含めることに関心があるワークロード チームにガイダンスを提供します。 生成 AI ワークロードを運用化するには、生成 AI Ops (GenAIOps、または LLMOps と呼ばれる場合あり) を使用して、MLOps 投資を拡張する必要があります。 この記事では、従来の機械学習と生成 AI ワークロードの両方に共通する技術パターンと、生成 AI 特有のパターンについて概説します。 この記事は、運用化において既存の投資を適用できる場所と、それらの投資を拡張する必要がある場所を理解するのに役立ちます。
MLOps と GenAIOps の計画と実装は、Azure 上の AI ワークロードのコア 設計領域の一部です。 これらのワークロードに特殊な操作が必要な理由の背景については、Azure Well-Architected Framework の Azure 上の AI ワークロード用の MLOps と GenAIOps
生成AIの技術パターン
生成 AI ワークロードは、従来の機械学習ワークロードとはいくつかの点で異なります。
生成モデルに焦点を当てます。 従来の機械学習ワークロードは、特定のタスクを実行するようにトレーニングされた新しいモデルのトレーニングに重点を置いています。 生成 AI ワークロードは、より幅広いユース ケースに対応する生成モデルを消費し、場合によってはマルチモーダルになります。
モデルの拡張に重点を置いています。 従来の機械学習の重要な資産は、デプロイされたモデルです。 モデルへのアクセスは 1 つ以上のワークロード内のクライアント コードに提供されますが、ワークロードは MLOps プロセスの一部ではありません。 生成 AI ソリューションでは、生成モデルに提供されるプロンプトがソリューションの重要な側面となります。 プロンプトは作成する必要があり、1 つ以上のデータ ストアからのデータを含めることができます。 ロジックを調整し、さまざまなバックエンドを呼び出し、プロンプトを生成し、生成モデルを呼び出すシステムは、GenAIOps で管理する必要がある生成 AI システムの一部です。
一部の生成 AI ソリューションでは、モデルのトレーニングやチューニングなどの従来の機械学習手法が使用されていますが、いずれも標準化する必要がある新しいパターンを導入しています。 このセクションでは、生成 AI ソリューションの技術パターンの 3 つの大まかなカテゴリの概要を示します。
- 事前トレーニングと微調整
- プロンプト エンジニアリング
- 検索拡張生成 (RAG)
言語モデルのトレーニングとチューニング
現在、多くの生成 AI ソリューションでは、使用前にチューニングする必要のない既存の基礎言語モデルが使用されています。 ただし、一部のユース ケースでは、基礎モデルの微調整や、小規模言語モデル (SLM) などの新しい生成 AI モデルのトレーニングを利用できます。
新しい SLM のトレーニングと生成基盤モデルの微調整は、論理的には従来の機械学習モデルのトレーニングと同じプロセスです。 これらのプロセスでは、既存の MLOps 投資を活用する必要があります。
プロンプト エンジニアリング
プロンプト エンジニアリングには、生成モデルへの入力として送信されるプロンプトの生成に関わるすべてのプロセスが含まれます。 通常、プロンプトを生成するワークフローを制御するオーケストレーターが存在します。 オーケストレーターは、任意の数のデータ ストアを呼び出してグラウンディング データなどの情報を収集し、必要なロジックを適用して最も効果的なプロンプトを生成できます。 次に、オーケストレーターは、インテリジェント アプリケーションのクライアント コードによってアクセスされる API エンドポイントとして展開されます。
次の図は、プロンプト エンジニアリングのアーキテクチャを示しています。
このカテゴリの技術パターンは、次のような多くのユースケースに対応できます。
- 分類。
- 翻訳。
- 要約。
- 検索拡張生成 (次のセクションで説明します)。
検索拡張生成
Retrieval-Augmented Generation (RAG) は、ドメイン固有のデータを言語モデルの基盤データに取り込むことを目的としたプロンプト エンジニアリングを使用するアーキテクチャ パターンです。 言語モデルは特定のデータセットに対してトレーニングされます。 ワークロードによっては、会社、顧客、またはドメイン固有のデータに対する推論が必要になる場合があります。 RAG ソリューションでは、データがクエリされ、その結果が通常はオーケストレーション レイヤーを通じてプロンプトの一部として言語モデルに提供されます。
一般的な RAG 実装では、ドキュメントをチャンクに分割し、メタデータとともにベクター ストアに保存します。 Azure AI Search などのベクター ストアを使用すると、テキストとベクターの両方の類似性検索を実行して、コンテキストに関連する結果を返すことができます。 RAG ソリューションは、 他のデータ ストアを使用 してグラウンディング データを返すこともできます。
次の図に、RAG のアーキテクチャを示します。
生成型 AI 技術パターンのための MLOps の拡張
このセクションでは、生成 AI 技術パターンの内部ループ フェーズと外部ループ フェーズの次の重要な側面を検討し、既存の MLOps 投資を適用できる場所と拡張する必要がある場所について説明します。
DataOps
MLOps と GenAIOps はどちらも DataOps の基礎を適用して拡張可能で再現可能なワークフローを作成し、実験と評価のためにデータが正しくクリーンアップ、変換、フォーマットされるようにします。 ワークフローの再現性とデータのバージョン管理は、すべての技術パターンにおいて DataOps の重要な機能です。 データのソース、型、インテントはパターンに依存します。
トレーニングと微調整
この技術パターンでは、MLOps 実装の一環として行った既存の DataOps 投資を十分に活用する必要があります。 再現性とデータのバージョン管理により、さまざまな特徴エンジニアリング データを実験し、さまざまなモデルのパフォーマンスを比較し、結果を再現できます。
RAGと迅速なエンジニアリング
RAG ソリューションのデータの目的は、プロンプトの一部として言語モデルに提示される基礎データを提供することです。 RAG ソリューションでは、多くの場合、大規模なドキュメントを適切なサイズで意味的に関連するチャンクのコレクションに処理し、それらのチャンクをベクター ストアに永続化する必要があります。 詳細については、 RAG ソリューションの設計と開発 を参照してください。 RAG ソリューションの再現性とデータのバージョン管理により、さまざまなチャンキングおよび埋め込み戦略を試し、パフォーマンスを比較し、以前のバージョンにロールバックすることができます。
ドキュメントをチャンク化するためのデータ パイプラインは、従来の MLOps の DataOps の一部ではないため、アーキテクチャと操作を拡張する必要があります。 データ パイプラインは、構造化データと非構造化データの両方を含む異なるソースからデータを読み取ることができます。 変換されたデータを別のターゲットに書き込むこともできます。 アーキテクチャを拡張して、基盤データに使用するデータ ストアを含める必要があります。 これらのパターンに共通するデータ ストアは、Azure AI 検索などのベクトル ストアです。
トレーニングや微調整と同様に、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 検索などのベクター ストアと統合する機能があります。 GenAIOps 環境では、パイプラインのこれらの機能を活用し、プロンプト エンジニアリングとカスタム前処理ロジックを管理するプロンプト フロー機能と組み合わせることができます。
評価と実験
評価は、ソリューションを構築、評価、改良する反復的な実験プロセスにおいて重要です。 変更を評価すると、改良を加えたり、現在の反復が要件を満たしていることを検証したりするために必要なフィードバックが提供されます。 次のセクションでは、一般的な生成 AI 技術パターンの実験フェーズでの評価について説明します。
トレーニングと微調整
微調整またはトレーニングされた生成 AI モデルを評価するには、既存の MLOps 投資を活用する必要があります。 たとえば、Azure Machine Learning パイプラインを使用して機械学習モデルのトレーニングを調整している場合は、基礎言語モデルの微調整ングや新しい小規模言語モデルのトレーニングに同じ評価機能を利用できます。 これらの機能には、特定のモデル タイプに対して業界標準の評価メトリックを計算し、モデル間で結果を比較する評価モデル コンポーネントを活用することが含まれます。
RAGと迅速なエンジニアリング
生成 AI ソリューションを評価するには、既存の MLOps 投資を拡張する必要があります。 評価用のフレームワークを提供するプロンプト フローなどのツールを使用できます。 プロンプト フローを使用すると、チームは、さまざまなプロンプト バリアントと大規模言語モデル (LLM) のパフォーマンスを評価するための基準とメトリックを指定することで、カスタム評価ロジックを定義できます。 この構造化されたアプローチにより、ハイパーパラメータやアーキテクチャのバリエーションなどのさまざまな構成を並べて比較でき、特定のタスクに適切な設定を特定できます。
プロンプトフローのジョブは、実験プロセス全体を通じて入力データと出力データを自動的にキャプチャし、包括的な試験記録を作成します。 このデータを分析することで洞察を得て、将来の反復に役立つ有望な構成を特定できます。 プロンプト フローを使用して効率的かつ体系的な実験を実施することで、生成 AI ソリューションの開発を加速できます。
実験プロセスは、生成 AI ソリューションのユース ケースに関係なく同じです。 これらのユース ケースには、分類、要約、翻訳、RAG などがあります。 重要な違いは、さまざまなユースケースを評価するために使用するメトリックです。 ユース ケースに基づいて考慮すべきいくつかのメトリックを次に示します。
- 翻訳: BLEU
- 要約：ROUGE。 BLEU, BERTScore, METEOR
- 分類: 精度、再現率、正確度、クロスエントロピー
- RAG: 根拠、関連性
Note
言語モデルと RAG ソリューションの評価の詳細については、「LLM エンドツーエンド評価」を参照してください。
一般的に、生成 AI ソリューションは、機械学習チームの責任をモデルのトレーニングからプロンプト エンジニアリング、グラウンディング データの管理まで拡張します。 プロンプト エンジニアリングと RAG の実験と評価には必ずしもデータ サイエンティストは必要ないため、ソフトウェア エンジニアやデータ エンジニアなどの他のロールでこれらの機能を実行することもできます。 プロンプト エンジニアリングと RAG ソリューションの実験プロセスからデータ サイエンティストを省略すると、課題が発生します。 他のロールでは一般的に、多くのデータ サイエンティストのように結果を科学的に評価するようにトレーニングされていません。 生成 AI ソリューションの設計の複雑さを理解するには、7 部構成の記事シリーズ RAG ソリューションの設計と開発 をお読みください。
生成 AI ソリューションに投資することで、データ サイエンス リソースの負担を軽減できます。 これらのソリューションではソフトウェア エンジニアの役割が拡大します。 たとえば、ソフトウェア エンジニアは、生成 AI ソリューションのオーケストレーション責任を管理する優れたリソースであり、プロンプト フローなどのツールで評価メトリックを設定することに長けています。 データ サイエンティストにこの作業をレビューしてもらう必要があります。 彼らは、実験を適切に評価する方法を理解するためのトレーニングと経験を持っています。
展開
生成 AI ソリューションの中には、カスタムトレーニング済みモデルの導入や既存モデルのチューニングを必要とするものもあれば、そうでないものもあります。 生成 AI ソリューションの場合は、オーケストレーターとデータ ストアをデプロイする追加のタスクを含める必要があります。 次のセクションでは、一般的な生成 AI 技術パターンの展開について説明します。
トレーニングと微調整
既存の MLOps への投資は、多少の調整を加えて、生成 AI モデルをデプロイし、基礎となるモデルを微調整するために使う必要があります。 たとえば、Azure OpenAI で大規模言語モデルを微調整するには、トレーニング データセットと検証データセットが JSONL 形式であることを確認し、REST API 経由でデータをアップロードする必要があります。 チューニングジョブも作成する必要があります。 トレーニング済みの小規模言語モデルをデプロイするには、既存の MLOps 投資を活用できます。
RAGと迅速なエンジニアリング
RAG とプロンプト エンジニアリングの場合、オーケストレーション ロジック、インデックスやスキーマなどのデータ ストアへの変更、データ パイプライン ロジックへの変更など、他の懸念事項があります。 オーケストレーション ロジックは一般的に、プロンプト フロー、セマンティック カーネル、LangChain などのフレームワークにカプセル化されます。 現在カスタム モデルをデプロイしているリソースを含む、さまざまなコンピューティング リソースにオーケストレーターをデプロイできます。 Azure Machine Learning が管理するオンライン エンドポイントまたは Azure App Service にプロンプト フローをデプロイする例については、「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 成熟度モデルを使用して、現在の機械学習の運用と環境を評価する場合があります。 生成 AI ワークロードに対する MLOps 投資を拡大する場合は、GenAIOps 成熟度モデル を使用してそれらの操作を評価する必要があります。 2 つの成熟度モデルを組み合わせたくなるかもしれませんが、それぞれを個別に測定することが推奨されます。 MLOps と GenAIOps は互いに独立して進化します。 たとえば、MLOps 成熟度モデルではレベル 4 ですが、生成 AI の場合はレベル 1 になります。
まとめ
MLOps 投資を拡張して生成 AI を含めるようにする場合、最初からやり直す必要はありません。 既存の MLOps への投資は、一部の生成 AI 技術パターンに使用できます。 生成モデルのチューニングは良い例です。 プロンプト エンジニアリングや RAG などの生成 AI ソリューションの領域には、新しいプロセスがあり、既存の運用投資を拡張して新しいスキルを習得する必要があります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- Luiz Braz |シニア テクニカル スペシャリスト
- Marco Aurelio Cardoso | シニア ソフトウェア エンジニア
- Paulo Lacerda | クラウド ソリューション アーキテクト
- Ritesh Modi | プリンシパル ソフトウェア エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。