AIP生成AIアプリケーションの運用効率と最適化
スタートアップ企業が、Claude 3.5 Sonnet
・Meta Llama 3
・Amazon Nova Proの3モデルをA/Bテストしながら最適なモデルを選択できるチャットボットを開発しています。モデルを切り替える際にアプリケーションコードの変更を最小限に抑えたいと考えています。最も適切な実装アプローチはどれですか？
A各モデルに対してInvokeModel APIを使用し、モデルごとに異なるリクエストボディを動的に生成するファクトリパターンを実装する
InvokeModelはモデルごとにリクエストボディの形式が異なり、ファクトリパターンでもモデル追加・切り替えのたびにペイロード生成ロジックの変更が必要です。コード変更の最小化という要件に反します。
BAmazon Bedrock Converse APIを採用し、modelIdパラメータのみを変更することで複数モデルを統一インターフェースで呼び出す
✓ 正解
Bedrock Converse APIはClaude・Llama・Nova等を統一されたリクエスト/レスポンス形式で扱え、messagesやinferenceConfigを共通化できます。modelIdを変えるだけで切り替え可能でA/Bテストや段階移行に最適です。
CAmazon Bedrock Agentsを使用して、各基盤モデルをサブエージェントとして登録・管理する
Bedrock Agentsで各モデルをサブエージェント化する構成は、本来不要なオーケストレーション層を追加し複雑性と管理負荷を高めます。単純なモデル切り替えには過剰な設計です。
DAWS AppSyncのカスタムリゾルバーに各モデル固有の呼び出しロジックを実装する
AppSyncのカスタムリゾルバーにモデル固有ロジックを実装すると、モデルを切り替えるたびにリゾルバーの修正が必要で、コード変更を最小化したい要件を満たせません。
解説
正解：
Amazon Bedrock Converse APIを採用し、modelIdパラメータのみを変更することで複数モデルを統一インターフェースで呼び出す。
Amazon Bedrock Converse APIは、Claude・Llama・Amazon Nova等サポートされるすべての基盤モデルに対して統一されたリクエスト/レスポンス形式を提供します。messagesフィールド・systemプロンプト・inferenceConfigを共通フォーマットで記述できるため、modelIdを変更するだけでモデル切り替えが可能で、A/Bテストや段階的なモデル移行に最適です。
選択肢Aは、モデルごとに異なるペイロード形式が必要で、切り替えのたびにコード変更が発生します。
選択肢Cは、各基盤モデルをサブエージェントとして登録・管理する方法で、複雑性が増し管理負荷が高くなります。
選択肢Dは、AWS AppSyncのカスタムリゾルバーに各モデル固有の呼び出しロジックを実装する方法で、モデル切り替えのたびにリゾルバー修正が必要になります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →