Prepare and test your skills
Prepare and test your skills
Continuous evaluation on the Gemini Enterprise Agent Platform is the automated system that samples live serving traffic and scores it against baselines to detect drift and protect production reliability. Vertex AI Model Monitoring compares request-response payloads from an Endpoint against training and production baselines, evaluates quantitative thresholds, and exports violations to Cloud Monitoring and Pub/Sub for response. This closed loop turns statistical change into an operational incident before accuracy collapses.
Training-serving skew, inference drift, and response quality degradation are the three drift classes that Model Monitoring measures with distinct baselines. Training-serving skew compares live serving feature distributions against the training dataset that produced the deployed Model resource and catches pipeline bugs such as sending a product name instead of a product code. Inference drift compares feature and prediction distributions in a recent production window against an earlier production window and catches changing world behavior even when training data is no longer representative.
Each monitored feature has its own quantitative threshold policy owned by the Monitoring Job. The policy defines the tolerable statistical distance, how long a violation must persist, and whether a breach triggers an alert or informational logging. Three classes require separate thresholds:
Exam tip: Training-serving skew compares serving data to training data, while inference drift compares recent serving data to earlier serving data; use skew to catch pipeline bugs and drift to catch changing world behavior.
Continuous evaluation pipelines are recurring serverless workflows that capture inference data and score it against versioned baselines. Agent Platform Pipelines (opens in a new tab) runs these workflows as Kubeflow directed acyclic graphs where each step has inputs, outputs, and a container image and step dependencies define execution order. Data flows from the serving data store to capture, transformation, scoring, and alerting stages in order, so a failed or skipped conditional step can be isolated by checking whether the step ran.
Metrics divide into rule-based checks and model-based judgments. A computation-based evaluation pipeline (opens in a new tab) applies deterministic thresholds for model size, latency, valid output format, and optimizing versus satisficing targets. Model-based evaluation uses an evaluator model to score groundedness, safety, and coherence against grounded reference data. Baselines are built from evaluation datasets, dataset statistics, transformed schemas, model checkpoints, and prior results, and thresholds must account for the target environment because cloud versus on-device and real-time versus batch serving require different satisficing values.
Staged validation proves a model artifact is fit to serve before it receives broad live traffic. Validation starts in a sandboxed staging environment to verify the artifact loads with its runtime dependencies, meets satisficing metrics such as latency and model size (opens in a new tab), and passes interface tests against raw inputs and edge cases such as all features set to None. Live release then proceeds in fixed exposure order:
Remediation rebuilds quality through the same tracked workflow. Supervised tuning (opens in a new tab) supports BERT, T5, image-generation (GPU), and Gemini models, with multimodal rows assembled to include contents, systemInstruction, and image fileData with fileUri and mimeType. Teams check validity with assess_tuning_validity() and size cost with assess_tuning_resources() before a full run. Vertex ML Metadata and Model Registry tracking (opens in a new tab) links source code, pipeline runs, datasets, hyperparameters, transformed data, checkpoints, and evaluation results, so a regression traces to a specific data, code, or configuration change.
The detection and alerting lifecycle connects serving, monitoring, and remediation without blocking predictions. The Endpoint continues to serve on one side of the trust boundary while monitoring and remediation operate on the observability side. The lifecycle runs in order:
Execution errors surface as HTTP statuses that map cause to client action. A 400 INVALID_ARGUMENT means bad schema or exceeded file limits and requires fixing markers and bounds. A 403 PERMISSION_DENIED means missing role or license and requires credential checks. A 408 LOCK_TIMEOUT means the client exceeded execution duration and requires 30-minute timeouts and penalty scores to clear the lock. A 429 RESOURCE_EXHAUSTED means quota exhaustion and requires exponential backoff and lower concurrency. A 503 SERVICE_UNAVAILABLE means backend overload and requires randomized exponential backoff.
Common production failures divide by what is compared and whether ground truth is required. Vertex AI Model Monitoring (opens in a new tab) tracks training-serving skew, data drift, concept drift, and feature attribution drift by comparing live payloads to training or production baselines. Skew and drift need only input distributions, while concept drift needs predictions joined to delayed labels.
Skew and drift detection in BigQuery ML compares feature distributions using statistical distances such as Chebyshev distance and Jensen-Shannon divergence. Training-serving skew compares current serving data to training statistics saved at model creation, while data drift compares one serving span to another serving span over time.
| Detection type | Baseline compared from | Serving data compared to |
|---|---|---|
| Training-serving skew | Training statistics saved during model creation | Current serving payload |
| Data drift | Earlier serving data span | Later serving data span |
Basic monitoring uses SQL functions that move data from source tables to statistics outputs to validation results. ML.DESCRIBE_DATA computes descriptive statistics to verify datasets stay within expected parameters. ML.VALIDATE_DATA_SKEW compares serving statistics to saved training statistics. ML.VALIDATE_DATA_DRIFT compares two serving datasets, such as current data versus a snapshot or ML.FEATURES_AT_TIME output. The basic skew workflow runs describe, train, validate skew, then investigate and retrain, while the basic drift workflow runs describe, train, validate drift, then investigate and retrain.
Advanced monitoring uses TensorFlow Data Validation (TFDV) statistics stored as JSON protocol buffers for fine-grained control. ML.TFDV_DESCRIBE generates statistics with the same behavior as tfdv.generate_statistics_from_csv, results are saved with CURRENT_TIMESTAMP() in a table such as serve_stats, and ML.TFDV_VALIDATE compares two JSON objects in SKEW mode for training-to-serving or drift mode for serving-to-serving. A golden dataset representing the ideal distribution plus a TFDV schema anchors these comparisons, and batch skew metrics are written to Cloud Storage as metrics/skew/feature_skew.json.
Exam tip: Skew compares serving data to training statistics, while drift compares one serving span to another serving span; skew needs the training baseline and drift does not.
Feature attribution drift detects when the model relies on features differently than during training, even when raw inputs look stable. Vertex Explainable AI (opens in a new tab) attribution scores measure per-feature contribution for a single instance. A prediction request returns only the value, while an explanation request returns the prediction plus signed per-feature attributions that sum to the prediction score. Because attributions are always numeric, standard univariate drift detection applies even to embeddings and time series.
Attribution monitoring has two modes with different baselines:
| Mode | Baseline compared against | Production signal |
|---|---|---|
| Training-serving skew | Attributions from training data or batch explanation output in Cloud Storage or BigQuery | Production attribution deviates from training attribution |
| Prediction drift | Attributions from an earlier production window, no training data required | Production attribution changes significantly over time |
Prerequisites ensure the endpoint emits explanations and the job can parse them. The team provides the training baseline URI for skew, deploys a tabular AutoML model with automatic explanations or a custom tabular model configured so ExplanationSpec.ExplanationParameters is populated, and provides the analysis instance schema for custom models or the job stays pending until it parses the schema from the first 1000 requests. Interpretation tracks top features first because large drift in important features usually moves predictions, sums attributions across embedding dimensions and related groups such as grade, sub_grade, and purpose, and accounts for interactions that can shift attribution even when a marginal distribution is unchanged.
Concept drift is a shift in the relationship between inputs and the target where P(y|X) changes and the same features now require a different label. Concept drift cannot be confirmed from inputs alone because it requires joining logged predictions to delayed ground-truth labels. The serving system writes predictions to PROJECT_ID.model_deployment_monitoring_ENDPOINT_ID.serving_predict, the evaluation job compares them to the true target column, and a sustained drop in accuracy, precision, recall, F1-score, AUC-ROC, or increase in log loss signals drift.
| Monitoring type | What is compared | Ground truth required |
|---|---|---|
| Training-serving skew | Training versus live serving inputs | No |
| Data drift | Past versus current production inputs | No |
| Concept drift | Production predictions versus delayed labels | Yes |
| Feature attribution drift | Baseline versus current importance distributions | No, uses numeric attributions as early proxy |
The continuous architecture turns a distance into a versioned recovery. Prediction traffic flows from the Endpoint to the monitoring job, which samples at a configured rate on a frequency with minimum granularity of 1 hour and default of 24 hours. Logged data flows to BigQuery and Cloud Logging, derived metrics flow to Cloud Monitoring, and alerts flow to Pub/Sub channels such as email, Slack, SMS, and PagerDuty. Each feature has its own threshold, for example Age=0.4 alerts when distance exceeds 0.4, while batch monitoring defaults to 0.3 for categorical and numerical features. Remediation runs in order: detect and alert, notify through Pub/Sub, trigger an Agent Platform Pipelines retraining job on fresh BigQuery or Cloud Storage data, validate recall, precision, AuPRC, accuracy, and safety and register in Model Registry, then promote through canary release with immediate rollback to the last stable version by disabling the endpoint, pausing the pipeline, or restoring the prior version.
Generative AI monitoring combines output-quality scoring, serving telemetry, and safety controls into one feedback loop. The Gen AI evaluation service scores variable generative outputs, Cloud Monitoring and Model Monitoring track serving health and distribution shift, and responsible AI filters and injection detection block harmful or manipulated behavior. Together they detect when live behavior drifts from the definition of good output and route recovery through rollback, retraining, or prompt refinement.
The Gen AI evaluation service is the managed service for continuously scoring generative output that cannot be judged by accuracy alone. Production responses flow from the serving endpoint into scheduled evaluation jobs, metric streams flow into Cloud Logging and Cloud Monitoring, and threshold breaches trigger rollback or retraining. Automatic metrics cover response quality for relevance, safety for unsafe or biased content, instruction adherence, grounding to source, and writing style and verbosity.
A standardized pipeline makes scores comparable from prototype to production. Data flows from BigQuery for SQL-driven tasks or Cloud Storage for large datasets into the evaluation service, scores flow into ML Metadata for lineage, and drift signals flow into Pipelines for retraining. The pipeline is built in order: first define quantitative computation-based metrics and qualitative indicators tied to business goals, then choose golden datasets, auto-raters, and user feedback with sufficient volume for significance, then standardize execution so the same datasets, metrics, and raters run on every version.
| Evaluation type | How it is scored | Example use |
|---|---|---|
| Computation-based metrics | Numeric formula in the evaluation service | Recall, precision, AuPRC, ROUGE, BLEU |
| Qualitative indicators | LLM-as-a-judge auto-rater or human labeling | Fluency or entertainment value |
The evaluation dataset must reflect production traffic distribution or the pipeline optimizes for rare cases. A golden dataset provides trusted baseline samples for skew detection, LLM-as-a-judge provides a separate model to score quality and safety, and user feedback from production guides improvements. Grounding checks verify retrieval-augmented generation (RAG) factuality against provided source text during evaluation, while enabling grounding adds verification for live output.
Exam tip: Use Cloud Monitoring and the observability dashboard for operational signals such as queries per second, time to first token, latency, and error rate, and use Model Monitoring plus the Gen AI evaluation service for drift and quality signals such as grounding, safety, and instruction adherence.
Production observability for generative AI tracks serving behavior, generation quality, and infrastructure health from the user's perspective. Reliability goals (opens in a new tab) translate business key performance indicators into service-level objectives (SLOs) such as 99.9% successful API responses, 95th percentile inference latency below 300 ms, time to first token (TTFT) below 500 ms for 99% of requests, and harmful output below 0.1%. When an SLO breaches, the breach routes to scaling, rollback, or prompt revision.
Serving telemetry follows the four golden signals, each revealing a different failure. Latency covers response time including TTFT and streaming delay. Traffic covers request volume including queries per second and token rate. Error rate covers failed requests and low-confidence predictions. Saturation covers CPU, memory, GPU, and TPU utilization showing proximity to capacity limits. Generative AI application telemetry (opens in a new tab) spans Vertex AI endpoints, vLLM and NVIDIA Triton Inference Server via Google Cloud Managed Service for Prometheus (GMP), Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, TPUs, and GPUs with NVIDIA Data Center GPU Manager detail, while Cloud Trace maps distributed latency and Cloud Profiler finds code bottlenecks. Token counts link cost, quota burn, and speed, and quota risk is managed by forecasting utilization, load testing, alerting near limits, and requesting increases.
Drift and retrieval observability explains what changed. Model Monitoring compares live inputs and outputs to a golden baseline and TFDV schema to signal input drift, output drift, and attribution drift, with v2 supporting GKE self-hosted serving and model-level tracking. Dataflow telemetry tracks ingestion and transformation, Pipelines telemetry tracks retraining success, and Knowledge Catalog governs accuracy, freshness, completeness, validity, and consistency with lineage for traceability. RAG signals separate retrieval failure from generation failure through context relevance, groundedness, vector-database throughput, hallucination rates, toxicity scores, and user ratings. Alerts flow from log-based metrics and custom dashboards to severity-specific Pub/Sub channels, then drive a closed loop of detect, notify, respond with rollback or retraining, and improve prompts and retrieval.
Safety testing systematically probes generative applications for harmful, manipulated, or ungrounded outputs and blocks those failures in production. Security controls (opens in a new tab) split across inline filtering in the serving path, offline alignment scoring, and injection detection for agents that act on screens. Systematic red teaming probes for prompt injection, jailbreaking, data leakage, and hallucination, with Vertex AI safety thresholds enforcing compliance.
Inline responsible AI filtering screens responses before they reach the user. The application generates a response, loads it to BigQuery beside the serving path for offline review, passes it through responsible AI filters, and only then sends the screened response through the frontend. This creates two boundaries: the filter sits between model and user to block harm in real time, while BigQuery retains prompts and responses for later analysis of hallucinations and leakage.
Offline alignment scoring measures accuracy and relevance over time. Pub/Sub triggers a Cloud Run function, the function reads configuration and evaluation prompts from AlloyDB for PostgreSQL, scores serving responses for factual accuracy and relevance, and loads scores plus prompts and responses to BigQuery for analysis. Factual accuracy targets hallucination risk, while relevance targets alignment among prompt, retrieved grounding data, and answer.
Injection detection guards computer use agents that receive screenshots as input, where an attacker can embed instructions in screen content. The control is disabled by default and must be explicitly enabled with enable_prompt_injection_detection set to true in REST computer_use configuration or Python Tool(computer_use=ComputerUse(...)). Red-team categories include untrusted content and scams such as following a free-phone survey while purchasing a phone, occasional unintended actions such as clicking the wrong button, and policy violations such as bypassing CAPTCHAs or interfering with system integrity. Mitigation layers injection detection on inputs, responsible AI filtering on outputs, and BigQuery logging for review.
Continue with this study guide: Monitoring, testing, and evaluating gen AI solutions
Reliable production AI depends on linking statistical monitoring, operational telemetry, and versioned recovery. Tabular and generative systems share the same pattern of sampling live traffic, comparing it to training and production baselines, alerting through Cloud Monitoring and Pub/Sub, and remediating through pipelines and Model Registry, while generative workloads add auto-rated quality, token and retrieval signals, and inline safety boundaries for variable and adversarial outputs.
ML.VALIDATE_DATA_SKEW for skew, ML.VALIDATE_DATA_DRIFT for drift, and ML.TFDV_DESCRIBE with ML.TFDV_VALIDATE for fine-grained TensorFlow Data Validation statistics.Training-serving skew compares current serving payloads to training statistics saved during model creation, while data drift compares one serving span to another serving span over time. Skew catches pipeline bugs such as sending a product name instead of a product code and requires the training baseline, while drift catches changing world behavior and does not require training data.
Concept drift is a shift in the relationship between inputs and the target where the same features now require a different label and it cannot be confirmed from inputs alone because it requires joining logged predictions to delayed ground-truth labels. The serving system writes predictions to the serving predict table and the evaluation job compares them to the true target column, where a sustained drop in accuracy, precision, recall, F1-score or AUC-ROC or an increase in log loss signals drift.
Cloud Monitoring and the observability dashboard track operational signals such as queries per second, time to first token, latency and error rate, while Vertex AI Model Monitoring plus the Gen AI evaluation service track drift and quality signals such as grounding, safety and instruction adherence. The Gen AI evaluation service scores variable generative outputs for response quality, safety, instruction adherence, grounding to source and writing style, while Cloud Monitoring evaluates serving health and distribution-shift metrics against thresholds for alerting.
Last updated