AIP-C01 の無料練習問題
AWS Certified Generative AI Developer - Professional

この問題の要件は、(1) Converse API による呼び出し方式を変えず、modelId の値の差し替えだけで済ませること、(2) リクエストの少ない時間帯に事前確保のコンピュートの費用を出さないこと、の2点である。どちらか一方だけなら満たす選択肢があるため、各選択肢を2つの要件の両方に同時に照らす必要がある。B は、カスタム Amazon Nova モデルのカスタムモデルデプロイを作成してオンデマンド推論にする。オンデマンド推論は使った分だけの支払いで、プロビジョンドのコンピュートを設定する必要がない。modelId にはデプロイの ARN を指定するので、(1)(2) を両方満たす。A のプロビジョンドスループットは、modelId の差し替えで呼び出せる点では (1) を満たす。しかし推論用のコンピュートを事前に確保する方式であり、問題文が費用を出したくないとする事前確保のコンピュートそのものなので (2) に合わない。C は事前確保をしない点では (2) の方向に合うように見えるが、デプロイを作成しない点が誤りである。オンデマンド推論はカスタムモデルデプロイによって設定され、modelId に使うのはデプロイ作成時に返されるデプロイの ARN である。D は呼び出し先が SageMaker AI のエンドポイントに変わり (1) を満たさず、リアルタイムエンドポイントはリクエストがない時間もインスタンスの稼働分が課金されるため (2) にも合わない。

A：不正解。プロビジョンドスループットを購入することは、推論に使うコンピュートリソースを事前に確保することにあたる。これは、問題文が「リクエストがない時間帯に費用を発生させたくない」とする『事前確保したコンピュートリソース』そのものである。一方、カスタムモデルをオンデマンド推論で使えば、使った分だけの支払いで、プロビジョンドのコンピュートリソースを設定する必要がない。A は modelId の差し替えだけで呼び出せるため呼び出し方式の要件には収まるが、推論用のコンピュートを事前に確保する方式であるため費用要件を満たさない。

B：正解。SageMaker AI でトレーニングしたカスタム Amazon Nova モデルは、Bedrock にインポートした場合、カスタムモデルデプロイを作成するとオンデマンド推論で使える。オンデマンド推論は使った分だけの支払いで、プロビジョンドのコンピュートリソースを設定する必要がないため、リクエストのない時間帯に事前確保の費用が出ない。推論リクエストの modelId にはデプロイの ARN を指定する。呼び出しは Bedrock の API のままで、差し替えるのは modelId の値だけなので、問題文で許容された範囲に収まる。

C：不正解。カスタムモデルのオンデマンド推論は、カスタムモデルデプロイでモデルをデプロイすることによって設定する。カスタムモデル自体の ARN は、デプロイを作成するときに入力として渡す値であり、デプロイを作成すると応答としてデプロイの ARN が返される。推論リクエストの modelId に指定するのはこのデプロイの ARN である。この方法ではデプロイを作成しないため、オンデマンド推論が設定されず、modelId に指定すべきデプロイの ARN も発行されない。そのため、要件を満たす呼び出しにならない。

D：不正解。この構成は、呼び出し先が Bedrock ではなく SageMaker AI のエンドポイントになり、Converse API による呼び出し方式を変えない条件を満たさない。さらに、この選択肢が指すリアルタイムエンドポイントはリクエストがない時間もインスタンスが稼働し続けてその稼働分が課金されるため、事前確保したコンピュートリソースの費用を出さない要件にも合わない。

学習のポイント：SageMaker AI でトレーニングしたカスタム Amazon Nova モデルは、Bedrock のカスタムモデルデプロイでオンデマンド推論にできる。事前確保のコンピュートが不要で、modelId にはモデルの ARN ではなくデプロイの ARN を指定して呼び出す。

公式ドキュメント

• deploy-custom-model-on-demand.html

要件は、(1) 意味に基づく振り分け、(2) 同期応答、(3) SDK の再試行後に Bedrock を一切呼び出さない代替経路で回答すること(分類段階の失敗を含む)、(4) X-Ray による追跡の4点である。A は4要件をすべて満たす。Bedrock 上の小型モデルの分類結果を Choice ステートで判定して分岐し、Express ワークフローを同期実行する。分類と回答生成の Bedrock 呼び出しを SDK の指数バックオフで再試行し、失敗時は EC2 上のモデルへ遷移したうえで、X-Ray で追跡する。Choice ステートは各ルールを真偽評価して遷移先を決め、どのルールにも一致しない場合の遷移先は Default で指定できる。B は (2)(3)(4) を満たすが、StringMatches によるワイルドカードパターンとの文字列照合で分岐するため、言い回しが変わると同じ先へ振り分けられず (1) で落ちる。C は (1)(3)(4) を満たすが、Standard ワークフローの開始では実行 ARN しか返らず回答本文は別の呼び出しで取得することになるため (2) で落ちる。D は (1)(2)(4) を満たすが、代替先が別リージョンとはいえ Bedrock を呼び出す経路であり、Bedrock に依存しない回答経路が残らないため (3) で落ちる。

A：正解。4要件に次のように対応する。(1) 意味に基づく振り分け: Bedrock 上の小型モデルが質問の意味を分類し、Choice ステートはその分類結果の値で各ルールを真偽評価して遷移先を決める。Choice ステート自体は渡された値に従って遷移するだけなので、振り分けの一貫性は分類段階の設計に左右される。問題文の前提では、分類用の小型モデルは質問の意味に応じて事前に定めた固定ラベル(「定型」「専門」)のいずれかだけを返し、意味が同じ質問には言い回しによらず同じラベルが返る。そのため、Choice ステートがそのラベルの値を判定すれば、言い回しが変わっても同じ先へ振り分けられる。どのルールにも一致しない分類結果が返った場合の遷移先は Default で指定できる。(2) 同期応答: Express ワークフローを同期実行するため、利用者は同じ呼び出しで回答本文を受け取れる。(3) 耐障害性: 分類と回答生成の両方の Bedrock 呼び出しを AWS SDK の指数バックオフで再試行し、それでも失敗した場合は Bedrock を呼び出さない EC2 上のモデルへ遷移する。分類段階で失敗しても振り分け前に処理が止まらず代替経路で回答できるため、利用者にエラーを返さない。(4) 追跡: X-Ray により API Gateway から基盤モデルの呼び出しまでをサービス境界をまたいで追跡できる。

B：不正解。同期実行、再試行後の Bedrock を呼ばない代替経路への遷移、X-Ray による追跡は要件に合い、分類で Bedrock を呼ばないため分類段階の障害も起きない。しかし StringMatches は、質問文の文字列が「*」を含むパターンに一致するかを判定する文字列比較であり、判定するのは文字の並びである。同じ意味の質問でも、言い回しが変わって登録済みのパターンに一致しなければ別の先に振り分けられるため、質問の意味に基づき言い回しが変わっても同じ先へ振り分けるという要件を満たさない。

C：不正解。意味に基づく分類、再試行、Bedrock を呼ばない代替経路への遷移、X-Ray による追跡は要件に合う。しかし問題文の前提では、結果を同じ呼び出しで受け取れるのは Express ワークフローを同期実行した場合であり、Standard ワークフローを開始した場合の応答は実行 ARN だけである。利用者は最初のリクエストでは回答本文を受け取れず、実行 ARN を使って別の呼び出しで結果を取りに行く必要がある。つまり回答本文が届くのは最初のリクエストとは別の呼び出しになり、1回のリクエストに対し同じ接続で回答本文を同期的に受け取るという要件を満たさない。

D：不正解。意味に基づく分類、同期実行、再試行、X-Ray による追跡は要件に合う。しかし再試行で回答できない場合の代替先は、リージョンが異なっても Amazon Bedrock を呼び出す経路である。問題文は代替経路を Amazon Bedrock を一切呼び出さない経路と定めているため、この要件を満たさない。代替先が別リージョンのモデルであっても Bedrock の API を呼ぶ点は変わらず、Bedrock 側のスロットリングや障害が原因の失敗に対して Bedrock に依存しない回答経路が残らない。そのため、Bedrock が原因の失敗を代替経路で切り分けて回答を続けることができない。EC2 上の自己ホスト型モデルであれば、Bedrock の状態に左右されずに回答できる。

学習のポイント：Choice ステートは渡された値や文字列をルールで判定するだけなので、意味に基づく振り分けにはモデルによる分類結果を値として渡す必要がある。そのうえで、同期応答には Express の同期実行を使い、代替経路は Bedrock を一切呼ばない EC2 上のモデルにすることを組み合わせる。

公式ドキュメント

• state-choice.html

正解はBです。登録失敗の原因は、knn_vector フィールドの次元数 768 と登録するベクトルの次元数 1,024 の不一致です。既存インデックスのフィールドは次元数を変更できないため、次元数を 1,024 に設定した新しいインデックスを作成し、Titan Text Embeddings V2 の埋め込みを登録すれば次元数が一致します。Aは、16,000 は設定できる次元数の最大値にすぎず、フィールドを 16,000 次元にしても登録するベクトルの 1,024 次元とは一致しないため誤りです。Cは、距離指標が類似度の計算方法を決める設定で次元数とは別の項目であり、変更しても既存フィールドの次元数 768 は変わらないため誤りです。Dは、検索方式が類似ベクトルの探し方を決める設定で次元数とは別の項目であり、変更しても既存フィールドの次元数 768 は変わらないため誤りです。

A：16,000 は knn_vector に設定できる次元数の最大値です。大きな値にしておけば次元数 1,024 のベクトルも収まると考えがちですが、最大値は設定できる値の範囲を示すだけで、それ以下の任意の次元数のベクトルを受け付けるという意味ではありません。登録失敗の原因はフィールドの次元数とベクトルの次元数の不一致であり、フィールドを 16,000 次元にしても、登録するベクトルは 1,024 次元のままなので不一致は残り、登録は失敗します。

B：knn_vector は次元数を設定できるフィールドで、登録するベクトルと同じ次元数にする必要があります。既存インデックスのフィールドは作成後に次元数を変更できないという条件のため、次元数 768 のフィールドは使い続けられません。Titan Text Embeddings V2 の出力次元数 1,024 に合わせた新しいインデックスを作成して埋め込みを登録すれば、次元数が一致します。開発環境の 768 次元のベクトルは別モデルの埋め込みで、モデルが違えばベクトルの意味も揃わないため、このインデックスには移さず Titan の埋め込みを登録します。

C：距離指標(Euclidean distance、cosine similarity、dot product など)は、ベクトル同士の類似度をどう計算するかを決める設定で、次元数とは別の設定項目です。登録失敗の原因はフィールドの次元数 768 と登録するベクトルの次元数 1,024 の不一致であり、距離指標を変えてもフィールドの次元数は 768 のままです。そのため登録し直しても失敗し続けます。

D：検索方式(k-NN、HNSW などを使う近似 k-NN)は、類似ベクトルをどのように探すかを決める設定で、次元数とは別の設定項目です。登録失敗の原因はフィールドの次元数 768 と登録するベクトルの次元数 1,024 の不一致であり、検索方式を変えてもフィールドの次元数は 768 のままです。そのため次元数の不一致は解消されず、登録し直しても失敗します。

学習のポイント：登録失敗の原因は knn_vector フィールドとベクトルの次元数の不一致であり、次元数を変更できない既存インデックスではなく、モデルの出力次元数に合わせた新しいインデックスを用意する点が鍵です。

公式ドキュメント

• vector-search.html
• model-card-amazon-titan-text-embeddings-v2.html

正解は B である。埋め込みを knn_vector に格納して次元数を埋め込みモデルの出力に合わせて設定し、HNSW などのアルゴリズムを用いる近似 k-NN で上位 k 件を取得すれば、意味検索の要件と遅延の要件を両立しやすい。A は格納方法は適切だが、問題文の検証結果(約300万チャンクで全件との距離計算の検索処理が95パーセンタイル約6秒)が2秒を超えており、上位の完全な再現が要件にない本件ではこの遅延を許容する理由がないため不正解である。C は語句の一致で上位を決めるキーワード一致の検索で、言い換えの質問では該当箇所が上位に挙がりにくく、文字列として保存した埋め込みは knn_vector による標準的なベクトル検索の対象にならないため不正解である。D は質問文を言い換えても検索がキーワード一致のままで、生成済みの埋め込みによるベクトル比較を行わず、検索前の基盤モデル呼び出しによる待ち時間も増えるため不正解である。

A：不正解。knn_vector への格納と次元数の設定は意味検索の要件に合う。しかし検索方式が遅延要件を満たさない。問題文の検証では、クエリごとに全チャンクとの距離を計算する方式の検索処理は95パーセンタイルで約6秒であり、2秒を超えている。問題文は上位の完全な再現を要件にしていないため、この遅延を許容してまで全件との距離計算を選ぶ理由は本件の条件にない。大規模データ向けに HNSW などのアルゴリズムで検索を速くする近似 k-NN を選ぶのが適切である。

B：正解。knn_vector は密ベクトルを格納するフィールド型で、次元数を最大16,000まで設定できるため、埋め込みモデルの出力に合わせて設定できる。ベクトル同士の類似度で検索するので、キーワードが一致しない言い換えの質問でも意味の近い箇所を取得できる。近似 k-NN は HNSW などのアルゴリズムで大規模データの検索を速くする方式であり、全件の距離計算で約6秒かかった検索を2秒以内に近づける課題に合う。問題文は上位の完全な再現を要件にしていないため、近似方式を選ぶ妨げにならない。

C：不正解。この検索は質問の語句とテキストの語句の一致で上位を決めるキーワード一致の検索である。言い換えの質問は語彙が一致しにくく、該当箇所が上位に挙がりにくいため、キーワードが一致しなくても意味の近い箇所を取得するという要件を満たしにくい。意味の近い内容を探すには、キーワード一致ではなくベクトル同士を比較するベクトル検索が必要である。また、埋め込みを文字列として保存した場合、knn_vector による標準的なベクトル検索の対象にはならない。

D：不正解。質問文を言い換えて増やしても、検索自体は語句の一致で上位を決めるキーワード一致のままである。言い換えた語句がチャンク本文の語句と一致しなければ該当箇所は上位に挙がりにくく、意味の近い箇所を取得する要件を安定して満たせない。この構成は Amazon Bedrock で生成済みの埋め込みを検索に使わず、ベクトルによる意味の比較を行わない。さらに、検索の前に基盤モデルで質問文を言い換える処理が加わり、その分の待ち時間も増える。

学習のポイント：意味検索の要件には埋め込みを knn_vector に格納するベクトル検索を使い、全件との距離計算が遅延要件を超えて上位の完全な再現が不要な場合は、HNSW などで大規模データの検索を速くする近似 k-NN を選ぶ。

公式ドキュメント

• vector-search.html

本問は、ターン(ご用件を尋ねるターン・回答ターン)とチャネル(チャット・音声)の組み合わせごとに、messages の必須要件、基盤モデルの呼び出し回数、ボタンの上限を同時に追い、すべてを満たす設計を絞り込む必要がある。具体的には、(a) ElicitIntent では messages を省略できないこと、(b) 回答ターンの1回という呼び出し制約の下で読み方の指定をどこで加えるか、(c) 1カード最大3件という上限の下で ElicitIntent のターンに4件のボタンをどう並べるか、という独立した3つの判断を、選択肢ごとに照合して誤答を除く。A は、音声の回答ターンで回答文の生成と読み方の指定の付加に基盤モデルを2回呼んでおり、1ターン1回までという条件に反するため誤り。B は、音声チャネルの ElicitIntent で messages を省略している。messages を省略するとボット作成時の定義メッセージが使われるという動作は messages フィールド全般の説明であるが、ElicitIntent では少なくとも1件の messages が必要であるため、既定メッセージへの切り替えは使えず誤り。C は、カードのボタンを3件に収めているが、4件目をボタンではない subtitle に書いており、ElicitIntent のターンで4件すべてをボタンで提示する要件を満たさないため誤り。D は、両チャネルの ElicitIntent に固定文を PlainText で入れ、音声の回答は1回の呼び出しで得た回答文に Lambda 関数が読み方の指定を加えて SSML で返し、チャットは ElicitIntent の messages に2件ずつの2つのカードを入れるため、すべての条件を満たし正しい。E は、音声の ElicitIntent に SSML の固定文を使い、チャットは ElicitIntent の messages に3件と1件の2つのカードを入れており、各カードのボタンが1カード最大3件以内で、各条件を満たすため正しい。D と E は音声の固定文の contentType とカードへのボタンの配分が異なるが、いずれも問題文で許容されている範囲であり、どちらも要件を満たす。以上から、正解は D と E である。

A：ElicitIntent でチャネルごとに固定文を messages に入れる点と、チャットのボタンを2件ずつ2つのカードに分ける点は条件を満たす。しかし音声の回答ターンで、回答文の生成と読み方の指定の付加のために基盤モデルを2回呼んでいる。問題文では回答ターンの基盤モデル呼び出しを1ターンにつき1回までとしているため、この制約に反して誤りである。Lambda 関数は契約番号の部分を特定できるので、読み方の指定を Lambda 関数が加えれば2回目の呼び出しは不要になる。

B：音声の回答とチャットのボタンの設計は条件を満たす。messages を省略するとボット作成時に定義したメッセージが使われるという動作は、messages フィールド全般についての説明である。一方、ElicitIntent については messages に少なくとも1件のメッセージを含める必要があり、問題文でもこの前提を示している。そのため音声チャネルの ElicitIntent 応答で messages を省略する設計は、ボット作成時に音声向けの案内文が定義されていてもこの要件に反し、誤りである。基盤モデルを呼ばない目的は、Lambda 内の固定文を messages に入れることで達成できる。

C：ElicitIntent と音声の回答の設計は条件を満たし、カードのボタンを3件に収めている点も上限に沿っている。しかし subtitle はボタンを選ぶよう利用者に促す文言を入れる項目であり、ボタンではない。4件目の選択肢を subtitle に書くと、その選択肢はボタンとして提示されないため、ElicitIntent のターンで4件すべてをボタンで提示するという要件 (3) を満たせず誤りである。

D：ElicitIntent では messages に少なくとも1件が必要であり、固定文を PlainText の content に入れれば必須要件を満たし、基盤モデルも呼ばずに済む。音声の固定文は PlainText と SSML のどちらでもよいと問題文で示されているため、PlainText で問題ない。音声の回答は、SSML が音声応答をカスタマイズする記述を含められる contentType であることを利用し、1回の呼び出しで得た回答文の契約番号部分に Lambda 関数が読み方の指定を加えるため、呼び出し回数の制約も守れる。messages は Lex V2 が顧客に返すメッセージのリストなので、ElicitIntent の応答の messages に ImageResponseCard のメッセージを2つ並べて入れる設計が取れ、各カードの buttons は問題文のとおり1カード最大3件までなので、2件ずつ2つのカードに分ければ ElicitIntent のターンで4件すべてをボタンで提示できる。3点と呼び出し回数の制約をすべて満たすため正しい。

E：ElicitIntent では、チャネルごとに PlainText または SSML の固定文を messages の content に入れており、少なくとも1件という必須要件を満たし、基盤モデルも呼ばない。SSML は content に文言を入れる contentType の1つであり、音声の固定文は PlainText と SSML のどちらでもよいと問題文で示されているため、SSML で返して問題ない。音声の回答は D と同じく1回の呼び出しで得た回答文に Lambda 関数が読み方の指定を加えて SSML で返す。チャットは、messages がメッセージのリストであることを利用して、同じ ElicitIntent の messages に3件と1件の2つのカードを入れ、各カードの buttons を1カード最大3件の上限以内に収めている。カードへの配分は問わないと問題文で示されているため、ElicitIntent のターンで4件すべてをボタンで提示できる。すべての条件を満たすため正しい。

学習のポイント：ElicitIntent の応答では messages に少なくとも1件が必要であり、ボット作成時の定義メッセージに任せて省略する設計は取れないこと、読み方の指定は Lambda 関数が生成済みの回答文に加えれば呼び出しは1回で済むこと、4件のボタンは ElicitIntent の messages に複数のカードを入れて1カード最大3件に収め、subtitle はボタンの代わりにならないこと、の3点をターンとチャネルごとに同時に確認することが鍵となる。

公式ドキュメント

• lambda-response-format.html