Prepare and test your skills
Prepare and test your skills
Preparing training data for BigQuery ML fine-tuning is the process of building validated prompt-response pairs inside BigQuery so a Gemini model can be tuned with SQL. Data flows from operational source systems into a separate ML-optimized store in BigQuery (opens in a new tab), where built-in transformations preprocess it before the CREATE MODEL fine-tuning job reads it. Because training data stays in BigQuery, the pipeline depends on correct schemas, validated labels, and materialized storage rather than on external data movement.
Prompt-response storage in BigQuery defines the schema that the fine-tuning job reads as input examples and expected outputs. Store unprocessed structured and semi-structured data in BigQuery ML (opens in a new tab) project datasets, and store intermediate processed data in BigQuery as well. For maximum training speed, store training data as materialized tables instead of views or subqueries, and read data through the BigQuery Storage API for artifact tracking with a managed tabular dataset.
For large fine-tuning datasets, apply partitioning in BigQuery to improve query performance and cost efficiency during preprocessing and training reads. Use the transformations built into BigQuery ML for preprocessing when the model is built in BigQuery ML, which is the most cost-effective method for SQL-based workflows. When historical feature values must be reused offline, store feature data in a BigQuery table or view behind Agent Platform Feature Store (opens in a new tab), which requires an online store instance and defined feature views to serve low-latency workloads.
Exam tip: Use materialized tables, not views or subqueries, for BigQuery ML training data to get maximum read speed.
Data validation for Gemini fine-tuning confirms that schemas are correct, anomalies are removed, and labels teach the desired behavior. Validate schemas and detect anomalies with TensorFlow Data Validation (TFDV) and with automated data quality scans in BigQuery where applicable. For generative AI, data quality has four peer dimensions:
Labels for fine-tuning or reinforcement learning from human feedback (RLHF) must accurately reflect the quality, relevance, and safety of generated outputs, because the tuned model reproduces the judgments encoded in those labels. Create and import text training data through the Agent Platform page in the Google Cloud console, where prompt and tuning capabilities support customized classification, entity extraction, and sentiment analysis, alongside Marketplace labeling solutions such as Labelbox and Snorkel Flow. Synthetic data improves prompt diversity and model robustness when real-world data is insufficient or imbalanced, so consider synthetic generation in Gemini Enterprise Agent Platform and BigQuery DataFrames to create datasets based on existing patterns.
Preprocessing service selection for BigQuery ML fine-tuning depends on data type, data volume, and existing team skills. SQL-based transformation in Gemini in BigQuery (opens in a new tab) keeps structured data in place, while distributed processing moves unstructured data into training-optimized binary formats before it lands in BigQuery or Cloud Storage.
| Option | Best for | Processing approach |
|---|---|---|
| BigQuery | Structured and semi-structured data processed with SQL | Built-in BigQuery and BigQuery ML transformations, with partitioning for large datasets |
| Dataflow | Large volumes of unstructured data | Apache Beam model to convert data into binary formats like TFRecord for faster ingestion |
| Managed Service for Apache Spark | Teams with existing Spark code and skills | Serverless Spark processing, with one-off Python scripts for smaller in-memory datasets, and pandas combined with Dataflow for non-SQL or streaming transforms |
Data flows from source systems to Dataflow or Spark for conversion, then to BigQuery as materialized training tables that the fine-tuning job depends on. Choose BigQuery when an SQL-based process is appropriate and all data is contained in BigQuery; choose Dataflow when throughput for large unstructured volumes controls ingestion; choose Managed Service for Apache Spark when reuse of Spark investments outweighs rewriting logic in SQL or Beam.
Managed dataset handling in BigQuery links a specific training snapshot to the resulting tuned model for reproducibility. After preprocessing, consider a managed dataset in Agent Platform to create a clear link between data and custom-trained models, with descriptive statistics and automatic or manual splitting into train, test, and validation sets. Managed datasets are not required when the team wants more control over splitting in training code or when lineage between data and model is not critical.
Version data artifacts in BigQuery or Cloud Storage and version code artifacts such as pipeline components in Artifact Registry, while storing metadata and pointers to data locations in version control or a data catalog. To maintain consistency of feature data across training runs, use Agent Platform Feature Store so BigQuery stores all feature data including historical values for offline work. This separation lets the training pipeline depend on a versioned BigQuery snapshot while the registry and catalog preserve which dataset, parameters, and model artifacts produced each result.
Evaluating and deploying a fine-tuned Gemini model is the process of proving that tuning improved the model for an enterprise task and then serving the validated version for inference. In BigQuery, BigQuery ML (opens in a new tab) holds the trained model and evaluation data, while Vertex AI Model Registry on Gemini Enterprise Agent Platform provides versioning, evaluation, and online prediction in a single interface without needing a serving container or export. The workflow moves from registration to comparative evaluation to controlled deployment and production monitoring.
Vertex AI Model Registry is the central store that lets teams manage BigQuery ML models alongside Gemini Enterprise Agent Platform models. Registration requires the Agent Platform API aiplatform.googleapis.com to be enabled, which needs the serviceusage.services.enable permission through the Owner role or Service Usage Admin role, and registration itself needs the Agent Platform Administrator role roles/aiplatform.admin. Once registered, the model appears in the Model Registry page with a Source column that shows it originated in BigQuery ML.
A BigQuery ML model can be registered in the Google Cloud console by selecting the model in the Explorer pane and clicking Register on the Registry tab, or in SQL with the CREATE MODEL statement. The statement supports three related options:
MODEL_REGISTRY: registers the model to Model Registry and shows it there automatically after BigQuery ML training completes.VERTEX_AI_MODEL_ID: sets the model ID visible in Model Registry for that BigQuery ML model.VERTEX_AI_MODEL_VERSION_ALIASES: assigns one or more version aliases to streamline deployment, manage versions, and enable Vertex Explainable AI.Exam tip: Each BigQuery ML model can be registered to only one model ID in Model Registry, so use version aliases under that ID to manage iterations rather than creating a second registration.
Comparison of fine-tuned Gemini models starts from measurable business outcomes broken into key performance indicators (KPIs) and then tests whether tuning moved those indicators. Models are first scored with aggregate metrics such as accuracy, precision, and recall on held-out test datasets, plus training signals such as loss and accuracy tracked over time. For generative behavior, evaluation extends to text quality, image fidelity, code functionality, automated metrics such as perplexity for language models, and checks against quality metrics and safety guidelines.
A robust comparison examines the fine-tuned model from three angles, not just a single score:
| Comparison | What is compared | Decision it supports |
|---|---|---|
| Baseline aggregate | Fine-tuned metrics versus the base foundation model on the same test set | Whether tuning improved overall task performance |
| Data slices | Performance on particular subsets, including safety, relevance, and quality slices | Whether gains hold for critical segments or hide regressions |
| Versions and architectures | Different model versions, hyperparameters, input datasets, and architectures | Which candidate to promote to deployment |
This layered approach aligns model performance with business needs because a higher aggregate score alone does not prove the model is safer, more relevant, or more robust on the enterprise distribution. Human-in-the-loop evaluation is used alongside automated metrics for nuanced aspects such as creativity, safety compliance, and output relevance, including prompt engineering and response filtering checks for generative AI.
Vertex AI TensorBoard and Experiments on Gemini Enterprise Agent Platform provide the experiment record that makes baseline comparisons trustworthy. Vertex AI TensorBoard visualizes and compares experiments by hyperparameters, tracks metrics like loss and accuracy over time, visualizes the model graph, and projects embeddings to lower dimensions. Experiments integrates with Vertex ML Metadata to log linkage across parameters, metrics, and dataset and model artifacts, so a fine-tuned Gemini version can be traced to its training data, prompts, and evaluation result.
Understanding individual predictions uses interactive and attribution tools. A Gemini Enterprise Agent Platform Workbench instance provides evaluation libraries plus the What-if Tool (WIT) for interactive bias analysis and the Language Interpretability Tool (LIT) for visual analysis of natural language processing behavior. Vertex Explainable AI adds feature attributions that detail the importance of each input feature to a prediction, which helps teams understand behavior and build trust before deployment.
Deployment of a validated fine-tuned model serves predictions either where the data already lives or as a scalable online service. BigQuery ML keeps data, infrastructure, and model together for SQL-based batch inference, which fits when all data is contained in BigQuery and the team works in SQL. Registering the same model to Model Registry (opens in a new tab) enables online prediction from the Agent Platform interface without building a serving container, although certain model types have deployment limitations.
The deployment path therefore depends on latency, access pattern, and governance needs. Batch scoring in BigQuery ML avoids data movement for tabular evaluation and large-scale analysis, while a Vertex AI endpoint supports low-latency online serving, integration with Feature Store for consistent features, and centralized version management through aliases. Model Garden remains the source for selecting the latest base models when retraining or re-tuning is needed, and continuous training can automatically update models with new training data or prompts.
Gemini Enterprise Agent Platform Pipelines automates the full sequence from data preparation through training, evaluation, and deployment. The ordered lifecycle runs as:
Cloud Build extends this pipeline into continuous integration and continuous delivery (CI/CD) by building, testing, and packaging model and application code. Stress testing under realistic load uses tools such as Locust, Grafana k6, or Apache JMeter, while Cloud Monitoring tracks latency, error rate, and resource utilization to find bottlenecks. Production reliability uses Model Monitoring on Gemini Enterprise Agent Platform to detect data drift, track performance, and identify anomalies, including shifts in generative output quality and safety compliance, with scheduled pipeline runs, execution metrics, and reusable templates keeping releases consistent and rollback-ready.
A fine-tuning job using BigQuery ML and Gemini Enterprise Agent Platform adapts a Gemini foundation model to a specialized enterprise task with supervised fine-tuning. The job reads a labeled JSONL training dataset from Cloud Storage, learns additional adapter parameters on top of the frozen base model, and outputs a new tuned model with its own model resource and serving endpoint. In-database ML with BigQuery ML (opens in a new tab) eliminates data movement for SQL-centric teams, while the tuning pipeline runs as a managed Agent Platform job that can be versioned, evaluated, and deployed through Vertex AI Model Registry.
Supported base models for supervised tuning are Gemini 3.5 Flash, Gemini 3.1 Flash-Lite, Gemini 2.5 Pro, Gemini 2.5 Flash, and Gemini 2.5 Flash-Lite. Each job selects one base model, a tuned model display name of up to 128 characters, a tuning job region, and training and optional validation datasets. User data such as the transformed dataset and the tuned model is stored in the tuning job region, while computation can be transparently offloaded to other US or EU regions for accelerator availability.
A supervised fine-tuning job can be created from four interfaces that submit the same underlying pipeline:
client.tunings.tunetuningJobs.create methodFor thinking-capable models, set the thinking budget to 0 for Gemini 2.5 models and lower or the thinking level to MINIMAL for Gemini 3 and higher. During supervised fine-tuning the model learns from training data and omits the thinking process, so the tuned model performs tuned tasks effectively with little to no thinking budget and lower cost.
Training parameters control how many passes the model makes, how many trainable adapter parameters are added, and how large each update step is. The platform automatically adjusts the default epoch value to training dataset size based on benchmarking, and the recommendation is to submit the first job without changing hyperparameters. The REST hyperParameters object carries the same settings that appear as Tuning setting fields in the console.
| Parameter | Meaning | Tradeoff |
|---|---|---|
Epoch count (epochCount / Number of epochs) | Number of complete passes over the entire training dataset | More epochs increase training tokens and cost; too many can overfit a small dataset |
Adapter size (adapterSize / Adapter Size) | Size of the parameter-efficient adapter; supported values are 1, 2, 4, 8, and 16, or 1, 2, 4, and 8 depending on model | Larger adapter learns more complex tasks but needs a larger dataset and longer training time |
Learning rate multiplier (learningRateMultiplier) | Multiplier on the step size at each iteration; default is 1 | Higher values move faster but risk instability; start from the default |
Additional execution options travel with the job configuration. The console exposes Export last checkpoint only to disable intermediate checkpoints and keep only the latest checkpoint, plus Enable model validation with a Cloud Storage validation dataset path to produce validation metrics during training. The REST job also supports tunedModelDisplayName, training_dataset_uri, validation_dataset_uri, encryptionSpec.kmsKeyName, serviceAccount, and preview evaluationConfig for automatic evaluation with the Gen AI evaluation service in us-central1.
Exam tip: Leave epochs, adapter size, and learning rate multiplier at defaults for the first run; the platform auto-tunes the default epoch count to dataset size, and training-token cost equals dataset tokens multiplied by epochs.
Execution of a supervised tuning job follows the same order in every interface: first configure model details, then configure tuning settings, then attach datasets and start the pipeline. Data flows from the Cloud Storage JSONL file to the tuning pipeline, then from the pipeline to the tuned model resource, its serving endpoint, and its per-epoch checkpoints.
In the console the ordered workflow is:
In code the job depends on the SDK client configuration and dataset objects. The Python flow sets GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION, and GOOGLE_GENAI_USE_ENTERPRISE=True, builds TuningDataset objects with gcs_uri values for training and validation, optionally builds EvaluationConfig with Metric and OutputConfig with GcsDestination, and calls client.tunings.tune with base_model and CreateTuningJobConfig. The REST flow sends a POST request to https://TUNING_JOB_REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/TUNING_JOB_REGION/tuningJobs with baseModel, supervisedTuningSpec, hyperParameters, and tunedModelDisplayName. Colab Enterprise adds parameter cells for PROJECT_ID, REGION, TUNED_MODEL_DISPLAY_NAME, source_model, train_dataset, and validation_dataset; running the cells creates the job and the View tuning job button opens Monitor, Dataset, and Details tabs.
Monitoring tracks the tuning pipeline from submission through serving readiness. The SDK job object exposes state values such as JOB_STATE_PENDING and JOB_STATE_RUNNING that are polled with client.tunings.get until the job leaves the running states, then exposes tuned_model.model, tuned_model.endpoint, tuned_model.checkpoints, and experiment. Each checkpoint reports a checkpoint_id, epoch, step, and endpoint, so teams can compare progress and select the best performing checkpoint. The console and Colab Enterprise Monitor tab surface tuning metrics when ready, while the Details tab shows the tuning method and base model.
Compute resources are managed through region choice, quota, dataset limits, and pricing. Quota enforces a global limit on concurrent tuning jobs shared across regions and models, with a default of at least one job per project under Global concurrent tuning jobs; additional concurrency requires a quota increase. Dataset limits bound cost and scheduling, including 131,072 maximum input and output tokens per training example, 1 GB maximum JSONL file size, 10M text-only or 300K multimodal training examples, and a validation set capped at 5000 examples or 30% of training examples when validation exceeds 1000 examples. Tuning endpoints are us-central1 and europe-west4 with serving on us and eu multi-region endpoints only, and customer-managed encryption keys (CMEK) are not supported. When a BigQuery ML model is created with the CREATE MODEL statement, the MODEL_REGISTRY option registers it to Model Registry and VERTEX_AI_MODEL_ID binds it to one Model Registry model ID for versioning, evaluation, and online prediction without a serving container.
Materialized tables provide maximum training read speed compared to views or subqueries. For large fine-tuning datasets, partitioning the tables also improves query performance and cost efficiency during preprocessing and training reads.
Supported base models are Gemini 3.5 Flash, Gemini 3.1 Flash-Lite, Gemini 2.5 Pro, Gemini 2.5 Flash, and Gemini 2.5 Flash-Lite. Leave epoch count, adapter size, and learning rate multiplier at defaults for the first run because the platform automatically adjusts the default epoch value to training dataset size based on benchmarking.
Each BigQuery ML model can be registered to only one model ID in Vertex AI Model Registry, so iterations are managed with version aliases under that ID. Registration can be done in the console by selecting the model in the Explorer pane and clicking Register on the Registry tab, or in SQL with the CREATE MODEL statement using the MODEL_REGISTRY, VERTEX_AI_MODEL_ID, and VERTEX_AI_MODEL_VERSION_ALIASES options.
Last updated