基盤モデルは、AI ワークロードで使用するバージョン管理された依存関係です。 各基礎モデルには、考慮する必要があるライフサイクルがあります。 ワークロード内のコード ライブラリやその他の依存関係と同様に、基盤モデルはパフォーマンスの向上と最適化を提供するマイナー バージョンの更新プログラムを受け取ります。 メジャー バージョンの更新では、機能、パフォーマンス、またはトレーニング データの鮮度に実質的な変更が加えられます。 時間の経過と同時に、陳腐化やモデルのホスト設定が制御できないために、基盤モデルが非推奨になる可能性があります。
依存関係として選択したモデルの文書化されたライフ サイクルをサポートするようにワークロードを設計する必要があります。 モデルのライフ サイクルを考慮しない場合は、不必要にリスクの高いアップグレードを実行したり、テストされていない動作の変更を導入したり、不要なワークロードのダウンタイムを発生させたり、ホスティング プラットフォームが有効期間終了モデルを処理する方法によって停止が発生したりする可能性があります。
モデルのライフ サイクルをサポートするように設計されたワークロードを使用すると、マーケットプレースに入る新しい基盤モデルを簡単に実験し、安全に新しい基盤モデルに移行できます。
モデルの更新の種類
ジェネレーティブ AI ソリューションのモデル更新の範囲は、マイナー リビジョン変更のアップグレードから新しいモデル ファミリの選択まで、大きく異なる場合があります。 ソリューションでモデルをアップグレードする理由はさまざまです。 次の表に、このアップグレードの例と利点と共に、さまざまな更新スコープを示します。
| 変更の範囲 | モデルを更新する利点 | 例 |
|---|---|---|
| 小規模なバージョン更新 | パフォーマンスの向上と洗練された機能を提供します。通常、既存の実装に大きな変更を加える必要はありません | GPT-4o v2024-08-06 から GPT-4o v2024-11-20 への移行 |
| 中間バージョンの更新 | ほとんどの下位互換性を維持し、中程度の実装調整のみを必要としながら、パフォーマンスの大幅な向上、新機能、および信頼性の向上を提供します | GPT-3 から GPT-3.5 への移行 |
| 大規模バージョンアップデート | 実装の大幅な変更とプロンプトの調整を正当化する推論、機能、コンテキスト サイズ、パフォーマンスの変革的な改善を提供します | GPT-3 から GPT-4 への移行 |
| バリアント更新 | コア アーキテクチャを維持し、通常は基本モデルとの下位互換性を確保しながら、処理速度の向上や待機時間の短縮など、特殊な最適化を提供します | GPT-4 から GPT-4-Turbo への移行 |
| 世代別バージョンの更新 | 推論、マルチモーダル機能、およびパフォーマンスが大幅に向上し、モデルのユーティリティが根本的に拡張される一方で、実装戦略を完全に再考する必要がある可能性があります。 | GPT-4 から GPT-4o への移行 |
| 一般的なモデルの変更 | 特殊な機能、さまざまな価格パフォーマンス比、および特定のユース ケースとのより適切な連携へのアクセスを提供します | GPT-4 から DeepSeek への移行 |
| 特殊なモデルの変更 | 特殊なアプリケーションに汎用モデルを使用する場合と比較して、ドメイン固有の最適化、特定のタスクのパフォーマンスの向上、コストの削減が可能 | GPT-4 から Prizedata への移行 |
| デプロイ オプションの変更 | インフラストラクチャ、カスタマイズ オプション、コスト削減の可能性をより詳細に制御しながら、管理責任の増加を犠牲にして、特殊な最適化とデータ プライバシーの強化を実現します | Azure AI Foundry でマネージド オンライン エンドポイントとしてホストされている LLaMa-1 から、仮想マシンでの LLaMa-1 のセルフホスティングへの移行 |
表に示すように、新しいモデルに移行する利点は、通常、次の要因の組み合わせです。
速度や待機時間などのパフォーマンス
容量 (1 分あたりのトランザクション数で測定されるスループットなど)
クォータの可用性
コスト効率
リージョン別の提供状況
マルチモーダル機能
更新されたトレーニングの知識
バグの修正
ユース ケースに合わせた特殊化または特殊化解除
モデル ホスト ライフ サイクル ポリシーによるワークロードの停止の回避
モデル提供終了時の動作
モデルのリタイア動作は、モデルのデプロイメント戦略によって異なります。 モデルをデプロイするための 3 つの主要な戦略があります。 各戦略でバージョンの提供終了がどのように処理されるかを理解することが重要です。
MaaS (サービスとしてのモデル) ソリューション は、スケーラビリティと統合の容易さを提供する API として公開される事前トレーニング済みモデルです。 コストが高くなり、モデルの制御が低下する可能性のあるトレードオフがあります。 MaaS ソリューションの例としては、Foundry Models の Azure OpenAI にデプロイされたモデルや、サーバーレス API としてデプロイされたモデル カタログのモデルなどがあります。
MaaP (プラットフォームとしてのモデル) ソリューション は、マネージド コンピューティングにデプロイされた Azure モデル カタログのモデルなど、大規模なプラットフォーム内でデプロイおよび 管理されるモデルです。 このソリューションは通常、モデルをより詳細に制御できますが、MaaS ソリューションよりも多くの管理が必要です。
セルフホスティング モデル は、独自のインフラストラクチャにデプロイされたモデルです。 このデプロイでは、モデルを最大限に制御できますが、インフラストラクチャ、管理、およびメンテナンスに大きな責任が必要です。
Azure AI モデル カタログ内の Azure ソース モデルに基づく MaaS および MaaP の両方の戦略。 モデル カタログ内のモデルは、モデルが非推奨になり、廃止されるライフサイクルに従います。 ワークロードにおけるこれらの可能性を考慮して計画する必要があります。
Warnung
サーバーレス API モデルを使用してデプロイされた Azure OpenAI でデプロイされたモデルやモデルを含む MaaS サービスの場合、 廃止された モデルの既存のデプロイでは HTTP エラーが返されることを理解することが重要です。 サポートされているモデルにアップグレードしない場合、アプリケーションは想定どおりに動作しなくなります。 非推奨のモデルの場合、これらのモデルの新しいデプロイを作成することはできませんが、既存のデプロイは廃止されるまで引き続き機能します。 詳細については、「サーバーレス API モデルの廃止と廃止」および「Azure OpenAI モデルの廃止と廃止」を参照してください。
モデルをセルフホストしたり、マネージド コンピューティングを使用したりする場合は、フル コントロールを維持し、モデルを更新する必要はありません。 ただし、新しいモデルがワークロードにもたらすことができる追加の利点のために、モデルのライフ サイクルをレプリケートすることをお勧めします。
モデル更新の変更範囲
古いモデルから新しいモデルへの移行を計画できるように、モデルの更新がワークロードに与える影響を評価する必要があります。 ワークロードの変化の程度は、古いモデルと新しいモデルの機能的および非機能的な違いに依存します。 この図は、モデルの更新が影響を受ける可能性がある領域を強調表示する番号付きセクションを含む、簡略化されたチャット アーキテクチャを示しています。
これらの領域ごとに、更新によって発生するダウンタイムと、システムが処理している要求の処理方法を検討してください。 ワークロードでメンテナンス期間が使用可能な場合は、変更の範囲が大きいときにこれらのウィンドウを使用します。 メンテナンス期間が利用できない場合は、これらの領域の変更に対処して、モデルの更新中にワークロードの機能とサービス レベルの目標を維持します。
モデル: 明らかな変更は、モデル自体に対する変更です。 選択したモデルデプロイ戦略を使用して、新しいモデルをデプロイします。 インプレース アップグレードとサイド バイ サイド デプロイの間のトレードオフを評価する必要があります。
微調整されたモデルから新しいモデル リビジョンに移行する場合は、新しいモデル バージョンを使用する前に、もう一度微調整を実行する必要があります。 別のモデルを使用するように更新する場合は、微調整が必要かどうかを判断する必要があります。
モデルの構成: AI ソリューションで基礎モデルを更新する場合は、新しいモデルのアーキテクチャと機能のパフォーマンスを最適化するためにハイパーパラメーターまたは構成を調整することが必要になる場合があります。 たとえば、トランスフォーマー ベースのモデルからリカレント ニューラル ネットワークに切り替えると、最適な結果を得るために異なる学習率とバッチ サイズが必要になる場合があります。
プロンプト: ワークロードで基盤モデルを変更する場合は、新しいモデルの長所と機能に合わせてオーケストレーターまたはエージェントのシステム プロンプトを調整することが必要になる場合があります。
モデル構成の更新と共に、モデルを更新する際の最も一般的な変更の 1 つは、プロンプトの更新です。 新しいモデルを評価するときに、マイナー バージョンの更新であっても、要件を満たしていない場合は、プロンプトに対する変更をテストします。 この方法により、他の変更を調査する前にパフォーマンスの問題に確実に対処できます。 新しいモデルに変更するときは、プロンプトに対処する必要があります。 大規模なリビジョン変更を行う際には、プロンプトへの対応が必要になる場合もあります。
オーケストレーション ロジック: 一部のモデルの更新 (特に新機能を利用する場合) には、オーケストレーションまたはエージェント ロジックを変更する必要があります。
たとえば、モデルを GPT-4 に更新して 関数呼び出しを利用する場合は、オーケストレーション ロジックを変更する必要があります。 古いモデルの結果を呼び出し元に返すことができました。 関数呼び出しでは、モデルの呼び出しによって、オーケストレーション ロジックが呼び出す必要がある関数が返されます。 Azure では、オーケストレーション ロジックを Azure AI Foundry Agent Service に実装するか、または Azure でホストされている セマンティック カーネル や LangChain などのコード ベースのソリューションを使用して実装するのが一般的です。
接地データ: 一部のモデルの更新や、スコープが大きい変更では、基礎データや微調整データや、そのデータの取得方法に変更を加える必要があります。
たとえば、金融や医療に重点を置いたモデルなど、一般化されたモデルからドメイン固有のモデルに移行する場合、ドメイン固有のグラウンド データをモデルに渡す必要がなくなった可能性があります。 もう 1 つの例は、新しいモデルがより大きなコンテキスト ウィンドウを処理できる場合です。 このシナリオでは、他の関連するチャンクを取得したり、チャンクのサイズを調整したりできます。 詳細については、「 取得拡張生成 (RAG) ソリューションの設計と開発」を参照してください。
ハードウェア： MaaP で実行されるモデルの場合、モデルの変更には新しいハードウェアが必要になる場合があります。 カタログのモデルに対して有効になっているのは、特定のコンピューティング SKU のみです。 また、ハードウェアは非推奨になる可能性があり、新しいハードウェアでモデルを実行する必要があります。
変更を見込んだ設計
ほとんどの場合、ワークロード内のモデルを更新します。 Azure で MaaS デプロイ戦略を使用する場合、モデルは廃止され、新しいバージョンにアップグレードする必要があります。 また、新しい機能を利用したり、価格を下げたり、パフォーマンスを向上させたりするために、異なるモデルまたはモデル バージョンに移行することもできます。 どちらの方法でも、アーキテクチャでは、生成 AI ワークロードで使用されるモデルの更新をサポートする必要があります。
前のセクションでは、 さまざまな種類の変更について説明しました。 適切な機械学習操作 (MLOps)、データ操作 (DataOps)、生成 AI 操作 (GenAIOps) のプラクティスに従って、モデルの微調整、エンジニア プロンプト、ハイパーパラメーターの変更、オーケストレーション ロジックの管理のための自動化されたパイプラインを構築および維持する必要があります。
ハイパーパラメーターとプロンプトの更新は、ほとんどのモデル更新で一般的です。 これらの変更は非常に一般的であるため、アーキテクチャでは、これらの領域の制御された変更メカニズムをサポートする必要があります。 重要な考慮事項は、プロンプトとハイパーパラメーターが特定のモデル バージョン用に設計されていることです。 プロンプトとハイパーパラメーターが常に正しいモデルとバージョンで使用されるようにする必要があります。
自動化されたパイプライン
自動パイプラインを実装して、生成型 AI アプリケーションのさまざまな側面をテストおよび評価します。
MLOps:Azure MLOps ガイダンスに従って、モデルの微調整用のパイプラインを構築します (該当する場合)。
GenAIOps: GenAIOps パイプラインを実装して 、モデル、モデルハイパーパラメーター、プロンプト、オーケストレーション ロジックに対する変更をテストおよび評価します。
DataOps:DATAOps パイプラインを実装して、RAG グラウンド データに対する変更をテストおよび評価します。
次の理由でパイプラインを実装する必要があります。
- 反復的な開発と実験に役立つ (内部ループ)
- ジェネレーティブ AI ソリューションの安全なデプロイと運用化を実行するには (外部ループ)
可能であれば、運用アプリケーションで使用するのと同じベースライン データを使用して、生成 AI アプリケーションへの変更をテストします。 更新されたアプリケーションが、データの変更を必要とする新しいモデル機能を使用している場合、このアプローチは不可能な場合があります。
アーキテクチャの考慮事項
次のアーキテクチャのような単純なアーキテクチャでは、クライアントは正しいプロンプト バージョンと構成でモデルを直接呼び出します。 プロンプトに変更がある場合は、新しいクライアントが新しいプロンプトと共に展開され、新しいモデルが呼び出されます。 プロンプト、構成、モデルのバージョンをリンクすることは困難ではありません。
運用アーキテクチャは単純ではありません。 通常は、任意のナレッジ データベースとモデル間の相互作用のフローを管理する責任があるオーケストレーターまたはエージェントを実装します。 アーキテクチャでは、ルーターやゲートウェイなど、1 つ以上の抽象化レイヤーを実装することもできます。
ルーター： ルーターは、さまざまなオーケストレーターのデプロイにトラフィックを転送します。 ルーターは、安全なデプロイ プラクティスの一環として、特定の割合のトラフィックを新しいオーケストレーター バージョンにルーティングすることを選択できるブルーグリーンデプロイなどのデプロイ戦略に役立ちます。 このコンポーネントは、A/B テストまたはトラフィック ミラーリングに使用して、運用環境のトラフィックに対するテスト済みの変更を評価することもできますが、未検証です。
ゲートウェイ：さまざまな理由から、AI モデルへのプロキシ アクセスが一般的です。 たとえば、複数のバックエンド インスタンス間の負荷分散やフェールオーバーの有効化、カスタム認証と承認の実装、モデルのログ記録と監視の実装などを行うことができます。
間接参照のレイヤーが関係するため、特定のバージョンのプロンプトを特定のモデルまたはモデル バージョンに送信できるようにアーキテクチャを設計する必要があります。 たとえば、モデル 1 などのモデル用に設計されたプロンプト (prompt1 など) が運用環境にある場合があります。 model1.1 にアップグレードする場合は、prompt1 を prompt2 に更新することが必要になる場合があります。 この例では、アーキテクチャで常に prompt1 を model1 で使用し、prompt2 を model1.1 で使用する必要があります。
ルーター
次の図は、ルーターを使用して要求を複数のデプロイにルーティングするアーキテクチャを示しています。 このアーキテクチャのもう 1 つの例には、Azure AI Foundry が含まれており、マネージド オンライン エンドポイントをルーターとして使用します。 また、オーケストレーターのさまざまなバージョンがマネージド コンピューティングにデプロイされます。
次のフローでは、オーケストレーターのさまざまなデプロイが正しいモデルを呼び出す方法について説明します。 各デプロイには、独自のバージョンのモデル構成とプロンプトがあります。
ユーザーがインテリジェント アプリケーションから要求を発行すると、その要求がルーターに送信されます。
ルーターは、そのロジックに応じて、オーケストレーターのデプロイ 1 またはデプロイ 2 にルーティングされます。
各デプロイには、独自のバージョンのプロンプトと構成があります。
オーケストレーターは、特定のモデルとバージョンで構成されます。 この情報を使用して、適切なモデルとバージョンを直接呼び出します。
特定のバージョンのプロンプトは、特定のモデルとバージョンで構成されたオーケストレーターと共に展開されるため、正しいプロンプトが正しいモデル バージョンに送信されます。
ゲートウェイ
次の図は、ルーターを使用して要求を複数のデプロイにルーティングするアーキテクチャを示しています。 ただし、このアーキテクチャでは、すべてのモデル要求がゲートウェイ経由でルーティングされます。 負荷分散、1 つのリージョンまたは複数のリージョン内の複数のバックエンド インスタンス間のフェールオーバーの有効化、従量課金制スピルオーバー戦略を使用したプロビジョニング済みスループット ユニットの実装など、 さまざまな理由で AI モデルへのプロキシ アクセスが一般的です。
次のフローでは、オーケストレーターのさまざまなデプロイがゲートウェイを介して正しいモデルを呼び出す方法について説明します。 各デプロイには、独自のバージョンのモデル構成とプロンプトがあります。
ユーザーがインテリジェント アプリケーションから要求を発行すると、その要求がルーターに送信されます。
ルーターは、ロジックに応じて、デプロイ 1 またはデプロイ 2 にルーティングされます。
各デプロイには、独自のバージョンのプロンプトがあります。
オーケストレーターは、特定のモデルとバージョンで構成されます。 この情報を使用して、呼び出す正しいモデルとバージョンを示す HTTP ヘッダーを設定します。
オーケストレーターはゲートウェイを呼び出します。 要求には、使用するモデルの名前とバージョンを示す HTTP ヘッダーが含まれています。
ゲートウェイは HTTP ヘッダーを使用して、要求を適切なモデルとバージョンにルーティングします。 また、ゲートウェイで定義された構成を適用することもできます。
構成の外部化
外部構成ストアのクラウド設計パターンは、プロンプトと構成の格納を処理するための優れた方法です。 モデルの変更の一部のスコープでは、オーケストレーターまたはエージェントのコードの外部の更新可能な場所に格納されている場合は、システム プロンプトと構成の変更を使用してモデルのデプロイを調整できる場合があります。 調整するオーケストレーション ロジックがある場合、この方法は機能しませんが、多くの小規模なスコープ モデルの更新で役立ちます。
コンピューティングの選択
MaaP ホスティングの場合、モデルは多くの場合、ホストによって提供されるコンピューティング リソースのサブセットに制限されます。 すべてのコンピューティングには、クォータ、可用性の制約、および有効期間終了のお知らせが適用されます。 現在のハードウェアがサポートされなくなった場合、または余分なスケールアウトを妨げる制約がある場合は、ルーティング パターンを使用して新しいハードウェアへの移行をサポートします。
寿命終了のお知らせの例として、 NC A100 v4 シリーズのコンピューティングアナウンスがあります。 このハードウェアでモデルをホストする場合は、サポートされている別の SKU に移行する必要があります。この SKU は、有効期間が終了せず、可用性が向上します。 また、新しい SKU で現在のモデルがサポートされていない場合、この移行にはモデルの変更が同時に必要になる場合があります。
推奨事項
抽象化と間接参照のレイヤーを追加して、ワークロードの特定の領域に対する制御された変更を有効にします。 これらの領域には、クライアント、インテリジェント アプリケーション API、オーケストレーション、モデル ホスティング、基礎知識が含まれます。
運用環境で使用する前に、モデル のバージョン、プロンプト、構成、オーケストレーション ロジック、および基礎知識の取得に対するすべての変更をテストする必要があります。 テスト済みの組み合わせが運用環境で 固定 されていることを確認します。つまり、デプロイ時に厳密にリンクされたままになります。 A/B テスト、負荷分散、およびブルーグリーンデプロイでは、テストされていない組み合わせにユーザーが公開されないようにコンポーネントを混在させないでください。
自動化されたパイプラインを使用して、新しいバージョンと新しいモデルをテストおよび評価します。 結果をベースラインの結果と比較して、必要な結果が確実に得られるようにする必要があります。
モデルの更新については意図的に行う必要があります。 テストを行わずに、運用モデルを新しいバージョンに自動的にアップグレードするプラットフォーム機能を使用しないでください。 すべてのモデルの更新がワークロードに与える影響に注意する必要があります。 Azure AI Foundry Models API を使用する場合は、特定のバージョンでデプロイを設定し、アップグレード ポリシーを指定しないでください。 新しいバージョンがリリースされた場合、このセットアップには手動アップグレードが必要です。 Azure OpenAI の場合、自動アップグレードをオフにするには、デプロイを [自動アップグレードなし ] に設定します。
監視とログ記録のソリューションで、観察された動作と関連する特定のプロンプト、構成、モデル、およびデータ取得ソリューションを関連付けるために十分なメタデータが収集されていることを確認します。 この相関関係により、システム パフォーマンスの予期しない回帰を特定できます。
概要
生成ワークロードの基本モデルを更新するには、さまざまな理由があります。 これらの理由は、モデルが廃止されたときに必要なバージョンのアップグレードから、別のモデルに切り替える決定までさまざまです。 モデルの更新のスコープによっては、プロンプト、モデル構成、オーケストレーション ロジック、データ パイプラインの変更など、モデルの変更を実装して評価することが必要になる場合があります。 MLOps、DataOps、GenAIOps のガイダンスに従って、ソリューションのさまざまな側面に合わせて自動化されたワークフローを構築する必要があります。 自動化されたワークフローを使用すると、新しいバージョンをテスト、評価、デプロイできます。 また、各バージョンが構成とプロンプト バージョンを特定のモデル バージョンにリンクするオーケストレーターの複数のバージョンの実行がアーキテクチャでサポートされていることを確認する必要もあります。
アーキテクチャでは、インテリジェント なアプリケーションやユーザー エクスペリエンスを変更することなく、新しいモデルまたは異なるモデルの更新と、プロンプトまたはモデル構成に必要な変更をサポートする必要があります。 これらの更新プログラムは、適切なコンポーネント内にカプセル化する必要があり、操作によって、それらの変更のテスト、評価、デプロイを自動化する必要があります。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
- Ritesh Modi | プリンシパル ソフトウェア エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。