Prepare data for AI and ML, including feature engineering, training and serving with BigQueryML, and preparing unstructured data for embeddings and retrieval-augmented generation (RAG).

A retail analytics team has a BigQuery ML logistic regression model that runs in production every hour. Over the last two weeks, log loss on incoming data has crept up and the team suspects that one categorical feature, product subcategory, has shifted its distribution because new subcategory codes are being assigned by a recent merchandising change. They want a repeatable way to detect this kind of feature drift between the training data and recent serving data using BigQuery ML built-in tooling. Which approach is most appropriate?

• ACall ML.TFDV_DESCRIBE on the training table and on the recent serving table, and use ML.VALIDATE_DATA_SKEW to compute Jensen-Shannon divergence and other skew statistics between the two datasets.check_circle Correct
• BRecreate the model every hour with the latest seven days of data and rely on the new evaluation metrics returned by ML.EVALUATE to surface drift indirectly.
• CUse ML.DESCRIBE_DATA on the training table and on the recent serving table separately, then write a SQL query that compares the standard deviation of every numeric column and flags differences above ten percent.
• DSchedule ML.GLOBAL_EXPLAIN nightly and trigger an alert whenever the global feature importance of product subcategory shifts by more than one decile compared with the prior week.

Why A is correct: ML.TFDV_DESCRIBE produces TensorFlow Data Validation statistics for a dataset, and ML.VALIDATE_DATA_SKEW compares two such snapshots feature by feature, surfacing per-feature divergence so the team can pinpoint that product subcategory has drifted between training and serving.

Why B is wrong: Continuous retraining masks drift rather than detecting it, and a falling ML.EVALUATE score gives no signal about which feature distribution shifted, so the team still has to diagnose the root cause manually after the model accuracy has already degraded.

Why C is wrong: ML.DESCRIBE_DATA gives column-level summary statistics but offers no built-in distributional comparison and cannot detect a shift in a categorical feature whose values are codes rather than numbers, which is exactly the team's situation.

Why D is wrong: ML.GLOBAL_EXPLAIN reports model-level feature importance, not data distribution. Importance can stay flat while the underlying feature distribution shifts, so this would miss many real drift events and is the wrong tool for the question.