1.5 Fine-Tuning Gemini Models from BigQuery

Google Cloud Professional Machine Learning Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Overview, Blueprint & Certification Logistics 0.2 Study Strategy, Scenario Mechanics & 8-Week Roadmap

2 Section 1: Architecting Low-Code AI Solutions (~13%)

1.1 BigQuery ML: Model Types, SQL Syntax and In-Database Evaluation 1.2 Feature Engineering and Feature Selection in BigQuery ML 1.3 Generating Predictions with BigQuery ML 1.4 AutoML on Agent Platform: Tabular, Image, Text and Video Training 1.5 Fine-Tuning Gemini Models from BigQuery 1.6 Model Garden: Evaluating and Selecting the Right Model 1.7 Industry-Specific AI APIs: Document AI, Vision, Translate and Speech 1.8 Generative Media and Models as a Service: Gemini, Imagen and Veo 1.9 Optimizing Gemini Applications for Cost, Latency and Availability

3 Section 2: Collaborating Within and Across Teams to Manage Data and Models (~16%)

2.1 Organizing and Exploring Tabular, Text, Image and Video Data 2.2 Choosing the Preprocessing Tool: BigQuery, Dataflow, Spark and In-Memory Python 2.3 Creating and Consolidating Features in Agent Platform Feature Store 2.4 Data Privacy, PII Handling and Sensitive Information 2.5 Notebook Environments: Collaboration and Security Best Practices 2.6 Prototyping in Workbench and Colab Enterprise with PyTorch, scikit-learn and JAX 2.7 Prototyping with Model Garden Foundational and Open Models in Notebooks 2.8 Choosing the Development and Experimentation Environment 2.9 Evaluating Generative Solutions: LLM-as-a-Judge and RAG Evaluation 2.10 Experiment Tracking, Artifact Lineage and Model Registry Governance

4 Section 3: Scaling Prototypes into ML Models (~21%)

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines 3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines 3.3 Choosing the Deployment Strategy at Design Time 3.4 Modeling Techniques for Interpretability Requirements 3.5 Organizing Training Data on Cloud Storage and BigQuery 3.6 Ingesting Structured and Unstructured Data into Training Pipelines 3.7 Training SDKs and Services: Custom Training, Kubeflow on GKE, AutoML and Tabular Workflows 3.8 Troubleshooting ML Model Training Failures 3.9 Hyperparameter Tuning, Bayesian Optimization and Vizier 3.10 Model Evaluation Metrics, Transfer Learning and Fine-Tuning 3.11 Evaluating Compute and Accelerator Options: CPU, GPU and TPU 3.12 Distributed Training Strategies, Hardware Acceleration and Performance Optimization

5 Section 4: Serving and Scaling Models (~20%)

4.1 Batch and Online Inference: Agent Platform, Model Garden, Cloud Run and GKE 4.2 Rollout Strategies: Canary, Traffic Splitting, Shadow and Blue-Green 4.3 Tuning Models for Production: Vector Search and Model Compression 4.4 Deploying Models to Public and Private Endpoints 4.5 Choosing Serving Hardware: CPU, GPU, TPU and Edge 4.6 Scaling the Serving Backend for Throughput

6 Section 5: Automating and Orchestrating ML Pipelines (~18%)

5.1 Validating Data and Models Inside Pipelines 5.2 Agent Platform Pipelines: Kubeflow Pipelines (KFP) and TFX Architecture 5.3 Reusable Pipeline Components, Artifacts and ML Metadata Lineage 5.4 Ray on Agent Platform for Distributed Python Workloads 5.5 MLOps CI/CD Automation, Retraining Triggers and Skew Prevention

7 Section 6: Monitoring AI Solutions (~13%)

6.1 Securing AI Systems: Exfiltration, Malicious Prompting and Model Armor 6.2 Responsible AI, Explainable AI, Fairness Metrics and Model Governance 6.3 Model Monitoring: Feature Skew and Drift Detection 6.4 Operational Troubleshooting, Performance Profiling and Cost Optimization 6.5 Monitoring, Testing and Evaluating Generative AI in Production

1.5 Fine-Tuning Gemini Models from BigQuery

Key Takeaways Explain This Topic AI

BigQuery reaches Gemini through a CREATE MODEL ... REMOTE WITH CONNECTION statement; the model object is a pointer and inference executes on the Agent Platform side.

Supervised tuning from BigQuery is configured on the remote model itself, using prompt and label columns supplied from a BigQuery table of labelled examples.

Tuning is the right answer when prompt engineering, few-shot examples, and grounding have already failed to fix a consistent behavioural gap — not when the model lacks facts, which is a retrieval problem.

A BigQuery Cloud resource connection with the Vertex AI User role on its service account is the mandatory prerequisite for any remote model or AI function.

AI.GENERATE, AI.GENERATE_TABLE, AI.CLASSIFY, AI.SCORE, AI.IF, AI.AGG, and AI.COUNT_TOKENS expose generative inference as ordinary SQL over warehouse tables.

Last updated: September 2026

• 1.5 Fine-Tuning Gemini Models from BigQuery
• Blueprint reference: Section 1.1, "Fine-tuning Gemini models using BigQuery."

This is one of the newest bullets on the exam guide and one of the least covered by older study material, which makes it disproportionately valuable. The scenario it tests is specific: an organization's labelled examples already live in BigQuery, and the question is whether they can improve a Gemini model without building a separate training pipeline. They can.

The Connection Is the Prerequisite

Nothing in this topic works without a BigQuery Cloud resource connection . The connection has its own service account, and that service account must be granted the Vertex AI User role on the project hosting the model. Every "the query fails with a permission error" distractor in this area resolves to this one grant. -- Created once per project/region, then reused by every remote model and AI function

• CREATE MODEL `analytics.gemini_support`
• REMOTE WITH CONNECTION `us.gemini_conn`
• OPTIONS (endpoint = 'gemini-2.5-flash');

The resulting model object is a pointer , not a copy. No weights land in BigQuery. When you call an AI function against it, BigQuery sends the rows to the Agent Platform endpoint and writes the responses back into the result set. Data residency follows the connection's region, which is why the connection region and the dataset region must match.

Supervised Tuning Driven from a BigQuery Table

Supervised tuning teaches a model a behaviour — a format, a tone, a taxonomy, a domain-specific style of reasoning — from labelled examples. In BigQuery, those examples are just rows: one column holding the prompt, one holding the desired response. CREATE OR REPLACE MODEL `analytics.gemini_ticket_router`

• REMOTE WITH CONNECTION `us.gemini_conn`
• OPTIONS (
• endpoint = 'gemini-2.5-flash',
• max_iterations = 10,
• prompt_col = 'ticket_text',
• input_label_cols = ['routing_label']
• ) AS
• SELECT ticket_text, routing_label
• FROM `analytics.labelled_tickets`
• WHERE split = 'train';

The tuning job runs on Agent Platform; BigQuery is the source of the training rows and the control surface. Practical points the exam likes:

Example count matters more than epochs. A few hundred high-quality, consistently-labelled examples usually beat thousands of noisy ones. Inconsistent labelling is the most common cause of a tuned model that is worse than the base model.

Hold out a validation split. Keep a split = 'eval' partition and score the tuned model against the base model on it. "Tuned" is not a synonym for "better."

A tuned model is a new endpoint. It has its own version and its own cost profile, and it does not automatically inherit later base-model upgrades.

Tuning Versus Prompting Versus Retrieval

This decision is the real exam content. Get it wrong and every downstream answer is wrong.

Symptom Correct response Why

Output format is inconsistent (JSON keys vary, tone drifts) Prompt engineering , then few-shot examples, then tuning Cheapest fixes first; tuning is the last resort

Model does not know internal facts (product catalogue, policy documents) Retrieval / grounding (RAG, Vector Search, grounding with Google Search) Tuning teaches behaviour, not facts; tuned facts go stale immediately

Model consistently mislabels a domain taxonomy despite good prompts and examples Supervised tuning The gap is behavioural and repeatable, which is what tuning fixes

Answers are correct but too slow or too expensive Smaller model, context caching, batch mode A capacity problem, not a quality problem

Model occasionally produces unsafe content Safety filters and Model Armor A guardrail problem, handled in Section 6

The single most-tested confusion is tuning versus grounding . If the scenario mentions a knowledge base, a document corpus, changing prices, or "the model gives outdated answers," the answer is retrieval. Fine-tuning bakes a snapshot of facts into weights that cannot be updated without retraining, which is exactly the wrong architecture for changing data.

Generative AI as SQL

Beyond tuning, BigQuery exposes generative inference through a family of functions that operate row-wise over warehouse tables. These turn unstructured columns into analyzable ones without an external pipeline.

• Function Purpose
• AI.GENERATE Free-form generation over text, image, audio, video, or PDF inputs
• AI.GENERATE_TABLE Generation constrained to a caller-supplied output schema
• AI.GENERATE_TEXT / ML.GENERATE_TEXT Table-valued text generation
• AI.EMBED / ML.GENERATE_EMBEDDING Dense embeddings for semantic search and clustering
• AI.CLASSIFY Categorize text into caller-defined classes
• AI.SCORE Rate an input on a described dimension
• AI.IF Natural-language boolean filter inside a WHERE clause
• AI.AGG Aggregate or summarize across a group of rows
• AI.COUNT_TOKENS Estimate token consumption before running a costly query

AI.GENERATE_TABLE is the one to remember for structured extraction, because it constrains output to a declared schema rather than asking the model to emit JSON and hoping it parses. SELECT counterparty, effective_date, auto_renew

• FROM AI.GENERATE_TABLE(
• MODEL `analytics.gemini_support`,
• TABLE `legal.contracts`,
• STRUCT('counterparty STRING, '
• 'effective_date STRING OPTIONS(description = "ISO 8601 date"), '
• 'auto_renew BOOL' AS output_schema)
• );

The declared fields become real columns of the result, so nothing needs parsing downstream. output_schema is a single string listing name TYPE pairs, each optionally carrying an OPTIONS(description = ...) clause that tells the model what the field means — descriptions are the cheapest accuracy improvement available in the function. Supported types are STRING , INT64 , FLOAT64 , BOOL , ARRAY , and STRUCT , which is why a date is requested as a described STRING and cast afterwards rather than declared as DATE .

AI.COUNT_TOKENS deserves a habit: generative functions bill per token across every row, so a careless AI.GENERATE over a hundred-million-row table is an expensive mistake that a token estimate on a LIMIT 1000 sample would have caught.

Exam Traps

Tuning to add knowledge. Wrong for anything that changes; use retrieval.

Missing IAM on the connection service account. Vertex AI User is the grant.

Assuming the tuned model auto-upgrades. It is pinned to the base version it was tuned from.

Running generative functions over an unfiltered fact table. Sample and estimate tokens first.

Region mismatch between the connection and the dataset.