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

Tìm thấy 635 câu.

Câu 21 Deployment and Orchestration of ML Workflows

A financial analytics company runs a data aggregation job every Saturday night to process transactional data from the past week. The job is scheduled to run for approximately 2 hours and can tolerate interruptions without impacting the results. The company plans to run this job consistently every weekend for the next 6 months.

Which EC2 instance purchasing option will meet these requirements MOST cost-effectively?

A
Use EC2 On-Demand Instances to run the job each weekend for 2 hours, paying only for the compute time consumed
B
Use EC2 Reserved Instances with a 6-month commitment to ensure lower costs and guaranteed availability
C
Use EC2 Dedicated Hosts to run the job for full control over the infrastructure and long-term cost efficiency
D
Use EC2 Spot Instances to run the aggregation job, as they provide substantial cost savings and can handle interruptions

Xem giải thích

Đáp án

D — Dùng EC2 Spot Instances chạy job gộp dữ liệu, vì chúng tiết kiệm chi phí đáng kể và chịu được gián đoạn.

Vì sao đúng

Đề cho ba thông tin, và cả ba đều chỉ về Spot: | Thông tin | Ý nghĩa | |---|---| | "can tolerate interruptions without impacting the results" | đủ điều kiện dùng Spot | | Chạy 2 giờ mỗi tuần | tổng cộng khoảng 52 giờ trong 6 tháng | | Chi phí thấp nhất | Spot giảm tới 90% |

Điều kiện đầu tiên là cửa vào bắt buộc của Spot, và đề nói ra rất rõ ràng — đây là dấu hiệu đề muốn bạn chọn Spot.

Phép tính cho thấy vì sao Reserved Instance sai:

Tổng thời gian chạy: 2 giờ × 4 tuần × 6 tháng ≈ 52 giờ

On-Demand:  52 giờ × giá cơ sở
Spot:       52 giờ × ~10–30% giá cơ sở        ← rẻ nhất
Reserved:   4.380 giờ (6 tháng liên tục) × ~60% giá cơ sở
            ← trả tiền cho 4.328 giờ KHÔNG DÙNG

Reserved Instance tính tiền theo thời gian cam kết, không theo thời gian sử dụng — nên với workload chạy 1,2% thời gian, nó là lựa chọn đắt nhất dù đơn giá thấp hơn.

Và tính chất gián đoạn không ảnh hưởng kết quả nghĩa là bạn không cần checkpoint phức tạp: nếu bị thu hồi, chỉ cần chạy lại — job 2 giờ chạy lại vẫn xong trước sáng thứ Hai.

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

B. Reserved Instance cam kết 6 tháng để có giá thấp hơn và đảm bảo khả dụng — đây là phương án dễ chọn nhầm vì đề nhắc "6 tháng", nhưng đó là bẫy: khoảng thời gian của dự án không giống với thời gian sử dụng. RI phù hợp với workload chạy liên tục, không phải với 2 giờ mỗi tuần.
A. On-Demand, chỉ trả cho thời gian tính toán đã dùng — đúng về mô hình tính tiền nhưng không rẻ nhất: nó bỏ qua việc job đã tự khai là chịu được gián đoạn, tức là bỏ qua khoản giảm giá lớn nhất có sẵn.
C. Dedicated Host để kiểm soát hoàn toàn hạ tầng và hiệu quả chi phí dài hạn — đắt nhất trong bốn: Dedicated Host tính tiền theo máy chủ vật lý, và chỉ đáng dùng khi có yêu cầu về giấy phép phần mềm tính theo socket hoặc ràng buộc tuân thủ về cách ly phần cứng. Không có yêu cầu nào như vậy trong đề.

Ghi nhớ

Bốn mô hình mua EC2 — và câu hỏi để chọn: | Mô hình | Giảm giá | Điều kiện | |---|---|---| | On-Demand | 0% | linh hoạt, không cam kết | | Spot | tới 90% | chịu được gián đoạn | | Savings Plans / Reserved | ~40–70% | chạy liên tục, cam kết 1–3 năm | | Dedicated Host | — | yêu cầu giấy phép hoặc tuân thủ về phần cứng |

Ba câu hỏi quyết định:

① Job có chịu được gián đoạn không?  → Có   → SPOT
② Có chạy liên tục hàng tháng không? → Có   → Savings Plans
③ Còn lại                                   → On-Demand

Bẫy hay gặp trong đề thi: "chạy trong 6 tháng" không có nghĩa là "chạy liên tục 6 tháng". Luôn tính tổng số giờ thực sự chạy trước khi so sánh.

Ba loại workload phù hợp với Spot: | Workload | Vì sao | |---|---| | Xử lý dữ liệu theo lô | chạy lại được ← câu này | | Huấn luyện ML | có checkpoint | | Render, mô phỏng | chia nhỏ được | | CI/CD build | ngắn, chạy lại rẻ |

Và ba cách giảm rủi ro khi dùng Spot: | Cách | Chi tiết | |---|---| | Đa dạng loại instance | khai nhiều loại — giảm xác suất không có capacity | | Spot Fleet với chiến lược capacity-optimized | chọn pool ít bị thu hồi nhất | | Xử lý thông báo thu hồi (2 phút) | lưu trạng thái trước khi bị dừng |

Với job đơn giản như trong đề, cách thứ nhất là đủ: khai ba bốn loại instance tương đương và để Spot Fleet chọn cái có sẵn.

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

A company’s data science team uses Amazon SageMaker notebook instances to develop machine learning models. The team frequently collaborates on projects that require access to shared datasets and specific Amazon S3 buckets. Currently, permissions for accessing S3 buckets are managed by creating individual IAM roles for each SageMaker notebook instance. This decentralized approach has led to inconsistent permissions, duplication of effort, and difficulty in managing access across team members. The company wants to centralize permissions management to ensure all SageMaker notebook instances used by the team can access the required S3 buckets consistently and efficiently.

Which solution will meet this requirement?

A
Attach the necessary permissions directly to each data scientist's IAM user to enable granular control over access to the notebook instances
B
Create an IAM group for the data science team, associate the required S3 access policies to the group, and attach the IAM group directly to the SageMaker notebook instances to grant permissions to all data scientists
C
Use inline policies directly on each notebook instance to define local permissions for the data scientists
D
Attach a single IAM role with S3 permissions to all SageMaker notebook instances used by the data science team

Xem giải thích

Đáp án

D — Gắn MỘT IAM role duy nhất có quyền S3 cho tất cả notebook instance mà đội khoa học dữ liệu dùng.

Vì sao đúng

Đề nêu ba vấn đề và một mục tiêu: | Vấn đề hiện tại | Nguyên nhân | |---|---| | Quyền không nhất quán | mỗi notebook một role riêng | | Trùng lặp công sức | phải cấu hình lại cho mỗi notebook | | Khó quản lý | không có nơi duy nhất để xem và sửa |

Cả ba đều bắt nguồn từ một nguyên nhân: quyền được định nghĩa ở N chỗ thay vì một chỗ.

Một role dùng chung sửa cả ba:

Trước:  notebook-1 → role-1 (quyền A, B)
        notebook-2 → role-2 (quyền A, C)      ← lệch
        notebook-3 → role-3 (quyền A)          ← thiếu

Sau:    notebook-1 ─┐
        notebook-2 ─┼→ role-doi-khoa-hoc-du-lieu (quyền A, B, C)
        notebook-3 ─┘

Sửa quyền một lần, mọi notebook được cập nhật ngay — không phải đi sửa từng cái.

Điểm kỹ thuật quan trọng cần nhớ: SageMaker notebook instance giả định (assume) một execution role, và role đó là thứ quyết định quyền. Notebook không chạy bằng danh tính IAM của người dùng đang mở nó.

Người dùng đăng nhập AWS → mở notebook instance
                          → notebook assume EXECUTION ROLE
                          → mọi lời gọi S3 dùng quyền của ROLE, không phải của người

Đó là lý do các phương án gắn quyền vào IAM user hoặc IAM group đều không hoạt động.

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

B. Tạo IAM group cho đội, gắn policy S3 vào group, rồi gắn group đó trực tiếp vào notebook instance — đây là phương án gần nhất và mắc một lỗi kỹ thuật cơ bản: không gắn IAM group vào tài nguyên AWS được. Group chỉ chứa IAM user; notebook instance cần một role. Câu này nghe hợp lý nhưng mô tả một thao tác không tồn tại.
A. Gắn quyền trực tiếp vào IAM user của từng nhà khoa học dữ liệu — sai chủ thể: quyền của người dùng quyết định họ có được tạo và mở notebook hay không, nhưng mã trong notebook chạy bằng execution role. Cấp quyền S3 cho user không làm notebook đọc được S3.
C. Dùng inline policy trực tiếp trên từng notebook instance để định nghĩa quyền cục bộ — chính là vấn đề hiện tại, chỉ đổi tên: inline policy gắn với từng role riêng lẻ nghĩa là vẫn N nơi định nghĩa, vẫn lệch nhau, vẫn khó quản lý. (Ngoài ra inline policy khó tái sử dụng và khó kiểm toán hơn managed policy.)

Ghi nhớ

Ba loại thực thể IAM và cái gì gắn được vào cái gì: | Thực thể | Gắn vào được | |---|---| | IAM user | người thật, có thông tin đăng nhập lâu dài | | IAM group | CHỈ chứa user — KHÔNG gắn vào tài nguyên AWS | | IAM role | dịch vụ, tài nguyên, hoặc danh tính liên kết assume |

Câu hỏi để chọn:

"Ai hoặc cái gì sẽ thực hiện hành động này?" Một dịch vụ AWS (notebook, Lambda, EC2) → role Một con người đăng nhập → user, và gom vào group để dễ quản

Hai loại role trong SageMaker: | Role | Việc | |---|---| | Execution role | notebook, training job, endpoint dùng để gọi các dịch vụ khác | | Service role | SageMaker dùng để quản lý tài nguyên thay bạn |

Ba nguyên tắc quản lý quyền cho đội ML: | Nguyên tắc | Chi tiết | |---|---| | Một role chung cho một vai trò công việc | không phải một role cho mỗi tài nguyên | | Dùng managed policy, không dùng inline | tái sử dụng được, dễ kiểm toán | | Tách môi trường bằng role riêng | dev và prod không dùng chung role |

Và một kỹ thuật đáng biết khi cần phân quyền chi tiết hơn trong cùng một đội: ABAC với tag. Gắn tag lên notebook instance và dùng condition key trong policy:

{"Condition": {"StringEquals":
  {"s3:ExistingObjectTag/duan": "${aws:PrincipalTag/duan}"}}}

Cách này cho một policy phục vụ nhiều dự án — mỗi notebook chỉ đọc được dữ liệu của dự án ghi trên tag của nó.

Câu 23 Deployment and Orchestration of ML Workflows

A healthcare company has developed multiple machine learning (ML) models for predicting patient outcomes. These models are stored in Amazon Elastic Container Registry (Amazon ECR) repositories across different AWS accounts where they were trained. The company needs to create a centralized catalog of these models to streamline version management, deployment tracking, and governance compliance. The catalog must provide cross-account access, allowing each AWS account to interact with the central repository securely. The solution should also enable the company to organize models logically and manage the lifecycle of different model versions efficiently.

Which solution will meet these requirements?

A
Use SageMaker Model Registry to create model groups for organizing models and managing versions. Configure cross-account access by attaching a resource-based policy to the SageMaker Model Registry that grants permissions to other AWS accounts
B
Set up an Amazon Redshift cluster to store metadata from ECR repositories across accounts and use SQL queries to track and catalog models centrally. Configure cross-account access to Redshift via federated roles
C
Create a central Amazon S3 bucket to store exported model artifacts from each account, enable cross-account access via bucket policies, and manually maintain a versioning structure for compliance
D
Use Amazon ECR to replicate model images across accounts and configure cross-account access using IAM roles. Track metadata and deployment status using custom tagging

Xem giải thích

Đáp án

A — Dùng SageMaker Model Registry tạo model group để tổ chức model và quản lý phiên bản; cấu hình truy cập chéo tài khoản bằng cách gắn resource-based policy vào Model Registry, cấp quyền cho các tài khoản AWS khác.

Vì sao đúng

Đề nêu bốn yêu cầu, và Model Registry đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Danh mục tập trung | một registry cho mọi model | | Quản lý phiên bản | model package version tự động tăng | | Theo dõi triển khai và tuân thủ | trạng thái phê duyệt + lineage | | Truy cập chéo tài khoản an toàn | resource-based policy | | Tổ chức logic và quản lý vòng đời | model group theo bài toán |

Model group là đơn vị tổ chức — mỗi group là một bài toán, mỗi version trong group là một lần cải tiến:

Model group: "du-doan-tai-nhap-vien"
  ├─ version 1  (Approved, đang chạy production)
  ├─ version 2  (Rejected — chỉ số kém hơn)
  └─ version 3  (PendingManualApproval)

Resource-based policy cho vế chéo tài khoản:

{
  "Effect": "Allow",
  "Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
  "Action": ["sagemaker:DescribeModelPackage",
             "sagemaker:ListModelPackages",
             "sagemaker:CreateModelPackage"],
  "Resource": "arn:aws:sagemaker:*:999988887777:model-package-group/du-doan-tai-nhap-vien/*"
}

Tài khoản huấn luyện đăng ký model vào registry trung tâm, tài khoản production đọc và triển khai từ đó — mà model artifact không phải sao chép đi đâu cả.

Và trạng thái phê duyệt phục vụ vế quản trị: chỉ model ở trạng thái Approved mới được pipeline triển khai — một cửa kiểm soát cho ngành y tế.

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

D. Dùng ECR sao chép image model qua các tài khoản và cấu hình truy cập chéo bằng IAM role; theo dõi metadata và trạng thái triển khai bằng tag tuỳ chỉnh — đây là phương án gần nhất và sai ở chỗ tự dựng lại registry bằng tag: tag không có khái niệm phiên bản có thứ tự, không có trạng thái phê duyệt, không có lineage. Và sao chép image qua các tài khoản tạo ra nhiều bản sao phải đồng bộ.
C. Bucket S3 trung tâm lưu artifact xuất từ mỗi tài khoản, bucket policy cho truy cập chéo, duy trì cấu trúc phiên bản THỦ CÔNG — "manually maintain a versioning structure" là chính thứ Model Registry loại bỏ. Và quy ước thư mục do người đặt sẽ lệch theo thời gian.
B. Cụm Redshift lưu metadata từ các ECR repository và dùng SQL truy vấn để theo dõi model — một kho dữ liệu phân tích không phải một registry: nó không quản lý vòng đời, không có phê duyệt, không tích hợp với pipeline triển khai. Và phải tự viết cơ chế đồng bộ metadata vào đó.

Ghi nhớ

SageMaker Model Registry cung cấp gì: | Khả năng | Chi tiết | |---|---| | Model group | nhóm các phiên bản của cùng một bài toán | | Model package version | tự tăng, bất biến | | Trạng thái phê duyệt | PendingManualApproval / Approved / Rejected | | Metadata | chỉ số đánh giá, thông tin container, lineage | | Resource-based policy | chia sẻ chéo tài khoản |

Mẫu kiến trúc nhiều tài khoản chuẩn cho ML:

Tài khoản Dev/Thử nghiệm ─┐
Tài khoản Huấn luyện     ─┼→ đăng ký vào → Model Registry (tài khoản CHUNG)
                          ┘                        ↓ đọc và triển khai
                                            Tài khoản Production

Ba lợi ích: artifact không nhân bản, một nơi duy nhất biết model nào đang chạy ở đâu, và cửa phê duyệt tách khỏi cả hai bên.

Ba trạng thái phê duyệt và cách dùng: | Trạng thái | Ý nghĩa | |---|---| | PendingManualApproval | pipeline đăng ký xong, chờ người xem báo cáo | | Approved | được phép triển khai — EventBridge có thể kích hoạt tự động | | Rejected | không đạt, giữ lại để tham chiếu |

Mẫu tự động hoá thường dùng: pipeline đăng ký ở trạng thái chờ, người duyệt sau khi xem chỉ số, và việc chuyển sang Approved phát ra sự kiện EventBridge kích hoạt triển khai. Giữ được tự động hoá mà vẫn có kiểm soát của con người.

Và một điểm về tuân thủ cho ngành y tế: nên ghi model card cùng mỗi version (xem #6395) — Model Registry liên kết được với model card, nên hồ sơ về mục đích sử dụng, giới hạn và chỉ số nằm ngay cạnh chính model đó.

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

A healthcare company is building a predictive model to identify high-risk patients for hospital readmission. The dataset includes patient records such as demographic information, past diagnoses, and admission history. The data is stored in Amazon S3 and a relational database hosted on an on-premises PostgreSQL server. The dataset has a class imbalance issue where very few patients are flagged as high-risk, which affects the performance of the model. Additionally, the dataset contains both categorical features (e.g., "diagnosis type") and numerical features (e.g., "days in hospital"). The ML engineer must preprocess the data to resolve the class imbalance and ensure the dataset is ready for training, using a solution that requires minimal operational effort.

Which solution will meet these requirements?

A
Use SageMaker Feature Store to automatically balance the class distribution in the dataset
B
Leverage AWS Glue DataBrew’s native features to clean and transform the dataset, including attempting to balance class distribution by duplicating records from the minority class
C
Use Amazon SageMaker Data Wrangler's 'balance data' operation to oversample the minority class to resolve the class imbalance
D
Use AWS Glue ETL jobs to write custom scripts for handling class imbalance by oversampling the minority class

Xem giải thích

Đáp án

C — Dùng thao tác "balance data" của SageMaker Data Wrangler để oversample lớp thiểu số, giải quyết mất cân bằng lớp.

Vì sao đúng

Đề nêu hai vấn đề và một ràng buộc: | Yếu tố | Chi tiết | |---|---| | Vấn đề | rất ít bệnh nhân được gắn cờ nguy cơ cao | | Dữ liệu | đặc trưng phân loại và số, từ S3 và PostgreSQL tại chỗ | | Ràng buộc | công sức vận hành tối thiểu |

Data Wrangler có thao tác "Balance Data" dựng sẵn với ba chiến lược: | Chiến lược | Cách làm | |---|---| | Random oversample | nhân bản ngẫu nhiên mẫu lớp thiểu số | | Random undersample | bỏ bớt mẫu lớp đa số | | SMOTE | sinh mẫu tổng hợp mới bằng nội suy |

SMOTE thường là lựa chọn tốt nhất vì nó tạo mẫu mới thay vì nhân bản — giảm nguy cơ overfitting vào đúng những bản ghi đã có:

Random oversample: bệnh nhân X xuất hiện 10 lần y hệt
                   → model học thuộc bệnh nhân X

SMOTE:             tạo bệnh nhân "giữa" X và láng giềng gần nhất
                   → model học vùng đặc trưng, không học điểm cụ thể

Và Data Wrangler xử lý được cả đặc trưng phân loại lẫn số — quan trọng vì SMOTE gốc chỉ làm việc với đặc trưng số; Data Wrangler lo phần mã hoá.

Ràng buộc "minimal operational effort" là điểm quyết định: đây là một thao tác chọn trong giao diện, không phải mã phải viết và bảo trì.

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

B. Dùng tính năng của AWS Glue DataBrew làm sạch và biến đổi, "cố gắng" cân bằng bằng cách nhân bản bản ghi lớp thiểu số — đây là phương án gần nhất và sai ở hai chỗ: DataBrew không có thao tác cân bằng lớp dựng sẵn (chính từ "attempting" trong phương án đã ngụ ý điều đó), và nhân bản đơn thuần kém hơn SMOTE vì gây overfitting.
D. Dùng Glue ETL viết script tuỳ chỉnh xử lý mất cân bằng bằng oversampling — tự viết thứ có sẵn: trái thẳng ràng buộc "minimal operational effort".
A. Dùng SageMaker Feature Store tự động cân bằng phân bố lớp — gán cho dịch vụ một chức năng nó không có: Feature Store lưu trữ và phục vụ đặc trưng, nó không biến đổi dữ liệu và không cân bằng gì cả.

Ghi nhớ

Ba cách xử lý mất cân bằng lớp — và nơi áp dụng: | Cách | Áp ở đâu | |---|---| | Lấy mẫu lại (oversample/SMOTE) | tầng DỮ LIỆU — Data Wrangler | | Trọng số lớp | tầng THUẬT TOÁN — scale_pos_weight của XGBoost | | Chọn metric đúng | tầng ĐÁNH GIÁ — F1, PR-AUC |

Ba cách này không loại trừ nhau — dùng kết hợp thường cho kết quả tốt nhất.

Quy tắc quan trọng nhất về lấy mẫu lại:

Chỉ cân bằng tập HUẤN LUYỆN. Giữ nguyên tập kiểm chứng và kiểm thử.

Cân bằng cả tập đánh giá cho ra điểm số đẹp không phản ánh thực tế production — nơi lớp thiểu số vẫn hiếm như cũ. Đây là lỗi phổ biến và hậu quả là model trông rất tốt cho tới khi triển khai.

Và một quy tắc đi kèm: chia tập trước, cân bằng sau. Nếu SMOTE chạy trước khi chia, mẫu tổng hợp sinh từ dữ liệu kiểm thử sẽ lọt vào tập huấn luyện — một dạng rò rỉ dữ liệu.

Bốn thao tác của Data Wrangler hữu ích cho bài toán y tế này: | Thao tác | Việc | |---|---| | Balance Data | oversample, undersample, SMOTE | | Handle Missing | điền hoặc bỏ giá trị thiếu | | Encode Categorical | one-hot, ordinal cho "loại chẩn đoán" | | Data Quality and Insights | phát hiện rò rỉ mục tiêu và mất cân bằng |

Thao tác cuối nên chạy trước tiên: nó cho biết mức mất cân bằng thực tế và cảnh báo nếu có đặc trưng rò rỉ thông tin về nhãn — với dữ liệu tái nhập viện, một cột như "ngày xuất viện lần sau" là rò rỉ điển hình.

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

You are an ML Engineer working for a healthcare company that uses a machine learning model to recommend personalized treatment plans to patients. The model is deployed on Amazon SageMaker and is critical to the company's operations, as any incorrect predictions could have significant consequences. A new version of the model has been developed, and you need to deploy it in production. However, you want to ensure that the deployment process is robust, allowing you to quickly roll back to the previous version if any issues arise. Additionally, you need to maintain version control for future updates and manage traffic between different model versions.

Which of the following strategies should you implement to ensure a smooth and reliable deployment of the new model version using Amazon SageMaker, considering best practices for versioning and rollback strategies? (Select two)

A
Use Amazon SageMaker’s built-in versioning to manage different versions of the model, and deploy the new version in a canary release by redirecting a small percentage of traffic to it initially
B
Create a backup of the current model, deploy the new version, and if any issues arise, manually roll back by redeploying the previous model version
C
Utilize Amazon SageMaker’s blue/green deployment strategy to shift traffic gradually from the old model to the new one, ensuring that you can monitor performance and quickly revert if needed
D
Deploy the new model version immediately and redirect 100% of traffic to it, assuming it has been thoroughly tested and will not require a rollback
E
Deploy the new model version alongside the current one, and use Amazon SageMaker’s multi-model endpoint to serve both models simultaneously, splitting traffic between them

Xem giải thích

Đáp án

A và C.

C — Dùng chiến lược blue/green của SageMaker chuyển lưu lượng dần dần từ model cũ sang model mới, theo dõi hiệu năng và quay lại nhanh khi cần
A — Dùng versioning dựng sẵn quản lý các phiên bản model, và triển khai bản mới theo kiểu canary — chuyển một phần nhỏ lưu lượng sang trước

Vì sao đúng

Đề nêu ba yêu cầu, và hai đáp án chia nhau: | Yêu cầu | Đáp án | |---|---| | Quay lại bản cũ NHANH khi có vấn đề | C — blue/green với rollback | | Quản lý phiên bản cho các lần cập nhật sau | A — Model Registry versioning | | Điều tiết lưu lượng giữa các phiên bản | A và C |

Bối cảnh quyết định: đây là model khuyến nghị phác đồ điều trị — dự đoán sai có hậu quả nghiêm trọng. Nên mọi lựa chọn đều phải nghiêng về giảm phạm vi ảnh hưởng nếu bản mới có vấn đề.

C — blue/green với auto rollback:

DeploymentConfig={
    'BlueGreenUpdatePolicy': {
        'TrafficRoutingConfiguration': {
            'Type': 'LINEAR',
            'LinearStepSize': {'Type': 'CAPACITY_PERCENT', 'Value': 20},
            'WaitIntervalInSeconds': 600},
        'TerminationWaitInSeconds': 1800},     # giữ bản cũ 30 phút sau khi xong
    'AutoRollbackConfiguration': {
        'Alarms': [{'AlarmName': 'canh-bao-do-lech-du-doan'}]}}

Hai chi tiết quan trọng: TerminationWaitInSeconds giữ hạ tầng cũ sống thêm một lúc (rollback tức thì, không phải dựng lại), và AutoRollbackConfiguration quay lại tự động khi alarm kêu — không chờ ai bấm nút.

A — canary cộng versioning bổ sung hai thứ: phạm vi ảnh hưởng ban đầu rất nhỏ (thường 5–10%), và lịch sử phiên bản để biết cần quay về đâu.

Hai đáp án cùng mô tả một triết lý: phơi bày dần, quan sát, và luôn có đường lui.

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

B. Sao lưu model hiện tại, triển khai bản mới, và nếu có vấn đề thì quay lại THỦ CÔNG bằng cách triển khai lại bản cũ — đây là phương án gần nhất và sai ở tốc độ và phạm vi: triển khai bản mới cho 100% lưu lượng ngay, và rollback thủ công mất nhiều phút tới hàng chục phút. Với hệ thống khuyến nghị điều trị, đó là quãng thời gian mọi bệnh nhân đều nhận khuyến nghị từ model chưa được kiểm chứng.
D. Triển khai bản mới và chuyển 100% lưu lượng ngay, giả định nó đã được kiểm thử kỹ và sẽ không cần rollback — giả định "sẽ không cần rollback" là điều không được phép có trong hệ thống có hậu quả cao. Kiểm thử kỹ tới đâu cũng không thay thế được việc quan sát trên lưu lượng thật.
E. Triển khai bản mới cạnh bản hiện tại và dùng multi-model endpoint phục vụ cả hai đồng thời, chia lưu lượng giữa chú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 (xem #6446), không phải để chia lưu lượng giữa hai phiên bản của cùng một model. Công cụ đúng cho việc đó là production variant.

Ghi nhớ

Ba cơ chế chia lưu lượng của SageMaker — nhớ đúng vai: | Cơ chế | Việc | |---|---| | Production variant | nhiều model trên MỘT endpoint, chia lưu lượng theo trọng số — A/B test | | Blue/green deployment | thay thế toàn bộ đội instance, có canary/linear và rollback | | Multi-model endpoint | nhiều model khác nhau chia sẻ instance để tiết kiệm |

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

"Tôi đang so sánh hai model?" → production variant "Tôi đang THAY THẾ model cũ bằng model mới?" → blue/green "Tôi có nhiều model khác nhau và muốn tiết kiệm?" → MME

Ba chiến lược chuyển lưu lượng trong blue/green: | Chiến lược | Cách làm | |---|---| | 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ờ giữa các bậc |

Với hệ thống y tế, canary thường phù hợp nhất: phơi bày ít nhất có thể ở giai đoạn rủi ro cao nhất.

Ba thứ cần có để rollback thật sự nhanh: | Thứ | Vì sao | |---|---| | Alarm gắn với chỉ số NGHIỆP VỤ | độ trễ tăng không phải dấu hiệu duy nhất — cần theo dõi phân bố dự đoán | | TerminationWaitInSeconds đủ dài | giữ hạ tầng cũ để quay lại tức thì | | Model version cũ vẫn ở trạng thái Approved | 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 ML, lỗi thường không gây 5XX. Endpoint chạy bình thường, chỉ là dự đoán sai đi. Nên alarm phải theo dõi phân bố đầu ra (tỷ lệ khuyến nghị mỗi loại phác đồ) chứ không chỉ theo dõi độ trễ và mã lỗi.

Câu 26 Deployment and Orchestration of ML Workflows

You are a machine learning engineer at a fintech company tasked with developing and deploying an end-to-end machine learning workflow for fraud detection. The workflow involves multiple steps, including data extraction, preprocessing, feature engineering, model training, hyperparameter tuning, and deployment. The company requires the solution to be scalable, support complex dependencies between tasks, and provide robust monitoring and versioning capabilities. Additionally, the workflow needs to integrate seamlessly with existing AWS services.

Which deployment orchestrator is the MOST SUITABLE for managing and automating your ML workflow?

A
Use AWS Step Functions to build a serverless workflow that integrates with SageMaker for model training and deployment, ensuring scalability and fault tolerance
B
Use Amazon SageMaker Pipelines to orchestrate the entire ML workflow, leveraging its built-in integration with SageMaker features like training, tuning, and deployment
C
Use AWS Lambda functions to manually trigger each step of the ML workflow, enabling flexible execution without needing a predefined orchestration tool
D
Use Apache Airflow to define and manage the workflow with custom DAGs (Directed Acyclic Graphs), integrating with AWS services through operators and hooks

Xem giải thích

Đáp án

B — Dùng Amazon SageMaker Pipelines điều phối toàn bộ quy trình ML, tận dụng tích hợp dựng sẵn với các tính năng của SageMaker như huấn luyện, tinh chỉnh và triển khai.

Vì sao đúng

Đề liệt kê sáu bước, và tất cả đều là bước ML — đó là dấu hiệu quyết định: | Bước | Step của SageMaker Pipelines | |---|---| | Trích xuất dữ liệu | ProcessingStep | | Tiền xử lý | ProcessingStep | | Feature engineering | ProcessingStep hoặc Feature Store | | Huấn luyện | TrainingStep | | Tinh chỉnh siêu tham số | TuningStep | | Triển khai | ModelStep |

Nguyên tắc chọn công cụ điều phối:

Mọi bước đều là ML → SageMaker Pipelines. Có nhiều dịch vụ ngoài ML → Step Functions.

Ba yêu cầu còn lại của đề cũng được đáp ứng: | Yêu cầu | Cơ chế | |---|---| | Hỗ trợ phụ thuộc phức tạp giữa các bước | DAG với depends_on và truyền property tự động | | Giám sát và quản lý phiên bản mạnh | execution history + Model Registry + lineage tự động | | Tích hợp liền mạch với dịch vụ AWS | native với SageMaker; gọi được Lambda và các bước khác |

TuningStep là ví dụ điển hình cho lợi thế của Pipelines: nó là một step dựng sẵn, và kết quả tốt nhất được truyền thẳng sang bước tiếp theo:

buoc_dang_ky = RegisterModel(
    name='DangKyModel',
    estimator=xgb,
    model_data=buoc_tinh_chinh.get_top_model_s3_uri(top_k=0, s3_bucket=bucket),
    approval_status='PendingManualApproval')

Với Step Functions, bạn phải tự viết Lambda gọi API, tự lấy kết quả, tự truyền đi.

Và lineage tracking tự động là thứ Pipelines cho miễn phí: mỗi lần chạy ghi lại dataset nào, tham số nào, sinh ra model nào — quan trọng cho hệ thống phát hiện gian lận chịu kiểm toán.

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

A. Step Functions dựng workflow serverless tích hợp với SageMaker cho huấn luyện và triển khai — đây là phương án gần nhất và hoàn toàn khả thi. Nó thua vì với một quy trình thuần ML, bạn phải tự viết nhiều mã kết nối và mất lineage tự động. Step Functions thắng khi workflow có nhiều dịch vụ ngoài ML (gọi API bên ngoài, chờ người duyệt, ghi vào nhiều hệ thống) — không phải trường hợp này.
D. Apache Airflow với DAG tuỳ chỉnh, tích hợp AWS qua operator và hook — hoạt động tốt nhưng thêm gánh nặng vận hành: bạn phải quản lý Airflow (hoặc trả tiền cho MWAA), quản lý DAG, và tự lo lineage. Đây là lựa chọn hợp lý nếu tổ chức đã có Airflow cho nhiều quy trình khác; dựng mới chỉ cho một pipeline ML thì không đáng.
C. Lambda kích hoạt THỦ CÔNG từng bước, cho phép chạy linh hoạt mà không cần công cụ điều phối định sẵn — không phải điều phối: không có DAG, không có xử lý lỗi, không có lịch sử. Và "kích hoạt thủ công" trái thẳng yêu cầu tự động hoá.

Ghi nhớ

So sánh hai công cụ điều phối chính: | | SageMaker Pipelines | Step Functions | |---|---|---| | Chuyên cho ML | ✅ step dựng sẵn | công cụ tổng quát | | Lineage tự động | ✅ | phải tự làm | | Tích hợp Model Registry | ✅ RegisterModel step | gọi API thủ công | | Ghép dịch vụ ngoài ML | hạn chế | ✅ 200+ dịch vụ | | Chờ người duyệt | qua trạng thái Model Registry | ✅ waitForTaskToken | | Chi phí | miễn phí (chỉ trả tài nguyên) | theo lần chuyển trạng thái |

Dòng cuối đáng biết: SageMaker Pipelines không tính phí điều phối — bạn chỉ trả tiền cho training job và processing job thật sự chạy.

Các step của SageMaker Pipelines: | Step | Việc | |---|---| | ProcessingStep | tiền xử lý, đánh giá | | TrainingStep | huấn luyện | | TuningStep | tinh chỉnh siêu tham số | | ConditionStep | rẽ nhánh — đề bạt có điều kiện | | RegisterModel | đăng ký vào registry | | TransformStep | batch transform | | LambdaStep | thoát ra gọi logic tuỳ ý | | CallbackStep | chờ hệ thống ngoài |

Hai step cuối quan trọng: chúng cho phép Pipelines ghép được cả những việc ngoài ML khi cần — nên ranh giới với Step Functions không tuyệt đối.

Và mẫu kết hợp thường dùng trong tổ chức lớn: Step Functions làm workflow nghiệp vụ tổng thể, và gọi SageMaker Pipeline như một bước trong đó. Mỗi công cụ làm đúng phần nó giỏi.

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

A fintech company is developing an AI-driven fraud detection system using Amazon SageMaker. The system must provide end-to-end ML capabilities, including data preprocessing, model training, versioned model storage, deployment, and monitoring. Customer transaction data is stored securely in Amazon S3.

The company requires the following:

Secure access to training data for different ML workflows to ensure data isolation.

A centralized model registry to manage model versions and deployments with minimal operational overhead.

What is the most appropriate approach to meet these requirements with the LEAST operational overhead?

A
Use Amazon S3 versioning to track model artifacts and manage deployments manually
B
Use unique tags for each model version and use SageMaker Model Registry to manage model deployments
C
Use Amazon Elastic Container Registry (Amazon ECR) to store model artifacts and versions
D
Use SageMaker Model Registry to manage model versions and associate models with model groups

Xem giải thích

Đáp án

D — Dùng SageMaker Model Registry quản lý phiên bản model và gắn model với model group.

Vì sao đúng

Đề nêu hai yêu cầu và một tiêu chí: | Yêu cầu | Cơ chế | |---|---| | Truy cập dữ liệu huấn luyện an toàn, cách ly giữa các luồng | IAM role riêng cho từng luồng | | Registry tập trung quản lý phiên bản và triển khai | Model Registry | | Ít công sức vận hành nhất | dịch vụ được quản lý, không tự dựng |

Model Registry được xây riêng cho yêu cầu thứ hai, và model group là đơn vị tổ chức tự nhiên:

Model group "phat-hien-gian-lan"
  ├─ version 1  → Approved, đang chạy production
  ├─ version 2  → Rejected (PR-AUC thấp hơn)
  └─ version 3  → PendingManualApproval

Mọi thứ cần cho quản trị đều có sẵn: | Khả năng | Chi tiết | |---|---| | Phiên bản tự động, bất biến | không đặt tên thủ công, không ghi đè | | Trạng thái phê duyệt | cửa kiểm soát trước khi triển khai | | Metadata chỉ số | so sánh các phiên bản | | Lineage | model này từ dữ liệu nào, job nào | | Tích hợp pipeline | RegisterModel step, EventBridge khi đổi trạng thái |

Và tiêu chí "LEAST operational overhead" là điểm quyết định: ba phương án còn lại đều yêu cầu tự dựng cơ chế quản lý phiên bản trên một dịch vụ không được thiết kế cho việc đó.

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

B. Dùng tag riêng cho từng phiên bản model và dùng Model Registry quản lý việc triển khai — đây là phương án gần nhất và thừa một nửa: Model Registry đã có phiên bản dựng sẵn, nên tự gắn tag phiên bản là làm lại việc đã có, và tệ hơn — hai hệ thống đánh số song song sẽ lệch nhau. (Tag hữu ích cho phân loại bổ sung như "môi trường" hay "chủ sở hữu", không phải cho phiên bản.)
A. Dùng S3 versioning theo dõi artifact model và quản lý triển khai THỦ CÔNG — S3 versioning theo dõi TỆP, không theo dõi MODEL: không có trạng thái phê duyệt, không có metadata chỉ số, không có lineage. Và "manually" trái thẳng tiêu chí.
C. Dùng Amazon ECR lưu artifact và phiên bản model — ECR quản lý IMAGE container, không quản lý model: nó lưu được image chứa mã suy luận, nhưng không biết gì về chỉ số đánh giá, phê duyệt, hay dữ liệu huấn luyện. Trong thực tế ECR là một phần của giải pháp (Model Registry trỏ tới image trong ECR), không phải toàn bộ.

Ghi nhớ

Bốn nơi lưu trữ và cái gì thuộc về đâu: | Nơi | Lưu gì | |---|---| | S3 | artifact model (trọng số), dữ liệu | | ECR | image container chứa mã suy luận | | Model Registry | METADATA: phiên bản, chỉ số, phê duyệt, trỏ tới S3 và ECR | | Feature Store | đặc trưng dùng chung |

Model Registry không lưu model — nó lưu thông tin về model và trỏ tới nơi thật sự chứa artifact. Đó là lý do nó nhẹ và không nhân bản dữ liệu.

Bốn thành phần của một model package: | Thành phần | Chi tiết | |---|---| | ModelDataUrl | trỏ tới artifact trên S3 | | Image | trỏ tới container trong ECR | | ModelMetrics | chỉ số đánh giá, báo cáo bias, giải thích | | ModelApprovalStatus | trạng thái phê duyệt |

Mẫu vận hành khuyến nghị:

Pipeline huấn luyện
    ↓ RegisterModel (PendingManualApproval)
Người xem báo cáo chỉ số
    ↓ đổi trạng thái sang Approved
EventBridge bắt sự kiện đổi trạng thái
    ↓ kích hoạt pipeline triển khai
Endpoint production

Mẫu này giữ tự động hoá đầu-cuối mà vẫn có một cửa kiểm soát của con người — phù hợp với hệ thống phát hiện gian lận nơi model sai có hậu quả tài chính.

Và về yêu cầu thứ nhất của đề (cách ly dữ liệu huấn luyện): cách làm là execution role riêng cho từng luồng ML, mỗi role chỉ đọc được prefix S3 của nó. Model Registry không giải quyết vế đó — nhưng nó cũng không cản trở, và bốn phương án đều không khác nhau ở điểm này.

Câu 28 Deployment and Orchestration of ML Workflows

A healthcare company is building an AI application to predict patient readmission rates using Amazon SageMaker. The application must support end-to-end machine learning workflows, including data preprocessing, model training, version management, and deployment. The training data, stored securely in Amazon S3, must be used in isolated and secure environments to comply with regulatory requirements. As part of model experimentation, the data science team is running multiple training jobs back-to-back to test different hyperparameter configurations.

To improve the team’s productivity, the company needs to reduce the startup time for each consecutive training job. What is the most efficient solution to achieve this goal?

A
Use SageMaker Training Compiler to minimize data transfer latency
B
Enable SageMaker Warm Pools to reuse training instances between jobs
C
Use Amazon EC2 On-Demand Instances with pre-configured AMIs for SageMaker
D
Use Amazon SageMaker Managed Spot Training for faster resource allocation

Xem giải thích

Đáp án

B — Bật SageMaker Warm Pools để tái sử dụng instance huấn luyện giữa các job.

Vì sao đúng

Đề nêu bài toán rất cụ thể: đội chạy nhiều job huấn luyện liên tiếp nhau để thử các cấu hình siêu tham số khác nhau, và muốn giảm thời gian khởi động cho mỗi job kế tiếp.

Thời gian khởi động của một training job gồm bốn phần:

① Cấp phát instance        ~2–4 phút
② Tải container image      ~1–3 phút
③ Tải dữ liệu từ S3        tuỳ kích thước
④ Huấn luyện thật          ← phần duy nhất tạo ra giá trị

Với job huấn luyện chỉ vài phút, ba bước đầu có thể chiếm phần lớn thời gian — và chúng lặp lại ở mỗi lần thử.

Warm pool giữ hạ tầng sống sau khi job kết thúc:

estimator = Estimator(..., keep_alive_period_in_seconds=1800)   # giữ 30 phút

Job tiếp theo với cùng cấu hình (loại instance, image, VPC) dùng lại instance đang ấm — bỏ qua cả bước ① lẫn ②:

Không warm pool:  [khởi động 5 phút][huấn luyện 8 phút] × 10 lần = 130 phút
Có warm pool:     [khởi động 5 phút][huấn luyện 8 phút]
                  + [huấn luyện 8 phút] × 9              =  85 phút

Và điều này khớp đúng với mô tả "running multiple training jobs back-to-back" — warm pool chỉ có ích khi các job chạy gần nhau về thời gian, đúng như trong đề.

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

A. Dùng SageMaker Training Compiler để giảm độ trễ truyền dữ liệu — mô tả sai chức năng: Training Compiler tối ưu mã model để huấn luyện nhanh hơn trên GPU (thường 10–50% với model deep learning), nó không liên quan gì tới truyền dữ liệu hay thời gian khởi động. Nó rút ngắn bước ④, không rút ngắn ①②③.
D. Dùng Managed Spot Training để cấp phát tài nguyên nhanh hơn — hiểu ngược: Spot tiết kiệm chi phí, và nó thường làm thời gian chờ LÂU HƠN vì phải đợi capacity khả dụng. max_wait tồn tại chính vì lý do đó.
C. Dùng EC2 On-Demand với AMI cấu hình sẵn cho SageMaker — từ bỏ dịch vụ được quản lý: bạn phải tự dựng cụm, tự quản lý AMI, tự lo phân phối dữ liệu. Và nó không phải là cách SageMaker training job hoạt động.

Ghi nhớ

Ba cách rút ngắn thời gian của một chu trình thử nghiệm ML: | Cách | Rút ngắn phần nào | |---|---| | Warm pool | thời gian KHỞI ĐỘNG giữa các job ← câu này | | Training Compiler | thời gian HUẤN LUYỆN trên GPU | | Local mode | bỏ hẳn khởi động — chạy trên máy dev để gỡ lỗi | | Fast File Mode / FSx | thời gian TẢI DỮ LIỆU |

Bốn cách đều nhắm vào những phần khác nhau — biết đúng nút thắt mới chọn được đúng công cụ.

Điều kiện để warm pool tái sử dụng được instance: | Điều kiện | Chi tiết | |---|---| | Cùng loại và số lượng instance | đổi từ ml.p3.2xlarge sang ml.p3.8xlarge là không dùng lại được | | Cùng container image | | | Cùng cấu hình VPC và subnet | | | Trong khoảng keep_alive_period_in_seconds | tối đa 3600 giây |

Và lưu ý về chi phí: warm pool tính tiền cho thời gian giữ instance sống, kể cả khi không chạy job. Nên đặt keep_alive_period vừa đủ cho nhịp làm việc thực tế — giữ 60 phút cho một đội chỉ chạy job mỗi 2 giờ là lãng phí.

Ba cách tải dữ liệu của SageMaker, ảnh hưởng tới bước ③: | Chế độ | Đặc điểm | |---|---| | File mode | tải toàn bộ xuống trước khi bắt đầu — chậm với dữ liệu lớn | | Fast File mode | stream từ S3, bắt đầu huấn luyện ngay | | Pipe mode | stream tuần tự | | FSx for Lustre | nhanh nhất khi đọc lặp cùng dữ liệu qua nhiều job |

Dòng cuối đáng cân nhắc kèm warm pool cho tình huống trong đề: nhiều job liên tiếp trên cùng một tập dữ liệu thì FSx loại bỏ luôn bước tải lặp lại — kết hợp cả hai cho chu trình thử nghiệm nhanh nhất.

Câu 29 ML Model Development

You are a data scientist working on a deep learning model to classify medical images for disease detection. The model initially shows high accuracy on the training data but performs poorly on the validation set, indicating signs of overfitting. The dataset is limited in size, and the model is complex, with many parameters. To improve generalization and reduce overfitting, you need to implement appropriate techniques while balancing model complexity and performance.

Given these challenges, which combination of techniques is the MOST LIKELY to help prevent overfitting and improve the model’s performance on unseen data?

A
Combine data augmentation to increase the diversity of the training data with early stopping to prevent overfitting, and use ensembling to average predictions from multiple models
B
Use ensembling by combining multiple versions of the same model trained with different random seeds, and apply data augmentation to artificially increase the size of the dataset
C
Prune the model by removing less important layers and nodes, and use L2 regularization to reduce the magnitude of the model’s weights, preventing overfitting
D
Apply early stopping to halt training when the validation loss stops improving, and use dropout as a regularization technique to prevent the model from becoming too reliant on specific neurons

Xem giải thích

Đáp án

A — Kết hợp data augmentation để tăng độ đa dạng của dữ liệu huấn luyện với early stopping để chặn overfitting, và dùng ensembling lấy trung bình dự đoán của nhiều model.

Vì sao đúng

Đề nêu ba điều kiện, và chúng cùng chỉ về một chẩn đoán: | Điều kiện | Ý nghĩa | |---|---| | Chính xác cao lúc train, kém lúc validation | overfitting rõ ràng | | Tập dữ liệu nhỏ | thiếu dữ liệu là nguyên nhân gốc | | Model phức tạp, nhiều tham số | năng lực model vượt lượng dữ liệu |

Ba kỹ thuật trong đáp án A tấn công cả ba nguyên nhân: | Kỹ thuật | Xử lý | |---|---| | Data augmentation | nguyên nhân GỐC — tập dữ liệu nhỏ | | Early stopping | triệu chứng — dừng trước khi model học thuộc | | Ensembling | giảm phương sai — tăng tổng quát hoá |

Data augmentation là mảnh quan trọng nhất vì nó xử lý nguyên nhân chứ không phải triệu chứng. Với ảnh y tế, các phép biến đổi phải chọn theo biến thể có thật:

Hợp lệ:      xoay nhẹ, lật ngang, đổi độ sáng/tương phản,
             thu phóng nhẹ, thêm nhiễu
Cẩn thận:    lật DỌC (nhiều ảnh y tế có hướng cố định),
             biến dạng mạnh (làm sai lệch dấu hiệu bệnh lý)

Ensembling giảm phương sai — mỗi model overfit theo một hướng khác nhau, và trung bình của chúng ổn định hơn từng cái:

Model 1 sai ở ca A
Model 2 sai ở ca B      → trung bình đúng ở cả A và B
Model 3 sai ở ca C

Ba kỹ thuật này bổ sung nhau ở ba tầng khác nhau: dữ liệu, quá trình huấn luyện, và dự đoán.

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

D. Early stopping dừng khi validation loss ngừng cải thiện, và dropout như một kỹ thuật chính quy hoá — đây là phương án gần nhất và cả hai kỹ thuật đều đúng và hữu ích. Nhưng nó không xử lý nguyên nhân gốc: tập dữ liệu vẫn nhỏ. Early stopping và dropout hạn chế mức độ overfitting, còn augmentation giảm nhu cầu overfitting bằng cách cho model nhiều dữ liệu hơn. Với "dataset is limited in size" được nêu rõ, bỏ qua augmentation là bỏ qua công cụ mạnh nhất.
B. Ensembling nhiều bản của CÙNG model với seed ngẫu nhiên khác nhau, cộng data augmentation — có hai kỹ thuật đúng, nhưng thiếu early stopping và ensembling cùng một kiến trúc cho lợi ích hạn chế: các model quá giống nhau nên sai theo cùng một cách. Ensembling hiệu quả nhất khi các thành viên đa dạng (kiến trúc khác, dữ liệu con khác).
C. Cắt tỉa model bỏ tầng và node ít quan trọng, cộng L2 regularization giảm độ lớn trọng số — cả hai đều là kỹ thuật chống overfitting hợp lệ, nhưng cắt tỉa chủ yếu để nén model cho triển khai, không phải để cải thiện tổng quát hoá. Và như D, nó không giải quyết vế dữ liệu nhỏ.

Ghi nhớ

Các kỹ thuật chống overfitting, phân theo tầng: | Tầng | Kỹ thuật | |---|---| | Dữ liệu | augmentation, thu thập thêm dữ liệu, 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 |

Nguyên tắc ưu tiên:

Xử lý nguyên nhân gốc trước. Với tập dữ liệu nhỏ, nguyên nhân gốc là thiếu dữ liệu.

Ba cách tăng dữ liệu hiệu quả khi không thể thu thập thêm: | Cách | Chi tiết | |---|---| | Data augmentation | biến đổi ảnh có sẵn | | Transfer learning | dùng model đã huấn luyện trên tập lớn, fine-tune trên tập nhỏ của bạn | | Dữ liệu tổng hợp | rủi ro — có thể khuếch đại thiên lệch |

Dòng giữa đặc biệt mạnh cho ảnh y tế và đáng nhắc dù không nằm trong phương án: một model đã học đặc trưng thị giác tổng quát từ hàng triệu ảnh cần rất ít dữ liệu chuyên ngành để thích nghi. Đây thường là bước đầu tiên nên thử với tập dữ liệu y tế nhỏ.

Ba loại ensembling: | Loại | Cách làm | |---|---| | Bagging | huấn luyện trên các tập con khác nhau, lấy trung bình | | Boosting | model sau sửa lỗi của model trước | | Stacking | model meta học cách kết hợp các model cơ sở |

Và một kỹ thuật rẻ đáng biết: test-time augmentation — áp augmentation lúc suy luận, dự đoán nhiều lần trên các biến thể của cùng một ảnh rồi lấy trung bình. Nó cho phần lớn lợi ích của ensembling mà chỉ cần một model.

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

You are a Machine Learning Engineer working for a large retail company that has developed multiple machine learning models to improve various aspects of their business, including personalized recommendations, generative AI, and fraud detection. The models have different deployment requirements:

The recommendations models need to handle real-time inference with low latency.
The generative AI model requires high scalability to manage fluctuating loads.
The fraud detection model is a large model and needs to be integrated into serverless applications to minimize infrastructure management.

Which of the following deployment targets should you choose for the different machine learning models, given their specific requirements? (Select two)

A
Deploy the generative AI model using Amazon Elastic Kubernetes Service (Amazon EKS) to leverage containerized microservices for high scalability and control over the deployment environment
B
Deploy the real-time recommendation model using Amazon SageMaker endpoints to ensure low-latency, high-availability, and managed infrastructure for real-time inference
C
Choose Amazon Elastic Container Service (Amazon ECS) for the recommendation model, as it provides container orchestration for large-scale, batch processing workloads with tight integration into other AWS services
D
Use AWS Lambda to deploy the fraud detection model, which requires rapid scaling and integration into an existing serverless architecture, minimizing infrastructure management
E
Deploy all models using Amazon SageMaker endpoints for consistency and ease of management, regardless of their individual requirements for scalability, latency, or integration

Xem giải thích

Đáp án

A và B.

B — Triển khai model gợi ý thời gian thực bằng SageMaker endpoint để có độ trễ thấp, tính sẵn sàng cao và hạ tầng được quản lý
A — Triển khai model GenAI bằng Amazon EKS để tận dụng microservice đóng gói container cho khả năng mở rộng cao và kiểm soát môi trường triển khai

Vì sao đúng

Đề đưa ra ba model với ba yêu cầu khác nhau, và câu hỏi chỉ chọn hai: | Model | Yêu cầu | Đáp án | |---|---|---| | Gợi ý | suy luận thời gian thực, độ trễ thấp | B | | GenAI | khả năng mở rộng cao, tải biến động | A | | Phát hiện gian lận | model LỚN, tích hợp vào ứng dụng serverless | (bẫy ở D) |

B — SageMaker endpoint cho gợi ý thời gian thực là lựa chọn hiển nhiên: model đã nạp sẵn, độ trễ mili giây, auto-scaling và tính sẵn sàng cao đều có sẵn.

A — EKS cho GenAI cần giải thích thêm vì nó không phải lựa chọn mặc định. Nó hợp lý khi: | Lý do | Chi tiết | |---|---| | Tải biến động mạnh | HPA và Cluster Autoscaler cho kiểm soát co giãn chi tiết | | Cần môi trường runtime tuỳ chỉnh | thư viện suy luận riêng như vLLM, TensorRT-LLM | | Đã có nền tảng Kubernetes | tận dụng công cụ và quy trình sẵn có |

Model GenAI thường cần cấu hình phục vụ đặc thù (continuous batching, tensor parallelism, quản lý bộ nhớ KV cache) — và container tự dựng cho kiểm soát mà endpoint được quản lý không phơi ra hết.

Và D là bẫy quan trọng nhất của câu này. Nó nghe rất hợp lý: "tích hợp vào kiến trúc serverless, giảm quản lý hạ tầng" — đúng thứ đề nói về model phát hiện gian lận. Nhưng đề cũng nói "is a LARGE model", và đó là chỗ Lambda gãy: | Giới hạn Lambda | Giá trị | |---|---| | Gói ZIP giải nén | 250 MB | | Container image | 10 GB | | Bộ nhớ | 10 GB | | GPU | không có |

Một model lớn thường vượt ít nhất một trong bốn giới hạn này, và cold start khi nạp model lớn làm hỏng yêu cầu về độ trễ.

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

D. Dùng AWS Lambda triển khai model phát hiện gian lận, vốn cần co giãn nhanh và tích hợp vào kiến trúc serverless sẵn có — như phân tích trên: mô tả yêu cầu thì đúng, nhưng Lambda không đáp ứng được vì model LỚN. Đây là phương án được thiết kế để hấp dẫn, và cụm "large model" trong đề là manh mối để loại nó. (Với model nhỏ, D sẽ là lựa chọn tốt.)
C. Chọn Amazon ECS cho model gợi ý vì nó điều phối container cho workload xử lý theo LÔ quy mô lớn — mô tả sai kịch bản: model gợi ý cần suy luận thời gian thực, không phải xử lý theo lô. Và ECS thêm gánh nặng quản lý so với SageMaker endpoint cho cùng một việc.
E. Triển khai TẤT CẢ model bằng SageMaker endpoint cho nhất quán và dễ quản lý, bất kể yêu cầu riêng của từng model — "regardless of their individual requirements" là điểm loại: đề mô tả ba yêu cầu khác nhau một cách có chủ đích, và bỏ qua chúng là bỏ qua chính bài toán.

Ghi nhớ

Bốn nền tảng triển khai model — và điều kiện chọn: | Nền tảng | Hợp với | Giới hạn | |---|---|---| | SageMaker endpoint | hầu hết model ML, thời gian thực | ít kiểm soát runtime | | EKS/ECS | cần môi trường tuỳ chỉnh, đã có nền tảng container | quản lý cụm | | Lambda | model NHỎ, tải thưa, kiến trúc serverless | 250 MB / 10 GB, không GPU | | Batch transform | không cần endpoint | không thời gian thực |

Bảng giới hạn của Lambda cần thuộc — nó là bẫy thường gặp: | Giới hạn | Giá trị | |---|---| | Gói ZIP (giải nén) | 250 MB | | Container image | 10 GB | | Bộ nhớ | 128 MB – 10 GB | | Thời gian chạy | 15 phút | | /tmp | 512 MB – 10 GB | | GPU | không có |

Ba dấu hiệu trong đề cho biết Lambda không phù hợp: | Dấu hiệu | Lý do | |---|---| | "large model" | vượt giới hạn kích thước | | "cần GPU" | Lambda không có | | "chạy quá 15 phút" | vượt timeout |

Và nguyên tắc chung rút ra từ câu này:

Đọc kỹ ràng buộc kỹ thuật, đừng chỉ đọc mô tả nhu cầu.

Phương án D mô tả nhu cầu chính xác tới từng chữ, nhưng công cụ nó đề xuất không thoả một ràng buộc kỹ thuật đã nêu ở đề bài. Đây là kiểu bẫy phổ biến trong đề thi AWS.

Trang 3 / 64 — tổng 635 câu hỏi