3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines

3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines

Blueprint reference: Section 3.1, "Choosing the product (e.g., Agent Platform AutoML, BigQuery ML, and Agent Platform Pipelines)."

The previous section chose what kind of model. This one chooses what builds it. The exam presents a team, a dataset location, a skill profile, and a constraint, and expects one product.

The Four Options

Agent Platform Pipelines is deliberately absent from that comparison. A pipeline does not train a model; it runs the steps that do. A pipeline can call BigQuery ML, AutoML, and custom training in the same DAG. If a question offers Pipelines as an alternative to AutoML for the training decision, it is testing whether you know the difference between orchestration and training.

BigQuery ML: The Data-Gravity Choice

Choose it when:

• The training data already lives in BigQuery and moving it is wasted effort.
• The team's fluency is SQL, not Python.
• Inference is batch or analytical — scoring a table, populating a serving table nightly.
• The model type is one BigQuery ML supports and the problem does not need a bespoke architecture.

Its limits are equally clear. There is no online endpoint, no custom architecture, no arbitrary loss function, and model types are limited to the supported list. When a scenario adds "must respond in under 100 ms per user request," BigQuery ML alone stops being the answer and the pattern becomes export-and-deploy or a registered remote model.

AutoML: The Capacity Choice

Choose it when:

• The team lacks ML engineering capacity or the deadline does not permit architecture work.
• The problem is a standard one — tabular classification/regression, image classification or object detection, text classification, entity extraction, sentiment, video classification.
• Quality per unit of engineering effort is the objective.

AutoML handles feature engineering, architecture selection, and hyperparameter tuning, and produces a model that deploys natively to an endpoint. What you give up is control: you cannot specify the architecture, insert a custom loss, or reproduce the search exactly. Training cost is also node-hour based and can exceed a well-targeted custom job for a simple problem.

A frequent and correct exam pattern: AutoML as the baseline. Train an AutoML model first to establish what an automated system achieves, then decide whether custom work can beat it. If custom effort does not beat AutoML, ship AutoML.

Custom Training: The Control Choice

Required when any of the following is true:

• A bespoke architecture or a published research model must be reproduced.
• A custom loss function or training loop is needed — ranking objectives, adversarial training, multi-task heads.
• The framework or version is not covered by managed offerings.
• Distributed training across many workers with a specific parallelism strategy is required.
• The training procedure itself must be auditable and version-controlled as code.

Custom training runs a container you provide (or a prebuilt container plus your Python package) on managed infrastructure, with worker pools, accelerators, and the tuning service available. It is the most work and the most control.

Tabular Workflows: The Middle Ground

For tabular problems, Tabular Workflows sit between AutoML and fully custom training: managed pipeline-based workflows for tabular model training that expose more configuration than AutoML — algorithm choice, feature transformations, and search budget — while still handling the plumbing. When a scenario wants "more control than AutoML but we are not writing a training loop," this is the intended answer.

Working Decision Flow

Is the data in BigQuery, the team SQL-first, and inference batch?
   └─ yes → BigQuery ML
   └─ no  ↓
Does the problem need a bespoke architecture, custom loss, or an unusual framework?
   └─ yes → Custom training
   └─ no  ↓
Is it a tabular problem needing more control than AutoML offers?
   └─ yes → Tabular Workflows
   └─ no  → AutoML

Then, independently: does this need to run repeatedly, on a schedule,
with lineage and validation gates?  → wrap it in a Pipeline.

Cost Shapes Compared

The recurring cost trap is an endpoint left deployed for a model that is only used in batch. Batch prediction jobs provision resources for the run and release them; an endpoint bills continuously.

Exam Traps

• Pipelines offered as a training product. It orchestrates; it does not train.
• BigQuery ML for real-time serving. Export or register a remote model.
• Custom training when AutoML would do. Over-engineering is a wrong answer when the scenario stresses limited capacity.
• AutoML when the scenario demands a specific architecture or loss. It cannot express one.
• Moving data out of BigQuery unnecessarily. Data gravity is a real argument.