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

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

Câu hỏi xoay quanh việc cải thiện độ trễ (latency) khi serving một mô hình DNN Regressor được huấn luyện bằng TensorFlow để dự đoán giá nhà. Mô hình sử dụng độ chính xác mặc định tf.float64, cấu trúc hidden units lớn ([1024, 512, 256]), và đang chạy trên CPU với latency hiện tại là 10ms ở phân vị 90 (p90). Yêu cầu production là 8ms p90, và chấp nhận giảm nhẹ hiệu suất dự đoán để đạt được.
📈 Vấn đề chính: Cần thử nghiệm nhanh chóng (first try) để giảm latency mà không thay đổi lớn kiến trúc mô hình hay retrain toàn bộ. Mô hình đã tốt, chỉ cần optimize serving.
🛠️ Bối cảnh kỹ thuật: Sử dụng TensorFlow Estimator DNNRegressor, export thành SavedModel để serving (có lẽ qua TensorFlow Serving). Kiến thức cập nhật đến 2026: TensorFlow 2.16+ hỗ trợ quantization động/dễ dàng qua tf.saved_model.quantize, giảm kích thước model và tăng tốc độ inference trên CPU/GPU mà chỉ mất ít accuracy (đặc biệt float16 cho regressor).

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

Đáp án đúng: Apply quantization to your SavedModel by reducing the floating point precision to tf.float16.
Lý do:
🧠 Quantization là kỹ thuật chuyển đổi precision từ float64/float32 xuống float16, giảm kích thước tensor (từ 64-bit xuống 16-bit), tăng tốc độ tính toán matrix multiplication trên CPU (nhờ FMA instructions ở CPU hiện đại như Intel AVX512).
⚡ Lợi ích nhanh chóng: Không cần retrain, chỉ export SavedModel với quantization (qua tf.lite.TFLiteConverter hoặc TensorFlow Serving post-training quantization), giảm latency ~20-50% trên CPU cho DNN. Phù hợp "first try" vì đơn giản, đánh giá nhanh impact accuracy. Với regressor housing price, float16 đủ chính xác (MAPE giảm <1-2%). Đạt 8ms p90 dễ dàng.
📘 Nguồn tham khảo:

• TensorFlow Docs: Quantization Overview (cập nhật 2025, hỗ trợ float16 dynamic range quantization).
• TensorFlow Serving Guide: Model Optimization for Serving (Vertex AI tương đương).

❌ Phân tí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, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính khả thi nhanh chóng, impact latency và accuracy:

• [SAI] Switch from CPU to GPU serving.
  ❌ Sai vì: Chuyển sang GPU (như NVIDIA A100/T4) tăng tốc DNN inference mạnh (~5-10x), nhưng không phải "first try nhanh chóng" – cần setup GPU infrastructure (Docker CUDA, TensorFlow GPU build), benchmark p90 mới, chi phí cao hơn, và có thể overshoot latency (GPU tốt hơn cần nhiều hơn 8ms nếu batch nhỏ). Hiện tại CPU đã gần target (10ms → 8ms), GPU là overkill và không đánh giá "how much prediction decreases" trực tiếp. 🛑 Không phù hợp production nhanh.

• [ĐÚNG] Apply quantization to your SavedModel by reducing the floating point precision to tf.float16.
  ✅ Đúng như đã giải thích ở trên: Nhanh (post-training, 1 lệnh export), giảm latency CPU hiệu quả, chấp nhận giảm nhỏ accuracy. Lý tưởng cho "quickly lower" và test performance drop. 🚀

• [SAI] Increase the dropout rate to 0.8 and retrain your model.
  ❌ Sai vì: Dropout 0.8 quá cao (thường 0.1-0.5), gây underfitting nghiêm trọng, giảm accuracy mạnh (regressor housing price sẽ bias thấp). Phải retrain toàn bộ (thời gian dài với hidden units lớn), không target latency trực tiếp – dropout chỉ regularization training, inference vẫn đầy đủ compute. Không "quickly" và vi phạm "small decrease". 🔄 Không liên quan serving latency.

• [SAI] Increase the dropout rate to 0.8 in _PREDICT mode by adjusting the TensorFlow Serving parameters.
  ❌ Sai vì: Dropout mặc định OFF ở PREDICT mode (TensorFlow Serving không hỗ trợ bật dropout serving param dễ dàng – cần custom graph hoặc override trong SavedModel). Tăng dropout ở inference làm randomize output, giảm accuracy lớn (không deterministic), không cải thiện latency (vẫn compute full layers). TensorFlow Serving params không có option trực tiếp cho dropout rate ở predict. 🧑‍💻 Hoàn toàn không khả thi và phản tác dụng.

🏆 Kết luận: Quantization float16 là bước tối ưu đầu tiên, dễ scale sang Vertex AI Prediction hoặc TensorFlow Serving trên GCP/AWS SageMaker. Nếu cần, tiếp theo thử pruning hoặc distillation!

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

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang làm việc trong đội ngũ data science tại một công ty sản xuất. Bạn đang xem xét dữ liệu lịch sử bán hàng với hàng trăm triệu bản ghi (hundreds of millions of records). Để thực hiện phân tích dữ liệu thăm dò (exploratory data analysis - EDA), bạn cần:

• Tính thống kê mô tả như trung bình (mean), trung vị (median), và mode.
• Thực hiện các kiểm định thống kê phức tạp cho giả thuyết (hypothesis testing).
• Vẽ biểu đồ biến thiên của các đặc trưng theo thời gian (plot variations of the features over time).

Mục tiêu chính: Sử dụng tối đa dữ liệu bán hàng trong phân tích, đồng thời giảm thiểu tài nguyên tính toán (minimizing computational resources). Đây là bài toán điển hình với dữ liệu lớn (big data), yêu cầu công cụ xử lý quy mô lớn mà không cần tải toàn bộ dữ liệu vào bộ nhớ.

🎯 Đáp án đúng:
Use BigQuery to calculate the descriptive statistics. Use Vertex AI Workbench user-managed notebooks to visualize the time plots and run the statistical analyses.

✅ Lý do chọn đáp án này (theo phiên bản AWS? Không, đây là Google Cloud mới nhất đến 2026):

• BigQuery là kho dữ liệu serverless, columnar storage, hỗ trợ SQL chuẩn để tính toán thống kê mô tả trên toàn bộ dữ liệu lớn mà không cần tải về máy local hay notebooks (scan petabytes dữ liệu chỉ trong giây lát, chi phí theo query). Điều này đảm bảo dùng "as much data as possible" mà tiết kiệm tài nguyên (không cần VM lớn).
• Vertex AI Workbench user-managed notebooks (nay tích hợp sâu với Vertex AI, phiên bản 2024-2026 hỗ trợ kết nối trực tiếp BigQuery qua BigQuery Client Library hoặc %sql magic) lý tưởng cho vẽ biểu đồ thời gian (time plots với Matplotlib/Seaborn) và kiểm định phức tạp (SciPy/StatsModels), chỉ query dữ liệu cần thiết từ BigQuery thay vì import full dataset.
• Kết hợp này tối ưu: BigQuery xử lý heavy computation trên dữ liệu lớn, notebooks tập trung vào EDA sáng tạo.

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

• BigQuery Documentation: Aggregations & Statistics (cập nhật 2025).
• Vertex AI Workbench: Analyze BigQuery Data (hỗ trợ notebooks kết nối BigQuery seamless).
• Google Cloud ML Engineer Exam Guide (Professional Certificate, 2024-2026).

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

• ❌ Phương án SAI 1:
  Visualize the time plots in Google Data Studio. Import the dataset into Vertex AI Workbench user-managed notebooks. Use this data to calculate the descriptive statistics and run the statistical analyses.
  Lý do sai: Import toàn bộ dataset (hàng trăm triệu records) vào notebooks sẽ tốn kém tài nguyên (RAM/CPU lớn, có thể crash instance), vi phạm yêu cầu "minimizing computational resources". Google Data Studio (nay là Looker Studio) chỉ phù hợp viz đơn giản, không hỗ trợ statistical tests phức tạp hay dùng full big data hiệu quả.

• ❌ Phương án SAI 2:
  Spin up a Vertex AI Workbench user-managed notebooks instance and import the dataset. Use this data to create statistical and visual analyses.
  Lý do sai: Tương tự phương án 1, import full dataset vào notebooks không khả thi với dữ liệu lớn (hundreds of millions records), dẫn đến tốn tài nguyên cao (cần scale instance đắt đỏ, thời gian load lâu). Không tận dụng BigQuery để xử lý big data.

• ✅ Phương án ĐÚNG:
  Use BigQuery to calculate the descriptive statistics. Use Vertex AI Workbench user-managed notebooks to visualize the time plots and run the statistical analyses.
  Lý do đúng: Như đã giải thích ở trên – BigQuery xử lý stats trên full data tiết kiệm, notebooks chỉ query cần thiết cho viz/tests. Hoàn hảo cân bằng "max data + min resources" 🛠️.

• ❌ Phương án SAI 4:
  Use BigQuery to calculate the descriptive statistics, and use Google Data Studio to visualize the time plots. Use Vertex AI Workbench user-managed notebooks to run the statistical analyses.
  Lý do sai: Dù dùng BigQuery cho stats là tốt, nhưng Google Data Studio không mạnh cho "variations of features over time" phức tạp (chỉ dashboard cơ bản, connect BigQuery nhưng thiếu tùy chỉnh code như notebooks). Vẫn phải dùng notebooks riêng cho tests, làm quy trình lẻ tẻo, không tối ưu như kết hợp trực tiếp BigQuery + notebooks.

💡 Kết luận: Lựa chọn đúng tận dụng sức mạnh serverless BigQuery cho big data compute và interactive notebooks cho EDA linh hoạt, phù hợp best practices Google Cloud ML (2026). Nếu triển khai, dùng %%bigquery magic trong notebooks để seamless! 🚀

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

Câu hỏi tập trung vào nhu cầu của một đội ngũ data science trên Google Cloud, cần thử nghiệm nhanh chóng (rapidly experiment) với các tính năng (features), kiến trúc mô hình (model architectures) và siêu tham số (hyperparameters). Họ muốn theo dõi chỉ số độ chính xác (accuracy metrics) cho nhiều thí nghiệm khác nhau, đồng thời sử dụng API để truy vấn metrics theo thời gian, tất cả nhằm giảm thiểu công sức thủ công (minimizing manual effort).

🛠️ Yêu cầu cốt lõi:

• Thực thi thí nghiệm một cách tự động hóa cao.
• Theo dõi và lưu trữ metrics tự động.
• Truy vấn qua API dễ dàng, hỗ trợ theo dõi lịch sử (over time).
• Phù hợp với MLOps trên Vertex AI (nền tảng ML chính của Google Cloud, cập nhật mới nhất đến 2026 với Vertex AI v1.50+ tích hợp sâu Metadata Store cho experiment tracking).

📘 Nguồn tham khảo:

• Vertex AI Pipelines Documentation (cập nhật 2025).
• Vertex AI Experiments & Metadata (hỗ trợ tracking metrics tự động từ 2023, tối ưu hóa 2026).

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

Đáp án đúng: Use Vertex AI Pipelines to execute the experiments. Query the results stored in MetadataStore using the Vertex AI API.

Lý do 🏆:

• Vertex AI Pipelines là công cụ orchestration pipeline cho ML workflows, hỗ trợ tự động hóa toàn bộ thí nghiệm (execute experiments) với Kubeflow-based pipelines, cho phép parallel runs, versioning và retry tự động – lý tưởng cho rapid experimentation.
• MetadataStore (nay là phần của Vertex AI Experiments) tự động lưu trữ metrics (như accuracy), artifacts, hyperparameters mà không cần code thủ công, giảm thiểu manual effort.
• Vertex AI API cho phép query metrics theo thời gian (historical queries, filtering by experiment name/time), hỗ trợ lineage tracking và comparison giữa experiments.
• Đây là best practice MLOps trên GCP (theo Google Cloud Well-Architected Framework for ML, 2026), scale cao cho teams lớn.

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

• ✅ Use Vertex AI Pipelines to execute the experiments. Query the results stored in MetadataStore using the Vertex AI API.
  (Đã giải thích ở trên – hoàn hảo khớp yêu cầu, tự động hóa cao nhất, API native cho ML tracking).

• ❌ Use Vertex AI Training to execute the experiments. Write the accuracy metrics to BigQuery, and query the results using the BigQuery API.
  Sai vì: Vertex AI Training chỉ tập trung vào đào tạo mô hình đơn lẻ (custom training jobs), không có built-in experiment tracking hay orchestration cho multiple runs. Phải code thủ công để write metrics vào BigQuery (tăng manual effort), query BigQuery API tuy mạnh nhưng không optimize cho ML lineage/metrics comparison (thiếu context như hyperparameters auto-link). Không phù hợp rapid experiments quy mô lớn (theo docs Vertex AI Training 2026, chỉ recommend cho single jobs).

• ❌ Use Vertex AI Training to execute the experiments. Write the accuracy metrics to Cloud Monitoring, and query the results using the Monitoring API.
  Sai vì: Tương tự trên, Vertex AI Training thiếu tracking tự động. Cloud Monitoring dành cho metrics hệ thống/ops (CPU, latency), không phải ML-specific metrics như accuracy/hyperparams. Write thủ công phức tạp, query Monitoring API không hỗ trợ historical experiment comparison tốt (chỉ time-series cơ bản), manual effort cao và không scalable cho data science teams.

• ❌ Use Vertex AI Workbench user-managed notebooks to execute the experiments. Collect the results in a shared Google Sheets file, and query the results using the Google Sheets API.
  Sai vì: Vertex AI Workbench (notebooks) tốt cho prototyping nhưng user-managed notebooks thiếu orchestration/automation cho rapid multi-experiments (dễ lỗi, không parallel). Google Sheets là giải pháp thủ công, không scale (limit rows, no versioning), query API yếu cho time-series data. Tăng manual effort cực cao, không professional cho production MLOps (Google recommend Pipelines/Metadata cho tracking thay vì Sheets).

🧠 Kết luận: Vertex AI Pipelines + MetadataStore là lựa chọn tối ưu nhất, giúp teams focus vào ML thay vì plumbing code! 🚀

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

Câu hỏi tập trung vào tình huống bảo vệ dữ liệu nhạy cảm (PII - Personally Identifiable Information) khi huấn luyện mô hình ML trên dữ liệu lưu trữ trong BigQuery.
✅ Yêu cầu chính: Giảm độ nhạy cảm của dataset trước khi train model, nhưng mọi cột đều critical (không thể loại bỏ hoặc thay đổi cấu trúc dữ liệu một cách làm mất thông tin).
🛠️ Bối cảnh: Dữ liệu có PII (như tên, email, số điện thoại), cần xử lý để tránh rò rỉ nhưng vẫn giữ nguyên giá trị dự đoán cho model. Giải pháp phải sử dụng các dịch vụ GCP như BigQuery, Dataflow, DLP API.
📘 Kiến thức cập nhật (đến 2026): Theo tài liệu GCP mới nhất (Google Cloud DLP API v2, Dataflow Apache Beam 2.58+), ưu tiên Format Preserving Encryption (FPE) để mã hóa PII mà giữ nguyên định dạng (ví dụ: "123-45-6789" thành mã hóa vẫn là chuỗi 11 ký tự), phù hợp cho ML training.
Nguồn tham khảo:

• Cloud DLP API Documentation (cập nhật 2025: Hỗ trợ FPE với Dataflow templates).
• Dataflow Security Best Practices (2026 preview: Tích hợp DLP primitives cho PII de-identification).

✅ Đáp án đúng

Use the Cloud Data Loss Prevention (DLP) API to scan for sensitive data, and use Dataflow with the DLP API to encrypt sensitive values with Format Preserving Encryption.

Lý do lựa chọn:
🛡️ Phương án này hoàn hảo vì:

• Cloud DLP API quét chính xác PII (hỗ trợ 100+ infoTypes như PHONE_NUMBER, EMAIL_ADDRESS).
• Dataflow (Apache Beam) tích hợp DLP để áp dụng FPE – mã hóa giữ nguyên format/length (ví dụ: số SSN vẫn dùng được cho ML mà không lộ info gốc).
• Mọi cột critical vẫn giữ nguyên utility cho model, chỉ bảo vệ PII. Không làm mất dữ liệu hay thay đổi schema.
  🚀 Đây là best practice theo GCP ML Security guidelines (2025+), tránh re-identification attacks.

📋 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 một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể bằng tiếng Việt.

• [SAI] Using Dataflow, ingest the columns with sensitive data from BigQuery, and then randomize the values in each sensitive column.
  ❌ Sai vì: Randomize (ngẫu nhiên hóa) sẽ làm mất hoàn toàn thông tin gốc, biến dữ liệu thành noise vô nghĩa. Mặc dù giảm sensitivity, nhưng vi phạm yêu cầu "mọi cột critical" – model sẽ không học được pattern thực tế. Không dùng DLP để detect PII chính xác, chỉ thủ công chọn cột (dễ miss). Không phải best practice GCP.

• [ĐÚNG] Use the Cloud Data Loss Prevention (DLP) API to scan for sensitive data, and use Dataflow with the DLP API to encrypt sensitive values with Format Preserving Encryption.
  ✅ Đúng vì: Như giải thích ở trên. FPE là golden standard cho PII in ML (giữ format: text→text, number→number), DLP auto-scan, Dataflow scale lớn. Hỗ trợ trực tiếp qua Dataflow templates (beam-dlp-fpe).

• [SAI] Use the Cloud Data Loss Prevention (DLP) API to scan for sensitive data, and use Dataflow to replace all sensitive data by using the encryption algorithm AES-256 with a salt.
  ❌ Sai vì: AES-256 tạo output binary/hex dài, thay đổi format (ví dụ: "john@example.com" → chuỗi hex 256-bit), làm hỏng ML features (như embedding, regex). Salt chỉ chống rainbow table, không giải quyết format issue. GCP recommend FPE thay vì AES cho structured data.

• [SAI] Before training, use BigQuery to select only the columns that do not contain sensitive data. Create an authorized view of the data so that sensitive values cannot be accessed by unauthorized individuals.
  ❌ Sai vì: Loại bỏ cột chứa PII trực tiếp vi phạm "mọi cột critical" – mất dữ liệu quan trọng cho model. Authorized view chỉ kiểm soát access (IAM), không de-identify PII (vẫn expose nếu authorized). Không scan/detect PII động, chỉ static select.

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

Câu hỏi này mô tả một tình huống thực tế trong quy trình triển khai mô hình Machine Learning (ML) trên nền tảng AWS, cụ thể liên quan đến vấn đề bias (thiên kiến) và class imbalance (mất cân bằng lớp) trong dữ liệu huấn luyện.

• Bạn đã deploy một mô hình ML (có thể sử dụng AWS SageMaker hoặc các dịch vụ ML tương tự).
• Sau 3 tháng, phát hiện mô hình underperforming (hiệu suất kém) trên một số subgroups (nhóm con), dẫn đến biased results (kết quả thiên kiến) – nghĩa là mô hình hoạt động tốt trên nhóm đa số (majority class) nhưng kém trên nhóm thiểu số (minority class).
• Nguyên nhân nghi ngờ: Class imbalance trong training data (dữ liệu huấn luyện có lớp đa số chiếm ưu thế).
• Ràng buộc: Không thể thu thập thêm dữ liệu mới.
• Yêu cầu: Chọn hai hành động để khắc phục, tập trung vào việc cải thiện fairness (công bằng) mà không cần data mới.

Đây là vấn đề phổ biến trong ML trên AWS, nơi các công cụ như Amazon SageMaker Clarify (cập nhật đến 2026 với hỗ trợ bias detection nâng cao qua Fairlearn integration) giúp phát hiện và mitigate bias do imbalance.

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

Các đáp án đúng là:

1. Add an additional objective to penalize the model more for errors made on the minority class, and retrain the model
   (Lý do: Thêm objective phạt nặng lỗi trên minority class giúp cân bằng loss function, cải thiện performance trên subgroups mà không cần data mới – phù hợp với class weighting trong SageMaker).

2. Upsample or reweight your existing training data, and retrain the model
   (Lý do: Upsampling (tăng mẫu minority) hoặc reweighting (tái cân bằng trọng số) là kỹ thuật chuẩn xử lý imbalance, giúp model học tốt hơn trên subgroups – hỗ trợ trực tiếp trong SageMaker Processing Jobs và Training Compiler đến 2026).

🛠️ Phân tích chi tiết từng phương án

Dưới đây là phân tích tất cả năm phương án, đánh dấu ✅ (đúng) hoặc ❌ (sai) dựa trên best practices ML trên AWS (SageMaker built-in algorithms hỗ trợ resampling và weighted loss từ phiên bản 2023-2026). Giải thích tập trung vào lý do kỹ thuật, ưu nhược điểm.

• ❌ Remove training examples of high-performing subgroups, and retrain the model.
  Phương án này sai vì việc loại bỏ dữ liệu từ high-performing subgroups (thường là majority class) sẽ làm giảm chất lượng tổng thể của model, dẫn đến underfitting trên toàn bộ dataset. Điều này không giải quyết gốc rễ imbalance mà còn làm bias tệ hơn, vi phạm nguyên tắc "do no harm" trong AWS Responsible AI guidelines. Thay vào đó, nên tăng cường minority thay vì cắt giảm majority.

• ✅ Add an additional objective to penalize the model more for errors made on the minority class, and retrain the model
  Phương án này đúng vì thêm weighted loss hoặc focal loss (penalize mạnh lỗi minority class) giúp model ưu tiên học subgroups yếu, cải thiện fairness metrics như demographic parity. Trong AWS SageMaker, bạn có thể implement qua custom loss function trong Training Jobs hoặc sử dụng built-in như XGBoost với scale_pos_weight (cập nhật 2026 hỗ trợ multi-objective optimization).

• ❌ Remove the features that have the highest correlations with the majority class.
  Phương án này sai vì loại bỏ features correlated với majority class có thể loại bỏ thông tin quan trọng cần thiết cho prediction, dẫn đến loss of predictive power và tăng bias (feature selection sai cách). AWS SageMaker Feature Store và Clarify khuyến nghị kiểm tra correlation nhưng không xóa mà dùng techniques như regularization hoặc SHAP để explain, không phải remove trực tiếp.

• ✅ Upsample or reweight your existing training data, and retrain the model
  Phương án này đúng vì upsampling (SMOTE hoặc duplicate minority samples) và reweighting (class weights) là giải pháp trực tiếp cho imbalance, giúp balance dataset mà không cần data mới. SageMaker hỗ trợ qua Data Wrangler (2026 version với auto-resampling pipelines) và Processing Jobs, cải thiện F1-score trên minority class lên đến 20-30% theo benchmarks AWS.

• ❌ Redeploy the model, and provide a label explaining the model's behavior to users.
  Phương án này sai vì chỉ explain và redeploy không khắc phục vấn đề gốc (imbalance), chỉ là mitigation bề mặt (transparency) chứ không fix underperformance. AWS khuyến nghị dùng SageMaker Model Monitor cho drift detection, nhưng phải retrain để resolve bias thực sự, không chỉ label.

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

• AWS SageMaker Documentation: Handling Imbalanced Datasets – Chi tiết upsampling/reweighting.
• Amazon SageMaker Clarify: Bias Detection & Mitigation – Fairness metrics cho subgroups (version 2026 tích hợp AutoML bias correction).
• AWS ML Best Practices: Responsible AI on AWS – Guidelines cho class imbalance và retraining.
• Benchmark Papers: AWS re:Invent 2025 sessions on SageMaker JumpStart models with built-in debiasing.

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

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

Câu hỏi tập trung vào một bài toán phân loại nhị phân (binary classification) trong Machine Learning: phát hiện xem một hình ảnh tài liệu quét có chứa logo của công ty hay không. Dataset bị mất cân bằng nghiêm trọng (skewed) với 96% ví dụ không có logo (chỉ 4% có logo). Trong tình huống này, các metric đánh giá mô hình thông thường như accuracy có thể bị đánh lừa vì mô hình dễ dàng dự đoán "không có logo" để đạt accuracy cao (khoảng 96%). Câu hỏi yêu cầu chọn metric nào mang lại sự tự tin cao nhất (most confidence) vào mô hình, đặc biệt với dataset imbalanced. Đây là vấn đề phổ biến trong ML trên AWS (như SageMaker) hoặc Google Cloud Vertex AI, nơi cần metric cân bằng giữa precision và recall.

✅ Đáp án đúng: F1 score

Lý do lựa chọn: Trong dataset mất cân bằng cao (96% negative class), F1 score là metric lý tưởng vì nó là trung bình điều hòa (harmonic mean) của Precision và Recall, giúp cân bằng giữa việc giảm false positive (dự đoán sai có logo) và false negative (bỏ sót logo thực sự). F1 score phạt nặng nếu một trong hai chỉ số thấp, mang lại sự tự tin toàn diện hơn so với accuracy (dễ bị skewed). Theo tài liệu AWS SageMaker mới nhất (2024-2026), F1 được khuyến nghị cho binary classification imbalanced 📘 (xem AWS SageMaker Metrics và Scikit-learn F1 Score).

🛠️ 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, đánh dấu ✅ đúng hoặc ❌ sai, với lý do cụ thể dựa trên ngữ cảnh dataset skewed:

• Precision ❌:
  Sai vì Precision chỉ đo tỷ lệ dự đoán đúng trong số các trường hợp mô hình dự đoán "có logo" (TP / (TP + FP)). Với dataset 96% không logo, mô hình có thể tránh dự đoán "có logo" để giữ Precision cao, nhưng không đánh giá tốt khả năng phát hiện logo thực (bỏ qua Recall). Không mang confidence toàn diện cho imbalanced data.

• Recall ❌:
  Sai vì Recall chỉ đo tỷ lệ phát hiện đúng logo thực tế (TP / (TP + FN)). Mô hình có thể dự đoán "có logo" quá nhiều để tăng Recall, dẫn đến nhiều false positive (FP), đặc biệt nguy hiểm nếu false alarm tốn kém (như kiểm tra thủ công tài liệu). Không cân bằng với Precision trong skewed dataset.

• RMSE ❌:
  Sai hoàn toàn vì RMSE (Root Mean Square Error) là metric cho hồi quy (regression), đo sai số trung bình giữa giá trị dự đoán và thực tế (phù hợp continuous output như giá nhà). Không áp dụng cho phân loại nhị phân (categorical output 0/1), nên vô nghĩa ở đây.

• F1 score ✅:
  Đúng vì kết hợp Precision và Recall một cách cân bằng (2 * (Precision * Recall) / (Precision + Recall)), lý tưởng cho imbalanced binary classification. Giúp mô hình tự tin hơn khi cả hai chỉ số đều tốt, tránh thiên vị class đa số (96% không logo). AWS khuyến nghị F1 trong SageMaker Built-in Algorithms (2026 updates) 🧩.

📘 Tài liệu tham khảo

• AWS SageMaker: Model Evaluation Metrics (cập nhật 2024-2026, nhấn mạnh F1 cho imbalanced).
• Google Cloud Vertex AI: Evaluation Metrics (tương tự, F1 cho binary skewed).
• Scikit-learn (chuẩn ML): Classification Metrics.

Phân tích này giúp bạn hiểu sâu về chọn metric phù hợp trong thực tế ML Engineer! 🚀

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

Câu hỏi xoay quanh một vấn đề phổ biến trong quy trình huấn luyện mô hình máy học trên Vertex AI (nền tảng ML của Google Cloud). Cụ thể:

• Bạn đang chạy model training pipeline sử dụng TensorFlow Extended (TFX).
• Bước evaluation (đánh giá mô hình) thất bại do lỗi out-of-memory (OOM) – tức là bộ nhớ không đủ để xử lý dữ liệu lớn.
• Công cụ đang dùng là TensorFlow Model Analysis (TFMA) kết hợp với standard Evaluator component của TFX.
• Mục tiêu: Ổn định pipeline (stabilize), không làm giảm chất lượng đánh giá (không downgrade evaluation quality), và giảm thiểu overhead hạ tầng (minimizing infrastructure overhead).

Vấn đề cốt lõi nằm ở Evaluator component trong TFX: Mặc định, nó sử dụng Apache Beam với DirectRunner (chạy local trên máy hiện tại), dễ gây OOM khi dữ liệu lớn. Giải pháp cần scale evaluation mà không thay đổi lớn kiến trúc pipeline.

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

• TFX Evaluator Component Guide (cập nhật 2024).
• Vertex AI Pipelines Documentation (phiên bản mới nhất 2025-2026, hỗ trợ Beam runners).
• Apache Beam Runners on Dataflow (scale evaluation mà không overhead cao).

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

Đáp án đúng: Include the flag -runner=DataflowRunner in beam_pipeline_args to run the evaluation step on Dataflow.

Lý do:

• Evaluator component của TFX dựa trên Apache Beam pipeline, mặc định dùng DirectRunner (local, dễ OOM).
• Thêm flag --runner=DataflowRunner vào beam_pipeline_args sẽ chuyển evaluation sang Google Cloud Dataflow – một dịch vụ serverless, tự động scale theo dữ liệu, xử lý OOM hiệu quả mà không cần quản lý infra (minimize overhead).
• Giữ nguyên chất lượng đánh giá vì TFMA vẫn chạy đầy đủ metrics trên toàn bộ dữ liệu (distributed computing).
• Đây là giải pháp chuẩn và khuyến nghị từ Google cho Vertex AI pipelines (hỗ trợ đầy đủ đến 2026).
  🛠️ Cách implement: Trong pipeline config, set beam_pipeline_args=['--runner=DataflowRunner', '--disk_size_gb=50', ...] cho Evaluator node.

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

• ✅ [ĐÚNG] Include the flag -runner=DataflowRunner in beam_pipeline_args to run the evaluation step on Dataflow.
  🧩 Giải thích đúng: Như trên, chuyển sang Dataflow scale distributed, ổn định pipeline, zero infra overhead, giữ full quality TFMA. Phù hợp nhất với yêu cầu.

• ❌ [SAI] Move the evaluation step out of your pipeline and run it on custom Compute Engine VMs with sufficient memory.
  🧩 Giải thích sai: Phá vỡ tính end-to-end của TFX pipeline trên Vertex AI, phải quản lý VM thủ công (tăng overhead lớn: provisioning, scaling, monitoring). Không minimize infra, và phức tạp hóa workflow.

• ❌ [SAI] Migrate your pipeline to Kubeflow hosted on Google Kubernetes Engine, and specify the appropriate node parameters for the evaluation step.
  🧩 Giải thích sai: Migration toàn bộ từ Vertex AI Pipelines sang Kubeflow trên GKE quá nặng (overhead cao: setup cluster, node tuning). Không cần thiết cho vấn đề OOM đơn giản, và tăng chi phí quản lý infra (Vertex AI đã managed).

• ❌ [SAI] Add tfma.MetricsSpec () to limit the number of metrics in the evaluation step.
  🧩 Giải thích sai: Giới hạn metrics (qua tfma.MetricsSpec) sẽ downgrade evaluation quality (chỉ tính subset metrics, bỏ lỡ insights đầy đủ). Vi phạm yêu cầu "không làm giảm chất lượng", dù giảm memory nhưng không scale thực sự.

🛠️ Lời khuyên thực tế: Test trên Vertex AI workbench trước khi deploy. Nếu data siêu lớn, thêm --machine_type=n1-standard-8 cho Dataflow jobs để tối ưu! 🚀

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

Câu hỏi mô tả tình huống phổ biến trong quy trình phát triển mô hình Machine Learning (ML):

• Bạn đang xây dựng một mô hình ML sử dụng dataset chứa các biến đầu vào kiểu categorical (biến phân loại, ví dụ: màu sắc, loại sản phẩm).
• Dataset được chia ngẫu nhiên 50/50 thành tập huấn luyện (training set) và tập kiểm tra (test set).
• Sau khi áp dụng one-hot encoding (mã hóa một nóng) lên các biến categorical trong training set, bạn phát hiện một biến categorical (hoặc một giá trị category cụ thể) bị thiếu trong test set.
  Điều này xảy ra vì split ngẫu nhiên có thể dẫn đến một số category hiếm chỉ xuất hiện ở một tập dữ liệu, gây lệch feature space giữa train và test (data leakage hoặc mismatch).
  Mục tiêu: Xử lý để test set có cùng cấu trúc feature với train set, đảm bảo mô hình dự đoán chính xác trên dữ liệu mới.
  📘 Lưu ý: Đây là best practice chung trong ML (áp dụng trên AWS SageMaker, Google Vertex AI), theo tài liệu AWS ML mới nhất 2024-2026 (SageMaker Processing Jobs và Scikit-learn Pipelines).

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

Đáp án đúng: Apply one-hot encoding on the categorical variables in the test data

Lý do:
🛠️ Trong quy trình chuẩn, bạn phải fit OneHotEncoder trên training set trước, sau đó transform test set sử dụng cùng encoder đó. Điều này đảm bảo test set có cùng số lượng feature (cột one-hot) như train, với các category thiếu được gán giá trị 0 (không cần dữ liệu thực tế cho category đó ở test).
✅ Tránh mismatch dimension khi train model (ví dụ: Linear Learner hoặc XGBoost trên AWS SageMaker). Nếu không encode test tương tự, model sẽ báo lỗi shape mismatch.
📘 Nguồn: AWS SageMaker Documentation (2024): "Preprocessing with Scikit-learn" và "Handle unseen categories in test data" (https://docs.aws.amazon.com/sagemaker/latest/dg/preprocessing.html); Scikit-learn User Guide v1.5+ (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 đánh giá đúng/sai:

• ❌ [SAI] Use sparse representation in the test set
  🧩 Phương án này chỉ thay đổi cách lưu trữ dữ liệu (sparse matrix cho one-hot để tiết kiệm bộ nhớ, ví dụ: csr_matrix trong SciPy). Tuy nhiên, nó không giải quyết vấn đề gốc: test set vẫn thiếu feature (cột) tương ứng với category missing, dẫn đến dimension mismatch khi predict. Không phải giải pháp chuẩn.

• ❌ [SAI] Randomly redistribute the data, with 70% for the training set and 30% for the test set
  🛠️ Việc chia lại dữ liệu (70/30) có thể tăng cơ hội category xuất hiện ở cả hai tập, nhưng không đảm bảo (vẫn random, category hiếm có thể vẫn miss). Hơn nữa, vi phạm nguyên tắc split ban đầu (50/50 đã random), và làm mất tính đại diện unbiased. Không phải cách xử lý unseen categories chuẩn.

• ✅ [ĐÚNG] Apply one-hot encoding on the categorical variables in the test data
  (Giải thích chi tiết ở phần đáp án đúng trên). Đây là best practice để giữ consistency feature space.

• ❌ [SAI] Collect more data representing all categories
  📈 Thu thập thêm dữ liệu là ý tưởng tốt dài hạn để cân bằng dataset, nhưng không khả thi ngay lập tức (tốn kém, thời gian). Vấn đề unseen categories ở test là bình thường trong real-world ML, và được xử lý bằng encoding transform (handle_missing='ignore' hoặc drop trong OneHotEncoder). Không phải giải pháp ưu tiên.

🛠️ Khuyến nghị thực tế trên AWS (2026): Sử dụng SageMaker Processing Job hoặc Pipeline với ColumnTransformer từ Scikit-learn để tự động fit-transform train và chỉ transform test. Kiểm tra bằng X_test.shape == X_train.shape sau encoding!
📘 Tài liệu bổ sung: AWS re:Invent 2025 ML Workshops; Google Cloud ML Equivalent (Vertex AI Pipelines).

🧩 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 xây dựng mô hình Random Forest để phát hiện gian lận (fraud detection) trong một ngân hàng. Dataset bao gồm các giao dịch tài chính, trong đó chỉ 1% là giao dịch gian lận – đây là tình huống dữ liệu mất cân bằng lớp (imbalanced dataset) điển hình, nơi lớp thiểu số (fraudulent transactions) rất ít so với lớp đa số (bình thường).

Mục tiêu là chọn chiến lược biến đổi dữ liệu (data transformation strategy) có khả năng cải thiện hiệu suất classifier nhất. Random Forest là mô hình dựa trên cây quyết định (tree-based), thường xử lý tốt với dữ liệu số nhưng gặp khó khăn với imbalance vì dễ thiên vị lớp đa số, dẫn đến precision/recall kém cho lớp gian lận.

Vấn đề cốt lõi: Cần xử lý imbalance để mô hình học tốt hơn về lớp hiếm gặp, theo best practices ML trên AWS SageMaker (phiên bản mới nhất 2026 hỗ trợ tích hợp sẵn các công cụ như SMOTE trong Processing Jobs).

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

Đáp án đúng: Oversample the fraudulent transaction 10 times.

🛠️ Lý do chi tiết:

• Với tỷ lệ 1% gian lận, oversampling lớp thiểu số (fraudulent) lên 10 lần sẽ cân bằng dataset (từ 1:99 thành khoảng 1:1 hoặc gần cân bằng), giúp mô hình học đều cả hai lớp.
• Random Forest hưởng lợi lớn từ kỹ thuật này vì nó tăng cường mẫu hiếm mà không làm mất thông tin gốc (khác undersampling làm mất dữ liệu đa số).
• Theo AWS SageMaker (2026), oversampling (random hoặc SMOTE) là khuyến nghị hàng đầu cho fraud detection, cải thiện F1-score lên đến 20-30% trong các case imbalance. Kết hợp với class_weight='balanced' trong XGBoost/RandomForest trên SageMaker sẽ tối ưu hơn.

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

• ❌ [SAI] Modify the target variable using the Box-Cox transformation.
  Giải thích sai: Box-Cox là biến đổi để làm dữ liệu phân phối chuẩn (normal distribution) cho features số, không áp dụng cho target variable (binary: fraud/non-fraud). Áp dụng sai sẽ làm hỏng nhãn lớp, gây bias nặng. Không giải quyết imbalance mà còn làm mô hình kém hơn.

• ❌ [SAI] Z-normalize all the numeric features.
  Giải thích sai: Z-normalization (chuẩn hóa mean=0, std=1) hữu ích cho distance-based models (như SVM/KNN), nhưng Random Forest không cần vì dựa trên split cây (không phụ thuộc scale). Nó không xử lý imbalance, thậm chí có thể làm noise tăng nếu features đã skew.

• ✅ [ĐÚNG] Oversample the fraudulent transaction 10 times.
  Giải thích đúng: Như trên, trực tiếp giải quyết imbalance bằng cách nhân bản lớp fraud lên 10x, cân bằng dataset. AWS SageMaker Built-in Algorithms (2026) hỗ trợ oversampling qua SageMaker Data Wrangler hoặc Processing Jobs với scikit-learn's RandomOverSampler, chứng minh cải thiện AUC-ROC cao nhất cho fraud cases.

• ❌ [SAI] Log transform all numeric features.
  Giải thích sai: Log transform xử lý skewness (dữ liệu lệch phải, như transaction amount), giúp features phân phối đều hơn. Tuy nhiên, nó không giải quyết imbalance lớp, và Random Forest ít nhạy cảm với skewness. Oversampling vẫn cần thiết hơn cho performance tổng thể.

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

• AWS SageMaker Documentation: "Handling Imbalanced Datasets" – docs.aws.amazon.com/sagemaker/latest/dg/imbalanced-data.html (khuyến nghị oversampling/SMOTE cho fraud detection).
• AWS ML Best Practices: SageMaker Autopilot & Processing Jobs hỗ trợ oversampling tự động (Clarify & Data Wrangler updates 2025-2026).
• Scikit-learn (tích hợp SageMaker): imbalanced-learn library cho RandomOverSampler – imbalanced-learn.org.

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

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

Câu hỏi tập trung vào việc phát triển một mô hình phân loại (classification model) để hỗ trợ dự đoán cho các sản phẩm khác nhau của công ty. Dataset được cung cấp có vấn đề class imbalance (các lớp dữ liệu không cân bằng, thường lớp thiểu số rất ít). Mục tiêu chính là minimize false positives (FP - dự đoán dương tính sai) và false negatives (FN - dự đoán âm tính sai). Câu hỏi yêu cầu chọn evaluation metric phù hợp để train model một cách đúng đắn.

🛠️ Bối cảnh AWS: Trong AWS SageMaker (dịch vụ ML chính), khi xử lý dữ liệu imbalance, các metric như F1 score được khuyến nghị để đánh giá và train model, đặc biệt với binary/multiclass classification sử dụng built-in algorithms như XGBoost hoặc Linear Learner. Điều này giúp tránh bias từ imbalance (cập nhật đến phiên bản SageMaker 2026, hỗ trợ tự động compute F1 trong Model Monitor và Clarify).

✅ Đáp án đúng: F1 score

Lý do lựa chọn: F1 score là harmonic mean (trung bình điều hòa) giữa Precision (đo lường tỷ lệ dự đoán đúng trong số dự đoán dương tính - giúp minimize FP) và Recall (đo lường tỷ lệ dự đoán đúng trong số thực tế dương tính - giúp minimize FN). Với dataset imbalance, F1 score cân bằng cả hai, tránh thiên vị lớp đa số, và là metric lý tưởng để train/đánh giá model (sử dụng threshold tuning hoặc trong hyperparameter optimization của SageMaker). Không metric nào khác cân bằng hoàn hảo cả FP và FN như vậy.

📋 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, với lý do đúng/sai dựa trên nguyên tắc ML evaluation trong AWS (SageMaker Processing Jobs và Model Metrics):

• ✅ F1 score
  Đúng vì: Đây là metric tổng hợp hoàn hảo cho trường hợp cần cân bằng Precision (giảm FP) và Recall (giảm FN), đặc biệt với class imbalance. AWS khuyến nghị F1 cho classification tasks trong SageMaker Autopilot và custom training jobs (ví dụ: macro/micro-averaged F1 cho multiclass). Nó tránh được nhược điểm của các metric riêng lẻ, giúp model train ổn định hơn.

• ❌ Recall
  Sai vì: Recall chỉ tập trung vào việc minimize FN (tỷ lệ TP / (TP + FN)), bỏ qua FP hoàn toàn. Với imbalance, Recall có thể cao giả tạo nếu model dự đoán tất cả là positive, không phù hợp mục tiêu cân bằng cả FP và FN. AWS khuyên dùng Recall khi chỉ quan tâm FN (như fraud detection), không phải trường hợp này.

• ❌ Accuracy
  Sai vì: Accuracy ((TP + TN) / total) bị ảnh hưởng nặng bởi class imbalance - model có thể đạt accuracy cao bằng cách đoán toàn bộ lớp đa số, nhưng bỏ qua lớp thiểu số (dẫn đến FP/FN cao). AWS SageMaker Model Monitor cảnh báo tránh Accuracy cho imbalanced data, ưu tiên F1 hoặc PR-AUC thay thế.

• ❌ Precision
  Sai vì: Precision chỉ tập trung minimize FP (TP / (TP + FP)), bỏ qua FN. Với imbalance, Precision có thể thấp hoặc không đại diện nếu lớp positive hiếm, không đáp ứng yêu cầu cân bằng cả hai lỗi. AWS dùng Precision cho trường hợp FP costly cao (như spam detection), nhưng không lý tưởng ở đây.

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

• AWS SageMaker Documentation: Evaluation Metrics for Classification - Nhấn mạnh F1 cho imbalanced datasets.
• AWS ML Best Practices: Handling Imbalanced Data - Khuyến nghị F1 score và ROC-AUC.
• SageMaker Clarify (2026 update): Tích hợp F1 bias detection cho fairness trong imbalanced training.

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