Ngân hàng đề — Google Cloud Professional Machine Learning Engineer

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả tình huống huấn luyện một mô hình thị giác máy tính (computer vision model) để dự đoán loại giấy tờ tùy thân chính phủ (government ID) từ hình ảnh, sử dụng máy ảo GPU trên Compute Engine (dịch vụ máy ảo của Google Cloud). Các tham số huấn luyện cụ thể bao gồm:

• Optimizer: SGD (Stochastic Gradient Descent).
• Kích thước hình ảnh: 224×224 pixel.
• Batch size: 64 (số lượng mẫu dữ liệu xử lý cùng lúc).
• Epochs: 10 (số vòng lặp huấn luyện toàn bộ dataset).
• Verbose: 2 (mức độ chi tiết log).

Trong quá trình huấn luyện, gặp lỗi ResourceExhaustedError: Out Of Memory (OOM) when allocating tensor, nghĩa là bộ nhớ GPU bị cạn kiệt khi cố gắng cấp phát tensor (ma trận dữ liệu). Vấn đề phổ biến trong huấn luyện deep learning trên GPU hạn chế bộ nhớ (ví dụ: NVIDIA T4 hoặc A100 trên Compute Engine có VRAM từ 16-80GB tùy loại). Lỗi này xảy ra vì tổng bộ nhớ cần thiết cho batch dữ liệu, gradient, activations vượt quá dung lượng GPU.

📘 Tài liệu tham khảo:

• TensorFlow Troubleshooting OOM (cập nhật 2024).
• Google Cloud Compute Engine GPU docs (phiên bản 2025-2026, hỗ trợ GPU Blackwell B200).
• Vertex AI Training OOM best practices (cập nhật mới nhất).

✅ Đáp án đúng: Reduce the batch size

Lý do lựa chọn: Batch size=64 quá lớn so với kích thước hình ảnh 224×224 và kiến trúc mô hình computer vision (thường như ResNet/CNN với activations lớn). Giảm batch size (ví dụ: xuống 32 hoặc 16) sẽ giảm đáng kể bộ nhớ sử dụng cho forward/backward pass, activations và gradient accumulation. Đây là giải pháp trực tiếp và hiệu quả nhất cho lỗi OOM mà không ảnh hưởng lớn đến chất lượng mô hình (có thể dùng gradient accumulation để bù đắp). Theo best practices TensorFlow/Keras trên Google Cloud, batch size là yếu tố chính gây OOM.
🛠️ Mẹo thực tế: Sử dụng tf.data với prefetch hoặc Vertex AI hyperparameter tuning để tự động tối ưu.

📋 Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên tác động đến bộ nhớ GPU và lỗi OOM cụ thể:

• [SAI] Change the optimizer.
  ❌ Sai vì: Thay đổi optimizer (từ SGD sang Adam/RMSprop) chỉ ảnh hưởng đến cách cập nhật trọng số (momentum, adaptive LR), không giảm bộ nhớ tensor allocation. OOM xảy ra ở giai đoạn allocate tensor cho batch data/activations, không liên quan optimizer. Thậm chí Adam dùng thêm memory cho momentum states, có thể tệ hơn.

• [ĐÚNG] Reduce the batch size.
  ✅ Đúng vì: Batch size trực tiếp quyết định kích thước tensor input/gradient (tỷ lệ thuận với memory usage). Với batch=64 và image 224×224×3 (RGB), memory ~ batch × height × width × channels × sizeof(float32) + overhead activations (~4-10x input size). Giảm batch giải quyết ngay OOM, phổ biến trong huấn luyện CV trên Compute Engine GPU.

• [SAI] Change the learning rate.
  ❌ Sai vì: Learning rate chỉ điều chỉnh tốc độ hội tụ (step size cho weight update), hoàn toàn không ảnh hưởng đến bộ nhớ cấp phát tensor. Lỗi OOM là vấn đề hardware memory, không phải hyperparameter convergence.

• [SAI] Reduce the image shape.
  ❌ Sai vì: Giảm image shape (từ 224×224 xuống 128×128) sẽ giảm memory (~4x nhỏ hơn), nhưng không phải giải pháp tối ưu nhất ở đây. Batch size là nguyên nhân chính với các param khác fixed; thay đổi shape ảnh hưởng lớn đến độ chính xác mô hình (CV cần resolution cao cho ID detection). Nên thử batch size trước, shape là option phụ.

🧩 Tóm tắt khuyến nghị: Nếu vẫn OOM sau giảm batch, kết hợp mixed precision (tf.keras.mixed_precision) hoặc distributed training trên Vertex AI (cập nhật 2025 hỗ trợ TPU v5p). Tránh các thay đổi không cần thiết để giữ hiệu suất mô hình!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống bạn đã phát triển một mô hình ML trên AI Platform (nay là Vertex AI) của Google Cloud, và muốn đưa vào production. Hệ thống đang phục vụ vài nghìn queries per second (QPS), nhưng gặp vấn đề latency cao (độ trễ cao). Các request đến qua load balancer, phân phối đến nhiều Kubeflow CPU-only pods chạy trên Google Kubernetes Engine (GKE).

Mục tiêu chính: Cải thiện serving latency (độ trễ khi phục vụ inference) mà không thay đổi hạ tầng cơ bản (không thêm GPU, không scale pods, không thay đổi GKE cluster).

🛠️ Bối cảnh kỹ thuật (dựa trên kiến thức GCP cập nhật đến 2026):

• Kubeflow trên GKE dùng TensorFlow Serving để deploy mô hình ML.
• CPU-only pods nghĩa là không dùng accelerator (GPU/TPU), nên cần tối ưu hóa CPU để xử lý high-throughput (few thousand QPS).
• Load balancer (có thể là Google Cloud Load Balancer) phân phối traffic đều.
• Vấn đề latency thường do: batching kém, queue dài, hoặc CPU không tối ưu (không dùng instruction sets hiện đại như AVX512).

📘 Tài liệu tham khảo:

• TensorFlow Serving Guide (cập nhật 2025).
• GKE CPU Optimization Docs (phiên bản 2026 hỗ trợ baseline CPU platforms như Intel Cascade Lake hoặc AMD EPYC).
• Kubeflow Serving on GKE (v2.10+ tích hợp TF Serving optimizations).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Recompile TensorFlow Serving using the source to support CPU-specific optimizations. Instruct GKE to choose an appropriate baseline minimum CPU platform for serving nodes.

Lý do chọn 🏆:

• Recompile TF Serving từ source cho phép bật CPU-specific optimizations (như AVX2/AVX512, SSE4, Intel MKL hoặc oneDNN), giúp inference nhanh hơn 2-5x trên CPU mà không cần GPU. Đây là cách tối ưu chuẩn cho high-QPS CPU serving.
• Instruct GKE chọn baseline minimum CPU platform (ví dụ: intel-cascadelake hoặc amd-epyc-rome qua node selector hoặc machine type) đảm bảo pods chạy trên CPU hiện đại hỗ trợ vector instructions, giảm latency đáng kể.
• Không thay đổi infra: Chỉ recompile binary và config GKE node affinity, giữ nguyên CPU-only pods. Phù hợp với few thousand QPS (typical cho CPU-optimized serving).
• Kết quả: Latency giảm mà throughput tăng, theo benchmarks TF Serving 2.15+ (2025).

❌ Phân tích tất cả các phương án (đúng/sai)

Dưới đây là giải thích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do chi tiết bằng tiếng Việt dựa trên docs mới nhất.

• [SAI] Significantly increase the max_batch_size TensorFlow Serving parameter.
  ❌ Sai vì: Tăng max_batch_size (mặc định 16-32) làm batch lớn hơn, tăng thời gian xử lý mỗi batch (do padding hoặc serialization), dẫn đến latency cao hơn thay vì giảm. Phù hợp cho low-QPS, nhưng với few thousand QPS sẽ gây bottleneck queue và OOM. (TF Serving config guide 2025 khuyên giữ nhỏ cho low-latency).

• [SAI] Switch to the tensorflow-model-server-universal version of TensorFlow Serving.
  ❌ Sai vì: Không tồn tại official version tensorflow-model-server-universal trong TF Serving (2.16+ 2026). Đây có thể là nhầm lẫn với custom builds hoặc OSS forks, nhưng không giải quyết latency CPU. Sử dụng official Docker image từ GCR đã đủ, và switch version không tối ưu CPU-specific.

• [SAI] Significantly increase the max_enqueued_batches TensorFlow Serving parameter.
  ❌ Sai vì: max_enqueued_batches (mặc định 1000) kiểm soát queue batches chờ xử lý. Tăng nó chỉ tăng queue length, làm request chờ lâu hơn (tail latency tăng), không cải thiện processing speed. Với high QPS, cần giảm queue bằng optimize CPU, không phải mở rộng queue (dẫn đến memory spike).

• [ĐÚNG] Recompile TensorFlow Serving using the source to support CPU-specific optimizations. Instruct GKE to choose an appropriate baseline minimum CPU platform for serving nodes.
  ✅ Đúng vì: Như giải thích ở trên. Đây là best practice cho CPU-only serving trên GKE (Kubeflow v2.10+). Recompile với flags như -march=native hoặc -mavx512f, kết hợp GKE --min-cpu-platform (docs 2026 hỗ trợ auto-selection), giảm latency 30-50% cho Transformer models.

🧠 Lời khuyên thực tế: Test với tf-serving-benchmark tool trên GKE cluster. Nếu QPS >10k, cân nhắc Vertex AI Prediction sau (serverless, auto-optimize CPU/GPU). Nếu cần hỗ trợ thêm, cung cấp logs latency! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả một pipeline dự báo nhu cầu (demand forecasting) đang chạy production trên Google Cloud Platform (GCP). Pipeline sử dụng Dataflow (dựa trên Apache Beam) để tiền xử lý dữ liệu thô trước khi huấn luyện mô hình và dự đoán. Cụ thể, trong bước tiền xử lý, áp dụng Z-score normalization (chuẩn hóa Z-score: ( z = \frac{x - \mu}{\sigma} ), với (\mu) là trung bình và (\sigma) là độ lệch chuẩn) trên dữ liệu lưu trữ trong BigQuery, sau đó ghi kết quả trở lại BigQuery. Dữ liệu huấn luyện mới được thêm hàng tuần.

Mục tiêu: Làm cho quy trình hiệu quả hơn bằng cách giảm thời gian tính toán (computation time) và giảm can thiệp thủ công (manual intervention).

Vấn đề hiện tại: Sử dụng Dataflow để đọc dữ liệu từ BigQuery, tính toán normalization, rồi ghi lại → Tốn tài nguyên (ETL pipeline chạy trên cluster), thời gian I/O lớn (đọc/ghi BigQuery), và cần quản lý job Dataflow định kỳ. Giải pháp lý tưởng phải tận dụng tính serverless của BigQuery để xử lý trực tiếp trong SQL, tránh ETL ngoài.

(Kiến thức cập nhật đến 2026: BigQuery hỗ trợ SQL chuẩn hóa nâng cao với window functions, UDF, và ML functions như ML.STANDARDIZE cho normalization tự động – xem docs GCP mới nhất).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Translate the normalization algorithm into SQL for use with BigQuery.

Lý do:

• Z-score normalization có thể dễ dàng triển khai bằng SQL thuần trong BigQuery (sử dụng AVG(), STDDEV() với window functions hoặc subqueries để tính mean/std theo nhóm, sau đó apply công thức).
• Lợi ích: Xử lý trực tiếp trong BigQuery (serverless, auto-scale), không cần Dataflow → Giảm computation time (query BigQuery nhanh hơn ETL 5-10x cho dữ liệu lớn), không manual intervention (chạy scheduled query qua Cloud Scheduler hoặc Airflow).
• Hàng tuần chỉ cần chạy một query SQL để cập nhật dữ liệu mới → Tối ưu chi phí và hiệu suất.
  (Ví dụ SQL đơn giản: SELECT *, (col - AVG(col) OVER()) / STDDEV(col) OVER() AS z_score FROM table – hỗ trợ partitioning/clustering để nhanh hơn).

🛠️ Giải thích tất cả các phương án (đúng/sai)

• ❌ [SAI] Normalize the data using Google Kubernetes Engine.
  Phương án này sai vì Google Kubernetes Engine (GKE) là dịch vụ quản lý container orchestration (Kubernetes), dùng cho ứng dụng microservices hoặc batch jobs phức tạp, không phù hợp để normalize dữ liệu BigQuery. Nó yêu cầu deploy container thủ công, quản lý pod, scaling → Tăng manual intervention và computation time (cần connector đọc/ghi BigQuery), không giải quyết vấn đề cốt lõi. Không hiệu quả hơn Dataflow.

• ✅ [ĐÚNG] Translate the normalization algorithm into SQL for use with BigQuery.
  (Như đã giải thích ở trên) – Phương án tối ưu nhất, tận dụng SQL engine mạnh mẽ của BigQuery (hỗ trợ UDF JavaScript/Python cho logic phức tạp nếu cần). Giảm I/O, serverless, scheduled dễ dàng → Đúng yêu cầu "minimizing computation time and manual intervention".

• ❌ [SAI] Use the normalizer_fn argument in TensorFlow's Feature Column API.
  Phương án này sai vì normalizer_fn trong TensorFlow FeatureColumn chỉ áp dụng tại thời điểm training/inference (chuẩn hóa on-the-fly trong mô hình), không preprocess và ghi dữ liệu trở lại BigQuery. Nó không xử lý dữ liệu thô hàng tuần, vẫn cần Dataflow cho bước trước → Không giảm computation/manual ở preprocessing pipeline.

• ❌ [SAI] Normalize the data with Apache Spark using the Dataproc connector for BigQuery.
  Phương án này sai vì Apache Spark trên Dataproc (serverless Spark) với connector BigQuery vẫn là ETL job tương tự Dataflow (đọc → normalize → ghi), chỉ thay engine → Không giảm đáng kể computation time (vẫn I/O lớn, cần khởi tạo cluster), tăng manual (quản lý Spark job). Dataproc phù hợp big data phức tạp hơn, nhưng ở đây SQL đơn giản hơn nhiều.

📘 Tài liệu tham khảo

• BigQuery SQL cho normalization: BigQuery SQL Reference - Aggregate Functions & ML.STANDARDIZE (cập nhật 2025+).
• Dataflow vs BigQuery optimization: Best Practices for ML Pipelines on GCP.
• Scheduled Queries: BigQuery Scheduled Queries.
  (Nguồn: Official GCP Documentation, cập nhật Q1 2026).

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào việc thiết kế một mạng nơ-ron sâu tùy chỉnh (customized deep neural network) bằng Keras để dự đoán hành vi mua hàng của khách hàng dựa trên lịch sử mua sắm. Yêu cầu chính bao gồm:

• 🔍 Khám phá hiệu suất mô hình với nhiều kiến trúc mô hình khác nhau (multiple model architectures).
• 💾 Lưu trữ dữ liệu huấn luyện (store training data).
• 📊 So sánh các chỉ số đánh giá (evaluation metrics) trên cùng một bảng điều khiển (dashboard) duy nhất.
  Đây là tình huống điển hình trong quy trình MLOps trên Google Cloud, nơi cần tổ chức các thử nghiệm (experiments) để theo dõi và so sánh nhiều lần chạy mô hình một cách hiệu quả. Câu hỏi nhấn mạnh nhu cầu về tính tổ chức, theo dõi và trực quan hóa trong môi trường tùy chỉnh Keras, không phải AutoML tự động.

✅ Đáp án đúng và lý do lựa chọn

Create an experiment in Kubeflow Pipelines to organize multiple runs.

🛠️ Lý do chọn đáp án này:
Kubeflow Pipelines (nay tích hợp sâu trong Vertex AI Pipelines đến năm 2026) là công cụ lý tưởng để tạo experiment – một không gian tổ chức riêng biệt cho nhiều lần chạy pipeline (runs). Nó cho phép:

• Chạy nhiều kiến trúc mô hình Keras tùy chỉnh song song hoặc tuần tự.
• Tự động lưu trữ dữ liệu huấn luyện, artifacts (như models, datasets) vào Metadata Store.
• So sánh metrics (accuracy, loss, etc.) trực tiếp trên dashboard tích hợp với biểu đồ, bảng so sánh, và tracking lịch sử.
  Điều này phù hợp hoàn hảo với yêu cầu "explore model performance... compare evaluation metrics in the same dashboard". Kubeflow hỗ trợ Keras/TensorFlow native và scale trên GKE.
  📘 Tài liệu tham khảo: Kubeflow Pipelines Documentation & Vertex AI Pipelines Experiments (cập nhật 2025-2026).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, với nội dung gốc giữ nguyên tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên tính phù hợp với yêu cầu tùy chỉnh Keras, tổ chức runs và dashboard so sánh.

• ❌ Create multiple models using AutoML Tables.
  Phương án này sai vì AutoML Tables (nay là Vertex AI AutoML Tabular đến 2026) chỉ hỗ trợ tự động hóa (AutoML) cho dữ liệu bảng, không cho phép tùy chỉnh deep neural network bằng Keras. Nó không lưu trữ training data linh hoạt hay cung cấp dashboard so sánh nhiều architectures thủ công – chỉ tạo một mô hình tốt nhất, không explore multiple runs.

• ❌ Automate multiple training runs using Cloud Composer.
  Phương án này sai vì Cloud Composer (dựa trên Apache Airflow) là công cụ orchestration workflow chung, không chuyên cho ML experiments. Nó có thể tự động hóa runs nhưng không có dashboard tích hợp để so sánh metrics hay tổ chức experiments cho Keras models. Phù hợp hơn cho ETL/data pipeline, không phải model exploration.

• ❌ Run multiple training jobs on AI Platform with similar job names.
  Phương án này sai vì AI Platform (nay là Vertex AI Training đến 2026) hỗ trợ chạy jobs tùy chỉnh Keras, nhưng chỉ dùng tên job tương tự không tạo được organization hay dashboard so sánh metrics tự động. Metrics phải export thủ công (qua TensorBoard hoặc custom logging), thiếu tính năng experiment tracking liền mạch.

• ✅ Create an experiment in Kubeflow Pipelines to organize multiple runs.
  Như đã giải thích ở trên, đây là lựa chọn đúng nhất vì trực tiếp đáp ứng tất cả yêu cầu: tùy chỉnh Keras, multiple architectures, lưu trữ data, và dashboard so sánh metrics. Kubeflow Experiments cung cấp metadata tracking đầy đủ, scale cao trên GKE/Vertex AI.

🧠 Tóm tắt lợi ích Kubeflow: Trong phiên bản mới nhất (v2.6+ đến 2026), nó tích hợp MLflow-like tracking, hỗ trợ hyperparameter tuning và reproducibility – vượt trội các lựa chọn khác!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc phát triển một Kubeflow Pipeline chạy trên Google Kubernetes Engine (GKE). 🛤️ Bước đầu tiên của pipeline là thực hiện một truy vấn (query) đối với BigQuery, và kết quả của truy vấn này sẽ được sử dụng làm đầu vào cho bước tiếp theo trong pipeline. Mục tiêu là đạt được điều này một cách dễ dàng nhất có thể (easiest way possible).

📌 Bối cảnh kỹ thuật: Kubeflow Pipelines là một phần của Kubeflow, giúp xây dựng, triển khai và quản lý các ML workflows dưới dạng các bước (steps/components) có thể tái sử dụng. Để kết nối BigQuery với pipeline một cách mượt mà, cần một component sẵn có hỗ trợ input/output artifacts, tránh phải code từ đầu. Kiến thức cập nhật đến năm 2026: Kubeflow Pipelines v2.6+ (tích hợp sâu với Google Cloud) vẫn duy trì các pre-built components trên GitHub để tối ưu hóa sự đơn giản và tính tái sử dụng.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Locate the Kubeflow Pipelines repository on GitHub. Find the BigQuery Query Component, copy that component's URL, and use it to load the component into your pipeline. Use the component to execute queries against BigQuery.

Lý do: 🏆 Đây là cách dễ dàng nhất vì Kubeflow Pipelines cung cấp sẵn BigQueryQueryComponentOp (một component pre-built) trong kho lưu trữ GitHub chính thức. Bạn chỉ cần copy URL của component (ví dụ: từ https://github.com/kubeflow/pipelines/blob/master/components/google-cloud/bigquery/query/) và load trực tiếp vào pipeline bằng Kubeflow SDK (Python DSL). Component này tự động xử lý query BigQuery, lưu kết quả dưới dạng artifact (như Table hoặc JSON), dễ dàng truyền cho bước sau mà không cần viết code custom. Điều này tuân thủ nguyên tắc "reuse existing components" của Kubeflow, giảm thời gian phát triển và lỗi.

Nguồn tham khảo:

• 📘 Kubeflow Pipelines Components - BigQuery Query (cập nhật mới nhất 2025).
• 📘 Google Cloud Docs: Kubeflow on GKE.

🔍 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên văn bản gốc bằng tiếng Anh cho các phương án, chỉ giải thích bằng tiếng Việt với emoji để dễ theo dõi:

• ❌ Phương án SAI 1: Use the BigQuery console to execute your query, and then save the query results into a new BigQuery table.
  Giải thích sai: 🛑 Cách này thủ công và không tự động hóa được trong pipeline. Bạn phải chạy query thủ công trên console BigQuery, tạo bảng mới, rồi tham chiếu bảng đó trong pipeline – không phải "first step" thực sự của pipeline, mà chỉ là bước chuẩn bị ngoài. Không dễ dàng vì thiếu tích hợp động (dynamic query) và không truyền artifact trực tiếp giữa các bước Kubeflow.

• ❌ Phương án SAI 2: Write a Python script that uses the BigQuery API to execute queries against BigQuery. Execute this script as the first step in your Kubeflow pipeline.
  Giải thích sai: 🛠️ Mặc dù có thể thực hiện, nhưng phải viết script từ đầu sử dụng BigQuery API (hoặc client library), containerize nó thành container op, và định nghĩa input/output. Điều này phức tạp hơn, tốn thời gian debug authentication (Service Account), và không tận dụng component sẵn có – vi phạm yêu cầu "easiest way".

• ❌ Phương án SAI 3: Use the Kubeflow Pipelines domain-specific language to create a custom component that uses the Python BigQuery client library to execute queries.
  Giải thích sai: 🔧 Tương tự phương án 2, bạn phải tự xây dựng custom component bằng Kubeflow DSL/Python, bao gồm executor, base image, và metadata YAML. Dù linh hoạt, nhưng không phải cách dễ nhất vì đòi hỏi code nhiều (khoảng 50-100 dòng), test, và maintain – trong khi Kubeflow đã có component sẵn tương đương.

• ✅ Phương án ĐÚNG: Locate the Kubeflow Pipelines repository on GitHub. Find the BigQuery Query Component, copy that component's URL, and use it to load the component into your pipeline. Use the component to execute queries against BigQuery.
  Giải thích đúng: 🎯 Như đã nêu ở phần đáp án đúng, đây là lựa chọn tối ưu nhờ tái sử dụng component chính thức, chỉ cần 2-3 dòng code load URL. Hỗ trợ SQL query động qua input params, output là BigQuery Table artifact, dễ chain với bước sau (ví dụ: Dataflow hoặc TFJob). Hoàn hảo cho GKE + Kubeflow v2.x (2026).

Kết luận: 🌟 Chọn component sẵn từ GitHub giúp pipeline scalable, maintainable, và nhanh chóng triển khai trên GKE. Nếu cần tùy chỉnh sâu, mới dùng custom components!

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi mô tả tình huống xây dựng mô hình dự đoán nhiệt độ hàng ngày (daily temperatures), sử dụng dữ liệu được tải lên hàng giờ (hourly). Bạn đã chia dữ liệu ngẫu nhiên (random split) giữa tập huấn luyện (training) và tập kiểm tra (test), sau đó chuyển đổi (transform) riêng biệt cho từng tập. Kết quả kiểm tra đạt 97% độ chính xác, nhưng khi triển khai sản xuất (production), độ chính xác rơi xuống 66%. Vấn đề cốt lõi là mô hình hoạt động kém ở môi trường thực tế, và bạn cần xác định cách cải thiện độ chính xác ở production.

🛠️ Nguyên nhân chính: Đây là dữ liệu chuỗi thời gian (time series), nơi dữ liệu có tính phụ thuộc thời gian (temporal dependency). Việc split ngẫu nhiên gây data leakage (rò rỉ dữ liệu tương lai vào training), dẫn đến mô hình "gian lận" trên test set (vì test set lẫn lộn quá khứ/tương lai). Ở production, dữ liệu mới đến theo thời gian thực (hourly upload), không giống với training, gây distribution shift (sự thay đổi phân phối). Giải pháp cần tập trung vào temporal split để mô phỏng thực tế production.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Split the training and test data based on time rather than a random split to avoid leakage.

Lý do: ✅ Việc chia dữ liệu theo thời gian (temporal split, ví dụ: training dùng dữ liệu cũ, test dùng dữ liệu mới hơn) tránh data leakage bằng cách đảm bảo training chỉ dùng dữ liệu quá khứ, test dùng tương lai – giống như production dự đoán dữ liệu mới. Random split trộn lẫn thời gian, làm test set "dễ đoán" (97% accuracy giả tạo). Theo best practices AWS SageMaker (cập nhật 2025-2026), temporal split là tiêu chuẩn cho time series để giảm model drift và cải thiện production accuracy lên đáng kể (có thể từ 66% lên gần 90%+ tùy case).

🔍 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do chi tiết bằng tiếng Việt:

• [SAI] Normalize the data for the training, and test datasets as two separate steps.
  ❌ Sai vì: Normalize riêng biệt (hai bước độc lập) có thể gây inconsistent scaling giữa training/test/production, dẫn đến distribution shift lớn hơn. Best practice là fit scaler trên training rồi apply cho test/production (single pipeline). Vấn đề chính ở đây không phải normalize, mà là data leakage từ random split – normalize riêng chỉ làm tình hình tệ hơn ở production.

• [ĐÚNG] Split the training and test data based on time rather than a random split to avoid leakage.
  ✅ Đúng vì: Temporal split giải quyết gốc rễ vấn đề: tránh rò rỉ thông tin tương lai vào training, đảm bảo test set đại diện cho production (dữ liệu mới theo thời gian). AWS Processing Jobs và SageMaker Canvas (phiên bản 2026) hỗ trợ time-based splits tự động cho time series, giúp accuracy production ổn định và phát hiện drift sớm qua Amazon Model Monitor.

• [SAI] Add more data to your test set to ensure that you have a fair distribution and sample for testing.
  ❌ Sai vì: Thêm dữ liệu vào test set chỉ làm test set lớn hơn, nhưng không giải quyết data leakage từ random split (test vẫn lẫn thời gian). Production vẫn gặp dữ liệu mới ngoài phân phối training. Tập trung cải thiện test size không giúp, vì 97% accuracy test đã "giả" – cần fix upstream (split method). AWS khuyên dùng hold-out set theo thời gian thay vì tăng size ngẫu nhiên.

• [SAI] Apply data transformations before splitting, and cross-validate to make sure that the transformations are applied to both the training and test sets.
  ❌ Sai vì: Transform trước split gây severe data leakage (test set "biết" thông tin toàn bộ dataset, bao gồm tương lai). Cross-validation (CV) trên time series cần time-series CV (không dùng k-fold random), nhưng cách này vẫn không fix random split gốc. AWS SageMaker Feature Store (2026) khuyến cáo transform sau temporal split để tránh leakage.

📚 Tài liệu tham khảo (cập nhật AWS 2025-2026)

• AWS SageMaker Documentation: "Handling Time Series Data" – Time-Based Splitting (nhấn mạnh avoid random splits).
• AWS ML Best Practices: "Prevent Data Leakage" – Whitepaper on Model Drift.
• Amazon Model Monitor (2026 update): Phát hiện distribution shift ở production cho time series.

🛠️ Khuyến nghị thực tế: Sử dụng AWS SageMaker Canvas hoặc Processing Jobs để implement temporal split + pipeline transform thống nhất, kết hợp Model Monitor theo dõi drift!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống: Bạn đang phát triển các mô hình phân loại email hỗ trợ khách hàng bằng TensorFlow Estimators trên hệ thống on-premises với dữ liệu nhỏ. Bây giờ, bạn cần huấn luyện trên dữ liệu lớn để đạt hiệu suất cao, và muốn chuyển sang Google Cloud với tối thiểu thay đổi code (minimize code refactoring) và giảm overhead hạ tầng (infrastructure overhead). Mục tiêu là dễ dàng migrate từ on-prem sang cloud.

🛠️ Yêu cầu chính:

• Hỗ trợ distributed training cho TensorFlow Estimators.
• Ít chỉnh sửa code nhất (Estimators có API đơn giản, cloud-native).
• Không cần quản lý hạ tầng phức tạp (serverless hoặc managed service).

📘 Kiến thức cập nhật (Vertex AI - AI Platform, 2026): AI Platform (nay tích hợp vào Vertex AI) hỗ trợ TensorFlow Estimators với distribution strategies (như tf.estimator.train_and_evaluate với MirroredStrategy hoặc MultiWorkerMirroredStrategy), chỉ cần thêm tham số --job-dir và submit job mà không refactor lớn. Đây là lựa chọn tối ưu cho migration nhanh từ on-prem.

Nguồn tham khảo:

• Vertex AI Training Documentation (cập nhật 2025-2026).
• TensorFlow Estimators on Vertex AI.

✅ Đáp án đúng: Use AI Platform for distributed training

Lý do lựa chọn:

• AI Platform (Vertex AI Training) được thiết kế dành riêng cho ML training với TensorFlow Estimators, hỗ trợ distributed training tự động (multi-GPU/TPU/multi-node) chỉ bằng cách chỉ định distribution strategy trong code Estimator.
• Minimize code refactoring: Chỉ cần thay --job-dir thành GCS path và submit job qua gcloud ai-platform jobs submit training.
• No infrastructure overhead: Fully managed, autoscaling, hyperparameter tuning tích hợp.
• Phù hợp migrate on-prem: Estimators chạy nguyên vẹn từ local sang cloud mà không cần container hóa hay Kubernetes.

📋 Giải thích tất cả các phương án

• Use AI Platform for distributed training
  ✅ Đúng: Như phân tích trên, đây là giải pháp managed, native hỗ trợ Estimators với distributed strategies (e.g., tf.distribute.MirroredStrategy), zero-infra management. Migration nhanh chỉ vài dòng code thay đổi.

• Create a cluster on Dataproc for training
  ❌ Sai: Dataproc là dịch vụ cho Spark/Hadoop big data processing, không phải ML training native. Bạn phải tự viết Spark MLlib hoặc containerize Estimators, dẫn đến code refactoring lớn và overhead cao (quản lý cluster Spark). Không tối ưu cho TensorFlow.

• Create a Managed Instance Group with autoscaling
  ❌ Sai: MIG (Managed Instance Groups) chỉ cung cấp compute instances autoscaling cơ bản (như Compute Engine), bạn phải tự install TensorFlow, set up distributed training (MPI/SSH), và quản lý hạ tầng thủ công. Refactoring code nhiều (thêm orchestration) và overhead cao, không dành cho ML.

• Use Kubeflow Pipelines to train on a Google Kubernetes Engine cluster
  ❌ Sai: Kubeflow yêu cầu containerize mô hình (Docker + Kubernetes YAML), refactor Estimators thành Kubeflow components/pipelines. Overhead hạ tầng lớn (quản lý GKE cluster), không minimal cho migration đơn giản từ on-prem Estimators.

🧠 Tóm tắt so sánh nhanh:

• ✅ AI Platform: Managed ML, Estimators-native, low-code/low-infra.
• ❌ Các lựa chọn khác: Tự quản lý hạ tầng, refactor cao, không chuyên ML.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần ví dụ code, hỏi thêm nhé!

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào quy trình batch prediction (dự đoán hàng loạt) cho một mô hình phân loại văn bản (text classification model) đã được huấn luyện bằng TensorFlow trên AI Platform (nay là Vertex AI trên Google Cloud).
📊 Yêu cầu chính:

• Dữ liệu đầu vào là văn bản lưu trữ trong BigQuery.
• Mục tiêu: Thực hiện dự đoán mà tối thiểu hóa computational overhead (giảm thiểu chi phí tính toán, tránh di chuyển dữ liệu lớn, tận dụng tài nguyên trực tiếp trên BigQuery).
  🛠️ Bối cảnh: Đây là tình huống phổ biến trong ML pipeline trên Google Cloud, nơi cần tích hợp mượt mà giữa Vertex AI và BigQuery để xử lý dữ liệu lớn mà không cần export dữ liệu ra ngoài, giúp tiết kiệm thời gian và chi phí.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Export the model to BigQuery ML.

Lý do chi tiết:

• BigQuery ML (BQML) cho phép import/export mô hình TensorFlow đã train trực tiếp vào BigQuery thông qua lệnh CREATE MODEL với tùy chọn FROM chỉ đến SavedModel trong Cloud Storage.
• Sau khi export, bạn có thể chạy batch prediction ngay trong BigQuery bằng SQL query như ML.PREDICT(MODEL your_model, TABLE your_data), tận dụng engine phân tán của BigQuery để xử lý dữ liệu lớn mà không cần di chuyển data (in-place prediction).
• ✅ Tối ưu overhead: Không cần provisioning compute riêng, không export data sang GCS/Dataflow, chi phí chỉ tính theo query BigQuery (rẻ hơn nhiều so với Vertex AI Batch Prediction hoặc Dataflow).
• Phù hợp cập nhật 2026: Vertex AI hỗ trợ seamless export sang BQML từ phiên bản TensorFlow 2.x+ (xem BigQuery ML docs 2024+).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên khả năng đáp ứng yêu cầu (batch pred trên BigQuery data, minimize overhead).

✅ Export the model to BigQuery ML.

• Đúng và tối ưu nhất 🏆: Như đã giải thích, BQML tích hợp native với BigQuery, hỗ trợ import TensorFlow SavedModel cho custom models (text classification). Prediction chạy trực tiếp bằng SQL, zero data movement, overhead thấp nhất. Lý tưởng cho dữ liệu lớn trong BQ.

❌ Deploy and version the model on AI Platform.

• Sai: Đây là cách deploy cho online prediction (real-time serving) qua endpoint Vertex AI, không phù hợp batch trên BigQuery. Phải export data từ BQ sang GCS trước, tăng overhead lớn (data transfer + serving compute). Không minimize chi phí.

❌ Use Dataflow with the SavedModel to read the data from BigQuery.

• Sai: Dataflow (Apache Beam) có thể dùng custom transform với TensorFlow SavedModel để batch pred, nhưng yêu cầu pipeline ETL đầy đủ: đọc BQ → load model → predict → ghi output. Overhead cao (provision Dataflow workers, data shuffling), phức tạp hơn BQML nhiều lần. Không hiệu quả cho pure prediction.

❌ Submit a batch prediction job on AI Platform that points to the model location in Cloud Storage.

• Sai: Vertex AI Batch Prediction mạnh mẽ cho scale lớn, nhưng bắt buộc input data ở GCS (phải export từ BQ trước). Tạo job riêng với compute quota, chi phí cao hơn (CPU/GPU hours), không tận dụng BigQuery native. Overhead data movement làm mất lợi thế minimize compute.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• BigQuery ML Export TensorFlow Models: cloud.google.com/bigquery/docs/bqml-import-tensorflow (hỗ trợ TF 2.15+).
• Vertex AI Batch Prediction: cloud.google.com/vertex-ai/docs/predictions/batch-predictions (yêu cầu GCS input).
• AI Platform to Vertex AI Migration: cloud.google.com/vertex-ai/docs/migrate (AI Platform legacy nhưng tương thích).
• BQML Prediction SQL: cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-syntax-predict.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần demo code SQL, hãy hỏi thêm.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một tình huống thực tế trong quy trình Machine Learning trên Google Cloud Platform (GCP):

• Bạn làm việc với team data engineering đã xây dựng pipeline để làm sạch dữ liệu và lưu vào Cloud Storage bucket.
• Bạn đã tạo một mô hình ML và muốn refresh model ngay khi có dữ liệu mới (real-time hoặc near real-time).
• Là phần của CI/CD workflow, bạn cần tự động chạy Kubeflow Pipelines training job trên Google Kubernetes Engine (GKE).

Mục tiêu chính: Thiết kế kiến trúc workflow tự động, hiệu quả, event-driven (kích hoạt ngay khi file mới xuất hiện trong bucket), tránh lãng phí tài nguyên và đảm bảo scalability. Đây là best practice cho MLOps trên GCP, tận dụng các dịch vụ serverless để trigger job mà không cần polling thủ công.

📘 Tài liệu tham khảo:

• Cloud Storage event notifications với Pub/Sub (cập nhật 2024-2026).
• Kubeflow Pipelines trên GKE (phiên bản 2.x+).
• Cloud Functions trigger bởi Pub/Sub (hỗ trợ Gen2 Functions đến 2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng:
Configure a Cloud Storage trigger to send a message to a Pub/Sub topic when a new file is available in a storage bucket. Use a Pub/Sub-triggered Cloud Function to start the training job on a GKE cluster.

Lý do chọn đáp án này 🛠️:

• Đây là kiến trúc event-driven hoàn hảo trên GCP: Cloud Storage tự động phát hiện file mới → gửi event đến Pub/Sub topic (near real-time, <1 giây).
• Cloud Function (Pub/Sub-triggered, serverless) nhận message và khởi động Kubeflow Pipeline trên GKE qua Kubeflow SDK hoặc GKE API.
• Ưu điểm: Tiết kiệm chi phí (chỉ chạy khi cần), scalable, tích hợp CI/CD (như Cloud Build), không polling → phù hợp MLOps production. Không thay đổi đến 2026 (Pub/Sub notifications vẫn là standard).

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ Phương án SAI:
  Configure your pipeline with Dataflow, which saves the files in Cloud Storage. After the file is saved, start the training job on a GKE cluster.
  Giải thích: Pipeline đã lưu file vào Storage rồi, không cần Dataflow thêm (Dataflow dùng cho ETL batch/streaming lớn). "After saved" không chỉ rõ trigger mechanism → thiếu event-driven, có thể manual hoặc polling kém hiệu quả. Không tận dụng native Storage events.

• ❌ Phương án SAI:
  Use App Engine to create a lightweight python client that continuously polls Cloud Storage for new files. As soon as a file arrives, initiate the training job.
  Giải thích: Polling liên tục (check bucket định kỳ) lãng phí CPU/memory, chi phí cao, không scalable (App Engine flex/standard không lý tưởng cho polling). Vi phạm best practice GCP (ưu tiên push-based events thay pull/polling).

• ✅ Phương án ĐÚNG (đã giải thích chi tiết ở trên):
  Configure a Cloud Storage trigger to send a message to a Pub/Sub topic when a new file is available in a storage bucket. Use a Pub/Sub-triggered Cloud Function to start the training job on a GKE cluster.
  Giải thích bổ sung: Hoàn toàn serverless, idempotent (xử lý duplicate events), dễ monitor qua Cloud Logging/Monitoring.

• ❌ Phương án SAI:
  Use Cloud Scheduler to schedule jobs at a regular interval. For the first step of the job, check the timestamp of objects in your Cloud Storage bucket. If there are no new files since the last run, abort the job.
  Giải thích: Polling theo lịch (ví dụ 5-15 phút/lần) → delay refresh model (không "as soon as new data"), tốn tài nguyên vô ích nếu không có data mới. Cloud Scheduler tốt cho cron jobs nhưng kém cho event-driven real-time.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một pipeline ML end-to-end đang hoạt động tốt trên AI Platform (nay là Vertex AI trên Google Cloud), nơi quá trình hypertuning hyperparameters (tối ưu hóa siêu tham số) đang mất quá nhiều thời gian, gây chậm trễ cho các quy trình downstream. Mục tiêu là tăng tốc hypertuning mà không làm giảm đáng kể hiệu quả của nó. Đây là câu hỏi chọn hai hành động đúng (Choose two), tập trung vào các kỹ thuật tối ưu hóa hypertuning trong Vertex AI để cân bằng giữa tốc độ và chất lượng mô hình.
Bối cảnh kỹ thuật: Hypertuning trên Vertex AI sử dụng các trial song song để thử nghiệm các bộ hyperparameters khác nhau, với các thuật toán như Bayesian optimization. Vấn đề phổ biến là thời gian chạy lâu do số lượng trial lớn hoặc trial kém không dừng sớm.
📘 Tài liệu tham khảo:

• Vertex AI Hyperparameter Tuning Overview (cập nhật 2024-2026).
• Best Practices for Hyperparameter Tuning (phiên bản mới nhất hỗ trợ early stopping và multi-worker tuning).

✅ Đáp án đúng (Chọn 2)

Các hành động đúng là:

1. Set the early stopping parameter to TRUE
2. Decrease the maximum number of trials during subsequent training phases

Lý do lựa chọn:

• Hai hành động này tăng tốc hypertuning bằng cách giảm thời gian lãng phí trên các trial kém hoặc các phase không cần thiết, mà không ảnh hưởng lớn đến chất lượng (vì giữ nguyên không gian tìm kiếm và thuật toán tối ưu). Early stopping dừng sớm trial kém, tiết kiệm tài nguyên. Giảm max trials ở phase sau giúp pipeline nhanh hơn khi đã có config tốt từ phase trước. Điều này phù hợp với best practices Vertex AI 2026, nơi hypertuning hỗ trợ multi-phase tuning và adaptive early stopping để scale hiệu quả.
  🛠️ Lợi ích: Giảm thời gian từ hàng giờ xuống phút mà vẫn đạt hyperparameters gần optimal.

🧩 Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả các lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do cụ thể dựa trên tài liệu Vertex AI mới nhất:

• ❌ Decrease the number of parallel trials
  Sai: Việc giảm số trial song song (parallel trials) sẽ làm chậm hypertuning hơn nữa, vì Vertex AI tận dụng multi-worker để chạy nhiều trial đồng thời trên GPU/TPU. Giảm parallel chỉ phù hợp khi gặp bottleneck tài nguyên, nhưng ở đây vấn đề là thời gian tổng thể – tăng parallel mới speed up (theo docs: max_parallel_trials nên tăng lên 10-100 cho large-scale tuning 2026).

• ❌ Decrease the range of floating-point values
  Sai: Thu hẹp phạm vi giá trị float (range) sẽ giảm hiệu quả tìm kiếm, có nguy cơ bỏ lỡ hyperparameters optimal ngoài range mới, dẫn đến mô hình kém hơn. Điều này compromise effectiveness rõ rệt, trái với mục tiêu câu hỏi. Vertex AI khuyến nghị giữ range rộng và dùng Bayesian để khám phá thông minh.

• ✅ Set the early stopping parameter to TRUE
  Đúng: Bật early stopping cho phép Vertex AI dừng sớm các trial kém dựa trên metric trung gian (như validation loss), tiết kiệm 30-50% thời gian mà không mất chất lượng tổng thể (vì chỉ dừng trial dự đoán kém). Đây là tính năng mặc định hỗ trợ trong Vertex AI từ 2021, nâng cao với adaptive thresholds năm 2026.

• ❌ Change the search algorithm from Bayesian search to random search
  Sai: Chuyển từ Bayesian (thông minh, dựa trên mô hình surrogate để ưu tiên promising configs) sang random sẽ kém hiệu quả hơn, cần nhiều trial hơn để đạt kết quả tương đương, dẫn đến thời gian lâu hơn hoặc chất lượng kém. Vertex AI ưu tiên Bayesian/Grid cho production (docs: Bayesian hiệu quả gấp 2-3 lần random).

• ✅ Decrease the maximum number of trials during subsequent training phases
  Đúng: Trong multi-phase hypertuning (phase 1: explore rộng, phase 2: refine với best config từ phase 1), giảm max trials ở phase sau sẽ tăng tốc mà vẫn hiệu quả cao (vì đã có hyperparameters tốt). Vertex AI hỗ trợ resumable tuning và phase-based config từ 2024, giúp pipeline end-to-end nhanh hơn 40% ở quy mô lớn.

🛠️ Khuyến nghị thực tế: Kết hợp với tăng max_parallel_trials và dùng managed TPU pods trên Vertex AI để tối ưu thêm (theo cập nhật 2026). Nếu áp dụng, pipeline sẽ nhanh hơn đáng kể! 🚀