MLOps 実践者のための GenAIOps
この記事では、既存の機械学習操作 (MLOps) への投資があり、それらの投資をワークロードに生成 AI を含めるために拡張するワークロード チームにガイダンスを提供します。 ジェネレーティブ AI ワークロードを運用するには、Generative AI Ops (GenAIOps、LLMOps とも呼ばれる) を使用して MLOps への投資を拡張する必要があります。 この記事では、従来の機械学習と生成 AI ワークロードの両方に共通する技術的なパターンと、生成型 AI の特定のパターンについて説明します。 この記事は、運用化に既存の投資を適用できる場所と、それらの投資を拡張する必要がある場所を理解するのに役立ちます。
生成AIの技術パターン
生成 AI ワークロードは、従来の機械学習ワークロードとはいくつかの点で異なります。
生成モデルに焦点を当てます。 従来の機械学習ワークロードは、特定のタスクを実行するようにトレーニングされた新しいモデルのトレーニングに重点を置いています。 生成 AI ワークロードでは、さまざまなユース ケースに対処できるジェネレーティブ モデルが使用されます。場合によってはマルチモーダルです。
モデルの拡張に重点を置く。 従来の機械学習の重要な資産は、デプロイされたモデルです。 モデルへのアクセスは、1 つ以上のワークロードのクライアント コードに提供されますが、ワークロードは MLOps プロセスの一部ではありません。 ジェネレーティブ AI ソリューションでは、ソリューションの重要な側面は、生成モデルに提供されるプロンプトです。 プロンプトは作成する必要があり、1 つ以上のデータ ストアからのデータを含めることができます。 ロジックを調整し、さまざまなバックエンドを呼び出し、プロンプトを生成し、生成モデルを呼び出すシステムは、GenAIOps で管理する必要がある生成 AI システムの一部です。
一部の生成 AI ソリューションでは、モデルトレーニングや微調整などの従来の機械学習プラクティスが使用されますが、それらはすべて標準化する必要がある新しいパターンを導入します。 このセクションでは、生成 AI ソリューションの技術パターンの 3 つの大まかなカテゴリの概要を示します。
- 事前トレーニングと微調整
- プロンプト エンジニアリング
- 検索拡張生成 (RAG)
言語モデルのトレーニングとチューニング
現在、多くの生成 AI ソリューションでは、使用前にチューニングする必要のない既存の基礎言語モデルが使用されています。 ただし、一部のユース ケースでは、基礎モデルの微調整や、小さな言語モデル (SLM) などの新しい生成 AI モデルのトレーニングを利用できます。
新しい SLM のトレーニングと生成基盤モデルの微調整は、従来の機械学習モデルのトレーニングと論理的に同じプロセスです。 これらのプロセスでは、既存の MLOps 投資を活用する必要があります。
プロンプト エンジニアリング
プロンプト エンジニアリングには、生成モデルへの入力として送信されるプロンプトの生成に関連するすべてのプロセスが含まれます。 通常、プロンプトを生成するワークフローを制御するオーケストレーターが存在します。 オーケストレーターは、任意の数のデータ ストアを呼び出して、データの接地などの情報を収集し、必要なロジックを適用して最も効果的なプロンプトを生成できます。 その後、オーケストレーターは、インテリジェント アプリケーションのクライアント コードによってアクセスされる API エンドポイントとしてデプロイされます。
次の図は、プロンプト エンジニアリングのアーキテクチャを示しています。
このカテゴリの技術パターンは、次のような多くのユースケースに対応できます。
- 分類。
- 翻訳。
- 要約。
- 検索拡張生成 (次のセクションで説明します)。
検索拡張生成
取得拡張生成 (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 の一部ではありません。そのため、アーキテクチャと操作を拡張する必要があります。 データ パイプラインは、構造化データと非構造化データの両方を含むさまざまなソースからデータを読み取ることができます。 また、変換されたデータをさまざまなターゲットに書き込むこともできます。 アーキテクチャを拡張して、基盤データに使用するデータ ストアを含める必要があります。 これらのパターンの一般的なデータ ストアは、AI Search などのベクター ストアです。
トレーニングと微調整と同様に、Azure Machine Learning パイプラインまたはその他のデータ パイプライン ツールを使用して、チャンクのステージを調整できます。 Azure Machine Learning パイプラインのプロンプト フローを活用して、一貫性と再現性のある方法でデータを処理および強化することができます。 また、データ ストア内の検索インデックスの最新性と有効性を維持するために、操作を拡張する必要があります。
実験
内部ループの一部である実験は、の作成、
トレーニングと微調整
既存の言語モデルを微調整したり、小さな言語モデルをトレーニングしたりすると、現在の MLOps への投資を活用できます。 たとえば、Azure Machine Learning パイプラインは、効率的かつ効果的に実験を行うためのツールキットを提供します。 これらのパイプラインを使用すると、データの前処理からモデルのトレーニングと評価まで、微調整プロセス全体を管理できます。
RAGと迅速なエンジニアリング
迅速なエンジニアリングと RAG ワークロードを実験するには、MLOps への投資を拡張する必要があります。 これらの技術パターンの場合、ワークロードはモデルで終了しません。 ワークロードにはオーケストレーターが必要です。オーケストレーターは、ロジックの実行、データの接地、プロンプトの生成、言語モデルの呼び出しなどの必要な情報をデータ ストアに呼び出すことができるシステムです。 データ ストアとストア内のインデックスもワークロードの一部です。 ワークロードのこれらの側面を管理するには、操作を拡張する必要があります。
さまざまな命令、ペルソナ、例、制約、プロンプト チェーンなどの高度な手法など、プロンプト エンジニアリング ソリューションの複数のディメンションを試すことができます。 RAG ソリューションを実験する際には、追加の領域も実験できます。
- チャンク戦略
- チャンクをエンリッチする内容と方法
- 埋め込みモデル
- 検索インデックスの設定
- 実行する検索 (ベクター、フルテキスト、ハイブリッドなど)
DataOpsで説明したように、再現性とデータのバージョン管理は実験の鍵となります。 適切な実験フレームワークを使用すると、ハイパーパラメーターやプロンプトの変更などの入力と、実験を評価するときに使用する出力
既存の MLOps 環境と同様に、Azure Machine Learning パイプラインなどのフレームワークを利用できます。 Azure Machine Learning パイプラインには、AI Search などのベクター ストアと統合することでインデックス作成をサポートする機能があります。 GenAIOps 環境では、これらのパイプライン機能を利用し、プロンプト エンジニアリングとカスタム前処理ロジックを管理するプロンプト フロー機能と組み合わせることができます。
評価と実験
評価は、ソリューションを構築、評価、改良する反復的な実験プロセスにおいて重要です。 変更の評価では、調整を行うか、現在のイテレーションが要件を満たしていることを検証するために必要なフィードバックが提供されます。 次のセクションでは、一般的な生成 AI 技術パターンの実験フェーズでの評価について説明します。
トレーニングと微調整
微調整またはトレーニングされた生成 AI モデルを評価するには、既存の MLOps 投資を活用する必要があります。 たとえば、Azure Machine Learning パイプラインを使用して機械学習モデルのトレーニングを調整する場合、同じ評価機能を使用して基礎言語モデルを微調整したり、新しい小さな言語モデルをトレーニングしたりできます。 これらの機能には、特定のモデルの種類の業界標準の評価メトリックを計算し、モデル間で結果を比較する Evaluate Model コンポーネントが含まれます。
RAGと迅速なエンジニアリング
既存の MLOps 投資を拡張して、生成型 AI ソリューションを評価する必要があります。 評価用のフレームワークを提供するプロンプト フローなどのツールを使用できます。 プロンプト フローを使用すると、さまざまな プロンプト バリアント および大規模言語モデル (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 のエンド ツー エンド チャット アーキテクチャの を参照してください。 App Service にデプロイするために、Azure OpenAI チャット アーキテクチャはフローとその依存関係をコンテナーとしてパッケージ化します。これは、さまざまな環境間で移植性と一貫性を高める手法です。
データ モデルやインデックスの変更など、データベース リソースへの変更のデプロイは、GenAIOps で処理する必要がある新しいタスクです。 大規模な言語モデルを扱う場合の一般的な方法は、 LLM の前でゲートウェイを使用することです。
プラットフォームでホストされる言語モデルを使用する多くの生成 AI アーキテクチャには、Azure OpenAI から提供されているものと同様に、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 になります。
まとめ
ジェネレーティブ AI を含むように MLOps の投資を拡張し始める際には、最初からやり直す必要はないと理解しておくことが重要です。 既存の MLOps への投資は、一部の生成 AI 技術パターンに使用できます。 生成モデルのチューニングは良い例です。 プロンプト エンジニアリングや RAG などの生成 AI ソリューションには新しいプロセスの領域があるため、既存の運用投資を拡張し、新しいスキルを獲得する必要があります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- ルイス・ロウズ |シニア テクニカル スペシャリスト
- マルコ アウレリオ カルドーゾ |シニア ソフトウェア エンジニア
- パウロ ラサーダ |クラウド ソリューション アーキテクト
- Ritesh Modi |プリンシパル ソフトウェア エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。