生成 AI アプリケーションを開発する

このドキュメントでは、生成 AI アプリケーションの開発の各段階における課題への対処方法について説明します。モデルの選択方法や、ニーズに合わせてモデルの出力をカスタマイズする方法、カスタマイズの評価方法、モデルのデプロイ方法について説明します。このドキュメントでは、すでにユースケースが検討されており、そのユースケースが生成 AI に適していることを前提としています。ユースケースの開発方法については、生成 AI のビジネス ユースケースの評価と定義をご覧ください。

生成 AI アプリケーションの開発を開始する前に、組織の技術的な準備状況（能力とインフラストラクチャ）を評価します。AI 機能を評価し、その可能性を活用するためのロードマップを作成する方法については、AI 対応準備のワークショップをご覧ください。生成 AI によって自動化されるワークフローを開発する場合は、重要な決定段階に人間を介在させるかどうかを評価します。人間による審査は、責任ある使用の担保、特定の品質管理要件の遵守、生成されたコンテンツのモニタリングなどの判断に役立ちます。

生成 AI モデル

生成 AI の基盤モデルは、テキスト、画像、コード、その他のマルチメディアのマルチテラバイトのデータセットでトレーニングされます。モデルは、データとモデル アーキテクチャによって複雑なパターンを識別し、コンテキストを深く理解して、トレーニング データに基づいてテキスト、画像、音楽、動画などの新しいコンテンツを生成します。

基盤モデルは、さまざまな生成 AI アプリケーションを構築するコアとなるモデルです。モデルの能力は新たな能力に変換されます。生成 AI の基盤モデルは、シンプルなテキスト プロンプトの指示に従って学習を行い、言語の翻訳、質問への回答、詩の作成、コードの作成など、さまざまなタスクを実行します。それぞれのタスクに対して明示的なトレーニングを行う必要はありません。生成 AI の基盤モデルは、いくつかのプロンプト手法で特定のタスクに適応させることができます。また、最小限のトレーニング データを追加してファインチューニングすることもできます。

大規模言語モデル（LLM）はテキストでトレーニングされます。これは、Google が 2017 年に開発した Transformer などのディープラーニング アーキテクチャに基づく基盤モデルの一例です。LLM は何十億ものテキスト サンプルやその他のコンテンツでトレーニングし、特定の分野に合わせてカスタマイズできます。

他のマルチモーダル モデルは生成 AI アプリケーションの機能を拡張し、画像、動画、音声、テキストなどの複数のモダリティからの情報を処理できるようにします。マルチモーダル プロンプトは、テキスト、画像、音声などの複数の入力形式を組み合わせたものです。たとえば、画像を入力し、生成 AI アプリケーションに画像内の物体をリスト化または説明するように指示できます。Google の Gemini モデルは、マルチモーダル用にゼロから構築されたモデルで、テキスト、画像、動画、音声、コードからシームレスに推論を行います。Google Cloud の Model Garden と Vertex AI を使用すると、Google、オープンソース、サードパーティから提供されている様々な基盤モデルを検索し、モデルをカスタマイズできます。

モデルを選択する

モデルを選択する際は、モデルのモダリティ、サイズ、コストを考慮する必要があります。レスポンスの品質とレイテンシの要件を満たす最適なモデルを選択します。

  • モダリティ: 前のセクションで説明したように、モデルのモダリティは、モデルがトレーニングされる上位データのカテゴリ（テキスト、画像、動画など）に対応します。通常、ユースケースとモデルのモダリティは密接に関連しています。テキストから画像の生成がユースケースに含まれている場合は、テキストと画像データでトレーニングされたモデルを見つける必要があります。マルチモーダル検索のようにモダリティの柔軟性が必要な場合は、マルチモーダル ユースケースをサポートするモデルを使用できますが、その場合、費用とレイテンシが高くなる可能性があります。
    • Vertex AI モデルには、使用できる生成 AI モデルのリストが用意されています。
    • Model Garden には、Google Cloud で利用できるファースト パーティおよびオープンソースの ML モデルの一覧が表示されます。
  • サイズ: 通常、モデルのサイズはパラメータの数で測定されます。一般に、モデルが大きいほど、データ内の複雑なパターンと関係を学習し、高品質のレスポンスを得ることができます。同じファミリーでは、モデルのサイズが大きいほど、レイテンシとコストが高くなる可能性があります。ユースケースに最適なモデルサイズを決定するために、モデルをテストして評価する必要があります。

  • コスト: モデルのコストはその機能に関連します。これは通常、モデルのパラメータ数に関連します。モデルの測定と課金方法が異なる場合もあります。たとえば、入力トークンと出力トークンの数に基づいて課金されるモデルもあれば、モデルのデプロイ中に使用されるノード時間数に基づいて課金されるモデルもあります。

    • Vertex AI での生成 AI モデルの料金については、Vertex AI の料金をご覧ください。

    • Google Kubernetes Engine（GKE）にモデルをデプロイする際の費用については、GKE の料金をご覧ください。

  • 機能: すべてのモデルがチューニングや抽出などの機能をサポートしているわけではありません。これらの機能が重要な場合は、各モデルでサポートされている機能を確認してください。

プロンプトを設計する

プロンプト設計とは、プロンプトとレスポンスのペアを作成して、言語モデルに追加のコンテキストと指示を与えるプロセスです。プロンプトを作成したら、プリトレーニング用のプロンプト データセットとしてモデルにフィードします。モデルが予測を処理し、組み込みの指示が返されます。

特定の出力を取得したい場合は、部分的な入力を補完するようにモデルに指示したり、モデルに理想的な回答の例を与えるなどのプロンプト設計戦略を使用できます。詳細は、プロンプト設計の概要をご覧ください。

モデルをカスタマイズする

プロンプト設計の後、モデルのレスポンスがうまく機能することが確認できれば、カスタマイズの必要はありません。モデルのパフォーマンスが良好でない（ハルシネーションを起こしているなど）場合は、追加のカスタマイズ手法を使用できます。以降のセクションでは、このような手法を紹介し、これらのオプションがモデルの出力にどのように影響するかについて説明します。

関数の呼び出しと拡張機能

関数呼び出しと Vertex AI 拡張機能を使用すると、モデルの機能を拡張できます。アプリケーションのユースケースと、既存のモデルでは十分な結果が得られない場合について検討してみてください。そのような場合は、関数の呼び出しや拡張機能を追加することでモデルを支援できます。たとえば、モデルでテキストからカレンダー情報を抽出し、拡張機能を使用して予約を検索して予約を行うことができます。

関数の呼び出しと拡張機能は同じように使用できますが、大まかな違いがいくつかあります。関数呼び出しは非同期オペレーションであるため、コードに認証情報を含める必要はありません。Vertex AI Extensions には、複雑なタスクに使用できるビルド済みのオプションが用意されているため、独自の関数を作成する必要がありません。ただし、Vertex AI Extensions は関数を返して呼び出すため、コードに認証情報を含める必要があります。

グラウンディング

グラウンディングとは、検証可能な情報源にモデルのレスポンスを関連付けることで、モデルのレスポンスを拡張することです。モデルをグラウンディングするには、モデルをデータソースに接続します。モデルをグラウンディングすると、ハルシネーションを減らし、生成されたコンテンツの信頼性を高めることができます。

検索拡張生成（RAG）は、広く使用されているグラウンディングの手法です。RAG は検索機能を利用して関連情報を検索し、その情報をモデルのプロンプトに追加します。RAG を使用すると、出力は事実と最新情報に基づいて生成されます。RAG 検索では、ベクトル エンベディングとベクトル データベースを使用します。これらのデータベースでは、データがテキストや画像などの非構造化データの数値表現として保存されます。詳細については、ベクトル データベースとはをご覧ください。

Vertex AI でのグラウンディングの詳細については、グラウンディングの概要をご覧ください。AlloyDB for PostgreSQL にエンベディング ワークフローを設定する方法については、エンベディング ワークフローの例をご覧ください。

モデルのチューニング

特定の用語について言語モデルをトレーニングする場合など、特殊なタスクでは、プロンプト設計だけでは十分なトレーニングを実施できない場合があります。このシナリオでは、モデルをチューニングしてパフォーマンスを改善し、モデルが特定の出力要件を満たすようにすることができます。

モデルをチューニングするには、トレーニング データセットを構築してから、教師ありチューニング、人間からのフィードバックを用いた強化学習（RLHF）チューニング、モデルの抽出などのチューニング方法を選択する必要があります。データセットのサイズとチューニング方法は、モデルと最適化の対象によって異なります。たとえば、ニッチなタスクで大幅な改善を行うには、小さなデータセットが必要です。モデルのチューニングの詳細については、言語の基盤モデルをチューニングするをご覧ください。

モデルを評価する

モデルの評価は、プロンプトとカスタマイズがモデルのパフォーマンスに与える影響を評価する際に役立ちます。評価方法にはそれぞれ長所と短所があります。たとえば、指標ベースの評価は自動化し、パフォーマンスを測定する定量的な方法で迅速にスケーリングできます。ただし、指標は単純になりすぎ、自然言語のコンテキストやニュアンスを見落としてしまう可能性があります。こうした欠点を補うため、人間による評価と組み合わせてさまざまな指標を使用します。

Vertex AI の生成 AI では、比較評価を自動的に実行し、2 つのモデルの出力を正解と比較できます。これにより、3 つ目のモデルがより質の高い回答を選択できるようになります。自動比較評価は人間の評価者と同等ですが、より迅速かつオンデマンドで使用できます。ただし、比較を行う場合、評価対象のモデルよりも大きなモデルが必要になるため、固有のバイアスが生じる可能性があります。そのため、人間による評価を引き続き行う必要があります。

どの評価方法でも評価用のデータセットが必要です。評価用のデータセットには、作成したプロンプトと正解（理想的なレスポンス）のペアが含まれます。データセットを構築するときは、有意な結果を得るために、評価するタスクに合わせたさまざまな例を含める必要があります。

モデルをデプロイする

モデルのデプロイでは、オンラインで低レイテンシの予測を提供するために、エンドポイントと物理マシンリソースをモデルに関連付けます。すべてのモデルでデプロイが必要なわけではありません。たとえば、Vertex AI の生成 AI で利用可能な Google の基盤モデルには、すでにエンドポイントがあります。このエンドポイントは Google Cloud プロジェクトに固有のものであり、すぐに使用できます。ただし、これらのモデルをチューニングする場合は、エンドポイントにデプロイする必要があります。

モデルをデプロイする際は、モデルをフルマネージド環境にデプロイするか、セルフマネージド環境にデプロイするかを決めます。フルマネージド環境では、マシンタイプやアクセラレータ タイプなどの必要な物理リソースを選択すると、Vertex AI がリソースをインスタンス化して管理します。たとえば、Vertex AI がデプロイ リソースを管理するオンライン予測を有効にするには、エンドポイントにモデルをデプロイするをご覧ください。セルフマネージド環境では、リソースをきめ細かく制御できますが、管理はユーザー自身で行います。セルフマネージド環境では、GKE などのプラットフォームでモデルをサービングできます。

デプロイする環境の種類を決定したら、予想されるトラフィック、レイテンシの要件、予算を検討します。これらの要素と物理リソースのバランスを取る必要があります。たとえば、コスト削減が最優先事項であれば、低コストのマシンを使用してレイテンシの増加を許容することも考えられます。テスト環境は、このトレードオフの良い例です。マシンタイプの選択方法の詳細については、ノートブック「Vertex AI エンドポイントに使用する最適なマシンタイプの決定」をご覧ください。

責任ある AI

Vertex AI の生成 AI は、Google の AI の原則を念頭に置いて設計されています。ただし、モデルをテストし、安全かつ責任を持って使用することが重要です。LLM は非常に汎用性が高いため、意図しないレスポンスや予期しないレスポンスを予測することは困難です。

ユースケースのアプリケーションを開発する場合は、潜在的な誤用や意図しない問題を軽減できるように生成 AI モデルの制限を検討する必要があります。モデルの品質は使用するデータで決まります。モデルに最適でないデータ（不正確なデータや不完全なデータなど）を渡すと、最適なパフォーマンスを得ることはできません。入力データとプロンプトが正確でなければ、モデルが最適なパフォーマンスを発揮できなかったり、モデル出力が正しく行われない可能性があります。生成 AI モデルの制限事項の詳細については、責任ある AI をご覧ください。

次のステップ