AWS MLA サンプル問題

正解：C

A　scikit-learnコンテナは単一インスタンス上のpandas処理を想定しており、数TBの分散結合には向かない。PySparkスクリプトもそのままでは動かない

B　分散処理自体は可能だが、クラスターを保持し続けるため前処理を行わない時間も課金される。完了後にリソースを残さない要件に合わない

C（正解）　正解。マネージドなSparkクラスタがジョブ単位で起動し、既存のPySparkスクリプトをそのまま実行できる。完了時にクラスタは自動終了する

D　Lambdaは実行時間15分・メモリ上限の制約があり、シャッフルを伴う結合処理には不向き。数TB規模の集計を担わせる設計ではない

正解：A

A（正解）　正解。ノーコードで欠損値・外れ値・特徴量重要度・ターゲットリークの警告までを含む診断レポートを自動生成し、探索の初動を短縮できる

B　同等の統計は得られるが、スクリプトの実装と実行環境の管理が必要になる。コーディングを最小限にしたいという要件に反する

C　Model Monitorは本番エンドポイントの推論データを既存ベースラインと比較する機能。学習前のデータセット探索を目的とした機能ではない

D　プロファイル統計は取得できるが、ターゲットリークの警告のようなML固有の診断は提供しない。Studio内で完結する探索にもならない

正解：D

A　Athenaはインタラクティブ分析向けでクエリ実行に秒単位かかる。数ミリ秒の推論経路に組み込むレイテンシ要件を満たせない

B架空　そのような名前のサービスはAWSに存在しない。低レイテンシの特徴量取得を担うのはSageMaker Feature Storeのオンラインストア

C　実現は可能だが、特徴量グループの定義・時点指定の取得・履歴の自動蓄積を自前で作り込む必要があり運用負荷が高い

D（正解）　正解。オンラインストアが低レイテンシ取得を、オフラインストアがS3上の履歴を提供し、単一の特徴量定義で学習と推論の整合を保てる

正解：B

A　レイテンシには効くが、特徴量の計算ロジックが二重に実装されている状況は変わらない。精度低下の原因に対処していない

B（正解）　正解。学習時と推論時で特徴量の定義がずれるtraining-serving skewが原因であり、単一の計算ロジックを共有することが根本対策になる

C　データ量は本質ではない。入力特徴量の計算方法そのものが学習時と推論時で異なるため、再学習しても同じずれが残る

D　劣化の検知は早くなるが検知は対症療法にとどまる。特徴量計算の二重実装というずれの原因そのものは取り除けない

正解：A

A（正解）　正解。値を埋めて行数を保ちつつ、欠損が発生したという事実そのものが持つ情報をフラグ列としてモデルに伝えられる

B　15%の行を失いデータ量が大きく減るうえ、欠損の発生自体が持つ予兆情報も同時に捨ててしまう

C　0はセンサー値として有効な値になり得るため、欠損と実測値を区別できなくなる。分布も不自然に歪む

D　故障予兆と相関する可能性がある特徴量を丸ごと失う。欠損率15%は列削除を正当化する水準でもない

正解：C

A　正当な取引を捨てると大口需要をまったく予測できなくなる。誤入力ではないデータを機械的に除去するのは不適切

B　実測値を平均で潰すと情報が失われ、目的変数との関係も壊れる。外れ値対応として妥当な手法ではない

C（正解）　正解。極端な値の影響を抑えつつ情報を保持でき、大口発注という発生要因をモデルが区別できるようになる

D　標準化はスケールを揃えるだけで分布の形は変えない。外れ値は標準化した後も外れ値のまま残る

正解：B

A　ラベルエンコーディング後の標準化は木ベースモデルでは無意味で、IDの数値順に意味があるかのような誤った順序も持ち込む

B（正解）　正解。カテゴリごとの目的変数の統計量に置き換えることで次元を1列に抑えられる。分割前の統計量利用によるリークには注意が必要

C　次元は減るが、販売店ごとの傾向という予測に有用な情報を完全に失う。まず次元を圧縮する手段を検討すべき

D　5万列を一度生成する必要がありメモリ不足は解決しない。疎な二値行列に対するPCAは解釈性も失われる

正解：D

A　誤りではないがXGBoostには不要な処理を課しており、工数を最小化したい要件には合わない。分割点の探索はスケールに依存しない

B　ロジスティック回帰は勾配降下法で最適化するため、桁の大きく異なる特徴量が混在すると収束が悪化する

C　正規化自体は有効だが木ベースモデルには効果がなく、二重に前処理を維持する手間だけが残る

D（正解）　正解。勾配ベースの線形モデルはスケールの影響を強く受けるが、木ベースモデルは特徴量の単調変換に不変でスケーリングを必要としない

正解：C

A　スケールが変わるだけで線形モデルが表現できる関係は直線のまま。U字型の非線形性は捉えられない

B　対数変換は右に裾の長い分布を圧縮する手法。単調変換なのでU字型の関係を線形モデルで表現できるようにはならない

C（正解）　正解。区間ごとに独立した係数を持たせることで、線形モデルのままU字型の非線形な関係を表現できる

D　予測に有効な変数を捨てる対処であり、非線形性をどう扱うかという本来の課題を回避しているだけ

正解：A

A（正解）　正解。データ量に余裕があるため多数派を間引いても学習に十分なサンプルが残り、学習時間の短縮という副次的な利点も得られる

B　正解率は不均衡データでは多数派に引きずられて実態を反映しない。指標としきい値の見直しなしに改善は測れない

C　単純複製は同一サンプルの重複により過学習を招きやすい。合成サンプル生成やクラス重みのほうが安全

D　次元削減はクラス比率の偏りに何の影響も与えない。不均衡そのものへの対処になっていない

正解：C

A　不均衡の程度を数値で把握できるだけで、偽陰性を減らす学習側の対処にはならない。計測は原因の把握にとどまる

B　データ量が限られている状況で多数派を削ると学習に使える情報が減る。レコードを削減できないという制約にも反する

C（正解）　正解。学習時の損失で少数派を重視しつつ、見逃しの少なさを直接測る再現率で評価することで偽陰性のコストに整合する

D　適合率重視としきい値の引き上げは偽陽性を減らす方向に働き、最も避けたい見逃しをかえって増やす

正解：B

A　語彙を独立した次元として扱うため、表記の異なる同義語はまったく別の特徴量になる。意味の近さを表現できない

B（正解）　正解。意味的に近い語が近いベクトルに写像されるため、表記が異なる同義語を同一視した分類が可能になる

C　文書中の希少語を強調する統計的な重み付けにすぎず、語同士の意味的な関係は依然として捉えられない

D　本文の長さの情報しか持たず、どの語が使われたかという分類に最も重要な情報を落としている

正解：A・C

A（正解）　正解。Glueが処理済みオブジェクトの状態を保持するため、実行のたびに前回以降に追加された分だけが対象になる。ジョブのコードを書き換えずに再処理を避けられる

B　カタログ上のスキーマやパーティションが最新化されるだけで、ジョブが読み込む範囲は変わらない。列構成の変化への備えにはなるが再処理はなくならない

C（正解）　正解。日付でパーティション分割されていれば読み込み対象を当日のプレフィックスに限定でき、スキャンするデータ量そのものを削減できる

D　読み込むデータ量は変わらないため、単位時間あたりの並列度が上がるだけで処理量に応じた費用は減らない。データの蓄積が続けば同じ問題が再発する

E　読み込みと変換の負荷はまったく減らず、実行時間と費用の問題はそのまま残る。重複の排除は出力の正しさに関する話であって、再処理の回避策ではない

正解：A・C

A（正解）　正解。過去の実績値を明示的に列として与えることで、直近の水準と前年同時期の季節性を木モデルが利用できるようになる。推論時点ですでに確定している値なのでリークにもならない

B　予測しようとしている値そのものであり、典型的なターゲットリーク。検証スコアは跳ね上がるが推論時には存在しない情報なので本番では使えない

C（正解）　正解。水準の変化と変動の大きさを要約した特徴量で、木モデルが単独では表現しにくいトレンドとばらつきを補える。集計対象を過去の確定値に限れば安全に使える

D　データの並び順に依存する人工的な値で、需要とは因果関係がない。並び順が偶然ターゲットと相関していた場合はむしろ誤った関係を学習させてしまう

E　予測実行時点ではまだ確定していない未来の値であり、学習時にしか手に入らない。本番のバッチ推論で値を埋められず、埋めれば学習時と分布が食い違う

正解：A

A（正解）　正解。勾配ブースティング木は数値とカテゴリが混在する表形式データの分類で高い精度が出やすく、学習も高速。表形式の教師あり分類における第一候補

B　K-Meansはラベルを使わない教師なしクラスタリングで、既に手元にある解約ラベルを学習に活かせない。クラスタが解約有無と一致する保証もない

C　RCFはラベルなしで希少な外れ値を検出する用途。解約顧客は外れ値ではなく、ラベル付きデータがある以上は教師あり学習を選ぶべき

D　Seq2Seqは翻訳や要約など可変長の系列を別の系列へ変換する用途。表形式の二値分類に用いるのは過剰かつ学習コストも高い

正解：B

A　線形モデルは季節性や系列間の共通パターンを自動では捉えられず、ラグ特徴量を人手で大量に設計する必要がある

B（正解）　正解。多数の関連時系列をまとめて1つのモデルで学習する設計で、系列が短くても他の系列から学んだ共通パターンを活用できる

C　150万個のモデルを学習・運用することになり現実的でない。系列間で情報を共有できず短い系列の精度も上がらない

D　RCFは時系列中の異常点にスコアを付けるアルゴリズムで、将来の値そのものを予測する機能を持たない

正解：C

A　教師あり学習には異常ラベルが必要だが手元に存在しない。仮に作っても未知の種類の異常には反応できない

B　IP InsightsはIPアドレスとユーザーIDなどエンティティのペアの異常さを学習する専用アルゴリズムで、数値メトリクスの時系列には適用できない

C（正解）　正解。ラベル不要の教師なし異常検知アルゴリズムで、逐次到着するデータ点に異常スコアを付ける用途に設計されている

D　クラスタ数を事前に決める必要があり、ストリーミングデータへの逐次的なスコア付けには向かない。判定基準の維持も煩雑

正解：D

A　Object2Vecはオブジェクトのペア関係を埋め込む汎用アルゴリズムで、テキスト分類に特化した最適化はなく学習コストが高くなる

B　LDAは教師なしのトピック抽出で、既存のカテゴリ体系と一致する保証がない。用意済みのラベルをまったく活かせない

C　Seq2Seqは系列変換用で学習コストが大きく、固定数のクラスへ振り分ける多クラス分類に用いるのは非効率

D（正解）　正解。fastText互換の高速なテキスト分類・単語埋め込みアルゴリズムで、CPUインスタンスでも大規模コーパスを短時間で学習できる

正解：A

A（正解）　正解。各画素にクラスラベルを割り当てるアルゴリズムで、領域の形状や面積を算出したいという要件に唯一適合する

B　画像単位のラベルしか得られず、傷がどこにどれだけ広がっているかは分からない。面積算出の要件を満たさない

C　矩形の位置と大きさは得られるが、矩形内には傷でない領域も含まれるため面積を正確に算出できない

D　照明むらや製品自体の模様も暗く写るため誤検出が多い。何を傷とみなすかを学習していないので精度が安定しない

正解：D

A　極端に疎な高次元ベクトルでは距離が意味を持ちにくく、数千万ユーザー規模の近傍探索は計算量の面でも厳しい

B　決定木はワンホット展開された非常に疎な高次元特徴量の相互作用を捉えるのが苦手で、分割の学習が困難になる

C　PCAは次元削減しか行わず、推薦に必要な特徴量ペアの相互作用は学習しない。二段構えになり運用も複雑

D（正解）　正解。高次元かつ疎なデータで特徴量ペアの相互作用を低次元表現として効率的に学習する設計で、推薦やクリック予測の定番

正解：B

A　研究で用いる独自アルゴリズムを捨てることになり目的を満たさない。依存関係をどう解決するかという問いへの答えにもなっていない

B（正解）　正解。OSレベルの依存まで自由に制御できるのはBYOCのみ。学習ジョブ用のインターフェースを満たせばSageMakerがそのまま実行できる

C　スクリプトモードで追加できるのは主にPythonパッケージ。OSのシステムパッケージや特定バージョンの共有ライブラリは導入できない

D　ライフサイクル設定が影響するのはノートブック環境だけで、学習ジョブが動く別のコンテナには一切反映されない

正解：C

A　小規模な自社データのみでは要約に必要な言語能力を獲得できない。事前学習済みモデルという既存資産を捨てている

B　Comprehendのカスタム分類は文書をあらかじめ定めたカテゴリへ割り当てる機能で、要約文を生成することはできない

C（正解）　正解。事前学習済みモデルとサンプルノートブックをカタログから数クリックで展開でき、そのままファインチューニングまで実行できる

D　事前学習のやり直しは時間も費用も桁違いに大きく、数週間で提供するという制約とまったく合わない

正解：A

A（正解）　正解。エンティティ識別子とIPアドレスの組み合わせをラベルなしで学習し、過去の傾向から見て起こりにくいペアに高い異常スコアを付ける専用アルゴリズム

B　疎な特徴量の相互作用から目的変数を予測する教師あり学習であり、学習には正解ラベルが必要になる。組み合わせの異常さそのものを出力する仕組みではない

C　数値の時系列から外れ値を検出する用途で、どのユーザーがどのIPから接続したかという組み合わせの妥当性は評価できない

D　教師あり学習には不正ラベルが必要だが、履歴にラベルが付いていないためそのままでは学習できない

正解：D

A　改訂のたびに再学習が必要で運用要件に真っ向から反する。ファインチューニングは知識の鮮度を保つ手段には向かない

B　ファインチューニングよりさらに大掛かりで費用も時間もかかる。頻繁に更新される事実情報の反映手段としては不適切

C　プロンプトの工夫だけではモデルが知らない社内規程の中身を答えられない。回答の根拠となる出典も提示できない

D（正解）　正解。ドキュメントを索引付けし質問時に関連箇所を取得してモデルへ渡す構成なら、規程の改訂は索引の更新だけで反映できる

正解：B

A　データ並列は各GPUがモデル全体の複製を保持する方式のため、モデルがGPUメモリに収まらないという問題は解消しない

B（正解）　正解。モデルの層やテンソルを複数GPUに分割して配置する方式で、単一GPUのメモリに収まらないモデルの学習を可能にする

C　インスタンスを増やしても1GPUに載せる必要のあるモデルサイズは変わらないため、同じメモリ不足が再発する

D　Pipeモードが軽減するのはデータのダウンロードとディスク使用量であって、モデルの重みが占めるGPUメモリではない

正解：C

A　画像分類の学習は行列演算が支配的でGPUの並列性能が効く。CPUに移すと学習時間はかえって大幅に延びる

B　ステップ数が激増して総学習時間はむしろ延びる。GPUの並列演算能力も活かせなくなる

C（正解）　正解。モデルが1GPUに収まりデータが大きい場合はデータ並列が適切。インスタンス数とGPU数を増やしてミニバッチを分担処理する

D　スポットは費用を下げる仕組みで学習時間の短縮にはならない。中断が起きればむしろ完了までの時間は延びる

正解：A

A（正解）　正解。チェックポイントにより中断後も途中から再開でき、最大待機時間の指定でスポット待ちを含む上限時間を制御できる

B　インスタンスを増やしても中断は起こり、チェックポイントがなければやはりやり直しになる。費用も無駄に増える

C　最大実行時間は実行中の上限にすぎず、スポット容量の待ち時間の制御にも中断からの再開にもならない

D　ウォームプールは連続するジョブの起動時間を短縮する機能で、スポット中断からの再開を保証するものではない

正解：B

A　バッチ変換は事前計算した結果しか返せず、表示時のリクエスト内容に応じた推論ができない。5分の遅延も要件に合わない

B（正解）　正解。常時起動のインスタンスがHTTPS経由でミリ秒単位の応答を返す方式で、常時トラフィックかつ低レイテンシという要件に最も合致する

C　非同期推論はキューイングを挟むため応答が即時にならず、大きなペイロードや長時間処理が本来の用途。100ミリ秒のSLAは満たせない

D　間欠的なトラフィック向けの方式で、コールドスタート時に数秒の遅延が生じうる。常時高トラフィックではコスト面の優位性もない

正解：C

A　最小1インスタンスが常時起動するため、呼び出しがない日も課金が続く。待機中の課金を避けたいという要件に反する

B　Batchはバッチ計算ジョブ向けのサービスで、同期的なAPI応答を返す用途ではない。ジョブ起動のオーバーヘッドも大きい

C（正解）　正解。リクエストがない間はインスタンスが起動せず課金もされない。間欠的なトラフィックでコールドスタートを許容できる場合に最適

D　待機課金は避けられるが、応答はS3出力と通知経由になる。分類結果を同期的に受け取る通常のAPI呼び出しには適さない

正解：A

A（正解）　正解。サーバーレス推論はGPU非対応でペイロード4MB・タイムアウト60秒の上限がある。非同期推論なら最大1GBのペイロードと最大60分の処理に対応する

B　メモリ拡張とProvisioned Concurrencyはコールドスタート対策であり、GPU非対応・ペイロード4MB・タイムアウト60秒の制約は変わらない

C　ペイロード制約は回避できるが、サーバーレス推論にGPUは割り当てられず、平均90秒の処理は60秒のタイムアウトを超える

D　実装が複雑になるうえ、サーバーレス推論の実行がCPUに限られる点は分割しても解消しない。タイムアウト制約も残る

正解：D

A　リアルタイム推論はペイロード6MB・タイムアウト60秒が上限で延長もできない。800MBの入力や30分の処理には対応できない

B　サーバーレス推論はペイロード4MB・タイムアウト60秒の制約があり、メモリを増やしても解消しない。GPUも利用できない

C　Lambdaは最大15分の実行時間とペイロード上限があり、30分かかる推論には不足する。大容量モデルのロードにも向かない

D（正解）　正解。最大1GBのペイロードと最大60分の処理時間に対応し、リクエストをキューイングして完了時にAmazon SNSで通知できる

正解：B

A　最小1インスタンスが残るため課金はゼロにならない。非同期推論が0台までスケールインできる特性を活かせていない

B（正解）　正解。非同期推論はキューの滞留量を指標にゼロまで縮退でき、リクエスト到着でキューが伸びると自動的にインスタンスが起動する

C　非同期推論は内部で既にキューイングを行っており、外部SQSを足しても待機中のインスタンス課金はなくならない

D　課金は止まるが作成に数分かかり運用も複雑になる。リクエスト到着時に自動で処理を再開するという要件を満たさない

正解：A

A（正解）　正解。エンドポイントを常時保持せずジョブ実行中だけ課金され、S3の入力を分散処理して結果をS3へ出力する。定期一括推論に最適

B　1,200万回のAPI呼び出しは処理時間もコストも膨大で、エンドポイントは残り6日間も課金され続ける

C　サーバーレス推論は同時実行数に上限があり、1,200万件の一括処理には向かない。1件ずつのHTTP呼び出しも非効率

D　非同期推論は大きなペイロードの個別リクエスト向けで、エンドポイントの維持も必要。定期一括処理ならバッチ変換が安い

正解：D

A　800台分のインスタンスが常時課金され、ほとんど呼ばれないモデルにも料金が発生する。コスト面で最も不利

B　テナント固有の予測精度が失われるうえ、テナント追加のたびに全体を再学習する必要があり運用が破綻する

C　マルチコンテナエンドポイントは異なるフレームワークのコンテナを最大15個まで配置する仕組みで、800個は収容できない

D（正解）　正解。同一フレームワークの多数モデルを1エンドポイントで共有し、呼び出し時にS3からオンデマンドでロードする。稀に呼ばれるモデルは初回のロード遅延が生じる

正解：C

A　マルチモデルエンドポイントは単一のフレームワークのコンテナを共有する仕組みで、TensorFlowとPyTorchの混在には対応できない

B　推論パイプラインはコンテナを直列実行して出力を次へ渡す構成。どちらか一方を選んで呼び出す用途には使えない

C（正解）　正解。異なるフレームワークのコンテナを同一エンドポイントに配置でき、直接呼び出しモードでコンテナ名を指定して個別に実行できる

D　インスタンスが2セット必要でコストが倍になる。SageMakerエンドポイントはALBのターゲットにも指定できない

正解：B

A　ネットワーク往復が2回に増えてレイテンシが悪化し、インスタンスも2セット必要。呼び出し順序の管理もアプリ側の責務になる

B（正解）　正解。1つのエンドポイント内でコンテナが直列実行され、前処理の出力がそのままモデルへ渡る。学習時と同じ前処理コードを再利用できる

C　前処理ロジックが学習パイプラインとは別のコードベースに分かれ、学習と推論の乖離という懸念がそのまま残る

D　直接呼び出しモードは個別のコンテナを独立して呼ぶ仕組みで、前処理の出力をモデルへ引き渡す直列実行にはならない

正解：A

A（正解）　正解。SageMakerVariantInvocationsPerInstanceを目標値に保つよう自動でスケールアウト・インし、突発的な負荷増にも追随できる

B　平常時に過剰な容量を抱えてコストが跳ね上がる。さらに想定を超える負荷には依然として対応できない

C　スケジュールスケーリングは負荷の時刻が読める場合に有効だが、キャンペーンによる突発的な急増には追随できない

D　Lambdaは大きなMLモデルのロードやGPU実行に向かず推論基盤の作り直しになる。エンドポイントの設定で解決できる問題

正解：D

A架空　そのような名前のサービスはAWSに存在しない。時間帯に応じたインスタンス数の制御はApplication Auto Scalingのスケジュールスケーリングが担う

B　負荷への追随はできるが最小容量が1のため営業時間外もインスタンスが残り、課金が続いてしまう

C　コストは下がるが推論方式そのものの変更を伴い、ペイロード上限やコールドスタートの再評価が必要。まずスケジュール制御で足りる

D（正解）　正解。負荷の時刻パターンが既知の場合に有効で、営業時間外は容量を絞りつつ開始時刻には事前にスケールアウトできる

正解：B

A　入力特徴量の型・欠損率・統計分布がベースラインから外れたかを見る仕組み。属性グループ間で予測がどう偏っているかという公平性の観点は評価しない

B（正解）　正解。Clarifyと連携し、学習時に算出したバイアス指標をベースラインとして本番データでの予測の偏りの変化を定期評価する

C　精度やF1などの予測性能を正解ラベルと突き合わせて測るもの。全体の精度が保たれたままグループ間の偏りだけが広がる状況は捉えられない

D　勾配消失や過学習など学習中の内部状態を捉える機能。本番エンドポイントで稼働中のモデルに対する継続監視には利用できない

正解：D

A　監視ジョブは別途起動されるProcessingインスタンス上で実行されるため、エンドポイント側のインスタンスタイプは判定結果に影響しない

B　頻度は評価の粒度を決めるだけ。比較の基準が用意されていなければ、頻度をどう変えても違反判定そのものが行われない

C　説明可能性モニターは特徴量の寄与度変化を見る別種のモニターであり、データ品質監視が動作するための前提条件ではない

D（正解）　正解。Model Monitorは学習データから生成したstatisticsとconstraintsを基準に逸脱を判定する。ベースラインがなければ比較が成立しない

正解：A

A（正解）　正解。DataCaptureConfigは収集割合を指定できるため、全リクエストを保存せずに統計比較に足るサンプルだけをS3に残せる

B　同じ結果は得られるがコンテナの改修と再デプロイが必要になる。マネージド機能で済むところに保守対象を持ち込んでいる

C　ログ経由の収集ではModel Monitorが期待するキャプチャ形式にならず、そのままでは監視ジョブの入力として扱えない

D　監視データは残せるがリアルタイム推論という前提を捨てることになる。オンラインのレイテンシ要求を満たせない

正解：C

A　シャドウテストは新しいモデル候補をユーザー影響なく評価する仕組み。稼働中モデルの精度劣化を継続測定する機能ではない

B　Feature Storeは学習と推論の特徴量整合を保つためのもので、精度指標の計算に必要な正解ラベルを供給する仕組みではない

C（正解）　正解。モデル品質監視はキャプチャされた予測と、後から用意されるグラウンドトゥルースを推論IDで突き合わせて精度指標を算出する

D　学習前バイアス指標はデータセットの偏りを測るもの。モデルの予測がどれだけ当たっているかという性能評価には使えない

正解：B

A　正解ラベルが45日後にしか揃わない以上、実行頻度を上げても評価できるデータが存在せず、意味のある精度指標は出ない

B（正解）　正解。ラベル待ちの間は入力分布の変化を早期警報に使い、ラベルが揃った時点で遅延評価として実際の精度を確認する二段構えが現実的

C　監視を止めている間は入力側の異常も見逃す。ラベルに依存しない監視まで捨てるのは早期察知という要件に反する

D　正解ラベルがない状態では再学習そのものができない。劣化の検知ではなく無条件の更新であり、コストも運用負荷も過大

正解：D

A　入力分布が変わっていない以上データドリフトではない。前処理を直しても誤差が拡大している原因には届かない

B　ハードウェアの問題なら予測値の誤りではなくレイテンシやエラー率に現れる。数か月かけた緩やかな精度低下の説明にならない

C　過学習ならデプロイ直後から精度が低い。時間とともに悪化していくパターンは学習時の汎化性能の問題では説明できない

D（正解）　正解。入力分布が保たれたまま精度が落ちるのは、特徴量と目的変数の関係そのものが変化した状態。最新データでの再学習が必要

正解：C

A　検知の頻度が上がるだけで、違反を受けて再学習を起動する経路は生まれない。結局は人手での起動が残る

B　実現はできるがポーリング用の関数とスケジュール、条件判定コードを自前で保守することになり、イベント駆動に比べて工数が大きい

C（正解）　正解。違反件数はCloudWatchメトリクスとアラームに反映されるため、その状態変化をEventBridgeが受けてパイプライン実行を直接呼び出せる

D　レポートは違反の有無にかかわらず毎回出力されるため、正常時にも再学習が走ってしまう。条件付きの起動にならない

正解：A

A（正解）　正解。1日2000件はドリフト判定に足るサンプル量であり、日次実行なら監視用Processingインスタンスの起動回数を最小限に抑えられる

B　1時間あたり数百件では統計比較のサンプルが不足しやすく、24倍のジョブ起動コストに見合う検知精度が得られない

C　監視はProcessingジョブとして起動されるためリクエスト単位の実行は非現実的で、コストも運用負荷も極端に膨らむ

D　検知までに最大1か月かかり、気づいた時点で長期間にわたり劣化したデータで推論し続けている。検知要件を満たさない

正解：B

A　日次バッチでは即時の通知にならないうえ、クエリ基盤とレポート送信の仕組みを別途構築・保守する必要がある

B（正解）　正解。監視ジョブは違反件数などをCloudWatchメトリクスとして発行するため、しきい値アラームからSNS経由で即時に通知できる

C　違反判定は推論コンテナではなく監視ジョブ側で行われるため、エンドポイントのログには違反情報が出力されない

D　ConfigはAWSリソースの構成が準拠しているかを評価する仕組み。S3上のレポートの中身を解釈して通知する用途ではない

正解：C

A　モデルコンテナ内での処理時間はModelLatencyに現れる。横ばいである以上、推論そのものが遅くなったとは考えにくい

B　ドリフトは予測の当たり外れに影響するもので、レイテンシの内訳が変化する現象とは直接の関係がない

C（正解）　正解。OverheadLatencyはコンテナ外でSageMakerが要した時間を示すため、大きなペイロードの受け渡しなどリクエスト処理側の詰まりを疑う

D　インスタンスに余裕がある状態はレイテンシを悪化させない。症状の説明としてそもそも成立しない

正解：A

A（正解）　正解。推論コンテナの標準出力と標準エラーはエンドポイント用のロググループに集約され、スタックトレースを時刻とともに追える

B　リソース逼迫の有無は分かるが、どの例外がどのリクエストで発生したかというアプリケーションレベルの原因までは特定できない

C　入力分布のベースラインからの逸脱を報告するもので、コンテナ内で起きた実行時エラーの内容は含まれない

D　CloudTrailはAPI呼び出しの監査記録であり、データプレーンの推論内容やコンテナ内の例外までは記録しない

正解：D

A　集計値の傾向は掴めるが、個々のリクエストが各区間でどれだけ時間を使ったかという因果を辿ることはできない

B　エンドポイント単体のインスタンス型選定と性能測定が目的。API GatewayやLambdaを含む経路全体の内訳は測定できない

C　Debuggerのプロファイリングは学習ジョブを対象とする機能であり、本番の推論経路のトレースには利用できない

D（正解）　正解。分散トレーシングにより1リクエストが各コンポーネントで費やした時間をサービスマップ上で可視化し、ボトルネック区間を特定できる