タグ: ApacheBeam

  • 【Google認定MLエンジニア】予測の生成と解釈 ( Prediction generation and interpretation )

    【Google認定MLエンジニア】予測の生成と解釈 ( Prediction generation and interpretation )

    Google Cloud Professional Machine Learning Engineer 認定試験対策まとめ

    🔍 概要

    「Prediction generation and interpretation」は、モデルの精度向上・特徴量エンジニアリング・次元削減・モデルの公平性などに関する一連の実務的な意思決定スキルを問うパートです。 BigQuery ML(BQML)を中心としながらも、Vertex AI、DataflowなどGCPの他プロダクトとの連携も求められます。


    📌 出題テーマ別まとめ


    ① 特徴量選択と次元削減(Feature Selection & Dimensionality Reduction)

    • BQMLのFEATURE_SELECTIONで重要な特徴量を自動選定
    • PCA(主成分分析)による次元削減は以下の2通り
      • Dataflow+Apache Beamによる実装
      • BQMLネイティブのPCA機能
    • Vertex AI Feature Storeは特徴量保存・管理用途であり、選定や削減には不向き
    • 手動のスケーリングや変換処理より、GCP統合機能を用いた自動処理が優先

    🎯 試験ポイント

    • BQMLのネイティブ機能が最優先FEATURE_SELECTION, PCAなど)
    • 他プロダクトの利用は、BQMLに統合されていない限り正答になりづらい

    ② 前処理と特徴量変換(Preprocessing & Feature Engineering)

    • 数値特徴量はstandard scalarでスケーリング(BQML)
    • one-hot encodingをBigQuery SQLで記述するのは非推奨(効率が悪い)
    • 特徴量の交差(crossing)は、BQMLのSQL構文で表現
    • Vertex AI Feature StoreやDataflowの利用は、BQML内で完結しないため正解になりにくい

    BigQuery SQLでの手動によるOne-Hot Encodingが非推奨とされる理由

    **「効率性・可読性・保守性の観点で不利になるから」**です。以下、詳しく解説します。

    🧨 BigQuery SQLでOne-Hot Encodingを手動実装する方法

    たとえば、color列に red, blue, green の3カテゴリがあるとします。これをOne-Hot Encodingしようとすると、以下のようなSQLを書きます:

    SELECT
    IF(color = 'red', 1, 0) AS color_red,
    IF(color = 'blue', 1, 0) AS color_blue,
    IF(color = 'green', 1, 0) AS color_green
    FROM my_table;
    
    😰 なぜ非推奨なのか?
    ① カテゴリ数が多いと爆発的に列が増える
    • カテゴリ数が100を超えると、手動で列を増やすのは非現実的です。
    • 特にユーザーID・商品コードなど高カーディナリティな特徴には致命的。
    ② SQLが長く・読みづらく・壊れやすくなる
    • すべての条件を手動で書くと人為ミスが起きやすい。
    • スキーマ変更(カテゴリの追加・削除)にコードの修正が必須になる。
    ③ パフォーマンスが悪化しやすい
    • 条件分岐(IF文)を大量に含むクエリはBigQueryの実行最適化が難しくなる。
    • それに伴ってクエリコスト(処理料金)も上昇する。
    ④ 再利用性・自動化パイプラインへの不向き
    • DataflowやVertex AI Pipelinesなどの自動処理と連携しづらく、コードがパイプラインに乗せにくい。
    • MLモデルの再訓練や新カテゴリの対応が発生するたびにSQLを変更する必要がある。
    ✅ 推奨される代替手段(BQML内)

    BQMLの CREATE MODEL では、自動的にOne-Hot Encodingされるケースが多いです:

    CREATE MODEL `project.dataset.model_name`
    OPTIONS(model_type='logistic_reg') AS
    SELECT
    *, -- BQMLがカテゴリ変数を自動変換
    FROM
    `project.dataset.training_data`;
    
    • 特に STRING 型の列に対してBQMLは内部でOne-Hot Encoding相当の変換を行います。
    • 明示的な変換をせずとも正しい前処理が適用されるよう設計されています。

    🎯 試験ポイント

    • スケーリングと交差はBQML内部で処理
    • SQLベースより、統合された関数や構文が優先される

    ③ モデルの公平性とバイアス対策(Fairness and Bias Mitigation)

    • BQMLはバイアス除去機能を提供していない
    • Vertex AI Model Monitoringを使って、公平性メトリクスの追跡・アラートを実装
    • TFXやAI Hubの活用は、文脈的にBQML外の話になりやすく、正答から外れる

    🎯 試験ポイント

    • Vertex AIでのモニタリングが唯一の正解
    • BQML単体ではバイアス対策が難しい点を把握すること

    🧠 総まとめ:Prediction generation and interpretationで問われる力

    項目 要点 推奨ツール
    特徴量選択 自動化・繰り返し可能な選択 FEATURE_SELECTION (BQML)
    次元削減 モデル精度&訓練時間改善 PCA(BQML or Dataflow)
    スケーリング 数値変数の正規化 standard scalar (BQML)
    エンコーディング カテゴリ変数の処理 BQML内の統合関数
    特徴量交差 相互作用の表現 BQMLのSQL構文
    公平性の担保 バイアス検知・追跡 Vertex AI Model Monitoring

    ✍️ 試験対策Tips

    • まずは「BQMLで完結できる方法」を優先して覚える
    • それでも補えない領域(公平性チェックなど)はVertex AIを使う
    • 「できるが非効率」な手法(SQLでの手動処理等)は選択肢として切り捨てるのが正解
  • 【Google認定MLエンジニア】特徴選択と特徴量エンジニアリング(Feature Selection and Engineering)ガイド

    【Google認定MLエンジニア】特徴選択と特徴量エンジニアリング(Feature Selection and Engineering)ガイド

    Google Cloud の BigQuery ML 環境をベースにした「特徴選択と特徴量エンジニアリング」の戦略を体系的に整理します。この知識は、機械学習モデルの精度向上・計算効率の最適化・スケーラビリティの担保に不可欠です。


    🧩 1. 特徴量エンジニアリングの目的

    目的 説明
    モデル性能の向上 意味のある新しい特徴量の作成により、モデルの精度を高める。
    データのスケーラビリティ 一貫した処理・自動化されたパイプラインにより、大規模データへの対応を強化。
    学習効率の向上 無駄な特徴を削減し、学習コストを下げる。

    🔧 2. BigQuery ML における主要なエンジニアリング手法

    2.1 欠損値への対応

    • 方法: SQLベースで IFNULL() などの関数を活用
    • 注意点: 欠損値処理は予測精度に直結するため、事前処理で徹底的に対策

    2.2 カテゴリカルデータの変換

    手法 概要 適用場面
    One-Hot Encoding 各カテゴリを0/1の列に展開 少数カテゴリ
    Label Encoding ラベルを数値に変換 順序付きカテゴリ
    Feature Hashing 高カーディナリティカテゴリを効率的に表現 大量のユニーク値がある場合(例:郵便番号)

    🧠 3. 特徴選択(Feature Selection)

    3.1 正則化による選択

    • Lasso回帰(L1正則化)
      • 重要でない特徴の係数をゼロにする
      • MODEL_TYPE='linear_reg', L1_REG を指定

    3.2 Feature Importance Metrics

    • 方法: ML.FEATURE_IMPORTANCE関数で重要度を算出
    • 目的: 予測精度に寄与する特徴量の可視化と選別

    🧪 4. 特徴量のスケーリングと変換

    処理 BigQuery ML内での対応 備考
    Standard Scaling ❌非対応 Dataflow等で前処理が必要
    正規化(Normalization) ❌非対応 外部パイプラインで実施

    🧬 5. 新たな特徴量の生成

    • SQLによる派生特徴量の生成

      • 例: 売上 = 単価 × 数量
      • 実装: CREATE MODELTRANSFORM を活用(SQLで表現可能)
    • Feature Crosses

      • 複数カテゴリカル特徴の掛け合わせ
      • 特定の組み合わせパターンの意味合いを捉える

    🤖 6. 自動化とパイプライン化

    方法 内容 利点
    Dataflow + Apache Beam 前処理パイプライン構築 一貫性と再現性の担保
    Vertex AI Pipelines 特徴量処理・モデル学習の自動化 スケーラブルなMLワークフロー構築

    ⚠️ 7. 注意すべき非対応機能

    機能名 状況 代替手段
    PCA(主成分分析) ❌未対応 手動で相関の高い特徴を削除する等
    Recursive Feature Elimination (RFE) ❌未対応 LassoやFeature Importanceで代替
    ハイパーパラメータチューニング ❌未対応 外部ツール(Vertex AI等)を使用

    ※ 現在のBQMLはPCAにネイティブ対応しています

    • 過去(〜2022年頃まで):BQMLにはPCA(主成分分析)は未対応でした。
    • 現在(2023年〜):BQMLは CREATE MODEL で MODEL_TYPE=’pca’ を指定することで、ネイティブにPCAモデルを構築可能になっています。

    ✅ 試験対策のためのまとめ

    試験フォーカス 警告アラート
    欠損値処理・特徴量変換・SQLによる生成 PCAやRFEは BigQuery ML に直接は存在しない
    正則化(Lasso)やFeature Importance 正規化・スケーリングはBigQuery ML内では未サポート
    Feature Hashingや自動化パイプライン構築 k-means は欠損値処理・次元削減には不向き

    📌 おすすめの学習順序(習得ステップ)

    1. SQLによる特徴量生成
    2. 欠損値処理とカテゴリ変換
    3. Lasso回帰・Feature Importanceの理解
    4. Feature Crosses・Feature Hashingの応用
    5. Dataflow/Vertex AIによる自動化