タグ: 特徴量エンジニアリング

  • 【Google認定MLエンジニア】Vertex AI Feature Storeにおける特徴量エンジニアリング完全ガイド

    【Google認定MLエンジニア】Vertex AI Feature Storeにおける特徴量エンジニアリング完全ガイド

    ✅ はじめに

    Vertex AI Feature Store は、GCP上で機械学習パイプラインにおける特徴量の生成・バージョン管理・共有・再利用を一元管理できる重要なコンポーネントです。本記事では、試験にも頻出の「特徴量エンジニアリングに関する設問」をベースに、実務・試験の両面で活用できる知識を体系的にまとめます。


    📌 基本概念:Vertex AI Feature Store の役割

    • 機械学習における特徴量を一元的に保存・管理
    • トレーニングとオンライン推論において一貫性ある特徴量を提供
    • 他プロジェクトやチームと再利用・共有が可能
    • 特徴量のバージョン管理と系譜管理(lineage) を内蔵

    🔧 特徴量エンジニアリングにおける4つの中核タスク

    1. 特徴量の作成(Feature Creation)

    • 正解Vertex AI Feature Store を直接使用して作成(例: create_feature メソッド)
    • 非推奨
      • 外部の BigQuery や Dataflow を介しての前処理(無駄なレイヤー追加)
      • TFX を使った変換(実現可能だが非効率)

    試験のポイント:

    「Vertex AI の組み込みツールを使うのが最も効率的」と覚えておく。


    2. 特徴量のバージョン管理(Feature Versioning)

    • 正解feature versioning を Vertex AI Feature Store の機能で直接実装
    • 利点:
      • モデルの再学習やアップデートにおいて変更履歴を追跡できる
      • チーム内で一貫したデータ基盤が保てる

    試験のポイント:

    「全問共通で登場、最重要項目」:すべての正答選択肢に含まれていた。


    3. 特徴量の共有と再利用(Feature Sharing & Reuse)

    • 正解export_feature 関数を使って他チーム・プロジェクトと共有
    • 試験での立ち位置
      • 主役ではないが、再利用性とコラボレーションを促進する副次的ベストプラクティス

    4. 特徴量の系譜管理(Lineage Tracking)

    • 正解:Vertex AI の組み込みツールで lineage をトラッキング
    • 意義:
      • どのデータからどの特徴が生まれたか追跡でき、データ品質とコンプライアンス向上に寄与

    🚫 非推奨パターンと注意事項(CAUTION ALERT)

    方法 理由
    Dataflow や BigQuery による外部前処理 機能的には可能だが、非効率で複雑化を招く
    Vertex AI Workbench での特徴量管理 できるが、Feature Storeの専用機能の方が効率的
    TFX での変換処理 Vertex AI内で完結すべき処理を外部に出すのは非効率

    📝 試験に向けた要点まとめ(EXAM FOCUS)

    • 🔹 **「バージョン管理」**は最優先で覚えるべき。
    • 🔹 **「Vertex AI Feature Store を直接使う」**が前提。
    • 🔹 「前処理や統合を外部ツールで行う」ことは誤答になりやすい
    • 🔹 「Lineage管理とFeature共有」も適切な文脈で選ぶと得点につながる。

    📚 おわりに

    Vertex AI Feature Store は、単なる特徴量保存の場所ではなく、データ品質・共有性・変更追跡性すべてを担保する基盤です。効率的な設計と運用は、モデルの精度だけでなく、チーム全体の生産性にも直結します。試験では上記のベストプラクティスを意識しながら、選択肢のニュアンスに注意しましょう。

  • 【Google認定MLエンジニア】ユースケースで学ぶ TFXによるデータ前処理のベストプラクティス

    【Google認定MLエンジニア】ユースケースで学ぶ TFXによるデータ前処理のベストプラクティス

    ✅ はじめに

    機械学習モデルの性能は、データ前処理(preprocessing)の質に大きく左右されます。
    Google Cloudの**TensorFlow Extended(TFX)**は、スケーラブルかつ再現性のあるMLパイプラインを構築できるフレームワークです。本記事では、TFXを活用したデータ前処理のベストプラクティスについて、試験頻出ユースケースをもとに解説します。


    📂 データ前処理におけるTFX主要コンポーネント

    コンポーネント 役割
    ExampleGen データの取り込み(Cloud Storage, BigQueryなど)
    Transform 特徴量エンジニアリング、欠損値処理、正規化などのデータ変換
    SchemaGen データスキーマの自動生成
    StatisticsGen データの統計量生成
    ExampleValidator 異常データの検出
    Trainer モデルのトレーニング
    Evaluator モデル評価

    🏥 ユースケース①:医療データの前処理

    シナリオ

    • データ:患者記録、治療履歴、人口統計情報
    • 課題:データの一貫性を確保し、欠損値処理・特徴量エンジニアリングを実施

    必要なステップ

    1. ExampleGenでCloud Storageからデータを取り込む。
    2. Transformで欠損値補完・特徴量変換を行う。

    SchemaGenExampleValidatorは補助的だが、特徴量エンジニアリングの主要ステップではない。


    🏬 ユースケース②:小売業の推薦エンジン

    シナリオ

    • データ:取引データ、顧客インタラクションデータ
    • 課題:大量データをスケーラブルに処理し、特徴量エンジニアリングを実施

    必要なステップ

    1. Dataflow with Apache Beamで大規模データをスケーラブルに処理。
    2. Transformでデータクリーニング・特徴量エンジニアリングを行う。

    SchemaGenはスケーラビリティに直接関与しない。


    🖼️ ユースケース③:画像分類モデル

    シナリオ

    • データ:Cloud Storageに保存されたラベル付き画像
    • 課題:画像リサイズ・正規化などの前処理を行い、モデル学習の準備を整える

    必要なステップ

    1. ExampleGenで画像を取り込む。
    2. Transformで画像リサイズ、正規化を実施。

    StatisticsGenExampleValidatorは補助的だが、リサイズ・正規化には関与しない。


    🚚 ユースケース④:物流業の配送予測モデル

    シナリオ

    • データ:タイムスタンプ、位置情報、配送ステータス
    • 課題:データクリーニング・正規化・特徴量エンジニアリングを行い、モデルの予測精度を高める

    必要なステップ

    1. ExampleGenでデータを取り込む。
    2. Transformでクリーニング・正規化・特徴量エンジニアリング。

    Trainerはモデル学習用であり、前処理の一部ではない。


    📝 まとめ:試験頻出ポイント

    覚えておきたいポイント 具体例
    ExampleGenでデータ取り込み 医療データ、取引データ、画像、物流データなどすべてに必要
    Transformで変換・特徴量エンジニアリング 欠損値処理、リサイズ、正規化、特徴量抽出
    Dataflow with Apache Beamはスケーラビリティ 大規模データ(小売業)向け
    SchemaGen/StatisticsGen/ExampleValidatorは補助的 主にデータ品質チェック目的

    🚨 試験対策メモ

    • Trainerは必ず「モデル学習専用」であり、前処理には使用しない。
    • ExampleValidatorは「データ異常検出」に使うが、必須ではない。
    • スケーラビリティの話が出たら、Dataflow + Apache Beam
  • 【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による自動化

  • 【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 を使う