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

Tìm thấy 635 câu.

Câu 101 ML Model Development

A telecommunications company receives real-time network performance data streams from thousands of devices across its infrastructure. The data streams consist of thousands of JSON records per second, detailing metrics like latency, packet loss, and jitter. The company needs to implement a scalable solution on AWS to monitor these metrics and detect anomalies in real time with the least operational overhead.

Which solution will meet these requirements?

  1. A

    Use Amazon Kinesis Data Streams to ingest the data, process it with Apache Flink to analyze the streams in real time, and apply the RANDOM_CUT_FOREST algorithm to detect anomalies
  2. B

    Use Amazon Kinesis Firehose for real-time streaming of the network metrics data into an Amazon S3 bucket, then periodically run an AWS Glue ETL job to detect anomalies using a custom Python script
  3. C

    Ingest the data using Amazon Kinesis Data Streams, analyze the network metrics using Amazon Comprehend, and identify anomalies with a SageMaker model
  4. D

    Use AWS Lambda to process the network metrics streams in real time and write a custom function to detect anomalies directly from the data
Xem giải thích

Đáp án

A — Dùng Kinesis Data Streams thu nhận dữ liệu, xử lý bằng Apache Flink để phân tích luồng theo thời gian thực, và áp thuật toán RANDOM_CUT_FOREST để phát hiện bất thường.

Vì sao đúng

Đề nêu ba yêu cầu, và đáp án A khớp cả ba: | Yêu cầu | Cơ chế | |---|---| | Hàng nghìn bản ghi JSON mỗi giây | Kinesis Data Streams — thu nhận quy mô lớn | | Phát hiện bất thường THỜI GIAN THỰC | Flink xử lý luồng + RCF | | Ít công sức vận hành nhất | Managed Service for Apache Flink — được quản lý |

RANDOM_CUT_FOREST là hàm dựng sẵn trong Managed Service for Apache Flink (trước đây là Kinesis Data Analytics) — bạn không huấn luyện gì, chỉ khai trong câu SQL:

CREATE STREAM bat_thuong (
    do_tre DOUBLE, mat_goi DOUBLE, jitter DOUBLE, diem_bat_thuong DOUBLE);

CREATE PUMP bom AS INSERT INTO bat_thuong
SELECT STREAM do_tre, mat_goi, jitter, ANOMALY_SCORE
FROM TABLE(RANDOM_CUT_FOREST(
    CURSOR(SELECT STREAM do_tre, mat_goi, jitter FROM nguon_kinesis)));

Vì sao RCF phù hợp cho metric mạng: | Đặc điểm | Chi tiết | |---|---| | Không giám sát | không cần nhãn "đây là sự cố mạng" | | Đa chiều | xét độ trễ + mất gói + jitter CÙNG LÚC | | Học liên tục trên luồng | tự thích nghi khi mẫu bình thường thay đổi | | Cho điểm liên tục | đặt ngưỡng cảnh báo theo mức chấp nhận |

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

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

  • D. Dùng AWS Lambda xử lý luồng theo thời gian thực và tự viết hàm phát hiện bất thường trực tiếp từ dữ liệu — đây là phương án gần nhất và khả thi, nhưng nó tự viết thuật toán phát hiện bất thường — trái tiêu chí "least operational overhead". Và Lambda xử lý từng lô message độc lập, nên rất khó duy trì trạng thái cửa sổ thời gian mà phát hiện bất thường cần.
  • B. Dùng Firehose đưa dữ liệu vào S3, rồi chạy Glue ETL ĐỊNH KỲ phát hiện bất thường bằng script Python tuỳ chỉnh — không phải thời gian thực: Firehose có buffer, và Glue chạy theo lịch — độ trễ tính bằng phút tới giờ. Trái thẳng yêu cầu "in real time".
  • C. Kinesis Data Streams thu nhận, dùng Amazon Comprehend phân tích metric mạng, phát hiện bất thường bằng model SageMaker — Comprehend xử lý NGÔN NGỮ TỰ NHIÊN, không xử lý được metric số. Đây là dùng sai dịch vụ hoàn toàn.

Ghi nhớ

Kiến trúc phát hiện bất thường theo thời gian thực trên AWS:

Nguồn dữ liệu
    ↓ Kinesis Data Streams (thu nhận)
    ↓ Managed Service for Apache Flink (xử lý + RANDOM_CUT_FOREST)
    ↓ điểm bất thường vượt ngưỡng
    ↓ Lambda / SNS (cảnh báo) + S3 (lưu trữ)

Bốn dịch vụ streaming và vai trò: | Dịch vụ | Việc | |---|---| | Kinesis Data Streams | thu nhận, lưu tạm, nhiều consumer | | Kinesis Data Firehose | giao tới đích, có buffer | | Managed Service for Apache Flink | XỬ LÝ và tổng hợp luồng | | Amazon MSK | Kafka được quản lý |

Ba nơi có thể chạy Random Cut Forest: | Nơi | Đặc điểm | |---|---| | Managed Flink (RANDOM_CUT_FOREST) | trên luồng, thời gian thực, khai bằng SQL | | SageMaker RCF (thuật toán dựng sẵn) | theo lô hoặc endpoint, kiểm soát nhiều hơn | | Amazon Lookout for Metrics | dịch vụ chuyên phát hiện bất thường trên metric nghiệp vụ |

Dòng cuối đáng cân nhắc trong thực tế: Lookout for Metrics được xây riêng cho việc giám sát chỉ số và tự động tìm nguyên nhân — không nằm trong bốn phương án, nhưng phù hợp với bài toán này.

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

Hai loại sau là lý do cần model thay vì chỉ đặt ngưỡng — và cũng là nơi giá trị thật của việc phát hiện bất thường nằm.

Và một tham số cần điều chỉnh: ngưỡng điểm bất thường. Quá thấp cho nhiều báo động giả (đội vận hành mất niềm tin và bỏ qua cảnh báo); quá cao bỏ lỡ sự cố thật. Nên theo dõi tỷ lệ báo động giả như một chỉ số vận hành và hiệu chỉnh định kỳ.

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

You are the senior project manager at a global e-commerce company that runs multiple machine learning projects, including recommendation systems, fraud detection, and demand forecasting. The company has a cloud budget that is tightly monitored, and you are required to provide detailed reports on the costs associated with each ML project. To do this effectively, you need to track and allocate costs across different teams and projects, ensuring that each project stays within its allocated budget.

Which of the following approaches is the MOST EFFECTIVE for tracking and allocating costs across your ML projects using AWS services?

  1. A

    Set up AWS Budgets for each project and rely on the alerts when the budget threshold is exceeded. Use these alerts to monitor costs and manually adjust resource usage as needed
  2. B

    Create separate AWS accounts for each ML project, allowing costs to be isolated and tracked at the account level. Manually aggregate the costs for reporting purposes using monthly billing statements
  3. C

    Implement resource tagging across all AWS resources used by your ML projects, including SageMaker instances, S3 buckets, and Lambda functions. Use AWS Cost Explorer to filter costs by tags such as project, team, and environment to generate detailed cost reports
  4. D

    Use Amazon CloudWatch to monitor usage metrics for each resource and manually calculate the associated costs based on the metrics. Allocate costs by assigning each resource to a specific project or team
Xem giải thích

Đáp án

C — Triển khai gắn thẻ (tagging) tài nguyên trên mọi tài nguyên AWS mà các dự án ML dùng, gồm SageMaker instance, S3 bucket và Lambda function; dùng AWS Cost Explorer lọc chi phí theo thẻ như dự án, đội và môi trường để sinh báo cáo chi tiết.

Vì sao đúng

Đề nêu ba yêu cầu, và tagging cộng Cost Explorer đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Theo dõi và phân bổ chi phí theo đội và dự án | cost allocation tag | | Báo cáo chi tiết | Cost Explorer lọc và nhóm theo thẻ | | Đảm bảo mỗi dự án trong ngân sách | tag + AWS Budgets theo tag |

Tagging là cơ chế phân bổ chi phí chuẩn của AWS, và nó cho nhiều chiều cắt cùng lúc:

Tag trên mỗi tài nguyên:
  Project     = he-thong-goi-y
  Team        = doi-ca-nhan-hoa
  Environment = production
  CostCenter  = CC-4471

Rồi trong Cost Explorer:

Nhóm theo: Project     → chi phí từng dự án
Nhóm theo: Team        → chi phí từng đội
Lọc theo:  Environment = production   → tách dev khỏi prod

Điểm mạnh so với tách tài khoản: linh hoạt. Một tài nguyên có thể mang nhiều thẻ, nên bạn cắt chi phí theo bất kỳ chiều nào mà không phải tổ chức lại hạ tầng.

Một bước bắt buộc dễ quên: thẻ phải được kích hoạt làm cost allocation tag trong Billing console thì mới xuất hiện trong Cost Explorer. Gắn thẻ mà không kích hoạt là thẻ tồn tại nhưng không dùng để phân bổ chi phí được.

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

  • B. Tạo tài khoản AWS RIÊNG cho từng dự án ML, tách chi phí ở mức tài khoản; tổng hợp THỦ CÔNG từ bảng kê hằng tháng — đây là phương án gần nhất và tách tài khoản là thực hành tốt cho cách ly, nhưng nó quá cứng nhắc cho việc phân bổ chi phí: một tài nguyên dùng chung giữa hai dự án không tách được, và "manually aggregate" trái yêu cầu báo cáo chi tiết tự động. (Trong thực tế nên dùng cả hai: tách tài khoản cho cách ly, tagging cho phân bổ chi tiết bên trong.)
  • A. Đặt AWS Budgets cho từng dự án và dựa vào cảnh báo khi vượt ngưỡng, điều chỉnh thủ công khi cần — Budgets là công cụ CẢNH BÁO, không phải công cụ PHÂN BỔ: nó cho biết đã vượt ngưỡng, nhưng không cho biết tiền đi vào đâu. Và nó vẫn cần tag để biết ngân sách của dự án nào.
  • D. Dùng CloudWatch giám sát metric sử dụng và TỰ TÍNH chi phí dựa trên metric, gán từng tài nguyên cho một dự án — tự dựng lại hệ thống tính tiền: CloudWatch đo mức sử dụng kỹ thuật (CPU, số lời gọi), không đo chi phí. Chuyển từ metric sang tiền đòi biết bảng giá của mọi dịch vụ, và sai số sẽ rất lớn.

Ghi nhớ

Bốn công cụ quản lý chi phí của AWS: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích, lọc theo tag, xem xu hướng, dự báo | | AWS Budgets | đặt ngưỡng và CẢNH BÁO | | Cost and Usage Report (CUR) | dữ liệu thô chi tiết nhất, đổ vào S3 để phân tích sâu | | Cost Anomaly Detection | tự phát hiện chi tiêu bất thường bằng ML |

Ba chiến lược phân bổ chi phí — nên kết hợp: | Chiến lược | Mức cách ly | Linh hoạt | |---|---|---| | Tagging | thấp | cao nhất — nhiều chiều cắt | | Tách tài khoản | cao nhất | thấp | | Kết hợp | cao | cao |

Mẫu phổ biến trong tổ chức lớn: tách tài khoản theo môi trường (dev/staging/prod) và tagging theo dự án và đội bên trong mỗi tài khoản.

Ba nguyên tắc để tagging thật sự hoạt động: | Nguyên tắc | Chi tiết | |---|---| | Chuẩn hoá tên thẻ từ đầu | Project khác project khác ProjectName | | Ép buộc bằng chính sách | Tag Policy hoặc SCP chặn tạo tài nguyên thiếu thẻ | | Kích hoạt cost allocation tag | bắt buộc, nếu không thẻ không hiện trong Cost Explorer |

Dòng giữa là điều làm nên khác biệt giữa "có tagging" và "tagging đáng tin": nếu chỉ dựa vào việc mọi người nhớ gắn thẻ, sau vài tháng sẽ có một phần đáng kể chi phí không phân bổ được.

Và ba loại chi phí ML thường bị bỏ sót khi phân bổ: | Chi phí | Ghi chú | |---|---| | S3 lưu dữ liệu huấn luyện | thường lớn hơn nhiều so với chi phí tính toán | | Endpoint nhàn rỗi | chạy 24/7 dù không ai gọi | | Notebook instance quên tắt | nguyên nhân phổ biến nhất của hoá đơn bất ngờ |

Cả ba đều gắn thẻ được — và chính chúng thường là nơi tiết kiệm lớn nhất khi bắt đầu phân tích.

Câu 103 ML Model Development

A healthcare organization has deployed a predictive ML model in production using Amazon SageMaker. To ensure the model's performance, the organization has enabled SageMaker Model Monitor to track data quality. After recent update to the model, a data scientist observes data quality issues flagged by Model Monitor checks.

What steps should the data scientist take to address the data quality issues identified by Model Monitor?

  1. A

    Modify the model's hyperparameters and redeploy the updated version to production
  2. B

    Generate a new baseline using the latest dataset and configure Model Monitor to use this updated baseline for future evaluations
  3. C

    Ingest Ground Truth labels and use these as an updated baseline for future evaluations
  4. D

    The constraint_violations.json file lists the violations detected in the current dataset. Manually correct the data issues and rerun the model
Xem giải thích

Đáp án

B — Sinh baseline mới từ tập dữ liệu mới nhất và cấu hình Model Monitor dùng baseline cập nhật đó cho các lần đánh giá về sau.

Vì sao đúng

Điểm mấu chốt nằm ở một chi tiết trong đề: vấn đề xuất hiện SAU KHI cập nhật model.

Model Monitor so sánh dữ liệu hiện tại với BASELINE, và baseline được tính từ dữ liệu huấn luyện của model cũ:

Model cũ  → baseline cũ (thống kê từ dữ liệu huấn luyện cũ)
    ↓ cập nhật model
Model mới → vẫn dùng BASELINE CŨ
    → dữ liệu mới lệch khỏi baseline cũ
    → Model Monitor báo vi phạm

Nên vi phạm ở đây không nhất thiết là vấn đề dữ liệu thật — nó có thể là baseline đã lỗi thời.

Cách xử lý đúng: sinh lại baseline từ dữ liệu huấn luyện của model MỚI:

my_monitor.suggest_baseline(
    baseline_dataset='s3://kho/du-lieu-huan-luyen-moi/',
    dataset_format=DatasetFormat.csv(header=True),
    output_s3_uri='s3://kho/baseline-moi/')

my_monitor.update_monitoring_schedule(
    statistics='s3://kho/baseline-moi/statistics.json',
    constraints='s3://kho/baseline-moi/constraints.json')

Nguyên tắc rút ra:

Baseline phải đi cùng model. Cập nhật model mà không cập nhật baseline là để hệ thống giám sát so sánh với một chuẩn không còn đúng.

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

  • D. Tệp constraint_violations.json liệt kê các vi phạm phát hiện được; sửa dữ liệu THỦ CÔNG và chạy lại model — đây là phương án gần nhất và nửa đầu hoàn toàn đúng: constraint_violations.json chính là nơi xem chi tiết vi phạm, và đó nên là bước điều tra đầu tiên. Nhưng "manually correct the data" là kết luận sai cho tình huống này: vấn đề là baseline lỗi thời, không phải dữ liệu hỏng. Sửa dữ liệu để khớp baseline cũ là làm ngược.
  • C. Nạp nhãn Ground Truth và dùng chúng làm baseline cập nhật — nhầm hai loại giám sát: Ground Truth label dùng cho model quality monitoring (đo độ chính xác), không dùng cho data quality monitoring (so phân bố đầu vào). Đề nói rõ vấn đề là data quality.
  • A. Sửa siêu tham số của model và triển khai lại phiên bản cập nhật — không liên quan: cảnh báo là về chất lượng dữ liệu, không về hiệu năng model. Đổi siêu tham số không ảnh hưởng gì tới việc dữ liệu có khớp baseline hay không.

Ghi nhớ

Ba tệp Model Monitor sinh ra — nên biết đọc: | Tệp | Nội dung | |---|---| | statistics.json | thống kê baseline: trung bình, phân vị, tỷ lệ null của từng cột | | constraints.json | ràng buộc suy ra: kiểu dữ liệu, độ đầy đủ, khoảng giá trị | | constraint_violations.json | vi phạm phát hiện được ở lần chạy hiện tại |

Luôn đọc tệp thứ ba trước khi kết luận nguyên nhân — nó cho biết cột nào, vi phạm gì, và mức độ ra sao.

Ba nguyên nhân của cảnh báo data quality, và cách phân biệt: | Nguyên nhân | Dấu hiệu | Cách chữa | |---|---|---| | Baseline lỗi thời | vi phạm xuất hiện ngay sau khi đổi model hoặc dữ liệu huấn luyện | sinh baseline mới ← câu này | | Lỗi pipeline dữ liệu | một cột đột nhiên đổi kiểu, đổi thang đo, hoặc toàn null | sửa pipeline | | Data drift thật | phân bố lệch DẦN theo thời gian | điều tra, cân nhắc huấn luyện lại |

Dấu hiệu thời gian là chìa khoá phân biệt: đột ngột sau một thay đổi → baseline hoặc pipeline; từ từ theo tuần → drift thật.

Bốn loại giám sát của Model Monitor và baseline tương ứng: | Loại | Baseline từ | Cần nhãn thật? | |---|---|---| | Data quality | dữ liệu huấn luyện (đầu vào) | ❌ | | Model quality | dự đoán + nhãn thật | ✅ | | Bias drift | dữ liệu + thuộc tính nhóm | ❌ | | Feature attribution | giá trị SHAP baseline | ❌ |

Và một thực hành nên đưa vào pipeline: sinh baseline như một BƯỚC trong pipeline huấn luyện, ngay sau bước huấn luyện. Cách này đảm bảo baseline luôn khớp với model — thay vì dựa vào việc ai đó nhớ chạy lại nó sau mỗi lần cập nhật.

Câu 104 ML Model Development

You are working as a data scientist at a company that specializes in predictive analytics. You are tasked with training a deep learning model using Amazon SageMaker to predict customer churn. The dataset you have is large and contains millions of records. The training process is taking longer than expected, and you suspect that the hyperparameters need fine-tuning. You want to balance the training time while ensuring the model converges effectively. You have set the batch size to 256, epochs to 50, and learning rate to 0.01. However, the training job is still not performing as expected.

Given this scenario, which of the following adjustments is MOST LIKELY to reduce the training time without compromising model performance?

  1. A

    Decrease the learning rate and increase the batch size
  2. B

    Increase the number of epochs and maintain the batch size
  3. C

    Increase the batch size and decrease the number of epochs
  4. D

    Decrease the batch size and increase the number of epochs
Xem giải thích

Đáp án

C — Tăng batch size và giảm số epoch.

Vì sao đúng

Đề nêu cấu hình hiện tại (batch 256, epoch 50, learning rate 0,01) và mục tiêu: giảm thời gian huấn luyện mà không hy sinh hiệu năng.

Hai điều chỉnh trong đáp án tác động vào hai chiều của thời gian huấn luyện:

Tổng thời gian ≈ (số epoch) × (số bước mỗi epoch) × (thời gian mỗi bước)
                                    ↑
                        = số mẫu / batch size
Điều chỉnh Tác động
Tăng batch size ít bước hơn mỗi epoch, tận dụng GPU tốt hơn
Giảm số epoch ít vòng qua dữ liệu hơn

Vì sao batch lớn hơn thật sự nhanh hơn — không chỉ là số học:

Batch nhỏ:  GPU xử lý ít dữ liệu mỗi lần
            → phần lớn thời gian là overhead (chuyển dữ liệu, đồng bộ)
            → GPU không được lấp đầy

Batch lớn:  GPU xử lý song song nhiều mẫu
            → tận dụng gần hết năng lực tính toán

Và vì sao giảm epoch không nhất thiết hy sinh chất lượng: với hàng triệu bản ghi, model thường hội tụ trước khi hết 50 epoch. Số epoch dư chỉ tốn thời gian và tăng nguy cơ overfitting.

Một điều chỉnh bắt buộc đi kèm mà đề không nêu: khi tăng batch size, phải tăng learning rate tương ứng (quy tắc tuyến tính: batch gấp đôi → learning rate gấp đôi, kèm warmup). Không làm vậy thì model học chậm hơn và cần nhiều epoch hơn — mất hết lợi ích.

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

  • **A. Giảm learning rate và tăng batch size — đây là phương án gần nhất và nửa sau đúng, nhưng giảm learning rate làm hội tụ CHẬM HƠN — cần nhiều epoch hơn, tăng tổng thời gian. Nó đi ngược đúng mục tiêu. (Và như đã nêu, khi tăng batch thì learning rate nên TĂNG chứ không giảm.)
  • **D. Giảm batch size và tăng số epoch — ngược hoàn toàn: batch nhỏ hơn nghĩa là nhiều bước hơn mỗi epoch, và nhiều epoch hơn nữa — thời gian tăng ở cả hai chiều.
  • B. Tăng số epoch và giữ nguyên batch size — chỉ làm tăng thời gian, không giảm. Và với 50 epoch đã có, thêm nữa thường dẫn tới overfitting.

Ghi nhớ

Ba siêu tham số ảnh hưởng thời gian huấn luyện: | Siêu tham số | Tăng lên thì | |---|---| | Batch size | ít bước hơn, GPU dùng hiệu quả hơn — NHANH HƠN | | Số epoch | nhiều vòng hơn — CHẬM HƠN | | Learning rate | hội tụ nhanh hơn (tới một ngưỡng), quá lớn thì dao động |

Quan hệ giữa batch size và learning rate — quy tắc quan trọng nhất:

Tăng batch size k lần thì tăng learning rate khoảng k lần, kèm warmup vài epoch đầu.

Lý do: batch lớn hơn cho gradient ít nhiễu hơn, nên có thể bước dài hơn một cách an toàn. Không tăng learning rate là lãng phí lợi thế đó.

Ba giới hạn của việc tăng batch size: | Giới hạn | Chi tiết | |---|---| | Bộ nhớ GPU | batch quá lớn gây lỗi hết bộ nhớ | | Chất lượng hội tụ | batch RẤT lớn (> vài nghìn) có thể làm model tổng quát hoá kém hơn | | Lợi ích giảm dần | qua một ngưỡng, GPU đã được lấp đầy |

Dòng giữa là hiện tượng đã được nghiên cứu nhiều: batch cực lớn có xu hướng hội tụ vào cực tiểu "sắc" (sharp minima), vốn tổng quát hoá kém hơn. Nên tăng batch có giới hạn, không phải càng lớn càng tốt.

Bốn cách khác giảm thời gian huấn luyện: | Cách | Chi tiết | |---|---| | Huấn luyện phân tán | nhiều GPU, data parallelism | | Mixed precision (FP16/BF16) | nhanh gấp 2–3 lần, gần như không mất độ chính xác | | Early stopping | dừng khi không còn cải thiện — bỏ epoch thừa | | Tối ưu đọc dữ liệu | FastFile, FSx for Lustre, gộp tệp nhỏ |

Dòng thứ hai thường bị bỏ qua nhưng cho lợi ích lớn nhất trên mỗi đơn vị công sức: bật mixed precision thường chỉ là một dòng cấu hình, và trên GPU hiện đại nó tăng tốc đáng kể nhờ Tensor Core.

Và early stopping đáng bật cùng với việc giảm epoch: thay vì đoán con số epoch đúng, để nó tự dừng khi validation loss ngừng cải thiện — vừa nhanh vừa an toàn hơn.

Câu 105 Deployment and Orchestration of ML Workflows

You are a machine learning engineer responsible for deploying a customer churn prediction model using Amazon SageMaker into production at a telecommunications company. The model is critical for proactive customer retention efforts, so maintaining high availability and reliability is essential. Given the model’s importance, you must implement best practices for deployment, including versioning and rollback strategies, to ensure that any issues with the new model version can be quickly addressed without impacting the business.

Which of the following approaches BEST exemplifies deployment best practices in this scenario?

  1. A

    Use a blue/green deployment strategy to deploy the new model version in parallel with the existing version, allowing you to switch traffic to the new model gradually and roll back if necessary
  2. B

    Deploy the new model version directly to production, replacing the existing model, and monitor its performance closely. If issues arise, retrain the model immediately and redeploy
  3. C

    Version the model by tagging the new version, deploy it to production, and use weighted traffic splitting to send a small percentage of traffic to the new model. If no issues are detected, gradually increase traffic to the new version
  4. D

    Deploy the new model version to a staging environment, test it thoroughly, and then manually replace the existing production model. If any issues occur, update the model in staging and redeploy
Xem giải thích

Đáp án

A — Dùng chiến lược blue/green deployment triển khai phiên bản model mới song song với phiên bản hiện có, cho phép chuyển lưu lượng dần dần và quay lại nếu cần.

Vì sao đúng

Đề nêu ba yêu cầu: | Yêu cầu | Cơ chế | |---|---| | Tính sẵn sàng và độ tin cậy cao | hai môi trường song song, không có khoảng gián đoạn | | Quản lý phiên bản | Model Registry với version | | Xử lý nhanh khi có vấn đề | rollback tức thì |

Blue/green giữ cả hai phiên bản sống cùng lúc:

Blue (hiện tại)  ──── 100% lưu lượng
Green (mới)      ──── 0%

    ↓ chuyển dần
Blue  ──── 90%          Green ──── 10%   (canary)
Blue  ──── 50%          Green ──── 50%
Blue  ──── 0%           Green ──── 100%

    ↓ có vấn đề bất kỳ lúc nào
Quay lại Blue TỨC THÌ — hạ tầng vẫn đang chạy

SageMaker hỗ trợ sẵn:

DeploymentConfig={
    'BlueGreenUpdatePolicy': {
        'TrafficRoutingConfiguration': {
            'Type': 'CANARY',
            'CanarySize': {'Type': 'CAPACITY_PERCENT', 'Value': 10}},
        'TerminationWaitInSeconds': 1800},      # giữ Blue thêm 30 phút
    'AutoRollbackConfiguration': {
        'Alarms': [{'AlarmName': 'canh-bao-do-tre'},
                   {'AlarmName': 'canh-bao-ty-le-loi'}]}}

Hai chi tiết làm nên giá trị thật: | Chi tiết | Vì sao quan trọng | |---|---| | TerminationWaitInSeconds | giữ Blue sống sau khi chuyển xong — rollback tức thì, không phải dựng lại | | AutoRollbackConfiguration | tự quay lại khi alarm kêu, không chờ ai bấm nút |

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

  • C. Gắn thẻ phiên bản mới, triển khai lên production và dùng weighted traffic splitting gửi một phần nhỏ lưu lượng sang model mới; tăng dần nếu không có vấn đề — đây là phương án gần nhất và rất giống blue/green về hành vi. Nó thua ở hai điểm: "tagging" không phải cơ chế quản lý phiên bản (Model Registry mới là), và nó thiếu vế rollback tự động. (Weighted traffic splitting qua production variant là cơ chế hợp lệ — nhưng nó thiên về so sánh hai model hơn là thay thế an toàn.)
  • D. Triển khai lên môi trường staging, kiểm thử kỹ, rồi thay thế THỦ CÔNG model production; nếu có vấn đề thì sửa ở staging và triển khai lại — kiểm thử ở staging là tốt nhưng không đủ: staging không có lưu lượng thật. Và "manually replace" nghĩa là 100% người dùng chuyển sang model mới cùng lúc, không có đường lui nhanh.
  • B. Triển khai thẳng model mới thay thế model hiện tại, giám sát chặt; nếu có vấn đề thì huấn luyện lại NGAY và triển khai lại — rủi ro cao nhất: không có nhóm đối chứng, không có rollback. Và "huấn luyện lại ngay" mất hàng giờ — trong lúc đó model lỗi vẫn phục vụ khách hàng.

Ghi nhớ

Ba chiến lược triển khai model — phân biệt cho rõ: | Chiến lược | Việc | |---|---| | Blue/green | THAY THẾ model cũ, có chuyển dần và rollback | | Canary | một dạng blue/green — phơi bày một phần nhỏ trước | | A/B test (production variant) | SO SÁNH hai model bằng chỉ số nghiệp vụ | | Shadow testing | gửi BẢN SAO lưu lượng sang model mới, không ảnh hưởng phản hồi |

Câu hỏi phân biệt:

"Tôi đang THAY THẾ model cũ?" → blue/green "Tôi đang SO SÁNH để quyết định?" → A/B test hoặc shadow testing

Ba chiến lược chuyển lưu lượng trong blue/green của SageMaker: | Kiểu | Hành vi | |---|---| | ALL_AT_ONCE | 100% ngay — chỉ cho dev | | CANARY | một phần nhỏ trước, chờ, rồi phần còn lại | | LINEAR | tăng đều theo bậc, có khoảng chờ |

Ba thứ cần có để rollback thật sự nhanh: | Thứ | Vì sao | |---|---| | Alarm gắn với chỉ số NGHIỆP VỤ | model ML hỏng thường KHÔNG gây lỗi 5XX | | TerminationWaitInSeconds đủ dài | giữ hạ tầng cũ để quay lại tức thì | | Phiên bản cũ vẫn Approved trong registry | không phải huấn luyện lại |

Dòng đầu quan trọng nhất và hay bị bỏ: với model dự đoán rời bỏ khách hàng, một model hỏng vẫn trả về kết quả bình thường về mặt kỹ thuật — chỉ là dự đoán sai. Nên alarm phải theo dõi phân bố đầu ra (tỷ lệ khách hàng bị gắn cờ "sẽ rời bỏ") chứ không chỉ độ trễ và mã lỗi.

Và một lựa chọn bổ sung đáng biết trước khi triển khai: shadow testing — gửi bản sao lưu lượng production sang model mới mà không dùng kết quả của nó. Bạn thu được dữ liệu hiệu năng trên lưu lượng thật với rủi ro bằng không, rồi mới quyết định có blue/green hay không.

Câu 106 Deployment and Orchestration of ML Workflows

You are responsible for deploying a machine learning model on AWS SageMaker for a real-time prediction application. The application requires low latency and high throughput. During deployment, you notice that the model’s response time is slower than expected, and the throughput is not meeting the required levels. You have already optimized the model itself, so the next step is to optimize the deployment environment. You are currently using a single instance of the ml.m5.large instance type with the default endpoint configuration.

Which of the following changes is MOST LIKELY to improve the model’s response time and throughput?

  1. A

    Enable Auto Scaling with a target metric for the instance utilization
  2. B

    Increase the instance count to two and enable asynchronous inference
  3. C

    Switch to an ml.m5.2xlarge instance type and use multi-AZ deployment
  4. D

    Change the instance type to ml.p2.xlarge and add multi-model support
Xem giải thích

Đáp án

A — Bật Auto Scaling với metric mục tiêu dựa trên mức sử dụng instance.

Vì sao đúng

Đề nêu tình trạng: một instance ml.m5.large duy nhất, model đã tối ưu xong, và cả thời gian phản hồi lẫn thông lượng đều không đạt.

Với một instance duy nhất chịu tải cao, phần lớn độ trễ đến từ XẾP HÀNG, không phải từ tính toán:

Một instance, tải cao:
  Request 1 → xử lý (50 ms)
  Request 2 → CHỜ 50 ms → xử lý (50 ms)   = 100 ms
  Request 3 → CHỜ 100 ms → xử lý (50 ms)  = 150 ms
  ...
  → độ trễ tăng theo độ dài hàng đợi

Thêm instance loại bỏ hàng đợi — nên nó cải thiện cả hai chỉ số cùng lúc: thông lượng tăng (nhiều instance xử lý song song) và độ trễ giảm (không phải chờ).

autoscaling.put_scaling_policy(
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'}})

Và auto scaling có lợi thế so với việc cố định thêm instance: nó co giãn theo tải thật, nên không trả tiền cho năng lực thừa lúc thấp điểm.

(Một sắc thái đáng nêu: nếu độ trễ cao kể cả khi tải thấp, nguyên nhân là instance quá nhỏ cho model — và khi đó phương án C mới đúng. Cách phân biệt: xem ModelLatency ở thời điểm ít request. Đề nói vấn đề là "throughput is not meeting the required levels", tức là liên quan tới tải — nên A phù hợp.)

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

  • C. Chuyển sang ml.m5.2xlarge và dùng multi-AZ deployment — đây là phương án gần nhất và có giúp, nhưng nó cấp thừa cố định: instance lớn hơn chạy 24/7 kể cả lúc thấp điểm. Và multi-AZ là về tính sẵn sàng, không phải về hiệu năng — nó không tăng thông lượng. (Nếu vấn đề là model quá lớn cho m5.large, đây sẽ là hướng đúng.)
  • **B. Tăng số instance lên hai và bật asynchronous inference — asynchronous đi ngược yêu cầu: đề nói cần low latency, real-time, còn async xếp hàng và trả kết quả qua S3 — độ trễ tính bằng giây. Tăng lên hai instance thì đúng hướng nhưng là con số cố định, không co giãn.
  • D. Đổi sang ml.p2.xlarge (GPU) và thêm multi-model support — hai lựa chọn không phù hợp: p2 là GPU thế hệ cũ và đắt hơn nhiều — chỉ đáng dùng nếu model thật sự cần GPU, mà đề không nói vậy. Và multi-model endpoint là để tiết kiệm khi có nhiều model, nó không cải thiện hiệu năng của một model.

Ghi nhớ

Chẩn đoán độ trễ của SageMaker endpoint: | Triệu chứng | Nguyên nhân | Cách chữa | |---|---|---| | Độ trễ TĂNG THEO TẢI | không đủ instance — xếp hàng | auto scaling ← câu này | | Độ trễ cao KỂ CẢ khi rảnh | instance quá nhỏ cho model | instance lớn hơn hoặc GPU | | OverheadLatency cao | payload lớn, vấn đề mạng | giảm kích thước payload | | Đỉnh tải dựng đứng | auto scaling phản ứng chậm | thêm scheduled scaling |

Hai metric của SageMaker cần phân biệt khi gỡ lỗi: | Metric | Đo | |---|---| | ModelLatency | thời gian MODEL xử lý — phản ánh kích thước instance | | OverheadLatency | thời gian SageMaker thêm vào — phản ánh payload và mạng |

Nếu ModelLatency ổn định thấp mà độ trễ đầu-cuối cao, vấn đề là xếp hàng — và đó là lúc auto scaling giải quyết được.

Ba metric dùng cho auto scaling: | Metric | Đặc điểm | |---|---| | SageMakerVariantInvocationsPerInstance | khuyến nghị — phản ánh trực tiếp lượng việc | | CPUUtilization | có thể thấp trong khi model chờ I/O | | Custom metric (độ trễ p99) | chính xác nhất, phải tự đẩy |

Bốn tham số cần đặt đúng: | Tham số | Ảnh hưởng | |---|---| | MinCapacity | ≥ 2 để chịu được mất một AZ | | MaxCapacity | trần chi phí | | TargetValue | quá cao thì chậm phản ứng | | Cooldown lên < xuống | mở rộng nhanh, thu hẹp chậm |

Và một điểm cần biết về giới hạn: auto scaling mất vài phút để instance mới sẵn sàng. Nếu lưu lượng có mẫu đã biết trước (giờ làm việc, sự kiện), scheduled scaling nâng MinCapacity từ trước sẽ hiệu quả hơn là để hệ thống phản ứng sau.

Câu 107 Chọn nhiều đáp án ML Solution Monitoring, Maintenance, and Security

You are a Data Scientist working for an e-commerce platform that uses a machine learning model to recommend products to customers. The model has been in production for over a year and was initially performing well. However, you have recently noticed a decrease in the model's accuracy, particularly when recommending products to new customers. This decline suggests that the model may be experiencing drift due to changing customer preferences and market trends. To address this issue, you need to implement a strategy for detecting and managing model drift using Amazon SageMaker.

Which of the following strategies should you implement to effectively detect and manage model drift in your product recommendation model using Amazon SageMaker? (Select two)

  1. A

    Retrain the model with the new training data, ensuring that the model remains up to date with new customer preferences
  2. B

    Use Amazon SageMaker Clarify to continuously monitor and mitigate bias in the model, and initiate model retraining due to changes in data distribution
  3. C

    Deploy multiple versions of the model simultaneously using Amazon SageMaker multi-model endpoints, and switch between them based on performance metrics
  4. D

    Manually review model performance every quarter and initiate retraining only if a significant drop in accuracy is observed, minimizing unnecessary retraining costs
  5. E

    Use Amazon SageMaker Model Monitor to set up monitoring for data quality and data drift, enabling you to receive alerts and initiate model retraining when the distribution of input data changes significantly from the training data
Xem giải thích

Đáp án

A và E.

  • E — Dùng SageMaker Model Monitor thiết lập giám sát chất lượng dữ liệu và data drift, nhận cảnh báo và kích hoạt huấn luyện lại khi phân bố dữ liệu đầu vào lệch đáng kể so với dữ liệu huấn luyện
  • A — Huấn luyện lại model với dữ liệu mới, đảm bảo model cập nhật theo sở thích khách hàng thay đổi

Vì sao đúng

Đề mô tả đúng vòng đời của vấn đề drift, và hai đáp án chia nhau hai nửa: | Nửa | Đáp án | |---|---| | PHÁT HIỆN drift | E — Model Monitor | | KHẮC PHỤC drift | A — huấn luyện lại |

Đề hỏi "detect and manage" — nên thiếu nửa nào cũng không đủ.

E — Model Monitor tự động hoá việc phát hiện:

DefaultModelMonitor(...).create_monitoring_schedule(
    endpoint_input=endpoint,
    statistics=baseline.baseline_statistics(),
    constraints=baseline.suggested_constraints(),
    schedule_cron_expression=CronExpressionGenerator.daily())

Nó so phân bố đặc trưng hiện tại với baseline và cảnh báo khi lệch — thay vì chờ ai đó nhận ra chất lượng đã giảm.

A — huấn luyện lại là cách khắc phục duy nhất thật sự. Khi sở thích khách hàng đã thay đổi, model học từ phân bố cũ không thể đúng — không có cách chỉnh tham số nào sửa được.

Và đề cho một manh mối cụ thể: chất lượng giảm đặc biệt với khách hàng MỚI. Đó là dấu hiệu phân bố người dùng đã dịch chuyển — nhóm khách hàng mới có hành vi khác nhóm mà model được huấn luyện trên.

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

  • B. Dùng SageMaker Clarify giám sát và giảm thiểu THIÊN LỆCH trong model, và kích hoạt huấn luyện lại do thay đổi phân bố dữ liệu — đây là phương án gần nhất và một phần đúng (Clarify có giám sát bias drift và feature attribution drift). Nhưng nó đo sai thứ: đề mô tả data drift và concept drift, không phải thiên lệch giữa các nhóm. Model Monitor là công cụ đúng cho drift phân bố.
  • D. Xem xét THỦ CÔNG hiệu năng mỗi quý và chỉ huấn luyện lại khi thấy giảm đáng kể, để giảm chi phí huấn luyện không cần thiết — quá chậm: một quý là ba tháng chạy với model đã lệch. Và "manual review" trái tinh thần tự động hoá.
  • C. Triển khai nhiều phiên bản model đồng thời bằng multi-model endpoint và chuyển đổi giữa chúng theo chỉ số hiệu năng — dùng sai tính năng: multi-model endpoint dành cho nhiều model KHÁC NHAU chia sẻ tài nguyên, không phải để chuyển đổi giữa các phiên bản. Và nó không phát hiện drift — bạn vẫn cần cơ chế biết khi nào nên chuyển.

Ghi nhớ

Vòng lặp quản lý drift đầy đủ:

① Baseline        → tính từ dữ liệu huấn luyện
② Giám sát liên tục → Model Monitor so phân bố
③ Cảnh báo        → EventBridge khi vượt ngưỡng
④ Điều tra        → drift ở đặc trưng nào, có ảnh hưởng chất lượng không
⑤ Huấn luyện lại  → với dữ liệu mới
⑥ Baseline MỚI    → cập nhật cùng model mới

Bước ⑥ hay bị quên — xem #6544 về hậu quả của việc giữ baseline cũ.

Bốn loại drift: | Loại | Cái gì đổi | |---|---| | Data drift | phân bố ĐẦU VÀO P(X) | | Concept drift | quan hệ P(Y|X) | | Label drift | phân bố nhãn P(Y) | | Upstream change | lỗi pipeline, đơn vị đo đổi |

Với hệ thống gợi ý, cả hai loại đầu đều xảy ra: người dùng mới có đặc điểm khác (data drift), và sở thích thay đổi theo mùa và xu hướng (concept drift).

Ba chiến lược huấn luyện lại: | Chiến lược | Đặc điểm | |---|---| | Theo lịch | đơn giản, có thể huấn luyện lại khi chưa cần | | Khi phát hiện drift | hiệu quả nhất — Model Monitor kích hoạt | | Học trực tuyến | cập nhật liên tục, phức tạp và rủi ro hơn |

Và một lưu ý riêng cho hệ thống gợi ý: khi huấn luyện lại, cẩn thận với catastrophic forgetting — huấn luyện chỉ trên dữ liệu mới khiến model quên mẫu của khách hàng lâu năm. Mẫu thực dụng là trộn dữ liệu cũ vào lô huấn luyện mới, hoặc huấn luyện lại toàn bộ định kỳ thay vì cập nhật gia tăng liên tục.

Hai điều kiện bắt buộc để Model Monitor hoạt động: | Điều kiện | Chi tiết | |---|---| | Data capture bật trên endpoint | không bật thì báo cáo trống | | Baseline đã tính | suggest_baseline() từ dữ liệu huấn luyện |

Câu 108 Deployment and Orchestration of ML Workflows

A healthcare company is automating the deployment of a machine learning solution to predict patient health risks. The ML engineer needs to use AWS CloudFormation to define a model that will be hosted on an Amazon SageMaker endpoint and serve real-time inference requests.

Which resource should the ML engineer create in the CloudFormation template to address this requirement?

  1. A

    Use AWS::SageMaker::Endpoint to define the SageMaker endpoint that will host the model and serve inference requests
  2. B

    Use AWS::EC2::Instance to host the ML model manually and handle inference requests
  3. C

    Use AWS::SageMaker::Model to specify the ML model, including the model artifacts and the inference container configuration for hosting
  4. D

    Use AWS::SageMaker::EndpointConfig to define the configuration for the SageMaker endpoint without specifying the model
Xem giải thích

Đáp án

C — Dùng AWS::SageMaker::Model để khai báo model ML, bao gồm artifact model và cấu hình container suy luận để hosting.

Vì sao đúng

Câu hỏi hỏi resource nào ĐỊNH NGHĨA MODEL — và trong CloudFormation, việc triển khai một SageMaker endpoint cần ba resource theo thứ tự phụ thuộc:

① AWS::SageMaker::Model
     → khai artifact trên S3 + container image trong ECR
        ↓
② AWS::SageMaker::EndpointConfig
     → khai loại instance, số lượng, variant
        ↓
③ AWS::SageMaker::Endpoint
     → tạo endpoint thật, phục vụ request

Câu hỏi hỏi về bước ①, và đó chính là nội dung của đáp án C — "specify the ML model, including the model artifacts and the inference container configuration":

Resources:
  ModelDuDoanRuiRo:
    Type: AWS::SageMaker::Model
    Properties:
      ExecutionRoleArn: !GetAtt SageMakerRole.Arn
      PrimaryContainer:
        Image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/du-doan:v1
        ModelDataUrl: s3://kho-model/du-doan-rui-ro/model.tar.gz

Hai thuộc tính bắt buộc trong PrimaryContainer: | Thuộc tính | Nội dung | |---|---| | Image | container image chứa mã suy luận (trong ECR) | | ModelDataUrl | artifact model đã huấn luyện (trên S3) |

Đây chính là "model artifacts and the inference container configuration" mà đáp án nêu.

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

  • A. Dùng AWS::SageMaker::Endpoint để định nghĩa endpoint host model và phục vụ request — đây là phương án gần nhất và cần thiết trong template, nhưng nó không định nghĩa model. Endpoint chỉ tham chiếu tới một EndpointConfig, và EndpointConfig tham chiếu tới Model. Câu hỏi hỏi resource nào khai model.
  • **D. Dùng AWS::SageMaker::EndpointConfig để định nghĩa cấu hình endpoint mà không khai model — tự mâu thuẫn: EndpointConfig bắt buộc phải tham chiếu ModelName trong ProductionVariants. Không có model thì không tạo được config.
  • B. Dùng AWS::EC2::Instance để host model thủ công và xử lý request suy luận — bỏ hoàn toàn SageMaker: bạn phải tự cài môi trường, tự viết máy chủ HTTP, tự lo auto scaling và giám sát. Trái mục đích của đề (triển khai lên SageMaker endpoint).

Ghi nhớ

Ba resource SageMaker trong CloudFormation — thứ tự và vai trò: | Resource | Khai gì | |---|---| | AWS::SageMaker::Model | artifact + container + execution role | | AWS::SageMaker::EndpointConfig | loại instance, số lượng, variant, data capture | | AWS::SageMaker::Endpoint | endpoint thật, tham chiếu tới config |

Template đầy đủ:

  CauHinhEndpoint:
    Type: AWS::SageMaker::EndpointConfig
    Properties:
      ProductionVariants:
        - ModelName: !GetAtt ModelDuDoanRuiRo.ModelName
          VariantName: AllTraffic
          InitialInstanceCount: 2
          InstanceType: ml.m5.xlarge
          InitialVariantWeight: 1
      DataCaptureConfig:                        # cần cho Model Monitor
        EnableCapture: true
        InitialSamplingPercentage: 100
        DestinationS3Uri: s3://kho/du-lieu-bat-duoc/

  Endpoint:
    Type: AWS::SageMaker::Endpoint
    Properties:
      EndpointConfigName: !GetAtt CauHinhEndpoint.EndpointConfigName

Một đặc điểm quan trọng cần biết về EndpointConfig:

EndpointConfig là BẤT BIẾN — không sửa được sau khi tạo.

Muốn đổi loại instance hoặc số lượng, bạn phải tạo config mới rồi cập nhật endpoint trỏ sang nó. CloudFormation xử lý việc này tự động, nhưng nó là lý do vì sao đổi cấu hình endpoint là một thao tác thay thế chứ không phải sửa tại chỗ.

Các resource SageMaker khác hay dùng trong CloudFormation: | Resource | Việc | |---|---| | AWS::SageMaker::NotebookInstance | notebook cho nhà khoa học dữ liệu | | AWS::SageMaker::ModelPackageGroup | model group trong Registry | | AWS::SageMaker::Pipeline | định nghĩa pipeline | | AWS::SageMaker::MonitoringSchedule | lịch giám sát |

Và một thực hành nên có: khai DataCaptureConfig ngay từ đầu như trong ví dụ trên. Nó là điều kiện bắt buộc cho Model Monitor, và bật sau nghĩa là phải tạo lại config và cập nhật endpoint — dễ bị hoãn rồi quên.

Câu 109 Deployment and Orchestration of ML Workflows

A media analytics company processes raw video metadata stored in Amazon S3 buckets to generate insights on audience engagement. The company needs to create data ingestion pipelines for processing this metadata and ML model deployment pipelines to analyze and predict audience behavior patterns. The solution must efficiently handle large-scale data processing and integrate seamlessly with ML workflows.

Which solution will meet these requirements?

  1. A

    Use SageMaker Studio Classic for both data ingestion pipelines and ML model deployment pipelines to simplify the process
  2. B

    Use AWS Glue to preprocess raw video metadata in Amazon S3 and create a custom script to deploy models manually using SageMaker endpoints
  3. C

    Use Kinesis Data Firehose to stream video metadata from Amazon S3 into the ingestion pipeline and deploy models using AWS Lambda
  4. D

    Use AWS Glue to create data ingestion pipelines for scalable data processing and SageMaker Studio Classic to manage ML model deployment pipelines
Xem giải thích

Đáp án

D — Dùng AWS Glue tạo pipeline nạp dữ liệu cho việc xử lý quy mô lớn, và SageMaker Studio Classic quản lý pipeline triển khai model ML.

Vì sao đúng

Đề nêu hai nhu cầu riêng biệt, và đáp án D dùng đúng công cụ cho từng cái: | Nhu cầu | Công cụ | |---|---| | Pipeline nạp và xử lý metadata video quy mô lớn | AWS Glue | | Pipeline triển khai model ML | SageMaker |

Glue cho phần dữ liệu: | Khả năng | Chi tiết | |---|---| | Serverless Spark | xử lý terabyte metadata mà không quản lý cụm | | Crawler | tự suy schema từ dữ liệu trên S3 | | Job bookmark | chỉ xử lý dữ liệu mới, không làm lại từ đầu | | Data Catalog | schema dùng chung cho Athena, SageMaker |

SageMaker cho phần ML: huấn luyện, đăng ký phiên bản, triển khai endpoint, giám sát — toàn bộ vòng đời model.

Và hai bên nối với nhau qua S3 và Data Catalog:

Metadata video thô trên S3
    ↓ Glue job: làm sạch, tổng hợp, tạo đặc trưng
Dữ liệu đã xử lý trên S3 (+ schema trong Data Catalog)
    ↓ SageMaker: huấn luyện, triển khai
Endpoint dự đoán hành vi khán giả

Đây là mẫu kiến trúc chuẩn: mỗi công cụ làm đúng phần nó giỏi, thay vì ép một công cụ làm cả hai.

(Ghi chú về cách diễn đạt: đề gọi là "SageMaker Studio Classic" — đây là giao diện thế hệ trước, và AWS hiện khuyến nghị SageMaker Studio mới cùng SageMaker Pipelines cho việc điều phối. Bản chất câu trả lời không đổi: dùng Glue cho dữ liệu, SageMaker cho ML.)

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

  • B. Dùng Glue tiền xử lý metadata trên S3 và viết script tuỳ chỉnh triển khai model THỦ CÔNG qua SageMaker endpoint — đây là phương án gần nhất và nửa đầu đúng, nhưng "custom script to deploy models manually" trái yêu cầu về pipeline triển khai. Đề nói cần "ML model deployment pipelines", không phải script tay.
  • A. Dùng SageMaker Studio Classic cho CẢ hai pipeline để đơn giản hoá — SageMaker không phải công cụ ETL quy mô lớn: SageMaker Processing chạy được job xử lý dữ liệu, nhưng nó không có crawler, không có Data Catalog, không có job bookmark — những thứ cần cho pipeline nạp dữ liệu liên tục.
  • C. Dùng Kinesis Data Firehose stream metadata TỪ S3 vào pipeline nạp, và triển khai model bằng Lambda — hiểu sai chiều của Firehose: nó ghi VÀO S3, không đọc TỪ S3. Và Lambda có giới hạn kích thước (250 MB / 10 GB) — thường không đủ cho model phân tích hành vi phức tạp.

Ghi nhớ

Phân vai giữa Glue và SageMaker: | | AWS Glue | SageMaker | |---|---|---| | Việc | ETL, catalog, chuẩn bị dữ liệu | huấn luyện, triển khai, giám sát model | | Quy mô dữ liệu | terabyte tới petabyte | vừa | | Serverless | ✅ | training job có, endpoint không | | Dùng khi | biến đổi dữ liệu quy mô lớn | vòng đời model |

Bốn thành phần của Glue hữu ích cho pipeline ML: | Thành phần | Việc | |---|---| | Crawler | suy schema, cập nhật Data Catalog | | Job (Spark hoặc Python shell) | biến đổi dữ liệu | | Job bookmark | chỉ xử lý dữ liệu mới — tránh làm lại và trùng lặp | | Workflow và Trigger | điều phối nhiều job |

Job bookmark đáng nhớ riêng: với metadata video đổ vào liên tục, nó là thứ khiến pipeline chỉ xử lý phần mới thay vì quét lại toàn bộ mỗi lần chạy.

Ba cách nối Glue với SageMaker Pipelines: | Cách | Đặc điểm | |---|---| | Qua S3 | đơn giản nhất — Glue ghi ra S3, SageMaker đọc vào | | CallbackStep | SageMaker Pipeline tạm dừng chờ Glue job xong | | EventBridge | Glue job xong phát sự kiện kích hoạt pipeline |

Cách thứ hai cho luồng liền mạch trong một pipeline duy nhất — xem thêm câu về CallbackStep trong lô trước.

Và một nguyên tắc kiến trúc rút ra:

Đừng ép một dịch vụ làm việc ngoài chuyên môn của nó. Glue cho dữ liệu quy mô lớn, SageMaker cho model — ghép chúng qua S3 rẻ hơn và bền hơn nhiều so với việc dùng một công cụ cho tất cả.

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

A retail company uses a recommendation model deployed on an Amazon SageMaker endpoint to provide product suggestions to customers in real time. The company has developed a new version of the recommendation model and wants to evaluate its performance using live customer data without affecting the current production model. The company needs to determine whether the new model provides better recommendations before replacing the production model.

What do you recommend?

  1. A

    Deploy the new model to a separate Amazon SageMaker endpoint and use a custom application to split live traffic between the endpoints for evaluation purposes
  2. B

    Use Amazon SageMaker multi-model endpoints to deploy both the current and new models simultaneously and manually analyze the logs for prediction comparisons
  3. C

    Use Amazon SageMaker shadow testing to route a copy of live customer data to the new model for evaluation while maintaining the production model’s operation. Compare predictions from both models to assess performance
  4. D

    Replace the current production model with the new model on the existing SageMaker endpoint, monitor its performance, and roll back if issues are detected
Xem giải thích

Đáp án

C — Dùng SageMaker shadow testing để định tuyến một BẢN SAO của dữ liệu khách hàng thực tới model mới để đánh giá, trong khi model production vẫn hoạt động bình thường; so sánh dự đoán của hai model để đánh giá hiệu năng.

Vì sao đúng

Đề nêu ba yêu cầu, và shadow testing là cơ chế được thiết kế chính xác cho chúng: | Yêu cầu | Shadow testing | |---|---| | Đánh giá bằng dữ liệu khách hàng THỰC | nhận bản sao của lưu lượng production thật | | KHÔNG ảnh hưởng model production | kết quả của shadow model bị VỨT BỎ, không trả về khách | | Quyết định trước khi thay thế | thu dữ liệu so sánh mà không có rủi ro |

Cách hoạt động:

Request từ khách hàng
    ├─→ Model PRODUCTION → phản hồi trả về KHÁCH HÀNG
    └─→ Model SHADOW     → phản hồi chỉ được GHI LẠI, không trả về
                             ↓
                     So sánh hai bộ dự đoán

Điểm khác biệt cốt lõi so với A/B test: | | Shadow testing | A/B test | |---|---|---| | Khách hàng nhận kết quả của model mới | ❌ KHÔNG BAO GIỜ | ✅ một phần | | Rủi ro | BẰNG KHÔNG | có | | Đo được chỉ số nghiệp vụ | ❌ (không ai thấy gợi ý mới) | ✅ | | Đo được | kỹ thuật: độ trễ, phân bố dự đoán, tỷ lệ lỗi | nghiệp vụ: CTR, doanh thu |

Đề nói rõ "without affecting the current production model" — nên shadow testing là lựa chọn đúng.

Cấu hình đơn giản:

sm.update_endpoint(
    EndpointName='goi-y-san-pham',
    ShadowProductionVariants=[{
        'VariantName': 'model-moi',
        'ModelName': 'model-goi-y-v2',
        'InitialInstanceCount': 1,
        'InstanceType': 'ml.m5.xlarge',
        'InitialVariantWeight': 1.0}])   # 100% lưu lượng được sao chép

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

  • A. Triển khai model mới lên endpoint RIÊNG và dùng ứng dụng tuỳ chỉnh chia lưu lượng giữa hai endpoint — đây là phương án gần nhất và tự dựng lại thứ SageMaker làm sẵn: bạn phải viết logic sao chép request, xử lý lỗi, và đảm bảo shadow không ảnh hưởng độ trễ của luồng chính. Và "split live traffic" nghĩa là một phần khách hàng thật sự nhận kết quả model mới — trái yêu cầu.
  • B. Dùng multi-model endpoint triển khai cả hai model đồng thời và phân tích log THỦ CÔNG để so sánh dự đoán — dùng sai tính năng: multi-model endpoint dành cho nhiều model KHÁC NHAU chia sẻ tài nguyên, nó không tự sao chép request sang model thứ hai. Bạn vẫn phải tự gọi cả hai.
  • D. Thay model production bằng model mới trên endpoint hiện có, giám sát và rollback nếu có vấn đề — phơi bày 100% khách hàng cho model chưa kiểm chứng. Trái thẳng yêu cầu "without affecting the current production model".

Ghi nhớ

Bốn kỹ thuật đánh giá model trên lưu lượng thật — theo mức rủi ro tăng dần: | Kỹ thuật | Khách hàng nhận kết quả model mới? | Rủi ro | |---|---|---| | Shadow testing | ❌ | không | | Canary (1–5%) | ✅ một phần rất nhỏ | thấp | | A/B test (10–50%) | ✅ một phần | vừa | | Blue/green chuyển hết | ✅ toàn bộ | cao (nhưng có rollback) |

Quy trình phát hành đầy đủ thường dùng cả bốn theo thứ tự:

① Shadow testing   → xác nhận model mới chạy ổn định, không lỗi, độ trễ chấp nhận được
② Canary 5%        → đo chỉ số nghiệp vụ trên nhóm nhỏ
③ A/B test 50%     → so sánh có ý nghĩa thống kê
④ Blue/green 100%  → chuyển hết, giữ đường lui

Shadow testing đo được gì và không đo được gì: | Đo được | Không đo được | |---|---| | Độ trễ và thông lượng thật | tỷ lệ nhấp, doanh thu | | Tỷ lệ lỗi, timeout | hành vi người dùng | | Phân bố dự đoán | | | Mức độ bất đồng giữa hai model | |

Dòng cuối bên trái là thứ giá trị nhất: tỷ lệ hai model cho kết quả khác nhau cho biết thay đổi lớn tới đâu — nếu chúng gần như luôn đồng ý, thay thế là an toàn; nếu bất đồng nhiều, cần điều tra kỹ trước khi phát hành.

Và một lưu ý về chi phí: shadow variant chạy trên instance riêng và tính tiền đầy đủ. Với đánh giá dài ngày, cân nhắc giảm InitialVariantWeight để chỉ sao chép một phần lưu lượng (ví dụ 20%) — vẫn đủ dữ liệu thống kê với chi phí thấp hơn.