生成 AI は、予測 AI とは異なる AI アプリケーションを構築して運用する新しい方法を導入しました。生成 AI アプリケーションを構築するには、さまざまなアーキテクチャとサイズから選択し、データをキュレートし、最適なプロンプトをエンジニアリングし、特定のタスク用にモデルをチューニングし、モデル出力を実際のデータにグラウンディングする必要があります。
このドキュメントでは、既存の基盤モデルで生成 AI アプリケーションを開発、デプロイ、運用するために、DevOps プロセスと MLOps プロセスを適応させる方法について説明します。予測 AI のデプロイについては、MLOps: ML における継続的デリバリーと自動化のパイプラインをご覧ください。
DevOps と MLOps とは
DevOps は、開発と運用をつなぐソフトウェア エンジニアリングの方法論です。DevOps は、継続的インテグレーションと継続的デリバリー（CI/CD）などのプラクティスを使用して、コラボレーション、自動化、継続的な改善を促進し、ソフトウェア開発ライフサイクルを効率化します。
MLOps は DevOps の原則に基づいて構築されており、ML システムの構築と運用の課題に対処します。通常、ML システムは予測 AI を使用してパターンを特定し、予測を行います。MLOps ワークフローには次のものが含まれます。
- データの検証
- モデルのトレーニング
- モデルの評価とイテレーション
- モデルのデプロイとサービング
- モデルのモニタリング
基盤モデルとは
基盤モデルは、生成 AI アプリケーションのコア コンポーネントです。これらのモデルは、データセットを使用して学習し、人間の介入なしで意思決定を行う大規模なプログラムです。基盤モデルは、テキスト、画像、音声、動画など、さまざまな種類のデータでトレーニングされます。基盤モデルには、Llama 3.1 などの大規模言語モデル（LLM）や、Gemini などのマルチモーダル モデルが含まれます。
特定のタスク向けに限定されたデータセットでトレーニングされる予測 AI モデルとは異なり、基盤モデルは膨大で多様なデータセットでトレーニングされます。このトレーニングでは、基盤モデルを使用して、さまざまなユースケース向けのアプリケーションを開発します。基盤モデルには新しいプロパティ（PDF）があり、明示的なトレーニングを行わなくても特定の入力に対する回答を提供できます。このような新しいプロパティのため、基盤モデルの作成と運用は困難であり、DevOps プロセスと MLOps プロセスを適応させる必要があります。
基盤モデルを開発するには、大量のデータリソース、専用のハードウェア、多大な投資、専門的な専門知識が必要です。そのため、多くの企業は、既存の基盤モデルを使用して生成 AI アプリケーションの開発とデプロイを簡素化することを好みます。
生成 AI アプリケーションのライフサイクル
生成 AI アプリケーションのライフサイクルには、次のフェーズがあります。
- 検出: デベロッパーと AI エンジニアは、ユースケースに最も適した基盤モデルを特定します。各モデルの長所、短所、費用を考慮して、十分な情報に基づいて意思決定を行います。
- 開発とテスト: デベロッパーはプロンプト エンジニアリングを使用して入力プロンプトを作成、調整し、必要な出力を取得します。利用可能な場合は、少数ショット学習、パラメータ エフィシエント ファインチューニング（PEFT）、モデル チェーンを使用してモデルの動作をガイドできます。モデルのチェーンとは、特定の順序で複数のモデルへの呼び出しをオーケストレートしてワークフローを作成することを指します。
- デプロイ: デベロッパーは、プロンプト テンプレート、チェーン定義、埋め込みモデル、取得データストア、ファインチューニング済みモデル アダプターなど、デプロイ プロセスで多くのアーティファクトを管理する必要があります。これらのアーティファクトには独自のガバナンス要件があり、開発とデプロイ全体で慎重な管理が必要です。生成 AI アプリケーションのデプロイでは、ターゲット インフラストラクチャの技術的な能力も考慮し、アプリケーションのハードウェア要件が満たされていることを確認する必要があります。
- 本番環境での継続的なモニタリング: 管理者は、モデルの出力の公平性、透明性、アカウンタビリティを確保するなど、責任ある AI 手法を通じてアプリケーションのパフォーマンスを向上させ、安全基準を維持します。
- 継続的な改善: デベロッパーは、プロンプト手法、モデルの新しいバージョンへの入れ替え、複数モデルの組み合わせなどを通じて、基盤モデルを絶えず調整し、パフォーマンス、費用対効果、レイテンシを向上させます。従来の継続的トレーニングは、反復的な微調整や人間のフィードバック ループの組み込みが必要なシナリオで引き続き有効です。
データ エンジニアリングの実践は、すべての開発段階で重要な役割を果たします。信頼できる出力を作成するには、事実に基づくグラウンディング（モデルの出力が正確で最新の情報に基づいていることを確認）と、内部システムとエンタープライズ システムからの最新のデータが必要です。チューニング データは、特定のタスクやスタイルにモデルを適応させ、永続的なエラーを修正するのに役立ちます。
ユースケースの基盤モデルを見つける
基盤モデルの構築はリソースを大量に消費するため、ほとんどの企業は、ユースケースに最適な既存の基盤モデルを使用することをおすすめします。基盤モデルは多数あるため、適切な基盤モデルを見つけるのは困難です。各モデルには、アーキテクチャ、サイズ、トレーニング データセット、ライセンスが異なります。また、各ユースケースには固有の要件があるため、複数のディメンションにわたって利用可能なモデルを分析する必要があります。
モデルを評価する際は、次の要素を考慮してください。
- 品質: テスト プロンプトを実行して出力の品質を測定します。
- レイテンシとスループット: これらの要素はユーザー エクスペリエンスに直接影響するため、ユースケースに必要な適切なレイテンシとスループットを決定します。たとえば、チャットボットでは、バッチ処理された要約タスクよりも低いレイテンシが必要です。
- 開発とメンテナンスにかかる時間: 初期開発と継続的なメンテナンスにかかる時間を検討します。マネージド モデルでは、自分でデプロイする公開モデルよりも労力が少なくなることがよくあります。
- 使用料: モデルに関連するインフラストラクチャと消費コストを考慮します。
- コンプライアンス: 関連する規制とライセンス条項に準拠するモデルの能力を評価します。
開発とテスト
生成 AI アプリケーションを構築する場合、開発とテストは反復的かつオーケストレートされます。各テストの反復処理では、データの精緻化、基盤モデルの適応、結果の評価が行われます。評価では、継続的なフィードバック ループで後続のイテレーションをガイドするフィードバックが提供されます。パフォーマンスが期待どおりにない場合は、追加のデータを収集したり、データを拡張したり、データをさらにキュレートしたりできます。また、プロンプトを最適化したり、ファインチューニング手法を適用したり、別の基盤モデルに変更したりする必要がある場合があります。評価の分析情報に基づくこの反復的な改善サイクルは、機械学習や予測 AI の場合と同様に、生成 AI アプリケーションの最適化においても重要です。
基盤モデルのパラダイム
基盤モデルは多目的モデルであるため、予測モデルとは異なります。基盤モデルは、特定のタスクに固有のデータで単一の目的のためにトレーニングされるのではなく、幅広いデータセットでトレーニングされるため、さまざまなユースケースに基盤モデルを適用できます。
また、基盤モデルは入力の変化に非常に敏感です。モデルの出力と実行するタスクは、モデルへの入力によって決まります。基盤モデルは、入力を変更するだけでテキストを翻訳したり、動画を生成したり、データを分類したりできます。入力にわずかな変更を加えるだけで、モデルがそのタスクを正しく実行する能力に影響する可能性があります。
基盤モデルのこれらの特性には、異なる開発と運用のプラクティスが必要です。予測 AI のコンテキスト内のモデルは自己完結型でタスク固有ですが、基盤モデルは多目的であり、ユーザー入力以外の要素が必要です。生成 AI モデルにはプロンプト、特にプロンプト テンプレートが必要です。プロンプト テンプレートは、手順と例のセットと、ユーザー入力に対応するプレースホルダです。アプリケーションは、プロンプト テンプレートと動的データ（ユーザー入力など）を組み合わせて、完全なプロンプトを作成できます。このプロンプトは、基盤モデルへの入力として渡されるテキストです。
プロンプト モデル コンポーネント
プロンプトの存在は、生成 AI アプリケーションの特徴です。モデルとプロンプトだけではコンテンツを生成できません。生成 AI には両方が必要です。モデルとプロンプトの組み合わせは、プロンプト付きモデル コンポーネントと呼ばれます。プロンプト モデル コンポーネントは、生成 AI アプリケーションの作成に十分な最小の独立したコンポーネントです。プロンプトは複雑である必要はありません。たとえば、「次の文を英語からフランス語に翻訳してください」などの簡単な指示に続いて、翻訳する文を指定します。ただし、この予備的な指示がないと、基盤モデルは必要な翻訳タスクを実行しません。そのため、基盤モデルにアプリケーションで必要なタスクを実行させるには、入力とともにプロンプト（基本的な指示でもかまいません）が必要です。
プロンプト付きモデル コンポーネントは、生成 AI アプリケーションを開発する際の MLOps プラクティスと重要な違いを生み出します。生成 AI アプリケーションの開発では、プロンプト付きモデル コンポーネントのコンテキストでテストと反復処理を行う必要があります。通常、生成 AI のテストサイクルは、プロンプトのバリエーションをテストすること（手順の文言の変更、コンテキストの追加、関連する例の追加）から始まり、それらの変更の影響を評価します。この手法は、一般にプロンプト エンジニアリングと呼ばれます。
プロンプト エンジニアリングには、次の反復的な手順が含まれます。
- プロンプト: プロンプトを作成して調整し、特定のユースケースの基盤モデルから望ましい動作を引き出します。
- 評価: モデルの出力を評価します（理想的にはプログラムで評価します）。これにより、プロンプトの指示を理解し、実行できたかどうかを判断できます。
評価結果を追跡するには、必要に応じてテストの結果を登録します。プロンプト自体はプロンプト エンジニアリング プロセスのコア要素であるため、実験の一部であるアーティファクトの中で最も重要なアーティファクトになります。
ただし、生成 AI アプリケーションをテストするには、アーティファクトのタイプを特定する必要があります。予測 AI では、データ、パイプライン、コードが異なります。一方、生成 AI のプロンプト パラダイムでは、プロンプトにはコンテキスト、指示、例、ガードレール、他の場所から取得した実際の内部データまたは外部データを含めることができます。
アーティファクトのタイプを特定するには、プロンプトに異なるコンポーネントがあり、異なる管理戦略が必要であることを認識する必要があります。次の点を考慮してください。
- データとしてのプロンプト: プロンプトの一部はデータのように動作します。少数ショットの例、ナレッジベース、ユーザーのクエリなどの要素は、基本的にデータポイントです。これらのコンポーネントには、データ検証、ドリフト検出、ライフサイクル管理などのデータ中心の MLOps プラクティスが必要です。
- コードとしてのプロンプト: コンテキスト、プロンプト テンプレート、ガードレールなどの他のコンポーネントはコードに似ています。これらのコンポーネントは、プロンプト自体の構造とルールを定義します。承認プロセス、コード バージョニング、テストなど、よりコード中心のプラクティスが必要になります。
そのため、MLOps のプラクティスを生成 AI に適用する場合は、デベロッパーがプロンプトを簡単に保存、取得、追跡、変更できるプロセスが必要です。これらのプロセスにより、迅速な反復と原則に基づくテストが可能になります。多くの場合、1 つのバージョンのプロンプトは特定のバージョンのモデルでは適切に機能しますが、別のバージョンでは適切に機能しません。テストの結果を追跡する場合は、プロンプト、コンポーネントのバージョン、モデルのバージョン、指標、出力データを記録する必要があります。
モデルのチェーンと拡張
生成 AI モデル、特に大規模言語モデル（LLM）は、最新情報を維持し、幻覚を回避するという固有の課題に直面しています。新しい情報を LLM にエンコードするには、デプロイする前に費用が高くデータ集約型のプリトレーニングが必要です。ユースケースによっては、プロンプト付きモデルを 1 つだけ使用して特定の生成を実行することが不十分な場合があります。この問題を解決するには、複数のプロンプト モデルを接続し、外部 API の呼び出しとコードとして表現されたロジックを接続します。このように連結されたプロンプト モデル コンポーネントのシーケンスを、一般にチェーンと呼びます。
次の図は、チェーンのコンポーネントと関連する開発プロセスを示しています。
直近とハルシネーションの軽減
直近性とハルシネーションを軽減できる 2 つの一般的なチェーンベースのパターンは、検索拡張生成（RAG）（PDF）とエージェントです。
- RAG は、事前トレーニング済みモデルにデータベースから取得した知識を拡張します。これにより、事前トレーニングの必要がなくなります。RAG は、最新の事実情報を生成プロセスに直接組み込むことで、グラウンディングを可能にし、幻覚を減らします。
- ReAct プロンプト手法（PDF）で普及したエージェントは、LLM を仲介者として使用し、RAG システム、内部または外部 API、カスタム拡張機能、さらには他のエージェントなど、さまざまなツールとやり取りします。エージェントは、関連する情報ソースを動的に選択して使用することで、複雑なクエリとリアルタイム アクションを可能にします。LLM はエージェントとして機能し、ユーザーのクエリを解釈し、使用するツールを決定し、取得した情報に基づいてレスポンスを作成します。
RAG とエージェントを使用して、大規模な情報ネットワークに接続されたマルチエージェント システムを構築し、高度なクエリ処理とリアルタイムの意思決定を実現できます。
さまざまなモデル、ロジック、API のオケストレーションは、生成 AI アプリケーションにとって新しいものではありません。たとえば、レコメンデーション エンジンは、コラボレーション フィルタリング モデル、コンテンツベースのモデル、ビジネスルールを組み合わせて、ユーザー向けにパーソナライズされた商品レコメンデーションを生成します。同様に、不正行為の検出では、機械学習モデルがルールベースのシステムや外部データソースと統合され、不審なアクティビティを特定します。
これらの生成 AI コンポーネントのチェーンが異なるのは、コンポーネント入力の分布を事前に特徴付けることができないため、個々のコンポーネントを個別に評価して維持するのがはるかに困難になる点です。オーケストレーションにより、生成 AI 用の AI アプリケーションの開発方法にパラダイム シフトが起こります。
予測 AI では、個別のモデルとコンポーネントを個別に反復処理してから、AI アプリケーションで連結できます。生成 AI では、統合中にチェーンを開発し、チェーン全体でテストを実行し、チェーン戦略、プロンプト、基盤モデル、その他の API を調整して反復処理し、特定の目標を達成します。多くの場合、特徴量エンジニアリング、データ収集、追加のモデル トレーニング サイクルは必要ありません。プロンプト テンプレートの文言を変更するだけで済みます。
予測 AI の MLOps とは対照的に、生成 AI の MLOps へのシフトにより、次のような違いが生じます。
- 評価: チェーンは緊密に結合されているため、チェーンの全体的なパフォーマンスと出力の品質を評価するには、各コンポーネントだけでなくエンドツーエンドの評価が必要です。評価手法と指標の観点から、チェーンの評価はプロンプト付きモデルの評価に似ています。
- バージョニング: チェーンは、完全なアーティファクトとして全体を管理する必要があります。分析、再現性、出力への変更の影響を把握するために、独自のリビジョン履歴でチェーン構成を追跡する必要があります。ログには、入力、出力、チェーンの中間状態、各実行で使用されたチェーン構成を含める必要があります。
- 継続的なモニタリング: チェーン内のパフォーマンスの低下、データのずれ、予期しない動作を検出するには、プロアクティブなモニタリング システムを構成する必要があります。継続的なモニタリングにより、潜在的な問題を早期に特定し、生成された出力の品質を維持できます。
- イントロスペクション: チェーンの内部データフロー（各コンポーネントからの入力と出力）と、チェーン全体の入力と出力を検査する必要があります。チェーンを流れるデータとその結果のコンテンツを可視化することで、デベロッパーはエラー、バイアス、望ましくない動作の原因を特定できます。
次の図は、生成 AI アプリケーションでチェーン、プロンプト モデル コンポーネント、モデル チューニングが連携して、最近性と幻覚を軽減する仕組みを示しています。データがキュレートされ、モデルがチューニングされ、チェーンが追加されて、レスポンスをさらに絞り込むことができます。結果を評価した後、デベロッパーはテストをログに記録して、反復処理を続行できます。
ファインチューニング
基盤モデルを含む生成 AI のユースケースを開発する場合、特に複雑なタスクでは、プロンプト エンジニアリングとチェーンのみに依存してユースケースを解決するのは難しい場合があります。タスクのパフォーマンスを向上させるために、デベロッパーはモデルを直接微調整することがよくあります。ファインチューニングでは、モデルのすべてのレイヤまたはレイヤのサブセット（パラメータ効率的なファインチューニング）を積極的に変更して、特定のタスクを実行する能力を最適化できます。モデルをチューニングする一般的な方法は次のとおりです。
- 教師ありファインチューニング: 教師ありの方法でモデルをトレーニングし、特定の入力に対して正しい出力シーケンスを予測するようにモデルに教えます。
- 人間からのフィードバックを用いた強化学習（RLHF）: 報酬モデルをトレーニングして、人間が回答として好むものを予測します。次に、この報酬モデルを使用して、チューニング プロセス中に LLM を適切な方向に誘導します。このプロセスは、人間の審査員のパネルがモデルの学習をガイドするのと似ています。
次の図は、チューニングがテストサイクル中にモデルをどのように洗練させるかを示しています。
MLOps では、ファインチューニングはモデル トレーニングと次の機能を共有します。
- チューニング ジョブの一部であるアーティファクトを追跡する機能。たとえば、アーティファクトには、モデルのチューニングに使用される入力データやパラメータが含まれます。
- チューニングの影響を測定する機能。この機能を使用すると、トレーニングされた特定のタスクについてチューニング済みモデルを評価し、同じタスクの事前にチューニング済みモデルまたはフリーズ済みモデルと結果を比較できます。
継続的なトレーニングとチューニング
MLOps における継続的トレーニングは、本番環境で ML モデルを繰り返し再トレーニングする手法です。継続的なトレーニングにより、モデルを最新の状態に保ち、時間の経過とともに変化する実際のデータパターンに合わせてパフォーマンスを維持できます。生成 AI モデルの場合、データと計算コストが高いため、モデルの継続的なチューニングがトレーニング プロセスよりも実用的であることが多いです。
継続的なチューニングのアプローチは、特定のユースケースと目標によって異なります。テキスト要約など、比較的静的なタスクでは、継続的なチューニングの要件が低くなる場合があります。ただし、人間による継続的な調整が必要な chatbot などの動的アプリケーションでは、人間のフィードバックに基づく RLHF などの手法を使用して、より頻繁にチューニングする必要があります。
適切な継続的なチューニング戦略を決定するには、ユースケースの性質と、入力データの経時的な変化を評価する必要があります。コンピューティング インフラストラクチャはチューニングの速度と費用に大きな影響を与えるため、コストも重要な考慮事項です。画像処理装置（GPU）と Tensor Processing Unit（TPU）は、ファインチューニングに必要なハードウェアです。並列処理能力で知られる GPU は、コンピューティング負荷の高いワークロードの処理に非常に効果的であり、複雑な ML モデルのトレーニングと実行に関連付けられることがよくあります。一方、TPU は、機械学習タスクの高速化を目的として 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 の多くの評価指標は主観的です。出力の優劣は主観的な問題です。指標はユーザーの考えを信頼できるプロキシとするため、自動評価が人間の判断と一致するようにする必要があります。テスト間で比較できるようにするには、開発プロセスの早い段階で評価方法と指標を決定する必要があります。
- 特にプロジェクトの初期段階では、グラウンド トゥルース データが不足しています。回避策の一つは、人間のフィードバックに基づいて時間をかけて精度を高めることができる一時的なグラウンド トゥルースとして機能する合成データを生成することです。
- 生成 AI アプリケーションを敵対的攻撃から保護するには、包括的な評価が不可欠です。悪意のある攻撃者は、機密情報を抽出したり、モデルの出力を操作したりするためにプロンプトを作成する可能性があります。評価セットでは、プロンプト ファジング（プロンプトのランダムなバリエーションをモデルにフィードする）や情報漏洩のテストなどの手法を通じて、これらの攻撃ベクトルに具体的に対処する必要があります。
生成 AI アプリケーションを評価するには、以下を実装します。
- 評価プロセスを自動化して、速度、スケーラビリティ、再現性を高めます。自動化は人間の判断の代用と見なすことができます。
- ユースケースに応じて評価プロセスをカスタマイズします。
- 比較可能性を確保するには、開発フェーズでできるだけ早い段階で評価方法、指標、グラウンド トゥルース データを安定させます。
- 実際のグラウンド トゥルース データがない場合は、合成グラウンド トゥルース データを生成します。
- これらの攻撃に対するシステム自体の信頼性をテストするために、評価セットの一部として敵対的プロンプトのテストケースを含めます。
デプロイ
本番環境レベルの生成 AI アプリケーションは、多くの相互作用するコンポーネントを含む複雑なシステムです。生成 AI アプリケーションを本番環境にデプロイするには、これらのコンポーネントを管理し、生成 AI アプリケーション開発の前のステージと調整する必要があります。たとえば、単一のアプリケーションで、データベースとともに複数の 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 のコンテキストでは、ガバナンスには、コード、データ、モデルのライフサイクルに関連するすべてのアクティビティを含む、機械学習モデルの開発、デプロイ、継続的な管理に対する制御、説明責任、透明性を確立するすべてのプラクティスとポリシーが含まれます。
予測 AI アプリケーションでは、リネージは ML モデルの完全な経路の追跡と理解に重点を置いています。生成 AI では、リネージはモデル アーティファクトを超えて、チェーン内のすべてのコンポーネントに拡張されます。トラッキングには、データ、モデル、モデルリネージ、コード、相対評価データと指標が含まれます。リネージ トラッキングは、モデルの監査、デバッグ、改善に役立ちます。
これらの新しい手法に加えて、標準の MLOps と DevOps の手法を使用して、データ ライフサイクルを管理し、生成 AI コンポーネントのライフサイクルを管理できます。
次のステップ
Vertex AI を使用して生成 AI アプリケーションをデプロイする