MLSは「MLの試験」ではなく「意思決定の試験」？
ここまで一通り振り返ってきて、
改めて思うのはこれです。
MLSは
モデルを作れるかどうか
を測る試験ではありません。
「この状況で、何を選ばないか」
を含めて判断できるかどうか。
その精度を見られている試験です。
MLSの問題構造は、ほぼこの型
MLSの設問を分解すると、
だいたい次の順番でできています。
- 業務・要件の説明
- 制約条件（時間、コスト、データ量、運用）
- 選択肢に“全部それっぽい解”が並ぶ
ここでやってはいけないのが、
「一番高度そうな技術を選ぶ」こと。
正解はほぼ例外なく、
要件に対して“やり過ぎていない”選択肢
です。
よくある誤答パターン
自分が実際に引っかかったパターンをまとめます。
・EDA前なのにモデル改善策を選ぶ
・フルマネージドで足りるのにSageMakerを選ぶ
・One-Hotを反射で選ぶ
・ベイズ最適化を万能だと思い込む
・Comprehendで足りるのに独自モデルを作る
どれも
「技術的には間違っていない」
のが厄介な点です。
MLSは
正しいかどうか
ではなく
適切かどうか
を問われます。
MLSの軸は常にこの4つ
迷ったときに立ち戻る軸は、
だいたいこの4つでした。
・今はどの工程か（前処理 / 学習 / 推論 / 運用）
・リアルタイムか、バッチか
・自作すべきか、マネージドで足りるか
・精度を追う段階か、まず形にする段階か
この軸で読むと、
選択肢が一気に減ります。
MLSにおけるAWSサービスの位置づけ
MLSは
アルゴリズム試験というより
AWS MLサービス設計試験
に近いです。
・Data Wrangler → 前処理を早く、確実に
・Autopilot → 最短でベースライン
・Clarify → 公平性と説明責任
・Feature Store → 再現性と一貫性
・Comprehend → 作らない選択
「MLをやるためのML」ではなく、
「業務で回すためのML」
という視点が一貫しています。
ここまでやれば、MLSは十分
MLS対策として、
自分なりの着地点はここでした。
・数式は深追いしない
・アルゴリズムの中身より使いどころ
・AWSサービスは工程で整理
・引っかけは「過剰」を疑う
この試験は、
全部を極めようとすると
確実に疲れます。
理解の浅さで落とす試験ではなく、
判断のズレで落とす試験です。
MLSを終えて、次に進むために
MLSをやって良かった点は、
MLそのものよりも、
「MLをどう業務に組み込むか」
の視点が明確になったことでした。
この感覚は、
次に控えている
DOP（DevOps Engineer – Professional）
と非常に相性がいいと感じています。
MLを
どう作るか
ではなく
どう回すか
という思考への切り替え。
MLSは、その良い橋渡しでした。
一度、体系的にまとめられた教材で
全体を通し読みしてから試験に臨むと、
「点ではなく線」で理解できるはずです。
ここまでで MLS-C01 復習シリーズは完結 です。
次回からは DOP（DevOps Engineer – Professional） をやっていきます。
コメントを残す