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

Đáp án

C — Dùng thao tác ImportModel API của Amazon Comprehend ở tài khoản B để nhập model phân tích cảm xúc từ tài khoản A, bằng cách cấu hình resource-based IAM policy ở TÀI KHOẢN A.

Vì sao đúng

Đề yêu cầu chuyển an toàn và hiệu quả với ít công sức nhất, và Comprehend có API dựng sẵn cho việc này.

Điểm phân biệt duy nhất giữa B và C là policy đặt ở tài khoản nào — và đây là nguyên tắc IAM cơ bản:

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

Tài khoản A (sở hữu model)
    ↓ gắn resource-based policy lên model
    "Cho phép tài khoản B gọi ImportModel trên model này"
                    ↓
Tài khoản B gọi ImportModel → được phép

Chủ sở hữu là bên cấp quyền; bên nhận không thể tự cấp quyền cho mình truy cập tài nguyên của người khác.

# Ở TÀI KHOẢN A — chủ sở hữu model
aws comprehend put-resource-policy   --resource-arn arn:aws:comprehend:us-west-2:111111111111:document-classifier/phan-tich-cam-xuc/version/v1   --resource-policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
      "Action": "comprehend:ImportModel",
      "Resource": "*"}]}'

# Ở TÀI KHOẢN B — bên nhận
aws comprehend import-model   --source-model-arn arn:aws:comprehend:us-west-2:111111111111:document-classifier/phan-tich-cam-xuc/version/v1   --model-name phan-tich-cam-xuc-cskh

Và ImportModel sao chép model một cách an toàn qua kênh nội bộ của AWS — không phải tải xuống, không phải viết script tái tạo.

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

• B. Dùng ImportModel ở tài khoản B bằng cách cấu hình resource-based policy ở TÀI KHOẢN B — đây là phương án gần nhất và sai ở đúng một từ. Đặt policy ở tài khoản B là tài khoản B tự cấp quyền cho mình truy cập tài nguyên của tài khoản A — điều đó không có tác dụng. Cuộc gọi sẽ bị từ chối vì tài khoản A chưa cho phép.
• A. Tải artifact model thủ công từ S3 ở tài khoản A và tải lên bucket ở tài khoản B; dùng script tuỳ chỉnh tái tạo model — không khả thi với Comprehend custom model: artifact của nó không phơi ra để bạn tải xuống, và không có cách nào "tái tạo" nó từ tệp. Ngay cả khi được, đây là công sức tối đa cho việc mà một lời gọi API làm xong.
• D. Dùng Glue Data Catalog đăng ký metadata model ở tài khoản A và bật chia sẻ chéo tài khoản; truy cập qua Console Comprehend ở tài khoản B — Glue Data Catalog quản lý metadata BẢNG DỮ LIỆU, không quản lý model ML. Và Comprehend không đọc gì từ Glue Catalog.

Ghi nhớ

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 tài nguyên; identity-based policy ở tài khoản GỌI.

Cả hai đều cần:

Tài khoản A: resource policy cho phép B     ← "tôi cho phép anh"
Tài khoản B: IAM policy cho role được gọi   ← "tôi cho nhân viên này gọi"

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

Các dịch vụ hỗ trợ resource-based policy — nhóm này hay xuất hiện trong đề thi: | Dịch vụ | Tên policy | |---|---| | S3 | bucket policy | | KMS | key policy | | Lambda | resource policy | | SNS / SQS | topic / queue policy | | Comprehend | resource policy cho custom model | | SageMaker Model Registry | resource policy cho model package group |

Và các dịch vụ không có resource-based policy (phải dùng role assumption): EC2, RDS, DynamoDB (trừ vài trường hợp), CloudWatch.

Hai cách chia sẻ model qua tài khoản: | Cách | Đặc điểm | |---|---| | ImportModel (Comprehend) | sao chép model sang tài khoản đích — độc lập sau đó | | Resource policy trên Model Registry (SageMaker) | tham chiếu, không sao chép — một nguồn sự thật |

Đánh đổi: sao chép cho độc lập (tài khoản B không phụ thuộc tài khoản A về sau) nhưng tạo ra hai bản phải đồng bộ khi model được cập nhật. Với Comprehend, sao chép là cơ chế duy nhất — nên cần quy trình cập nhật khi có phiên bản mới.

Và một lưu ý về Region: ImportModel có thể sao chép qua Region trong cùng lời gọi — hữu ích nếu tài khoản B hoạt động ở Region khác us-west-2.

Đáp án

B — Dùng Amazon SageMaker Clarify phân tích dữ liệu suy luận đã bắt được từ endpoint thời gian thực để phát hiện thiên lệch theo yêu cầu (on-demand).

Vì sao đúng

Đề nêu yêu cầu rõ ràng: chạy một workflow theo yêu cầu để giám sát bias drift trên model đã triển khai.

Clarify là dịch vụ duy nhất trong bốn phương án làm được việc này, và nó có hai chế độ: | Chế độ | Cách chạy | |---|---| | Theo lịch (monitoring schedule) | định kỳ tự động | | Theo yêu cầu (processing job) | chạy khi cần — đúng yêu cầu của đề |

from sagemaker.clarify import SageMakerClarifyProcessor, BiasConfig, DataConfig

clarify = SageMakerClarifyProcessor(role=role, instance_count=1,
                                    instance_type='ml.m5.xlarge')
clarify.run_post_training_bias(
    data_config=DataConfig(s3_data_input_path=duong_dan_du_lieu_bat_duoc,
                           s3_output_path='s3://kho/bao-cao-bias/',
                           label='du_doan'),
    data_bias_config=BiasConfig(label_values_or_threshold=[1],
                                facet_name='nhom_tuoi'),
    model_config=..., model_predicted_label_config=...)

Điều kiện tiên quyết là data capture — và đó là chi tiết đáng nhớ nhất của câu này:

DataCaptureConfig(enable_capture=True,
                  sampling_percentage=100,
                  destination_s3_uri='s3://kho/du-lieu-bat-duoc/')

Không bật data capture thì Clarify không có gì để phân tích, và job chạy xong với báo cáo trống — một lỗi im lặng.

Và phân tích trên dữ liệu suy luận thật là điều làm cho việc này có nghĩa: nó đo thiên lệch trên phân bố người dùng hiện tại, không phải trên tập dữ liệu huấn luyện cũ.

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

• A. Dùng image dựng sẵn sagemaker-model-monitor-analyzer để tự động PHÂN TÍCH VÀ KHẮC PHỤC bias drift — đây là phương án gần nhất và mắc một lỗi quan trọng: image đó phân tích chất lượng dữ liệu và model, và quan trọng hơn — không có công cụ nào "tự khắc phục" bias. Khắc phục đòi hỏi huấn luyện lại, đổi dữ liệu, hoặc điều chỉnh ngưỡng — đều là quyết định của con người.
• C. Dùng SageMaker Lineage Tracking truy vết và phân tích bias drift trong dự đoán — sai công cụ: lineage ghi lại model này từ dữ liệu nào, job nào (xem #6429). Nó hữu ích sau khi phát hiện bias để truy nguồn gốc, nhưng nó không đo lường thiên lệch.
• D. Dùng AWS Glue Data Quality kiểm tra và giám sát chất lượng dữ liệu để phát hiện bias drift ở endpoint thời gian thực — sai phạm vi: Glue Data Quality kiểm tra dữ liệu trong data lake (đầy đủ, đúng định dạng, trong khoảng hợp lệ). Nó không kết nối với endpoint SageMaker và không tính chỉ số công bằng.

Ghi nhớ

Bốn loại giám sát của SageMaker — bảng này lặp lại trong nhiều câu: | Loại | Phát hiện | Công cụ | |---|---|---| | Data quality | phân bố đầu vào đổi | Model Monitor | | Model quality | độ chính xác giảm (cần nhãn thật) | Model Monitor | | Bias drift | chênh lệch giữa các nhóm tăng | Clarify ← câu này | | Feature attribution drift | đặc trưng chi phối dự đoán đổi | Clarify |

Hai loại phân tích bias của Clarify: | Loại | Khi nào | |---|---| | Pre-training bias | trên DỮ LIỆU, trước khi huấn luyện | | Post-training bias | trên DỰ ĐOÁN, sau khi huấn luyện hoặc trên production ← câu này |

Ba chỉ số bias hay dùng: | Chỉ số | Đo | |---|---| | DPPL | chênh lệch tỷ lệ kết quả tích cực giữa các nhóm | | DI | tỷ số của hai tỷ lệ — quy tắc 80% thường dùng làm ngưỡng | | RD | chênh lệch recall |

Ba điều kiện để giám sát bias trên production: | Điều kiện | Chi tiết | |---|---| | Data capture bật trên endpoint | không bật thì không có dữ liệu | | Đường cơ sở | không có baseline thì không biết thế nào là "drift" | | Thuộc tính nhóm có trong dữ liệu bắt được | không có cột nhóm thì không tính được chênh lệch |

Điều kiện thứ ba là chỗ khó về mặt thực tế và pháp lý: để đo thiên lệch theo nhóm, bạn phải biết người dùng thuộc nhóm nào — trong khi nhiều quy định hạn chế việc thu thập chính những thuộc tính đó. Cách thường dùng là giữ thuộc tính nhóm ở một kho riêng chỉ dùng cho kiểm toán công bằng, không đưa vào đặc trưng của model.

Và về vế "on-demand" trong đề: chạy theo yêu cầu hợp với kiểm toán định kỳ hoặc điều tra sự cố; với giám sát liên tục, nên dùng monitoring schedule kết hợp EventBridge để tự động hoá (xem #6436).

Đáp án

A — AUC gần 1,0 nghĩa là model có khả năng PHÂN BIỆT rất tốt, tách được hiệu quả nhóm vỡ nợ và nhóm không vỡ nợ.

Vì sao đúng

Đề nêu bối cảnh quan trọng: dữ liệu mất cân bằng nặng (chỉ 10% vỡ nợ), nên accuracy không đủ — và đó là lý do dùng ROC/AUC.

Ý nghĩa của AUC — cách diễn giải chính xác nhất:

AUC là xác suất model xếp một mẫu dương ngẫu nhiên cao hơn một mẫu âm ngẫu nhiên.

Đường ROC vẽ True Positive Rate theo False Positive Rate qua mọi ngưỡng:

TPR │      ╭─────────  AUC ≈ 0,95  (góc trên trái — tốt)
    │    ╭─╯
    │  ╭─╯      ╱ ← đường chéo: AUC = 0,5 (ngẫu nhiên)
    │╭─╯      ╱
    └───────────────── FPR

Càng gần góc trên bên trái càng tốt — đó là điểm mà model bắt được nhiều mẫu dương với ít báo động giả.

Và điểm mạnh của AUC cho bài toán này: nó không phụ thuộc ngưỡng phân loại, nên nó đo năng lực phân biệt của model chứ không đo một điểm vận hành cụ thể.

Vì sao các cách diễn giải khác sai

• C. Đường ROC gần góc trên trái (AUC ≈ 1) cho thấy model đang OVERFITTING và dự đoán quá lạc quan — đây là phương án gần nhất và nhầm lẫn hai khái niệm: AUC cao trên tập kiểm thử là dấu hiệu tốt. Overfitting biểu hiện qua khoảng cách giữa AUC huấn luyện và AUC kiểm thử, không qua giá trị AUC tuyệt đối. (AUC = 1,0 hoàn hảo trên tập kiểm thử thì đáng nghi — nhưng thường là dấu hiệu rò rỉ dữ liệu, không phải overfitting.)
• B. AUC gần 0 nghĩa là model rất chính xác, phân loại đúng gần như mọi trường hợp — ngược hoàn toàn: AUC gần 0 nghĩa là model xếp hạng ngược — nó gán điểm cao cho mẫu âm và điểm thấp cho mẫu dương. (Điều oái oăm: một model như vậy vẫn hữu ích nếu bạn đảo dự đoán — nhưng nó không "chính xác" theo nghĩa thông thường.)
• **D. Đường ROC gần đường chéo (AUC ≈ 0,5) cho thấy model hoạt động TỐT qua mọi ngưỡng — ngược hoàn toàn: đường chéo là đoán ngẫu nhiên. Một đồng xu cũng cho AUC 0,5.

Ghi nhớ

Bốn thành phần của ma trận nhầm lẫn và các chỉ số dẫn xuất: | Chỉ số | Công thức | Ý nghĩa | |---|---|---| | TPR / Recall / Sensitivity | TP / (TP + FN) | bắt được bao nhiêu % mẫu dương thật | | FPR | FP / (FP + TN) | báo nhầm bao nhiêu % mẫu âm | | Precision | TP / (TP + FP) | trong số báo dương, bao nhiêu đúng | | Specificity | TN / (TN + FP) | 1 − FPR |

ROC-AUC so với PR-AUC — điểm quan trọng nhất cần nhớ cho dữ liệu mất cân bằng: | | ROC-AUC | PR-AUC | |---|---|---| | Trục | TPR theo FPR | Precision theo Recall | | Nhạy với mất cân bằng | KHÔNG — có thể trông đẹp giả tạo | CÓ — phản ánh thực tế hơn | | Dùng khi | hai lớp cân bằng tương đối | lớp dương rất hiếm |

Vì sao ROC-AUC có thể gây hiểu lầm với dữ liệu rất mất cân bằng: FPR có mẫu số rất lớn (số mẫu âm), nên hàng nghìn báo động giả vẫn cho FPR nhỏ và đường ROC vẫn đẹp. PR-AUC dùng precision, vốn phản ánh trực tiếp tỷ lệ báo nhầm trong số cảnh báo — nên nó khắt khe hơn.

Với 10% vỡ nợ như đề mô tả, mất cân bằng còn ở mức vừa phải, nên ROC-AUC vẫn hợp lý. Với 1% hoặc thấp hơn (như phát hiện gian lận ở #6455), PR-AUC là lựa chọn đúng hơn.

Ba lưu ý khi dùng AUC để ra quyết định: | Lưu ý | Chi tiết | |---|---| | AUC không cho biết chọn ngưỡng nào | phải chọn riêng theo chi phí nghiệp vụ | | AUC cao vẫn có thể vô dụng ở ngưỡng cụ thể | xem thêm precision và recall tại ngưỡng đó | | So AUC train với AUC test | khoảng cách lớn = overfitting |

Dòng đầu quan trọng nhất trong thực tế: với dự đoán vỡ nợ, chi phí của việc từ chối nhầm một khách hàng tốt khác hẳn chi phí của việc cho vay một khách hàng sẽ vỡ nợ — và ngưỡng phải phản ánh sự bất đối xứng đó, không phải mặc định 0,5.

Đáp án

B — CDD đánh giá chênh lệch tỷ lệ dự đoán dương giữa các nhóm nhân khẩu, CÓ ĐIỀU KIỆN theo một đặc trưng cụ thể như thu nhập, để phát hiện thiên lệch không lộ ra khi chỉ nhìn kết quả tổng thể.

Vì sao đúng

Điểm mấu chốt nằm ở chữ "Conditional" trong tên chỉ số. Nó là thứ phân biệt CDD với các chỉ số thiên lệch thông thường.

Vì sao cần điều kiện hoá — đây là một hiện tượng thống kê có thật, gọi là nghịch lý Simpson:

Nhìn TỔNG THỂ:
  Nhóm A: 30% bị gắn cờ gian lận
  Nhóm B: 20% bị gắn cờ gian lận
  → có vẻ thiên lệch chống nhóm A

Nhìn CÓ ĐIỀU KIỆN theo mức thu nhập:
  Thu nhập thấp:  nhóm A 35%, nhóm B 34%   ← gần như bằng nhau
  Thu nhập cao:   nhóm A 12%, nhóm B 11%   ← gần như bằng nhau
  → chênh lệch tổng thể do PHÂN BỐ THU NHẬP khác nhau,
    không phải do model đối xử khác nhau

Và điều ngược lại cũng xảy ra: hai nhóm trông cân bằng ở mức tổng thể nhưng lệch nặng trong từng phân khúc — đó chính là loại thiên lệch mà đáp án gọi là "may not be apparent when only considering overall outcomes".

Với bài toán gian lận bảo hiểm, thu nhập là biến gây nhiễu hợp lý: nó thực sự liên quan tới khả năng gian lận, nên việc điều kiện hoá theo nó cho ra bức tranh công bằng hơn.

BiasConfig(
    label_values_or_threshold=[1],
    facet_name='nhom_nhan_khau',
    group_name='muc_thu_nhap')      # ← điều kiện hoá theo cột này

Tham số group_name chính là thứ biến DPL thành CDD.

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

• A. CDD đo chênh lệch kết quả dự đoán trung bình giữa các nhóm, giúp nhận diện thiên lệch tổng thể KHÔNG xét tới yếu tố khác — đây là phương án gần nhất và mô tả đúng DPL (Difference in Positive Proportions in Labels), không phải CDD. Cụm "without considering other factors" chính là thứ CDD thêm vào.
• C. CDD đánh giá tỷ lệ dự đoán ĐÚNG cho từng nhóm, đảm bảo model chính xác như nhau giữa các nhóm — mô tả chênh lệch độ chính xác (accuracy difference), một chỉ số khác. CDD nhìn vào tỷ lệ kết quả dương, không nhìn vào tính đúng.
• D. CDD tập trung vào quan hệ giữa mức quan trọng của đặc trưng và các nhóm — mô tả feature attribution drift, thứ Clarify cũng cung cấp nhưng là chỉ số riêng.

Ghi nhớ

Các chỉ số thiên lệch của SageMaker Clarify — nhóm hay hỏi: | Chỉ số | Đo gì | |---|---| | CI (Class Imbalance) | mất cân bằng số lượng giữa các nhóm trong dữ liệu | | DPL | chênh lệch tỷ lệ nhãn dương trong DỮ LIỆU | | DPPL | chênh lệch tỷ lệ dự đoán dương của MODEL | | CDD | DPL nhưng CÓ ĐIỀU KIỆN theo một biến khác | | DI (Disparate Impact) | tỷ số của hai tỷ lệ — quy tắc 80% | | RD | chênh lệch recall |

Hai loại phân tích của Clarify: | Loại | Chạy khi | |---|---| | Pre-training bias | trên DỮ LIỆU, trước khi huấn luyện — CI, DPL, CDD | | Post-training bias | trên DỰ ĐOÁN — DPPL, DI, RD |

Nguyên tắc quan trọng nhất rút ra:

Chênh lệch tổng thể không chứng minh có thiên lệch, và cân bằng tổng thể không chứng minh không có thiên lệch.

Luôn phân tích theo phân khúc khi có biến gây nhiễu hợp lý. Nhưng cẩn thận với chiều ngược lại: điều kiện hoá theo một biến vốn đã bị thiên lệch (ví dụ thu nhập, nếu chính thu nhập phản ánh bất bình đẳng có hệ thống) có thể che giấu thiên lệch thật. Chọn biến điều kiện là quyết định cần cân nhắc về nghiệp vụ, không chỉ về kỹ thuật.

Đáp án

D — Dùng SageMaker Pipelines điều phối quy trình ML, trực quan hoá thành DAG, và dùng SageMaker ML Lineage Tracking cho kiểm toán và tuân thủ.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án phải khớp đúng công cụ cho đúng yêu cầu: | Yêu cầu | Công cụ | |---|---| | Kiểm soát chi tiết các bước pipeline | SageMaker Pipelines | | Trực quan hoá thành DAG | SageMaker Pipelines | | Lịch sử các lần thử nghiệm | Experiments (hoặc chính Pipelines) | | Quản trị model cho kiểm toán quy định | ML Lineage Tracking |

Điểm phân biệt giữa C và D nằm ở yêu cầu cuối cùng, và đây là chỗ dễ nhầm: | Công cụ | Việc thật sự | |---|---| | SageMaker Experiments | theo dõi và SO SÁNH các lần chạy thử nghiệm — tham số, chỉ số | | SageMaker ML Lineage Tracking | ghi lại QUAN HỆ: dataset nào → job nào → model nào → endpoint nào |

Với kiểm toán quy định trong ngành dược, câu hỏi của kiểm toán viên là:

"Model đang dùng để quyết định thử nghiệm tiền lâm sàng này được huấn luyện từ dữ liệu nào, qua những bước xử lý nào?"

Đó là câu hỏi về quan hệ nguồn gốc, và lineage trả lời được; Experiments thì không — nó chỉ cho biết lần chạy nào có chỉ số tốt hơn.

Và Pipelines tự động ghi lineage cho mọi bước của nó, nên hai công cụ này khớp nhau tự nhiên:

LineageQuery(session).query(
    start_arns=[arn_model], direction=LineageQueryDirectionEnum.ASCENDANTS)
# → toàn bộ cây tổ tiên: dataset, processing job, training job

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

• C. SageMaker Pipelines điều phối, trực quan hoá DAG, và dùng SageMaker Experiments cho quản trị model và tuân thủ — đây là phương án gần nhất và sai ở đúng một chỗ: Experiments không phải công cụ quản trị. Nó theo dõi thử nghiệm để so sánh, không ghi lại chuỗi nguồn gốc mà kiểm toán viên cần.
• A. CodePipeline điều phối, trực quan hoá thành chuỗi các stage, và dùng Experiments giữ lịch sử — hai vấn đề: CodePipeline là công cụ CI/CD tuyến tính, không diễn đạt được DAG với các nhánh phụ thuộc; và nó thiếu tích hợp ML gốc.
• B. Dùng Experiments để theo dõi và trực quan hoá MỌI workflow, dựa vào CodePipeline cho điều phối và quản trị — Experiments không điều phối gì cả: nó không chạy bước nào, không quản lý phụ thuộc. Và CodePipeline không có khả năng quản trị model.

Ghi nhớ

Bốn công cụ ML của SageMaker — phân biệt cho rõ: | Công cụ | Việc | |---|---| | Pipelines | ĐIỀU PHỐI: chạy các bước theo DAG | | Experiments | THEO DÕI: so sánh tham số và chỉ số giữa các lần chạy | | ML Lineage Tracking | GHI QUAN HỆ: cái gì sinh ra cái gì | | Model Registry | QUẢN LÝ PHIÊN BẢN: version, phê duyệt |

Bốn công cụ này bổ sung nhau, và một quy trình ML chịu quản lý thường dùng cả bốn:

Pipelines chạy các bước
    ├─ Experiments ghi chỉ số của từng lần chạy
    ├─ Lineage ghi quan hệ giữa artifact
    └─ Model Registry giữ phiên bản và trạng thái phê duyệt

Ba thực thể của lineage: | Thực thể | Nghĩa | |---|---| | Artifact | thứ tồn tại: dataset, model, image | | Action | việc đã làm: training job, processing job | | Context | nhóm logic: một experiment, một pipeline |

Và ba câu hỏi kiểm toán mà chỉ lineage trả lời được: | Câu hỏi | Hướng truy vấn | |---|---| | "Model này từ đâu ra?" | ASCENDANTS | | "Dataset hỏng này đã ảnh hưởng model nào?" | DESCENDANTS | | "Ai đã duyệt phiên bản đang chạy?" | Model Registry + CloudTrail |

Câu thứ hai đặc biệt giá trị trong ngành dược: nếu phát hiện một lô dữ liệu thử nghiệm có vấn đề, truy vấn xuôi cho biết ngay lập tức model nào phải thu hồi.

Đáp án

B — Áp dụng stacking: dùng dự đoán của hồi quy logistic, cây quyết định và SVM làm đầu vào cho một meta-model (ví dụ random forest) để đưa ra dự đoán cuối.

Vì sao đúng

Đề mô tả tình huống đặc trưng cho stacking: nhiều model KHÁC LOẠI, mỗi cái có điểm mạnh riêng, và không cái nào một mình đủ tốt.

Stacking học cách kết hợp, thay vì kết hợp theo công thức cố định:

Tầng 0:  Logistic Regression → dự đoán p1
         Decision Tree       → dự đoán p2
         SVM                 → dự đoán p3
              ↓
Tầng 1:  Meta-model (Random Forest) học từ (p1, p2, p3) → dự đoán cuối

Điểm mạnh so với bỏ phiếu đơn thuần: meta-model có thể học được những quy tắc tinh tế mà công thức cố định không diễn đạt được:

"Khi cây quyết định rất tự tin, hãy tin nó"
"Khi ba model bất đồng, nghiêng về hồi quy logistic"
"Với hồ sơ có thu nhập cao, SVM đáng tin hơn"

Không ai lập trình những quy tắc đó — meta-model học từ dữ liệu.

Và stacking đặc biệt phù hợp khi các model khác loại, vì chúng mắc lỗi ở những chỗ khác nhau — đúng điều kiện đề mô tả.

Một lưu ý kỹ thuật bắt buộc: meta-model phải được huấn luyện trên dự đoán out-of-fold, không phải trên dự đoán của chính dữ liệu mà model tầng 0 đã thấy:

Chia dữ liệu thành K fold
Với mỗi fold: huấn luyện model tầng 0 trên K−1 fold còn lại,
              dự đoán trên fold này
→ Meta-model học từ những dự đoán "chưa từng thấy" này

Bỏ qua bước này là rò rỉ dữ liệu, và meta-model sẽ quá tin vào model tầng 0.

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

• A. Voting ensemble đơn giản, dự đoán cuối theo đa số phiếu của ba model — đây là phương án gần nhất và hoạt động được, nhưng nó đối xử ba model như nhau ở mọi trường hợp. Nếu SVM tốt hơn hẳn ở một phân khúc, voting không tận dụng được điều đó. Stacking học trọng số theo ngữ cảnh.
• C. Bagging — huấn luyện ba loại model khác nhau trên các tập con khác nhau rồi lấy trung bình — mô tả sai bagging: bagging huấn luyện nhiều bản của CÙNG MỘT loại model trên các tập con bootstrap (đó là cách random forest hoạt động). Kết hợp nhiều loại model không phải bagging.
• D. Boosting — huấn luyện tuần tự ba loại model khác nhau, mỗi model sửa lỗi của model trước — mô tả sai boosting: boosting cũng dùng cùng một loại weak learner lặp lại, và nó huấn luyện từ đầu chứ không phải ghép các model đã có sẵn.

Ghi nhớ

Ba kỹ thuật ensemble — phân biệt cho rõ: | Kỹ thuật | Cách làm | Loại model | |---|---|---| | Bagging | huấn luyện song song trên tập con bootstrap, lấy trung bình | cùng loại | | Boosting | huấn luyện tuần tự, model sau sửa lỗi model trước | cùng loại | | Stacking | meta-model học cách kết hợp | KHÁC LOẠI — đây là điểm mạnh |

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

"Tôi có nhiều model KHÁC LOẠI đã huấn luyện sẵn?" → stacking "Tôi muốn giảm phương sai của một loại model?" → bagging "Tôi muốn giảm độ chệch (bias)?" → boosting

Bảng đánh đổi: | | Giảm | Rủi ro | |---|---|---| | Bagging | phương sai | ít overfitting | | Boosting | độ chệch | dễ overfitting hơn | | Stacking | cả hai | rò rỉ dữ liệu nếu làm sai |

Ba nguyên tắc để stacking hiệu quả: | Nguyên tắc | Chi tiết | |---|---| | Model tầng 0 phải ĐA DẠNG | model giống nhau thì sai giống nhau — không có gì để kết hợp | | Dùng dự đoán out-of-fold | bắt buộc, nếu không sẽ rò rỉ | | Meta-model nên ĐƠN GIẢN | hồi quy logistic thường đủ; meta-model phức tạp dễ overfit |

Dòng cuối đáng lưu ý: đáp án nêu random forest làm meta-model, và đó là lựa chọn hợp lý — nhưng trong thực tế hồi quy logistic thường được ưa dùng hơn cho tầng meta vì nó ít overfit và cho trọng số dễ diễn giải.

Đáp án

D — Tạo Docker container với môi trường cần thiết, đẩy image lên Amazon ECR, và dùng SageMaker chạy script huấn luyện trong container đó.

Vì sao đúng

Đề nêu tình huống rõ ràng: cần phiên bản TensorFlow cụ thể với thư viện Python tuỳ chỉnh không có trong môi trường SageMaker chuẩn.

Điểm phân biệt duy nhất giữa C và D là nơi lưu image, và đó là một yêu cầu cứng:

SageMaker chỉ kéo container image từ Amazon ECR. Nó không kéo được từ Docker Hub hay registry ngoài.

# ① Xây image với môi trường tuỳ chỉnh
docker build -t model-gen .

# ② Đăng nhập ECR
aws ecr get-login-password --region ap-northeast-1 |   docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com

# ③ Gắn thẻ và đẩy lên ECR
docker tag model-gen:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/model-gen:latest
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/model-gen:latest

# ④ Tham chiếu trong SageMaker

estimator = Estimator(
    image_uri='123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/model-gen:latest',
    role=role, instance_type='ml.p3.2xlarge')

Lý do ECR là bắt buộc: quyền truy cập được kiểm soát bằng IAM, và SageMaker execution role cần quyền ecr:GetDownloadUrlForLayer — cơ chế đó không tồn tại với registry bên ngoài.

Ghi chú về cách diễn đạt của đáp án: D nói "use SageMaker's Script Mode to execute the training script within the container". Thực tế BYOC và Script Mode là hai cách tiếp cận khác nhau: | Cách | Container | Mã của bạn | |---|---|---| | Script Mode | container do AWS quản lý | truyền script vào qua entry_point | | BYOC | container của bạn | nằm sẵn trong image | | Mở rộng container AWS | container AWS + FROM trong Dockerfile | kết hợp cả hai |

Đề nói rõ đang dùng BYOC, nên cách diễn đạt hơi lẫn. Nhưng vế quan trọng nhất — đẩy lên ECR — thì hoàn toàn đúng, và đó là thứ phân biệt D với C. (Cũng có một biến thể hợp lệ ở giữa: đóng gói SageMaker Training Toolkit vào container riêng để nó nhận được entry_point như Script Mode — có lẽ đó là ý mà phương án muốn nói.)

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

• C. Xây Docker container với TensorFlow và phụ thuộc cần thiết, đẩy image lên Docker Hub, và tham chiếu image đó trong SageMaker — đây là phương án gần nhất và sai ở đúng một từ: SageMaker không kéo được image từ Docker Hub. Mọi thứ khác đúng.
• A. Đóng gói model thành tệp tương thích SageMaker, tải lên S3, và dùng container dựng sẵn của SageMaker cho huấn luyện — mâu thuẫn với chính bài toán: nếu dùng được container dựng sẵn thì đã không cần BYOC. Đề nói rõ phụ thuộc không có trong môi trường chuẩn.
• B. Triển khai model cục bộ bằng Docker, rồi dùng Console sao chép THỦ CÔNG môi trường và tệp model sang SageMaker instance — không có thao tác nào như vậy: SageMaker không cho "sao chép môi trường" qua Console. Đây là mô tả một quy trình không tồn tại.

Ghi nhớ

Ba mức tuỳ biến container trên SageMaker, theo công sức tăng dần: | Mức | Cách làm | Dùng khi | |---|---|---| | Container dựng sẵn | dùng nguyên | framework và phiên bản chuẩn | | Script Mode | container AWS + script của bạn | cần mã riêng, framework chuẩn | | Mở rộng container AWS | FROM image AWS rồi cài thêm | cần vài thư viện thêm | | BYOC | container hoàn toàn của bạn | framework hoặc phiên bản không được hỗ trợ |

Nguyên tắc: leo thang từ trên xuống — mức càng thấp càng ít việc phải bảo trì. Với "phiên bản TensorFlow cụ thể + thư viện tuỳ chỉnh", mức thứ ba (mở rộng container AWS) thường là đủ và ít công hơn BYOC hoàn toàn.

Yêu cầu bắt buộc của một container BYOC cho SageMaker: | Yêu cầu | Chi tiết | |---|---| | Huấn luyện | chạy được lệnh train; đọc dữ liệu từ /opt/ml/input/data/; ghi model ra /opt/ml/model/ | | Suy luận | chạy serve; phục vụ HTTP trên cổng 8080 với /ping và /invocations | | Lưu ở ECR | cùng Region với training job |

Dòng cuối có một chi tiết dễ vấp: image phải nằm ở cùng Region với job. Image ở us-east-1 không dùng được cho job ở ap-northeast-1 — phải sao chép sang.

Và SageMaker Training Toolkit cùng Inference Toolkit là hai thư viện đáng dùng: cài chúng vào container riêng thì bạn được các quy ước của SageMaker (đọc siêu tham số, xử lý entry_point) mà không phải tự viết.

Đáp án

B — Triển khai toàn bộ quy trình bằng Amazon SageMaker Pipelines, vốn cung cấp điều phối tích hợp cho xử lý dữ liệu, huấn luyện, tinh chỉnh và triển khai.

Vì sao đúng

Đề liệt kê bốn bước, và tất cả đều là bước ML: | Bước | Step tương ứng | |---|---| | Tiền xử lý dữ liệu | ProcessingStep | | Huấn luyện model | TrainingStep | | Tinh chỉnh siêu tham số | TuningStep | | Triển khai | ModelStep |

Và yêu cầu bổ sung — huấn luyện lại định kỳ với can thiệp thủ công tối thiểu — được đáp ứng bằng cách kích hoạt pipeline từ EventBridge khi có dữ liệu mới trên S3.

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 lợi ích cụ thể của Pipelines cho tình huống này: | Lợi ích | Chi tiết | |---|---| | Lineage tự động | quan trọng với dữ liệu y tế chịu kiểm toán | | Tích hợp Model Registry sẵn | RegisterModel step, không cần gọi API thủ công | | Không tính phí điều phối | chỉ trả tiền cho job thật sự chạy |

Và ConditionStep cho phép đặt cửa chất lượng — chỉ triển khai khi chỉ số đạt ngưỡng:

ConditionStep(
    name='KiemTraChatLuong',
    conditions=[ConditionGreaterThanOrEqualTo(
        left=JsonGet(step_name='DanhGia', property_file=bao_cao,
                     json_path='metrics.auc'),
        right=0.80)],
    if_steps=[buoc_dang_ky, buoc_trien_khai],
    else_steps=[])

Với dự đoán tái nhập viện, cửa này quan trọng: một model kém hơn bản cũ không được tự động lên production.

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

• **D. Step Functions định nghĩa và điều phối từng bước, tích hợp với SageMaker cho huấn luyện và triển khai, dùng Lambda cho tiền xử lý — đây là phương án gần nhất và hoạt động tốt, nhưng nó tự viết nhiều mã kết nối hơn và mất lineage tự động. Ngoài ra Lambda giới hạn 15 phút, thường không đủ cho tiền xử lý dữ liệu bệnh án quy mô lớn. Step Functions thắng khi có nhiều dịch vụ ngoài ML — không phải trường hợp này.
• C. Glue tiền xử lý, SageMaker huấn luyện và tinh chỉnh, triển khai THỦ CÔNG lên EC2 — "manually deploy" trái thẳng yêu cầu "minimal manual intervention", và ghép ba công cụ rời rạc thì không có điều phối nào cả.
• A. EC2 chạy THỦ CÔNG từng bước, RDS lưu kết quả trung gian, SageMaker endpoint để triển khai — không có tự động hoá nào: mỗi lần huấn luyện lại là công việc tay, và dùng RDS lưu kết quả trung gian của ML là lựa chọn kỳ lạ (S3 là nơi đúng).

Ghi nhớ

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

Ba cách kích hoạt huấn luyện lại tự động: | Cách | Kích hoạt bởi | |---|---| | EventBridge rule + S3 event | dữ liệu mới tới | | EventBridge schedule | theo lịch (hằng tuần, hằng tháng) | | Model Monitor phát hiện drift | chất lượng suy giảm — kích hoạt có điều kiện |

Cách thứ ba là mẫu trưởng thành nhất: chỉ huấn luyện lại khi cần, thay vì theo lịch cứng. Nó tiết kiệm chi phí và tránh việc thay model khi model cũ vẫn tốt.

Và ba step nên có trong mọi pipeline production: | Step | Vì sao | |---|---| | Đánh giá | sinh báo cáo chỉ số | | ConditionStep | chặn model kém | | RegisterModel với PendingManualApproval | cửa kiểm soát của con người |

Với dữ liệu y tế, dòng cuối gần như bắt buộc: tự động hoá tới bước đăng ký, nhưng việc đưa vào production cần một người chịu trách nhiệm bấm duyệt.

Đáp án

B — Thứ tự 1, 5, 3:

1. AWS Glue crawler suy ra schema và các cột có sẵn
2. AWS Glue DataBrew làm sạch dữ liệu và tạo đặc trưng
3. Lưu kết quả trở lại Amazon S3

Vì sao đúng

Đề mô tả dữ liệu thiếu nhãn cột, điền không đầy đủ, có giá trị thiếu — nên bước đầu tiên bắt buộc là hiểu dữ liệu có gì.

Thứ tự này là bắt buộc về mặt logic:

① Crawler suy ra schema  → biết có những cột nào, kiểu gì
        ↓ (phải biết cấu trúc trước khi làm sạch)
② DataBrew làm sạch      → xử lý thiếu, chuẩn hoá, tạo đặc trưng
        ↓
③ Lưu về S3              → sẵn sàng cho huấn luyện

Vì sao Glue crawler cho bước ①: đề nói dữ liệu thiếu nhãn cột — crawler quét tệp CSV, suy ra kiểu dữ liệu từng cột và ghi schema vào Glue Data Catalog. Sau đó mọi công cụ khác đọc được cấu trúc đó.

Vì sao DataBrew cho bước ②: nó là công cụ trực quan, không cần viết mã, với hơn 250 phép biến đổi dựng sẵn — bao gồm chính những thứ đề cần: | Vấn đề | Phép biến đổi DataBrew | |---|---| | Giá trị thiếu | điền bằng trung bình, trung vị, hoặc giá trị cố định | | Dữ liệu điền không đầy đủ | lọc, chuẩn hoá định dạng | | Tạo đặc trưng | tách cột, mã hoá phân loại, chuẩn hoá thang đo |

Và "efficiently" là tiêu chí phân biệt với phương án C.

Vì sao các thứ tự khác sai

• C. 1, 2, 3 — Glue crawler, rồi EMR với Apache Spark làm sạch, rồi lưu S3 — đây là phương án gần nhất và hoạt động được, nhưng EMR tốn công hơn nhiều: phải khởi tạo và quản lý cụm, viết mã Spark. Với một tác vụ làm sạch dữ liệu bảng, DataBrew làm cùng việc bằng giao diện trực quan.
• A. 5, 1, 3 — DataBrew làm sạch TRƯỚC, rồi crawler suy schema, rồi lưu — sai thứ tự: làm sạch dữ liệu chưa biết có cột gì là làm mù. Crawler phải chạy trước để có schema.
• D. 4, 5, 3 — dùng Redshift Spectrum suy schema, rồi DataBrew, rồi lưu — Redshift Spectrum không suy schema: nó truy vấn dữ liệu S3 dựa trên schema đã có sẵn trong Glue Data Catalog. Nó là bên tiêu thụ catalog, không phải bên tạo ra.

Ghi nhớ

Ba công cụ chuẩn bị dữ liệu — phân biệt cho rõ: | Công cụ | Đặc điểm | Dùng khi | |---|---|---| | Glue Crawler | suy schema, ghi vào Data Catalog | bước đầu tiên với dữ liệu chưa biết cấu trúc | | Glue DataBrew | trực quan, 250+ transform, không cần mã | làm sạch và biến đổi dữ liệu bảng | | SageMaker Data Wrangler | trực quan, tích hợp sâu với SageMaker | chuẩn bị đặc trưng cho ML | | Glue ETL / EMR Spark | viết mã, mạnh nhất | biến đổi phức tạp, quy mô rất lớn |

Phân biệt DataBrew với Data Wrangler — hai công cụ rất giống nhau: | | DataBrew | Data Wrangler | |---|---|---| | Thuộc về | Glue (kỹ sư dữ liệu) | SageMaker (nhà khoa học dữ liệu) | | Đầu ra | S3, Data Catalog | Feature Store, pipeline SageMaker | | Tính năng ML riêng | ít | cân bằng lớp, phát hiện rò rỉ mục tiêu, quick model |

Với bối cảnh chuẩn bị dữ liệu cho ML, cả hai đều dùng được — Data Wrangler nhỉnh hơn nhờ các tính năng chuyên cho ML.

Ba việc Glue crawler làm: | Việc | Chi tiết | |---|---| | Suy ra schema | tên cột (từ header nếu có), kiểu dữ liệu | | Phát hiện phân vùng | từ cấu trúc thư mục nam=2026/thang=07/ | | Cập nhật Data Catalog | tạo hoặc cập nhật bảng |

Và một lưu ý về dữ liệu thiếu nhãn cột như trong đề: crawler sẽ đặt tên mặc định (col0, col1…). Bạn cần sửa lại tên cột trong Data Catalog hoặc trong DataBrew để chúng có nghĩa — nếu không, mọi bước sau sẽ làm việc với những cái tên vô nghĩa.

Đáp án

A — Tiến hành phân tích dữ liệu thăm dò (EDA) để hiểu phân bố dữ liệu, xử lý giá trị thiếu và đánh giá mức mất cân bằng lớp, TRƯỚC KHI quyết định giải pháp ML có khả thi hay không.

Vì sao đúng

Đề nêu ba vấn đề đồng thời, và mỗi cái đều nghiêm trọng: | Vấn đề | Mức độ | |---|---| | Chỉ 1.000 bản ghi | rất nhỏ cho bài toán dự đoán 5 năm | | Thiếu giá trị ở đặc trưng quan trọng | ảnh hưởng trực tiếp chất lượng | | Chỉ 5% mắc bệnh | 50 ca dương tính — cực ít |

Và câu hỏi hỏi thẳng: "determine the FEASIBILITY of an ML solution and guide your next steps" — tức là quyết định có nên làm hay không, không phải làm thế nào.

EDA là bước đúng vì nó trả lời được những câu hỏi quyết định:

① Phân bố đặc trưng ra sao? Có đặc trưng nào phân biệt được hai lớp không?
② Thiếu giá trị theo mẫu gì? Ngẫu nhiên hay có hệ thống?
③ 50 ca dương tính có đủ đa dạng để học không?
④ Có rò rỉ dữ liệu không? (một cột nào đó tiết lộ nhãn)

Câu ② đặc biệt quan trọng và hay bị bỏ qua: giá trị thiếu có hệ thống mang thông tin. Nếu bệnh nhân nặng hơn thì hay thiếu kết quả xét nghiệm, thì bản thân việc "thiếu" là một đặc trưng — và điền bừa vào là xoá mất tín hiệu đó.

Với 50 ca dương tính, kết luận của EDA có thể là "chưa nên làm ML" — và đó là một kết luận hợp lệ, thậm chí có giá trị:

50 ca dương  → chia train/test còn ~35/15
             → mô hình nào cũng sẽ có phương sai rất lớn
             → khoảng tin cậy của mọi chỉ số đều rộng

Kết luận thực tế thường là: đi thu thập thêm dữ liệu trước, hoặc thu hẹp bài toán (dự đoán 1 năm thay vì 5 năm, nơi có nhiều ca dương hơn).

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

• B. Áp dụng ngay kỹ thuật oversampling để cân bằng dữ liệu, rồi huấn luyện XGBoost để tối đa hiệu năng trên lớp thiểu số — đây là phương án gần nhất và các kỹ thuật đều đúng, nhưng nó bỏ qua câu hỏi khả thi. Oversample 50 ca lên 950 không tạo ra thông tin mới — nó chỉ nhân bản cùng 50 mẫu đó, và model sẽ học thuộc chúng.
• C. Huấn luyện mạng nơ-ron sâu (DNN) vì DNN xử lý được tập dữ liệu nhỏ nhờ học được mẫu phức tạp — sai về nguyên lý: DNN cần nhiều dữ liệu HƠN model đơn giản, không phải ít hơn. Với 1.000 bản ghi, DNN gần như chắc chắn overfit.
• D. Sinh dữ liệu tổng hợp để tăng kích thước rồi huấn luyện hồi quy logistic đơn giản — dữ liệu tổng hợp chỉ tái tạo mẫu đã có, nó không thêm thông tin. Và với dữ liệu y tế, dữ liệu tổng hợp có thể khuếch đại thiên lệch trong 50 ca gốc.

Ghi nhớ

EDA luôn là bước đầu tiên — và một trong những kết luận hợp lệ của nó là "bài toán này chưa đủ dữ liệu để làm".

Bốn câu hỏi EDA phải trả lời trước khi cam kết làm ML: | Câu hỏi | Vì sao | |---|---| | Có tín hiệu trong dữ liệu không? | đặc trưng có phân biệt được hai lớp không | | Đủ mẫu lớp thiểu số không? | quy tắc thô: cần ít nhất vài trăm ca dương | | Giá trị thiếu theo mẫu gì? | ngẫu nhiên thì điền được; có hệ thống thì mang thông tin | | Có rò rỉ dữ liệu không? | chỉ số quá đẹp thường là dấu hiệu rò rỉ |

Ba loại giá trị thiếu — cách xử lý khác nhau: | Loại | Nghĩa | Xử lý | |---|---|---| | MCAR | thiếu hoàn toàn ngẫu nhiên | điền hoặc bỏ đều được | | MAR | thiếu phụ thuộc đặc trưng khác | điền có điều kiện | | MNAR | thiếu phụ thuộc chính giá trị bị thiếu | tạo cờ "đã thiếu" làm đặc trưng |

Loại thứ ba là loại hay gặp trong dữ liệu y tế và cũng nguy hiểm nhất khi xử lý sai.

Ba lựa chọn khi EDA kết luận dữ liệu chưa đủ: | Lựa chọn | Chi tiết | |---|---| | Thu thập thêm | tốt nhất, tốn thời gian | | Thu hẹp bài toán | dự đoán 1 năm thay vì 5 năm — nhiều ca dương hơn | | Đổi cách tiếp cận | model dựa trên luật, hoặc điểm rủi ro có sẵn trong y văn |

Và điều quan trọng nhất về mặt nghề nghiệp: nói "chưa nên làm ML" là một kết luận có giá trị. Xây một model từ 50 ca dương rồi để nó tham gia quyết định lâm sàng nguy hiểm hơn nhiều so với việc thừa nhận dữ liệu chưa đủ.