このページは Cloud Translation API によって翻訳されました。

生成 AI アプリケーションをデプロイして運用する

Last reviewed 2024-11-19 UTC

生成 AI は、予測 AI とは異なる AI アプリケーションの構築と運用を行う新しい方法を導入しました。生成 AI アプリケーションを構築するには、さまざまなアーキテクチャとサイズから選択し、データをキュレートし、最適なプロンプトを設計し、特定のタスクに合わせてモデルを調整し、モデル出力を実際のデータでグラウンディングする必要があります。

このドキュメントでは、既存の基盤モデルで生成 AI アプリケーションを開発、デプロイ、運用するために DevOps プロセスと MLOps プロセスを適応させる方法について説明します。予測 AI のデプロイについては、MLOps: 機械学習における継続的デリバリーと自動化のパイプラインをご覧ください。

DevOps と MLOps とは

DevOps は、開発と運用を結び付けるソフトウェアエンジニアリング手法です。DevOps は、継続的インテグレーションや継続的デリバリー（CI/CD）などの手法を使用して、コラボレーション、自動化、継続的改善を促進し、ソフトウェア開発ライフサイクルを効率化します。

MLOps は、DevOps の原則に基づいて、ML（ML）システムの構築と運用の課題に対処します。通常、ML システムは予測 AI を使用してパターンを特定し、予測を行います。MLOps ワークフローには、次のものが含まれます。

データの検証
モデルのトレーニング
モデルの評価とイテレーション
モデルのデプロイとサービング
モデルのモニタリング

基盤モデルとは

基盤モデルは、生成 AI アプリケーションの中核となるコンポーネントです。これらのモデルは、データセットを使用して学習し、人間の介入なしで意思決定を行う大規模なプログラムです。基盤モデルは、テキスト、画像、音声、動画など、さまざまな種類のデータでトレーニングされます。基盤モデルには、Llama 3.1 などの大規模言語モデル（LLM）や、Gemini などのマルチモーダルモデルが含まれます。

特定のタスク用に焦点を絞ったデータセットでトレーニングされる予測 AI モデルとは異なり、基盤モデルは大規模で多様なデータセットでトレーニングされます。このトレーニングでは、基盤モデルを使用して、さまざまなユースケースに対応するアプリケーションを開発する方法を学びます。基盤モデルには創発的特性（PDF）があり、明示的なトレーニングを行わなくても特定の入力に対して応答できます。このような創発的特性があるため、基盤モデルの作成と運用は難しく、DevOps と MLOps のプロセスを適応させる必要があります。

基盤モデルの開発には、大量のデータリソース、専用のハードウェア、多額の投資、専門知識が必要です。そのため、多くの企業は既存の基盤モデルを使用して、生成 AI アプリケーションの開発とデプロイを簡素化することを好みます。

生成 AI アプリケーションのライフサイクル

生成 AI アプリケーションのライフサイクルには、次のフェーズが含まれます。

検出: デベロッパーと AI エンジニアが、ユースケースに最適な基盤モデルを特定します。各モデルの長所、短所、費用を考慮して、十分な情報に基づいて意思決定を行います。
開発とテスト: デベロッパーは、プロンプトエンジニアリングを使用して、必要な出力を得るための入力プロンプトを作成して調整します。利用可能な場合、フューショット学習、パラメータ効率の高いファインチューニング（PEFT）、モデルのチェーン化は、モデルの動作をガイドするのに役立ちます。モデルのチェーンとは、特定のシーケンスで複数のモデルへの呼び出しをオーケストレートしてワークフローを作成することです。
デプロイ: デベロッパーは、プロンプトテンプレート、チェーン定義、埋め込みモデル、検索データストア、ファインチューニングされたモデルアダプタなど、デプロイプロセスで多くのアーティファクトを管理する必要があります。これらのアーティファクトには独自のガバナンス要件があり、開発とデプロイ全体で慎重な管理が必要です。生成 AI アプリケーションのデプロイでは、ターゲットインフラストラクチャの技術的な機能も考慮して、アプリケーションのハードウェア要件が満たされるようにする必要があります。
本番環境での継続的なモニタリング: 管理者は、モデルの出力における公平性、透明性、アカウンタビリティの確保など、責任ある AI 手法を通じて、アプリケーションのパフォーマンスを向上させ、安全基準を維持します。
継続的な改善: デベロッパーは、プロンプト手法、モデルの新しいバージョンへの交換、複数のモデルの組み合わせなどにより、基盤モデルを常に調整して、パフォーマンスの向上、費用対効果の向上、レイテンシの短縮を実現します。従来の継続的トレーニングは、繰り返し微調整や人間からのフィードバックループの組み込みが必要なシナリオでは、依然として有効です。

データエンジニアリングの実践は、すべての開発段階で重要な役割を果たします。信頼性の高い出力を生成するには、事実に基づくグラウンディング（モデルの出力が正確で最新の情報に基づいていることを保証する）と、内部システムとエンタープライズシステムからの最新のデータが必要です。チューニングデータは、モデルを特定のタスクやスタイルに適応させ、永続的なエラーを修正するのに役立ちます。

ユースケースに適した基盤モデルを見つける

基盤モデルの構築はリソースを大量に消費するため、ほとんどの企業はユースケースに最適な既存の基盤モデルを使用することを好みます。基盤モデルは多数存在するため、適切な基盤モデルを見つけるのは困難です。各モデルには、異なるアーキテクチャ、サイズ、トレーニングデータセット、ライセンスがあります。また、ユースケースごとに固有の要件があるため、複数のディメンションにわたって利用可能なモデルを分析する必要があります。

モデルを評価する際は、次の要素を考慮してください。

品質: テストプロンプトを実行して、出力の品質を測定します。
レイテンシとスループット: ユースケースに必要な適切なレイテンシとスループットを決定します。これらの要素はユーザーエクスペリエンスに直接影響します。たとえば、chatbot では、バッチ処理された要約タスクよりも低いレイテンシが求められます。
開発とメンテナンスの時間: 初期開発と継続的なメンテナンスにかかる時間を考慮します。マネージドモデルは、自分でデプロイする公開モデルよりも労力が少なくて済むことがよくあります。
使用コスト: モデルに関連するインフラストラクチャと消費コストを検討します。
コンプライアンス: 関連する規制とライセンス条項を遵守するモデルの能力を評価します。

開発とテスト

生成 AI アプリケーションを構築する場合、開発とテストは反復的でオーケストレートされます。各テストイテレーションでは、データの絞り込み、基盤モデルの適応、結果の評価を行います。評価は、継続的なフィードバックループで後続のイテレーションをガイドするフィードバックを提供します。パフォーマンスが期待どおりでない場合は、データを追加で収集したり、データを拡張したり、データをさらにキュレートしたりできます。また、プロンプトの最適化、ファインチューニング手法の適用、別の基盤モデルへの変更が必要になることもあります。評価の分析情報に基づくこの反復的な改善サイクルは、ML や予測 AI と同様に、生成 AI アプリケーションの最適化にも重要です。

基盤モデルのパラダイム

基盤モデルは、多目的モデルであるため、予測モデルとは異なります。基盤モデルは、特定のタスクに固有のデータで単一の目的のためにトレーニングされるのではなく、幅広いデータセットでトレーニングされます。これにより、基盤モデルをさまざまなユースケースに適用できます。

基盤モデルは、入力の変化にも非常に敏感です。モデルの出力と実行するタスクは、モデルへの入力によって決まります。基盤モデルは、入力を変更するだけで、テキストの翻訳、動画の生成、データの分類を行うことができます。入力にわずかな変更を加えただけでも、モデルがそのタスクを正しく実行する能力に影響する可能性があります。

基盤モデルのこれらの特性には、異なる開発と運用のプラクティスが必要です。予測 AI コンテキストのモデルは自己完結型でタスク固有ですが、基盤モデルは多目的であり、ユーザー入力以外の追加要素が必要です。生成 AI モデルには、プロンプト（具体的にはプロンプトテンプレート）が必要です。プロンプトテンプレートは、ユーザー入力を受け入れるためのプレースホルダとともに、一連の指示と例を含むものです。アプリケーションは、プロンプトテンプレートと動的データ（ユーザー入力など）を組み合わせて完全なプロンプトを作成できます。これは、基盤モデルへの入力として渡されるテキストです。

プロンプトモデルコンポーネント

プロンプトの存在は、生成 AI アプリケーションの際立った特徴です。モデルとプロンプトだけではコンテンツを生成できません。生成 AI には両方が必要です。モデルとプロンプトの組み合わせは、プロンプトモデルコンポーネントと呼ばれます。プロンプトモデルコンポーネントは、生成 AI アプリケーションの作成に十分な最小の独立コンポーネントです。プロンプトは複雑である必要はありません。たとえば、「次の文を英語からフランス語に翻訳してください」のような簡単な指示の後に、翻訳する文を続けることができます。ただし、この予備的な指示がないと、基盤モデルは必要な変換タスクを実行しません。そのため、基盤モデルにアプリケーションに必要なタスクを実行させるには、入力とともにプロンプト（基本的な指示でも可）が必要です。

プロンプトモデルコンポーネントは、生成 AI アプリケーションを開発する際の MLOps プラクティスに重要な違いをもたらします。生成 AI アプリケーションの開発では、プロンプトモデルコンポーネントのコンテキストでテストと反復を行う必要があります。通常、生成 AI の実験サイクルは、プロンプトのバリエーションをテストすることから始まります。手順の文言を変更したり、追加のコンテキストを提供したり、関連する例を含めたりして、それらの変更の影響を評価します。この手法は、一般にプロンプトエンジニアリングと呼ばれます。

プロンプトエンジニアリングには、次の反復手順が含まれます。

プロンプト: 特定のユースケースで基盤モデルから目的の動作を引き出すために、プロンプトを作成して調整します。
評価: モデルの出力を評価します。理想的には、プログラムでモデルの理解度を測定し、プロンプトの指示を満たしているかどうかを評価します。

評価結果をトラッキングするには、必要に応じてテストの結果を登録します。プロンプト自体がプロンプトエンジニアリングプロセスのコア要素であるため、実験の一部であるアーティファクトの中で最も重要なアーティファクトになります。

ただし、生成 AI アプリケーションをテストするには、アーティファクトタイプを特定する必要があります。予測 AI では、データ、パイプライン、コードは異なります。しかし、生成 AI のプロンプトパラダイムでは、プロンプトにコンテキスト、指示、例、ガードレール、他の場所から取得した実際の内部データまたは外部データを含めることができます。

アーティファクトのタイプを判断するには、プロンプトにさまざまなコンポーネントがあり、さまざまな管理戦略が必要であることを認識する必要があります。次の点を考慮してください。

データとしてのプロンプト: プロンプトの一部はデータとして機能します。数ショットの例、ナレッジベース、ユーザーのクエリなどの要素は、基本的にデータポイントです。これらのコンポーネントには、データ検証、ドリフト検出、ライフサイクル管理などのデータ中心の MLOps プラクティスが必要です。
コードとしてのプロンプト: コンテキスト、プロンプトテンプレート、ガードレールなどの他のコンポーネントはコードに似ています。これらのコンポーネントは、プロンプト自体の構造とルールを定義し、承認プロセス、コードバージョニング、テストなどのコード中心のプラクティスを必要とします。

そのため、生成 AI に MLOps のプラクティスを適用する場合は、デベロッパーがプロンプトを簡単に保存、取得、追跡、変更できるプロセスが必要です。これらのプロセスにより、迅速な反復と原則に基づいたテストが可能になります。プロンプトの 1 つのバージョンが特定のバージョンのモデルではうまく機能しても、別のバージョンではうまく機能しないことがよくあります。テストの結果を追跡する場合は、プロンプト、コンポーネントのバージョン、モデルバージョン、指標、出力データを記録する必要があります。

モデルのチェーンと拡張

生成 AI モデル、特に大規模言語モデル（LLM）は、最新性を維持し、ハルシネーションを回避するうえで固有の課題を抱えています。LLM に新しい情報をエンコードするには、デプロイする前に費用とデータ集約型の事前トレーニングが必要です。ユースケースによっては、特定の生成を行うために 1 つのプロンプトモデルだけを使用するだけでは不十分な場合があります。この問題を解決するには、プロンプトモデルを複数接続し、外部 API の呼び出しとコードとして表現されたロジックを接続します。このように接続されたプロンプトモデルコンポーネントのシーケンスは、一般にチェーンと呼ばれます。

次の図は、チェーンのコンポーネントと相対的な開発プロセスを示しています。

開発プロセスにおけるモデルチェーン。

ファインチューニング

基盤モデルを含む生成 AI のユースケースを開発する場合、特に複雑なタスクでは、プロンプトエンジニアリングとチェーンのみに依存してユースケースを解決することは困難です。タスクのパフォーマンスを向上させるために、デベロッパーはモデルを直接ファインチューニングする必要があることがよくあります。ファインチューニングでは、モデルのすべてのレイヤまたはレイヤのサブセット（パラメータ効率の高いファインチューニング）を積極的に変更して、特定のタスクを実行する能力を最適化できます。モデルをチューニングする最も一般的な方法は次のとおりです。

教師ありファインチューニング: 教師ありの方法でモデルをトレーニングし、特定の入力に対して正しい出力シーケンスを予測するようにモデルを学習させます。
人間からのフィードバックを用いた強化学習（RLHF）: 人間が回答として好むものを予測するように報酬モデルをトレーニングします。次に、この報酬モデルを使用して、チューニングプロセス中に LLM を正しい方向に誘導します。このプロセスは、人間の審査員がモデルの学習をガイドするのに似ています。

次の図は、チューニングが実験サイクルの間にモデルを改善する仕組みを示しています。

モデルのファインチューニング。

MLOps では、ファインチューニングはモデルトレーニングと次の機能を共有します。

チューニングジョブの一部であるアーティファクトを追跡する機能。たとえば、アーティファクトには、モデルのチューニングに使用される入力データやパラメータが含まれます。
チューニングの影響を測定する機能。この機能を使用すると、チューニングされたモデルがトレーニングされた特定のタスクについてモデルを評価し、同じタスクについて以前にチューニングされたモデルまたはフリーズされたモデルと結果を比較できます。

継続的なトレーニングとチューニング

MLOps では、継続的なトレーニングは、本番環境で ML モデルを繰り返し再トレーニングすることです。継続的トレーニングは、実世界のデータパターンが時間とともに変化しても、モデルが最新の状態を維持し、パフォーマンスを維持するのに役立ちます。生成 AI モデルの場合、データと計算費用が高いため、モデルの継続的なチューニングは再トレーニングプロセスよりも実用的であることがよくあります。

継続的チューニングのアプローチは、特定のユースケースと目標によって異なります。テキスト要約などの比較的静的なタスクでは、継続的チューニングの要件が低くなる可能性があります。ただし、人間との継続的な調整が必要な chatbot などの動的アプリケーションでは、人間のフィードバックに基づく RLHF などの手法を使用して、より頻繁にチューニングする必要があります。

適切な継続的チューニング戦略を決定するには、ユースケースの性質と入力データの経時的な変化を評価する必要があります。コンピューティングインフラストラクチャはチューニングの速度と費用に大きな影響を与えるため、コストも重要な考慮事項です。グラフィックプロセッシングユニット（GPU）と Tensor Processing Unit（TPU）は、ファインチューニングに必要なハードウェアです。並列処理能力で知られる GPU は、コンピューティング負荷の高いワークロードの処理に非常に効果的であり、複雑な ML モデルのトレーニングと実行によく使用されます。一方、TPU は、ML タスクの高速化を目的として Google が特別に設計したものです。TPU は、ディープラーニングニューラルネットワークで一般的な大規模な行列演算の処理に優れています。

データの取り扱い

以前は、ML モデルの動作はトレーニングデータのみによって決定されていました。これは基盤モデルにも当てはまりますが、基盤モデルの上に構築された生成 AI アプリケーションのモデルの動作は、さまざまな種類の入力データでモデルを適応させる方法によって決まります。

基盤モデルは、次のようなデータでトレーニングされます。

事前トレーニングデータセット（C4、The Pile、独自データなど）
指示チューニングデータセット
安全性チューニング用データセット
人間の好みに関するデータ

生成 AI アプリケーションは、次のようなデータに基づいて適応されます。

プロンプト
拡張データまたはグラウンディングデータ（ウェブサイト、ドキュメント、PDF、データベース、API など）
PEFT のタスク固有のデータ
タスク固有の評価
人間の好みに関するデータ

予測 ML と生成 AI のデータプラクティスの主な違いは、ライフサイクルプロセスの開始時にあります。予測 ML では、データエンジニアリングに多くの時間を費やします。適切なデータがないと、アプリケーションを構築できません。生成 AI では、基盤モデル、いくつかの指示、場合によってはいくつかの入力例（コンテキスト内学習など）から始めます。ごくわずかなデータでアプリケーションのプロトタイプを作成してリリースできます。

ただし、プロトタイピングの容易さには、多様なデータの管理という新たな課題が伴います。予測 AI は、明確に定義されたデータセットに依存します。生成 AI では、1 つのアプリケーションで、まったく異なるデータソースからさまざまなデータ型を使用し、それらを連携させることができます。

次のデータ型について考えてみましょう。

条件付けプロンプト: 基盤モデルに出力と生成可能な境界を設定するための指示。
少数ショットの例: 入出力ペアを通じて実現したいことをモデルに示す方法。これらの例は、モデルが特定のタスクを理解するのに役立ちます。多くの場合、これらの例はパフォーマンスを向上させることができます。
グラウンディングデータまたは拡張データ: 基盤モデルが特定のコンテキストに対する回答を生成し、基盤モデル全体を再トレーニングすることなく、回答を最新かつ関連性の高い状態に保つことができるデータ。このデータは、外部 API（Google 検索など）または内部 API やデータソースから取得できます。
タスク固有のデータセット: 特定のタスク用に既存の基盤モデルをファインチューニングし、その特定の分野でのパフォーマンスを向上させるのに役立つデータセット。
完全な事前トレーニングデータセット: 基盤モデルの初期トレーニングに使用される大規模なデータセット。アプリケーションデベロッパーは、これらのデータやトークナイザーにアクセスできない可能性がありますが、モデル自体にエンコードされた情報は、アプリケーションの出力とパフォーマンスに影響します。

このような多様なデータ型は、データの整理、追跡、ライフサイクル管理の面で複雑さを増大させます。たとえば、RAG ベースのアプリケーションは、ユーザーのクエリを書き換え、厳選された一連の例を使用して関連する例を動的に収集し、ベクトルデータベースにクエリを実行して、情報をプロンプトテンプレートと組み合わせることができます。RAG ベースのアプリケーションでは、ユーザークエリ、キュレートされたフューショットの例と会社情報を含むベクトルデータベース、プロンプトテンプレートなど、複数のデータ型を管理する必要があります。

各データ型には、慎重な整理とメンテナンスが必要です。たとえば、ベクトルデータベースでは、データをエンベディングに処理し、チャンク化戦略を最適化し、関連情報のみが利用可能であることを確認する必要があります。プロンプトテンプレートにはバージョン管理とトラッキングが必要であり、ユーザークエリを書き換える必要があります。MLOps と DevOps のベストプラクティスは、これらのタスクに役立ちます。予測 AI では、抽出、変換、読み込み用のデータパイプラインを作成します。生成 AI では、パイプラインを構築して、さまざまなデータ型をバージョン管理、追跡、再現可能な方法で管理、進化、適応、統合します。

基盤モデルをファインチューニングすると、生成 AI アプリケーションのパフォーマンスを向上させることができますが、モデルにはデータが必要です。このデータは、アプリを起動して実世界のデータを収集したり、合成データを生成したり、その両方を組み合わせたりすることで取得できます。大規模モデルを使用して合成データを生成する方法は、デプロイプロセスを高速化できるため、普及しつつあります。ただし、品質保証のために、結果を人間がチェックすることが重要です。データエンジニアリングの目的で大規模モデルを使用する方法の例を次に示します。

合成データの生成: このプロセスでは、特性と統計的プロパティの点で実際のデータに非常によく似た人工データを作成します。大規模で高性能なモデルは、このタスクを完了することがよくあります。合成データは生成 AI の追加のトレーニングデータとして機能し、ラベル付きの実際のデータが少ない場合でも、パターンと関係を学習できます。
合成データの修正: この手法は、既存のラベル付きデータセット内のエラーと不整合を特定して修正することに重点を置いています。生成 AI は、より大きなモデルの能力を活用して、ラベル付けの潜在的な誤りを検出し、修正案を提示することで、トレーニングデータの品質と信頼性を高めることができます。
合成データ拡張: このアプローチは、新しいデータを生成するだけではありません。合成データ拡張では、既存のデータをインテリジェントに操作して、重要な特徴と関係性を維持しながら多様なバリエーションを作成します。生成 AI は、トレーニング中に予測 AI よりも幅広いシナリオに遭遇する可能性があるため、一般化が改善され、ニュアンスのある関連性の高い出力を生成する能力が向上します。

予測 AI とは異なり、生成 AI の評価は困難です。たとえば、基盤モデルのトレーニングデータの分布がわからない場合があります。必須ケース、平均ケース、エッジケースなど、すべてのユースケースを反映したカスタム評価データセットを構築する必要があります。ファインチューニングデータと同様に、強力な LLM を使用して、堅牢な評価データセットを構築するためのデータの生成、キュレーション、拡張を行うことができます。

評価

評価プロセスは、生成 AI アプリケーションの開発における中心的なアクティビティです。評価の自動化の程度は、完全に人間が実施するものから、プロセスによって完全に自動化されるものまで、さまざまです。

プロジェクトのプロトタイピングでは、評価は手動で行われることがよくあります。デベロッパーはモデルの出力を確認し、モデルのパフォーマンスを定性的に把握します。しかし、プロジェクトが成熟し、テストケースの数が増えると、手動評価がボトルネックになります。

評価を自動化すると、迅速な対応が可能になり、評価の信頼性が高まるという 2 つの大きなメリットがあります。また、人間の主観性を排除することで、結果の再現性を確保できます。

ただし、生成 AI アプリケーションの評価を自動化するには、独自の課題があります。たとえば、次の点を考えます。

入力（プロンプト）と出力の両方が非常に複雑になる可能性があります。1 つのプロンプトに、モデルが管理する必要がある複数の指示と制約が含まれる場合があります。出力自体は、生成された画像やテキストブロックなど、高次元であることがよくあります。これらの出力の品質を単純な指標で捉えることは困難です。翻訳の BLEU や要約の ROUGE など、確立された指標だけでは十分でない場合があります。そのため、カスタム評価方法や別の基盤モデルを使用してシステムを評価できます。たとえば、大規模言語モデル（AutoSxS など）に、さまざまなディメンションで生成されたテキストの品質をスコアリングするように指示できます。
生成 AI の評価指標の多くは主観的です。ある出力が別の出力よりも優れているかどうかは、意見が分かれる可能性があります。指標が人々の考えを正確に反映するように、自動評価が人間の判断と一致していることを確認する必要があります。テスト間の比較可能性を確保するには、開発プロセスの早い段階で評価アプローチと指標を決定する必要があります。
グラウンドトゥルースデータの不足（特にプロジェクトの初期段階）。回避策の 1 つは、一時的なグラウンドトゥルースとして機能する合成データを生成し、人間のフィードバックに基づいて時間をかけて改善することです。
包括的な評価は、敵対的攻撃から生成 AI アプリケーションを保護するために不可欠です。悪意のあるユーザーは、機密情報の抽出やモデルの出力の操作を試みるプロンプトを作成できます。評価セットでは、プロンプトファジング（モデルにプロンプトのランダムなバリエーションをフィードする）や情報漏洩のテストなどの手法を使用して、これらの攻撃ベクトルに特に対処する必要があります。

生成 AI アプリケーションを評価するには、次のものを実装します。

評価プロセスを自動化して、速度、スケーラビリティ、再現性を確保します。自動化は人間の判断の代わりと考えることができます。
ユースケースに応じて、評価プロセスをカスタマイズします。
比較可能性を確保するには、開発フェーズの早い段階で評価アプローチ、指標、グラウンドトゥルースデータを安定させます。
実際のグラウンドトゥルースデータがない場合に、合成グラウンドトゥルースデータを生成します。
敵対的なプロンプトのテストケースを評価セットの一部として含め、これらの攻撃に対するシステム自体の信頼性をテストします。

デプロイ

本番環境レベルの生成 AI アプリケーションは、相互作用する多くのコンポーネントを含む複雑なシステムです。生成 AI アプリケーションを本番環境にデプロイするには、これらのコンポーネントを管理し、生成 AI アプリケーション開発の前のステージと連携させる必要があります。たとえば、1 つのアプリケーションで、データベースとともに複数の LLM を使用し、すべてが動的データパイプラインによって供給される場合があります。これらの各コンポーネントには、独自のデプロイプロセスが必要になる場合があります。

生成 AI アプリケーションのデプロイは、他の複雑なソフトウェアシステムのデプロイと似ています。データベースや Python アプリケーションなどのシステムコンポーネントをデプロイする必要があるためです。バージョン管理や CI/CD などの標準的なソフトウェアエンジニアリング手法を使用することをおすすめします。

バージョン管理

生成 AI のテストは、開発、評価、変更のサイクルを繰り返す反復的なプロセスです。構造化された管理しやすいアプローチを確保するには、変更可能なすべてのコンポーネントに厳格なバージョン管理を実装する必要があります。コンポーネントは次のとおりです。

プロンプトテンプレート: 特定のプロンプト管理ソリューションを使用しない限り、バージョン管理ツールを使用してバージョンを追跡します。
チェーン定義: バージョン管理ツールを使用して、チェーンを定義するコードのバージョン（API 統合、データベース呼び出し、関数など）を追跡します。
外部データセット: RAG システムでは、外部データセットが重要な役割を果たします。BigQuery、AlloyDB for PostgreSQL、Vertex AI Feature Store などの既存のデータ分析ソリューションを使用して、これらの変更とデータセットのバージョンを追跡します。
アダプターモデル: アダプターモデルの LoRA チューニングなどの手法は常に進化しています。確立されたデータストレージソリューション（Cloud Storage など）を使用して、これらのアセットを効果的に管理し、バージョン管理します。

継続的インテグレーション

継続的インテグレーションフレームワークでは、すべてのコード変更が自動テストを経てから統合されるため、問題を早期に検出できます。品質と信頼性の観点から、単体テストと統合テストは重要です。単体テストは個々のコード部分に焦点を当てますが、統合テストではさまざまなコンポーネントが連携して動作することを確認します。

継続的インテグレーションシステムを実装すると、次のことが可能になります。

信頼性の高い高品質の出力を確保する: 厳格なテストにより、システムのパフォーマンスと一貫性に対する信頼性が高まります。
バグを早期に発見する: テストで問題を特定することで、下流でより大きな問題が発生するのを防ぐことができます。バグを早期に検出することで、システムがより堅牢になり、エッジケースや予期しない入力に対する復元力が高まります。
メンテナンスコストの削減: ドキュメント化されたテストケースにより、トラブルシューティングが簡素化され、将来の変更がスムーズに行えるため、メンテナンス全体の労力が軽減されます。

これらのメリットは、生成 AI アプリケーションに適用されます。プロンプトテンプレート、チェーン、チェーンロジック、埋め込みモデル、検索システムなど、システムのすべての要素に継続的インテグレーションを適用します。

ただし、生成 AI に継続的インテグレーションを適用するには、次の課題があります。

包括的なテストケースの生成が難しい: 生成 AI の出力は複雑でオープンエンドな性質を持つため、考えられるすべての可能性を網羅する包括的なテストケースを定義して作成することが困難です。
再現性の問題: 生成モデルには、同一の入力に対しても出力に固有のランダム性とばらつきがあることが多いため、決定論的で再現可能な結果を得ることは困難です。このランダム性により、期待される動作を常にテストすることが難しくなります。

これらの課題は、生成 AI アプリケーションを評価する方法というより広範な問題と密接に関連しています。生成 AI の CI システムの開発には、同じ評価手法の多くを適用できます。

継続的デリバリー

コードがマージされると、継続的デリバリープロセスが開始され、ビルドおよびテストされたコードが本番環境に類似した環境に移動され、最終的なデプロイの前にさらにテストされます。

開発とテストで説明したように、チェーン要素は生成 AI アプリケーションを構成する基本的な要素であるため、デプロイする主なコンポーネントの 1 つになります。チェーンを含む生成 AI アプリケーションの配信プロセスは、レイテンシ要件とユースケースがバッチかオンラインかによって異なる場合があります。

バッチユースケースでは、本番環境でスケジュールに従って実行されるバッチプロセスをデプロイする必要があります。デリバリープロセスでは、デプロイ前に本番環境に類似した環境で統合のパイプライン全体をテストすることに重点を置いています。テストプロセスの一環として、開発者はバッチ処理自体のスループットに関する特定の要件をアサートし、アプリケーションのすべてのコンポーネントが正しく機能していることを確認できます。（たとえば、デベロッパーは権限、インフラストラクチャ、コードの依存関係を確認できます）。

オンラインユースケースでは、チェーンを含むアプリケーションである API をデプロイし、低レイテンシでユーザーに応答できるようにする必要があります。配信プロセスでは、本番環境に類似した環境で統合の API をテストします。これらのテストでは、アプリケーションのすべてのコンポーネントが正しく機能していることを確認します。負荷テストなどの一連のテストを通じて、非機能要件（スケーラビリティ、信頼性、パフォーマンスなど）を確認できます。

デプロイチェックリスト

次のリストは、Vertex AI などのマネージドサービスを使用して生成 AI アプリケーションをデプロイする際の手順を示しています。

バージョン管理を構成する: モデルのデプロイにバージョン管理プラクティスを実装します。バージョン管理を使用すると、必要に応じて以前のバージョンにロールバックし、モデルまたはデプロイ構成に加えられた変更を追跡できます。
モデルを最適化する: モデルをパッケージ化またはデプロイする前に、モデルの最適化タスク（蒸留、量子化、プルーニング）を実行します。
モデルをコンテナ化する: トレーニング済みモデルをコンテナにパッケージ化します。
ターゲットハードウェアの要件を定義する: ターゲットデプロイ環境が、GPU、TPU、その他の専用ハードウェアアクセラレータなど、モデルの最適なパフォーマンスの要件を満たしていることを確認します。
モデルエンドポイントを定義する: モデルコンテナ、入力形式、出力形式、追加の構成パラメータを指定します。
リソースを割り当てる: 予想されるトラフィックとパフォーマンス要件に基づいて、エンドポイントに適切なコンピューティングリソースを割り当てます。
アクセス制御を構成する: 認証ポリシーと認可ポリシーに基づいてエンドポイントへのアクセスを制限するアクセス制御メカニズムを設定します。アクセス制御により、承認されたユーザーまたはサービスのみがデプロイされたモデルを操作できるようになります。
モデルエンドポイントを作成する: エンドポイントを作成して、モデルを REST API サービスとしてデプロイします。エンドポイントを使用すると、クライアントはエンドポイントにリクエストを送信し、モデルからレスポンスを受け取ることができます。
モニタリングとロギングを構成する: エンドポイントのパフォーマンス、リソース使用率、エラーログを追跡するようにモニタリングシステムとロギングシステムを設定します。
カスタム統合をデプロイする: モデルの SDK または API を使用して、モデルをカスタムアプリケーションまたはサービスに統合します。
リアルタイムアプリケーションをデプロイする: データを処理し、リアルタイムでレスポンスを生成するストリーミングパイプラインを作成します。

ロギングとモニタリング

生成 AI アプリケーションとそのコンポーネントをモニタリングするには、従来の MLOps で使用するモニタリング手法に追加できる手法が必要です。アプリケーションの全体的な入力と出力、およびすべてのコンポーネントのロギングとモニタリングを含め、アプリケーションをエンドツーエンドでロギングしてモニタリングする必要があります。

アプリケーションへの入力により、複数のコンポーネントがトリガーされ、出力が生成されます。特定の入力に対する出力が事実と異なる場合は、どのコンポーネントが適切に機能しなかったかを判断する必要があります。実行されたすべてのコンポーネントのロギングでリネージが必要です。入出力の分析ができるように、入力とコンポーネントを、それらが依存する追加のアーティファクトとパラメータにマッピングする必要もあります。

モニタリングを適用する場合は、アプリケーションレベルのモニタリングを優先します。アプリケーションレベルのモニタリングでアプリケーションが正常に動作していることが確認された場合、すべてのコンポーネントも正常に動作していることになります。その後、プロンプトモデルコンポーネントにモニタリングを適用して、より詳細な結果を取得し、アプリケーションをより深く理解します。

MLOps の従来のモニタリングと同様に、ドリフト、スキュー、パフォーマンスの低下が検出されたときにアプリケーションの所有者に通知するアラートプロセスをデプロイする必要があります。アラートを設定するには、アラートと通知ツールをモニタリングプロセスに統合する必要があります。

以降のセクションでは、スキューとドリフトのモニタリングと継続的評価タスクについて説明します。また、MLOps のモニタリングには、リソース使用率やレイテンシなどのシステム全体の健全性に関する指標のモニタリングも含まれます。これらの効率指標は、生成 AI アプリケーションにも適用されます。

スキュー検出

従来の ML システムでのスキュー検出は、本番環境での特徴データの分布が、モデルのトレーニング中に観測された特徴データの分布と異なる場合に発生するトレーニング / サービングスキューを指します。出力を生成するために連鎖されたコンポーネントで事前トレーニング済みモデルを使用する生成 AI アプリケーションの場合は、スキューも測定する必要があります。スキューを測定するには、アプリケーションの評価に使用した入力データの分布と、本番環境のアプリケーションへの入力の分布を比較します。2 つの分布が離れている場合は、さらに調査する必要があります。出力データにも同じプロセスを適用できます。

ドリフト検出

スキュー検出と同様に、ドリフト検出では 2 つのデータセット間の統計的差異がチェックされます。ただし、ドリフトは評価とサービング入力を比較するのではなく、入力データの変化を探します。ドリフトを使用すると、入力と、それに伴うユーザーの行動の変化を評価できます。

通常、アプリケーションへの入力はテキストであるため、さまざまな方法でスキューとドリフトを測定できます。一般に、これらのメソッドは、評価データセットと比較して、本番環境のデータにおけるテキスト（入力サイズなど）とコンセプト（入力のトピックなど）の両方の大幅な変化を特定しようとします。これらの方法はすべて、アプリケーションが新しいデータの性質を適切に処理する準備ができていない可能性を示す変化を探しています。一般的な方法には、次のようなものがあります。

エンベディングと距離の計算
テキストの長さとトークン数をカウントする
データセット内の語彙の変化、新しいコンセプトとインテント、プロンプトとトピックの追跡
最小二乗密度差（PDF）、最大平均不一致（MMD）、学習済みカーネル MMD（PDF）、コンテキスト認識 MMD などの統計的アプローチを使用します。

生成 AI のユースケースは非常に多様であるため、データの予期しない変化をより適切に捉える追加のカスタム指標が必要になる場合があります。

継続評価

継続的評価は、生成 AI アプリケーションのモニタリングの一般的なアプローチです。継続的評価システムでは、モデルのプロダクション出力を取得し、その出力を使用して評価タスクを実行して、モデルのパフォーマンスを継続的に追跡します。ユーザーからの直接的なフィードバック（評価など）を収集できます。これにより、出力の品質に関するユーザーの認識をすぐに把握できます。並行して、モデル生成のレスポンスを確立されたグラウンドトゥルースと比較することで、パフォーマンスをより深く分析できます。グラウンドトゥルースは、人間の評価を通じて収集することも、アンサンブル AI モデルアプローチの結果として収集して評価指標を生成することもできます。このプロセスでは、モデルの開発時から現在本番環境で使用しているモデルまでの評価指標の変化を確認できます。

管理

MLOps のコンテキストでは、ガバナンスは、コード、データ、モデルのライフサイクルに関連するすべてのアクティビティを含む、ML モデルの開発、デプロイ、継続的な管理に対する制御、説明責任、透明性を確立するすべてのプラクティスとポリシーを網羅します。

予測 AI アプリケーションでは、リネージは ML モデルの完全なジャーニーの追跡と理解に重点を置いています。生成 AI では、リネージはモデルアーティファクトを超えて、チェーン内のすべてのコンポーネントに拡張されます。トラッキングには、データ、モデル、モデルリネージ、コード、相対的な評価データと指標が含まれます。リネージトラッキングは、モデルの監査、デバッグ、改善に役立ちます。

これらの新しいプラクティスに加えて、標準の MLOps と DevOps のプラクティスを使用して、データライフサイクルと生成 AI コンポーネントのライフサイクルを管理できます。

次のステップ

Vertex AI を使用して生成 AI アプリケーションをデプロイする

作成者: Anant Nawalgaria、Christos Aniftos、Elia Secchi、Gabriela Hernandez Larios、Mike Styer、Onofrio Petragallo

生成 AI アプリケーションをデプロイして運用する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。