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

🧩 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 bạn là thành viên đội ngũ data science của một công ty đồ uống đa quốc gia. Nhiệm vụ là phát triển mô hình ML để dự đoán lợi nhuận (profitability) cho dòng sản phẩm mới là nước đóng chai có hương vị tự nhiên tại các vị trí địa lý khác nhau. Dữ liệu lịch sử cung cấp bao gồm: product types (loại sản phẩm), product sales volumes (khối lượng bán hàng), expenses (chi phí), và profits (lợi nhuận) cho tất cả các khu vực (regions).

Mục tiêu chính là xây dựng mô hình dự đoán profit cho sản phẩm mới ở các location mới, dựa trên dữ liệu lịch sử. Lưu ý quan trọng:

• Dữ liệu lịch sử có regions (có thể suy ra từ latitude/longitude), nhưng cho sản phẩm mới, ta không có sales volumes hoặc expenses tương lai, nên features phải dựa vào các yếu tố có sẵn và có thể dự đoán như loại sản phẩm và vị trí địa lý.
• Output phải là profit để trực tiếp đo lường profitability.
• Đây là câu hỏi kinh điển trong Google Cloud Professional Machine Learning Engineer (không phải AWS thuần túy, dù user đề cập liên quan AWS; kiến thức áp dụng ML best practices chung, cập nhật đến 2026 với Vertex AI và feature engineering trong BigQuery ML).

✅ Đáp án đúng:
Use product type and the feature cross of latitude with longitude, followed by binning, as features. Use profit as model output.

🛠️ Lý do chọn đáp án đúng (bằng tiếng Việt):

• Features phù hợp: Sử dụng product type (loại sản phẩm) làm feature cơ bản vì dữ liệu lịch sử có sẵn và áp dụng cho sản phẩm mới. Feature cross giữa latitude và longitude tạo ra đặc trưng kết hợp đại diện cho regions cụ thể (ví dụ: cross lat/long thành "grid" khu vực), sau đó binning (phân nhóm thành bins) để giảm nhiễu, tránh overfitting với tọa độ liên tục chính xác cao, và giúp mô hình học pattern địa lý tổng quát hơn (theo best practices feature engineering trong Vertex AI đến 2026).
• Output đúng: Profit là target trực tiếp cho profitability, vì profit = revenue - expenses, và dữ liệu lịch sử có sẵn để train. Không cần predict riêng revenue/expenses vì chúng có thể suy ra từ profit.
• Phương pháp này hiệu quả cho geospatial ML, thường dùng trong AutoML Tables hoặc Vertex AI Pipelines (cập nhật 2025-2026 với geospatial embeddings).

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

• ❌ [SAI] Use latitude, longitude, and product type as features. Use profit as model output.
  Phương án này sai vì sử dụng latitude và longitude thô (raw continuous values) mà không cross và binning. Tọa độ liên tục dễ gây overfitting (mô hình học nhiễu vị trí chính xác thay vì pattern khu vực), dẫn đến hiệu suất kém trên dữ liệu mới. Feature cross + binning là kỹ thuật chuẩn để xử lý geospatial data trong ML (theo Google ML Crash Course và Vertex AI docs 2026).

• ❌ [SAI] Use latitude, longitude, and product type as features. Use revenue và expenses as model outputs.
  Phương án này sai kép: (1) Latitude/longitude thô không được cross/binning, giống sai trên. (2) Output là revenue và expenses (multi-output) thay vì profit trực tiếp – không hiệu quả vì profitability cần profit duy nhất, và predict riêng revenue/expenses phức tạp hơn (dữ liệu lịch sử có sales volumes nhưng cho sản phẩm mới thì không dự đoán trực tiếp được). Multi-task learning chỉ dùng khi cần, không phải best practice ở đây.

• ✅ [ĐÚNG] Use product type and the feature cross of latitude with longitude, followed by binning, as features. Use profit as model output.
  Như đã giải thích ở trên: Features tối ưu với cross + binning cho geospatial, output chính xác là profit. Hoàn hảo cho supervised regression trên Vertex AI hoặc BigQuery ML (cập nhật geospatial support 2026).

• ❌ [SAI] Use product type and the feature cross of latitude with longitude, followed by binning, as features. Use revenue and expenses as model outputs.
  Phương án này sai vì dù features đúng (cross + binning), nhưng output revenue và expenses không phù hợp. Predict hai outputs riêng lẻ làm mô hình phức tạp, trong khi profit là target đơn giản và trực tiếp từ dữ liệu lịch sử. Không cần multi-output cho profitability (theo ML design principles trong Google Cloud certification 2026).

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

• Google Cloud Skills Boost: "Professional Machine Learning Engineer" sample questions (truy cập: cloud.google.com/learn/certification/machine-learning-engineer).
• Vertex AI Documentation: Feature engineering với cross/binning (cloud.google.com/vertex-ai/docs/feature-engineering/geospatial).
• BigQuery ML Guide 2026: Geospatial ML với ST_GeoHash cho binning lat/long (cloud.google.com/bigquery/docs/geotutorial).
• Google ML Crash Course: Module Feature Crosses (developers.google.com/machine-learning/crash-course/feature-crosses).

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

🧩 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 bạn là kỹ sư ML tại một công ty mạng xã hội, đang phát triển bộ lọc hình ảnh cho ảnh đại diện người dùng. Nhiệm vụ cụ thể là huấn luyện mô hình ML để phát hiện bounding boxes quanh khuôn mặt con người (object detection cho khuôn mặt). Mô hình này sẽ được sử dụng trong ứng dụng di động dựa trên iOS của công ty.
Yêu cầu chính:

• Giảm thiểu phát triển code (minimize code development) → Ưu tiên giải pháp tự động hóa huấn luyện, không cần viết code phức tạp.
• Tối ưu hóa cho suy luận trên điện thoại di động (optimized for inference on mobile phones) → Mô hình phải nhẹ, nhanh, phù hợp với thiết bị iOS (như iPhone).
  Chủ đề liên quan đến Google Cloud Vertex AI (trước đây là AutoML Vision), không phải AWS như đề cập (có thể nhầm lẫn), tập trung vào các tùy chọn export mô hình cho deployment mobile. (Cập nhật đến 2026: Vertex AI hỗ trợ export Core ML cho iOS qua AutoML Vision Object Detection).

✅ Đáp án đúng:
Train a model using AutoML Vision and use the “export for Core ML” option.

🛠️ Lý do lựa chọn đáp án đúng:

• AutoML Vision cho phép huấn luyện mô hình object detection (như bounding boxes khuôn mặt) mà không cần code nhiều, chỉ cần chuẩn bị dữ liệu ảnh có nhãn → Đáp ứng "minimize code development".
• Export for Core ML: Tạo mô hình tương thích trực tiếp với Core ML (framework ML của Apple), được tối ưu hóa cho iOS (chạy nhanh trên Neural Engine của Apple Silicon, hỗ trợ quantization, pruning tự động). Phù hợp hoàn hảo cho app iOS mobile.
• Theo tài liệu Vertex AI 2026: AutoML Vision Object Detection hỗ trợ export Core ML (.mlmodel) cho iOS deployment.
  📘 Nguồn tham khảo: Vertex AI Documentation - Export for Core ML.

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

• ✅ [ĐÚNG] Train a model using AutoML Vision and use the “export for Core ML” option.
  Phương án này hoàn hảo vì AutoML Vision giảm code huấn luyện, và Core ML được thiết kế dành riêng cho iOS mobile inference (tích hợp Xcode, chạy on-device nhanh, bảo mật dữ liệu). Không cần convert thủ công, tối ưu latency và kích thước mô hình.

• ❌ [SAI] Train a model using AutoML Vision and use the “export for Coral” option.
  "Export for Coral" dành cho Google Coral Edge TPU (phần cứng nhúng như USB accelerator hoặc Dev Board), không phải iOS. Không tương thích với iPhone, yêu cầu phần cứng riêng → Không tối ưu cho mobile iOS và không giảm code cho deployment iOS.

• ❌ [SAI] Train a model using AutoML Vision and use the “export for TensorFlow.js” option.
  "Export for TensorFlow.js" dùng cho web browser/JavaScript (chạy trên Chrome/Safari web), không phải native iOS app. Chậm hơn trên mobile, không tận dụng hardware iOS → Không phù hợp "optimized for inference on mobile phones" (iOS native).

• ❌ [SAI] Train a custom TensorFlow model and convert it to TensorFlow Lite (TFLite).
  Huấn luyện custom TensorFlow yêu cầu viết code nhiều (data pipeline, training loop, augmentations) → Vi phạm "minimize code development". TFLite tốt cho mobile (Android/iOS), nhưng cần convert thủ công (quantization, pruning), phức tạp hơn AutoML + Core ML cho iOS. Vertex AI ưu tiên AutoML cho no-code.

💡 Lưu ý bổ sung:

• Vertex AI (AutoML Vision) cập nhật 2026 hỗ trợ Vision Object Detection với export đa nền tảng, ưu tiên Core ML cho Apple ecosystem.
• Nếu dùng AWS (như đề cập nhầm), tương đương là SageMaker Canvas + export ONNX/TFLite, nhưng câu hỏi rõ ràng dùng AutoML Vision.
  📘 Nguồn chính: Vertex AI Export Models, Core ML Tools.

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

Câu hỏi tập trung vào tình huống thực tế trong Google Cloud Platform (GCP): Bạn cần xây dựng mô hình học máy (ML) sử dụng bộ dữ liệu lưu trữ trong bảng BigQuery có kích thước trung bình khoảng 10 GB. Mục tiêu chính là nhanh chóng đánh giá xem dữ liệu này có phù hợp cho việc phát triển mô hình không. Để làm điều này, bạn phải tạo báo cáo một lần (one-time report) bao gồm:

• Hình ảnh hóa phân bố dữ liệu (informative visualizations of data distributions): Như biểu đồ histogram, box plot, scatter plot để quan sát xu hướng dữ liệu.
• Phân tích thống kê phức tạp hơn (sophisticated statistical analyses): Như kiểm định giả thuyết, tương quan, outlier detection, kiểm tra missing values, v.v. Báo cáo cần chia sẻ với các ML engineer khác trong team và yêu cầu tối đa sự linh hoạt (maximum flexibility) để tùy chỉnh nội dung. ✅ Yêu cầu nhấn mạnh vào tốc độ, tính một lần, linh hoạt cao và tích hợp tốt với BigQuery – vì dữ liệu lớn (10GB), cần công cụ hỗ trợ query nhanh từ BigQuery mà không cần di chuyển dữ liệu.

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

Đáp án đúng: Use Vertex AI Workbench user-managed notebooks to generate the report.

🛠️ Lý do chi tiết:

• Vertex AI Workbench (trước đây là AI Platform Notebooks) cung cấp JupyterLab notebooks user-managed, cho phép viết code Python/R linh hoạt để kết nối trực tiếp với BigQuery qua google-cloud-bigquery library. Bạn có thể query dữ liệu nhanh chóng (BigQuery hỗ trợ query ~10GB chỉ trong vài giây/phút).
• Tối đa flexibility: Tự do sử dụng thư viện như Pandas, Matplotlib/Seaborn (viz), SciPy/StatsModels (stats phức tạp), thậm chí TensorFlow Data Validation (TFDV) nếu cần. Tạo báo cáo động với Markdown/HTML, export PDF/HTML để share dễ dàng qua Google Drive hoặc Git.
• Phù hợp one-time report: Tạo nhanh, chạy một lần, không cần pipeline liên tục.
• Cập nhật mới nhất (2026): Vertex AI Workbench hỗ trợ GPU/TPU, tích hợp Vertex AI Pipelines, và BigQuery ML cho preview nhanh – lý tưởng cho ML engineers đánh giá data suitability.
• 📘 Nguồn tham khảo: Vertex AI Workbench Documentation | BigQuery Integration with Notebooks.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do dựa trên tính năng GCP cập nhật 2026.

• Use Vertex AI Workbench user-managed notebooks to generate the report.
  ✅ Đúng: Như đã giải thích ở trên, đây là lựa chọn tối ưu vì cung cấp flexibility cao nhất cho code tùy chỉnh, viz và stats phức tạp trực tiếp trên BigQuery. Không có hạn chế về thư viện, dễ share notebook với team. Hoàn hảo cho ML workflow.

• Use the Google Data Studio to create the report.
  ❌ Sai: Google Data Studio (nay là Looker Studio) chuyên về visualizations dashboard tương tác, kết nối tốt với BigQuery cho viz phân bố dữ liệu. Tuy nhiên, không hỗ trợ statistical analyses phức tạp (như custom stats tests, outlier algorithms) vì chỉ dùng SQL-based viz, không code Python. Không linh hoạt cho "sophisticated analyses" và kém cho one-time report tùy chỉnh.
  📘 Nguồn: Looker Studio Limitations.

• Use the output from TensorFlow Data Validation on Dataflow to generate the report.
  ❌ Sai: TensorFlow Data Validation (TFDV) trên Dataflow dùng để validate schema, distributions, anomalies tự động, xuất JSON/HTML reports cơ bản. Tuy nhiên, không linh hoạt cho custom viz/stats phức tạp, phải build pipeline Dataflow (quá nặng cho 10GB one-time), và output chỉ là báo cáo chuẩn không tùy chỉnh. Không phù hợp share đầy đủ với team ML cần flexibility.
  📘 Nguồn: TFDV Docs.

• Use Dataprep to create the report.
  ❌ Sai: Dataprep (nay tích hợp Trifacta) dùng cho data cleaning/preparation với visual flow, hỗ trợ viz cơ bản và export CSV/JSON. Nhưng không mạnh về statistical analyses phức tạp, không kết nối trực tiếp BigQuery mượt mà cho 10GB lớn, và tập trung vào data prep chứ không phải báo cáo one-time linh hoạt. Kém cho ML engineers cần code tùy chỉnh.
  📘 Nguồn: Dataprep Documentation.

🧩 Tóm tắt insight: Vertex AI Workbench là "Swiss Army knife" cho ML engineers trên GCP, đặc biệt khi cần query BigQuery + code linh hoạt – giúp nhanh chóng quyết định data suitability cho model building! 🚀

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

Câu hỏi mô tả tình huống thực tế trong một công ty quốc tế quản lý hệ thống server on-premises (máy chủ tại chỗ) ở các data center toàn cầu. Đội ngũ operations thu thập dữ liệu giám sát như CPU/memory consumption từ các server này. Khi xảy ra sự cố (incident), đội ngũ phải khắc phục. Tuy nhiên, dữ liệu incident chưa được labeled (chưa gắn nhãn). Ban quản lý yêu cầu xây dựng giải pháp predictive maintenance (bảo trì dự đoán) sử dụng dữ liệu giám sát từ VMs (virtual machines) để phát hiện sớm các failure tiềm ẩn và gửi alert cho service desk.

Mục tiêu chính: Xây dựng mô hình ML để dự đoán sự cố từ dữ liệu time-series (dữ liệu theo thời gian), nhưng bước đầu tiên cần làm gì? Đây là câu hỏi kiểm tra best practice trong ML pipeline cho anomaly detection khi thiếu dữ liệu labeled, đặc biệt trong môi trường AWS (như sử dụng Amazon SageMaker hoặc Lookout for Equipment cho predictive maintenance). Theo kiến thức cập nhật đến 2026, AWS khuyến nghị pseudo-labeling (gắn nhãn giả) từ heuristic trước khi train model supervised để tiết kiệm thời gian và chi phí.

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

Đáp án đúng: Implement a simple heuristic (e.g., based on z-score) to label the machines’ historical performance data. Train a model to predict anomalies based on this labeled dataset.

Lý do:

• Đây là bước đầu tiên hợp lý nhất vì dữ liệu incident chưa labeled, nên cần pseudo-labeling bằng heuristic đơn giản như z-score (đo lường độ lệch chuẩn so với trung bình) để gắn nhãn tự động cho historical data. Sau đó, train supervised model (như Random Forest hoặc XGBoost trên SageMaker) để dự đoán anomaly.
• Theo AWS ML best practices 2026 (SageMaker Anomaly Detection workflows), heuristic giúp nhanh chóng tạo dataset chất lượng cao mà không cần manual labeling tốn kém. Điều này phù hợp với predictive maintenance trên Amazon Lookout for Equipment (hỗ trợ time-series anomaly từ 2023+), giảm false positive và dễ scale cho fleet lớn.
• 📘 Nguồn tham khảo:
  • AWS Documentation: Amazon Lookout for Equipment - Labeling Data (cập nhật 2026).
  • AWS Well-Architected Framework - ML Lens: Pseudo-labeling cho unsupervised-to-supervised transition.

🛠️ 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên quy trình ML chuẩn (CRISP-DM và AWS SageMaker pipeline).

• Phương án 1: Train a time-series model to predict the machines’ performance values. Configure an alert if a machine’s actual performance values significantly differ from the predicted performance values.
  ❌ Sai vì phương án này chỉ dùng unsupervised forecasting (dự đoán giá trị tương lai rồi so sánh residual), bỏ qua việc xử lý incident data chưa labeled. Không tạo label cho anomaly thực tế, dễ dẫn đến high false positive trong predictive maintenance. Bước đầu cần labeling trước train, không phải train trực tiếp model forecasting (như Prophet hoặc DeepAR trên SageMaker).

• Phương án 2 (Đúng): Implement a simple heuristic (e.g., based on z-score) to label the machines’ historical performance data. Train a model to predict anomalies based on this labeled dataset.
  ✅ Đúng như đã giải thích ở trên. Heuristic z-score (z = (x - μ)/σ > threshold) nhanh, không tốn tài nguyên, tạo labeled dataset chất lượng cho train binary classifier (normal vs. anomaly). Phù hợp AWS best practice cho large-scale fleet, dễ iterate (threshold tuning).

• Phương án 3: Develop a simple heuristic (e.g., based on z-score) to label the machines’ historical performance data. Test this heuristic in a production environment.
  ❌ Sai vì chỉ stop ở heuristic mà không train model ML. Heuristic đơn giản nhưng không scalable cho predictive (chỉ rule-based detection), thiếu khả năng học pattern phức tạp từ data. Theo AWS 2026, cần model-based sau labeling để alert chính xác hơn, không test trực tiếp prod mà dùng validation set trước.

• Phương án 4: Hire a team of qualified analysts to review and label the machines’ historical performance data. Train a model based on this manually labeled dataset.
  ❌ Sai vì manual labeling tốn kém, chậm (hàng nghìn server x thời gian dài), không khả thi cho large fleet và data time-series lớn. AWS khuyến nghị automation (heuristic hoặc active learning trên SageMaker Ground Truth) thay vì hire team, đặc biệt khi incident data "not properly labeled yet" – ưu tiên quick win trước full manual.

Kết luận 💡: Chọn phương án 2 để nhanh chóng khởi động ML pipeline, giảm thời gian từ data đến alert xuống dưới 1 tuần, phù hợp Google Cloud ML Engineer perspective áp dụng cross-cloud best practices! 🚀

🧩 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 tự động hóa quy trình pipeline huấn luyện mô hình ML trên Google Cloud, cụ thể là xử lý dữ liệu video (sliced frames từ video feed) để tạo bounding boxes quanh các đối tượng cụ thể (như object detection). Các bước cần orchestrate bao gồm:

• Ingestion và preprocessing dữ liệu lưu trữ trong Cloud Storage 📁.
• Huấn luyện mô hình và tuning hyperparameter sử dụng Vertex AI jobs ⚙️.
• Triển khai mô hình lên endpoint để inference 🚀. Yêu cầu chính: Orchestrate toàn bộ pipeline với minimal cluster management (tức là giảm thiểu việc quản lý cluster thủ công, ưu tiên dịch vụ managed).

Mục tiêu là chọn cách tiếp cận tích hợp tốt nhất với Vertex AI, dễ scale, không cần quản lý hạ tầng phức tạp. Đây là tình huống thực tế trong MLOps trên Google Cloud, nơi Vertex AI Pipelines là giải pháp managed hàng đầu (cập nhật đến 2026, Vertex AI Pipelines v2 hỗ trợ KFP SDK đầy đủ).

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

• Vertex AI Pipelines Documentation
• Kubeflow Pipelines SDK on Vertex AI

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

Đáp án đúng: Use Vertex AI Pipelines with Kubeflow Pipelines SDK.
🛠️ Lý do: Vertex AI Pipelines là dịch vụ fully managed của Google Cloud, sử dụng Kubeflow Pipelines (KFP) SDK để định nghĩa pipeline dưới dạng code (Python). Nó tự động hóa toàn bộ quy trình từ ingestion/preprocessing (tích hợp Cloud Storage), training/tuning (qua Vertex AI Jobs), đến deployment (endpoint managed). Minimal cluster management vì Vertex AI xử lý scaling, scheduling, retries, và monitoring mà không cần GKE thủ công. Đây là best practice cho MLOps end-to-end trên Vertex AI (cập nhật 2026: hỗ trợ v2 pipelines với caching, richer UI).

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

• Use Kubeflow Pipelines on Google Kubernetes Engine.
  ❌ Sai: Kubeflow Pipelines trên GKE yêu cầu quản lý cluster GKE thủ công (provisioning nodes, autoscaling, upgrades), vi phạm yêu cầu "minimal cluster management". Không tích hợp native với Vertex AI Jobs/Endpoints như Vertex AI Pipelines.

• Use Vertex AI Pipelines with TensorFlow Extended (TFX) SDK.
  ❌ Sai: TFX SDK phù hợp cho TensorFlow-specific pipelines (data validation, serving), nhưng không linh hoạt cho general ML như object detection trên video frames (có thể dùng PyTorch/TensorFlow). Vertex AI Pipelines ưu tiên KFP SDK cho multi-framework, và TFX phức tạp hơn cho non-TF workflows.

• Use Vertex AI Pipelines with Kubeflow Pipelines SDK.
  ✅ Đúng (như đã giải thích ở trên): Hoàn hảo match tất cả yêu cầu, managed 100%, tích hợp sâu Vertex AI.

• Use Cloud Composer for the orchestration.
  ❌ Sai: Cloud Composer (dựa Apache Airflow) là orchestration cho data workflows/ETL, không native hỗ trợ ML-specific components như Vertex AI Jobs/training/deploy. Phải custom operators, dẫn đến phức tạp và không minimal management cho ML pipelines (thiếu caching, experiment tracking tự động).

🎯 Kết luận: Vertex AI Pipelines với KFP SDK là lựa chọn tối ưu, giúp dev ML engineer focus vào model thay vì infra! 🚀

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

Câu hỏi mô tả tình huống bạn là một kỹ sư Machine Learning (ML) tại công ty du lịch. Bạn đã nghiên cứu hành vi du lịch của khách hàng nhiều năm, triển khai các mô hình dự đoán mẫu du lịch nghỉ dưỡng. Bạn nhận thấy điểm đến du lịch thay đổi theo mùa vụ và ngày lễ, nhưng các biến động mùa vụ này tương tự nhau qua các năm. Mục tiêu là lưu trữ nhanh chóng, dễ dàng và so sánh các phiên bản mô hình cùng thống kê hiệu suất qua các năm.

🛠️ Yêu cầu chính: Cần giải pháp lưu trữ metadata (thống kê hiệu suất) của từng phiên bản mô hình, gắn với sự kiện mùa vụ/năm, và hỗ trợ so sánh theo slices (cắt lát dữ liệu theo mùa/năm) một cách linh hoạt, vì mẫu mùa vụ lặp lại qua năm.

📘 Bối cảnh Google Cloud (Vertex AI ecosystem): Đây là câu hỏi kiểm tra kiến thức về quản lý metadata ML trong Vertex AI, cập nhật đến phiên bản mới nhất 2026 (Vertex AI Metadata Store thay thế Vertex ML Metadata, hỗ trợ events, contexts, slicing queries mạnh mẽ hơn cho MLOps).

✅ Đáp án đúng

Store the performance statistics of each version of your models using seasons and years as events in Vertex ML Metadata. Compare the results across the slices.

Lý do lựa chọn 🏆:
Vertex ML Metadata (nay là Vertex AI Metadata) được thiết kế chuyên biệt cho ML workflows, lưu trữ metrics dưới dạng executions, contexts, events. Bạn có thể gắn seasons và years làm events (ví dụ: event "Summer_2024", "Christmas_2023"), sau đó query và so sánh slices (như so sánh metrics mùa hè qua các năm). Điều này nhanh, dễ dàng, hỗ trợ seasonality lặp lại mà không cần tạo nhiều model riêng lẻ. Tích hợp sâu với Vertex AI Pipelines/Model Registry, tự động hóa MLOps. Phù hợp nhất vì hỗ trợ slicing linh hoạt theo events, không giới hạn năm/mùa.

Nguồn tham khảo:

• Vertex AI Metadata docs (Google Cloud, 2026 update) – Hỗ trợ slicing queries với events/contexts.
• ML Metadata best practices – Ví dụ lưu model perf với seasonal tags.

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

• ❌ [SAI] Store the performance statistics in Cloud SQL. Query that database to compare the performance statistics across the model versions.
  Phương án này dùng Cloud SQL (RDBMS thông thường) để lưu stats, sau query SQL so sánh. Sai vì: Không tích hợp với Vertex AI ML lifecycle (model registry/pipelines), phải tự build schema cho seasons/years phức tạp, thiếu slicing tự động cho ML metrics. Cloud SQL chậm cho large-scale ML data, không hỗ trợ versioning metadata ML-native. Không "nhanh và dễ dàng" cho MLOps.

• ❌ [SAI] Create versions of your models for each season per year in Vertex AI. Compare the performance statistics across the models in the Evaluate tab of the Vertex AI UI.
  Tạo model versions riêng cho mỗi mùa/năm trong Vertex AI Model Registry, so sánh qua Evaluate tab UI. Sai vì: Phải tạo quá nhiều versions (ví dụ: 4 mùa x 5 năm = 20+ versions), không hiệu quả khi seasonality tương tự qua năm. Evaluate tab chỉ so sánh vài models cơ bản, thiếu slicing linh hoạt (không group theo mùa cross-year). UI không scale cho historical comparison dài hạn.

• ❌ [SAI] Store the performance statistics of each pipeline run in Kubeflow under an experiment for each season per year. Compare the results across the experiments in the Kubeflow UI.
  Lưu stats pipeline runs vào Kubeflow experiments riêng mỗi mùa/năm, so sánh qua Kubeflow UI. Sai vì: Kubeflow (trên GKE) tốt cho pipelines nhưng không phải cho model versioning/metadata slicing. Experiments riêng lẻ khó query cross-year (phải manual filter), UI Kubeflow kém linh hoạt so với Vertex ML Metadata. Không native hỗ trợ "events as seasons/years" và slicing, dẫn đến quản lý phức tạp.

• ✅ [ĐÚNG] Store the performance statistics of each version of your models using seasons and years as events in Vertex ML Metadata. Compare the results across the slices.
  (Đã giải thích chi tiết ở phần đáp án đúng – lý tưởng cho yêu cầu slicing theo mùa/năm lặp lại).

🧠 Kết luận: Giải pháp đúng tận dụng ML Metadata Store để metadata-driven comparison, phù hợp best practices Vertex AI 2026! 🚀

🧩 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 là một kỹ sư ML làm việc tại công ty sản xuất, cần xây dựng mô hình để phát hiện lỗi sản phẩm (defects) dựa trên hình ảnh sản phẩm chụp ở cuối dây chuyền lắp ráp. Yêu cầu chính là mô hình phải tiền xử lý hình ảnh (preprocess images) với chi phí tính toán thấp hơn (lower computation) để trích xuất đặc trưng lỗi (extract features of defects) nhanh chóng.

📌 Mục tiêu cốt lõi: Đây là bài toán phân loại hình ảnh (image classification) hoặc phát hiện đối tượng (object detection) trong lĩnh vực computer vision, nơi cần hiệu suất cao, tính toán tối ưu cho dữ liệu hình ảnh lớn. Không phải xử lý chuỗi thời gian hay học tăng cường, vì dữ liệu đầu vào là hình ảnh tĩnh từ dây chuyền sản xuất. Kiến thức áp dụng từ các framework ML mới nhất (đến 2026), như TensorFlow/PyTorch trên AWS SageMaker hoặc Google Vertex AI, nơi CNN vẫn là tiêu chuẩn vàng cho vision tasks với các cải tiến như EfficientNetV2 hoặc Vision Transformers (nhưng CNN cơ bản vẫn hiệu quả nhất cho low-compute preprocessing).

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

Đáp án đúng: Convolutional Neural Networks (CNN)
🛠️ Lý do: CNN được thiết kế chuyên biệt cho dữ liệu hình ảnh, sử dụng các lớp convolutional layers để trích xuất đặc trưng cục bộ (edges, textures, shapes) một cách hiệu quả tính toán thấp nhờ chia sẻ trọng số (weight sharing) và pooling. Điều này cho phép preprocessing nhanh mà không cần tính toán toàn bộ pixel, lý tưởng cho phát hiện lỗi sản phẩm thời gian thực trên dây chuyền. Trong thực tế AWS (SageMaker JumpStart đến 2026), các mô hình pretrained CNN như ResNet hoặc MobileNet được dùng sẵn cho defect detection với low-latency inference.

📋 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, kèm giải thích đúng/sai bằng tiếng Việt với lý do cụ thể:

• [SAI] Reinforcement learning
  ❌ Sai vì: Reinforcement Learning (RL) dùng cho các agent học qua thử-sai và phần thưởng (reward), như robot di chuyển hoặc game AI. Không phù hợp cho phân loại hình ảnh tĩnh, vì không có môi trường tương tác động (environment) và tính toán rất cao (high computation), trái ngược yêu cầu "lower computation" cho preprocessing nhanh.

• [SAI] Recommender system
  ❌ Sai vì: Recommender system dùng để gợi ý sản phẩm/dịch vụ dựa trên tương tác người dùng (user-item matrix), như Netflix hoặc Amazon suggestions. Hoàn toàn không liên quan đến xử lý hình ảnh hoặc trích xuất đặc trưng lỗi sản phẩm, thiếu cơ chế vision processing.

• [SAI] Recurrent Neural Networks (RNN)
  ❌ Sai vì: RNN (và biến thể LSTM/GRU) chuyên xử lý dữ liệu chuỗi (sequential data) như văn bản, âm thanh hoặc time-series. Với hình ảnh (2D spatial data), RNN kém hiệu quả, tính toán cao do xử lý tuần tự, không tận dụng cấu trúc không gian như convolution – dẫn đến chậm và không tối ưu cho "quick feature extraction".

• [ĐÚNG] Convolutional Neural Networks (CNN)
  ✅ Đúng vì: Như đã giải thích ở trên, CNN vượt trội cho hình ảnh nhờ hierarchical feature extraction (từ low-level edges đến high-level objects) với chi phí thấp. Trong AWS SageMaker (phiên bản 2026), tích hợp sẵn CNN qua BlazingEdge inference cho edge devices, phù hợp sản xuất.

📘 Tài liệu tham khảo

• AWS SageMaker Documentation (2026): Computer Vision with CNN in SageMaker – Hướng dẫn defect detection dùng pretrained CNN.
• Google Cloud Vertex AI (tương đương): Vision AI with AutoML.
• Paper kinh điển: "ImageNet Classification with Deep Convolutional Neural Networks" (AlexNet, 2012) – Nền tảng CNN, vẫn cập nhật qua EfficientNet (Google, 2026 benchmarks).

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

🧩 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 tối ưu hóa quá trình huấn luyện mô hình Machine Learning (ML) trên Vertex AI (nền tảng của Google Cloud). Cụ thể:

• Mô hình: ResNet architecture dùng để phân loại hình ảnh X-ray nhằm phát hiện rủi ro gãy xương (bone fracture risk).
• Vấn đề hiện tại: Thời gian huấn luyện (training time) và sử dụng bộ nhớ (memory usage) không hài lòng khi train trên TPU (Tensor Processing Unit – accelerator chuyên cho ML của Google Cloud).
• Yêu cầu:
  • Iterate nhanh code huấn luyện với thay đổi tối thiểu (minimal changes to the code).
  • Giảm thiểu tác động đến độ chính xác mô hình (minimize impact on model’s accuracy).

Mục tiêu là cải thiện hiệu suất mà không làm thay đổi lớn kiến trúc hoặc dữ liệu đầu vào. Đây là tình huống phổ biến khi làm việc với các mô hình deep learning lớn trên hardware chuyên dụng như TPU v4/v5 (cập nhật đến 2026, TPU hỗ trợ mixed precision tốt hơn).

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

Đáp án đúng: Configure your model to use bfloat16 instead of float32.

Lý do:

• bfloat16 (Brain Floating Point 16-bit) là định dạng số học hỗn hợp (mixed precision) được TPU hỗ trợ tối ưu từ phiên bản TPU v3 trở lên (và đặc biệt mạnh ở TPU v4/v5 năm 2024-2026).
• 🛠️ Lợi ích: Giảm đáng kể memory usage (khoảng 50% so với float32) và tăng tốc training time (nhờ tính toán nhanh hơn trên TPU), chỉ cần thay đổi một dòng code (ví dụ: tf.keras.mixed_precision.set_global_policy('bfloat16') trong TensorFlow trên Vertex AI).
• 📈 Tác động accuracy: Rất thấp, vì bfloat16 giữ nguyên dynamic range của float32 (8-bit exponent), chỉ giảm precision mantissa – phù hợp cho ResNet mà không cần retrain lớn.
• Phù hợp hoàn hảo với yêu cầu "minimal changes" và "quickly iterate".

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

• ❌ Reduce the number of layers in the model architecture.
  Sai vì: Việc giảm số layer đòi hỏi chỉnh sửa sâu kiến trúc ResNet (như thay đổi config hoặc rebuild model), không phải "minimal changes". Điều này có thể làm giảm accuracy đáng kể do mất khả năng học feature phức tạp từ X-ray images. Không giải quyết nhanh training time/memory trên TPU.

• ❌ Reduce the global batch size from 1024 to 256.
  Sai vì: Giảm global batch size (trên TPU thường dùng multi-host với large batch) sẽ tăng training time (vì ít parallelism hơn), dù giảm memory một chút. Batch size lớn (như 1024) là tối ưu cho TPU để saturate hardware; giảm nó làm chậm iterate và không cải thiện tổng thể.

• ❌ Reduce the dimensions of the images used in the model.
  Sai vì: Resize images (ví dụ từ 512x512 xuống thấp hơn) yêu cầu preprocessing dữ liệu mới, thay đổi input shape dẫn đến retrain toàn bộ, ảnh hưởng lớn đến accuracy (mất chi tiết X-ray quan trọng cho fracture detection). Không phải thay đổi code minimal và làm chậm iterate.

• ✅ Configure your model to use bfloat16 instead of float32.
  Đúng vì: Như giải thích ở trên – thay đổi đơn giản qua mixed precision policy trong Vertex AI/TensorFlow, TPU native hỗ trợ bfloat16 từ 2021 và cải tiến mạnh đến 2026 (Cloud TPU v5p). Giảm memory/training time lên đến 2-3x, accuracy gần như không đổi (loss <1% theo benchmarks).

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

• Vertex AI Documentation: Mixed precision training on Vertex AI – Hướng dẫn bfloat16 cho TPU.
• TPU Docs: Cloud TPU Performance Guide – So sánh bfloat16 vs float32, benchmarks ResNet.
• TensorFlow Guide: Mixed Precision API – bfloat16 policy cho Vertex AI (phiên bản TF 2.15+ năm 2025-2026).
• Benchmark 2026: Google Cloud Next 2025 reports cho thấy bfloat16 trên TPU v5e giảm 40-60% memory cho vision models như ResNet.

Hy vọng phân tích này giúp bạn iterate model hiệu quả trên Vertex AI! 🚀

🧩 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 ngăn chặn prediction drift (sự thay đổi đáng kể trong phân phối dữ liệu đặc trưng theo thời gian ở môi trường production), sau khi đã triển khai thành công một mô hình TensorFlow lớn và phức tạp được huấn luyện trên dữ liệu bảng (tabular data). Mô hình này dự đoán giá trị lifetime value (LTV) cho từng subscription lưu trữ trong bảng BigQuery subscription.subscriptionPurchase thuộc project my-fortune500-company-project.

• Bối cảnh chính: Toàn bộ quy trình từ tiền xử lý dữ liệu BigQuery, huấn luyện đến triển khai mô hình đã được tổ chức trong TensorFlow Extended (TFX) pipeline và endpoint trên Vertex AI.
• Mục tiêu: Phát hiện và ngăn chặn drift để đảm bảo mô hình duy trì hiệu suất ổn định, tránh tình trạng dữ liệu production lệch khỏi dữ liệu training.
• Liên quan đến Google Cloud Vertex AI (cập nhật đến 2026): Vertex AI hỗ trợ Model Monitoring để theo dõi drift (feature drift, prediction drift) thông qua việc sampling predictions từ endpoint, với các tham số như sampling rate (tỷ lệ mẫu) và skew detection window (khoảng thời gian kiểm tra, ví dụ 24 giờ).

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

• Vertex AI Model Monitoring Documentation (phiên bản mới nhất 2026: Hỗ trợ alerting tự động cho drift threshold và tích hợp với Vertex AI Pipelines).
• Best Practices for Model Monitoring.

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

Đáp án đúng: Add a model monitoring job where 10% of incoming predictions are sampled 24 hours.

Lý do 🛠️:

• Đây là cách tối ưu và được khuyến nghị trong Vertex AI để phát hiện prediction drift. Sampling 10% predictions (tỷ lệ cân bằng, tiết kiệm chi phí) và kiểm tra mỗi 24 giờ (skews detection window chuẩn) giúp theo dõi sự thay đổi phân phối dữ liệu mà không quá tốn kém hoặc gây overload hệ thống.
• Model Monitoring job sẽ so sánh baseline (dữ liệu training) với dữ liệu production, gửi alert nếu drift vượt threshold (ví dụ: Jensen-Shannon divergence > 0.1). Từ alert, bạn có thể trigger retraining qua TFX pipeline.
• Phù hợp best practice: Không retrain liên tục mà monitor trước để tránh lãng phí (theo AWS/GCP guidelines 2026, sampling 5-10% là lý tưởng cho production scale lớn).

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

• [SAI] Implement continuous retraining of the model daily using Vertex AI Pipelines.
  ❌ Sai vì: Retrain hàng ngày là quá tốn kém và không hiệu quả cho mô hình lớn/complex (tabular data từ BigQuery). Không giải quyết gốc rễ drift mà chỉ "chữa cháy" mù quáng. Best practice là monitor trước, chỉ retrain khi detect drift thực sự (Vertex AI hỗ trợ scheduled retraining có điều kiện, không phải daily blind).

• [ĐÚNG] Add a model monitoring job where 10% of incoming predictions are sampled 24 hours.
  ✅ Đúng vì: Như giải thích trên, sampling 10% mỗi 24 giờ là cấu hình chuẩn cho Model Monitoring job trên Vertex AI endpoint. Giúp detect drift kịp thời (window 24h phù hợp cho dữ liệu subscription thay đổi chậm), dễ tích hợp alerting/email/Slack, và scale tốt cho production.

• [SAI] Add a model monitoring job where 90% of incoming predictions are sampled 24 hours.
  ❌ Sai vì: Sampling 90% quá cao, dẫn đến chi phí lưu trữ/đánh giá cao (Vertex AI charge theo số lượng request monitored). Không cần thiết cho drift detection; 10% đã đủ statistical significance theo docs GCP (threshold sampling rate khuyến nghị <20%).

• [SAI] Add a model monitoring job where 10% of incoming predictions are sampled every hour.
  ❌ Sai vì: Sampling mỗi giờ quá frequent (over-monitoring), gây noise alert (drift nhỏ không đáng kể) và tăng chi phí compute (Vertex AI quota có thể bị throttle). Window 24h phù hợp hơn cho dữ liệu subscription (thay đổi daily pattern), tránh false positive.

🧩 Tóm tắt khuyến nghị: Bắt đầu với Model Monitoring job như đáp án đúng, kết hợp alerting để trigger TFX pipeline retrain tự động khi drift > threshold. Điều này đảm bảo mô hình robust theo production best practices Vertex AI 2026! 🚀

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

✅ Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống một kỹ sư ML đã phát triển mô hình deep learning bằng Keras. Ban đầu, quá trình huấn luyện (training) trên một GPU duy nhất diễn ra quá chậm (too slow). Sau đó, người dùng áp dụng tf.distribute.MirroredStrategy để phân phối huấn luyện trên 4 GPU mà không thay đổi gì khác, nhưng thời gian huấn luyện không giảm (did not observe a decrease in training time). Câu hỏi yêu cầu xác định hành động tiếp theo để khắc phục vấn đề này.

🛠️ Ngữ cảnh kỹ thuật chính:

• tf.distribute.MirroredStrategy là chiến lược phân phối (distribution strategy) của TensorFlow dùng cho multi-GPU trên cùng một máy (single machine). Nó sao chép (replicate) mô hình lên mỗi GPU, chia batch dữ liệu thành các micro-batch song song, tính gradient trên từng GPU, rồi đồng bộ (all-reduce) gradient để cập nhật mô hình chung.
• Vấn đề cốt lõi: Khi chuyển từ 1 GPU sang 4 GPU mà không tăng batch size, mỗi GPU chỉ xử lý phần nhỏ batch gốc (batch_size / 4), dẫn đến overhead cao từ đồng bộ và không tận dụng hết sức mạnh song song, khiến thời gian train không cải thiện (thậm chí chậm hơn do chi phí giao tiếp).
  (Kiến thức cập nhật TensorFlow 2.x đến 2026: MirroredStrategy vẫn là lựa chọn chuẩn cho multi-GPU local, theo TensorFlow 2.15+ và hướng dẫn distributed training mới nhất).

🟢 Đáp án đúng và lý do lựa chọn:
Increase the batch size.
✅ Lý do chi tiết: Khi sử dụng MirroredStrategy, để đạt tốc độ lý tưởng (linear scaling), cần tăng batch size tổng thể lên gấp 4 lần (hoặc tỷ lệ với số GPU). Ví dụ: Nếu batch size gốc là 128, tăng lên 512 cho 4 GPU → mỗi GPU xử lý 128 sample, tận dụng đầy công suất compute mà giảm tỷ lệ overhead đồng bộ. Không thay đổi khác, đây là bước đầu tiên và hiệu quả nhất theo best practice TensorFlow. Kết quả: Thời gian/step giảm đáng kể, tổng thời gian train ngắn hơn.

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

• ❌ [SAI] Distribute the dataset with tf.distribute.Strategy.experimental_distribute_dataset
  Phương án này không đúng vì experimental_distribute_dataset (nay là experimental_distribute_datasets_from_function trong TF 2.x mới) dùng để phân phối dataset thủ công qua strategy, nhưng MirroredStrategy đã tự động xử lý phân phối dataset khi gọi model.fit() với dataset. Vấn đề không phải dataset chưa phân phối (nó đã được replicate tự động), mà là batch size chưa scale, nên thêm bước này thừa thãi và không giải quyết tốc độ.

• ❌ [SAI] Create a custom training loop.
  Phương án không cần thiết vì Keras model.fit() hỗ trợ đầy đủ MirroredStrategy mà không cần custom loop. Custom loop (dùng @tf.function + GradientTape) chỉ hữu ích cho logic phức tạp (như mixed precision nâng cao), nhưng ở đây vấn đề đơn giản là batch size, không liên quan custom loop. Thêm custom loop chỉ tăng độ phức tạp mà không fix vấn đề gốc.

• ❌ [SAI] Use a TPU with tf.distribute.TPUStrategy.
  Phương án không phù hợp vì chuyển sang TPU và TPUStrategy yêu cầu môi trường Cloud TPU (Google Cloud), thay đổi hardware lớn, và có thể cần chỉnh sửa code (như XLA compilation). Vấn đề hiện tại là multi-GPU local chưa tối ưu, không phải thiếu TPU. Đây là overkill (quá mức cần thiết), không giải quyết trực tiếp mà chỉ là "thay đổi lớn" không liên quan AWS/GCP ngay lập tức.

• ✅ [ĐÚNG] Increase the batch size.
  Như đã giải thích ở trên: Giải pháp trực tiếp, hiệu quả nhất để scale MirroredStrategy, đảm bảo strong scaling (tốc độ tăng tỷ lệ nghịch với số GPU).

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

• TensorFlow Official Guide: Distributed Training 🛠️ tensorflow.org/guide/distributed_training – Giải thích rõ batch size scaling cho MirroredStrategy.
• TensorFlow Keras Multi-GPU Best Practices 📖 tensorflow.org/tutorials/distribute/multi_gpu_keras – Ví dụ thực tế tăng batch size x4 cho 4 GPU.
• AWS SageMaker hỗ trợ TensorFlow Distributed (liên quan chủ đề): docs.aws.amazon.com/sagemaker/latest/dg/distributed-training.html – Xác nhận nguyên tắc tương tự cho TF trên AWS (dùng SMDDP hoặc Horovod, nhưng MirroredStrategy cơ bản giống).
• TensorFlow 2.15+ Release Notes 🔄 tensorflow.org/news/news/2024-12-16-tf-2.16 – Không thay đổi core logic MirroredStrategy đến 2026.

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