Ngân hàng đề — AWS Certified Machine Learning Engineer Associate

Tìm thấy 635 câu.

Câu 61 Deployment and Orchestration of ML Workflows

You are an ML engineer at a startup that is developing a recommendation engine for an e-commerce platform. The workload involves training models on large datasets and deploying them to serve real-time recommendations to customers. The training jobs are sporadic but require significant computational power, while the inference workloads must handle varying traffic throughout the day. The company is cost-conscious and aims to balance cost efficiency with the need for scalability and performance.

Given these requirements, which approach to resource allocation is the MOST SUITABLE for training and inference, and why?

  1. A

    Use provisioned resources with spot instances for both training and inference to take advantage of the lowest possible costs, accepting the potential for interruptions during workload execution
  2. B

    Use on-demand instances for training, allowing the flexibility to scale resources as needed, and use provisioned resources with auto-scaling for inference to handle varying traffic while controlling costs
  3. C

    Use provisioned resources with reserved instances for both training and inference to lock in lower costs and guarantee resource availability, ensuring predictability in budgeting
  4. D

    Use on-demand instances for both training and inference to ensure that the company only pays for the compute resources it uses when it needs them, avoiding any upfront commitments
Xem giải thích

Đáp án

B — Dùng on-demand instance cho huấn luyện để linh hoạt co giãn khi cần, và tài nguyên có auto-scaling cho suy luận để xử lý lưu lượng biến động trong khi kiểm soát chi phí.

Vì sao đúng

Đề mô tả hai khối lượng công việc có hình dạng khác nhau, và mỗi cái cần một cách cấp phát khác nhau: | Khối lượng | Đặc điểm | Cách cấp phát | |---|---|---| | Huấn luyện | thất thường (sporadic), tốn tính toán lớn | on-demand — chỉ trả khi chạy | | Suy luận | liên tục, lưu lượng thay đổi trong ngày | auto-scaling — co giãn theo tải |

Vì sao on-demand cho huấn luyện: job huấn luyện thất thường nghĩa là không có mẫu ổn định để cam kết. Reserved instance sẽ trả tiền cho hàng nghìn giờ không dùng, còn on-demand chỉ tính tiền lúc job chạy — và SageMaker training job tự tắt instance khi xong.

Vì sao auto-scaling cho suy luận: đề nói lưu lượng thay đổi suốt ngày, và auto-scaling khớp năng lực với nhu cầu thực:

Ban đêm:   2 instance   ← chi phí thấp
Giờ cao điểm: 8 instance ← đủ năng lực

Hai lựa chọn này giải quyết hai vấn đề khác nhau, và đó là lý do đáp án phải nêu cả hai — chứ không phải áp một chiến lược cho tất cả như ba phương án còn lại.

Vì sao các phương án khác sai

  • A. Dùng Spot instance cho CẢ huấn luyện lẫn suy luận để có chi phí thấp nhất, chấp nhận nguy cơ bị gián đoạn — đây là phương án đáng bàn: Spot cho huấn luyện là ý hay (xem #6454), nhưng Spot cho endpoint suy luận là sai nghiêm trọng: bị thu hồi nghĩa là dịch vụ đứt với khách hàng đang mua sắm. Suy luận phục vụ người dùng không chịu được gián đoạn.
  • C. Dùng reserved instance cho cả hai để khoá giá thấp và đảm bảo tài nguyên — sai cho phần huấn luyện: reserved tính tiền theo thời gian cam kết, không theo thời gian dùng. Với job thất thường, phần lớn khoản cam kết bị lãng phí. (Reserved hợp lý cho phần nền của suy luận, nhưng không hợp cho huấn luyện.)
  • D. Dùng on-demand cho cả hai, chỉ trả cho tài nguyên khi cần, không cam kết trước — đúng cho huấn luyện nhưng bỏ lỡ cơ hội ở suy luận: on-demand mà không có auto-scaling nghĩa là bạn phải cấp phát cho đỉnh tải và trả tiền cho nó 24/7. Đây là phương án gần nhất với B và thiếu đúng vế auto-scaling.

Ghi nhớ

Chọn mô hình cấp phát theo hình dạng khối lượng công việc: | Khối lượng | Mô hình | |---|---| | Thất thường, chịu được gián đoạn | Spot — huấn luyện, tinh chỉnh siêu tham số | | Thất thường, không chịu được gián đoạn | On-demand | | Liên tục, tải thay đổi | On-demand + auto-scaling | | Liên tục, tải ổn định và dự đoán được | Savings Plans / Reserved |

Mẫu tối ưu chi phí cho một hệ thống ML production đầy đủ:

Huấn luyện:      Managed Spot Training (giảm tới 90%)
Tinh chỉnh HPO:  Spot (mỗi lần thử độc lập, mất một cái không sao)
Suy luận nền:    Savings Plans cho mức tải tối thiểu
Suy luận đỉnh:   On-demand qua auto-scaling

Mẫu này thường tiết kiệm 50–70% so với dùng on-demand cho tất cả.

Ba lý do không dùng Spot cho endpoint suy luận: | Lý do | Chi tiết | |---|---| | Bị thu hồi = dịch vụ đứt | chỉ báo trước 2 phút | | Không đảm bảo có capacity | có thể không khởi động lại được | | SageMaker endpoint không hỗ trợ Spot | (khác với training job) |

Dòng cuối là điểm kỹ thuật đáng nhớ: SageMaker training job hỗ trợ Spot qua Managed Spot Training, nhưng SageMaker endpoint thì không — nên phương án A không chỉ là lựa chọn tồi, nó còn không thực hiện được.

Và ba tham số auto-scaling cần đặt đúng: | Tham số | Ảnh hưởng | |---|---| | MinCapacity | sàn — đặt ≥ 2 để chịu được mất một AZ | | MaxCapacity | trần chi phí | | Metric: InvocationsPerInstance | phản ánh lượng việc chính xác hơn CPU |

Câu 62 ML Model Development

You are a machine learning engineer working for a telecommunications company that needs to develop a predictive maintenance model. The goal is to predict when network equipment is likely to fail based on historical sensor data. The data includes features such as temperature, pressure, usage, and error rates recorded over time. The company wants to avoid unplanned downtime and optimize maintenance schedules by predicting failures just in time.

Given the nature of the data and the business objective, which Amazon SageMaker built-in algorithm is the MOST SUITABLE for this use case?

  1. A

    DeepAR Algorithm to forecast future equipment failures based on historical data
  2. B

    Time Series K-Means Algorithm to cluster similar patterns in the sensor data and predict failures
  3. C

    Linear Learner Algorithm to classify equipment status as 'healthy' or 'at risk' based on sensor readings
  4. D

    Random Cut Forest (RCF) Algorithm to detect anomalies in sensor data that may indicate impending failures
Xem giải thích

Đáp án

D — Random Cut Forest (RCF) để phát hiện bất thường trong dữ liệu cảm biến, những dấu hiệu có thể báo trước hỏng hóc sắp xảy ra.

Vì sao đúng

Đề mô tả bài toán bảo trì dự đoán với dữ liệu cảm biến chuỗi thời gian (nhiệt độ, áp suất, mức sử dụng, tỷ lệ lỗi), và mục tiêu là phát hiện sớm dấu hiệu hỏng hóc.

Vì sao phát hiện bất thường là cách tiếp cận đúng cho bài toán này:

Vấn đề của học có giám sát ở đây:
  Hỏng hóc thiết bị là sự kiện HIẾM
  → rất ít mẫu dương để học
  → và mỗi lần hỏng có thể theo một kiểu khác nhau

Phát hiện bất thường:
  Học "trạng thái BÌNH THƯỜNG" trông thế nào (có rất nhiều dữ liệu)
  → cảnh báo khi lệch khỏi bình thường
  → bắt được cả kiểu hỏng CHƯA TỪNG THẤY

Vế cuối là ưu điểm quyết định: một model phân loại chỉ nhận ra những kiểu hỏng đã có trong dữ liệu huấn luyện; phát hiện bất thường bắt được bất kỳ hành vi lạ nào.

RCF phù hợp với dữ liệu cảm biến vì: | Đặc điểm | Chi tiết | |---|---| | Không giám sát | không cần nhãn hỏng hóc | | Xử lý được nhiều chiều | nhiệt độ + áp suất + mức dùng + tỷ lệ lỗi cùng lúc | | Bắt được bất thường theo NGỮ CẢNH | nhiệt độ 70°C bình thường lúc tải cao, bất thường lúc tải thấp | | Cho điểm bất thường liên tục | đặt ngưỡng theo mức chấp nhận rủi ro |

Dòng thứ ba quan trọng: từng chỉ số riêng lẻ có thể nằm trong ngưỡng cho phép, nhưng TỔ HỢP của chúng là bất thường — đó là thứ ngưỡng cứng không bắt được.

Và "predicting failures just in time" trong đề khớp với cách RCF được dùng: điểm bất thường tăng dần thường xuất hiện trước khi hỏng thật, cho đủ thời gian lên lịch bảo trì.

Vì sao các phương án khác sai

  • A. DeepAR dự báo hỏng hóc trong tương lai dựa trên dữ liệu lịch sử — đây là phương án gần nhất và DeepAR là thuật toán chuỗi thời gian mạnh, nhưng nó dự báo GIÁ TRỊ tương lai (nhiệt độ tuần tới là bao nhiêu), không dự đoán SỰ KIỆN hỏng hóc. Bạn có thể ghép nó vào một pipeline (dự báo giá trị rồi so ngưỡng), nhưng đó là cách gián tiếp và kém hiệu quả hơn.
  • C. Linear Learner phân loại trạng thái thiết bị là 'khoẻ' hay 'có nguy cơ' — cần nhãn mà đề không nói là có. Và ngay cả khi có, số ca hỏng thường rất ít, và mỗi ca một kiểu — không đủ để học một ranh giới phân loại tin cậy.
  • B. Time Series K-Means phân cụm các mẫu tương tự trong dữ liệu cảm biến rồi dự đoán hỏng hóc — phân cụm nhóm dữ liệu lại, nó không phát hiện bất thường: một cụm nhỏ có thể là chế độ vận hành hiếm chứ không phải hỏng hóc, và K-Means không cho điểm số để đặt ngưỡng cảnh báo.

Ghi nhớ

Ba cách tiếp cận bảo trì dự đoán — chọn theo dữ liệu có sẵn: | Cách | Điều kiện | Ưu điểm | |---|---|---| | Phát hiện bất thường (RCF) | không cần nhãn hỏng | bắt được kiểu hỏng chưa từng thấy | | Phân loại có giám sát | cần nhiều ca hỏng đã gán nhãn | chính xác hơn với kiểu hỏng đã biết | | Hồi quy RUL (remaining useful life) | cần dữ liệu tới lúc hỏng của nhiều thiết bị | cho biết CÒN BAO LÂU |

Cách thứ ba là mục tiêu lý tưởng nhưng đòi hỏi dữ liệu nhiều nhất — thường chỉ khả thi sau khi đã vận hành hệ thống thu thập dữ liệu nhiều năm.

Ba dịch vụ AWS cho bảo trì dự đoán: | Dịch vụ | Đặc điểm | |---|---| | SageMaker RCF | thuật toán dựng sẵn, linh hoạt | | Amazon Lookout for Equipment | dịch vụ CHUYÊN cho cảm biến thiết bị công nghiệp | | Kinesis Data Analytics RANDOM_CUT_FOREST | phát hiện bất thường trên luồng thời gian thực |

Dòng giữa đáng cân nhắc trong thực tế: Lookout for Equipment được xây riêng cho bài toán này, tự xử lý nhiều chi tiết (đồng bộ nhiều cảm biến, xử lý dữ liệu thiếu) mà tự làm sẽ tốn công.

Ba loại bất thường trong dữ liệu cảm biến: | Loại | Ví dụ | Phát hiện được bằng | |---|---|---| | Điểm | một giá trị vượt xa bình thường | ngưỡng cứng cũng bắt được | | Ngữ cảnh | bình thường nói chung, bất thường LÚC NÀY | cần model | | Tập hợp | từng giá trị bình thường nhưng CHUỖI thì lạ | cần model |

Hai loại sau là lý do cần RCF thay vì chỉ đặt ngưỡng — và cũng là nơi giá trị thật của bảo trì dự đoán nằm.

Và một lưu ý vận hành: đặt ngưỡng cảnh báo là đánh đổi nghiệp vụ. Ngưỡng thấp cho nhiều báo động giả (kỹ thuật viên đi kiểm tra vô ích); ngưỡng cao bỏ lỡ hỏng hóc thật (ngừng máy ngoài kế hoạch). Nên hiệu chỉnh bằng chi phí thực tế của hai loại lỗi, và theo dõi tỷ lệ báo động giả như một chỉ số vận hành.

Câu 63 ML Solution Monitoring, Maintenance, and Security

You are a machine learning engineer at an e-commerce company that uses a recommendation model to suggest products to customers. The model was trained on data from the past year, but after being in production for several months, you notice that the model's recommendations are becoming less relevant. You suspect that either data drift or model drift could be causing the decline in performance. To investigate and resolve the issue, you need to understand the difference between these two types of drift and how to monitor them using Amazon SageMaker.

Which of the following statements BEST describes the difference between data drift and model drift, and how you would address them using Amazon SageMaker?

  1. A

    Data drift occurs when the model’s predictions start to deviate from the expected outcomes, while model drift occurs when the model's accuracy declines due to changes in the input data. SageMaker Pipelines should be used to automate retraining for both types of drift
  2. B

    Data drift occurs when the distribution of the input data changes over time, while model drift happens when the model’s underlying assumptions or parameters become outdated. To address data drift, you should use SageMaker Model Monitor to track changes in input data distribution. For model drift, you should periodically retrain the model using the latest data
  3. C

    Data drift refers to changes in the model’s accuracy due to shifts in the data, while model drift refers to changes in the underlying data features over time. To address both, you should use SageMaker Clarify to detect bias and retrain the model monthly
  4. D

    Data drift is a sudden change in the model’s accuracy, while model drift is a gradual degradation in model performance. You should use SageMaker Feature Store to manage both types of drift by standardizing input data
Xem giải thích

Đáp án

B — Data drift xảy ra khi phân bố dữ liệu đầu vào thay đổi theo thời gian; model drift xảy ra khi giả định hoặc tham số nền của model trở nên lỗi thời. Xử lý data drift bằng Model Monitor theo dõi thay đổi phân bố đầu vào; xử lý model drift bằng huấn luyện lại định kỳ với dữ liệu mới nhất.

Vì sao đúng

Đây là câu hỏi về định nghĩa, và B là phương án duy nhất định nghĩa đúng cả hai khái niệm và ghép đúng công cụ: | Khái niệm | Định nghĩa đúng | |---|---| | Data drift | phân bố ĐẦU VÀO P(X) thay đổi | | Model drift | model trở nên lỗi thời so với thực tế hiện tại |

Ví dụ cụ thể cho hệ thống gợi ý trong đề:

DATA DRIFT:
  Năm ngoái: 70% lưu lượng từ desktop
  Năm nay:   70% từ mobile
  → phân bố đặc trưng "loại thiết bị" đã đổi

MODEL DRIFT:
  Model học "người mua áo khoác cũng mua găng tay"
  Nhưng thời trang đã đổi, quan hệ đó không còn đúng
  → giả định nền của model lỗi thời

Và cách xử lý khác nhau: | Loại | Phát hiện | Xử lý | |---|---|---| | Data drift | Model Monitor so phân bố với baseline | có thể chỉ cần theo dõi, hoặc huấn luyện lại | | Model drift | độ chính xác giảm | huấn luyện lại là cách duy nhất |

Một điểm quan trọng: data drift không luôn có nghĩa model đã hỏng. Nếu phân bố đầu vào đổi nhưng quan hệ đầu vào–nhãn vẫn giữ nguyên, model vẫn hoạt động tốt. Đó là lý do phải theo dõi cả hai, không suy diễn từ một cái sang cái kia.

Vì sao các phương án khác sai

  • A. Data drift là khi dự đoán của model lệch khỏi kết quả mong đợi, model drift là khi độ chính xác giảm do dữ liệu đầu vào thay đổi — đảo ngược cả hai định nghĩa. Và "dùng Pipelines tự động huấn luyện lại cho cả hai" tuy hợp lý về vận hành nhưng không sửa được định nghĩa sai.
  • C. Data drift là thay đổi ĐỘ CHÍNH XÁC do dữ liệu dịch chuyển, model drift là thay đổi trong ĐẶC TRƯNG dữ liệu — cũng đảo ngược. Và "dùng Clarify để phát hiện thiên lệch" là sai công cụ: Clarify đo thiên lệch giữa các nhóm, không đo drift phân bố nói chung.
  • D. Data drift là thay đổi ĐỘT NGỘT về độ chính xác, model drift là suy giảm DẦN DẦN — phân biệt theo tốc độ là sai: cả hai loại drift đều có thể diễn ra đột ngột hoặc từ từ. Và Feature Store không quản lý drift — nó lưu và phục vụ đặc trưng.

Ghi nhớ

Bốn loại drift — phân biệt bằng cái gì thay đổi: | Loại | Ký hiệu | Nghĩa | |---|---|---| | Data drift (covariate shift) | P(X) đổi | phân bố đầu vào | | Concept drift | P(Y|X) đổi | quan hệ đầu vào–nhãn | | Label drift (prior shift) | P(Y) đổi | phân bố nhãn | | Model drift | — | thuật ngữ chung: model không còn phù hợp thực tế |

(Lưu ý: "model drift" là thuật ngữ rộng, thường bao hàm concept drift. Trong đề thi, nó thường được đặt đối lập với data drift theo đúng cách phương án B mô tả.)

Cách nhận biết loại nào đang xảy ra: | Quan sát | Kết luận | |---|---| | Đầu vào đổi, độ chính xác giữ nguyên | data drift vô hại | | Đầu vào đổi, độ chính xác giảm | data drift có hại — huấn luyện lại | | Đầu vào KHÔNG đổi, độ chính xác giảm | concept drift |

Bốn loại giám sát của SageMaker Model Monitor: | Loại | Phát hiện | Cần nhãn thật? | |---|---|---| | Data quality | thay đổi phân bố đầu vào | ❌ | | Model quality | độ chính xác giảm | ✅ | | Bias drift | chênh lệch giữa các nhóm | ❌ | | Feature attribution drift | đặc trưng chi phối đổi | ❌ |

Cột cuối rất quan trọng trong thực tế: model quality monitoring cần nhãn thật, mà nhãn thường đến rất muộn (với gợi ý sản phẩm: khách có mua hay không thì biết ngay, nhưng với dự đoán rời bỏ thì phải chờ hàng tháng). Nên data drift monitoring thường là chỉ báo sớm khả dụng duy nhất.

Và hai điều kiện bắt buộc trước khi giám sát được:

  1. Data capture bật trên endpoint — không bật thì không có gì để phân tích.
  2. Baseline đã tính — suggest_baseline() từ dữ liệu huấn luyện.
Câu 64 Chọn nhiều đáp án ML Model Development

A healthcare company is training a neural network to classify medical images as healthy or abnormal. The ML engineer observes that the model's performance on the validation dataset improves significantly during the early epochs but begins to degrade after a certain number of epochs.

Which solutions will mitigate this problem? (Select two)

  1. A

    Reduce the size of the training dataset to simplify the learning process and avoid overfitting
  2. B

    Increase the number of layers as well as the number of neurons to prevent overfitting
  3. C

    Add dropout layers to the neural network architecture to prevent overfitting
  4. D

    Use early stopping to halt training once the validation loss stops improving
  5. E

    Increase the number of epochs to ensure the model learns the training data thoroughly before stopping
Xem giải thích

Đáp án

C và D.

  • C — Thêm dropout layer vào kiến trúc mạng nơ-ron để chống overfitting
  • D — Dùng early stopping để dừng huấn luyện khi validation loss ngừng cải thiện

Vì sao đúng

Đề mô tả triệu chứng rất rõ: hiệu năng trên tập kiểm chứng cải thiện ở các epoch đầu rồi bắt đầu XẤU ĐI sau một số epoch nhất định.

Đó là định nghĩa của overfitting:

loss │
     │╲                     validation
     │ ╲___         ___╱───
     │     ╲___╱───            ← điểm này: bắt đầu overfit
     │╲
     │ ╲____                training
     │      ╲_____
     └─────────────────────  epoch
              ↑
        điểm dừng lý tưởng

Model đã ngừng học quy luật tổng quát và bắt đầu học thuộc dữ liệu huấn luyện.

D — Early stopping xử lý trực tiếp triệu chứng:

EarlyStopping(monitor='val_loss', patience=10, restore_best_weights=True)

Nó dừng ở đúng điểm tốt nhất và khôi phục trọng số của epoch đó. Đây là cách chữa đơn giản nhất và gần như không có nhược điểm.

C — Dropout xử lý nguyên nhân:

Mỗi bước huấn luyện, ngẫu nhiên "tắt" một tỷ lệ neuron
→ model KHÔNG THỂ phụ thuộc vào một neuron cụ thể nào
→ buộc phải học biểu diễn dư thừa và bền vững hơn

Nó cho phép model học lâu hơn trước khi overfit — nên nó và early stopping bổ sung nhau: dropout đẩy lùi điểm overfit, early stopping bắt đúng điểm đó.

Vì sao các phương án khác sai

  • B. Tăng số tầng và số neuron để chống overfitting — ngược hoàn toàn: model lớn hơn có nhiều tham số hơn, nên overfit dễ hơn và nhanh hơn. Đây là bẫy được thiết kế để bắt người nhầm lẫn giữa "tăng năng lực" với "tăng tổng quát hoá".
  • E. Tăng số epoch để model học kỹ dữ liệu huấn luyện trước khi dừng — làm tình hình tệ hơn: đề đã nói hiệu năng xấu đi sau một số epoch, nên chạy thêm chỉ khiến nó xấu hơn nữa. Và "học kỹ dữ liệu huấn luyện" chính là mô tả của overfitting.
  • A. Giảm kích thước tập huấn luyện để đơn giản hoá quá trình học và tránh overfitting — đây là phương án đáng bàn vì nó nghe có vẻ hợp lý, nhưng ngược hoàn toàn: ít dữ liệu hơn làm overfitting TỆ HƠN. Với ảnh y tế, hướng đúng là tăng dữ liệu — bằng thu thập thêm hoặc data augmentation.

Ghi nhớ

Các kỹ thuật chống overfitting, phân theo tầng: | Tầng | Kỹ thuật | |---|---| | Dữ liệu | thêm dữ liệu, data augmentation, transfer learning | | Kiến trúc | dropout, batch normalization, giảm số tham số | | Huấn luyện | early stopping, L1/L2 regularization, weight decay | | Dự đoán | ensembling, test-time augmentation |

Ưu tiên tầng dữ liệu trước — nó xử lý nguyên nhân gốc. Ba tầng còn lại hạn chế mức độ overfitting nhưng không tăng lượng thông tin model có để học.

Bốn dấu hiệu phân biệt overfitting với các vấn đề khác: | Triệu chứng | Vấn đề | |---|---| | Train thấp, validation cao và TĂNG | overfitting ← đề này | | Cả hai cao, dao động | learning rate quá lớn | | Cả hai cao, phẳng lì | underfitting — model quá đơn giản | | Loss thành NaN | gradient bùng nổ |

Ba tham số của dropout: | Tham số | Giá trị thường dùng | |---|---| | Tỷ lệ dropout ở tầng ẩn | 0,2 – 0,5 | | Tỷ lệ ở tầng đầu vào | 0,1 – 0,2 (thấp hơn) | | Tắt dropout khi suy luận | bắt buộc — framework tự lo |

Dòng cuối là chi tiết kỹ thuật đáng nhớ: dropout chỉ hoạt động lúc huấn luyện. Lúc suy luận, mọi neuron đều bật và đầu ra được chia tỷ lệ tương ứng — framework xử lý tự động, nhưng nếu tự cài đặt thì đây là chỗ dễ sai.

Ba tham số của early stopping: | Tham số | Việc | |---|---| | monitor | theo dõi validation loss, không phải training loss | | patience | chờ bao nhiêu epoch không cải thiện trước khi dừng | | restore_best_weights | khôi phục trọng số tốt nhất — nên luôn bật |

Tham số cuối hay bị quên: không bật thì model giữ trọng số của epoch cuối cùng (đã overfit), chứ không phải epoch tốt nhất.

Và với ảnh y tế nói riêng, data augmentation thường có tác động lớn hơn cả hai kỹ thuật trong đáp án — nhưng nó không nằm trong năm phương án. Trong thực tế, nên dùng cả ba.

Câu 65 Deployment and Orchestration of ML Workflows

A media streaming company processes video metadata using AWS Glue jobs orchestrated by an AWS Glue workflow. These jobs can run on a schedule or be triggered manually. The company is building Amazon SageMaker Pipelines to develop ML models for predicting user engagement with video content. The pipelines require the processed metadata from the AWS Glue jobs during the feature engineering phase of the ML workflow. The company needs a solution to integrate the AWS Glue jobs with SageMaker Pipelines to ensure seamless data flow.

Which solution will meet these requirements with the LEAST operational overhead?

  1. A

    Set up a custom Python script to orchestrate both the AWS Glue workflow and SageMaker Pipelines, ensuring data dependencies are met
  2. B

    Configure an Amazon EventBridge rule to trigger the SageMaker pipeline after the completion of AWS Glue jobs and pass job metadata via Lambda
  3. C

    Integrate the AWS Glue jobs as processing steps in the SageMaker Pipelines workflow to handle data preprocessing
  4. D

    Use SageMaker Pipelines callback steps to wait for the AWS Glue jobs to complete and retrieve the outputs directly from Amazon S3
Xem giải thích

Đáp án

D — Dùng callback step của SageMaker Pipelines để chờ AWS Glue job hoàn thành và lấy đầu ra trực tiếp từ Amazon S3.

Vì sao đúng

Đề nêu bài toán tích hợp: Glue workflow đã có sẵn và SageMaker Pipelines cần dữ liệu đã xử lý từ đó, với tiêu chí ít công sức vận hành nhất.

Callback step là cơ chế dựng sẵn của SageMaker Pipelines để chờ hệ thống bên ngoài:

SageMaker Pipeline
    ↓ CallbackStep: gửi token vào SQS rồi TẠM DỪNG
       ↓
    Lambda nhận message → khởi động Glue workflow
       ↓ (Glue chạy, có thể hàng giờ)
    Glue xong → Lambda gọi SendPipelineExecutionStepSuccess(token)
       ↓
SageMaker Pipeline TIẾP TỤC với dữ liệu từ S3

buoc_glue = CallbackStep(
    name='ChoGlueXuLy',
    sqs_queue_url=url_hang_doi,
    inputs={'s3_input': duong_dan_nguon},
    outputs=[CallbackOutput(output_name='s3_output',
                            output_type=CallbackOutputTypeEnum.String)])

buoc_huan_luyen = TrainingStep(
    name='HuanLuyen',
    inputs={'training': buoc_glue.properties.Outputs['s3_output']})  # ← nối tiếp

Ba lợi ích so với việc điều phối từ bên ngoài: | Lợi ích | Chi tiết | |---|---| | Một pipeline duy nhất | toàn bộ luồng nằm trong một định nghĩa, một lịch sử thực thi | | Phụ thuộc dữ liệu tường minh | bước huấn luyện nhận đầu ra của bước Glue | | Xử lý lỗi thống nhất | Glue hỏng thì pipeline biết và dừng đúng cách |

Và quan trọng nhất về mặt lineage: vì mọi thứ nằm trong một pipeline, SageMaker ghi lại được quan hệ giữa dữ liệu Glue xử lý và model sinh ra từ nó.

Vì sao các phương án khác sai

  • B. EventBridge rule kích hoạt SageMaker pipeline sau khi Glue job xong, truyền metadata qua Lambda — đây là phương án gần nhất và hoàn toàn khả thi trong thực tế. Nó thua ở chỗ hai hệ thống rời rạc: Glue workflow và SageMaker pipeline là hai lần chạy độc lập, nên không có lineage nối liền, và khi có lỗi bạn phải ghép hai nơi để hiểu chuyện gì xảy ra. (Nếu đề không nhấn mạnh "seamless data flow", B sẽ là lựa chọn rất hợp lý.)
  • C. Tích hợp Glue job làm PROCESSING STEP trong SageMaker Pipelines — không tồn tại: ProcessingStep chạy SageMaker Processing job, không chạy được Glue job. Không có step type nào cho Glue.
  • A. Viết script Python tuỳ chỉnh điều phối cả Glue workflow lẫn SageMaker Pipelines — tự dựng lại điều phối: bạn phải tự lo thử lại, xử lý lỗi, theo dõi trạng thái, và chạy script đó ở đâu đó. Trái thẳng tiêu chí "LEAST operational overhead".

Ghi nhớ

Các step của SageMaker Pipelines — nhóm hay dùng: | Step | Việc | |---|---| | ProcessingStep | SageMaker Processing job | | TrainingStep | huấn luyện | | TuningStep | tinh chỉnh siêu tham số | | ConditionStep | rẽ nhánh theo điều kiện | | RegisterModel | đăng ký vào registry | | LambdaStep | gọi Lambda — logic tuỳ ý ngắn | | CallbackStep | TẠM DỪNG chờ hệ thống bên ngoài ← câu này |

Phân biệt hai step cuối: | | LambdaStep | CallbackStep | |---|---|---| | Thời gian | ≤ 15 phút (giới hạn Lambda) | không giới hạn | | Cách hoạt động | gọi và chờ | gửi token, chờ được gọi lại | | Dùng cho | logic ngắn | job dài, hệ thống bên ngoài, chờ người |

Ba tình huống dùng CallbackStep: | Tình huống | Chi tiết | |---|---| | Chờ job bên ngoài | Glue, EMR, hệ thống on-premises | | Chờ người phê duyệt | gửi thông báo, chờ ai đó bấm duyệt | | Chờ dịch vụ bên thứ ba | gọi API rồi chờ webhook |

Cơ chế token giống waitForTaskToken của Step Functions, và nó là mẫu chuẩn cho việc tạm dừng workflow:

sagemaker.send_pipeline_execution_step_success(
    CallbackToken=token,
    OutputParameters=[{'Name': 's3_output', 'Value': duong_dan_ket_qua}])

Và một điều cần chuẩn bị khi dùng CallbackStep: phải có timeout. Nếu hệ thống bên ngoài chết mà không gọi lại, pipeline sẽ treo mãi. SageMaker cho đặt TimeoutInSeconds ở mức pipeline — nên đặt nó dài hơn thời gian chạy Glue tối đa dự kiến, nhưng có giới hạn.

Câu 66 Data Preparation for Machine Learning (ML)

Your company is starting a new machine learning project, and the data preparation tasks are being handled by a team of business analysts. These analysts are more comfortable working with visual tools rather than writing code, and they need to combine, transform, and clean large datasets efficiently. The goal is to use a SageMaker tool that allows them to perform these tasks using a visual, point-and-click interface.

Which SageMaker tool(s) would best suit the team's requirements for preparing and analyzing data without writing code?

  1. A

    Use Amazon SageMaker Data Wrangler within Amazon SageMaker JumpStart
  2. B

    Prepare data with SQL in Amazon SageMaker Studio. The SQL extension connections to Amazon Athena for working with datasets
  3. C

    Use Amazon SageMaker Data Wrangler within Amazon SageMaker Canvas
  4. D

    Prepare data using Amazon EMR in Studio
Xem giải thích

Đáp án

C — Dùng Amazon SageMaker Data Wrangler trong Amazon SageMaker Canvas.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều chỉ về Canvas: | Điều kiện | Cơ chế | |---|---| | Người dùng là nhà phân tích nghiệp vụ, không thoải mái viết mã | Canvas — giao diện không cần mã | | Kết hợp, biến đổi, làm sạch tập dữ liệu lớn | Data Wrangler — 300+ transform | | Giao diện trực quan, thao tác bằng chuột | cả hai đều là point-and-click |

Vì sao Canvas chứ không phải Studio: | | SageMaker Studio | SageMaker Canvas | |---|---|---| | Đối tượng | nhà khoa học dữ liệu, kỹ sư ML | nhà phân tích nghiệp vụ | | Cách làm việc | notebook, viết mã | hoàn toàn trực quan | | Kiến thức cần | Python, ML | không cần |

Data Wrangler có mặt trong cả hai môi trường, nhưng Canvas là môi trường được thiết kế cho người không viết mã — và đề nói rõ đội là "business analysts... more comfortable working with visual tools rather than writing code".

Trong Canvas, luồng làm việc hoàn toàn bằng chuột:

Chọn nguồn dữ liệu (S3, Redshift, Snowflake…)
    ↓ kéo thả để join nhiều bảng
    ↓ chọn transform từ danh sách (xử lý thiếu, mã hoá, chuẩn hoá)
    ↓ xem biểu đồ và thống kê ngay tại chỗ
    ↓ xuất kết quả

Vì sao các phương án khác sai

  • **A. Dùng Data Wrangler trong SageMaker JumpStart — JumpStart không phải môi trường làm việc: nó là kho model đã huấn luyện sẵn và mẫu giải pháp. Data Wrangler không nằm trong JumpStart.
  • B. Chuẩn bị dữ liệu bằng SQL trong SageMaker Studio, dùng SQL extension kết nối Athena — yêu cầu viết SQL, trái thẳng điều kiện "without writing code". Và Studio là môi trường cho người viết mã.
  • **D. Chuẩn bị dữ liệu bằng Amazon EMR trong Studio — tốn công nhất và cần viết mã Spark. Hoàn toàn không phù hợp với nhà phân tích nghiệp vụ.

Ghi nhớ

Ba môi trường ML của SageMaker — chọn theo đối tượng người dùng: | Môi trường | Dành cho | Cách làm việc | |---|---|---| | Studio | nhà khoa học dữ liệu, kỹ sư ML | notebook, mã | | Canvas | nhà phân tích nghiệp vụ | hoàn toàn trực quan | | JumpStart | mọi đối tượng | kho model và mẫu giải pháp |

Khả năng của SageMaker Canvas: | Khả năng | Chi tiết | |---|---| | Chuẩn bị dữ liệu | Data Wrangler tích hợp | | Xây model không cần mã | AutoML — chọn cột mục tiêu là xong | | Dự đoán | chạy dự đoán theo lô hoặc từng dòng | | Dùng foundation model | truy cập Bedrock và JumpStart | | Chia sẻ với đội ML | xuất model sang Studio để tinh chỉnh thêm |

Dòng cuối là một điểm mạnh về mặt tổ chức: nhà phân tích dựng bản thử nghiệm trong Canvas, rồi đội ML tiếp nhận trong Studio để đưa vào sản xuất — hai bên làm việc trên cùng một artifact thay vì bắt đầu lại từ đầu.

Bốn khả năng của Data Wrangler mà nhà phân tích dùng được ngay: | Khả năng | Việc | |---|---| | Kết nối nhiều nguồn | S3, Athena, Redshift, Snowflake, JDBC | | 300+ transform dựng sẵn | không viết mã | | Data Quality and Insights Report | phát hiện vấn đề tự động | | Quick Model | ước lượng nhanh chất lượng đặc trưng |

Và một lưu ý về chi phí đáng biết với Canvas: phiên làm việc tính tiền theo giờ, và nó không tự tắt khi bạn đóng trình duyệt. Cần đăng xuất khỏi ứng dụng Canvas khi xong — đây là nguyên nhân phổ biến của hoá đơn bất ngờ với đội mới dùng.

Câu 67 ML Model Development

You are a machine learning engineer tasked with deploying a machine learning model to a mobile device for real-time object detection. The model currently performs well but is too large to fit within the device's memory and computational constraints. To ensure the model can run efficiently on the device without sacrificing too much accuracy, you need to reduce its size.

Given these constraints, which combination of techniques is the MOST LIKELY to effectively reduce the model’s size while maintaining acceptable performance?

  1. A

    Prune the model by removing less important neurons and layers, and apply quantization to reduce the precision of the model’s weights from 32-bit to 8-bit
  2. B

    Apply dimensionality reduction using PCA on the input data, and use model ensembling to combine smaller models, which collectively match the performance of the original model
  3. C

    Use feature selection to reduce the number of input features, compress the model by converting the model weights from floating-point to integer format
  4. D

    Reduce the size of the training dataset, use dropout to decrease model complexity, thereby shrinking the deployed model size
Xem giải thích

Đáp án

A — Cắt tỉa (prune) model bằng cách loại bỏ neuron và tầng ít quan trọng, và áp dụng quantization để giảm độ chính xác của trọng số từ 32-bit xuống 8-bit.

Vì sao đúng

Đề nêu ba ràng buộc: model quá lớn cho bộ nhớ thiết bị, giới hạn tính toán, và không được hy sinh quá nhiều độ chính xác.

Hai kỹ thuật trong đáp án tấn công hai chiều khác nhau của kích thước: | Kỹ thuật | Giảm gì | Mức giảm | |---|---|---| | Pruning | SỐ LƯỢNG tham số | 30–90% tuỳ mức | | Quantization | KÍCH THƯỚC mỗi tham số | 32-bit → 8-bit = giảm 4 lần |

Vì chúng tác động vào hai chiều độc lập, hiệu quả nhân lên:

Model gốc:                    100 MB
Sau pruning (bỏ 50% tham số):  50 MB
Sau quantization (32→8 bit):   12,5 MB    ← đủ nhỏ cho thiết bị di động

Quantization còn có lợi ích thứ hai quan trọng cho thiết bị di động: tốc độ. Phép toán số nguyên 8-bit nhanh hơn nhiều so với dấu phẩy động 32-bit, và nhiều chip di động có đơn vị tăng tốc chuyên cho INT8.

Và cả hai đều giữ được độ chính xác chấp nhận được khi làm đúng cách: | Kỹ thuật | Giữ độ chính xác bằng cách | |---|---| | Pruning | cắt dần rồi tinh chỉnh lại (iterative pruning + fine-tuning) | | Quantization | quantization-aware training — model học với ràng buộc 8-bit |

Vì sao các phương án khác sai

  • C. Feature selection giảm số đặc trưng đầu vào, và nén model bằng cách chuyển trọng số từ dấu phẩy động sang số nguyên — đây là phương án gần nhất và vế thứ hai chính là quantization (đúng). Nhưng vế đầu sai kịch bản: với phát hiện vật thể trong ảnh, "đặc trưng đầu vào" là các điểm ảnh — bạn không "chọn lọc" chúng được. Feature selection áp dụng cho dữ liệu bảng, không cho ảnh.
  • B. PCA giảm chiều dữ liệu đầu vào, và dùng ensembling ghép nhiều model nhỏ để đạt hiệu năng tương đương model gốc — hai lỗi: PCA giảm chiều dữ liệu, không giảm kích thước model; và ensembling LÀM TĂNG tổng kích thước — nhiều model cộng lại thường lớn hơn một model.
  • D. Giảm kích thước tập huấn luyện, dùng dropout để giảm độ phức tạp model và thu nhỏ model triển khai — hiểu sai cả hai: kích thước tập huấn luyện không ảnh hưởng kích thước model đã huấn luyện; và dropout chỉ hoạt động lúc huấn luyện — nó bị tắt khi suy luận và không làm model nhỏ đi chút nào.

Ghi nhớ

Bốn kỹ thuật nén model cho thiết bị biên: | Kỹ thuật | Cách làm | Mức giảm | |---|---|---| | Quantization | giảm độ chính xác số: FP32 → INT8 hoặc INT4 | 4–8 lần | | Pruning | loại bỏ trọng số, neuron, tầng ít quan trọng | 2–10 lần | | Knowledge distillation | model nhỏ học bắt chước model lớn | tuỳ thiết kế, có thể rất lớn | | Kiến trúc hiệu quả | MobileNet, EfficientNet thay ResNet | tuỳ chọn |

Ba kỹ thuật đầu kết hợp được với nhau — mẫu thường dùng cho thiết bị di động là: chưng cất sang kiến trúc nhỏ → cắt tỉa → lượng tử hoá.

Hai loại quantization: | Loại | Đặc điểm | |---|---| | Post-training quantization | nhanh, không cần huấn luyện lại; mất chút độ chính xác | | Quantization-aware training (QAT) | model học với ràng buộc 8-bit — giữ độ chính xác tốt hơn |

Với ràng buộc "without sacrificing too much accuracy" trong đề, QAT là lựa chọn đúng dù tốn thêm một vòng huấn luyện.

Hai loại pruning: | Loại | Đặc điểm | |---|---| | Unstructured | bỏ từng trọng số lẻ — nén tốt nhưng cần phần cứng hỗ trợ ma trận thưa | | Structured | bỏ cả kênh hoặc tầng — nén ít hơn nhưng NHANH trên mọi phần cứng |

Dòng thứ hai đáng chú ý cho thiết bị di động: unstructured pruning làm model nhỏ về dung lượng nhưng không nhanh hơn trên phần cứng thông thường, vì ma trận thưa vẫn được lưu và tính như ma trận đầy. Nếu mục tiêu là tốc độ, structured pruning mới có tác dụng.

Ba công cụ AWS cho triển khai lên thiết bị biên: | Công cụ | Việc | |---|---| | SageMaker Neo | biên dịch và tối ưu model cho phần cứng đích cụ thể | | SageMaker Edge Manager | quản lý model trên đội thiết bị | | AWS IoT Greengrass | chạy suy luận tại biên |

SageMaker Neo đáng nhắc riêng: nó tối ưu model cho đúng chip đích (ARM, Nvidia Jetson, Intel), thường cho tốc độ tăng nhiều lần mà không cần đổi model — nên đáng thử trước khi nén thủ công.

Câu 68 ML Model Development

You are a data scientist working for a healthcare company that develops predictive models for diagnosing diseases based on patient data. Due to regulatory requirements and the critical nature of healthcare decisions, model interpretability is a top priority. The company needs to ensure that the predictions made by the model can be explained to both medical professionals and regulatory bodies.

You are evaluating different algorithms in Amazon SageMaker for your model, balancing the trade-off between accuracy and interpretability. The initial trials show that more complex models like deep neural networks (DNNs) yield higher accuracy but are less interpretable, whereas simpler models like logistic regression provide clearer insights but may not perform as well on the dataset.

Given these considerations, which of the following approaches is MOST APPROPRIATE for achieving both interpretability and acceptable performance?

  1. A

    Choose a logistic regression model due to its high interpretability and supplement it with additional data preprocessing to improve accuracy
  2. B

    Deploy an ensemble of models including a complex model for accuracy and a simpler model for interpretability, using model stacking in SageMaker
  3. C

    Select a deep neural network (DNN) model and use SHAP (SHapley Additive exPlanations) to provide interpretability
  4. D

    Use a tree-based algorithm like XGBoost, which offers a balance between accuracy and interpretability with feature importance
Xem giải thích

Đáp án

D — Dùng thuật toán dựa trên cây như XGBoost, vốn cho cân bằng giữa độ chính xác và khả năng diễn giải nhờ feature importance.

Vì sao đúng

Đề đặt ra một đánh đổi rõ ràng: DNN chính xác hơn nhưng khó diễn giải, hồi quy logistic dễ hiểu nhưng kém chính xác. Câu hỏi là tìm điểm cân bằng.

XGBoost nằm đúng ở giữa: | Tiêu chí | Hồi quy logistic | XGBoost | DNN | |---|---|---|---| | Độ chính xác (dữ liệu bảng) | thấp | cao nhất | vừa | | Diễn giải được | rất cao | khá cao | thấp | | Chi phí tính toán | thấp | vừa | cao |

Và một điểm quan trọng thường bị bỏ qua: với dữ liệu bảng, XGBoost thường CHÍNH XÁC HƠN DNN, không phải chỉ ngang bằng. Nên "đánh đổi" ở đây thực ra không phải đánh đổi — bạn được cả hai.

XGBoost cung cấp ba mức diễn giải: | Mức | Công cụ | |---|---| | Toàn cục | feature importance — đặc trưng nào quan trọng nói chung | | Cục bộ | TreeSHAP — vì sao bệnh nhân NÀY được dự đoán như vậy | | Quan hệ | PDP — hình dạng ảnh hưởng của một đặc trưng |

TreeSHAP đáng nhắc riêng: nó tính giá trị Shapley chính xác và nhanh cho model cây — trong khi với DNN phải dùng xấp xỉ (KernelSHAP) vừa chậm vừa kém tin cậy hơn.

Với chẩn đoán bệnh, mức thứ hai là thứ bác sĩ cần: "vì sao hệ thống cho rằng bệnh nhân này có nguy cơ cao?"

Vì sao các phương án khác sai

  • C. Chọn DNN và dùng SHAP để cung cấp khả năng diễn giải — đây là phương án gần nhất và hoàn toàn hợp lệ về mặt kỹ thuật. Nó thua ở hai điểm: DNN thường không chính xác hơn XGBoost trên dữ liệu bảng y tế, và SHAP cho DNN chậm và là xấp xỉ. Chọn một model vốn đã dễ diễn giải hơn là lựa chọn hợp lý hơn khi hiệu năng tương đương.
  • A. Chọn hồi quy logistic vì tính diễn giải cao và bổ sung tiền xử lý dữ liệu để cải thiện độ chính xác — hy sinh độ chính xác không cần thiết: đề nói rõ hồi quy logistic "may not perform as well". Tiền xử lý tốt giúp được nhưng không bù được việc model tuyến tính không nắm được tương tác phi tuyến — vốn phổ biến trong dữ liệu y tế.
  • B. Triển khai ensemble gồm một model phức tạp cho độ chính xác và một model đơn giản cho khả năng diễn giải, dùng stacking — giải thích SAI: nếu model đơn giản chỉ dùng để "giải thích" model phức tạp, thì nó không giải thích thứ thật sự đưa ra quyết định. Đây là minh bạch giả, và trong y tế thì nguy hiểm — bác sĩ tin vào một lời giải thích không phản ánh logic thật.

Ghi nhớ

Phổ đánh đổi giữa độ chính xác và khả năng diễn giải:

Diễn giải cao ←──────────────────────────→ Chính xác cao (nói chung)
Linear/Logistic   Decision Tree   XGBoost   Random Forest   DNN

Nhưng với DỮ LIỆU BẢNG, phổ này không đúng ở đầu bên phải: XGBoost thường thắng DNN. Nên điểm ngọt cho dữ liệu y tế dạng bảng nằm ở XGBoost.

Hai khái niệm cần phân biệt: | Khái niệm | Nghĩa | |---|---| | Interpretability | bản thân model đủ đơn giản để hiểu trực tiếp | | Explainability | model phức tạp + công cụ giải thích từng dự đoán |

Ba kỹ thuật giải thích và tốc độ: | Kỹ thuật | Model | Tốc độ | |---|---|---| | TreeSHAP | chỉ model cây | nhanh, CHÍNH XÁC | | KernelSHAP | mọi model | chậm, xấp xỉ | | LIME | mọi model | nhanh, xấp xỉ cục bộ |

Ba lý do cần diễn giải trong y tế: | Lý do | Chi tiết | |---|---| | Yêu cầu quy định | quyết định tự động ảnh hưởng tới người phải giải thích được | | Chấp nhận của bác sĩ | không ai dùng công cụ mình không hiểu | | Phát hiện lỗi model | đặc trưng quan trọng bất thường thường là rò rỉ dữ liệu |

Lý do thứ ba có một ví dụ kinh điển: một model chẩn đoán viêm phổi từ ảnh X-quang hoạt động rất tốt cho tới khi người ta phát hiện nó đang học nhận diện loại máy chụp — vì máy di động thường dùng cho bệnh nhân nặng. Chỉ có công cụ giải thích mới lộ ra được điều đó.

Và một lưu ý: SageMaker Clarify cung cấp SHAP và PDP cho mọi model, chạy được như một ProcessingStep — nên báo cáo giải thích được sinh tự động cho mỗi phiên bản model, không phải làm thủ công.

Câu 69 ML Model Development

A healthcare organization is developing a deep learning model on Amazon SageMaker to predict patient outcomes. The training dataset is substantial, and the organization aims to optimize the model's hyperparameters to minimize the validation dataset's loss function.

Which hyperparameter tuning strategy should the organization use to achieve this goal with the least computational effort?

  1. A

    Random Forest
  2. B

    Hyperband
  3. C

    Gradient descent
  4. D

    Grid search
Xem giải thích

Đáp án

B — Hyperband.

Vì sao đúng

Đề nêu hai yếu tố quyết định: model deep learning với tập dữ liệu lớn, và ít công sức tính toán nhất.

Hyperband được thiết kế chính xác cho tình huống này — nó dừng sớm những cấu hình kém thay vì chạy hết mọi lần thử:

Chiến lược khác:  chạy ĐỦ 100 epoch cho MỌI cấu hình
                  → cấu hình tệ vẫn tốn đủ tài nguyên

Hyperband:        chạy tất cả 10 epoch → giữ 50% tốt nhất
                  chạy tiếp 20 epoch  → giữ 50% tốt nhất
                  chạy tiếp 40 epoch  → giữ 50% tốt nhất
                  → chỉ cấu hình hứa hẹn mới được chạy đủ

Đó là ý nghĩa của "least computational effort" — không phải ít lần thử hơn, mà ít tài nguyên lãng phí hơn cho mỗi lần thử.

Vì sao Hyperband đặc biệt hợp với deep learning: model deep learning huấn luyện theo epoch, và chất lượng cuối cùng thường lộ ra sớm — một cấu hình có loss cao sau 10 epoch hiếm khi trở thành tốt nhất sau 100 epoch. Hyperband khai thác đúng đặc tính đó.

tuner = HyperparameterTuner(
    estimator=estimator,
    strategy='Hyperband',
    objective_metric_name='validation:loss',
    objective_type='Minimize',
    hyperparameter_ranges=khoang_gia_tri,
    max_jobs=100, max_parallel_jobs=10)

Với model dữ liệu bảng huấn luyện nhanh, lợi ích của Hyperband nhỏ hơn — nhưng với deep learning trên dữ liệu lớn (mỗi lần thử tốn hàng giờ GPU), nó tiết kiệm rất đáng kể.

Vì sao các phương án khác sai

  • **D. Grid search — đây là phương án gần nhất về mặt "là một chiến lược tinh chỉnh thật", nhưng nó tốn kém nhất: vét cạn mọi tổ hợp, và số lần thử bùng nổ theo số siêu tham số. Với deep learning trên dữ liệu lớn, đây là lựa chọn tệ nhất về chi phí.
  • **A. Random Forest — không phải chiến lược tinh chỉnh: đây là một thuật toán học máy. Nó không liên quan gì tới việc tìm siêu tham số.
  • **C. Gradient descent — thuật toán tối ưu TRỌNG SỐ trong quá trình huấn luyện, không phải để tìm siêu tham số. Nó hoạt động ở tầng khác hẳn: gradient descent tìm trọng số tốt nhất cho một bộ siêu tham số đã cho; tinh chỉnh siêu tham số tìm bộ siêu tham số tốt nhất.

Ghi nhớ

Bốn chiến lược tinh chỉnh siêu tham số của SageMaker: | Chiến lược | Cách làm | Tiết kiệm | |---|---|---| | Grid | vét cạn mọi tổ hợp | tệ nhất | | Random | chọn ngẫu nhiên | song song tốt | | Bayesian | học từ lần thử trước | hiệu quả nhất theo SỐ LẦN THỬ | | Hyperband | dừng sớm nhánh kém | hiệu quả nhất theo TÀI NGUYÊN |

Phân biệt hai chiến lược tốt nhất — chúng tối ưu hai thứ khác nhau: | | Bayesian | Hyperband | |---|---|---| | Tối ưu | số lần thử cần thiết | tài nguyên mỗi lần thử | | Song song | kém hiệu quả khi song song cao | song song tốt | | Hợp với | mỗi lần thử NHANH | mỗi lần thử CHẬM (deep learning) | | Cần | không yêu cầu đặc biệt | model phải báo chỉ số theo từng epoch |

Dòng cuối là điều kiện kỹ thuật của Hyperband: nó cần chỉ số trung gian để quyết định dừng sớm. Model phải phát ra validation:loss sau mỗi epoch — nếu chỉ báo một lần lúc kết thúc thì Hyperband không có gì để dựa vào.

Cách chọn theo tình huống: | Tình huống | Chọn | |---|---| | Deep learning, mỗi lần thử tốn hàng giờ | Hyperband | | Model nhanh, muốn ít lần thử nhất | Bayesian | | Nhiều tài nguyên song song, muốn nhanh | Random | | Không gian rất nhỏ (2–3 giá trị) | Grid |

Và ba nguyên tắc chung cho mọi chiến lược: | Nguyên tắc | Chi tiết | |---|---| | Chỉ tinh chỉnh 2–4 siêu tham số quan trọng nhất | nhiều chiều hơn = không gian lớn theo cấp số nhân | | Dùng thang log cho tham số biến thiên nhiều bậc | learning rate, regularization | | Đặt khoảng hợp lý | khoảng quá rộng lãng phí lần thử vào vùng vô nghĩa |

Với hầu hết model, learning rate là siêu tham số quan trọng nhất — nếu chỉ tinh chỉnh được một thứ, hãy chọn nó.

Câu 70 Chọn nhiều đáp án Deployment and Orchestration of ML Workflows

You are a Senior ML Engineer at a global logistics company that heavily relies on machine learning models for optimizing delivery routes, predicting demand, and detecting anomalies in real-time. The company is rapidly expanding, and you are tasked with building a maintainable, scalable, and cost-effective ML infrastructure that can handle increasing data volumes and evolving model requirements. You must implement best practices to ensure that the infrastructure can support ongoing development, deployment, monitoring, and scaling of multiple models across different regions.

Which of the following strategies should you implement to create a maintainable, scalable, and cost-effective ML infrastructure for your company using AWS services? (Select three)

  1. A

    Store all model artifacts and data in Amazon S3, and use versioning to manage changes over time, ensuring that models can be easily rolled back if needed
  2. B

    Provision fixed resources for each model to avoid unexpected costs, ensuring that the infrastructure is always available for each model
  3. C

    Utilize infrastructure as code (IaC) with AWS CloudFormation to automate the deployment and management of ML resources, making it easy to replicate and scale infrastructure across regions
  4. D

    Use a monolithic architecture to manage all machine learning models in a single environment, simplifying management and reducing overhead
  5. E

    Implement a microservices-based architecture with Amazon SageMaker endpoints, where each model is deployed independently, allowing for isolated scaling and updates
  6. F

    Store all model artifacts and data in Amazon CodeCommit for version control and managing changes over time
Xem giải thích

Đáp án

A, C và E.

  • A — Lưu artifact model và dữ liệu trên S3 với versioning, để rollback được khi cần
  • C — Dùng hạ tầng là mã (IaC) với CloudFormation tự động hoá triển khai và quản lý tài nguyên ML, dễ nhân bản và mở rộng qua nhiều Region
  • E — Triển khai theo kiến trúc microservice với SageMaker endpoint, mỗi model độc lập, cho phép co giãn và cập nhật riêng biệt

Vì sao đúng

Đề yêu cầu ba tính chất, và ba đáp án chia nhau: | Tính chất | Đáp án | |---|---| | Bảo trì được (maintainable) | C — IaC | | Mở rộng được (scalable) | E — microservice | | Hiệu quả chi phí + rollback | A — S3 versioning; E — co giãn độc lập |

A — S3 với versioning cho hai thứ: một nơi lưu trữ duy nhất cho mọi artifact, và khả năng quay lại phiên bản trước khi model mới có vấn đề. S3 cũng rẻ, bền và tích hợp với mọi dịch vụ ML.

C — IaC là nền tảng của "maintainable" và "replicate across regions":

# Cùng một template, ba Region, ba môi trường
aws cloudformation deploy --template ml-stack.yaml   --parameter-overrides Environment=prod Region=ap-northeast-1

Ba lợi ích: nhất quán giữa các môi trường, có lịch sử thay đổi, và rollback được cả hạ tầng.

E — microservice cho "scalable":

Endpoint riêng cho mỗi model:
  ├─ tối-ưu-tuyến-đường  → co giãn theo lưu lượng của riêng nó
  ├─ dự-báo-nhu-cầu      → cập nhật độc lập, không ảnh hưởng cái khác
  └─ phát-hiện-bất-thường → chọn loại instance phù hợp riêng

Ba lợi ích: cách ly lỗi, co giãn độc lập, triển khai độc lập — một model cập nhật không đụng tới hai model kia.

Vì sao các phương án khác sai

  • B. Cấp phát tài nguyên CỐ ĐỊNH cho mỗi model để tránh chi phí bất ngờ, đảm bảo hạ tầng luôn sẵn sàng — đây là phương án nghe hợp lý nhất trong ba cái sai, nhưng nó trái yêu cầu hiệu quả chi phí: tài nguyên cố định nghĩa là trả tiền cho đỉnh tải 24/7. Với công ty đang mở rộng nhanh, đó là chi phí tăng tuyến tính theo số model.
  • D. Dùng kiến trúc nguyên khối (monolithic) quản lý mọi model trong một môi trường, đơn giản hoá quản lý — trái thẳng yêu cầu scalable: một model cần nhiều tài nguyên buộc phải mở rộng cả khối; một model lỗi ảnh hưởng tất cả; và mọi cập nhật đều phải triển khai lại toàn bộ.
  • F. Lưu artifact model và dữ liệu trong AWS CodeCommit để quản lý phiên bản — sai công cụ: CodeCommit là kho mã nguồn Git, không thiết kế cho tệp nhị phân lớn. Artifact model hàng trăm MB tới GB sẽ làm repo phình và chậm. (Mã huấn luyện thì nên ở Git; artifact thì ở S3.)

Ghi nhớ

Ba trụ cột của hạ tầng ML bền vững: | Trụ cột | Cơ chế | |---|---| | Bảo trì được | IaC, quy ước đặt tên, tài liệu, giám sát tự động | | Mở rộng được | microservice, auto-scaling, tài nguyên độc lập | | Hiệu quả chi phí | co giãn theo tải, Spot cho huấn luyện, co về 0 khi rảnh |

Nơi lưu từng loại artifact — bảng nên thuộc: | Loại | Nơi đúng | |---|---| | Mã huấn luyện | Git (CodeCommit, GitHub) | | Artifact model | S3 | | Container image | ECR | | Metadata model | SageMaker Model Registry | | Đặc trưng | Feature Store | | Template hạ tầng | Git |

Ba lợi ích của kiến trúc microservice cho ML: | Lợi ích | Chi tiết | |---|---| | Cách ly lỗi | một model hỏng không kéo theo cái khác | | Co giãn độc lập | mỗi model có mẫu lưu lượng riêng | | Triển khai độc lập | cập nhật một model không cần dừng cái khác |

Và một đánh đổi cần biết: microservice tốn hơn về vận hành — nhiều endpoint hơn nghĩa là nhiều thứ phải giám sát. Với ít model và tải thấp, multi-model endpoint (xem #6446) là điểm cân bằng tốt hơn: chia sẻ tài nguyên nhưng vẫn tách biệt về logic.

Ba thực hành nên có cho hạ tầng ML đa Region: | Thực hành | Chi tiết | |---|---| | Một template, nhiều tham số | không sao chép template cho từng Region | | Kiểm tra model có sẵn ở Region đích | không phải model nào cũng có ở mọi Region | | Sao chép artifact bằng S3 replication | tự động, không phải script tay |