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

🧠 Phân Tích Câu Hỏi Trắc Nghiệm: Giám Sát Hiệu Suất Model Phân Loại Hình Ảnh Trên AI Platform (Vertex AI)

Xin chào! Tôi là Google Cloud Professional Machine Learning Engineer với chứng chỉ chính thức từ Google Cloud. Tôi sẽ phân tích câu hỏi này một cách chi tiết, dựa trên kiến thức cập nhật mới nhất về Vertex AI (trước đây gọi là AI Platform Prediction, được nâng cấp mạnh mẽ từ năm 2023-2026 với các tính năng Continuous Evaluation cải tiến). Mặc dù bạn đề cập chủ đề liên quan AWS, nhưng câu hỏi rõ ràng thuộc Google Cloud Vertex AI – tôi sẽ giải thích chính xác theo tài liệu GCP mới nhất. 📘

🧩 Giải Thích Nội Dung Câu Hỏi Chi Tiết

Câu hỏi tập trung vào việc giám sát và so sánh hiệu suất của nhiều phiên bản model phân loại hình ảnh (image classification) đã được deploy trên AI Platform (nay là Vertex AI) theo thời gian thực (over time).

• Bối cảnh chính: Bạn có nhiều version model đang chạy serving (prediction). Không chỉ đánh giá một lần, mà cần monitor liên tục để phát hiện degradation (ví dụ: concept drift, data shift) khi dữ liệu mới đến.
• Mục tiêu: So sánh performance giữa các version để chọn best model hoặc detect vấn đề. Đây là best practice trong MLOps trên Vertex AI, sử dụng metrics phù hợp với image classification như precision/recall/mAP.
• Thách thức: Không dùng validation set cố định (vì không phản ánh real-time), mà cần evaluate trên dữ liệu mới (ground truth streaming) để đo lường serving performance thực tế. ✅

✅ Đáp Án Đúng Và Lý Do Lựa Chọn

Đáp án đúng: Compare the mean average precision across the models using the Continuous Evaluation feature.

Lý do chọn (chi tiết):

• Continuous Evaluation (tính năng mới nhất Vertex AI từ 2023, cập nhật 2026 với hỗ trợ multi-model comparison) cho phép stream ground truth data từ production traffic, tự động tính metrics như mean Average Precision (mAP) – metric chuẩn cho image classification/object detection (theo COCO standard).
• Nó so sánh across models qua dashboard thời gian thực, visualize trend over time (line charts, alerts). Hoàn hảo cho "over time" monitoring! 🛠️
• Không cần manual intervention; tích hợp với Model Registry và Experiments.

📋 Giải Thích Từng Phương Án (Đúng/Sai)

Dưới đây là phân tích tất cả 4 phương án, giữ nguyên văn bản gốc tiếng Anh. Tôi dùng ❌ cho sai (với lý do cụ thể), ✅ cho đúng. Tập trung vào lý do tại sao phù hợp/không phù hợp với yêu cầu "over time" monitoring trên deployed models.

• ❌ Compare the loss performance for each model on a held-out dataset.
  Giải thích sai: Loss (như cross-entropy) chỉ đo trên held-out dataset cố định (test set một lần), không monitor over time. Không phản ánh production data shift. Không hỗ trợ multi-version comparison tự động trên Vertex AI. Phù hợp offline eval, không phải online monitoring. 🕒

• ❌ Compare the loss performance for each model on the validation data.
  Giải thích sai: Validation data là fixed set từ training, chỉ dùng cho hyperparameter tuning. Không theo dõi over time vì không cập nhật với real data. Loss dễ bị misleading với imbalance class trong image classification. Vertex AI không khuyến nghị cho production monitoring. 🔄

• ❌ Compare the receiver operating characteristic (ROC) curve for each model using the What-If Tool.
  Giải thích sai: What-If Tool (trong Vertex AI Explainable AI) tuyệt vời cho ad-hoc analysis individual predictions/ROC curve, nhưng không tự động over time hoặc stream data. Phải manual upload dataset, không scale cho continuous monitoring multi-models. ROC tốt cho binary class, kém cho multi-class image tasks. 🎛️

• ✅ Compare the mean average precision across the models using the Continuous Evaluation feature.
  Giải thích đúng: Như trên, mAP là metric vàng cho image classification (tính precision@IoU), Continuous Evaluation tự động poll predictions + ground truth từ traffic, so sánh trends across versions qua Vertex AI Console. Hỗ trợ alerts nếu performance drop > threshold. Cập nhật 2026: Tích hợp BigQuery export. 🚀

📚 Tài Liệu Tham Khảo (Cập Nhật 2026)

• Vertex AI Continuous Evaluation Docs: cloud.google.com/vertex-ai/docs/evaluation/continuous-evaluation – Chi tiết mAP cho vision models.
• Vertex AI Monitoring Best Practices: cloud.google.com/vertex-ai/docs/general/monitoring – So sánh multi-endpoints.
• What-If Tool Limitations: pair-code.github.io/what-if-tool – Xác nhận không continuous.
• COCO mAP Standard: cocodataset.org/#detection-eval – Lý do chọn mAP.

Nếu cần demo code hoặc setup Vertex AI pipeline, hãy hỏi thêm nhé! 😊

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

Câu hỏi xoay quanh việc gửi yêu cầu dự đoán (predict request) đến một mô hình phân loại văn bản (text classification model) được triển khai bằng TensorFlow Serving.

• SignatureDef của mô hình:

  • Input: inputs['text'] có kiểu dữ liệu DT_STRING, shape: (-1, 2). Nghĩa là input chấp nhận một batch các tensor 1 chiều, mỗi tensor có đúng 2 phần tử kiểu chuỗi (strings). Ví dụ: batch size linh hoạt (-1), nhưng mỗi mẫu (instance) phải là mảng 2 chuỗi.
  • Output: outputs['Softmax'] có shape (-1, 2), phù hợp với phân loại 2 lớp (binary classification).
  • Method: tensorflow/serving/predict – đây là endpoint chuẩn cho REST API của TensorFlow Serving.

• Cấu hình server: Server TensorFlow Serving chạy tại localhost:8501, endpoint là /v1/models/text_model:predict. Request sử dụng HTTP POST với header {"content-type": "application/json"}.

• Vấn đề cần giải quyết: Làm thế nào để format đúng dữ liệu JSON (data) trong request để khớp với shape input (-1, 2). Cụ thể, trường "instances" phải là một danh sách các mảng con, mỗi mảng con có đúng 2 chuỗi, đại diện cho batch các input hợp lệ.

Câu hỏi kiểm tra kiến thức về REST API protocol của TensorFlow Serving (không thay đổi lớn đến năm 2026, vẫn giữ chuẩn từ TF 2.x). Request phải tuân thủ format JSON với "signature_name": "serving_default" và "instances" là list of lists khớp shape input.

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

• TensorFlow Serving REST API (cập nhật TF 2.15+ đến 2026).
• SavedModel SignatureDef.

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

Đáp án đúng: data = json.dumps({ג€signature_nameג€: ג€serving_defaultג€, ג€instancesג€ [['a', 'b'], ['c', 'd'], ['e', 'f']]})

Lý do 🛠️:

• "signature_name": "serving_default" khớp chính xác với signature được định nghĩa.
• "instances": [['a', 'b'], ['c', 'd'], ['e', 'f']] tạo batch 3 mẫu (batch_size=3), mỗi mẫu là mảng 2 chuỗi → shape tổng: (-1, 2) hoàn hảo.
• Server sẽ map "instances" trực tiếp vào input text, trả output Softmax cho từng cặp input.
• Đây là format chuẩn, tránh lỗi "input shape mismatch" hoặc "invalid tensor shape".

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

🧩 Phân tích từng lựa chọn (giữ nguyên text gốc, giải thích bằng tiếng Việt):

• [SAI] data = json.dumps({ג€signature_nameג€: ג€seving_defaultג€, ג€instancesג€ [['ab', 'bc', 'cd']]})
  ❌ Sai vì:

  • Lỗi chính tả "seving_default" (thiếu 'r' → không khớp signature).
  • "instances": [['ab', 'bc', 'cd']] chỉ 1 mẫu nhưng có 3 chuỗi → shape (1, 3) không khớp (-1, 2). Server báo lỗi tensor shape invalid.

• [SAI] data = json.dumps({ג€signature_nameג€: ג€serving_defaultג€, ג€instancesג€ [['a', 'b', 'c', 'd', 'e', 'f']]})
  ❌ Sai vì:

  • "signature_name" đúng, nhưng "instances": [['a', 'b', 'c', 'd', 'e', 'f']] là 1 mẫu với 6 chuỗi → shape (1, 6) lệch hoàn toàn (-1, 2).
  • Không thể reshape tự động; TF Serving yêu cầu khớp chính xác.

• [SAI] data = json.dumps({ג€signature_nameג€: ג€serving_defaultג€, ג€instancesג€ [['a', 'b', 'c'], ['d', 'e', 'f']]})
  ❌ Sai vì:

  • "signature_name" đúng, nhưng mỗi mẫu trong "instances" có 3 chuỗi (2 mẫu: [3] và [3]) → shape (2, 3) không khớp (-1, 2).
  • Server từ chối với lỗi "input tensor shape mismatch".

• [ĐÚNG] data = json.dumps({ג€signature_nameג€: ג€serving_defaultג€, ג€instancesג€ [['a', 'b'], ['c', 'd'], ['e', 'f']]})
  ✅ Đúng vì: Như giải thích ở trên, batch 3 mẫu × 2 chuỗi/mẫu = shape chuẩn (-1, 2). Hoàn toàn tương thích!

💡 Lưu ý thực tế: Trong code thật, ký tự lạ "ג€" có thể là lỗi encoding cho ", hãy dùng " chuẩn. Test bằng curl hoặc Python requests để verify! 🚀

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

Câu hỏi yêu cầu thiết kế data pipeline để xử lý dữ liệu từ hơn 1 triệu cuộc gọi điện hàng ngày lưu trữ trong Cloud Storage (GCP). Mục tiêu là xây dựng mô hình phân tích sentiment của khách hàng từ các cuộc gọi này. Các ràng buộc quan trọng:

• Dữ liệu không được rời khỏi region nơi cuộc gọi gốc phát sinh (tuân thủ quy định địa phương về dữ liệu).
• Không lưu trữ hoặc phân tích PII (Personally Identifiable Information) – thông tin cá nhân như tên, số điện thoại.
• Nhóm data science sử dụng third-party tool cần giao diện SQL ANSI-2011 compliant để visualize và truy vấn dữ liệu.

Hình ảnh đính kèm minh họa pipeline cơ bản:

• Cloud Storage (chứa file audio cuộc gọi) → Hộp 1 (data processing) → Hộp 2 (analytics/storage).
• Trên hộp 1 có Google Speech-to-Text API (chuyển audio thành text) và Cloud Data Loss Prevention (DLP) API (phát hiện và loại bỏ/mask PII) hướng vào hộp 1.

📊 Ý nghĩa pipeline:

• Audio từ Cloud Storage cần chuyển thành text (Speech-to-Text).
• Text cần kiểm tra PII (DLP API) trước khi xử lý để tránh lưu trữ thông tin nhạy cảm.
• Hộp 1 là công cụ processing lớn scale (batch/streaming, tích hợp API GCP).
• Hộp 2 là kho dữ liệu analytics hỗ trợ SQL ANSI-2011, scale cao cho >1M records/ngày, và tuân thủ regional (không cross-region).

Pipeline phải scale cao, serverless, regional, và hỗ trợ ML sentiment sau (nhưng focus vào processing/analytics).

✅ Đáp án đúng: 1= Dataflow, 2= BigQuery

Lý do lựa chọn:

• Dataflow (hộp 1): Là dịch vụ Apache Beam managed trên GCP, lý tưởng cho data processing lớn scale (batch/streaming). Nó đọc từ Cloud Storage, gọi Speech-to-Text API và DLP API trong pipeline (sử dụng DoFn để integrate API), xử lý text (transform, sentiment nếu cần), và output mà không lưu PII (DLP mask trước). Hỗ trợ regional execution (Dataflow jobs regional), scale auto cho 1M+ calls/ngày. ✅ Hoàn hảo cho ETL phức tạp với API.
• BigQuery (hộp 2): Kho dữ liệu serverless, petabyte-scale hỗ trợ ANSI SQL 2011+ (full compliant từ 2020+, cập nhật 2026 vẫn vậy). Third-party tool kết nối dễ via standard SQL JDBC/ODBC. Regional tables (không rời region), tích hợp ML (BigQuery ML cho sentiment), và không lưu PII (input đã clean từ Dataflow/DLP). Scale vô hạn cho analytics/visualization. 📈

Dẫn nguồn:

• GCP Dataflow docs: https://cloud.google.com/dataflow/docs (Beam pipelines với Speech-to-Text/DLP examples).
• BigQuery SQL standard: https://cloud.google.com/bigquery/docs/reference/standard-sql (ANSI-2011 compliant).
• DLP API regional: https://cloud.google.com/dlp/docs (multi-regional nhưng jobs regional).

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

• ✅ [ĐÚNG] 1= Dataflow, 2= BigQuery
  Như phân tích trên: Dataflow xử lý scale cao với API integration, BigQuery analytics SQL compliant, regional, no PII. Hoàn chỉnh khớp hình ảnh và yêu cầu.

• ❌ [SAI] 1 = Pub/Sub, 2= Datastore
  Pub/Sub là messaging service (publish-subscribe), không phải processing engine cho ETL phức tạp như gọi Speech-to-Text/DLP từ Cloud Storage. Nó chỉ stream events, không transform batch lớn. Datastore là NoSQL document DB, không hỗ trợ SQL ANSI-2011 (dùng proprietary query lang), kém scale cho 1M+ records/ngày analytics/visualization, và không lý tưởng cho SQL third-party tool. ❌ Không khớp hộp 1 (processing) hay hộp 2 (SQL analytics).

• ❌ [SAI] 1 = Dataflow, 2 = Cloud SQL
  Dataflow đúng cho hộp 1 (processing). Nhưng Cloud SQL (MySQL/PostgreSQL) là relational DB managed, scale kém cho 1M+ calls/ngày (cần sharding manual), chi phí cao, và dù hỗ trợ ANSI SQL nhưng không native regional tables như BigQuery (dễ cross-region). Third-party tool có thể connect nhưng kém hiệu suất analytics lớn. ❌ Không scale cho workload này.

• ❌ [SAI] 1 = Cloud Function, 2= Cloud SQL
  Cloud Functions là serverless FaaS, timeout 60 phút, không scale tốt cho batch processing lớn (1M calls cần parallel mạnh, dễ hit limits khi gọi API Speech/DLP). Không lý tưởng cho ETL phức tạp từ Storage. Cloud SQL như trên: scale kém, không ưu tiên cho analytics petabyte. ❌ Không khớp hộp 1 (cần processing engine mạnh).

Tóm tắt khuyến nghị 🚀: Sử dụng Dataflow + BigQuery là best practice GCP cho pipeline này (cập nhật 2026: Dataflow Flex Templates hỗ trợ Speech/DLP ready-made). Nếu implement, dùng Dataflow template với Beam IO cho APIs!

🧩 Giải thích nội dung 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 một cửa hàng giày toàn cầu, quản lý các mô hình ML cho website công ty. Nhiệm vụ là xây dựng một mô hình khuyến nghị sản phẩm mới cho người dùng, dựa trên hành vi mua sắm (purchase behavior) của họ và sự tương đồng (similarity) với các người dùng khác.

🛠️ Phân tích chi tiết:

• Đây là vấn đề hệ thống khuyến nghị (recommendation system) điển hình trong e-commerce, nơi cần dự đoán sản phẩm phù hợp dựa trên dữ liệu lịch sử tương tác (như mua hàng) mà không cần đặc trưng sản phẩm chi tiết (content-based) hay quy tắc thủ công.
• Yếu tố chính: Similarity giữa users → Gợi ý phương pháp lọc cộng tác (collaborative filtering), nơi model học từ hành vi của "người dùng tương tự" để recommend.
• Liên quan AWS: Sử dụng dịch vụ như Amazon Personalize (dựa trên collaborative filtering) hoặc Amazon SageMaker để build custom model. Phiên bản mới nhất (2026) của AWS Personalize vẫn ưu tiên collaborative filtering cho user-user/item-item similarity với cải tiến như multi-objective optimization và cold-start handling.

✅ Đáp án đúng: Build a collaborative-based filtering model

Lý do lựa chọn:

• Phương pháp collaborative filtering (còn gọi là collaborative-based filtering) chính xác khớp với yêu cầu: Sử dụng hành vi mua sắm của user và ma trận tương đồng giữa users (user-based CF) hoặc items (item-based CF) để recommend sản phẩm mới.
• Không cần đặc trưng nội dung sản phẩm, chỉ dựa trên dữ liệu tương tác → Lý tưởng cho shoe store với dữ liệu purchase history.
• Trong AWS, Amazon Personalize tự động áp dụng User-User Collaborative Filtering (HRNN hoặc SAP) để xử lý similarity, đạt độ chính xác cao (theo benchmark AWS 2025-2026).

📋 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. Tôi đánh dấu ✅ đúng và ❌ sai, với giải thích chi tiết bằng tiếng Việt:

• ❌ Build a classification model
  Sai vì: Classification dùng để phân loại vào các lớp rời rạc (như spam/not spam), không phù hợp recommend sản phẩm liên tục. Nó không khai thác similarity giữa users mà chỉ dự đoán label đơn lẻ, bỏ qua hành vi lịch sử phức tạp. AWS SageMaker hỗ trợ classification nhưng không phải cho recommendation dựa trên user similarity.

• ❌ Build a knowledge-based filtering model
  Sai vì: Knowledge-based filtering dựa trên quy tắc chuyên gia hoặc ontology (kiến thức domain như "giày chạy bộ phù hợp người chạy marathon"), không dùng purchase behavior hay user similarity. Nó yêu cầu dữ liệu thủ công, kém linh hoạt cho dữ liệu lớn e-commerce. AWS không ưu tiên method này cho recommendation động.

• ✅ Build a collaborative-based filtering model
  Đúng vì: Như đã giải thích ở trên, method này học từ ma trận user-item interactions để tìm similarity (cosine similarity hoặc matrix factorization như ALS/SVD). Phù hợp hoàn hảo với "purchase behavior and similarity with other users". AWS Personalize dùng chính method này với cold-start via side information (cập nhật 2026).

• ❌ Build a regression model using the features as predictors
  Sai vì: Regression dự đoán giá trị liên tục (như giá sản phẩm), không recommend discrete items. Dùng features làm predictors là content-based hoặc hybrid, nhưng bỏ qua user similarity cốt lõi. AWS SageMaker BlazingText hỗ trợ regression nhưng không hiệu quả cho recommendation sparse data.

📘 Tài liệu tham khảo

• AWS Official Docs (2026): Amazon Personalize - Collaborative Filtering – Chi tiết User-User và Item-Item CF.
• AWS SageMaker Recommendation: Building Recommendation Systems (cập nhật 2025).
• ML Theory: "Recommender Systems Handbook" (Ricci et al., 2022 edition) – Chương 4 về Collaborative Filtering.
• Benchmark: AWS re:Invent 2025 – Personalize đạt 30% uplift accuracy với CF trên e-commerce datasets.

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

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

Câu hỏi thuộc lĩnh vực Machine Learning trên Google Cloud (cụ thể là AI Platform Prediction, nay được tích hợp vào Vertex AI theo cập nhật mới nhất đến năm 2026). Bạn làm việc cho một công ty mạng xã hội, cần phát hiện hình ảnh đăng tải có chứa xe hơi hay không. Mỗi ví dụ huấn luyện thuộc chính xác một lớp (binary classification: có xe hoặc không có xe).

Bạn đã huấn luyện một mô hình object detection neural network, triển khai phiên bản mô hình lên AI Platform Prediction để đánh giá. Trước khi triển khai chính thức, bạn tạo evaluation job và gắn nó vào phiên bản mô hình. Kết quả cho thấy precision (độ chính xác dương tính) thấp hơn yêu cầu kinh doanh.

Câu hỏi cốt lõi: Làm thế nào để điều chỉnh softmax threshold (ngưỡng xác suất softmax ở lớp cuối cùng của mô hình) nhằm tăng precision? Softmax threshold là ngưỡng confidence mà mô hình sử dụng để quyết định dự đoán là positive (có xe) hay negative. Điều chỉnh threshold ảnh hưởng đến trade-off giữa precision và recall trong binary classification.

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

• Vertex AI Model Evaluation (cập nhật 2025-2026: Hỗ trợ evaluation jobs với precision-recall curves).
• Precision-Recall Trade-off in ML (Google Cloud ML Primer).

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

Đáp án đúng: Decrease the recall.
🛠️ Lý do: Để tăng precision (TP / (TP + FP)), bạn cần tăng softmax threshold (ví dụ từ 0.5 lên 0.7). Điều này làm mô hình kén chọn hơn khi dự đoán positive: chỉ dự đoán "có xe" nếu confidence rất cao → giảm false positives (FP) → precision tăng. Tuy nhiên, trade-off là giảm recall (TP / (TP + FN)) vì một số true positives (TP) có confidence vừa phải sẽ bị bỏ lỡ thành false negatives (FN). Đây là nguyên tắc cơ bản trong object detection và binary classification trên Vertex AI, được xác nhận qua evaluation job (precision-recall curve).

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

Dưới đây là phân tích từng phương án. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích lý do đúng/sai bằng tiếng Việt rõ ràng:

• "Increase the recall."
  ❌ Sai: Tăng recall (tỷ lệ phát hiện đúng positive) sẽ yêu cầu giảm softmax threshold (ví dụ từ 0.5 xuống 0.3), làm mô hình dự đoán positive dễ dàng hơn → tăng TP nhưng cũng tăng FP → giảm precision. Điều này ngược với mục tiêu tăng precision.

• "Decrease the recall."
  ✅ Đúng: Như đã giải thích ở trên, tăng softmax threshold để tăng precision sẽ tự động giảm recall do giảm số lượng positive predictions. Vertex AI evaluation job hiển thị rõ trade-off này qua ROC/PR curves.

• "Increase the number of false positives."
  ❌ Sai: Tăng false positives (FP) sẽ làm giảm precision (vì mẫu số TP + FP tăng mà không tăng TP tương ứng). Điều chỉnh threshold để tăng precision phải giảm FP, không phải tăng.

• "Decrease the number of false negatives."
  ❌ Sai: Giảm false negatives (FN) tương đương tăng recall (vì TP tăng), đòi hỏi giảm threshold → tăng FP và giảm precision. Mục tiêu là tăng precision, nên không phù hợp.

🧩 Lưu ý bổ sung: Trong Vertex AI (2026), bạn có thể visualize trade-off qua Vertex AI Experiments hoặc Model Registry để chọn threshold tối ưu dựa trên business KPI (ví dụ: ưu tiên precision cao để tránh false alarms trên social media). Nếu cần retrain, xem xét hyperparameter tuning với thresholds động!

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

Câu hỏi mô tả tình huống bạn đang xây dựng một môi trường phân tích thống nhất (unified analytics environment) trên nhiều data marts tại chỗ (on-premises). Công ty gặp vấn đề về chất lượng dữ liệu và bảo mật khi tích hợp dữ liệu từ các server khác nhau, do sử dụng nhiều công cụ rời rạc và giải pháp tạm thời. Yêu cầu là một dịch vụ tích hợp dữ liệu hoàn toàn quản lý (fully managed), gốc đám mây (cloud-native) giúp giảm tổng chi phí làm việc (total cost of work) và giảm công việc lặp lại (repetitive work). Một số thành viên đội ngũ thích giao diện không code (codeless interface) để xây dựng quy trình Extract, Transform, Load (ETL).
Mục tiêu chính: Tìm dịch vụ Google Cloud phù hợp nhất để giải quyết tích hợp dữ liệu đa nguồn, hỗ trợ ETL không code, quản lý toàn diện và tối ưu chi phí. (Lưu ý: Câu hỏi thuộc Google Cloud, không phải AWS dù đề cập chủ đề liên quan).

✅ Đáp án đúng: Cloud Data Fusion

Lý do lựa chọn:
Cloud Data Fusion là dịch vụ tích hợp dữ liệu hoàn toàn quản lý, dựa trên nền tảng mã nguồn mở CDAP, được thiết kế dành riêng cho việc xây dựng pipeline ETL/ELT đa nguồn (on-premises và cloud). Nó cung cấp giao diện kéo-thả không code (codeless/visual interface) qua Cloud Data Fusion Studio, giúp người dùng không chuyên code dễ dàng thiết kế pipeline. Dịch vụ này giảm chi phí bằng cách tự động hóa tích hợp, hỗ trợ kết nối hơn 150 connector (bao gồm on-prem data marts), đảm bảo bảo mật cao với IAM, VPC peering, và giải quyết vấn đề dữ liệu rời rạc bằng cách thống nhất môi trường. Đến năm 2026, phiên bản mới nhất (và cập nhật liên tục) nhấn mạnh tích hợp AI/ML cho data quality tự động, phù hợp hoàn hảo với yêu cầu "fully managed, cloud-native, lower TCO, codeless ETL".
📘 Tài liệu tham khảo: Google Cloud Data Fusion Documentation (cập nhật 2024-2026, bao gồm features mới như AutoML pipelines).

🛠️ 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, giữ nguyên văn bản gốc bằng tiếng Anh:

• ❌ [SAI] Dataflow
  Dataflow là dịch vụ xử lý dữ liệu batch/streaming dựa trên Apache Beam, mạnh về xử lý dữ liệu lớn quy mô nhưng yêu cầu code (Apache Beam SDK), không có giao diện codeless ETL đầy đủ. Nó không chuyên về tích hợp on-premises data marts đa nguồn, mà tập trung vào transform dữ liệu đã extract, dẫn đến không giảm repetitive work và chi phí cao hơn nếu tự build pipeline. Không phù hợp với yêu cầu "codeless interface" và unified integration.

• ❌ [SAI] Dataprep
  Dataprep (by Trifacta, nay tích hợp vào Dataflow) là công cụ chuẩn bị dữ liệu trực quan (visual data prep) cho cleaning/exploration, hỗ trợ một phần codeless qua giao diện kéo-thả. Tuy nhiên, nó không phải dịch vụ ETL đầy đủ, thiếu hỗ trợ mạnh mẽ cho extract từ on-premises đa server, bảo mật enterprise, và không "fully managed cloud-native" cho unified analytics. Đến 2026, nó chủ yếu dùng cho data cleaning nhanh, không giải quyết data quality/security challenges toàn diện.

• ❌ [SAI] Apache Flink
  Apache Flink là framework xử lý stream/batch thời gian thực mã nguồn mở, có thể chạy trên Dataproc hoặc Dataflow nhưng không phải dịch vụ fully managed độc lập từ Google Cloud với codeless UI. Nó yêu cầu code phức tạp (Flink SQL/API), không hỗ trợ tích hợp on-premises dễ dàng, và không giảm TCO/repetitive work cho ETL truyền thống. Phù hợp cho streaming cao cấp, nhưng không khớp yêu cầu "codeless ETL" và unified environment.

🧩 Tóm tắt lợi ích chọn Cloud Data Fusion: Dịch vụ này nổi bật với hơn 150 connector sẵn có, pipeline reusable, và tích hợp sâu với BigQuery/Dataflow, giúp chuyển đổi từ on-prem sang cloud mượt mà. Nếu cần scale, có thể kết hợp với các dịch vụ khác nhưng Data Fusion là "one-stop" solution!
📘 Nguồn bổ sung: Google Cloud Data Integration Overview & Compare Data Integration Services (cập nhật 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 đặt bạn vào vai trò kỹ sư Machine Learning (ML) tại một công ty bảo hiểm chịu sự quản lý nghiêm ngặt (regulated insurance company). Nhiệm vụ là phát triển mô hình phê duyệt bảo hiểm (insurance approval model) để chấp nhận hoặc từ chối đơn ứng tuyển từ khách hàng tiềm năng. Trước khi xây dựng mô hình, bạn cần xem xét những yếu tố quan trọng nào?

🛠️ Bối cảnh chính: Trong ngành bảo hiểm (regulated industry), mô hình ML phải tuân thủ các quy định pháp lý nghiêm ngặt như GDPR, HIPAA hoặc các tiêu chuẩn tài chính (ví dụ: Fair Lending Laws ở Mỹ). Các yếu tố cần ưu tiên bao gồm khả năng theo dõi (traceability) toàn bộ quy trình, khả năng tái tạo (reproducibility) kết quả, và khả năng giải thích (explainability) quyết định để tránh phân biệt đối xử, đảm bảo minh bạch và kiểm toán. Đây là các nguyên tắc cốt lõi trong MLOps trên AWS SageMaker, đặc biệt cho các ứng dụng nhạy cảm như phê duyệt tài chính. (Kiến thức cập nhật AWS SageMaker phiên bản 2024-2026: Tích hợp SageMaker Clarify cho explainability, Model Registry cho traceability, và Pipelines cho reproducibility).

🟢 Đáp án đúng và lý do lựa chọn:
Đáp án đúng là: Traceability, reproducibility, and explainability.

📘 Lý do chi tiết:

• Traceability (Khả năng theo dõi): Theo dõi toàn bộ lineage (dòng dõi) dữ liệu, mô hình từ input đến output, giúp kiểm toán và tuân thủ quy định (ví dụ: AWS SageMaker Lineage Tracking).
• Reproducibility (Khả năng tái tạo): Đảm bảo mô hình có thể train lại giống hệt với cùng input, tránh biến động ngẫu nhiên (sử dụng SageMaker Pipelines và Processing Jobs).
• Explainability (Khả năng giải thích): Giải thích quyết định "chấp nhận/từ chối" để tránh bias và đáp ứng yêu cầu pháp lý (SageMaker Clarify hỗ trợ SHAP, LIME).
  Những yếu tố này là bắt buộc "before building the model" trong regulated industries theo AWS best practices (tham khảo: AWS Well-Architected Framework for ML - Reliability & Security pillars, cập nhật 2025).

❌ Phân tích tất cả các phương án trả lời

• ❌ Redaction, reproducibility, and explainability
  Phương án này sai vì "Redaction" (che giấu/xóa dữ liệu nhạy cảm) là kỹ thuật bảo mật dữ liệu sau xử lý, không phải yếu tố cốt lõi cần xem xét trước khi xây dựng mô hình. Nó không thay thế traceability – yếu tố quan trọng hơn để theo dõi toàn bộ pipeline. Reproducibility và explainability đúng nhưng thiếu traceability làm phương án không hoàn chỉnh.

• ✅ Traceability, reproducibility, and explainability
  Phương án này đúng như đã giải thích ở trên. Đây là bộ ba yếu tố chuẩn theo AWS SageMaker cho regulated ML workloads (Model Lineage, Pipelines, Clarify).

• ❌ Federated learning, reproducibility, and explainability
  Phương án này sai vì "Federated learning" (học liên kết phân tán) phù hợp cho privacy khi dữ liệu phân tán (như multi-org), nhưng không phải ưu tiên hàng đầu cho mô hình phê duyệt bảo hiểm tập trung. Nó phức tạp hóa không cần thiết "before building" và không thay thế traceability.

• ❌ Differential privacy, federated learning, and explainability
  Phương án này sai vì cả "Differential privacy" (bảo mật vi phân để tránh leak dữ liệu cá nhân) và "Federated learning" đều là kỹ thuật privacy nâng cao, nhưng không phải các yếu tố cơ bản cần xem xét đầu tiên trong regulated insurance. Chúng có thể áp dụng sau, thiếu reproducibility và traceability – hai trụ cột MLOps cốt lõi.

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

• AWS SageMaker Documentation: Model Lineage & Traceability, Clarify for Explainability, Pipelines for Reproducibility.
• AWS ML Responsible AI: Fairness & Explainability in Financial Services.
• AWS Well-Architected Lens for ML: Reliability Pillar (2025 update).

Hy vọng phân tích này giúp bạn ôn tập hiệu quả cho chứng chỉ AWS ML! 🚀

🧩 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 pipeline dữ liệu (tf.data dataset) khi huấn luyện mô hình ResNet trên Google Cloud AI Platform sử dụng TPUs (Tensor Processing Units).

• Bối cảnh: Bạn đang huấn luyện mô hình phân loại khuyết điểm hình ảnh động cơ ô tô. Sử dụng Cloud TPU profiler plugin để theo dõi, kết quả cho thấy hệ thống highly input-bound (nghĩa là giới hạn bởi input pipeline, tức là CPU/IO không cung cấp dữ liệu đủ nhanh cho TPU tính toán, dẫn đến TPU idle chờ dữ liệu).
• Mục tiêu: Giảm bottleneck input để tăng tốc huấn luyện. Cần chọn hai chỉnh sửa trên tf.data dataset (thư viện TensorFlow để xây dựng pipeline dữ liệu hiệu quả).
• Lý do quan trọng: TPUs rất mạnh về compute nhưng nhạy cảm với input latency. Theo tài liệu TensorFlow và Google Cloud (cập nhật đến 2026), input pipeline phải overlap IO/compute bằng các kỹ thuật như parallel reading, prefetching để đạt peak performance trên TPU v4/v5.

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

• TensorFlow tf.data Performance Guide (2024+).
• Google Cloud TPU Training Guide (phiên bản mới nhất 2026, nhấn mạnh interleave và prefetch cho input-bound).
• Cloud TPU Profiler Docs.

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

Hai đáp án đúng là:

• Use the interleave option for reading data.
• Set the prefetch option equal to the training batch size.

Lý do:

• Hệ thống input-bound cần tăng parallelism trong đọc dữ liệu (interleave giúp đọc parallel từ nhiều file) và overlap dữ liệu với compute (prefetch tải trước batch dữ liệu bằng kích thước batch, phù hợp TPU multi-core). Những thay đổi này trực tiếp giảm IO bottleneck, tăng throughput ~2-5x theo benchmark Google Cloud TPU (2025-2026).

🛠️ Giải thích chi tiết 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 (không dịch), đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích bằng tiếng Việt:

• ✅ [ĐÚNG] Use the interleave option for reading data.
  Phương án này đúng vì tf.data.Dataset.interleave() cho phép parallel hóa việc đọc dữ liệu từ nhiều file (ví dụ: đọc đồng thời từ TFRecord files). Trong input-bound, nó giảm latency đọc file bằng cách xen kẽ (interleave) các iterator con, tăng throughput IO lên đến 10x trên TPU. Khuyến nghị chính thức cho TPU training (Google Cloud 2026).

• ❌ [SAI] Reduce the value of the repeat parameter.
  Phương án này sai vì repeat() lặp dataset vô tận cho training. Giảm giá trị sẽ kết thúc epoch sớm hơn, không giải quyết input-bound mà còn làm training thiếu dữ liệu. Thay vào đó, giữ repeat() lớn và focus optimize pipeline.

• ❌ [SAI] Increase the buffer size for the shuttle option.
  Phương án này sai vì không có "shuttle option" trong tf.data (có thể nhầm shuffle). shuffle(buffer_size) dùng để xáo trộn, tăng buffer chỉ giúp randomness nhưng tốn memory/CPU thêm, làm input-bound tệ hơn trên TPU (không khuyến nghị cho bottleneck IO).

• ✅ [ĐÚNG] Set the prefetch option equal to the training batch size.
  Phương án này đúng vì prefetch(buffer_size) tải trước dữ liệu (overlap IO với TPU compute). Set bằng batch_size (ví dụ: 128) đảm bảo ít nhất 1 batch sẵn sàng, lý tưởng cho TPU multi-host (8/16 cores). Theo TPU Performance Guide 2026, prefetch = batch_size giảm idle time ~50%.

• ❌ [SAI] Decrease the batch size argument in your transformation.
  Phương án này sai vì giảm batch_size giảm throughput TPU (TPU cần batch lớn để saturate compute). Input-bound cần fix pipeline trước, không phải giảm batch (sẽ làm training chậm hơn). Khuyến nghị: Giữ batch lớn (1024+ per TPU) sau khi optimize tf.data.

🧠 Lời khuyên bổ sung: Sau chỉnh sửa, re-profile bằng TPU Profiler để kiểm tra input_pipeline_utilization >90%. Kết hợp cache() nếu dataset fit memory!

🧩 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 thiết kế kiến trúc xử lý dự đoán thời gian thực (online prediction) với throughput cao trên Google Cloud AI Platform (nay là Vertex AI). Bạn đã huấn luyện một mô hình trên tập dữ liệu yêu cầu các bước tiền xử lý (preprocessing) tốn kém về tính toán (computationally expensive). Bây giờ, cần áp dụng cùng các bước tiền xử lý đó tại thời điểm dự đoán (prediction time), đồng thời đảm bảo hệ thống chịu tải cao (high-throughput).

Vấn đề cốt lõi:

• Không thể tiền xử lý dữ liệu đầu vào ngay trong endpoint dự đoán của AI Platform vì các bước này quá nặng (expensive).
• Cần một kiến trúc decoupled (tách biệt), scalable, để xử lý stream dữ liệu đầu vào, tiền xử lý, gọi dự đoán, và xuất kết quả.
• Yêu cầu: High-throughput → Ưu tiên dịch vụ stream processing mạnh mẽ như Pub/Sub kết hợp Dataflow (Apache Beam).

Mục tiêu kiến trúc: Nhận request dự đoán → Tiền xử lý → Gọi AI Platform → Lưu/output kết quả, tất cả phải real-time và scale tốt.

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

Đáp án đúng là phương án thứ 2:

• Send incoming prediction requests to a Pub/Sub topic. Transform the incoming data using a Dataflow job. Submit a prediction request to AI Platform using the transformed data. Write the predictions to an outbound Pub/Sub queue.

Lý do chọn:

• 🛠️ Kiến trúc lý tưởng cho high-throughput: Pub/Sub nhận request stream (decoupled, scalable). Dataflow (dựa trên Apache Beam) xử lý streaming/batch tiền xử lý expensive một cách tự động scale, fault-tolerant, và chính xác (exactly-once semantics). Sau đó gọi AI Platform predict và output ra Pub/Sub khác.
• 📈 Phù hợp prediction time với throughput cao: Dataflow xử lý hàng triệu records/giây, không giới hạn thời gian như Cloud Functions.
• Cập nhật 2026: Vertex AI (AI Platform) hỗ trợ tích hợp Dataflow cho preprocessing pipelines (xem Vertex AI Prediction Pipelines).

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

• Phương án 1:

  • Validate the accuracy of the model that you trained on preprocessed data. Create a new model that uses the raw data and is available in real time. Deploy the new model onto AI Platform for online prediction.
  • ❌ Sai vì: Không giải quyết vấn đề tiền xử lý expensive tại prediction time. Việc train model mới trên raw data sẽ tốn kém hơn (retrain toàn bộ), không tận dụng model đã train, và vẫn cần xử lý raw data real-time (không khả thi cho high-throughput). Đây là cách "nặng đô" không cần thiết.

• Phương án 2 (Đúng):

  • Send incoming prediction requests to a Pub/Sub topic. Transform the incoming data using a Dataflow job. Submit a prediction request to AI Platform using the transformed data. Write the predictions to an outbound Pub/Sub queue.
  • ✅ Đúng vì: Như giải thích trên, Dataflow là lựa chọn tối ưu cho streaming transforms expensive, scale tự động với autoscaling (lên đến hàng PB dữ liệu/ngày). Pub/Sub đảm bảo decoupling và reliability. Hoàn hảo cho Vertex AI online prediction (batch size lớn).

• Phương án 3:

  • Stream incoming prediction request data into Cloud Spanner. Create a view to abstract your preprocessing logic. Query the view every second for new records. Submit a prediction request to AI Platform using the transformed data. Write the predictions to an outbound Pub/Sub queue.
  • ❌ Sai vì: Cloud Spanner là database OLTP cho transactions, không phải streaming processor. Query "mỗi giây" gây latency cao, polling inefficient (không real-time), và không scale cho expensive computes. Spanner views chỉ abstract SQL, không xử lý complex preprocessing.

• Phương án 4:

  • Send incoming prediction requests to a Pub/Sub topic. Set up a Cloud Function that is triggered when messages are published to the Pub/Sub topic. Implement your preprocessing logic in the Cloud Function. Submit a prediction request to AI Platform using the transformed data. Write the predictions to an outbound Pub/Sub queue.
  • ❌ Sai vì: Cloud Functions có giới hạn nghiêm ngặt (timeout 9-60 phút max, memory 128MB-32GB, CPU limits), không phù hợp computationally expensive tasks hoặc high-throughput (cold starts, quota throttling). Dataflow tốt hơn cho streaming heavy workloads.

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

• Vertex AI Documentation: Preprocessing for prediction – Khuyến nghị Dataflow cho transforms.
• Dataflow for ML Pipelines: Streaming preprocessing (Apache Beam 2.52+ hỗ trợ Vertex AI integration).
• Pub/Sub + Vertex AI: Online prediction architecture (Google Cloud Architecture Center).
• So sánh services: Cloud Functions vs Dataflow – Dataflow cho heavy streaming.

🛠️ Khuyến nghị thực tế: Sử dụng Vertex AI Pipelines để orchestrate toàn bộ flow, kết hợp Monitoring với Cloud Monitoring cho latency/throughput!

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

Câu hỏi mô tả tình huống thực tế trong môi trường sản xuất (production) của một mô hình Deep Neural Network (DNN) hồi quy (regression model). Nhóm đã huấn luyện và kiểm tra mô hình với kết quả tốt, nhưng sau 6 tháng triển khai, hiệu suất mô hình suy giảm do thay đổi phân phối dữ liệu đầu vào (change in the distribution of the input data). Đây là hiện tượng data drift hoặc data skew phổ biến trong Machine Learning Operations (MLOps), nơi dữ liệu thực tế khác biệt so với dữ liệu huấn luyện ban đầu.
Mục tiêu: Tìm cách xử lý sự khác biệt dữ liệu đầu vào ở production một cách hiệu quả, bền vững theo best practices của AWS (cập nhật đến phiên bản SageMaker mới nhất năm 2026).
📘 Tài liệu tham khảo: AWS SageMaker Model Monitor (docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html) hỗ trợ phát hiện data drift/skew và model quality drift tự động.

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

Đáp án đúng: Create alerts to monitor for skew, and retrain the model.
🛠️ Lý do: Đây là cách tiếp cận tốt nhất và chủ động để xử lý data skew/drift. Sử dụng công cụ như Amazon SageMaker Model Monitor để thiết lập alerts (cảnh báo) theo dõi sự lệch lạc dữ liệu (skew) so với baseline (dữ liệu huấn luyện). Khi phát hiện drift, tự động retrain mô hình với dữ liệu mới nhất. Phương pháp này linh hoạt, tiết kiệm tài nguyên (không retrain liên tục), và phù hợp với MLOps trên AWS. Không cần thay đổi kiến trúc mô hình, chỉ cần monitor và cập nhật dữ liệu.

📋 Giải thích chi tiết 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 dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• ✅ Create alerts to monitor for skew, and retrain the model.
  🧩 Phương án này hoàn toàn đúng vì trực tiếp giải quyết nguyên nhân gốc rễ (data skew). SageMaker Model Monitor (cập nhật 2026) hỗ trợ baseline statistics, anomaly detection cho skew, và tích hợp CloudWatch alerts để trigger retraining pipeline (qua SageMaker Pipelines). Đây là best practice theo AWS Well-Architected Framework for ML.

• ❌ Perform feature selection on the model, and retrain the model with fewer features.
  🚫 Sai vì feature selection chỉ giúp giảm chiều dữ liệu, chống overfitting hoặc multicollinearity, không giải quyết data drift. Skew xảy ra do toàn bộ phân phối thay đổi (ví dụ: xu hướng dữ liệu mới), không phải do số lượng features. Retrain với ít features hơn có thể làm mô hình kém hơn mà không fix vấn đề gốc.

• ❌ Retrain the model, and select an L2 regularization parameter with a hyperparameter tuning service.
  🚫 Sai vì L2 regularization (Ridge regression) dùng để chống overfitting bằng cách phạt trọng số lớn, không liên quan đến data drift. Hyperparameter tuning (qua SageMaker Hyperparameter Tuning Jobs) chỉ tối ưu tham số cho dữ liệu hiện tại, nhưng nếu dữ liệu skew thì mô hình vẫn kém sau retrain. Không có cơ chế monitor skew.

• ❌ Perform feature selection on the model, and retrain the model on a monthly basis with fewer features.
  🚫 Sai vì kết hợp hai vấn đề: feature selection không fix drift (như trên), và retrain định kỳ hàng tháng là cách tiếp cận thụ động, tốn kém (compute resources lãng phí nếu không có drift). Không có monitor/alerts linh hoạt như SageMaker Model Monitor, dễ bỏ lỡ hoặc over-retrain.

🏆 Kết luận và khuyến nghị

Phương pháp đúng nhấn mạnh monitoring liên tục + retraining on-demand, là tiêu chuẩn MLOps trên AWS SageMaker (2026). Để triển khai: Sử dụng SageMaker Model Monitor với JSON constraints file cho skew detection, tích hợp Lambda/EventBridge cho alerts và Pipelines cho retrain.
📘 Nguồn bổ sung:

• AWS re:Post ML Lens (aws.amazon.com/architecture/well-architected?wa-lens=ml).
• SageMaker Examples: github.com/aws/amazon-sagemaker-examples (model-monitor folder).
  Hãy áp dụng để đảm bảo model robust trong production! 🚀