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

Đáp án

B và C.

• C — Dùng Multi-Model Endpoint host nhiều model scikit-learn trong một container sau một endpoint duy nhất, giảm chi phí hạ tầng
• B — Dùng Real-Time Inference để triển khai Multi-Model Endpoint đó, cho dự đoán độ trễ thấp và xử lý lưu lượng tối ưu

Vì sao đúng

Đề nêu ba yêu cầu, và cặp B+C đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Nhiều model scikit-learn | MME — cùng framework, chia sẻ container | | Dự đoán thời gian thực độ trễ thấp | Real-Time Inference | | Hiệu quả chi phí | một instance cho nhiều model |

Hai đáp án là hai nửa của cùng một giải pháp: C mô tả cơ chế (multi-model endpoint), B mô tả kiểu triển khai (real-time) — và MME chạy trên nền real-time endpoint.

Vì sao MME phù hợp với nhiều model scikit-learn:

Nhiều endpoint riêng:
  model_tim_mach   → instance riêng, dùng 15%
  model_tieu_duong → instance riêng, dùng 8%     ← lãng phí
  model_ho_hap     → instance riêng, dùng 12%    ← lãng phí

Multi-Model Endpoint:
  Cả ba → CÙNG instance, nạp và loại bỏ động theo nhu cầu
  → chi phí giảm khoảng ba lần

Điều kiện để MME hoạt động — và đề thoả cả hai: | Điều kiện | Đề | |---|---| | Cùng framework | tất cả đều là scikit-learn ✅ | | Model đủ nhỏ để nạp nhiều cùng lúc | model scikit-learn thường nhỏ ✅ |

mme = MultiDataModel(
    name='du-doan-rui-ro-benh',
    model_data_prefix='s3://kho-model/scikit-learn/',
    model=sklearn_model)
predictor = mme.deploy(initial_instance_count=2, instance_type='ml.m5.xlarge')

# Gọi model cụ thể bằng target_model
predictor.predict(du_lieu, target_model='tim-mach.tar.gz')

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

• D. Đóng gói mỗi model vào container RIÊNG và triển khai sau một endpoint duy nhất — đây là phương án gần nhất và mô tả multi-CONTAINER endpoint, một tính năng thật nhưng khác MME: nó dành cho model dùng framework KHÁC NHAU, giới hạn tối đa 15 container, và cập nhật một model đòi triển khai lại endpoint. Với nhiều model cùng là scikit-learn, MME phù hợp hơn hẳn.
• A. Triển khai mỗi model trên endpoint RIÊNG để cách ly lưu lượng — trái yêu cầu chi phí: mỗi endpoint là một khoản chi phí instance riêng chạy 24/7.
• E. Dùng Serverless Inference cho từng model và cấu hình ALB định tuyến giữa các endpoint — phức tạp không cần thiết: bạn phải dựng và duy trì tầng định tuyến riêng, và serverless có cold start — mâu thuẫn với yêu cầu độ trễ thấp.

Ghi nhớ

Ba cơ chế chia sẻ tài nguyên trên SageMaker endpoint: | Cơ chế | Điều kiện | Số model | |---|---|---| | Multi-Model Endpoint (MME) | CÙNG framework | hàng nghìn | | Multi-Container Endpoint | framework KHÁC NHAU | tối đa 15 | | Inference Component | model lớn cần GPU | kiểm soát tài nguyên từng model |

Bảng so sánh hai cái đầu: | | MME | Multi-Container | |---|---|---| | Framework | phải giống nhau | có thể khác | | Nạp model | động từ S3 | cố định khi tạo endpoint | | Cập nhật một model | tải tệp lên S3 | triển khai lại endpoint | | Cold start | có khi model chưa nạp | không |

Dòng áp chót là lợi thế vận hành lớn nhất của MME: thêm hoặc cập nhật model chỉ là thao tác trên S3.

Khi nào KHÔNG nên dùng MME: | Tình huống | Lý do | |---|---| | Model rất lớn | không đủ chỗ nạp nhiều model | | Mọi model đều gọi liên tục | tranh chấp bộ nhớ, evict liên tục | | Yêu cầu p99 rất chặt | cold start khi model chưa nạp |

Hai metric riêng của MME cần theo dõi: | Metric | Ý nghĩa | |---|---| | ModelLoadingWaitTime | thời gian chờ nạp model — cao nghĩa là evict nhiều | | ModelCacheHit | tỷ lệ model đã có sẵn trong bộ nhớ |

Tỷ lệ cache hit thấp là dấu hiệu bộ nhớ không đủ — cần instance lớn hơn hoặc giảm số model trên mỗi endpoint.

Và một mẹo giữ model quan trọng luôn ấm: gọi chúng định kỳ bằng một EventBridge schedule — chi phí không đáng kể và loại bỏ cold start cho những model được dùng nhiều nhất.

Đáp án

A và E.

• A — Model phải được đăng ký trong SageMaker Model Registry
• E — Người dùng Canvas phải có quyền truy cập S3 bucket chứa artifact của model

Vì sao đúng

Đề mô tả tình huống: model được huấn luyện bằng framework bên ngoài, artifact nằm trên S3, và cần chia sẻ cho đồng nghiệp dùng SageMaker Canvas.

Hai điều kiện trong đáp án là hai mắt xích của cơ chế chia sẻ: | Điều kiện | Vì sao cần | |---|---| | Đăng ký trong Model Registry | Canvas nhập model TỪ Model Registry, không từ S3 trực tiếp | | Quyền đọc S3 | Model Registry chỉ lưu METADATA và con trỏ; artifact vẫn ở S3 |

Điểm mấu chốt là hiểu Model Registry lưu gì:

Model Registry KHÔNG lưu model
    → nó lưu METADATA + con trỏ tới:
        ├─ ModelDataUrl  → artifact trên S3
        └─ Image         → container trong ECR

Nên người dùng Canvas cần:
    ① Quyền đọc Model Registry  (để thấy model)
    ② Quyền đọc S3               (để nạp artifact thật)

Thiếu quyền S3 thì Canvas thấy model trong danh sách nhưng không nạp được — một lỗi khó chẩn đoán nếu không biết cơ chế này.

sm.create_model_package(
    ModelPackageGroupName='phan-loai-marketing',
    InferenceSpecification={
        'Containers': [{'Image': arn_image_ecr,
                        'ModelDataUrl': 's3://kho-model/model.tar.gz'}],
        'SupportedContentTypes': ['text/csv'],
        'SupportedResponseMIMETypes': ['text/csv']},
    ModelApprovalStatus='Approved')

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

• B. Người dùng Canvas phải được cấu hình trong SageMaker domain, VÀ phải có quyền truy cập S3 bucket — đây là phương án gần nhất và gộp HAI yêu cầu vào một phương án. Vế S3 trùng với đáp án E, còn vế "cấu hình trong domain" thì đề đã nói sẵn ("Both the analyst and the colleague are part of the same SageMaker domain") — nên nó không phải điều kiện cần bổ sung. Chọn B cùng E sẽ là đếm trùng một yêu cầu.
• D. Người dùng Canvas phải trong domain, và dùng Autopilot để chia sẻ model với Canvas — Autopilot không phải cơ chế chia sẻ: nó là công cụ AutoML. Model được chia sẻ qua Model Registry.
• C. Cần phiên bản Studio mới nhất; Studio Classic không hỗ trợ chia sẻ model sang Canvas — phát biểu về khả năng của công cụ không đúng, và quan trọng hơn: yêu cầu về phiên bản giao diện không phải điều kiện của cơ chế chia sẻ model.

Ghi nhớ

SageMaker Model Registry lưu gì và không lưu gì: | Lưu | Không lưu | |---|---| | Metadata: phiên bản, chỉ số, trạng thái phê duyệt | artifact model (ở S3) | | Con trỏ tới S3 và ECR | container image (ở ECR) | | Lineage, model card | |

Hệ quả thực tế: mọi người cần truy cập model qua Registry đều cần cả quyền Registry lẫn quyền tới S3 và ECR mà nó trỏ tới.

Bốn thành phần của một model package: | Thành phần | Nội dung | |---|---| | ModelDataUrl | artifact trên S3 | | Image | container trong ECR | | ModelMetrics | chỉ số đánh giá | | ModelApprovalStatus | trạng thái phê duyệt |

Ba cách đưa model vào SageMaker Canvas: | Cách | Chi tiết | |---|---| | Từ Model Registry | model huấn luyện ở nơi khác ← câu này | | Xây trong Canvas | AutoML không cần mã | | Từ JumpStart | model đã huấn luyện sẵn |

Ba quyền IAM cần cho người dùng Canvas nhập model:

{"Effect": "Allow",
 "Action": ["sagemaker:ListModelPackages",
            "sagemaker:DescribeModelPackage",
            "s3:GetObject",
            "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"],
 "Resource": [...]}

Ba nhóm quyền, ba nơi khác nhau — và thiếu nhóm nào cũng gây lỗi ở một bước khác nhau trong quá trình nhập.

Và một lưu ý về mô hình cộng tác: Model Registry là điểm bàn giao chuẩn giữa các vai trò — nhà khoa học dữ liệu huấn luyện và đăng ký; nhà phân tích nghiệp vụ nhập vào Canvas để thử nghiệm; kỹ sư ML triển khai lên endpoint. Cả ba làm việc trên cùng một artifact có phiên bản, thay vì gửi tệp cho nhau.

Đáp án

C và D — hai cách độc lập đều đáp ứng yêu cầu:

• D — Gắn IAM role cho notebook instance với s3:GetObject cho bucket và kms:Decrypt cho KMS key
• C — Cấp cho role s3:GetObject, và đưa ARN của role vào KMS key policy để cho phép kms:Decrypt

Vì sao đúng

Đề nêu yêu cầu rõ: notebook phải đọc được dữ liệu từ S3 và giải mã bằng KMS key, theo thực hành tốt nhất về bảo mật.

Với SSE-KMS, cần HAI quyền ở HAI nơi:

① Quyền đọc object trên S3   →  s3:GetObject
② Quyền giải mã bằng KMS key →  kms:Decrypt

Thiếu quyền thứ hai thì S3 trả về AccessDenied khi giải mã — một lỗi hay bị nhầm là vấn đề quyền S3.

Và KMS có ĐẶC ĐIỂM RIÊNG: quyền được cấp ở HAI nơi, cả hai đều hợp lệ: | Cách | Cấp ở đâu | |---|---| | D — identity-based policy | IAM role có kms:Decrypt | | C — key policy | KMS key policy liệt kê ARN của role |

Đó là lý do đề hỏi "meet these requirements INDEPENDENTLY" — hai cách này là hai con đường riêng biệt tới cùng kết quả.

// Cách D: trong IAM role
{"Effect": "Allow",
 "Action": ["s3:GetObject", "kms:Decrypt"],
 "Resource": ["arn:aws:s3:::kho-gen/*",
              "arn:aws:kms:...:key/abcd-1234"]}

// Cách C: trong KMS key policy
{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:role/SageMakerNotebookRole"},
 "Action": "kms:Decrypt",
 "Resource": "*"}

Một chi tiết quan trọng về KMS: key policy là nguồn quyền gốc. Nếu key policy không uỷ quyền cho IAM (không có statement "Principal": {"AWS": "arn:aws:iam::<account>:root"} với quyền tương ứng), thì IAM policy một mình không đủ — và khi đó chỉ cách C hoạt động.

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

• B. Cấu hình inline policy cấp kms:Decrypt cho key và s3:GetBucketAcl cho bucket — đây là phương án gần nhất và sai ở quyền S3: s3:GetBucketAcl chỉ cho đọc danh sách kiểm soát truy cập của bucket, không cho đọc nội dung object. Quyền cần là s3:GetObject.
• A. Thêm IAM role của notebook vào access control list (ACL) của bucket và thêm kms:Decrypt vào policy của role — ACL là cơ chế cũ và không dùng IAM role: S3 ACL cấp quyền cho AWS account hoặc nhóm định sẵn, không cho IAM role. AWS khuyến nghị tắt ACL và dùng bucket policy hoặc IAM policy.
• E. Cập nhật security group của notebook để cho phép inbound từ S3 bucket và outbound tới KMS key — nhầm tầng kiểm soát: security group lọc lưu lượng mạng theo IP và cổng; S3 và KMS là dịch vụ có endpoint, không phải nguồn IP mà bạn "cho phép inbound". Đây là vấn đề quyền, không phải mạng.

Ghi nhớ

Ba loại mã hoá phía máy chủ của S3: | Loại | Khoá do ai quản | Cần kms:Decrypt? | |---|---|---| | SSE-S3 | AWS quản lý hoàn toàn | ❌ | | SSE-KMS | KMS key (AWS hoặc của bạn) | ✅ | | SSE-C | bạn cung cấp khoá mỗi request | ❌ (bạn tự giữ khoá) |

Chỉ SSE-KMS mới cần quyền KMS bổ sung — và đó là nguyên nhân phổ biến nhất của lỗi "AccessDenied dù đã có quyền S3".

Bốn quyền KMS hay dùng: | Quyền | Việc | |---|---| | kms:Decrypt | đọc dữ liệu đã mã hoá | | kms:GenerateDataKey | GHI dữ liệu mới (mã hoá) | | kms:DescribeKey | xem thông tin key | | kms:Encrypt | mã hoá trực tiếp |

Dòng thứ hai đáng nhớ: nếu notebook cần ghi dữ liệu vào bucket SSE-KMS, chỉ kms:Decrypt là không đủ — cần thêm kms:GenerateDataKey.

Hai nơi cấp quyền KMS — và cách chúng phối hợp: | Nơi | Vai trò | |---|---| | Key policy | nguồn quyền GỐC — bắt buộc phải có | | IAM policy | chỉ có hiệu lực nếu key policy uỷ quyền cho IAM |

Statement uỷ quyền điển hình trong key policy:

{"Sid": "Enable IAM policies",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
 "Action": "kms:*", "Resource": "*"}

Không có statement này thì IAM policy vô tác dụng với key đó — một trong những điểm hay gây bối rối nhất của KMS.

Và ba thực hành tốt cho notebook truy cập dữ liệu mã hoá: | Thực hành | Chi tiết | |---|---| | Đặc quyền tối thiểu | chỉ prefix cần thiết, chỉ key cần thiết | | Dùng execution role, không dùng access key | notebook chạy bằng role | | Bật CloudTrail cho KMS | ghi lại mọi lần giải mã — cần cho dữ liệu gen |

Đáp án

C — Triển khai model bằng SageMaker Serverless Inference với provisioned concurrency.

Vì sao đúng

Đề nêu năm yếu tố, và serverless với provisioned concurrency khớp cả năm: | Yếu tố | Cơ chế | |---|---| | Workload DỰ ĐOÁN ĐƯỢC, trong cửa sổ 90 phút mỗi ngày | bật provisioned concurrency đúng cửa sổ đó | | Nhiều lời gọi ĐỒNG THỜI | provisioned concurrency giữ sẵn nhiều phiên bản | | Cần độ trễ thấp | provisioned concurrency LOẠI BỎ cold start | | Ít can thiệp vào hạ tầng | serverless — không quản lý instance | | AWS lo hạ tầng và auto scaling | đúng định nghĩa serverless |

Vì sao provisioned concurrency là mảnh quyết định:

Serverless THUẦN:
  Request đầu tiên → cold start vài giây
  → không đạt "low-latency responses"

Serverless + PROVISIONED CONCURRENCY:
  Giữ sẵn N phiên bản ĐÃ KHỞI ĐỘNG
  → request đầu tiên cũng nhanh
  → và vẫn không phải quản lý instance

ServerlessConfig(
    memory_size_in_mb=4096,
    max_concurrency=20,
    provisioned_concurrency=10)    # ← giữ sẵn 10 phiên bản ấm

Và vì workload DỰ ĐOÁN ĐƯỢC, bạn bật provisioned concurrency chỉ trong cửa sổ 90 phút rồi tắt — trả tiền cho khoảng đó thay vì cả ngày:

23:00 — EventBridge → Lambda bật provisioned concurrency
23:00–00:30 — job chạy, độ trễ thấp
00:30 — tắt provisioned concurrency
→ 22,5 giờ còn lại gần như không tốn gì

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

• A. Dùng Real-time Inference với auto scaling — đây là phương án gần nhất và hoạt động tốt về mặt kỹ thuật, nhưng nó kém kinh tế hơn: endpoint real-time chạy 24/7 với MinCapacity ≥ 1, tức trả tiền cho 22,5 giờ nhàn rỗi mỗi ngày. Và bạn vẫn phải chọn loại instance và cấu hình scaling — nhiều hơn "minimal involvement in infrastructure maintenance or configuration".
• **D. Dùng Asynchronous Inference với auto scaling — không đáp ứng yêu cầu độ trễ thấp: async xếp hàng và trả kết quả qua S3. Nó co về 0 được (tốt về chi phí) nhưng sai về mô hình tương tác.
• B. Triển khai trên EC2 bằng SageMaker Python SDK, "spin up một managed endpoint với nhiều EC2 instance, mỗi instance có webserver" — mô tả lẫn lộn: nếu là managed endpoint thì bạn không quản lý EC2; nếu tự dựng EC2 thì trái yêu cầu "minimal involvement in infrastructure maintenance".

Ghi nhớ

Bốn kiểu suy luận và đặc điểm chi phí: | Kiểu | Tính tiền | Cold start | Co về 0 | |---|---|---|---| | Real-time | theo instance-giờ, 24/7 | không | ❌ | | Serverless | theo thời gian xử lý | có | ✅ | | Serverless + provisioned | theo thời gian giữ sẵn + xử lý | không | ❌ trong lúc bật | | Asynchronous | theo instance-giờ (co về 0 được) | có | ✅ |

Provisioned concurrency là điểm trung gian: nó cho độ trễ của real-time với mô hình chi phí linh hoạt hơn — bật khi cần, tắt khi không.

Ba giới hạn của Serverless Inference: | Giới hạn | Giá trị | |---|---| | Bộ nhớ | 1 GB – 6 GB | | Payload | 4 MB | | Timeout | 60 giây | | GPU | KHÔNG hỗ trợ |

Bốn giới hạn này là bộ lọc nhanh — nếu model vượt bất kỳ cái nào, serverless không dùng được.

Ba cách quản lý provisioned concurrency theo lịch: | Cách | Chi tiết | |---|---| | EventBridge schedule + Lambda | bật và tắt theo giờ cố định | | Application Auto Scaling scheduled action | tương tự, dùng cơ chế scaling | | Giữ bật liên tục | đơn giản nhất, tốn hơn |

Cách đầu phù hợp với đề: cửa sổ 90 phút biết trước, nên lịch cố định là đủ.

Và một cân nhắc về điểm hoà vốn: provisioned concurrency đắt hơn serverless thuần trên mỗi đơn vị thời gian, nhưng rẻ hơn real-time endpoint chạy 24/7 nếu chỉ bật vài giờ mỗi ngày. Với 90 phút/ngày (khoảng 6% thời gian), khoản tiết kiệm so với real-time là rất lớn.

Đáp án

C — Logistic regression (hồi quy logistic).

Vì sao đúng

Đề mô tả bài toán rất rõ ràng qua một câu: dự báo xem khách hàng tương lai CÓ cần hỗ trợ dài hạn hay KHÔNG.

"Có hay không" = phân loại nhị phân, và trong bốn phương án chỉ hồi quy logistic thuộc loại đó: | Thuật toán | Loại bài toán | |---|---| | Logistic regression | phân loại (nhị phân hoặc nhiều lớp) ✅ | | Linear regression | hồi quy — giá trị liên tục ❌ | | Anomaly detection | phát hiện bất thường — không giám sát ❌ | | PCA | giảm chiều — không giám sát ❌ |

Và đề nói rõ có DỮ LIỆU LỊCH SỬ CÓ NHÃN: "historical data with information about clients that required extended assistance" — tức là biết ai đã cần hỗ trợ dài hạn. Đó là điều kiện của học có giám sát.

Vì sao tên "logistic REGRESSION" gây nhầm lẫn:

Dù tên có chữ "regression", nó là thuật toán PHÂN LOẠI.

Cơ chế:  tính một giá trị tuyến tính  z = w·x + b
         rồi đưa qua hàm sigmoid       p = 1 / (1 + e^(-z))
         → p là XÁC SUẤT thuộc lớp dương (0 tới 1)
         → so với ngưỡng để ra quyết định

Chính bước sigmoid biến nó từ hồi quy thành phân loại.

Và đầu ra là xác suất, không phải nhãn cứng — điều này có giá trị nghiệp vụ: đội hỗ trợ có thể xếp hạng khách hàng theo nguy cơ thay vì chỉ nhận nhãn có/không.

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

• **B. Linear regression — đây là phương án gần nhất về mặt tên gọi và cũng là học có giám sát, nhưng nó dự đoán giá trị liên tục (giá nhà, doanh số). Với câu hỏi "có hay không", đầu ra liên tục không có nghĩa — và nó có thể cho giá trị ngoài khoảng [0, 1].
• **A. Anomaly Detection — học không giám sát: nó tìm điểm dữ liệu lệch khỏi bình thường mà không dùng nhãn. Ở đây đề có nhãn lịch sử, và "cần hỗ trợ dài hạn" không phải "bất thường" — nó là một nhóm khách hàng bình thường có đặc điểm riêng.
• **D. PCA — giảm chiều, không giám sát: nó là bước tiền xử lý hữu ích khi có nhiều đặc trưng, nhưng nó không dự đoán gì cả.

Ghi nhớ

Bảng chọn thuật toán theo dạng đầu ra: | Đầu ra cần | Loại bài toán | Thuật toán | |---|---|---| | Có / Không | phân loại nhị phân | logistic regression, XGBoost, SVM | | Một trong nhiều nhãn | phân loại nhiều lớp | softmax regression, XGBoost | | Số liên tục | hồi quy | linear regression, XGBoost | | Nhóm (không có nhãn) | phân cụm | K-Means | | Điểm bất thường | phát hiện bất thường | Random Cut Forest |

Ba câu hỏi để chọn nhanh:

① Có nhãn không?
   Không → không giám sát (phân cụm, bất thường, giảm chiều)
   Có ↓
② Nhãn là gì?
   Danh mục → PHÂN LOẠI
   Số liên tục → HỒI QUY

Hai thuật toán dựng sẵn của SageMaker cho phân loại nhị phân: | Thuật toán | Đặc điểm | |---|---| | Linear Learner | triển khai của hồi quy logistic — nhanh, đơn giản, diễn giải được | | XGBoost | mạnh hơn — nắm được tương tác phi tuyến |

Với dữ liệu bảng thật, XGBoost thường cho kết quả tốt hơn — nhưng câu hỏi này ở mức khái niệm (chọn loại thuật toán), và logistic regression là câu trả lời đúng cho "cách tiếp cận" nào.

Ba lợi thế của hồi quy logistic dù đơn giản: | Lợi thế | Chi tiết | |---|---| | Diễn giải được | hệ số cho biết đặc trưng nào tăng/giảm nguy cơ | | Nhanh và rẻ | huấn luyện trong giây | | Đường cơ sở tốt | so sánh model phức tạp với nó để biết có đáng công không |

Dòng cuối là thực hành nên có: luôn dựng một model đơn giản trước để biết bài toán khó tới đâu — nếu XGBoost chỉ hơn hồi quy logistic 1%, model đơn giản có thể là lựa chọn đúng cho production.

Và một lưu ý về ngưỡng: hồi quy logistic trả về xác suất, và ngưỡng biến nó thành quyết định. Với hỗ trợ khách hàng, ngưỡng là quyết định nghiệp vụ — hạ ngưỡng để chủ động chăm sóc nhiều khách hơn (recall cao), hay nâng ngưỡng để tập trung nguồn lực (precision cao).

Đáp án

A — SageMaker là dịch vụ được quản lý hoàn toàn, đơn giản hoá cả vòng đời học máy

Vì sao đúng

Đề cần một môi trường lo được mọi bước, từ chuẩn bị dữ liệu tới triển khai. SageMaker đúng là như vậy: Data Wrangler và Feature Store cho khâu dữ liệu, job huấn luyện tự cấp phát máy rồi tự trả lại, Experiments theo dõi các lần chạy, và endpoint suy luận tự co giãn qua nhiều vùng sẵn sàng. Bạn không dựng hay vá máy chủ nào.

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

• B. Phải tự dựng máy chủ — sai; đây chính là thứ SageMaker thay bạn làm.
• C. Phải tự cấu hình EC2 — SageMaker có dùng EC2 bên dưới, nhưng bạn không phải chạm tới.
• D. Chỉ hỗ trợ khâu huấn luyện — sai; nó phủ cả vòng đời, và triển khai là một trong những phần mạnh nhất.

Đáp án

B — Đặt luật riêng trong SageMaker Debugger để phát hiện gradient biến mất

Vì sao đúng

Triệu chứng đề mô tả — mô hình ngừng cải thiện — là dấu hiệu kinh điển của gradient biến mất: gradient nhỏ dần qua từng lớp cho tới khi trọng số gần như không đổi nữa. Debugger sinh ra cho đúng việc này: nó lấy mẫu tensor trong lúc huấn luyện, và có sẵn luật VanishingGradient để phát hiện. Bạn còn gắn được hành động tự dừng job khi luật kích hoạt, khỏi trả tiền cho những giờ huấn luyện vô ích.

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

• A. Dừng tay rồi thêm dữ liệu — thêm dữ liệu không chữa được vấn đề nằm ở lan truyền gradient, và "bằng tay" thì lần sau lại lặp lại.
• C. Tăng batch size để bắt gradient rõ hơn — batch size ảnh hưởng độ nhiễu của ước lượng gradient, không phải công cụ chẩn đoán.
• D. SageMaker Neo — tối ưu mô hình đã huấn luyện xong cho thiết bị biên; hoàn toàn khác giai đoạn.

Đáp án

B và C — tăng mẫu lớp thiểu số, và đặt trọng số lớp

Vì sao đúng

Với tỷ lệ 95/5, mô hình đoán bừa "lớp đa số" cho mọi mẫu là đã đạt 95% độ chính xác mà chẳng học được gì. Hai cách xử lý ở tầng dữ liệu và tầng hàm mất mát:

• B. Oversampling nhân bản hoặc sinh thêm mẫu lớp thiểu số (SMOTE chẳng hạn) để mô hình nhìn thấy chúng đủ nhiều.
• C. Trọng số lớp phạt nặng hơn khi đoán sai lớp hiếm, nên gradient bị kéo về phía học lớp đó — làm ngay trong hàm mất mát, không đụng tới dữ liệu.

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

• A. Dùng AUC làm chỉ số — AUC là cách đo, không sửa được việc mô hình học lệch.
• D. Dùng precision thay accuracy — cũng chỉ là đổi thước đo.
• E. Undersampling lớp đa số — giảm mẫu là vứt bỏ dữ liệu thật; với lớp đa số áp đảo thì mất rất nhiều thông tin, chỉ nên dùng khi dữ liệu quá lớn.

Đáp án

D — Dùng kỹ thuật chính quy hoá, phạt các tham số có giá trị cực đoan

Vì sao đúng

Quá khớp xảy ra khi mô hình học thuộc cả nhiễu của tập huấn luyện. Chính quy hoá thêm một số hạng phạt vào hàm mất mát theo độ lớn của trọng số (L1 hoặc L2), nên mô hình bị ép chọn lời giải "trơn" hơn thay vì uốn theo từng điểm dữ liệu. Đây là cách trực tiếp và rẻ nhất.

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

• A. Thêm dữ liệu mà không có bước kiểm định — thêm dữ liệu thường có ích, nhưng không có tập kiểm định thì không biết mình có đang quá khớp hay không.
• B. Giảm kích thước tập huấn luyện — ít dữ liệu hơn thì quá khớp nặng thêm.
• C. Dùng mô hình phức tạp hơn — thêm tham số là thêm khả năng học thuộc nhiễu.

Đáp án

B — Chia dữ liệu ra nhiều máy, mỗi máy huấn luyện cùng một mô hình trên phần của mình

Vì sao đúng

Song song hoá theo dữ liệu giữ bản sao đầy đủ của mô hình trên mỗi máy và chia tập dữ liệu thành nhiều phần. Mỗi máy tính gradient trên phần của mình, sau đó các gradient được gộp lại (all-reduce) và mọi bản sao cùng cập nhật giống hệt nhau. Nhờ vậy tăng tốc gần tuyến tính theo số máy, miễn là mô hình vừa bộ nhớ một GPU.

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

• A. Chia cả dữ liệu lẫn mô hình — đó là cách kết hợp hai kiểu, không phải định nghĩa của song song theo dữ liệu.
• C. Mỗi máy huấn luyện một mô hình khác nhau — đó là chạy nhiều thí nghiệm song song, không phải huấn luyện phân tán.
• D. Chia mô hình ra nhiều máy — đó là song song theo mô hình, dùng khi mô hình quá lớn cho một GPU.