タグ: バイアス対策

  • 【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エンジニア】BigQuery MLによる実践的なモデル構築・評価・運用ガイド

    【Google認定MLエンジニア】BigQuery MLによる実践的なモデル構築・評価・運用ガイド

    ✅ はじめに

    BigQuery ML(BQML) は、Google Cloud 上でSQLベースに機械学習モデルを構築・運用できる強力なツールです。 このノウハウ記事では、Googleの認定試験(Professional ML Engineer)や現場で問われるスキルをベースに、

    • データ設計
    • 特徴量エンジニアリング
    • モデル選定
    • 公平性
    • 自動運用(MLOps)

    といった観点から、構築すべきモデルの判断力・手順をわかりやすくまとめました。

    📂 適切なモデル構築ステップ(全体像)

    1. データの収集・更新設計
    2. 特徴量の抽出と前処理
    3. モデルアルゴリズムの選定
    4. 評価とリトレーニング戦略
    5. 公平性と責任あるAIの実装
    6. デプロイとスケーラブル運用

    各フェーズで BQMLがどこまでカバーできるか/どこで外部ツールが必要か を理解するのが重要です。

    ① データの更新性・鮮度を保つ

    🧠 ポイント

    • モデル精度は 「最新データ×継続的学習」 が命
    • 特に「離脱予測」「購買予測」「レコメンド」などは時間とともにデータが陳腐化

    ✅ 推奨する構成

    要素 ツール
    データ自動更新 BigQuery Data Transfer Service (BQ DTS)
    月次リトレーニング Cloud Scheduler + BQML で retrain

    ❌ よくある誤り

    • Cloud Functions でデータ取り込みを手作業スクリプトでやる(冗長・非効率)

    ② 特徴量エンジニアリングは「BQ内完結」が基本

    BQMLには、次のような特徴量処理機能が組み込みで提供されています。

    機能 用途
    FEATURE_SELECTION 重要な特徴量を自動選定(高次元対策)
    FEATURE_CROSS カテゴリ変数同士の掛け合わせ
    STANDARD_SCALER 数値のスケーリング(勾配学習安定化)

    🔧 実務Tips

    • 顧客の「性別×年代」などの交差は FEATURE_CROSS
    • 価格や視聴回数のスケーリングは STANDARD_SCALER

    ❌ NG判断

    • 「Cloud Functions + Python」で前処理を書く必要は基本なし
    • 「Vertex AI Workbench」で前処理だけ行うのは冗長

    ③ モデルの選び方(タスク別)

    🎯 BQMLで選べる主要モデルと適用ケース

    モデルタイプ 主な用途
    LINEAR_REG 数値予測(売上・温度・故障時期)
    LOGISTIC_REG 二値分類(購入/非購入、離脱/継続)
    ARIMA_PLUS 時系列予測(週ごとのPV、売上)
    MATRIX_FACTORIZATION レコメンド(ユーザー×アイテム)←🆕 推薦問題対応

    🚨 注意点

    • 「Vertex AIを使えばいい」はNG。BQMLでできるならそれがベストプラクティス
    • モデル選定の根拠が重要。回帰 vs 分類 vs 推薦の判断力を持つこと。

    ④ 評価・自動再学習・モニタリング

    ✅ モデル精度の評価指標(BQML)

    ML.EVALUATE関数で AUC、RMSE、Log Loss などを確認

    🔁 再学習スキーム

    • Cloud Schedulerで月次バッチ retrain を自動化
    • 特徴量エンジニアリング+再学習=MLOps構築の第一歩

    🧠 高度化オプション

    • Vertex AI Model Monitoring で、モデルバイアスや精度の劣化を継続監視
      • 特にローン審査・医療・HR分野で重要

    ⑤ フェアネスと責任あるAIの実装

    ✅ なぜ必要?

    • 特定の属性(年齢・性別・国籍)に偏った予測を防ぐため

    推奨実装

    項目 方法
    バイアス検出 Vertex AI Model Monitoringで属性ごとの予測傾向を監視
    定期レビュー チームで公平性のダッシュボード確認(特にモデル更新時)

    ❌ 誤解されがち

    • 「暗号化」はセキュリティ対策であって、フェアネスとは別問題

    ⑥ モデルのデプロイとスケーラブル運用

    シナリオ 推奨手法
    Webアプリからリアルタイム予測 Cloud Run で BQMLモデルをサービング ←🆕 推薦システム問題で出題
    モデルの保存 BigQuery ML内で自動的にバージョニング管理される(Cloud Storageへの保存は不要)

    ✅ まとめ:試験や実務で役立つ判断軸

    判断軸 YESなら選択
    データがBigQueryにある → BQMLで処理
    前処理がSQLでできる → BQML内で完結させる
    モデル更新は月次でOK → Cloud Scheduler+BQML retraining
    公平性が求められる → Vertex AI Model Monitoring で監視
    推薦が必要 → MATRIX_FACTORIZATION
    リアルタイム推論が必要 → Cloud Run を使う