AWS AIサービスは「アルゴリズムを使わない判断」を問われる
MLSの後半になると、
急に「モデルを作らない選択肢」が増えます。
最初は違和感がありましたが、
これは完全に実務寄りの視点だと感じました。
「自分で学習させる必要、本当にある？」
これを冷静に判断できるかが問われています。
Amazon CloudSearchは“検索専用”
CloudSearchは
フルマネージドの検索サービスです。
ポイントはシンプルで、
これは機械学習サービスではあるけれど、
モデル設計や学習を考えるものではありません。
向いているケースは、
・全文検索
・フィルタリング
・ランキング
・検索のスケーラビリティ
ここで自分がやらかしたのは、
「テキスト処理＝Comprehend」
と短絡的に結びつけてしまったこと。
検索要件がメインなら、
CloudSearchを選ぶのが正解です。
Amazon Comprehendは“意味を理解する側”
Comprehendは
自然言語の意味解析に特化したサービス。
代表的な機能としては、
・感情分析
・エンティティ抽出
・キーフレーズ抽出
・言語検出
ここでMLS的に重要なのが、
APIの使い分けです。
DetectSentiment APIはリアルタイム向き
DetectSentimentは
単発リクエスト向けの同期API。
・即時レスポンスが必要
・小規模
・低レイテンシ
という条件がつくと、
ほぼこれ一択です。
試験では
「Webアプリから即時判定」
といった表現がヒントになります。
BatchDetectSentiment APIはまとめ処理用
BatchDetectSentimentは
最大25ドキュメントをまとめて処理します。
リアルタイム性よりも
効率重視。
ログ解析や
バッチ処理向きです。
ここで重要なのは、
リアルタイム用途には向かない
という点。
StartSentimentDetectionJob APIは大規模バッチ
StartSentimentDetectionJobは
非同期の大規模ジョブ用。
S3に置いた大量データを
まとめて処理する場合に使います。
ここでの判断軸は、
・データ量
・即時性の要否
「夜間バッチ」「履歴分析」
といったキーワードが出たら、
このAPIを疑います。
Comprehendを選ぶ理由は「作らない」こと
MLSで何度も感じたのは、
Comprehendは
「精度を追求するためのサービスではない」
という点。
・すぐ使える
・運用が楽
・学習不要
このメリットが
そのまま正解理由になります。
「独自モデルで精度を上げたい」
という文脈なら、
SageMaker側に話が移ります。
SageMaker Feature Storeは“再利用”のため
Feature Storeは
特徴量を保存・再利用するための仕組み。
自分が混乱したのは、
「データレイクとの違い」。
Feature Storeは
学習用・推論用で
同じ特徴量を使う
という点が最大の価値です。
再現性や一貫性が求められる
という条件がつくと、
これが選択肢に上がります。
QuickSightかSageMaker Studioか
Future Store化レポート作成の文脈で、
QuickSightとSageMaker Studioが並ぶ問題も出ます。
判断基準は明確で、
・ビジネス向け可視化 → QuickSight
・MLエンジニア向け分析 → SageMaker Studio
ここで「高度な可視化」と書いてあっても、
利用者が誰か
を見るのがコツです。
ここまでのまとめ
この回で一番大事なのは、
「モデルを作らない勇気」。
MLSは
アルゴリズム試験に見えて、
実は
AWSサービス選定試験
でもあります。
精度を追う前に、
・フルマネージドで足りないか
・運用コストはどうか
を考える。
これができると、
選択肢が一気に減ります。
詰まった時は、
サービス横断で整理された教材を
一度通して見ると、
知識が線でつながります。
次回はいよいよ
全体を横断した「試験視点の整理」と
引っかけポイント総まとめに入ります。
ここまで来れば、
MLSは暗記試験ではない、
という感覚がはっきりするはずです。
コメントを残す