ジェネレーティブAIソリューションの戦略が決まれば、完了すべきタスクを含むワークフローを計画することができる。
次の表は、プランに含めることができる高レベルのタスクと、各タスクがニーズに応じて必須、推奨、オプション、または場合によっては必須であるかどうかを示しています。 一部の状況でのみ必要とされるタスクもあるが、すべての状況で推奨されるタスクもある。
タスク | 必須ですか? |
---|---|
AIのユースケースを定義する | 時々、お勧め |
ガバナンス・ワークフローの開発 | 時々 |
プロジェクトのセットアップ | 必須 |
データ準備 | 時々 |
プロンプトを使った実験 | 必須 |
プロンプトを評価する | 時々、お勧め |
foundation modelの最適化 | 時々 |
ソリューションの展開 | 必須 |
ソリューションの監視と保守 | 時々、お勧め |
AIユースケースの定義
AIユースケースは、モデルやプロンプトテンプレートなどのAI資産のライフサイクルに関する系譜、履歴、その他の関連情報を含む一連のファクトシートで構成される。
あなたの組織は、透明性や規制遵守のために、AIソリューションを追跡し、文書化することを要求するかもしれません。 しかし、AIのユースケースは、ソリューションに関する進捗、意思決定、測定基準を追跡する統合的な方法を提供するため、必要でない場合でも有用である。
AIのユースケースを作成するには、まずインベントリーを作成し、次にユースケースを作成する。 データサイエンティスト、データエンジニア、およびソリューションの作成、テスト、管理に関与するその他のユーザーを、ユースケースの共同作業者として追加します。
AIのユースケースの定義について学ぶ
ガバナンス・ワークフローの開発
ガバナンス・ワークフローは、AIのユースケースとモデル使用のレビューと承認プロセスを強制する。
あなたの組織では、以下のタイプのガバナンス・ワークフローの1つ以上が必要になるかもしれない:
- AIユースケースの承認、 foundation modelの承認、リスク評価の実行、モデルのパフォーマンス監視の自動化を行うモデルリスクガバナンスワークフロー。
- 規制コンプライアンス管理ワークフローは、規制当局から発表されるアラートを処理します。
- オペレーショナルリスク管理ワークフローにより、モデルリスクとその他のオペレーショナルリスクを全社的に追跡。
ガバナンス・ワークフローを設定するには、ガバナンス・コンソールで設定します。
ガバナンス・ワークフローの開発について学ぶ
プロジェクトの設定
プロジェクトとは、共有された目標を達成するために、人々がモデルやデータを使って作業する共同作業空間のことである。
プロンプトを作成し、実験を行い、モデルを調整するにはプロジェクトが必要だ。
AIエンジニアによって明示的に追加されるか、プロセスの結果として作成される:
- ベクターストアやトレーニングデータ、チューニングデータを保存する場所など、データソースへの接続アセット。
- モデルのトレーニングやチューニングのためのデータセットを表すデータ資産。
- プロンプトのセッション資産は、将来の参照用に保存します。
- 推論のためのエンドポイントを提供するプロンプト・テンプレート・アセット。
- 作成したノートブック、またはプロンプトをノートブックとして保存したり、 AutoAI 実験を実行したりするプロセスによって生成されたノートブック。
- RAGパターンのベクトル化された文書を表すベクトルインデックス。
- AutoAI, Tuning Studio、 Synthetic Data Generatorなどのツールを使用して作成した実験アセットやフローアセット。
- RAGのようなAIパターンのエンドポイントを提供するAIサービス資産。
- ツールでアセットを実行することによって作成されるジョブ。
自動作成されたサンドボックス・プロジェクトがある。 しかし、自分の目標を反映した名前のプロジェクトを作りたいと思うかもしれない。 プロジェクトの作成は、ホームページまたはナビゲーションメニューから行うことができます。 解決策に取り組んでもらいたい人全員を追加する。 各コラボレーターにロールを割り当て、プロジェクト内での権限をコントロールします。
プロジェクト作成の詳細
データの準備
データ準備には、ソリューションが必要とするフォーマットと品質レベルで、必要なデータへのアクセスを提供することが含まれます。
RAGパターンで文書を用いてモデルの根拠とする場合、プロンプトテンプレートを評価する場合、またはfoundation modelを調整する場合には、データを準備する必要がある。 ユースケースが翻訳、要約、分類、テキスト生成の場合は、評価を実行するのでなければ、データを準備する必要はないかもしれない。
RAGパターンでは、効率的な検索のために、ドキュメントを埋め込みベクトルに変換する。 ベクトル化された文書をベクトルストアに保存し、ベクトルインデックスで検索する。 以下の方法でRAGパターンに文書を含めることができます:
- ローカルシステムからドキュメントファイルをアップロードし、ベクターストアに追加します
- 既存のベクターストアにあるドキュメントを指定する
- 接続されたデータソースからベクトルストアにドキュメントを追加する
RAGパターンの作成方法は、ドキュメントの総サイズや実験の自動化レベルなどに応じて、さまざまな方法から選ぶことができる。
プロンプトテンプレートの評価やfoundation modelのチューニングには、モデルへの代表的な入力と、それに対してモデルが生成する適切な出力を含むデータセットを提供する。 チューニングデータは以下の方法で提供できます:
- ローカルシステムからファイルをアップロードする
- データセットを含むデータソースに接続する
データ準備の詳細
プロンプトの実験
プロンプトとは、 foundation modelモデルに応答を生成するよう指示する方法である。
以下のように条件を変えてプロンプトを試すことができる:
- チャットモードと非チャットモードの切り替え
- プロンプトテキストまたはシステムプロンプトの変更
- foundation modelの変更
- モデルパラメーターの調整
- ガードレールの有効化と無効化
- チャットに画像やドキュメントを追加する
- 変数を追加してプロンプト・テキストを動的に変更する
- ツールを呼び出すエージェントの設定
プロンプトを開発するには、 Prompt LabまたはREST API、 Python、 Node.js コードで実験できます。 最適なRAGパターンを自動で見つけるには、 AutoAI for RAG実験を実行する。
プロンプトを使った実験の詳細
プロンプトの評価
プロンプトの評価では、選択した一連のメトリクスに対するモデル出力の品質をテストします。 いくつかのメトリクスは、テスト・データ・セットで提供された適切な出力とモデルの出力を比較することに基づいています。 モデルがいかに効率的にレスポンスを生成するかも評価される。
あなたの組織では、規制遵守や内部ポリシーのために評価が必要になるかもしれません。 しかし、評価指標のスコアはソリューションの品質を示すことができ、スコアが低下したときにユーザー満足度の低下を予測できる可能性があるため、評価は必要ない場合でも有用である。
プロンプトを評価する場合、以下の要素を設定できる:
- テストするサンプルサイズ
- どのメトリクスを含めるか
- 各メトリクスのしきい値
ジェネレーティブAIメトリクスは、プロンプトに関する以下のタイプの情報を提供する:
- 出力テキストと入力テキストの類似度
- 出力テキストが参照出力にどれだけ似ているか
- 入力テキストまたは出力テキストに有害情報や機密情報が含まれているかどうか
現在の成績と過去の成績を見ることができる。 各評価の結果は、プロンプトのユースケースに追加される。
プロンプトを評価するには、 Prompt Lab、コード、またはデプロイされたプロンプトテンプレートから評価を実行する。 RAGパターンの AutoAI 実験を実行すると、プロンプト候補が自動的に評価され、ランク付けされます。
複数のプロンプトテンプレートを同時に評価および比較するには、評価スタジオで評価実験を実行します。
プロンプトの評価について
foundation modelの最適化
foundation modelを最適化することで、モデルの1つ以上の性能指標が改善される。
精度、コスト、推論スループット、またはモデルライフサイクルの制御のために、ソリューションのfoundation modelモデルを最適化することができます。
foundation modelの展開方法は、以下の特徴によって異なる:
- 課金方法は、参照されたトークンごと、またはホストされた時間ごとです
- ホスティング環境はマルチテナントまたは専用ハードウェアを使用
- 配備の仕組みは、 IBMが行うか、またはお客様が行うかです
- モデルがチューニングされているかどうか
- 非推奨ポリシーは、 IBM またはお客様によって管理されます
マルチテナント・ハードウェア上でモデルを実行し、トークンごとに料金を支払い、 IBMがモデルのライフサイクルを管理するには、 IBMが提供し、デプロイするモデルを選択します。
foundation modelをチューニングするには、チューニング方法を選択し、チューニングデータを追加し、 Tuning Studioまたはコードでジョブを実行します。 そして、チューニングされたモデルをマルチテナントのハードウェア上に展開し、トークンごとに支払い、モデルのライフサイクルをコントロールする。
専用ハードウェアでモデルを実行し、時間ごとに料金を支払い、モデルのライフサイクルを制御するには、カスタムモデルをインポートしてデプロイするか、オンデマンドモデルをデプロイします。
基礎モデルの最適化について詳しくはこちら
ソリューションの展開
アセットをデプロイすると、エンドポイントでのテストや生産的な使用に利用できるようになります。 デプロイメントを作成したら、それをテストして管理し、本番前環境や本番環境にデプロイするための資産を準備することができます。
デプロイメントは、デプロイメント スペースで作成します。デプロイメント スペースは、プロジェクトとは別のワークスペースであり、別のコラボレータ セットを追加できます。
ほとんどのタイプの gen AI アセットを配置するには、アセットを配置スペースに昇格させ、エンドポイントを含む配置を作成します。 そして、アプリケーションからエンドポイントを呼び出して、 foundation modelを推論することができる。 変数を含まないプロンプトテンプレートの場合は、 Prompt Labからエンドポイントコードを直接コピーできます。 ModelOps ワークフローをサポートするために、テスト、ステージング、本番デプロイメント用に別々のデプロイメントスペースを作成することができます。
AIアセット導入の詳細
ソリューションの監視と保守
ソリューションをアプリケーションに組み込み、本番稼動させた後は、ソリューションを保守しなければなりません。 また、モデルのパフォーマンスをモニターすることもできる。 ソリューションのメンテナンスには、評価やユーザーからのフィードバックに基づいて、 foundation modelを更新したり、新しいバージョンに置き換えたり、モデルを最適化したりすることが含まれます。 ソリューションのモニタリングは、本番環境におけるモデルのパフォーマンスを評価します。
お客様の組織では、ソリューションを監視し、パフォーマンスが指定の閾値を下回らないようにすることが求められるかもしれません。
ソリューションを監視するには、配置スペースでソリューションの配置を開き、評価 を有効にします。 ペイロードロギングエンドポイントを使用して、公平性とドリフト評価のためのスコアリング要求を送信し、フィードバックロギングエンドポイントを使用して、品質評価のためのフィードバックデータを提供することができます。
お客様のソリューションのfoundation modelが IBMによって提供され、デプロイされている場合、 IBMはそのモデルを新しいバージョンに置き換える可能性があります。 IBMソリューションのモデルを非推奨にする場合、モデルが削除される前にソリューションを更新してモデルを変更する必要があります。 ソリューションのfoundation modelをデプロイした場合、パフォーマンスを向上させるためにモデルを定期的に更新したくなるかもしれません。
ソリューションの監視と保守について
親トピック 生成的AIソリューションの計画