7.1 Planning an ML Project: BigQuery ML, AutoML, or Pretrained Models?

7.1 Planning an ML Project: BigQuery ML, AutoML, or Pretrained Models?

Core Focus: Exam section 2.3 starts before any SQL is written: identify which business problems suit machine learning, plan a standard ML project (data collection, training, evaluation, prediction), and choose between BigQuery ML, AutoML, and pretrained models. The rest of this chapter then covers training (7.2), inference and Model Registry (7.3), and large language models (7.4).

Vertex AI, the platform behind AutoML and Model Registry, was renamed Gemini Enterprise Agent Platform in April 2026. The exam guide uses the older names.

---

Is Machine Learning the Right Tool?

ML fits when all of these are true:

• There is a pattern to learn that is hard to write as fixed rules (which customers will cancel, what demand will be next month).
• There is historical data with the outcome, called the label, for supervised problems (past customers marked "churned" or "stayed").
• A prediction changes a decision (who gets a retention offer, how much stock to order).

If a simple SQL rule answers the question ("flag orders over $10,000 for review"), use the rule. The exam rewards the simplest solution that meets the requirement.

---

Matching Business Problems to ML Task Types

---

The Standard ML Project Lifecycle

The exam guide lists the core stages as data collection, model training, model evaluation, and prediction. A production project wraps them with framing at the start and monitoring at the end:

Data Leakage

Leakage happens when a training feature contains information that would not exist at prediction time. Predicting whether an order will be returned using refund_issued_date produces excellent evaluation scores and useless real predictions, because a refund date exists only after the return. Build features only from data available at the moment you would make the prediction.

Feature Preparation in BigQuery ML

BigQuery ML automatically one-hot encodes strings, standardizes numbers, and imputes missing values for many model types. For custom logic, the TRANSFORM clause stores preprocessing with the model, so the same steps run again at prediction time:

CREATE OR REPLACE MODEL `customer_analytics.churn_model`
TRANSFORM (
  ML.QUANTILE_BUCKETIZE(tenure_months, 5) OVER () AS tenure_bucket,
  monthly_spend,
  contract_type,
  has_churned
)
OPTIONS (model_type = 'logistic_reg', input_label_cols = ['has_churned']) AS
SELECT tenure_months, monthly_spend, contract_type, has_churned
FROM `customer_analytics.customer_features`;

---

Choosing the Approach: BigQuery ML, AutoML, Pretrained, or Custom

-- AutoML from SQL: Google searches models and tunes them within the budget
CREATE OR REPLACE MODEL `customer_analytics.churn_automl`
OPTIONS (
  model_type = 'AUTOML_CLASSIFIER',
  input_label_cols = ['has_churned'],
  budget_hours = 1.0
) AS
SELECT * EXCEPT (customer_id)
FROM `customer_analytics.customer_features`;

---

Common Exam Traps

• Exporting tabular data to train elsewhere: For standard models on data already in BigQuery, BigQuery ML avoids data movement and infrastructure.
• Training on images with BigQuery ML clustering: Labeled image classification calls for AutoML or a pretrained vision model, not KMEANS on raw bytes.
• Evaluating on training data: Always judge a model on held-out data; a perfect training score often means overfitting or leakage.
• Using ML when a rule works: Fixed business thresholds belong in SQL, not in a model.
• Ignoring the label: Supervised models need historical outcomes. With no labels, think clustering, anomaly detection, or a pretrained model.