3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines
Key Takeaways
- Model type follows the data shape and the requirement: gradient boosting for tabular, ARIMA_PLUS for univariate seasonal time series, DNNs for high-dimensional unstructured data, LLMs for language tasks.
- ARIMA_PLUS handles trend, multiple seasonalities, holidays, and anomaly cleaning automatically; ARIMA_PLUS_XREG adds external regressors such as price or promotion flags.
- Deep neural networks rarely beat gradient boosting on tabular data of moderate size and cost far more to train, serve, and explain.
- An LLM is the right model type for open-ended language work but the wrong one for a high-volume, low-latency, fixed-taxonomy classification that a small supervised model handles for a fraction of the cost.
- Always establish a simple baseline first — the naive forecast, the majority class, or a logistic regression — because it defines what "better" means.
3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines
Blueprint reference: Section 3.1, "Choosing the model type (e.g., ARIMA, DNN, and LLM)."
Google names three examples in that bullet and they are deliberately far apart: a statistical time-series model, a neural network, and a large language model. The exam wants to see that you pick by problem shape rather than by fashion.
The Decision, in One Table
| Data shape and task | First choice | Why |
|---|---|---|
| Tabular, mixed types, thousands to millions of rows | Gradient boosting (XGBoost, BOOSTED_TREE_*) | Consistently the strongest tabular family; handles missing values and mixed types natively |
| Tabular, need a transparent linear model | Linear / logistic regression | Coefficients are directly interpretable; L1 gives feature selection |
| Univariate or grouped time series with seasonality | ARIMA_PLUS | Automatic trend, seasonality, holiday, and anomaly handling |
| Time series driven by known external factors | ARIMA_PLUS_XREG | Accepts exogenous regressors such as price, weather, promotions |
| Images, audio, video, dense embeddings | DNN / CNN / transformer | Learns representations from raw high-dimensional input |
| Sequential dependencies, long horizons, many covariates | Deep forecasting or transformer models | Captures cross-series and non-linear interactions ARIMA cannot |
| Open-ended language: summarize, extract, converse, reason | LLM | Handles unbounded output space and unseen phrasing |
| Fixed-taxonomy, high-volume text classification | Small supervised classifier or AutoML | Orders of magnitude cheaper and faster than an LLM at the same accuracy |
| Recommendation from interaction history | Matrix factorization or two-tower retrieval | Purpose-built for collaborative signal |
| Grouping without labels | k-means, DBSCAN, PCA, autoencoder | Unsupervised structure discovery |
ARIMA_PLUS in Detail
Forecasting questions are common and ARIMA_PLUS is Google Cloud's default answer for classical time series. What it does automatically is the point:
- Trend and seasonality decomposition, including multiple seasonal periods (daily, weekly, yearly).
- Holiday effects, when a region is specified.
- Anomaly detection and cleaning on the input series, so a one-off spike does not distort the fit.
- Automatic hyperparameter search over the ARIMA order.
- Prediction intervals at a requested confidence level.
- Grouped forecasting — many series (per store, per SKU) in a single
CREATE MODELusingtime_series_id_col.
CREATE OR REPLACE MODEL `analytics.sku_forecast`
OPTIONS (
model_type = 'ARIMA_PLUS',
time_series_timestamp_col = 'sale_date',
time_series_data_col = 'units',
time_series_id_col = 'sku_id',
holiday_region = 'US',
auto_arima = TRUE
) AS SELECT sale_date, units, sku_id FROM `analytics.daily_sales`;
Choose ARIMA_PLUS_XREG instead when the series is genuinely driven by measurable external variables you will know at forecast time — price, promotion flag, temperature. If you will not know the regressor's future value, it cannot be used as a regressor.
Move beyond ARIMA when there are many interacting series, rich covariates, or non-linear regime behaviour; that is where deep forecasting models or AutoML forecasting earn their extra cost.
When a DNN Is Justified — and When It Is Not
Deep networks earn their keep when the input is high-dimensional and the useful features are not hand-engineerable: pixels, waveforms, token sequences, graphs. On tabular data of moderate size, gradient boosting usually wins, trains in minutes on CPU, and is far easier to explain and serve.
The costs a DNN adds are real and testable: accelerator hours for training, a larger serving footprint, more hyperparameters to tune, more ways to fail to converge, and weaker out-of-the-box interpretability. A scenario that stresses limited budget, a small team, tabular data, or a requirement to explain individual decisions is steering away from a DNN.
Where DNNs do belong on tabular data: very large datasets with high-cardinality categorical features that benefit from learned embeddings, or when the tabular data must be fused with text or images in one model.
When an LLM Is the Wrong Answer
LLMs are the correct model type for open-ended language work — summarization, extraction from unseen document layouts, conversational interfaces, reasoning over text. They are the wrong model type for:
- High-volume, fixed-taxonomy classification. Routing ten million tickets a day into twelve categories is a supervised classification problem. A small fine-tuned classifier or AutoML text model costs a fraction of per-token inference and answers in milliseconds.
- Numeric prediction from tabular features. An LLM asked to predict a churn probability from structured fields is strictly worse than a model trained for it.
- Anything with a hard sub-100 ms latency budget and high QPS, unless a small model tier has been measured to fit.
The reverse trap also appears: a scenario with an unbounded output space, novel document layouts, or a requirement to handle phrasings never seen in training is not solvable by a fixed-class classifier, and choosing AutoML there is the wrong answer.
Cost, Complexity, Latency, Scalability
The blueprint bullet names four axes. Apply them explicitly:
| Axis | Question to ask |
|---|---|
| Cost | Training cost plus inference cost at production volume. A model that is cheap to train and expensive per call can be the more expensive choice overall. |
| Complexity | Can this team maintain, debug, retrain, and explain it? A model nobody understands is an operational liability. |
| Latency | What is the p95 budget at the required QPS, including preprocessing and feature lookup? |
| Scalability | Does the approach hold at 100× the current volume, or does it require a rearchitecture? |
Always Start with a Baseline
Before any of this, establish what "better" means:
- Forecasting: the naive forecast (tomorrow equals today) or a seasonal naive.
- Classification: the majority class, then a logistic regression.
- Regression: predicting the mean, then a linear model.
- Recommendation: most-popular items.
A surprising number of production models fail to beat these. Reporting a model's metric without a baseline is uninterpretable, and the exam rewards candidates who recognize that.
Exam Traps
- A deep network for a mid-sized tabular problem. Boosted trees, almost always.
- An LLM for fixed-class, high-volume classification. Cost and latency disqualify it.
- ARIMA when the driver is a known external variable. Use ARIMA_PLUS_XREG.
- A regressor whose future values are unknown. It cannot be used for forecasting.
- Reporting a metric with no baseline. Nothing is established.
A retailer must forecast daily units for 40,000 SKUs, each with weekly and yearly seasonality plus national holiday effects, using only historical sales. The team has strong SQL skills and no deep learning experience. What is the most appropriate model type?
A team routes 9 million support tickets per day into 14 fixed internal categories. A Gemini-based prototype achieves 94% accuracy; a fine-tuned small text classifier achieves 93%. Latency budget is 50 ms and cost is under scrutiny. Which should ship?
A demand model must incorporate planned promotional discounts, which the merchandising team publishes 12 weeks ahead. The current ARIMA_PLUS model ignores them and misses promotional spikes. What is the correct change?
A team reports that their new churn model achieves 0.71 AUC and asks for approval to deploy. What is the most important missing piece of information?