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

Đáp án

B — Dùng AWS Trainium cho việc huấn luyện deep learning hiệu năng cao và tiết kiệm chi phí; dùng AWS Inferentia cho ứng dụng suy luận deep learning và GenAI.

Vì sao đúng

Đây là câu hỏi kiểm tra việc nhớ đúng vai của hai chip do AWS thiết kế: | Chip | Việc | Instance | |---|---|---| | AWS Trainium | HUẤN LUYỆN (Training) | trn1, trn2 | | AWS Inferentia | SUY LUẬN (Inference) | inf1, inf2 |

Mẹo nhớ nằm ngay trong tên:

Train + ium    → TRAINING (huấn luyện)
Infer + entia  → INFERENCE (suy luận)

Vì sao AWS thiết kế hai chip riêng thay vì một: huấn luyện và suy luận có đặc tính tính toán khác nhau: | | Huấn luyện | Suy luận | |---|---|---| | Phép tính | forward + backward pass | chỉ forward | | Bộ nhớ | cần lưu activation cho backward | ít hơn nhiều | | Độ chính xác số | thường cần cao hơn | chấp nhận INT8, BF16 | | Tối ưu cho | thông lượng | độ trễ và chi phí mỗi dự đoán |

Chip chuyên dụng cho từng việc đạt hiệu năng trên mỗi đơn vị chi phí tốt hơn so với GPU đa năng.

Ba lợi ích của chip AWS so với GPU: | Lợi ích | Chi tiết | |---|---| | Chi phí thấp hơn | thường rẻ hơn đáng kể cho cùng khối lượng công việc | | Hiệu quả năng lượng | quan trọng với mục tiêu bền vững | | Sẵn có | ít bị khan hiếm hơn GPU cao cấp |

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

• D. Dùng Inferentia cho huấn luyện và Trainium cho suy luận — đây là phương án gần nhất và đảo ngược hoàn toàn hai vai trò. Đây là bẫy chính của câu hỏi.
• A. Dùng HOẶC Trainium HOẶC Inferentia cho suy luận — sai vì Trainium không tối ưu cho suy luận: dùng được về mặt kỹ thuật nhưng lãng phí năng lực huấn luyện mà suy luận không cần.
• C. Dùng HOẶC Trainium HOẶC Inferentia cho huấn luyện — cùng lỗi theo chiều ngược: Inferentia không hỗ trợ backward pass hiệu quả, nên không phù hợp cho huấn luyện.

Ghi nhớ

Các loại instance ML của AWS — bảng nên thuộc: | Họ | Chip | Dùng cho | |---|---|---| | trn1, trn2 | AWS Trainium | HUẤN LUYỆN | | inf1, inf2 | AWS Inferentia | SUY LUẬN | | p3, p4d, p5 | NVIDIA V100, A100, H100 | huấn luyện quy mô lớn | | g4dn, g5 | NVIDIA T4, A10G | suy luận GPU, huấn luyện nhỏ | | c5, m5, r5 | CPU | model nhẹ, tiền xử lý |

Điều kiện dùng chip AWS: | Điều kiện | Chi tiết | |---|---| | Biên dịch qua AWS Neuron SDK | thêm một bước trong pipeline | | Framework được hỗ trợ | PyTorch, TensorFlow, JAX | | Kiểm tra model biên dịch được | không phải mọi kiến trúc đều hỗ trợ |

Neuron SDK là chi phí thật cần tính: mỗi lần đổi model phải biên dịch lại, và một số toán tử tuỳ chỉnh có thể không được hỗ trợ.

Ba trường hợp nên chọn chip AWS thay GPU: | Trường hợp | Lý do | |---|---| | Model phổ biến (transformer, CNN chuẩn) | Neuron hỗ trợ tốt | | Khối lượng lớn và ổn định | tiết kiệm chi phí tích luỹ lớn | | Có mục tiêu bền vững | hiệu quả năng lượng cao hơn |

Và ba trường hợp nên giữ GPU: | Trường hợp | Lý do | |---|---| | Kiến trúc model rất mới hoặc tuỳ chỉnh sâu | Neuron có thể chưa hỗ trợ | | Cần thư viện CUDA đặc thù | | | Khối lượng nhỏ, thử nghiệm | không đáng công biên dịch |

Và một liên hệ với câu #6599 trong cùng lô: mẫu kiến trúc tối ưu thường là huấn luyện trên GPU mạnh hoặc Trainium, suy luận trên Inferentia — mỗi giai đoạn dùng phần cứng phù hợp với đặc tính của nó.

Đáp án

A — Thiết lập VPC endpoint cho Amazon S3 ở tài khoản chính để giao tiếp riêng tư; cấu hình bucket policy chéo tài khoản ở tài khoản phụ để cấp quyền cho Redshift ML truy cập bucket một cách an toàn.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi phần của đáp án lo một cái: | Yêu cầu | Cơ chế | |---|---| | Redshift ML ở tài khoản chính truy cập S3 ở tài khoản phụ | bucket policy chéo tài khoản | | KHÔNG dùng địa chỉ IPv4 công cộng | VPC endpoint cho S3 |

VPC endpoint giữ lưu lượng trong mạng AWS:

Không có VPC endpoint:
  Redshift → NAT gateway → INTERNET → endpoint công khai của S3
  → dùng IP công cộng ❌

Có Gateway VPC endpoint cho S3:
  Redshift → route table trỏ tới endpoint → S3
  → KHÔNG rời khỏi mạng AWS ✅

Và bucket policy ở tài khoản PHỤ là chỗ cấp quyền — theo nguyên tắc IAM cơ bản:

Resource-based policy luôn gắn ở tài khoản SỞ HỮU tài nguyên.

// Ở TÀI KHOẢN PHỤ (sở hữu bucket)
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/RedshiftMLRole"},
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::du-lieu-huan-luyen",
               "arn:aws:s3:::du-lieu-huan-luyen/*"]
}

Và Gateway endpoint cho S3 là lựa chọn kinh tế: nó miễn phí (khác với Interface endpoint tính phí theo giờ và GB).

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

• C. Triển khai kết nối VPN giữa hai VPC ở tài khoản chính và phụ để truyền dữ liệu an toàn — đây là phương án gần nhất về mặt "giữ riêng tư", nhưng S3 không nằm trong VPC: nó là dịch vụ khu vực có endpoint riêng. Nối hai VPC không giúp truy cập S3 riêng tư — vẫn cần VPC endpoint. (Và VPN giữa hai VPC cùng Region là lựa chọn kém so với VPC peering hoặc Transit Gateway.)
• B. Xuất dữ liệu sang bucket mới ở tài khoản chính bằng Glue, rồi Redshift ML đọc từ bucket đó — nhân bản dữ liệu: tốn chi phí lưu trữ gấp đôi, cần đồng bộ liên tục, và không giải quyết vế IP công cộng (Glue vẫn phải đọc qua đâu đó).
• D. Dùng S3 Transfer Acceleration tối ưu truyền dữ liệu giữa các tài khoản — sai mục đích và đi ngược yêu cầu: Transfer Acceleration tăng tốc truyền qua Internet công cộng bằng edge location — tức là chắc chắn dùng IP công cộng, đúng thứ đề cấm.

Ghi nhớ

Hai loại VPC endpoint — nhớ đúng loại nào cho dịch vụ nào: | Loại | Cơ chế | Dịch vụ | Chi phí | |---|---|---|---| | Gateway endpoint | route table entry | CHỈ S3 và DynamoDB | MIỄN PHÍ | | Interface endpoint | ENI trong subnet (PrivateLink) | hầu hết dịch vụ khác | theo giờ + GB |

S3 có cả hai lựa chọn: Gateway endpoint miễn phí nhưng chỉ dùng được trong VPC; Interface endpoint tính phí nhưng truy cập được từ on-premises qua Direct Connect.

Nguyên tắc vàng của truy cập chéo tài khoản:

Resource-based policy ở tài khoản SỞ HỮU; identity-based policy ở tài khoản GỌI.

Cả hai đều cần:

Tài khoản PHỤ:   bucket policy cho phép role của tài khoản chính
Tài khoản CHÍNH: IAM policy cho role được gọi S3

Thiếu một trong hai là bị từ chối.

Ba cấu hình bổ sung nên có cho môi trường nhạy cảm: | Cấu hình | Việc | |---|---| | Endpoint policy | giới hạn bucket nào truy cập được qua endpoint này | | aws:SourceVpce condition | chỉ cho phép truy cập QUA endpoint, chặn đường khác | | Bật VPC Flow Logs | xác nhận không có lưu lượng ra Internet |

Dòng giữa đáng dùng cho bucket chứa dữ liệu nhạy cảm:

{"Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}},
 "Effect": "Deny", "Action": "s3:*", ...}

Nó đảm bảo kể cả khi thông tin xác thực bị lộ, dữ liệu chỉ truy cập được từ trong VPC của bạn.

Và ba cách xác nhận không có lưu lượng ra Internet: | Cách | Chi tiết | |---|---| | Bỏ NAT gateway khỏi subnet | nếu vẫn chạy được, chắc chắn không ra Internet | | VPC Flow Logs | xác nhận không có luồng tới IP ngoài | | Kiểm tra route table | không có route 0.0.0.0/0 tới IGW |

Đáp án

A — Dùng AWS SDK for Python (Boto3) truy vấn DynamoDB trực tiếp từ SageMaker notebook.

Vì sao đúng

Đây là cách trực tiếp và ít bước nhất để đọc dữ liệu DynamoDB từ notebook:

import boto3
dynamodb = boto3.resource('dynamodb')
bang = dynamodb.Table('du-lieu-khach-hang')

phan_hoi = bang.query(
    KeyConditionExpression=Key('ma_khach_hang').eq('KH001'))

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có bước trung gian | không sao chép, không đồng bộ | | Dữ liệu luôn mới nhất | đọc trực tiếp từ nguồn | | Ít công cấu hình | chỉ cần quyền IAM trên execution role |

Quyền cần có trên execution role của notebook:

{"Effect": "Allow",
 "Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
 "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/du-lieu-khach-hang"}

Ghi chú quan trọng về giới hạn thực tế

Cần nói rõ một điều mà đề không nêu: đáp án A đúng cho truy cập theo khoá — Query hoặc GetItem trên một số bản ghi cụ thể. Nhưng đề nói "a significant amount of data" cho phân tích và phát triển model, và ở quy mô đó, cách này có ba vấn đề thật:

Trong thực tế, mẫu chuẩn cho phân tích ML trên dữ liệu DynamoDB là xuất sang S3:

DynamoDB → Export to S3 (tính năng dựng sẵn, không tốn read capacity)
         → Athena hoặc Glue → phân tích
         → SageMaker huấn luyện

ExportTableToPointInTimeS3 là tính năng dựng sẵn của DynamoDB làm việc này mà không tiêu thụ read capacity — quan trọng vì nó không ảnh hưởng ứng dụng production.

Nên phương án D (Glue chuyển sang S3) là hướng đúng cho phân tích quy mô lớn, dù nó tốn nhiều bước hơn. Trong phạm vi câu hỏi — nhấn mạnh "efficiently accessible" và "minimizing potential delays" — A là đáp án ít bước nhất, nhưng đừng áp dụng nó cho việc quét hàng triệu bản ghi.

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

• D. Dùng AWS Glue chuyển bảng từ DynamoDB sang S3, rồi notebook đọc từ S3 — như phân tích trên, đây là mẫu đúng cho phân tích quy mô lớn, nhưng nó thêm một bước và có độ trễ đồng bộ — kém trực tiếp hơn A theo tiêu chí đề nêu.
• C. Xuất bảng ra tệp .csv THỦ CÔNG và tải lên S3, rồi notebook đọc từ S3 — "manually" là điểm loại: không tự động, không lặp lại được, và với dữ liệu lớn thì không khả thi.
• B. Dùng Data Wrangler nhập trực tiếp từ DynamoDB — Data Wrangler KHÔNG có connector DynamoDB. Các nguồn nó hỗ trợ là S3, Athena, Redshift, Snowflake, Databricks và JDBC — không có DynamoDB.

Ghi nhớ

Các nguồn dữ liệu của SageMaker Data Wrangler: | Hỗ trợ | Không hỗ trợ trực tiếp | |---|---| | S3, Athena, Redshift | DynamoDB | | Snowflake, Databricks | Kinesis | | JDBC (SQL Server, MySQL, PostgreSQL) | |

Ba cách đưa dữ liệu DynamoDB vào ML workflow: | Cách | Đặc điểm | |---|---| | Boto3 trực tiếp | ít bước nhất — hợp truy cập theo khoá, dữ liệu nhỏ | | DynamoDB Export to S3 | không tốn read capacity — tốt nhất cho phân tích quy mô lớn | | Glue với DynamoDB connector | có biến đổi dữ liệu kèm theo |

Cách thứ hai đáng biết nhất và hay bị bỏ qua:

aws dynamodb export-table-to-point-in-time   --table-arn arn:aws:dynamodb:...:table/du-lieu-khach-hang   --s3-bucket kho-phan-tich   --export-format DYNAMODB_JSON

Nó dùng point-in-time recovery để xuất, nên hoàn toàn không đụng tới read capacity của bảng — ứng dụng production không bị ảnh hưởng.

Ba thao tác đọc của DynamoDB — biết chọn đúng: | Thao tác | Đặc điểm | |---|---| | GetItem | một bản ghi theo khoá — nhanh nhất | | Query | nhiều bản ghi cùng partition key — hiệu quả | | Scan | ĐỌC TOÀN BỘ bảng — chậm và tốn kém |

Tránh Scan trên bảng lớn là nguyên tắc cơ bản khi làm việc với DynamoDB — và đó là lý do việc phân tích ML nên đi qua bản xuất trên S3.

Và một lưu ý nếu buộc phải quét từ notebook: dùng ConsistentRead=False (mặc định) và cân nhắc parallel scan với Segment và TotalSegments để chia việc — nhưng vẫn nên đặt giới hạn tốc độ để không làm nghẽn ứng dụng.

Đáp án

C — Feature selection (chọn lọc đặc trưng).

Vì sao đúng

Đề mô tả chính xác định nghĩa: chọn một TẬP CON các đặc trưng liên quan nhất từ hàng trăm đặc trưng có sẵn, nhằm giảm tỷ lệ lỗi và giảm độ phức tạp của model.

Từ khoá quyết định là "select a subset" — tức là giữ lại một phần trong những gì đã có, không tạo mới và không biến đổi.

Ba nhóm phương pháp chọn lọc đặc trưng: | Nhóm | Cách làm | Ví dụ | |---|---|---| | Filter | chấm điểm từng đặc trưng độc lập với model | tương quan, chi-square, mutual information | | Wrapper | thử các tập con, đánh giá bằng chính model | forward selection, backward elimination, RFE | | Embedded | chọn lọc xảy ra TRONG lúc huấn luyện | L1 (Lasso), feature importance của cây |

Nhóm thứ ba thường thực dụng nhất:

# L1 regularization tự đưa hệ số về 0
LogisticRegression(penalty='l1', solver='liblinear', C=0.1)

# Hoặc dùng feature importance của XGBoost
importance = model.get_score(importance_type='gain')

Ba lợi ích của việc giảm số đặc trưng: | Lợi ích | Chi tiết | |---|---| | Giảm overfitting | ít chiều hơn với cùng lượng dữ liệu | | Huấn luyện và suy luận nhanh hơn | ít phép tính hơn | | Dễ diễn giải hơn | ít đặc trưng để giải thích |

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

• **B. Feature extraction (trích xuất đặc trưng) — đây là phương án gần nhất và cũng giảm số chiều, nhưng nó TẠO RA đặc trưng MỚI bằng cách kết hợp các đặc trưng cũ, thay vì chọn một tập con:

  Feature selection:  giữ [tuoi, thu_nhap] từ 100 cột      ← cột GỐC
  Feature extraction: tạo PC1 = 0,3·tuoi + 0,7·thu_nhap... ← cột MỚI
  

  PCA là ví dụ điển hình — và nhược điểm của nó là mất khả năng diễn giải: "PC1" không có ý nghĩa nghiệp vụ nào.
• **A. Feature creation (tạo đặc trưng) — tạo đặc trưng MỚI từ dữ liệu thô (tỷ số, tổng hợp theo thời gian). Nó làm tăng số đặc trưng, ngược với mục tiêu.
• **D. Feature transformation (biến đổi đặc trưng) — đổi CÁCH BIỂU DIỄN của đặc trưng (chuẩn hoá, log transform, one-hot). Số lượng không giảm.

Ghi nhớ

Bốn nhóm kỹ thuật feature engineering — phân biệt bằng tác động tới số cột: | Nhóm | Số cột | Cột có ý nghĩa gốc? | |---|---|---| | Creation | tăng | ✅ | | Transformation | giữ nguyên | ✅ | | Selection | giảm | ✅ giữ cột GỐC | | Extraction | giảm | ❌ cột mới tổng hợp |

Phân biệt selection và extraction là câu hỏi hay gặp, và tiêu chí là cột kết quả có phải cột gốc không.

Cách chọn giữa hai: | Tình huống | Chọn | |---|---| | Cần diễn giải được | selection — giữ tên cột gốc | | Chỉ cần hiệu năng, không cần giải thích | extraction (PCA) | | Nhiều đặc trưng tương quan cao | extraction xử lý tốt hơn | | Yêu cầu quy định về giải thích | selection bắt buộc |

Ba phương pháp selection, theo chi phí tính toán: | Phương pháp | Chi phí | Chất lượng | |---|---|---| | Filter (tương quan, chi-square) | rẻ nhất | thô — bỏ qua tương tác giữa các đặc trưng | | Embedded (L1, tree importance) | vừa | tốt — thường là lựa chọn thực dụng | | Wrapper (RFE, forward/backward) | đắt nhất | tốt nhất nhưng chậm |

Nhóm embedded thường là điểm cân bằng đúng: nó xét được tương tác giữa các đặc trưng (khác filter) mà không phải huấn luyện hàng trăm lần (khác wrapper).

Và một cảnh báo quan trọng khi chọn lọc đặc trưng:

Thực hiện chọn lọc BÊN TRONG vòng cross-validation, không phải trước đó.

Chọn đặc trưng dựa trên toàn bộ dữ liệu rồi mới chia tập là một dạng rò rỉ dữ liệu — tập kiểm chứng đã ảnh hưởng tới việc chọn cột, nên điểm số sẽ lạc quan hơn thực tế.

Đáp án

B — Dùng SageMaker Batch Transform để triển khai model; thiết lập SageMaker Model Monitor theo dõi chất lượng dữ liệu và cấu hình gửi cảnh báo khi có thay đổi đáng kể.

Vì sao đúng

Đề nêu ba yêu cầu, và B đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Phân tích BẤT ĐỒNG BỘ trên tập dữ liệu lịch sử lớn | Batch Transform | | Giám sát chất lượng dữ liệu theo thời gian | Model Monitor | | Nhận thông báo khi có thay đổi đáng kể | alarm + SNS |

Vì sao Batch Transform đúng cho workload này:

Đặc điểm workload:
  ├─ dữ liệu LỊCH SỬ, có sẵn cả tập
  ├─ xử lý BẤT ĐỒNG BỘ — không ai chờ kết quả ngay
  └─ khối lượng lớn

Batch Transform:
  ├─ đọc cả tệp từ S3, xử lý, ghi kết quả ra S3
  ├─ KHÔNG cần endpoint thường trực → không trả tiền khi rảnh
  └─ tự song song hoá theo instance_count

transformer = model.transformer(
    instance_count=4, instance_type='ml.m5.xlarge',
    strategy='MultiRecord',
    output_path='s3://kho/ket-qua/')
transformer.transform(data='s3://kho/du-lieu-lich-su/', content_type='text/csv')

Và Model Monitor hỗ trợ batch transform job, không chỉ endpoint:

DefaultModelMonitor(...).create_monitoring_schedule(
    batch_transform_input=BatchTransformInput(
        data_captured_destination_s3_uri='s3://kho/du-lieu-bat-duoc/',
        destination='/opt/ml/processing/input',
        dataset_format=MonitoringDatasetFormat.csv()),
    statistics=baseline.baseline_statistics(),
    constraints=baseline.suggested_constraints())

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

• C. Dùng Real-time inference triển khai model; Model Monitor theo dõi chất lượng dữ liệu và gửi cảnh báo — đây là phương án gần nhất và vế giám sát đúng, nhưng real-time endpoint sai với yêu cầu bất đồng bộ: nó chạy 24/7 và tính tiền liên tục, trong khi đề nói rõ phân tích được thực hiện asynchronously trên dữ liệu lịch sử.
• D. Dùng Batch Transform (đúng) nhưng SageMaker Data Wrangler theo dõi chất lượng dữ liệu và gửi cảnh báo — Data Wrangler không giám sát: nó là công cụ chuẩn bị dữ liệu dùng trong giai đoạn phát triển. Nó không chạy theo lịch, không so với baseline, không gửi cảnh báo.
• A. Dùng Docker đóng gói model và triển khai lên Lambda; dùng CloudTrail giám sát chất lượng dữ liệu và gửi cảnh báo — hai lỗi: Lambda có giới hạn kích thước và thời gian (15 phút) — khó xử lý "large historical datasets"; và CloudTrail ghi lời gọi API, nó không biết gì về chất lượng dữ liệu.

Ghi nhớ

Bốn kiểu triển khai của SageMaker — chọn theo hình dạng workload: | Kiểu | Đồng bộ? | Endpoint thường trực | Dùng khi | |---|---|---|---| | Real-time | ✅ | ✅ tính tiền 24/7 | người dùng đang chờ | | Serverless | ✅ | ❌ co về 0 | tải thưa | | Asynchronous | ❌ | ✅ (co về 0 được) | payload lớn, đến rải rác | | Batch Transform | ❌ | ❌ không có endpoint | có sẵn cả tệp ← câu này |

Phân biệt hai kiểu bất đồng bộ: | | Asynchronous Inference | Batch Transform | |---|---|---| | Gọi theo | từng request | cả tệp dữ liệu | | Endpoint | có (co về 0 được) | không có | | Hợp với | dữ liệu đến rải rác | dữ liệu có sẵn, xử lý một lần |

Đề nói "large historical datasets" — dữ liệu đã có sẵn, nên Batch Transform phù hợp hơn.

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

Model Monitor hỗ trợ cả hai nguồn dữ liệu: | Nguồn | Cấu hình | |---|---| | Endpoint | endpoint_input + data capture | | Batch transform | batch_transform_input + data capture trong transform job |

Hai điều kiện bắt buộc — giống nhau ở cả hai trường hợp: | Điều kiện | Chi tiết | |---|---| | Data capture bật | không bật thì báo cáo trống | | Baseline đã tính | suggest_baseline() từ dữ liệu huấn luyện |

Và ba tham số tối ưu Batch Transform: | Tham số | Việc | |---|---| | strategy='MultiRecord' | gộp nhiều bản ghi mỗi lời gọi — hiệu quả hơn | | instance_count | song song hoá qua nhiều máy | | max_payload | kích thước tối đa mỗi lô |

Đáp án

B — XGBoost.

Vì sao đúng

Đề nêu ba yêu cầu, và XGBoost khớp cả ba: | Yêu cầu | XGBoost | |---|---| | Xử lý dữ liệu BẢNG | mạnh nhất trong nhóm cho dữ liệu bảng | | Học CÓ GIÁM SÁT | ✅ | | Phân loại NHỊ PHÂN | objective='binary:logistic' |

Và với dự đoán rời bỏ khách hàng, XGBoost có ba ưu thế cụ thể: | Ưu thế | Chi tiết | |---|---| | Nắm được tương tác phi tuyến | "khách hàng lâu năm + nhiều lần khiếu nại" là tín hiệu khác với từng cái riêng | | Xử lý giá trị thiếu tự nhiên | dữ liệu khách hàng thường thiếu trường | | Feature importance | biết yếu tố nào dẫn tới rời bỏ — có giá trị nghiệp vụ |

xgb.set_hyperparameters(
    objective='binary:logistic',
    eval_metric='aucpr',           # PR-AUC cho dữ liệu mất cân bằng
    scale_pos_weight=ty_le,        # cân bằng lớp
    max_depth=6, eta=0.1, subsample=0.8)

Và với dữ liệu bảng, XGBoost thường CHÍNH XÁC HƠN mạng nơ-ron — không phải chỉ ngang bằng. Đây là kết quả được lặp lại trong nhiều so sánh thực nghiệm, và là lý do nó vẫn là lựa chọn mặc định cho bài toán bảng.

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

• **A. Linear Learner — đây là phương án gần nhất và cũng là thuật toán phân loại nhị phân có giám sát hợp lệ, nhưng nó không nắm được tương tác phi tuyến: model tuyến tính học trọng số độc lập cho từng đặc trưng. Với hành vi khách hàng, các yếu tố thường tương tác với nhau — và đó là chỗ XGBoost vượt trội. (Linear Learner vẫn hữu ích làm đường cơ sở — xem #6537.)
• **C. K-Means — học KHÔNG giám sát, dùng để phân cụm: nó nhóm khách hàng tương tự lại nhưng không dự đoán được ai sẽ rời bỏ. Đề nói rõ đây là bài toán có giám sát với nhãn sẵn có.
• **D. BlazingText — thuật toán xử lý VĂN BẢN: word embedding và phân loại văn bản. Dữ liệu trong đề là bảng (nhân khẩu, lịch sử giao dịch, tương tác hỗ trợ), không phải văn bản tự do.

Ghi nhớ

Thuật toán dựng sẵn của SageMaker — phân theo loại bài toán: | Bài toán | Thuật toán | |---|---| | Phân loại / hồi quy (dữ liệu bảng) | XGBoost, Linear Learner | | Hệ gợi ý | Factorization Machines, Object2Vec | | Phát hiện bất thường | Random Cut Forest, IP Insights | | Phân cụm | K-Means | | Giảm chiều | PCA | | Văn bản | BlazingText, Neural Topic Model, LDA, Sequence-to-Sequence | | Chuỗi thời gian | DeepAR | | Ảnh | Image Classification, Object Detection, Semantic Segmentation |

Cách nhận biết nhanh trong đề thi:

Có nhãn + dự đoán nhãn đó        → có giám sát
Dữ liệu bảng + phân loại/hồi quy → XGBoost (mặc định tốt)
Không có nhãn, tìm cấu trúc      → không giám sát

Ba tham số XGBoost quan trọng nhất cho dự đoán rời bỏ: | Tham số | Việc | |---|---| | scale_pos_weight | cân bằng lớp — khách rời bỏ thường là thiểu số | | eval_metric='aucpr' | PR-AUC phù hợp hơn accuracy với dữ liệu lệch | | max_depth | 4–6 thường đủ; sâu hơn dễ overfit |

Ba loại đặc trưng mạnh cho dự đoán rời bỏ: | Loại | Ví dụ | |---|---| | Xu hướng theo thời gian | giảm tần suất sử dụng 3 tháng gần đây | | Tương tác hỗ trợ | số lần khiếu nại, thời gian giải quyết | | Độ lệch so với chính khách hàng đó | chi tiêu tháng này so với trung bình của họ |

Loại đầu thường mạnh nhất: rời bỏ hiếm khi đột ngột — nó có dấu hiệu báo trước trong xu hướng sử dụng, và model chỉ thấy được nếu bạn tạo đặc trưng thể hiện xu hướng đó.

Và một lưu ý về triển khai: luôn cho model trả về XÁC SUẤT, không phải nhãn cứng. Với dự đoán rời bỏ, đội marketing thường muốn xếp hạng khách hàng theo nguy cơ để phân bổ ngân sách giữ chân — và điều đó cần điểm số liên tục, không phải nhãn nhị phân.

Đáp án

B — Giám sát mức dùng CPU và bộ nhớ để đảm bảo tài nguyên không quá tải, theo dõi thông lượng request để đo số dự đoán mỗi giây, và dùng chính sách auto-scaling duy trì tính sẵn sàng và khả năng mở rộng khi có đỉnh tải.

Vì sao đúng

Đề liệt kê năm khía cạnh hạ tầng cần giám sát, và đáp án B phủ đủ: | Khía cạnh trong đề | Cơ chế trong B | |---|---| | Utilization (mức dùng) | CPU và bộ nhớ | | Throughput (thông lượng) | số dự đoán mỗi giây | | Scalability (khả năng mở rộng) | auto-scaling | | Availability (tính sẵn sàng) | auto-scaling duy trì đủ năng lực | | Fault tolerance | auto-scaling thay instance hỏng |

Điểm quan trọng: đề hỏi về HẠ TẦNG, không phải về chất lượng model. Đó là tiêu chí loại các phương án khác:

Chỉ số HẠ TẦNG:  CPU, bộ nhớ, thông lượng, độ trễ, tỷ lệ lỗi
Chỉ số MODEL:    accuracy, precision, training loss, AUC

Đề nói rõ "metrics related to scalability, availability, utilization, throughput and fault tolerance" — toàn bộ là hạ tầng.

Và auto-scaling là thứ biến giám sát thành hành động:

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

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

• D. Đo độ trễ, theo dõi số request thất bại để đánh giá khả năng chịu lỗi, và dùng scheduled scaling điều chỉnh tài nguyên theo nhu cầu dự kiến — đây là phương án gần nhất và hai chỉ số đầu rất hợp lý (độ trễ và tỷ lệ lỗi đều là chỉ số hạ tầng quan trọng). Nó thua ở vế cuối: scheduled scaling chỉ xử lý được đỉnh tải BIẾT TRƯỚC — với hồ sơ vay đến bất thường, cần auto-scaling phản ứng theo tải thật. (Trong thực tế nên kết hợp cả hai — nhưng scheduled một mình là không đủ.)
• C. Theo dõi accuracy và precision để đảm bảo dự đoán đúng, giám sát dung lượng đĩa, và mở rộng THỦ CÔNG lúc cao điểm — sai loại chỉ số (accuracy là chất lượng model, không phải hạ tầng) và "manually scale" không khả thi cho hệ thống thời gian thực.
• A. Theo dõi training loss và validation accuracy, đo băng thông mạng, và dùng alarm khởi động lại instance hỏng — sai giai đoạn: training loss là chỉ số của quá trình huấn luyện, không liên quan tới hạ tầng phục vụ.

Ghi nhớ

Hai loại chỉ số trong hệ thống ML — phân biệt cho rõ: | Loại | Chỉ số | Trả lời | |---|---|---| | Hạ tầng | CPU, bộ nhớ, độ trễ, thông lượng, tỷ lệ lỗi | "hệ thống có khoẻ không?" | | Model | accuracy, precision, AUC, drift | "dự đoán có đúng không?" |

Cả hai đều cần, và chúng dùng công cụ khác nhau:

Hạ tầng  → CloudWatch metric + alarm + auto-scaling
Model    → SageMaker Model Monitor + Clarify

Năm khía cạnh của hạ tầng ML production và chỉ số tương ứng: | Khía cạnh | Chỉ số | |---|---| | Utilization | CPUUtilization, MemoryUtilization | | Throughput | Invocations, InvocationsPerInstance | | Latency | ModelLatency (p50, p99) | | Fault tolerance | Invocation5XXErrors, số instance khoẻ | | Scalability | số instance hiện tại so với MaxCapacity |

Bốn loại chính sách auto-scaling: | Loại | Cơ chế | Dùng khi | |---|---|---| | Target tracking | giữ metric ở mức mục tiêu | mặc định — đơn giản và hiệu quả nhất | | Step scaling | bậc thang theo mức vượt | cần kiểm soát chi tiết | | Scheduled | theo lịch biết trước | sự kiện đã biết — dùng KÈM target tracking | | Manual | người tự đổi | môi trường dev |

Mẫu tốt nhất cho hệ thống tài chính: target tracking làm nền, cộng scheduled scaling nâng MinCapacity cho những khung giờ cao điểm đã biết (giờ hành chính, cuối tháng) — vì auto-scaling mất vài phút để instance mới sẵn sàng.

Ba tham số cần đặt đúng: | Tham số | Lý do | |---|---| | MinCapacity ≥ 2 | chịu được mất một AZ — đây là vế fault tolerance | | MaxCapacity | trần chi phí | | Cooldown lên < xuống | lên nhanh, xuống chậm để tránh dao động |

Và một chỉ số nên dùng cho auto-scaling: InvocationsPerInstance thay vì CPUUtilization — CPU có thể thấp trong khi model đang chờ I/O, nên nó không phản ánh đúng tải thực.

Đáp án

C — Dùng Amazon EMR trong Amazon SageMaker Studio.

Vì sao đúng

Đề nêu ba yếu tố, và cả ba đều chỉ về EMR: | Yếu tố | EMR | |---|---| | Dữ liệu lớn (big data) | xử lý terabyte tới petabyte | | Dữ liệu trải trên NHIỀU NGUỒN | đọc được S3, HDFS, JDBC, Kafka... | | Cần framework tính toán PHÂN TÁN | Spark, Hive, Presto, Flink |

Cụm "distributed computing framework" là từ khoá quyết định — đó là mô tả trực tiếp của Spark trên EMR.

Và tích hợp EMR trong SageMaker Studio là tính năng đáng biết: bạn kết nối tới cụm EMR ngay từ notebook trong Studio, không phải chuyển sang công cụ khác:

%load_ext sagemaker_studio_analytics_extension.magics
%sm_analytics emr connect --cluster-id j-XXXXXXXX --auth-type None

# Rồi viết Spark bình thường
df = spark.read.parquet('s3://kho/du-lieu-lon/')
df.groupBy('ma_khach_hang').agg(...)

Ba lợi ích của việc dùng EMR từ trong Studio: | Lợi ích | Chi tiết | |---|---| | Một môi trường làm việc | không chuyển qua lại giữa các công cụ | | Sức mạnh xử lý phân tán | Spark xử lý dữ liệu vượt bộ nhớ một máy | | Kết quả đi thẳng vào luồng ML | ghi ra S3 hoặc Feature Store |

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

• **D. Dùng Data Wrangler trong SageMaker Canvas — đây là phương án gần nhất và Data Wrangler là công cụ chuẩn bị dữ liệu tốt, nhưng nó không phải framework tính toán phân tán: nó lấy mẫu để hiển thị tương tác, và dù áp transform lên toàn bộ dữ liệu khi xuất, nó không thiết kế cho quy mô big data thật sự. (Với dữ liệu tới vài chục GB thì Data Wrangler đủ; vượt qua đó cần Spark.)
• **B. Dùng SQL extension trong SageMaker Studio — SQL extension nối tới Athena hoặc Redshift, hữu ích cho truy vấn, nhưng nó không phải môi trường tính toán phân tán tuỳ ý: biến đổi phức tạp và tính toán khoa học không diễn đạt được bằng SQL.
• **A. Dùng SageMaker Ground Truth — sai dịch vụ hoàn toàn: Ground Truth là công cụ GÁN NHÃN dữ liệu, không xử lý và không biến đổi dữ liệu.

Ghi nhớ

Chọn công cụ chuẩn bị dữ liệu theo quy mô: | Quy mô | Công cụ | |---|---| | MB tới vài GB | pandas trong notebook, Data Wrangler | | Vài GB tới vài trăm GB | Data Wrangler, Glue | | TB tới PB | EMR (Spark), Glue với nhiều DPU |

So sánh ba công cụ xử lý dữ liệu lớn: | | EMR | Glue | SageMaker Processing | |---|---|---|---| | Serverless | ❌ (có EMR Serverless) | ✅ | ✅ | | Framework | Spark, Hive, Presto, Flink | Spark | container của bạn | | Kiểm soát | cao nhất | vừa | cao | | Tốn công quản lý | cao nhất | thấp | thấp | | Dùng khi | cần kiểm soát cụm, nhiều framework | ETL chuẩn | môi trường tuỳ chỉnh |

EMR Serverless đáng biết như lựa chọn trung gian: nó cho sức mạnh Spark mà không phải quản lý cụm — thường là điểm cân bằng tốt hơn EMR truyền thống cho workload không liên tục.

Ba cách kết nối EMR với SageMaker: | Cách | Đặc điểm | |---|---| | Studio EMR integration | kết nối trực tiếp từ notebook ← câu này | | CallbackStep trong Pipelines | chạy EMR job như một bước trong pipeline | | Ghi kết quả ra S3 | đơn giản nhất, không có ràng buộc |

Cách thứ hai đã bàn ở #6601 — nó là mẫu đúng khi cần tự động hoá thay vì làm việc tương tác.

Và một lưu ý về chi phí: cụm EMR tính tiền theo thời gian chạy, kể cả khi nhàn rỗi. Ba cách kiểm soát: | Cách | Chi tiết | |---|---| | Cụm tạm thời (transient) | khởi tạo, chạy job, tự tắt | | Auto-termination policy | tự tắt sau N phút nhàn rỗi | | Spot cho task node | giảm tới 90% — xem #6521 |

Đáp án

A và D.

• A — Dùng instance dựa trên AWS Trainium để huấn luyện, cải thiện hiệu quả năng lượng và giảm chi phí nhờ phần cứng deep learning được tối ưu
• D — Dùng SageMaker Debugger giám sát training job phát hiện tình trạng không hội tụ và dừng job sớm để tiết kiệm tài nguyên tính toán

Vì sao đúng

Đề nêu mục tiêu: giảm năng lượng và tài nguyên tính toán trong khi giữ độ chính xác model. Hai đáp án tấn công theo hai hướng khác nhau: | Đáp án | Cách tiết kiệm | |---|---| | A — Trainium | làm cùng công việc với ÍT NĂNG LƯỢNG hơn | | D — Debugger dừng sớm | KHÔNG làm công việc vô ích |

A — Trainium là chip do AWS thiết kế riêng cho huấn luyện: | Đặc điểm | Chi tiết | |---|---| | Chuyên cho huấn luyện deep learning | tối ưu đúng phép tính cần | | Hiệu quả năng lượng cao hơn GPU đa năng | đúng mục tiêu bền vững của đề | | Chi phí thấp hơn | thường rẻ hơn đáng kể |

D — dừng job hỏng sớm là khoản tiết kiệm lớn nhất:

Job 12 giờ trên instance GPU/Trainium đắt tiền
    ↓ phút thứ 20: Debugger phát hiện vanishing gradient
    ↓ EventBridge → Lambda → StopTrainingJob
Job dừng — tiết kiệm 11 giờ 40 phút tài nguyên

rules = [
    Rule.sagemaker(rule_configs.vanishing_gradient()),
    Rule.sagemaker(rule_configs.loss_not_decreasing()),
    Rule.sagemaker(rule_configs.overfit()),
    Rule.sagemaker(rule_configs.low_gpu_utilization())]

Rule cuối đáng nhắc riêng cho mục tiêu bền vững: nó phát hiện phần cứng đắt tiền đang nằm chờ dữ liệu — một dạng lãng phí năng lượng không lộ ra trong bất kỳ chỉ số nào khác.

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

• E. Tăng kích thước instance để mỗi job dùng nhiều tài nguyên hơn, thực thi nhanh hơn và giảm tiêu thụ năng lượng — đây là phương án gần nhất và lập luận nghe hợp lý nhưng không đúng: instance lớn hơn tiêu thụ nhiều năng lượng hơn trên mỗi đơn vị thời gian. Nó chỉ tiết kiệm nếu tổng năng lượng giảm — điều chỉ xảy ra khi tài nguyên hiện tại đang là nút thắt thật, không phải mặc định.
• B. Tắt huấn luyện phân tán để giảm tiêu thụ năng lượng bằng cách huấn luyện trên một instance — thường làm tăng tổng năng lượng: một instance mất nhiều thời gian hơn nhiều, và tổng năng lượng = công suất × thời gian. Huấn luyện phân tán hiệu quả thường tiết kiệm hơn.
• C. Tăng kích thước tập huấn luyện để model có nhiều dữ liệu hơn, giảm nguy cơ không hội tụ — đi ngược mục tiêu: nhiều dữ liệu hơn nghĩa là nhiều tính toán hơn. Và dữ liệu nhiều không chữa được vấn đề hội tụ — nguyên nhân thường là learning rate hoặc kiến trúc.

Ghi nhớ

Bốn kỹ thuật giảm năng lượng và tài nguyên khi huấn luyện: | Kỹ thuật | Cách tiết kiệm | |---|---| | Phần cứng chuyên dụng (Trainium) | hiệu quả năng lượng cao hơn | | Dừng sớm job hỏng (Debugger) | không làm việc vô ích | | Early stopping | dừng khi hết cải thiện — bỏ epoch thừa | | Mixed precision (FP16/BF16) | nhanh gấp 2–3 lần, gần như không mất độ chính xác |

Bốn kỹ thuật này nên là mặc định cho mọi dự án có mục tiêu bền vững hoặc ràng buộc ngân sách — chúng giảm tài nguyên mà không hy sinh chất lượng, đúng yêu cầu của đề.

Các rule của SageMaker Debugger cho việc dừng sớm: | Rule | Phát hiện | |---|---| | vanishing_gradient | gradient tiến về 0 — model ngừng học | | loss_not_decreasing | loss đứng yên — chạy tiếp vô ích | | overfit | validation loss tăng | | low_gpu_utilization | phần cứng nhàn rỗi — nút thắt ở I/O | | exploding_tensor | giá trị thành NaN |

Cấu hình phản ứng tự động:

Rule kích hoạt → EventBridge event → Lambda → StopTrainingJob

Ba nguyên tắc bền vững cho ML trên AWS: | Nguyên tắc | Chi tiết | |---|---| | Chọn phần cứng hiệu quả | Trainium, Inferentia, Graviton | | Không lãng phí tính toán | dừng sớm, early stopping, right-sizing | | Chọn Region có năng lượng tái tạo cao | AWS công bố thông tin này |

Và ba cách khác đáng biết: | Cách | Chi tiết | |---|---| | Transfer learning thay huấn luyện từ đầu | giảm tính toán hàng chục lần | | Model nhỏ hơn (distillation, pruning) | ít tính toán ở cả huấn luyện lẫn suy luận | | Managed Spot Training | dùng năng lực dư thừa vốn đã được cấp phát |

Dòng đầu thường có tác động lớn nhất: fine-tune một model đã huấn luyện sẵn tốn ít hơn nhiều so với huấn luyện từ đầu — và với hầu hết bài toán, nó cho kết quả tốt hơn.

Đáp án

C — Dùng serverless inference endpoint với tham số MaxConcurrency đặt bằng 1.

Vì sao đúng

Đề cho bốn thông số kỹ thuật rất cụ thể, và chúng cùng chỉ về serverless: | Thông số | Ý nghĩa | |---|---| | Chạy MỘT LẦN mỗi tối | endpoint rảnh 23+ giờ mỗi ngày | | Payload tối đa 3,5 MB | vừa giới hạn 4 MB của serverless | | Hoàn thành trong 60 giây | vừa giới hạn timeout 60 giây | | Một request duy nhất | MaxConcurrency = 1 là đủ |

Vì sao serverless là lựa chọn kinh tế nhất cho mẫu sử dụng này:

Real-time endpoint:  chạy 24/7 = 720 giờ/tháng tính tiền
                     thực tế dùng: 30 phút/tháng
                     → trả tiền cho 719,5 giờ KHÔNG DÙNG

Serverless:          tính tiền theo thời gian xử lý thật
                     → khoảng 30 phút/tháng

Với một workload chạy 0,07% thời gian, khác biệt chi phí là rất lớn.

MaxConcurrency = 1 phù hợp vì chỉ có một request mỗi tối — không cần năng lực song song.

Và cold start không phải vấn đề ở đây: job chạy ban đêm, không ai chờ kết quả tức thì — vài giây khởi động không ảnh hưởng gì.

Ghi chú về giới hạn cần lưu ý

Hai thông số trong đề nằm sát giới hạn của serverless inference: | Thông số | Giá trị đề | Giới hạn serverless | |---|---|---| | Payload | 3,5 MB | 4 MB | | Thời gian xử lý | 60 giây | 60 giây |

Dòng thứ hai đáng chú ý: 60 giây là đúng bằng giới hạn, không có biên an toàn. Nếu dữ liệu tăng hoặc model chậm hơn một chút, request sẽ timeout.

Trong thực tế, Batch Transform (phương án A) cũng là lựa chọn rất hợp lý cho một job chạy theo lịch mỗi tối: nó không có giới hạn timeout đó, xử lý được dữ liệu lớn hơn, và cũng chỉ tính tiền khi chạy. Nó thua ở chỗ cần thiết lập đường vào/ra trên S3 thay vì gọi API trực tiếp — nhiều bước hơn một chút.

Nên nếu gặp câu tương tự với thời gian xử lý vượt 60 giây hoặc payload vượt 4 MB, đáp án sẽ chuyển sang Batch Transform hoặc Asynchronous Inference.

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

• A. Dùng Batch Transform — đây là phương án gần nhất và hoàn toàn hợp lý như phân tích trên. Nó thua ở tiêu chí đơn giản: với một request 3,5 MB duy nhất, gọi endpoint trực tiếp gọn hơn việc chuẩn bị tệp đầu vào trên S3 và đọc kết quả từ S3.
• B. Dùng Asynchronous Inference endpoint và đặt payload vào S3 — thừa năng lực: async thiết kế cho payload rất lớn (tới 1 GB) và xử lý dài (tới 60 phút). Với 3,5 MB và 60 giây, nó thêm độ phức tạp (hàng đợi, thông báo, đọc kết quả từ S3) mà không giải quyết vấn đề gì.
• D. Dùng Real-time inference endpoint với số bản sao tối thiểu bằng 1 — trả tiền 24/7 cho một workload chạy 30 phút mỗi tháng. Trái hẳn mục tiêu chi phí.

Ghi nhớ

Bốn kiểu suy luận và giới hạn — bảng nên thuộc: | Kiểu | Payload | Timeout | Co về 0 | |---|---|---|---| | Real-time | 6 MB | 60 giây | ❌ | | Serverless | 4 MB | 60 giây | ✅ | | Asynchronous | 1 GB | 60 phút | ✅ | | Batch Transform | 100 MB/bản ghi | theo job | ✅ không có endpoint |

Cây quyết định:

Người dùng đang chờ ngay?
  ├─ Có, tải liên tục         → Real-time
  ├─ Có, tải thưa + payload nhỏ → Serverless
  └─ Không
      ├─ Payload lớn hoặc xử lý > 60s → Asynchronous
      └─ Có sẵn cả tệp, chạy theo lịch → Batch Transform

Ba giới hạn của Serverless Inference: | Giới hạn | Giá trị | |---|---| | Bộ nhớ | 1 GB – 6 GB | | GPU | KHÔNG hỗ trợ | | MaxConcurrency | 1–200 |

Dòng giữa quan trọng: model cần GPU thì không dùng serverless được.

Ba cách giảm cold start nếu cần: | Cách | Chi tiết | |---|---| | Provisioned concurrency | giữ sẵn phiên bản ấm — có phí | | Giảm kích thước model | quantization, pruning | | Giảm kích thước container | ít lớp, ít thư viện |

Với job chạy ban đêm như trong đề, không cần cách nào cả — cold start vài giây hoàn toàn chấp nhận được.