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　標準化はスケールを揃えるだけで分布の形は変えない。外れ値は標準化した後も外れ値のまま残る

正解：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　事前学習のやり直しは時間も費用も桁違いに大きく、数週間で提供するという制約とまったく合わない

正解：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からオンデマンドでロードする。稀に呼ばれるモデルは初回のロード遅延が生じる

正解：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架空　そのような名前のサービスはAWSに存在しない。実際にドリフト検知を起点とした自動化を担うのは EventBridge と SageMaker Pipelines の組み合わせ

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

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

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