セクション2 要点と暗記 — チーム横断でのデータとモデルの管理
🎯 暗記用。意思決定ツリー・対比表・暗記カード。
🌳 前処理ツール選定ツリー（30秒で唱える）
1. データはどこ？
├─ BigQuery で SQL でいける → BigQuery
├─ GCS の画像/動画 → Dataflow or Dataproc
└─ ストリーミング → Dataflow
2. 規模は？
├─ < 10GB / 単発 → pandas / Polars
├─ TB〜PB → BigQuery or Dataflow
└─ 既存 Spark 資産 → Dataproc
3. 訓練と推論の skew を防ぐ？
→ TFT または Feature Store で前処理を共有
🃏 暗記カード（Q→A）
| Q | A |
|---|---|
| BigQuery と Dataflow の使い分け？ | SQL で書ける/データが BQ にある = BQ、ストリーミング/Beam = Dataflow |
| 既存 Spark を活かすなら？ | Dataproc（必要に応じて Dataproc Serverless） |
| 訓練/推論の前処理を共通化する2つの仕組みは？ | TFT (TensorFlow Transform) と Feature Store |
| PII 検出・マスキングのサービスは？ | Sensitive Data Protection (旧 Cloud DLP) |
| Feature Store の2つのストアは？ | Online Store（低レイテンシ）と Offline Store（訓練用） |
| Workbench と Colab Enterprise の最大の違いは？ | Workbench はインスタンス管理あり、Colab Enterprise は サーバーレス & 協業向け |
| Notebook の課金を抑える設定は？ | Idle shutdown |
| 実験を比較する Google サービスは？ | Agent Platform Experiments |
| パイプライン/モデルの系統管理は？ | ML Metadata |
| 🆕 生成 AI を LLM で評価する手法は？ | LLM-as-a-judge |
| LLM-as-a-judge をマネージドで提供するサービスは？ | Gen AI Evaluation Service |
| BigQuery で列レベル制御を行う仕組みは？ | ポリシータグ (Policy Tags) |
| 暗号化キーを自社管理するには？ | CMEK (Customer-Managed Encryption Keys) |
| データ外部送信を境界制御するには？ | VPC Service Controls |
| 過去時点での特徴量値を訓練で使うには？ | Point-in-time correctness（Feature Store の feature_time） |
📊 対比表
前処理ツール比較
| pandas | BigQuery | Dataflow | Dataproc | |
|---|---|---|---|---|
| 規模上限 | GB | PB+ | PB+ | PB+ |
| 言語 | Python | SQL | Beam (Python/Java) | Spark/PySpark |
| サーバーレス | – | ○ | ○ | △ (Serverless 版) |
| ストリーミング | × | × (Streaming insert は別) | ◎ | ○ |
| 既存資産活用 | × | × | × | ◎ |
| 第一候補 | EDA・小規模 | SQL で完結 | Beam パイプライン | 既存 Spark |
Workbench vs Colab Enterprise
| Workbench | Colab Enterprise | |
|---|---|---|
| インスタンス管理 | 必要 | 不要（サーバーレス） |
| GPU カスタマイズ | 細かく可 | 限定的 |
| 協業 | △ | ◎（コメント・共有） |
| カスタムイメージ | ○ | △ |
| 第一候補 | 長期 ML 開発・GPU 細かく要 | アドホック・ペアプロ |
モデル評価アプローチ
| 自動メトリクス | LLM-as-a-judge | 人手評価 | |
|---|---|---|---|
| コスト | 最安 | 中 | 最高 |
| 速度 | 即時 | 数秒/件 | 分〜時間 |
| 主観性 | 低（参照との一致） | 中（基準次第） | 高 |
| 用途 | 翻訳/要約の自動評価 | 指示遵守・有害性 | 最終品質確認 |
🔥 頻出シナリオ → 即答パターン
| シナリオ | 即答 |
|---|---|
| TB 級の SQL で書ける前処理 | BigQuery |
| Pub/Sub からストリーミングで特徴量計算 | Dataflow → Feature Store |
| 既存 PySpark コードを移行 | Dataproc Serverless for Spark |
| 数 GB のローカル EDA | pandas / Polars in Workbench/Colab |
| 訓練/推論で同じ前処理コード | TFT or Feature Store |
| オンライン推論で ms 級に特徴量取得 | Feature Store Online Store |
| 過去時点での特徴量値で訓練 | Point-in-time correctness（Feature Store） |
| PII を含むテキストを LLM に渡す | DLP redaction + Model Armor |
| ノートブックの放置で課金 | Idle shutdown 設定 |
| 実験のパラメータ・メトリクス比較 | Agent Platform Experiments |
| 「このモデルはどのデータから？」を辿りたい | ML Metadata（Lineage） |
| 生成 AI の品質を低コスト評価 | LLM-as-a-judge / Gen AI Evaluation Service |
| 列単位でアクセス制御 | BigQuery ポリシータグ |
| 機微データの暗号化キーを自社管理 | CMEK |
| ノートブックを VPC 内に閉じる | VPC SC + Private Google Access |
⚠️ ひっかけ警報
- 「BigQuery にあるデータを Dataflow で前処理」 → 大抵 BQ で完結する方が安い・速い
- 「ストリーミング処理」と聞いて Dataproc → ストリーミングは Dataflow が第一候補
- 「LLM-as-a-judge は全件で人手評価を不要にする」 → 重要意思決定は人手評価で裏付けが必要
- 「Workbench ならどんな共有も OK」 → 協業重視なら Colab Enterprise が向く
- 「Feature Store なしで Bigtable から特徴量取得」 → Feature Store は 特徴量管理・系統・skew 防止 までセット
- 「PII を含むデータを GCP 外に送信して処理」 → VPC SC + DLP で境界を保つ
- 「Idle shutdown は不要」 → 課金の主要因。必ず設定
📝 一行サマリー
データはまず BigQuery、ストリーミングは Dataflow、特徴量は Feature Store、実験は Experiments、評価は自動+LLM-as-a-judge+人手の3層。